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

[ksi at koi8.net]

On Wed, 18 Feb 2009, Wolfgang Denk wrote:

> Dear ksi at koi8.net,
> 
> In message <Pine.LNX.4.64ksi.0902181400470.5729 at home-gw.koi8.net> you wrote:
> >
> > How would you know what to initialize and what not to? We were initializing
> 
> I don't know. You probably need some way to encode some kind of
> routing information that tells you which adapter(s) need to be
> initialized to reach some specific device.

It's already there. ADAP(bus_no) macro takes care of this returning the
right adapter .

> > _ALL_ I2C adapters up to today with a single i2c_init() function. It just
> 
> Yes, that's the status quo. And it is not good as is, and shall be
> changed.
> 
> > It is easy to initialize just a selected set of adapters in the new code but
> > how do we decide what to initialize and what not to?
> 
> Good question. Probably each  I2C  device  will  have  some  list  of
> bus/adapter  ID's  that need to be up to access it, and that will get
> shut down afterwards.

Eh, that is what I call overcomplicated... And it definitely does not belong
to I2C subsystem per se, it's up to the board developer to know which bus
each device is connected to. I2C system can not now where that "afterwards"
happen. If we are reading something from a device, checking some bit,
writing something else back depending on that bit and then repeat the entire
cycle (let's say we are polling for something and until that something
happened we are sending a "please continue" command back to that device,
then we tell it "thanks, stop now",) where in this sequence that
"afterwards" happens?

> > Should we add a config option like CONFIG_I2C_INIT_ADAPTERS {1,3,5,9} ? But
> 
> No, because we probably do not need to activate all tehse adapters at
> the same time.
> 
> > Or should we remove i2c_init() from _ALL_ common places and let board
> > developers to call i2c_adap[X]->init() as they see fit? But that is a big
> > rewrite... And there is another place, cmd_i2c.c that must be taken care
> > of...
> 
> You will always call i2c_init() for a specific I2C device.
> 
> The code should automatically know which adapters need to be  initia-
> lized  to  "talk"  to that device. Yes, you must somehow describe the
> I2C bus topology, but a single one-way description for the path  from
> the specific device to the CPU should be sufficient.

Topology is already there, this is not a problem. That is that
initinialization that is. The a.m. approach means the I2C layer should not
initialize anything at all, it should only provide API to do it (that it
does.) It is up to each board developer to call appropriate init function
when needed. That means huge, no, even _HUGE_ rewrite with entire U-Boot
affected. And this is not grep-and-replace kind of job, it requires intimate
knowledge of the boards affected...

Sorry, I do not have _THAT_ much time, my board is already on a
pick-and-place machine and I will have to start the bringup process really
soon...

> 
> > There is also no way of DE-initilizing those interfaces so that init is like
> > a gun trigger -- once it is pulled, there is no way to bring the bullet
> > back.
> 
> That needs to be changed, too.

Again, most of the drivers disable the adapter when transfer is complete but
that does not involve turning of its power or clock or reconfiguring GPIOs
or whatever else it was before initial adapter init. Then, it is all
different for different chips. E.g. OMAP can only turn power on/off for all
I2C adapters so initializing any of them should turn the power on and it
must not be turned back off until the last adapter is shutdown. Pinmuxes are
usually configured as a part of board setup etc.

This means a whole lot of, IMHO, absolutely unneeded work.

> > And the final question -- what is wrong with initializing all I2C adapters
> > for a handful of boards that have more than one? What is the problem? I can
> 
> Initializing things that are not actually  needed  is  bad  for  many
> reasons. It takes time, and boot time is critical on many systems. It
> increases  the  power  consumption,  and  we have a growing number of
> mobile devices where power consumption is critical.  It  carries  big
> potential for "unexpected" behaviour (read: nasty failure modes), and
> so on.
> 
> There are projets around that paid a bite  price  for  not  deinitia-
> lizing  devices  after  use.  I2C  may be relatively harmless, but we
> thought the same about USB until it bit. And it bit  hard.  That's  a
> lesson learned.

I'd say it should not be treated as "never do it again" but rather as "take
caution"... 

> > make that init_all function a weak alias so if there's some problem with
> > performing total init it can be replaced with board-specific function. But
> > frankly I can not see any problems with initializing all 2-3 adapters for
> > a few multiadapter boards...
> 
> A rule is a rule is a rule.

Eh, never say never...

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