public inbox for linux-media@vger.kernel.org
 help / color / mirror / Atom feed
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

  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