Hi, On 02/26/2012 09:58 PM, Guennadi Liakhovetski wrote: >>> It might be difficult to completely eliminate the CPU, at the very least >>> you need to queue and dequeue buffers to and from the V4L driver. To avoid >>> even that, in principle, you could try to use only one buffer, but I don't >>> think the current version of the mx3_camera driver would be very happy >>> about that. You could take 2 buffers and use panning, then you'd just have >>> to send queue and dequeue buffers and pan the display. But in any case, >>> you probably will have to process buffers, but your most important >>> advantage is, that you won't have to copy data, you only have to move >>> pointers around. >> >> The method that you describe is exactly what I had in mind. >> It would be more correct to say it is "minimum" CPU intervention and not without CPU intervention. > >> As far I understand, I can implement MMAP method for frame buffer device >> and pass this pointer directly to mx3_camera driver with use USERPTR >> method, then send queue and dequeue buffers to mx3_camera driver. >> What is not clear, if it is possible to pass the same pointer of frame >> buffer in mx3_camera, if the driver is using two buffers? <It should work when you request 2 USERPTR buffers and assign same address (>frame buffer start) to them. I've seen setups like this working with <videbuf2 based drivers. Thanks for you information this is what I had in mind :-) <However it's really poor configuration, to avoid tearing <you could just set framebuffer virtual window size to contain at least <two screen windows and for the second buffer use framebuffer start address <with a proper offset as the USERPTR address. Then you could just add <display panning to display every frame. Looks good I'll try to implement this method. Thank you for your advice. Regards, Alex Gershgorin -- 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
