From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Kieran Bingham <kieran.bingham@ideasonboard.com>
Cc: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>,
linux-media@vger.kernel.org, dri-devel@lists.freedesktop.org,
linux-renesas-soc@vger.kernel.org
Subject: Re: [PATCH v2 7/8] v4l: vsp1: Integrate DISCOM in display pipeline
Date: Sat, 28 Apr 2018 22:15:38 +0300 [thread overview]
Message-ID: <2726723.Sl6OlPdl7O@avalon> (raw)
In-Reply-To: <759b7675-d0d5-4a31-0949-2affd4019f77@ideasonboard.com>
Hi Kieran,
On Saturday, 28 April 2018 21:58:53 EEST Kieran Bingham wrote:
> On 22/04/18 23:34, Laurent Pinchart wrote:
> > The DISCOM is used to compute CRCs on display frames. Integrate it in
> > the display pipeline at the output of the blending unit to process
> > output frames.
> >
> > Computing CRCs on input frames is possible by positioning the DISCOM at
> > a different point in the pipeline. This use case isn't supported at the
> > moment and could be implemented by extending the API between the VSP1
> > and DU drivers if needed.
> >
> > Signed-off-by: Laurent Pinchart
> > <laurent.pinchart+renesas@ideasonboard.com>
>
> Only a couple of small questions - but nothing to block an RB tag.
>
> Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
>
> > ---
> >
> > drivers/media/platform/vsp1/vsp1_drm.c | 115 +++++++++++++++++++++++++++-
> > drivers/media/platform/vsp1/vsp1_drm.h | 12 ++++
> > 2 files changed, 124 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/media/platform/vsp1/vsp1_drm.c
> > b/drivers/media/platform/vsp1/vsp1_drm.c index 5fc31578f9b0..7864b43a90e1
> > 100644
> > --- a/drivers/media/platform/vsp1/vsp1_drm.c
> > +++ b/drivers/media/platform/vsp1/vsp1_drm.c
[snip]
> > @@ -748,6 +847,9 @@ void vsp1_du_atomic_flush(struct device *dev, unsigned
> > int pipe_index,>
> > struct vsp1_drm_pipeline *drm_pipe = &vsp1->drm->pipe[pipe_index];
> > struct vsp1_pipeline *pipe = &drm_pipe->pipe;
> >
> > + drm_pipe->crc.source = cfg->crc.source;
> > + drm_pipe->crc.index = cfg->crc.index;
>
> I think this could be shortened to
>
> drm_pipe->crc = cfg->crc;
>
> Or is that a GCC extension. Either way, it's just a matter of taste, and you
> might prefer to be more explicit.
That's what I had written in the first place, only to have gcc throwing an
error because the crc fields are anonymous structures.
> > +
> > vsp1_du_pipeline_setup_inputs(vsp1, pipe);
> > vsp1_du_pipeline_configure(pipe);
> > mutex_unlock(&vsp1->drm->lock);
[snip]
> > diff --git a/drivers/media/platform/vsp1/vsp1_drm.h
> > b/drivers/media/platform/vsp1/vsp1_drm.h index e5b88b28806c..1e7670955ef0
> > 100644
> > --- a/drivers/media/platform/vsp1/vsp1_drm.h
> > +++ b/drivers/media/platform/vsp1/vsp1_drm.h
> > @@ -13,6 +13,8 @@
> > #include <linux/videodev2.h>
> > #include <linux/wait.h>
> >
> > +#include <media/vsp1.h>
> > +
> > #include "vsp1_pipe.h"
> >
> > /**
> > @@ -22,6 +24,9 @@
> > * @height: output display height
> > * @force_brx_release: when set, release the BRx during the next
> > reconfiguration
> > * @wait_queue: wait queue to wait for BRx release completion
> > + * @uif: UIF entity if available for the pipeline
> > + * @crc.source: source for CRC calculation
> > + * @crc.index: index of the CRC source plane (when crc.source is set to
> > plane)
> > * @du_complete: frame completion callback for the DU driver (optional)
> > * @du_private: data to be passed to the du_complete callback
> > */
> > @@ -34,6 +39,13 @@ struct vsp1_drm_pipeline {
> > bool force_brx_release;
> > wait_queue_head_t wait_queue;
> >
> > + struct vsp1_entity *uif;
> > +
> > + struct {
> > + enum vsp1_du_crc_source source;
> > + unsigned int index;
> > + } crc;
>
> Does this have to be duplicated ? Or can it be included from the API
> header...
It's a good point. I thought it might not be worth it just for two fields, but
I see no compelling reason against it. I'll introduce a new structure.
> > +
> > /* Frame synchronisation */
> > void (*du_complete)(void *data, bool completed, u32 crc);
> > void *du_private;
--
Regards,
Laurent Pinchart
next prev parent reply other threads:[~2018-04-28 19:15 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-22 22:34 [PATCH v2 0/8] R-Car DU: Support CRC calculation Laurent Pinchart
2018-04-22 22:34 ` [PATCH v2 1/8] v4l: vsp1: Use SPDX license headers Laurent Pinchart
2018-04-27 21:25 ` Kieran Bingham
2018-04-27 21:47 ` Laurent Pinchart
2018-04-22 22:34 ` [PATCH v2 2/8] v4l: vsp1: Share the CLU, LIF and LUT set_fmt pad operation code Laurent Pinchart
2018-04-28 9:50 ` jacopo mondi
2018-04-28 16:07 ` Laurent Pinchart
2018-04-28 17:16 ` Kieran Bingham
2018-04-28 17:25 ` Laurent Pinchart
2018-04-28 17:30 ` Laurent Pinchart
2018-04-28 17:32 ` Kieran Bingham
2018-04-22 22:34 ` [PATCH v2 3/8] v4l: vsp1: Reset the crop and compose rectangles in the set_fmt helper Laurent Pinchart
2018-04-28 9:56 ` jacopo mondi
2018-04-28 17:22 ` Kieran Bingham
2018-04-22 22:34 ` [PATCH v2 4/8] v4l: vsp1: Document the vsp1_du_atomic_config structure Laurent Pinchart
2018-04-28 17:29 ` Kieran Bingham
2018-04-22 22:34 ` [PATCH v2 5/8] v4l: vsp1: Extend the DU API to support CRC computation Laurent Pinchart
2018-04-28 10:03 ` jacopo mondi
2018-04-28 16:19 ` Laurent Pinchart
2018-04-28 17:48 ` Kieran Bingham
2018-04-22 22:34 ` [PATCH v2 6/8] v4l: vsp1: Add support for the DISCOM entity Laurent Pinchart
2018-04-28 10:40 ` jacopo mondi
2018-04-28 16:50 ` Laurent Pinchart
2018-04-28 18:28 ` Kieran Bingham
2018-04-22 22:34 ` [PATCH v2 7/8] v4l: vsp1: Integrate DISCOM in display pipeline Laurent Pinchart
2018-04-28 11:00 ` jacopo mondi
2018-04-28 16:57 ` Laurent Pinchart
2018-04-28 18:58 ` Kieran Bingham
2018-04-28 19:15 ` Laurent Pinchart [this message]
2018-04-22 22:34 ` [PATCH v2 8/8] drm: rcar-du: Add support for CRC computation Laurent Pinchart
2018-04-28 19:16 ` Kieran Bingham
2018-04-28 20:15 ` 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=2726723.Sl6OlPdl7O@avalon \
--to=laurent.pinchart@ideasonboard.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=kieran.bingham@ideasonboard.com \
--cc=laurent.pinchart+renesas@ideasonboard.com \
--cc=linux-media@vger.kernel.org \
--cc=linux-renesas-soc@vger.kernel.org \
/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