Re: [PATCH v2 2/2] pmdomain: rockchip: Add support for rk3576 SoC

Heiko Stübner
2024-08-08T18:00:18Z

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