Re: [RFCv2 API PATCH 05/28] DocBook: bus_info can no longer be empty.
On Wed September 19 2012 20:46:19 Laurent Pinchart wrote: Hi Hans, On Thursday 13 September 2012 12:40:07 Hans Verkuil wrote: On Thu 13 September 2012 03:24:53 Laurent Pinchart wrote: On Friday 07 September 2012 15:29:05 Hans Verkuil wrote: From: Hans Verkuil hans.verk...@cisco.com During the 2012 Media Workshop it was decided that bus_info as returned by VIDIOC_QUERYCAP can no longer be empty. It should be a unique identifier, and empty strings are obviously not unique. Signed-off-by: Hans Verkuil hans.verk...@cisco.com --- Documentation/DocBook/media/v4l/vidioc-querycap.xml | 14 ++ 1 file changed, 10 insertions(+), 4 deletions(-) diff --git a/Documentation/DocBook/media/v4l/vidioc-querycap.xml b/Documentation/DocBook/media/v4l/vidioc-querycap.xml index f33dd74..d5b1248 100644 --- a/Documentation/DocBook/media/v4l/vidioc-querycap.xml +++ b/Documentation/DocBook/media/v4l/vidioc-querycap.xml @@ -90,11 +90,17 @@ ambiguities./entry entry__u8/entry entrystructfieldbus_info/structfield[32]/entry entryLocation of the device in the system, a -NUL-terminated ASCII string. For example: PCI Slot 4. This +NUL-terminated ASCII string. For example: PCI::05:06.0. This information is intended for users, to distinguish multiple -identical devices. If no such information is available the field may -simply count the devices controlled by the driver, or contain the -empty string (structfieldbus_info/structfield[0] = 0).!-- XXX pci_dev-slot_name example --/entry +identical devices. If no such information is available the field must +simply count the devices controlled by the driver (vivi-000). The bus_info +must start with PCI: for PCI boards, PCIe: for PCI Express boards, +usb- for USB devices, I2C: for i2c devices, ISA: for ISA devices and +parport for parallel port devices. What about being a bit more precise than that ? We could specify what API drivers must use to fill the bus_info field. For instance, for USB devices, usb_make_path() is currently used by most drivers (which, by the way, doesn't return a string that starts with USB:). I thought about that, but should that be defined in the spec? I'm not sure if that's the right place. On the other hand, if we don't specify the format of the bus_info field precisely, it will only be usable as an opaque identifier to userspace. What do we want to do with bus_info ? Telling otherwise identical devices apart is a must, but do we want to provide more information to userspace ? If the field had been longer a sysfs path might have been a good idea, but it won't fit. Well, we can use the bus_info to find a device in sysfs. E.g. for the ivtv card I get bus_info PCI::0b:01.0 and the same device is found here in sysfs: /sys/bus/pci/devices/:0b:01.0 We can try to document the relationship between bus_info and sysfs here and that would define bus_info exactly. I don't quite see how a usb bus_info maps to sysfs, however. Do you know? Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFCv2 API PATCH 05/28] DocBook: bus_info can no longer be empty.
Hi Hans, On Thursday 20 September 2012 08:38:26 Hans Verkuil wrote: On Wed September 19 2012 20:46:19 Laurent Pinchart wrote: On Thursday 13 September 2012 12:40:07 Hans Verkuil wrote: On Thu 13 September 2012 03:24:53 Laurent Pinchart wrote: On Friday 07 September 2012 15:29:05 Hans Verkuil wrote: From: Hans Verkuil hans.verk...@cisco.com During the 2012 Media Workshop it was decided that bus_info as returned by VIDIOC_QUERYCAP can no longer be empty. It should be a unique identifier, and empty strings are obviously not unique. Signed-off-by: Hans Verkuil hans.verk...@cisco.com --- Documentation/DocBook/media/v4l/vidioc-querycap.xml | 14 ++-- 1 file changed, 10 insertions(+), 4 deletions(-) diff --git a/Documentation/DocBook/media/v4l/vidioc-querycap.xml b/Documentation/DocBook/media/v4l/vidioc-querycap.xml index f33dd74..d5b1248 100644 --- a/Documentation/DocBook/media/v4l/vidioc-querycap.xml +++ b/Documentation/DocBook/media/v4l/vidioc-querycap.xml @@ -90,11 +90,17 @@ ambiguities./entry entry__u8/entry entrystructfieldbus_info/structfield[32]/entry entryLocation of the device in the system, a -NUL-terminated ASCII string. For example: PCI Slot 4. This +NUL-terminated ASCII string. For example: PCI::05:06.0. This information is intended for users, to distinguish multiple -identical devices. If no such information is available the field may -simply count the devices controlled by the driver, or contain the -empty string (structfieldbus_info/structfield[0] = 0).!-- XXX pci_dev-slot_name example --/entry +identical devices. If no such information is available the field must +simply count the devices controlled by the driver (vivi-000). The bus_info +must start with PCI: for PCI boards, PCIe: for PCI Express boards, +usb- for USB devices, I2C: for i2c devices, ISA: for ISA devices and +parport for parallel port devices. What about being a bit more precise than that ? We could specify what API drivers must use to fill the bus_info field. For instance, for USB devices, usb_make_path() is currently used by most drivers (which, by the way, doesn't return a string that starts with USB:). I thought about that, but should that be defined in the spec? I'm not sure if that's the right place. On the other hand, if we don't specify the format of the bus_info field precisely, it will only be usable as an opaque identifier to userspace. What do we want to do with bus_info ? Telling otherwise identical devices apart is a must, but do we want to provide more information to userspace ? If the field had been longer a sysfs path might have been a good idea, but it won't fit. Well, we can use the bus_info to find a device in sysfs. E.g. for the ivtv card I get bus_info PCI::0b:01.0 and the same device is found here in sysfs: /sys/bus/pci/devices/:0b:01.0 For PCI (and probably PCIe) devices we're probably safe. We can try to document the relationship between bus_info and sysfs here and that would define bus_info exactly. That sounds good to me. I don't quite see how a usb bus_info maps to sysfs, however. Do you know? It's a bit more difficult. usb_make_path() uses snprintf(buf, size, usb-%s-%s, dev-bus-bus_name, dev-devpath); to create the path. dev-bus-bus_name is the physical USB host controller name, and devpath the USB device path relative to that controller. For instance my UVC webcam produces usb-:00:1d.0-1.4 :00:1d.0 refers to the PCI USB host controller, but doesn't mention that it's a PCI device. If I'm not mistaken, 1.4 refers to port 4 on root hub 1. Knowing that the USB host controller is a PCI device, I can get the USB host controller number: $ ls -d /sys/bus/pci/devices/:00:1d.0/usb[0-9] /sys/bus/pci/devices/:00:1d.0/usb2 and then go the to USB device itself: $ ls -d /sys/bus/usb/devices/2-1.4 /sys/bus/usb/devices/2-1.4 That's a bit hackish though. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFCv2 API PATCH 05/28] DocBook: bus_info can no longer be empty.
Hi Hans, On Thursday 13 September 2012 12:40:07 Hans Verkuil wrote: On Thu 13 September 2012 03:24:53 Laurent Pinchart wrote: On Friday 07 September 2012 15:29:05 Hans Verkuil wrote: From: Hans Verkuil hans.verk...@cisco.com During the 2012 Media Workshop it was decided that bus_info as returned by VIDIOC_QUERYCAP can no longer be empty. It should be a unique identifier, and empty strings are obviously not unique. Signed-off-by: Hans Verkuil hans.verk...@cisco.com --- Documentation/DocBook/media/v4l/vidioc-querycap.xml | 14 ++ 1 file changed, 10 insertions(+), 4 deletions(-) diff --git a/Documentation/DocBook/media/v4l/vidioc-querycap.xml b/Documentation/DocBook/media/v4l/vidioc-querycap.xml index f33dd74..d5b1248 100644 --- a/Documentation/DocBook/media/v4l/vidioc-querycap.xml +++ b/Documentation/DocBook/media/v4l/vidioc-querycap.xml @@ -90,11 +90,17 @@ ambiguities./entry entry__u8/entry entrystructfieldbus_info/structfield[32]/entry entryLocation of the device in the system, a -NUL-terminated ASCII string. For example: PCI Slot 4. This +NUL-terminated ASCII string. For example: PCI::05:06.0. This information is intended for users, to distinguish multiple -identical devices. If no such information is available the field may -simply count the devices controlled by the driver, or contain the -empty string (structfieldbus_info/structfield[0] = 0).!-- XXX pci_dev-slot_name example --/entry +identical devices. If no such information is available the field must +simply count the devices controlled by the driver (vivi-000). The bus_info +must start with PCI: for PCI boards, PCIe: for PCI Express boards, +usb- for USB devices, I2C: for i2c devices, ISA: for ISA devices and +parport for parallel port devices. What about being a bit more precise than that ? We could specify what API drivers must use to fill the bus_info field. For instance, for USB devices, usb_make_path() is currently used by most drivers (which, by the way, doesn't return a string that starts with USB:). I thought about that, but should that be defined in the spec? I'm not sure if that's the right place. On the other hand, if we don't specify the format of the bus_info field precisely, it will only be usable as an opaque identifier to userspace. What do we want to do with bus_info ? Telling otherwise identical devices apart is a must, but do we want to provide more information to userspace ? If the field had been longer a sysfs path might have been a good idea, but it won't fit. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFCv2 API PATCH 05/28] DocBook: bus_info can no longer be empty.
Hi Hans, Thanks for the patch. On Friday 07 September 2012 15:29:05 Hans Verkuil wrote: From: Hans Verkuil hans.verk...@cisco.com During the 2012 Media Workshop it was decided that bus_info as returned by VIDIOC_QUERYCAP can no longer be empty. It should be a unique identifier, and empty strings are obviously not unique. Signed-off-by: Hans Verkuil hans.verk...@cisco.com --- Documentation/DocBook/media/v4l/vidioc-querycap.xml | 14 ++ 1 file changed, 10 insertions(+), 4 deletions(-) diff --git a/Documentation/DocBook/media/v4l/vidioc-querycap.xml b/Documentation/DocBook/media/v4l/vidioc-querycap.xml index f33dd74..d5b1248 100644 --- a/Documentation/DocBook/media/v4l/vidioc-querycap.xml +++ b/Documentation/DocBook/media/v4l/vidioc-querycap.xml @@ -90,11 +90,17 @@ ambiguities./entry entry__u8/entry entrystructfieldbus_info/structfield[32]/entry entryLocation of the device in the system, a -NUL-terminated ASCII string. For example: PCI Slot 4. This +NUL-terminated ASCII string. For example: PCI::05:06.0. This information is intended for users, to distinguish multiple -identical devices. If no such information is available the field may -simply count the devices controlled by the driver, or contain the -empty string (structfieldbus_info/structfield[0] = 0).!-- XXX pci_dev-slot_name example --/entry +identical devices. If no such information is available the field must +simply count the devices controlled by the driver (vivi-000). The bus_info +must start with PCI: for PCI boards, PCIe: for PCI Express boards, +usb- for USB devices, I2C: for i2c devices, ISA: for ISA devices and +parport for parallel port devices. What about being a bit more precise than that ? We could specify what API drivers must use to fill the bus_info field. For instance, for USB devices, usb_make_path() is currently used by most drivers (which, by the way, doesn't return a string that starts with USB:). +For devices without a bus it should start with the driver name, optionally +followed by - and an index if multiple instances of the device as possible. +Many platform devices can have only one instance, so in that case bus_info +is identical to the structfielddriver/structfield field./entry /row row entry__u32/entry -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFCv2 API PATCH 05/28] DocBook: bus_info can no longer be empty.
On Thu 13 September 2012 03:24:53 Laurent Pinchart wrote: Hi Hans, Thanks for the patch. On Friday 07 September 2012 15:29:05 Hans Verkuil wrote: From: Hans Verkuil hans.verk...@cisco.com During the 2012 Media Workshop it was decided that bus_info as returned by VIDIOC_QUERYCAP can no longer be empty. It should be a unique identifier, and empty strings are obviously not unique. Signed-off-by: Hans Verkuil hans.verk...@cisco.com --- Documentation/DocBook/media/v4l/vidioc-querycap.xml | 14 ++ 1 file changed, 10 insertions(+), 4 deletions(-) diff --git a/Documentation/DocBook/media/v4l/vidioc-querycap.xml b/Documentation/DocBook/media/v4l/vidioc-querycap.xml index f33dd74..d5b1248 100644 --- a/Documentation/DocBook/media/v4l/vidioc-querycap.xml +++ b/Documentation/DocBook/media/v4l/vidioc-querycap.xml @@ -90,11 +90,17 @@ ambiguities./entry entry__u8/entry entrystructfieldbus_info/structfield[32]/entry entryLocation of the device in the system, a -NUL-terminated ASCII string. For example: PCI Slot 4. This +NUL-terminated ASCII string. For example: PCI::05:06.0. This information is intended for users, to distinguish multiple -identical devices. If no such information is available the field may -simply count the devices controlled by the driver, or contain the -empty string (structfieldbus_info/structfield[0] = 0).!-- XXX pci_dev-slot_name example --/entry +identical devices. If no such information is available the field must +simply count the devices controlled by the driver (vivi-000). The bus_info +must start with PCI: for PCI boards, PCIe: for PCI Express boards, +usb- for USB devices, I2C: for i2c devices, ISA: for ISA devices and +parport for parallel port devices. What about being a bit more precise than that ? We could specify what API drivers must use to fill the bus_info field. For instance, for USB devices, usb_make_path() is currently used by most drivers (which, by the way, doesn't return a string that starts with USB:). I thought about that, but should that be defined in the spec? I'm not sure if that's the right place. Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFCv2 API PATCH 05/28] DocBook: bus_info can no longer be empty.
On Sat September 8 2012 16:19:18 Sylwester Nawrocki wrote: On 09/08/2012 01:15 PM, Hans Verkuil wrote: On Fri September 7 2012 22:00:33 Sylwester Nawrocki wrote: On 09/07/2012 03:29 PM, Hans Verkuil wrote: From: Hans Verkuilhans.verk...@cisco.com During the 2012 Media Workshop it was decided that bus_info as returned by VIDIOC_QUERYCAP can no longer be empty. It should be a unique identifier, and empty strings are obviously not unique. Signed-off-by: Hans Verkuilhans.verk...@cisco.com Reviewed-by: Sylwester Nawrockis.nawro...@samsung.com --- Documentation/DocBook/media/v4l/vidioc-querycap.xml | 14 ++ 1 file changed, 10 insertions(+), 4 deletions(-) diff --git a/Documentation/DocBook/media/v4l/vidioc-querycap.xml b/Documentation/DocBook/media/v4l/vidioc-querycap.xml index f33dd74..d5b1248 100644 --- a/Documentation/DocBook/media/v4l/vidioc-querycap.xml +++ b/Documentation/DocBook/media/v4l/vidioc-querycap.xml @@ -90,11 +90,17 @@ ambiguities./entry entry__u8/entry entrystructfieldbus_info/structfield[32]/entry entryLocation of the device in the system, a -NUL-terminated ASCII string. For example: PCI Slot 4. This +NUL-terminated ASCII string. For example: PCI::05:06.0. This information is intended for users, to distinguish multiple -identical devices. If no such information is available the field may -simply count the devices controlled by the driver, or contain the -empty string (structfieldbus_info/structfield[0] = 0).!-- XXX pci_dev-slot_name example --/entry +identical devices. If no such information is available the field must +simply count the devices controlled by the driver (vivi-000). The bus_info +must start with PCI: for PCI boards, PCIe: for PCI Express boards, +usb- for USB devices, I2C: for i2c devices, ISA: for ISA devices and +parport for parallel port devices. +For devices without a bus it should start with the driver name, optionally Most, if not all, devices are on some sort of bus. What would be an example of a device without a bus ? Virtual devices like vivi and platform devices. Or is there some sort of platform bus? OK, then virtual devices like vivi are indeed not on any bus. But saying so, or implicitly assuming, about platform devices would have been misleading. On ASICs and SoCs such devices are on some kind of on-chip peripheral bus, e.g. AMBA APB/AHB [1]. Yes, but such busses are internal to the hardware and are not enumerated by the kernel. The kernel will generate unique names for e.g. usb and pci busses which is used to identify the device on that bus. And that's used also when generating the bus_info. That said, I checked drivers/base/platform.c and there is actually a platform bus that's created in the kernel for platform devices. So perhaps something like platform:devname wouldn't be such a bad idea after all. I'd have to do some tests with this to see how it would look. Regards, Hans So perhaps we could specify that for platform devices bus_info should start with platform- ? A unique remainder could be easily formed in drivers on basis of a memory mapped register region address/size and/or a device interrupt number to the CPU. However, exposing such sensitive data may be questionable, so it's probably better to just stick with a simple counter of identical devices. Could we just be saying here For other devices instead of For devices without a bus, or something similar ? Well, I'd like for any device on a bus to have a consistent naming convention so we can guarantee that bus_info is always unique. Regards, Hans +followed by - and an index if multiple instances of the device as possible. +Many platform devices can have only one instance, so in that case bus_info +is identical to thestructfielddriver/structfield field./entry /row row entry__u32/entry [1] http://www-micro.deis.unibo.it/~magagni/amba99.pdf -- Regards, Sylwester -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFCv2 API PATCH 05/28] DocBook: bus_info can no longer be empty.
On 09/09/2012 10:45 AM, Hans Verkuil wrote: diff --git a/Documentation/DocBook/media/v4l/vidioc-querycap.xml b/Documentation/DocBook/media/v4l/vidioc-querycap.xml index f33dd74..d5b1248 100644 --- a/Documentation/DocBook/media/v4l/vidioc-querycap.xml +++ b/Documentation/DocBook/media/v4l/vidioc-querycap.xml @@ -90,11 +90,17 @@ ambiguities./entry entry__u8/entry entrystructfieldbus_info/structfield[32]/entry entryLocation of the device in the system, a -NUL-terminated ASCII string. For example: PCI Slot 4. This +NUL-terminated ASCII string. For example: PCI::05:06.0. This information is intended for users, to distinguish multiple -identical devices. If no such information is available the field may -simply count the devices controlled by the driver, or contain the -empty string (structfieldbus_info/structfield[0] = 0).!-- XXX pci_dev-slot_name example --/entry +identical devices. If no such information is available the field must +simply count the devices controlled by the driver (vivi-000). The bus_info +must start with PCI: for PCI boards, PCIe: for PCI Express boards, +usb- for USB devices, I2C: for i2c devices, ISA: for ISA devices and +parport for parallel port devices. +For devices without a bus it should start with the driver name, optionally Most, if not all, devices are on some sort of bus. What would be an example of a device without a bus ? Virtual devices like vivi and platform devices. Or is there some sort of platform bus? OK, then virtual devices like vivi are indeed not on any bus. But saying so, or implicitly assuming, about platform devices would have been misleading. On ASICs and SoCs such devices are on some kind of on-chip peripheral bus, e.g. AMBA APB/AHB [1]. Yes, but such busses are internal to the hardware and are not enumerated by the kernel. The kernel will generate unique names for e.g. usb and pci busses which is used to identify the device on that bus. And that's used also when generating the bus_info. They are not enumerated but are commonly referred to as simple bus or AMBA bus and mapped to system address space. See drivers/of/platform.c or Documentation/devicetree/usage-model.txt. And the device names must also be unique IIRC. platform_bus_type is also often used for devices that don't match with any other existing bus_type. One could look at /sys/bus/platform/devices for sample list of platform devices. That said, I checked drivers/base/platform.c and there is actually a platform bus that's created in the kernel for platform devices. So perhaps something like platform:devname wouldn't be such a bad idea after all. I'd have to do some tests with this to see how it would look. Yeah, obviously. platform:devname sounds good, bus_info would be then telling something about the bus, rather than being a redundant copy of driver's name. -- Regards, Sylwester -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFCv2 API PATCH 05/28] DocBook: bus_info can no longer be empty.
On Fri September 7 2012 22:00:33 Sylwester Nawrocki wrote: On 09/07/2012 03:29 PM, Hans Verkuil wrote: From: Hans Verkuilhans.verk...@cisco.com During the 2012 Media Workshop it was decided that bus_info as returned by VIDIOC_QUERYCAP can no longer be empty. It should be a unique identifier, and empty strings are obviously not unique. Signed-off-by: Hans Verkuilhans.verk...@cisco.com Reviewed-by: Sylwester Nawrocki s.nawro...@samsung.com --- Documentation/DocBook/media/v4l/vidioc-querycap.xml | 14 ++ 1 file changed, 10 insertions(+), 4 deletions(-) diff --git a/Documentation/DocBook/media/v4l/vidioc-querycap.xml b/Documentation/DocBook/media/v4l/vidioc-querycap.xml index f33dd74..d5b1248 100644 --- a/Documentation/DocBook/media/v4l/vidioc-querycap.xml +++ b/Documentation/DocBook/media/v4l/vidioc-querycap.xml @@ -90,11 +90,17 @@ ambiguities./entry entry__u8/entry entrystructfieldbus_info/structfield[32]/entry entryLocation of the device in the system, a -NUL-terminated ASCII string. For example: PCI Slot 4. This +NUL-terminated ASCII string. For example: PCI::05:06.0. This information is intended for users, to distinguish multiple -identical devices. If no such information is available the field may -simply count the devices controlled by the driver, or contain the -empty string (structfieldbus_info/structfield[0] = 0).!-- XXX pci_dev-slot_name example --/entry +identical devices. If no such information is available the field must +simply count the devices controlled by the driver (vivi-000). The bus_info +must start with PCI: for PCI boards, PCIe: for PCI Express boards, +usb- for USB devices, I2C: for i2c devices, ISA: for ISA devices and +parport for parallel port devices. +For devices without a bus it should start with the driver name, optionally Most, if not all, devices are on some sort of bus. What would be an example of a device without a bus ? Virtual devices like vivi and platform devices. Or is there some sort of platform bus? Could we just be saying here For other devices instead of For devices without a bus, or something similar ? Well, I'd like for any device on a bus to have a consistent naming convention so we can guarantee that bus_info is always unique. Regards, Hans +followed by - and an index if multiple instances of the device as possible. +Many platform devices can have only one instance, so in that case bus_info +is identical to thestructfielddriver/structfield field./entry /row row entry__u32/entry -- Regards, Sylwester -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFCv2 API PATCH 05/28] DocBook: bus_info can no longer be empty.
On 09/08/2012 01:15 PM, Hans Verkuil wrote: On Fri September 7 2012 22:00:33 Sylwester Nawrocki wrote: On 09/07/2012 03:29 PM, Hans Verkuil wrote: From: Hans Verkuilhans.verk...@cisco.com During the 2012 Media Workshop it was decided that bus_info as returned by VIDIOC_QUERYCAP can no longer be empty. It should be a unique identifier, and empty strings are obviously not unique. Signed-off-by: Hans Verkuilhans.verk...@cisco.com Reviewed-by: Sylwester Nawrockis.nawro...@samsung.com --- Documentation/DocBook/media/v4l/vidioc-querycap.xml | 14 ++ 1 file changed, 10 insertions(+), 4 deletions(-) diff --git a/Documentation/DocBook/media/v4l/vidioc-querycap.xml b/Documentation/DocBook/media/v4l/vidioc-querycap.xml index f33dd74..d5b1248 100644 --- a/Documentation/DocBook/media/v4l/vidioc-querycap.xml +++ b/Documentation/DocBook/media/v4l/vidioc-querycap.xml @@ -90,11 +90,17 @@ ambiguities./entry entry__u8/entry entrystructfieldbus_info/structfield[32]/entry entryLocation of the device in the system, a -NUL-terminated ASCII string. For example: PCI Slot 4. This +NUL-terminated ASCII string. For example: PCI::05:06.0. This information is intended for users, to distinguish multiple -identical devices. If no such information is available the field may -simply count the devices controlled by the driver, or contain the -empty string (structfieldbus_info/structfield[0] = 0).!-- XXX pci_dev-slot_name example --/entry +identical devices. If no such information is available the field must +simply count the devices controlled by the driver (vivi-000). The bus_info +must start with PCI: for PCI boards, PCIe: for PCI Express boards, +usb- for USB devices, I2C: for i2c devices, ISA: for ISA devices and +parport for parallel port devices. +For devices without a bus it should start with the driver name, optionally Most, if not all, devices are on some sort of bus. What would be an example of a device without a bus ? Virtual devices like vivi and platform devices. Or is there some sort of platform bus? OK, then virtual devices like vivi are indeed not on any bus. But saying so, or implicitly assuming, about platform devices would have been misleading. On ASICs and SoCs such devices are on some kind of on-chip peripheral bus, e.g. AMBA APB/AHB [1]. So perhaps we could specify that for platform devices bus_info should start with platform- ? A unique remainder could be easily formed in drivers on basis of a memory mapped register region address/size and/or a device interrupt number to the CPU. However, exposing such sensitive data may be questionable, so it's probably better to just stick with a simple counter of identical devices. Could we just be saying here For other devices instead of For devices without a bus, or something similar ? Well, I'd like for any device on a bus to have a consistent naming convention so we can guarantee that bus_info is always unique. Regards, Hans +followed by - and an index if multiple instances of the device as possible. +Many platform devices can have only one instance, so in that case bus_info +is identical to thestructfielddriver/structfield field./entry /row row entry__u32/entry [1] http://www-micro.deis.unibo.it/~magagni/amba99.pdf -- Regards, Sylwester -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFCv2 API PATCH 05/28] DocBook: bus_info can no longer be empty.
On 09/07/2012 03:29 PM, Hans Verkuil wrote: From: Hans Verkuilhans.verk...@cisco.com During the 2012 Media Workshop it was decided that bus_info as returned by VIDIOC_QUERYCAP can no longer be empty. It should be a unique identifier, and empty strings are obviously not unique. Signed-off-by: Hans Verkuilhans.verk...@cisco.com Reviewed-by: Sylwester Nawrocki s.nawro...@samsung.com --- Documentation/DocBook/media/v4l/vidioc-querycap.xml | 14 ++ 1 file changed, 10 insertions(+), 4 deletions(-) diff --git a/Documentation/DocBook/media/v4l/vidioc-querycap.xml b/Documentation/DocBook/media/v4l/vidioc-querycap.xml index f33dd74..d5b1248 100644 --- a/Documentation/DocBook/media/v4l/vidioc-querycap.xml +++ b/Documentation/DocBook/media/v4l/vidioc-querycap.xml @@ -90,11 +90,17 @@ ambiguities./entry entry__u8/entry entrystructfieldbus_info/structfield[32]/entry entryLocation of the device in the system, a -NUL-terminated ASCII string. For example: PCI Slot 4. This +NUL-terminated ASCII string. For example: PCI::05:06.0. This information is intended for users, to distinguish multiple -identical devices. If no such information is available the field may -simply count the devices controlled by the driver, or contain the -empty string (structfieldbus_info/structfield[0] = 0).!-- XXX pci_dev-slot_name example --/entry +identical devices. If no such information is available the field must +simply count the devices controlled by the driver (vivi-000). The bus_info +must start with PCI: for PCI boards, PCIe: for PCI Express boards, +usb- for USB devices, I2C: for i2c devices, ISA: for ISA devices and +parport for parallel port devices. +For devices without a bus it should start with the driver name, optionally Most, if not all, devices are on some sort of bus. What would be an example of a device without a bus ? Could we just be saying here For other devices instead of For devices without a bus, or something similar ? +followed by - and an index if multiple instances of the device as possible. +Many platform devices can have only one instance, so in that case bus_info +is identical to thestructfielddriver/structfield field./entry /row row entry__u32/entry -- Regards, Sylwester -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
