On Monday 26 July 2010 18:34:42 Laurent Pinchart wrote:
> Hi Hans,
> 
> On Saturday 24 July 2010 14:45:39 Hans Verkuil wrote:
> > On Wednesday 21 July 2010 16:35:31 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 |  134
> > >  ++++++++++++++++++++++++++++++++ drivers/media/media-device.c      | 
> > >  153 +++++++++++++++++++++++++++++++++++++ include/linux/media.h        
> > >      |   73 ++++++++++++++++++
> > >  include/media/media-device.h      |    3 +
> > >  include/media/media-entity.h      |   19 +-----
> > >  5 files changed, 364 insertions(+), 18 deletions(-)
> > >  create mode 100644 include/linux/media.h
> > 
> > <snip>
> > 
> > > diff --git a/include/linux/media.h b/include/linux/media.h
> > > new file mode 100644
> > > index 0000000..746bdda
> > > --- /dev/null
> > > +++ b/include/linux/media.h
> > > @@ -0,0 +1,73 @@
> > > +#ifndef __LINUX_MEDIA_H
> > > +#define __LINUX_MEDIA_H
> > > +
> > > +#define MEDIA_ENTITY_TYPE_NODE                           1
> > > +#define MEDIA_ENTITY_TYPE_SUBDEV                 2
> > > +
> > > +#define MEDIA_ENTITY_SUBTYPE_NODE_V4L                    1
> > > +#define MEDIA_ENTITY_SUBTYPE_NODE_FB                     2
> > > +#define MEDIA_ENTITY_SUBTYPE_NODE_ALSA                   3
> > > +#define MEDIA_ENTITY_SUBTYPE_NODE_DVB                    4
> > > +
> > > +#define MEDIA_ENTITY_SUBTYPE_SUBDEV_VID_DECODER          1
> > > +#define MEDIA_ENTITY_SUBTYPE_SUBDEV_VID_ENCODER          2
> > > +#define MEDIA_ENTITY_SUBTYPE_SUBDEV_MISC         3
> > > +
> > > +#define MEDIA_PAD_DIR_INPUT                              1
> > > +#define MEDIA_PAD_DIR_OUTPUT                             2
> > > +
> > > +#define MEDIA_LINK_FLAG_ACTIVE                           (1 << 0)
> > > +#define MEDIA_LINK_FLAG_IMMUTABLE                        (1 << 1)
> > > +
> > > +#define MEDIA_ENTITY_ID_FLAG_NEXT        (1 << 31)
> > > +
> > > +struct media_user_pad {
> > > + __u32 entity;           /* entity ID */
> > > + __u8 index;             /* pad index */
> > > + __u32 direction;        /* pad direction */
> > > +};
> > 
> > How about:
> > 
> > struct media_pad {
> >     __u32 entity;           /* entity ID */
> >     __u16 index;            /* pad index */
> >     __u16 flags;            /* pad flags (includes direction) */
> 
> Just to be sure, I suppose I should combine flags + direction in the 
> media_k_pad structure as well, right ?

Yes. I think we should just make a u32 flags, use bits 0 and 1 for the direction
and add a simple inline like this:

static inline u8 media_dir(struct media_pad *pad)
{
        return pad->flags & MEDIA_PAD_MASK_DIR);
}

And we should use the same for media_k_pad (and make a media_k_dir inline).

> 
> >     u32 reserved;
> > };
> 
> OK.
> 
> > I think u16 for the number of pads might be safer than a u8.
> 
> it should definitely be enough, otherwise we'll have a big issue anyway.

Is u8 definitely enough or u16? I assume u16.

<snip>

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

Reply via email to