Hello ksi, k...@koi8.net wrote: > On Sun, 15 Feb 2009, Heiko Schocher wrote: >> k...@koi8.net wrote: >>> On Sat, 14 Feb 2009, Heiko Schocher wrote: >>>> k...@koi8.net wrote: >>>>>> k...@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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
