linux-kernel - Re: [Freedreno] [PATCH] drm/msm/dpu: always program dsc active bits

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: <2e6dwt74oyy7rroxyus6ebfbylbbtinsi7bccpqazjm64owiv4@gfs52kkq47c3>
Date:   Sat, 15 Apr 2023 01:11:42 +0200
From:   Marijn Suijten <marijn.suijten@...ainline.org>
To:     Abhinav Kumar <quic_abhinavk@...cinc.com>
Cc:     freedreno@...ts.freedesktop.org, quic_sbillaka@...cinc.com,
        dianders@...omium.org, airlied@...il.com, andersson@...nel.org,
        robdclark@...il.com, dri-devel@...ts.freedesktop.org,
        swboyd@...omium.org, vkoul@...nel.org, agross@...nel.org,
        daniel@...ll.ch, linux-arm-msm@...r.kernel.org,
        dmitry.baryshkov@...aro.org,
        Kuogee Hsieh <quic_khsieh@...cinc.com>, sean@...rly.run,
        linux-kernel@...r.kernel.org
Subject: Re: [Freedreno] [PATCH] drm/msm/dpu: always program dsc active bits

On 2023-04-14 10:57:45, Abhinav Kumar wrote:
> On 4/14/2023 10:34 AM, Marijn Suijten wrote:
> > On 2023-04-14 08:48:43, Abhinav Kumar wrote:
> >> On 4/14/2023 12:35 AM, Marijn Suijten wrote:
> >>> On 2023-04-12 10:33:15, Abhinav Kumar wrote:
> >>> [..]
> >>>>> What happens if a device boots without DSC panel connected?  Will
> >>>>> CTL_DSC_FLUSH be zero and not (unnecessarily, I assume) flush any of the
> >>>>> DSC blocks?  Or could this flush uninitialized state to the block?
> >>>>
> >>>> If we bootup without DSC panel connected, the kernel's cfg->dsc will be
> >>>> 0 and default register value of CTL_DSC_FLUSH will be 0 so it wont flush
> >>>> any DSC blocks.
> >>>
> >>> Ack, that makes sense.  However, if I connect a DSC panel, then
> >>> disconnect it (now the register should be non-zero, but cfg->dsc will be
> >>> zero), and then replug a non-DSC panel multiple times, it'll get flushed
> >>> every time because we never clear CTL_DSC_FLUSH after that?
> >>
> >> If we remove it after kernel starts, that issue is there even today
> >> without that change because DSI is not a hot-pluggable display so a
> >> teardown wont happen when you plug out the panel. How will cfg->dsc be 0
> >> then? In that case, its not a valid test as there was no indication to
> >> DRM that display was disconnected so we cannot tear it down.
> > 
> > The patch description itself describes hot-pluggable displays, which I
> > believe is the upcoming DSC support for DP?  You ask how cfg->dsc can
> > become zero, but this is **exactly** what the patch description
> > describes, and what this patch is removing the `if` for.  If we are not
> > allowed to discuss that scenario because it is not currently supported,
> > neither should we allow to apply this patch.
> > 
> > With that in mind, can you re-answer the question?
> 
> I didnt follow what needs to be re-answered.
> 
> This patch is being sent in preparation of the DSC over DP support. This 
> does not handle non-hotpluggable displays.

Good, because my question is specifically about *hotpluggable*
displays/panels like the upcoming DSC support for DP.  After all there
would be no point in me suggesting to connect and disconnect
non-hotpluggable displays and expect something sensible to happen,
wouldn't it?  Allow me to copy-paste the question again for convenience,
with some minor wording changes:

	However, if I connect a DSC DP display, then disconnect it (now the
	register should be non-zero, but cfg->dsc will be zero), and then
	connect and reconnect a non-DSC DP display multiple times, it'll get
	flushed every time because we never clear CTL_DSC_FLUSH after that?

And the missing part is: would multiple flushes be harmful in this case?

> I do not think dynamic switch 
> between DSC and non-DSC of non-hotpluggable displays needs to be 
> discussed here as its not handled at all with or without this patch.
> 
> We wanted to get early reviews on the patch. If you want this patch to 
> be absorbed when rest of DSC over DP lands, I have no concerns with 
> that. I wont pick this up for fixes and we will land this together with 
> the rest of DP over DSC.

I don't mind when and where this lands, just want to have the semantics
clear around persisting the value of CTL_DSC_FLUSh in the register.

Regardless, this patch doesn't sound like a fix but a workaround until
reset_intf_cfg() is fixed to be called at the right point, and extended
to clear CTL_DSC_ACTIVE and flush the DSCs.  Perhaps it shouldn't have a
Fixes: tag for that reason, as you intend to reinstate this
if (cfg->dsc) condition when that is done?

- Marijn