[U-Boot] [PATCH v2 08/17] dm: i2c: Add a uclass for I2C

[Masahiro Yamada]

Hi Heiko, Simon,

On Fri, 21 Nov 2014 08:24:18 +0100
Heiko Schocher <hs at 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.




> >>
> >>
> >
> > 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