[U-Boot-Users] [Patch 5/9]U-boot-V2:cmd: add I2C commands

[Menon, Nishanth]

Sascha,

Summary: Ok, you sold the idea to me.

> -----Original Message-----
> From: Sascha Hauer [mailto:s.hauer at pengutronix.de]
> Sent: Friday, June 20, 2008 10:17 AM
> To: Menon, Nishanth
> Cc: u-boot-users at lists.sourceforge.net
> Subject: Re: [Patch 5/9]U-boot-V2:cmd: add I2C commands
> +int write_i2c(int file, uchar daddr, u16 addr, u8 reg_width, char
> *buffer,
> +             size_t count)
>
> These arguments map nicely to md/mm
Not exactly as of date (we can have register width as 16 bit and data width as 8 bit). But yeah, we can easily make md/mm do it. Yep, I have used md to dump nand and cp to write data.

> > What do we achieve by introducing i2c device based nodes?
>
> - An overview over the system for those who are not familiar with it.
>   You may know the devices that are connected to the bus on your board,
>   I don't. One of the benefits in U-Boot-V2 for me is that many different
>   systems behave similarly although they have a very different hardware.
> - when md/mm are usable on a device it also means that cp/memcmp/cat or
>   any other file command is usable.
> - reduction in code size since you can reuse what's already there (like
>   file commands instead of new commands). That's one of the points that
>   make U-Boot-V1 bigger than it has to be.
Ok, getting down to implementation level, here is the proposal as I understand:
1: I2c bus device node:
1.a: For every bus registered, a default device is registered /dev/i2cbusX.
1.b: this will be done by enabling CHARDEV config
2: Device Nodes:
2.a: created only when CHARDEV config is enabled.
2.b: board files can optionally register default devices. That will appear
as: /dev/i2cbusX_Y where X=busID and Y=device address in hex.
2.c: new command i2cadd <options> -f /dev/i2cbusX -d device address in hex

Usage:
md /dev/i2cbusX will do i2cdetect. (writes and any other access will not be supported). In future when smbus is supported, what ever the bus's default feature is, that will be used. This will attempt a 0 byte read only. (What about buses on which we'd want to do detect based on 0 byte writes?).

devinfo /dev/i2cbusX will display i2c functionality.

i2cadd -f /dev/i2cbusX -d 0x49 will create /dev/i2cbusX_49
With default features: 8 bit reg access access, 8 bit data.
Other Options:
Register addressing: 8 or 16 bit
Anything else we can think of..

devinfo /dev/i2cbusX_Y will give device information.

md /dev/i2cbusX_Y will do the equivalent of i2cdump and i2cget

mm /dev/i2cbusX_Y will do the equivalent of i2cset.

The risk I see is in trying to do i2cdetect with equivalent of -q -
quick read. I don't have aneed for it, but does anyone else have?
Another risk in using generic commands.. folks are going to want
some custom feature and extension to the generic commands.. that
is a good thing, and something we can take in when the need comes.

md/mm might need further changes to handle access sizes.

Does this strategy work ok for eeproms?

The only negative I see is that folks need an additional command
to create a device node. Not too bad a tradeoff considering the
other stuff we could do..

Regards,
Nishanth Menon