Hi Sergio, On Thursday 06 May 2010 01:29:54 Aguirre, Sergio wrote: > > -----Original Message----- > > From: Mauro Carvalho Chehab [mailto:mchehab@xxxxxxxxxx] > > Sent: Wednesday, May 05, 2010 6:24 PM > > To: Aguirre, Sergio > > Cc: linux-media@xxxxxxxxxxxxxxx > > Subject: Re: [videobuf] Query: Condition bytesize limit in > > videobuf_reqbufs -> buf_setup() call? > > > > Aguirre, Sergio wrote: > > > Hi all, > > > > > > While working on an old port of the omap3 camera-isp driver, > > > I have faced some problem. > > > > > > 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. > > > > > > Is this scenario a good consideration to change buf_setup API, and > > > propagate buffers memory type aswell? > > > > I don't see any problem on propagating the memory type to buffer_setup, > > if this is really needed. Yet, I can't see why you would restrict the > > buffer size to 32 MB on one case, and not restrict the size at all with > > non-MMAP types. > > Ok, my reason for doing that is because I thought that there should be a > memory limit in whichever place you're doing the buffer allocations. > > MMAP is allocating buffers in kernel, so kernel should provide a memory > restriction, if applies. > > USERPTR is allocating buffers in userspace, so userspace should provide a > memory restriction, if applies. I agree with the intend here, but not with the current implementation which has a hardcoded arbitrary limit. Do you think it would be possible to compute a meaningful default limit in the V4L2 core, with a way for userspace to modify it (with root privileges of course) ? -- Regards, Laurent Pinchart -- 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
