[libcamera-devel] Behaviour of Camera::stop()

Naushir Patuck naush at raspberrypi.com
Fri Dec 16 16:00:03 CET 2022


Hi,

Just in case folks want something to ponder over the coming holidays, I
have a
question on Camera::stop().  This has been brought up in the past, but never
really resolved.  The documentation for the API call is not explicit on what
happens to resource allocations in the pipeline handlers once Camera::stop()
completed.

The Raspberry Pi pipeline handler keeps all framebuffer allocations around
after
PipelineHandlerRPi::stopDevice() completes.  This is so that we do not have
to
re-allocate buffers (and possibly cause fragmentation in the CMA heap)
between
calls to Camera::stop() and Camera::start() from the application.  Of
course,
if Camera::configure() is called in-between, buffer allocations are cleared
and
re-allocated for the new configurations requested.

Now this is all fine, but it turns out lc-compliance expects resources to be
freed on a call to Camera::stop(), as subsequent calls to Camera::start()
during
some tests try to re-allocate buffers again.  And this fails as the buffers
are already allocated by the device.  The "fix" to the tests are simple, do
not
re-allocate between calls to Camera::stop() and Camera::start(), but I
expect
this will break other pipeline handlers.

So the question is, what should the behavior be?  We really don't want to
reallocate buffers between Camera::stop() and Camera::start() if there is no
configuration change - as mentioned earlier this will cause CMA
fragmentation and
does break some of our use cases.  Would it be reasonable to pass a flag
like
Camera::stop(bool releaseAllocations) to explicitly request a particular
behavior from the application?

Thanks,
Naush
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.libcamera.org/pipermail/libcamera-devel/attachments/20221216/341e9cd4/attachment.htm>


More information about the libcamera-devel mailing list