[PATCH 02/18] media controller: deprecate entity subtype

[PATCH 02/18] media controller: deprecate entity subtype

[Mauro Carvalho Chehab]

The media controller entity subtype doesn't make much sense,
especially since V4L2 subdevices may also have associated devnodes.

So, better to get rid of it while it is not too late.

We need, of course, to keep the old symbols to avoid userspace
breakage, but we should avoid using them internally at the
Kernel.

Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>

diff --git a/include/uapi/linux/media.h b/include/uapi/linux/media.h
index 4e816be3de39..775c11c6b173 100644
--- a/include/uapi/linux/media.h
+++ b/include/uapi/linux/media.h
@@ -42,31 +42,45 @@ struct media_device_info {
 
 #define MEDIA_ENT_ID_FLAG_NEXT		(1 << 31)
 
+/* Used values for media_entity_desc::type */
+
+#define MEDIA_ENT_T_DEVNODE_V4L		(((1 << 16)) + 1)
+#define MEDIA_ENT_T_DEVNODE_DVB_FE	(MEDIA_ENT_T_DEVNODE_V4L + 3)
+#define MEDIA_ENT_T_DEVNODE_DVB_DEMUX	(MEDIA_ENT_T_DEVNODE_V4L + 4)
+#define MEDIA_ENT_T_DEVNODE_DVB_DVR	(MEDIA_ENT_T_DEVNODE_V4L + 5)
+#define MEDIA_ENT_T_DEVNODE_DVB_CA	(MEDIA_ENT_T_DEVNODE_V4L + 6)
+#define MEDIA_ENT_T_DEVNODE_DVB_NET	(MEDIA_ENT_T_DEVNODE_V4L + 7)
+
+#define MEDIA_ENT_T_V4L2_SUBDEV_SENSOR	((2 << 16) + 1)
+#define MEDIA_ENT_T_V4L2_SUBDEV_FLASH	(MEDIA_ENT_T_V4L2_SUBDEV_SENSOR + 1)
+#define MEDIA_ENT_T_V4L2_SUBDEV_LENS	(MEDIA_ENT_T_V4L2_SUBDEV_SENSOR + 2)
+/* A converter of analogue video to its digital representation. */
+#define MEDIA_ENT_T_V4L2_SUBDEV_DECODER	(MEDIA_ENT_T_V4L2_SUBDEV_SENSOR + 3)
+
+#define MEDIA_ENT_T_V4L2_SUBDEV_TUNER	(MEDIA_ENT_T_V4L2_SUBDEV_SENSOR + 4)
+
+#if 1
+/*
+ * Legacy symbols.
+ * Kept just to avoid userspace compilation breakages.
+ * One day, the symbols bellow will be removed
+ */
+
 #define MEDIA_ENT_TYPE_SHIFT		16
 #define MEDIA_ENT_TYPE_MASK		0x00ff0000
 #define MEDIA_ENT_SUBTYPE_MASK		0x0000ffff
 
 #define MEDIA_ENT_T_DEVNODE		(1 << MEDIA_ENT_TYPE_SHIFT)
-#define MEDIA_ENT_T_DEVNODE_V4L		(MEDIA_ENT_T_DEVNODE + 1)
+#define MEDIA_ENT_T_V4L2_SUBDEV		(2 << MEDIA_ENT_TYPE_SHIFT)
+
 #define MEDIA_ENT_T_DEVNODE_FB		(MEDIA_ENT_T_DEVNODE + 2)
 #define MEDIA_ENT_T_DEVNODE_ALSA	(MEDIA_ENT_T_DEVNODE + 3)
-#define MEDIA_ENT_T_DEVNODE_DVB_FE	(MEDIA_ENT_T_DEVNODE + 4)
-#define MEDIA_ENT_T_DEVNODE_DVB_DEMUX	(MEDIA_ENT_T_DEVNODE + 5)
-#define MEDIA_ENT_T_DEVNODE_DVB_DVR	(MEDIA_ENT_T_DEVNODE + 6)
-#define MEDIA_ENT_T_DEVNODE_DVB_CA	(MEDIA_ENT_T_DEVNODE + 7)
-#define MEDIA_ENT_T_DEVNODE_DVB_NET	(MEDIA_ENT_T_DEVNODE + 8)
 
-/* Legacy symbol. Use it to avoid userspace compilation breakages */
+
 #define MEDIA_ENT_T_DEVNODE_DVB		MEDIA_ENT_T_DEVNODE_DVB_FE
+#endif
 
-#define MEDIA_ENT_T_V4L2_SUBDEV		(2 << MEDIA_ENT_TYPE_SHIFT)
-#define MEDIA_ENT_T_V4L2_SUBDEV_SENSOR	(MEDIA_ENT_T_V4L2_SUBDEV + 1)
-#define MEDIA_ENT_T_V4L2_SUBDEV_FLASH	(MEDIA_ENT_T_V4L2_SUBDEV + 2)
-#define MEDIA_ENT_T_V4L2_SUBDEV_LENS	(MEDIA_ENT_T_V4L2_SUBDEV + 3)
-/* A converter of analogue video to its digital representation. */
-#define MEDIA_ENT_T_V4L2_SUBDEV_DECODER	(MEDIA_ENT_T_V4L2_SUBDEV + 4)
-
-#define MEDIA_ENT_T_V4L2_SUBDEV_TUNER	(MEDIA_ENT_T_V4L2_SUBDEV + 5)
+/* Used bitmasks for media_entity_desc::flags */
 
 #define MEDIA_ENT_FL_DEFAULT		(1 << 0)
 
-- 
2.1.0

Re: [PATCH 02/18] media controller: deprecate entity subtype

[Hans Verkuil]

Hi Mauro,

Just a typo, after that you can add my:

Acked-by: Hans Verkuil <hans.verkuil-FYB4Gu1CFyUAvxtiuMwx3w@public.gmane.org>

Thanks,

	Hans

On 05/08/2015 03:12 AM, Mauro Carvalho Chehab wrote:
> The media controller entity subtype doesn't make much sense,
> especially since V4L2 subdevices may also have associated devnodes.
> 
> So, better to get rid of it while it is not too late.
> 
> We need, of course, to keep the old symbols to avoid userspace
> breakage, but we should avoid using them internally at the
> Kernel.
> 
> Signed-off-by: Mauro Carvalho Chehab <mchehab-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org>
> 
> diff --git a/include/uapi/linux/media.h b/include/uapi/linux/media.h
> index 4e816be3de39..775c11c6b173 100644
> --- a/include/uapi/linux/media.h
> +++ b/include/uapi/linux/media.h
> @@ -42,31 +42,45 @@ struct media_device_info {
>  
>  #define MEDIA_ENT_ID_FLAG_NEXT		(1 << 31)
>  
> +/* Used values for media_entity_desc::type */
> +
> +#define MEDIA_ENT_T_DEVNODE_V4L		(((1 << 16)) + 1)
> +#define MEDIA_ENT_T_DEVNODE_DVB_FE	(MEDIA_ENT_T_DEVNODE_V4L + 3)
> +#define MEDIA_ENT_T_DEVNODE_DVB_DEMUX	(MEDIA_ENT_T_DEVNODE_V4L + 4)
> +#define MEDIA_ENT_T_DEVNODE_DVB_DVR	(MEDIA_ENT_T_DEVNODE_V4L + 5)
> +#define MEDIA_ENT_T_DEVNODE_DVB_CA	(MEDIA_ENT_T_DEVNODE_V4L + 6)
> +#define MEDIA_ENT_T_DEVNODE_DVB_NET	(MEDIA_ENT_T_DEVNODE_V4L + 7)
> +
> +#define MEDIA_ENT_T_V4L2_SUBDEV_SENSOR	((2 << 16) + 1)
> +#define MEDIA_ENT_T_V4L2_SUBDEV_FLASH	(MEDIA_ENT_T_V4L2_SUBDEV_SENSOR + 1)
> +#define MEDIA_ENT_T_V4L2_SUBDEV_LENS	(MEDIA_ENT_T_V4L2_SUBDEV_SENSOR + 2)
> +/* A converter of analogue video to its digital representation. */
> +#define MEDIA_ENT_T_V4L2_SUBDEV_DECODER	(MEDIA_ENT_T_V4L2_SUBDEV_SENSOR + 3)
> +
> +#define MEDIA_ENT_T_V4L2_SUBDEV_TUNER	(MEDIA_ENT_T_V4L2_SUBDEV_SENSOR + 4)
> +
> +#if 1
> +/*
> + * Legacy symbols.
> + * Kept just to avoid userspace compilation breakages.
> + * One day, the symbols bellow will be removed

bellow -> below

> + */
> +
>  #define MEDIA_ENT_TYPE_SHIFT		16
>  #define MEDIA_ENT_TYPE_MASK		0x00ff0000
>  #define MEDIA_ENT_SUBTYPE_MASK		0x0000ffff
>  
>  #define MEDIA_ENT_T_DEVNODE		(1 << MEDIA_ENT_TYPE_SHIFT)
> -#define MEDIA_ENT_T_DEVNODE_V4L		(MEDIA_ENT_T_DEVNODE + 1)
> +#define MEDIA_ENT_T_V4L2_SUBDEV		(2 << MEDIA_ENT_TYPE_SHIFT)
> +
>  #define MEDIA_ENT_T_DEVNODE_FB		(MEDIA_ENT_T_DEVNODE + 2)
>  #define MEDIA_ENT_T_DEVNODE_ALSA	(MEDIA_ENT_T_DEVNODE + 3)
> -#define MEDIA_ENT_T_DEVNODE_DVB_FE	(MEDIA_ENT_T_DEVNODE + 4)
> -#define MEDIA_ENT_T_DEVNODE_DVB_DEMUX	(MEDIA_ENT_T_DEVNODE + 5)
> -#define MEDIA_ENT_T_DEVNODE_DVB_DVR	(MEDIA_ENT_T_DEVNODE + 6)
> -#define MEDIA_ENT_T_DEVNODE_DVB_CA	(MEDIA_ENT_T_DEVNODE + 7)
> -#define MEDIA_ENT_T_DEVNODE_DVB_NET	(MEDIA_ENT_T_DEVNODE + 8)
>  
> -/* Legacy symbol. Use it to avoid userspace compilation breakages */
> +
>  #define MEDIA_ENT_T_DEVNODE_DVB		MEDIA_ENT_T_DEVNODE_DVB_FE
> +#endif
>  
> -#define MEDIA_ENT_T_V4L2_SUBDEV		(2 << MEDIA_ENT_TYPE_SHIFT)
> -#define MEDIA_ENT_T_V4L2_SUBDEV_SENSOR	(MEDIA_ENT_T_V4L2_SUBDEV + 1)
> -#define MEDIA_ENT_T_V4L2_SUBDEV_FLASH	(MEDIA_ENT_T_V4L2_SUBDEV + 2)
> -#define MEDIA_ENT_T_V4L2_SUBDEV_LENS	(MEDIA_ENT_T_V4L2_SUBDEV + 3)
> -/* A converter of analogue video to its digital representation. */
> -#define MEDIA_ENT_T_V4L2_SUBDEV_DECODER	(MEDIA_ENT_T_V4L2_SUBDEV + 4)
> -
> -#define MEDIA_ENT_T_V4L2_SUBDEV_TUNER	(MEDIA_ENT_T_V4L2_SUBDEV + 5)
> +/* Used bitmasks for media_entity_desc::flags */
>  
>  #define MEDIA_ENT_FL_DEFAULT		(1 << 0)
>  
> 

[PATCH 04/18] media controller: Rename camera entities

[Mauro Carvalho Chehab]

As explained before, the hole idea of subtypes at entities was
not nice. All V4L2 subdevs may have a device node associated.

Also, the hole idea is to expose hardware IP blocks, so calling
them as V4L2 is a very bad practice, as they were not designed
for the V4L2 API. It is just the reverse.

So, instead of using V4L2_SUBDEV, let's call the camera sub-
devices with CAM, instead:

	MEDIA_ENT_T_V4L2_SUBDEV_SENSOR -> MEDIA_ENT_T_CAM_SENSOR
	MEDIA_ENT_T_V4L2_SUBDEV_FLASH  -> MEDIA_ENT_T_CAM_FLASH
	MEDIA_ENT_T_V4L2_SUBDEV_LENS   -> MEDIA_ENT_T_CAM_LENS

Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>

diff --git a/Documentation/DocBook/media/v4l/media-ioc-enum-entities.xml b/Documentation/DocBook/media/v4l/media-ioc-enum-entities.xml
index 5b8147629159..759604e3529f 100644
--- a/Documentation/DocBook/media/v4l/media-ioc-enum-entities.xml
+++ b/Documentation/DocBook/media/v4l/media-ioc-enum-entities.xml
@@ -219,15 +219,15 @@
 	    <entry>Unknown V4L sub-device</entry>
 	  </row>
 	  <row>
-	    <entry><constant>MEDIA_ENT_T_V4L2_SUBDEV_SENSOR</constant></entry>
+	    <entry><constant>MEDIA_ENT_T_CAM_SENSOR</constant></entry>
 	    <entry>Video sensor</entry>
 	  </row>
 	  <row>
-	    <entry><constant>MEDIA_ENT_T_V4L2_SUBDEV_FLASH</constant></entry>
+	    <entry><constant>MEDIA_ENT_T_CAM_FLASH</constant></entry>
 	    <entry>Flash controller</entry>
 	  </row>
 	  <row>
-	    <entry><constant>MEDIA_ENT_T_V4L2_SUBDEV_LENS</constant></entry>
+	    <entry><constant>MEDIA_ENT_T_CAM_LENS</constant></entry>
 	    <entry>Lens controller</entry>
 	  </row>
 	  <row>
diff --git a/drivers/media/i2c/adp1653.c b/drivers/media/i2c/adp1653.c
index c70ababce954..c12f873a8e26 100644
--- a/drivers/media/i2c/adp1653.c
+++ b/drivers/media/i2c/adp1653.c
@@ -516,7 +516,7 @@ static int adp1653_probe(struct i2c_client *client,
 	if (ret < 0)
 		goto free_and_quit;
 
-	flash->subdev.entity.type = MEDIA_ENT_T_V4L2_SUBDEV_FLASH;
+	flash->subdev.entity.type = MEDIA_ENT_T_CAM_FLASH;
 
 	return 0;
 
diff --git a/drivers/media/i2c/as3645a.c b/drivers/media/i2c/as3645a.c
index 301084b07887..9a2872be11b0 100644
--- a/drivers/media/i2c/as3645a.c
+++ b/drivers/media/i2c/as3645a.c
@@ -831,7 +831,7 @@ static int as3645a_probe(struct i2c_client *client,
 	if (ret < 0)
 		goto done;
 
-	flash->subdev.entity.type = MEDIA_ENT_T_V4L2_SUBDEV_FLASH;
+	flash->subdev.entity.type = MEDIA_ENT_T_CAM_FLASH;
 
 	mutex_init(&flash->power_lock);
 
diff --git a/drivers/media/i2c/lm3560.c b/drivers/media/i2c/lm3560.c
index d9ece4b2d047..4d28cda77f4d 100644
--- a/drivers/media/i2c/lm3560.c
+++ b/drivers/media/i2c/lm3560.c
@@ -368,7 +368,7 @@ static int lm3560_subdev_init(struct lm3560_flash *flash,
 	rval = media_entity_init(&flash->subdev_led[led_no].entity, 0, NULL, 0);
 	if (rval < 0)
 		goto err_out;
-	flash->subdev_led[led_no].entity.type = MEDIA_ENT_T_V4L2_SUBDEV_FLASH;
+	flash->subdev_led[led_no].entity.type = MEDIA_ENT_T_CAM_FLASH;
 
 	return rval;
 
diff --git a/drivers/media/i2c/lm3646.c b/drivers/media/i2c/lm3646.c
index 626fb4679c02..19ee2ac00be7 100644
--- a/drivers/media/i2c/lm3646.c
+++ b/drivers/media/i2c/lm3646.c
@@ -285,7 +285,7 @@ static int lm3646_subdev_init(struct lm3646_flash *flash)
 	rval = media_entity_init(&flash->subdev_led.entity, 0, NULL, 0);
 	if (rval < 0)
 		goto err_out;
-	flash->subdev_led.entity.type = MEDIA_ENT_T_V4L2_SUBDEV_FLASH;
+	flash->subdev_led.entity.type = MEDIA_ENT_T_CAM_FLASH;
 	return rval;
 
 err_out:
diff --git a/drivers/media/i2c/m5mols/m5mols_core.c b/drivers/media/i2c/m5mols/m5mols_core.c
index 6404c0d93e7a..beb519cf8be4 100644
--- a/drivers/media/i2c/m5mols/m5mols_core.c
+++ b/drivers/media/i2c/m5mols/m5mols_core.c
@@ -978,7 +978,7 @@ static int m5mols_probe(struct i2c_client *client,
 	ret = media_entity_init(&sd->entity, 1, &info->pad, 0);
 	if (ret < 0)
 		return ret;
-	sd->entity.type = MEDIA_ENT_T_V4L2_SUBDEV_SENSOR;
+	sd->entity.type = MEDIA_ENT_T_CAM_SENSOR;
 
 	init_waitqueue_head(&info->irq_waitq);
 	mutex_init(&info->lock);
diff --git a/drivers/media/i2c/noon010pc30.c b/drivers/media/i2c/noon010pc30.c
index f197b6cbd407..a03556197405 100644
--- a/drivers/media/i2c/noon010pc30.c
+++ b/drivers/media/i2c/noon010pc30.c
@@ -779,7 +779,7 @@ static int noon010_probe(struct i2c_client *client,
 		goto np_err;
 
 	info->pad.flags = MEDIA_PAD_FL_SOURCE;
-	sd->entity.type = MEDIA_ENT_T_V4L2_SUBDEV_SENSOR;
+	sd->entity.type = MEDIA_ENT_T_CAM_SENSOR;
 	ret = media_entity_init(&sd->entity, 1, &info->pad, 0);
 	if (ret < 0)
 		goto np_err;
diff --git a/drivers/media/i2c/ov2659.c b/drivers/media/i2c/ov2659.c
index d700a1d0a6f2..63b9464e813f 100644
--- a/drivers/media/i2c/ov2659.c
+++ b/drivers/media/i2c/ov2659.c
@@ -1425,7 +1425,7 @@ static int ov2659_probe(struct i2c_client *client,
 
 #if defined(CONFIG_MEDIA_CONTROLLER)
 	ov2659->pad.flags = MEDIA_PAD_FL_SOURCE;
-	sd->entity.type = MEDIA_ENT_T_V4L2_SUBDEV_SENSOR;
+	sd->entity.type = MEDIA_ENT_T_CAM_SENSOR;
 	ret = media_entity_init(&sd->entity, 1, &ov2659->pad, 0);
 	if (ret < 0) {
 		v4l2_ctrl_handler_free(&ov2659->ctrls);
diff --git a/drivers/media/i2c/ov9650.c b/drivers/media/i2c/ov9650.c
index 2bc473385c91..ed3c0573a0f8 100644
--- a/drivers/media/i2c/ov9650.c
+++ b/drivers/media/i2c/ov9650.c
@@ -1500,7 +1500,7 @@ static int ov965x_probe(struct i2c_client *client,
 		return ret;
 
 	ov965x->pad.flags = MEDIA_PAD_FL_SOURCE;
-	sd->entity.type = MEDIA_ENT_T_V4L2_SUBDEV_SENSOR;
+	sd->entity.type = MEDIA_ENT_T_CAM_SENSOR;
 	ret = media_entity_init(&sd->entity, 1, &ov965x->pad, 0);
 	if (ret < 0)
 		return ret;
diff --git a/drivers/media/i2c/s5k4ecgx.c b/drivers/media/i2c/s5k4ecgx.c
index 97084237275d..23af7f90678a 100644
--- a/drivers/media/i2c/s5k4ecgx.c
+++ b/drivers/media/i2c/s5k4ecgx.c
@@ -961,7 +961,7 @@ static int s5k4ecgx_probe(struct i2c_client *client,
 	sd->flags |= V4L2_SUBDEV_FL_HAS_DEVNODE;
 
 	priv->pad.flags = MEDIA_PAD_FL_SOURCE;
-	sd->entity.type = MEDIA_ENT_T_V4L2_SUBDEV_SENSOR;
+	sd->entity.type = MEDIA_ENT_T_CAM_SENSOR;
 	ret = media_entity_init(&sd->entity, 1, &priv->pad, 0);
 	if (ret)
 		return ret;
diff --git a/drivers/media/i2c/s5k5baf.c b/drivers/media/i2c/s5k5baf.c
index bee73de347dc..fadd48d35a55 100644
--- a/drivers/media/i2c/s5k5baf.c
+++ b/drivers/media/i2c/s5k5baf.c
@@ -408,7 +408,7 @@ static inline struct v4l2_subdev *ctrl_to_sd(struct v4l2_ctrl *ctrl)
 
 static inline bool s5k5baf_is_cis_subdev(struct v4l2_subdev *sd)
 {
-	return sd->entity.type == MEDIA_ENT_T_V4L2_SUBDEV_SENSOR;
+	return sd->entity.type == MEDIA_ENT_T_CAM_SENSOR;
 }
 
 static inline struct s5k5baf *to_s5k5baf(struct v4l2_subdev *sd)
@@ -1904,7 +1904,7 @@ static int s5k5baf_configure_subdevs(struct s5k5baf *state,
 	sd->flags |= V4L2_SUBDEV_FL_HAS_DEVNODE;
 
 	state->cis_pad.flags = MEDIA_PAD_FL_SOURCE;
-	sd->entity.type = MEDIA_ENT_T_V4L2_SUBDEV_SENSOR;
+	sd->entity.type = MEDIA_ENT_T_CAM_SENSOR;
 	ret = media_entity_init(&sd->entity, NUM_CIS_PADS, &state->cis_pad, 0);
 	if (ret < 0)
 		goto err;
diff --git a/drivers/media/i2c/s5k6aa.c b/drivers/media/i2c/s5k6aa.c
index d0ad6a25bdab..d2390c6e5dbe 100644
--- a/drivers/media/i2c/s5k6aa.c
+++ b/drivers/media/i2c/s5k6aa.c
@@ -1577,7 +1577,7 @@ static int s5k6aa_probe(struct i2c_client *client,
 	sd->flags |= V4L2_SUBDEV_FL_HAS_DEVNODE;
 
 	s5k6aa->pad.flags = MEDIA_PAD_FL_SOURCE;
-	sd->entity.type = MEDIA_ENT_T_V4L2_SUBDEV_SENSOR;
+	sd->entity.type = MEDIA_ENT_T_CAM_SENSOR;
 	ret = media_entity_init(&sd->entity, 1, &s5k6aa->pad, 0);
 	if (ret)
 		return ret;
diff --git a/drivers/media/i2c/smiapp/smiapp-core.c b/drivers/media/i2c/smiapp/smiapp-core.c
index 636ebd6fe5dc..78f2cdd3561b 100644
--- a/drivers/media/i2c/smiapp/smiapp-core.c
+++ b/drivers/media/i2c/smiapp/smiapp-core.c
@@ -2763,7 +2763,7 @@ static int smiapp_init(struct smiapp_sensor *sensor)
 
 	dev_dbg(&client->dev, "profile %d\n", sensor->minfo.smiapp_profile);
 
-	sensor->pixel_array->sd.entity.type = MEDIA_ENT_T_V4L2_SUBDEV_SENSOR;
+	sensor->pixel_array->sd.entity.type = MEDIA_ENT_T_CAM_SENSOR;
 
 	/* final steps */
 	smiapp_read_frame_fmt(sensor);
diff --git a/include/uapi/linux/media.h b/include/uapi/linux/media.h
index a7aa2aac9c23..2e465ba087ba 100644
--- a/include/uapi/linux/media.h
+++ b/include/uapi/linux/media.h
@@ -51,13 +51,13 @@ struct media_device_info {
 #define MEDIA_ENT_T_DEVNODE_DVB_CA	(MEDIA_ENT_T_AV_DMA + 6)
 #define MEDIA_ENT_T_DEVNODE_DVB_NET	(MEDIA_ENT_T_AV_DMA + 7)
 
-#define MEDIA_ENT_T_V4L2_SUBDEV_SENSOR	((2 << 16) + 1)
-#define MEDIA_ENT_T_V4L2_SUBDEV_FLASH	(MEDIA_ENT_T_V4L2_SUBDEV_SENSOR + 1)
-#define MEDIA_ENT_T_V4L2_SUBDEV_LENS	(MEDIA_ENT_T_V4L2_SUBDEV_SENSOR + 2)
+#define MEDIA_ENT_T_CAM_SENSOR	((2 << 16) + 1)
+#define MEDIA_ENT_T_CAM_FLASH	(MEDIA_ENT_T_CAM_SENSOR + 1)
+#define MEDIA_ENT_T_CAM_LENS	(MEDIA_ENT_T_CAM_SENSOR + 2)
 /* A converter of analogue video to its digital representation. */
-#define MEDIA_ENT_T_V4L2_SUBDEV_DECODER	(MEDIA_ENT_T_V4L2_SUBDEV_SENSOR + 3)
+#define MEDIA_ENT_T_V4L2_SUBDEV_DECODER	(MEDIA_ENT_T_CAM_SENSOR + 3)
 
-#define MEDIA_ENT_T_V4L2_SUBDEV_TUNER	(MEDIA_ENT_T_V4L2_SUBDEV_SENSOR + 4)
+#define MEDIA_ENT_T_V4L2_SUBDEV_TUNER	(MEDIA_ENT_T_CAM_SENSOR + 4)
 
 #if 1
 /*
@@ -76,8 +76,10 @@ struct media_device_info {
 #define MEDIA_ENT_T_DEVNODE_FB		(MEDIA_ENT_T_DEVNODE + 2)
 #define MEDIA_ENT_T_DEVNODE_ALSA	(MEDIA_ENT_T_DEVNODE + 3)
 
-
 #define MEDIA_ENT_T_DEVNODE_DVB		MEDIA_ENT_T_DEVNODE_DVB_FE
+#define MEDIA_ENT_T_V4L2_SUBDEV_SENSOR	MEDIA_ENT_T_CAM_SENSOR
+#define MEDIA_ENT_T_V4L2_SUBDEV_FLASH	MEDIA_ENT_T_CAM_FLASH
+#define MEDIA_ENT_T_V4L2_SUBDEV_LENS	MEDIA_ENT_T_CAM_LENS
 #endif
 
 /* Used bitmasks for media_entity_desc::flags */
-- 
2.1.0

Re: [PATCH 04/18] media controller: Rename camera entities

[Hans Verkuil]

On 05/08/2015 03:12 AM, Mauro Carvalho Chehab wrote:
> As explained before, the hole idea of subtypes at entities was

hole -> whole

> not nice. All V4L2 subdevs may have a device node associated.
> 
> Also, the hole idea is to expose hardware IP blocks, so calling
> them as V4L2 is a very bad practice, as they were not designed
> for the V4L2 API. It is just the reverse.
> 
> So, instead of using V4L2_SUBDEV, let's call the camera sub-
> devices with CAM, instead:
> 
> 	MEDIA_ENT_T_V4L2_SUBDEV_SENSOR -> MEDIA_ENT_T_CAM_SENSOR
> 	MEDIA_ENT_T_V4L2_SUBDEV_FLASH  -> MEDIA_ENT_T_CAM_FLASH
> 	MEDIA_ENT_T_V4L2_SUBDEV_LENS   -> MEDIA_ENT_T_CAM_LENS

I would actually postpone this until Laurent has a properties API ready.
These entity types are fatally flawed since an entity can combine functions
in one. E.g. an i2c device (generally represented as a single entity) might
provide for both sensor and flash. Or combine tuner and video decoder, etc.

Basically an entity like this is a sub-device (as in the literal meaning
of being a part of a larger device) that has one or more functions and may
have device node(s) associated with it. That is best expressed as properties.

And you really do have to tell userspace that these entities expose a
v4l-subdev device node. Renaming them doesn't make that go away.

Regards,

	Hans

> 
> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
> 
> diff --git a/Documentation/DocBook/media/v4l/media-ioc-enum-entities.xml b/Documentation/DocBook/media/v4l/media-ioc-enum-entities.xml
> index 5b8147629159..759604e3529f 100644
> --- a/Documentation/DocBook/media/v4l/media-ioc-enum-entities.xml
> +++ b/Documentation/DocBook/media/v4l/media-ioc-enum-entities.xml
> @@ -219,15 +219,15 @@
>  	    <entry>Unknown V4L sub-device</entry>
>  	  </row>
>  	  <row>
> -	    <entry><constant>MEDIA_ENT_T_V4L2_SUBDEV_SENSOR</constant></entry>
> +	    <entry><constant>MEDIA_ENT_T_CAM_SENSOR</constant></entry>
>  	    <entry>Video sensor</entry>
>  	  </row>
>  	  <row>
> -	    <entry><constant>MEDIA_ENT_T_V4L2_SUBDEV_FLASH</constant></entry>
> +	    <entry><constant>MEDIA_ENT_T_CAM_FLASH</constant></entry>
>  	    <entry>Flash controller</entry>
>  	  </row>
>  	  <row>
> -	    <entry><constant>MEDIA_ENT_T_V4L2_SUBDEV_LENS</constant></entry>
> +	    <entry><constant>MEDIA_ENT_T_CAM_LENS</constant></entry>
>  	    <entry>Lens controller</entry>
>  	  </row>
>  	  <row>
> diff --git a/drivers/media/i2c/adp1653.c b/drivers/media/i2c/adp1653.c
> index c70ababce954..c12f873a8e26 100644
> --- a/drivers/media/i2c/adp1653.c
> +++ b/drivers/media/i2c/adp1653.c
> @@ -516,7 +516,7 @@ static int adp1653_probe(struct i2c_client *client,
>  	if (ret < 0)
>  		goto free_and_quit;
>  
> -	flash->subdev.entity.type = MEDIA_ENT_T_V4L2_SUBDEV_FLASH;
> +	flash->subdev.entity.type = MEDIA_ENT_T_CAM_FLASH;
>  
>  	return 0;
>  
> diff --git a/drivers/media/i2c/as3645a.c b/drivers/media/i2c/as3645a.c
> index 301084b07887..9a2872be11b0 100644
> --- a/drivers/media/i2c/as3645a.c
> +++ b/drivers/media/i2c/as3645a.c
> @@ -831,7 +831,7 @@ static int as3645a_probe(struct i2c_client *client,
>  	if (ret < 0)
>  		goto done;
>  
> -	flash->subdev.entity.type = MEDIA_ENT_T_V4L2_SUBDEV_FLASH;
> +	flash->subdev.entity.type = MEDIA_ENT_T_CAM_FLASH;
>  
>  	mutex_init(&flash->power_lock);
>  
> diff --git a/drivers/media/i2c/lm3560.c b/drivers/media/i2c/lm3560.c
> index d9ece4b2d047..4d28cda77f4d 100644
> --- a/drivers/media/i2c/lm3560.c
> +++ b/drivers/media/i2c/lm3560.c
> @@ -368,7 +368,7 @@ static int lm3560_subdev_init(struct lm3560_flash *flash,
>  	rval = media_entity_init(&flash->subdev_led[led_no].entity, 0, NULL, 0);
>  	if (rval < 0)
>  		goto err_out;
> -	flash->subdev_led[led_no].entity.type = MEDIA_ENT_T_V4L2_SUBDEV_FLASH;
> +	flash->subdev_led[led_no].entity.type = MEDIA_ENT_T_CAM_FLASH;
>  
>  	return rval;
>  
> diff --git a/drivers/media/i2c/lm3646.c b/drivers/media/i2c/lm3646.c
> index 626fb4679c02..19ee2ac00be7 100644
> --- a/drivers/media/i2c/lm3646.c
> +++ b/drivers/media/i2c/lm3646.c
> @@ -285,7 +285,7 @@ static int lm3646_subdev_init(struct lm3646_flash *flash)
>  	rval = media_entity_init(&flash->subdev_led.entity, 0, NULL, 0);
>  	if (rval < 0)
>  		goto err_out;
> -	flash->subdev_led.entity.type = MEDIA_ENT_T_V4L2_SUBDEV_FLASH;
> +	flash->subdev_led.entity.type = MEDIA_ENT_T_CAM_FLASH;
>  	return rval;
>  
>  err_out:
> diff --git a/drivers/media/i2c/m5mols/m5mols_core.c b/drivers/media/i2c/m5mols/m5mols_core.c
> index 6404c0d93e7a..beb519cf8be4 100644
> --- a/drivers/media/i2c/m5mols/m5mols_core.c
> +++ b/drivers/media/i2c/m5mols/m5mols_core.c
> @@ -978,7 +978,7 @@ static int m5mols_probe(struct i2c_client *client,
>  	ret = media_entity_init(&sd->entity, 1, &info->pad, 0);
>  	if (ret < 0)
>  		return ret;
> -	sd->entity.type = MEDIA_ENT_T_V4L2_SUBDEV_SENSOR;
> +	sd->entity.type = MEDIA_ENT_T_CAM_SENSOR;
>  
>  	init_waitqueue_head(&info->irq_waitq);
>  	mutex_init(&info->lock);
> diff --git a/drivers/media/i2c/noon010pc30.c b/drivers/media/i2c/noon010pc30.c
> index f197b6cbd407..a03556197405 100644
> --- a/drivers/media/i2c/noon010pc30.c
> +++ b/drivers/media/i2c/noon010pc30.c
> @@ -779,7 +779,7 @@ static int noon010_probe(struct i2c_client *client,
>  		goto np_err;
>  
>  	info->pad.flags = MEDIA_PAD_FL_SOURCE;
> -	sd->entity.type = MEDIA_ENT_T_V4L2_SUBDEV_SENSOR;
> +	sd->entity.type = MEDIA_ENT_T_CAM_SENSOR;
>  	ret = media_entity_init(&sd->entity, 1, &info->pad, 0);
>  	if (ret < 0)
>  		goto np_err;
> diff --git a/drivers/media/i2c/ov2659.c b/drivers/media/i2c/ov2659.c
> index d700a1d0a6f2..63b9464e813f 100644
> --- a/drivers/media/i2c/ov2659.c
> +++ b/drivers/media/i2c/ov2659.c
> @@ -1425,7 +1425,7 @@ static int ov2659_probe(struct i2c_client *client,
>  
>  #if defined(CONFIG_MEDIA_CONTROLLER)
>  	ov2659->pad.flags = MEDIA_PAD_FL_SOURCE;
> -	sd->entity.type = MEDIA_ENT_T_V4L2_SUBDEV_SENSOR;
> +	sd->entity.type = MEDIA_ENT_T_CAM_SENSOR;
>  	ret = media_entity_init(&sd->entity, 1, &ov2659->pad, 0);
>  	if (ret < 0) {
>  		v4l2_ctrl_handler_free(&ov2659->ctrls);
> diff --git a/drivers/media/i2c/ov9650.c b/drivers/media/i2c/ov9650.c
> index 2bc473385c91..ed3c0573a0f8 100644
> --- a/drivers/media/i2c/ov9650.c
> +++ b/drivers/media/i2c/ov9650.c
> @@ -1500,7 +1500,7 @@ static int ov965x_probe(struct i2c_client *client,
>  		return ret;
>  
>  	ov965x->pad.flags = MEDIA_PAD_FL_SOURCE;
> -	sd->entity.type = MEDIA_ENT_T_V4L2_SUBDEV_SENSOR;
> +	sd->entity.type = MEDIA_ENT_T_CAM_SENSOR;
>  	ret = media_entity_init(&sd->entity, 1, &ov965x->pad, 0);
>  	if (ret < 0)
>  		return ret;
> diff --git a/drivers/media/i2c/s5k4ecgx.c b/drivers/media/i2c/s5k4ecgx.c
> index 97084237275d..23af7f90678a 100644
> --- a/drivers/media/i2c/s5k4ecgx.c
> +++ b/drivers/media/i2c/s5k4ecgx.c
> @@ -961,7 +961,7 @@ static int s5k4ecgx_probe(struct i2c_client *client,
>  	sd->flags |= V4L2_SUBDEV_FL_HAS_DEVNODE;
>  
>  	priv->pad.flags = MEDIA_PAD_FL_SOURCE;
> -	sd->entity.type = MEDIA_ENT_T_V4L2_SUBDEV_SENSOR;
> +	sd->entity.type = MEDIA_ENT_T_CAM_SENSOR;
>  	ret = media_entity_init(&sd->entity, 1, &priv->pad, 0);
>  	if (ret)
>  		return ret;
> diff --git a/drivers/media/i2c/s5k5baf.c b/drivers/media/i2c/s5k5baf.c
> index bee73de347dc..fadd48d35a55 100644
> --- a/drivers/media/i2c/s5k5baf.c
> +++ b/drivers/media/i2c/s5k5baf.c
> @@ -408,7 +408,7 @@ static inline struct v4l2_subdev *ctrl_to_sd(struct v4l2_ctrl *ctrl)
>  
>  static inline bool s5k5baf_is_cis_subdev(struct v4l2_subdev *sd)
>  {
> -	return sd->entity.type == MEDIA_ENT_T_V4L2_SUBDEV_SENSOR;
> +	return sd->entity.type == MEDIA_ENT_T_CAM_SENSOR;
>  }
>  
>  static inline struct s5k5baf *to_s5k5baf(struct v4l2_subdev *sd)
> @@ -1904,7 +1904,7 @@ static int s5k5baf_configure_subdevs(struct s5k5baf *state,
>  	sd->flags |= V4L2_SUBDEV_FL_HAS_DEVNODE;
>  
>  	state->cis_pad.flags = MEDIA_PAD_FL_SOURCE;
> -	sd->entity.type = MEDIA_ENT_T_V4L2_SUBDEV_SENSOR;
> +	sd->entity.type = MEDIA_ENT_T_CAM_SENSOR;
>  	ret = media_entity_init(&sd->entity, NUM_CIS_PADS, &state->cis_pad, 0);
>  	if (ret < 0)
>  		goto err;
> diff --git a/drivers/media/i2c/s5k6aa.c b/drivers/media/i2c/s5k6aa.c
> index d0ad6a25bdab..d2390c6e5dbe 100644
> --- a/drivers/media/i2c/s5k6aa.c
> +++ b/drivers/media/i2c/s5k6aa.c
> @@ -1577,7 +1577,7 @@ static int s5k6aa_probe(struct i2c_client *client,
>  	sd->flags |= V4L2_SUBDEV_FL_HAS_DEVNODE;
>  
>  	s5k6aa->pad.flags = MEDIA_PAD_FL_SOURCE;
> -	sd->entity.type = MEDIA_ENT_T_V4L2_SUBDEV_SENSOR;
> +	sd->entity.type = MEDIA_ENT_T_CAM_SENSOR;
>  	ret = media_entity_init(&sd->entity, 1, &s5k6aa->pad, 0);
>  	if (ret)
>  		return ret;
> diff --git a/drivers/media/i2c/smiapp/smiapp-core.c b/drivers/media/i2c/smiapp/smiapp-core.c
> index 636ebd6fe5dc..78f2cdd3561b 100644
> --- a/drivers/media/i2c/smiapp/smiapp-core.c
> +++ b/drivers/media/i2c/smiapp/smiapp-core.c
> @@ -2763,7 +2763,7 @@ static int smiapp_init(struct smiapp_sensor *sensor)
>  
>  	dev_dbg(&client->dev, "profile %d\n", sensor->minfo.smiapp_profile);
>  
> -	sensor->pixel_array->sd.entity.type = MEDIA_ENT_T_V4L2_SUBDEV_SENSOR;
> +	sensor->pixel_array->sd.entity.type = MEDIA_ENT_T_CAM_SENSOR;
>  
>  	/* final steps */
>  	smiapp_read_frame_fmt(sensor);
> diff --git a/include/uapi/linux/media.h b/include/uapi/linux/media.h
> index a7aa2aac9c23..2e465ba087ba 100644
> --- a/include/uapi/linux/media.h
> +++ b/include/uapi/linux/media.h
> @@ -51,13 +51,13 @@ struct media_device_info {
>  #define MEDIA_ENT_T_DEVNODE_DVB_CA	(MEDIA_ENT_T_AV_DMA + 6)
>  #define MEDIA_ENT_T_DEVNODE_DVB_NET	(MEDIA_ENT_T_AV_DMA + 7)
>  
> -#define MEDIA_ENT_T_V4L2_SUBDEV_SENSOR	((2 << 16) + 1)
> -#define MEDIA_ENT_T_V4L2_SUBDEV_FLASH	(MEDIA_ENT_T_V4L2_SUBDEV_SENSOR + 1)
> -#define MEDIA_ENT_T_V4L2_SUBDEV_LENS	(MEDIA_ENT_T_V4L2_SUBDEV_SENSOR + 2)
> +#define MEDIA_ENT_T_CAM_SENSOR	((2 << 16) + 1)
> +#define MEDIA_ENT_T_CAM_FLASH	(MEDIA_ENT_T_CAM_SENSOR + 1)
> +#define MEDIA_ENT_T_CAM_LENS	(MEDIA_ENT_T_CAM_SENSOR + 2)
>  /* A converter of analogue video to its digital representation. */
> -#define MEDIA_ENT_T_V4L2_SUBDEV_DECODER	(MEDIA_ENT_T_V4L2_SUBDEV_SENSOR + 3)
> +#define MEDIA_ENT_T_V4L2_SUBDEV_DECODER	(MEDIA_ENT_T_CAM_SENSOR + 3)
>  
> -#define MEDIA_ENT_T_V4L2_SUBDEV_TUNER	(MEDIA_ENT_T_V4L2_SUBDEV_SENSOR + 4)
> +#define MEDIA_ENT_T_V4L2_SUBDEV_TUNER	(MEDIA_ENT_T_CAM_SENSOR + 4)
>  
>  #if 1
>  /*
> @@ -76,8 +76,10 @@ struct media_device_info {
>  #define MEDIA_ENT_T_DEVNODE_FB		(MEDIA_ENT_T_DEVNODE + 2)
>  #define MEDIA_ENT_T_DEVNODE_ALSA	(MEDIA_ENT_T_DEVNODE + 3)
>  
> -
>  #define MEDIA_ENT_T_DEVNODE_DVB		MEDIA_ENT_T_DEVNODE_DVB_FE
> +#define MEDIA_ENT_T_V4L2_SUBDEV_SENSOR	MEDIA_ENT_T_CAM_SENSOR
> +#define MEDIA_ENT_T_V4L2_SUBDEV_FLASH	MEDIA_ENT_T_CAM_FLASH
> +#define MEDIA_ENT_T_V4L2_SUBDEV_LENS	MEDIA_ENT_T_CAM_LENS
>  #endif
>  
>  /* Used bitmasks for media_entity_desc::flags */
> 

Re: [PATCH 04/18] media controller: Rename camera entities

[Mauro Carvalho Chehab]

Em Fri, 08 May 2015 14:03:01 +0200
Hans Verkuil <hverkuil@xs4all.nl> escreveu:

> On 05/08/2015 03:12 AM, Mauro Carvalho Chehab wrote:
> > As explained before, the hole idea of subtypes at entities was
> 
> hole -> whole
> 
> > not nice. All V4L2 subdevs may have a device node associated.
> > 
> > Also, the hole idea is to expose hardware IP blocks, so calling
> > them as V4L2 is a very bad practice, as they were not designed
> > for the V4L2 API. It is just the reverse.
> > 
> > So, instead of using V4L2_SUBDEV, let's call the camera sub-
> > devices with CAM, instead:
> > 
> > 	MEDIA_ENT_T_V4L2_SUBDEV_SENSOR -> MEDIA_ENT_T_CAM_SENSOR
> > 	MEDIA_ENT_T_V4L2_SUBDEV_FLASH  -> MEDIA_ENT_T_CAM_FLASH
> > 	MEDIA_ENT_T_V4L2_SUBDEV_LENS   -> MEDIA_ENT_T_CAM_LENS
> 
> I would actually postpone this until Laurent has a properties API ready.
> These entity types are fatally flawed since an entity can combine functions
> in one. E.g. an i2c device (generally represented as a single entity) might
> provide for both sensor and flash. Or combine tuner and video decoder, etc.

Mapping one I2C address as one entity is plain wrong.

It doesn't matter if a piece of hardware has just one I2C address or
multiple ones. There are tuners that have multiple I2C addresses. This is
actually common on some RDS tuners: they have one address for control, and
another one to transfer data from the tuned station. Still, it is just one
tuner.

There are also cases where there's no I2C address at all, but still
there are multiple entities.

Just enumerating a few examples of drivers I touched recently:

- au8522 - the same I2C address controls both V4L2 analod demod
	   and DVB demod;
- as102 - it is just a single chip, with tuner, demod and bridge on it.
	  no I2C buses internally at all.
- cx231xx - It has one internal I2C bus used to control different functions
	 inside the bridge chipset.

etc.


So, if a single piece of hardware has the functions of two entities
(sensor and flash), it should be represented as two separate entities.

The I2C bus would matter if we were mapping the control plane of the
entities, adding PADs for the control lines. But last time I checked,
Laurent was still strongly opposed to that.

> Basically an entity like this is a sub-device (as in the literal meaning
> of being a part of a larger device) that has one or more functions and may
> have device node(s) associated with it. That is best expressed as properties.
> 
> And you really do have to tell userspace that these entities expose a
> v4l-subdev device node. Renaming them doesn't make that go away.

Well, we should decide if we want the namespace and the entities
representing the hardware or representing the Linux API.
V4L2_SUBDEV has nothing to do with hardware. It is just an abstraction
that we've created on one of our subsystems.

> 
> Regards,
> 
> 	Hans
> 
> > 
> > Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
> > 
> > diff --git a/Documentation/DocBook/media/v4l/media-ioc-enum-entities.xml b/Documentation/DocBook/media/v4l/media-ioc-enum-entities.xml
> > index 5b8147629159..759604e3529f 100644
> > --- a/Documentation/DocBook/media/v4l/media-ioc-enum-entities.xml
> > +++ b/Documentation/DocBook/media/v4l/media-ioc-enum-entities.xml
> > @@ -219,15 +219,15 @@
> >  	    <entry>Unknown V4L sub-device</entry>
> >  	  </row>
> >  	  <row>
> > -	    <entry><constant>MEDIA_ENT_T_V4L2_SUBDEV_SENSOR</constant></entry>
> > +	    <entry><constant>MEDIA_ENT_T_CAM_SENSOR</constant></entry>
> >  	    <entry>Video sensor</entry>
> >  	  </row>
> >  	  <row>
> > -	    <entry><constant>MEDIA_ENT_T_V4L2_SUBDEV_FLASH</constant></entry>
> > +	    <entry><constant>MEDIA_ENT_T_CAM_FLASH</constant></entry>
> >  	    <entry>Flash controller</entry>
> >  	  </row>
> >  	  <row>
> > -	    <entry><constant>MEDIA_ENT_T_V4L2_SUBDEV_LENS</constant></entry>
> > +	    <entry><constant>MEDIA_ENT_T_CAM_LENS</constant></entry>
> >  	    <entry>Lens controller</entry>
> >  	  </row>
> >  	  <row>
> > diff --git a/drivers/media/i2c/adp1653.c b/drivers/media/i2c/adp1653.c
> > index c70ababce954..c12f873a8e26 100644
> > --- a/drivers/media/i2c/adp1653.c
> > +++ b/drivers/media/i2c/adp1653.c
> > @@ -516,7 +516,7 @@ static int adp1653_probe(struct i2c_client *client,
> >  	if (ret < 0)
> >  		goto free_and_quit;
> >  
> > -	flash->subdev.entity.type = MEDIA_ENT_T_V4L2_SUBDEV_FLASH;
> > +	flash->subdev.entity.type = MEDIA_ENT_T_CAM_FLASH;
> >  
> >  	return 0;
> >  
> > diff --git a/drivers/media/i2c/as3645a.c b/drivers/media/i2c/as3645a.c
> > index 301084b07887..9a2872be11b0 100644
> > --- a/drivers/media/i2c/as3645a.c
> > +++ b/drivers/media/i2c/as3645a.c
> > @@ -831,7 +831,7 @@ static int as3645a_probe(struct i2c_client *client,
> >  	if (ret < 0)
> >  		goto done;
> >  
> > -	flash->subdev.entity.type = MEDIA_ENT_T_V4L2_SUBDEV_FLASH;
> > +	flash->subdev.entity.type = MEDIA_ENT_T_CAM_FLASH;
> >  
> >  	mutex_init(&flash->power_lock);
> >  
> > diff --git a/drivers/media/i2c/lm3560.c b/drivers/media/i2c/lm3560.c
> > index d9ece4b2d047..4d28cda77f4d 100644
> > --- a/drivers/media/i2c/lm3560.c
> > +++ b/drivers/media/i2c/lm3560.c
> > @@ -368,7 +368,7 @@ static int lm3560_subdev_init(struct lm3560_flash *flash,
> >  	rval = media_entity_init(&flash->subdev_led[led_no].entity, 0, NULL, 0);
> >  	if (rval < 0)
> >  		goto err_out;
> > -	flash->subdev_led[led_no].entity.type = MEDIA_ENT_T_V4L2_SUBDEV_FLASH;
> > +	flash->subdev_led[led_no].entity.type = MEDIA_ENT_T_CAM_FLASH;
> >  
> >  	return rval;
> >  
> > diff --git a/drivers/media/i2c/lm3646.c b/drivers/media/i2c/lm3646.c
> > index 626fb4679c02..19ee2ac00be7 100644
> > --- a/drivers/media/i2c/lm3646.c
> > +++ b/drivers/media/i2c/lm3646.c
> > @@ -285,7 +285,7 @@ static int lm3646_subdev_init(struct lm3646_flash *flash)
> >  	rval = media_entity_init(&flash->subdev_led.entity, 0, NULL, 0);
> >  	if (rval < 0)
> >  		goto err_out;
> > -	flash->subdev_led.entity.type = MEDIA_ENT_T_V4L2_SUBDEV_FLASH;
> > +	flash->subdev_led.entity.type = MEDIA_ENT_T_CAM_FLASH;
> >  	return rval;
> >  
> >  err_out:
> > diff --git a/drivers/media/i2c/m5mols/m5mols_core.c b/drivers/media/i2c/m5mols/m5mols_core.c
> > index 6404c0d93e7a..beb519cf8be4 100644
> > --- a/drivers/media/i2c/m5mols/m5mols_core.c
> > +++ b/drivers/media/i2c/m5mols/m5mols_core.c
> > @@ -978,7 +978,7 @@ static int m5mols_probe(struct i2c_client *client,
> >  	ret = media_entity_init(&sd->entity, 1, &info->pad, 0);
> >  	if (ret < 0)
> >  		return ret;
> > -	sd->entity.type = MEDIA_ENT_T_V4L2_SUBDEV_SENSOR;
> > +	sd->entity.type = MEDIA_ENT_T_CAM_SENSOR;
> >  
> >  	init_waitqueue_head(&info->irq_waitq);
> >  	mutex_init(&info->lock);
> > diff --git a/drivers/media/i2c/noon010pc30.c b/drivers/media/i2c/noon010pc30.c
> > index f197b6cbd407..a03556197405 100644
> > --- a/drivers/media/i2c/noon010pc30.c
> > +++ b/drivers/media/i2c/noon010pc30.c
> > @@ -779,7 +779,7 @@ static int noon010_probe(struct i2c_client *client,
> >  		goto np_err;
> >  
> >  	info->pad.flags = MEDIA_PAD_FL_SOURCE;
> > -	sd->entity.type = MEDIA_ENT_T_V4L2_SUBDEV_SENSOR;
> > +	sd->entity.type = MEDIA_ENT_T_CAM_SENSOR;
> >  	ret = media_entity_init(&sd->entity, 1, &info->pad, 0);
> >  	if (ret < 0)
> >  		goto np_err;
> > diff --git a/drivers/media/i2c/ov2659.c b/drivers/media/i2c/ov2659.c
> > index d700a1d0a6f2..63b9464e813f 100644
> > --- a/drivers/media/i2c/ov2659.c
> > +++ b/drivers/media/i2c/ov2659.c
> > @@ -1425,7 +1425,7 @@ static int ov2659_probe(struct i2c_client *client,
> >  
> >  #if defined(CONFIG_MEDIA_CONTROLLER)
> >  	ov2659->pad.flags = MEDIA_PAD_FL_SOURCE;
> > -	sd->entity.type = MEDIA_ENT_T_V4L2_SUBDEV_SENSOR;
> > +	sd->entity.type = MEDIA_ENT_T_CAM_SENSOR;
> >  	ret = media_entity_init(&sd->entity, 1, &ov2659->pad, 0);
> >  	if (ret < 0) {
> >  		v4l2_ctrl_handler_free(&ov2659->ctrls);
> > diff --git a/drivers/media/i2c/ov9650.c b/drivers/media/i2c/ov9650.c
> > index 2bc473385c91..ed3c0573a0f8 100644
> > --- a/drivers/media/i2c/ov9650.c
> > +++ b/drivers/media/i2c/ov9650.c
> > @@ -1500,7 +1500,7 @@ static int ov965x_probe(struct i2c_client *client,
> >  		return ret;
> >  
> >  	ov965x->pad.flags = MEDIA_PAD_FL_SOURCE;
> > -	sd->entity.type = MEDIA_ENT_T_V4L2_SUBDEV_SENSOR;
> > +	sd->entity.type = MEDIA_ENT_T_CAM_SENSOR;
> >  	ret = media_entity_init(&sd->entity, 1, &ov965x->pad, 0);
> >  	if (ret < 0)
> >  		return ret;
> > diff --git a/drivers/media/i2c/s5k4ecgx.c b/drivers/media/i2c/s5k4ecgx.c
> > index 97084237275d..23af7f90678a 100644
> > --- a/drivers/media/i2c/s5k4ecgx.c
> > +++ b/drivers/media/i2c/s5k4ecgx.c
> > @@ -961,7 +961,7 @@ static int s5k4ecgx_probe(struct i2c_client *client,
> >  	sd->flags |= V4L2_SUBDEV_FL_HAS_DEVNODE;
> >  
> >  	priv->pad.flags = MEDIA_PAD_FL_SOURCE;
> > -	sd->entity.type = MEDIA_ENT_T_V4L2_SUBDEV_SENSOR;
> > +	sd->entity.type = MEDIA_ENT_T_CAM_SENSOR;
> >  	ret = media_entity_init(&sd->entity, 1, &priv->pad, 0);
> >  	if (ret)
> >  		return ret;
> > diff --git a/drivers/media/i2c/s5k5baf.c b/drivers/media/i2c/s5k5baf.c
> > index bee73de347dc..fadd48d35a55 100644
> > --- a/drivers/media/i2c/s5k5baf.c
> > +++ b/drivers/media/i2c/s5k5baf.c
> > @@ -408,7 +408,7 @@ static inline struct v4l2_subdev *ctrl_to_sd(struct v4l2_ctrl *ctrl)
> >  
> >  static inline bool s5k5baf_is_cis_subdev(struct v4l2_subdev *sd)
> >  {
> > -	return sd->entity.type == MEDIA_ENT_T_V4L2_SUBDEV_SENSOR;
> > +	return sd->entity.type == MEDIA_ENT_T_CAM_SENSOR;
> >  }
> >  
> >  static inline struct s5k5baf *to_s5k5baf(struct v4l2_subdev *sd)
> > @@ -1904,7 +1904,7 @@ static int s5k5baf_configure_subdevs(struct s5k5baf *state,
> >  	sd->flags |= V4L2_SUBDEV_FL_HAS_DEVNODE;
> >  
> >  	state->cis_pad.flags = MEDIA_PAD_FL_SOURCE;
> > -	sd->entity.type = MEDIA_ENT_T_V4L2_SUBDEV_SENSOR;
> > +	sd->entity.type = MEDIA_ENT_T_CAM_SENSOR;
> >  	ret = media_entity_init(&sd->entity, NUM_CIS_PADS, &state->cis_pad, 0);
> >  	if (ret < 0)
> >  		goto err;
> > diff --git a/drivers/media/i2c/s5k6aa.c b/drivers/media/i2c/s5k6aa.c
> > index d0ad6a25bdab..d2390c6e5dbe 100644
> > --- a/drivers/media/i2c/s5k6aa.c
> > +++ b/drivers/media/i2c/s5k6aa.c
> > @@ -1577,7 +1577,7 @@ static int s5k6aa_probe(struct i2c_client *client,
> >  	sd->flags |= V4L2_SUBDEV_FL_HAS_DEVNODE;
> >  
> >  	s5k6aa->pad.flags = MEDIA_PAD_FL_SOURCE;
> > -	sd->entity.type = MEDIA_ENT_T_V4L2_SUBDEV_SENSOR;
> > +	sd->entity.type = MEDIA_ENT_T_CAM_SENSOR;
> >  	ret = media_entity_init(&sd->entity, 1, &s5k6aa->pad, 0);
> >  	if (ret)
> >  		return ret;
> > diff --git a/drivers/media/i2c/smiapp/smiapp-core.c b/drivers/media/i2c/smiapp/smiapp-core.c
> > index 636ebd6fe5dc..78f2cdd3561b 100644
> > --- a/drivers/media/i2c/smiapp/smiapp-core.c
> > +++ b/drivers/media/i2c/smiapp/smiapp-core.c
> > @@ -2763,7 +2763,7 @@ static int smiapp_init(struct smiapp_sensor *sensor)
> >  
> >  	dev_dbg(&client->dev, "profile %d\n", sensor->minfo.smiapp_profile);
> >  
> > -	sensor->pixel_array->sd.entity.type = MEDIA_ENT_T_V4L2_SUBDEV_SENSOR;
> > +	sensor->pixel_array->sd.entity.type = MEDIA_ENT_T_CAM_SENSOR;
> >  
> >  	/* final steps */
> >  	smiapp_read_frame_fmt(sensor);
> > diff --git a/include/uapi/linux/media.h b/include/uapi/linux/media.h
> > index a7aa2aac9c23..2e465ba087ba 100644
> > --- a/include/uapi/linux/media.h
> > +++ b/include/uapi/linux/media.h
> > @@ -51,13 +51,13 @@ struct media_device_info {
> >  #define MEDIA_ENT_T_DEVNODE_DVB_CA	(MEDIA_ENT_T_AV_DMA + 6)
> >  #define MEDIA_ENT_T_DEVNODE_DVB_NET	(MEDIA_ENT_T_AV_DMA + 7)
> >  
> > -#define MEDIA_ENT_T_V4L2_SUBDEV_SENSOR	((2 << 16) + 1)
> > -#define MEDIA_ENT_T_V4L2_SUBDEV_FLASH	(MEDIA_ENT_T_V4L2_SUBDEV_SENSOR + 1)
> > -#define MEDIA_ENT_T_V4L2_SUBDEV_LENS	(MEDIA_ENT_T_V4L2_SUBDEV_SENSOR + 2)
> > +#define MEDIA_ENT_T_CAM_SENSOR	((2 << 16) + 1)
> > +#define MEDIA_ENT_T_CAM_FLASH	(MEDIA_ENT_T_CAM_SENSOR + 1)
> > +#define MEDIA_ENT_T_CAM_LENS	(MEDIA_ENT_T_CAM_SENSOR + 2)
> >  /* A converter of analogue video to its digital representation. */
> > -#define MEDIA_ENT_T_V4L2_SUBDEV_DECODER	(MEDIA_ENT_T_V4L2_SUBDEV_SENSOR + 3)
> > +#define MEDIA_ENT_T_V4L2_SUBDEV_DECODER	(MEDIA_ENT_T_CAM_SENSOR + 3)
> >  
> > -#define MEDIA_ENT_T_V4L2_SUBDEV_TUNER	(MEDIA_ENT_T_V4L2_SUBDEV_SENSOR + 4)
> > +#define MEDIA_ENT_T_V4L2_SUBDEV_TUNER	(MEDIA_ENT_T_CAM_SENSOR + 4)
> >  
> >  #if 1
> >  /*
> > @@ -76,8 +76,10 @@ struct media_device_info {
> >  #define MEDIA_ENT_T_DEVNODE_FB		(MEDIA_ENT_T_DEVNODE + 2)
> >  #define MEDIA_ENT_T_DEVNODE_ALSA	(MEDIA_ENT_T_DEVNODE + 3)
> >  
> > -
> >  #define MEDIA_ENT_T_DEVNODE_DVB		MEDIA_ENT_T_DEVNODE_DVB_FE
> > +#define MEDIA_ENT_T_V4L2_SUBDEV_SENSOR	MEDIA_ENT_T_CAM_SENSOR
> > +#define MEDIA_ENT_T_V4L2_SUBDEV_FLASH	MEDIA_ENT_T_CAM_FLASH
> > +#define MEDIA_ENT_T_V4L2_SUBDEV_LENS	MEDIA_ENT_T_CAM_LENS
> >  #endif
> >  
> >  /* Used bitmasks for media_entity_desc::flags */
> > 
> 

Re: [PATCH 04/18] media controller: Rename camera entities

[Hans Verkuil]

On 05/08/2015 02:53 PM, Mauro Carvalho Chehab wrote:
> Em Fri, 08 May 2015 14:03:01 +0200
> Hans Verkuil <hverkuil@xs4all.nl> escreveu:
> 
>> On 05/08/2015 03:12 AM, Mauro Carvalho Chehab wrote:
>>> As explained before, the hole idea of subtypes at entities was
>>
>> hole -> whole
>>
>>> not nice. All V4L2 subdevs may have a device node associated.
>>>
>>> Also, the hole idea is to expose hardware IP blocks, so calling
>>> them as V4L2 is a very bad practice, as they were not designed
>>> for the V4L2 API. It is just the reverse.
>>>
>>> So, instead of using V4L2_SUBDEV, let's call the camera sub-
>>> devices with CAM, instead:
>>>
>>> 	MEDIA_ENT_T_V4L2_SUBDEV_SENSOR -> MEDIA_ENT_T_CAM_SENSOR
>>> 	MEDIA_ENT_T_V4L2_SUBDEV_FLASH  -> MEDIA_ENT_T_CAM_FLASH
>>> 	MEDIA_ENT_T_V4L2_SUBDEV_LENS   -> MEDIA_ENT_T_CAM_LENS
>>
>> I would actually postpone this until Laurent has a properties API ready.
>> These entity types are fatally flawed since an entity can combine functions
>> in one. E.g. an i2c device (generally represented as a single entity) might
>> provide for both sensor and flash. Or combine tuner and video decoder, etc.
> 
> Mapping one I2C address as one entity is plain wrong.

I said 'i2c device', not i2c address. That would definitely be wrong. I'm also
not saying that each i2c device (chip) maps always to one entity, although this
is generally true. In the end it depends on the driver author to decide how
to split up the functionality of the device into entities. There is no hard
and fast rule for that.

> So, if a single piece of hardware has the functions of two entities
> (sensor and flash), it should be represented as two separate entities.

Perhaps, perhaps not. There is in the general case no clear rule at what
level you design your entities. In a complex pipeline it would be madness
to map every little HW block to an entity since you would get a zillion
entities, which is highly impractical. The cx25840 combines multiple
functions (tuner, audio/video decoders), and I am not at all sure you
would gain anything from splitting that up into smaller entities. In the
end, if you would write a block diagram of your board the cx25840 would be
a single block. And experience has shown that that is typically the right
level for deciding what will be an entity or not.

Also, in such devices the various functions are often intertwined and
generally not easy to separate.

> 
> The I2C bus would matter if we were mapping the control plane of the
> entities, adding PADs for the control lines. But last time I checked,
> Laurent was still strongly opposed to that.
> 
>> Basically an entity like this is a sub-device (as in the literal meaning
>> of being a part of a larger device) that has one or more functions and may
>> have device node(s) associated with it. That is best expressed as properties.
>>
>> And you really do have to tell userspace that these entities expose a
>> v4l-subdev device node. Renaming them doesn't make that go away.
> 
> Well, we should decide if we want the namespace and the entities
> representing the hardware or representing the Linux API.
> V4L2_SUBDEV has nothing to do with hardware. It is just an abstraction
> that we've created on one of our subsystems.

I agree. MEDIA_ENT_T_V4L2_SUBDEV_SENSOR basically contains two bits of
information: the linux API used to access the entity and the function.

Since you don't combine multiple APIs (e.g. ALSA and V4L2) for a single
device node (I would certainly never allow such code in the kernel!) there
is only one of those, but one entity can certainly combine multiple functions
as I argued for above. Hence, those should be properties.

Anyway, let's wait what Laurent thinks and setup an irc session for this.

Regards,

	Hans

[PATCH 06/18] media controller: rename analog TV decoder

[Mauro Carvalho Chehab]

To keep coherency, let's also remove V4L2_SUBDEV from the analog
TV decoder, calling it by its function, and not by the V4L2
API mapping.

So,

	MEDIA_ENT_T_V4L2_SUBDEV_DECODER -> MEDIA_ENT_T_ATV_DECODER

Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>

diff --git a/Documentation/DocBook/media/v4l/media-ioc-enum-entities.xml b/Documentation/DocBook/media/v4l/media-ioc-enum-entities.xml
index 27082b07f4c2..9b3861058f0d 100644
--- a/Documentation/DocBook/media/v4l/media-ioc-enum-entities.xml
+++ b/Documentation/DocBook/media/v4l/media-ioc-enum-entities.xml
@@ -231,7 +231,7 @@
 	    <entry>Lens controller</entry>
 	  </row>
 	  <row>
-	    <entry><constant>MEDIA_ENT_T_V4L2_SUBDEV_DECODER</constant></entry>
+	    <entry><constant>MEDIA_ENT_T_ATV_DECODER</constant></entry>
 	    <entry>Video decoder, the basic function of the video decoder is to
 	    accept analogue video from a wide variety of sources such as
 	    broadcast, DVD players, cameras and video cassette recorders, in
diff --git a/drivers/media/i2c/adv7180.c b/drivers/media/i2c/adv7180.c
index a493c0b0b5fe..e8f0b53cc253 100644
--- a/drivers/media/i2c/adv7180.c
+++ b/drivers/media/i2c/adv7180.c
@@ -1212,7 +1212,7 @@ static int adv7180_probe(struct i2c_client *client,
 		goto err_unregister_vpp_client;
 
 	state->pad.flags = MEDIA_PAD_FL_SOURCE;
-	sd->entity.flags |= MEDIA_ENT_T_V4L2_SUBDEV_DECODER;
+	sd->entity.flags |= MEDIA_ENT_T_ATV_DECODER;
 	ret = media_entity_init(&sd->entity, 1, &state->pad, 0);
 	if (ret)
 		goto err_free_ctrl;
diff --git a/drivers/media/i2c/cx25840/cx25840-core.c b/drivers/media/i2c/cx25840/cx25840-core.c
index e15a789ad596..cd8a3c273ab8 100644
--- a/drivers/media/i2c/cx25840/cx25840-core.c
+++ b/drivers/media/i2c/cx25840/cx25840-core.c
@@ -5208,7 +5208,7 @@ static int cx25840_probe(struct i2c_client *client,
 	state->pads[CX25840_PAD_INPUT].flags = MEDIA_PAD_FL_SINK;
 	state->pads[CX25840_PAD_VID_OUT].flags = MEDIA_PAD_FL_SOURCE;
 	state->pads[CX25840_PAD_VBI_OUT].flags = MEDIA_PAD_FL_SOURCE;
-	sd->entity.type = MEDIA_ENT_T_V4L2_SUBDEV_DECODER;
+	sd->entity.type = MEDIA_ENT_T_ATV_DECODER;
 
 	ret = media_entity_init(&sd->entity, ARRAY_SIZE(state->pads),
 				state->pads, 0);
diff --git a/drivers/media/i2c/tvp514x.c b/drivers/media/i2c/tvp514x.c
index 24e47279e30c..77744c390941 100644
--- a/drivers/media/i2c/tvp514x.c
+++ b/drivers/media/i2c/tvp514x.c
@@ -1106,7 +1106,7 @@ tvp514x_probe(struct i2c_client *client, const struct i2c_device_id *id)
 #if defined(CONFIG_MEDIA_CONTROLLER)
 	decoder->pad.flags = MEDIA_PAD_FL_SOURCE;
 	decoder->sd.flags |= V4L2_SUBDEV_FL_HAS_DEVNODE;
-	decoder->sd.entity.flags |= MEDIA_ENT_T_V4L2_SUBDEV_DECODER;
+	decoder->sd.entity.flags |= MEDIA_ENT_T_ATV_DECODER;
 
 	ret = media_entity_init(&decoder->sd.entity, 1, &decoder->pad, 0);
 	if (ret < 0) {
diff --git a/drivers/media/i2c/tvp7002.c b/drivers/media/i2c/tvp7002.c
index 05077cffd235..3facef49aef1 100644
--- a/drivers/media/i2c/tvp7002.c
+++ b/drivers/media/i2c/tvp7002.c
@@ -1019,7 +1019,7 @@ static int tvp7002_probe(struct i2c_client *c, const struct i2c_device_id *id)
 #if defined(CONFIG_MEDIA_CONTROLLER)
 	device->pad.flags = MEDIA_PAD_FL_SOURCE;
 	device->sd.flags |= V4L2_SUBDEV_FL_HAS_DEVNODE;
-	device->sd.entity.flags |= MEDIA_ENT_T_V4L2_SUBDEV_DECODER;
+	device->sd.entity.flags |= MEDIA_ENT_T_ATV_DECODER;
 
 	error = media_entity_init(&device->sd.entity, 1, &device->pad, 0);
 	if (error < 0)
diff --git a/drivers/media/usb/cx231xx/cx231xx-cards.c b/drivers/media/usb/cx231xx/cx231xx-cards.c
index fe00da105e77..a756f74f0adc 100644
--- a/drivers/media/usb/cx231xx/cx231xx-cards.c
+++ b/drivers/media/usb/cx231xx/cx231xx-cards.c
@@ -1216,7 +1216,7 @@ static void cx231xx_create_media_graph(struct cx231xx *dev)
 		case MEDIA_ENT_T_V4L2_SUBDEV_TUNER:
 			tuner = entity;
 			break;
-		case MEDIA_ENT_T_V4L2_SUBDEV_DECODER:
+		case MEDIA_ENT_T_ATV_DECODER:
 			decoder = entity;
 			break;
 		}
diff --git a/drivers/media/usb/cx231xx/cx231xx-video.c b/drivers/media/usb/cx231xx/cx231xx-video.c
index af44f2d1c0a1..bed4ee28916d 100644
--- a/drivers/media/usb/cx231xx/cx231xx-video.c
+++ b/drivers/media/usb/cx231xx/cx231xx-video.c
@@ -119,7 +119,7 @@ static int cx231xx_enable_analog_tuner(struct cx231xx *dev)
 	 * this should be enough for the actual needs.
 	 */
 	media_device_for_each_entity(entity, mdev) {
-		if (entity->type == MEDIA_ENT_T_V4L2_SUBDEV_DECODER) {
+		if (entity->type == MEDIA_ENT_T_ATV_DECODER) {
 			decoder = entity;
 			break;
 		}
diff --git a/include/uapi/linux/media.h b/include/uapi/linux/media.h
index 0de9912411c5..9b3d80e765f0 100644
--- a/include/uapi/linux/media.h
+++ b/include/uapi/linux/media.h
@@ -54,8 +54,8 @@ struct media_device_info {
 #define MEDIA_ENT_T_CAM_SENSOR	((2 << 16) + 1)
 #define MEDIA_ENT_T_CAM_FLASH	(MEDIA_ENT_T_CAM_SENSOR + 1)
 #define MEDIA_ENT_T_CAM_LENS	(MEDIA_ENT_T_CAM_SENSOR + 2)
-/* A converter of analogue video to its digital representation. */
-#define MEDIA_ENT_T_V4L2_SUBDEV_DECODER	(MEDIA_ENT_T_CAM_SENSOR + 3)
+
+#define MEDIA_ENT_T_ATV_DECODER	(MEDIA_ENT_T_CAM_SENSOR + 3)
 
 #define MEDIA_ENT_T_V4L2_SUBDEV_TUNER	(MEDIA_ENT_T_CAM_SENSOR + 4)
 
@@ -86,6 +86,8 @@ struct media_device_info {
 #define MEDIA_ENT_T_V4L2_SUBDEV_SENSOR	MEDIA_ENT_T_CAM_SENSOR
 #define MEDIA_ENT_T_V4L2_SUBDEV_FLASH	MEDIA_ENT_T_CAM_FLASH
 #define MEDIA_ENT_T_V4L2_SUBDEV_LENS	MEDIA_ENT_T_CAM_LENS
+
+#define MEDIA_ENT_T_V4L2_SUBDEV_DECODER MEDIA_ENT_T_ATV_DECODER
 #endif
 
 /* Used bitmasks for media_entity_desc::flags */
-- 
2.1.0

Re: [PATCH 06/18] media controller: rename analog TV decoder

[Hans Verkuil]

On 05/08/2015 03:12 AM, Mauro Carvalho Chehab wrote:
> To keep coherency, let's also remove V4L2_SUBDEV from the analog
> TV decoder, calling it by its function, and not by the V4L2
> API mapping.

Same issue as with patch 04/18.

	Hans

> 
> So,
> 
> 	MEDIA_ENT_T_V4L2_SUBDEV_DECODER -> MEDIA_ENT_T_ATV_DECODER
> 
> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
> 
> diff --git a/Documentation/DocBook/media/v4l/media-ioc-enum-entities.xml b/Documentation/DocBook/media/v4l/media-ioc-enum-entities.xml
> index 27082b07f4c2..9b3861058f0d 100644
> --- a/Documentation/DocBook/media/v4l/media-ioc-enum-entities.xml
> +++ b/Documentation/DocBook/media/v4l/media-ioc-enum-entities.xml
> @@ -231,7 +231,7 @@
>  	    <entry>Lens controller</entry>
>  	  </row>
>  	  <row>
> -	    <entry><constant>MEDIA_ENT_T_V4L2_SUBDEV_DECODER</constant></entry>
> +	    <entry><constant>MEDIA_ENT_T_ATV_DECODER</constant></entry>
>  	    <entry>Video decoder, the basic function of the video decoder is to
>  	    accept analogue video from a wide variety of sources such as
>  	    broadcast, DVD players, cameras and video cassette recorders, in
> diff --git a/drivers/media/i2c/adv7180.c b/drivers/media/i2c/adv7180.c
> index a493c0b0b5fe..e8f0b53cc253 100644
> --- a/drivers/media/i2c/adv7180.c
> +++ b/drivers/media/i2c/adv7180.c
> @@ -1212,7 +1212,7 @@ static int adv7180_probe(struct i2c_client *client,
>  		goto err_unregister_vpp_client;
>  
>  	state->pad.flags = MEDIA_PAD_FL_SOURCE;
> -	sd->entity.flags |= MEDIA_ENT_T_V4L2_SUBDEV_DECODER;
> +	sd->entity.flags |= MEDIA_ENT_T_ATV_DECODER;
>  	ret = media_entity_init(&sd->entity, 1, &state->pad, 0);
>  	if (ret)
>  		goto err_free_ctrl;
> diff --git a/drivers/media/i2c/cx25840/cx25840-core.c b/drivers/media/i2c/cx25840/cx25840-core.c
> index e15a789ad596..cd8a3c273ab8 100644
> --- a/drivers/media/i2c/cx25840/cx25840-core.c
> +++ b/drivers/media/i2c/cx25840/cx25840-core.c
> @@ -5208,7 +5208,7 @@ static int cx25840_probe(struct i2c_client *client,
>  	state->pads[CX25840_PAD_INPUT].flags = MEDIA_PAD_FL_SINK;
>  	state->pads[CX25840_PAD_VID_OUT].flags = MEDIA_PAD_FL_SOURCE;
>  	state->pads[CX25840_PAD_VBI_OUT].flags = MEDIA_PAD_FL_SOURCE;
> -	sd->entity.type = MEDIA_ENT_T_V4L2_SUBDEV_DECODER;
> +	sd->entity.type = MEDIA_ENT_T_ATV_DECODER;
>  
>  	ret = media_entity_init(&sd->entity, ARRAY_SIZE(state->pads),
>  				state->pads, 0);
> diff --git a/drivers/media/i2c/tvp514x.c b/drivers/media/i2c/tvp514x.c
> index 24e47279e30c..77744c390941 100644
> --- a/drivers/media/i2c/tvp514x.c
> +++ b/drivers/media/i2c/tvp514x.c
> @@ -1106,7 +1106,7 @@ tvp514x_probe(struct i2c_client *client, const struct i2c_device_id *id)
>  #if defined(CONFIG_MEDIA_CONTROLLER)
>  	decoder->pad.flags = MEDIA_PAD_FL_SOURCE;
>  	decoder->sd.flags |= V4L2_SUBDEV_FL_HAS_DEVNODE;
> -	decoder->sd.entity.flags |= MEDIA_ENT_T_V4L2_SUBDEV_DECODER;
> +	decoder->sd.entity.flags |= MEDIA_ENT_T_ATV_DECODER;
>  
>  	ret = media_entity_init(&decoder->sd.entity, 1, &decoder->pad, 0);
>  	if (ret < 0) {
> diff --git a/drivers/media/i2c/tvp7002.c b/drivers/media/i2c/tvp7002.c
> index 05077cffd235..3facef49aef1 100644
> --- a/drivers/media/i2c/tvp7002.c
> +++ b/drivers/media/i2c/tvp7002.c
> @@ -1019,7 +1019,7 @@ static int tvp7002_probe(struct i2c_client *c, const struct i2c_device_id *id)
>  #if defined(CONFIG_MEDIA_CONTROLLER)
>  	device->pad.flags = MEDIA_PAD_FL_SOURCE;
>  	device->sd.flags |= V4L2_SUBDEV_FL_HAS_DEVNODE;
> -	device->sd.entity.flags |= MEDIA_ENT_T_V4L2_SUBDEV_DECODER;
> +	device->sd.entity.flags |= MEDIA_ENT_T_ATV_DECODER;
>  
>  	error = media_entity_init(&device->sd.entity, 1, &device->pad, 0);
>  	if (error < 0)
> diff --git a/drivers/media/usb/cx231xx/cx231xx-cards.c b/drivers/media/usb/cx231xx/cx231xx-cards.c
> index fe00da105e77..a756f74f0adc 100644
> --- a/drivers/media/usb/cx231xx/cx231xx-cards.c
> +++ b/drivers/media/usb/cx231xx/cx231xx-cards.c
> @@ -1216,7 +1216,7 @@ static void cx231xx_create_media_graph(struct cx231xx *dev)
>  		case MEDIA_ENT_T_V4L2_SUBDEV_TUNER:
>  			tuner = entity;
>  			break;
> -		case MEDIA_ENT_T_V4L2_SUBDEV_DECODER:
> +		case MEDIA_ENT_T_ATV_DECODER:
>  			decoder = entity;
>  			break;
>  		}
> diff --git a/drivers/media/usb/cx231xx/cx231xx-video.c b/drivers/media/usb/cx231xx/cx231xx-video.c
> index af44f2d1c0a1..bed4ee28916d 100644
> --- a/drivers/media/usb/cx231xx/cx231xx-video.c
> +++ b/drivers/media/usb/cx231xx/cx231xx-video.c
> @@ -119,7 +119,7 @@ static int cx231xx_enable_analog_tuner(struct cx231xx *dev)
>  	 * this should be enough for the actual needs.
>  	 */
>  	media_device_for_each_entity(entity, mdev) {
> -		if (entity->type == MEDIA_ENT_T_V4L2_SUBDEV_DECODER) {
> +		if (entity->type == MEDIA_ENT_T_ATV_DECODER) {
>  			decoder = entity;
>  			break;
>  		}
> diff --git a/include/uapi/linux/media.h b/include/uapi/linux/media.h
> index 0de9912411c5..9b3d80e765f0 100644
> --- a/include/uapi/linux/media.h
> +++ b/include/uapi/linux/media.h
> @@ -54,8 +54,8 @@ struct media_device_info {
>  #define MEDIA_ENT_T_CAM_SENSOR	((2 << 16) + 1)
>  #define MEDIA_ENT_T_CAM_FLASH	(MEDIA_ENT_T_CAM_SENSOR + 1)
>  #define MEDIA_ENT_T_CAM_LENS	(MEDIA_ENT_T_CAM_SENSOR + 2)
> -/* A converter of analogue video to its digital representation. */
> -#define MEDIA_ENT_T_V4L2_SUBDEV_DECODER	(MEDIA_ENT_T_CAM_SENSOR + 3)
> +
> +#define MEDIA_ENT_T_ATV_DECODER	(MEDIA_ENT_T_CAM_SENSOR + 3)
>  
>  #define MEDIA_ENT_T_V4L2_SUBDEV_TUNER	(MEDIA_ENT_T_CAM_SENSOR + 4)
>  
> @@ -86,6 +86,8 @@ struct media_device_info {
>  #define MEDIA_ENT_T_V4L2_SUBDEV_SENSOR	MEDIA_ENT_T_CAM_SENSOR
>  #define MEDIA_ENT_T_V4L2_SUBDEV_FLASH	MEDIA_ENT_T_CAM_FLASH
>  #define MEDIA_ENT_T_V4L2_SUBDEV_LENS	MEDIA_ENT_T_CAM_LENS
> +
> +#define MEDIA_ENT_T_V4L2_SUBDEV_DECODER MEDIA_ENT_T_ATV_DECODER
>  #endif
>  
>  /* Used bitmasks for media_entity_desc::flags */
> 

[PATCH 07/18] media controller: rename the tuner entity

[Mauro Carvalho Chehab]

Finally, let's rename the tuner entity. inside the media subsystem,
a tuner can be used by AM/FM radio, SDR radio, analog TV and digital TV.
It could even be used on other subsystems, like network, for wireless
devices.

So, it is not constricted to V4L2 API, or to a subdev.

Let's then rename it as:
	MEDIA_ENT_T_V4L2_SUBDEV_TUNER -> MEDIA_ENT_T_TUNER

Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>

diff --git a/Documentation/DocBook/media/v4l/media-ioc-enum-entities.xml b/Documentation/DocBook/media/v4l/media-ioc-enum-entities.xml
index 9b3861058f0d..5c7f366bb1f4 100644
--- a/Documentation/DocBook/media/v4l/media-ioc-enum-entities.xml
+++ b/Documentation/DocBook/media/v4l/media-ioc-enum-entities.xml
@@ -241,7 +241,7 @@
 	    signals.</entry>
 	  </row>
 	  <row>
-	    <entry><constant>MEDIA_ENT_T_V4L2_SUBDEV_TUNER</constant></entry>
+	    <entry><constant>MEDIA_ENT_T_TUNER</constant></entry>
 	    <entry>TV and/or radio tuner</entry>
 	  </row>
 	</tbody>
diff --git a/drivers/media/dvb-core/dvbdev.c b/drivers/media/dvb-core/dvbdev.c
index 39846077045e..d6a096495035 100644
--- a/drivers/media/dvb-core/dvbdev.c
+++ b/drivers/media/dvb-core/dvbdev.c
@@ -393,7 +393,7 @@ void dvb_create_media_graph(struct dvb_adapter *adap)
 
 	media_device_for_each_entity(entity, mdev) {
 		switch (entity->type) {
-		case MEDIA_ENT_T_V4L2_SUBDEV_TUNER:
+		case MEDIA_ENT_T_TUNER:
 			tuner = entity;
 			break;
 		case MEDIA_ENT_T_DTV_DEMOD:
diff --git a/drivers/media/usb/cx231xx/cx231xx-cards.c b/drivers/media/usb/cx231xx/cx231xx-cards.c
index a756f74f0adc..2a7331e3c4a0 100644
--- a/drivers/media/usb/cx231xx/cx231xx-cards.c
+++ b/drivers/media/usb/cx231xx/cx231xx-cards.c
@@ -1213,7 +1213,7 @@ static void cx231xx_create_media_graph(struct cx231xx *dev)
 
 	media_device_for_each_entity(entity, mdev) {
 		switch (entity->type) {
-		case MEDIA_ENT_T_V4L2_SUBDEV_TUNER:
+		case MEDIA_ENT_T_TUNER:
 			tuner = entity;
 			break;
 		case MEDIA_ENT_T_ATV_DECODER:
diff --git a/drivers/media/v4l2-core/tuner-core.c b/drivers/media/v4l2-core/tuner-core.c
index abdcffabcb59..ecf4e8a543b3 100644
--- a/drivers/media/v4l2-core/tuner-core.c
+++ b/drivers/media/v4l2-core/tuner-core.c
@@ -696,7 +696,7 @@ static int tuner_probe(struct i2c_client *client,
 register_client:
 #if defined(CONFIG_MEDIA_CONTROLLER)
 	t->pad.flags = MEDIA_PAD_FL_SOURCE;
-	t->sd.entity.type = MEDIA_ENT_T_V4L2_SUBDEV_TUNER;
+	t->sd.entity.type = MEDIA_ENT_T_TUNER;
 	t->sd.entity.name = t->name;
 
 	ret = media_entity_init(&t->sd.entity, 1, &t->pad, 0);
diff --git a/include/uapi/linux/media.h b/include/uapi/linux/media.h
index 9b3d80e765f0..6acc4be1378c 100644
--- a/include/uapi/linux/media.h
+++ b/include/uapi/linux/media.h
@@ -57,7 +57,7 @@ struct media_device_info {
 
 #define MEDIA_ENT_T_ATV_DECODER	(MEDIA_ENT_T_CAM_SENSOR + 3)
 
-#define MEDIA_ENT_T_V4L2_SUBDEV_TUNER	(MEDIA_ENT_T_CAM_SENSOR + 4)
+#define MEDIA_ENT_T_TUNER	(MEDIA_ENT_T_CAM_SENSOR + 4)
 
 #if 1
 /*
@@ -88,6 +88,8 @@ struct media_device_info {
 #define MEDIA_ENT_T_V4L2_SUBDEV_LENS	MEDIA_ENT_T_CAM_LENS
 
 #define MEDIA_ENT_T_V4L2_SUBDEV_DECODER MEDIA_ENT_T_ATV_DECODER
+
+#define MEDIA_ENT_T_V4L2_SUBDEV_TUNER	MEDIA_ENT_T_TUNER
 #endif
 
 /* Used bitmasks for media_entity_desc::flags */
-- 
2.1.0

Re: [PATCH 07/18] media controller: rename the tuner entity

[Hans Verkuil]

On 05/08/2015 03:12 AM, Mauro Carvalho Chehab wrote:
> Finally, let's rename the tuner entity. inside the media subsystem,
> a tuner can be used by AM/FM radio, SDR radio, analog TV and digital TV.
> It could even be used on other subsystems, like network, for wireless
> devices.
> 
> So, it is not constricted to V4L2 API, or to a subdev.
> 
> Let's then rename it as:
> 	MEDIA_ENT_T_V4L2_SUBDEV_TUNER -> MEDIA_ENT_T_TUNER

See patch 04/18.

	Hans

> 
> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
> 
> diff --git a/Documentation/DocBook/media/v4l/media-ioc-enum-entities.xml b/Documentation/DocBook/media/v4l/media-ioc-enum-entities.xml
> index 9b3861058f0d..5c7f366bb1f4 100644
> --- a/Documentation/DocBook/media/v4l/media-ioc-enum-entities.xml
> +++ b/Documentation/DocBook/media/v4l/media-ioc-enum-entities.xml
> @@ -241,7 +241,7 @@
>  	    signals.</entry>
>  	  </row>
>  	  <row>
> -	    <entry><constant>MEDIA_ENT_T_V4L2_SUBDEV_TUNER</constant></entry>
> +	    <entry><constant>MEDIA_ENT_T_TUNER</constant></entry>
>  	    <entry>TV and/or radio tuner</entry>
>  	  </row>
>  	</tbody>
> diff --git a/drivers/media/dvb-core/dvbdev.c b/drivers/media/dvb-core/dvbdev.c
> index 39846077045e..d6a096495035 100644
> --- a/drivers/media/dvb-core/dvbdev.c
> +++ b/drivers/media/dvb-core/dvbdev.c
> @@ -393,7 +393,7 @@ void dvb_create_media_graph(struct dvb_adapter *adap)
>  
>  	media_device_for_each_entity(entity, mdev) {
>  		switch (entity->type) {
> -		case MEDIA_ENT_T_V4L2_SUBDEV_TUNER:
> +		case MEDIA_ENT_T_TUNER:
>  			tuner = entity;
>  			break;
>  		case MEDIA_ENT_T_DTV_DEMOD:
> diff --git a/drivers/media/usb/cx231xx/cx231xx-cards.c b/drivers/media/usb/cx231xx/cx231xx-cards.c
> index a756f74f0adc..2a7331e3c4a0 100644
> --- a/drivers/media/usb/cx231xx/cx231xx-cards.c
> +++ b/drivers/media/usb/cx231xx/cx231xx-cards.c
> @@ -1213,7 +1213,7 @@ static void cx231xx_create_media_graph(struct cx231xx *dev)
>  
>  	media_device_for_each_entity(entity, mdev) {
>  		switch (entity->type) {
> -		case MEDIA_ENT_T_V4L2_SUBDEV_TUNER:
> +		case MEDIA_ENT_T_TUNER:
>  			tuner = entity;
>  			break;
>  		case MEDIA_ENT_T_ATV_DECODER:
> diff --git a/drivers/media/v4l2-core/tuner-core.c b/drivers/media/v4l2-core/tuner-core.c
> index abdcffabcb59..ecf4e8a543b3 100644
> --- a/drivers/media/v4l2-core/tuner-core.c
> +++ b/drivers/media/v4l2-core/tuner-core.c
> @@ -696,7 +696,7 @@ static int tuner_probe(struct i2c_client *client,
>  register_client:
>  #if defined(CONFIG_MEDIA_CONTROLLER)
>  	t->pad.flags = MEDIA_PAD_FL_SOURCE;
> -	t->sd.entity.type = MEDIA_ENT_T_V4L2_SUBDEV_TUNER;
> +	t->sd.entity.type = MEDIA_ENT_T_TUNER;
>  	t->sd.entity.name = t->name;
>  
>  	ret = media_entity_init(&t->sd.entity, 1, &t->pad, 0);
> diff --git a/include/uapi/linux/media.h b/include/uapi/linux/media.h
> index 9b3d80e765f0..6acc4be1378c 100644
> --- a/include/uapi/linux/media.h
> +++ b/include/uapi/linux/media.h
> @@ -57,7 +57,7 @@ struct media_device_info {
>  
>  #define MEDIA_ENT_T_ATV_DECODER	(MEDIA_ENT_T_CAM_SENSOR + 3)
>  
> -#define MEDIA_ENT_T_V4L2_SUBDEV_TUNER	(MEDIA_ENT_T_CAM_SENSOR + 4)
> +#define MEDIA_ENT_T_TUNER	(MEDIA_ENT_T_CAM_SENSOR + 4)
>  
>  #if 1
>  /*
> @@ -88,6 +88,8 @@ struct media_device_info {
>  #define MEDIA_ENT_T_V4L2_SUBDEV_LENS	MEDIA_ENT_T_CAM_LENS
>  
>  #define MEDIA_ENT_T_V4L2_SUBDEV_DECODER MEDIA_ENT_T_ATV_DECODER
> +
> +#define MEDIA_ENT_T_V4L2_SUBDEV_TUNER	MEDIA_ENT_T_TUNER
>  #endif
>  
>  /* Used bitmasks for media_entity_desc::flags */
> 

Re: [PATCH 07/18] media controller: rename the tuner entity

[Mauro Carvalho Chehab]

Em Fri, 08 May 2015 14:13:22 +0200
Hans Verkuil <hverkuil@xs4all.nl> escreveu:

> On 05/08/2015 03:12 AM, Mauro Carvalho Chehab wrote:
> > Finally, let's rename the tuner entity. inside the media subsystem,
> > a tuner can be used by AM/FM radio, SDR radio, analog TV and digital TV.
> > It could even be used on other subsystems, like network, for wireless
> > devices.
> > 
> > So, it is not constricted to V4L2 API, or to a subdev.
> > 
> > Let's then rename it as:
> > 	MEDIA_ENT_T_V4L2_SUBDEV_TUNER -> MEDIA_ENT_T_TUNER
> 
> See patch 04/18.

Mapping the tuner as a V4L2_SUBDEV is plain wrong. We can't assume
that a tuner will always be mapped via V4L2 subdev API.

> 
> 	Hans
> 
> > 
> > Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
> > 
> > diff --git a/Documentation/DocBook/media/v4l/media-ioc-enum-entities.xml b/Documentation/DocBook/media/v4l/media-ioc-enum-entities.xml
> > index 9b3861058f0d..5c7f366bb1f4 100644
> > --- a/Documentation/DocBook/media/v4l/media-ioc-enum-entities.xml
> > +++ b/Documentation/DocBook/media/v4l/media-ioc-enum-entities.xml
> > @@ -241,7 +241,7 @@
> >  	    signals.</entry>
> >  	  </row>
> >  	  <row>
> > -	    <entry><constant>MEDIA_ENT_T_V4L2_SUBDEV_TUNER</constant></entry>
> > +	    <entry><constant>MEDIA_ENT_T_TUNER</constant></entry>
> >  	    <entry>TV and/or radio tuner</entry>
> >  	  </row>
> >  	</tbody>
> > diff --git a/drivers/media/dvb-core/dvbdev.c b/drivers/media/dvb-core/dvbdev.c
> > index 39846077045e..d6a096495035 100644
> > --- a/drivers/media/dvb-core/dvbdev.c
> > +++ b/drivers/media/dvb-core/dvbdev.c
> > @@ -393,7 +393,7 @@ void dvb_create_media_graph(struct dvb_adapter *adap)
> >  
> >  	media_device_for_each_entity(entity, mdev) {
> >  		switch (entity->type) {
> > -		case MEDIA_ENT_T_V4L2_SUBDEV_TUNER:
> > +		case MEDIA_ENT_T_TUNER:
> >  			tuner = entity;
> >  			break;
> >  		case MEDIA_ENT_T_DTV_DEMOD:
> > diff --git a/drivers/media/usb/cx231xx/cx231xx-cards.c b/drivers/media/usb/cx231xx/cx231xx-cards.c
> > index a756f74f0adc..2a7331e3c4a0 100644
> > --- a/drivers/media/usb/cx231xx/cx231xx-cards.c
> > +++ b/drivers/media/usb/cx231xx/cx231xx-cards.c
> > @@ -1213,7 +1213,7 @@ static void cx231xx_create_media_graph(struct cx231xx *dev)
> >  
> >  	media_device_for_each_entity(entity, mdev) {
> >  		switch (entity->type) {
> > -		case MEDIA_ENT_T_V4L2_SUBDEV_TUNER:
> > +		case MEDIA_ENT_T_TUNER:
> >  			tuner = entity;
> >  			break;
> >  		case MEDIA_ENT_T_ATV_DECODER:
> > diff --git a/drivers/media/v4l2-core/tuner-core.c b/drivers/media/v4l2-core/tuner-core.c
> > index abdcffabcb59..ecf4e8a543b3 100644
> > --- a/drivers/media/v4l2-core/tuner-core.c
> > +++ b/drivers/media/v4l2-core/tuner-core.c
> > @@ -696,7 +696,7 @@ static int tuner_probe(struct i2c_client *client,
> >  register_client:
> >  #if defined(CONFIG_MEDIA_CONTROLLER)
> >  	t->pad.flags = MEDIA_PAD_FL_SOURCE;
> > -	t->sd.entity.type = MEDIA_ENT_T_V4L2_SUBDEV_TUNER;
> > +	t->sd.entity.type = MEDIA_ENT_T_TUNER;
> >  	t->sd.entity.name = t->name;
> >  
> >  	ret = media_entity_init(&t->sd.entity, 1, &t->pad, 0);
> > diff --git a/include/uapi/linux/media.h b/include/uapi/linux/media.h
> > index 9b3d80e765f0..6acc4be1378c 100644
> > --- a/include/uapi/linux/media.h
> > +++ b/include/uapi/linux/media.h
> > @@ -57,7 +57,7 @@ struct media_device_info {
> >  
> >  #define MEDIA_ENT_T_ATV_DECODER	(MEDIA_ENT_T_CAM_SENSOR + 3)
> >  
> > -#define MEDIA_ENT_T_V4L2_SUBDEV_TUNER	(MEDIA_ENT_T_CAM_SENSOR + 4)
> > +#define MEDIA_ENT_T_TUNER	(MEDIA_ENT_T_CAM_SENSOR + 4)
> >  
> >  #if 1
> >  /*
> > @@ -88,6 +88,8 @@ struct media_device_info {
> >  #define MEDIA_ENT_T_V4L2_SUBDEV_LENS	MEDIA_ENT_T_CAM_LENS
> >  
> >  #define MEDIA_ENT_T_V4L2_SUBDEV_DECODER MEDIA_ENT_T_ATV_DECODER
> > +
> > +#define MEDIA_ENT_T_V4L2_SUBDEV_TUNER	MEDIA_ENT_T_TUNER
> >  #endif
> >  
> >  /* Used bitmasks for media_entity_desc::flags */
> > 
> 

Re: [PATCH 07/18] media controller: rename the tuner entity

[Hans Verkuil]

On 05/08/2015 02:57 PM, Mauro Carvalho Chehab wrote:
> Em Fri, 08 May 2015 14:13:22 +0200
> Hans Verkuil <hverkuil-qWit8jRvyhVmR6Xm/wNWPw@public.gmane.org> escreveu:
> 
>> On 05/08/2015 03:12 AM, Mauro Carvalho Chehab wrote:
>>> Finally, let's rename the tuner entity. inside the media subsystem,
>>> a tuner can be used by AM/FM radio, SDR radio, analog TV and digital TV.
>>> It could even be used on other subsystems, like network, for wireless
>>> devices.
>>>
>>> So, it is not constricted to V4L2 API, or to a subdev.
>>>
>>> Let's then rename it as:
>>> 	MEDIA_ENT_T_V4L2_SUBDEV_TUNER -> MEDIA_ENT_T_TUNER
>>
>> See patch 04/18.
> 
> Mapping the tuner as a V4L2_SUBDEV is plain wrong. We can't assume
> that a tuner will always be mapped via V4L2 subdev API.

True. Today we have subdevs that have no device node to control them, so
in that case it would just be a SUBDEV entity. There are subdevs that make
a v4l-subdev device node, so those can be V4L(2)_SUBDEV entities.

The question is: what are your ideas for e.g. DVB-only tuners? Would they
get a DVB-like device node? (so DTV_SUBDEV) Would hybrid tuners have two
device nodes? One v4l-subdev, one dvb/dtv-subdev?

Just curious what your thoughts are.

Brainstorming:

It might be better to map each device node to an entity and each hardware
component (tuner, DMA engine) to an entity, and avoid this mixing of
hw entity vs device node entity.

Hmm, we need a another brainstorm meeting...

Regards,

	Hans

Re: [PATCH 07/18] media controller: rename the tuner entity

[Mauro Carvalho Chehab]

Em Fri, 08 May 2015 15:21:39 +0200
Hans Verkuil <hverkuil-qWit8jRvyhVmR6Xm/wNWPw@public.gmane.org> escreveu:

> On 05/08/2015 02:57 PM, Mauro Carvalho Chehab wrote:
> > Em Fri, 08 May 2015 14:13:22 +0200
> > Hans Verkuil <hverkuil-qWit8jRvyhVmR6Xm/wNWPw@public.gmane.org> escreveu:
> > 
> >> On 05/08/2015 03:12 AM, Mauro Carvalho Chehab wrote:
> >>> Finally, let's rename the tuner entity. inside the media subsystem,
> >>> a tuner can be used by AM/FM radio, SDR radio, analog TV and digital TV.
> >>> It could even be used on other subsystems, like network, for wireless
> >>> devices.
> >>>
> >>> So, it is not constricted to V4L2 API, or to a subdev.
> >>>
> >>> Let's then rename it as:
> >>> 	MEDIA_ENT_T_V4L2_SUBDEV_TUNER -> MEDIA_ENT_T_TUNER
> >>
> >> See patch 04/18.
> > 
> > Mapping the tuner as a V4L2_SUBDEV is plain wrong. We can't assume
> > that a tuner will always be mapped via V4L2 subdev API.
> 
> True. Today we have subdevs that have no device node to control them, so
> in that case it would just be a SUBDEV entity. There are subdevs that make
> a v4l-subdev device node, so those can be V4L(2)_SUBDEV entities.
> 
> The question is: what are your ideas for e.g. DVB-only tuners? Would they
> get a DVB-like device node? (so DTV_SUBDEV)

I guess we may need DVB subdevs in the future. For now, I don't see
much usage.

> Would hybrid tuners have two
> device nodes? One v4l-subdev, one dvb/dtv-subdev?

No. A tuner is a tuner. The very same device can be used for analog or
digital TV. Ok, there are tuners that only work for digital TV (satellite
tuners, typically), because satellite requires a different tuning range,
and require an extra hardware to power up the satellite antena. So, on
most devices, the tuner is integrated with SEC.

In any case, I don't see any reason why artificially one piece of hardware
component (tuner) into one subdevice entity per API.

What it might make sense in the future is to have some DVB-specific ioctls
for a hybrid tuner,  in order to allow adjusting its internal filters to
an specific digital TV standard.

> Just curious what your thoughts are.
> 
> Brainstorming:
> 
> It might be better to map each device node to an entity and each hardware
> component (tuner, DMA engine) to an entity, and avoid this mixing of
> hw entity vs device node entity.

Ok, but then we need to properly define the namespaces for HW and for
Linux API components.

So, we would have a namespace like:
 
	- ENT_T_DEVNODE_DVB_(FE|CA|NET|DEMUX|DVR) for the DVB API device nodes;
	- ENT_T_DEVNODE_V4L for the radio/swradio/video/vbi devnodes, or,
alternatively, use ENT_T_DEVNODE_V4L_(RADIO|SWRADIO|VIDEO|VBI);
	- ENT_T_HW_(TUNER|CAM_SENSOR|ATV_DEMOD|DTV_DEMOD|...) for the
hardware components.

In other words, the namespace would actually define two subtypes:
	- devnodes;
	- hardware components

There's one advantage on this strategy: it is easier to keep backward
compatibility, IMHO, as we'll be preserving 1 << 16 for device nodes
and 2 << 16 for hardware components.

Yet, we'll need to add an entity for the V4L2 hardware DMA (with makes
sense to me), and this might break backward compatibility if not done
well.

It should be said that, in such case, hardware components will then
mean not only V4L2-specific hardware (V4L2_SUBDEV_foo), but also DVB,
ALSA, ... components.

So, we'll still need a way to identify what of those components are
V4L2 subdevs, probably using the properties API.

If you all agree with that, I'll respin the patch series to map the
entities like that.

Regards,
Mauro


> 
> Hmm, we need a another brainstorm meeting...
> 
> Regards,
> 
> 	Hans

Re: [PATCH 07/18] media controller: rename the tuner entity

[Hans Verkuil]

On 05/08/2015 04:08 PM, Mauro Carvalho Chehab wrote:
> Em Fri, 08 May 2015 15:21:39 +0200
> Hans Verkuil <hverkuil-qWit8jRvyhVmR6Xm/wNWPw@public.gmane.org> escreveu:
> 
>> On 05/08/2015 02:57 PM, Mauro Carvalho Chehab wrote:
>>> Em Fri, 08 May 2015 14:13:22 +0200
>>> Hans Verkuil <hverkuil-qWit8jRvyhVmR6Xm/wNWPw@public.gmane.org> escreveu:
>>>
>>>> On 05/08/2015 03:12 AM, Mauro Carvalho Chehab wrote:
>>>>> Finally, let's rename the tuner entity. inside the media subsystem,
>>>>> a tuner can be used by AM/FM radio, SDR radio, analog TV and digital TV.
>>>>> It could even be used on other subsystems, like network, for wireless
>>>>> devices.
>>>>>
>>>>> So, it is not constricted to V4L2 API, or to a subdev.
>>>>>
>>>>> Let's then rename it as:
>>>>> 	MEDIA_ENT_T_V4L2_SUBDEV_TUNER -> MEDIA_ENT_T_TUNER
>>>>
>>>> See patch 04/18.
>>>
>>> Mapping the tuner as a V4L2_SUBDEV is plain wrong. We can't assume
>>> that a tuner will always be mapped via V4L2 subdev API.
>>
>> True. Today we have subdevs that have no device node to control them, so
>> in that case it would just be a SUBDEV entity. There are subdevs that make
>> a v4l-subdev device node, so those can be V4L(2)_SUBDEV entities.
>>
>> The question is: what are your ideas for e.g. DVB-only tuners? Would they
>> get a DVB-like device node? (so DTV_SUBDEV)
> 
> I guess we may need DVB subdevs in the future. For now, I don't see
> much usage.
> 
>> Would hybrid tuners have two
>> device nodes? One v4l-subdev, one dvb/dtv-subdev?
> 
> No. A tuner is a tuner. The very same device can be used for analog or
> digital TV. Ok, there are tuners that only work for digital TV (satellite
> tuners, typically), because satellite requires a different tuning range,
> and require an extra hardware to power up the satellite antena. So, on
> most devices, the tuner is integrated with SEC.
> 
> In any case, I don't see any reason why artificially one piece of hardware
> component (tuner) into one subdevice entity per API.
> 
> What it might make sense in the future is to have some DVB-specific ioctls
> for a hybrid tuner,  in order to allow adjusting its internal filters to
> an specific digital TV standard.
> 
>> Just curious what your thoughts are.
>>
>> Brainstorming:
>>
>> It might be better to map each device node to an entity and each hardware
>> component (tuner, DMA engine) to an entity, and avoid this mixing of
>> hw entity vs device node entity.
> 
> Ok, but then we need to properly define the namespaces for HW and for
> Linux API components.
> 
> So, we would have a namespace like:
>  
> 	- ENT_T_DEVNODE_DVB_(FE|CA|NET|DEMUX|DVR) for the DVB API device nodes;
> 	- ENT_T_DEVNODE_V4L for the radio/swradio/video/vbi devnodes, or,
> alternatively, use ENT_T_DEVNODE_V4L_(RADIO|SWRADIO|VIDEO|VBI);
> 	- ENT_T_HW_(TUNER|CAM_SENSOR|ATV_DEMOD|DTV_DEMOD|...) for the
> hardware components.
> 
> In other words, the namespace would actually define two subtypes:
> 	- devnodes;
> 	- hardware components
> 
> There's one advantage on this strategy: it is easier to keep backward
> compatibility, IMHO, as we'll be preserving 1 << 16 for device nodes

Right, that will work.

> and 2 << 16 for hardware components.

This remains problematic since I believe this should be done as a list
of properties. Instead the entity type would be ENT_T_HW (if it represents
actual hardware), ENT_T_SW (if it is a software implementation, for example
for the DVB demux if there is no HW demux), and perhaps ENT_T_IP for
representing IP blocks (not sure about this one).

And the properties will tell what functions it supports.

The existing 2 << 16 defines would only be used if the property list matches
the original meaning of the define to keep it backwards compatible.

> 
> Yet, we'll need to add an entity for the V4L2 hardware DMA (with makes
> sense to me), and this might break backward compatibility if not done
> well.

I see this as a property as well, but otherwise I agree with this.

> 
> It should be said that, in such case, hardware components will then
> mean not only V4L2-specific hardware (V4L2_SUBDEV_foo), but also DVB,
> ALSA, ... components.
> 
> So, we'll still need a way to identify what of those components are
> V4L2 subdevs, probably using the properties API.

Why? A hardware component that can be controlled via a v4l-subdev node
would be linked to an entity for that v4l-subdev node. That's an API
entity. The whole 'is this a v4l-subdev' question disappears, since that
is now no longer relevant. Instead you will have an ENT_T_DEVNODE_V4L_SUBDEV
entity linked to the hw entity.

Even a radio device would fit cleanly into this: the tuner entity simply
has a link to a radio device node entity.

Hmm, does this also solve the control vs DMA issue? If a DEVNODE entity
is hooked up to an entity with the DMA functionality, then you can stream,
otherwise it is just for control.

I'm not sure if this is always true, though. Of course, we can also just
add the streaming/dma property to the DEVNODE entity as well.

> If you all agree with that, I'll respin the patch series to map the
> entities like that.

We can interpret the existing ENT_T_HW_TUNER etc. as shorthand for a
property while the property API isn't there yet (we need that anyway
for backwards compat).

So we would need to add a ENT_T_HW_DMA as well (to be replaced by a
property later).

Basically I see the 1 << 16 range as device node types, the 2 << 16 range
as shorthands for what should be properties (this really defined functions
and entities can combine multiple functions), and we would need to have a
new range (4 << 16) for non-DEVNODE entity types. Although we could keep
it in range 1 << 16 as well, but I think it might make sense to keep it
separate.

And there you would get ENT_T_HW/SW/IP (not sure about the last one). And
perhaps FPGA.

Again, just brainstorming here.

Regards,

	Hans

Re: [PATCH 07/18] media controller: rename the tuner entity

[Mauro Carvalho Chehab]

Em Fri, 08 May 2015 16:32:03 +0200
Hans Verkuil <hverkuil@xs4all.nl> escreveu:

> On 05/08/2015 04:08 PM, Mauro Carvalho Chehab wrote:
> > Em Fri, 08 May 2015 15:21:39 +0200
> > Hans Verkuil <hverkuil@xs4all.nl> escreveu:
> > 
> >> On 05/08/2015 02:57 PM, Mauro Carvalho Chehab wrote:
> >>> Em Fri, 08 May 2015 14:13:22 +0200
> >>> Hans Verkuil <hverkuil@xs4all.nl> escreveu:
> >>>
> >>>> On 05/08/2015 03:12 AM, Mauro Carvalho Chehab wrote:
> >>>>> Finally, let's rename the tuner entity. inside the media subsystem,
> >>>>> a tuner can be used by AM/FM radio, SDR radio, analog TV and digital TV.
> >>>>> It could even be used on other subsystems, like network, for wireless
> >>>>> devices.
> >>>>>
> >>>>> So, it is not constricted to V4L2 API, or to a subdev.
> >>>>>
> >>>>> Let's then rename it as:
> >>>>> 	MEDIA_ENT_T_V4L2_SUBDEV_TUNER -> MEDIA_ENT_T_TUNER
> >>>>
> >>>> See patch 04/18.
> >>>
> >>> Mapping the tuner as a V4L2_SUBDEV is plain wrong. We can't assume
> >>> that a tuner will always be mapped via V4L2 subdev API.
> >>
> >> True. Today we have subdevs that have no device node to control them, so
> >> in that case it would just be a SUBDEV entity. There are subdevs that make
> >> a v4l-subdev device node, so those can be V4L(2)_SUBDEV entities.
> >>
> >> The question is: what are your ideas for e.g. DVB-only tuners? Would they
> >> get a DVB-like device node? (so DTV_SUBDEV)
> > 
> > I guess we may need DVB subdevs in the future. For now, I don't see
> > much usage.
> > 
> >> Would hybrid tuners have two
> >> device nodes? One v4l-subdev, one dvb/dtv-subdev?
> > 
> > No. A tuner is a tuner. The very same device can be used for analog or
> > digital TV. Ok, there are tuners that only work for digital TV (satellite
> > tuners, typically), because satellite requires a different tuning range,
> > and require an extra hardware to power up the satellite antena. So, on
> > most devices, the tuner is integrated with SEC.
> > 
> > In any case, I don't see any reason why artificially one piece of hardware
> > component (tuner) into one subdevice entity per API.
> > 
> > What it might make sense in the future is to have some DVB-specific ioctls
> > for a hybrid tuner,  in order to allow adjusting its internal filters to
> > an specific digital TV standard.
> > 
> >> Just curious what your thoughts are.
> >>
> >> Brainstorming:
> >>
> >> It might be better to map each device node to an entity and each hardware
> >> component (tuner, DMA engine) to an entity, and avoid this mixing of
> >> hw entity vs device node entity.
> > 
> > Ok, but then we need to properly define the namespaces for HW and for
> > Linux API components.
> > 
> > So, we would have a namespace like:
> >  
> > 	- ENT_T_DEVNODE_DVB_(FE|CA|NET|DEMUX|DVR) for the DVB API device nodes;
> > 	- ENT_T_DEVNODE_V4L for the radio/swradio/video/vbi devnodes, or,
> > alternatively, use ENT_T_DEVNODE_V4L_(RADIO|SWRADIO|VIDEO|VBI);
> > 	- ENT_T_HW_(TUNER|CAM_SENSOR|ATV_DEMOD|DTV_DEMOD|...) for the
> > hardware components.
> > 
> > In other words, the namespace would actually define two subtypes:
> > 	- devnodes;
> > 	- hardware components
> > 
> > There's one advantage on this strategy: it is easier to keep backward
> > compatibility, IMHO, as we'll be preserving 1 << 16 for device nodes
> 
> Right, that will work.
> 
> > and 2 << 16 for hardware components.
> 
> This remains problematic since I believe this should be done as a list
> of properties. Instead the entity type would be ENT_T_HW (if it represents
> actual hardware), ENT_T_SW (if it is a software implementation, for example
> for the DVB demux if there is no HW demux), and perhaps ENT_T_IP for
> representing IP blocks (not sure about this one).

I don't think we should distinguish IP block from HW. I would also use
a different namespace for SW implementation like the DVB demux or
for API devnodes.

Perhaps:
	ENT_T_API - for non-subdev API device nodes;
	ENT_T_HW - for hardware/firmware/IP blocks;
	ENT_T_SW - for software emulation blocks like DVB demux

I would not map subdev API as a separate entity, as those should have
a 1:1 map to the entity. So, a property (or a flag) should be enough
to indicate that either a ENT_T_HW_ or a ENT_T_SW_ is exposed via a
subdev.

With regards to the API mapping, I would have a set of properties that
would be grouping V4L2, subdev, DVB, ... parts of the API.

So, for example, if the entity that represents a video devnode
controls the tuner, the analog demod and the DMA engine, such
entity would have 3 properties:
	- ENT_PROP_V4L2_TUNER
	- ENT_PROP_V4L2_ATV_DEMOD
	- ENT_PROP_V4L2_DMA

> And the properties will tell what functions it supports.

Yes, but, as the API right now groups the subtypes, it would
be better to keep it splitted, not for userspace to use this as
subtype. Just as a matter of keeping things well organized.

I mean, if you take a look at the resulting namespace after all
those patches I wrote, the end result is:

#define MEDIA_ENT_T_UNKNOWN	0

#define MEDIA_ENT_T_AV_DMA		(((1 << 16)) + 1)
#define MEDIA_ENT_T_DTV_DEMOD	(MEDIA_ENT_T_AV_DMA + 3)
#define MEDIA_ENT_T_DTV_DEMUX	(MEDIA_ENT_T_AV_DMA + 4)
#define MEDIA_ENT_T_DTV_DVR	(MEDIA_ENT_T_AV_DMA + 5)
#define MEDIA_ENT_T_DTV_CA	(MEDIA_ENT_T_AV_DMA + 6)
#define MEDIA_ENT_T_DTV_NET	(MEDIA_ENT_T_AV_DMA + 7)

#define MEDIA_ENT_T_CAM_SENSOR	((2 << 16) + 1)
#define MEDIA_ENT_T_CAM_FLASH	(MEDIA_ENT_T_CAM_SENSOR + 1)
#define MEDIA_ENT_T_CAM_LENS	(MEDIA_ENT_T_CAM_SENSOR + 2)
#define MEDIA_ENT_T_ATV_DECODER	(MEDIA_ENT_T_CAM_SENSOR + 3)
#define MEDIA_ENT_T_TUNER	(MEDIA_ENT_T_CAM_SENSOR + 4)

We cannot renumber them, or otherwise things will break. So, we'll have
to deal with at least 2 number spaces: 1 << 16 and 2 << 16.

If we use the 1<<16 number space for ENT_T_API and the 2<<16 for
ENT_T_HW, the above will keep fitting, and it will be easier to maintain,
as we'll be grouping by name.

> The existing 2 << 16 defines would only be used if the property list matches
> the original meaning of the define to keep it backwards compatible.
> 
> > 
> > Yet, we'll need to add an entity for the V4L2 hardware DMA (with makes
> > sense to me), and this might break backward compatibility if not done
> > well.
> 
> I see this as a property as well, but otherwise I agree with this.

Yes, this could be a property.

> > 
> > It should be said that, in such case, hardware components will then
> > mean not only V4L2-specific hardware (V4L2_SUBDEV_foo), but also DVB,
> > ALSA, ... components.
> > 
> > So, we'll still need a way to identify what of those components are
> > V4L2 subdevs, probably using the properties API.
> 
> Why? A hardware component that can be controlled via a v4l-subdev node
> would be linked to an entity for that v4l-subdev node. That's an API
> entity. The whole 'is this a v4l-subdev' question disappears, since that
> is now no longer relevant. Instead you will have an ENT_T_DEVNODE_V4L_SUBDEV
> entity linked to the hw entity.

I see V4L_SUBDEV as a set of properties, specifying exactly what group
of subdev ioctls controls an specific hardware entity.

> Even a radio device would fit cleanly into this: the tuner entity simply
> has a link to a radio device node entity.

Yes.

> Hmm, does this also solve the control vs DMA issue? If a DEVNODE entity
> is hooked up to an entity with the DMA functionality, then you can stream,
> otherwise it is just for control.

Probably yes.

> I'm not sure if this is always true, though. Of course, we can also just
> add the streaming/dma property to the DEVNODE entity as well.
> 
> > If you all agree with that, I'll respin the patch series to map the
> > entities like that.
> 
> We can interpret the existing ENT_T_HW_TUNER etc. as shorthand for a
> property while the property API isn't there yet (we need that anyway
> for backwards compat).

I do prefer using a switch() like I did on patch 10/18, specifying the
entities that belong to subdev. After we add the property API, we can
convert is_media_entity_v4l2_subdev and is_media_entity_av_dma (with
should likely be renamed to is_media_entity_v4l_dma) to use the
properties API.

I don't think we'll need to create a separate number space for the new
entities in order to be backward-compatible.

> 
> So we would need to add a ENT_T_HW_DMA as well (to be replaced by a
> property later).

Let's add this directly when we add the Property API.

> Basically I see the 1 << 16 range as device node types, the 2 << 16 range
> as shorthands for what should be properties (this really defined functions
> and entities can combine multiple functions), and we would need to have a
> new range (4 << 16) for non-DEVNODE entity types. Although we could keep
> it in range 1 << 16 as well, but I think it might make sense to keep it
> separate.

Keeping a backward-compatible separate range would create messy graphs.
I don't think we should do it.

> 
> And there you would get ENT_T_HW/SW/IP (not sure about the last one). And
> perhaps FPGA.
> 
> Again, just brainstorming here.
> 
> Regards,
> 
> 	Hans

Re: [PATCH 07/18] media controller: rename the tuner entity

[Hans Verkuil]

>>> Brainstorming:
>>>
>>> It might be better to map each device node to an entity and each hardware
>>> component (tuner, DMA engine) to an entity, and avoid this mixing of
>>> hw entity vs device node entity.

There are two options here:

either make each device node an entity, or expose the device node information
as properties of an entity.

The latter would be backwards compatible with what we do today. I'm trying to
think of reasons why you would want to make each device node an entity in its
own right.

The problem today is that a video_device representing a video/vbi/radio/swradio
device node is an entity, but it is really representing the dma engine. Which
is weird for radio devices since there is no dma engine there.

Implementing device nodes as entities in their own right does solve this problem,
but implementing it as properties would be weird since a radio device node would
be a property of a radio tuner entity, which can be a subdevice driver which means
that the bridge driver would have to add the radio device property to a subdev
driver, which feels really wrong to me.

With this in mind I do think representing device nodes as entities in their own
right makes sense. But I would do this also for a v4l-subdev node. It's very
inconsistent not to do that.

Regards,

	Hans

Re: [PATCH 07/18] media controller: rename the tuner entity

[Mauro Carvalho Chehab]

Em Sat, 09 May 2015 11:31:42 +0200
Hans Verkuil <hverkuil@xs4all.nl> escreveu:

> >>> Brainstorming:
> >>>
> >>> It might be better to map each device node to an entity and each hardware
> >>> component (tuner, DMA engine) to an entity, and avoid this mixing of
> >>> hw entity vs device node entity.
> 
> There are two options here:
> 
> either make each device node an entity, or expose the device node information
> as properties of an entity.
> 
> The latter would be backwards compatible with what we do today. I'm trying to
> think of reasons why you would want to make each device node an entity in its
> own right.
> 
> The problem today is that a video_device representing a video/vbi/radio/swradio
> device node is an entity, but it is really representing the dma engine. Which
> is weird for radio devices since there is no dma engine there.
> 
> Implementing device nodes as entities in their own right does solve this problem,
> but implementing it as properties would be weird since a radio device node would
> be a property of a radio tuner entity, which can be a subdevice driver which means
> that the bridge driver would have to add the radio device property to a subdev
> driver, which feels really wrong to me.
> 
> With this in mind I do think representing device nodes as entities in their own
> right makes sense.

I agree with that: devnodes should be entities, as they're the points to control
the hardware, and need to be known by the Kernel, no matter if they have DMA
engines associated with it or not. The better seems to map the DMA engine
as a property on those entities.

> But I would do this also for a v4l-subdev node. It's very
> inconsistent not to do that.

It should be easy to create an entity for each v4l-subdev node. I just
don't see much usage on it, and this will almost double the number of
entities. Also, in order to keep it backward-compatible, both the subdev
devnode and the subdev no-devnode entity should accept the same set of
ioctls.

Regards,
Mauro

Re: [PATCH 07/18] media controller: rename the tuner entity

[Hans Verkuil]

On 05/11/2015 11:31 AM, Mauro Carvalho Chehab wrote:
> Em Sat, 09 May 2015 11:31:42 +0200
> Hans Verkuil <hverkuil-qWit8jRvyhVmR6Xm/wNWPw@public.gmane.org> escreveu:
> 
>>>>> Brainstorming:
>>>>>
>>>>> It might be better to map each device node to an entity and each hardware
>>>>> component (tuner, DMA engine) to an entity, and avoid this mixing of
>>>>> hw entity vs device node entity.
>>
>> There are two options here:
>>
>> either make each device node an entity, or expose the device node information
>> as properties of an entity.
>>
>> The latter would be backwards compatible with what we do today. I'm trying to
>> think of reasons why you would want to make each device node an entity in its
>> own right.
>>
>> The problem today is that a video_device representing a video/vbi/radio/swradio
>> device node is an entity, but it is really representing the dma engine. Which
>> is weird for radio devices since there is no dma engine there.
>>
>> Implementing device nodes as entities in their own right does solve this problem,
>> but implementing it as properties would be weird since a radio device node would
>> be a property of a radio tuner entity, which can be a subdevice driver which means
>> that the bridge driver would have to add the radio device property to a subdev
>> driver, which feels really wrong to me.
>>
>> With this in mind I do think representing device nodes as entities in their own
>> right makes sense.
> 
> I agree with that: devnodes should be entities, as they're the points to control
> the hardware, and need to be known by the Kernel, no matter if they have DMA
> engines associated with it or not. The better seems to map the DMA engine
> as a property on those entities.
> 
>> But I would do this also for a v4l-subdev node. It's very
>> inconsistent not to do that.
> 
> It should be easy to create an entity for each v4l-subdev node. I just
> don't see much usage on it, and this will almost double the number of
> entities.

The memory is already allocated for that since it is part of struct video_device,
which v4l-subdev uses. So I don't see this as a problem.

> Also, in order to keep it backward-compatible, both the subdev
> devnode and the subdev no-devnode entity should accept the same set of
> ioctls.

The ioctls always go through the video_device, that will not be changed by
this.

But I agree that there are other backward-compat issues. Unfortunately I cannot
dedicate much time on this at the moment.

Regards,

	Hans

[PATCH 08/18] media controller: add comments for the entity types

[Mauro Carvalho Chehab]

Better document the linux/media.h UAPI header, by adding
comments to each entity subtype.

Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>

diff --git a/include/uapi/linux/media.h b/include/uapi/linux/media.h
index 6acc4be1378c..8d47b70b7ea8 100644
--- a/include/uapi/linux/media.h
+++ b/include/uapi/linux/media.h
@@ -44,19 +44,25 @@ struct media_device_info {
 
 /* Used values for media_entity_desc::type */
 
+/* Audio/video streaming bridges */
 #define MEDIA_ENT_T_AV_DMA		(((1 << 16)) + 1)
+
+/* Digital TV entities */
 #define MEDIA_ENT_T_DTV_DEMOD	(MEDIA_ENT_T_AV_DMA + 3)
 #define MEDIA_ENT_T_DTV_DEMUX	(MEDIA_ENT_T_AV_DMA + 4)
 #define MEDIA_ENT_T_DTV_DVR	(MEDIA_ENT_T_AV_DMA + 5)
 #define MEDIA_ENT_T_DTV_CA	(MEDIA_ENT_T_AV_DMA + 6)
 #define MEDIA_ENT_T_DTV_NET	(MEDIA_ENT_T_AV_DMA + 7)
 
+/* Camera entities */
 #define MEDIA_ENT_T_CAM_SENSOR	((2 << 16) + 1)
 #define MEDIA_ENT_T_CAM_FLASH	(MEDIA_ENT_T_CAM_SENSOR + 1)
 #define MEDIA_ENT_T_CAM_LENS	(MEDIA_ENT_T_CAM_SENSOR + 2)
 
+/* Analog TV entities */
 #define MEDIA_ENT_T_ATV_DECODER	(MEDIA_ENT_T_CAM_SENSOR + 3)
 
+/* Radio, Analog TV and/or Digital TV tuners */
 #define MEDIA_ENT_T_TUNER	(MEDIA_ENT_T_CAM_SENSOR + 4)
 
 #if 1
-- 
2.1.0

[PATCH 03/18] media controller: use MEDIA_ENT_T_AV_DMA for A/V DMA engines

[Mauro Carvalho Chehab]

At the Video4Linux API, the /dev/video?, /dev/vbi? and
/dev/radio? device nodes are used for the chipset that
provides the bridge between video/radio streams and the
USB, PCI or CPU buses.

Such bridge is also typically used to control the V4L2 device
as a hole.

For video streaming devices and SDR radio devices, they're
also associated with the DMA engines that transfer the
video stream (or SDR stream) to the CPU's memory.

It should be noticed, however, this is not true on non-SDR
radio devices, and may also not be true on embedded devices
that, due to DRM reasons, don't allow writing unencrypted
data on a memory that could be seen by the CPU.

So, we'll eventually need to add another entity for such
bridge chipsets that have a video/vbi/radio device node
associated, but don't have DMA engines on (some) devnodes.

As, currently, we don't have any such case, let's for now
just rename the device nodes that are associated with a
DMA engine as MEDIA_ENT_T_AV_DMA.

So,
	MEDIA_ENT_T_DEVNODE_V4L -> MEDIA_ENT_T_AV_DMA

PS.: This is not actually true for USB devices, as the
DMA engine is an internal component, as it is up to the
Kernel to strip the stream payload from the URB packages.

Signed-off-by: Mauro Carvalho Chehab <mchehab-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org>

diff --git a/Documentation/DocBook/media/v4l/media-ioc-enum-entities.xml b/Documentation/DocBook/media/v4l/media-ioc-enum-entities.xml
index 5872f8bbf774..5b8147629159 100644
--- a/Documentation/DocBook/media/v4l/media-ioc-enum-entities.xml
+++ b/Documentation/DocBook/media/v4l/media-ioc-enum-entities.xml
@@ -183,7 +183,7 @@
 	    <entry>Unknown device node</entry>
 	  </row>
 	  <row>
-	    <entry><constant>MEDIA_ENT_T_DEVNODE_V4L</constant></entry>
+	    <entry><constant>MEDIA_ENT_T_AV_DMA</constant></entry>
 	    <entry>V4L video, radio or vbi device node</entry>
 	  </row>
 	  <row>
diff --git a/drivers/media/platform/xilinx/xilinx-dma.c b/drivers/media/platform/xilinx/xilinx-dma.c
index efde88adf624..7fa0cc0f08f0 100644
--- a/drivers/media/platform/xilinx/xilinx-dma.c
+++ b/drivers/media/platform/xilinx/xilinx-dma.c
@@ -193,7 +193,7 @@ static int xvip_pipeline_validate(struct xvip_pipeline *pipe,
 	while ((entity = media_entity_graph_walk_next(&graph))) {
 		struct xvip_dma *dma;
 
-		if (entity->type != MEDIA_ENT_T_DEVNODE_V4L)
+		if (entity->type != MEDIA_ENT_T_AV_DMA)
 			continue;
 
 		dma = to_xvip_dma(media_entity_to_video_device(entity));
diff --git a/drivers/media/v4l2-core/v4l2-dev.c b/drivers/media/v4l2-core/v4l2-dev.c
index 71a1b93b0790..9ef920221b5a 100644
--- a/drivers/media/v4l2-core/v4l2-dev.c
+++ b/drivers/media/v4l2-core/v4l2-dev.c
@@ -912,7 +912,7 @@ int __video_register_device(struct video_device *vdev, int type, int nr,
 	/* Part 5: Register the entity. */
 	if (vdev->v4l2_dev->mdev &&
 	    vdev->vfl_type != VFL_TYPE_SUBDEV) {
-		vdev->entity.type = MEDIA_ENT_T_DEVNODE_V4L;
+		vdev->entity.type = MEDIA_ENT_T_AV_DMA;
 		vdev->entity.name = vdev->name;
 		vdev->entity.info.dev.major = VIDEO_MAJOR;
 		vdev->entity.info.dev.minor = vdev->minor;
diff --git a/drivers/media/v4l2-core/v4l2-subdev.c b/drivers/media/v4l2-core/v4l2-subdev.c
index 63596063b213..9f8fc8330b3e 100644
--- a/drivers/media/v4l2-core/v4l2-subdev.c
+++ b/drivers/media/v4l2-core/v4l2-subdev.c
@@ -535,7 +535,7 @@ v4l2_subdev_link_validate_get_format(struct media_pad *pad,
 		return v4l2_subdev_call(sd, pad, get_fmt, NULL, fmt);
 	}
 
-	WARN(pad->entity->type != MEDIA_ENT_T_DEVNODE_V4L,
+	WARN(pad->entity->type != MEDIA_ENT_T_AV_DMA,
 	     "Driver bug! Wrong media entity type 0x%08x, entity %s\n",
 	     pad->entity->type, pad->entity->name);
 
diff --git a/include/uapi/linux/media.h b/include/uapi/linux/media.h
index 775c11c6b173..a7aa2aac9c23 100644
--- a/include/uapi/linux/media.h
+++ b/include/uapi/linux/media.h
@@ -44,12 +44,12 @@ struct media_device_info {
 
 /* Used values for media_entity_desc::type */
 
-#define MEDIA_ENT_T_DEVNODE_V4L		(((1 << 16)) + 1)
-#define MEDIA_ENT_T_DEVNODE_DVB_FE	(MEDIA_ENT_T_DEVNODE_V4L + 3)
-#define MEDIA_ENT_T_DEVNODE_DVB_DEMUX	(MEDIA_ENT_T_DEVNODE_V4L + 4)
-#define MEDIA_ENT_T_DEVNODE_DVB_DVR	(MEDIA_ENT_T_DEVNODE_V4L + 5)
-#define MEDIA_ENT_T_DEVNODE_DVB_CA	(MEDIA_ENT_T_DEVNODE_V4L + 6)
-#define MEDIA_ENT_T_DEVNODE_DVB_NET	(MEDIA_ENT_T_DEVNODE_V4L + 7)
+#define MEDIA_ENT_T_AV_DMA		(((1 << 16)) + 1)
+#define MEDIA_ENT_T_DEVNODE_DVB_FE	(MEDIA_ENT_T_AV_DMA + 3)
+#define MEDIA_ENT_T_DEVNODE_DVB_DEMUX	(MEDIA_ENT_T_AV_DMA + 4)
+#define MEDIA_ENT_T_DEVNODE_DVB_DVR	(MEDIA_ENT_T_AV_DMA + 5)
+#define MEDIA_ENT_T_DEVNODE_DVB_CA	(MEDIA_ENT_T_AV_DMA + 6)
+#define MEDIA_ENT_T_DEVNODE_DVB_NET	(MEDIA_ENT_T_AV_DMA + 7)
 
 #define MEDIA_ENT_T_V4L2_SUBDEV_SENSOR	((2 << 16) + 1)
 #define MEDIA_ENT_T_V4L2_SUBDEV_FLASH	(MEDIA_ENT_T_V4L2_SUBDEV_SENSOR + 1)
-- 
2.1.0

Re: [PATCH 03/18] media controller: use MEDIA_ENT_T_AV_DMA for A/V DMA engines

[Hans Verkuil]

On 05/08/2015 03:12 AM, Mauro Carvalho Chehab wrote:
> At the Video4Linux API, the /dev/video?, /dev/vbi? and
> /dev/radio? device nodes are used for the chipset that

You should add /dev/swradio? for SDR devices.

> provides the bridge between video/radio streams and the
> USB, PCI or CPU buses.
> 
> Such bridge is also typically used to control the V4L2 device
> as a hole.

hole -> whole

> 
> For video streaming devices and SDR radio devices, they're
> also associated with the DMA engines that transfer the
> video stream (or SDR stream) to the CPU's memory.
> 
> It should be noticed, however, this is not true on non-SDR
> radio devices,

I think you forgot that SDR devices are not using /dev/radio
but /dev/swradio. They have different names. Radio devices never
stream (OK, I think there are one or two exceptions, but that's really
because nobody bothered to make an alsa driver. Those boards are
in practice out of spec.)

> and may also not be true on embedded devices
> that, due to DRM reasons, don't allow writing unencrypted
> data on a memory that could be seen by the CPU.

This actually might still work by using opaque DMABUF handles. But that's
under discussion right now in the Secure Data Path thread.

Another reason can also be that the SoC vendor re-invented the wheel
and made there own DMA streaming solution. You can still make V4L drivers
that control the video receivers/transmitters, but for the actual streaming
you are forced to use the vendor's crap code (hello TI!).

I've bitter experiences with that :-(
 
> So, we'll eventually need to add another entity for such
> bridge chipsets that have a video/vbi/radio device node
> associated, but don't have DMA engines on (some) devnodes.
> 
> As, currently, we don't have any such case,

??? Radio devices are exactly that.

> let's for now
> just rename the device nodes that are associated with a
> DMA engine as MEDIA_ENT_T_AV_DMA.
> 
> So,
> 	MEDIA_ENT_T_DEVNODE_V4L -> MEDIA_ENT_T_AV_DMA
> 
> PS.: This is not actually true for USB devices, as the
> DMA engine is an internal component, as it is up to the
> Kernel to strip the stream payload from the URB packages.

How about MEDIA_ENT_T_DATA_STREAMING? Or perhaps DATA_IO? Perhaps even just
"IO"?

That would cover USB as well, and I dislike the use of "AV", since the
data might contain other things besides audio and/or video.

Regards,

	Hans

> 
> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
> 
> diff --git a/Documentation/DocBook/media/v4l/media-ioc-enum-entities.xml b/Documentation/DocBook/media/v4l/media-ioc-enum-entities.xml
> index 5872f8bbf774..5b8147629159 100644
> --- a/Documentation/DocBook/media/v4l/media-ioc-enum-entities.xml
> +++ b/Documentation/DocBook/media/v4l/media-ioc-enum-entities.xml
> @@ -183,7 +183,7 @@
>  	    <entry>Unknown device node</entry>
>  	  </row>
>  	  <row>
> -	    <entry><constant>MEDIA_ENT_T_DEVNODE_V4L</constant></entry>
> +	    <entry><constant>MEDIA_ENT_T_AV_DMA</constant></entry>
>  	    <entry>V4L video, radio or vbi device node</entry>
>  	  </row>
>  	  <row>
> diff --git a/drivers/media/platform/xilinx/xilinx-dma.c b/drivers/media/platform/xilinx/xilinx-dma.c
> index efde88adf624..7fa0cc0f08f0 100644
> --- a/drivers/media/platform/xilinx/xilinx-dma.c
> +++ b/drivers/media/platform/xilinx/xilinx-dma.c
> @@ -193,7 +193,7 @@ static int xvip_pipeline_validate(struct xvip_pipeline *pipe,
>  	while ((entity = media_entity_graph_walk_next(&graph))) {
>  		struct xvip_dma *dma;
>  
> -		if (entity->type != MEDIA_ENT_T_DEVNODE_V4L)
> +		if (entity->type != MEDIA_ENT_T_AV_DMA)
>  			continue;
>  
>  		dma = to_xvip_dma(media_entity_to_video_device(entity));
> diff --git a/drivers/media/v4l2-core/v4l2-dev.c b/drivers/media/v4l2-core/v4l2-dev.c
> index 71a1b93b0790..9ef920221b5a 100644
> --- a/drivers/media/v4l2-core/v4l2-dev.c
> +++ b/drivers/media/v4l2-core/v4l2-dev.c
> @@ -912,7 +912,7 @@ int __video_register_device(struct video_device *vdev, int type, int nr,
>  	/* Part 5: Register the entity. */
>  	if (vdev->v4l2_dev->mdev &&
>  	    vdev->vfl_type != VFL_TYPE_SUBDEV) {
> -		vdev->entity.type = MEDIA_ENT_T_DEVNODE_V4L;
> +		vdev->entity.type = MEDIA_ENT_T_AV_DMA;
>  		vdev->entity.name = vdev->name;
>  		vdev->entity.info.dev.major = VIDEO_MAJOR;
>  		vdev->entity.info.dev.minor = vdev->minor;
> diff --git a/drivers/media/v4l2-core/v4l2-subdev.c b/drivers/media/v4l2-core/v4l2-subdev.c
> index 63596063b213..9f8fc8330b3e 100644
> --- a/drivers/media/v4l2-core/v4l2-subdev.c
> +++ b/drivers/media/v4l2-core/v4l2-subdev.c
> @@ -535,7 +535,7 @@ v4l2_subdev_link_validate_get_format(struct media_pad *pad,
>  		return v4l2_subdev_call(sd, pad, get_fmt, NULL, fmt);
>  	}
>  
> -	WARN(pad->entity->type != MEDIA_ENT_T_DEVNODE_V4L,
> +	WARN(pad->entity->type != MEDIA_ENT_T_AV_DMA,
>  	     "Driver bug! Wrong media entity type 0x%08x, entity %s\n",
>  	     pad->entity->type, pad->entity->name);
>  
> diff --git a/include/uapi/linux/media.h b/include/uapi/linux/media.h
> index 775c11c6b173..a7aa2aac9c23 100644
> --- a/include/uapi/linux/media.h
> +++ b/include/uapi/linux/media.h
> @@ -44,12 +44,12 @@ struct media_device_info {
>  
>  /* Used values for media_entity_desc::type */
>  
> -#define MEDIA_ENT_T_DEVNODE_V4L		(((1 << 16)) + 1)
> -#define MEDIA_ENT_T_DEVNODE_DVB_FE	(MEDIA_ENT_T_DEVNODE_V4L + 3)
> -#define MEDIA_ENT_T_DEVNODE_DVB_DEMUX	(MEDIA_ENT_T_DEVNODE_V4L + 4)
> -#define MEDIA_ENT_T_DEVNODE_DVB_DVR	(MEDIA_ENT_T_DEVNODE_V4L + 5)
> -#define MEDIA_ENT_T_DEVNODE_DVB_CA	(MEDIA_ENT_T_DEVNODE_V4L + 6)
> -#define MEDIA_ENT_T_DEVNODE_DVB_NET	(MEDIA_ENT_T_DEVNODE_V4L + 7)
> +#define MEDIA_ENT_T_AV_DMA		(((1 << 16)) + 1)
> +#define MEDIA_ENT_T_DEVNODE_DVB_FE	(MEDIA_ENT_T_AV_DMA + 3)
> +#define MEDIA_ENT_T_DEVNODE_DVB_DEMUX	(MEDIA_ENT_T_AV_DMA + 4)
> +#define MEDIA_ENT_T_DEVNODE_DVB_DVR	(MEDIA_ENT_T_AV_DMA + 5)
> +#define MEDIA_ENT_T_DEVNODE_DVB_CA	(MEDIA_ENT_T_AV_DMA + 6)
> +#define MEDIA_ENT_T_DEVNODE_DVB_NET	(MEDIA_ENT_T_AV_DMA + 7)
>  
>  #define MEDIA_ENT_T_V4L2_SUBDEV_SENSOR	((2 << 16) + 1)
>  #define MEDIA_ENT_T_V4L2_SUBDEV_FLASH	(MEDIA_ENT_T_V4L2_SUBDEV_SENSOR + 1)
> 

Re: [PATCH 03/18] media controller: use MEDIA_ENT_T_AV_DMA for A/V DMA engines

[Mauro Carvalho Chehab]

Em Fri, 08 May 2015 13:54:07 +0200
Hans Verkuil <hverkuil@xs4all.nl> escreveu:

> On 05/08/2015 03:12 AM, Mauro Carvalho Chehab wrote:
> > At the Video4Linux API, the /dev/video?, /dev/vbi? and
> > /dev/radio? device nodes are used for the chipset that

I knew that this patch would cause some discussions ;)

> 
> You should add /dev/swradio? for SDR devices.

I will.

> 
> > provides the bridge between video/radio streams and the
> > USB, PCI or CPU buses.
> > 
> > Such bridge is also typically used to control the V4L2 device
> > as a hole.
> 
> hole -> whole

Ok.

> > 
> > For video streaming devices and SDR radio devices, they're
> > also associated with the DMA engines that transfer the
> > video stream (or SDR stream) to the CPU's memory.
> > 
> > It should be noticed, however, this is not true on non-SDR
> > radio devices,
> 
> I think you forgot that SDR devices are not using /dev/radio
> but /dev/swradio.

Yeah, true. I forgot that, in the end of the day, we used a
different naming for SDR radio devnodes. I'll fix the comments.

> They have different names. Radio devices never
> stream (OK, I think there are one or two exceptions, but that's really
> because nobody bothered to make an alsa driver. Those boards are
> in practice out of spec.)

Yes, I know.

> > and may also not be true on embedded devices
> > that, due to DRM reasons, don't allow writing unencrypted
> > data on a memory that could be seen by the CPU.
> 
> This actually might still work by using opaque DMABUF handles. But that's
> under discussion right now in the Secure Data Path thread.

Well, a DMABUF opaque handler like that actually refers to either a
buffer that is shared only between 2 devices or to a device-to-device
DMA transfer.

Such dataflow is different than the usual meaning of the video devnode,
where the devnode is used to do I/O transfers. So, it may actually 
be mapped as a different type of entity.

We'll need to discuss further when we start mapping this via MC.

> Another reason can also be that the SoC vendor re-invented the wheel
> and made there own DMA streaming solution. You can still make V4L drivers
> that control the video receivers/transmitters, but for the actual streaming
> you are forced to use the vendor's crap code (hello TI!).
> 
> I've bitter experiences with that :-(
>  
> > So, we'll eventually need to add another entity for such
> > bridge chipsets that have a video/vbi/radio device node
> > associated, but don't have DMA engines on (some) devnodes.
> > 
> > As, currently, we don't have any such case,
> 
> ??? Radio devices are exactly that.

I actually meant to say:

	"As, currently, no driver uses Media Controller on such cases,"

> > let's for now
> > just rename the device nodes that are associated with a
> > DMA engine as MEDIA_ENT_T_AV_DMA.
> > 
> > So,
> > 	MEDIA_ENT_T_DEVNODE_V4L -> MEDIA_ENT_T_AV_DMA
> > 
> > PS.: This is not actually true for USB devices, as the
> > DMA engine is an internal component, as it is up to the
> > Kernel to strip the stream payload from the URB packages.
> 
> How about MEDIA_ENT_T_DATA_STREAMING? Or perhaps DATA_IO? Perhaps even just
> "IO"?

Almost entities do I/O and data streaming (exceptions are flash controller,
SEC and similar control subdevices). So, DATA_STREAMING, DATA_IO or IO
are a way too generic.

DMA is a little bit more restrictive than we wanted.

Actually, I originally named those as MEDIA_ENT_T_AV_BRIDGE, because
the hardware component that implements the device->CPU I/O is typically
a bridge. But then I went into the drivers, and I noticed that several
devices with just one bridge have several different entities for I/O.

So, I ran this script:
	$ git filter-branch -f --msg-filter 'cat && sed s,MEDIA_ENT_T_AV_BRIDGE,MEDIA_ENT_T_AV_DMA,g' origin/patchwork..
	$ git filter-branch -f --tree-filter 'for i in $(git grep -l MEDIA_ENT_T_AV_BRIDGE); do sed s,MEDIA_ENT_T_AV_BRIDGE,MEDIA_ENT_T_AV_DMA,g $i >a && mv a $i; done' origin/patchwork..

To replace the name everywere. Provided that we decide a better name,
this can be easily fixable by doing the above scripting.

Perhaps MEDIA_ENT_T_DEV_CPU_AV_IO would be a better name?

> That would cover USB as well, and I dislike the use of "AV", since the
> data might contain other things besides audio and/or video.

True, but how to distinguish such device from an ALSA DEV/CPU IO?

Answering myself, I see one alternative for that... we could use
MEDIA_ENT_T_DEV_CPU_IO for all device->CPU I/O devices, and use
properties to tell what APIs are valid on such entity. The bad thing
is that someone could add multiple "incompatible" APIs at the same
device (like ALSA, V4L and DVB - all on the dame sevnode).

I'm running out of ideas here ;)

In the lack of a better name, I would keep MEDIA_ENT_T_AV_DMA, as
it is the closest one to what's provided by such entities (or the
less wrong one).


Regards,
Mauro

Re: [PATCH 03/18] media controller: use MEDIA_ENT_T_AV_DMA for A/V DMA engines

[Hans Verkuil]

Hi Mauro,

On 05/08/2015 02:32 PM, Mauro Carvalho Chehab wrote:
>>> and may also not be true on embedded devices
>>> that, due to DRM reasons, don't allow writing unencrypted
>>> data on a memory that could be seen by the CPU.
>>
>> This actually might still work by using opaque DMABUF handles. But that's
>> under discussion right now in the Secure Data Path thread.
> 
> Well, a DMABUF opaque handler like that actually refers to either a
> buffer that is shared only between 2 devices or to a device-to-device
> DMA transfer.
> 
> Such dataflow is different than the usual meaning of the video devnode,
> where the devnode is used to do I/O transfers. So, it may actually 
> be mapped as a different type of entity.
> 
> We'll need to discuss further when we start mapping this via MC.

Yes, this is quite theoretical at the moment.

>>> So, we'll eventually need to add another entity for such
>>> bridge chipsets that have a video/vbi/radio device node
>>> associated, but don't have DMA engines on (some) devnodes.
>>>
>>> As, currently, we don't have any such case,
>>
>> ??? Radio devices are exactly that.
> 
> I actually meant to say:
> 
> 	"As, currently, no driver uses Media Controller on such cases,"

Ah, OK. That makes more sense :-)

> 
>>> let's for now
>>> just rename the device nodes that are associated with a
>>> DMA engine as MEDIA_ENT_T_AV_DMA.
>>>
>>> So,
>>> 	MEDIA_ENT_T_DEVNODE_V4L -> MEDIA_ENT_T_AV_DMA
>>>
>>> PS.: This is not actually true for USB devices, as the
>>> DMA engine is an internal component, as it is up to the
>>> Kernel to strip the stream payload from the URB packages.
>>
>> How about MEDIA_ENT_T_DATA_STREAMING? Or perhaps DATA_IO? Perhaps even just
>> "IO"?
> 
> Almost entities do I/O and data streaming (exceptions are flash controller,
> SEC and similar control subdevices). So, DATA_STREAMING, DATA_IO or IO
> are a way too generic.

For some of our products we have lots of video nodes that just control the
receiver or transmitter (and possibly other related blocks), but leave the
streaming to vendor code where we are forced to use that. So this can be
a lot more common than you might think, although you won't see that appearing
in the kernel.

> 
> DMA is a little bit more restrictive than we wanted.
> 
> Actually, I originally named those as MEDIA_ENT_T_AV_BRIDGE, because
> the hardware component that implements the device->CPU I/O is typically
> a bridge. But then I went into the drivers, and I noticed that several
> devices with just one bridge have several different entities for I/O.
> 
> So, I ran this script:
> 	$ git filter-branch -f --msg-filter 'cat && sed s,MEDIA_ENT_T_AV_BRIDGE,MEDIA_ENT_T_AV_DMA,g' origin/patchwork..
> 	$ git filter-branch -f --tree-filter 'for i in $(git grep -l MEDIA_ENT_T_AV_BRIDGE); do sed s,MEDIA_ENT_T_AV_BRIDGE,MEDIA_ENT_T_AV_DMA,g $i >a && mv a $i; done' origin/patchwork..
> 
> To replace the name everywere. Provided that we decide a better name,
> this can be easily fixable by doing the above scripting.
> 
> Perhaps MEDIA_ENT_T_DEV_CPU_AV_IO would be a better name?
> 
>> That would cover USB as well, and I dislike the use of "AV", since the
>> data might contain other things besides audio and/or video.
> 
> True, but how to distinguish such device from an ALSA DEV/CPU IO?
> 
> Answering myself, I see one alternative for that... we could use
> MEDIA_ENT_T_DEV_CPU_IO for all device->CPU I/O devices, and use
> properties to tell what APIs are valid on such entity. The bad thing
> is that someone could add multiple "incompatible" APIs at the same
> device (like ALSA, V4L and DVB - all on the dame sevnode).
> 
> I'm running out of ideas here ;)
> 
> In the lack of a better name, I would keep MEDIA_ENT_T_AV_DMA, as
> it is the closest one to what's provided by such entities (or the
> less wrong one).

See my reply to patch 10/18: I see whether streaming is supported or not as a
function (or feature) of the entity, just like a subdev entity can be both
a tuner and a video decoder. I.e. these are properties.

I think the naming issue here shows the problem with your approach. Whereas
having a 'streaming' property simplifies this IMHO.

Regards,

	Hans

[PATCH 05/18] media controller: rename MEDIA_ENT_T_DEVNODE_DVB entities

[Mauro Carvalho Chehab]

In order to reflect that the entities are actually the hardware
(or firmware, or in-kernel software), and are not associated
with the DVB API, let's remove DEVNODE_ from the entity names
and use DTV (Digital TV) for the entities.

The frontend is an special case: the frontend devnode actually
talks directly with the DTV demodulator. It may or may not also
talk with the SEC (Satellite Equipment Control) and with the
tuner. For the sake of unifying the nomenclature, let's call it
as MEDIA_ENT_T_DTV_DEMOD, because this component is always
there.

So:

	MEDIA_ENT_T_DEVNODE_DVB_FE    -> MEDIA_ENT_T_DTV_DEMOD
	MEDIA_ENT_T_DEVNODE_DVB_DEMUX -> MEDIA_ENT_T_DTV_DEMUX
	MEDIA_ENT_T_DEVNODE_DVB_DVR   -> MEDIA_ENT_T_DTV_DVR
	MEDIA_ENT_T_DEVNODE_DVB_CA    -> MEDIA_ENT_T_DTV_CA
	MEDIA_ENT_T_DEVNODE_DVB_NET   -> MEDIA_ENT_T_DTV_NET

PS.: we could actually not keep this define:
	#define MEDIA_ENT_T_DEVNODE_DVB_FE MEDIA_ENT_T_DTV_DEMOD

As MEDIA_ENT_T_DEVNODE_DVB_FE symbol will not arrive any Kernel
version (being present only at the 4.1-rc kernels), but keeping
it helps to show that the DVB frontend node is actually associated
with the DTV demodulator. So, keeping it for now helps to better
document. Also, it avoids to break experimental versions of v4l-utils.
So, better to remove this only when we remove the remaining legacy
stuff.

Signed-off-by: Mauro Carvalho Chehab <mchehab-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org>

diff --git a/Documentation/DocBook/media/v4l/media-ioc-enum-entities.xml b/Documentation/DocBook/media/v4l/media-ioc-enum-entities.xml
index 759604e3529f..27082b07f4c2 100644
--- a/Documentation/DocBook/media/v4l/media-ioc-enum-entities.xml
+++ b/Documentation/DocBook/media/v4l/media-ioc-enum-entities.xml
@@ -195,23 +195,23 @@
 	    <entry>ALSA card</entry>
 	  </row>
 	  <row>
-	    <entry><constant>MEDIA_ENT_T_DEVNODE_DVB_FE</constant></entry>
+	    <entry><constant>MEDIA_ENT_T_DTV_DEMOD</constant></entry>
 	    <entry>DVB frontend devnode</entry>
 	  </row>
 	  <row>
-	    <entry><constant>MEDIA_ENT_T_DEVNODE_DVB_DEMUX</constant></entry>
+	    <entry><constant>MEDIA_ENT_T_DTV_DEMUX</constant></entry>
 	    <entry>DVB demux devnode</entry>
 	  </row>
 	  <row>
-	    <entry><constant>MEDIA_ENT_T_DEVNODE_DVB_DVR</constant></entry>
+	    <entry><constant>MEDIA_ENT_T_DTV_DVR</constant></entry>
 	    <entry>DVB DVR devnode</entry>
 	  </row>
 	  <row>
-	    <entry><constant>MEDIA_ENT_T_DEVNODE_DVB_CA</constant></entry>
+	    <entry><constant>MEDIA_ENT_T_DTV_CA</constant></entry>
 	    <entry>DVB CAM devnode</entry>
 	  </row>
 	  <row>
-	    <entry><constant>MEDIA_ENT_T_DEVNODE_DVB_NET</constant></entry>
+	    <entry><constant>MEDIA_ENT_T_DTV_NET</constant></entry>
 	    <entry>DVB network devnode</entry>
 	  </row>
 	  <row>
diff --git a/drivers/media/dvb-core/dvbdev.c b/drivers/media/dvb-core/dvbdev.c
index 13bb57f0457f..39846077045e 100644
--- a/drivers/media/dvb-core/dvbdev.c
+++ b/drivers/media/dvb-core/dvbdev.c
@@ -221,26 +221,26 @@ static void dvb_register_media_device(struct dvb_device *dvbdev,
 
 	switch (type) {
 	case DVB_DEVICE_FRONTEND:
-		dvbdev->entity->type = MEDIA_ENT_T_DEVNODE_DVB_FE;
+		dvbdev->entity->type = MEDIA_ENT_T_DTV_DEMOD;
 		dvbdev->pads[0].flags = MEDIA_PAD_FL_SINK;
 		dvbdev->pads[1].flags = MEDIA_PAD_FL_SOURCE;
 		break;
 	case DVB_DEVICE_DEMUX:
-		dvbdev->entity->type = MEDIA_ENT_T_DEVNODE_DVB_DEMUX;
+		dvbdev->entity->type = MEDIA_ENT_T_DTV_DEMUX;
 		dvbdev->pads[0].flags = MEDIA_PAD_FL_SINK;
 		dvbdev->pads[1].flags = MEDIA_PAD_FL_SOURCE;
 		break;
 	case DVB_DEVICE_DVR:
-		dvbdev->entity->type = MEDIA_ENT_T_DEVNODE_DVB_DVR;
+		dvbdev->entity->type = MEDIA_ENT_T_DTV_DVR;
 		dvbdev->pads[0].flags = MEDIA_PAD_FL_SINK;
 		break;
 	case DVB_DEVICE_CA:
-		dvbdev->entity->type = MEDIA_ENT_T_DEVNODE_DVB_CA;
+		dvbdev->entity->type = MEDIA_ENT_T_DTV_CA;
 		dvbdev->pads[0].flags = MEDIA_PAD_FL_SINK;
 		dvbdev->pads[1].flags = MEDIA_PAD_FL_SOURCE;
 		break;
 	case DVB_DEVICE_NET:
-		dvbdev->entity->type = MEDIA_ENT_T_DEVNODE_DVB_NET;
+		dvbdev->entity->type = MEDIA_ENT_T_DTV_NET;
 		break;
 	default:
 		kfree(dvbdev->entity);
@@ -396,16 +396,16 @@ void dvb_create_media_graph(struct dvb_adapter *adap)
 		case MEDIA_ENT_T_V4L2_SUBDEV_TUNER:
 			tuner = entity;
 			break;
-		case MEDIA_ENT_T_DEVNODE_DVB_FE:
+		case MEDIA_ENT_T_DTV_DEMOD:
 			fe = entity;
 			break;
-		case MEDIA_ENT_T_DEVNODE_DVB_DEMUX:
+		case MEDIA_ENT_T_DTV_DEMUX:
 			demux = entity;
 			break;
-		case MEDIA_ENT_T_DEVNODE_DVB_DVR:
+		case MEDIA_ENT_T_DTV_DVR:
 			dvr = entity;
 			break;
-		case MEDIA_ENT_T_DEVNODE_DVB_CA:
+		case MEDIA_ENT_T_DTV_CA:
 			ca = entity;
 			break;
 		}
diff --git a/include/uapi/linux/media.h b/include/uapi/linux/media.h
index 2e465ba087ba..0de9912411c5 100644
--- a/include/uapi/linux/media.h
+++ b/include/uapi/linux/media.h
@@ -45,11 +45,11 @@ struct media_device_info {
 /* Used values for media_entity_desc::type */
 
 #define MEDIA_ENT_T_AV_DMA		(((1 << 16)) + 1)
-#define MEDIA_ENT_T_DEVNODE_DVB_FE	(MEDIA_ENT_T_AV_DMA + 3)
-#define MEDIA_ENT_T_DEVNODE_DVB_DEMUX	(MEDIA_ENT_T_AV_DMA + 4)
-#define MEDIA_ENT_T_DEVNODE_DVB_DVR	(MEDIA_ENT_T_AV_DMA + 5)
-#define MEDIA_ENT_T_DEVNODE_DVB_CA	(MEDIA_ENT_T_AV_DMA + 6)
-#define MEDIA_ENT_T_DEVNODE_DVB_NET	(MEDIA_ENT_T_AV_DMA + 7)
+#define MEDIA_ENT_T_DTV_DEMOD	(MEDIA_ENT_T_AV_DMA + 3)
+#define MEDIA_ENT_T_DTV_DEMUX	(MEDIA_ENT_T_AV_DMA + 4)
+#define MEDIA_ENT_T_DTV_DVR	(MEDIA_ENT_T_AV_DMA + 5)
+#define MEDIA_ENT_T_DTV_CA	(MEDIA_ENT_T_AV_DMA + 6)
+#define MEDIA_ENT_T_DTV_NET	(MEDIA_ENT_T_AV_DMA + 7)
 
 #define MEDIA_ENT_T_CAM_SENSOR	((2 << 16) + 1)
 #define MEDIA_ENT_T_CAM_FLASH	(MEDIA_ENT_T_CAM_SENSOR + 1)
@@ -76,7 +76,13 @@ struct media_device_info {
 #define MEDIA_ENT_T_DEVNODE_FB		(MEDIA_ENT_T_DEVNODE + 2)
 #define MEDIA_ENT_T_DEVNODE_ALSA	(MEDIA_ENT_T_DEVNODE + 3)
 
-#define MEDIA_ENT_T_DEVNODE_DVB		MEDIA_ENT_T_DEVNODE_DVB_FE
+#define MEDIA_ENT_T_DEVNODE_DVB		MEDIA_ENT_T_DTV_DEMOD
+#define MEDIA_ENT_T_DEVNODE_DVB_FE	MEDIA_ENT_T_DTV_DEMOD
+#define MEDIA_ENT_T_DEVNODE_DVB_DEMUX	MEDIA_ENT_T_DTV_DEMUX
+#define MEDIA_ENT_T_DEVNODE_DVB_DVR	MEDIA_ENT_T_DTV_DVR
+#define MEDIA_ENT_T_DEVNODE_DVB_CA	MEDIA_ENT_T_DTV_CA
+#define MEDIA_ENT_T_DEVNODE_DVB_NET	MEDIA_ENT_T_DTV_NET
+
 #define MEDIA_ENT_T_V4L2_SUBDEV_SENSOR	MEDIA_ENT_T_CAM_SENSOR
 #define MEDIA_ENT_T_V4L2_SUBDEV_FLASH	MEDIA_ENT_T_CAM_FLASH
 #define MEDIA_ENT_T_V4L2_SUBDEV_LENS	MEDIA_ENT_T_CAM_LENS
-- 
2.1.0

Re: [PATCH 05/18] media controller: rename MEDIA_ENT_T_DEVNODE_DVB entities

[Hans Verkuil]

On 05/08/2015 03:12 AM, Mauro Carvalho Chehab wrote:
> In order to reflect that the entities are actually the hardware
> (or firmware, or in-kernel software), and are not associated
> with the DVB API, let's remove DEVNODE_ from the entity names
> and use DTV (Digital TV) for the entities.
> 
> The frontend is an special case: the frontend devnode actually
> talks directly with the DTV demodulator. It may or may not also
> talk with the SEC (Satellite Equipment Control) and with the
> tuner. For the sake of unifying the nomenclature, let's call it
> as MEDIA_ENT_T_DTV_DEMOD, because this component is always
> there.
> 
> So:
> 
> 	MEDIA_ENT_T_DEVNODE_DVB_FE    -> MEDIA_ENT_T_DTV_DEMOD
> 	MEDIA_ENT_T_DEVNODE_DVB_DEMUX -> MEDIA_ENT_T_DTV_DEMUX
> 	MEDIA_ENT_T_DEVNODE_DVB_DVR   -> MEDIA_ENT_T_DTV_DVR
> 	MEDIA_ENT_T_DEVNODE_DVB_CA    -> MEDIA_ENT_T_DTV_CA
> 	MEDIA_ENT_T_DEVNODE_DVB_NET   -> MEDIA_ENT_T_DTV_NET

I'm happy with the new names.

> 
> PS.: we could actually not keep this define:
> 	#define MEDIA_ENT_T_DEVNODE_DVB_FE MEDIA_ENT_T_DTV_DEMOD
> 
> As MEDIA_ENT_T_DEVNODE_DVB_FE symbol will not arrive any Kernel
> version (being present only at the 4.1-rc kernels), but keeping
> it helps to show that the DVB frontend node is actually associated
> with the DTV demodulator. So, keeping it for now helps to better
> document. Also, it avoids to break experimental versions of v4l-utils.
> So, better to remove this only when we remove the remaining legacy
> stuff.

I disagree with that. Let's not introduce defines that are not going to
be used. And v4l-utils is easily fixed.

Instead of keeping an unused define, why not...

> 
> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
> 
> diff --git a/Documentation/DocBook/media/v4l/media-ioc-enum-entities.xml b/Documentation/DocBook/media/v4l/media-ioc-enum-entities.xml
> index 759604e3529f..27082b07f4c2 100644
> --- a/Documentation/DocBook/media/v4l/media-ioc-enum-entities.xml
> +++ b/Documentation/DocBook/media/v4l/media-ioc-enum-entities.xml
> @@ -195,23 +195,23 @@
>  	    <entry>ALSA card</entry>
>  	  </row>
>  	  <row>
> -	    <entry><constant>MEDIA_ENT_T_DEVNODE_DVB_FE</constant></entry>
> +	    <entry><constant>MEDIA_ENT_T_DTV_DEMOD</constant></entry>
>  	    <entry>DVB frontend devnode</entry>

... explain what is going on here? I.e. that this frontend always controls a demod
and optionally also a tuner and/or SEC.

Regards,

	Hans

>  	  </row>
>  	  <row>
> -	    <entry><constant>MEDIA_ENT_T_DEVNODE_DVB_DEMUX</constant></entry>
> +	    <entry><constant>MEDIA_ENT_T_DTV_DEMUX</constant></entry>
>  	    <entry>DVB demux devnode</entry>
>  	  </row>
>  	  <row>
> -	    <entry><constant>MEDIA_ENT_T_DEVNODE_DVB_DVR</constant></entry>
> +	    <entry><constant>MEDIA_ENT_T_DTV_DVR</constant></entry>
>  	    <entry>DVB DVR devnode</entry>
>  	  </row>
>  	  <row>
> -	    <entry><constant>MEDIA_ENT_T_DEVNODE_DVB_CA</constant></entry>
> +	    <entry><constant>MEDIA_ENT_T_DTV_CA</constant></entry>
>  	    <entry>DVB CAM devnode</entry>
>  	  </row>
>  	  <row>
> -	    <entry><constant>MEDIA_ENT_T_DEVNODE_DVB_NET</constant></entry>
> +	    <entry><constant>MEDIA_ENT_T_DTV_NET</constant></entry>
>  	    <entry>DVB network devnode</entry>
>  	  </row>
>  	  <row>
> diff --git a/drivers/media/dvb-core/dvbdev.c b/drivers/media/dvb-core/dvbdev.c
> index 13bb57f0457f..39846077045e 100644
> --- a/drivers/media/dvb-core/dvbdev.c
> +++ b/drivers/media/dvb-core/dvbdev.c
> @@ -221,26 +221,26 @@ static void dvb_register_media_device(struct dvb_device *dvbdev,
>  
>  	switch (type) {
>  	case DVB_DEVICE_FRONTEND:
> -		dvbdev->entity->type = MEDIA_ENT_T_DEVNODE_DVB_FE;
> +		dvbdev->entity->type = MEDIA_ENT_T_DTV_DEMOD;
>  		dvbdev->pads[0].flags = MEDIA_PAD_FL_SINK;
>  		dvbdev->pads[1].flags = MEDIA_PAD_FL_SOURCE;
>  		break;
>  	case DVB_DEVICE_DEMUX:
> -		dvbdev->entity->type = MEDIA_ENT_T_DEVNODE_DVB_DEMUX;
> +		dvbdev->entity->type = MEDIA_ENT_T_DTV_DEMUX;
>  		dvbdev->pads[0].flags = MEDIA_PAD_FL_SINK;
>  		dvbdev->pads[1].flags = MEDIA_PAD_FL_SOURCE;
>  		break;
>  	case DVB_DEVICE_DVR:
> -		dvbdev->entity->type = MEDIA_ENT_T_DEVNODE_DVB_DVR;
> +		dvbdev->entity->type = MEDIA_ENT_T_DTV_DVR;
>  		dvbdev->pads[0].flags = MEDIA_PAD_FL_SINK;
>  		break;
>  	case DVB_DEVICE_CA:
> -		dvbdev->entity->type = MEDIA_ENT_T_DEVNODE_DVB_CA;
> +		dvbdev->entity->type = MEDIA_ENT_T_DTV_CA;
>  		dvbdev->pads[0].flags = MEDIA_PAD_FL_SINK;
>  		dvbdev->pads[1].flags = MEDIA_PAD_FL_SOURCE;
>  		break;
>  	case DVB_DEVICE_NET:
> -		dvbdev->entity->type = MEDIA_ENT_T_DEVNODE_DVB_NET;
> +		dvbdev->entity->type = MEDIA_ENT_T_DTV_NET;
>  		break;
>  	default:
>  		kfree(dvbdev->entity);
> @@ -396,16 +396,16 @@ void dvb_create_media_graph(struct dvb_adapter *adap)
>  		case MEDIA_ENT_T_V4L2_SUBDEV_TUNER:
>  			tuner = entity;
>  			break;
> -		case MEDIA_ENT_T_DEVNODE_DVB_FE:
> +		case MEDIA_ENT_T_DTV_DEMOD:
>  			fe = entity;
>  			break;
> -		case MEDIA_ENT_T_DEVNODE_DVB_DEMUX:
> +		case MEDIA_ENT_T_DTV_DEMUX:
>  			demux = entity;
>  			break;
> -		case MEDIA_ENT_T_DEVNODE_DVB_DVR:
> +		case MEDIA_ENT_T_DTV_DVR:
>  			dvr = entity;
>  			break;
> -		case MEDIA_ENT_T_DEVNODE_DVB_CA:
> +		case MEDIA_ENT_T_DTV_CA:
>  			ca = entity;
>  			break;
>  		}
> diff --git a/include/uapi/linux/media.h b/include/uapi/linux/media.h
> index 2e465ba087ba..0de9912411c5 100644
> --- a/include/uapi/linux/media.h
> +++ b/include/uapi/linux/media.h
> @@ -45,11 +45,11 @@ struct media_device_info {
>  /* Used values for media_entity_desc::type */
>  
>  #define MEDIA_ENT_T_AV_DMA		(((1 << 16)) + 1)
> -#define MEDIA_ENT_T_DEVNODE_DVB_FE	(MEDIA_ENT_T_AV_DMA + 3)
> -#define MEDIA_ENT_T_DEVNODE_DVB_DEMUX	(MEDIA_ENT_T_AV_DMA + 4)
> -#define MEDIA_ENT_T_DEVNODE_DVB_DVR	(MEDIA_ENT_T_AV_DMA + 5)
> -#define MEDIA_ENT_T_DEVNODE_DVB_CA	(MEDIA_ENT_T_AV_DMA + 6)
> -#define MEDIA_ENT_T_DEVNODE_DVB_NET	(MEDIA_ENT_T_AV_DMA + 7)
> +#define MEDIA_ENT_T_DTV_DEMOD	(MEDIA_ENT_T_AV_DMA + 3)
> +#define MEDIA_ENT_T_DTV_DEMUX	(MEDIA_ENT_T_AV_DMA + 4)
> +#define MEDIA_ENT_T_DTV_DVR	(MEDIA_ENT_T_AV_DMA + 5)
> +#define MEDIA_ENT_T_DTV_CA	(MEDIA_ENT_T_AV_DMA + 6)
> +#define MEDIA_ENT_T_DTV_NET	(MEDIA_ENT_T_AV_DMA + 7)
>  
>  #define MEDIA_ENT_T_CAM_SENSOR	((2 << 16) + 1)
>  #define MEDIA_ENT_T_CAM_FLASH	(MEDIA_ENT_T_CAM_SENSOR + 1)
> @@ -76,7 +76,13 @@ struct media_device_info {
>  #define MEDIA_ENT_T_DEVNODE_FB		(MEDIA_ENT_T_DEVNODE + 2)
>  #define MEDIA_ENT_T_DEVNODE_ALSA	(MEDIA_ENT_T_DEVNODE + 3)
>  
> -#define MEDIA_ENT_T_DEVNODE_DVB		MEDIA_ENT_T_DEVNODE_DVB_FE
> +#define MEDIA_ENT_T_DEVNODE_DVB		MEDIA_ENT_T_DTV_DEMOD
> +#define MEDIA_ENT_T_DEVNODE_DVB_FE	MEDIA_ENT_T_DTV_DEMOD
> +#define MEDIA_ENT_T_DEVNODE_DVB_DEMUX	MEDIA_ENT_T_DTV_DEMUX
> +#define MEDIA_ENT_T_DEVNODE_DVB_DVR	MEDIA_ENT_T_DTV_DVR
> +#define MEDIA_ENT_T_DEVNODE_DVB_CA	MEDIA_ENT_T_DTV_CA
> +#define MEDIA_ENT_T_DEVNODE_DVB_NET	MEDIA_ENT_T_DTV_NET
> +
>  #define MEDIA_ENT_T_V4L2_SUBDEV_SENSOR	MEDIA_ENT_T_CAM_SENSOR
>  #define MEDIA_ENT_T_V4L2_SUBDEV_FLASH	MEDIA_ENT_T_CAM_FLASH
>  #define MEDIA_ENT_T_V4L2_SUBDEV_LENS	MEDIA_ENT_T_CAM_LENS
> 

Re: [PATCH 05/18] media controller: rename MEDIA_ENT_T_DEVNODE_DVB entities

[Mauro Carvalho Chehab]

Em Fri, 08 May 2015 14:10:48 +0200
Hans Verkuil <hverkuil-qWit8jRvyhVmR6Xm/wNWPw@public.gmane.org> escreveu:

> On 05/08/2015 03:12 AM, Mauro Carvalho Chehab wrote:
> > In order to reflect that the entities are actually the hardware
> > (or firmware, or in-kernel software), and are not associated
> > with the DVB API, let's remove DEVNODE_ from the entity names
> > and use DTV (Digital TV) for the entities.
> > 
> > The frontend is an special case: the frontend devnode actually
> > talks directly with the DTV demodulator. It may or may not also
> > talk with the SEC (Satellite Equipment Control) and with the
> > tuner. For the sake of unifying the nomenclature, let's call it
> > as MEDIA_ENT_T_DTV_DEMOD, because this component is always
> > there.
> > 
> > So:
> > 
> > 	MEDIA_ENT_T_DEVNODE_DVB_FE    -> MEDIA_ENT_T_DTV_DEMOD
> > 	MEDIA_ENT_T_DEVNODE_DVB_DEMUX -> MEDIA_ENT_T_DTV_DEMUX
> > 	MEDIA_ENT_T_DEVNODE_DVB_DVR   -> MEDIA_ENT_T_DTV_DVR
> > 	MEDIA_ENT_T_DEVNODE_DVB_CA    -> MEDIA_ENT_T_DTV_CA
> > 	MEDIA_ENT_T_DEVNODE_DVB_NET   -> MEDIA_ENT_T_DTV_NET
> 
> I'm happy with the new names.
> 
> > 
> > PS.: we could actually not keep this define:
> > 	#define MEDIA_ENT_T_DEVNODE_DVB_FE MEDIA_ENT_T_DTV_DEMOD
> > 
> > As MEDIA_ENT_T_DEVNODE_DVB_FE symbol will not arrive any Kernel
> > version (being present only at the 4.1-rc kernels), but keeping
> > it helps to show that the DVB frontend node is actually associated
> > with the DTV demodulator. So, keeping it for now helps to better
> > document. Also, it avoids to break experimental versions of v4l-utils.
> > So, better to remove this only when we remove the remaining legacy
> > stuff.
> 
> I disagree with that. Let's not introduce defines that are not going to
> be used. And v4l-utils is easily fixed.
> 
> Instead of keeping an unused define, why not...

We agree to disagree here ;)

> 
> > 
> > Signed-off-by: Mauro Carvalho Chehab <mchehab-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org>
> > 
> > diff --git a/Documentation/DocBook/media/v4l/media-ioc-enum-entities.xml b/Documentation/DocBook/media/v4l/media-ioc-enum-entities.xml
> > index 759604e3529f..27082b07f4c2 100644
> > --- a/Documentation/DocBook/media/v4l/media-ioc-enum-entities.xml
> > +++ b/Documentation/DocBook/media/v4l/media-ioc-enum-entities.xml
> > @@ -195,23 +195,23 @@
> >  	    <entry>ALSA card</entry>
> >  	  </row>
> >  	  <row>
> > -	    <entry><constant>MEDIA_ENT_T_DEVNODE_DVB_FE</constant></entry>
> > +	    <entry><constant>MEDIA_ENT_T_DTV_DEMOD</constant></entry>
> >  	    <entry>DVB frontend devnode</entry>
> 
> ... explain what is going on here? I.e. that this frontend always controls a demod
> and optionally also a tuner and/or SEC.

I'm actually doing just the renames on those initial patches. There are
some adjustments to be done at the documentation, not just that.

So, I opted to do such adjustment on the last patch of this series.
> 
> Regards,
> 
> 	Hans
> 
> >  	  </row>
> >  	  <row>
> > -	    <entry><constant>MEDIA_ENT_T_DEVNODE_DVB_DEMUX</constant></entry>
> > +	    <entry><constant>MEDIA_ENT_T_DTV_DEMUX</constant></entry>
> >  	    <entry>DVB demux devnode</entry>
> >  	  </row>
> >  	  <row>
> > -	    <entry><constant>MEDIA_ENT_T_DEVNODE_DVB_DVR</constant></entry>
> > +	    <entry><constant>MEDIA_ENT_T_DTV_DVR</constant></entry>
> >  	    <entry>DVB DVR devnode</entry>
> >  	  </row>
> >  	  <row>
> > -	    <entry><constant>MEDIA_ENT_T_DEVNODE_DVB_CA</constant></entry>
> > +	    <entry><constant>MEDIA_ENT_T_DTV_CA</constant></entry>
> >  	    <entry>DVB CAM devnode</entry>
> >  	  </row>
> >  	  <row>
> > -	    <entry><constant>MEDIA_ENT_T_DEVNODE_DVB_NET</constant></entry>
> > +	    <entry><constant>MEDIA_ENT_T_DTV_NET</constant></entry>
> >  	    <entry>DVB network devnode</entry>
> >  	  </row>
> >  	  <row>
> > diff --git a/drivers/media/dvb-core/dvbdev.c b/drivers/media/dvb-core/dvbdev.c
> > index 13bb57f0457f..39846077045e 100644
> > --- a/drivers/media/dvb-core/dvbdev.c
> > +++ b/drivers/media/dvb-core/dvbdev.c
> > @@ -221,26 +221,26 @@ static void dvb_register_media_device(struct dvb_device *dvbdev,
> >  
> >  	switch (type) {
> >  	case DVB_DEVICE_FRONTEND:
> > -		dvbdev->entity->type = MEDIA_ENT_T_DEVNODE_DVB_FE;
> > +		dvbdev->entity->type = MEDIA_ENT_T_DTV_DEMOD;
> >  		dvbdev->pads[0].flags = MEDIA_PAD_FL_SINK;
> >  		dvbdev->pads[1].flags = MEDIA_PAD_FL_SOURCE;
> >  		break;
> >  	case DVB_DEVICE_DEMUX:
> > -		dvbdev->entity->type = MEDIA_ENT_T_DEVNODE_DVB_DEMUX;
> > +		dvbdev->entity->type = MEDIA_ENT_T_DTV_DEMUX;
> >  		dvbdev->pads[0].flags = MEDIA_PAD_FL_SINK;
> >  		dvbdev->pads[1].flags = MEDIA_PAD_FL_SOURCE;
> >  		break;
> >  	case DVB_DEVICE_DVR:
> > -		dvbdev->entity->type = MEDIA_ENT_T_DEVNODE_DVB_DVR;
> > +		dvbdev->entity->type = MEDIA_ENT_T_DTV_DVR;
> >  		dvbdev->pads[0].flags = MEDIA_PAD_FL_SINK;
> >  		break;
> >  	case DVB_DEVICE_CA:
> > -		dvbdev->entity->type = MEDIA_ENT_T_DEVNODE_DVB_CA;
> > +		dvbdev->entity->type = MEDIA_ENT_T_DTV_CA;
> >  		dvbdev->pads[0].flags = MEDIA_PAD_FL_SINK;
> >  		dvbdev->pads[1].flags = MEDIA_PAD_FL_SOURCE;
> >  		break;
> >  	case DVB_DEVICE_NET:
> > -		dvbdev->entity->type = MEDIA_ENT_T_DEVNODE_DVB_NET;
> > +		dvbdev->entity->type = MEDIA_ENT_T_DTV_NET;
> >  		break;
> >  	default:
> >  		kfree(dvbdev->entity);
> > @@ -396,16 +396,16 @@ void dvb_create_media_graph(struct dvb_adapter *adap)
> >  		case MEDIA_ENT_T_V4L2_SUBDEV_TUNER:
> >  			tuner = entity;
> >  			break;
> > -		case MEDIA_ENT_T_DEVNODE_DVB_FE:
> > +		case MEDIA_ENT_T_DTV_DEMOD:
> >  			fe = entity;
> >  			break;
> > -		case MEDIA_ENT_T_DEVNODE_DVB_DEMUX:
> > +		case MEDIA_ENT_T_DTV_DEMUX:
> >  			demux = entity;
> >  			break;
> > -		case MEDIA_ENT_T_DEVNODE_DVB_DVR:
> > +		case MEDIA_ENT_T_DTV_DVR:
> >  			dvr = entity;
> >  			break;
> > -		case MEDIA_ENT_T_DEVNODE_DVB_CA:
> > +		case MEDIA_ENT_T_DTV_CA:
> >  			ca = entity;
> >  			break;
> >  		}
> > diff --git a/include/uapi/linux/media.h b/include/uapi/linux/media.h
> > index 2e465ba087ba..0de9912411c5 100644
> > --- a/include/uapi/linux/media.h
> > +++ b/include/uapi/linux/media.h
> > @@ -45,11 +45,11 @@ struct media_device_info {
> >  /* Used values for media_entity_desc::type */
> >  
> >  #define MEDIA_ENT_T_AV_DMA		(((1 << 16)) + 1)
> > -#define MEDIA_ENT_T_DEVNODE_DVB_FE	(MEDIA_ENT_T_AV_DMA + 3)
> > -#define MEDIA_ENT_T_DEVNODE_DVB_DEMUX	(MEDIA_ENT_T_AV_DMA + 4)
> > -#define MEDIA_ENT_T_DEVNODE_DVB_DVR	(MEDIA_ENT_T_AV_DMA + 5)
> > -#define MEDIA_ENT_T_DEVNODE_DVB_CA	(MEDIA_ENT_T_AV_DMA + 6)
> > -#define MEDIA_ENT_T_DEVNODE_DVB_NET	(MEDIA_ENT_T_AV_DMA + 7)
> > +#define MEDIA_ENT_T_DTV_DEMOD	(MEDIA_ENT_T_AV_DMA + 3)
> > +#define MEDIA_ENT_T_DTV_DEMUX	(MEDIA_ENT_T_AV_DMA + 4)
> > +#define MEDIA_ENT_T_DTV_DVR	(MEDIA_ENT_T_AV_DMA + 5)
> > +#define MEDIA_ENT_T_DTV_CA	(MEDIA_ENT_T_AV_DMA + 6)
> > +#define MEDIA_ENT_T_DTV_NET	(MEDIA_ENT_T_AV_DMA + 7)
> >  
> >  #define MEDIA_ENT_T_CAM_SENSOR	((2 << 16) + 1)
> >  #define MEDIA_ENT_T_CAM_FLASH	(MEDIA_ENT_T_CAM_SENSOR + 1)
> > @@ -76,7 +76,13 @@ struct media_device_info {
> >  #define MEDIA_ENT_T_DEVNODE_FB		(MEDIA_ENT_T_DEVNODE + 2)
> >  #define MEDIA_ENT_T_DEVNODE_ALSA	(MEDIA_ENT_T_DEVNODE + 3)
> >  
> > -#define MEDIA_ENT_T_DEVNODE_DVB		MEDIA_ENT_T_DEVNODE_DVB_FE
> > +#define MEDIA_ENT_T_DEVNODE_DVB		MEDIA_ENT_T_DTV_DEMOD
> > +#define MEDIA_ENT_T_DEVNODE_DVB_FE	MEDIA_ENT_T_DTV_DEMOD
> > +#define MEDIA_ENT_T_DEVNODE_DVB_DEMUX	MEDIA_ENT_T_DTV_DEMUX
> > +#define MEDIA_ENT_T_DEVNODE_DVB_DVR	MEDIA_ENT_T_DTV_DVR
> > +#define MEDIA_ENT_T_DEVNODE_DVB_CA	MEDIA_ENT_T_DTV_CA
> > +#define MEDIA_ENT_T_DEVNODE_DVB_NET	MEDIA_ENT_T_DTV_NET
> > +
> >  #define MEDIA_ENT_T_V4L2_SUBDEV_SENSOR	MEDIA_ENT_T_CAM_SENSOR
> >  #define MEDIA_ENT_T_V4L2_SUBDEV_FLASH	MEDIA_ENT_T_CAM_FLASH
> >  #define MEDIA_ENT_T_V4L2_SUBDEV_LENS	MEDIA_ENT_T_CAM_LENS
> > 
> 

[PATCH 16/18] v4l2-subdev: use MEDIA_ENT_T_UNKNOWN for new subdevs

[Mauro Carvalho Chehab]

Instead of abusing MEDIA_ENT_T_V4L2_SUBDEV, initialize
new subdev entities as MEDIA_ENT_T_UNKNOWN.

Signed-off-by: Mauro Carvalho Chehab <mchehab-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org>

diff --git a/drivers/media/v4l2-core/v4l2-subdev.c b/drivers/media/v4l2-core/v4l2-subdev.c
index 66c6d9fd2033..0233d30b4922 100644
--- a/drivers/media/v4l2-core/v4l2-subdev.c
+++ b/drivers/media/v4l2-core/v4l2-subdev.c
@@ -584,7 +584,7 @@ void v4l2_subdev_init(struct v4l2_subdev *sd, const struct v4l2_subdev_ops *ops)
 	sd->host_priv = NULL;
 #if defined(CONFIG_MEDIA_CONTROLLER)
 	sd->entity.name = sd->name;
-	sd->entity.type = MEDIA_ENT_T_V4L2_SUBDEV;
+	sd->entity.type = MEDIA_ENT_T_UNKNOWN;
 #endif
 }
 EXPORT_SYMBOL(v4l2_subdev_init);
diff --git a/include/uapi/linux/media.h b/include/uapi/linux/media.h
index 8d47b70b7ea8..663eb2c6019d 100644
--- a/include/uapi/linux/media.h
+++ b/include/uapi/linux/media.h
@@ -44,6 +44,12 @@ struct media_device_info {
 
 /* Used values for media_entity_desc::type */
 
+/*
+ * Initial value when an entity is created
+ * Drivers should change it to something useful
+ */
+#define MEDIA_ENT_T_UNKNOWN	0
+
 /* Audio/video streaming bridges */
 #define MEDIA_ENT_T_AV_DMA		(((1 << 16)) + 1)
 
-- 
2.1.0

[PATCH 17/18] media controller: get rid of entity subtype on Kernel

[Mauro Carvalho Chehab]

Don't use anymore the type/subtype entity data/macros
inside the Kernel.

Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>

diff --git a/include/media/media-entity.h b/include/media/media-entity.h
index f15b48145711..bb98506532ff 100644
--- a/include/media/media-entity.h
+++ b/include/media/media-entity.h
@@ -103,16 +103,6 @@ struct media_entity {
 	} info;
 };
 
-static inline u32 media_entity_type(struct media_entity *entity)
-{
-	return entity->type & MEDIA_ENT_TYPE_MASK;
-}
-
-static inline u32 media_entity_subtype(struct media_entity *entity)
-{
-	return entity->type & MEDIA_ENT_SUBTYPE_MASK;
-}
-
 static inline bool is_media_entity_av_dma(struct media_entity *entity)
 {
 	if (!entity)
diff --git a/include/uapi/linux/media.h b/include/uapi/linux/media.h
index 663eb2c6019d..307cc4d72af0 100644
--- a/include/uapi/linux/media.h
+++ b/include/uapi/linux/media.h
@@ -71,7 +71,9 @@ struct media_device_info {
 /* Radio, Analog TV and/or Digital TV tuners */
 #define MEDIA_ENT_T_TUNER	(MEDIA_ENT_T_CAM_SENSOR + 4)
 
-#if 1
+#define MEDIA_ENT_T_DEVNODE		(1 << MEDIA_ENT_TYPE_SHIFT)
+
+#ifndef __KERNEL__
 /*
  * Legacy symbols.
  * Kept just to avoid userspace compilation breakages.
@@ -82,7 +84,6 @@ struct media_device_info {
 #define MEDIA_ENT_TYPE_MASK		0x00ff0000
 #define MEDIA_ENT_SUBTYPE_MASK		0x0000ffff
 
-#define MEDIA_ENT_T_DEVNODE		(1 << MEDIA_ENT_TYPE_SHIFT)
 #define MEDIA_ENT_T_V4L2_SUBDEV		(2 << MEDIA_ENT_TYPE_SHIFT)
 
 #define MEDIA_ENT_T_DEVNODE_FB		(MEDIA_ENT_T_DEVNODE + 2)
-- 
2.1.0