From: Viresh Kumar <viresh.kumar@linaro.org>
To: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Cc: linaro-kernel@lists.linaro.org, linux-pm@vger.kernel.org,
Kristen Carlson Accardi <kristen@linux.intel.com>,
open list <linux-kernel@vger.kernel.org>,
Sudeep Holla <sudeep.holla@arm.com>
Subject: Re: [PATCH] cpufreq: pass policy to ->get() driver callback
Date: Thu, 10 Sep 2015 06:52:22 +0530 [thread overview]
Message-ID: <20150910012222.GN5266@linux> (raw)
In-Reply-To: <11470100.cEo24Tpcgr@vostro.rjw.lan>
On 10-09-15, 03:41, Rafael J. Wysocki wrote:
> I see one. That unfortunately is the acpi-cpufreq driver, but it still is one.
Hmm..
> Well, cpufreq_generic_get() does _get_raw(), so I suppose acpi-cpufreq may
> do that too?
Yeah, it can.
> > need to get the policy back and so do
> > cpufreq_cpu_get(cpu) on the cpu passed as argument to ->get().
> >
> > It would be better if we pass them 'policy' directly and drivers can use
> > policy->cpu if that's all they need.
>
> Passing a pointer and dereferencing it is generally less efficient than passing
> a number. Before the patch the core has to do the dereference before calling
> ->get, so it likely doesn't matter here, but the code churn from this change
> is quite substantial and the benefit from it is in the noise IMO.
Hmm.. Actually almost every other callback (bios_limit() is another
one), passes the policy to the driver, and I thought always passing
the policy will make it more symmetrical. And the expectation that the
cpufreq drivers wouldn't need to use policy from the ->get() callback
would be wrong. Even if there are only few users today. One is the
acpi-cpufreq driver and others are the ones, that are using
cpufreq_generic_get() :)
> Overall, we need to talk about the design aspect of cpufreq, because there
> are much more significant issues in it than things like this one.
I agree.
--
viresh
next prev parent reply other threads:[~2015-09-10 1:22 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-31 10:44 [PATCH] cpufreq: pass policy to ->get() driver callback Viresh Kumar
2015-07-31 10:44 ` Viresh Kumar
2015-09-03 4:45 ` Viresh Kumar
2015-09-04 14:50 ` Rafael J. Wysocki
2015-09-10 1:41 ` Rafael J. Wysocki
2015-09-10 1:22 ` Viresh Kumar [this message]
2015-09-10 21:36 ` Rafael J. Wysocki
2015-09-11 16:18 ` Viresh Kumar
2015-09-15 7:39 ` Viresh Kumar
2015-09-15 7:58 ` Viresh Kumar
2015-09-16 1:30 ` Rafael J. Wysocki
2015-09-10 21:40 ` Rafael J. Wysocki
2015-09-10 21:59 ` Rafael J. Wysocki
2015-09-15 7:54 ` Viresh Kumar
2015-09-16 1:42 ` Rafael J. Wysocki
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=20150910012222.GN5266@linux \
--to=viresh.kumar@linaro.org \
--cc=kristen@linux.intel.com \
--cc=linaro-kernel@lists.linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=rjw@rjwysocki.net \
--cc=sudeep.holla@arm.com \
/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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.