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

Message-ID: <mArHDRo5bhIAjG8sDOR-kM7DsVdbXxxcC8hfuEEPfUWIdMwNnSUy8ZFoLis66DFSuIEq8TrnAxUGkyo5IUTGw3AG4k3vuVVz0fsoI27BAms=@proton.me>
Date: Sat, 07 Jun 2025 15:32:07 +0000
From: Piotr Zalewski <pZ010001011111@...ton.me>
To: Diederik de Haas <didi.debian@...ow.org>
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

On Thursday, June 5th, 2025 at 10:13 PM, Diederik de Haas <didi.debian@...ow.org> wrote:

> Hi Piotr,
> 
> Since kernel 6.14-rc1 I have the problem that visual output is no longer
> shown on my PineTab2 and a `git bisect` pointed to this patch/commit
> as the culprit. What is important to note is that `CONFIG_DRM=m` seems
> to be required as the problem does not occur with `CONFIG_DRM=y`.
> 
> Near the end of my bisect session, something interesting occurred.
> I was booted into a 'bad' kernel (ie no visual output) and when I
> started to build my final kernel, I closed the lid of the PineTab2 which
> made it go into suspend. When my final kernel was built, I opened the
> lid again, which made it resume, to transfer my final kernel to it.
> And much to my surprise, I then did have visual output.
> When I read the (below) commit message of the 'offending' commit, it may
> not be such a surprise after all.
> 
> When I build a (new) 6.14-rc1 kernel with a revert of this commit on
> top, then I did not have the above mentioned problem, confirming this
> commit was the 'bad' commit.
> 
> I did try it on a Quartz64-B (also rk3566) and it did not have any issue
> (output via HDMI).
> I don't know what the cause for this issue is, hopefully you do.
> 

Hi Diederik,

I tested and confirmed that this happens with drm=m but also in my case 
it happened when drm=y. After some testing I found out that at boot modeset
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 
patched vop2_vp_dsp_lut_disable function so that dsp_ctrl is set only if 
GAMMA LUT EN bit is set. I checked that this also does not break the gamma 
lut functionality with emphasis on out-of/into suspend behavior.

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
index d0f5fea15e21..7ddf311b38c6 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
@@ -897,6 +897,9 @@ static void vop2_vp_dsp_lut_disable(struct vop2_video_port *vp)
 {
 	u32 dsp_ctrl = vop2_vp_read(vp, RK3568_VP_DSP_CTRL);
 
+	if ((dsp_ctrl & RK3568_VP_DSP_CTRL__DSP_LUT_EN) == 0)
+		return;
+
 	dsp_ctrl &= ~RK3568_VP_DSP_CTRL__DSP_LUT_EN;
 	vop2_vp_write(vp, RK3568_VP_DSP_CTRL, dsp_ctrl);
 }

I will wait with sending a patch because maybe Andy has something to add 
to this.

Best regards, Piotr Zalewski