Hello ksi,
ksi@koi8.net wrote:
On Sun, 15 Feb 2009, Heiko Schocher wrote:
ksi@koi8.net wrote:
On Sat, 14 Feb 2009, Heiko Schocher wrote:
ksi@koi8.net wrote:
ksi@koi8.net wrote:
> Here is the second attempt for initial portion of multibus/multiadapter > I2C support.
[...]
When running from ram, this is no problem. It should be set in i2c_set_bus_num().
Yep. But nobody's perfect and you can have a situation when you need to access several busses before relocation. It is not hardware for U-Boot, it is U-Boot for hardware. When hardware designers design their hardware they don't make their decisions based on U-Boot limitation. That is us who should accomodate what they designed.
Din;t know, there is such a design.
There is also another consideration -- when having several adapters which one should be initialized at boot time, before relocation? Another problem is init() function that can be unique for each adapter. To make the lower layer transparent I'm reprogramming muxes if any when switching busses. It is necessary to make I2C API simple and uniform between muxed and non-muxed busses. That essentially means that we can NOT do i2c_set_bus_num() to execute init() for a particular adapter -- adapter MUST be initialized for i2c_set_bus_num() to succeed.
Hmm.. okay, but we can also call from i2c_set_bus_num() when running in flash first the init() function ... but that wouldn;t be nice, you are right.
Remember, i2c_init is quite often called BEFORE the code is relocated to RAM so you can NOT change "current" adapter.
Yes, thats a point. But do we need this before running from ram (except one hardwareadapter)?
Yes, see above.
Yes, thats is a problem in my approach, and if we need more then one i2c bus when running from flash, maybe a no go.
[...]
That is if we want to keep the original I2C API. The other, simpler way is to add an argument to each and every function, a pointer to i2c_adap_t structure or its index or something similar. But that defeats the entire purpose of this code by requiring to find and change each and every call to any I2C function in the entire U-Boot source thus totally breaking ALL existing code 99.99% of which only use single I2C adapter/bus...
That would be a hard way.
That is why I spent a week thinking about the design that would allow to keep most of existing code.
Thats why I discuss with you, to get this infos ;-)
[...]
If we really need more then one bus when running from flash, this is a problem.
No, that's not just that. There are multiple reasons why the original driver had been made with macros.
First, it is _SMALLER_ when done this way. Most of those macros (I2C_SCL etc.) translate into 1 to 3 assembly instructions depending on particular processor code set. Except some special cases the most complex operation they do is changing a bit at some address that takes 3 instructions if particular CPU can not change set/reset bits directly - read->modify->write. Many CPUs can make it in 1 to 2 instructions.
Ok.
There is no way how you can avoid those instructions -- the work must be done. You insist on making them into functions (there is no other way if they reside in another object file.) That means that you do NOT eliminate
As I said, it should be possible to do this also in macros. But you are right, there is always a +switch, which will cost more code ...
bye Heiko