linux-kernel - Re: [PATCH] drm/msm/dpu: add missing flush and fetch bits for DMA4/DMA5 planes

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]

Date:   Wed, 5 Jul 2023 10:53:12 +0200
From:   Neil Armstrong <neil.armstrong@...aro.org>
To:     Jonathan Marek <jonathan@...ek.ca>, freedreno@...ts.freedesktop.org
Cc:     Rob Clark <robdclark@...il.com>,
        Abhinav Kumar <quic_abhinavk@...cinc.com>,
        Dmitry Baryshkov <dmitry.baryshkov@...aro.org>,
        Sean Paul <sean@...rly.run>, David Airlie <airlied@...il.com>,
        Daniel Vetter <daniel@...ll.ch>,
        Kalyan Thota <quic_kalyant@...cinc.com>,
        "open list:DRM DRIVER FOR MSM ADRENO GPU" 
        <linux-arm-msm@...r.kernel.org>,
        "open list:DRM DRIVER FOR MSM ADRENO GPU" 
        <dri-devel@...ts.freedesktop.org>,
        open list <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] drm/msm/dpu: add missing flush and fetch bits for
 DMA4/DMA5 planes

On 04/07/2023 18:01, Jonathan Marek wrote:
> Note that with this, DMA4/DMA5 are still non-functional, but at least
> display *something* in modetest instead of nothing or underflow.
> 
> Fixes: efcd0107727c ("drm/msm/dpu: add support for SM8550")
> Signed-off-by: Jonathan Marek <jonathan@...ek.ca>
> ---
>   drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c | 8 +++++++-
>   1 file changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
> index bbdc95ce374a..52222af5975f 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
> @@ -51,7 +51,7 @@
>   
>   static const u32 fetch_tbl[SSPP_MAX] = {CTL_INVALID_BIT, 16, 17, 18, 19,
>   	CTL_INVALID_BIT, CTL_INVALID_BIT, CTL_INVALID_BIT, CTL_INVALID_BIT, 0,
> -	1, 2, 3, CTL_INVALID_BIT, CTL_INVALID_BIT};
> +	1, 2, 3, 4, 5};
>   
>   static const struct dpu_ctl_cfg *_ctl_offset(enum dpu_ctl ctl,
>   		const struct dpu_mdss_cfg *m,
> @@ -206,6 +206,12 @@ static void dpu_hw_ctl_update_pending_flush_sspp(struct dpu_hw_ctl *ctx,
>   	case SSPP_DMA3:
>   		ctx->pending_flush_mask |= BIT(25);
>   		break;
> +	case SSPP_DMA4:
> +		ctx->pending_flush_mask |= BIT(13);
> +		break;
> +	case SSPP_DMA5:
> +		ctx->pending_flush_mask |= BIT(14);
> +		break;
>   	case SSPP_CURSOR0:
>   		ctx->pending_flush_mask |= BIT(22);
>   		break;

It permits displaying something, but the output is still corrupted on both DMA4 & DMA5,
tested with multiple plane sizes and formats.

modetest -P 81@93:1080x2400
and
modetest -P 87@93:1080x2400

Photo of actual display:
https://people.linaro.org/~neil.armstrong/sm8550-dma5.jpg

Works fine with DMA2 & DMA3 planes with same parameters.

Tested with https://patchwork.freedesktop.org/patch/538277/?series=118074&rev=1, and it doesn't change anything.

I think this is still accurate:
Tested-by: Neil Armstrong <neil.armstrong@...aro.org> # on SM8550-QRD

Thanks,
Neil