<div dir="ltr">Hi,<br><br>Just in case folks want something to ponder over the coming holidays, I have a<br>question on Camera::stop().  This has been brought up in the past, but never<br>really resolved.  The documentation for the API call is not explicit on what<br>happens to resource allocations in the pipeline handlers once Camera::stop()<br>completed.<br><br>The Raspberry Pi pipeline handler keeps all framebuffer allocations around after<br>PipelineHandlerRPi::stopDevice() completes.  This is so that we do not have to<br>re-allocate buffers (and possibly cause fragmentation in the CMA heap) between<br>calls to Camera::stop() and Camera::start() from the application.  Of course,<br>if Camera::configure() is called in-between, buffer allocations are cleared and<br>re-allocated for the new configurations requested.<br><br>Now this is all fine, but it turns out lc-compliance expects resources to be<br>freed on a call to Camera::stop(), as subsequent calls to Camera::start() during<br>some tests try to re-allocate buffers again.  And this fails as the buffers<br>are already allocated by the device.  The "fix" to the tests are simple, do not<br>re-allocate between calls to Camera::stop() and Camera::start(), but I expect<br>this will break other pipeline handlers.<br><br>So the question is, what should the behavior be?  We really don't want to<br>reallocate buffers between Camera::stop() and Camera::start() if there is no<br>configuration change - as mentioned earlier this will cause CMA fragmentation and<br>does break some of our use cases.  Would it be reasonable to pass a flag like<br>Camera::stop(bool releaseAllocations) to explicitly request a particular<br>behavior from the application?<br><br>Thanks,<br>Naush<br></div>