[PATCH drm-misc-next] rockchip/drm: vop2: don't check color_mgmt_changed in atomic_enable

[PATCH drm-misc-next] rockchip/drm: vop2: don't check color_mgmt_changed in atomic_enable

[Piotr Zalewski]

Remove color_mgmt_changed check from vop2_crtc_atomic_try_set_gamma to
allow gamma LUT rewrite during modeset when coming out of suspend. Add
a check for color_mgmt_changed directly in vop2_crtc_atomic_flush.

This patch fixes the patch adding gamma LUT support for vop2 [1].

[1] https://lore.kernel.org/linux-rockchip/20241101185545.559090-3-pZ010001011111@proton.me/

Suggested-by: Andy Yan <andy.yan@rock-chips.com>
Signed-off-by: Piotr Zalewski <pZ010001011111@proton.me>
---
 drivers/gpu/drm/rockchip/rockchip_drm_vop2.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
index 0c8ec7220fbe..d259f1c6571d 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
@@ -1601,7 +1601,7 @@ static void vop2_crtc_atomic_try_set_gamma(struct vop2 *vop2,
 					   struct drm_crtc *crtc,
 					   struct drm_crtc_state *crtc_state)
 {
-	if (!vop2->lut_regs || !crtc_state->color_mgmt_changed)
+	if (!vop2->lut_regs)
 		return;
 
 	if (!crtc_state->gamma_lut) {
@@ -2669,7 +2669,7 @@ static void vop2_crtc_atomic_flush(struct drm_crtc *crtc,
 	struct vop2 *vop2 = vp->vop2;
 
 	/* In case of modeset, gamma lut update already happened in atomic enable */
-	if (!drm_atomic_crtc_needs_modeset(crtc_state))
+	if (!drm_atomic_crtc_needs_modeset(crtc_state) && crtc_state->color_mgmt_changed)
 		vop2_crtc_atomic_try_set_gamma_locked(vop2, vp, crtc, crtc_state);
 
 	vop2_post_config(crtc);
-- 
2.47.1

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

[Heiko Stuebner]

On Fri, 06 Dec 2024 19:26:10 +0000, Piotr Zalewski wrote:
> Remove color_mgmt_changed check from vop2_crtc_atomic_try_set_gamma to
> allow gamma LUT rewrite during modeset when coming out of suspend. Add
> a check for color_mgmt_changed directly in vop2_crtc_atomic_flush.
> 
> This patch fixes the patch adding gamma LUT support for vop2 [1].
> 
> [1] https://lore.kernel.org/linux-rockchip/20241101185545.559090-3-pZ010001011111@proton.me/
> 
> [...]

Applied, thanks!

[1/1] rockchip/drm: vop2: don't check color_mgmt_changed in atomic_enable
      commit: 9c22b6ece2e5c2308f41ba4bec27cfa158397fa7

Best regards,
-- 
Heiko Stuebner <heiko@sntech.de>

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

[Diederik de Haas]

[-- Attachment #1: Type: text/plain, Size: 2890 bytes --]

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.

Cheers,
  Diederik

On Fri Dec 6, 2024 at 8:26 PM CET, Piotr Zalewski wrote:
> Remove color_mgmt_changed check from vop2_crtc_atomic_try_set_gamma to
> allow gamma LUT rewrite during modeset when coming out of suspend. Add
> a check for color_mgmt_changed directly in vop2_crtc_atomic_flush.
>
> This patch fixes the patch adding gamma LUT support for vop2 [1].
>
> [1] https://lore.kernel.org/linux-rockchip/20241101185545.559090-3-pZ010001011111@proton.me/
>
> Suggested-by: Andy Yan <andy.yan@rock-chips.com>
> Signed-off-by: Piotr Zalewski <pZ010001011111@proton.me>
> ---
>  drivers/gpu/drm/rockchip/rockchip_drm_vop2.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
> index 0c8ec7220fbe..d259f1c6571d 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
> @@ -1601,7 +1601,7 @@ static void vop2_crtc_atomic_try_set_gamma(struct vop2 *vop2,
>  					   struct drm_crtc *crtc,
>  					   struct drm_crtc_state *crtc_state)
>  {
> -	if (!vop2->lut_regs || !crtc_state->color_mgmt_changed)
> +	if (!vop2->lut_regs)
>  		return;
>  
>  	if (!crtc_state->gamma_lut) {
> @@ -2669,7 +2669,7 @@ static void vop2_crtc_atomic_flush(struct drm_crtc *crtc,
>  	struct vop2 *vop2 = vp->vop2;
>  
>  	/* In case of modeset, gamma lut update already happened in atomic enable */
> -	if (!drm_atomic_crtc_needs_modeset(crtc_state))
> +	if (!drm_atomic_crtc_needs_modeset(crtc_state) && crtc_state->color_mgmt_changed)
>  		vop2_crtc_atomic_try_set_gamma_locked(vop2, vp, crtc, crtc_state);
>  
>  	vop2_post_config(crtc);


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

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

[Piotr Zalewski]

On Thursday, June 5th, 2025 at 10:13 PM, Diederik de Haas <didi.debian@cknow.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

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

[Diederik de Haas]

[-- Attachment #1: Type: text/plain, Size: 3249 bytes --]

Hi Piotr,

On Sat Jun 7, 2025 at 5:32 PM CEST, Piotr Zalewski wrote:
> On Thursday, June 5th, 2025 at 10:13 PM, Diederik de Haas <didi.debian@cknow.org> wrote:
>> 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.
>> 
>> 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.
>
> 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

Interesting that it also happened with drm=y.
As you're more knowledgeable then I am with this, maybe look through
https://lists.sr.ht/~diederik/pine64-discuss/<D9AM2OOLREO0.2JMAI42J06TW0@cknow.org>

to see if you may spot something relevant?

> 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.
But (IIUC) setting a bit to a value it already has causing issues,
sounds surprising as well.

> 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 built a kernel with 6.14-rc1 + this patch and can confirm the screen
has output again :-)

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

Sounds like a plan. It could be that this issue surfaced an underlaying
issue and if so, fixing that would be even better.

> Best regards, Piotr Zalewski

Thanks a lot!

Cheers,
  Diederik

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

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

[Andy Yan]

Hello，

At 2025-06-08 19:08:50, "Diederik de Haas" <didi.debian@cknow.org> wrote:
>Hi Piotr,
>
>On Sat Jun 7, 2025 at 5:32 PM CEST, Piotr Zalewski wrote:
>> On Thursday, June 5th, 2025 at 10:13 PM, Diederik de Haas <didi.debian@cknow.org> wrote:
>>> 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.
>>> 
>>> 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.
>>
>> 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
>
>Interesting that it also happened with drm=y.
>As you're more knowledgeable then I am with this, maybe look through
>https://lists.sr.ht/~diederik/pine64-discuss/<D9AM2OOLREO0.2JMAI42J06TW0@cknow.org>
>
>to see if you may spot something relevant?
>
>> 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.
>But (IIUC) setting a bit to a value it already has causing issues,
>sounds surprising as well.


I have conducted tests on both rk3566-box-demo (with drm set to y) and rk3568-lubancat-2 (with drm set to m), 
but I was unable to reproduce this issue. Could you two please share your kernel defconfig and the corresponding kernel startup logs? 
Additionally, both of my two boards tested with HDMI output. What kind of display interface does your board use for output?

>
>> 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 built a kernel with 6.14-rc1 + this patch and can confirm the screen
>has output again :-)
>
>> I will wait with sending a patch because maybe Andy has something to add 
>> to this.
>
>Sounds like a plan. It could be that this issue surfaced an underlaying
>issue and if so, fixing that would be even better.
>
>> Best regards, Piotr Zalewski
>
>Thanks a lot!
>
>Cheers,
>  Diederik

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

[Diederik de Haas]

[-- Attachment #1: Type: text/plain, Size: 4567 bytes --]

Hi Andy,

On Sun Jun 8, 2025 at 2:10 PM CEST, Andy Yan wrote:
> At 2025-06-08 19:08:50, "Diederik de Haas" <didi.debian@cknow.org> wrote:
>>On Sat Jun 7, 2025 at 5:32 PM CEST, Piotr Zalewski wrote:
>>> On Thursday, June 5th, 2025 at 10:13 PM, Diederik de Haas <didi.debian@cknow.org> wrote:
>>>> 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.
>>>> 
>>>> 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.
>>>
>>> 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
>>
>>Interesting that it also happened with drm=y.
>>As you're more knowledgeable then I am with this, maybe look through
>>https://lists.sr.ht/~diederik/pine64-discuss/<D9AM2OOLREO0.2JMAI42J06TW0@cknow.org>
>>
>>to see if you may spot something relevant?
>>
>>> 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.
>>But (IIUC) setting a bit to a value it already has causing issues,
>>sounds surprising as well.
>
> I have conducted tests on both rk3566-box-demo (with drm set to y) and rk3568-lubancat-2 (with drm set to m), 
> but I was unable to reproduce this issue. Could you two please share your kernel defconfig and the corresponding kernel startup logs? 
> Additionally, both of my two boards tested with HDMI output. What kind of display interface does your board use for output?

I wasn't able to reproduce this issue on my PINE64 Quartz-B (rk3566) 
with HDMI output either, but the problem is present on a PineTab2 [1]
(also rk3566) which uses a MIPI DSI connection to the display panel.

Kernel config:
https://paste.sr.ht/~diederik/aa747ed170aa01cc759fbe1ffd9cebe8c887b10b

dmesg kernel 6.14-rc1:
https://paste.sr.ht/~diederik/733fbf8bb7f6aee8b68cf5a652157d445462c24a

dmesg kernel 6.14-rc1 with Piotr's patch:
https://paste.sr.ht/~diederik/db1af672cfb611acbfbdf35adb6f170e5c38febc

Both dmesg outputs contain a suspend-resume cycle.
I'm using a USB Wi-Fi adapter for the wireless connection.

[1] https://wiki.pine64.org/wiki/PineTab2

Happy to provide more info and/or do some tests.

Cheers,
  Diederik

>>> 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 built a kernel with 6.14-rc1 + this patch and can confirm the screen
>>has output again :-)
>>
>>> I will wait with sending a patch because maybe Andy has something to add 
>>> to this.
>>
>>Sounds like a plan. It could be that this issue surfaced an underlaying
>>issue and if so, fixing that would be even better.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

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

[Andy Yan]

[-- Attachment #1: Type: text/plain, Size: 4808 bytes --]



Hi Diederik,

At 2025-06-08 20:53:37, "Diederik de Haas" <didi.debian@cknow.org> wrote:
>Hi Andy,
>
>On Sun Jun 8, 2025 at 2:10 PM CEST, Andy Yan wrote:
>> At 2025-06-08 19:08:50, "Diederik de Haas" <didi.debian@cknow.org> wrote:
>>>On Sat Jun 7, 2025 at 5:32 PM CEST, Piotr Zalewski wrote:
>>>> On Thursday, June 5th, 2025 at 10:13 PM, Diederik de Haas <didi.debian@cknow.org> wrote:
>>>>> 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.
>>>>> 
>>>>> 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.
>>>>
>>>> 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
>>>
>>>Interesting that it also happened with drm=y.
>>>As you're more knowledgeable then I am with this, maybe look through
>>>https://lists.sr.ht/~diederik/pine64-discuss/<D9AM2OOLREO0.2JMAI42J06TW0@cknow.org>
>>>
>>>to see if you may spot something relevant?
>>>
>>>> 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.
>>>But (IIUC) setting a bit to a value it already has causing issues,
>>>sounds surprising as well.
>>
>> I have conducted tests on both rk3566-box-demo (with drm set to y) and rk3568-lubancat-2 (with drm set to m), 
>> but I was unable to reproduce this issue. Could you two please share your kernel defconfig and the corresponding kernel startup logs? 
>> Additionally, both of my two boards tested with HDMI output. What kind of display interface does your board use for output?
>
>I wasn't able to reproduce this issue on my PINE64 Quartz-B (rk3566) 
>with HDMI output either, but the problem is present on a PineTab2 [1]
>(also rk3566) which uses a MIPI DSI connection to the display panel.
>
>Kernel config:
>https://paste.sr.ht/~diederik/aa747ed170aa01cc759fbe1ffd9cebe8c887b10b
>
>dmesg kernel 6.14-rc1:
>https://paste.sr.ht/~diederik/733fbf8bb7f6aee8b68cf5a652157d445462c24a
>
>dmesg kernel 6.14-rc1 with Piotr's patch:
>https://paste.sr.ht/~diederik/db1af672cfb611acbfbdf35adb6f170e5c38febc
>
>Both dmesg outputs contain a suspend-resume cycle.
>I'm using a USB Wi-Fi adapter for the wireless connection.
>
>[1] https://wiki.pine64.org/wiki/PineTab2
>
>Happy to provide more info and/or do some tests.

Can you apply the patch in the attachment, reproduce this issue(without Piotr's patch), 
and then provide me with a copy of the kernel log?

Thanks.

>
>Cheers,
>  Diederik
>
>>>> 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 built a kernel with 6.14-rc1 + this patch and can confirm the screen
>>>has output again :-)
>>>
>>>> I will wait with sending a patch because maybe Andy has something to add 
>>>> to this.
>>>
>>>Sounds like a plan. It could be that this issue surfaced an underlaying
>>>issue and if so, fixing that would be even better.

[-- Attachment #2: print_lut_0609_1710.patch --]
[-- Type: application/octet-stream, Size: 1223 bytes --]

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
index d0f5fea15e21..d90b345b5b53 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
@@ -898,6 +898,7 @@ static void vop2_vp_dsp_lut_disable(struct vop2_video_port *vp)
 	u32 dsp_ctrl = vop2_vp_read(vp, RK3568_VP_DSP_CTRL);
 
 	dsp_ctrl &= ~RK3568_VP_DSP_CTRL__DSP_LUT_EN;
+	printk("vop2_vp_dsp_lut_disable dsp_ctrl: 0x%08x\n", dsp_ctrl);
 	vop2_vp_write(vp, RK3568_VP_DSP_CTRL, dsp_ctrl);
 }
 
@@ -1506,7 +1507,7 @@ static void vop2_crtc_atomic_try_set_gamma(struct vop2 *vop2,
 {
 	if (!vop2->lut_regs)
 		return;
-
+	printk("%s  gamma_lut: %px\n", __func__, crtc_state->gamma_lut);
 	if (!crtc_state->gamma_lut) {
 		vop2_vp_dsp_lut_disable(vp);
 		return;
@@ -1643,7 +1644,7 @@ static void vop2_crtc_atomic_enable(struct drm_crtc *crtc,
 	int ret;
 	struct drm_encoder *encoder;
 
-	drm_dbg(vop2->drm, "Update mode to %dx%d%s%d, type: %d for vp%d\n",
+	drm_info(vop2->drm, "Update mode to %dx%d%s%d, type: %d for vp%d\n",
 		hdisplay, vdisplay, mode->flags & DRM_MODE_FLAG_INTERLACE ? "i" : "p",
 		drm_mode_vrefresh(mode), vcstate->output_type, vp->id);
 

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

[Diederik de Haas]

[-- Attachment #1: Type: text/plain, Size: 5242 bytes --]

Hi Andy,

On Mon Jun 9, 2025 at 11:15 AM CEST, Andy Yan wrote:
> At 2025-06-08 20:53:37, "Diederik de Haas" <didi.debian@cknow.org> wrote:
>>On Sun Jun 8, 2025 at 2:10 PM CEST, Andy Yan wrote:
>>> At 2025-06-08 19:08:50, "Diederik de Haas" <didi.debian@cknow.org> wrote:
>>>>On Sat Jun 7, 2025 at 5:32 PM CEST, Piotr Zalewski wrote:
>>>>> On Thursday, June 5th, 2025 at 10:13 PM, Diederik de Haas <didi.debian@cknow.org> wrote:
>>>>>> 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.
>>>>>> 
>>>>>> 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.
>>>>>
>>>>> 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
>>>>
>>>>Interesting that it also happened with drm=y.
>>>>As you're more knowledgeable then I am with this, maybe look through
>>>>https://lists.sr.ht/~diederik/pine64-discuss/<D9AM2OOLREO0.2JMAI42J06TW0@cknow.org>
>>>>
>>>>to see if you may spot something relevant?
>>>>
>>>>> 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.
>>>>But (IIUC) setting a bit to a value it already has causing issues,
>>>>sounds surprising as well.
>>>
>>> I have conducted tests on both rk3566-box-demo (with drm set to y) and rk3568-lubancat-2 (with drm set to m), 
>>> but I was unable to reproduce this issue. Could you two please share your kernel defconfig and the corresponding kernel startup logs? 
>>> Additionally, both of my two boards tested with HDMI output. What kind of display interface does your board use for output?
>>
>>I wasn't able to reproduce this issue on my PINE64 Quartz-B (rk3566) 
>>with HDMI output either, but the problem is present on a PineTab2 [1]
>>(also rk3566) which uses a MIPI DSI connection to the display panel.
>>
>>Kernel config:
>>https://paste.sr.ht/~diederik/aa747ed170aa01cc759fbe1ffd9cebe8c887b10b
>>
>>dmesg kernel 6.14-rc1:
>>https://paste.sr.ht/~diederik/733fbf8bb7f6aee8b68cf5a652157d445462c24a
>>
>>dmesg kernel 6.14-rc1 with Piotr's patch:
>>https://paste.sr.ht/~diederik/db1af672cfb611acbfbdf35adb6f170e5c38febc
>>
>>Both dmesg outputs contain a suspend-resume cycle.
>>I'm using a USB Wi-Fi adapter for the wireless connection.
>>
>>[1] https://wiki.pine64.org/wiki/PineTab2
>>
>>Happy to provide more info and/or do some tests.
>
> Can you apply the patch in the attachment, reproduce this issue(without Piotr's patch), 
> and then provide me with a copy of the kernel log?

Same test as above, but added ``dmesg | grep "vop2_"`` at the end as well

dmesg kernel 6.14-rc1 with Andy's print_lut_0609_1710 patch:
https://paste.sr.ht/~diederik/ac356ee8b0f7e772c7310293d99d95644f59a4ee

Thanks!

Diederik

>>>>> 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 built a kernel with 6.14-rc1 + this patch and can confirm the screen
>>>>has output again :-)
>>>>
>>>>> I will wait with sending a patch because maybe Andy has something to add 
>>>>> to this.
>>>>
>>>>Sounds like a plan. It could be that this issue surfaced an underlaying
>>>>issue and if so, fixing that would be even better.


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

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

[Piotr Zalewski]

Hi Diederik, sorry for late response

> 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.

> As you're more knowledgeable then I am with this, maybe look through
> https://lists.sr.ht/~diederik/pine64-discuss/D9AM2OOLREO0.2JMAI42J06TW0@cknow.org
> 
> to see if you may spot something relevant?

Heh, I'm not that knowledgeable but I will look through it.

> > 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 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
```

> > 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 built a kernel with 6.14-rc1 + this patch and can confirm the screen
> has output again :-)

cool :)
 
> > I will wait with sending a patch because maybe Andy has something to add
> > to this.
> 
> 
> 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.

> Thanks a lot!
> 

Thank _you_ for taking your time to do all the bisecting.

Best regards, Piotr Zalewski

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

[Andy Yan]

[-- Attachment #1: Type: text/plain, Size: 6607 bytes --]



Hi Diederik，
At 2025-06-09 20:36:41, "Diederik de Haas" <didi.debian@cknow.org> wrote:
>Hi Andy,
>
>On Mon Jun 9, 2025 at 11:15 AM CEST, Andy Yan wrote:
>> At 2025-06-08 20:53:37, "Diederik de Haas" <didi.debian@cknow.org> wrote:
>>>On Sun Jun 8, 2025 at 2:10 PM CEST, Andy Yan wrote:
>>>> At 2025-06-08 19:08:50, "Diederik de Haas" <didi.debian@cknow.org> wrote:
>>>>>On Sat Jun 7, 2025 at 5:32 PM CEST, Piotr Zalewski wrote:
>>>>>> On Thursday, June 5th, 2025 at 10:13 PM, Diederik de Haas <didi.debian@cknow.org> wrote:
>>>>>>> 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.
>>>>>>> 
>>>>>>> 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.
>>>>>>
>>>>>> 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
>>>>>
>>>>>Interesting that it also happened with drm=y.
>>>>>As you're more knowledgeable then I am with this, maybe look through
>>>>>https://lists.sr.ht/~diederik/pine64-discuss/<D9AM2OOLREO0.2JMAI42J06TW0@cknow.org>
>>>>>
>>>>>to see if you may spot something relevant?
>>>>>
>>>>>> 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.
>>>>>But (IIUC) setting a bit to a value it already has causing issues,
>>>>>sounds surprising as well.
>>>>
>>>> I have conducted tests on both rk3566-box-demo (with drm set to y) and rk3568-lubancat-2 (with drm set to m), 
>>>> but I was unable to reproduce this issue. Could you two please share your kernel defconfig and the corresponding kernel startup logs? 
>>>> Additionally, both of my two boards tested with HDMI output. What kind of display interface does your board use for output?
>>>
>>>I wasn't able to reproduce this issue on my PINE64 Quartz-B (rk3566) 
>>>with HDMI output either, but the problem is present on a PineTab2 [1]
>>>(also rk3566) which uses a MIPI DSI connection to the display panel.
>>>
>>>Kernel config:
>>>https://paste.sr.ht/~diederik/aa747ed170aa01cc759fbe1ffd9cebe8c887b10b
>>>
>>>dmesg kernel 6.14-rc1:
>>>https://paste.sr.ht/~diederik/733fbf8bb7f6aee8b68cf5a652157d445462c24a
>>>
>>>dmesg kernel 6.14-rc1 with Piotr's patch:
>>>https://paste.sr.ht/~diederik/db1af672cfb611acbfbdf35adb6f170e5c38febc
>>>
>>>Both dmesg outputs contain a suspend-resume cycle.
>>>I'm using a USB Wi-Fi adapter for the wireless connection.
>>>
>>>[1] https://wiki.pine64.org/wiki/PineTab2
>>>
>>>Happy to provide more info and/or do some tests.
>>
>> Can you apply the patch in the attachment, reproduce this issue(without Piotr's patch), 
>> and then provide me with a copy of the kernel log?
>
>Same test as above, but added ``dmesg | grep "vop2_"`` at the end as well
>
>dmesg kernel 6.14-rc1 with Andy's print_lut_0609_1710 patch:
>https://paste.sr.ht/~diederik/ac356ee8b0f7e772c7310293d99d95644f59a4ee


root@pt2-scmi:~# dmesg | grep "vop2_"
[    4.996281] rockchip-drm display-subsystem: bound fe040000.vop (ops vop2_crtc_atomic_try_set_gamma.part.0 [rockchipdrm])
[    5.005207] rockchip-drm display-subsystem: bound fe0a0000.hdmi (ops vop2_crtc_atomic_try_set_gamma.part.0 [rockchipdrm])
[    5.006798] rockchip-drm display-subsystem: bound fe060000.dsi (ops vop2_crtc_atomic_try_set_gamma.part.0 [rockchipdrm])
[    5.021204] vop2_crtc_atomic_try_set_gamma  gamma_lut: 0000000000000000
[    5.021219] vop2_vp_dsp_lut_disable dsp_ctrl: 0x0000000f

It seems that dsp_ctrl: 0x0000000f , this value is not what we expected.

The expected is 0x00010000.

Could you please do an experiment for me? When there is no display on your screen, 
execute the following command and see if the screen can resume displaying:

./data/io  -w -4 0xfe040d00 0x10000; io -w -4 0xfe040000 0x28002 

I have placed the io tool in the attachment.

You can use command like bellow to read back to confirm if what you write has taken effect:
io -r -4 -l 0x100  0xfe040d00 

you may need to make CONFIG_DEVMEM=y so that you can write the register by io command.



[   73.750524] vop2_crtc_atomic_try_set_gamma  gamma_lut: 0000000000000000
[   73.750542] vop2_vp_dsp_lut_disable dsp_ctrl: 0x00010000
>
>Thanks!
>
>Diederik
>
>>>>>> 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 built a kernel with 6.14-rc1 + this patch and can confirm the screen
>>>>>has output again :-)
>>>>>
>>>>>> I will wait with sending a patch because maybe Andy has something to add 
>>>>>> to this.
>>>>>
>>>>>Sounds like a plan. It could be that this issue surfaced an underlaying
>>>>>issue and if so, fixing that would be even better.
>

[-- Attachment #2: io --]
[-- Type: application/octet-stream, Size: 593608 bytes --]

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

[Diederik de Haas]

[-- Attachment #1: Type: text/plain, Size: 5799 bytes --]

Hi Andy,

On Tue Jun 10, 2025 at 11:07 AM CEST, Andy Yan wrote:
> At 2025-06-09 20:36:41, "Diederik de Haas" <didi.debian@cknow.org> wrote:
>>On Mon Jun 9, 2025 at 11:15 AM CEST, Andy Yan wrote:
>>> At 2025-06-08 20:53:37, "Diederik de Haas" <didi.debian@cknow.org> wrote:
>>>>On Sun Jun 8, 2025 at 2:10 PM CEST, Andy Yan wrote:
>>>>> At 2025-06-08 19:08:50, "Diederik de Haas" <didi.debian@cknow.org> wrote:
>>>>>>On Sat Jun 7, 2025 at 5:32 PM CEST, Piotr Zalewski wrote:
>>>>>>> On Thursday, June 5th, 2025 at 10:13 PM, Diederik de Haas <didi.debian@cknow.org> wrote:
>>>>>>>> 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
>>>>>
>>>>> I have conducted tests on both rk3566-box-demo (with drm set to y)
>>>>> and rk3568-lubancat-2 (with drm set to m), but I was unable to
>>>>> reproduce this issue. Could you two please share your kernel
>>>>> defconfig and the corresponding kernel startup logs?
>>>>> Additionally, both of my two boards tested with HDMI output. What
>>>>> kind of display interface does your board use for output?
>>>>
>>>>I wasn't able to reproduce this issue on my PINE64 Quartz-B (rk3566) 
>>>>with HDMI output either, but the problem is present on a PineTab2 [1]
>>>>(also rk3566) which uses a MIPI DSI connection to the display panel.
>>>>
>>>>Kernel config:
>>>>https://paste.sr.ht/~diederik/aa747ed170aa01cc759fbe1ffd9cebe8c887b10b
>>>>
>>>>dmesg kernel 6.14-rc1:
>>>>https://paste.sr.ht/~diederik/733fbf8bb7f6aee8b68cf5a652157d445462c24a
>>>>
>>>>dmesg kernel 6.14-rc1 with Piotr's patch:
>>>>https://paste.sr.ht/~diederik/db1af672cfb611acbfbdf35adb6f170e5c38febc
>>>>
>>>>Both dmesg outputs contain a suspend-resume cycle.
>>>>I'm using a USB Wi-Fi adapter for the wireless connection.
>>>>
>>>>[1] https://wiki.pine64.org/wiki/PineTab2
>>>>
>>>>Happy to provide more info and/or do some tests.
>>>
>>> Can you apply the patch in the attachment, reproduce this issue(without Piotr's patch), 
>>> and then provide me with a copy of the kernel log?
>>
>>Same test as above, but added ``dmesg | grep "vop2_"`` at the end as well
>>
>>dmesg kernel 6.14-rc1 with Andy's print_lut_0609_1710 patch:
>>https://paste.sr.ht/~diederik/ac356ee8b0f7e772c7310293d99d95644f59a4ee
>
>
> root@pt2-scmi:~# dmesg | grep "vop2_"
> [    4.996281] rockchip-drm display-subsystem: bound fe040000.vop (ops vop2_crtc_atomic_try_set_gamma.part.0 [rockchipdrm])
> [    5.005207] rockchip-drm display-subsystem: bound fe0a0000.hdmi (ops vop2_crtc_atomic_try_set_gamma.part.0 [rockchipdrm])
> [    5.006798] rockchip-drm display-subsystem: bound fe060000.dsi (ops vop2_crtc_atomic_try_set_gamma.part.0 [rockchipdrm])
> [    5.021204] vop2_crtc_atomic_try_set_gamma  gamma_lut: 0000000000000000
> [    5.021219] vop2_vp_dsp_lut_disable dsp_ctrl: 0x0000000f
>
> It seems that dsp_ctrl: 0x0000000f , this value is not what we expected.
>
> The expected is 0x00010000.
>
> Could you please do an experiment for me? When there is no display on your screen, 
> execute the following command and see if the screen can resume displaying:
>
> ./data/io  -w -4 0xfe040d00 0x10000; io -w -4 0xfe040000 0x28002 
>
> I have placed the io tool in the attachment.
>
> You can use command like bellow to read back to confirm if what you write has taken effect:
> io -r -4 -l 0x100  0xfe040d00 
>
> you may need to make CONFIG_DEVMEM=y so that you can write the register by io command.

I renamed it as ``andy-io`` and performed the test:

```sh
root@pt2-scmi:~# echo 'just (re-)booted into my PineTab2; screen is blank'
just (re-)booted into my PineTab2; screen is blank
root@pt2-scmi:~# uname -a
Linux pt2-scmi 6.14.0-rc1-00001-gfbe17d9b77b0 #18 SMP Mon Jun  9 13:17:28 CEST 2025 aarch64 GNU/Linux
root@pt2-scmi:~# ./andy-io -r -4 -l 0x100 0xfe040d00
mmap() failed: Operation not permitted
root@pt2-scmi:~# grep CONFIG_DEVMEM /boot/config-6.14.0-rc1-00001-gfbe17d9b77b0
CONFIG_DEVMEM=y
root@pt2-scmi:~# ./andy-io -w -4 0xfe040d00 0x10000
mmap() failed: Operation not permitted
root@pt2-scmi:~# ./andy-io -w -4 0xfe040000 0x28002
mmap() failed: Operation not permitted
```

I guess this is not what you expected and I don't know why it happens.

Cheers,
  Diederik

> [   73.750524] vop2_crtc_atomic_try_set_gamma  gamma_lut: 0000000000000000
> [   73.750542] vop2_vp_dsp_lut_disable dsp_ctrl: 0x00010000
>>>>>>> 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 built a kernel with 6.14-rc1 + this patch and can confirm the screen
>>>>>>has output again :-)
>>>>>>
>>>>>>> I will wait with sending a patch because maybe Andy has something to add 
>>>>>>> to this.
>>>>>>
>>>>>>Sounds like a plan. It could be that this issue surfaced an underlaying
>>>>>>issue and if so, fixing that would be even better.


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

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

[Diederik de Haas]

[-- Attachment #1: Type: text/plain, Size: 2743 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

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

[Andy Yan]

Hi Diederik，

At 2025-06-10 19:02:11, "Diederik de Haas" <didi.debian@cknow.org> wrote:
>Hi Andy,
>
>On Tue Jun 10, 2025 at 11:07 AM CEST, Andy Yan wrote:
>> At 2025-06-09 20:36:41, "Diederik de Haas" <didi.debian@cknow.org> wrote:
>>>On Mon Jun 9, 2025 at 11:15 AM CEST, Andy Yan wrote:
>>>> At 2025-06-08 20:53:37, "Diederik de Haas" <didi.debian@cknow.org> wrote:
>>>>>On Sun Jun 8, 2025 at 2:10 PM CEST, Andy Yan wrote:
>>>>>> At 2025-06-08 19:08:50, "Diederik de Haas" <didi.debian@cknow.org> wrote:
>>>>>>>On Sat Jun 7, 2025 at 5:32 PM CEST, Piotr Zalewski wrote:
>>>>>>>> On Thursday, June 5th, 2025 at 10:13 PM, Diederik de Haas <didi.debian@cknow.org> wrote:
>>>>>>>>> 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
>>>>>>
>>>>>> I have conducted tests on both rk3566-box-demo (with drm set to y)
>>>>>> and rk3568-lubancat-2 (with drm set to m), but I was unable to
>>>>>> reproduce this issue. Could you two please share your kernel
>>>>>> defconfig and the corresponding kernel startup logs?
>>>>>> Additionally, both of my two boards tested with HDMI output. What
>>>>>> kind of display interface does your board use for output?
>>>>>
>>>>>I wasn't able to reproduce this issue on my PINE64 Quartz-B (rk3566) 
>>>>>with HDMI output either, but the problem is present on a PineTab2 [1]
>>>>>(also rk3566) which uses a MIPI DSI connection to the display panel.
>>>>>
>>>>>Kernel config:
>>>>>https://paste.sr.ht/~diederik/aa747ed170aa01cc759fbe1ffd9cebe8c887b10b
>>>>>
>>>>>dmesg kernel 6.14-rc1:
>>>>>https://paste.sr.ht/~diederik/733fbf8bb7f6aee8b68cf5a652157d445462c24a
>>>>>
>>>>>dmesg kernel 6.14-rc1 with Piotr's patch:
>>>>>https://paste.sr.ht/~diederik/db1af672cfb611acbfbdf35adb6f170e5c38febc
>>>>>
>>>>>Both dmesg outputs contain a suspend-resume cycle.
>>>>>I'm using a USB Wi-Fi adapter for the wireless connection.
>>>>>
>>>>>[1] https://wiki.pine64.org/wiki/PineTab2
>>>>>
>>>>>Happy to provide more info and/or do some tests.
>>>>
>>>> Can you apply the patch in the attachment, reproduce this issue(without Piotr's patch), 
>>>> and then provide me with a copy of the kernel log?
>>>
>>>Same test as above, but added ``dmesg | grep "vop2_"`` at the end as well
>>>
>>>dmesg kernel 6.14-rc1 with Andy's print_lut_0609_1710 patch:
>>>https://paste.sr.ht/~diederik/ac356ee8b0f7e772c7310293d99d95644f59a4ee
>>
>>
>> root@pt2-scmi:~# dmesg | grep "vop2_"
>> [    4.996281] rockchip-drm display-subsystem: bound fe040000.vop (ops vop2_crtc_atomic_try_set_gamma.part.0 [rockchipdrm])
>> [    5.005207] rockchip-drm display-subsystem: bound fe0a0000.hdmi (ops vop2_crtc_atomic_try_set_gamma.part.0 [rockchipdrm])
>> [    5.006798] rockchip-drm display-subsystem: bound fe060000.dsi (ops vop2_crtc_atomic_try_set_gamma.part.0 [rockchipdrm])
>> [    5.021204] vop2_crtc_atomic_try_set_gamma  gamma_lut: 0000000000000000
>> [    5.021219] vop2_vp_dsp_lut_disable dsp_ctrl: 0x0000000f
>>
>> It seems that dsp_ctrl: 0x0000000f , this value is not what we expected.
>>
>> The expected is 0x00010000.
>>
>> Could you please do an experiment for me? When there is no display on your screen, 
>> execute the following command and see if the screen can resume displaying:
>>
>> ./data/io  -w -4 0xfe040d00 0x10000; io -w -4 0xfe040000 0x28002 
>>
>> I have placed the io tool in the attachment.
>>
>> You can use command like bellow to read back to confirm if what you write has taken effect:
>> io -r -4 -l 0x100  0xfe040d00 
>>
>> you may need to make CONFIG_DEVMEM=y so that you can write the register by io command.
>
>I renamed it as ``andy-io`` and performed the test:
>
>```sh
>root@pt2-scmi:~# echo 'just (re-)booted into my PineTab2; screen is blank'
>just (re-)booted into my PineTab2; screen is blank
>root@pt2-scmi:~# uname -a
>Linux pt2-scmi 6.14.0-rc1-00001-gfbe17d9b77b0 #18 SMP Mon Jun  9 13:17:28 CEST 2025 aarch64 GNU/Linux
>root@pt2-scmi:~# ./andy-io -r -4 -l 0x100 0xfe040d00
>mmap() failed: Operation not permitted
>root@pt2-scmi:~# grep CONFIG_DEVMEM /boot/config-6.14.0-rc1-00001-gfbe17d9b77b0
>CONFIG_DEVMEM=y
>root@pt2-scmi:~# ./andy-io -w -4 0xfe040d00 0x10000
>mmap() failed: Operation not permitted
>root@pt2-scmi:~# ./andy-io -w -4 0xfe040000 0x28002
>mmap() failed: Operation not permitted
>```


This is my config about DEVMEM:

~/WorkSpace/linux-next$ rg DEVMEM .config
1014:CONFIG_NET_DEVMEM=y
3069:CONFIG_DEVMEM=y
7280:CONFIG_GENERIC_LIB_DEVMEM_IS_ALLOWED=y
7542:CONFIG_STRICT_DEVMEM=y
7543:# CONFIG_IO_STRICT_DEVMEM is not set

CONFIG_IO_STRICT_DEVMEM should not be set to y if you want to access an IO address from usersapce.


>
>I guess this is not what you expected and I don't know why it happens.
>
>Cheers,
>  Diederik
>
>> [   73.750524] vop2_crtc_atomic_try_set_gamma  gamma_lut: 0000000000000000
>> [   73.750542] vop2_vp_dsp_lut_disable dsp_ctrl: 0x00010000
>>>>>>>> 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 built a kernel with 6.14-rc1 + this patch and can confirm the screen
>>>>>>>has output again :-)
>>>>>>>
>>>>>>>> I will wait with sending a patch because maybe Andy has something to add 
>>>>>>>> to this.
>>>>>>>
>>>>>>>Sounds like a plan. It could be that this issue surfaced an underlaying
>>>>>>>issue and if so, fixing that would be even better.
>

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

[Diederik de Haas]

[-- Attachment #1: Type: text/plain, Size: 10945 bytes --]

Hi Andy,

On Wed Jun 11, 2025 at 9:41 AM CEST, Andy Yan wrote:
> At 2025-06-10 19:02:11, "Diederik de Haas" <didi.debian@cknow.org> wrote:
>>On Tue Jun 10, 2025 at 11:07 AM CEST, Andy Yan wrote:
>>> At 2025-06-09 20:36:41, "Diederik de Haas" <didi.debian@cknow.org> wrote:
>>>>On Mon Jun 9, 2025 at 11:15 AM CEST, Andy Yan wrote:
>>>>> At 2025-06-08 20:53:37, "Diederik de Haas" <didi.debian@cknow.org> wrote:
>>>>>>On Sun Jun 8, 2025 at 2:10 PM CEST, Andy Yan wrote:
>>>>>>> At 2025-06-08 19:08:50, "Diederik de Haas" <didi.debian@cknow.org> wrote:
>>>>>>>>On Sat Jun 7, 2025 at 5:32 PM CEST, Piotr Zalewski wrote:
>>>>>>>>> On Thursday, June 5th, 2025 at 10:13 PM, Diederik de Haas <didi.debian@cknow.org> wrote:
>>>>>>>>>> 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
>>>>>>>
>>>>>>> I have conducted tests on both rk3566-box-demo (with drm set to y)
>>>>>>> and rk3568-lubancat-2 (with drm set to m), but I was unable to
>>>>>>> reproduce this issue. Could you two please share your kernel
>>>>>>> defconfig and the corresponding kernel startup logs?
>>>>>>> Additionally, both of my two boards tested with HDMI output. What
>>>>>>> kind of display interface does your board use for output?
>>>>>>
>>>>>>I wasn't able to reproduce this issue on my PINE64 Quartz-B (rk3566) 
>>>>>>with HDMI output either, but the problem is present on a PineTab2 [1]
>>>>>>(also rk3566) which uses a MIPI DSI connection to the display panel.
>>>>>>
>>>>>>Kernel config:
>>>>>>https://paste.sr.ht/~diederik/aa747ed170aa01cc759fbe1ffd9cebe8c887b10b
>>>>>>
>>>>>>dmesg kernel 6.14-rc1:
>>>>>>https://paste.sr.ht/~diederik/733fbf8bb7f6aee8b68cf5a652157d445462c24a
>>>>>>
>>>>>>dmesg kernel 6.14-rc1 with Piotr's patch:
>>>>>>https://paste.sr.ht/~diederik/db1af672cfb611acbfbdf35adb6f170e5c38febc
>>>>>>
>>>>>>Both dmesg outputs contain a suspend-resume cycle.
>>>>>>I'm using a USB Wi-Fi adapter for the wireless connection.
>>>>>>
>>>>>>[1] https://wiki.pine64.org/wiki/PineTab2
>>>>>>
>>>>>>Happy to provide more info and/or do some tests.
>>>>>
>>>>> Can you apply the patch in the attachment, reproduce this issue(without Piotr's patch), 
>>>>> and then provide me with a copy of the kernel log?
>>>>
>>>>Same test as above, but added ``dmesg | grep "vop2_"`` at the end as well
>>>>
>>>>dmesg kernel 6.14-rc1 with Andy's print_lut_0609_1710 patch:
>>>>https://paste.sr.ht/~diederik/ac356ee8b0f7e772c7310293d99d95644f59a4ee
>>>
>>> root@pt2-scmi:~# dmesg | grep "vop2_"
>>> [    4.996281] rockchip-drm display-subsystem: bound fe040000.vop (ops vop2_crtc_atomic_try_set_gamma.part.0 [rockchipdrm])
>>> [    5.005207] rockchip-drm display-subsystem: bound fe0a0000.hdmi (ops vop2_crtc_atomic_try_set_gamma.part.0 [rockchipdrm])
>>> [    5.006798] rockchip-drm display-subsystem: bound fe060000.dsi (ops vop2_crtc_atomic_try_set_gamma.part.0 [rockchipdrm])
>>> [    5.021204] vop2_crtc_atomic_try_set_gamma  gamma_lut: 0000000000000000
>>> [    5.021219] vop2_vp_dsp_lut_disable dsp_ctrl: 0x0000000f
>>>
>>> It seems that dsp_ctrl: 0x0000000f , this value is not what we expected.
>>>
>>> The expected is 0x00010000.
>>>
>>> Could you please do an experiment for me? When there is no display on your screen, 
>>> execute the following command and see if the screen can resume displaying:
>>>
>>> ./data/io  -w -4 0xfe040d00 0x10000; io -w -4 0xfe040000 0x28002 
>>>
>>> I have placed the io tool in the attachment.
>>>
>>> You can use command like bellow to read back to confirm if what you write has taken effect:
>>> io -r -4 -l 0x100  0xfe040d00 
>>>
>>> you may need to make CONFIG_DEVMEM=y so that you can write the register by io command.
>>
>>I renamed it as ``andy-io`` and performed the test:
>>
>>```sh
>>root@pt2-scmi:~# echo 'just (re-)booted into my PineTab2; screen is blank'
>>just (re-)booted into my PineTab2; screen is blank
>>root@pt2-scmi:~# uname -a
>>Linux pt2-scmi 6.14.0-rc1-00001-gfbe17d9b77b0 #18 SMP Mon Jun  9 13:17:28 CEST 2025 aarch64 GNU/Linux
>>root@pt2-scmi:~# ./andy-io -r -4 -l 0x100 0xfe040d00
>>mmap() failed: Operation not permitted
>>root@pt2-scmi:~# grep CONFIG_DEVMEM /boot/config-6.14.0-rc1-00001-gfbe17d9b77b0
>>CONFIG_DEVMEM=y
>>root@pt2-scmi:~# ./andy-io -w -4 0xfe040d00 0x10000
>>mmap() failed: Operation not permitted
>>root@pt2-scmi:~# ./andy-io -w -4 0xfe040000 0x28002
>>mmap() failed: Operation not permitted
>>```
>
> This is my config about DEVMEM:
>
> ~/WorkSpace/linux-next$ rg DEVMEM .config
> 1014:CONFIG_NET_DEVMEM=y
> 3069:CONFIG_DEVMEM=y
> 7280:CONFIG_GENERIC_LIB_DEVMEM_IS_ALLOWED=y
> 7542:CONFIG_STRICT_DEVMEM=y
> 7543:# CONFIG_IO_STRICT_DEVMEM is not set
>
> CONFIG_IO_STRICT_DEVMEM should not be set to y if you want to access an IO address from usersapce.

That last one seems to be the culprit:

root@pt2-scmi:~# grep DEVMEM /boot/config-6.14.0-rc1-00001-gfbe17d9b77b0
CONFIG_NET_DEVMEM=y
CONFIG_DEVMEM=y
CONFIG_GENERIC_LIB_DEVMEM_IS_ALLOWED=y
CONFIG_STRICT_DEVMEM=y
CONFIG_IO_STRICT_DEVMEM=y

My kernel config is based upon Debian's and in commit
ef7e196951aa ("[arm*,powerpc*,s390x,x86] Enable IO_STRICT_DEVMEM")

I found "can be reverted using the kernel parameter: iomem=relaxed", so
I added that parameter and rebooted:

```sh
root@pt2-scmi:~# echo 'just (re-)booted into my PineTab2; screen is blank'
just (re-)booted into my PineTab2; screen is blank
root@pt2-scmi:~# uname -a
Linux pt2-scmi 6.14.0-rc1-00001-gfbe17d9b77b0 #18 SMP Mon Jun  9 13:17:28 CEST 2025 aarch64 GNU/Linux
root@pt2-scmi:~# cat /proc/cmdline 
root=UUID=42bbb627-189b-49e3-ae42-699815dc2cbb ignore_loglevel ro rootwait earlycon console=tty0 console=ttyS2,1500000n8 fw_devlink=off iomem=relaxed
root@pt2-scmi:~# ./andy-io -r -4 -l 0x100 0xfe040d00
fe040d00:  0000000f 00000000 00000000 00000000
fe040d10:  00000010 00000000 00000000 00000000
fe040d20:  00000000 00000000 00000000 00000000
fe040d30:  01b70010 00500370 00100510 10001000
fe040d40:  00000000 00000000 03b00010 00500370
fe040d50:  05120004 00100510 00000000 00000000
fe040d60:  00000000 00000000 00000000 00000000
fe040d70:  00000000 00000000 00000000 00000000
fe040d80:  15110903 00030911 1a150b04 00040b15
fe040d90:  15110903 00030911 00000000 00000000
fe040da0:  00000000 00000000 00000000 00000000
fe040db0:  00000000 00000000 00000000 00000000
fe040dc0:  00000000 00000000 00000000 00000000
fe040dd0:  00000000 00000000 00000000 00000000
fe040de0:  00000000 00000000 00000000 00000000
fe040df0:  00000000 00000000 00000000 00000000
root@pt2-scmi:~# ./andy-io -w -4 0xfe040d00 0x10000
root@pt2-scmi:~# echo 'screen just turned on \o/'
screen just turned on \o/
root@pt2-scmi:~# ./andy-io -r -4 -l 0x100 0xfe040d00
fe040d00:  00010000 00000000 00000000 00000000
fe040d10:  00000010 00000000 00000000 00000000
fe040d20:  00000000 00000000 00000000 00000000
fe040d30:  01b70010 00500370 00100510 10001000
fe040d40:  00000000 00000000 03b00010 00500370
fe040d50:  05120004 00100510 00000000 00000000
fe040d60:  00000000 00000000 00000000 00000000
fe040d70:  00000000 00000000 00000000 00000000
fe040d80:  15110903 00030911 1a150b04 00040b15
fe040d90:  15110903 00030911 00000000 00000000
fe040da0:  00000000 00000000 00000000 00000000
fe040db0:  00000000 00000000 00000000 00000000
fe040dc0:  00000000 00000000 00000000 00000000
fe040dd0:  00000000 00000000 00000000 00000000
fe040de0:  00000000 00000000 00000000 00000000
fe040df0:  00000000 00000000 00000000 00000000
root@pt2-scmi:~# ./andy-io -w -4 0xfe040000 0x28002
root@pt2-scmi:~# echo "screen is still on ... don't see any changes on screen"
screen is still on ... don't see any changes on screen
root@pt2-scmi:~# ./andy-io -r -4 -l 0x100 0xfe040d00
fe040d00:  00010000 00000000 00000000 00000000
fe040d10:  00000010 00000000 00000000 00000000
fe040d20:  00000000 00000000 00000000 00000000
fe040d30:  01b70010 00500370 00100510 10001000
fe040d40:  00000000 00000000 03b00010 00500370
fe040d50:  05120004 00100510 00000000 00000000
fe040d60:  00000000 00000000 00000000 00000000
fe040d70:  00000000 00000000 00000000 00000000
fe040d80:  15110903 00030911 1a150b04 00040b15
fe040d90:  15110903 00030911 00000000 00000000
fe040da0:  00000000 00000000 00000000 00000000
fe040db0:  00000000 00000000 00000000 00000000
fe040dc0:  00000000 00000000 00000000 00000000
fe040dd0:  00000000 00000000 00000000 00000000
fe040de0:  00000000 00000000 00000000 00000000
fe040df0:  00000000 00000000 00000000 00000000
```

For completeness, I then closed the lid and opened it again:

```sh
root@pt2-scmi:~# dmesg | grep "vop2_"
[    5.128785] rockchip-drm display-subsystem: bound fe040000.vop (ops vop2_crtc_atomic_try_set_gamma.part.0 [rockchipdrm])
[    5.138031] rockchip-drm display-subsystem: bound fe0a0000.hdmi (ops vop2_crtc_atomic_try_set_gamma.part.0 [rockchipdrm])
[    5.139641] rockchip-drm display-subsystem: bound fe060000.dsi (ops vop2_crtc_atomic_try_set_gamma.part.0 [rockchipdrm])
[    5.160937] vop2_crtc_atomic_try_set_gamma  gamma_lut: 0000000000000000
[    5.160950] vop2_vp_dsp_lut_disable dsp_ctrl: 0x0000000f
[ 1931.879232] vop2_crtc_atomic_try_set_gamma  gamma_lut: 0000000000000000
[ 1931.879245] vop2_vp_dsp_lut_disable dsp_ctrl: 0x00010000
```

Cheers,
  Diederik

>>> [   73.750524] vop2_crtc_atomic_try_set_gamma  gamma_lut: 0000000000000000
>>> [   73.750542] vop2_vp_dsp_lut_disable dsp_ctrl: 0x00010000
>>>>>>>>> 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 built a kernel with 6.14-rc1 + this patch and can confirm the screen
>>>>>>>>has output again :-)
>>>>>>>>
>>>>>>>>> I will wait with sending a patch because maybe Andy has something to add 
>>>>>>>>> to this.
>>>>>>>>
>>>>>>>>Sounds like a plan. It could be that this issue surfaced an underlaying
>>>>>>>>issue and if so, fixing that would be even better.


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

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

[Andy Yan]

Hi Diederik,
At 2025-06-11 18:56:31, "Diederik de Haas" <didi.debian@cknow.org> wrote:
>Hi Andy,
>
>On Wed Jun 11, 2025 at 9:41 AM CEST, Andy Yan wrote:
>> At 2025-06-10 19:02:11, "Diederik de Haas" <didi.debian@cknow.org> wrote:
>>>On Tue Jun 10, 2025 at 11:07 AM CEST, Andy Yan wrote:
>>>> At 2025-06-09 20:36:41, "Diederik de Haas" <didi.debian@cknow.org> wrote:
>>>>>On Mon Jun 9, 2025 at 11:15 AM CEST, Andy Yan wrote:
>>>>>> At 2025-06-08 20:53:37, "Diederik de Haas" <didi.debian@cknow.org> wrote:
>>>>>>>On Sun Jun 8, 2025 at 2:10 PM CEST, Andy Yan wrote:
>>>>>>>> At 2025-06-08 19:08:50, "Diederik de Haas" <didi.debian@cknow.org> wrote:
>>>>>>>>>On Sat Jun 7, 2025 at 5:32 PM CEST, Piotr Zalewski wrote:
>>>>>>>>>> On Thursday, June 5th, 2025 at 10:13 PM, Diederik de Haas <didi.debian@cknow.org> wrote:
>>>>>>>>>>> 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
>>>>>>>>
>>>>>>>> I have conducted tests on both rk3566-box-demo (with drm set to y)
>>>>>>>> and rk3568-lubancat-2 (with drm set to m), but I was unable to
>>>>>>>> reproduce this issue. Could you two please share your kernel
>>>>>>>> defconfig and the corresponding kernel startup logs?
>>>>>>>> Additionally, both of my two boards tested with HDMI output. What
>>>>>>>> kind of display interface does your board use for output?
>>>>>>>
>>>>>>>I wasn't able to reproduce this issue on my PINE64 Quartz-B (rk3566) 
>>>>>>>with HDMI output either, but the problem is present on a PineTab2 [1]
>>>>>>>(also rk3566) which uses a MIPI DSI connection to the display panel.
>>>>>>>
>>>>>>>Kernel config:
>>>>>>>https://paste.sr.ht/~diederik/aa747ed170aa01cc759fbe1ffd9cebe8c887b10b
>>>>>>>
>>>>>>>dmesg kernel 6.14-rc1:
>>>>>>>https://paste.sr.ht/~diederik/733fbf8bb7f6aee8b68cf5a652157d445462c24a
>>>>>>>
>>>>>>>dmesg kernel 6.14-rc1 with Piotr's patch:
>>>>>>>https://paste.sr.ht/~diederik/db1af672cfb611acbfbdf35adb6f170e5c38febc
>>>>>>>
>>>>>>>Both dmesg outputs contain a suspend-resume cycle.
>>>>>>>I'm using a USB Wi-Fi adapter for the wireless connection.
>>>>>>>
>>>>>>>[1] https://wiki.pine64.org/wiki/PineTab2
>>>>>>>
>>>>>>>Happy to provide more info and/or do some tests.
>>>>>>
>>>>>> Can you apply the patch in the attachment, reproduce this issue(without Piotr's patch), 
>>>>>> and then provide me with a copy of the kernel log?
>>>>>
>>>>>Same test as above, but added ``dmesg | grep "vop2_"`` at the end as well
>>>>>
>>>>>dmesg kernel 6.14-rc1 with Andy's print_lut_0609_1710 patch:
>>>>>https://paste.sr.ht/~diederik/ac356ee8b0f7e772c7310293d99d95644f59a4ee
>>>>
>>>> root@pt2-scmi:~# dmesg | grep "vop2_"
>>>> [    4.996281] rockchip-drm display-subsystem: bound fe040000.vop (ops vop2_crtc_atomic_try_set_gamma.part.0 [rockchipdrm])
>>>> [    5.005207] rockchip-drm display-subsystem: bound fe0a0000.hdmi (ops vop2_crtc_atomic_try_set_gamma.part.0 [rockchipdrm])
>>>> [    5.006798] rockchip-drm display-subsystem: bound fe060000.dsi (ops vop2_crtc_atomic_try_set_gamma.part.0 [rockchipdrm])
>>>> [    5.021204] vop2_crtc_atomic_try_set_gamma  gamma_lut: 0000000000000000
>>>> [    5.021219] vop2_vp_dsp_lut_disable dsp_ctrl: 0x0000000f
>>>>
>>>> It seems that dsp_ctrl: 0x0000000f , this value is not what we expected.
>>>>
>>>> The expected is 0x00010000.
>>>>
>>>> Could you please do an experiment for me? When there is no display on your screen, 
>>>> execute the following command and see if the screen can resume displaying:
>>>>
>>>> ./data/io  -w -4 0xfe040d00 0x10000; io -w -4 0xfe040000 0x28002 
>>>>
>>>> I have placed the io tool in the attachment.
>>>>
>>>> You can use command like bellow to read back to confirm if what you write has taken effect:
>>>> io -r -4 -l 0x100  0xfe040d00 
>>>>
>>>> you may need to make CONFIG_DEVMEM=y so that you can write the register by io command.
>>>
>>>I renamed it as ``andy-io`` and performed the test:
>>>
>>>```sh
>>>root@pt2-scmi:~# echo 'just (re-)booted into my PineTab2; screen is blank'
>>>just (re-)booted into my PineTab2; screen is blank
>>>root@pt2-scmi:~# uname -a
>>>Linux pt2-scmi 6.14.0-rc1-00001-gfbe17d9b77b0 #18 SMP Mon Jun  9 13:17:28 CEST 2025 aarch64 GNU/Linux
>>>root@pt2-scmi:~# ./andy-io -r -4 -l 0x100 0xfe040d00
>>>mmap() failed: Operation not permitted
>>>root@pt2-scmi:~# grep CONFIG_DEVMEM /boot/config-6.14.0-rc1-00001-gfbe17d9b77b0
>>>CONFIG_DEVMEM=y
>>>root@pt2-scmi:~# ./andy-io -w -4 0xfe040d00 0x10000
>>>mmap() failed: Operation not permitted
>>>root@pt2-scmi:~# ./andy-io -w -4 0xfe040000 0x28002
>>>mmap() failed: Operation not permitted
>>>```
>>
>> This is my config about DEVMEM:
>>
>> ~/WorkSpace/linux-next$ rg DEVMEM .config
>> 1014:CONFIG_NET_DEVMEM=y
>> 3069:CONFIG_DEVMEM=y
>> 7280:CONFIG_GENERIC_LIB_DEVMEM_IS_ALLOWED=y
>> 7542:CONFIG_STRICT_DEVMEM=y
>> 7543:# CONFIG_IO_STRICT_DEVMEM is not set
>>
>> CONFIG_IO_STRICT_DEVMEM should not be set to y if you want to access an IO address from usersapce.
>
>That last one seems to be the culprit:
>
>root@pt2-scmi:~# grep DEVMEM /boot/config-6.14.0-rc1-00001-gfbe17d9b77b0
>CONFIG_NET_DEVMEM=y
>CONFIG_DEVMEM=y
>CONFIG_GENERIC_LIB_DEVMEM_IS_ALLOWED=y
>CONFIG_STRICT_DEVMEM=y
>CONFIG_IO_STRICT_DEVMEM=y
>
>My kernel config is based upon Debian's and in commit
>ef7e196951aa ("[arm*,powerpc*,s390x,x86] Enable IO_STRICT_DEVMEM")
>
>I found "can be reverted using the kernel parameter: iomem=relaxed", so
>I added that parameter and rebooted:
>
>```sh
>root@pt2-scmi:~# echo 'just (re-)booted into my PineTab2; screen is blank'
>just (re-)booted into my PineTab2; screen is blank
>root@pt2-scmi:~# uname -a
>Linux pt2-scmi 6.14.0-rc1-00001-gfbe17d9b77b0 #18 SMP Mon Jun  9 13:17:28 CEST 2025 aarch64 GNU/Linux
>root@pt2-scmi:~# cat /proc/cmdline 
>root=UUID=42bbb627-189b-49e3-ae42-699815dc2cbb ignore_loglevel ro rootwait earlycon console=tty0 console=ttyS2,1500000n8 fw_devlink=off iomem=relaxed
>root@pt2-scmi:~# ./andy-io -r -4 -l 0x100 0xfe040d00
>fe040d00:  0000000f 00000000 00000000 00000000
>fe040d10:  00000010 00000000 00000000 00000000
>fe040d20:  00000000 00000000 00000000 00000000
>fe040d30:  01b70010 00500370 00100510 10001000
>fe040d40:  00000000 00000000 03b00010 00500370
>fe040d50:  05120004 00100510 00000000 00000000
>fe040d60:  00000000 00000000 00000000 00000000
>fe040d70:  00000000 00000000 00000000 00000000
>fe040d80:  15110903 00030911 1a150b04 00040b15
>fe040d90:  15110903 00030911 00000000 00000000
>fe040da0:  00000000 00000000 00000000 00000000
>fe040db0:  00000000 00000000 00000000 00000000
>fe040dc0:  00000000 00000000 00000000 00000000
>fe040dd0:  00000000 00000000 00000000 00000000
>fe040de0:  00000000 00000000 00000000 00000000
>fe040df0:  00000000 00000000 00000000 00000000
>root@pt2-scmi:~# ./andy-io -w -4 0xfe040d00 0x10000
>root@pt2-scmi:~# echo 'screen just turned on \o/'
>screen just turned on \o/


Do you mean the screen is turned on(that you see the display on the screen) here ?




> root@pt2-scmi:~# ./andy-io -r -4 -l 0x100 0xfe040d00
>fe040d00:  00010000 00000000 00000000 00000000
>fe040d10:  00000010 00000000 00000000 00000000
>fe040d20:  00000000 00000000 00000000 00000000
>fe040d30:  01b70010 00500370 00100510 10001000
>fe040d40:  00000000 00000000 03b00010 00500370
>fe040d50:  05120004 00100510 00000000 00000000
>fe040d60:  00000000 00000000 00000000 00000000
>fe040d70:  00000000 00000000 00000000 00000000
>fe040d80:  15110903 00030911 1a150b04 00040b15
>fe040d90:  15110903 00030911 00000000 00000000
>fe040da0:  00000000 00000000 00000000 00000000
>fe040db0:  00000000 00000000 00000000 00000000
>fe040dc0:  00000000 00000000 00000000 00000000
>fe040dd0:  00000000 00000000 00000000 00000000
>fe040de0:  00000000 00000000 00000000 00000000
>fe040df0:  00000000 00000000 00000000 00000000
>root@pt2-scmi:~# ./andy-io -w -4 0xfe040000 0x28002
>root@pt2-scmi:~# echo "screen is still on ... don't see any changes on screen"
>screen is still on ... don't see any changes on screen
>root@pt2-scmi:~# ./andy-io -r -4 -l 0x100 0xfe040d00
>fe040d00:  00010000 00000000 00000000 00000000
>fe040d10:  00000010 00000000 00000000 00000000
>fe040d20:  00000000 00000000 00000000 00000000
>fe040d30:  01b70010 00500370 00100510 10001000
>fe040d40:  00000000 00000000 03b00010 00500370
>fe040d50:  05120004 00100510 00000000 00000000
>fe040d60:  00000000 00000000 00000000 00000000
>fe040d70:  00000000 00000000 00000000 00000000
>fe040d80:  15110903 00030911 1a150b04 00040b15
>fe040d90:  15110903 00030911 00000000 00000000
>fe040da0:  00000000 00000000 00000000 00000000
>fe040db0:  00000000 00000000 00000000 00000000
>fe040dc0:  00000000 00000000 00000000 00000000
>fe040dd0:  00000000 00000000 00000000 00000000
>fe040de0:  00000000 00000000 00000000 00000000
>fe040df0:  00000000 00000000 00000000 00000000
>```
>
>For completeness, I then closed the lid and opened it again:
>
>```sh
>root@pt2-scmi:~# dmesg | grep "vop2_"
>[    5.128785] rockchip-drm display-subsystem: bound fe040000.vop (ops vop2_crtc_atomic_try_set_gamma.part.0 [rockchipdrm])
>[    5.138031] rockchip-drm display-subsystem: bound fe0a0000.hdmi (ops vop2_crtc_atomic_try_set_gamma.part.0 [rockchipdrm])
>[    5.139641] rockchip-drm display-subsystem: bound fe060000.dsi (ops vop2_crtc_atomic_try_set_gamma.part.0 [rockchipdrm])
>[    5.160937] vop2_crtc_atomic_try_set_gamma  gamma_lut: 0000000000000000
>[    5.160950] vop2_vp_dsp_lut_disable dsp_ctrl: 0x0000000f
>[ 1931.879232] vop2_crtc_atomic_try_set_gamma  gamma_lut: 0000000000000000
>[ 1931.879245] vop2_vp_dsp_lut_disable dsp_ctrl: 0x00010000
>```
>
>Cheers,
>  Diederik
>
>>>> [   73.750524] vop2_crtc_atomic_try_set_gamma  gamma_lut: 0000000000000000
>>>> [   73.750542] vop2_vp_dsp_lut_disable dsp_ctrl: 0x00010000
>>>>>>>>>> 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 built a kernel with 6.14-rc1 + this patch and can confirm the screen
>>>>>>>>>has output again :-)
>>>>>>>>>
>>>>>>>>>> I will wait with sending a patch because maybe Andy has something to add 
>>>>>>>>>> to this.
>>>>>>>>>
>>>>>>>>>Sounds like a plan. It could be that this issue surfaced an underlaying
>>>>>>>>>issue and if so, fixing that would be even better.
>

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

[Diederik de Haas]

[-- Attachment #1: Type: text/plain, Size: 10596 bytes --]

Hi,

On Wed Jun 11, 2025 at 2:15 PM CEST, Andy Yan wrote:
> At 2025-06-11 18:56:31, "Diederik de Haas" <didi.debian@cknow.org> wrote:
>>On Wed Jun 11, 2025 at 9:41 AM CEST, Andy Yan wrote:
>>> At 2025-06-10 19:02:11, "Diederik de Haas" <didi.debian@cknow.org> wrote:
>>>>On Tue Jun 10, 2025 at 11:07 AM CEST, Andy Yan wrote:
>>>>> At 2025-06-09 20:36:41, "Diederik de Haas" <didi.debian@cknow.org> wrote:
>>>>>>On Mon Jun 9, 2025 at 11:15 AM CEST, Andy Yan wrote:
>>>>>>> At 2025-06-08 20:53:37, "Diederik de Haas" <didi.debian@cknow.org> wrote:
>>>>>>>>On Sun Jun 8, 2025 at 2:10 PM CEST, Andy Yan wrote:
>>>>>>>>> At 2025-06-08 19:08:50, "Diederik de Haas" <didi.debian@cknow.org> wrote:
>>>>>>>>>>On Sat Jun 7, 2025 at 5:32 PM CEST, Piotr Zalewski wrote:
>>>>>>>>>>> On Thursday, June 5th, 2025 at 10:13 PM, Diederik de Haas <didi.debian@cknow.org> wrote:
>>>>>>>>>>>> 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
>>>>>>>>>
>>>>>>>>> I have conducted tests on both rk3566-box-demo (with drm set to y)
>>>>>>>>> and rk3568-lubancat-2 (with drm set to m), but I was unable to
>>>>>>>>> reproduce this issue. Could you two please share your kernel
>>>>>>>>> defconfig and the corresponding kernel startup logs?
>>>>>>>>> Additionally, both of my two boards tested with HDMI output. What
>>>>>>>>> kind of display interface does your board use for output?
>>>>>>>>
>>>>>>>>I wasn't able to reproduce this issue on my PINE64 Quartz-B (rk3566) 
>>>>>>>>with HDMI output either, but the problem is present on a PineTab2 [1]
>>>>>>>>(also rk3566) which uses a MIPI DSI connection to the display panel.
>>>>>>>>
>>>>>>>>Kernel config:
>>>>>>>>https://paste.sr.ht/~diederik/aa747ed170aa01cc759fbe1ffd9cebe8c887b10b
>>>>>>>>
>>>>>>>>dmesg kernel 6.14-rc1:
>>>>>>>>https://paste.sr.ht/~diederik/733fbf8bb7f6aee8b68cf5a652157d445462c24a
>>>>>>>>
>>>>>>>>dmesg kernel 6.14-rc1 with Piotr's patch:
>>>>>>>>https://paste.sr.ht/~diederik/db1af672cfb611acbfbdf35adb6f170e5c38febc
>>>>>>>>
>>>>>>>>Both dmesg outputs contain a suspend-resume cycle.
>>>>>>>>I'm using a USB Wi-Fi adapter for the wireless connection.
>>>>>>>>
>>>>>>>>[1] https://wiki.pine64.org/wiki/PineTab2
>>>>>>>>
>>>>>>>>Happy to provide more info and/or do some tests.
>>>>>>>
>>>>>>> Can you apply the patch in the attachment, reproduce this issue(without Piotr's patch), 
>>>>>>> and then provide me with a copy of the kernel log?
>>>>>>
>>>>>>Same test as above, but added ``dmesg | grep "vop2_"`` at the end as well
>>>>>>
>>>>>>dmesg kernel 6.14-rc1 with Andy's print_lut_0609_1710 patch:
>>>>>>https://paste.sr.ht/~diederik/ac356ee8b0f7e772c7310293d99d95644f59a4ee
>>>>>
>>>>> root@pt2-scmi:~# dmesg | grep "vop2_"
>>>>> [    4.996281] rockchip-drm display-subsystem: bound fe040000.vop (ops vop2_crtc_atomic_try_set_gamma.part.0 [rockchipdrm])
>>>>> [    5.005207] rockchip-drm display-subsystem: bound fe0a0000.hdmi (ops vop2_crtc_atomic_try_set_gamma.part.0 [rockchipdrm])
>>>>> [    5.006798] rockchip-drm display-subsystem: bound fe060000.dsi (ops vop2_crtc_atomic_try_set_gamma.part.0 [rockchipdrm])
>>>>> [    5.021204] vop2_crtc_atomic_try_set_gamma  gamma_lut: 0000000000000000
>>>>> [    5.021219] vop2_vp_dsp_lut_disable dsp_ctrl: 0x0000000f
>>>>>
>>>>> It seems that dsp_ctrl: 0x0000000f , this value is not what we expected.
>>>>>
>>>>> The expected is 0x00010000.
>>>>>
>>>>> Could you please do an experiment for me? When there is no display on your screen, 
>>>>> execute the following command and see if the screen can resume displaying:
>>>>>
>>>>> ./data/io  -w -4 0xfe040d00 0x10000; io -w -4 0xfe040000 0x28002 
>>>>>
>>>>> I have placed the io tool in the attachment.
>>>>>
>>>>> You can use command like bellow to read back to confirm if what you write has taken effect:
>>>>> io -r -4 -l 0x100  0xfe040d00 
>>>>>
>>>>> you may need to make CONFIG_DEVMEM=y so that you can write the register by io command.
>>>>
>>>>I renamed it as ``andy-io`` and performed the test:
>>>>
>>> 7543:# CONFIG_IO_STRICT_DEVMEM is not set
>>>
>>> CONFIG_IO_STRICT_DEVMEM should not be set to y if you want to access an IO address from usersapce.
>>
>>That last one seems to be the culprit:
>>
>>My kernel config is based upon Debian's and in commit
>>ef7e196951aa ("[arm*,powerpc*,s390x,x86] Enable IO_STRICT_DEVMEM")
>>
>>I found "can be reverted using the kernel parameter: iomem=relaxed", so
>>I added that parameter and rebooted:
>>
>>```sh
>>root@pt2-scmi:~# echo 'just (re-)booted into my PineTab2; screen is blank'
>>just (re-)booted into my PineTab2; screen is blank
>>root@pt2-scmi:~# uname -a
>>Linux pt2-scmi 6.14.0-rc1-00001-gfbe17d9b77b0 #18 SMP Mon Jun  9 13:17:28 CEST 2025 aarch64 GNU/Linux
>>root@pt2-scmi:~# cat /proc/cmdline 
>>root=UUID=42bbb627-189b-49e3-ae42-699815dc2cbb ignore_loglevel ro rootwait earlycon console=tty0 console=ttyS2,1500000n8 fw_devlink=off iomem=relaxed
>>root@pt2-scmi:~# ./andy-io -r -4 -l 0x100 0xfe040d00
>>fe040d00:  0000000f 00000000 00000000 00000000
>>fe040d10:  00000010 00000000 00000000 00000000
>>fe040d20:  00000000 00000000 00000000 00000000
>>fe040d30:  01b70010 00500370 00100510 10001000
>>fe040d40:  00000000 00000000 03b00010 00500370
>>fe040d50:  05120004 00100510 00000000 00000000
>>fe040d60:  00000000 00000000 00000000 00000000
>>fe040d70:  00000000 00000000 00000000 00000000
>>fe040d80:  15110903 00030911 1a150b04 00040b15
>>fe040d90:  15110903 00030911 00000000 00000000
>>fe040da0:  00000000 00000000 00000000 00000000
>>fe040db0:  00000000 00000000 00000000 00000000
>>fe040dc0:  00000000 00000000 00000000 00000000
>>fe040dd0:  00000000 00000000 00000000 00000000
>>fe040de0:  00000000 00000000 00000000 00000000
>>fe040df0:  00000000 00000000 00000000 00000000
>>root@pt2-scmi:~# ./andy-io -w -4 0xfe040d00 0x10000
>>root@pt2-scmi:~# echo 'screen just turned on \o/'
>>screen just turned on \o/
>
> Do you mean the screen is turned on(that you see the display on the screen) here ?

Yep. Before the ``-w`` command the screen was blank/black and after the
``-w`` command the (sway based) login screen was visible.

>> root@pt2-scmi:~# ./andy-io -r -4 -l 0x100 0xfe040d00
>>fe040d00:  00010000 00000000 00000000 00000000
>>fe040d10:  00000010 00000000 00000000 00000000
>>fe040d20:  00000000 00000000 00000000 00000000
>>fe040d30:  01b70010 00500370 00100510 10001000
>>fe040d40:  00000000 00000000 03b00010 00500370
>>fe040d50:  05120004 00100510 00000000 00000000
>>fe040d60:  00000000 00000000 00000000 00000000
>>fe040d70:  00000000 00000000 00000000 00000000
>>fe040d80:  15110903 00030911 1a150b04 00040b15
>>fe040d90:  15110903 00030911 00000000 00000000
>>fe040da0:  00000000 00000000 00000000 00000000
>>fe040db0:  00000000 00000000 00000000 00000000
>>fe040dc0:  00000000 00000000 00000000 00000000
>>fe040dd0:  00000000 00000000 00000000 00000000
>>fe040de0:  00000000 00000000 00000000 00000000
>>fe040df0:  00000000 00000000 00000000 00000000
>>root@pt2-scmi:~# ./andy-io -w -4 0xfe040000 0x28002
>>root@pt2-scmi:~# echo "screen is still on ... don't see any changes on screen"
>>screen is still on ... don't see any changes on screen
>>root@pt2-scmi:~# ./andy-io -r -4 -l 0x100 0xfe040d00
>>fe040d00:  00010000 00000000 00000000 00000000
>>fe040d10:  00000010 00000000 00000000 00000000
>>fe040d20:  00000000 00000000 00000000 00000000
>>fe040d30:  01b70010 00500370 00100510 10001000
>>fe040d40:  00000000 00000000 03b00010 00500370
>>fe040d50:  05120004 00100510 00000000 00000000
>>fe040d60:  00000000 00000000 00000000 00000000
>>fe040d70:  00000000 00000000 00000000 00000000
>>fe040d80:  15110903 00030911 1a150b04 00040b15
>>fe040d90:  15110903 00030911 00000000 00000000
>>fe040da0:  00000000 00000000 00000000 00000000
>>fe040db0:  00000000 00000000 00000000 00000000
>>fe040dc0:  00000000 00000000 00000000 00000000
>>fe040dd0:  00000000 00000000 00000000 00000000
>>fe040de0:  00000000 00000000 00000000 00000000
>>fe040df0:  00000000 00000000 00000000 00000000
>>```
>>
>>For completeness, I then closed the lid and opened it again:
>>
>>```sh
>>root@pt2-scmi:~# dmesg | grep "vop2_"
>>[    5.128785] rockchip-drm display-subsystem: bound fe040000.vop (ops vop2_crtc_atomic_try_set_gamma.part.0 [rockchipdrm])
>>[    5.138031] rockchip-drm display-subsystem: bound fe0a0000.hdmi (ops vop2_crtc_atomic_try_set_gamma.part.0 [rockchipdrm])
>>[    5.139641] rockchip-drm display-subsystem: bound fe060000.dsi (ops vop2_crtc_atomic_try_set_gamma.part.0 [rockchipdrm])
>>[    5.160937] vop2_crtc_atomic_try_set_gamma  gamma_lut: 0000000000000000
>>[    5.160950] vop2_vp_dsp_lut_disable dsp_ctrl: 0x0000000f
>>[ 1931.879232] vop2_crtc_atomic_try_set_gamma  gamma_lut: 0000000000000000
>>[ 1931.879245] vop2_vp_dsp_lut_disable dsp_ctrl: 0x00010000
>>```
>>
>>Cheers,
>>  Diederik
>>
>>>>> [   73.750524] vop2_crtc_atomic_try_set_gamma  gamma_lut: 0000000000000000
>>>>> [   73.750542] vop2_vp_dsp_lut_disable dsp_ctrl: 0x00010000
>>>>>>>>>>> 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 built a kernel with 6.14-rc1 + this patch and can confirm the screen
>>>>>>>>>>has output again :-)
>>>>>>>>>>
>>>>>>>>>>> I will wait with sending a patch because maybe Andy has something to add 
>>>>>>>>>>> to this.
>>>>>>>>>>
>>>>>>>>>>Sounds like a plan. It could be that this issue surfaced an underlaying
>>>>>>>>>>issue and if so, fixing that would be even better.
>>


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

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

[Andy Yan]

Hi Deiderik and Piotr,

At 2025-06-11 20:26:38, "Diederik de Haas" <didi.debian@cknow.org> wrote:
>Hi,
>
>On Wed Jun 11, 2025 at 2:15 PM CEST, Andy Yan wrote:
>> At 2025-06-11 18:56:31, "Diederik de Haas" <didi.debian@cknow.org> wrote:
>>>On Wed Jun 11, 2025 at 9:41 AM CEST, Andy Yan wrote:
>>>> At 2025-06-10 19:02:11, "Diederik de Haas" <didi.debian@cknow.org> wrote:
>>>>>On Tue Jun 10, 2025 at 11:07 AM CEST, Andy Yan wrote:
>>>>>> At 2025-06-09 20:36:41, "Diederik de Haas" <didi.debian@cknow.org> wrote:
>>>>>>>On Mon Jun 9, 2025 at 11:15 AM CEST, Andy Yan wrote:
>>>>>>>> At 2025-06-08 20:53:37, "Diederik de Haas" <didi.debian@cknow.org> wrote:
>>>>>>>>>On Sun Jun 8, 2025 at 2:10 PM CEST, Andy Yan wrote:
>>>>>>>>>> At 2025-06-08 19:08:50, "Diederik de Haas" <didi.debian@cknow.org> wrote:
>>>>>>>>>>>On Sat Jun 7, 2025 at 5:32 PM CEST, Piotr Zalewski wrote:
>>>>>>>>>>>> On Thursday, June 5th, 2025 at 10:13 PM, Diederik de Haas <didi.debian@cknow.org> wrote:
>>>>>>>>>>>>> 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
>>>>>>>>>>
>>>>>>>>>> I have conducted tests on both rk3566-box-demo (with drm set to y)
>>>>>>>>>> and rk3568-lubancat-2 (with drm set to m), but I was unable to
>>>>>>>>>> reproduce this issue. Could you two please share your kernel
>>>>>>>>>> defconfig and the corresponding kernel startup logs?
>>>>>>>>>> Additionally, both of my two boards tested with HDMI output. What
>>>>>>>>>> kind of display interface does your board use for output?
>>>>>>>>>
>>>>>>>>>I wasn't able to reproduce this issue on my PINE64 Quartz-B (rk3566) 
>>>>>>>>>with HDMI output either, but the problem is present on a PineTab2 [1]
>>>>>>>>>(also rk3566) which uses a MIPI DSI connection to the display panel.
>>>>>>>>>
>>>>>>>>>Kernel config:
>>>>>>>>>https://paste.sr.ht/~diederik/aa747ed170aa01cc759fbe1ffd9cebe8c887b10b
>>>>>>>>>
>>>>>>>>>dmesg kernel 6.14-rc1:
>>>>>>>>>https://paste.sr.ht/~diederik/733fbf8bb7f6aee8b68cf5a652157d445462c24a
>>>>>>>>>
>>>>>>>>>dmesg kernel 6.14-rc1 with Piotr's patch:
>>>>>>>>>https://paste.sr.ht/~diederik/db1af672cfb611acbfbdf35adb6f170e5c38febc
>>>>>>>>>
>>>>>>>>>Both dmesg outputs contain a suspend-resume cycle.
>>>>>>>>>I'm using a USB Wi-Fi adapter for the wireless connection.
>>>>>>>>>
>>>>>>>>>[1] https://wiki.pine64.org/wiki/PineTab2
>>>>>>>>>
>>>>>>>>>Happy to provide more info and/or do some tests.
>>>>>>>>
>>>>>>>> Can you apply the patch in the attachment, reproduce this issue(without Piotr's patch), 
>>>>>>>> and then provide me with a copy of the kernel log?
>>>>>>>
>>>>>>>Same test as above, but added ``dmesg | grep "vop2_"`` at the end as well
>>>>>>>
>>>>>>>dmesg kernel 6.14-rc1 with Andy's print_lut_0609_1710 patch:
>>>>>>>https://paste.sr.ht/~diederik/ac356ee8b0f7e772c7310293d99d95644f59a4ee
>>>>>>
>>>>>> root@pt2-scmi:~# dmesg | grep "vop2_"
>>>>>> [    4.996281] rockchip-drm display-subsystem: bound fe040000.vop (ops vop2_crtc_atomic_try_set_gamma.part.0 [rockchipdrm])
>>>>>> [    5.005207] rockchip-drm display-subsystem: bound fe0a0000.hdmi (ops vop2_crtc_atomic_try_set_gamma.part.0 [rockchipdrm])
>>>>>> [    5.006798] rockchip-drm display-subsystem: bound fe060000.dsi (ops vop2_crtc_atomic_try_set_gamma.part.0 [rockchipdrm])
>>>>>> [    5.021204] vop2_crtc_atomic_try_set_gamma  gamma_lut: 0000000000000000
>>>>>> [    5.021219] vop2_vp_dsp_lut_disable dsp_ctrl: 0x0000000f
>>>>>>
>>>>>> It seems that dsp_ctrl: 0x0000000f , this value is not what we expected.
>>>>>>
>>>>>> The expected is 0x00010000.
>>>>>>
>>>>>> Could you please do an experiment for me? When there is no display on your screen, 
>>>>>> execute the following command and see if the screen can resume displaying:
>>>>>>
>>>>>> ./data/io  -w -4 0xfe040d00 0x10000; io -w -4 0xfe040000 0x28002 
>>>>>>
>>>>>> I have placed the io tool in the attachment.
>>>>>>
>>>>>> You can use command like bellow to read back to confirm if what you write has taken effect:
>>>>>> io -r -4 -l 0x100  0xfe040d00 
>>>>>>
>>>>>> you may need to make CONFIG_DEVMEM=y so that you can write the register by io command.
>>>>>
>>>>>I renamed it as ``andy-io`` and performed the test:
>>>>>
>>>> 7543:# CONFIG_IO_STRICT_DEVMEM is not set
>>>>
>>>> CONFIG_IO_STRICT_DEVMEM should not be set to y if you want to access an IO address from usersapce.
>>>
>>>That last one seems to be the culprit:
>>>
>>>My kernel config is based upon Debian's and in commit
>>>ef7e196951aa ("[arm*,powerpc*,s390x,x86] Enable IO_STRICT_DEVMEM")
>>>
>>>I found "can be reverted using the kernel parameter: iomem=relaxed", so
>>>I added that parameter and rebooted:
>>>
>>>```sh
>>>root@pt2-scmi:~# echo 'just (re-)booted into my PineTab2; screen is blank'
>>>just (re-)booted into my PineTab2; screen is blank
>>>root@pt2-scmi:~# uname -a
>>>Linux pt2-scmi 6.14.0-rc1-00001-gfbe17d9b77b0 #18 SMP Mon Jun  9 13:17:28 CEST 2025 aarch64 GNU/Linux
>>>root@pt2-scmi:~# cat /proc/cmdline 
>>>root=UUID=42bbb627-189b-49e3-ae42-699815dc2cbb ignore_loglevel ro rootwait earlycon console=tty0 console=ttyS2,1500000n8 fw_devlink=off iomem=relaxed
>>>root@pt2-scmi:~# ./andy-io -r -4 -l 0x100 0xfe040d00
>>>fe040d00:  0000000f 00000000 00000000 00000000
>>>fe040d10:  00000010 00000000 00000000 00000000
>>>fe040d20:  00000000 00000000 00000000 00000000
>>>fe040d30:  01b70010 00500370 00100510 10001000
>>>fe040d40:  00000000 00000000 03b00010 00500370
>>>fe040d50:  05120004 00100510 00000000 00000000
>>>fe040d60:  00000000 00000000 00000000 00000000
>>>fe040d70:  00000000 00000000 00000000 00000000
>>>fe040d80:  15110903 00030911 1a150b04 00040b15
>>>fe040d90:  15110903 00030911 00000000 00000000
>>>fe040da0:  00000000 00000000 00000000 00000000
>>>fe040db0:  00000000 00000000 00000000 00000000
>>>fe040dc0:  00000000 00000000 00000000 00000000
>>>fe040dd0:  00000000 00000000 00000000 00000000
>>>fe040de0:  00000000 00000000 00000000 00000000
>>>fe040df0:  00000000 00000000 00000000 00000000
>>>root@pt2-scmi:~# ./andy-io -w -4 0xfe040d00 0x10000
>>>root@pt2-scmi:~# echo 'screen just turned on \o/'
>>>screen just turned on \o/
>>
>> Do you mean the screen is turned on(that you see the display on the screen) here ?
>
>Yep. Before the ``-w`` command the screen was blank/black and after the
>``-w`` command the (sway based) login screen was visible.

The root case for the problem is now clear。

Most of the registers in VOP need to write the cfd_done register(call vop2_cfg_done) 
after you have configured the registers. Then, they will take effect only when the VSYNC event occurs(It doesn't take effect immediately after you finish writing.). 
This also includes all the VP_DSP_CTRL registers.

see the code:

 vop2_vp_write(vp, RK3568_VP_DSP_CTRL, dsp_ctrl);

 vop2_crtc_atomic_try_set_gamma(vop2, vp, crtc, crtc_state);
-->
static void vop2_vp_dsp_lut_disable(struct vop2_video_port *vp)
{
        u32 dsp_ctrl = vop2_vp_read(vp, RK3568_VP_DSP_CTRL);


When we read this register, we are reading the actual effective value, 
not the one(dsp_ctrl) that was just written in before (it has not yet taken effect)

So when we continue to write about this register here, we overwrite the actual
value we originally intended to put in.


        dsp_ctrl &= ~RK3568_VP_DSP_CTRL__DSP_LUT_EN;
        vop2_vp_write(vp, RK3568_VP_DSP_CTRL, dsp_ctrl); 
}

I think the correct solution should be similar to the Windows-related registry settings. 
All the registers related to Video Ports should be set as non-volatile, see:

/*      
 * The window registers are only updated when config done is written.
 * Until that they read back the old value. As we read-modify-write
 * these registers mark them as non-volatile. This makes sure we read
 * the new values from the regmap register cache.
 */     
static const struct regmap_range vop2_nonvolatile_range[] = {
        regmap_reg_range(0x1000, 0x23ff),
};      

static const struct regmap_access_table vop2_volatile_table = {
        .no_ranges = vop2_nonvolatile_range,
        .n_no_ranges = ARRAY_SIZE(vop2_nonvolatile_range),
};     


Actually, there is another question. I still haven't figured out why
this problem doesn't occur when compiling rockchipdrm=y . 


>
>>> root@pt2-scmi:~# ./andy-io -r -4 -l 0x100 0xfe040d00
>>>fe040d00:  00010000 00000000 00000000 00000000
>>>fe040d10:  00000010 00000000 00000000 00000000
>>>fe040d20:  00000000 00000000 00000000 00000000
>>>fe040d30:  01b70010 00500370 00100510 10001000
>>>fe040d40:  00000000 00000000 03b00010 00500370
>>>fe040d50:  05120004 00100510 00000000 00000000
>>>fe040d60:  00000000 00000000 00000000 00000000
>>>fe040d70:  00000000 00000000 00000000 00000000
>>>fe040d80:  15110903 00030911 1a150b04 00040b15
>>>fe040d90:  15110903 00030911 00000000 00000000
>>>fe040da0:  00000000 00000000 00000000 00000000
>>>fe040db0:  00000000 00000000 00000000 00000000
>>>fe040dc0:  00000000 00000000 00000000 00000000
>>>fe040dd0:  00000000 00000000 00000000 00000000
>>>fe040de0:  00000000 00000000 00000000 00000000
>>>fe040df0:  00000000 00000000 00000000 00000000
>>>root@pt2-scmi:~# ./andy-io -w -4 0xfe040000 0x28002
>>>root@pt2-scmi:~# echo "screen is still on ... don't see any changes on screen"
>>>screen is still on ... don't see any changes on screen
>>>root@pt2-scmi:~# ./andy-io -r -4 -l 0x100 0xfe040d00
>>>fe040d00:  00010000 00000000 00000000 00000000
>>>fe040d10:  00000010 00000000 00000000 00000000
>>>fe040d20:  00000000 00000000 00000000 00000000
>>>fe040d30:  01b70010 00500370 00100510 10001000
>>>fe040d40:  00000000 00000000 03b00010 00500370
>>>fe040d50:  05120004 00100510 00000000 00000000
>>>fe040d60:  00000000 00000000 00000000 00000000
>>>fe040d70:  00000000 00000000 00000000 00000000
>>>fe040d80:  15110903 00030911 1a150b04 00040b15
>>>fe040d90:  15110903 00030911 00000000 00000000
>>>fe040da0:  00000000 00000000 00000000 00000000
>>>fe040db0:  00000000 00000000 00000000 00000000
>>>fe040dc0:  00000000 00000000 00000000 00000000
>>>fe040dd0:  00000000 00000000 00000000 00000000
>>>fe040de0:  00000000 00000000 00000000 00000000
>>>fe040df0:  00000000 00000000 00000000 00000000
>>>```
>>>
>>>For completeness, I then closed the lid and opened it again:
>>>
>>>```sh
>>>root@pt2-scmi:~# dmesg | grep "vop2_"
>>>[    5.128785] rockchip-drm display-subsystem: bound fe040000.vop (ops vop2_crtc_atomic_try_set_gamma.part.0 [rockchipdrm])
>>>[    5.138031] rockchip-drm display-subsystem: bound fe0a0000.hdmi (ops vop2_crtc_atomic_try_set_gamma.part.0 [rockchipdrm])
>>>[    5.139641] rockchip-drm display-subsystem: bound fe060000.dsi (ops vop2_crtc_atomic_try_set_gamma.part.0 [rockchipdrm])
>>>[    5.160937] vop2_crtc_atomic_try_set_gamma  gamma_lut: 0000000000000000
>>>[    5.160950] vop2_vp_dsp_lut_disable dsp_ctrl: 0x0000000f
>>>[ 1931.879232] vop2_crtc_atomic_try_set_gamma  gamma_lut: 0000000000000000
>>>[ 1931.879245] vop2_vp_dsp_lut_disable dsp_ctrl: 0x00010000
>>>```
>>>
>>>Cheers,
>>>  Diederik
>>>
>>>>>> [   73.750524] vop2_crtc_atomic_try_set_gamma  gamma_lut: 0000000000000000
>>>>>> [   73.750542] vop2_vp_dsp_lut_disable dsp_ctrl: 0x00010000
>>>>>>>>>>>> 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 built a kernel with 6.14-rc1 + this patch and can confirm the screen
>>>>>>>>>>>has output again :-)
>>>>>>>>>>>
>>>>>>>>>>>> I will wait with sending a patch because maybe Andy has something to add 
>>>>>>>>>>>> to this.
>>>>>>>>>>>
>>>>>>>>>>>Sounds like a plan. It could be that this issue surfaced an underlaying
>>>>>>>>>>>issue and if so, fixing that would be even better.
>>>
>

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

[Piotr Zalewski]

Hi Andy and Diederik

> 
> The root case for the problem is now clear。
> 
> Most of the registers in VOP need to write the cfd_done register(call vop2_cfg_done)
> after you have configured the registers. Then, they will take effect only when the VSYNC event occurs(It doesn't take effect immediately after you finish writing.).
> This also includes all the VP_DSP_CTRL registers.
> 
> see the code:
> 
> vop2_vp_write(vp, RK3568_VP_DSP_CTRL, dsp_ctrl);
> 
> vop2_crtc_atomic_try_set_gamma(vop2, vp, crtc, crtc_state);
> -->
> 
> static void vop2_vp_dsp_lut_disable(struct vop2_video_port vp)
> {
> u32 dsp_ctrl = vop2_vp_read(vp, RK3568_VP_DSP_CTRL);
> 
> 
> When we read this register, we are reading the actual effective value,
> not the one(dsp_ctrl) that was just written in before (it has not yet taken effect)
> 
> So when we continue to write about this register here, we overwrite the actual
> value we originally intended to put in.
> 
> 
> dsp_ctrl &= ~RK3568_VP_DSP_CTRL__DSP_LUT_EN;
> vop2_vp_write(vp, RK3568_VP_DSP_CTRL, dsp_ctrl);
> }
> 
> I think the correct solution should be similar to the Windows-related registry settings.
> All the registers related to Video Ports should be set as non-volatile, see:
> /
> * The window registers are only updated when config done is written.
> * Until that they read back the old value. As we read-modify-write
> * these registers mark them as non-volatile. This makes sure we read
> * the new values from the regmap register cache.
> */
> static const struct regmap_range vop2_nonvolatile_range[] = {
> regmap_reg_range(0x1000, 0x23ff),
> };
> 
> static const struct regmap_access_table vop2_volatile_table = {
> .no_ranges = vop2_nonvolatile_range,
> .n_no_ranges = ARRAY_SIZE(vop2_nonvolatile_range),
> };
> 

I'm wondering that perhaps making a separate code path for gamma
LUT enable in atomic enable would fix it? IIUC we set config. 
earlier in atomic_enable and write dsp_ctrl + cfg_done with proper
configuration but since there wasn't a vsync the read of dsp ctrl
in lut disable is not correct (or we cannot be sure it is correct).
Putting try set gamma LUT before first dsp ctrl write and make it
use the dsp_ctrl value so far written in atomic enable could also
fix the issue because we wouldn't read dsp ctrl value from the 
register.

> Actually, there is another question. I still haven't figured out why
> this problem doesn't occur when compiling rockchipdrm=y .
> 

I applied your patch and run a test on both versions. This is what
i got with drm=m, so the same result as diederik.
```
[    8.138482] vop2_crtc_atomic_try_set_gamma  gamma_lut: 0000000000000000
[    8.139093] vop2_vp_dsp_lut_disable dsp_ctrl: 0x0000000f
```
This is what i got with drm=y. So it seems with drm=y read value in 
the register _is_ what was written earlier in atomic enable i.e value is 
vaild? Maybe it is just "unfortunate" timing?
```
[    6.646991] vop2_crtc_atomic_try_set_gamma  gamma_lut: 0000000000000000
[    6.647594] vop2_vp_dsp_lut_disable dsp_ctrl: 0x00010000
```

I will have time to spend more on this over the weekend.

Best regards, Piotr Zalewski

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

[Diederik de Haas]

[-- Attachment #1.1.1: Type: text/plain, Size: 1027 bytes --]

Hi Andy,

On Wed Jun 11, 2025 at 2:49 PM CEST, Andy Yan wrote:
> The root case for the problem is now clear。

\o/

> ...
>
> Actually, there is another question. I still haven't figured out why
> this problem doesn't occur when compiling rockchipdrm=y . 

Thus far I had compiled all my kernels with this:

```sh
make clean
cp ../config-6.14-arm64-cknow .config
scripts/config --enable LOCALVERSION_AUTO
scripts/config --enable DEBUG_INFO_NONE
scripts/config --disable DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT
make oldconfig
time make -j `nproc` bindeb-pkg
```

And with ``make oldconfig`` I accepted all the defaults (during
git bisect I did say 'y' to a new Rockchip related setting)

Wanting to see ``DRM_ROCKCHIP=y`` for myself, I added

```sh
scripts/config --enable DRM_ROCKCHIP
scripts/config --enable DRM
```

before ``make oldconfig`` and built a new kernel.
I can confirm I'm seeing it work now too.
Attached you'll find the ``.config`` diff between the 2 builds.

HTH,
  Diederik

[-- Attachment #1.2: kernel-config-diff-with-drm_rockchip-y.diff --]
[-- Type: text/x-patch, Size: 2624 bytes --]

root@pt2-scmi:/boot# diff -u config-6.14.0-rc1-00001-gfbe17d9b77b0 config-6.14.0-rc1-00002-gbc85fa3dec68 
--- config-6.14.0-rc1-00001-gfbe17d9b77b0       2025-06-09 11:47:09.000000000 +0200
+++ config-6.14.0-rc1-00002-gbc85fa3dec68       2025-06-11 18:43:24.000000000 +0200
@@ -6193,13 +6193,12 @@
 CONFIG_RC_ATI_REMOTE=m
 CONFIG_RC_LOOPBACK=m
 # CONFIG_RC_XBOX_DVD is not set
-CONFIG_CEC_CORE=m
+CONFIG_CEC_CORE=y
 CONFIG_CEC_NOTIFIER=y
 
 #
 # CEC support
 #
-CONFIG_MEDIA_CEC_RC=y
 CONFIG_MEDIA_CEC_SUPPORT=y
 # CONFIG_CEC_CH7322 is not set
 # CONFIG_CEC_CROS_EC is not set
@@ -7185,16 +7184,16 @@
 CONFIG_TEGRA_HOST1X_CONTEXT_BUS=y
 CONFIG_TEGRA_HOST1X=m
 CONFIG_TEGRA_HOST1X_FIREWALL=y
-CONFIG_DRM=m
+CONFIG_DRM=y
 CONFIG_DRM_MIPI_DSI=y
 # CONFIG_DRM_DEBUG_MM is not set
-CONFIG_DRM_KMS_HELPER=m
+CONFIG_DRM_KMS_HELPER=y
 # CONFIG_DRM_PANIC is not set
 # CONFIG_DRM_DEBUG_DP_MST_TOPOLOGY_REFS is not set
 # CONFIG_DRM_DEBUG_MODESET_LOCK is not set
 CONFIG_DRM_CLIENT=y
-CONFIG_DRM_CLIENT_LIB=m
-CONFIG_DRM_CLIENT_SELECTION=m
+CONFIG_DRM_CLIENT_LIB=y
+CONFIG_DRM_CLIENT_SELECTION=y
 CONFIG_DRM_CLIENT_SETUP=y
 
 #
@@ -7210,7 +7209,7 @@
 
 CONFIG_DRM_LOAD_EDID_FIRMWARE=y
 CONFIG_DRM_DISPLAY_DP_AUX_BUS=m
-CONFIG_DRM_DISPLAY_HELPER=m
+CONFIG_DRM_DISPLAY_HELPER=y
 CONFIG_DRM_BRIDGE_CONNECTOR=y
 # CONFIG_DRM_DISPLAY_DP_AUX_CEC is not set
 CONFIG_DRM_DISPLAY_DP_AUX_CHARDEV=y
@@ -7226,7 +7225,7 @@
 CONFIG_DRM_BUDDY=m
 CONFIG_DRM_VRAM_HELPER=m
 CONFIG_DRM_TTM_HELPER=m
-CONFIG_DRM_GEM_DMA_HELPER=m
+CONFIG_DRM_GEM_DMA_HELPER=y
 CONFIG_DRM_GEM_SHMEM_HELPER=m
 CONFIG_DRM_SUBALLOC_HELPER=m
 CONFIG_DRM_SCHED=m
@@ -7317,7 +7316,7 @@
 CONFIG_DRM_VGEM=m
 # CONFIG_DRM_VKMS is not set
 # CONFIG_DRM_EXYNOS is not set
-CONFIG_DRM_ROCKCHIP=m
+CONFIG_DRM_ROCKCHIP=y
 CONFIG_ROCKCHIP_VOP=y
 CONFIG_ROCKCHIP_VOP2=y
 CONFIG_ROCKCHIP_ANALOGIX_DP=y
@@ -7520,7 +7519,7 @@
 # CONFIG_DRM_TI_TPD12S015 is not set
 CONFIG_DRM_ANALOGIX_ANX6345=m
 # CONFIG_DRM_ANALOGIX_ANX78XX is not set
-CONFIG_DRM_ANALOGIX_DP=m
+CONFIG_DRM_ANALOGIX_DP=y
 CONFIG_DRM_ANALOGIX_ANX7625=m
 CONFIG_DRM_I2C_ADV7511=m
 CONFIG_DRM_I2C_ADV7511_AUDIO=y
@@ -7535,13 +7534,13 @@
 # CONFIG_DRM_IMX8QXP_PIXEL_COMBINER is not set
 # CONFIG_DRM_IMX8QXP_PIXEL_LINK_TO_DPI is not set
 # CONFIG_DRM_IMX93_MIPI_DSI is not set
-CONFIG_DRM_DW_HDMI=m
+CONFIG_DRM_DW_HDMI=y
 # CONFIG_DRM_DW_HDMI_AHB_AUDIO is not set
 CONFIG_DRM_DW_HDMI_I2S_AUDIO=m
 # CONFIG_DRM_DW_HDMI_GP_AUDIO is not set
 CONFIG_DRM_DW_HDMI_CEC=m
-CONFIG_DRM_DW_HDMI_QP=m
-CONFIG_DRM_DW_MIPI_DSI=m
+CONFIG_DRM_DW_HDMI_QP=y
+CONFIG_DRM_DW_MIPI_DSI=y
 # end of Display Interface Bridges
 
 CONFIG_DRM_IMX_DCSS=m

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

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

[Piotr Zalewski]

Hi Andy

> 
> The root case for the problem is now clear。
> 
> Most of the registers in VOP need to write the cfd_done register(call vop2_cfg_done)
> after you have configured the registers. Then, they will take effect only when the VSYNC event occurs(It doesn't take effect immediately after you finish writing.).
> This also includes all the VP_DSP_CTRL registers.
> 
> see the code:
> 
> vop2_vp_write(vp, RK3568_VP_DSP_CTRL, dsp_ctrl);
> 
> vop2_crtc_atomic_try_set_gamma(vop2, vp, crtc, crtc_state);
> -->
> 
> static void vop2_vp_dsp_lut_disable(struct vop2_video_port vp)
> {
> u32 dsp_ctrl = vop2_vp_read(vp, RK3568_VP_DSP_CTRL);
> 
> 
> When we read this register, we are reading the actual effective value,
> not the one(dsp_ctrl) that was just written in before (it has not yet taken effect)
> 
> So when we continue to write about this register here, we overwrite the actual
> value we originally intended to put in.
> 
> 
> dsp_ctrl &= ~RK3568_VP_DSP_CTRL__DSP_LUT_EN;
> vop2_vp_write(vp, RK3568_VP_DSP_CTRL, dsp_ctrl);
> }
> 
> I think the correct solution should be similar to the Windows-related registry settings.
> All the registers related to Video Ports should be set as non-volatile, see:
> 
> /
> * The window registers are only updated when config done is written.
> * Until that they read back the old value. As we read-modify-write
> * these registers mark them as non-volatile. This makes sure we read
> * the new values from the regmap register cache.
> */
> static const struct regmap_range vop2_nonvolatile_range[] = {
> regmap_reg_range(0x1000, 0x23ff),
> };
> 
> static const struct regmap_access_table vop2_volatile_table = {
> .no_ranges = vop2_nonvolatile_range,
> .n_no_ranges = ARRAY_SIZE(vop2_nonvolatile_range),
> };

Following your suggestion I added vop2 video port registers as not
volatile and it fixed the issue. I took the values from RK3588 TRM
Part2 V1.1. See the patch below and confirm if it is correct.

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
index d0f5fea15e21..c5c1910fa5ca 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
@@ -2596,6 +2596,7 @@ static int vop2_win_init(struct vop2 *vop2)
  */
 static const struct regmap_range vop2_nonvolatile_range[] = {
 	regmap_reg_range(0x1000, 0x23ff),
+	regmap_reg_range(0x0C00, 0x0fff),
 };
 
 static const struct regmap_access_table vop2_volatile_table = {


> Actually, there is another question. I still haven't figured out why
> this problem doesn't occur when compiling rockchipdrm=y .

Couldn't reason out why this only happens with drm=m yet
unfortunately.

Best regards, Piotr Zalewski

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

[Andy Yan]

HI Piotr，

在 2025-06-19 19:54:12，"Piotr Zalewski" <pZ010001011111@proton.me> 写道：
>Hi Andy
>
>> 
>> The root case for the problem is now clear。
>> 
>> Most of the registers in VOP need to write the cfd_done register(call vop2_cfg_done)
>> after you have configured the registers. Then, they will take effect only when the VSYNC event occurs(It doesn't take effect immediately after you finish writing.).
>> This also includes all the VP_DSP_CTRL registers.
>> 
>> see the code:
>> 
>> vop2_vp_write(vp, RK3568_VP_DSP_CTRL, dsp_ctrl);
>> 
>> vop2_crtc_atomic_try_set_gamma(vop2, vp, crtc, crtc_state);
>> -->
>> 
>> static void vop2_vp_dsp_lut_disable(struct vop2_video_port vp)
>> {
>> u32 dsp_ctrl = vop2_vp_read(vp, RK3568_VP_DSP_CTRL);
>> 
>> 
>> When we read this register, we are reading the actual effective value,
>> not the one(dsp_ctrl) that was just written in before (it has not yet taken effect)
>> 
>> So when we continue to write about this register here, we overwrite the actual
>> value we originally intended to put in.
>> 
>> 
>> dsp_ctrl &= ~RK3568_VP_DSP_CTRL__DSP_LUT_EN;
>> vop2_vp_write(vp, RK3568_VP_DSP_CTRL, dsp_ctrl);
>> }
>> 
>> I think the correct solution should be similar to the Windows-related registry settings.
>> All the registers related to Video Ports should be set as non-volatile, see:
>> 
>> /
>> * The window registers are only updated when config done is written.
>> * Until that they read back the old value. As we read-modify-write
>> * these registers mark them as non-volatile. This makes sure we read
>> * the new values from the regmap register cache.
>> */
>> static const struct regmap_range vop2_nonvolatile_range[] = {
>> regmap_reg_range(0x1000, 0x23ff),
>> };
>> 
>> static const struct regmap_access_table vop2_volatile_table = {
>> .no_ranges = vop2_nonvolatile_range,
>> .n_no_ranges = ARRAY_SIZE(vop2_nonvolatile_range),
>> };
>
>Following your suggestion I added vop2 video port registers as not
>volatile and it fixed the issue. I took the values from RK3588 TRM
>Part2 V1.1. See the patch below and confirm if it is correct.
>
>diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
>index d0f5fea15e21..c5c1910fa5ca 100644
>--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
>+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
>@@ -2596,6 +2596,7 @@ static int vop2_win_init(struct vop2 *vop2)
>  */
> static const struct regmap_range vop2_nonvolatile_range[] = {
> 	regmap_reg_range(0x1000, 0x23ff),
>+	regmap_reg_range(0x0C00, 0x0fff),
> };
> 

For a complete solution, the registers of all four Video Ports should all be
marked as non-volatile.
And they should be arranged in ascending order of address size, so they
should be placed before 0x1000.

Additionally, the comments here should also be updated accordingly.


#define RK3568_VP0_CTRL_BASE                    0x0C00
#define RK3568_VP1_CTRL_BASE                    0x0D00
#define RK3568_VP2_CTRL_BASE                    0x0E00
#define RK3588_VP3_CTRL_BASE                    0x0F00

> static const struct regmap_access_table vop2_volatile_table = {
>
>
>> Actually, there is another question. I still haven't figured out why
>> this problem doesn't occur when compiling rockchipdrm=y .
>
>Couldn't reason out why this only happens with drm=m yet
>unfortunately.

This should eventually lead to an answer. However, I've been quite busy recently
and haven't had time to conduct further analysis yet. I will incorporate it into my TODO list.


>
>Best regards, Piotr Zalewski