Adding S4882 support to the i2c-amd756 driver

Mark M. Hoffman mhoffman at
Fri Oct 22 05:21:17 CEST 2004

Hi Jean:

> >(...) Usage, e.g.:
> >
> >static struct i2c_adapter *xyz_real_adap;
> >static struct i2c_adapter *xyz_virt_adap;
> >
> >static int __init xyz_mux_init(void)
> >{
> >
> >	int err;
> >
> >	/* register myself as a driver/client */
> >	if ((err = i2c_add_driver(&xyz_mux_driver))
> >		goto ERROR_0;
> Except that you cannot register the client at this point. If you do,
> it'll get kicked as soon as you "lock" the adapter.

Oops, of course you're right.  I wrote this example code too late
at night. :)

> >	/* find the real bus */
> >	if (!((xyz_real_adap = i2c_get_adapter(<some id>))) {
> >		err = -EINVAL;
> >		goto ERROR_1;
> >	}
> >
> >	/* lock all other clients out of it */
> >	if ((err = i2c_lock_adapter(&xyz_real_adap))
> >		goto ERROR_2;
> And register the client manually at this point. The mux client is the
> only client attached to the real bus.

Right again.

> >	/* build the virtual adapter */
> >	/* ... */
> >	if ((err = i2c_add_adapter(&xyz_virt_adap))
> >		goto ERROR_3;
> >
> >	return 0;
> >1) The above carries a built-in assumption: that the mux itself, if it
> >is controlled by I2C/SMBus, must be a client of the immediate parent
> >segment.  Does anyone know of a mux that doesn't work that way?  E.g.
> >a 2x1 mux with a fourth bus connection for mux control only?
> The S4882 itself has an interesting architecture. The Philips PCA9556
> itself is not an I2C mux chip. It is an 8-bit I/O. On the S4882 each pin
> is used as an output, and the pins control two PCA9516 chips, which are
> the real (5-way) I2C muxes. The PCA9516 chips don't show on the I2C bus.
> This shows that the multiplexing is highly board-dependant. It also shows
> that we could see PCA9556 chips which are not means for bus
> multiplexing, or PCA9516 chips which are controled by other means (such
> as LPC GPIO chips).

That's one reason I think the module in your case is best named "s4882"
instead of any name referencing the mux chips. :)  We might end up copy-
pasting some of the PCA9556 code into other similar but different modules,
but we can consolidate if and when it comes to that.

> However, I don't see how the model you propose wouldn't cover such
> cases. What prevents the virtual busses from doing e.g. ISA I/O to
> control the multiplexer(s)?


> >2) Doesn't address the sysfs hierarchy.  It would be nice to have a
> >sysfs structure that is isomorphic to the i2c bus structure... I think
> >USB is like that so I will look into it.
> I wonder if it is worth the effort. There aren't that many multiplexed
> SMBus systems out there, and we still have to see multilevel muxes. The
> problem I see is that a sysfs structure change would most likely require
> changes to user-space tools such as i2cdetect. While not impossible to
> do, I think we have to think about these changes before taking the
> actual move.

Yes, I'll want to tackle this in stages.  The sysfs fixups can come later.
It brings up a point though: if the MUX client is registered "manually"
as we're calling it, what do we do with the sysfs structure?  Maybe it 
would be better for i2c_lock_adapter to do this:

1) force all existing clients to detach
2) attach the caller client as normal
3) mark the bus as no-probe and allow no further client attachments

That would retain all the existing sysfs structure.  Thoughts?


Mark M. Hoffman
mhoffman at

More information about the lm-sensors mailing list