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

[Simon Glass]

Hi Masahiro,

On 21 November 2014 09:18, Masahiro Yamada <yamada.m at jp.panasonic.com> wrote:
> 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.

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