From: "liviu.dudau@arm.com" <liviu.dudau@arm.com>
To: Wen He <wen.he_1@nxp.com>
Cc: "malidp@foss.arm.com" <malidp@foss.arm.com>,
"dri-devel@lists.freedesktop.org"
<dri-devel@lists.freedesktop.org>
Subject: Re: [PATCH 2/2] drm/arm/malidp: Setting QoS priority for 4k to avoid flicker issue
Date: Thu, 28 Mar 2019 16:39:18 +0000 [thread overview]
Message-ID: <20190328163917.GO21747@e110455-lin.cambridge.arm.com> (raw)
In-Reply-To: <20190328035840.4883-1-wen.he_1@nxp.com>
Hi Wen,
On Thu, Mar 28, 2019 at 03:56:58AM +0000, Wen He wrote:
> When we running DDR benchmark test will able to observed flicker issue
> in 4k@60 resolution on monitor. In LS1028A SoC, need increasing DP500
> priority to avoid that issue.
>
> Signed-off-by: Wen He <wen.he_1@nxp.com>
> ---
> drivers/gpu/drm/arm/malidp_hw.c | 13 +++++++++++++
> drivers/gpu/drm/arm/malidp_regs.h | 8 ++++++++
> 2 files changed, 21 insertions(+)
>
> diff --git a/drivers/gpu/drm/arm/malidp_hw.c b/drivers/gpu/drm/arm/malidp_hw.c
> index 8df12e9a33bb..a5263488eb02 100644
> --- a/drivers/gpu/drm/arm/malidp_hw.c
> +++ b/drivers/gpu/drm/arm/malidp_hw.c
> @@ -378,6 +378,19 @@ static void malidp500_modeset(struct malidp_hw_device *hwdev, struct videomode *
> malidp_hw_setbits(hwdev, MALIDP_DISP_FUNC_ILACED, MALIDP_DE_DISPLAY_FUNC);
> else
> malidp_hw_clearbits(hwdev, MALIDP_DISP_FUNC_ILACED, MALIDP_DE_DISPLAY_FUNC);
> +
> +#ifdef CONFIG_ARCH_LAYERSCAPE
> + /* Setting QoS for 4k resolution to avoid flicker issue */
> + if (mode->hactive == 3840
> + && mode->vactive == 2160)
I'm not keen on this check, it only enables this for one 3840x2160.
What if the output is 2160x3840? Does it matter what pixel clock you
use? Can the same issue be seen if (for example) you use 120Hz refresh
rate but on a smaller output resolution?
I think it's worth thinking this in terms of bandwidth and not hardcode
for one resolution.
Also, I think setting the QoS bits should be a bit more generic, i.e if
the modeset requires a certain bandwidth you should write a value read
from a device tree, for example?
> + malidp_hw_setbits(hwdev, GREEN_ARQOS_CONFIG
> + | RED_ARQOS_CONFIG, MALIDP500_RQOS_QUALITY);
> + else
> + malidp_hw_clearbits(hwdev, GREEN_ARQOS_CONFIG
> + | RED_ARQOS_CONFIG, MALIDP500_RQOS_QUALITY);
> +
> + malidp_hw_setbits(hwdev, CONFIG_VALID, MALIDP500_CONFIG_VALID);
malidp500_modeset() will be called with MALIDP_CFG_VALID set anyway, so
you should not need this. I don't know what bit 1 in MALIDP500_CONFIG_VALID does
for LS1028A, I don't have that spec.
> +#endif
> }
>
> int malidp_format_get_bpp(u32 fmt)
> diff --git a/drivers/gpu/drm/arm/malidp_regs.h b/drivers/gpu/drm/arm/malidp_regs.h
> index a0dd6e1676a8..8dcf7e9f46ce 100644
> --- a/drivers/gpu/drm/arm/malidp_regs.h
> +++ b/drivers/gpu/drm/arm/malidp_regs.h
> @@ -213,6 +213,14 @@
> #define MALIDP500_DC_IRQ_BASE 0x00f00
> #define MALIDP500_CONFIG_VALID 0x00f00
> #define MALIDP500_CONFIG_ID 0x00fd4
> +#ifdef CONFIG_ARCH_LAYERSCAPE
> +#define MALIDP500_RQOS_QUALITY 0x00500
> +/* Increasing QoS level signal */
> +#define GREEN_ARQOS_CONFIG (0xd << 28)
> +/* Close to underflow QoS level signal */
> +#define RED_ARQOS_CONFIG (0xd << 12)
> +#define CONFIG_VALID 0x3
What are these values? Is it something NXP has added to the DP500? If so, I
think these should have some LAYERSCAPE (or LS) in their name. Also,
rather than hardcoding the values, would it not be better to read them
form device tree, to allow for fine tuning or variability between IP
deployments?
Best regards,
Liviu
> +#endif
>
> /* register offsets and bits specific to DP550/DP650 */
> #define MALIDP550_ADDR_SPACE_SIZE 0x10000
> --
> 2.17.1
>
--
====================
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---------------
¯\_(ツ)_/¯
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2019-03-28 16:39 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-28 3:56 [PATCH 2/2] drm/arm/malidp: Setting QoS priority for 4k to avoid flicker issue Wen He
2019-03-28 16:39 ` liviu.dudau [this message]
2019-03-29 8:20 ` Wen He
2019-03-29 16:10 ` liviu.dudau
2019-07-17 6:26 ` Wen He
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=20190328163917.GO21747@e110455-lin.cambridge.arm.com \
--to=liviu.dudau@arm.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=malidp@foss.arm.com \
--cc=wen.he_1@nxp.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;
as well as URLs for NNTP newsgroup(s).