On 11/18/2013 09:22 AM, Viresh Kumar wrote: > 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? as is - though manually applied ;) > >> 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. depends on how we look at it.. if we consider freq_table as a list of valid frequencies, anything that is not in there is an invalid entry. why should stat support it when freq_table is enforced by cpufreq layer? > > 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.. yeah, I guessed that.. no strong feelings other wise.. > > 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.. :) -> https://patchwork.kernel.org/patch/3192211/ shows how confused my git am feels ;) -- Regards, Nishanth Menon -- 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
