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

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

[Hans Verkuil]

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.

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.

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

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

[Jean-Michel Hautbois]

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 ?

> 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...

> 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

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

[Hans Verkuil]

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
>