[U-Boot-Users] Using a second I2C interface

[U-Boot-Users] Using a second I2C interface

[Ben Warren]

Hello,

The CPU I'm using (MPC8349) has two hardware I2C interfaces, and I'd
like to access the second one in U-boot.  Implementing this looks easy
to me, but I don't want to reinvent the wheel if it's already been done
elsewhere.  Has anyone done this?  If not, I'll follow up with a
proposal.

regards,
Ben
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20060512/a8a75115/attachment.htm 

[U-Boot-Users] Using a second I2C interface

[Ben Warren]

Let me follow up by saying that there is some kludgy code that uses the
second port, but it's  hard-coded and not nearly generic enough in my
mind.

Ben

On Fri, 2006-05-12 at 10:36 -0400, Ben Warren wrote:

> Hello,
> 
> The CPU I'm using (MPC8349) has two hardware I2C interfaces, and I'd
> like to access the second one in U-boot.  Implementing this looks easy
> to me, but I don't want to reinvent the wheel if it's already been
> done elsewhere.  Has anyone done this?  If not, I'll follow up with a
> proposal.
> 
> regards,
> Ben
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20060512/9fc6238f/attachment.htm 

[U-Boot-Users] Using a second I2C interface

[Kumar Gala]

On May 12, 2006, at 9:36 AM, Ben Warren wrote:

> Hello,
>
> The CPU I'm using (MPC8349) has two hardware I2C interfaces, and  
> I'd like to access the second one in U-boot.  Implementing this  
> looks easy to me, but I don't want to reinvent the wheel if it's  
> already been done elsewhere.  Has anyone done this?  If not, I'll  
> follow up with a proposal.

Depending on what you want to do, you can cheat and just change the  
pointer to the 2nd interface.  If you want something more full  
featured up to the command level then I think some discussion would  
be required on how the commands should work for specifying which  
controller to use.

- kumar

[U-Boot-Users] Using a second I2C interface

[Ben Warren]

Here's how I've done things in my sandbox:

All public I2C calls take a uchar as the first argument.  Since I2C only
uses 7 bits for addressing, the MSB is unused (at least, at the function
call level.  I know the hardware uses the bit for w/r).  I've
commandeered this bit to denote controller number.  This way, the
existing API doesn't need to be changed, just the drivers that choose to
implement it.  I've modified the MPC8349 driver and the 'iprobe' command
to do this.  To use the other commands, as well as the API itself, I've
just been adding 0x80 manually, but it could be done more nicely like:

#define i2c_wr(bus, dev, ...)  i2c_write((bus)==2 ? dev+0x80 : dev, ...)

Of course, this solution isn't scalable beyond two controllers, but I'm
not sure we need to worry about that.

Any thoughts?

Ben
.   On Fri, 2006-05-12 at 13:00 -0500, Kumar Gala wrote:

> On May 12, 2006, at 9:36 AM, Ben Warren wrote:
> 
> > Hello,
> >
> > The CPU I'm using (MPC8349) has two hardware I2C interfaces, and  
> > I'd like to access the second one in U-boot.  Implementing this  
> > looks easy to me, but I don't want to reinvent the wheel if it's  
> > already been done elsewhere.  Has anyone done this?  If not, I'll  
> > follow up with a proposal.
> 
> Depending on what you want to do, you can cheat and just change the  
> pointer to the 2nd interface.  If you want something more full  
> featured up to the command level then I think some discussion would  
> be required on how the commands should work for specifying which  
> controller to use.
> 
> - kumar
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20060512/c33e880b/attachment.htm 

[U-Boot-Users] Using a second I2C interface

[Howard, Marc]

I had always assumed from reading the U-Boot guide that:

imd chip address[.0, .1, .2] [# of objects]

...meant that imd 50.1 would read I2C address 50 on controller #1.  If
that's not the case then what does the [.0, .1, .2] option do??

Marc W. Howard

> -----Original Message-----
> From: u-boot-users-admin at lists.sourceforge.net 
> [mailto:u-boot-users-admin at lists.sourceforge.net] On Behalf 
> Of Kumar Gala
> Sent: Friday, May 12, 2006 11:00 AM
> To: bwarren at qstreams.com
> Cc: u-boot-users at lists.sourceforge.net
> Subject: Re: [U-Boot-Users] Using a second I2C interface
> 
> 
> On May 12, 2006, at 9:36 AM, Ben Warren wrote:
> 
> > Hello,
> >
> > The CPU I'm using (MPC8349) has two hardware I2C interfaces, and  
> > I'd like to access the second one in U-boot.  Implementing this  
> > looks easy to me, but I don't want to reinvent the wheel if it's  
> > already been done elsewhere.  Has anyone done this?  If not, I'll  
> > follow up with a proposal.
> 
> Depending on what you want to do, you can cheat and just change the  
> pointer to the 2nd interface.  If you want something more full  
> featured up to the command level then I think some discussion would  
> be required on how the commands should work for specifying which  
> controller to use.
> 
> - kumar
> 
> 
> -------------------------------------------------------
> Using Tomcat but need to do more? Need to support web 
> services, security?
> Get stuff done quickly with pre-integrated technology to make 
> your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on 
> Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&
dat=121642
> _______________________________________________
> U-Boot-Users mailing list
> U-Boot-Users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/u-boot-users
> 

[U-Boot-Users] Using a second I2C interface

[Ben Warren]

Marc,

The [.0, .1, .2] refers to the size of the address in bytes, since some
of the bigger EEPROMs (and maybe other things) can address larger than 8
bits.

/*
		 * I2C data address within the chip.  This can be 1 or
		 * 2 bytes long.  Some day it might be 3 bytes long :-).
		 */
		addr = simple_strtoul(argv[2], NULL, 16);
		alen = 1;
		for(j = 0; j < 8; j++) {
			if (argv[2][j] == '.') {
				alen = argv[2][j+1] - '0';
				if (alen > 4) {
					printf ("Usage:\n%s\n", cmdtp->usage);
					return 1;
				}
				break;
			} else if (argv[2][j] == '\0') {
				break;
			}
		}

regards,
Ben

On Fri, 2006-05-12 at 11:37 -0700, Howard, Marc wrote:
> I had always assumed from reading the U-Boot guide that:
> 
> imd chip address[.0, .1, .2] [# of objects]
> 
> ...meant that imd 50.1 would read I2C address 50 on controller #1.  If
> that's not the case then what does the [.0, .1, .2] option do??
> 
> Marc W. Howard
> 
> > -----Original Message-----
> > From: u-boot-users-admin at lists.sourceforge.net 
> > [mailto:u-boot-users-admin at lists.sourceforge.net] On Behalf 
> > Of Kumar Gala
> > Sent: Friday, May 12, 2006 11:00 AM
> > To: bwarren at qstreams.com
> > Cc: u-boot-users at lists.sourceforge.net
> > Subject: Re: [U-Boot-Users] Using a second I2C interface
> > 
> > 
> > On May 12, 2006, at 9:36 AM, Ben Warren wrote:
> > 
> > > Hello,
> > >
> > > The CPU I'm using (MPC8349) has two hardware I2C interfaces, and  
> > > I'd like to access the second one in U-boot.  Implementing this  
> > > looks easy to me, but I don't want to reinvent the wheel if it's  
> > > already been done elsewhere.  Has anyone done this?  If not, I'll  
> > > follow up with a proposal.
> > 
> > Depending on what you want to do, you can cheat and just change the  
> > pointer to the 2nd interface.  If you want something more full  
> > featured up to the command level then I think some discussion would  
> > be required on how the commands should work for specifying which  
> > controller to use.
> > 
> > - kumar
> > 
> > 
> > -------------------------------------------------------
> > Using Tomcat but need to do more? Need to support web 
> > services, security?
> > Get stuff done quickly with pre-integrated technology to make 
> > your job easier
> > Download IBM WebSphere Application Server v.1.0.1 based on 
> > Apache Geronimo
> > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&
> dat=121642
> > _______________________________________________
> > U-Boot-Users mailing list
> > U-Boot-Users at lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/u-boot-users
> > 

[U-Boot-Users] Using a second I2C interface

[Wolfgang Denk]

Hello,

in message <E541A453-EC07-4597-8D60-2EE3919C1A18@kernel.crashing.org> you wrote:
> 
> > The CPU I'm using (MPC8349) has two hardware I2C interfaces, and  
> > I'd like to access the second one in U-boot.  Implementing this  
> > looks easy to me, but I don't want to reinvent the wheel if it's  
> > already been done elsewhere.  Has anyone done this?  If not, I'll  
> > follow up with a proposal.
> 
> Depending on what you want to do, you can cheat and just change the  
> pointer to the 2nd interface.  If you want something more full  
> featured up to the command level then I think some discussion would  
> be required on how the commands should work for specifying which  
> controller to use.

A clean design should allow to switch I2C  busses  usign  a  command;
additionally,  I think we should try to stay backward-compatible with
the existing code. Eventually this is not too difficult:  similar  to
the  "ide"  or  "usb"  commands  we  could  create a new command "i2c
device" which takes as argument the number of the I2C bus which  shal
become  the  current  (=  active)  bus. Then all existing I2C related
commands can be left unchanged (and "i2c  device"  without  arguments
should of course print the ID of the current bus).

In parallel, existing I2C commands could be changed to migrate  to  a
new  "i2c"  group  of  commands:  "imd"  would become "i2c md", "imw"
becomes "i2c mw", "iprobe" becomes "i2c probe", etc. For some  (long)
transition  period old and new commands could be provided in parallel
(at least optionally). Later, the old syntax could be dropped.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Ever try. Ever fail. No matter. Try again. Fail again.  Fail  better.
                                                        -- S. Beckett

[U-Boot-Users] Using a second I2C interface

[Howard, Marc]

> On May 12, 2006, at 9:36 AM, Ben Warren wrote:
> 
> > Hello,
> >
> > The CPU I'm using (MPC8349) has two hardware I2C interfaces, and  
> > I'd like to access the second one in U-boot.  Implementing this  
> > looks easy to me, but I don't want to reinvent the wheel if it's  
> > already been done elsewhere.  Has anyone done this?  If not, I'll  
> > follow up with a proposal.
> 
> Depending on what you want to do, you can cheat and just change the  
> pointer to the 2nd interface.  If you want something more full  
> featured up to the command level then I think some discussion would  
> be required on how the commands should work for specifying which  
> controller to use.
> 
> - kumar

OK, just as a suggestion how about an optional suffix on all the I2C
commands. Ex:

iprobe.2 -- discover valid I2C interfaces on controller #2.

imw.0 (or just imw) -- memory write to address on controller #0 (or the
only controller in most cases).

Seems like it wouldn't break anything to specify the controller this
way.

Marc W. Howard

[U-Boot-Users] Using a second I2C interface

[Wolfgang Denk]

In message <91B22F93A880FA48879475E134D6F0BE028DDE1C@CA1EXCLV02.adcorp.kla-tencor.com> you wrote:
>
> OK, just as a suggestion how about an optional suffix on all the I2C
> commands. Ex:

No, I don't like this. Please see my previous suggestion. It seems to
be more in line with existing commands.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
The use of Microsoft crippleware systems is a sin that  carries  with
it its own punishment.
         -- Tom Christiansen in <6bo3fr$pj8$5@csnews.cs.colorado.edu>

[U-Boot-Users] Using a second I2C interface

[Ben Warren]

Marc,

I'm going to implement something similar to what you've suggested, but
like this:

iprobe <chip>[.1, .2]...

instead of

iprobe[.1, .2] <chip> ...

This 2-controller support will be conditionally compiled if
CONFIG_I2C_2_CTRLS is defined.  I should have some code to share this
afternoon.

regards,
Ben

On Fri, 2006-05-12 at 12:37 -0700, Howard, Marc wrote:

> > On May 12, 2006, at 9:36 AM, Ben Warren wrote:
> > 
> > > Hello,
> > >
> > > The CPU I'm using (MPC8349) has two hardware I2C interfaces, and  
> > > I'd like to access the second one in U-boot.  Implementing this  
> > > looks easy to me, but I don't want to reinvent the wheel if it's  
> > > already been done elsewhere.  Has anyone done this?  If not, I'll  
> > > follow up with a proposal.
> > 
> > Depending on what you want to do, you can cheat and just change the  
> > pointer to the 2nd interface.  If you want something more full  
> > featured up to the command level then I think some discussion would  
> > be required on how the commands should work for specifying which  
> > controller to use.
> > 
> > - kumar
> 
> OK, just as a suggestion how about an optional suffix on all the I2C
> commands. Ex:
> 
> iprobe.2 -- discover valid I2C interfaces on controller #2.
> 
> imw.0 (or just imw) -- memory write to address on controller #0 (or the
> only controller in most cases).
> 
> Seems like it wouldn't break anything to specify the controller this
> way.
> 
> Marc W. Howard
> 
> 
> -------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid\x120709&bid&3057&dat\x121642
> _______________________________________________
> U-Boot-Users mailing list
> U-Boot-Users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/u-boot-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20060515/1c7d8486/attachment.htm 

[U-Boot-Users] Using a second I2C interface

[Andreas Schweigstill]

Hello!

Wolfgang Denk schrieb:
> A clean design should allow to switch I2C  busses  usign  a  command;
> additionally,  I think we should try to stay backward-compatible with
> the existing code. Eventually this is not too difficult:  similar  to
> the  "ide"  or  "usb"  commands  we  could  create a new command "i2c
> device" which takes as argument the number of the I2C bus which  shal
> become  the  current  (=  active)  bus. Then all existing I2C related
> commands can be left unchanged (and "i2c  device"  without  arguments
> should of course print the ID of the current bus).

It has to be taken into account that the I2C busses may have different
adress length. So either the address length has to be read back from
the low-level driver or a table has to be maintained in the I2C command
implementations.


With best regards
Andreas Schweigstill

PS.: Has anybody written some "high-level" I2C commands for chipcard
      interfaces?

-- 
Dipl.-Phys. Andreas Schweigstill
Schweigstill IT | Embedded Systems
Schauenburgerstra?e 116, D-24118 Kiel, Germany
Phone: (+49) 431 5606-435, Fax: (+49) 431 5606-436
Mobile: (+49) 171 6921973, Web: http://www.schweigstill.de/

[U-Boot-Users] Using a second I2C interface

[Woodruff, Richard]

I've can post a diff to some code we use to do this.  I didn't look at
it to closely, but it has worked well.  Select a device, then standard
commands go to it.

Regards,
Richard W.

> A clean design should allow to switch I2C  busses  usign  a  command;
> additionally,  I think we should try to stay backward-compatible with
> the existing code. Eventually this is not too difficult:  similar  to
> the  "ide"  or  "usb"  commands  we  could  create a new command "i2c
> device" which takes as argument the number of the I2C bus which  shal
> become  the  current  (=  active)  bus. Then all existing I2C related
> commands can be left unchanged (and "i2c  device"  without  arguments
> should of course print the ID of the current bus).
> 
> In parallel, existing I2C commands could be changed to migrate  to  a
> new  "i2c"  group  of  commands:  "imd"  would become "i2c md", "imw"
> becomes "i2c mw", "iprobe" becomes "i2c probe", etc. For some  (long)
> transition  period old and new commands could be provided in parallel
> (at least optionally). Later, the old syntax could be dropped.
> 
> Best regards,
> 
> Wolfgang Denk
> 
> --
> Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
> Ever try. Ever fail. No matter. Try again. Fail again.  Fail  better.
>                                                         -- S. Beckett
> 
> 
> -------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services,
security?
> Get stuff done quickly with pre-integrated technology to make your job
> easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache
Geronimo
> http://sel.as-us.falkag.net/sel?cmd=k&kid\x120709&bid&3057&dat\x121642
> _______________________________________________
> U-Boot-Users mailing list
> U-Boot-Users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/u-boot-users

[U-Boot-Users] Using a second I2C interface

[Ben Warren]

Wolfgang,

This sounds like a sensible approach.  This should clean the code up
nicely (as you'll notice, the patch that I submitted yesterday adds
quite a bit of noisy code).  Let's look at what Richard Woodruff
submits, and we can take it from there.

Too bad I didn't get your input until this morning, even though your
message went out on Friday...

regards,
Ben

On Fri, 2006-05-12 at 21:01 +0200, Wolfgang Denk wrote:

> Hello,
> 
> in message <E541A453-EC07-4597-8D60-2EE3919C1A18@kernel.crashing.org> you wrote:
> > 
> > > The CPU I'm using (MPC8349) has two hardware I2C interfaces, and  
> > > I'd like to access the second one in U-boot.  Implementing this  
> > > looks easy to me, but I don't want to reinvent the wheel if it's  
> > > already been done elsewhere.  Has anyone done this?  If not, I'll  
> > > follow up with a proposal.
> > 
> > Depending on what you want to do, you can cheat and just change the  
> > pointer to the 2nd interface.  If you want something more full  
> > featured up to the command level then I think some discussion would  
> > be required on how the commands should work for specifying which  
> > controller to use.
> 
> A clean design should allow to switch I2C  busses  usign  a  command;
> additionally,  I think we should try to stay backward-compatible with
> the existing code. Eventually this is not too difficult:  similar  to
> the  "ide"  or  "usb"  commands  we  could  create a new command "i2c
> device" which takes as argument the number of the I2C bus which  shal
> become  the  current  (=  active)  bus. Then all existing I2C related
> commands can be left unchanged (and "i2c  device"  without  arguments
> should of course print the ID of the current bus).
> 
> In parallel, existing I2C commands could be changed to migrate  to  a
> new  "i2c"  group  of  commands:  "imd"  would become "i2c md", "imw"
> becomes "i2c mw", "iprobe" becomes "i2c probe", etc. For some  (long)
> transition  period old and new commands could be provided in parallel
> (at least optionally). Later, the old syntax could be dropped.
> 
> Best regards,
> 
> Wolfgang Denk
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20060516/2d97f759/attachment.htm 

[U-Boot-Users] Using a second I2C interface

[Menon, Nishanth]

Hi All,

Here is another approach I followed for OMAP2430 (which has 2 i2c controller, one of which is a High speed I2C controller).
common/cmd_i2c.c:
#if defined(CFG_I2C_BUS_SELECT)
int do_i2c_bus(cmd_tbl_t * cmdtp, int flag, int argc, char *argv[])
{
       int bus_idx, bus_spd, res = 0;
       if (argc < 3) {
               printf("Usage[%d]:\n%s\n", argc, cmdtp->usage);
               return 1;
       }
       bus_idx = simple_strtoul(argv[1], NULL, 16);
       bus_spd = simple_strtoul(argv[2], NULL, 16);
       printf("Setting bus[%d] to Speed[%d]: ", bus_idx, bus_spd);
       res = select_bus(bus_idx, bus_spd);
       if (res) {
               printf("FAILED\n");
       } else {
               printf("PASS\n");
       }
       return res;
}
#endif                         /* bus select */
#if defined(CFG_I2C_BUS_SELECT)
U_BOOT_CMD(ibus, 3, 1, do_i2c_bus,
          "ibus    - Select i2c Bus\n",
          "bus_index speed\n    - Selects the bus index and sets the speed (0x64(ST),0x190(FS),0xD48(HS))\n"
          "      (reports success/failure)\n");
#endif

Allows one to select the bus and then use the normal i2c cmds to work on it.. speed of the bus is not variable and is coded into macros.

Regards,
Nishanth Menon

________________________________________
From: u-boot-users-admin@lists.sourceforge.net [mailto:u-boot-users-admin at lists.sourceforge.net] On Behalf Of Ben Warren
Sent: Friday, May 12, 2006 1:28 PM
To: Kumar Gala
Cc: u-boot-users at lists.sourceforge.net
Subject: Re: [U-Boot-Users] Using a second I2C interface

Here's how I've done things in my sandbox:

All public I2C calls take a uchar as the first argument.? Since I2C only uses 7 bits for addressing, the MSB is unused (at least, at the function call level.? I know the hardware uses the bit for w/r).? I've commandeered this bit to denote controller number.? This way, the existing API doesn't need to be changed, just the drivers that choose to implement it.? I've modified the MPC8349 driver and the 'iprobe' command to do this.? To use the other commands, as well as the API itself, I've just been adding 0x80 manually, but it could be done more nicely like:

#define i2c_wr(bus, dev, ...)? i2c_write((bus)==2 ? dev+0x80 : dev, ...)

Of course, this solution isn't scalable beyond two controllers, but I'm not sure we need to worry about that.

Any thoughts?

Ben
.?? On Fri, 2006-05-12 at 13:00 -0500, Kumar Gala wrote: 

On May 12, 2006, at 9:36 AM, Ben Warren wrote:

> Hello,
>
> The CPU I'm using (MPC8349) has two hardware I2C interfaces, and  
> I'd like to access the second one in U-boot.  Implementing this  
> looks easy to me, but I don't want to reinvent the wheel if it's  
> already been done elsewhere.  Has anyone done this?  If not, I'll  
> follow up with a proposal.

Depending on what you want to do, you can cheat and just change the  
pointer to the 2nd interface.  If you want something more full  
featured up to the command level then I think some discussion would  
be required on how the commands should work for specifying which  
controller to use.

- kumar

[U-Boot-Users] Using a second I2C interface

[Wolfgang Denk]

In message <1147458475.16780.105.camel@saruman.qstreams.net> you wrote:
> 
> Here's how I've done things in my sandbox:
> 
> All public I2C calls take a uchar as the first argument.  Since I2C only
> uses 7 bits for addressing, the MSB is unused (at least, at the function
> call level.  I know the hardware uses the bit for w/r).  I've
> commandeered this bit to denote controller number.  This way, the

And what if you have 3 I2C busses? Sorry, but I will no accept such a
hack.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
There is an order of things in this universe.
	-- Apollo, "Who Mourns for Adonais?" stardate 3468.1

[U-Boot-Users] Using a second I2C interface

[Woodruff, Richard]

Ben,

 

I work with Nishanth and he has already presented what he added.  I've
no comment beyond that (other than it works well for us).

 

Regards,

Richard W.

 

________________________________

From: u-boot-users-admin@lists.sourceforge.net
[mailto:u-boot-users-admin at lists.sourceforge.net] On Behalf Of Ben
Warren
Sent: Tuesday, May 16, 2006 8:50 AM
To: Wolfgang Denk
Cc: Kumar Gala; u-boot-users at lists.sourceforge.net
Subject: Re: [U-Boot-Users] Using a second I2C interface

 

Wolfgang,

This sounds like a sensible approach.  This should clean the code up
nicely (as you'll notice, the patch that I submitted yesterday adds
quite a bit of noisy code).  Let's look at what Richard Woodruff
submits, and we can take it from there.

Too bad I didn't get your input until this morning, even though your
message went out on Friday...

regards,
Ben

On Fri, 2006-05-12 at 21:01 +0200, Wolfgang Denk wrote: 

 
Hello,
 
in message <E541A453-EC07-4597-8D60-2EE3919C1A18@kernel.crashing.org>
you wrote:
> 
> > The CPU I'm using (MPC8349) has two hardware I2C interfaces, and  
> > I'd like to access the second one in U-boot.  Implementing this  
> > looks easy to me, but I don't want to reinvent the wheel if it's  
> > already been done elsewhere.  Has anyone done this?  If not, I'll  
> > follow up with a proposal.
> 
> Depending on what you want to do, you can cheat and just change the  
> pointer to the 2nd interface.  If you want something more full  
> featured up to the command level then I think some discussion would  
> be required on how the commands should work for specifying which  
> controller to use.
 
A clean design should allow to switch I2C  busses  usign  a  command;
additionally,  I think we should try to stay backward-compatible with
the existing code. Eventually this is not too difficult:  similar  to
the  "ide"  or  "usb"  commands  we  could  create a new command "i2c
device" which takes as argument the number of the I2C bus which  shal
become  the  current  (=  active)  bus. Then all existing I2C related
commands can be left unchanged (and "i2c  device"  without  arguments
should of course print the ID of the current bus).
 
In parallel, existing I2C commands could be changed to migrate  to  a
new  "i2c"  group  of  commands:  "imd"  would become "i2c md", "imw"
becomes "i2c mw", "iprobe" becomes "i2c probe", etc. For some  (long)
transition  period old and new commands could be provided in parallel
(at least optionally). Later, the old syntax could be dropped.
 
Best regards,
 
Wolfgang Denk
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20060516/7ad79fed/attachment.htm