public inbox for linux-media@vger.kernel.org
 help / color / mirror / Atom feed
From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Kieran Bingham <kieran.bingham@ideasonboard.com>
Cc: linux-media@vger.kernel.org, linux-renesas-soc@vger.kernel.org,
	Sakari Ailus <sakari.ailus@iki.fi>,
	Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>,
	Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Subject: Re: [PATCH v2 12/19] media: renesas: vsp1: Keep the DRM pipeline entities sorted
Date: Wed, 19 Jun 2024 15:31:38 +0300	[thread overview]
Message-ID: <20240619123138.GA3125@pendragon.ideasonboard.com> (raw)
In-Reply-To: <171879964925.2248009.4044816953897425991@ping.linuxembedded.co.uk>

On Wed, Jun 19, 2024 at 01:20:49PM +0100, Kieran Bingham wrote:
> Quoting Laurent Pinchart (2024-06-19 01:17:15)
> > Some of the code that handles pipeline configuration assumes that
> > entities in a pipeline's entities list are sorted from sink to source.
> > To prepare for using that code with the DRM pipeline, insert the BRx
> > just before the WPF, and the RPFs at the head of the list.
> > 
> > Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> > ---
> >  drivers/media/platform/renesas/vsp1/vsp1_drm.c | 10 +++++++---
> >  1 file changed, 7 insertions(+), 3 deletions(-)
> > 
> > diff --git a/drivers/media/platform/renesas/vsp1/vsp1_drm.c b/drivers/media/platform/renesas/vsp1/vsp1_drm.c
> > index 1aa59a74672f..e44359b661b6 100644
> > --- a/drivers/media/platform/renesas/vsp1/vsp1_drm.c
> > +++ b/drivers/media/platform/renesas/vsp1/vsp1_drm.c
> > @@ -317,7 +317,10 @@ static int vsp1_du_pipeline_setup_brx(struct vsp1_device *vsp1,
> >                         list_add_tail(&released_brx->list_pipe,
> >                                       &pipe->entities);
> >  
> > -               /* Add the BRx to the pipeline. */
> > +               /*
> > +                * Add the BRx to the pipeline, inserting it just before the
> > +                * WPF.
> 
> So - the pipe->output is from what I recall/can see the output wpf.
>  (struct vsp1_rwpf *output)
> 
> > +                */
> >                 dev_dbg(vsp1->dev, "%s: pipe %u: acquired %s\n",
> >                         __func__, pipe->lif->index, BRX_NAME(brx));
> >  
> > @@ -326,7 +329,8 @@ static int vsp1_du_pipeline_setup_brx(struct vsp1_device *vsp1,
> >                 pipe->brx->sink = &pipe->output->entity;
> >                 pipe->brx->sink_pad = 0;
> >  
> > -               list_add_tail(&pipe->brx->list_pipe, &pipe->entities);
> > +               list_add_tail(&pipe->brx->list_pipe,
> > +                             &pipe->output->entity.list_pipe);
> 
> But this reads to me as if we're adding the brx after ('the tail') of
> the output WPF....
> 
> Now ... of course if we open up list_add_tail()
> 
>  * Insert a new entry before the specified head.
> 
> And that checks out - because of course the list_add adds it as the
> 'next' item in the list... and we're using list_add_tail as a convenient
> way to provide list_add_before() ...
> 
> So I believe this is correct, but the nuance of it reads back to front to me.
> 
> Because of that it possibly deserves a better comment to be explicit on
> what it's doing, or makes me wonder if list.h should have something that
> explicitly impliments
> 
> #define list_add_before list_add_tail

https://lore.kernel.org/all/alpine.LSU.2.11.1406061242370.16010@eggly.anvils/

I'll let you argue :-)

> but otherwise - it does check out.
> 
> 
> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
> 
> >         }
> >  
> >         /*
> > @@ -420,7 +424,7 @@ static int vsp1_du_pipeline_setup_inputs(struct vsp1_device *vsp1,
> >  
> >                 if (!rpf->entity.pipe) {
> >                         rpf->entity.pipe = pipe;
> > -                       list_add_tail(&rpf->entity.list_pipe, &pipe->entities);
> > +                       list_add(&rpf->entity.list_pipe, &pipe->entities);
> >                 }
> >  
> >                 brx->inputs[i].rpf = rpf;

-- 
Regards,

Laurent Pinchart

  reply	other threads:[~2024-06-19 12:32 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-19  0:17 [PATCH v2 00/19] media: renesas: vsp1: Conversion to subdev active state Laurent Pinchart
2024-06-19  0:17 ` [PATCH v2 01/19] media: renesas: vsp1: Drop vsp1_entity_get_pad_format() wrapper Laurent Pinchart
2024-06-19  0:17 ` [PATCH v2 02/19] media: renesas: vsp1: Drop vsp1_entity_get_pad_selection() wrapper Laurent Pinchart
2024-06-19  0:17 ` [PATCH v2 03/19] media: renesas: vsp1: Drop vsp1_rwpf_get_crop() wrapper Laurent Pinchart
2024-06-19  0:17 ` [PATCH v2 04/19] media: renesas: vsp1: Drop brx_get_compose() wrapper Laurent Pinchart
2024-06-19  0:17 ` [PATCH v2 05/19] media: renesas: vsp1: Drop custom .get_fmt() handler for histogram Laurent Pinchart
2024-06-19  0:17 ` [PATCH v2 06/19] media: renesas: vsp1: Move partition calculation to vsp1_pipe.c Laurent Pinchart
2024-06-19  0:17 ` [PATCH v2 07/19] media: renesas: vsp1: Simplify partition calculation Laurent Pinchart
2024-06-19  0:17 ` [PATCH v2 08/19] media: renesas: vsp1: Store RPF partition configuration per RPF instance Laurent Pinchart
2024-06-19  0:17 ` [PATCH v2 09/19] media: renesas: vsp1: Pass partition pointer to .configure_partition() Laurent Pinchart
2024-06-19  0:17 ` [PATCH v2 10/19] media: renesas: vsp1: Replace vsp1_partition_window with v4l2_rect Laurent Pinchart
2024-06-19  0:17 ` [PATCH v2 11/19] media: renesas: vsp1: Add and use function to dump a pipeline to the log Laurent Pinchart
2024-06-19 18:59   ` [PATCH v2.1 " Laurent Pinchart
2024-06-19  0:17 ` [PATCH v2 12/19] media: renesas: vsp1: Keep the DRM pipeline entities sorted Laurent Pinchart
2024-06-19 12:20   ` Kieran Bingham
2024-06-19 12:31     ` Laurent Pinchart [this message]
2024-06-19  0:17 ` [PATCH v2 13/19] media: renesas: vsp1: Compute partitions for DRM pipelines Laurent Pinchart
2024-06-19  0:17 ` [PATCH v2 14/19] media: renesas: vsp1: Get configuration from partition instead of state Laurent Pinchart
2024-06-19  0:17 ` [PATCH v2 15/19] media: renesas: vsp1: Name parameters to entity operations Laurent Pinchart
2024-06-19  0:17 ` [PATCH v2 16/19] media: renesas: vsp1: Pass subdev state " Laurent Pinchart
2024-06-19  0:17 ` [PATCH v2 17/19] media: renesas: vsp1: Initialize control handler after subdev Laurent Pinchart
2024-06-19  0:17 ` [PATCH v2 18/19] media: renesas: vsp1: Switch to V4L2 subdev active state Laurent Pinchart
2024-06-19  0:17 ` [PATCH v2 19/19] media: renesas: vsp1: Rename all v4l2_subdev_state variables to 'state' Laurent Pinchart
2025-06-26  8:30 ` [PATCH v2 00/19] media: renesas: vsp1: Conversion to subdev active state Tomi Valkeinen
2025-06-26  9:07   ` Laurent Pinchart

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20240619123138.GA3125@pendragon.ideasonboard.com \
    --to=laurent.pinchart@ideasonboard.com \
    --cc=jacopo.mondi@ideasonboard.com \
    --cc=kieran.bingham@ideasonboard.com \
    --cc=linux-media@vger.kernel.org \
    --cc=linux-renesas-soc@vger.kernel.org \
    --cc=sakari.ailus@iki.fi \
    --cc=tomi.valkeinen@ideasonboard.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox