mirror of
https://github.com/lm-sensors/lm-sensors.git
synced 2026-10-20 11:29:31 +00:00
Mark D. Studebaker
8f73f9beed
<klh@google.com> received Sept. '04. No changes by me other than include file path fixups. Compiles, but will not insmod without i2c-core changes or stubs to add xxx_nolock() functions. ----------------- Here you go. I apologize for the fact this code is not integrated into the lm_sensors package structure and thus will require you to make various little updates. But I really wanted to get this out before I'm yanked away again, and am pretty sure you can do it much faster than I can figure out what needs to be done! BTW the kernel files are built against 2.4.x where x varies; 18 and 19 should work. Feel free to clean up anything. --Ken On Sat, 18 Sep 2004, Mark Studebaker wrote: >>> > On Tue, 7 Sep 2004, Mark Studebaker wrote: >> >>>> >>sure, send it over. >>>> >>Sorry for delay, your mail got buried by other mail and just now spotted it. >>>> >>mds >>>> >> >>>> >>Ken Harrenstien wrote: >>>> >> >>> >>>>> >>>It turned out to be a while before I could get back to this, but >>>>> >>>everything's been working for a while now and I'd like to send in the >>>>> >>>new pca954x driver. >>>>> >>> >>>>> >>>I was looking at the list in the "new_drivers" file -- it *is* kind of >>>>> >>>intimidating. Since some of the changes affect core i2c files, I was >>>>> >>>hoping that what I could do to start with is just send you a tar of >>>>> >>>the modified files in their entirety, or a patch-diff of the changes >>>>> >>>against the 2.8.7 distribution, so you can scope things out and verify >>>>> >>>they're on the right track for acceptance. The following files are >>>>> >>>the ones I've changed so far: >>>>> >>> >>>>> >>> New: >>>>> >>> Documentation/i2c/virtual_i2c >>>>> >>> drivers/i2c/i2c-virtual.c >>>>> >>> drivers/sensors/pca954x.c >>>>> >>> include/linux/i2c-virtual.h >>>>> >>> Patched: >>>>> >>> Documentation/Configure.help >>>>> >>> drivers/i2c/Makefile >>>>> >>> drivers/i2c/Config.in >>>>> >>> drivers/i2c/i2c-core.c >>>>> >>> drivers/sensors/Makefile >>>>> >>> drivers/sensors/Config.in >>>>> >>> include/linux/i2c-id.h >>>>> >>> include/linux/i2c.h >>>>> >>> >>>>> >>> >>>>> >>>I plan to write some additional doc once I know that the code itself >>>>> >>>is acceptable, and you then can tell me what other files need to be >>>>> >>>updated. >>>>> >>> >>>>> >>>To answer a couple other issues you raised: >>>>> >>> >>>>> >>>On Thu, 24 Jun 2004, Mark Studebaker wrote: >>>>> >>> >>>>> >>> >>>>> >>> >>>> >>>>>> >>>>(copying the mailing list, already forwarded the first mail to the list) >>>>>> >>>> >>>>>> >>>>First I want to ask whether you are working on kernel 2.4 or 2.6. >>>> >>>>> >>> >>>>> >>> >>>>> >>>2.4. >>>>> >>> >>>>> >>> >>>>> >>> >>>> >>>>>> >>>>Third, you may not have realized that Khali recently did a (2.4 kernel) pca9540 driver. >>>>>> >>>>It is in our sensors package. It however doesn't do any of the bootstrapping or >>>>>> >>>>bus registering either. It may or may not help you. >>>> >>>>> >>> >>>>> >>> >>>>> >>>I saw it in the 2.8.7 distrib, and used parts of it as a template. >>>>> >>>The pca954x driver will support that chip, although the external /proc >>>>> >>>interface it presents is necessarily different. >>>>> >>> >>>>> >>>--Ken git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@2765 7894878c-1315-0410-8ee3-d5d059ff63e0
103 lines
4.9 KiB
Plaintext
103 lines
4.9 KiB
Plaintext
Virtual i2c bus
|
|
Brian Kuschak <bkuschak@xxxxxxxxx>
|
|
|
|
|
|
I2C devices must have a unique 7 bit address on the bus to which they
|
|
are attached. Many I2C chips have one or more input lines which can be
|
|
used to configure one or more of their address bits. This allows the
|
|
hardware designer to include multiple chips on a single bus by selecting
|
|
different addresses for each one. However, some chips have fixed addresses
|
|
which present a problem if more than one of them are required on a board.
|
|
Also, sometimes there are more devices than there are selectable addresses.
|
|
|
|
A common solution is to break the i2c bus into disjoint segments, by using
|
|
a multiplexor or i2c bus switch. This electrically isolates the individual
|
|
bus segments. Then the devices with duplicate addresses are placed on
|
|
separate bus segments, to prevent address conflicts.
|
|
|
|
This seems to be a very common approach in certain types of applications,
|
|
such as bladed chassis, where many identical 'blades' or cards are inserted
|
|
into a common backplane. The I2C bus on each blade is then located behind
|
|
a mux or i2c bus switch. This solution works great from the hardware
|
|
perspective, but presents some complexities for software.
|
|
|
|
The 'virtual i2c adapter' driver is an attempt to provide a flexible software
|
|
abstraction to simiplify these issues, while minimizing the impact on
|
|
existing code and fitting nicely into the i2c driver framework.
|
|
|
|
|
|
What is a 'virtual i2c adapter'
|
|
===============================
|
|
|
|
Think of this adapter as a layer above the existing algorithm and adapter
|
|
drivers. The virtual i2c adapter is the handle by which you access a
|
|
specific multiplexed bus segment. Each disjoint bus segment becomes a new
|
|
virtual bus. The virtual adapter is associated with a 'real' adapter and a
|
|
set of multiplexor control variables.
|
|
|
|
For example: you have an i2c-0 bus with one multiplexor or i2c bus switch,
|
|
and the mux has four outputs which can be electrically connected to the
|
|
i2c-0 bus. You would register four virtual i2c busses, one for each position
|
|
of the mux. As part of the registration, you provide callback functions to
|
|
select and deselect the mux as well as the selector values to be passed to
|
|
these functions.
|
|
|
|
--------- <--------> i2c-1 virtual
|
|
| i2c mux | <--------> i2c-2 virtual
|
|
i2c-0 <-------> | | <--------> i2c-3 virtual
|
|
ibm_ocp | 0x74 | <--------> i2c-4 virtual
|
|
---------
|
|
^
|
|
|
|
|
+--- (or externally controlled)
|
|
|
|
The mux may be i2c-controlled, in which case the mux_addr is set to the
|
|
slave address (0x74) and the mux_val would be the port number to select (0-3).
|
|
Alternatively, the mux could be controlled by some fixed memory-mapped register
|
|
in which case only the mux_val would be needed. The callback functions
|
|
are hardware specific and written by the user.
|
|
|
|
Once the virtual busses are registered, you may talk to any devices behind
|
|
the mux simply the using the i2c-1, i2c-2, i2c-3, etc. adapters instead of
|
|
the i2c-0 adapter. This makes the mux essentially transparent to the
|
|
i2c_client.
|
|
|
|
The great advantage of course is that all the existing sensor drivers and
|
|
other i2c client drivers automatically work, and the mux becomes transparent
|
|
to them.
|
|
|
|
|
|
Additional capabilities
|
|
=======================
|
|
|
|
This driver also supports multiple levels of muxing, by allowing the
|
|
user to register a virtual bus which has a different virtual bus as its
|
|
'real' adapter. In addition, each virtual bus may have different kinds of
|
|
multiplexors, with each bus having its own set of callback functions.
|
|
This allows you to easily support some very complex topologies.
|
|
|
|
In addition to multiplexing, some systems require that you obtain hardware
|
|
access to the bus behind the mux before talking on it. (Again, bladed chassis
|
|
typically 'fence' other blades off the bus to prevent a crashed blade from
|
|
bringing down the whole backplane.) Before talking on this bus, you have to
|
|
arbitrate with the other blades to acquire exclusive access to the bus. This
|
|
requirement is met by the addition of two new function pointers to the
|
|
algorithm drivers, acquire_exclusive() and release_exclusive(). Traditional
|
|
adapters will not use these and they can safely be left NULL. If they are
|
|
non-null, the virtual bus driver will call the acquire_exclusive() function
|
|
before attempting any operations on that virtual bus. This function may block,
|
|
and this is done before acquiring the lock on the underlying 'real' bus to
|
|
allow transactions on the real bus to continue unimpeded while waiting for
|
|
arbitrartion. In addition the ownership is only held for as long as it takes
|
|
to complete the transfer.
|
|
|
|
|
|
Files
|
|
=====
|
|
|
|
drivers/i2c/i2c-virtual.c: The 'algorithm' and 'adapter' driver
|
|
include/linux/i2c-virtual.h: Header file with the mux control structure
|
|
and callback prototypes.
|
|
|
|
|