Dear Timur,
In message 4947F8B4.8070804@freescale.com you wrote:
ksi@koi8.net wrote:
That looks messy... Why would we use two different versions if we can make everything uniform?
Because we already have something that makes it uniform, and it's broken. The idea of having a "current i2c bus" that needs to be set before read/write operations can be performed is the broken part!
Hm... what exactly is broken with the concept of having a "current device" or a "current bus"? We use it elasewhere, too (like for selection IDE or S-ATA devices and such), and so far I am not aware of fundamental issues because of that.
You sound as if we were designing a system where tens of independend users could log in simultaneously and concurrently access different devices on different busses.
But this is NOT the case. We're strictly single user, single threaded, and when one command is runnign we are certain that there cannot be any interference from other I2C accesses.
Eh, you can just set bus number every time you're gonna do i2c read/write...
Not with the current i2c command line. We would need another global variable in the i2c command line code to store what IT thinks is the current bus.
Not really. It is really sufficient to set the bus for each command. There is no need to save and restore any previous state, because accesses cannot be nested because of the way how U-Boot is designed.
That i2c_get_bus_num() doesn't make any sence at all. Just set bus number every time you access i2c device.
That's risky. Sooner or later, you will want to know what the current bus number is, at least for debugging or status purposes.
The design has been discussed before, and I see little reason why we should not throw all this away and come up with something new, more complicated.
Sounds to me like you haven't really looked at the U-Boot code. There are plenty of places where one function does I2C operations, then calls another function that does its own.
Really? Where exactly does such a thing happen?
I tend to call this a bug that needs to be fixed, if there is ssuch code.
I think all this boils down to one core disagreement we have: I think the idea of a "current" i2c bus is a bad one.
This statement is probably correct: I don't share your point of view here, either.
Best regards,
Wolfgang Denk