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 <redacted>
From: Hans Verkuil <hidden> Date: 2015-05-08 12:13:39
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
Em Fri, 08 May 2015 14:13:22 +0200
Hans Verkuil [off-list ref] escreveu:
On 05/08/2015 03:12 AM, Mauro Carvalho Chehab wrote:
quoted
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.
From: Hans Verkuil <hidden> Date: 2015-05-08 13:21:56
On 05/08/2015 02:57 PM, Mauro Carvalho Chehab wrote:
Em Fri, 08 May 2015 14:13:22 +0200
Hans Verkuil [off-list ref] escreveu:
quoted
On 05/08/2015 03:12 AM, Mauro Carvalho Chehab wrote:
quoted
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
Em Fri, 08 May 2015 15:21:39 +0200
Hans Verkuil [off-list ref] escreveu:
On 05/08/2015 02:57 PM, Mauro Carvalho Chehab wrote:
quoted
Em Fri, 08 May 2015 14:13:22 +0200
Hans Verkuil [off-list ref] escreveu:
quoted
On 05/08/2015 03:12 AM, Mauro Carvalho Chehab wrote:
quoted
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
From: Hans Verkuil <hidden> Date: 2015-05-08 14:32:22
On 05/08/2015 04:08 PM, Mauro Carvalho Chehab wrote:
Em Fri, 08 May 2015 15:21:39 +0200
Hans Verkuil [off-list ref] escreveu:
quoted
On 05/08/2015 02:57 PM, Mauro Carvalho Chehab wrote:
quoted
Em Fri, 08 May 2015 14:13:22 +0200
Hans Verkuil [off-list ref] escreveu:
quoted
On 05/08/2015 03:12 AM, Mauro Carvalho Chehab wrote:
quoted
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.
quoted
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.
quoted
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
Em Fri, 08 May 2015 16:32:03 +0200
Hans Verkuil [off-list ref] escreveu:
On 05/08/2015 04:08 PM, Mauro Carvalho Chehab wrote:
quoted
Em Fri, 08 May 2015 15:21:39 +0200
Hans Verkuil [off-list ref] escreveu:
quoted
On 05/08/2015 02:57 PM, Mauro Carvalho Chehab wrote:
quoted
Em Fri, 08 May 2015 14:13:22 +0200
Hans Verkuil [off-list ref] escreveu:
quoted
On 05/08/2015 03:12 AM, Mauro Carvalho Chehab wrote:
quoted
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.
quoted
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.
quoted
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.
quoted
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.
quoted
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.
quoted
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.
quoted
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
From: Hans Verkuil <hidden> Date: 2015-05-09 09:31:49
quoted
quoted
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
Em Sat, 09 May 2015 11:31:42 +0200
Hans Verkuil [off-list ref] escreveu:
quoted
quoted
quoted
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
From: Hans Verkuil <hidden> Date: 2015-05-11 09:39:59
On 05/11/2015 11:31 AM, Mauro Carvalho Chehab wrote:
Em Sat, 09 May 2015 11:31:42 +0200
Hans Verkuil [off-list ref] escreveu:
quoted
quoted
quoted
quoted
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.
quoted
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