On Sun, 15 Mar 2009 18:53:13 +0100 Jean Delvare <khali@xxxxxxxxxxxx> wrote: > On Sun, 15 Mar 2009 10:42:41 -0700 (PDT), Trent Piepho wrote: > > On Sun, 15 Mar 2009, Jean Delvare wrote: > > > On Sun, 15 Mar 2009 13:44:01 +0100, Hans Verkuil wrote: > > > This is the typical multifunction device problem. It isn't specifically > > > related to I2C, the exact same problem happens for other devices, for > > > example a PCI south bridge including hardware monitoring and SMBus, or > > > a Super-I/O chip including hardware monitoring, parallel port, > > > infrared, watchdog, etc. Linux currently only allows one driver to bind > > > to a given device, so it becomes very difficult to make per-function > > > drivers for such devices. > > > > > > For very specific devices, it isn't necessarily a big problem. You can > > > simply make an all-in-one driver for that specific device. The real > > > problem is when the device in question is fully compatible with other > > > devices which only implement functionality A _and_ fully compatible with > > > other devices which only implement functionality B. You don't really > > > want to support functions A and B in the same driver if most devices > > > out there have either function but not both. > > > > You can also split the "device" into multiple devices. Most SoCs have one > > register block where all kinds of devices, from i2c controllers to network > > adapters, exist. This is shown to linux as many devices, rather than one > > massive multifunction device. > > It really depends on the device type. You can't split an I2C or PCI > device that way. In the case of PCI, you can. There are several devices where you have a PCI bridge inside the chip. The PCI bus identifies such cases and create a PCI sub-bus to handle this. This is what happens by default with cx88 drivers (where we have up to 4 different PCI devices at the same chip) and with devices with multiple bt848 chips, inside the same board. Of course, a subdev information is attached inside the BUS address on this case. I suspect that we may need to have something like this, in order to support some complex devices that use I2C. It seems to be very common those days to have a device using a subaddress to address different functions. With the current approach, we need to bind two different things inside the same i2c module, which is not good. - Getting back to the problem Hans discovered with PV951 this was introduced by date: Sun Feb 22 01:59:34 2004 +0000 Yet, I'm not convinced is what Hans discovered is a board with two different functions at the same address, or (what I think it is more likely), aboard with two different setups. Something like: Cheers, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
