linux-kernel - Re: [PATCH] drm/msm/dp: fix the max supported bpp logic

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAA8EJpoYqHnG_=jt6Lo6v7a7h3CdF66bKqRf63RCmvqHWb4kFQ@mail.gmail.com>
Date: Sat, 27 Jul 2024 15:51:54 +0300
From: Dmitry Baryshkov <dmitry.baryshkov@...aro.org>
To: Abhinav Kumar <quic_abhinavk@...cinc.com>
Cc: freedreno@...ts.freedesktop.org, Rob Clark <robdclark@...il.com>, 
	Sean Paul <sean@...rly.run>, Marijn Suijten <marijn.suijten@...ainline.org>, 
	David Airlie <airlied@...il.com>, Daniel Vetter <daniel@...ll.ch>, Guenter Roeck <groeck@...omium.org>, 
	Tanmay Shah <tanmay@...eaurora.org>, Vara Reddy <quic_varar@...cinc.com>, 
	Stephen Boyd <swboyd@...omium.org>, dri-devel@...ts.freedesktop.org, 
	quic_jesszhan@...cinc.com, neil.armstrong@...aro.org, abel.vesa@...aro.org, 
	quic_khsieh@...cinc.com, Rob Clark <robdclark@...omium.org>, 
	Chandan Uddaraju <chandanu@...eaurora.org>, linux-arm-msm@...r.kernel.org, 
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] drm/msm/dp: fix the max supported bpp logic

On Fri, 26 Jul 2024 at 01:04, Abhinav Kumar <quic_abhinavk@...cinc.com> wrote:
>
> Currently the DP driver hard-codes the max supported bpp to 30.
> This is incorrect because the number of lanes and max data rate
> supported by the lanes need to be taken into account.
>
> Replace the hardcoded limit with the appropriate math which accounts
> for the accurate number of lanes and max data rate.
>
> Fixes: c943b4948b58 ("drm/msm/dp: add displayPort driver support")
> Signed-off-by: Abhinav Kumar <quic_abhinavk@...cinc.com>
> ---
>  drivers/gpu/drm/msm/dp/dp_panel.c | 7 +++++--
>  1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/dp/dp_panel.c b/drivers/gpu/drm/msm/dp/dp_panel.c
> index a916b5f3b317..56ce5e4008f8 100644
> --- a/drivers/gpu/drm/msm/dp/dp_panel.c
> +++ b/drivers/gpu/drm/msm/dp/dp_panel.c
> @@ -397,6 +397,7 @@ int dp_panel_init_panel_info(struct dp_panel *dp_panel)
>  {
>         struct drm_display_mode *drm_mode;
>         struct dp_panel_private *panel;
> +       u32 max_supported_bpp;
>
>         drm_mode = &dp_panel->dp_mode.drm_mode;
>
> @@ -423,8 +424,10 @@ int dp_panel_init_panel_info(struct dp_panel *dp_panel)
>                                 drm_mode->clock);
>         drm_dbg_dp(panel->drm_dev, "bpp = %d\n", dp_panel->dp_mode.bpp);
>
> -       dp_panel->dp_mode.bpp = max_t(u32, 18,
> -                               min_t(u32, dp_panel->dp_mode.bpp, 30));
> +       max_supported_bpp = dp_panel_get_mode_bpp(dp_panel, dp_panel->dp_mode.bpp,
> +                                                 dp_panel->dp_mode.drm_mode.clock);
> +       dp_panel->dp_mode.bpp = max_t(u32, 18, max_supported_bpp);

I think that in mode_valid() the driver should filter out modes that
result in BPP being less than 18. Then the max_t can be dropped
completely.

Nevertheless this indeed fixes an issue with the screen corruption,
this is great!

Tested-by: Dmitry Baryshkov <dmitry.baryshkov@...aro.org> # SM8350-HDK

> +
>         drm_dbg_dp(panel->drm_dev, "updated bpp = %d\n",
>                                 dp_panel->dp_mode.bpp);
>
> --
> 2.44.0
>


-- 
With best wishes
Dmitry