Re: [RFC/PATCH v4 07/11] media: Entities, pads and links enumeration
Hi Hans,
On Monday 06 September 2010 18:51:59 Hans Verkuil wrote:
On Wednesday, September 01, 2010 16:05:10 Laurent Pinchart wrote:
On Saturday 28 August 2010 13:02:22 Hans Verkuil wrote:
On Friday, August 20, 2010 17:29:09 Laurent Pinchart wrote:
[snip]
diff --git a/Documentation/media-framework.txt
b/Documentation/media-framework.txt index 66f7f6c..74a137d 100644
--- a/Documentation/media-framework.txt
+++ b/Documentation/media-framework.txt
[snip]
+The media_entity_desc structure is defined as
+
+- struct media_entity_desc
+
+__u32 id Entity id, set by the application. When the id
is
+ or'ed with MEDIA_ENTITY_ID_FLAG_NEXT, the driver
+ clears the flag and returns the first entity
with a
+ larger id.
+char name[32]Entity name. UTF-8 NULL-terminated string.
Why UTF-8 instead of ASCII?
Because vendor-specific names could include non-ASCII characters (same
reason for the model name in the media_device structure, if we decice to
make the model name ASCII I'll make the entity name ASCII as well).
[snip]
+struct media_entity_desc {
+ __u32 id;
+ char name[32];
+ __u32 type;
+ __u32 revision;
+ __u32 flags;
+ __u32 group_id;
+ __u16 pads;
+ __u16 links;
+
+ __u32 reserved[4];
+
+ union {
+ /* Node specifications */
+ struct {
+ __u32 major;
+ __u32 minor;
+ } v4l;
+ struct {
+ __u32 major;
+ __u32 minor;
+ } fb;
+ int alsa;
+ int dvb;
+
+ /* Sub-device specifications */
+ /* Nothing needed yet */
+ __u8 raw[64];
+ };
+};
Should this be a packed struct?
Why ? :-) Packed struct are most useful when they need to match hardware
structures or network protocols. Packing a structure can generate
unaligned fields, which are bad performance-wise.
I'm thinking about preventing a compat32 mess as we have for v4l.
It is my understanding that the only way to prevent different struct sizes
between 32 and 64 bit is to use packed.
I don't think that's correct. Different struct sizes between 32bit and 64bit
are caused by variable-size fields, such as 'long' (32bit on 32bit
architectures, 64bit on 64bit architectures). I might be wrong 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: [RFC/PATCH v4 07/11] media: Entities, pads and links enumeration
Hi Laurent and Hans, Laurent Pinchart wrote: Hi Hans, On Monday 06 September 2010 18:51:59 Hans Verkuil wrote: On Wednesday, September 01, 2010 16:05:10 Laurent Pinchart wrote: On Saturday 28 August 2010 13:02:22 Hans Verkuil wrote: On Friday, August 20, 2010 17:29:09 Laurent Pinchart wrote: ... +}; Should this be a packed struct? Why ? :-) Packed struct are most useful when they need to match hardware structures or network protocols. Packing a structure can generate unaligned fields, which are bad performance-wise. I'm thinking about preventing a compat32 mess as we have for v4l. It is my understanding that the only way to prevent different struct sizes between 32 and 64 bit is to use packed. I don't think that's correct. Different struct sizes between 32bit and 64bit are caused by variable-size fields, such as 'long' (32bit on 32bit architectures, 64bit on 64bit architectures). I might be wrong though. As far as I understand that's another reason for the structures not being exactly the same. Alignment of different data types in structures depends on ABI. I don't know the exact rules for all the architectures Linux supports if there are cases where the alignment would be different for 32-bit and 64-bit and smaller than the data type. On ARM there have been different alignments depending on ABI (EABI vs. GNU ABI) which is now practically history though. I couldn't find a better reference than this: URL:http://developers.sun.com/solaris/articles/about_amd64_abi.html 64-bit integers are aligned differently on 32-bit and 64-bit x86 but the alignment is still smaller or equal to the size of the data type. I'd also pack them to be sure. The structures should be constructed so that the alignment is sane even if they are packed. In that case there's no harm done by packing. It just prevents a failure (32-bit vs. 64-bit) if there's a problem with the definition. Just my 2 cents worth. :) Regards, -- Sakari Ailus sakari.ai...@maxwell.research.nokia.com -- 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: [RFC/PATCH v4 07/11] media: Entities, pads and links enumeration
Hi Sakari,
On Thursday 16 September 2010 17:36:29 Sakari Ailus wrote:
Laurent Pinchart wrote:
On Monday 06 September 2010 18:51:59 Hans Verkuil wrote:
On Wednesday, September 01, 2010 16:05:10 Laurent Pinchart wrote:
On Saturday 28 August 2010 13:02:22 Hans Verkuil wrote:
On Friday, August 20, 2010 17:29:09 Laurent Pinchart wrote:
...
+};
Should this be a packed struct?
Why ? :-) Packed struct are most useful when they need to match
hardware structures or network protocols. Packing a structure can
generate unaligned fields, which are bad performance-wise.
I'm thinking about preventing a compat32 mess as we have for v4l.
It is my understanding that the only way to prevent different struct
sizes between 32 and 64 bit is to use packed.
I don't think that's correct. Different struct sizes between 32bit and
64bit are caused by variable-size fields, such as 'long' (32bit on 32bit
architectures, 64bit on 64bit architectures). I might be wrong though.
As far as I understand that's another reason for the structures not
being exactly the same. Alignment of different data types in structures
depends on ABI. I don't know the exact rules for all the architectures
Linux supports if there are cases where the alignment would be different
for 32-bit and 64-bit and smaller than the data type. On ARM there have
been different alignments depending on ABI (EABI vs. GNU ABI) which is
now practically history though.
I couldn't find a better reference than this:
URL:http://developers.sun.com/solaris/articles/about_amd64_abi.html
64-bit integers are aligned differently on 32-bit and 64-bit x86 but the
alignment is still smaller or equal to the size of the data type.
Thanks for the link.
I'd also pack them to be sure. The structures should be constructed so
that the alignment is sane even if they are packed. In that case there's
no harm done by packing. It just prevents a failure (32-bit vs. 64-bit)
if there's a problem with the definition.
Even if the structures were packed we would have a problem with
media_user_links. The pads and links pointers will be 4-bytes long on 32-bit
and 8-bytes long on 64-bit. There's no way around that. I could pad the
structure to a fixed size with
struct media_links_enum {
__u32 entity;
/* Should have enough room for pads elements */
struct media_pad_desc __user *pads;
__u8 __pad1[8 - sizeof(void *)];
/* Should have enough room for links elements */
struct media_link_desc __user *links;
__u8 __pad2[8 - sizeof(void *)];
__u32 reserved[4];
};
or with
struct media_links_enum {
__u32 entity;
union {
struct {
/* Should have enough room for pads elements */
struct media_pad_desc __user *pads;
/* Should have enough room for links elements */
struct media_link_desc __user *links;
};
__u32 __pad[4];
};
__u32 reserved[4];
};
Is there any other way ?
--
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: [RFC/PATCH v4 07/11] media: Entities, pads and links enumeration
On Wednesday, September 01, 2010 16:05:10 Laurent Pinchart wrote:
Hi Hans,
On Saturday 28 August 2010 13:02:22 Hans Verkuil wrote:
On Friday, August 20, 2010 17:29:09 Laurent Pinchart wrote:
[snip]
diff --git a/Documentation/media-framework.txt
b/Documentation/media-framework.txt index 66f7f6c..74a137d 100644
--- a/Documentation/media-framework.txt
+++ b/Documentation/media-framework.txt
[snip]
+The media_entity_desc structure is defined as
+
+- struct media_entity_desc
+
+__u32id Entity id, set by the application. When the id
is
+ or'ed with MEDIA_ENTITY_ID_FLAG_NEXT, the driver
+ clears the flag and returns the first entity with a
+ larger id.
+char name[32]Entity name. UTF-8 NULL-terminated string.
Why UTF-8 instead of ASCII?
Because vendor-specific names could include non-ASCII characters (same reason
for the model name in the media_device structure, if we decice to make the
model name ASCII I'll make the entity name ASCII as well).
[snip]
+struct media_entity_desc {
+ __u32 id;
+ char name[32];
+ __u32 type;
+ __u32 revision;
+ __u32 flags;
+ __u32 group_id;
+ __u16 pads;
+ __u16 links;
+
+ __u32 reserved[4];
+
+ union {
+ /* Node specifications */
+ struct {
+ __u32 major;
+ __u32 minor;
+ } v4l;
+ struct {
+ __u32 major;
+ __u32 minor;
+ } fb;
+ int alsa;
+ int dvb;
+
+ /* Sub-device specifications */
+ /* Nothing needed yet */
+ __u8 raw[64];
+ };
+};
Should this be a packed struct?
Why ? :-) Packed struct are most useful when they need to match hardware
structures or network protocols. Packing a structure can generate unaligned
fields, which are bad performance-wise.
I'm thinking about preventing a compat32 mess as we have for v4l.
It is my understanding that the only way to prevent different struct sizes
between 32 and 64 bit is to use packed.
Regards,
Hans
--
Hans Verkuil - video4linux developer - sponsored by TANDBERG, part of Cisco
--
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: [RFC/PATCH v4 07/11] media: Entities, pads and links enumeration
Hi Hans,
On Saturday 28 August 2010 13:02:22 Hans Verkuil wrote:
On Friday, August 20, 2010 17:29:09 Laurent Pinchart wrote:
[snip]
diff --git a/Documentation/media-framework.txt
b/Documentation/media-framework.txt index 66f7f6c..74a137d 100644
--- a/Documentation/media-framework.txt
+++ b/Documentation/media-framework.txt
[snip]
+The media_entity_desc structure is defined as
+
+- struct media_entity_desc
+
+__u32 id Entity id, set by the application. When the id
is
+ or'ed with MEDIA_ENTITY_ID_FLAG_NEXT, the driver
+ clears the flag and returns the first entity with a
+ larger id.
+char name[32]Entity name. UTF-8 NULL-terminated string.
Why UTF-8 instead of ASCII?
Because vendor-specific names could include non-ASCII characters (same reason
for the model name in the media_device structure, if we decice to make the
model name ASCII I'll make the entity name ASCII as well).
[snip]
+struct media_entity_desc {
+ __u32 id;
+ char name[32];
+ __u32 type;
+ __u32 revision;
+ __u32 flags;
+ __u32 group_id;
+ __u16 pads;
+ __u16 links;
+
+ __u32 reserved[4];
+
+ union {
+ /* Node specifications */
+ struct {
+ __u32 major;
+ __u32 minor;
+ } v4l;
+ struct {
+ __u32 major;
+ __u32 minor;
+ } fb;
+ int alsa;
+ int dvb;
+
+ /* Sub-device specifications */
+ /* Nothing needed yet */
+ __u8 raw[64];
+ };
+};
Should this be a packed struct?
Why ? :-) Packed struct are most useful when they need to match hardware
structures or network protocols. Packing a structure can generate unaligned
fields, which are bad performance-wise.
--
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: [RFC/PATCH v4 07/11] media: Entities, pads and links enumeration
On Friday, August 20, 2010 17:29:09 Laurent Pinchart wrote:
Create the following two ioctls and implement them at the media device
level to enumerate entities, pads and links.
- MEDIA_IOC_ENUM_ENTITIES: Enumerate entities and their properties
- MEDIA_IOC_ENUM_LINKS: Enumerate all pads and links for a given entity
Entity IDs can be non-contiguous. Userspace applications should
enumerate entities using the MEDIA_ENTITY_ID_FLAG_NEXT flag. When the
flag is set in the entity ID, the MEDIA_IOC_ENUM_ENTITIES will return
the next entity with an ID bigger than the requested one.
Only forward links that originate at one of the entity's source pads are
returned during the enumeration process.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Signed-off-by: Sakari Ailus sakari.ai...@maxwell.research.nokia.com
---
Documentation/media-framework.txt | 142
-
drivers/media/media-device.c | 123
include/linux/media.h | 81 +
include/media/media-entity.h | 24 +--
4 files changed, 346 insertions(+), 24 deletions(-)
diff --git a/Documentation/media-framework.txt
b/Documentation/media-framework.txt
index 66f7f6c..74a137d 100644
--- a/Documentation/media-framework.txt
+++ b/Documentation/media-framework.txt
@@ -320,7 +320,7 @@ Userspace application API
-
Media devices offer an API to userspace application to query device
information
-through ioctls.
+and discover the device internal topology through ioctls.
MEDIA_IOC_DEVICE_INFO - Get device information
--
@@ -357,3 +357,143 @@ instances of otherwise identical hardware. The serial
number takes precedence
when provided and can be assumed to be unique. If the serial number is an
empty string, the bus_info field can be used instead. The bus_info field is
guaranteed to be unique, but can vary across reboots or device unplug/replug.
+
+
+ MEDIA_IOC_ENUM_ENTITIES - Enumerate entities and their properties
+ -
+
+ ioctl(int fd, int request, struct media_entity_desc *argp);
+
+To query the attributes of an entity, applications set the id field of a
+media_entity_desc structure and call the MEDIA_IOC_ENUM_ENTITIES ioctl with a
+pointer to this structure. The driver fills the rest of the structure or
+returns a EINVAL error code when the id is invalid.
+
+Entities can be enumerated by or'ing the id with the
MEDIA_ENTITY_ID_FLAG_NEXT
+flag. The driver will return information about the entity with the smallest
id
+strictly larger than the requested one ('next entity'), or EINVAL if there is
+none.
+
+Entity IDs can be non-contiguous. Applications must *not* try to enumerate
+entities by calling MEDIA_IOC_ENUM_ENTITIES with increasing id's until they
+get an error.
+
+Two or more entities that share a common non-zero group_id value are
+considered as logically grouped. Groups are used to report
+
+ - ALSA, VBI and video nodes that carry the same media stream
+ - lens and flash controllers associated with a sensor
+
+The media_entity_desc structure is defined as
+
+- struct media_entity_desc
+
+__u32id Entity id, set by the application. When the id
is
+ or'ed with MEDIA_ENTITY_ID_FLAG_NEXT, the driver
+ clears the flag and returns the first entity with a
+ larger id.
+char name[32]Entity name. UTF-8 NULL-terminated string.
Why UTF-8 instead of ASCII?
+__u32typeEntity type.
+__u32revisionEntity revision in a driver/hardware specific
format.
+__u32flags Entity flags.
+__u32group_idEntity group ID.
+__u16padsNumber of pads.
+__u16links Total number of outbound links. Inbound links
are not
+ counted in this field.
+/* union */
+ /* struct v4l, Valid for V4L sub-devices and nodes only */
+__u32major V4L device node major number. For V4L
sub-devices with
+ no device node, set by the driver to 0.
+__u32minor V4L device node minor number. For V4L
sub-devices with
+ no device node, set by the driver to 0.
+ /* struct fb, Valid for frame buffer nodes only */
+__u32major FB device node major number
+__u32minor FB device node minor number
+ /* Valid for ALSA devices only */
+int alsaALSA card number
+ /* Valid for DVB devices only */
+int dvb DVB card number
+
+Valid entity types are
+
+ MEDIA_ENTITY_TYPE_NODE - Unknown device node
+ MEDIA_ENTITY_TYPE_NODE_V4L - V4L video, radio or vbi device node
[RFC/PATCH v4 07/11] media: Entities, pads and links enumeration
Create the following two ioctls and implement them at the media device
level to enumerate entities, pads and links.
- MEDIA_IOC_ENUM_ENTITIES: Enumerate entities and their properties
- MEDIA_IOC_ENUM_LINKS: Enumerate all pads and links for a given entity
Entity IDs can be non-contiguous. Userspace applications should
enumerate entities using the MEDIA_ENTITY_ID_FLAG_NEXT flag. When the
flag is set in the entity ID, the MEDIA_IOC_ENUM_ENTITIES will return
the next entity with an ID bigger than the requested one.
Only forward links that originate at one of the entity's source pads are
returned during the enumeration process.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Signed-off-by: Sakari Ailus sakari.ai...@maxwell.research.nokia.com
---
Documentation/media-framework.txt | 142 -
drivers/media/media-device.c | 123
include/linux/media.h | 81 +
include/media/media-entity.h | 24 +--
4 files changed, 346 insertions(+), 24 deletions(-)
diff --git a/Documentation/media-framework.txt
b/Documentation/media-framework.txt
index 66f7f6c..74a137d 100644
--- a/Documentation/media-framework.txt
+++ b/Documentation/media-framework.txt
@@ -320,7 +320,7 @@ Userspace application API
-
Media devices offer an API to userspace application to query device information
-through ioctls.
+and discover the device internal topology through ioctls.
MEDIA_IOC_DEVICE_INFO - Get device information
--
@@ -357,3 +357,143 @@ instances of otherwise identical hardware. The serial
number takes precedence
when provided and can be assumed to be unique. If the serial number is an
empty string, the bus_info field can be used instead. The bus_info field is
guaranteed to be unique, but can vary across reboots or device unplug/replug.
+
+
+ MEDIA_IOC_ENUM_ENTITIES - Enumerate entities and their properties
+ -
+
+ ioctl(int fd, int request, struct media_entity_desc *argp);
+
+To query the attributes of an entity, applications set the id field of a
+media_entity_desc structure and call the MEDIA_IOC_ENUM_ENTITIES ioctl with a
+pointer to this structure. The driver fills the rest of the structure or
+returns a EINVAL error code when the id is invalid.
+
+Entities can be enumerated by or'ing the id with the MEDIA_ENTITY_ID_FLAG_NEXT
+flag. The driver will return information about the entity with the smallest id
+strictly larger than the requested one ('next entity'), or EINVAL if there is
+none.
+
+Entity IDs can be non-contiguous. Applications must *not* try to enumerate
+entities by calling MEDIA_IOC_ENUM_ENTITIES with increasing id's until they
+get an error.
+
+Two or more entities that share a common non-zero group_id value are
+considered as logically grouped. Groups are used to report
+
+ - ALSA, VBI and video nodes that carry the same media stream
+ - lens and flash controllers associated with a sensor
+
+The media_entity_desc structure is defined as
+
+- struct media_entity_desc
+
+__u32 id Entity id, set by the application. When the id is
+ or'ed with MEDIA_ENTITY_ID_FLAG_NEXT, the driver
+ clears the flag and returns the first entity with a
+ larger id.
+char name[32]Entity name. UTF-8 NULL-terminated string.
+__u32 typeEntity type.
+__u32 revisionEntity revision in a driver/hardware specific format.
+__u32 flags Entity flags.
+__u32 group_idEntity group ID.
+__u16 padsNumber of pads.
+__u16 links Total number of outbound links. Inbound links are not
+ counted in this field.
+/* union */
+ /* struct v4l, Valid for V4L sub-devices and nodes only */
+__u32 major V4L device node major number. For V4L sub-devices with
+ no device node, set by the driver to 0.
+__u32 minor V4L device node minor number. For V4L sub-devices with
+ no device node, set by the driver to 0.
+ /* struct fb, Valid for frame buffer nodes only */
+__u32 major FB device node major number
+__u32 minor FB device node minor number
+ /* Valid for ALSA devices only */
+intalsaALSA card number
+ /* Valid for DVB devices only */
+intdvb DVB card number
+
+Valid entity types are
+
+ MEDIA_ENTITY_TYPE_NODE - Unknown device node
+ MEDIA_ENTITY_TYPE_NODE_V4L - V4L video, radio or vbi device node
+ MEDIA_ENTITY_TYPE_NODE_FB - Frame buffer device node
+ MEDIA_ENTITY_TYPE_NODE_ALSA - ALSA card
+ MEDIA_ENTITY_TYPE_NODE_DVB - DVB card
+
+ MEDIA_ENTITY_TYPE_SUBDEV - Unknown V4L sub-device
+
