Em Fri, 30 Oct 2015 00:40:14 +0200 Sakari Ailus sakari.ailus@iki.fi escreveu:
Hi Mauro,
On Mon, Oct 19, 2015 at 10:54:11AM -0200, Mauro Carvalho Chehab wrote:
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).
Could there be an I/O entity which exposes multiple different interfaces?
Technically, yes. We used to have that with some devices that could/can export audio I/O either via /dev/video or via ALSA (pvrusb2 and ivtv drivers).
Not sure if, in such cases, we should export the two I/O endpoints as two separate entities or just one. I guess exporting it as two separate I/O endpoints make more sense, as the interface to control the I/O will be different, and it will very likely use different ringbuffers on the different interfaces.
I think referring to the entity (that corresponds to a piece of hardware, with some exceptions) by a (Linux) software interface looks hackish.
Well, technically speaking, the I/O graph elements are actually a Linux software interface.
Ok, on most cases, it could be associated with a DMA hardware block, but still the DMA engine is controlled via the Linux API - QBUF/DQBUF or via read()/write()/poll() syscalls.
Also, except for DMA engines, the I/O is actually done via some sort of ringbuffer. That is the case of V4L2 read()/write(), ALSA[1] and DVB.
We could, instead, map such graph elements as interfaces, but then we'll have troubles with old API support. Also, the I/O block.
[1] ALSA might use DMA, but, last time I checked, pulseaudio doesn't support mmap. So, AFAIK, the usual API is to receive a buffer via read() syscall.
Regards, Mauro