[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAKohpokzk2Zr7G+GV9d9Bc73WJHNMg01dfAJcxbwCGKFt9BpOw@mail.gmail.com>
Date: Mon, 18 Nov 2013 20:52:02 +0530
From: Viresh Kumar <viresh.kumar@...aro.org>
To: Nishanth Menon <nm@...com>
Cc: "Rafael J. Wysocki" <rjw@...ysocki.net>,
"cpufreq@...r.kernel.org" <cpufreq@...r.kernel.org>,
"linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Carlos Hernandez <ceh@...com>,
Tobias Diedrich <ranma+xen@...edrich.de>,
Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>,
Dave Jones <davej@...hat.com>
Subject: Re: [PATCH] cpufreq: stats: Do not populate stats when policy->cur
has no exact match
On 18 November 2013 20:38, Nishanth Menon <nm@...com> wrote:
> On 11/15/2013 11:22 PM, viresh kumar wrote:
>> I have a untested patch for this. If this looks okay, Nishant can you please try
>> below patch? With some fixups from your side :)
>
> http://pastebin.mozilla.org/3628975
>
> I agree that it does show something
Were you required to update it or fix it? Or you used it as is?
> but would we not rather prefer to
> stick with the entries available in freq_table than have to deal with
> invalid frequencies that may be provided by the driver? for example:
> how do we in stat know that there will only be one invalid frequency
> request?
We don't have to. Actually there is nothing like an invalid freq, as system
is able to run with it. Its only if kernel is allowed to switch to that
frequency or not.
This information will be useful for platform developers to know that kernel
was running on some out of freq-table freq for some time, what that
frequency was their job to find out and kernel doesn't need to print all
out of range frequencies. Keeping a single entry for that is more than
sufficient..
Though I personally didn't like: 4294967295 to be printed there.. Will
see if I can improve that, but its obviously looks better than failing
in cpufreq-stats..
> there are some patch wrapping that thunderbird tends to do - I prefer
> mutt that way, when I need to send inline patches :).
There are steps in Documentation/email-clients.txt to get that fixed.. I
have used thunderbird for several years and never found anything
wrong with sending inline patches..
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists