All of lore.kernel.org
 help / color / mirror / Atom feed
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 v2] vsp1: fix video output on R8A77970
Date: Mon, 15 Jan 2018 14:51:28 +0200	[thread overview]
Message-ID: <2210461.kXqmUypRF2@avalon> (raw)
In-Reply-To: <20171226211424.870595086@cogentembedded.com>

Hi Sergei,

Thank you for the patch.

On Tuesday, 26 December 2017 23:14:12 EET Sergei Shtylyov wrote:
> Laurent has added support for the VSP2-D found on R-Car V3M (R8A77970) but

I'm not sure there's a need to state my name in the commit message.

> the video  output that VSP2-D sends to DU has a greenish garbage-like line

Why does the text in your patches (commit message, comments, ...) sometime 
have double spaces between words ?

> repeated every 8 or so screen rows.

Is it every "8 or so" rows, or exactly every 8 rows ?

> It turns out that V3M has a teeny LIF register (at least it's documented!)
> that you need to set to some kind of a  magic value for the LIF to work
> correctly...
> 
> Based on the original (and large) patch by Daisuke Matsushita
> <daisuke.matsushita.ns@hitachi.com>.

What else is in the big patch ? Is it available somewhere ?

> 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 'master' branch.
> 
> 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  |   12 ++++++++++++
>  drivers/media/platform/vsp1/vsp1_regs.h |    5 +++++
>  2 files changed, 17 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,18 @@ 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);
> +
> +	/*
> +	 * R-Car V3M has the buffer attribute register you absolutely need
> +	 * to write kinda magic value to  for the LIF to work correctly...
> +	 */

I'm not sure about the "kinda" magic value. 1536 is very likely a buffer size. 
How about the following text ?

	/*
	 * On V3M the LBA 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 datasheet is not documented but
	 * is likely a buffer size or threshold.
	 */

The commit message should also be updated to feel a bit less magic.

> +	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));
> +	}
>  }

The datasheet documents the register as being present on both V3M and M3-W 
(and the test I've just run on H3 shows that the register is present there as 
well). Should we program it on M3-W or leave it to the default value that 
should be what is recommended by the datasheet for that SoC ?

>  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

  reply	other threads:[~2018-01-15 12:51 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-12-26 21:14 [PATCH v2] vsp1: fix video output on R8A77970 Sergei Shtylyov
2018-01-15 12:51 ` Laurent Pinchart [this message]
2018-01-15 16:06   ` Sergei Shtylyov
2018-01-15 20:41     ` 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=2210461.kXqmUypRF2@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.