Hello,
the i.MX8QM and i.MX8QXP contain MIPI CSI-2 controllers that forward the
received data on a parallel bus to the Image Sensing Interface (ISI) of
the chip. If the data on the MIPI bus is in any of the six RAW formats
defined for CSI-2, the CSI controller will shift the values so that the
msb is always in bit 13. This was most likely done to allow following
hardware to process the data as RAW14 regardless of the actual RAW format.
Unfortunately the ISI is not able to shift the bits back before writing it
to memory. RAW8 data therefore has to be saved in two bytes per sample with
two unused bits at the top and six unused bits at the bottom.
The drivers for the hardware are still being developed in NXP's repository
at CodeAurora. We have extended them to support greyscale and Bayer
cameras. Now all we need are stable defines for the pixel and media bus
formats for use in libraries and applications and documentation for people
to know their meaning.
To keep the number of needed formats low, we would like to ignore that
there might be unused bits at the bottom. Then we can use the existing
MEDIA_BUS_FMT_S{BGGR,GBRG,GRBG,RGGB}14_1X14 formats between the CSI
controller and the ISI and just have to add a MEDIA_BUS_FMT_Y14_1X14
format. For the pixel formats we would add V4L2_PIX_FMT_Y14 and rebase
e38d5f254ad8 from Sakari's packed12-postponed branch for Bayer.
Now the questions:
- Is it acceptable to use MEDIA_BUS_FMT_Y14_1X14 in this case instead of
using MEDIA_BUS_FMT_Y12_1X14_PADLO, MEDIA_BUS_FMT_Y10_1X14_PADLO,
MEDIA_BUS_FMT_Y8_1X14_PADLO, MEDIA_BUS_FMT_Y7_1X14_PADLO,
MEDIA_BUS_FMT_Y6_1X14_PADLO? Another 20 _PADLO formats would have to
be added for Bayer.
- Given the history of Sakari's packed12-postponed branch, is there a
chance to get these definitions merged into mainline although the
driver is not? I fear that NXP's drivers will not hit mainline for a
long time.
- Sakari, do you mind me adding the same license header to your
pixfmt-y14.rst that is used by all other pixfmt-y*.rst files?
Best regards,
Daniel
