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

[Nishanth Menon <nm@ti.com>]

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 also have a suspicion that this will end up having a subset of sane
> values, and Linux won't necessarily be able to do any interpolation of
> values without additional platform knowledge.

These may be SoC dependent. An fixed regulator might be acceptable on
SoC x, but not on y (as leakage angle might make it infeasible).

[...]
> > I did make a proposal here: 
> > http://marc.info/?l=devicetree&m=137530056230441&w=2
> > 
> > Do you see it making sense, If yes, I can help flesh out the idea with code.
> 
> I can see one of the example mechanisms working for describing OPPs
> being usable, but I'm still concerned about the division into profiles.
Above.

Does this make sense? I understand and share the concern about potential
misuse, but I am all open ears of how we'd like to ensure data is
completely separated out from kernel source.

-- 
Regards,
Nishanth Menon