Re: [RFC/PATCH v2 03/10] media: Entities, pads and links

2010-07-26 Thread Laurent Pinchart
Hi Hans,

On Saturday 24 July 2010 14:18:11 Hans Verkuil wrote:
 On Wednesday 21 July 2010 16:35:28 Laurent Pinchart wrote:
 
 snip
 
  diff --git a/include/media/media-entity.h b/include/media/media-entity.h
  new file mode 100644
  index 000..fd44647
  --- /dev/null
  +++ b/include/media/media-entity.h
  @@ -0,0 +1,79 @@
  +#ifndef _MEDIA_ENTITY_H
  +#define _MEDIA_ENTITY_H
  +
  +#include linux/list.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_DECODER1
  +#define MEDIA_ENTITY_SUBTYPE_SUBDEV_VID_ENCODER2
  +#define MEDIA_ENTITY_SUBTYPE_SUBDEV_MISC   3
 
 These names are too awkward.
 
 I see two options:
 
 1) Rename the type field to 'entity' and the macros to
 MEDIA_ENTITY_NODE/SUBDEV. Also rename subtype to type and the macros to
 MEDIA_ENTITY_TYPE_NODE_V4L and MEDIA_ENTITY_TYPE_SUBDEV_VID_DECODER. We
 might even get away with dropping _TYPE from the macro name.
 
 2) Merge type and subtype to a single entity field. The top 16 bits are the
 entity type, the bottom 16 bits are the subtype. That way you end up with:
 
 #define MEDIA_ENTITY_NODE (1  16)
 #define MEDIA_ENTITY_SUBDEV   (2  16)
 
 #define MEDIA_ENTITY_NODE_V4L (MEDIA_ENTITY_NODE + 1)
 
 #define MEDIA_ENTITY_SUBDEV_VID_DECODER   (MEDIA_ENTITY_SUBDEV + 
 1)
 
 I rather like this option myself.

I like option 2 better, but I would keep the field name type instead of 
entity. Constants could start with MEDIA_ENTITY_TYPE_, or just MEDIA_ENTITY_ 
(I think I would prefer MEDIA_ENTITY_TYPE_).

  +
  +#define MEDIA_LINK_FLAG_ACTIVE (1  0)
  +#define MEDIA_LINK_FLAG_IMMUTABLE  (1  1)
  +
  +#define MEDIA_PAD_DIR_INPUT1
  +#define MEDIA_PAD_DIR_OUTPUT   2
  +
  +struct media_entity_link {
  +   struct media_entity_pad *source;/* Source pad */
  +   struct media_entity_pad *sink;  /* Sink pad  */
  +   struct media_entity_link *other;/* Link in the reverse direction */
  +   u32 flags;  /* Link flags (MEDIA_LINK_FLAG_*) */
  +};
  +
  +struct media_entity_pad {
  +   struct media_entity *entity;/* Entity this pad belongs to */
  +   u32 direction;  /* Pad direction (MEDIA_PAD_DIR_*) */
  +   u8 index;   /* Pad index in the entity pads array */
 
 We can use bitfields for direction and index. That way we can also easily
 add other flags/attributes.

You proposed to merge the direction field into a new flags field, I suppose 
that should be done here too for consistency. Having 16 flags might be a bit 
low though, 32 would be better. If you want to keep 16 bits for now, maybe we 
should have 2 reserved __u32 instead of one.

  +};
  +

-- 
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 v2 03/10] media: Entities, pads and links

2010-07-26 Thread Hans Verkuil
On Monday 26 July 2010 18:38:28 Laurent Pinchart wrote:
 Hi Hans,
 
 On Saturday 24 July 2010 14:18:11 Hans Verkuil wrote:
  On Wednesday 21 July 2010 16:35:28 Laurent Pinchart wrote:
  
  snip
  
   diff --git a/include/media/media-entity.h b/include/media/media-entity.h
   new file mode 100644
   index 000..fd44647
   --- /dev/null
   +++ b/include/media/media-entity.h
   @@ -0,0 +1,79 @@
   +#ifndef _MEDIA_ENTITY_H
   +#define _MEDIA_ENTITY_H
   +
   +#include linux/list.h
   +
   +#define MEDIA_ENTITY_TYPE_NODE   1
   +#define MEDIA_ENTITY_TYPE_SUBDEV 2
   +
   +#define MEDIA_ENTITY_SUBTYPE_NODE_V4L1
   +#define MEDIA_ENTITY_SUBTYPE_NODE_FB 2
   +#define MEDIA_ENTITY_SUBTYPE_NODE_ALSA   3
   +#define MEDIA_ENTITY_SUBTYPE_NODE_DVB4
   +
   +#define MEDIA_ENTITY_SUBTYPE_SUBDEV_VID_DECODER  1
   +#define MEDIA_ENTITY_SUBTYPE_SUBDEV_VID_ENCODER  2
   +#define MEDIA_ENTITY_SUBTYPE_SUBDEV_MISC 3
  
  These names are too awkward.
  
  I see two options:
  
  1) Rename the type field to 'entity' and the macros to
  MEDIA_ENTITY_NODE/SUBDEV. Also rename subtype to type and the macros to
  MEDIA_ENTITY_TYPE_NODE_V4L and MEDIA_ENTITY_TYPE_SUBDEV_VID_DECODER. We
  might even get away with dropping _TYPE from the macro name.
  
  2) Merge type and subtype to a single entity field. The top 16 bits are the
  entity type, the bottom 16 bits are the subtype. That way you end up with:
  
  #define MEDIA_ENTITY_NODE   (1  16)
  #define MEDIA_ENTITY_SUBDEV (2  16)
  
  #define MEDIA_ENTITY_NODE_V4L   (MEDIA_ENTITY_NODE + 1)
  
  #define MEDIA_ENTITY_SUBDEV_VID_DECODER (MEDIA_ENTITY_SUBDEV + 
  1)
  
  I rather like this option myself.
 
 I like option 2 better, but I would keep the field name type instead of 
 entity. Constants could start with MEDIA_ENTITY_TYPE_, or just 
 MEDIA_ENTITY_ 
 (I think I would prefer MEDIA_ENTITY_TYPE_).

Yes, I realized that later as well. Keep the 'type' field name.
I'm not sure about the macro name. I still think 
MEDIA_ENTITY_TYPE_SUBDEV_VID_DECODER
is too much of a mouthful.

 
   +
   +#define MEDIA_LINK_FLAG_ACTIVE   (1  0)
   +#define MEDIA_LINK_FLAG_IMMUTABLE(1  1)
   +
   +#define MEDIA_PAD_DIR_INPUT  1
   +#define MEDIA_PAD_DIR_OUTPUT 2
   +
   +struct media_entity_link {
   + struct media_entity_pad *source;/* Source pad */
   + struct media_entity_pad *sink;  /* Sink pad  */
   + struct media_entity_link *other;/* Link in the reverse direction */
   + u32 flags;  /* Link flags (MEDIA_LINK_FLAG_*) */
   +};
   +
   +struct media_entity_pad {
   + struct media_entity *entity;/* Entity this pad belongs to */
   + u32 direction;  /* Pad direction (MEDIA_PAD_DIR_*) */
   + u8 index;   /* Pad index in the entity pads array */
  
  We can use bitfields for direction and index. That way we can also easily
  add other flags/attributes.
 
 You proposed to merge the direction field into a new flags field, I suppose 
 that should be done here too for consistency. Having 16 flags might be a bit 
 low though, 32 would be better. If you want to keep 16 bits for now, maybe we 
 should have 2 reserved __u32 instead of one.

Yes, let's use a u32 flags field for this.

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 v2 03/10] media: Entities, pads and links

2010-07-24 Thread Hans Verkuil
On Wednesday 21 July 2010 16:35:28 Laurent Pinchart wrote:

snip

 diff --git a/include/media/media-entity.h b/include/media/media-entity.h
 new file mode 100644
 index 000..fd44647
 --- /dev/null
 +++ b/include/media/media-entity.h
 @@ -0,0 +1,79 @@
 +#ifndef _MEDIA_ENTITY_H
 +#define _MEDIA_ENTITY_H
 +
 +#include linux/list.h
 +
 +#define MEDIA_ENTITY_TYPE_NODE   1
 +#define MEDIA_ENTITY_TYPE_SUBDEV 2
 +
 +#define MEDIA_ENTITY_SUBTYPE_NODE_V4L1
 +#define MEDIA_ENTITY_SUBTYPE_NODE_FB 2
 +#define MEDIA_ENTITY_SUBTYPE_NODE_ALSA   3
 +#define MEDIA_ENTITY_SUBTYPE_NODE_DVB4
 +
 +#define MEDIA_ENTITY_SUBTYPE_SUBDEV_VID_DECODER  1
 +#define MEDIA_ENTITY_SUBTYPE_SUBDEV_VID_ENCODER  2
 +#define MEDIA_ENTITY_SUBTYPE_SUBDEV_MISC 3

These names are too awkward.

I see two options:

1) Rename the type field to 'entity' and the macros to MEDIA_ENTITY_NODE/SUBDEV.
   Also rename subtype to type and the macros to MEDIA_ENTITY_TYPE_NODE_V4L
   and MEDIA_ENTITY_TYPE_SUBDEV_VID_DECODER. We might even get away with 
dropping
   _TYPE from the macro name.

2) Merge type and subtype to a single entity field. The top 16 bits are the 
entity
   type, the bottom 16 bits are the subtype. That way you end up with:

#define MEDIA_ENTITY_NODE   (1  16)
#define MEDIA_ENTITY_SUBDEV (2  16)

#define MEDIA_ENTITY_NODE_V4L   (MEDIA_ENTITY_NODE + 1)

#define MEDIA_ENTITY_SUBDEV_VID_DECODER (MEDIA_ENTITY_SUBDEV + 1)

I rather like this option myself.

 +
 +#define MEDIA_LINK_FLAG_ACTIVE   (1  0)
 +#define MEDIA_LINK_FLAG_IMMUTABLE(1  1)
 +
 +#define MEDIA_PAD_DIR_INPUT  1
 +#define MEDIA_PAD_DIR_OUTPUT 2
 +
 +struct media_entity_link {
 + struct media_entity_pad *source;/* Source pad */
 + struct media_entity_pad *sink;  /* Sink pad  */
 + struct media_entity_link *other;/* Link in the reverse direction */
 + u32 flags;  /* Link flags (MEDIA_LINK_FLAG_*) */
 +};
 +
 +struct media_entity_pad {
 + struct media_entity *entity;/* Entity this pad belongs to */
 + u32 direction;  /* Pad direction (MEDIA_PAD_DIR_*) */
 + u8 index;   /* Pad index in the entity pads array */

We can use bitfields for direction and index. That way we can also easily add
other flags/attributes.

 +};
 +
 +struct media_entity {
 + struct list_head list;
 + struct media_device *parent;/* Media device this entity belongs to*/
 + u32 id; /* Entity ID, unique in the parent media
 +  * device context */
 + const char *name;   /* Entity name */
 + u32 type;   /* Entity type (MEDIA_ENTITY_TYPE_*) */
 + u32 subtype;/* Entity subtype (type-specific) */
 +
 + u8 num_pads;/* Number of input and output pads */
 + u8 num_links;   /* Number of existing links, both active
 +  * and inactive */
 + u8 num_backlinks;   /* Number of backlinks */
 + u8 max_links;   /* Maximum number of links */
 +
 + struct media_entity_pad *pads;  /* Array of pads (num_pads elements) */
 + struct media_entity_link *links;/* Array of links (max_links elements)*/
 +
 + 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 */
 + };
 +};
 +
 +int media_entity_init(struct media_entity *entity, u8 num_pads,
 + struct media_entity_pad *pads, u8 extra_links);
 +void media_entity_cleanup(struct media_entity *entity);
 +int media_entity_create_link(struct media_entity *source, u8 source_pad,
 + struct media_entity *sink, u8 sink_pad, u32 flags);
 +
 +#endif
 

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


[RFC/PATCH v2 03/10] media: Entities, pads and links

2010-07-21 Thread Laurent Pinchart
As video hardware pipelines become increasingly complex and
configurable, the current hardware description through v4l2 subdevices
reaches its limits. In addition to enumerating and configuring
subdevices, video camera drivers need a way to discover and modify at
runtime how those subdevices are connected. This is done through new
elements called entities, pads and links.

An entity is a basic media hardware building block. It can correspond to
a large variety of logical blocks such as physical hardware devices
(CMOS sensor for instance), logical hardware devices (a building block
in a System-on-Chip image processing pipeline), DMA channels or physical
connectors.

A pad is a connection endpoint through which an entity can interact with
other entities. Data (not restricted to video) produced by an entity
flows from the entity's output to one or more entity inputs. Pads should
not be confused with physical pins at chip boundaries.

A link is a point-to-point oriented connection between two pads, either
on the same entity or on different entities. Data flows from a source
pad to a sink pad.

Links are stored in the source entity. To make backwards graph walk
faster, a copy of all links is also stored in the sink entity. The copy
is known as a backlink and is only used to help graph traversal.

The entity API is made of three functions:

- media_entity_init() initializes an entity. The caller must provide an
array of pads as well as an estimated number of links. The links array
is allocated dynamically and will be reallocated if it grows beyond the
initial estimate.

- media_entity_cleanup() frees resources allocated for an entity. It
must be called during the cleanup phase after unregistering the entity
and before freeing it.

- media_entity_create_link() creates a link between two entities. An
entry in the link array of each entity is allocated and stores pointers
to source and sink pads.

When a media device is unregistered, all its entities are unregistered
automatically.

The code is based on Hans Verkuil hverk...@xs4all.nl initial work.

Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Signed-off-by: Sakari Ailus sakari.ai...@maxwell.research.nokia.com
---
 Documentation/media-framework.txt |  127 
 drivers/media/Makefile|2 +-
 drivers/media/media-device.c  |   53 ++
 drivers/media/media-entity.c  |  145 +
 include/media/media-device.h  |   16 
 include/media/media-entity.h  |   79 
 6 files changed, 421 insertions(+), 1 deletions(-)
 create mode 100644 drivers/media/media-entity.c
 create mode 100644 include/media/media-entity.h

diff --git a/Documentation/media-framework.txt 
b/Documentation/media-framework.txt
index b942c8f..1c8779c 100644
--- a/Documentation/media-framework.txt
+++ b/Documentation/media-framework.txt
@@ -35,6 +35,30 @@ belong to userspace.
 The media kernel API aims at solving those problems.
 
 
+Abstract media device model
+---
+
+Discovering a device internal topology, and configuring it at runtime, is one
+of the goals of the media framework. To achieve this, hardware devices are
+modeled as an oriented graph of building blocks called entities connected
+through pads.
+
+An entity is a basic media hardware building block. It can correspond to
+a large variety of logical blocks such as physical hardware devices
+(CMOS sensor for instance), logical hardware devices (a building block
+in a System-on-Chip image processing pipeline), DMA channels or physical
+connectors.
+
+A pad is a connection endpoint through which an entity can interact with
+other entities. Data (not restricted to video) produced by an entity
+flows from the entity's output to one or more entity inputs. Pads should
+not be confused with physical pins at chip boundaries.
+
+A link is a point-to-point oriented connection between two pads, either
+on the same entity or on different entities. Data flows from a source
+pad to a sink pad.
+
+
 Media device
 
 
@@ -66,3 +90,106 @@ Drivers unregister media device instances by calling
 
 Unregistering a media device that hasn't been registered is *NOT* safe.
 
+
+Entities, pads and links
+
+
+- Entities
+
+Entities are represented by a struct media_entity instance, defined in
+include/media/media-entity.h. The structure is usually embedded into a
+higher-level structure, such as a v4l2_subdev or video_device instance,
+although drivers can allocate entities directly.
+
+Drivers initialize entities by calling
+
+   media_entity_init(struct media_entity *entity, u8 num_pads,
+ struct media_entity_pad *pads, u8 extra_links);
+
+The media_entity name, type and subtype fields can be initialized before or
+after calling media_entity_init. Entities embedded in higher-level standard
+structures have those fields set by the higher-level