[Skiboot] [PATCH v5] power-mgmt : occ : Add 'freq-domain-indicator' DT property

[Stewart Smith]

Abhishek Goel <huntbag at linux.vnet.ibm.com> writes:
> Add a new device-tree property freq-domain-indicator to define group of
> CPUs which would share same frequency. This property has been added under
> power-mgmt node.
>
> It is a bitmask which will have different value depending upon the
> generation of the processor. Bitwise AND is taken between this bitmask
> value and PIR of cpu. All the CPUs lying in the same frequency domain will
> have same result for AND.
>
> For example, for POWER8 0xFFF8 indicates core wide frequency domain.
> Taking AND with the PIR of CPUs will yield us a frequency domain which is
> core wide distribution as last 3 bits have been masked which represent the
> threads.
>
> For POWER9, 0xFFF0 indicates quad wide frequency domain. Taking AND with
> the PIR of CPUs will yield us frequency domain which is quad wise
> distribution as last 4 bits have been masked which represent the
> cores.

Sorry it's taken so long to get back to this patch!

I like the idea, I don't think we have a current sensible way to expose
this, and thus the choices left to an OS are either to have this
knowledge baked in for each processor generation, or to try to do things
that can't be done, possibly leading to not as good decisions.

> diff --git a/doc/device-tree/ibm,opal/power-mgt/occ.rst b/doc/device-tree/ibm,opal/power-mgt/occ.rst
> index d13a62b..77d4258 100644
> --- a/doc/device-tree/ibm,opal/power-mgt/occ.rst
> +++ b/doc/device-tree/ibm,opal/power-mgt/occ.rst
> @@ -37,3 +37,39 @@ ibm,pstate-vcss ibm,pstate-vdds
>  These properties list a voltage-identifier of each of the pstates listed in
>  ibm,pstate-ids for the Vcs and Vdd values used for that pstate in that chip.
>  Each VID is a single byte.
> +
> +ibm,opal/power-mgt/ibm,freq-domain-indicator

I think 'frequency-domain-mask' would be better as it's a property so it
doesn't need the 'ibm,' prefix (it's already in the OPAL specific
'ibm,opal' hierarchy).

The definition should be that if present, then an OS can use this as an
indicator of how the hardware/firmware behaves. If not present, then
each *can* be treated separately but this may not reflect what frequency
the hardware runs at. For any new scheme, we can add a property
describing it.


> +--------------------------------------------
> +
> +This property is a bitmask which will have different value depending upon the
> +generation of the processor. Frequency domain would indicate group of CPUs
> +which would share same frequency. Bitwise AND is taken between this bitmask
> +value and PIR of cpu. All the CPUs lying in the same frequency domain will have
> +same result for AND. Thus frequency management can be done based on frequency
> +domain. A frequency domain may be a core or a quad, etc depending upon the
> +generation of the processor.
> +
> +For example, for POWER8 0xFFF8 indicates core wide frequency domain. Taking AND
> +with the PIR of CPUs will yield us a frequency domain which is core wide
> +distribution as last 3 bits have been masked which represent the threads.
> +
> +For POWER9, 0xFFF0 indicates quad wide frequency domain. Taking AND with
> +the PIR of CPUs will yield us frequency domain which is quad wise
> +distribution as last 4 bits have been masked which represent the cores.
> +
> +ibm,opal/power-mgt/compatible
> +--------------------------------------------
> +
> +`p9-occ-quirk`
> +
> +It represents the current DVFS implementation in firmware. To set a frequency
> +in a quad, all cores of the quad need to set frequency in their respective
> +PMCR's. Ideally setting frequency on any of the core of that quad should change
> +frequency for the quad.

I'm not sure if these should be in the compatible property or not... it
doesn't seem quite right, but more that it should be a property in the
power-mgt node.

I don't like the 'p9-occ-quirk' name, perhaps instead we should have a
property with a value indicating what frequency the hardware actually
runs at? 'domain-runs-at' = 'max-in-domain' | 'most-recently-set' or
something? (I don't like those names too much either, so improvements
are welcome). The idea being that how the hardware/firmware behaves is
certainly *one* of these, but never more than.

> +
> +`freq-domain-v1`
> +
> +This compatibility string helps kernel to interpret freq-domain-indicator's
> +format. If in future we have different format for freq-domain-indicator, future
> +firmwares running newer kernel will not interpret freq-domain-indicator
> +incorrectly.

I don't think we need this, it's taken care of by the implicit
presence/absence of the property.


-- 
Stewart Smith
OPAL Architect, IBM.