Re: [RFC] cpufreq: Add ->get_rate() driver callback
On Thursday, July 30, 2015 03:17:21 PM Viresh Kumar wrote: > On 10-07-15, 01:26, Rafael J. Wysocki wrote: > > *You* can do them faily quickly. Say if all of the outstanding cpufreq > > patches are queued up for 4.3, then it will be the time to submit more. > > Otherwise I'll just have an ever growing queue of patches to process > > which won't speed up things at all. > > Lots of pending stuff is already committed. Would you like me to send > these now? OK > Also, how should I send them? I mean, you want separate patches for > drivers? Or all of them in a single patch. This is how stats may look: A single patch for all of them, please. Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] cpufreq: Add ->get_rate() driver callback
On 10-07-15, 01:26, Rafael J. Wysocki wrote: > *You* can do them faily quickly. Say if all of the outstanding cpufreq > patches are queued up for 4.3, then it will be the time to submit more. > Otherwise I'll just have an ever growing queue of patches to process > which won't speed up things at all. Lots of pending stuff is already committed. Would you like me to send these now? Also, how should I send them? I mean, you want separate patches for drivers? Or all of them in a single patch. This is how stats may look: drivers/cpufreq/acpi-cpufreq.c | 7 --- drivers/cpufreq/arm_big_little.c | 11 --- drivers/cpufreq/at32ap-cpufreq.c | 2 +- drivers/cpufreq/blackfin-cpufreq.c | 6 +++--- drivers/cpufreq/cpufreq-dt.c | 2 +- drivers/cpufreq/cpufreq-nforce2.c | 8 drivers/cpufreq/cris-artpec3-cpufreq.c | 4 ++-- drivers/cpufreq/cris-etraxfs-cpufreq.c | 4 ++-- drivers/cpufreq/davinci-cpufreq.c | 2 +- drivers/cpufreq/dbx500-cpufreq.c | 2 +- drivers/cpufreq/e_powersaver.c | 5 +++-- drivers/cpufreq/elanfreq.c | 6 +++--- drivers/cpufreq/exynos-cpufreq.c | 2 +- drivers/cpufreq/exynos5440-cpufreq.c | 2 +- drivers/cpufreq/gx-suspmod.c | 6 +++--- drivers/cpufreq/ia64-acpi-cpufreq.c| 5 +++-- drivers/cpufreq/imx6q-cpufreq.c| 2 +- drivers/cpufreq/integrator-cpufreq.c | 5 +++-- drivers/cpufreq/intel_pstate.c | 6 +++--- drivers/cpufreq/kirkwood-cpufreq.c | 5 +++-- drivers/cpufreq/longhaul.c | 6 +++--- drivers/cpufreq/longrun.c | 6 +++--- drivers/cpufreq/loongson2_cpufreq.c| 2 +- drivers/cpufreq/ls1x-cpufreq.c | 2 +- drivers/cpufreq/maple-cpufreq.c| 4 ++-- drivers/cpufreq/omap-cpufreq.c | 2 +- drivers/cpufreq/p4-clockmod.c | 7 +++ drivers/cpufreq/pcc-cpufreq.c | 5 +++-- drivers/cpufreq/pmac32-cpufreq.c | 4 ++-- drivers/cpufreq/pmac64-cpufreq.c | 4 ++-- drivers/cpufreq/powernow-k6.c | 4 ++-- drivers/cpufreq/powernow-k7.c | 6 +++--- drivers/cpufreq/powernow-k8.c | 5 +++-- drivers/cpufreq/powernv-cpufreq.c | 8 drivers/cpufreq/pxa2xx-cpufreq.c | 4 ++-- drivers/cpufreq/pxa3xx-cpufreq.c | 4 ++-- drivers/cpufreq/qoriq-cpufreq.c| 2 +- drivers/cpufreq/s3c2416-cpufreq.c | 6 +++--- drivers/cpufreq/s3c24xx-cpufreq.c | 2 +- drivers/cpufreq/s3c64xx-cpufreq.c | 2 +- drivers/cpufreq/s5pv210-cpufreq.c | 2 +- drivers/cpufreq/sa1100-cpufreq.c | 7 ++- drivers/cpufreq/sa1110-cpufreq.c | 7 ++- drivers/cpufreq/sc520_freq.c | 4 ++-- drivers/cpufreq/sh-cpufreq.c | 8 drivers/cpufreq/sparc-us2e-cpufreq.c | 5 +++-- drivers/cpufreq/sparc-us3-cpufreq.c| 5 +++-- drivers/cpufreq/spear-cpufreq.c| 2 +- drivers/cpufreq/speedstep-centrino.c | 5 +++-- drivers/cpufreq/speedstep-ich.c| 7 --- drivers/cpufreq/speedstep-smi.c| 6 +++--- drivers/cpufreq/tegra-cpufreq.c| 2 +- drivers/cpufreq/unicore2-cpufreq.c | 2 +- 53 files changed, 132 insertions(+), 107 deletions(-) -- viresh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] cpufreq: Add ->get_rate() driver callback
On 10 July 2015 at 04:56, Rafael J. Wysocki wrote: > *You* can do them faily quickly. Say if all of the outstanding cpufreq > patches are queued up for 4.3, then it will be the time to submit more. > Otherwise I'll just have an ever growing queue of patches to process > which won't speed up things at all. Ack. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] cpufreq: Add ->get_rate() driver callback
On Thursday, July 09, 2015 10:29:02 AM Viresh Kumar wrote: > On 09-07-15, 01:41, Rafael J. Wysocki wrote: > > On Wednesday, July 08, 2015 04:07:32 PM Viresh Kumar wrote: > > > CPUFreq drivers today support a ->get(cpu) callback, which returns > > > current rate of a CPU. The problem with ->get() is that it takes a cpu > > > number as parameter and this unnecessarily makes things complex. > > > > > > Firstly the core gets the cpu number by doing operation 'policy->cpu' on > > > the policy and then many drivers need to get the policy back and so do > > > cpufreq_cpu_get(cpu) on the passed cpu. > > > > > > As cpufreq core works on policies, it would be better if we pass them > > > 'policy' directly and drivers can use policy->cpu if that's all they > > > need. > > > > > > Hence, this patch adds in another callback, ->get_rate() which does > > > exactly the same work as ->get(), just that we pass 'policy' as > > > parameter instead of 'cpu'. > > > > > > The plan is to migrate all drivers to this new callback and remove > > > ->get() after that. > > > > > > Signed-off-by: Viresh Kumar > > > --- > > > Hi Rafael, > > > > > > I hope you are fine with this stuff :), once you approve I will get > > > other patches to migrate existing drivers to this interface. > > > > I'm generally fine with it, but please target it at 4.4 at the earliest. > > Sure, but I was a bit curious on why 4.4 and not 4.3 ? I already have 20+ cpufreq patches from you for 4.3 needing my attention, not to mention the Ashwin's CPPC series. > as we are still at 4.2-rc1 today, and these patches can be done fairly > quickly. *You* can do them faily quickly. Say if all of the outstanding cpufreq patches are queued up for 4.3, then it will be the time to submit more. Otherwise I'll just have an ever growing queue of patches to process which won't speed up things at all. Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] cpufreq: Add ->get_rate() driver callback
On 09-07-15, 01:41, Rafael J. Wysocki wrote: > On Wednesday, July 08, 2015 04:07:32 PM Viresh Kumar wrote: > > CPUFreq drivers today support a ->get(cpu) callback, which returns > > current rate of a CPU. The problem with ->get() is that it takes a cpu > > number as parameter and this unnecessarily makes things complex. > > > > Firstly the core gets the cpu number by doing operation 'policy->cpu' on > > the policy and then many drivers need to get the policy back and so do > > cpufreq_cpu_get(cpu) on the passed cpu. > > > > As cpufreq core works on policies, it would be better if we pass them > > 'policy' directly and drivers can use policy->cpu if that's all they > > need. > > > > Hence, this patch adds in another callback, ->get_rate() which does > > exactly the same work as ->get(), just that we pass 'policy' as > > parameter instead of 'cpu'. > > > > The plan is to migrate all drivers to this new callback and remove > > ->get() after that. > > > > Signed-off-by: Viresh Kumar > > --- > > Hi Rafael, > > > > I hope you are fine with this stuff :), once you approve I will get > > other patches to migrate existing drivers to this interface. > > I'm generally fine with it, but please target it at 4.4 at the earliest. Sure, but I was a bit curious on why 4.4 and not 4.3 ? as we are still at 4.2-rc1 today, and these patches can be done fairly quickly. -- viresh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] cpufreq: Add ->get_rate() driver callback
On Wednesday, July 08, 2015 04:07:32 PM Viresh Kumar wrote:
> CPUFreq drivers today support a ->get(cpu) callback, which returns
> current rate of a CPU. The problem with ->get() is that it takes a cpu
> number as parameter and this unnecessarily makes things complex.
>
> Firstly the core gets the cpu number by doing operation 'policy->cpu' on
> the policy and then many drivers need to get the policy back and so do
> cpufreq_cpu_get(cpu) on the passed cpu.
>
> As cpufreq core works on policies, it would be better if we pass them
> 'policy' directly and drivers can use policy->cpu if that's all they
> need.
>
> Hence, this patch adds in another callback, ->get_rate() which does
> exactly the same work as ->get(), just that we pass 'policy' as
> parameter instead of 'cpu'.
>
> The plan is to migrate all drivers to this new callback and remove
> ->get() after that.
>
> Signed-off-by: Viresh Kumar
> ---
> Hi Rafael,
>
> I hope you are fine with this stuff :), once you approve I will get
> other patches to migrate existing drivers to this interface.
I'm generally fine with it, but please target it at 4.4 at the earliest.
> drivers/cpufreq/cpufreq.c | 50
> ---
> include/linux/cpufreq.h | 1 +
> 2 files changed, 35 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> index b612411655f9..b66e169601e8 100644
> --- a/drivers/cpufreq/cpufreq.c
> +++ b/drivers/cpufreq/cpufreq.c
> @@ -154,6 +154,20 @@ void disable_cpufreq(void)
> }
> static DEFINE_MUTEX(cpufreq_governor_mutex);
>
> +/* Operations for ->get() and ->get_rate() operations */
> +static inline bool driver_supports_get_rate(void)
> +{
> + return cpufreq_driver->get || cpufreq_driver->get_rate;
> +}
> +
> +static inline unsigned int policy_get_rate(struct cpufreq_policy *policy)
> +{
> + if (cpufreq_driver->get)
> + return cpufreq_driver->get(policy->cpu);
> + else
> + return cpufreq_driver->get_rate(policy);
> +}
> +
> bool have_governor_per_policy(void)
> {
> return !!(cpufreq_driver->flags & CPUFREQ_HAVE_GOVERNOR_PER_POLICY);
> @@ -596,8 +610,9 @@ static ssize_t show_scaling_cur_freq(struct
> cpufreq_policy *policy, char *buf)
> {
> ssize_t ret;
>
> - if (cpufreq_driver && cpufreq_driver->setpolicy && cpufreq_driver->get)
> - ret = sprintf(buf, "%u\n", cpufreq_driver->get(policy->cpu));
> + if (cpufreq_driver && cpufreq_driver->setpolicy &&
> + driver_supports_get_rate())
> + ret = sprintf(buf, "%u\n", policy_get_rate(policy));
> else
> ret = sprintf(buf, "%u\n", policy->cur);
> return ret;
> @@ -1032,7 +1047,7 @@ static int cpufreq_add_dev_interface(struct
> cpufreq_policy *policy,
> return ret;
> drv_attr++;
> }
> - if (cpufreq_driver->get) {
> + if (driver_supports_get_rate()) {
> ret = sysfs_create_file(&policy->kobj, &cpuinfo_cur_freq.attr);
> if (ret)
> return ret;
> @@ -1313,10 +1328,10 @@ static int cpufreq_add_dev(struct device *dev, struct
> subsys_interface *sif)
> write_unlock_irqrestore(&cpufreq_driver_lock, flags);
> }
>
> - if (cpufreq_driver->get && !cpufreq_driver->setpolicy) {
> - policy->cur = cpufreq_driver->get(policy->cpu);
> + if (driver_supports_get_rate() && !cpufreq_driver->setpolicy) {
> + policy->cur = policy_get_rate(policy);
> if (!policy->cur) {
> - pr_err("%s: ->get() failed\n", __func__);
> + pr_err("%s: ->get_rate() failed\n", __func__);
> goto err_get_freq;
> }
> }
> @@ -1594,14 +1609,17 @@ unsigned int cpufreq_quick_get(unsigned int cpu)
> struct cpufreq_policy *policy;
> unsigned int ret_freq = 0;
>
> - if (cpufreq_driver && cpufreq_driver->setpolicy && cpufreq_driver->get)
> - return cpufreq_driver->get(cpu);
> -
> policy = cpufreq_cpu_get(cpu);
> - if (policy) {
> + if (!policy)
> + return 0;
> +
> + if (cpufreq_driver && cpufreq_driver->setpolicy &&
> + driver_supports_get_rate())
> + ret_freq = policy_get_rate(policy);
> + else
> ret_freq = policy->cur;
> - cpufreq_cpu_put(policy);
> - }
> +
> + cpufreq_cpu_put(policy);
>
> return ret_freq;
> }
> @@ -1631,10 +1649,10 @@ static unsigned int __cpufreq_get(struct
> cpufreq_policy *policy)
> {
> unsigned int ret_freq = 0;
>
> - if (!cpufreq_driver->get)
> + if (!driver_supports_get_rate())
> return ret_freq;
>
> - ret_freq = cpufreq_driver->get(policy->cpu);
> + ret_freq = policy_get_rate(policy);
>
> /* Updating inactive policies is invalid, so avoid doing that. */
> if (unlikely(policy_is_inactive(policy)))
>
