Re: [PATCH 1/3] media: Fix ALSA and DVB representation at media controller API
Em Mon, 26 Jan 2015 09:41:41 -0500
Devin Heitmueller dheitmuel...@kernellabs.com escreveu:
It is actually trivial to get the device nodes once you have the
major/minor. The media-ctl library does that for you. See:
No objection then.
On a related note, you would be very well served to consider testing
your dvb changes with a device that has more than one DVB tuner (such
as the hvr-2200/2250). That will help you shake out any edge cases
related to ensuring that the different DVB nodes appear in different
groups.
Hi Devin,
I did some tests (and fixes) for WinTV Nova-TD, with has two adapters.
I saw two alternatives for it:
1) to create a media controller device for each adapter;
2) to create just one media controller.
I actually implemented (1), as, in the case of this device, AFAIKT, the
two devices are indepentent, e. g. it is not possible to, for example,
share the same tuner with two demods:
$ ls -la /dev/media?
crw-rw. 1 root video 249, 0 Fev 23 10:02 /dev/media0
crw-rw. 1 root video 249, 1 Fev 23 10:02 /dev/media1
The adapter 0 corresponds to /dev/media0, and the adapter 1
to /dev/media1:
$ media-ctl --print-dot -d /dev/media0
digraph board {
rankdir=TB
n0001 [label=dvb-demux\n/dev/dvb/adapter0/demux0, shape=box,
style=filled, fillcolor=yellow]
n0001 - n0002
n0002 [label=dvb-dvr\n/dev/dvb/adapter0/dvr0, shape=box,
style=filled, fillcolor=yellow]
n0003 [label=dvb-net\n/dev/dvb/adapter0/net0, shape=box,
style=filled, fillcolor=yellow]
n0004 [label=DiBcom 7000PC\n/dev/dvb/adapter0/frontend0,
shape=box, style=filled, fillcolor=yellow]
n0004 - n0001
}
$ media-ctl --print-dot -d /dev/media1
digraph board {
rankdir=TB
n0001 [label=dvb-demux\n/dev/dvb/adapter1/demux0, shape=box,
style=filled, fillcolor=yellow]
n0001 - n0002
n0002 [label=dvb-dvr\n/dev/dvb/adapter1/dvr0, shape=box,
style=filled, fillcolor=yellow]
n0003 [label=dvb-net\n/dev/dvb/adapter1/net0, shape=box,
style=filled, fillcolor=yellow]
n0004 [label=DiBcom 7000PC\n/dev/dvb/adapter1/frontend0,
shape=box, style=filled, fillcolor=yellow]
n0004 - n0001
}
On a more complex hardware where some components may be rewired
on a different way, however, using just one media controller
would be a better approach.
Comments?
Mauro
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] media: Fix ALSA and DVB representation at media controller API
Hi Mauro,
On Monday 23 February 2015 10:55:08 Mauro Carvalho Chehab wrote:
Em Mon, 26 Jan 2015 09:41:41 -0500 Devin Heitmueller escreveu:
It is actually trivial to get the device nodes once you have the
major/minor. The media-ctl library does that for you. See:
No objection then.
On a related note, you would be very well served to consider testing
your dvb changes with a device that has more than one DVB tuner (such
as the hvr-2200/2250). That will help you shake out any edge cases
related to ensuring that the different DVB nodes appear in different
groups.
Hi Devin,
I did some tests (and fixes) for WinTV Nova-TD, with has two adapters.
I saw two alternatives for it:
1) to create a media controller device for each adapter;
2) to create just one media controller.
I actually implemented (1), as, in the case of this device, AFAIKT, the
two devices are indepentent, e. g. it is not possible to, for example,
share the same tuner with two demods:
$ ls -la /dev/media?
crw-rw. 1 root video 249, 0 Fev 23 10:02 /dev/media0
crw-rw. 1 root video 249, 1 Fev 23 10:02 /dev/media1
The adapter 0 corresponds to /dev/media0, and the adapter 1
to /dev/media1:
$ media-ctl --print-dot -d /dev/media0
digraph board {
rankdir=TB
n0001 [label=dvb-demux\n/dev/dvb/adapter0/demux0, shape=box,
style=filled, fillcolor=yellow] n0001 - n0002
n0002 [label=dvb-dvr\n/dev/dvb/adapter0/dvr0, shape=box,
style=filled, fillcolor=yellow] n0003
[label=dvb-net\n/dev/dvb/adapter0/net0, shape=box, style=filled,
fillcolor=yellow] n0004 [label=DiBcom
7000PC\n/dev/dvb/adapter0/frontend0, shape=box, style=filled,
fillcolor=yellow] n0004 - n0001
}
$ media-ctl --print-dot -d /dev/media1
digraph board {
rankdir=TB
n0001 [label=dvb-demux\n/dev/dvb/adapter1/demux0, shape=box,
style=filled, fillcolor=yellow] n0001 - n0002
n0002 [label=dvb-dvr\n/dev/dvb/adapter1/dvr0, shape=box,
style=filled, fillcolor=yellow] n0003
[label=dvb-net\n/dev/dvb/adapter1/net0, shape=box, style=filled,
fillcolor=yellow] n0004 [label=DiBcom
7000PC\n/dev/dvb/adapter1/frontend0, shape=box, style=filled,
fillcolor=yellow] n0004 - n0001
}
On a more complex hardware where some components may be rewired
on a different way, however, using just one media controller
would be a better approach.
Comments?
A few, yes :-)
There's surprisingly many details that are not fully specified in MC, and
this is one of them. Historically the design idea was to create one media
device per instance of master video device. For PCI devices that's roughly one
media device per card, for platform devices one media device per master IP
core (or group of IP cores) instance, and for USB devices one media device per
USB control interface.
We can depart from that model in two ways.
As you mentioned above, it could make sense to create separate media device
instances for a single master device (USB in this case) when the master device
contains several completely independent pipelines. Completely independent
means that no data link connects the two pipelines, and that no resource is
shared between them in a way that affects the device's behaviour.
In the example above the only shared hardware resource seems to be the USB
bridge chip, which implements two independent DMA channels through the same
USB interface. If the DMA channels are really independent, in the sense that
they have no influence on each other such as e.g. bandwidth sharing, then two
media devices could be created. Note that there's no requirement to do so,
creating a single media device in this case is still perfectly valid.
It should also be noted that split pipelines could be difficult to represent
as independent media devices when an external chip is shared between the two
pipelines, even if that chip is itself split in two independent parts. This is
caused by how the kernel APIs used to manage composite devices (v4l2-async and
the component framework) handle components. For instance, in the DT case, we
can't use v4l2-async to bind to one of the subdevs create for a single I2C
chip or IP core, as they would share the same hardware identifier (device
name, DT node, ...) used to match subdevs. Arguably that's a framework issue
that should be fixed, but it wouldn't be trivial.
The second way to depart from the existing model is unrelated to the DVB
examples above, but is still worth mentioning for completeness. When several
master devices share resources (either on-chip or off-chip), a single media
device is required. I've discussed such a case with Jean-Michel Hautbois and
Hans Verkuil at the FOSDEM for the i.MX6 SoC. The chip includes two
independent IPUs (Image Processing Units), with two independent parallel
receivers but one shared CSI-2 receiver. On the system Jean-Michel is working
with, an external FPGA is connected to the
Re: [PATCH 1/3] media: Fix ALSA and DVB representation at media controller API
Hi Mauro and Hans,
On Monday 26 January 2015 14:41:53 Hans Verkuil wrote:
On 01/26/2015 02:34 PM, Mauro Carvalho Chehab wrote:
Em Mon, 26 Jan 2015 14:11:50 +0100 Hans Verkuil escreveu:
On 01/26/2015 01:47 PM, Mauro Carvalho Chehab wrote:
The previous provision for DVB media controller support were to
define an ID (likely meaning the adapter number) for the DVB
devnodes.
This is just plain wrong. Just like V4L, DVB devices (and ALSA,
or whatever) are identified via a (major, minor) tuple.
This is enough to uniquely identify a devnode, no matter what
API it implements.
So, before we go too far, let's mark the old v4l, dvb and alsa
devnode info as deprecated, and just call it as dev.
As we don't want to break compilation on already existing apps,
let's just keep the old definitions as-is, adding a note that
those are deprecated at media-entity.h.
Signed-off-by: Mauro Carvalho Chehab mche...@osg.samsung.com
[snip]
diff --git a/include/media/media-entity.h b/include/media/media-entity.h
index e00459185d20..d6d74bcfe183 100644
--- a/include/media/media-entity.h
+++ b/include/media/media-entity.h
@@ -87,17 +87,7 @@ struct media_entity {
struct {
u32 major;
u32 minor;
- } v4l;
- struct {
- u32 major;
- u32 minor;
- } fb;
- struct {
- u32 card;
- u32 device;
- u32 subdevice;
- } alsa;
I don't think the alsa entity information can be replaced by major/minor.
In particular you will loose the subdevice information which you need as
well. In addition, alsa devices are almost never referenced via major and
minor numbers, but always by card/device/subdevice numbers.
For media-ctl, it is easier to handle major/minor, in order to identify
the associated devnode name. Btw, media-ctl currently assumes that all
devnode devices are specified by v4l.major/v4l.minor.
Ok, maybe for alsa we'll need also card/device/subdevice, but I think this
should be mapped elsewhere, if this can't be retrieved via its sysfs/udev
interface (with seems to be doubtful).
The card/device tuple can likely be mapped to major/minor, but not
subdevice. And since everything inside alsa is based on card/device I
wouldn't change that.
I think we'll likely need changes for ALSA, but I don't think we know which
ones yet. For that reason I'd avoid creating any ALSA-specific API for now
until we implement proper support for ALSA devices. I'm fine, however, with
deprecating the ALSA API we have now, before it gets (ab)used.
- int dvb;
+ } dev;
/* Sub-device specifications */
/* Nothing needed yet */
diff --git a/include/uapi/linux/media.h b/include/uapi/linux/media.h
index d847c760e8f0..418f4fec391a 100644
--- a/include/uapi/linux/media.h
+++ b/include/uapi/linux/media.h
@@ -78,6 +78,20 @@ struct media_entity_desc {
struct {
__u32 major;
__u32 minor;
+ } dev;
+
+#if 1
+ /*
+ * DEPRECATED: previous node specifications. Kept just to
+ * avoid breaking compilation, but media_entity_desc.dev
+ * should be used instead. In particular, alsa and dvb
+ * fields below are wrong: for all devnodes, there should
+ * be just major/minor inside the struct, as this is enough
+ * to represent any devnode, no matter what type.
+ */
+ struct {
+ __u32 major;
+ __u32 minor;
} v4l;
struct {
__u32 major;
@@ -89,6 +103,7 @@ struct media_entity_desc {
__u32 subdevice;
} alsa;
int dvb;
I wouldn't merge all the v4l/fb/etc. structs into one struct. That will
make it difficult in the future if you need to add a field for e.g. v4l
entities.
This is something Hans and I have discussed at the FOSDEM, and ended up
disagreeing.
I like the single struct dev here, but I believe it should be moved before the
union, or, as Hans proposed, that the reserved bytes should be moved after the
union. However, the reason why I like your proposal has probably nothing to do
with your intents.
To start directly with the big news, I believe the MC device node entity types
are bogus. They should never have been created in the first place, and your
proposal for DVB support in MC clearly shows it in my opinion.
The media controller model is supposed to describe the device hardware
topology, or at least a logical view of that topology mapped to the operating
system from a hardware point of view. Device nodes, on the other hand, are
purely Linux concepts, and have nothing to do with the hardware topology. What
we have tried to describe with the
Re: [PATCH 1/3] media: Fix ALSA and DVB representation at media controller API
Em Tue, 24 Feb 2015 00:58:23 +0200
Laurent Pinchart laurent.pinch...@ideasonboard.com escreveu:
Hi Mauro and Hans,
On Monday 26 January 2015 14:41:53 Hans Verkuil wrote:
On 01/26/2015 02:34 PM, Mauro Carvalho Chehab wrote:
Em Mon, 26 Jan 2015 14:11:50 +0100 Hans Verkuil escreveu:
On 01/26/2015 01:47 PM, Mauro Carvalho Chehab wrote:
The previous provision for DVB media controller support were to
define an ID (likely meaning the adapter number) for the DVB
devnodes.
This is just plain wrong. Just like V4L, DVB devices (and ALSA,
or whatever) are identified via a (major, minor) tuple.
This is enough to uniquely identify a devnode, no matter what
API it implements.
So, before we go too far, let's mark the old v4l, dvb and alsa
devnode info as deprecated, and just call it as dev.
As we don't want to break compilation on already existing apps,
let's just keep the old definitions as-is, adding a note that
those are deprecated at media-entity.h.
Signed-off-by: Mauro Carvalho Chehab mche...@osg.samsung.com
[snip]
diff --git a/include/media/media-entity.h b/include/media/media-entity.h
index e00459185d20..d6d74bcfe183 100644
--- a/include/media/media-entity.h
+++ b/include/media/media-entity.h
@@ -87,17 +87,7 @@ struct media_entity {
struct {
u32 major;
u32 minor;
- } v4l;
- struct {
- u32 major;
- u32 minor;
- } fb;
- struct {
- u32 card;
- u32 device;
- u32 subdevice;
- } alsa;
I don't think the alsa entity information can be replaced by major/minor.
In particular you will loose the subdevice information which you need as
well. In addition, alsa devices are almost never referenced via major and
minor numbers, but always by card/device/subdevice numbers.
For media-ctl, it is easier to handle major/minor, in order to identify
the associated devnode name. Btw, media-ctl currently assumes that all
devnode devices are specified by v4l.major/v4l.minor.
Ok, maybe for alsa we'll need also card/device/subdevice, but I think this
should be mapped elsewhere, if this can't be retrieved via its sysfs/udev
interface (with seems to be doubtful).
The card/device tuple can likely be mapped to major/minor, but not
subdevice. And since everything inside alsa is based on card/device I
wouldn't change that.
I think we'll likely need changes for ALSA, but I don't think we know which
ones yet. For that reason I'd avoid creating any ALSA-specific API for now
until we implement proper support for ALSA devices. I'm fine, however, with
deprecating the ALSA API we have now, before it gets (ab)used.
That's my opinion too: deprecate it before it gets (ab)used.
- int dvb;
+ } dev;
/* Sub-device specifications */
/* Nothing needed yet */
diff --git a/include/uapi/linux/media.h b/include/uapi/linux/media.h
index d847c760e8f0..418f4fec391a 100644
--- a/include/uapi/linux/media.h
+++ b/include/uapi/linux/media.h
@@ -78,6 +78,20 @@ struct media_entity_desc {
struct {
__u32 major;
__u32 minor;
+ } dev;
+
+#if 1
+ /*
+* DEPRECATED: previous node specifications. Kept just
to
+* avoid breaking compilation, but media_entity_desc.dev
+* should be used instead. In particular, alsa and dvb
+* fields below are wrong: for all devnodes, there
should
+* be just major/minor inside the struct, as this is
enough
+* to represent any devnode, no matter what type.
+*/
+ struct {
+ __u32 major;
+ __u32 minor;
} v4l;
struct {
__u32 major;
@@ -89,6 +103,7 @@ struct media_entity_desc {
__u32 subdevice;
} alsa;
int dvb;
I wouldn't merge all the v4l/fb/etc. structs into one struct. That will
make it difficult in the future if you need to add a field for e.g. v4l
entities.
This is something Hans and I have discussed at the FOSDEM, and ended up
disagreeing.
I like the single struct dev here, but I believe it should be moved before
the
union, or, as Hans proposed, that the reserved bytes should be moved after
the
union. However, the reason why I like your proposal has probably nothing to
do
with your intents.
We can't move it before the union, as it would otherwise break
Re: [PATCH 1/3] media: Fix ALSA and DVB representation at media controller API
Em Mon, 23 Feb 2015 23:20:15 +0200
Laurent Pinchart laurent.pinch...@ideasonboard.com escreveu:
Hi Mauro,
On Monday 23 February 2015 10:55:08 Mauro Carvalho Chehab wrote:
Em Mon, 26 Jan 2015 09:41:41 -0500 Devin Heitmueller escreveu:
It is actually trivial to get the device nodes once you have the
major/minor. The media-ctl library does that for you. See:
No objection then.
On a related note, you would be very well served to consider testing
your dvb changes with a device that has more than one DVB tuner (such
as the hvr-2200/2250). That will help you shake out any edge cases
related to ensuring that the different DVB nodes appear in different
groups.
Hi Devin,
I did some tests (and fixes) for WinTV Nova-TD, with has two adapters.
I saw two alternatives for it:
1) to create a media controller device for each adapter;
2) to create just one media controller.
I actually implemented (1), as, in the case of this device, AFAIKT, the
two devices are indepentent, e. g. it is not possible to, for example,
share the same tuner with two demods:
$ ls -la /dev/media?
crw-rw. 1 root video 249, 0 Fev 23 10:02 /dev/media0
crw-rw. 1 root video 249, 1 Fev 23 10:02 /dev/media1
The adapter 0 corresponds to /dev/media0, and the adapter 1
to /dev/media1:
$ media-ctl --print-dot -d /dev/media0
digraph board {
rankdir=TB
n0001 [label=dvb-demux\n/dev/dvb/adapter0/demux0, shape=box,
style=filled, fillcolor=yellow] n0001 - n0002
n0002 [label=dvb-dvr\n/dev/dvb/adapter0/dvr0, shape=box,
style=filled, fillcolor=yellow] n0003
[label=dvb-net\n/dev/dvb/adapter0/net0, shape=box, style=filled,
fillcolor=yellow] n0004 [label=DiBcom
7000PC\n/dev/dvb/adapter0/frontend0, shape=box, style=filled,
fillcolor=yellow] n0004 - n0001
}
$ media-ctl --print-dot -d /dev/media1
digraph board {
rankdir=TB
n0001 [label=dvb-demux\n/dev/dvb/adapter1/demux0, shape=box,
style=filled, fillcolor=yellow] n0001 - n0002
n0002 [label=dvb-dvr\n/dev/dvb/adapter1/dvr0, shape=box,
style=filled, fillcolor=yellow] n0003
[label=dvb-net\n/dev/dvb/adapter1/net0, shape=box, style=filled,
fillcolor=yellow] n0004 [label=DiBcom
7000PC\n/dev/dvb/adapter1/frontend0, shape=box, style=filled,
fillcolor=yellow] n0004 - n0001
}
On a more complex hardware where some components may be rewired
on a different way, however, using just one media controller
would be a better approach.
Comments?
A few, yes :-)
There's surprisingly many details that are not fully specified in MC, and
this is one of them. Historically the design idea was to create one media
device per instance of master video device. For PCI devices that's roughly
one
media device per card, for platform devices one media device per master IP
core (or group of IP cores) instance, and for USB devices one media device
per
USB control interface.
We can depart from that model in two ways.
As you mentioned above, it could make sense to create separate media device
instances for a single master device (USB in this case) when the master
device
contains several completely independent pipelines. Completely independent
means that no data link connects the two pipelines, and that no resource is
shared between them in a way that affects the device's behaviour.
In the example above the only shared hardware resource seems to be the USB
bridge chip, which implements two independent DMA channels through the same
USB interface. If the DMA channels are really independent, in the sense that
they have no influence on each other such as e.g. bandwidth sharing, then two
media devices could be created. Note that there's no requirement to do so,
creating a single media device in this case is still perfectly valid.
Ok, so both ways can be applied on this case. I'll think a little bit more
about it.
It should also be noted that split pipelines could be difficult to represent
as independent media devices when an external chip is shared between the two
pipelines, even if that chip is itself split in two independent parts. This
is
caused by how the kernel APIs used to manage composite devices (v4l2-async
and
the component framework) handle components. For instance, in the DT case, we
can't use v4l2-async to bind to one of the subdevs create for a single I2C
chip or IP core, as they would share the same hardware identifier (device
name, DT node, ...) used to match subdevs. Arguably that's a framework issue
that should be fixed, but it wouldn't be trivial.
The second way to depart from the existing model is unrelated to the DVB
examples above, but is still worth mentioning for completeness. When several
master devices share resources (either on-chip or off-chip), a single media
device is required. I've discussed such a case with
[PATCH 1/3] media: Fix ALSA and DVB representation at media controller API
The previous provision for DVB media controller support were to
define an ID (likely meaning the adapter number) for the DVB
devnodes.
This is just plain wrong. Just like V4L, DVB devices (and ALSA,
or whatever) are identified via a (major, minor) tuple.
This is enough to uniquely identify a devnode, no matter what
API it implements.
So, before we go too far, let's mark the old v4l, dvb and alsa
devnode info as deprecated, and just call it as dev.
As we don't want to break compilation on already existing apps,
let's just keep the old definitions as-is, adding a note that
those are deprecated at media-entity.h.
Signed-off-by: Mauro Carvalho Chehab mche...@osg.samsung.com
diff --git a/drivers/media/v4l2-core/v4l2-dev.c
b/drivers/media/v4l2-core/v4l2-dev.c
index 86bb93fd7db8..d89d5cb465d9 100644
--- a/drivers/media/v4l2-core/v4l2-dev.c
+++ b/drivers/media/v4l2-core/v4l2-dev.c
@@ -943,8 +943,8 @@ int __video_register_device(struct video_device *vdev, int
type, int nr,
vdev-vfl_type != VFL_TYPE_SUBDEV) {
vdev-entity.type = MEDIA_ENT_T_DEVNODE_V4L;
vdev-entity.name = vdev-name;
- vdev-entity.info.v4l.major = VIDEO_MAJOR;
- vdev-entity.info.v4l.minor = vdev-minor;
+ vdev-entity.info.dev.major = VIDEO_MAJOR;
+ vdev-entity.info.dev.minor = vdev-minor;
ret = media_device_register_entity(vdev-v4l2_dev-mdev,
vdev-entity);
if (ret 0)
diff --git a/drivers/media/v4l2-core/v4l2-device.c
b/drivers/media/v4l2-core/v4l2-device.c
index 015f92aab44a..204cc67c84e8 100644
--- a/drivers/media/v4l2-core/v4l2-device.c
+++ b/drivers/media/v4l2-core/v4l2-device.c
@@ -248,8 +248,8 @@ int v4l2_device_register_subdev_nodes(struct v4l2_device
*v4l2_dev)
goto clean_up;
}
#if defined(CONFIG_MEDIA_CONTROLLER)
- sd-entity.info.v4l.major = VIDEO_MAJOR;
- sd-entity.info.v4l.minor = vdev-minor;
+ sd-entity.info.dev.major = VIDEO_MAJOR;
+ sd-entity.info.dev.minor = vdev-minor;
#endif
sd-devnode = vdev;
}
diff --git a/include/media/media-entity.h b/include/media/media-entity.h
index e00459185d20..d6d74bcfe183 100644
--- a/include/media/media-entity.h
+++ b/include/media/media-entity.h
@@ -87,17 +87,7 @@ struct media_entity {
struct {
u32 major;
u32 minor;
- } v4l;
- struct {
- u32 major;
- u32 minor;
- } fb;
- struct {
- u32 card;
- u32 device;
- u32 subdevice;
- } alsa;
- int dvb;
+ } dev;
/* Sub-device specifications */
/* Nothing needed yet */
diff --git a/include/uapi/linux/media.h b/include/uapi/linux/media.h
index d847c760e8f0..418f4fec391a 100644
--- a/include/uapi/linux/media.h
+++ b/include/uapi/linux/media.h
@@ -78,6 +78,20 @@ struct media_entity_desc {
struct {
__u32 major;
__u32 minor;
+ } dev;
+
+#if 1
+ /*
+* DEPRECATED: previous node specifications. Kept just to
+* avoid breaking compilation, but media_entity_desc.dev
+* should be used instead. In particular, alsa and dvb
+* fields below are wrong: for all devnodes, there should
+* be just major/minor inside the struct, as this is enough
+* to represent any devnode, no matter what type.
+*/
+ struct {
+ __u32 major;
+ __u32 minor;
} v4l;
struct {
__u32 major;
@@ -89,6 +103,7 @@ struct media_entity_desc {
__u32 subdevice;
} alsa;
int dvb;
+#endif
/* Sub-device specifications */
/* Nothing needed yet */
--
2.1.0
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] media: Fix ALSA and DVB representation at media controller API
Em Mon, 26 Jan 2015 09:00:46 -0500
Devin Heitmueller dheitmuel...@kernellabs.com escreveu:
For media-ctl, it is easier to handle major/minor, in order to identify
the associated devnode name. Btw, media-ctl currently assumes that all
devnode devices are specified by v4l.major/v4l.minor.
I suspect part of the motivation for the id that corresponds to the
adapter field was to make it easier to find the actual underlying
device node.
Yes, that was the reason why, back in 2007, we believed that just id
would be enough. Yet, we never tried to implement it, until the end
of the last year.
While it's trivial to convert a V4L device node from
major/minor to the device node (since for major number is constant and
the minor corresponds to the X in /dev/videoX), that's tougher with
DVB adapters because of the hierarchical nature of the DVB device
nodes. Having the adapter number makes it trivial to open
/dev/dvb/adapterX.
Perhaps my POSIX is rusty -- is there a way to identify the device
node based on major minor without having to traverse the entire /dev
tree?
It is actually trivial to get the device nodes once you have the
major/minor. The media-ctl library does that for you. See:
$ media-ctl --print-dot
digraph board {
rankdir=TB
n0001 [label={{port0 0} | cx25840 19-0044 | {port1 1 | port2
2}}, shape=Mrecord, style=filled, fillcolor=green]
n0001:port1 - n0003
n0001:port2 - n0004
n0002 [label={{} | NXP TDA18271HD | {port0 0}}, shape=Mrecord,
style=filled, fillcolor=green]
n0002:port0 - n0005 [style=dashed]
n0002:port0 - n0001:port0
n0003 [label=cx231xx #0 video\n/dev/video0, shape=box,
style=filled, fillcolor=yellow]
n0004 [label=cx231xx #0 vbi\n/dev/vbi0, shape=box, style=filled,
fillcolor=yellow]
n0005 [label=Fujitsu mb86A20s\n/dev/dvb/adapter0/frontend0,
shape=box, style=filled, fillcolor=yellow]
n0005 - n0006
n0006 [label=demux\n/dev/dvb/adapter0/demux0, shape=box,
style=filled, fillcolor=yellow]
n0006 - n0007
n0007 [label=dvr\n/dev/dvb/adapter0/dvr0, shape=box,
style=filled, fillcolor=yellow]
n0008 [label=dvb net\n/dev/dvb/adapter0/net0, shape=box,
style=filled, fillcolor=yellow]
}
There are two routines inside the media-ctl libraries to convert from
major/minor into a devnode name like: /dev/dvb/adapter0/demux0.
The first one uses sysfs:
$ ls -la /sys/dev/char|grep dvb
lrwxrwxrwx. 1 root root 0 Jan 26 10:32 212:0 -
../../devices/pci:00/:00:14.0/usb1/1-2/1-2:1.1/dvb/dvb0.frontend0
lrwxrwxrwx. 1 root root 0 Jan 26 10:32 212:1 -
../../devices/pci:00/:00:14.0/usb1/1-2/1-2:1.1/dvb/dvb0.demux0
lrwxrwxrwx. 1 root root 0 Jan 26 10:32 212:2 -
../../devices/pci:00/:00:14.0/usb1/1-2/1-2:1.1/dvb/dvb0.dvr0
lrwxrwxrwx. 1 root root 0 Jan 26 10:32 212:3 -
../../devices/pci:00/:00:14.0/usb1/1-2/1-2:1.1/dvb/dvb0.net0
Unfortunately, the sysfs nodes are dvb0 for adapter0, so a patch is needed
to fix it:
http://git.linuxtv.org/cgit.cgi/mchehab/experimental-v4l-utils.git/commit/?h=dvb-media-ctlid=d854a9bb24706dbfc878484e4538d79b1ac52aae
The second (and better) approach is to require udev to return the name of the
devnode. The logic, implemented at utils/media-ctl/libmediactl.c, inside
v4l-utils, is:
devnum = makedev(entity-info.v4l.major, entity-info.v4l.minor);
media_dbg(entity-media, looking up device: %u:%u\n,
major(devnum), minor(devnum));
device = udev_device_new_from_devnum(udev, 'c', devnum);
Right now, by default, media-ctl will use the sysfs approach, except
if an extra option is called at ./configure, in order to enable it to
use the udev library.
IMHO, we should make udev the default behavior, if libudev-dev(el) is
there at compilation time.
Regards,
Mauro
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] media: Fix ALSA and DVB representation at media controller API
It is actually trivial to get the device nodes once you have the major/minor. The media-ctl library does that for you. See: No objection then. On a related note, you would be very well served to consider testing your dvb changes with a device that has more than one DVB tuner (such as the hvr-2200/2250). That will help you shake out any edge cases related to ensuring that the different DVB nodes appear in different groups. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] media: Fix ALSA and DVB representation at media controller API
Em Mon, 26 Jan 2015 14:11:50 +0100
Hans Verkuil hverk...@xs4all.nl escreveu:
On 01/26/2015 01:47 PM, Mauro Carvalho Chehab wrote:
The previous provision for DVB media controller support were to
define an ID (likely meaning the adapter number) for the DVB
devnodes.
This is just plain wrong. Just like V4L, DVB devices (and ALSA,
or whatever) are identified via a (major, minor) tuple.
This is enough to uniquely identify a devnode, no matter what
API it implements.
So, before we go too far, let's mark the old v4l, dvb and alsa
devnode info as deprecated, and just call it as dev.
As we don't want to break compilation on already existing apps,
let's just keep the old definitions as-is, adding a note that
those are deprecated at media-entity.h.
Signed-off-by: Mauro Carvalho Chehab mche...@osg.samsung.com
diff --git a/drivers/media/v4l2-core/v4l2-dev.c
b/drivers/media/v4l2-core/v4l2-dev.c
index 86bb93fd7db8..d89d5cb465d9 100644
--- a/drivers/media/v4l2-core/v4l2-dev.c
+++ b/drivers/media/v4l2-core/v4l2-dev.c
@@ -943,8 +943,8 @@ int __video_register_device(struct video_device *vdev,
int type, int nr,
vdev-vfl_type != VFL_TYPE_SUBDEV) {
vdev-entity.type = MEDIA_ENT_T_DEVNODE_V4L;
vdev-entity.name = vdev-name;
- vdev-entity.info.v4l.major = VIDEO_MAJOR;
- vdev-entity.info.v4l.minor = vdev-minor;
+ vdev-entity.info.dev.major = VIDEO_MAJOR;
+ vdev-entity.info.dev.minor = vdev-minor;
ret = media_device_register_entity(vdev-v4l2_dev-mdev,
vdev-entity);
if (ret 0)
diff --git a/drivers/media/v4l2-core/v4l2-device.c
b/drivers/media/v4l2-core/v4l2-device.c
index 015f92aab44a..204cc67c84e8 100644
--- a/drivers/media/v4l2-core/v4l2-device.c
+++ b/drivers/media/v4l2-core/v4l2-device.c
@@ -248,8 +248,8 @@ int v4l2_device_register_subdev_nodes(struct
v4l2_device *v4l2_dev)
goto clean_up;
}
#if defined(CONFIG_MEDIA_CONTROLLER)
- sd-entity.info.v4l.major = VIDEO_MAJOR;
- sd-entity.info.v4l.minor = vdev-minor;
+ sd-entity.info.dev.major = VIDEO_MAJOR;
+ sd-entity.info.dev.minor = vdev-minor;
#endif
sd-devnode = vdev;
}
diff --git a/include/media/media-entity.h b/include/media/media-entity.h
index e00459185d20..d6d74bcfe183 100644
--- a/include/media/media-entity.h
+++ b/include/media/media-entity.h
@@ -87,17 +87,7 @@ struct media_entity {
struct {
u32 major;
u32 minor;
- } v4l;
- struct {
- u32 major;
- u32 minor;
- } fb;
- struct {
- u32 card;
- u32 device;
- u32 subdevice;
- } alsa;
I don't think the alsa entity information can be replaced by major/minor.
In particular you will loose the subdevice information which you need as
well. In addition, alsa devices are almost never referenced via major and
minor numbers, but always by card/device/subdevice numbers.
For media-ctl, it is easier to handle major/minor, in order to identify
the associated devnode name. Btw, media-ctl currently assumes that all
devnode devices are specified by v4l.major/v4l.minor.
Ok, maybe for alsa we'll need also card/device/subdevice, but I think this
should be mapped elsewhere, if this can't be retrieved via its sysfs/udev
interface (with seems to be doubtful).
- int dvb;
+ } dev;
/* Sub-device specifications */
/* Nothing needed yet */
diff --git a/include/uapi/linux/media.h b/include/uapi/linux/media.h
index d847c760e8f0..418f4fec391a 100644
--- a/include/uapi/linux/media.h
+++ b/include/uapi/linux/media.h
@@ -78,6 +78,20 @@ struct media_entity_desc {
struct {
__u32 major;
__u32 minor;
+ } dev;
+
+#if 1
+ /*
+* DEPRECATED: previous node specifications. Kept just to
+* avoid breaking compilation, but media_entity_desc.dev
+* should be used instead. In particular, alsa and dvb
+* fields below are wrong: for all devnodes, there should
+* be just major/minor inside the struct, as this is enough
+* to represent any devnode, no matter what type.
+*/
+ struct {
+ __u32 major;
+ __u32 minor;
} v4l;
struct {
__u32 major;
@@ -89,6 +103,7 @@ struct media_entity_desc {
__u32 subdevice;
} alsa;
int dvb;
I wouldn't merge all the v4l/fb/etc. structs into one struct. That will make
it
difficult in the future if
Re: [PATCH 1/3] media: Fix ALSA and DVB representation at media controller API
For media-ctl, it is easier to handle major/minor, in order to identify the associated devnode name. Btw, media-ctl currently assumes that all devnode devices are specified by v4l.major/v4l.minor. I suspect part of the motivation for the id that corresponds to the adapter field was to make it easier to find the actual underlying device node. While it's trivial to convert a V4L device node from major/minor to the device node (since for major number is constant and the minor corresponds to the X in /dev/videoX), that's tougher with DVB adapters because of the hierarchical nature of the DVB device nodes. Having the adapter number makes it trivial to open /dev/dvb/adapterX. Perhaps my POSIX is rusty -- is there a way to identify the device node based on major minor without having to traverse the entire /dev tree? Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] media: Fix ALSA and DVB representation at media controller API
On 01/26/2015 01:47 PM, Mauro Carvalho Chehab wrote:
The previous provision for DVB media controller support were to
define an ID (likely meaning the adapter number) for the DVB
devnodes.
This is just plain wrong. Just like V4L, DVB devices (and ALSA,
or whatever) are identified via a (major, minor) tuple.
This is enough to uniquely identify a devnode, no matter what
API it implements.
So, before we go too far, let's mark the old v4l, dvb and alsa
devnode info as deprecated, and just call it as dev.
As we don't want to break compilation on already existing apps,
let's just keep the old definitions as-is, adding a note that
those are deprecated at media-entity.h.
Signed-off-by: Mauro Carvalho Chehab mche...@osg.samsung.com
diff --git a/drivers/media/v4l2-core/v4l2-dev.c
b/drivers/media/v4l2-core/v4l2-dev.c
index 86bb93fd7db8..d89d5cb465d9 100644
--- a/drivers/media/v4l2-core/v4l2-dev.c
+++ b/drivers/media/v4l2-core/v4l2-dev.c
@@ -943,8 +943,8 @@ int __video_register_device(struct video_device *vdev,
int type, int nr,
vdev-vfl_type != VFL_TYPE_SUBDEV) {
vdev-entity.type = MEDIA_ENT_T_DEVNODE_V4L;
vdev-entity.name = vdev-name;
- vdev-entity.info.v4l.major = VIDEO_MAJOR;
- vdev-entity.info.v4l.minor = vdev-minor;
+ vdev-entity.info.dev.major = VIDEO_MAJOR;
+ vdev-entity.info.dev.minor = vdev-minor;
ret = media_device_register_entity(vdev-v4l2_dev-mdev,
vdev-entity);
if (ret 0)
diff --git a/drivers/media/v4l2-core/v4l2-device.c
b/drivers/media/v4l2-core/v4l2-device.c
index 015f92aab44a..204cc67c84e8 100644
--- a/drivers/media/v4l2-core/v4l2-device.c
+++ b/drivers/media/v4l2-core/v4l2-device.c
@@ -248,8 +248,8 @@ int v4l2_device_register_subdev_nodes(struct v4l2_device
*v4l2_dev)
goto clean_up;
}
#if defined(CONFIG_MEDIA_CONTROLLER)
- sd-entity.info.v4l.major = VIDEO_MAJOR;
- sd-entity.info.v4l.minor = vdev-minor;
+ sd-entity.info.dev.major = VIDEO_MAJOR;
+ sd-entity.info.dev.minor = vdev-minor;
#endif
sd-devnode = vdev;
}
diff --git a/include/media/media-entity.h b/include/media/media-entity.h
index e00459185d20..d6d74bcfe183 100644
--- a/include/media/media-entity.h
+++ b/include/media/media-entity.h
@@ -87,17 +87,7 @@ struct media_entity {
struct {
u32 major;
u32 minor;
- } v4l;
- struct {
- u32 major;
- u32 minor;
- } fb;
- struct {
- u32 card;
- u32 device;
- u32 subdevice;
- } alsa;
I don't think the alsa entity information can be replaced by major/minor.
In particular you will loose the subdevice information which you need as
well. In addition, alsa devices are almost never referenced via major and
minor numbers, but always by card/device/subdevice numbers.
- int dvb;
+ } dev;
/* Sub-device specifications */
/* Nothing needed yet */
diff --git a/include/uapi/linux/media.h b/include/uapi/linux/media.h
index d847c760e8f0..418f4fec391a 100644
--- a/include/uapi/linux/media.h
+++ b/include/uapi/linux/media.h
@@ -78,6 +78,20 @@ struct media_entity_desc {
struct {
__u32 major;
__u32 minor;
+ } dev;
+
+#if 1
+ /*
+ * DEPRECATED: previous node specifications. Kept just to
+ * avoid breaking compilation, but media_entity_desc.dev
+ * should be used instead. In particular, alsa and dvb
+ * fields below are wrong: for all devnodes, there should
+ * be just major/minor inside the struct, as this is enough
+ * to represent any devnode, no matter what type.
+ */
+ struct {
+ __u32 major;
+ __u32 minor;
} v4l;
struct {
__u32 major;
@@ -89,6 +103,7 @@ struct media_entity_desc {
__u32 subdevice;
} alsa;
int dvb;
I wouldn't merge all the v4l/fb/etc. structs into one struct. That will make it
difficult in the future if you need to add a field for e.g. v4l entities.
So I would keep the v4l, fb and alsa structs, and just add a new struct for
dvb. I wonder if the dvb field can't just be replaced since I doubt anyone is
using it. And even if someone does, then it can't be right since a single
int isn't enough and never worked anyway.
Regards,
Hans
+#endif
/* Sub-device specifications */
/* Nothing needed yet */
--
To unsubscribe from this
Re: [PATCH 1/3] media: Fix ALSA and DVB representation at media controller API
On 01/26/2015 02:34 PM, Mauro Carvalho Chehab wrote:
Em Mon, 26 Jan 2015 14:11:50 +0100
Hans Verkuil hverk...@xs4all.nl escreveu:
On 01/26/2015 01:47 PM, Mauro Carvalho Chehab wrote:
The previous provision for DVB media controller support were to
define an ID (likely meaning the adapter number) for the DVB
devnodes.
This is just plain wrong. Just like V4L, DVB devices (and ALSA,
or whatever) are identified via a (major, minor) tuple.
This is enough to uniquely identify a devnode, no matter what
API it implements.
So, before we go too far, let's mark the old v4l, dvb and alsa
devnode info as deprecated, and just call it as dev.
As we don't want to break compilation on already existing apps,
let's just keep the old definitions as-is, adding a note that
those are deprecated at media-entity.h.
Signed-off-by: Mauro Carvalho Chehab mche...@osg.samsung.com
diff --git a/drivers/media/v4l2-core/v4l2-dev.c
b/drivers/media/v4l2-core/v4l2-dev.c
index 86bb93fd7db8..d89d5cb465d9 100644
--- a/drivers/media/v4l2-core/v4l2-dev.c
+++ b/drivers/media/v4l2-core/v4l2-dev.c
@@ -943,8 +943,8 @@ int __video_register_device(struct video_device *vdev,
int type, int nr,
vdev-vfl_type != VFL_TYPE_SUBDEV) {
vdev-entity.type = MEDIA_ENT_T_DEVNODE_V4L;
vdev-entity.name = vdev-name;
- vdev-entity.info.v4l.major = VIDEO_MAJOR;
- vdev-entity.info.v4l.minor = vdev-minor;
+ vdev-entity.info.dev.major = VIDEO_MAJOR;
+ vdev-entity.info.dev.minor = vdev-minor;
ret = media_device_register_entity(vdev-v4l2_dev-mdev,
vdev-entity);
if (ret 0)
diff --git a/drivers/media/v4l2-core/v4l2-device.c
b/drivers/media/v4l2-core/v4l2-device.c
index 015f92aab44a..204cc67c84e8 100644
--- a/drivers/media/v4l2-core/v4l2-device.c
+++ b/drivers/media/v4l2-core/v4l2-device.c
@@ -248,8 +248,8 @@ int v4l2_device_register_subdev_nodes(struct
v4l2_device *v4l2_dev)
goto clean_up;
}
#if defined(CONFIG_MEDIA_CONTROLLER)
- sd-entity.info.v4l.major = VIDEO_MAJOR;
- sd-entity.info.v4l.minor = vdev-minor;
+ sd-entity.info.dev.major = VIDEO_MAJOR;
+ sd-entity.info.dev.minor = vdev-minor;
#endif
sd-devnode = vdev;
}
diff --git a/include/media/media-entity.h b/include/media/media-entity.h
index e00459185d20..d6d74bcfe183 100644
--- a/include/media/media-entity.h
+++ b/include/media/media-entity.h
@@ -87,17 +87,7 @@ struct media_entity {
struct {
u32 major;
u32 minor;
- } v4l;
- struct {
- u32 major;
- u32 minor;
- } fb;
- struct {
- u32 card;
- u32 device;
- u32 subdevice;
- } alsa;
I don't think the alsa entity information can be replaced by major/minor.
In particular you will loose the subdevice information which you need as
well. In addition, alsa devices are almost never referenced via major and
minor numbers, but always by card/device/subdevice numbers.
For media-ctl, it is easier to handle major/minor, in order to identify
the associated devnode name. Btw, media-ctl currently assumes that all
devnode devices are specified by v4l.major/v4l.minor.
Ok, maybe for alsa we'll need also card/device/subdevice, but I think this
should be mapped elsewhere, if this can't be retrieved via its sysfs/udev
interface (with seems to be doubtful).
The card/device tuple can likely be mapped to major/minor, but not subdevice.
And since everything inside alsa is based on card/device I wouldn't change
that.
- int dvb;
+ } dev;
/* Sub-device specifications */
/* Nothing needed yet */
diff --git a/include/uapi/linux/media.h b/include/uapi/linux/media.h
index d847c760e8f0..418f4fec391a 100644
--- a/include/uapi/linux/media.h
+++ b/include/uapi/linux/media.h
@@ -78,6 +78,20 @@ struct media_entity_desc {
struct {
__u32 major;
__u32 minor;
+ } dev;
+
+#if 1
+ /*
+* DEPRECATED: previous node specifications. Kept just to
+* avoid breaking compilation, but media_entity_desc.dev
+* should be used instead. In particular, alsa and dvb
+* fields below are wrong: for all devnodes, there should
+* be just major/minor inside the struct, as this is enough
+* to represent any devnode, no matter what type.
+*/
+ struct {
+ __u32 major;
+ __u32 minor;
} v4l;
struct {
__u32 major;
@@ -89,6 +103,7 @@ struct media_entity_desc {
__u32 subdevice;
} alsa;
int dvb;
