On Mon, Oct 07, 2024 at 09:35:49PM +0200, Jacopo Mondi wrote:
> Hi Sebastian,
>
> On Mon, Oct 07, 2024 at 04:05:01PM GMT, Sebastian Fricke wrote:
> > On 07.10.2024 16:47, Laurent Pinchart wrote:
> > > On Mon, Oct 07, 2024 at 02:57:30PM +0200, Sebastian Fricke wrote:
> > > > Hey Jacopo,
> > > >
> > > > On 07.10.2024 14:42, Jacopo Mondi wrote:
> > > > > There apparently is no reason to require 3 queued buffers to call
> > > > > streamon() for the RkISP1 as the driver operates with a scratch buffer
> > > > > where frames can be directed to if there's no available buffer provided
> > > > > by userspace.
> > > > >
> > > > > Reduce the number of required buffers to 1 to allow applications to
> > > > > operate with a single queued buffer.
> > > > >
> > > > > Tested with libcamera, by operating with a single capture a request. The
> > > > > same request (and associated capture buffer) gets recycled once
> > > > > completed. This of course causes a frame rate drop but doesn't hinder
> > > > > operations.
> > > > >
> > > > > Signed-off-by: Jacopo Mondi <jacopo.mondi@xxxxxxxxxxxxxxxx>
> > > > > ---
> > > > >
> > > > > Adam,
> > > > > a few months ago you were exercizing your pinhole app with a single capture
> > > > > request for StillCapture operations and you got the video device to hang because
> > > > > no enough buffers where provided.
> > > > >
> > > > > This small change should be enough to unblock you. Could you maybe give it a
> > > > > spin if you're still working on this ?
> > > > >
> > > > > Thanks
> > > > > j
> > > > > ---
> > > > >
> > > > > drivers/media/platform/rockchip/rkisp1/rkisp1-capture.c | 4 +---
> > > > > 1 file changed, 1 insertion(+), 3 deletions(-)
> > > > >
> > > > > diff --git a/drivers/media/platform/rockchip/rkisp1/rkisp1-capture.c b/drivers/media/platform/rockchip/rkisp1/rkisp1-capture.c
> > > > > index 2bddb4fa8a5c..34adaecdee54 100644
> > > > > --- a/drivers/media/platform/rockchip/rkisp1/rkisp1-capture.c
> > > > > +++ b/drivers/media/platform/rockchip/rkisp1/rkisp1-capture.c
> > > > > @@ -35,8 +35,6 @@
> > > > > #define RKISP1_SP_DEV_NAME RKISP1_DRIVER_NAME "_selfpath"
> > > > > #define RKISP1_MP_DEV_NAME RKISP1_DRIVER_NAME "_mainpath"
> > > > >
> > > > > -#define RKISP1_MIN_BUFFERS_NEEDED 3
> > > > > -
> > > > > enum rkisp1_plane {
> > > > > RKISP1_PLANE_Y = 0,
> > > > > RKISP1_PLANE_CB = 1,
> > > > > @@ -1563,7 +1561,7 @@ static int rkisp1_register_capture(struct rkisp1_capture *cap)
> > > > > q->ops = &rkisp1_vb2_ops;
> > > > > q->mem_ops = &vb2_dma_contig_memops;
> > > > > q->buf_struct_size = sizeof(struct rkisp1_buffer);
> > > > > - q->min_queued_buffers = RKISP1_MIN_BUFFERS_NEEDED;
> > > >
> > > > It looks like RKISP1_MIN_BUFFERS_NEEDED is used only here, so can you
> > > > remove the define as well?
> > >
> > > Isn't that exactly what this patch is doing ?
> >
> > Oh *facepalm* ... I missed that please disregard ...
> >
> > but my question below remains whether to not just change the value.
>
> Do you mean
>
> -#define RKISP1_MIN_BUFFERS_NEEDED 3
> +#define RKISP1_MIN_BUFFERS_NEEDED 1
>
> ?
>
> I would rather avoid defining a value used in a single place. If it
> was some magic number a macro name would maybe help giving come
> context, but considering this is assigned to min_queued_buffers it's
> imho clear enough ?
I find it clear enough, I prefer dropping the macro as you do in this
patch.
> > > > rg 'RKISP1_MIN_BUFFERS_NEEDED'
> > > > drivers/media/platform/rockchip/rkisp1/rkisp1-capture.c
> > > > 38:#define RKISP1_MIN_BUFFERS_NEEDED 3
> > > > 1566: q->min_queued_buffers = RKISP1_MIN_BUFFERS_NEEDED;
> > > >
> > > > Or maybe just change the value, but I am not sure whether this can be
> > > > considered a magic value.
> > > >
> > > > > + q->min_queued_buffers = 1;
> > > > > q->timestamp_flags = V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC;
> > > > > q->lock = &node->vlock;
> > > > > q->dev = cap->rkisp1->dev;
--
Regards,
Laurent Pinchart
