Em Mon, 19 Oct 2015 13:05:23 +0200 Hans Verkuil hverkuil@xs4all.nl escreveu:
On 10/12/2015 06:44 PM, Mauro Carvalho Chehab wrote:
Rename the userspace types from MEDIA_ENT_T_ to MEDIA_ENT_F_ and add the backward compatibility bits.
The changes at the .c files was generated by the following coccinelle script:
@@ @@ -MEDIA_ENT_T_UNKNOWN +MEDIA_ENT_F_UNKNOWN @@ @@ -MEDIA_ENT_T_DVB_BASE +MEDIA_ENT_F_DVB_BASE @@ @@ -MEDIA_ENT_T_V4L2_BASE +MEDIA_ENT_F_V4L2_BASE @@ @@ -MEDIA_ENT_T_V4L2_SUBDEV_BASE +MEDIA_ENT_F_V4L2_SUBDEV_BASE @@ @@ -MEDIA_ENT_T_CONNECTOR_BASE +MEDIA_ENT_F_CONNECTOR_BASE @@ @@ -MEDIA_ENT_T_V4L2_VIDEO +MEDIA_ENT_F_IO
I have to agree with a comment from Shuah that F_IO is too generic.
Huh? You're the one that requested to change it to use a single function for all I/O, and determining the API type via the associated interface.
In the past, we had different IO functions for VIDEO, SWRADIO, VBI and DVB.
Why not keep it V4L2_VIDEO? Especially since it remains specific for video IO (VBI and SWRADIO still have their own 'function' define).
V4L2 is a Linux Kernel interface. We should not mess interfaces with entities.
That's said, the I/O "entities" is actually somewhat messy. This is not a hardware block, but a software block, as we use those IO functions to actually represent an interface that would be handling data input/output from/to userspace.
In the specific case of webcam SoC, such I/O interface matches a hardware block (DMA), but this is not true for ALSA (on non-mmap mode, with is currently a requirement for pulseaudio to work, afait) or for DVB with the current read() API.
On both ALSA and DVB, the I/O is implemented by FIFO buffers, in software.
So, it would likely be better to represent them as interfaces (MEDIA_INTF_V4L2_VIDEO), but this won't be backward compatible.
I'm not against using MEDIA_ENT_F_IO_function. That was actually my proposal, but you nacked it (on IRC, i guess).
Yet, I have to confess that the graphs look cleaner using just I/O instead of IO_type.
See the graphs I have so far at: https://mchehab.fedorapeople.org/mc-next-gen/
I might be missing something. I believe I suggested using F_IO, but I think Shuah is right and that that wasn't a good idea.
Shuah's comment from the 'Topics for workshop' thread:
- ENT_F_IO appears to be too generic, requiring additional steps to determine what kind of IO function it is really is. I propose preserving and allowing enough uniqueness to enable drivers to tag the functions when they create them. For example, if AUDIO functions are all tagged ENT_F_IO, bridge driver has to determine what kind of IO it really is. This requires finding the Interface entity associated with the function entity or comparing entity name strings. Instead, if a function can be tagged as Audio Capture when it gets created, these additional steps aren't necessary.
If we get an agreement before MC, we can certainly drop this topic from the agenda.
Regards, Mauro