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

Sun Feb 9 20:29:48 CET 2025

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.

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 :-)
>
> --
> Regards,
>
> Laurent Pinchart
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.libcamera.org/pipermail/libcamera-devel/attachments/20250209/8aed6ffb/attachment.htm>