On Mon, 3 Aug 2015 08:43:25 +0530 Viresh Kumar <viresh.ku...@linaro.org> wrote:
> On 01-08-15, 17:04, Viresh Kumar wrote: > > On 31-07-15, 08:30, Radivoje Jovanovic wrote: > > > > I agree with you that this patch is trivial for the current > > > implementation since the notifier, as it is currently, will > > > enforce cpu_cooling policy change at every CPUFREQ_ADJUST which > > > would cause problems in our current implementation. In our > > > implementation there is a cpufreq driver that will also change > > > policies during CPUFREQ_ADJUST, once the request comes from the > > > underlying FW so there would be a fight who gets there first > > > since cpu_cooling will change the policy in CPUFREQ_ADJUST > > > notifier_chain and the driver would do the same thing. > > Okay, I had a detailed look this morning. cpufreq-notifier is designed > this way that policy->max can be updated by drivers.. So, that's fine. > > Now coming to your problem. So, there are two users: fw and thermal, > which can affect policy->max. Now, both of them need to respect the > limits set by others and only decrease policy->max from the notifier > if it doesn't suit them. > > I think it should work pretty well, unless you know you have triggered > a corner case somewhere, that I am not able to imagine. > > Please let me know in case I am wrong. > I will port the upstream driver to our platfrom, test for all corner cases and update this thread once I have the data Thank you for all the help -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
