On 04/22/2016 10:23 AM, Jean-Michel Hautbois wrote: > Hi Hans, > > 2016-04-22 10:08 GMT+02:00 Hans Verkuil <hverkuil@xxxxxxxxx>: >> 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@xxxxxxxxxxxxxxx >> 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@xxxxxxxxxxxxxxx > 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
