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

Reply via email to