public inbox for linux-rockchip@lists.infradead.org
 help / color / mirror / Atom feed
From: "Andy Yan" <andyshrk@163.com>
To: "Piotr Zalewski" <pZ010001011111@proton.me>
Cc: "Diederik de Haas" <didi.debian@cknow.org>,
	hjc@rock-chips.com, heiko@sntech.de, andy.yan@rock-chips.com,
	maarten.lankhorst@linux.intel.com, mripard@kernel.org,
	tzimmermann@suse.de, airlied@gmail.com, simona@ffwll.ch,
	"Dang Huynh" <danct12@riseup.net>,
	dri-devel@lists.freedesktop.org,
	linux-rockchip@lists.infradead.org
Subject: Re:Re: [PATCH drm-misc-next] rockchip/drm: vop2: don't check color_mgmt_changed in atomic_enable
Date: Fri, 20 Jun 2025 08:42:49 +0800 (CST)	[thread overview]
Message-ID: <4a124fa9.75b.1978ac9c8a8.Coremail.andyshrk@163.com> (raw)
In-Reply-To: <oT4pI24an4vFCCysHCInNVi7B-jsgNUVKs4olmiuQ4lWzdd0FS_nwMs-ja40ofjDElVARdad8I_eTG9tRXkgJos48eQmsWo13V5mgc-dXEg=@proton.me>


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
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

  reply	other threads:[~2025-06-20  0:43 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-12-06 19:26 [PATCH drm-misc-next] rockchip/drm: vop2: don't check color_mgmt_changed in atomic_enable Piotr Zalewski
2024-12-11 22:45 ` Heiko Stuebner
2025-06-05 20:08 ` Diederik de Haas
2025-06-07 15:32   ` Piotr Zalewski
2025-06-08 11:08     ` Diederik de Haas
2025-06-08 12:10       ` Andy Yan
2025-06-08 12:53         ` Diederik de Haas
2025-06-09  9:15           ` Andy Yan
2025-06-09 12:36             ` Diederik de Haas
2025-06-10  9:07               ` Andy Yan
2025-06-10 11:02                 ` Diederik de Haas
2025-06-11  7:41                   ` Andy Yan
2025-06-11 10:56                     ` Diederik de Haas
2025-06-11 12:15                       ` Andy Yan
2025-06-11 12:26                         ` Diederik de Haas
2025-06-11 12:49                           ` Andy Yan
2025-06-11 22:12                             ` Piotr Zalewski
2025-06-12  8:33                             ` Diederik de Haas
2025-06-19 11:54                             ` Piotr Zalewski
2025-06-20  0:42                               ` Andy Yan [this message]
2025-06-09 22:37       ` Piotr Zalewski
2025-06-10 11:27         ` Diederik de Haas

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4a124fa9.75b.1978ac9c8a8.Coremail.andyshrk@163.com \
    --to=andyshrk@163.com \
    --cc=airlied@gmail.com \
    --cc=andy.yan@rock-chips.com \
    --cc=danct12@riseup.net \
    --cc=didi.debian@cknow.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=heiko@sntech.de \
    --cc=hjc@rock-chips.com \
    --cc=linux-rockchip@lists.infradead.org \
    --cc=maarten.lankhorst@linux.intel.com \
    --cc=mripard@kernel.org \
    --cc=pZ010001011111@proton.me \
    --cc=simona@ffwll.ch \
    --cc=tzimmermann@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox