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

[Laurent Pinchart]

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