Skip to contentSkip to conversation

- i2c virtual adapter driver for multiplexed busses

PATCH New Brian Kuschak 2 participants 4 messages May 19, 2005

Subsystems (2)
Documentation I2C
lore
Share & tools
lore

Brian Kuschak

author
#0 lore raw

PATCH 1/1 - i2c virtual adapter driver for multiplexed busses

Hi Greg, Mark,

As described in a previous email to this list, this is a patch for simplified access to multiplexed i2c busses. A documentation file is included, as well as an example (i2c-virtual_cb.c) of how to implement the mux-control callbacks.

Tested on a heavily patched 2.4.19 kernel on embedded PowerPC. However, this patch is against a clean kernel.org 2.4.19 tree. I don't have the bandwidth to port this to 2.6.0 right now, but I wanted to make it available in case someone else finds it useful.

Comments/feedback welcome.

Thanks,
Brian Kuschak

__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree
-------------- next part --------------

Documentation/Configure.help +9 -0
diff -urN linux-2.4.19/Documentation/Configure.help linux-2.4.19.new/Documentation/Configure.help
@@ -16905,6 +16905,15 @@
   it as a module, say M here and read <file:Documentation/modules.txt>.
   The module will be called i2c-proc.o.
 
+I2C virtual bus
+CONFIG_I2C_VIRTUAL
+  This driver allows you to handle multiplexed or bus-switched I2C
+  bus topologies by registering 'virtual' i2c busses for each multiplexed
+  bus segment.  It requires some hardware-specific code to be written to 
+  perform the multiplexor control.
+
+  See Documentation/i2c/virtual_i2c for details.
+
 Bus Mouse Support
 CONFIG_BUSMOUSE
   Say Y here if your machine has a bus mouse as opposed to a serial
Documentation/i2c/virtual_i2c +99 -0

99 lines not on this page · raw message

drivers/i2c/Config.in +1 -0
diff -urN linux-2.4.19/drivers/i2c/Config.in linux-2.4.19.new/drivers/i2c/Config.in
@@ -48,6 +48,7 @@
 
    dep_tristate 'I2C device interface' CONFIG_I2C_CHARDEV $CONFIG_I2C
    dep_tristate 'I2C /proc interface (required for hardware sensors)' CONFIG_I2C_PROC $CONFIG_I2C
+   dep_tristate 'Virtualized I2C adapter' CONFIG_I2C_VIRTUAL $CONFIG_I2C
 
 fi
 endmenu
drivers/i2c/Makefile +4 -1
diff -urN linux-2.4.19/drivers/i2c/Makefile linux-2.4.19.new/drivers/i2c/Makefile
@@ -5,7 +5,7 @@
 O_TARGET := i2c.o
 
 export-objs	:= i2c-core.o i2c-algo-bit.o i2c-algo-pcf.o \
-		   i2c-algo-ite.o i2c-proc.o
+		   i2c-algo-ite.o i2c-proc.o i2c-virtual.o
 
 obj-$(CONFIG_I2C)		+= i2c-core.o
 obj-$(CONFIG_I2C_CHARDEV)	+= i2c-dev.o

@@ -19,9 +19,12 @@
 obj-$(CONFIG_ITE_I2C_ADAP)	+= i2c-adap-ite.o
 obj-$(CONFIG_I2C_PROC)		+= i2c-proc.o
 obj-$(CONFIG_I2C_KEYWEST)	+= i2c-keywest.o
+obj-$(CONFIG_I2C_VIRTUAL)	+= i2c-virtual.o
 
 # This is needed for automatic patch generation: sensors code starts here
 # This is needed for automatic patch generation: sensors code ends here
+
+ 
 
 include $(TOPDIR)/Rules.make
drivers/i2c/i2c-core.c +83 -10

200 lines not on this page · raw message

drivers/i2c/i2c-virtual.c +275 -0

275 lines not on this page · raw message

drivers/i2c/i2c-virtual_cb.c +335 -0

335 lines not on this page · raw message

include/linux/i2c-virtual.h +38 -0
diff -urN linux-2.4.19/include/linux/i2c-virtual.h linux-2.4.19.new/include/linux/i2c-virtual.h
@@ -0,0 +1,38 @@
+/* This is the header files for the 'virtual i2c' adapter driver.
+ * See Documentation/i2c/virtual_i2c for usage information.
+ */
+#ifndef __I2C_VIRTUAL_H
+#define __I2C_VIRTUAL_H
+
+#include <linux/i2c.h>
+
+struct i2c_mux_ctrl {
+	unsigned long	addr;		
+	unsigned long	value;
+
+	/* fn which enables the mux */
+	void (*select)(struct i2c_adapter *adap, struct i2c_mux_ctrl *mux);	
+
+	/* fn which disables the mux */
+	void (*deselect)(struct i2c_adapter *adap, struct i2c_mux_ctrl *mux);	
+};
+
+/* This has to be exposed, since the code which assigns the callbacks must use it. */
+struct i2c_virt_priv {
+	struct i2c_adapter	*real_adap;		/* pointer to our 'real' adapter */
+	struct i2c_mux_ctrl	mux;			/* MUX settings for this adapter */
+};
+
+
+static inline struct i2c_adapter *i2c_get_real_adap(struct i2c_adapter *adap)
+{
+	struct i2c_virt_priv *priv;
+
+	if((adap->id & 0xff) != I2C_HW_VIRT)
+		return NULL;
+	
+	priv = (void*) adap->data;
+	return(priv->real_adap);
+}
+
+#endif /* __I2C_VIRTUAL_H */
include/linux/i2c.h +10 -2
diff -urN linux-2.4.19/include/linux/i2c.h linux-2.4.19.new/include/linux/i2c.h
@@ -58,7 +58,7 @@
 /* --- General options ------------------------------------------------	*/
 
 #define I2C_ALGO_MAX	4		/* control memory consumption	*/
-#define I2C_ADAP_MAX	16
+#define I2C_ADAP_MAX	48
 #define I2C_DRIVER_MAX	16
 #define I2C_CLIENT_MAX	32
 #define I2C_DUMMY_MAX 4

@@ -184,6 +184,7 @@
 	unsigned int addr;		/* chip address - NOTE: 7bit 	*/
 					/* addresses are stored in the	*/
 					/* _LOWER_ 7 bits of this char	*/
+
 	/* addr: unsigned int to make lm_sensors i2c-isa adapter work
 	  more cleanly. It does not take any more memory space, due to
 	  alignment considerations */

@@ -224,6 +225,12 @@
 
 	/* To determine what the adapter supports */
 	u32 (*functionality) (struct i2c_adapter *);
+
+	/* Some chassis/bladed systems must arbitrate with another CPU to
+	 * get exclusive access to the I2C bus.  Set NULL if not used.
+	 */
+	int (*acquire_exclusive)(struct i2c_adapter *adap);
+	int (*release_exclusive)(struct i2c_adapter *adap);
 };
 
 #if LINUX_VERSION_CODE < KERNEL_VERSION(2,1,29)

@@ -367,7 +374,8 @@
  */
 extern int i2c_adapter_id(struct i2c_adapter *adap);
 
-
+/* Return a pointer to the i2c_adapter */
+extern struct i2c_adapter* i2c_get_adapter(int index);
 
 /* Return the functionality mask */
 extern u32 i2c_get_functionality (struct i2c_adapter *adap);
include/linux/i2c-id.h +2 -0
diff -urN linux-2.4.19/include/linux/i2c-id.h linux-2.4.19.new/include/linux/i2c-id.h
@@ -189,6 +189,8 @@
 /* --- MPC8xx PowerPC adapters						*/
 #define I2C_HW_MPC8XX_EPON 0x00	/* Eponymous MPC8xx I2C adapter 	*/
 
+#define I2C_HW_VIRT	0x01 	/* Virtualized adapter                  */
+
 /* --- SMBus only adapters						*/
 #define I2C_HW_SMBUS_PIIX4	0x00
 #define I2C_HW_SMBUS_ALI15X3	0x01
author
#1 lore raw

PATCH 1/1 - i2c virtual adapter driver for multiplexed busses

Hi Mark,
See my comments below.
Regards, Brian

Quoted 6 lines

- I think i2c-virtual is really the algorithm driver (i2c-algo-virtual?).
It contains a common algorithm for virtual
drivers.

Quoted 9 lines

- Therefore i2c-virtual_cb is the adapter driver, specific to the
PCA954x chips (ic2-pca954x?).
The algo/adapter boundary in the 405 driver you
copied may be a little
muddy.
See i2c-algo-bit and its many adapter drivers in
sensors for examples.

It's quite possible I muddied the boundaries here. The reason for keeping the main functionality out of i2c-virtual_cb.c is that this file is where the user-specific and platform-specific code resides. The makefiles in the patch don't actually use i2c-virtual_cb.c - it was included more as an example of usage. In my case, at least, the callbacks are where some of our proprietary code resides and I wanted to keep that isolated.

Quoted 8 lines

- I'd rather not add entries to struct i2c_algorithm, we just went
through that
hell and are finishing a patch to go to Marcelo.
Rather than
xxx_exclusive,
we could use the (essentially unused)
algo_control. i2c-core could

Quoted 9 lines

recognize
that a driver is virtual by adding a functionality
entry to identify
that
it is virtual. If you really want it the way it is
we need to put
#ifdefs everywhere
so we can stay compatible, at least for now...

Point well taken. This sounds like a reasonable change.

One comment is that the bus exclusivity and multiplexing are two separate things. Even a regular non-multiplexed bus may require 'arbitration' with other blades before being allowed to use it. Likewise some multiplexed busses may not require arbitration.

Quoted 7 lines

- If i2c-pca954x also registered as a chip driver (sensors-style)
(that is, be an i2c client as well) at addresses
0x70-77 then it will
get called whenever a device is found at that
location, it can do
detection

Quoted 9 lines

(if possible -doesn't look like it) and then
register the new busses,
and
everything gets bootstrapped. You'll get called
anytime a bus
is registered. That's better than simply scanning
the
adapters already present at module_init time.

Yes, I originally thought about doing exactly that. In our application due to the variety of different HW platforms it made more sense to register these busses manually based on a priori knowledge of the HW.

I'll try to put together a little pcf954x client driver to do the runtime registration of the virtual busses, since that will likely be more useful for the larger audience.

Quoted 8 lines

- It's much easier for us if you give us a patch
against CVS, or else
patch
your kernel with our kernel patches first (see
home page) and then
give us a patch
against that kernel. At least for i2c-core.

Understood. Is your CVS based on 2.4 or 2.6?

Quoted 30 lines
Quoted 4 lines · Brian Kuschak

Hi Greg, Mark,

As described in a previous email to this list,

this is

Quoted 2 lines

a patch for simplified access to multiplexed i2c busses. A documentation file is included, as well

as

Quoted 1 line

an example (i2c-virtual_cb.c) of how to implement

the

Quoted 3 lines

mux-control callbacks.

Tested on a heavily patched 2.4.19 kernel on

embedded

Quoted 2 lines

PowerPC. However, this patch is against a clean
kernel.org 2.4.19 tree. I don't have the

bandwidth to

Quoted 1 line

port this to 2.6.0 right now, but I wanted to make

it

Quoted 10 lines

available in case someone else finds it useful.

Comments/feedback welcome.

Thanks,
Brian Kuschak

__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail

Quoted 9 lines

AddressGuard

Quoted 4 lines

http://antispam.yahoo.com/whatsnewfree

Name:

i2c_virtual.2_4_19.patch

Quoted 1 line

i2c_virtual.2_4_19.patch Type: Plain Text

(text/plain)

Quoted 1 line

Description:

i2c_virtual.2_4_19.patch

__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree

#2 lore raw

PATCH 1/1 - i2c virtual adapter driver for multiplexed busses

In reply to Brian Kuschak

excellent. here's some first comments.
Thanks for doing some good documentation.

- I think i2c-virtual is really the algorithm driver (i2c-algo-virtual?).
It contains a common algorithm for virtual drivers.

- Therefore i2c-virtual_cb is the adapter driver, specific to the PCA954x chips (ic2-pca954x?).
The algo/adapter boundary in the 405 driver you copied may be a little
muddy.
See i2c-algo-bit and its many adapter drivers in sensors for examples.

- I'd rather not add entries to struct i2c_algorithm, we just went through that
hell and are finishing a patch to go to Marcelo. Rather than
xxx_exclusive,
we could use the (essentially unused) algo_control. i2c-core could
recognize
that a driver is virtual by adding a functionality entry to identify
that
it is virtual. If you really want it the way it is we need to put
#ifdefs everywhere
so we can stay compatible, at least for now...

- If i2c-pca954x also registered as a chip driver (sensors-style) (that is, be an i2c client as well) at addresses 0x70-77 then it will get called whenever a device is found at that location, it can do
detection
(if possible -doesn't look like it) and then register the new busses,
and
everything gets bootstrapped. You'll get called anytime a bus is registered. That's better than simply scanning the adapters already present at module_init time.

- It's much easier for us if you give us a patch against CVS, or else patch
your kernel with our kernel patches first (see home page) and then
give us a patch
against that kernel. At least for i2c-core.

Quoted 29 lines · Brian Kuschak

Hi Greg, Mark,

As described in a previous email to this list, this is a patch for simplified access to multiplexed i2c busses. A documentation file is included, as well as an example (i2c-virtual_cb.c) of how to implement the mux-control callbacks.

Tested on a heavily patched 2.4.19 kernel on embedded PowerPC. However, this patch is against a clean kernel.org 2.4.19 tree. I don't have the bandwidth to port this to 2.6.0 right now, but I wanted to make it available in case someone else finds it useful.

Comments/feedback welcome.

Thanks,
Brian Kuschak

__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree

                                  Name: i2c_virtual.2_4_19.patch
   i2c_virtual.2_4_19.patch       Type: Plain Text (text/plain)
                           Description: i2c_virtual.2_4_19.patch
#3 lore raw

PATCH 1/1 - i2c virtual adapter driver for multiplexed busses

In reply to Brian Kuschak

inline

Quoted 21 lines · Brian Kuschak

Hi Mark,
See my comments below.
Regards, Brian

Quoted 6 lines

- I think i2c-virtual is really the algorithm driver (i2c-algo-virtual?).
It contains a common algorithm for virtual
drivers.

Quoted 9 lines

- Therefore i2c-virtual_cb is the adapter driver, specific to the
PCA954x chips (ic2-pca954x?).
The algo/adapter boundary in the 405 driver you
copied may be a little
muddy.
See i2c-algo-bit and its many adapter drivers in
sensors for examples.

Quoted 10 lines

It's quite possible I muddied the boundaries here. The reason for keeping the main functionality out of i2c-virtual_cb.c is that this file is where the user-specific and platform-specific code resides. The makefiles in the patch don't actually use i2c-virtual_cb.c - it was included more as an example of usage. In my case, at least, the callbacks are where some of our proprietary code resides and I wanted to keep that isolated.

we're in agreement. You did it right, I'm just conceptually mapping what you did
onto our naming conventions. i2c-virtual is a generic 'algorithm" and i2c-virtual-cb is one of many possible hardware-specific "adapters" using that algorithm.

Quoted 18 lines
Quoted 8 lines

- I'd rather not add entries to struct i2c_algorithm, we just went
through that
hell and are finishing a patch to go to Marcelo.
Rather than
xxx_exclusive,
we could use the (essentially unused)
algo_control. i2c-core could

Quoted 9 lines

recognize
that a driver is virtual by adding a functionality
entry to identify
that
it is virtual. If you really want it the way it is
we need to put
#ifdefs everywhere
so we can stay compatible, at least for now...

Quoted 9 lines

Point well taken. This sounds like a reasonable change.

One comment is that the bus exclusivity and multiplexing are two separate things. Even a regular non-multiplexed bus may require 'arbitration' with other blades before being allowed to use it. Likewise some multiplexed busses may not require arbitration.

ok. if they are two separate things let's keep them separate...

Quoted 22 lines
Quoted 7 lines

- If i2c-pca954x also registered as a chip driver (sensors-style)
(that is, be an i2c client as well) at addresses
0x70-77 then it will
get called whenever a device is found at that
location, it can do
detection

Quoted 9 lines

(if possible -doesn't look like it) and then
register the new busses,
and
everything gets bootstrapped. You'll get called
anytime a bus
is registered. That's better than simply scanning
the
adapters already present at module_init time.

Yes, I originally thought about doing exactly that. In our application due to the variety of different HW platforms it made more sense to register these busses manually based on a priori knowledge of the HW.

Quoted 5 lines

I'll try to put together a little pcf954x client driver to do the runtime registration of the virtual busses, since that will likely be more useful for the larger audience.

do that and you don't need the bus scan in i2c-virtual I don't think (i2c-core scans for you).
also you can greatly simplify i2c-virtual-cb by using the i2c_smbus_write_byte function from i2c-core rather than calling master_xfer directly.

Quoted 11 lines
Quoted 8 lines

- It's much easier for us if you give us a patch
against CVS, or else
patch
your kernel with our kernel patches first (see
home page) and then
give us a patch
against that kernel. At least for i2c-core.

Understood. Is your CVS based on 2.4 or 2.6?

2.4

Quoted 45 lines
Quoted 30 lines
Quoted 4 lines · Brian Kuschak

Hi Greg, Mark,

As described in a previous email to this list,

this is

Quoted 2 lines

a patch for simplified access to multiplexed i2c busses. A documentation file is included, as well

as

Quoted 1 line

an example (i2c-virtual_cb.c) of how to implement

the

Quoted 3 lines

mux-control callbacks.

Tested on a heavily patched 2.4.19 kernel on

embedded

Quoted 2 lines

PowerPC. However, this patch is against a clean
kernel.org 2.4.19 tree. I don't have the

bandwidth to

Quoted 1 line

port this to 2.6.0 right now, but I wanted to make

it

Quoted 10 lines

available in case someone else finds it useful.

Comments/feedback welcome.

Thanks,
Brian Kuschak

__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail

Quoted 9 lines

AddressGuard

Quoted 4 lines

http://antispam.yahoo.com/whatsnewfree

Name:

i2c_virtual.2_4_19.patch

Quoted 1 line

i2c_virtual.2_4_19.patch Type: Plain Text

(text/plain)

Quoted 1 line

Description:

i2c_virtual.2_4_19.patch

__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree