On Mon, 2018-04-16 at 09:54 +0200, Ibtsam Ul-Haq wrote: [...] > This indeed looks the case. But then, is 'GR16' the FourCC for 'SGRBG16'? Yes, see Documentation/media/uapi/v4l/pixfmt-srggb16.rst: https://linuxtv.org/downloads/v4l-dvb-apis-new/uapi/v4l/pixfmt-srggb16.html > To be honest, I had not seen GR16 as FourCC before. > And the Gstreamer debug logs (I used GST_DEBUG=5) also say that they > do not know this FourCC: > v4l2 gstv4l2object.c:1541:gst_v4l2_object_v4l2fourcc_to_bare_struct: [00m > Unsupported fourcc 0x36315247 GR16 The GStreamer V4L2 elements currently only support 8-bit per component Bayer formats. > Is there a way we can get by this? There's two ways to handle this correctly, IMHO. One would be adding SGRBG8_1X8 support to the mt9p031 driver. This is the correct way if the device tree is configured for 8-bit parallel and there are only 8 data lines connected between camera and SoC. As a quick hack, I think you could just: sed "s/MEDIA_BUS_FMT_SGRBG12_1X12/MEDIA_BUS_FMT_SGRBG8_1X8/" -i drivers/media/i2c/mt9p031.c The other would be to connect all 12 data lines, configure the device tree with 12 bit data width, and extend the imx-media CSI subdevice driver to allow setting SGRBG12_1X12 on the sink pad and SGRBG8_1X8 on the source pad at the same time (and then just internally configuring the hardware to 8-bit, ignoring the 4 LSB). That would be a bit more involved. Another possiblity would be to replace v4l2_subdev_link_validate() in drivers/media/v4l2-core/v4l2-subdev.c with a variant that allows source_fmt->format.code != sink_fmt->format.code in case the source format can be turned into the sink format by just dropping LSB for one of the links. regards Philipp
