I am trying to capture RGB888 data via the MIPI-CSI2 link on an IMX8M.
I had to modify the mx6s_capture.c driver to set the PARALLEL24_EN bit in register CSIRC18 (otherwise all I got was bits 2-9 of each 24-bit pixel). Setting the PARALLEL24_EN bit got me all 24 bits of the RGB888 pixels, but unfortunately it looks as though the CSI bridge is padding a zero byte onto each pixel, so that the pixels go from 24 bits wide to 32 bits wide. That is, each 32-bit word in the bridge fifo contains a 24-bit RGB pixel with a zero byte added as padding.
The IMX7 reference manual states -- section 18.104.22.168.3 -- (for some bizarre reason, the CSI bridge is completely undocumented in the IMX8M manual, you *really* need to fix that)
An optional scheme to pack a dummy byte is provided. For every group of 3 bytes data, a
dummy zero is packed to form a 32-bit word as shown in the figure below. The dummy
zero can be packed at the LSB position or MSB position. Using
RGB888A_FORMAT_SEL in CSI_CSICR18 to determine to put the dummy bytes
packed at LSB or MSB position.
I see the bit in CSICR18 that controls *where* the zero byte gets added (lsb v msb), but I don't see any bit that stops the zero-byte padding altogether, as the first sentence in the above quote suggests.
Is there a way to disable the zero-byte padding for RGB888 data?
Alternatively, is there any way to make the zero pad byte drop away when transferring data out of the bridge fifo? (Other than software repacking the image data?)