[PATCH v2] pmdomain: rockchip: Fix rkvdec0/1 and venc0/1 for RK3588

Shawn Lin shawn.lin at rock-chips.com
Tue Feb 24 18:25:25 PST 2026


Hi Chaoyi

在 2026/02/25 星期三 9:37, Chaoyi Chen 写道:
> Hi Shawn,
> 
> On 2/24/2026 11:47 AM, Shawn Lin wrote:
>> Per the RK3588 TRM Table 7-1 RK3588 Voltage Domain and Power Domain Summary,
>> PD_RKVDEC0/1 and PD_VENC0/1 rely on VD_VCODEC which require extra voltages to
>> be applied, otherwise it breaks RK3588-evb1-v10 board after vdec support landed[1].
>> The panic looks like below:
>>
>>    rockchip-pm-domain fd8d8000.power-management:power-controller: failed to set domain 'rkvdec0' on, val=0
>>    rockchip-pm-domain fd8d8000.power-management:power-controller: failed to set domain 'rkvdec1' on, val=0
>>    ...
>>    Hardware name: Rockchip RK3588S EVB1 V10 Board (DT)
>>    Workqueue: pm genpd_power_off_work_fn
>>    Call trace:
>>    show_stack+0x18/0x24 (C)
>>    dump_stack_lvl+0x40/0x84
>>    dump_stack+0x18/0x24
>>    vpanic+0x1ec/0x4fc
>>    vpanic+0x0/0x4fc
>>    check_panic_on_warn+0x0/0x94
>>    arm64_serror_panic+0x6c/0x78
>>    do_serror+0xc4/0xcc
>>    el1h_64_error_handler+0x3c/0x5c
>>    el1h_64_error+0x6c/0x70
>>    regmap_mmio_read32le+0x18/0x24 (P)
>>    regmap_bus_reg_read+0xfc/0x130
>>    regmap_read+0x188/0x1ac
>>    regmap_read+0x54/0x78
>>    rockchip_pd_power+0xcc/0x5f0
>>    rockchip_pd_power_off+0x1c/0x4c
>>    genpd_power_off+0x84/0x120
>>    genpd_power_off+0x1b4/0x260
>>    genpd_power_off_work_fn+0x38/0x58
>>    process_scheduled_works+0x194/0x2c4
>>    worker_thread+0x2ac/0x3d8
>>    kthread+0x104/0x124
>>    ret_from_fork+0x10/0x20
>>    SMP: stopping secondary CPUs
>>    Kernel Offset: disabled
>>    CPU features: 0x3000000,000e0005,40230521,0400720b
>>    Memory Limit: none
>>    ---[ end Kernel panic - not syncing: Asynchronous SError Interrupt ]---
>>
>> [1] https://lore.kernel.org/linux-rockchip/20251020212009.8852-2-detlev.casanova@collabora.com/
>> Fixes: db6df2e3fc16 ("pmdomain: rockchip: add regulator support")
>> Cc: stable at vger.kernel.org
>> Reviewed-by: Heiko Stuebner <heiko at sntech.de>
>> Reviewed-by: Sebastian Reichel <sebastian.reichel at collabora.com>
>> Signed-off-by: Shawn Lin <shawn.lin at rock-chips.com>
>> ---
>>
>> Changes in v2:
>> - collect tags
>> - correct TRM section(Sebastian)
>>
>>   drivers/pmdomain/rockchip/pm-domains.c | 8 ++++----
>>   1 file changed, 4 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/pmdomain/rockchip/pm-domains.c b/drivers/pmdomain/rockchip/pm-domains.c
>> index 997e93c..040aa5f 100644
>> --- a/drivers/pmdomain/rockchip/pm-domains.c
>> +++ b/drivers/pmdomain/rockchip/pm-domains.c
>> @@ -1315,10 +1315,10 @@ static const struct rockchip_domain_info rk3588_pm_domains[] = {
>>   	[RK3588_PD_NPUTOP]	= DOMAIN_RK3588("nputop",  0x0, BIT(3),  0,       0x0, BIT(11), BIT(2),  0x0, BIT(1),  BIT(1),  false, false),
>>   	[RK3588_PD_NPU1]	= DOMAIN_RK3588("npu1",    0x0, BIT(4),  0,       0x0, BIT(12), BIT(3),  0x0, BIT(2),  BIT(2),  false, false),
>>   	[RK3588_PD_NPU2]	= DOMAIN_RK3588("npu2",    0x0, BIT(5),  0,       0x0, BIT(13), BIT(4),  0x0, BIT(3),  BIT(3),  false, false),
>> -	[RK3588_PD_VENC0]	= DOMAIN_RK3588("venc0",   0x0, BIT(6),  0,       0x0, BIT(14), BIT(5),  0x0, BIT(4),  BIT(4),  false, false),
>> -	[RK3588_PD_VENC1]	= DOMAIN_RK3588("venc1",   0x0, BIT(7),  0,       0x0, BIT(15), BIT(6),  0x0, BIT(5),  BIT(5),  false, false),
>> -	[RK3588_PD_RKVDEC0]	= DOMAIN_RK3588("rkvdec0", 0x0, BIT(8),  0,       0x0, BIT(16), BIT(7),  0x0, BIT(6),  BIT(6),  false, false),
>> -	[RK3588_PD_RKVDEC1]	= DOMAIN_RK3588("rkvdec1", 0x0, BIT(9),  0,       0x0, BIT(17), BIT(8),  0x0, BIT(7),  BIT(7),  false, false),
>> +	[RK3588_PD_VENC0]	= DOMAIN_RK3588("venc0",   0x0, BIT(6),  0,       0x0, BIT(14), BIT(5),  0x0, BIT(4),  BIT(4),  false, true),
>> +	[RK3588_PD_VENC1]	= DOMAIN_RK3588("venc1",   0x0, BIT(7),  0,       0x0, BIT(15), BIT(6),  0x0, BIT(5),  BIT(5),  false, true),
>> +	[RK3588_PD_RKVDEC0]	= DOMAIN_RK3588("rkvdec0", 0x0, BIT(8),  0,       0x0, BIT(16), BIT(7),  0x0, BIT(6),  BIT(6),  false, true),
>> +	[RK3588_PD_RKVDEC1]	= DOMAIN_RK3588("rkvdec1", 0x0, BIT(9),  0,       0x0, BIT(17), BIT(8),  0x0, BIT(7),  BIT(7),  false, true),
>>   	[RK3588_PD_VDPU]	= DOMAIN_RK3588("vdpu",    0x0, BIT(10), 0,       0x0, BIT(18), BIT(9),  0x0, BIT(8),  BIT(8),  false, false),
>>   	[RK3588_PD_RGA30]	= DOMAIN_RK3588("rga30",   0x0, BIT(11), 0,       0x0, BIT(19), BIT(10), 0x0, 0,       0,       false, false),
>>   	[RK3588_PD_AV1]		= DOMAIN_RK3588("av1",     0x0, BIT(12), 0,       0x0, BIT(20), BIT(11), 0x0, BIT(9),  BIT(9),  false, false),
> 
> Perhaps you could try modifying only RK3588_PD_VCODEC.
> VCODEC is the parent of these PDs, so you won't need to modify too

Thanks for your suggestion! I once took a quick look at rk3588-base.dtsi
and indeed noticed that these PDs (PD_RKVDEC0/1 and PD_VENC0/1) are all
placed under PD_VCODEC. At that time, I considered PD_VCODEC to be a
"fake" power domain, this was, because all my reference materials came 
from the relevant chapters of the RK3588 TRM, where the structure is 
illustrated as follows:

┌────┬──────┬──────┐
│        │            │BIU_RKVDEC0 │
│        │PD_RKVDEC0  ├──────┤
│        │            │RKVDEC0&CCU │
│        ├──────┼──────┤
│        │            │BIU_RKVDEC1 │
│VD_VCODEC│PD_RKVDEC1 ├──────┤
│        │            │RKVDEC1     │
│        ├──────┼──────┤
│        │            │BIU_VENC0   │
│        │PD_VENC0    ├──────┤
│        │            │RKVENCO     │
│        ├──────┼──────┤
│        │            │BIU_VENC1   │
│        │PD_VENC1    ├──────┤
│        │            │RKVENC1     │
└────┴──────┴──────┘

PD_VCODEC does not show up in any of these diagrams from the TRM. Looks
like the people who wrote the TRM thought PD_VCODEC was a huge secret t
that they just wouldn’t put it in the figure, for fear of being
discovered :)

Of course, you are right, there is some registers called
pd_vcodec_foo..bar which seems it does exist. So I gave it a try
and it worked too. Will update v3, thanks for help.


> much code and devicetree. BTW I have tried it before, but with an
> internal MPP driver. Maybe you can give it another try :)
> 



More information about the Linux-rockchip mailing list