Dear ksi@koi8.net,
In message Pine.LNX.4.64ksi.0902152236430.17769@home-gw.koi8.net you wrote:
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.
We don't have to make the mainline U-Boot implementation unnecessary complex just for the small chance that there is sombeody stupid enough to design a broken system.
It is our task as software engineers to tell the hardware designers which designs are easy to support, nd which will cause problems in the software.
There is also another consideration -- when having several adapters which one should be initialized at boot time, before relocation? Another problem
The one that is needed there, if any at all.
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.
Your suggestion requires total LOGIC change.
Maybe. But that's why we're discussing this here.
Is this needed? If so, you must before call a i2c_set_bus_num(), and after you finished call it again with the old busnumber. So it is done for example in do_date () common/cmd_date.c
You can not do it before all adapters are initialized. And you WON'T be able to initialize adapters because you will not be able to switch busses.
This sounds like a design problem to me, then.
Please keep in mind that according to U-Boot philosophy it is forbidden to always initialize all adapters. Only those actually used by U-Boot may be initialized, and shall be de-initialized after use.
Yes, thats a point. But do we need this before running from ram (except one hardwareadapter)?
Yes, see above.
Um... Maybe I missed something - did you give an example (except for broken designs) where this really might be needed?
Yes, I know. But again, do we need this?
We do. Otherwise we can essentially throw everything to trash and start over. This requires changing the logical design, architecture. And this is that logic that is most difficult and takes most thinking. Coding is easy.
You say: "we do [need that]". I ask: why? what for?
Another reason why macros are used is speed. Not everyone is running U-Boot on 10 GHz Pentium-9 with gigabyte of cache. In bitbanged I2C every instruction counts if you want to run a bus at a decent speed (I won't even start with regular 100kHz less for 400kHz; 50kHz would be very good.) Your
Are you sure? If I remember correctly soft-I2C can even run 400 KHz on a slow 50 MHz MPC8xx system.
Do you have other numbers?
must be executed. And remember, there is probably no instruction cache and you're running off of flash so every instruction fetch is something like
I tend to say that an U-Boot port where instruction cache is disabled is misconfigured and should be fixed :-)
Best regards,
Wolfgang Denk