07:35 <pivi> javierm: good to know, I should also test something in this area, but I have more urgent stuff to do before ... I'll follow-up on your progresses, thanks!

07:36 <javierm> pivi: sure, I'll let you know!

11:41 <jluthra> javierm: ah, so the EPIPE issue is expected for any resolution/format other than the OV5640 default (640x480 UYVY)

11:42 <jluthra> javierm: the fix for that involes running `media-ctl -V` on the cdns subdev and ticsi2rx subdevs to match the format the sensor is sending

11:44 <NishanthMenon> jluthra: it does'nt automatically match up?

11:45 <jluthra> javierm: the gstreamer pipeline requires support for 10-bit bayer formats though, as OV5647 sensor driver currently only sends 10-bit bayer. That support was only recently merged https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4686 - so I'm not sure if that has hit the debian repositories

11:45 <jluthra> NishanthMenon: no, with embedded camera pipelines the userspace has to do all the matching up. drivers are not supposed to read across the "links" to see what the other device is sending

11:45 <NishanthMenon> jluthra: aah.. thanks

11:47 <jluthra> libcamera helps there, if you use the cam tool in debian sid you can just run a single command and it will configure the full media graph for you. same for their libcamerasrc gstreamer element (instead of v4l2src)

11:47 <jluthra> i've tested it with debian sid on am62 with different sensors, worked flawlessly

12:28 <NishanthMenon> javierm pivi ^^

13:36 <javierm> jluthra: I thought that this would be propagated when setting the sensor (source) pad ?

13:37 <javierm> becase as mentioned I did: media-ctl -V '"ov5647 4-0036":0[SRGGB10_1X10/640x480]'

13:38 <javierm> jluthra: and with that I saw the media-ctl -p output to show the proper format in the ticsi2rx sink pad: https://paste.centos.org/view/raw/e2e1e21d

13:38 <javierm> but I still get -EPIPE...

13:38 <javierm> jluthra: I also tried with libcamesrc yesterday but didn't work either

13:38 <javierm> https://paste.centos.org/view/raw/967e6155

13:39 <javierm> problem in that case is: ioctl(14, VIDIOC_ENUM_FRAMESIZES, {index=1, pixel_format=v4l2_fourcc('B', 'G', '1', '0') /* V4L2_PIX_FMT_SBGGR10 */}) = -1 EINVAL (Invalid argument)

13:49 <javierm> jluthra: just to be clear, you tested on debian with libcamera (libcamerasrc gst element) using the same sensor (OV5647) ?

14:15 <javierm> jluthra: cam (from libcamera) takes me a little bit further indeed, but `cam --camera=1 --file=frames.raw --capture=10` hangs on poll()

14:15 <javierm> ppoll([{fd=10, events=POLLIN}, {fd=15, events=POLLIN}, {fd=11, events=POLLIN}], 3, NULL, NULL, 8)

14:15 <javierm> so it does VIDIOC_QBUF but never VIDIOC_DQBUF

15:58 <javierm> the media-ctl command to get the same media pipeline config that libcamera/cam does is:

15:58 <javierm> media-ctl --set-v4l2 '"cdns_csi2rx.30101000.csi-bridge":0[SBGGR10_1X10/640x480 colorspace:rec709 xfer:srgb ycbcr:601 quantization:lim-range]'

15:59 <javierm> with that, v4l2-ctl --device /dev/video0 --stream-mmap=2 --stream-count=10 --stream-to=/dev/null hangs VIDIOC_DQBUF. I wonder if the problem is on my DTB...

15:59 <javierm> jluthra: if you can share your DTS snippet for ov5647, that would be great

21:27 <pivi> jluthra: thanks for the comment, here. Just for my curiosity, are you using the kernel from Debian sid or just the userspace?