Hi Masahiro,
On 21 November 2014 09:18, Masahiro Yamada yamada.m@jp.panasonic.com wrote:
Hi Heiko, Simon,
On Fri, 21 Nov 2014 08:24:18 +0100 Heiko Schocher hs@denx.de wrote:
Likewise, when we read data from a EEPROM chip connected to i2c bus,
We generally send/receive [byte 0] SLAVE_ADDR (7bit) + W flag [byte 1] Offset address in EEPROM where you want to start reading [byte 2] SLAVE_ADDR (7bit) + R flag [byte 3] RData 0 [byte 4] Rdata 1
[byte 1], [byte 3], [byte 4] are data written/read via I2C bus.
In my view, each I2C driver should handle [byte 0] and [byte 1] in its ".write" operation and [byte 2], [byte3], [byte 4], .... in its ".read" operation.
Yes, but this changes the current U-Boot API ...
I am hoping the translation code will be implemented in drivers/i2c/i2c-uclass.c, I think.
That's right, no change to the U-Boot API.
We could certainly change this. I'm not sure that I have a strong opinion either way.
I haven't to date seen an I2C chip where we don't have an address as the first byte. If we change the API at the driver level, which I think is what we are discussing, then we would need to move to a message array format. The read transaction would become two elements: a write (for the address) then a read (to get the data).
If we want to change it, we should do it now. My question is, what is the point? Will we really want >2 elements in the message array, do we
Do we need more than 2 elements? But of course, if we go into this direction we should support n elements ...
want more control over how transactions are done (repeated start, etc.)? I'm not sure. Still it would be a fairly low-impact change I
Thats the point ... do we need all this stuff in U-Boot?
feel. We are changing the drivers anyway, so changing the uclass-to-driver API would be feasible. One advantage perhaps it that it would match Linux more closely.
Perhaps Heiko can share an opinion here?
This implements that we must adapt each i2c driver "a little bit more" right? But I think, as we go with this approach more into the linux direction it sounds good to me (maybe we can directly use linux i2c drivers? ... that sounds good, and maybe should be a goal too?). I could not really say how many work this would be, but as we do this change step by step it is worth to go in this direction, as we can cleanup here and there (especially the eeprom driver) some "suboptimal" code ...
Thinking about it ... maybe we start from scratch with i2c drivers for DM and try to use linux i2c drivers?
Anyway, DM is a giant change. I think it is the best (and perhaps the last) opportunity to implement things correctly.
OK, any other opinions? I'm leaning towards going with Masahiro's idea.
Regards, Simon