Hi Michal, On Friday 18 February 2011 15:05:42 Michal Nazarewicz wrote: > > On Friday 18 February 2011 14:19:44 Michal Nazarewicz wrote: > >> Cache operations are always needed, aren't they? Whatever you do, you > >> will always have to handle cache coherency (in one way or another) so > >> there's nothing we can do about it, or is there? > > On Fri, 18 Feb 2011 14:21:53 +0100, Laurent Pinchart wrote: > > To achieve low latency still image capture, you need to minimize the time > > spent reconfiguring the device from viewfinder to still capture. Cache > > cleaning is always needed, but you can prequeue buffers you can clean the > > cache in advance, avoiding an extra delay when the user presses the still > > image capture button. > > If there is enough time to perform those operation while preview is shown > (ie. several frames pare second), why would there not be enough time to > perform those operations for still image capture? For still image capture you want to minimize the shot-to-snapshot delay (delay between the time when the user presses the shot button and the time when the image is captured). Allocating memory for the buffers and prequeuing them should thus be done before the user presses the shot button. > If I understand you correctly, what you are describing is a situation where > one has set of buffers for preview and a buffer for still image laying > around waiting to be used, right? That's correct. That's what we currently do with the OMAP3 ISP. > Such scheme will of course work, but I'm just suggesting to think of > a scheme where the unused buffer for still image is reused for preview > frames when preview is shown. That will work as well, but it will increase the shot-to-snapshot delay as cache management will need to be performed after the user presses the shot button. -- 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
