On 08/20/2013 05:00 AM, Sudeep KarkadaNagesha wrote: > 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 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 -- To unsubscribe from this list: send the line "unsubscribe cpufreq" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
