Hello ksi,
ksi@koi8.net wrote:
On Mon, 16 Feb 2009, Wolfgang Denk wrote:
Dear ksi@koi8.net,
In message Pine.LNX.4.64ksi.0902142104100.6240@home-gw.koi8.net you wrote:
OK, please explain how that cur_adap_nr->hwadapnr gets assigned. Please also explain how can one invoke a function on other adapter than "current". Remember, i2c_init is quite often called BEFORE the code is relocated to RAM so you can NOT change "current" adapter.
We could assign an entry in the global data for it.
But then - how often will it bbe necessary to switch adapters before relocation? What is I2C being used for? To read the SPD data for the RAM init code. Which other adapter would be needed?
I can not tell it right away. There might be several RAM DIMMs with their own SPD EPROMS sitting on different busses or something else. It is not like we absolutely need this feature right now, urgently but it is so easy to implement that it would've been a crime to not to... :)
There is another problem with choosing a proper i2c_init() function with i2c_set_bus_num() -- the latter also reprograms I2C multiplexers/switches if there are any so you essentially need an initialized adapter to switch to it to initialize it. Catch 22...
That would not be a problem:
if we are running from flash we could always init in i2c_set_bus_num() first the new controllor to which we switch. And if we are running in ram we can always check in i2c_set_bus_num() if adap->init_done in i2c_adap_t is 1. If this is not so, we first init the bus! With this, it should be possible to get rid of all this i2c_init calls all over the code ...
One requirement for this: All "old" code who directly call i2c_read, i2c_write, ... must, if this new feature is activated, call a i2c_set_bus_num() before accessing the bus. But this would be only "work" (grep and fix).
bye
Heiko