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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On 07/08/13 17:17, Mark Rutland wrote:
> 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).
> 

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


--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]
  Powered by Linux