Hi Detlev, Am Donnerstag, 8. August 2024, 19:53:20 CEST schrieb Detlev Casanova: > On Thursday, 8 August 2024 12:41:05 EDT Heiko Stübner wrote: > > > @@ -552,7 +575,10 @@ static int rockchip_pd_power(struct > > > rockchip_pm_domain *pd, bool power_on)> > > > /* if powering up, leave idle mode */ > > > rockchip_pmu_set_idle_request(pd, false); > > > > > > - rockchip_pmu_restore_qos(pd); > > > + if (pd->info->delay_us) > > > + udelay(pd->info->delay_us); > > > + else > > > + rockchip_pmu_restore_qos(pd); > > > > I still want this behaviour change in a separate patch with adequate > > commit message please. > > > > Going from always handling qos to allowing to just wait a specific time > > needs explanation and is not part of "just" adding rk3576 support. > > You are right, I didn't takle this issue. > This is actually a bug, the else is not supposed to be there, it should only > be an added delay for some PDs. > > Unfortunately, I'm not sure why that delay is needed exactly, so I'm willing > to remove it for now (only used by nputop and vop, both unsupported) and come > back to it if needed when VOP/NPU support is added. > > Would that work for this upstream ? that would work. The whole delay thing is not part of the dt-binding which would be more critical to get right in the first round. So as long as your "add rk3576 support" patch really only adds the rk3576-specific data, but does not change how the shared code behaves, we should be fine and can find out about that delay later. Heiko
