ksi@koi8.net wrote:
On Tue, 16 Dec 2008, Timur Tabi 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!
Eh, we don't have any uniformity. That "uniformity" we do have is only for a trivial case of a single I2C bus. Everything else is a bunch of SoC specific hacks made differently fo different platforms. The fsl-i2c.c e.g. uses local bus number variable.
[snip]
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.
I can see nothing wrong with that but I also have nothing against changing all i2c_{read,write,probe}() functions to take bus number as an argument.
I offered 4 possible scenarios and additional parameter to i2c functions was one of them. Wolfgang said that current bus approach looks better than others and I agree with him. But it is not rocket science to use an additional parameter either. The only thing is it MUST be consistent, i.e. we should NOT have 2 different sets of functions based on CONFIG_MULTIBUS or whatever. If we are to make this change ALL boards must be multibus with majority of them having bus count of 1.
Does anybody else have something to say on this? I'm going to write code so let's make some decision. I don't want this to end up as a company hack and making it properly affects a lot of U-boot...
IMHO Sergey's approach is reasonable. It is pragmatic in that it builds on and improves the existing method. It only touches boards with multiple i2c buses.
The best is the enemy of the good. - Voltaire http://www.bartleby.com/66/2/63002.html
My two cents, gvb