From: Jon Mason <email@example.com> To: Sudeep Holla <firstname.lastname@example.org> Cc: Russell King <email@example.com>, firstname.lastname@example.org, linux-arm-kernel <email@example.com> Subject: Re: [RFC 1/1] ARM: print MHz in /proc/cpuinfo Date: Thu, 9 Jun 2016 13:36:42 -0400 [thread overview] Message-ID: <CAC3K-4rTMy4n0u1Lo5KQKMtGAeH1uE1St3D71YwPVYCJs4+U6g@mail.gmail.com> (raw) In-Reply-To: <firstname.lastname@example.org> On Thu, Jun 9, 2016 at 5:09 AM, Sudeep Holla <email@example.com> wrote: > > > On 08/06/16 20:31, Jon Mason wrote: >> >> On Wed, Jun 08, 2016 at 09:34:06AM +0100, Sudeep Holla wrote: >>> >>> >>> >>> On 07/06/16 22:08, Jon Mason wrote: >>>> >>>> Query the CPU core clock in the device tree to determine the core clock >>>> speed. >>> >>> >>> How do guarantee that it's the current frequency of the CPU ? >> >> >> I am basing it on the assumption (perhaps incorrect) that the clock in >> the CPU DT corresponds to the one determining the CPU clock rate. And, >> that this clock rate is accurate in describing the speed at which the >> CPU is currently running. >> > > As you already noticed, it's not always correct. > > [..] > >>> >>> What if they just don't have in DT but have DVFS support ? >> >> >> This can be extended to cover DVFS or SMC calls or anything else. >> This was simply a first step to cover what appeared to be the most >> prevalent case. >> > > Using DVFS/CPUFreq makes this DT based approach irrelevant. > >>> Also whey do we need this support when the user-space can query the >>> CPUFreq sysfs which is more accurate and maintains the current running >>> frequency ? >> >> >> This is exactly what x86 is doing to provide its value in >> /proc/cpuinfo. I could easily augment this patch to call >> cpufreq_quick_get(), if it returns 0, then call clk_get_rate(). If >> both return 0, then simply not print out anything (which would cover >> all of the possibilities). Or, I could have it just call >> cpufreq_quick_get() to get the value. >> > > Agree x86 has, may be for legacy reasons. It even has CPUFreq sysfs > entries which is architecture agnostic while /proc/cpuinfo is more > architecture based. So applications that want to be portable across > architectures must choose the generic CPUFreq sysfs path rather than > some x86 based cpuinfo. Thank you for educating me. I am taking this (and RMK's comment) as any modification to add CPU speed to /proc/cpuinfo is not welcomed, anyone who wants to query this should instead look at cpufreq in sysfs, and any dev who wants to add such a thing should look into writing a driver in drivers/cpufreq/. Thanks, Jon > > -- > Regards, > Sudeep
next prev parent reply other threads:[~2016-06-09 17:36 UTC|newest] Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top 2016-06-07 21:08 [RFC 0/1] " Jon Mason 2016-06-07 21:08 ` [RFC 1/1] " Jon Mason 2016-06-08 8:34 ` Sudeep Holla 2016-06-08 19:31 ` Jon Mason 2016-06-09 9:09 ` Sudeep Holla 2016-06-09 17:36 ` Jon Mason [this message] 2016-06-07 22:18 ` [RFC 0/1] " Russell King - ARM Linux 2016-06-07 22:58 ` Jon Mason 2016-07-02 23:58 ` Jon Masters 2016-07-03 16:54 ` Russell King - ARM Linux 2016-07-03 18:49 ` Andrew Lunn 2016-07-03 19:10 ` Russell King - ARM Linux 2016-07-18 10:02 ` Pavel Machek
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=CAC3K-4rTMy4n0u1Lo5KQKMtGAeH1uE1St3D71YwPVYCJs4+U6g@mail.gmail.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --subject='Re: [RFC 1/1] ARM: print MHz in /proc/cpuinfo' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).