Hi Michal, On Friday 18 February 2011 12:37:24 Michal Nazarewicz wrote: [snip] > What I'm trying to say is that it would be best if one could configure the > device in such a way that switching between modes would not require the > device to free buffers (even though in user space they could be > inaccessible). > > > This is what I have in mind the usage would look like: > > 1. Open device > Kernel creates some control structures, the usual stuff. > 2. Initialize multi-format (specifying what formats user space will use). > Kernel calculates amount of memory needed for the most > demanding format and allocates it. Don't forget that applications can also use USERPTR. We need a low-latency solution for that as well. > 3. Set format (restricted to one of formats specified in step 2) > Kernel has memory already allocated, so it only needs to split > it to buffers needed in given format. > 4. Allocate buffers. > Kernel allocates memory needed for most demanding format > (calculated in step 2). > Once memory is allocated, splits it to buffers needed in > given format. > 5. Do the loop... queue, dequeue, all the usual stuff. > Kernel instructs device to handle buffers, the usual stuff. When buffers are queued cache needs to be cleaned. This is an expensive operation, and we need to be able to pre-queue (or at least pre-clean) buffers. > 6. Free buffers. > Kernel space destroys the buffers needed for given format > but DOES NOT free memory. > > 7. If not done, go to step 3. > > 8. Finish multi-format mode. > Kernel actually frees the memory. > > 9. Close the device. > > A V4L device driver could just ignore step 2 and 7 and work in the less > optimal mode. > > If I understand V4L2 correctly, the API does not allow for step 2 and 8. > In theory, they could be merged with step 1 and 9 respectively, I don't > know id that feasible though. -- 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
