[U-Boot] [PATCH] 0/12 Multiadapter/multibus I2C

[Heiko Schocher <hs@denx.de>]

Hello ksi,

ksi at koi8.net wrote:
> On Sun, 15 Feb 2009, Heiko Schocher wrote:
>> ksi at koi8.net wrote:
>>> On Sat, 14 Feb 2009, Heiko Schocher wrote:
>>>> ksi at koi8.net wrote:
>>>>>> ksi at 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
-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany