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" > media-ctl -l "'ipu1_csi0_mux':2 -> 'ipu1_csi0':0" > media-ctl -l "'ipu1_csi0':2 -> 'ipu1_csi0 capture':0" > > 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" 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. 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 ? > 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. regards Philipp