Hi Thomas, Sudeep, > On Sat, Feb 8, 2014 at 1:11 AM, Nishanth Menon <nm@xxxxxx> wrote: > > On Fri, Feb 7, 2014 at 12:02 PM, Sudeep Holla > > <Sudeep.Holla@xxxxxxx> wrote: > >> On 07/02/14 17:37, Nishanth Menon wrote: > >>> On Fri, Feb 7, 2014 at 11:31 AM, Sudeep Holla > >>> <Sudeep.Holla@xxxxxxx> wrote: > >> > >> [...] > >> > >>>> Yes I think its counter-intuitive as it's visible to the > >>>> userspace(list of frequencies and the boost parameters are > >>>> exposed through sysfs) > >>> > >>> That will be a different problem -> as currently every single > >>> frequency in the cpufreq list has ability to be marked as boost > >>> frequency - if userspace does not maintain that, then, IMHO, fix > >>> the userspace :D > >>> > >> > >> /sys/devices/system/cpu/cpu*/cpufreq/scaling_available_frequencies > >> gives the list of frequencies based on the state of the boost > >> feature at anytime. > >> > >> Intuitively the list without boost shouldn't have any frequency > >> above the range when it's enabled :), that's what I was referring > >> to. So I am not talking about any issue with user-space > >> maintenance. > > Fair enough - but i still think it has nothing to do with dt binding > > itself -> and i think the discussion we've had should be good for > > the binding provided in this patch.. I hope.. if documentation > > needs a bit of better explanation to prevent a repeat of the same > > discussion at a later point of time, now might be a good time to > > add it in. > > The term boost and over-clocking have been described in the bindings > document as being the same. Since the term over-clocking refers to > running a CPU beyond normal operating frequencies, I tend to agree > with Sudeep that it is not intuitive if a normal operating frequency > is greater than a boost mode frequency. > > Otherwise, when userspace does "echo 1 > > /sys/devices/system/cpu/cpufreq/boost", what is it supposed to mean. I > think the original intent of boost mode patches was to allow CPU to > operate at frequencies greater than the normal operating frequencies. > > Lukasz, how would you want this to be handled? Please consider an example: normal-freqs: 1400000, 1200000, 1000000, 800000, 600000, 400000, 200000 [1] boost-freqs: 1700000, 1600000, 1500000. [2] All those freqs shall be represented as OPPs freq and voltage tuple. Best would be to specify all the boost-freqs as: boost-freqs = <1700000 1600000 1500000> to be prepared for future quirks or problems (or special cases which might show up latter). If anybody can foresee any potential threads - like platform on which boost freqs are 1700000 and 1500000, but not 1600000, then please share this information. However, I think that it would be also acceptable to specify only: boost-freq = <1500000> and mark all freqs greater or equal to it as CPUFREQ_BOOST_FREQ. If there aren't any potential problems, then I think the second option would be a good solution (we would have only one BOOST attribute stored at CPUs DTS node). > > Thanks, > Thomas. > > > > > Regards, > > Nishanth Menon > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@xxxxxxxxxxxxxxxxxxx > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- Best regards, Lukasz Majewski Samsung R&D Institute Poland (SRPOL) | Linux Platform Group -- 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
