35 lines
1.4 KiB
Plaintext
35 lines
1.4 KiB
Plaintext
1) Support dma-buf memory management.
|
|
|
|
In order to zero-copy import camera images into the 3D or display
|
|
pipelines, we need to export our buffers through dma-buf so that the
|
|
vc4 driver can import them. This may involve bringing in the VCSM
|
|
driver (which allows long-term management of regions of memory in the
|
|
space that the VPU reserved and Linux otherwise doesn't have access
|
|
to), or building some new protocol that allows VCSM-style management
|
|
of Linux's CMA memory.
|
|
|
|
2) Avoid extra copies for padding of images.
|
|
|
|
We expose V4L2_PIX_FMT_* formats that have a specified stride/height
|
|
padding in the V4L2 spec, but that padding doesn't match what the
|
|
hardware can do. If we exposed the native padding requirements
|
|
through the V4L2 "multiplanar" formats, the firmware would have one
|
|
less copy it needed to do.
|
|
|
|
3) Port to ARM64
|
|
|
|
The bulk_receive() does some manual cache flushing that are 32-bit ARM
|
|
only, which we should convert to proper cross-platform APIs.
|
|
|
|
4) Convert to be a platform driver.
|
|
|
|
Right now when the module probes, it tries to initialize VCHI and
|
|
errors out if it wasn't ready yet. If bcm2835-v4l2 was built in, then
|
|
VCHI generally isn't ready because it depends on both the firmware and
|
|
mailbox drivers having already loaded.
|
|
|
|
We should have VCHI create a platform device once it's initialized,
|
|
and have this driver bind to it, so that we automatically load the
|
|
v4l2 module after VCHI loads.
|
|
|