[U-Boot] [PATCH v3 10/10] dm: i2c: tegra: Convert to driver model

Simon Glass sjg at chromium.org
Wed Dec 3 17:37:51 CET 2014


Hi Masahiro,

On 3 December 2014 at 08:52, Masahiro YAMADA <yamada.m at jp.panasonic.com> wrote:
> Hi Simon,
>
>
> 2014-12-04 0:23 GMT+09:00 Simon Glass <sjg at chromium.org>:
>
>>>> -/* Probe to see if a chip is present. */
>>>> -static int tegra_i2c_probe(struct i2c_adapter *adap, uchar chip)
>>>> +static int tegra_i2c_set_offset_len(struct udevice *dev, const uint olen)
>>>>  {
>>>> -     struct i2c_bus *bus;
>>>> -     int rc;
>>>> -     uchar reg;
>>>> -
>>>> -     debug("i2c_probe: addr=0x%x\n", chip);
>>>> -     bus = tegra_i2c_get_bus(adap);
>>>> -     if (!bus)
>>>> -             return 1;
>>>> -     reg = 0;
>>>> -     rc = i2c_write_data(bus, chip, &reg, 1, false);
>>>> -     if (rc) {
>>>> -             debug("Error probing 0x%x.\n", chip);
>>>> -             return 1;
>>>> -     }
>>>> -     return 0;
>>>> -}
>>>> +     if (olen < 4)
>>>> +             return 0;
>>>
>>>
>>> The maximum length 4 is not tegra-specific.
>>> I can't find good reason to have .set_offset_len handler.
>>
>> It's not needed here as 4 is the maximum supported by the uclass. Some
>> drivers may support less though, so perhaps we should keep the method?
>>
>
> I think this handler is totally useless.
>
> Moreover, the offset address within a chip is out of the scope of I2C protocol.
> I think it is odd for each of I2C drivers to care about it.

The Intel SPI driver requires us to figure out the offset from the
spi_xfer() call, and it is painful. I wondered if there might be I2C
drivers that need to do the same thing. I have not looked.

Regards,
Simon


More information about the U-Boot mailing list