Fwd: XISP : Creating new Pipeline Handler for AMD/Xilinx HLS-based ISP

Mon Feb 10 16:11:15 CET 2025

Hi,

Le dimanche 09 février 2025 à 14:29 -0500, Mario Bergeron a écrit :
> Thank you Kieran and Laurent,
> 
> Sorry for the delay in my response ... it took me a while to learn how to
> "enable v4l2 debug" ... 
> It was indeed fun, since I did not know about this, and it seemed like
> opening a treasure chest :)
> Your feedback steered me in the proper direction.

To make this a little more discoverable, we now have an initial documentation
page upstream:

https://www.kernel.org/doc/html/v6.13/process/debugging/media_specific_debugging_guide.html

> 
> I started with the following observations:
> - after the error with my xisp pipeline handler, I was still able to launch a
> gstreamer pipeline with v4l2src
> - the error fails at following code in V4L2VideoDevice::queueBuffer() : ret =
> ioctl(VIDIOC_QBUF, &buf);
> This gave me the intuition that the problem was not with my V4LSubdevices, but
> rather my V4LVideoDevice.
> 
> I did not enable "dynamic_debug" in the kernel, but enabled the following v4l
> debug for my V4LVideoDevice:
>    echo 3 > /sys/class/video4linux/video0/dev_debug
>    echo 3 > /sys/module/videobuf2_common/parameters/debug
> 
> The debug log was not very intuitive for me, but it turned out it did hold
> information on the culprit:
> 
> ...
> [250879.144584] video0: VIDIOC_S_FMT: type=vid-cap-mplane, width=640,
> height=480, format=BGR3 little-endian (0x33524742), field=none, colorspace=0,
> num_planes=0, flags=0x0, ycbcr_enc=0, quantization=0, xfer_func=0
> ...
> 
> The "num_planes=0" was incorrect, and the cause of my issue.
> 
> After going back to my "configure" function, and properly configuring the
> format for the V4L2VideoDevice, 
> 
>     ...
>     captureFormat.fourcc = pipe->capture-
> >toV4L2PixelFormat(config.pixelFormat);
>     captureFormat.size = config.size;
> 
>     const PixelFormatInfo &info = PixelFormatInfo::info(config.pixelFormat);
> 
>     captureFormat.planesCount = info.numPlanes();
>     captureFormat.planes[0].bpl = config.stride;
> 
>     /* \todo Set stride and format. */
>     ret = pipe->capture->setFormat(&captureFormat);
>     ...
> 
> I got the following change in the v4l2 debug messages:
> 
> ...
> [  474.808502] video0: VIDIOC_S_FMT: type=vid-cap-mplane, width=640,
> height=480, format=BGR3 little-endian (0x33524742), field=none, colorspace=0,
> num_planes=1, flags=0x0, ycbcr_enc=0, quantization=0, xfer_func=0
> [  474.808570] plane 0: bytesperline=1920 sizeimage=921600
> ...
> 
> With these modifications, I was able to capture my first image:
> 
> root at uzev-hailo-2024-1:~/libcamera.xisp_take01/build# cam -c1 -C1
> ...
> Using camera /base/pl-bus/i2c at 80040000/sensor at 10 as cam0
> [0:13:58.267167846] [804]  INFO Camera camera.cpp:1202 configuring streams:
> (0) 640x480-RBG888
> cam0: Capture 1 frames
> 838.393150 (0.00 fps) cam0-stream0 seq: 000000 bytesused: 921600
> 
> 
> Thank you again !
> 
> Cheers !
> 
> Mario Bergeron (AlbertaBeef)
> 
> 
> 
> 
> On Fri, Jan 17, 2025 at 4:25 AM Laurent Pinchart
> <laurent.pinchart at ideasonboard.com> wrote:
> > On Fri, Jan 17, 2025 at 08:58:47AM +0000, Kieran Bingham wrote:
> > > Quoting Laurent Pinchart (2025-01-17 06:10:14)
> > > > On Thu, Jan 16, 2025 at 11:34:31PM +0000, Kieran Bingham wrote:
> > > > > Quoting Mario Bergeron (2025-01-16 22:04:06)
> > > > > > Hello,
> > > > > > 
> > > > > > I have made some progress on my XISP pipeline handler.
> > > > > > 
> > > > > > I am able to enumerate the four (4) cameras in my system:
> > > > > > 
> > > > > > # cam -l
> > > > > > ...
> > > > > > Available cameras:
> > > > > > 1: 'imx219' (/base/pl-bus/i2c at 80040000/sensor at 10)
> > > > > > 2: 'imx708_wide' (/base/pl-bus/i2c at 80070000/sensor at 10)
> > > > > > 3: 'imx500' (/base/pl-bus/i2c at 80090000/sensor at 1a)
> > > > > > 4: 'imx477' (/base/pl-bus/i2c at 800b0000/sensor at 1a)
> > > > > > 
> > > > > > 
> > > > > > When I attempt to capture one frame, I get the following error
> > message when
> > > > > > queueing buffers:
> > > > > > 
> > > > > > # cam -c1 -C1
> > > > > > ...
> > > > > > Using camera /base/pl-bus/i2c at 80040000/sensor at 10 as cam0
> > > > > > [51:33:28.743843521] [53606]  INFO Camera camera.cpp:1202
> > configuring
> > > > > > streams: (0) 640x480-RBG888
> > > > > > cam0: Capture 1 frames
> > > > > > [51:33:28.782733421] [53607] ERROR V4L2 v4l2_videodevice.cpp:1777
> > > > > > /dev/video0[16:cap]: Failed to queue buffer 0: Invalid argument
> > > > > 
> > > > > This is quite often a failure to conifgure the pipeline correctly and
> > > > > propagate formats through from the camera to the ISP for all of the
> > link
> > > > > validations.
> > > > 
> > > > I'd expect a -EPIPE error in such a case, but we're dealing with an
> > > > out-of-tree driver here that may not return the right error codes.
> > > 
> > > Ah yes, I chose my words poorly - but I hope the intent/actions are
> > > still the same. Yesterday, we tackled an issue with the same 'symptom'
> > > on a -EINVAL at queue buffer time because the CSI2 receiver was being
> > > configured with an out of bounds link frequency. I 'wrapped that up as
> > > link validation' in my head - but it is a bit distinct.
> > > 
> > > The principle issue is - there are many components that often all get
> > > started when you first queue a buffer (even though there's a stream on
> > > call, that can often be deferred to the first buffer being available).
> > 
> > I really dislike how queuing buffers can fail due to misconfigured
> > pipelines, and I consider that as driver bugs. Some of those bugs can't
> > be fixed without changes to frameworks, but we really need to aim at
> > improving all this.
> > 
> > > Unfortunately - many debug and error paths are often disabled in v4l2
> > > by default to prevent rogue applications flooding kernel logs. I do
> > > wish it was clearer what went wrong sometimes - but that's why we turn
> > > on all the logging when it fails.
> > > 
> > > > > I usually make sure I enable all v4l2 debug at this stage on the
> > > > > subdevices and video devices to be sure all dbg prints come out from
> > the
> > > > > kernel - and check to see what's failing.
> > > > 
> > > > And in the worst case, add more print statements in the kernel to trace
> > > > code paths and see what's going on.
> > > > 
> > > > > Happy bug hunting!
> > > > 
> > > > It's fun. For some definition of fun :-)
> > 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.libcamera.org/pipermail/libcamera-devel/attachments/20250210/bd48129e/attachment.htm>