Hi Heiko, Simon, On Fri, 21 Nov 2014 08:24:18 +0100 Heiko Schocher <[email protected]> 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. > >> > >> > > > > 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. Best Regards Masahiro Yamada _______________________________________________ U-Boot mailing list [email protected] http://lists.denx.de/mailman/listinfo/u-boot
