Hi Philipp,

Thanks a lot for your response.

On Fri, Apr 13, 2018 at 4:18 PM, Philipp Zabel <p.za...@pengutronix.de> wrote:
> Hi Ibtsam,
> On Thu, 2018-04-12 at 16:00 +0200, Ibtsam Ul-Haq wrote:
>> Greetings everyone,
>> I am using Linux 4.14.31 on an IMX6 platform, with an MT9P031 sensor
>> attached to the ipu1_csi0 (parallel).
>> My Gstreamer version is 1.14.0 and v4l-utils version is 1.14.2.
>> The problem is that I am unable to set up a capture pipeline.
>> Even the simplest capture pipeline such as:
>> gst-launch-1.0 v4l2src device=/dev/video4 ! fakesink
>> returns the following error:
>> ERROR: from element /GstPipeline:pipeline0/GstV4l2Src:v4l2src0:
>> Internal data stream error.
>> Additional debug info:
>> ../../../../gstreamer-1.14.0/libs/gst/base/gstbasesrc.c(3055):
>> gst_base_src_loop (): /GstPipeline:pipeline0/GstV4l2Src:v4l2src0:
>> streaming stopped, reason not-negotiated (-4)
>> ERROR: pipeline doesn't want to preroll.
>> I get the same error on any pipeline involving v4l2src.
>> I have set up the media entity links using:
>> media-ctl -l "'mt9p031 0-0048':0 -> 'ipu1_csi0_mux':1[1]"
>> media-ctl -l "'ipu1_csi0_mux':2 -> 'ipu1_csi0':0[1]"
>> media-ctl -l "'ipu1_csi0':2 -> 'ipu1_csi0 capture':0[1]"
>> And I configure the pads using:
>> media-ctl -V "'mt9p031 0-0048':0 [fmt:SGRBG8/640x480 field:none]"
>> media-ctl -V "'ipu1_csi0_mux':2 [fmt:SGRBG8/640x480 field:none]"
>> media-ctl -V "'ipu1_csi0':2 [fmt:SGRBG8/640x480 field:none]"
> What is the actual format that all pads are configured to? I found it
> helpful to double check the whole pipeline after configuring pads (or
> use media-ctl -v):
> media-ctl --get-v4l2 "'mt9p031 0-0048':0"
> media-ctl --get-v4l2 "'ipu1_csi0_mux':1"
> media-ctl --get-v4l2 "'ipu1_csi0_mux':2"
> media-ctl --get-v4l2 "'ipu1_csi0':0"
> media-ctl --get-v4l2 "'ipu1_csi0':2"

Here is what I get after I have executed the commands to configure all
the pads to SGRBG8/640x480:

:~# media-ctl --get-v4l2 "'mt9p031 0-0048':0"
[fmt:SGRBG12_1X12/648x486 field:none colorspace:srgb

:~# media-ctl --get-v4l2 "'ipu1_csi0_mux':1"
[fmt:SGRBG12_1X12/648x486 field:none colorspace:srgb]

:~# media-ctl --get-v4l2 "'ipu1_csi0_mux':2"
[fmt:SGRBG12_1X12/648x486 field:none colorspace:srgb]

:~# media-ctl --get-v4l2 "'ipu1_csi0':0"
[fmt:SGRBG12_1X12/656x486@1/30 field:none colorspace:srgb xfer:srgb
ycbcr:601 quantization:full-range

:~# media-ctl --get-v4l2 "'ipu1_csi0':2"
[fmt:SGRBG12_1X12/656x486@1/30 field:none colorspace:srgb xfer:srgb
ycbcr:601 quantization:full-range]

> I assume that because mt9p031 only supports SGRBG12_1X12, that's what
> will be propagated down the pipeline to the CSI, which will then expand
> it to SGRBG16.

This indeed looks the case. But then, is 'GR16' the FourCC for 'SGRBG16'?
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

Is there a way we can get by this?

> I suppose we should allow, at least for parallel input, to let the CSI
> 'convert' 12-bit input formats to 8-bit output formats by just ignoring
> the LSBs.
> Another possibility would be to just allow SGRBG12_1X12 -> SGRBG8_1X8
> mbus codes in link_validate. Actually, does your hardware have 12 data
> lines connected between sensor and i.MX6, or just 8 ?

Currently we have 8. Although we can populate extra resistors to
connect the remaining 4.
The device tree is set for 8 lines currently.

>> And I do not get any errors from these commands.
> That's because of the way the V4L2 API works, unsupported formats are
> adjusted by the drivers:
> https://linuxtv.org/downloads/v4l-dvb-apis-new/uapi/v4l/vidioc-subdev-g-fmt.html#description
> [...]
>> What confuses me here is that the Pixel Format shown by v4l2-ctl is
>> 'GR16', which is not what I expected. And it seems like the media-ctl
>> pad configuration commands are unable to change the Pixel Format, even
>> though they do not return any errors.
> Whenever you media-ctl -V on a source pad, it will also try to set the
> connected sink pad to the same format. And for subdevices with sink and
> source pads, the source pads usually mirror (or somehow depend on) the
> format of the sink pad. Due to the way the V4L2 APIs correct your input
> to possible values, calling media-ctl -V on all source pads of the
> pipeline in downstream direction essentially propagates the sensor
> source pad format.

Thanks for the nice explanation. This is valuable learning for me as I
am just a beginner in this stuff.

> regards
> Philipp

Best regards,
Ibtsam Haq

Reply via email to