Re: [PATCH v4] dt-bindings: dvfs: Add support for generic performance domains

[Ulf Hansson]

On Thu, 21 Oct 2021 at 15:33, Sudeep Holla <sudeep.holla@xxxxxxx> wrote:
>
> On Thu, Oct 21, 2021 at 03:13:30PM +0200, Ulf Hansson wrote:
> > On Wed, 20 Oct 2021 at 14:11, Rob Herring <robh@xxxxxxxxxx> wrote:
> > >
>
> [...]
>
> > > 'power domains' in DT is supposed to mean physical power islands in
> > > the h/w where as genpd can be whatever you want. Are power and
> > > performance domains always 1:1?
> >
> > I wouldn't say that "power domains" *must* correspond to physical
> > power islands. At least, that's not the way the bindings are being
> > used. For example, if it makes better sense to keep some of the logic
> > in FW, rather than describing a complete topology in DT, that should
> > be perfectly fine.
> >
>
> I agree. The DT must either have h/w view or f/w view of the topology
> and not both(that is inviting more trouble in terms of bindings as well
> as handling it in the OSPM).
>
> > Additionally, I am not suggesting that "performance domains" and
> > "power domains" must map 1:1. A device can be performance managed
> > through one domain and power managed by another, that would be
> > perfectly fine to me.
>
> I don't understand what you mean by that. Do you expect to create a genpd
> with no power domain ops and just performance ops to deal with scenario
> I have been presenting(i.e. power domains for a set of devices(CPUs in
> particular) aren't exposed to OSPM while performance domains are).

Yes, but only if that would make sense, of course.

If it matters, the performance states and idle states in genpd are
supported as two orthogonal states.

>
> I really don't like to create psuedo/dummy power domains with no useful
> info(as f/w hides or abstracts it) just to represent the performance
> domains.

I assume you mean creating dummy *genpds* - and yes that seems very
silly, I agree.

We shouldn't do that, unless we can make use of them in some clever
way to avoid open coding, but that's an entirely different question,
unrelated to DT.

>
> Also with CPUs you can imagine all sort of combinations like:
> 1. cluster level perf domain + cpu level power domains
> 3. cluster level perf domain + cluster level power domains
> 2. cpu level perf domain + cpu level power domains
> 4. cpu level perf domain + cluster level power domains
>
> + power domains not available to OSPM in all the 4 combo.
>
> So I am really struggling to visualise a way to represent these based
> on your suggestion.

For perf domains, we could model this in DT as one power domain for
performance, per CPU, but without a cluster power domain for the
performance, as that seems to be managed in FW. Note that, this
doesn't mean we need to create genpds and hook up devices to them.

I guess this would map 1:1 towards how the "performance-domains"
binding is intended to be used, right?

One thing though, for PSCI we distinguish the power domains, by
specifying "power-domain-names = "psci" in DT. Similar to this, we
would then need to come up with another power-domain-name, to map it
to a "performance domain". Mostly to cover future compatibility
issues.

So, to summarize (thanks for a good discussion!), I will not insist on
deprecating the recently introduced "performance domains" binding. I
leave the call to you! However, to me, it still looks like the
power-domains binding could be used to support "performance" as well.
Especially, as we already have other cpufreq drivers [1] supporting
them.

Kind regards
Uffe

[1]
Documentation/devicetree/bindings/opp/qcom-nvmem-cpufreq.txt