From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Cc: Mauro Carvalho Chehab <mchehab@kernel.org>,
linux-media@vger.kernel.org, linux-renesas-soc@vger.kernel.org
Subject: Re: [PATCH v3] vsp1: fix video output on R8A77970
Date: Thu, 22 Feb 2018 18:29:31 +0200 [thread overview]
Message-ID: <1728090.GRuQRXDi5g@avalon> (raw)
In-Reply-To: <11341738.DVmQoThvsb@avalon>
Hi Sergei,
On Thursday, 22 February 2018 18:26:20 EET Laurent Pinchart wrote:
> On Thursday, 18 January 2018 16:05:51 EET Sergei Shtylyov wrote:
> > Commit d455b45f8393 ("v4l: vsp1: Add support for new VSP2-BS, VSP2-DL,
> > and VSP2-D instances") added support for the VSP2-D found in the R-Car
> > V3M (R8A77970) but the video output that VSP2-D sends to DU has a greenish
> > garbage-like line repeated every 8 screen rows. It turns out that R-Car
> > V3M has the LIF0 buffer attribute register that you need to set to a non-
> > default value in order to get rid of the output artifacts...
> >
> > Based on the original (and large) patch by Daisuke Matsushita
> > <daisuke.matsushita.ns@hitachi.com>.
> >
> > Fixes: d455b45f8393 ("v4l: vsp1: Add support for new VSP2-BS, VSP2-DL and
> > VSP2-D instances") Signed-off-by: Sergei Shtylyov
> > <sergei.shtylyov@cogentembedded.com>
> >
> > ---
> > This patch is against the 'media_tree.git' repo's 'fixes' branch.
> >
> > Changes in version 3:
> > - reworded the comment in lif_configure();
> > - reworded the patch description.
> >
> > Changes in version 2:
> > - added a comment before the V3M SoC check;
> > - fixed indetation in that check;
> > - reformatted the patch description.
> >
> > drivers/media/platform/vsp1/vsp1_lif.c | 15 +++++++++++++++
> > drivers/media/platform/vsp1/vsp1_regs.h | 5 +++++
> > 2 files changed, 20 insertions(+)
> >
> > Index: media_tree/drivers/media/platform/vsp1/vsp1_lif.c
> > ===================================================================
> > --- media_tree.orig/drivers/media/platform/vsp1/vsp1_lif.c
> > +++ media_tree/drivers/media/platform/vsp1/vsp1_lif.c
> > @@ -155,6 +155,21 @@ static void lif_configure(struct vsp1_en
> >
> > (obth << VI6_LIF_CTRL_OBTH_SHIFT) |
> > (format->code == 0 ? VI6_LIF_CTRL_CFMT : 0) |
> > VI6_LIF_CTRL_REQSEL | VI6_LIF_CTRL_LIF_EN);
> >
> > +
> > + /*
> > + * On R-Car V3M the LIF0 buffer attribute register has to be set
> > + * to a non-default value to guarantee proper operation (otherwise
> > + * artifacts may appear on the output). The value required by
> > + * the manual is not explained but is likely a buffer size or
> > + * threshold...
>
> One period is enough :-)
>
> > + */
> > + if ((entity->vsp1->version &
> > + (VI6_IP_VERSION_MODEL_MASK | VI6_IP_VERSION_SOC_MASK)) ==
> > + (VI6_IP_VERSION_MODEL_VSPD_V3 | VI6_IP_VERSION_SOC_V3M)) {
> > + vsp1_lif_write(lif, dl, VI6_LIF_LBA,
> > + VI6_LIF_LBA_LBA0 |
> > + (1536 << VI6_LIF_LBA_LBA1_SHIFT));
> > + }
>
> There's no need for braces or inner parentheses.
There's of course a need for the inner parentheses, please ignore this
comment.
> To make this easier to read I propose defining a new macro
> VI6_IP_VERSION_MASK that combines both the model and SoC. Otherwise this
> looks good to me,
>
> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
>
> I'll post a v4 with that change in reply to this e-mail, please let me know
> if you're fine with it.
>
> > }
> >
> > static const struct vsp1_entity_operations lif_entity_ops = {
> >
> > Index: media_tree/drivers/media/platform/vsp1/vsp1_regs.h
> > ===================================================================
> > --- media_tree.orig/drivers/media/platform/vsp1/vsp1_regs.h
> > +++ media_tree/drivers/media/platform/vsp1/vsp1_regs.h
> > @@ -693,6 +693,11 @@
> > #define VI6_LIF_CSBTH_LBTH_MASK (0x7ff << 0)
> > #define VI6_LIF_CSBTH_LBTH_SHIFT 0
> >
> > +#define VI6_LIF_LBA 0x3b0c
> > +#define VI6_LIF_LBA_LBA0 (1 << 31)
> > +#define VI6_LIF_LBA_LBA1_MASK (0xfff << 16)
> > +#define VI6_LIF_LBA_LBA1_SHIFT 16
> > +
> > /* ----------------------------------------------------------------------
> > * Security Control Registers
> > */
--
Regards,
Laurent Pinchart
next prev parent reply other threads:[~2018-02-22 16:29 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-18 14:05 [PATCH v3] vsp1: fix video output on R8A77970 Sergei Shtylyov
2018-02-22 16:26 ` Laurent Pinchart
2018-02-22 16:29 ` Laurent Pinchart [this message]
2018-02-22 16:32 ` [PATCH v4] v4l: vsp1: Fix " Laurent Pinchart
2018-02-22 18:34 ` Sergei Shtylyov
2018-02-22 18:46 ` Laurent Pinchart
2018-02-22 18:57 ` Sergei Shtylyov
2018-02-22 18:42 ` [PATCH v3] vsp1: fix " Sergei Shtylyov
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=1728090.GRuQRXDi5g@avalon \
--to=laurent.pinchart@ideasonboard.com \
--cc=linux-media@vger.kernel.org \
--cc=linux-renesas-soc@vger.kernel.org \
--cc=mchehab@kernel.org \
--cc=sergei.shtylyov@cogentembedded.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.