[libcamera-devel] Video recording on PinePhone Re: libcamera on pinephone

Nicolas Dufresne nicolas at ndufresne.ca
Mon Jul 18 17:10:59 CEST 2022


Le samedi 16 juillet 2022 à 00:52 +0200, Pavel Machek via libcamera-devel a
écrit :
> > 
> > > Second, no. If we do read(), it is simple interface, kernel will be
> > > doing the copying, and it is free to do the usual magic to speed
> > > things up. (I suppose simply working with memory as cached and using
> > > flush_dcache_range). 
> > 
> > Regardless of whether or not drivers could speed things up with read(),
> > read() is not the way forward. It's deprecated for V4L2 camera devices,
> > so we won't use it in libcamera, the way forward is to fix V4L2 memory
> > mapping with cache management.
> 
> If I wanted to attempt that, do you have hints/ideas where to start?

You'll find some hints through the 
V4L2_BUF_CAP_SUPPORTS_MMAP_CACHE_HINTS support. This feature does NOT work for
DMABuf at ALL, be aware (and only 1 driver enables that feature, which needs to
be opt-in by userland).

There was some discussion again recently [0]. The problem is that what ARM folks
need to achieve on these platform have simply not been fully designed and agreed
on. Also, there is massive knowledge gaps when folks like you and I try to
improves things, as the cache mechanism is far for an homogeneous concepts
across brand and familiy of computers. Not to add that it seems some drivers
(AMD) have exposed on a single device multiple internal devices for which don't
live in the same coherency space. This isn't illegal as per any rules in the
kernel, but it breaks the only currently available option for handling cross-
domain coherency, which is exporter driven handling.

regards,
Nicolas

[0] https://lore.kernel.org/all/91ff0bbb-ea3a-2663-3453-dea96ccd6dd8@amd.com/


More information about the libcamera-devel mailing list