[U-Boot] [PATCH v3 08/10] dm: Add a simple EEPROM driver

Masahiro YAMADA yamada.m at jp.panasonic.com
Wed Dec 3 17:03:41 CET 2014


Hi Simon,



2014-12-04 0:18 GMT+09:00 Simon Glass <sjg at chromium.org>:

>> Moreover, can we read data from EEPROM
>> without knowing if its parent is I2C bus or SPI bus ?
>>
>>
>> My rough image is like this:
>>
>> int eeprom_read(struct udevice *dev, int offset, uint8_t buf, int size)
>> {
>>         struct udevice *bus = dev->parent;
>>         struct generic_bus_operation *ops = bus->uclass->uc_drv->ops;
>>
>>         return ops->read(dev, bus, offset, buf, size);
>> }
>>
>> I am not sure, but if this approach is possible,
>> we do not need to have both of "i2c_eeprom uclass" and "spi_eeprom uclass".
>>
>> struct generic_bus_operation is the operaton some uclasses have.
>>
>> We can move i2c_read() and i2c_write()
>> to struct generic_bus_operation of i2c uclass.
>>
>> Likewise, we can move spi_read() and spi_write()
>> to struct generic_bus_operation of spi uclass.
>
> Yes we should do join up I2C and SPI. In order to do it we need SPI
> uclass to support reading and writing a particular offset (rather than
> just the current generic xfer()).
>
> Perhaps we should have a generic register access uclass. Drivers that
> want to support it could add themselves to the I2C and REGISTER
> uclass. But it would be better to handle this entirely in the I2C/SPI
> uclasses if we can.
>
> I added Przemyslaw as he needs something like this for the PMIC uclass.

Good.
Or you can do this after SPI uclass things are prepared.
Please feel free to postpone it if it is too much work to be included
in this series.

Except some minor mistakes, this series looks good!


-- 
Best Regards
Masahiro Yamada


More information about the U-Boot mailing list