On Fri, Jan 06, 2012 at 09:38:39PM +0200, Antti P Miettinen wrote: > [seems that posting via gmane is broken - resending (heehee - I do > resent the gmane problem :) manually via mail - sorry if you get > duplicates] FWIW I've been having odd email behavior WRT linux-pm. I'm not sure if its my .procmailrc file or something else. > mark gross <markgross@xxxxxxxxxxx> writes: > > diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c > > index 987a165..4cbd58b 100644 > > --- a/drivers/cpufreq/cpufreq.c > > +++ b/drivers/cpufreq/cpufreq.c > [..] > > + > > + if (policy->min < pm_qos_request(PM_QOS_CPU_THROUGHPUT)) > > + policy->min = pm_qos_request(PM_QOS_CPU_THROUGHPUT); > > > > Consider the following sequence > > - say original min is 100MHz > - PM QoS requests 1GHz minimum > - user requests 500MHz minimum via sysfs > - PM QoS request is canceled > > After this the policy->min will be 1GHz. I'm not really happy with the > min/max save/restore etc but something is needed to enable restoring the > policy min/max when PM QoS constraints dissappear. you are right. If CPUFREQ is to be QoS aware we need to have it save the request from user mode and compute the max between the user request and the pm_qos constraint. --mark _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/linux-pm
