Hi, >Aguirre, Sergio wrote: >Basically, when calling VIDIOC_REQBUFS with a certain buffer >Count, we had a software limit for total size, calculated depending on: > > Total bytesize = bytesperline x height x count > >So, we had an arbitrary limit to, say 32 MB, which was generic. > >Now, we want to condition it ONLY when MMAP buffers will be used. >Meaning, we don't want to keep that policy when the kernel is not >allocating the space > >But the thing is that, according to videobuf documentation, buf_setup is >the one who should put a RAM usage limit. BUT the memory type passed to >reqbufs is not propagated to buf_setup, therefore forcing me to go to a >non-standard memory limitation in my reqbufs callback function, instead >of doing it properly inside buf_setup. buf_setup is called during REQBUFS and is indeed the place to limit the size and actually allocate the buffers as well, or at least try to do so, as V4L2 API requires. This is not currently the case with videobuf, but right now we are working to change it. buf_prepare() is called on QBUF and it is definitely too late to do things like that then. It is the REQBUFS that should be failing if the requested number of buffers is too high. You could also (although it's very hacky) just take one of the buffers from vq passed to buf_setup and check its memory field. >Is this scenario a good consideration to change buf_setup API, and >propagate buffers memory type aswell? I agree with Mauro that there should not be a restriction for MMAP only, for the same reasons he already pointed out. As I mentioned, an intensive work is underway to change the buf_* API in videobuf at the moment, so if you have any recommendation/requirements that you feel would be useful, please let us know. Best regards -- Pawel Osciak Linux Platform Group Samsung Poland R&D Center -- 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
