[i2c] [PATCH 5/6]: i2c: Add bus addressing support.
khali at linux-fr.org
Fri Oct 17 17:24:59 CEST 2008
On Wed, 15 Oct 2008 14:37:22 -0700 (PDT), David Miller wrote:
> From: Jean Delvare <khali at linux-fr.org>
> Date: Wed, 15 Oct 2008 14:52:28 +0200
> > Hi David,
> > On Thu, 21 Aug 2008 02:43:30 -0700 (PDT), David Miller wrote:
> > >
> > > i2c: Add bus addressing support.
> > >
> > > Some I2C bus controllers support the driving of multiple I2C bus
> > > segments (think PCI domains).
> > >
> > > For example, the pcf8584 variants on some sparc64 boxes can do this.
> > > They have an auxiliary 8-bit register that specifies the I2C bus each
> > > I2C operation acts upon. In the openfirmware device tree, the I2C
> > > client devices are described using an 8-bit bus address and a 10-bit
> > > I2C device address.
> > Can you please point me to the part of the PCF8454 datasheet which
> > explains this? I can't find it. As I read the datasheet, the PCF8454
> > supports a single I2C bus.
> It's a feature Sun added to their PCF chips. The register address
> is forwarded to an internal MUX they implemented which implements
> the register selecting the I2C bus.
I don't really follow you here. The PCF8584 is a chip manufactured by
Philips. I don't quite see how Sun could have added registers to a chip
after the fact. Or do they produce compatible chips for their own
systems, with extra features?
More likely, they combined the PCF8584 with another chip which is
multiplexing the I2C bus. Philips has many such chips, for example the
PCA9540 series. It probably doesn't really matter for the problem at
hand anyway, but I'm curious.
> > Oh my, holy crap! I can't believe you dared to propose this.
> Propose an alternative solution that actually works and preserves
> compatability, as mine does.
What you need is i2c bus multiplexing support. What you call "bus
addressing" is only the most simple form of multiplexing, i.e. a single
level of multiplexing and no trunk.
A generic form of i2c bus multiplexing is not upstream yet but a number
of people have been working on this in the last few years, in
particular Rodolfo Giometti (Cc'd.) I admit I did not pay too much
attention to the patches myself, due to a lack of time and personal
interest, as well as the feeling that it was preferable to first
cleanup i2c-core from its legacy binding model and redundant lists and
locks before adding something as complex as bus multiplexing support.
Multiplexing will require clever locking and it did not seem sane to
attempt to do that as long as legacy and new-style i2c devices coexist.
But the cleanup phase of i2c-core is hopefully coming to an end so it
will soon be time to look into i2c bus multiplexing support.
In the meantime, it is always possible to write hardware-specific
multiplexing drivers. See for example i2c-amd756-s4882 and
i2c-nforce2-s4985, two drivers that handle the multiplexing of SMBus on
Tyan motherboards. While these drivers aren't exactly elegant and we do
not want such drivers to proliferate, they at least fill the gap until
we have a good generic solution. And these two drivers did not require
any change to i2c-core as I recall, except maybe bug fixes which the
new use case revealed.
> > I don't like this at all. This really looks like a custom hack to solve
> > the problem at hand without paying too much attention to compatibility
> > issues which I am certain will arise. Just to mention the first one
> > that comes to mind: access from user-space through i2c-dev, and
> > specifically i2c-tools.
> I got that working, read the patch my patch works, I was careful
> to keep things working.
How do you access your "addressed buses" through i2c-dev? It will
reject any address larger than 0x3ff. And even if you did update
i2c-dev to no longer check for "wrong" addresses, i2c-tools would not
support them. So you'd also need to update i2c-tools.
Now maybe you don't plan to use i2c-dev and i2c-tools on your I2C
buses, but that's hardly the point. The point is that your proposal
requires changes to other drivers and user-space tools, while the
alternative doesn't require such changes.
Even i2c-core has checks on invalid addresses, in
i2c_new_probed_device(), i2c_detect_address() and i2c_probe_address().
While we don't care much about the latter (it's going away soon) the
former 2 would need to be updated. Then again you may say that you do
not plan to use these functions on your I2C buses, but this illustrates
how your proposal would require more changes to be universally usable.
> > What makes your setup fundamentally different from a motherboard with
> > more than one I2C bus (which is a rather common case)? Why don't you
> > simply register one i2c_adapter for each i2c bus segment?
> It doesn't work like that. All the bit banging goes through the
> one I2C controller, the bus it is accessing is simply changed behind
> it's back by that special register.
That's the definition of bus multiplexing. You apparently think that
struct i2c_adapter represents one I2C controller (and admittedly that's
what the name suggests for historical reasons) while what it really
represents is an I2C bus segment. In your case you have one controller
for several I2C bus segments. So you simply need as many i2c_adapter
structures registered, and then it's up to your driver to handle the
multiplexing in a way that is transparent for the users.
If you want to see generic i2c bus multiplexing support available soon,
then please help Rodolfo by reviewing and testing his patches, and help
me finish the conversion of all i2c chip drivers to the standard device
driver binding model. 87 drivers have been converted or deleted
already, most by myself, 27 are remaining. An up-to-date list is at:
As you can see, most remaining drivers are in drivers/macintosh and
drivers/media/video. I can probably handle media/video myself with the
help of Hans Verkuil but I have no idea what to do with the macintosh
More information about the i2c