Re: [PATCH] cpufreq: stats: Do not populate stats when policy->cur has no exact match

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 18 November 2013 20:38, Nishanth Menon <nm@xxxxxx> 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 cpufreq" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Kernel Devel]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Forum]     [Linux SCSI]

  Powered by Linux