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

Masahiro Yamada
2014-11-21T08:18:12Z

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.

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