On 10-04-24, 06:22, Lizhe wrote:
> For the exit() callback function returning an int type value.
> this leads many driver authors mistakenly believing that error
> handling can be performed by returning an error code. However.
> the returned value is ignore, and to improve this situation.
> it is
On 25-09-23, 14:02, Rob Herring wrote:
> Use the recently added of_property_read_reg() helper to get the
> untranslated "reg" address value.
>
> Acked-by: Viresh Kumar
> Signed-off-by: Rob Herring
> ---
> v2:
> - Add missing include
> ---
> drivers/c
0, , NULL) < 0)
> return 0;
> /* That works for all keylargos but shall be fixed properly
>* some day... The problem is that it seems we can't rely
Acked-by: Viresh Kumar
--
viresh
5adf0..63b126c6215e 100644
> --- a/drivers/opp/of.c
> +++ b/drivers/opp/of.c
> @@ -13,7 +13,7 @@
> #include
> #include
> #include
> -#include
> +#include
> #include
> #include
> #include
Acked-by: Viresh Kumar
--
viresh
> @@ -10,9 +10,10 @@
>
> #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
>
> +#include
> #include
> #include
> -#include
> +#include
> #include
> #include
> #include
Acked-by: Viresh Kumar
--
viresh
de/linux/cpufreq.h | 1 -
> 10 files changed, 8 insertions(+), 11 deletions(-)
Acked-by: Viresh Kumar
--
viresh
ty_read_bool().
>
> Signed-off-by: Rob Herring
> ---
> drivers/cpufreq/pmac32-cpufreq.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
Acked-by: Viresh Kumar
--
viresh
On 18-06-22, 10:25, Liang He wrote:
> In pmac_cpufreq_init_MacRISC3(), we need to add corresponding
> of_node_put() for the three node pointers whose refcount have
> been incremented by of_find_node_by_name().
>
> Signed-off-by: Liang He
> ---
> drivers/cpufreq/pmac32-cpufreq.c | 4
> 1
> b/drivers/cpufreq/ppc_cbe_cpufreq_pmi.c
> index 037fe23bc6ed..4fba3637b115 100644
> --- a/drivers/cpufreq/ppc_cbe_cpufreq_pmi.c
> +++ b/drivers/cpufreq/ppc_cbe_cpufreq_pmi.c
> @@ -13,9 +13,9 @@
> #include
> #include
> #include
> +#include
>
> #include
> -#include
> #include
> #include
Acked-by: Viresh Kumar
--
viresh
On 23-06-21, 15:45, Michael Ellerman wrote:
> Viresh Kumar writes:
> >
> > Subject: Re: [PATCH V4 3/4] cpufreq: powerenv: Migrate to ->exit() callback
> > instead of ->stop_cpu()
>
> Typo in subject should be "powernv".
Thanks for noticing it :)
--
viresh
callbacks for cpufreq drivers, i.e. stop_cpu() and exit(), as everything
can be done from the exit() callback itself.
Migrate to using the exit() callback instead of stop_cpu().
Signed-off-by: Viresh Kumar
---
V4->V4.1:
- s/powerenv/powernv/
drivers/cpufreq/powernv-cpufreq.c | 23 +-
callbacks for cpufreq drivers, i.e. stop_cpu() and exit(), as everything
can be done from the exit() callback itself.
Migrate to using the exit() callback instead of stop_cpu().
Signed-off-by: Viresh Kumar
---
drivers/cpufreq/powernv-cpufreq.c | 23 +--
1 file changed, 9 inserti
from 5.13-rc7.
- No need to update exit() for intel pstate anymore.
- Remove the stop_cpu() callback completely.
--
Viresh
[1] https://lore.kernel.org/linux-pm/5490292.DvuYhMxLoT@kreacher/
Viresh Kumar (4):
cpufreq: cppc: Migrate to ->exit() callback instead of ->stop_cpu()
cpufreq: in
callbacks for cpufreq drivers, i.e. stop_cpu() and exit(), as everything
can be done from the exit() callback itself.
Migrate to using the exit() callback instead of stop_cpu().
Signed-off-by: Viresh Kumar
---
drivers/cpufreq/powernv-cpufreq.c | 23 +--
1 file changed, 9 inserti
) callback instead of stop_cpu().
The stop_cpu() callback isn't removed from core as it will be reused in
a different way in a separate patchset.
--
Viresh
Viresh Kumar (3):
cpufreq: cppc: Migrate to ->exit() callback instead of ->stop_cpu()
cpufreq: intel_pstate: Migrate to ->exit
On 15-06-21, 08:17, Qian Cai wrote:
> On 6/15/2021 3:50 AM, Viresh Kumar wrote:
> > This is a strange place to get the issue from. And this is a new
> > issue.
>
> Well, it was still the same exercises with CPU online/offline.
>
> >
> >> [ 4
On 15-06-21, 13:20, Viresh Kumar wrote:
> I can see one place where race can happen, i.e. between
> topology_clear_scale_freq_source() and topology_scale_freq_tick(). It
> is possible that sfd->set_freq_scale() may get called for a previously
> set handler as there is no protectio
Hi Qian,
First of all thanks for testing this, I need more of your help to test
this out :)
FWIW, I did test this on my Hikey board today, with some hacks, and
tried multiple insmod/rmmod operations for the driver, and I wasn't
able to reproduce the issue you reported. I did enable the
callbacks for cpufreq drivers, i.e. stop_cpu() and exit(), as everything
can be done from the exit() callback itself.
Migrate to using the exit() callback instead of stop_cpu().
Signed-off-by: Viresh Kumar
---
drivers/cpufreq/powernv-cpufreq.c | 23 +--
1 file changed, 9 inserti
cpu() callbacks in the
cpufreq core, which will be called for each CPU's addition/removal.
A similar call was already available in the cpufreq core, which isn't required
anymore and so its users are migrated to use exit() callback instead.
This is targeted for v5.14-rc1.
--
Viresh
Viresh Kumar
and so left it
for the right people to handle. :)
Acked-by: Viresh Kumar
--
viresh
This flag is set by one of the drivers but it isn't used in the code
otherwise. Remove the unused flag and update the driver.
Signed-off-by: Viresh Kumar
---
Rebased over:
https://lore.kernel.org/lkml/a59bb322b22c247d570b70a8e94067804287623b.1612241683.git.viresh.ku...@linaro.org/
drivers
On 14-01-21, 17:05, Viresh Kumar wrote:
> The "oprofile" user-space tools don't use the kernel OPROFILE support
> any more, and haven't in a long time. User-space has been converted to
> the perf interfaces.
>
> This commits stops building oprofile for powerpc an
On 14-01-21, 17:05, Viresh Kumar wrote:
> The "oprofile" user-space tools don't use the kernel OPROFILE support
> any more, and haven't in a long time. User-space has been converted to
> the perf interfaces.
>
> This commits stops building oprofile for powerpc an
The previous commit already disabled building oprofile, lets remove the
oprofile directory now.
Suggested-by: Christoph Hellwig
Suggested-by: Linus Torvalds
Signed-off-by: Viresh Kumar
---
arch/powerpc/oprofile/Makefile | 19 -
arch/powerpc/oprofile/backtrace.c | 120
uggested-by: Christoph Hellwig
Suggested-by: Linus Torvalds
Signed-off-by: Viresh Kumar
---
arch/powerpc/Kconfig | 1 -
arch/powerpc/Makefile | 2 -
arch/powerpc/configs/44x/akebono_defconfig| 1 -
arch/powerpc/configs/44x/currituck_de
vious prototype for
> ‘powernv_cpufreq_work_fn’ [-Wmissing-prototypes]
>
> Cc: Michael Ellerman
> Cc: Benjamin Herrenschmidt
> Cc: Paul Mackerras
> Cc: linuxppc-dev@lists.ozlabs.org
> Signed-off-by: Lee Jones
> Acked-by: Viresh Kumar
> ---
> drivers/cpufreq/po
On 15-07-20, 07:36, Lee Jones wrote:
> I searched for "include.*platforms/" in drivers/, and was scared off
> this method since no one else does this.
Yeah its not right for generic drivers, but this is very much platform
specific so it is fine here.
--
viresh
On 14-07-20, 20:49, Olof Johansson wrote:
> On Tue, Jul 14, 2020 at 8:07 PM Viresh Kumar wrote:
> >
> > On 14-07-20, 15:50, Lee Jones wrote:
> > > If function callers and providers do not share the same prototypes the
> > > compiler complains of missin
ns(-)
Lee also sent a fix for this, but yours look complete :)
https://lore.kernel.org/lkml/20200714145049.2496163-7-lee.jo...@linaro.org/
Acked-by: Viresh Kumar
--
viresh
e void queue_gpstate_timer(struct
> global_pstate_info *gpstates)
> /**
> * gpstate_timer_handler
> *
> - * @data: pointer to cpufreq_policy on which timer was queued
> + * @t: Timer context used to fetch global pstate info struct
> *
> * This handler brings down the global pstate closer to the local pstate
> * according quadratic equation. Queues a new timer if it is still not equal
Acked-by: Viresh Kumar
--
viresh
cpufreq_reboot_notifier,
> };
>
> -void powernv_cpufreq_work_fn(struct work_struct *work)
> +static void powernv_cpufreq_work_fn(struct work_struct *work)
> {
> struct chip *chip = container_of(work, struct chip, throttle);
> struct cpufreq_policy *policy;
Acked-by: Viresh Kumar
--
viresh
On 14-07-20, 15:50, Lee Jones wrote:
> If function callers and providers do not share the same prototypes the
> compiler complains of missing prototypes. Fix this by moving the
> already existing prototypes out to a mutually convenient location.
>
> Fixes the following W=1 kernel build
.
Acked-by: Viresh Kumar
Signed-off-by: Quentin Perret
Signed-off-by: Viresh Kumar
---
.../platforms/cell/cpufreq_spudemand.c| 26 ++-
drivers/cpufreq/cpufreq_conservative.c| 22
drivers/cpufreq/cpufreq_ondemand.c| 24
pecify default governor on command line
Viresh Kumar (1):
cpufreq: Fix locking issues with governors
.../admin-guide/kernel-parameters.txt | 5 ++
Documentation/admin-guide/pm/cpufreq.rst | 6 +-
.../platforms/cell/cpufreq_spudemand.c| 26 +-
drivers/cpufreq/cpu
.
Acked-by: Viresh Kumar
Signed-off-by: Quentin Perret
Signed-off-by: Viresh Kumar
---
.../platforms/cell/cpufreq_spudemand.c| 26 ++-
drivers/cpufreq/cpufreq_conservative.c| 22
drivers/cpufreq/cpufreq_ondemand.c| 24
ead of the driver registration (Viresh)
Quentin Perret (2):
cpufreq: Register governors at core_initcall
cpufreq: Specify default governor on command line
Viresh Kumar (1):
cpufreq: Fix locking issues with governors
.../admin-guide/kernel-parameters.txt | 5 +
Documentation/admin-guide
On 23-06-20, 15:21, Quentin Perret wrote:
> @@ -2789,7 +2796,13 @@ static int __init cpufreq_core_init(void)
> cpufreq_global_kobject = kobject_create_and_add("cpufreq",
> _subsys.dev_root->kobj);
> BUG_ON(!cpufreq_global_kobject);
>
> + mutex_lock(_governor_mutex);
> + if
efault_governor();
> mutex_unlock(_governor_mutex);
> }
> EXPORT_SYMBOL_GPL(cpufreq_unregister_governor);
> @@ -2789,7 +2796,13 @@ static int __init cpufreq_core_init(void)
> cpufreq_global_kobject = kobject_create_and_add("cpufreq",
> _subsys.dev_root
On 16-06-20, 10:48, Quentin Perret wrote:
> ---8<---
> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> index 0f05caedc320..a9219404e07f 100644
> --- a/drivers/cpufreq/cpufreq.c
> +++ b/drivers/cpufreq/cpufreq.c
> @@ -2340,6 +2340,11 @@ int cpufreq_register_governor(struct
On 16-06-20, 09:31, Quentin Perret wrote:
> Right, so the reason I avoided cpufreq_core_init() was because it is
> called at core_initcall() time, which means I can't really assume the
> governors have been loaded by that time. By waiting for the driver to
> probe before detecting the default gov,
On 15-06-20, 17:55, Quentin Perret wrote:
> +static void cpufreq_get_default_governor(void)
> +{
> + default_governor = cpufreq_parse_governor(cpufreq_param_governor);
> + if (!default_governor) {
> + if (*cpufreq_param_governor)
> + pr_warn("Failed to find
req_powersave.c | 18 +++--
> drivers/cpufreq/cpufreq_userspace.c | 18 +++--
> include/linux/cpufreq.h | 14 ++
> kernel/sched/cpufreq_schedutil.c | 6 +
> 8 files changed, 36 insertions(+), 106 deletions(-)
Acked-by: Viresh Kumar
--
viresh
On 28-04-20, 16:31, Viresh Kumar wrote:
> On 21-04-20, 10:29, Mian Yousaf Kaukab wrote:
> > The driver has to be manually loaded if it is built as a module. It
> > is neither exporting MODULE_DEVICE_TABLE nor MODULE_ALIAS. Moreover,
> > no platform-device is created (and t
s it depends on.
>
> Convert the module to a platform driver with its own alias. Moreover,
> drop whitelisted SOCs. Platform device will be created only for the
> compatible platforms.
>
> Reviewed-by: Yuantian Tang
> Acked-by: Viresh Kumar
> Signed-off-by: Mian Yousaf Kaukab
> -
-
> 1 file changed, 29 insertions(+), 47 deletions(-)
For both patches,
Acked-by: Viresh Kumar
--
viresh
due to Pmax
> capping at chip level")
> Cc: Michael Ellerman
> Cc: Shilpasri G Bhat
> Cc: Preeti U Murthy
> Cc: Viresh Kumar
> Cc: Rafael J. Wysocki
> Cc: linux...@vger.kernel.org
> Cc: linuxppc-dev@lists.ozlabs.org
> Signed-off-by: John Hubbard
> ---
Acked-by: Viresh Kumar
llocating based on CONFIG_NR_CPUS.
>
> Fixes: 053819e0bf840 ("cpufreq: powernv: Handle throttling due to Pmax
> capping at chip level")
> Cc: Shilpasri G Bhat
> Cc: Preeti U Murthy
> Cc: Viresh Kumar
> Cc: Rafael J. Wysocki
> Cc: linux...@vger.kernel.org
> Cc: lin
On 17-10-19, 21:41, John Hubbard wrote:
> On 10/17/19 9:38 PM, Viresh Kumar wrote:
> > On 17-10-19, 21:34, John Hubbard wrote:
> >> On 10/17/19 9:27 PM, Viresh Kumar wrote:
> >>> On 17-10-19, 17:04, John Hubbard wrote:
> >>>> The following bu
On 17-10-19, 21:34, John Hubbard wrote:
> On 10/17/19 9:27 PM, Viresh Kumar wrote:
> > On 17-10-19, 17:04, John Hubbard wrote:
> >> The following build warning occurred on powerpc 64-bit builds:
> >>
> >> drivers/cpufreq/powernv-cpufreq.c: In function 'init_chip
R_CPUS > 256.
>
> Fix both problems by dynamically allocating based on CONFIG_NR_CPUS.
>
> Fixes: 053819e0bf840 ("cpufreq: powernv: Handle throttling due to Pmax
> capping at chip level")
> Cc: Shilpasri G Bhat
> Cc: Preeti U Murthy
> Cc: Viresh Kumar
> Cc: Rafael J.
The cpufreq core now takes the min/max frequency constraints via QoS
requests and the CPUFREQ_ADJUST notifier shall get removed later on.
Switch over to using the QoS request for maximum frequency constraint
for windfarm_cpufreq_clamp driver.
Signed-off-by: Viresh Kumar
---
drivers/macintosh
;V2:
- Added Acked-by tags
- Reordered to keep cleanups at the bottom
- Rebased over 5.3-rc1
--
viresh
Viresh Kumar (10):
cpufreq: Add policy create/remove notifiers
thermal: cpu_cooling: Switch to QoS requests instead of cpufreq
notifier
powerpc: macintosh: Switch to QoS requests inst
Wen Yang
> Cc: "Rafael J. Wysocki"
> Cc: Viresh Kumar
> Cc: Michael Ellerman
> Cc: linuxppc-dev@lists.ozlabs.org
> Cc: linux...@vger.kernel.org
> Cc: linux-ker...@vger.kernel.org
> ---
> v7: adapt to commit ("cpufreq: Make cpufreq_generic_init(
On 16-07-19, 12:06, Rafael J. Wysocki wrote:
> On Tue, Jul 16, 2019 at 11:49 AM Viresh Kumar wrote:
> >
> > Hello,
> >
> > Now that cpufreq core supports taking QoS requests for min/max cpu
> > frequencies, lets migrate rest of the users to using them in
The cpufreq core now takes the min/max frequency constraints via QoS
requests and the CPUFREQ_ADJUST notifier shall get removed later on.
Switch over to using the QoS request for maximum frequency constraint
for windfarm_cpufreq_clamp driver.
Signed-off-by: Viresh Kumar
---
drivers/macintosh
CPUFREQ_CREATE_POLICY and
CPUFREQ_REMOVE_POLICY events to it for the acpi stuff specifically. So
the policy notifiers aren't completely removed.
Boot tested on my x86 PC and ARM hikey board. Nothing looked broken :)
This has already gone through build bot for a few days now.
--
viresh
Viresh Kumar (10):
cpufreq
On 16-07-19, 16:26, wen.yan...@zte.com.cn wrote:
> Okay thank you.
> Now this patch
> (https://lore.kernel.org/lkml/ee8cf5fb4b4a01fdf9199037ff6d835b935cfd13.1562902877.git.viresh.ku...@linaro.org/)
>
> seems to have not been merged into the linux-next.
>
> In order to avoid code conflicts, we
It always returns 0 (success) and its return type should really be void.
Over that, many drivers have added error handling code based on its
return value, which is not required at all.
change its return type to void and update all the callers.
Signed-off-by: Viresh Kumar
---
V2->V3:
- Upd
It always returns 0 (success) and its return type should really be void.
Over that, many drivers have added error handling code based on its
return value, which is not required at all.
change its return type to void and update all the callers.
Signed-off-by: Viresh Kumar
---
V1->V2:
- Fi
Wen Yang
> Cc: "Rafael J. Wysocki"
> Cc: Viresh Kumar
> Cc: Michael Ellerman
> Cc: linuxppc-dev@lists.ozlabs.org
> Cc: linux...@vger.kernel.org
> Cc: linux-ker...@vger.kernel.org
> ---
> v6: keep the blank line and fix warning: label 'out_unmap_sdcpwr' defin
It always returns 0 (success) and its return type should really be void.
Over that, many drivers have added error handling code based on its
return value, which is not required at all.
change its return type to void and update all the callers.
Signed-off-by: Viresh Kumar
---
drivers/cpufreq
Wen Yang
> Cc: "Rafael J. Wysocki"
> Cc: Viresh Kumar
> Cc: Michael Ellerman
> Cc: linuxppc-dev@lists.ozlabs.org
> Cc: linux...@vger.kernel.org
> Cc: linux-ker...@vger.kernel.org
> ---
> v5: put together the code to get, use, and release cpu device_node.
>
Wen Yang
> Cc: "Rafael J. Wysocki"
> Cc: Viresh Kumar
> Cc: linuxppc-dev@lists.ozlabs.org
> Cc: linux...@vger.kernel.org
> Cc: linux-ker...@vger.kernel.org
> ---
> v4: restore the blank line.
I don't find it restored in the below code.
> v3: fix a leaked reference
Wen Yang
> Cc: "Rafael J. Wysocki"
> Cc: Viresh Kumar
> Cc: linuxppc-dev@lists.ozlabs.org
> Cc: linux...@vger.kernel.org
> Cc: linux-ker...@vger.kernel.org
> ---
> v3: fix a leaked reference.
> v2: clean up the code according to the advice of viresh.
>
> dri
Wen Yang
> Cc: "Rafael J. Wysocki"
> Cc: Viresh Kumar
> Cc: linuxppc-dev@lists.ozlabs.org
> Cc: linux...@vger.kernel.org
> Cc: linux-ker...@vger.kernel.org
> ---
> v2: clean up the code according to the advice of viresh.
>
> drivers/cpufreq/pasemi-cpufreq.c |
Wen Yang
> Cc: "Rafael J. Wysocki"
> Cc: Viresh Kumar
> Cc: linuxppc-dev@lists.ozlabs.org
> Cc: linux...@vger.kernel.org
> Cc: linux-ker...@vger.kernel.org
> ---
> drivers/cpufreq/pasemi-cpufreq.c | 10 ++
> 1 file changed, 6 insertions(+), 4 deletions(-)
On 16-02-19, 12:06, Yangtao Li wrote:
> kmalloc() could fail, so insert a check of its return value. And
> if it fails, returns -ENOMEM.
>
> And remove (struct pstate_idx_revmap_data *) to fix coccinelle WARNING
> by the way.
>
> WARNING: casting value returned by memory allocation function to
On 03-12-18, 15:32, Rob Herring wrote:
> Convert SPEAr SoC bindings to DT schema format using json-schema.
>
> Cc: Viresh Kumar
> Cc: Shiraz Hashim
> Cc: Mark Rutland
> Cc: devicet...@vger.kernel.org
> Signed-off-by: Rob Herring
> ---
> .../devicetree/bindings
On 23-11-18, 08:33, Yangtao Li wrote:
> of_find_node_by_path() acquires a reference to the node
> returned by it and that reference needs to be dropped by its caller.
> g5_neo2_cpufreq_init() doesn't do that, so fix it.
>
> Signed-off-by: Yangtao Li
> Acked-by: Viresh Kuma
anges in v2
> -update changelog
> ---
> drivers/cpufreq/powernv-cpufreq.c | 17 +++--
> 1 file changed, 11 insertions(+), 6 deletions(-)
Acked-by: Viresh Kumar
--
viresh
NULL) {
> pr_err("Can't find required platform function\n");
Acked-by: Viresh Kumar
--
viresh
static int dfs_set_cpu_speed(int low_speed)
> }
>
> /* set frequency */
> -#ifdef CONFIG_6xx
> +#ifdef CONFIG_PPC_BOOK3S_32
> low_choose_7447a_dfs(low_speed);
> #endif
> udelay(100);
Acked-by: Viresh Kumar
--
viresh
> { .compatible = "fsl,p4080-clockgen", },
> { .compatible = "fsl,qoriq-clockgen-1.0", },
> { .compatible = "fsl,qoriq-clockgen-2.0", },
Acked-by: Viresh Kumar
--
viresh
ta...@vger.kernel.org>[4.8+]
> Reported-by: Nicholas Piggin <npig...@gmail.com>
> Reported-by: Pridhiviraj Paidipeddi <ppaid...@linux.vnet.ibm.com>
> Signed-off-by: Shilpasri G Bhat <shilpa.b...@linux.vnet.ibm.com>
> ---
> Changes from V2:
> - Remove the c
On 25-04-18, 15:32, Shilpasri G Bhat wrote:
> Hi,
>
> On 04/25/2018 02:47 PM, Viresh Kumar wrote:
> > On 25-04-18, 14:32, Shilpasri G Bhat wrote:
> >> gpstate_timer_handler() uses synchronous smp_call to set the pstate
> >> on the requested core.
On 25-04-18, 14:32, Shilpasri G Bhat wrote:
> gpstate_timer_handler() uses synchronous smp_call to set the pstate
> on the requested core. This causes the below hard lockup:
>
> [c03fe566b320] [c01d5340] smp_call_function_single+0x110/0x180
> (unreliable)
> [c03fe566b390]
> return 0;
> }
> @@ -990,7 +1002,8 @@ static void powernv_cpufreq_stop_cpu(struct
> cpufreq_policy *policy)
> freq_data.pstate_id = idx_to_pstate(powernv_pstate_info.min);
> freq_data.gpstate_id = idx_to_pstate(powernv_pstate_info.min);
> smp_call_f
On 26-02-18, 10:38, Viresh Kumar wrote:
> Hi,
>
> A patchset [1] sent last week already updated the cpufreq core to start
> validating cpufreq table if the policy contains a valid
> "policy->freq_table" pointer.
>
> This series updates all such drivers to s
frequency table from powernv driver.
Signed-off-by: Viresh Kumar <viresh.ku...@linaro.org>
---
V1->V2:
- s/powerenv/powernv/
drivers/cpufreq/powernv-cpufreq.c | 11 +++
1 file changed, 3 insertions(+), 8 deletions(-)
diff --git a/drivers/cpufreq/powernv-cpufreq.c
b/drive
On 26-02-18, 22:53, Michael Ellerman wrote:
> Viresh Kumar <viresh.ku...@linaro.org> writes:
> > Subject: Re: [PATCH 15/27] cpufreq: powerenv: Don't validate the frequency
> > table twice
>^
>
frequency table from powerenv driver.
Signed-off-by: Viresh Kumar <viresh.ku...@linaro.org>
---
drivers/cpufreq/powernv-cpufreq.c | 11 +++
1 file changed, 3 insertions(+), 8 deletions(-)
diff --git a/drivers/cpufreq/powernv-cpufreq.c
b/drivers/cpufreq/powernv-cpufreq.c
ind
linaro.org
[2]
https://lkml.kernel.org/r/77d470741dab32c2076a35253b9c0c2f0136583b.1519293292.git.viresh.ku...@linaro.org
[3]
https://lkml.kernel.org/r/6b737a9c285840b4b2036fa51b692ee835664ec8.1519358505.git.viresh.ku...@linaro.org
Viresh Kumar (27):
cpufreq: imx6q: Find max freq from frequency
On 21-02-18, 11:17, Rafael J. Wysocki wrote:
> The driver is expected to call cpufreq_table_validate_and_show() at
> ->init() time and fail ->init() if that fails.
>
> That's kind of fragile, because it depends on the driver to do the right
> thing.
That's exactly what I am trying to explore
On 21-02-18, 10:27, Rafael J. Wysocki wrote:
> To be precise, ->init() should fail as that's where the table is
> created. The registration fails as a result then.
>
> But what if the bug is that ->init() doesn't fail when it should?
>
> I guess the core could double check the frequency table
On 21-02-18, 16:39, Michael Ellerman wrote:
> Viresh Kumar <viresh.ku...@linaro.org> writes:
> > AFAICT, you will get -1 here only if the freq table had no valid
> > frequencies (or the freq table is empty). Why would that happen ?
>
> Bugs?
The cupfreq driver shoul
On 12-02-18, 16:03, Shilpasri G Bhat wrote:
> I agree too. There is no way we can get -1 with initialized cpu frequency
> table.
> We don't initialize powernv-cpufreq if we don't have valid CPU frequency
> entries. Is there any other way to suppress the Coverity tool warning apart
> from
>
On 12-02-18, 15:51, Shilpasri G Bhat wrote:
> This patch fixes the below Coverity warning:
>
> *** CID 182816: Memory - illegal accesses (NEGATIVE_RETURNS)
> /drivers/cpufreq/powernv-cpufreq.c: 1008 in powernv_fast_switch()
> 1002 unsigned int
info.nominal = i;
> - else if (id == pstate_min)
> + if (id == pstate_min)
> powernv_pstate_info.min = i;
>
> if (powernv_pstate_info.wof_enabled && id == pstate_turbo) {
Acked-by: Viresh Kumar <viresh.ku...@linaro.org>
--
viresh
On 13-12-17, 12:27, Gautham R. Shenoy wrote:
> From: "Gautham R. Shenoy" <e...@linux.vnet.ibm.com>
>
> This is a third version of the patch to fix pstate related issues in
> the powernv-cpufreq driver.
Acked-by: Viresh Kumar <viresh.ku...@linaro.org>
--
viresh
On 20-12-17, 12:12, Abhishek Goel wrote:
> diff --git a/drivers/cpufreq/powernv-cpufreq.c
> b/drivers/cpufreq/powernv-cpufreq.c
> index b6d7c4c..fd642bc 100644
> --- a/drivers/cpufreq/powernv-cpufreq.c
> +++ b/drivers/cpufreq/powernv-cpufreq.c
> @@ -37,6 +37,7 @@
> #include /* Required for
On 18-12-17, 10:41, Abhishek wrote:
> We need to do it in this way as the current implementation takes the max of
> the PMSR of the cores. Thus, when the frequency is required to be ramped up,
> it suffices to write to just the local PMSR, but when the frequency is to be
> ramped down, if we don't
+ Gautham,
@Gautham: Can you please help reviewing this one ?
On 13-12-17, 13:49, Abhishek Goel wrote:
> @@ -693,6 +746,8 @@ static int powernv_cpufreq_target_index(struct
> cpufreq_policy *policy,
> {
> struct powernv_smp_call_data freq_data;
> unsigned int cur_msec, gpstate_idx;
o read the correct pstate value.
>
> Signed-off-by: Gautham R. Shenoy <e...@linux.vnet.ibm.com>
> Tested-by: Shilpasri G Bhat <shilpa.b...@linux.vnet.ibm.com>
> ---
> drivers/cpufreq/powernv-cpufreq.c | 43
> ++-
> 1 file changed, 33 i
ing transition_latency
unconditionally to CPUFREQ_ETERNAL are updated to use it. They don't
need to set transition_latency anymore.
There shouldn't be any functional change after this patch.
Signed-off-by: Viresh Kumar <viresh.ku...@linaro.org>
---
drivers/cpufreq/cpufreq-nforce2.c | 2 +-
where the
transition latency set to CPUFREQ_ETERNAL would not allow use of
ondemand/conservative governors. Thanks to Dominik for his feedback on
that.
--
viresh
Viresh Kumar (9):
cpufreq: governor: Drop min_sampling_rate
cpufreq: Use transition_delay_us for legacy governors as well
cpufre
; Cc: "Rafael J. Wysocki" <r...@rjwysocki.net>
> Cc: Viresh Kumar <viresh.ku...@linaro.org>
> Cc: Benjamin Herrenschmidt <b...@kernel.crashing.org>
> Cc: Paul Mackerras <pau...@samba.org>
> Cc: Michael Ellerman <m...@ellerman.id.au>
> Cc: Patrice
es.
>
> Signed-off-by: Thomas Gleixner <t...@linutronix.de>
> Cc: "Rafael J. Wysocki" <r...@rjwysocki.net>
> Cc: Viresh Kumar <viresh.ku...@linaro.org>
> Cc: linuxppc-dev@lists.ozlabs.org
> ---
> drivers/cpufreq/pasemi-cpufreq.c |2 +-
> 1 fil
with
CONFIG_CPU_FREQ_STAT now in them, as users wanted stats to be enabled.
Signed-off-by: Viresh Kumar <viresh.ku...@linaro.org>
---
arch/arm/configs/exynos_defconfig | 2 +-
arch/arm/configs/multi_v5_defconfig | 2 +-
arch/arm/configs/multi_v7_defconfig | 2 +-
arch/arm/c
e...@linux.vnet.ibm.com>
> ---
> Changes from v1:
> - Print if WOF is enabled
> - s/clean_notifiers/cleanup_notifiers
>
> drivers/cpufreq/powernv-cpufreq.c | 50
> ++++---
> 1 file changed, 47 insertions(+), 3 deletions(-)
Acked-by: Viresh Kumar <viresh.ku...@linaro.org>
--
viresh
1 - 100 of 250 matches
Mail list logo
