On Wed, 18 Feb 2009, Wolfgang Denk wrote:
Dear ksi@koi8.net,
In message Pine.LNX.4.64ksi.0902181400470.5729@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@home KOI8 Net < > The impossible we do immediately. * * Las Vegas NV, USA < > Miracles require 24-hour notice. * ******************************************************************