linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Daniel Vetter <daniel@ffwll.ch>
To: Linus Walleij <linus.walleij@linaro.org>
Cc: Stephan Gerhold <stephan@gerhold.net>,
	newbytee@protonmail.com,
	Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
	Maxime Ripard <mripard@kernel.org>,
	dri-devel@lists.freedesktop.org, Sean Paul <sean@poorly.run>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 1/4 v2] drm/mcde: Improve pixel fetcher FIFO depth setting
Date: Mon, 10 Aug 2020 14:54:32 +0200	[thread overview]
Message-ID: <20200810125432.GP2352366@phenom.ffwll.local> (raw)
In-Reply-To: <20200808223122.1492124-1-linus.walleij@linaro.org>

On Sun, Aug 09, 2020 at 12:31:19AM +0200, Linus Walleij wrote:
> The pixel fetcher FIFO depth was just hardcoded to 48
> which works fine as long as the framebuffer is 32BPP
> and the DSI output is RGB888.
> 
> We will need more elaborate handling for some buffer
> formats and displays, so start to improve this function
> by setting reasonable defaults for 32, 24 and 16 BPP
> framebuffers.
> 
> Cc: newbytee@protonmail.com
> Cc: Stephan Gerhold <stephan@gerhold.net>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> ---
>  drivers/gpu/drm/mcde/mcde_display.c | 34 +++++++++++++++++++++++++----
>  1 file changed, 30 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/mcde/mcde_display.c b/drivers/gpu/drm/mcde/mcde_display.c
> index cac660ac8803..cbc7c0c4955a 100644
> --- a/drivers/gpu/drm/mcde/mcde_display.c
> +++ b/drivers/gpu/drm/mcde/mcde_display.c
> @@ -333,7 +333,7 @@ static void mcde_configure_overlay(struct mcde *mcde, enum mcde_overlay ovl,
>  				   enum mcde_extsrc src,
>  				   enum mcde_channel ch,
>  				   const struct drm_display_mode *mode,
> -				   u32 format)
> +				   u32 format, int cpp)

Note that format->cpp is a bit outdated, since it doesn't work for planar
stuff. But I guess not a problem for you (for now at least). Blocky
formats like yuv don't set format->cpp, or at least not in the way you'd
expect.

Anyway now idea on the hw, but patch looks reasonable.

Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>

>  {
>  	u32 val;
>  	u32 conf1;
> @@ -342,6 +342,7 @@ static void mcde_configure_overlay(struct mcde *mcde, enum mcde_overlay ovl,
>  	u32 ljinc;
>  	u32 cr;
>  	u32 comp;
> +	u32 pixel_fetcher_watermark;
>  
>  	switch (ovl) {
>  	case MCDE_OVERLAY_0:
> @@ -426,8 +427,33 @@ static void mcde_configure_overlay(struct mcde *mcde, enum mcde_overlay ovl,
>  			format);
>  		break;
>  	}
> -	/* The default watermark level for overlay 0 is 48 */
> -	val |= 48 << MCDE_OVLXCONF2_PIXELFETCHERWATERMARKLEVEL_SHIFT;
> +
> +	/*
> +	 * Pixel fetch watermark level is max 0x1FFF pixels.
> +	 * Two basic rules should be followed:
> +	 * 1. The value should be at least 256 bits.
> +	 * 2. The sum of all active overlays pixelfetch watermark level
> +	 *    multiplied with bits per pixel, should be lower than the
> +	 *    size of input_fifo_size in bits.
> +	 * 3. The value should be a multiple of a line (256 bits).
> +	 */
> +	switch (cpp) {
> +	case 2:
> +		pixel_fetcher_watermark = 128;
> +		break;
> +	case 3:
> +		pixel_fetcher_watermark = 96;
> +		break;
> +	case 4:
> +		pixel_fetcher_watermark = 48;
> +		break;
> +	default:
> +		pixel_fetcher_watermark = 48;
> +		break;
> +	}
> +	dev_dbg(mcde->dev, "pixel fetcher watermark level %d pixels\n",
> +		pixel_fetcher_watermark);
> +	val |= pixel_fetcher_watermark << MCDE_OVLXCONF2_PIXELFETCHERWATERMARKLEVEL_SHIFT;
>  	writel(val, mcde->regs + conf2);
>  
>  	/* Number of bytes to fetch per line */
> @@ -932,7 +958,7 @@ static void mcde_display_enable(struct drm_simple_display_pipe *pipe,
>  	 * channel 0
>  	 */
>  	mcde_configure_overlay(mcde, MCDE_OVERLAY_0, MCDE_EXTSRC_0,
> -			       MCDE_CHANNEL_0, mode, format);
> +			       MCDE_CHANNEL_0, mode, format, cpp);
>  
>  	/*
>  	 * Configure pixel-per-line and line-per-frame for channel 0 and then
> -- 
> 2.26.2
> 
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

      parent reply	other threads:[~2020-08-10 12:56 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-08 22:31 [PATCH 1/4 v2] drm/mcde: Improve pixel fetcher FIFO depth setting Linus Walleij
2020-08-08 22:31 ` [PATCH 2/4 v2] drm/mcde: Support using DSI in LP mode Linus Walleij
2020-08-08 22:31 ` [PATCH 3/4 v2] drm/mcde: Fix display pipeline restart Linus Walleij
2020-08-08 22:31 ` [PATCH 4/4 v2] drm/mcde: Enable the DSI link with display Linus Walleij
2020-08-10 13:03   ` Daniel Vetter
2020-08-10 12:54 ` Daniel Vetter [this message]

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=20200810125432.GP2352366@phenom.ffwll.local \
    --to=daniel@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=linus.walleij@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=maarten.lankhorst@linux.intel.com \
    --cc=mripard@kernel.org \
    --cc=newbytee@protonmail.com \
    --cc=sean@poorly.run \
    --cc=stephan@gerhold.net \
    /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;
as well as URLs for NNTP newsgroup(s).