[U-Boot] [PATCH] 7/12 Multiadapter/multibus I2C, drivers part 4

[ksi at koi8.net]

On Tue, 17 Feb 2009, Wolfgang Denk wrote:

> Dear ksi at koi8.net,
> 
> In message <Pine.LNX.4.64ksi.0902171233390.30435 at home-gw.koi8.net> you wrote:
> >
> > What is unreadable in that code?
> 
> It gets out of control. You don;t see any more how much code gets
> generated from that.

Why not?

But anyways, I can make those instances manually, without CPP
participations. Would it be better?

> > > This is a boot loader with limited resources, not a general purpose
> > > OS.
> > 
> > It doesn't matter. It is much better to have a uniform API for all the
> > future developers to use than to multiply horrible hacks and reinventing the
> > wheel again and again.
> 
> Well, I tell you again that size does matter, and may even be a
> killing point when deciding abouut a patch.

There is no much size increase here. Also it is still possible to simply
include just those adapters that are required for SPD and thus reduce size
if several I2C drivers make it too big.

> > > What makes you insist that we cannot change a variable if we need to
> > > be able to change one?
> > 
> > It is NOT just variable. My approach uses i2c _BUS_, not _ADAPTER_. And
> > number of busses can be bigger than number of adapters (e.g. when some
> > busses a reached via muxes or switches.) When doing i2c_set_current_bus()
> > you are switching _NOT_ adapters, but busses. That involves not only
> > changing that global variable but also reprogramming muxes/switches for
> > i2c_set_current_bus() to be consistent and hardware independent. Otherwise
> > your code should know if that particular bus it is switching to is directly
> > connected or switched and check the bus it is switching from for muxes. If
> > they are switched, your code should disconnect the current bus switches,
> > then do that i2c_set_current_bus() and connect the switches to the new bus
> > after that.
> > 
> > That means that code MUST somehow know the topology to take appropriate
> > actions and properly configure those switches. That means you should somehow
> > describe that topology for each and every board in CONFIG_* terms and make
> > each and every place at U-Boot that invokes _ANY_ i2c function to take care
> > of that switching.
> 
> You convinced me. This code must not be used before relocation to RAM,
> then.
> 
> [On the other hand I still wonder why I have never seen any such
> board appear to me in real life yet. None of the 500+ boards
> supported in U-Boot uses any such configuration.]

Eh, for those 500+ (actually 472 judging on the number of files in
include/configs) boards there are at least twice that many that were never
submitted to the U-Boot tree... I have ported U-Boot/Linux to at least 10
different boards that were never submitted anywhere myself. You know,
company only pays for making their boards work, not for pushing them in the
official tree.

This is the second company where I have a luxury of crafting patches for
submission (the first one was that now defunct that allowed me to push that
Davinci port.)

And one can not even imagine what runaway hardware designers can design... I
still remember some Brasilian MPC8560/Fujitsu ARM boards that were pure
nightmare to work on :(

> > And yes, we DO have some boards with switched I2C busses in U-Boot main tree
> > so this is NOT a hypothetical situation.
> 
> Yes, it is, because none of them needs any such switching before
> relocation. And switching is really simple so far.

No, it is not easy. You simply did not dig deep enough :)

> > > > And the million dollar question -- what is the potential gain?
> > > 
> > > Indeed. The  same  question  goes  to  you  -  where  is  this  added
> > > complexity  really  needed? So far nowhere. Are we just talking about
> > > hypothetical cases, or about a real design? How  many  such  designs?
> > > Just a single one?
> > 
> > Please see above.
> 
> You did not answer my question.

OK, this is not about using multiple I2C busses before relocation and using
them right now for any of existing boards (some of which are actually dead
or vaporware.)

This is about consistent logical API for multiple I2C busses. As for
multiple busses I personally need that right now for my new board. That
board has 2 ST Micro M41ST87 chips on it (braindead chip, I wouldn't've used
such a weirdo but it is "certified" by our licensing authorities so I have
to) and DS1307 RTT. M41ST87 is a Tamper Detector with RTT but I can not use
those RTTs for timekeeping because they are frozen to give a tamper event
timestamp hence the separate RTT.

Operation procedure requires to check for tamper events on bootup and if
one's detected the system must log the current bootup time, give some
indication to the user and halt for proper authorities to investigate.

The problem is M41ST87 uses a fixed I2C address, 0x68 that is also used by
RTT. That means I need 3 I2C busses to talk to those 3 chips...

And this is just a first such board out of a whole bunch that we have in
various stages. The next one, OMAP3-based, is almost ready, we should have
prototypes in a month or two. And we are not the only players at that niche
market (however very old ones,) there are others.

And this is just one of heavily regulated industries (you know those big
shiny casinos on Las Vegas Strip, don't ya? :) There are others with
different braindead requirements out there...

---
******************************************************************
*  KSI at home    KOI8 Net  < >  The impossible we do immediately.  *
*  Las Vegas   NV, USA   < >  Miracles require 24-hour notice.   *
******************************************************************