On 08/20/2013 05:00 AM, Sudeep KarkadaNagesha wrote:

On 07/08/13 17:17, Mark Rutland wrote:

quoted

On Tue, Aug 06, 2013 at 02:45:34PM +0100, Nishanth Menon wrote:

quoted

On 14:15-20130802, Mark Rutland wrote:

quoted

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

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

Until we get more feedback and agreement on new proposal can we have
this simple amendment in this patch to the existing binding ? Since the
new proposal[1] is backward compatible(this patch adding support for
option#5 to existing option#1), we will have to add support for other
binding options in [1] later.

This is needed to support shared OPPs with simple/single OPP profile
and also to fix the broken and unused binding
@Documentation/devicetree/bindings/cpufreq/arm_big_little_dt.txt

Regards,
Sudeep

[1] http://www.spinics.net/lists/cpufreq/msg06563.html

Could you post a non-RFC version of this series? As I had mentioned
earlier in the thread, I dont mind having this pulled in as stage 1 of
the transition to a more elaborate solution.

-- 
Regards,
Nishanth Menon