Re: [RFC PATCH 1/2] PM / OPP: add support to specify phandle of another node for OPP

[Mark Rutland <mark.rutland@arm.com>]

On Tue, Aug 06, 2013 at 02:45:34PM +0100, Nishanth Menon wrote:
> On 14:15-20130802, Mark Rutland wrote:
> > On Thu, Aug 01, 2013 at 05:25:06PM +0100, Nishanth Menon wrote:
> > > On 08/01/2013 08:54 AM, Mark Rutland wrote:
> > > > On Wed, Jul 31, 2013 at 05:27:39PM +0100, Nishanth Menon wrote:
> > > >> On 07/31/2013 11:11 AM, Mark Rutland wrote:
> > > >>> On Wed, Jul 31, 2013 at 04:58:22PM +0100, Nishanth Menon wrote:
> > > >>>> On 07/31/2013 10:29 AM, Mark Rutland wrote:
> > > >>>>> On Wed, Jul 31, 2013 at 03:46:34PM +0100, Nishanth Menon wrote:
> > > >>>>>> On 07/31/2013 06:14 AM, Sudeep KarkadaNagesha wrote:
> > > >>>>>>> On 30/07/13 21:48, Nishanth Menon wrote:
> > > >>>>>>>> On 07/30/2013 01:34 PM, Stephen Warren wrote:
> > > >>>>>>>>> On 07/30/2013 12:00 PM, Sudeep KarkadaNagesha wrote:
> [...]
> > > 
> > > >
> > > > * Performance profiles, in which you have a set of OPP tables for
> > > >    "performance, "low-power", and whatever else. This arbitrary split
> > > >    seems like a configuration decision rather than a hardware description
> > > >    unless there is some hard limit that cannot be detected (e.g. the
> > > >    processor can function at some arbitrary high speed, but becomes hot
> > > >    enough to melt something, and there's no temperature sensor to handle
> > > >    this case dynamically).
> > > 
> > > precisely -> I think I point this out in this thread:
> > > http://marc.info/?l=devicetree&m=137535932402560&w=2
> > 
> > The one thing I don't like is the arbitrary grouping into profiles, as
> > the division is entirely a configuration decision. The operating points
> > themselves are a hardware capability, and it may make sense to describe
> > the feasible points for a device in the dt, but I don't want to have
> > different profiles exported because it straddles the line of the dt
> > telling us how to use the hardware rather than what the hardware is, and
> > will come back to bite us later if we want to handle cpu frequency
> > decisions differently.
> 
> I can understand why it seems to wrongly indicate *how* to use the
> hardware, rather than *what the hardware is* - Lets try it this way:
> - if Bit X is set in efuse, one cannot use high performance mode
> - If PDN (Power Distribution Network) guidelines are not met, one cannot
> use high performance mode.
> 
> These constrain *hardware capability* you can do on that SoC+Board
> combination - that is exactly what we have been struggling to describe
> here. These are not *how to use hardware* profiles, but *hardware
> capability* profiles whose selection is upto to the System in
> discussion - example - SoC x will decide on bit based decision and
> forbid Board file overrides while an SoC y family might choose another
> path.. Framework and dts should not dictate policy and we dont try to
> do that here.
> 
> How to use the hardware within the *capability costraints* is upto
> drivers, there is no attempt to define that in my proposal.

I'm happy to have the OPPs, as your arguments certainly make sense. My
only concern is that if we have them grouped in some fashion in dt (e.g.
profiles), people will use this as configuration, treating the groups of
OPPs differnetly (prefering a 'performance' or 'low-power' profile). I'd
prefer that any decision on how to use the provided OPP values were done
in the kernel dynamically.

I suspect even if we remove profile names, people will attempt to read
some semantics into the groupings. For that reason, I'd prefer to have a
single OPP table for any device (though this table could be shared by
devices).

Thanks,
Mark.