Dear ksi@koi8.net,
In message Pine.LNX.4.64ksi.0902162132540.27482@home-gw.koi8.net you wrote:
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.
It is not complex. Quite in the contrary, it is much simpler and more straightforward to have 2 sets of functions for 2 adapters in one place than to have one that includes both of them in one place switchable using some global variable at another place used by wrappers in a third place.
To code I've seen so far looked pretty complex, and the fact that we've spend many rounds of discussion here seems to indicate a certain level of cmplexity, too.
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.
You will have to pick that one for each and every board somehow...
Only for those boards that need it, whichis a tiny fraction of all boards which use I2C. And there,it should be trivial to configure in the board config file.
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.
Eh, I don't see any problem initializing all I2C controllers at the same time. What is the problem with that?
Why would you do that? It makes little sense to initialize components that may never be accessed at all.
Then, we _DO_ already initialize _ALL_ controllers in U-Boot. Most of the time the total number of controllers is 1 and we do initialize all of them. In those rare cases when that number is not 1, we _DO_ initialize all of them (look at fsl_i2c.c as it is in the main tree right now.) Existing i2c_init() function does not have any provision for initializing any particular controller; it initializes them all.
When we re-implementing that code, we should fix that error instead of copying it.
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?
Is something wrong with those numbers?
You seem to claim that soft-I2C cannot run at 400 kHz clock. I doubt that claim.
I tend to say that an U-Boot port where instruction cache is disabled is misconfigured and should be fixed :-)
Eh, everything is easy when you have your RAM running and all handicaps dropped off... Just try to run 100 meters with heavy weights on your legs and you will see you can not compete with sprinters :)
We're at the point: who needs I2C before relocation to RAM? Only a small fraction of all boards. How many of these use soft-I2C? An even smaller fraction. For how many of these is it critical to run at 100 kHz I2C clock or faster? Well, I think the answer is none here.
We're wasting time and efforts on a non-issue.
Best regards,
Wolfgang Denk