Hi Heiko,
On Wed, Jan 18, 2012 at 10:35 PM, Heiko Schocher hs@denx.de wrote:
Hello Wolfgang, Timur, Simon,
Wolfgang Denk wrote:
Dear Simon Glass,
In message CAPnjgZ2kLPfMzzwgHkDJ4eL+wixqLv89+CvdVP7PCcy+XFaqNQ@mail.gmail.com you wrote:
I was really hoping we could get rid of the concept of a "current" i2c adapter, and just force all drivers to specify the I2C adapter they want to use for a given I2C operation. =A0That's how Linux operates, and it will prevent stuff like this:
I agree completely, it was one of the things I was going to ask for. We should add a new parameter to calls instead IMO.
Let's do one step at a time. Now we go for multi-bus support.
Ok.
Implementing a new, better device interface is one of the next steps, then.
Some thoughts to the subject "get rid of concept of a current i2c"
First, it would be great to get rid of that ;-)
2 reasons why we currently need the info, what is the current
i2c adapter/i2c bus:
- U-Boot principle says, don't init a device, if you don't use it.
So, if we switch to another i2c adapter or i2c bus (A i2c bus is a combination if one i2c adpater and n i2c muxes), we must deinit the current adapter/bus. Ok, current code didn't this too, but this should a goal to keep in mind ... or we define, that this is not needed.
- If we have i2c muxes, and you don't know your current i2c bus,
you must on every i2c access also setup the i2c muxes on this i2c bus ... would we do this really?
Ignoring muxes, we can have more than one i2c adaptor inited at a time (i.e. de-initing is optional).
Perhaps reword this slightly. U-Boot can have knowledge of a current adaptor, mux settings and so on, and use this internally within the i2c layer to optimise performance and redundant i2c traffic. But the pain is when the concept of a 'current adaptor' is exposed outside the i2c layer.
if we have the current i2c bus info, we just have to check, if we are on this bus, and do the i2c access ... if we are not on this i2c bus, we can deinit it complete (the new i2c_core disconnects for example all i2c muxes on the i2c bus) and init the new bus. All this work is done in a central function i2c_set_bus_numer()
Yes but this function could become internal perhaps.
- Looking in the new multibus i2c_core.c file, we should get rid of
static unsigned int i2c_cur_bus __attribute__((section(".data"))) = CONFIG_SYS_SPD_BUS_NUM;
and "cur_adap" renamed to "cur_i2c_bus" and should be a "struct i2c_bus_hose" pointer.
Sounds good. Heiko do you have time to take over your two patches I sent and tidy them up, or should I continue?
Regards, Simon
bye, Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany