From: Sakari Ailus <sakari.ailus@maxwell.research.nokia.com>
To: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: linux-media@vger.kernel.org, Hans Verkuil <hverkuil@xs4all.nl>
Subject: Re: [RFC/PATCH v2 06/10] media: Entities, pads and links enumeration
Date: Thu, 22 Jul 2010 18:10:01 +0300 [thread overview]
Message-ID: <4C485F49.2000703@maxwell.research.nokia.com> (raw)
In-Reply-To: <1279722935-28493-7-git-send-email-laurent.pinchart@ideasonboard.com>
Heippa,
What a nice patch! :-)
Laurent Pinchart wrote:
...
> diff --git a/Documentation/media-framework.txt b/Documentation/media-framework.txt
> index 3acc62b..16c0177 100644
> --- a/Documentation/media-framework.txt
> +++ b/Documentation/media-framework.txt
> @@ -270,3 +270,137 @@ required, drivers don't need to provide a set_power operation. The operation
> is allowed to fail when turning power on, in which case the media_entity_get
> function will return NULL.
>
> +
> +Userspace application API
> +-------------------------
> +
> +Media devices offer an API to userspace application to discover the device
> +internal topology through ioctls.
> +
> + MEDIA_IOC_ENUM_ENTITIES - Enumerate entities and their properties
> + -----------------------------------------------------------------
> +
> + ioctl(int fd, int request, struct media_user_entity *argp);
> +
> +To query the attributes of an entity, applications set the id field of a
> +media_user_entity 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.
> +
> +The media_user_entity structure is defined as
> +
> +- struct media_user_entity
> +
> +__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 type Entity type.
> +__u32 subtype Entity subtype.
> +__u8 pads Number of pads.
> +__u32 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 */
> +int alsa ALSA card number
> + /* Valid for DVB devices only */
> +int dvb DVB card number
> +
> +Valid entity types are
> +
> + MEDIA_ENTITY_TYPE_NODE - V4L, FB, ALSA or DVB device
> + MEDIA_ENTITY_TYPE_SUBDEV - V4L sub-device
> +
> +For MEDIA_ENTITY_TYPE_NODE entities, valid entity subtypes are
> +
> + MEDIA_ENTITY_SUBTYPE_NODE_V4L - V4L video, radio or vbi device node
> + MEDIA_ENTITY_SUBTYPE_NODE_FB - Frame buffer device node
> + MEDIA_ENTITY_SUBTYPE_NODE_ALSA - ALSA card
> + MEDIA_ENTITY_SUBTYPE_NODE_DVB - DVB card
> +
> +For MEDIA_ENTITY_TYPE_SUBDEV entities, valid entity subtypes are
> +
> + MEDIA_ENTITY_SUBTYPE_SUBDEV_VID_DECODER - Video decoder
> + MEDIA_ENTITY_SUBTYPE_SUBDEV_VID_ENCODER - Video encoder
> + MEDIA_ENTITY_SUBTYPE_SUBDEV_MISC - Unspecified entity subtype
> +
> +
> + MEDIA_IOC_ENUM_LINKS - Enumerate all pads and links for a given entity
> + ----------------------------------------------------------------------
> +
> + ioctl(int fd, int request, struct media_user_links *argp);
> +
> +Only forward links that originate at one of the entity's source pads are
> +returned during the enumeration process.
> +
> +To enumerate pads and/or links for a given entity, applications set the entity
> +field of a media_user_links structure and initialize the media_user_pad and
> +media_user_link structure arrays pointed by the pads and links fields. They
> +then call the MEDIA_IOC_ENUM_LINKS ioctl with a pointer to this structure.
> +
> +If the pads field is not NULL, the driver fills the pads array with
> +information about the entity's pads. The array must have enough room to store
> +all the entity's pads. The number of pads can be retrieved with the
> +MEDIA_IOC_ENUM_ENTITIES ioctl.
> +
> +If the links field is not NULL, the driver fills the links array with
> +information about the entity's outbound links. The array must have enough room
> +to store all the entity's outbound links. The number of outbound links can be
> +retrieved with the MEDIA_IOC_ENUM_ENTITIES ioctl.
> +
> +The media_user_pad, media_user_link and media_user_links structure are defined
> +as
I have a comment on naming. These are user space structures, sure, but
do we want that fact to be visible in the names of the structures? I
would just drop the user_ out and make the naming as good as possible in
user space. That is much harder to change later than naming inside the
kernel.
That change causes a lot of clashes in naming since the equivalent
kernel structure is there as well. Those could have _k postfix, for
example, to differentiate them from user space names. I don't really
have a good suggestion how they should be called.
> +- struct media_user_pad
> +
> +__u32 entity ID of the entity this pad belongs to.
> +__8 index 0-based pad index.
It's possible that 8 bits is enough (I think Hans commented this
already). The compiler will use 4 bytes in any case and I think it's a
good practice not to create holes in the structures, especially not to
the interface ones.
The OMAP 4 has a tiler, could it be that this kind of functionality
might introduce large numbers of pads in the future?
> +__u32 direction Pad direction.
> +
> +Valid pad directions are
> +
> + MEDIA_PAD_DIR_INPUT - Input pad, relative to the entity. Input pads
> + sink data and are targets of links.
> + MEDIA_PAD_DIR_OUTPUT - Output pad, relative to the entity. Output
> + pads source data and are origins of links.
> +
> +- struct media_user_link
> +
> +struct media_user_pad source Pad at the origin of this link.
> +struct media_user_pad sink Pad at the target of this link.
> +__u32 flags Link flags.
> +
> +Valid link flags are
> +
> + MEDIA_LINK_FLAG_ACTIVE - The link is active and can be used to
> + transfer media data. When two or more links target a sink pad,
> + only one of them can be active at a time.
> + MEDIA_LINK_FLAG_IMMUTABLE - The link active state can't be modified at
> + runtime. An immutable link is always active.
> +
> +- struct media_user_links
> +
> +__u32 entity Entity id, set by the application.
> +struct media_user_pad *pads Pointer to a pads array allocated by the
> + application. Ignored if NULL.
> +struct media_user_link *links Pointer to a links array allocated by the
> + application. Ignored if NULL.
> +
Regards,
--
Sakari Ailus
sakari.ailus@maxwell.research.nokia.com
next prev parent reply other threads:[~2010-07-22 15:10 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-07-21 14:35 [RFC/PATCH v2 00/10] Media controller (core and V4L2) Laurent Pinchart
2010-07-21 14:35 ` [RFC/PATCH v2 01/10] media: Media device node support Laurent Pinchart
2010-07-24 11:59 ` Hans Verkuil
2010-07-26 9:07 ` Laurent Pinchart
2010-07-26 16:19 ` Laurent Pinchart
2010-07-21 14:35 ` [RFC/PATCH v2 02/10] media: Media device Laurent Pinchart
2010-07-24 12:02 ` Hans Verkuil
2010-07-26 9:08 ` Laurent Pinchart
2010-07-26 14:44 ` Sakari Ailus
2010-07-21 14:35 ` [RFC/PATCH v2 03/10] media: Entities, pads and links Laurent Pinchart
2010-07-24 12:18 ` Hans Verkuil
2010-07-26 16:38 ` Laurent Pinchart
2010-07-26 16:57 ` Sakari Ailus
2010-07-26 19:51 ` Hans Verkuil
2010-07-21 14:35 ` [RFC/PATCH v2 04/10] media: Entity graph traversal Laurent Pinchart
2010-07-21 14:35 ` [RFC/PATCH v2 05/10] media: Reference count and power handling Laurent Pinchart
2010-07-21 14:35 ` [RFC/PATCH v2 06/10] media: Entities, pads and links enumeration Laurent Pinchart
2010-07-22 15:10 ` Sakari Ailus [this message]
2010-07-22 15:20 ` Laurent Pinchart
2010-07-22 16:29 ` Sakari Ailus
2010-07-22 16:36 ` Pete Eberlein
2010-07-26 16:30 ` Laurent Pinchart
2010-07-22 15:26 ` Sakari Ailus
2010-07-22 15:33 ` Laurent Pinchart
2010-07-22 17:30 ` Sakari Ailus
2010-07-26 16:31 ` Laurent Pinchart
2010-07-24 12:45 ` Hans Verkuil
2010-07-26 16:34 ` Laurent Pinchart
2010-07-26 19:48 ` Hans Verkuil
2010-07-27 9:30 ` Laurent Pinchart
2010-07-21 14:35 ` [RFC/PATCH v2 07/10] media: Links setup Laurent Pinchart
2010-07-21 14:35 ` [RFC/PATCH v2 08/10] v4l: Add a media_device pointer to the v4l2_device structure Laurent Pinchart
2010-07-21 14:35 ` [RFC/PATCH v2 09/10] v4l: Make video_device inherit from media_entity Laurent Pinchart
2010-07-21 14:35 ` [RFC/PATCH v2 10/10] v4l: Make v4l2_subdev " Laurent Pinchart
2010-07-21 14:41 ` [SAMPLE v2 00/12] Further V4L2 API additions and OMAP3 ISP driver Laurent Pinchart
2010-07-21 14:41 ` [SAMPLE v2 01/12] v4l: Move the media/v4l2-mediabus.h header to include/linux Laurent Pinchart
2010-07-21 14:41 ` [SAMPLE v2 02/12] v4l: Add 16 bit YUYV and SGRBG10 media bus format codes Laurent Pinchart
2010-07-21 14:41 ` [SAMPLE v2 03/12] v4l: Create v4l2 subdev file handle structure Laurent Pinchart
2010-07-21 14:41 ` [SAMPLE v2 04/12] v4l-subdev: Add pads operations Laurent Pinchart
2010-07-23 15:56 ` Karicheri, Muralidharan
2010-07-26 16:12 ` Laurent Pinchart
2010-07-26 16:19 ` Karicheri, Muralidharan
2010-07-26 16:39 ` Laurent Pinchart
2010-07-26 19:42 ` Hans Verkuil
2010-07-26 19:46 ` Laurent Pinchart
2010-07-21 14:41 ` [SAMPLE v2 05/12] v4l: v4l2_subdev userspace format API Laurent Pinchart
2010-07-21 14:41 ` [SAMPLE v2 06/12] v4l: Add subdev userspace API to enumerate and configure frame interval Laurent Pinchart
2010-07-21 14:41 ` [SAMPLE v2 07/12] v4l: Add crop ioctl to V4L2 subdev API Laurent Pinchart
2010-07-21 14:41 ` [SAMPLE v2 08/12] v4l: subdev: Generic ioctl support Laurent Pinchart
2010-07-21 14:41 ` [SAMPLE v2 09/12] ARM: OMAP3: Update Camera ISP definitions for OMAP3630 Laurent Pinchart
2010-07-21 14:41 ` [SAMPLE v2 10/12] omap3: Export omap3isp platform device structure Laurent Pinchart
2010-07-21 14:41 ` [SAMPLE v2 11/12] omap34xxcam: Register the ISP platform device during omap34xxcam probe Laurent Pinchart
2010-07-21 14:43 ` [SAMPLE 12/12] OMAP3 ISP driver Laurent Pinchart
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4C485F49.2000703@maxwell.research.nokia.com \
--to=sakari.ailus@maxwell.research.nokia.com \
--cc=hverkuil@xs4all.nl \
--cc=laurent.pinchart@ideasonboard.com \
--cc=linux-media@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox