From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from bombadil.infradead.org ([18.85.46.34]:34799 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752322AbZCPJIw (ORCPT ); Mon, 16 Mar 2009 05:08:52 -0400 Date: Mon, 16 Mar 2009 06:08:14 -0300 From: Mauro Carvalho Chehab To: Jean Delvare Cc: Trent Piepho , Hans Verkuil , linux-media@vger.kernel.org Subject: Re: bttv, tvaudio and ir-kbd-i2c probing conflict Message-ID: <20090316060814.2c3fd2d5@gaivota.chehab.org> In-Reply-To: <20090315185313.4c15702c@hyperion.delvare> References: <200903151344.01730.hverkuil@xs4all.nl> <20090315181207.36d951ac@hyperion.delvare> <20090315185313.4c15702c@hyperion.delvare> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-media-owner@vger.kernel.org List-ID: On Sun, 15 Mar 2009 18:53:13 +0100 Jean Delvare 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