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

[Sascha Hauer]

On Fri, Jun 20, 2008 at 11:28:52AM -0500, Menon, Nishanth wrote:
> 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.

Are you aware of device parameters? Well, you are, they are used for
setting the mac address and stuff like that. Maybe this would be a
possibility for the user to change the address width.

> 
> > > 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.

I don't think that this has to be dependent on an additional config
option. I mean, is there something sensible left when this option is
disabled?

> 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

I haven't thought that to the end, that was just an idea, but it looks
plausible. Please use 0 as base to simple_strtoul() so that the base is
determined by the prefix.

> 
> 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?).

Hm, what should the output look like for 'md /dev/i2cbusX'? How about
another command:

i2cdetect -f /dev/i2cbusX
- try to detect slave devices on a bus and register them.

or maybe just 'i2cadd -d -f /dev/i2cbusX' (d for detect) instead of
another command.

> 
> devinfo /dev/i2cbusX will display i2c functionality.

whereas devinfo /dev/i2cbusX_Y could show the access mode (7bit/10bit
addressing) and give the user a chance to change it.

> 
> 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.

It shouldn't need any changes, at least no i2c specific ones. If it
does, we did something wrong.

> 
> Does this strategy work ok for eeproms?

Why not? When we have a eeprom slave driver together with a /dev/eepromX
device node, everything should be fine.

> 
> The only negative I see is that folks need an additional command
> to create a device node.

Normally they wouldn't need it because mostly the board would register
all devices available on the system. This may not be true for your
board, but most boards I have only have an eeprom, a rtc and only a few
other devices connected to the i2c bus. It's not a big memory penalty to
register them.


Regards,
  Sascha


-- 
Pengutronix e.K. - Linux Solutions for Science and Industry
-----------------------------------------------------------
Kontakt-Informationen finden Sie im Header dieser Mail oder
auf der Webseite -> http://www.pengutronix.de/impressum/ <-