Re: [RFC] Streaming I/O: proposal to expose MMAP/USERPTR/DMABUF capabilities with QUERYCAP

[Hans Verkuil <hverkuil@xs4all.nl>]

On 04/22/2016 10:23 AM, Jean-Michel Hautbois wrote:
> Hi Hans,
> 
> 2016-04-22 10:08 GMT+02:00 Hans Verkuil <hverkuil@xs4all.nl>:
>> Hi all,
>>
>> I have always been unhappy with the fact that it is so hard to tell whether
>> the USERPTR and/or DMABUF modes are available with Streaming I/O. QUERYCAP
>> only tells you if Streaming I/O is available, but not in which flavors.
>>
>> So I propose the following:
>>
>> #define V4L2_CAP_STREAMING_MMAP V4L2_CAP_STREAMING
>> #define V4L2_CAP_STREAMING_USERPTR 0x08000000
>> #define V4L2_CAP_STREAMING_DMABUF  0x10000000
>>
>> All drivers that currently support CAP_STREAMING also support MMAP. For userptr
>> and dmabuf support we add new caps. These can be set by the core if the driver
>> uses vb2 since the core can query the io_modes field of vb2_queue.
> 
> So, you want to make it mandatory for future drivers that they support
> MMAP. Fine with me.
> BTW, dmabuf is still marked as experimental, what would make it part
> of the API for good ?

Just laziness on our part. I think I should go through the docs and update these
things. Most things marked experimental can probably drop that designation.

> 
>> For the drivers that do not yet support vb2 we can add it manually.
>>
>> I was considering making it a requirement that the MMAP streaming mode is
>> always present, but I don't know if that works once we get drivers that operate
>> on secure memory. So I won't do that for now.
> 
> By using "#define V4L2_CAP_STREAMING_MMAP V4L2_CAP_STREAMING" you make
> it mandatory... You would need a separate bit to indicate MMAP
> otherwise...

No: all *current* drivers marked CAP_STREAMING support MMAP. But future devices
that might not support MMAP would not set this cap.

So it is possible that in the future you'd get a driver that has just STREAMING_DMABUF
set. Which is something I can imagine for drivers operating on secure memory.

Regards,

	Hans

> 
>> Since we are looking at device caps anyway: can we just drop V4L2_CAP_ASYNCIO?
>> It's never been implemented, nor is it likely in the future. And we don't have
>> all that many bits left before we need to use one of the reserved fields for
>> additional capabilities.
>>
>> Regards,
>>
>>         Hans
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-media" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>