linux-kernel - Re: [PATCH drm-misc-next] rockchip/drm: vop2: don't check color_mgmt_changed in atomic

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] [day] [month] [year] [list]

Message-Id: <DAITFEPGXB6Z.38FAE9O9NSSLX@cknow.org>
Date: Tue, 10 Jun 2025 13:27:13 +0200
From: "Diederik de Haas" <didi.debian@...ow.org>
To: "Piotr Zalewski" <pZ010001011111@...ton.me>
Cc: <hjc@...k-chips.com>, <heiko@...ech.de>, <andy.yan@...k-chips.com>,
 <maarten.lankhorst@...ux.intel.com>, <mripard@...nel.org>,
 <tzimmermann@...e.de>, <airlied@...il.com>, <simona@...ll.ch>, "Dang Huynh"
 <danct12@...eup.net>, <dri-devel@...ts.freedesktop.org>,
 <linux-arm-kernel@...ts.infradead.org>,
 <linux-rockchip@...ts.infradead.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH drm-misc-next] rockchip/drm: vop2: don't check
 color_mgmt_changed in atomic_enable

Hi Piotr,

On Tue Jun 10, 2025 at 12:37 AM CEST, Piotr Zalewski wrote:
> Hi Diederik, sorry for late response

No need to be sorry :-)

(late? Less then 2 days vs my ~4 months before the git bisect ...)

>> Interesting that it also happened with drm=y.
>
> I actually checked now and i don't have the issue with drm=y, sorry for 
> misinforming you all, hopefully no one's time was wasted.

Good to know, thanks :-)

>> > happened twice and at short interval and since this patch allows for gamma
>> > LUT update regardless of color_mgmt_changed state this makes DSP CTRL GAMMA
>> > LUT EN bit to be unset twice too. It seems that VOP does not like it. I
>> 
>> Happy to see you found the cause :-)
>> Do you happen to know why it was unset twice? That sounds suboptimal.
>
> It is due to DRM modeset which can happens when CRTC (display) config changes 
> "significantly". AFAIK modeset happens def. when you go out of suspend or
> display timings change. I might have been fooled by serial console last time
> as it does not appear to happen twice in short interval when i review the 
> journal entries.
>
>> But (IIUC) setting a bit to a value it already has causing issues,
>> sounds surprising as well.
>
> Depends on what hardware does, when you write to a register it might cause
> many other things to happen and seems like for vop2 it messes something up.

I didn't know that, thanks.

> I made a second patch so that the first write is not permitted but all 
> subsequent are permitted (regardless of lut en state) - issue disappeared 
> too. So it might be that very first write to dsp lut disable happens too 
> fast (in relation to something else)?. It is not intuitive because when drm is
> a module it happens usually like ~second later.
>
> part of the log with drm=y
> ```
> [    6.543099] rockchip-drm display-subsystem: [drm] GAMMA LUT DISABLE
> ```
>
> part of the log with drm=m
> ```
> [    7.944120] rockchip-drm display-subsystem: [drm] GAMMA LUT DISABLE
> ```

My first (uneducated) hunch was a timing issue and ``=m`` can reveal
issues which you wouldn't see with ``=y``.
Andy already found an issue "that shouldn't happen" and my latest test
also had an unexpected result. So (eventually) we'll figure it out :-)

>> Sounds like a plan. It could be that this issue surfaced an underlaying
>> issue and if so, fixing that would be even better.
>
> When i have time this week I will check on what version of the kernel i 
> tested gamma lut when i sent the patches and test there.

I think it would be beneficial if you'd do the tests that Andy asked
'me' to do too, so we can compare results.
FWIW: I have the 4GB RAM version.

Cheers,
  Diederik

Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)