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? Thanks, Thomas. > > Regards, > Nishanth Menon -- 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
