Hi Masahiro, On 21 November 2014 09:18, Masahiro Yamada <yamad...@jp.panasonic.com> wrote: > Hi Heiko, Simon, > > On Fri, 21 Nov 2014 08:24:18 +0100 > Heiko Schocher <h...@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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot