[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, ®, 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