On 14:15-20130802, Mark Rutland wrote:

On Thu, Aug 01, 2013 at 05:25:06PM +0100, Nishanth Menon wrote:

quoted

On 08/01/2013 08:54 AM, Mark Rutland wrote:

quoted

On Wed, Jul 31, 2013 at 05:27:39PM +0100, Nishanth Menon wrote:

quoted

On 07/31/2013 11:11 AM, Mark Rutland wrote:

quoted

On Wed, Jul 31, 2013 at 04:58:22PM +0100, Nishanth Menon wrote:

quoted

On 07/31/2013 10:29 AM, Mark Rutland wrote:

quoted

On Wed, Jul 31, 2013 at 03:46:34PM +0100, Nishanth Menon wrote:

quoted

On 07/31/2013 06:14 AM, Sudeep KarkadaNagesha wrote:

quoted

On 30/07/13 21:48, Nishanth Menon wrote:

quoted

On 07/30/2013 01:34 PM, Stephen Warren wrote:

quoted

On 07/30/2013 12:00 PM, Sudeep KarkadaNagesha wrote:

[...]

quoted

quoted

* 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).

[...]

quoted

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