Re: Multiple device attachments
On Thu, Jul 21, 2011 at 04:24:11PM -0500, Frank Zerangue wrote: The examples you site seem to indicate that for example the le device may attach to many alternative devices (e.g. pci, tc, …), but only one attachment is made when autoconf is complete. I may have read the code examples incorrectly -- please pardon me if I did; but what I want to know is -- can a device have multiple attachments (more than one parent device) when autoconf is complete. I think you mean to ask if one device instance can have more than one parent, e.g., le0 at pci0 le0 at pci1 or le0 at pci0 le0 at isapnp0 I am pretty sure that is not possible. Dave -- David Young OJC Technologies dyo...@ojctech.com Urbana, IL * (217) 344-0444 x24
Re: Multiple device attachments
On Thu, Jul 21, 2011 at 05:42:59PM -0500, David Young wrote: I think you mean to ask if one device instance can have more than one parent, e.g., le0 at pci0 le0 at pci1 or le0 at pci0 le0 at isapnp0 I am pretty sure that is not possible. I'm fairly sure the config file has requested stuff like that for com0/1 on x86. I guess that the second one (detected during autoconf) is rejected. David -- David Laight: da...@l8s.co.uk
Re: Multiple device attachments
I have a hardware configuration with a cmos camera sensor on an i2c bus (for configuring the camera) and connected to an (ipu) image processing controller that acts as a hub for all things video. I envisioned (naturally I think) a camera driver inheriting from two parents 1) i2c bus driver and 2) ipu controller driver. This does not seem like such a strange hardware configuration to me that would not be found on other embedded systems. Does anyone have a suggestion for an appropriate driver hierarchy for such a configuration? Frank On Jul 22, 2011, at 12:07 PM, Eduardo Horvath wrote: On Thu, 21 Jul 2011, Frank Zerangue wrote: The examples you site seem to indicate that for example the le device may attach to many alternative devices (e.g. pci, tc, …), but only one attachment is made when autoconf is complete. I may have read the code examples incorrectly -- please pardon me if I did; but what I want to know is -- can a device have multiple attachments (more than one parent device) when autoconf is complete. What we have is a device tree. That means a device instance can only have one parent. Once it has been instantiated, that instance, with its associated instance number, cannot appear anywhere else in the device tree. It might be good to extend the device tree to a directed graph at some point to support multi-pathed devices on fabrics like SAS, Fibre-channel, or PCIe that allow that sort of thing, but that's a different issue. Eduardo
Re: Multiple device attachments
On Fri, 22 Jul 2011, Frank Zerangue wrote: I have a hardware configuration with a cmos camera sensor on an i2c bus (for configuring the camera) and connected to an (ipu) image processing controller that acts as a hub for all things video. I envisioned (naturally I think) a camera driver inheriting from two parents 1) i2c bus driver and 2) ipu controller driver. This does not seem like such a strange hardware configuration to me that would not be found on other embedded systems. Does anyone have a suggestion for an appropriate driver hierarchy for such a configuration? Ouch. The autoconfig infrastructure is not designed to deal with that sort of configuration. That's also not a traditional multi-path arrangement where the same device is visible through two distinct bus conrollers. In this case you have two distinct connections to two separate devices that need to be managed together. (I assume you can't send the same command down either the I2C or IPU bus and expect the same behavior?) Is the I2C controller and ipu controller under the same parent device or are they in different parts of the device tree? If you have e.g. a PCI card that provides I2C and IPU functionality it would be best to generate a driver for that that manages the entire camera, with possible child devices to handle communication over I2C and IPU separately. However coordination between the two would be best handled at the parent. If not, you need to do some nasty hacks to allow the separate driver bits to rendevous. I did a really ugly hack like that for the psycho device which is a single bus controller which provides two PCI child buses, and some registers are shared between the two buses. But it's definitely best if you could stick to the standard tree approach with one parent and one or more children, at least until the config framework really has multipath support. Eduardo On Jul 22, 2011, at 12:07 PM, Eduardo Horvath wrote: On Thu, 21 Jul 2011, Frank Zerangue wrote: The examples you site seem to indicate that for example the le device may attach to many alternative devices (e.g. pci, tc, …), but only one attachment is made when autoconf is complete. I may have read the code examples incorrectly -- please pardon me if I did; but what I want to know is -- can a device have multiple attachments (more than one parent device) when autoconf is complete. What we have is a device tree. That means a device instance can only have one parent. Once it has been instantiated, that instance, with its associated instance number, cannot appear anywhere else in the device tree. It might be good to extend the device tree to a directed graph at some point to support multi-pathed devices on fabrics like SAS, Fibre-channel, or PCIe that allow that sort of thing, but that's a different issue. Eduardo
Multiple device attachments
/sys/device.h -- seems to indicate that a device driver can attach to multiple parent drivers (e.g. busses, controllers, …) /* * Devices can have multiple configuration attachments if they attach * to different attributes (busses, or whatever), to allow specification * of multiple match and attach functions. There is only one configuration * driver per driver, so that things like unit numbers and the device * structure array will be shared. */ Does anyone know how this is done in practice? Frank
Re: Multiple device attachments
/sys/device.h -- seems to indicate that a device driver can attach to multiple parent drivers (e.g. busses, controllers, ?) Does anyone know how this is done in practice? device wdc: ata, wdc_common attach wdc at isa with wdc_isa attach wdc at isapnp with wdc_iaspnp attach wdc at ofisa with wdc_ofisa attach wdc at pcmcia with wdc_pcmcia com is another example. So is le. I'm sure there are plenty of others. In some cases they don't even need the with stuff, I think. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Re: Multiple device attachments
Hello, On Thu, 21 Jul 2011 14:44:04 -0500 Frank Zerangue frank.zeran...@gmail.com wrote: /sys/device.h -- seems to indicate that a device driver can attach to multiple parent drivers (e.g. busses, controllers, ?) /* * Devices can have multiple configuration attachments if they attach * to different attributes (busses, or whatever), to allow specification * of multiple match and attach functions. There is only one configuration * driver per driver, so that things like unit numbers and the device * structure array will be shared. */ Does anyone know how this is done in practice? You split the driver in bus-dependent and bus-independent portions - the former does stuff like match attach, find and map registers etc., the latter is the actual driver. There are plenty examples in the source tree: - hme, gem exist as pci and sbus variants - le, esp, com have lots of different bus backends ( Try to find a 1990s UNIX workstation that has neither an le nor an esp. Suns used both as sbus devices, others used their own buses or had them embedded in custom IO chips. ) - chipsfb and igsfb supports both pci and ofbus ( actually vlb with OpenFirmware glue, see arch/shark/ofw/chipsfb_ofbus.c, igsfb_ofbus.c ) have fun Michael -- Michael macal...@netbsd.org
Re: Multiple device attachments
Thanks -- On Jul 21, 2011, at 3:18 PM, Michael wrote: Hello, On Thu, 21 Jul 2011 14:44:04 -0500 Frank Zerangue frank.zeran...@gmail.com wrote: /sys/device.h -- seems to indicate that a device driver can attach to multiple parent drivers (e.g. busses, controllers, ?) /* * Devices can have multiple configuration attachments if they attach * to different attributes (busses, or whatever), to allow specification * of multiple match and attach functions. There is only one configuration * driver per driver, so that things like unit numbers and the device * structure array will be shared. */ Does anyone know how this is done in practice? You split the driver in bus-dependent and bus-independent portions - the former does stuff like match attach, find and map registers etc., the latter is the actual driver. There are plenty examples in the source tree: - hme, gem exist as pci and sbus variants - le, esp, com have lots of different bus backends ( Try to find a 1990s UNIX workstation that has neither an le nor an esp. Suns used both as sbus devices, others used their own buses or had them embedded in custom IO chips. ) - chipsfb and igsfb supports both pci and ofbus ( actually vlb with OpenFirmware glue, see arch/shark/ofw/chipsfb_ofbus.c, igsfb_ofbus.c ) have fun Michael -- Michael macal...@netbsd.org
Re: Multiple device attachments
The examples you site seem to indicate that for example the le device may attach to many alternative devices (e.g. pci, tc, …), but only one attachment is made when autoconf is complete. I may have read the code examples incorrectly -- please pardon me if I did; but what I want to know is -- can a device have multiple attachments (more than one parent device) when autoconf is complete. Thanks, Frank On Jul 21, 2011, at 3:18 PM, Michael wrote: Hello, On Thu, 21 Jul 2011 14:44:04 -0500 Frank Zerangue frank.zeran...@gmail.com wrote: /sys/device.h -- seems to indicate that a device driver can attach to multiple parent drivers (e.g. busses, controllers, ?) /* * Devices can have multiple configuration attachments if they attach * to different attributes (busses, or whatever), to allow specification * of multiple match and attach functions. There is only one configuration * driver per driver, so that things like unit numbers and the device * structure array will be shared. */ Does anyone know how this is done in practice? You split the driver in bus-dependent and bus-independent portions - the former does stuff like match attach, find and map registers etc., the latter is the actual driver. There are plenty examples in the source tree: - hme, gem exist as pci and sbus variants - le, esp, com have lots of different bus backends ( Try to find a 1990s UNIX workstation that has neither an le nor an esp. Suns used both as sbus devices, others used their own buses or had them embedded in custom IO chips. ) - chipsfb and igsfb supports both pci and ofbus ( actually vlb with OpenFirmware glue, see arch/shark/ofw/chipsfb_ofbus.c, igsfb_ofbus.c ) have fun Michael -- Michael macal...@netbsd.org
Re: Multiple device attachments
Hello, On Thu, 21 Jul 2011 16:24:11 -0500 Frank Zerangue frank.zeran...@gmail.com wrote: The examples you site seem to indicate that for example the le device may attach to many alternative devices (e.g. pci, tc, ?), but only one attachment is made when autoconf is complete. I may have read the code examples incorrectly -- please pardon me if I did; but what I want to know is -- can a device have multiple attachments (more than one parent device) when autoconf is complete. What do you mean - several instances of the same driver with different bus backends in the same kernel? Sure, there is absolutely nothing to prevent it. have fun Michael
Re: Multiple device attachments
On Thu, 21 Jul 2011, Michael wrote: The examples you site seem to indicate that for example the le device may attach to many alternative devices (e.g. pci, tc, ?), but only one attachment is made when autoconf is complete. I may have read the code examples incorrectly -- please pardon me if I did; but what I want to know is -- can a device have multiple attachments (more than one parent device) when autoconf is complete. What do you mean - several instances of the same driver with different bus backends in the same kernel? Sure, there is absolutely nothing to prevent it. Yes, there can be multiple instances of a driver, with each instance attached to a different attribute. However, each single instance can be attached to only one parent. - | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | Customer Service | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com| | Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette at juniper.net | | Kernel Developer | | pgoyette at netbsd.org | -
Re: Multiple device attachments
The examples you site seem to indicate that for example the le device may attach to many alternative devices (e.g. pci, tc, ?), but only one attachment is made when autoconf is complete. For any particular instance of le, yes. I may have read the code examples incorrectly -- please pardon me if I did; but what I want to know is -- can a device have multiple attachments (more than one parent device) when autoconf is complete. A device can in the sense that, for example, ne0 and ne1 might not attach to the same parent, or even the same kind of parent (eg, one ISA and one PCMCIA). But a single node, a single instance of a driver (eg, ne0), always has at most one parent (exactly one, I think, except for the autoconf root most ports call mainbus). To put it another way, the autoconf tree is a tree, not a dag. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
