On 22 April 2015 at 22:34, Shilpasri G Bhat
wrote:
> diff --git a/drivers/cpufreq/powernv-cpufreq.c
> b/drivers/cpufreq/powernv-cpufreq.c
> +static char throttle_reason[6][50] = { "No throttling",
Don't need to mention 6 here.
And the max length you need right now is 27, so maybe s/50/30 ?
Al
On 28 April 2015 at 11:53, Shilpasri G Bhat
wrote:
> Changes from v1:
> - Add macros to define OCC_RESET, OCC_LOAD and OCC_THROTTLE
> - Define a structure to store chip id, chip mask which has bits set
> for cpus present in the chip, throttled state and a work_struct.
> - Modify powernv_cpufreq
On 28 April 2015 at 13:48, Shilpasri G Bhat
wrote:
> My bad I haven't added explicit comment to state reason behind this change.
>
> I modified the definition of *throttle_check() to match the function
> definition
> to be called via smp_call() instead of adding an additional wrapper around
> *th
/asm/opal-api.h | 8 ++
> drivers/cpufreq/powernv-cpufreq.c | 199
> +---
> 2 files changed, 192 insertions(+), 15 deletions(-)
Acked-by: Viresh Kumar
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
> input clocks per CPU, that will not take much memory as well.
Not sure how it got included in this form in the first place. :)
> Signed-off-by: Tang Yuantian
> ---
> drivers/cpufreq/qoriq-cpufreq.c | 32 +---
> 1 file changed, 21 insertions(+), 11 d
On 08-06-15, 18:45, Denis Kirjanov wrote:
> Hi,
>
> I see the following lockdep splat on my RackMac machine on boot:
What kernel version is it ?
--
viresh
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/li
On 08-06-15, 19:37, Denis Kirjanov wrote:
> [6.091149] 4.1.0-rc6-01265-g908e80d-dirty #15 Not tainted
Sorry, this points to a dirty tree. Can you please explain what's more
than rc6 is here ? Are you using any other patches from somewhere?
--
viresh
_
rivers/cpufreq/pmac64-cpufreq.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
Looks fine to me as well..
Acked-by: Viresh Kumar
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
On 24 July 2013 01:54, Aaro Koskinen wrote:
> Enable cpufreq on iMac G5 (iSight) model. Tested with the 2.1 GHz version.
>
> Signed-off-by: Aaro Koskinen
> ---
> drivers/cpufreq/pmac64-cpufreq.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
Acke
On 24 July 2013 01:54, Aaro Koskinen wrote:
> The patch also enables to use ondemand governor on the latter.
How? I can't see anything obvious here. :(
>
> Signed-off-by: Aaro Koskinen
> ---
> drivers/cpufreq/pmac64-cpufreq.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> dif
On 24 July 2013 15:48, Aaro Koskinen wrote:
> Hi,
>
> On Wed, Jul 24, 2013 at 11:04:50AM +0530, Viresh Kumar wrote:
>> On 24 July 2013 01:54, Aaro Koskinen wrote:
>> > The patch also enables to use ondemand governor on the latter.
>>
>> How? I can't see
> dev_err(&pdev->dev, "failure adding adapter\n");
> goto err_free_irq;
> }
> - of_i2c_register_devices(adap);
>
> return 0;
For SPEAr,
Reviewed-by: Viresh Kumar
__
On Thu, Mar 20, 2014 at 5:40 PM, Gautham R. Shenoy
wrote:
> This is the v3 of the consolidated patchset consisting
> patches for enabling cpufreq on IBM POWERNV platforms
> along with some enhancements.
This is the first time I saw them. Looks like you never Cc'd linux-pm list.
Also, would be bet
On Thu, Mar 20, 2014 at 5:40 PM, Gautham R. Shenoy
wrote:
> From: Vaidyanathan Srinivasan
Hi Vaidy,
> diff --git a/drivers/cpufreq/Kconfig b/drivers/cpufreq/Kconfig
> index 4b029c0..4ba1632 100644
> --- a/drivers/cpufreq/Kconfig
> +++ b/drivers/cpufreq/Kconfig
> @@ -48,6 +48,7 @@ config CPU_FRE
On Thu, Mar 20, 2014 at 5:40 PM, Gautham R. Shenoy
wrote:
> From: "Srivatsa S. Bhat"
>
> On POWER systems, the CPU frequency is controlled at a core-level and
> hence we need to serialize so that only one of the threads in the core
> switches the core's frequency at a time.
Probably you don't ne
On Thu, Mar 20, 2014 at 5:40 PM, Gautham R. Shenoy
wrote:
> From: "Gautham R. Shenoy"
>
> Create a driver attribute named cpuinfo_nominal_freq which
> creates a sysfs read-only file named cpuinfo_nominal_freq. Export
> the frequency corresponding to the nominal_pstate through this
> interface.
>
On Thu, Mar 20, 2014 at 5:41 PM, Gautham R. Shenoy
wrote:
> From: "Gautham R. Shenoy"
>
> The current frequency of a cpu is reported through the sysfs file
> cpuinfo_cur_freq. This requires the driver to implement a
> "->get(unsigned int cpu)" method which will return the current
> operating freq
On 21 March 2014 15:25, Gautham R Shenoy wrote:
> Probably the use of ATTR_RO(cpuinfo_nominal_freq) and renaming
> show_cpuinfo_nominal_freq to cpuinfo_nominal_freq_show() would be even
> better. What do you think ?
+1
___
Linuxppc-dev mailing list
Linu
On 21 March 2014 16:13, Gautham R Shenoy wrote:
> On Fri, Mar 21, 2014 at 02:11:32PM +0530, Viresh Kumar wrote:
>> > + pr_debug("PState id %d freq %d MHz\n", id, freq);
>> > + powernv_freqs[i].driver_data = i;
>>
>> I don&
On 21 March 2014 16:34, Gautham R Shenoy wrote:
> Heh! Well, that wasn't the reason why this was sent out as a separate
> patch, but never mind. Though I don't understand why it would be
> difficult to review the patch though.
Because the initial driver wasn't complete earlier. There were 2-3 pat
On 21 March 2014 17:15, Srivatsa S. Bhat
wrote:
>> I think you have Srivatsa there who has seen lots of cpufreq code and
>> could have helped you a lot :)
>>
>
> :-)
I was waiting for your reply here :)
> I have followed the locking and synchronization aspects of cpufreq
> closely, but unfortuna
On 21 March 2014 17:31, David Laight wrote:
>> *(int *)ret_freq = freq;
>
> Because it is very likely to be wrong.
> In general casts of pointers to integer types are dangerous.
Where are we converting pointers to integers? We are doing a
cast from 'void * ' to 'int *' and then using indirection
On 21 March 2014 18:34, Gautham R Shenoy wrote:
> Consider the case when pmspr = 0x00fe;
>
> We are interested in extracting the value 'fe'. And ensure that when
> we store this value into an int, we get the sign extension right.
>
> So the following doesn't work:
>
>pstate_id = (p
On 21 March 2014 18:53, Gautham R Shenoy wrote:
> Ok, I had based my code on linus's git tree. I checked the 'pm-cpufreq'
Always check his bleeding-edge or linux-next branch.
> branch of Rafael's 'linux-pm' tree and freq_table.c contains the
> following code snippet in show_available_frequencies
On 21 March 2014 20:18, Vaidyanathan Srinivasan
wrote:
> Yeah, I had the driver written using driver_data to store pstates.
> Gautham found the bug that we are missing one PState when we match the
> ID with CPUFREQ_BOOST_FREQ!
I see..
> We did not know that you have taken care of those issues.
On 21 March 2014 20:24, Gautham R Shenoy wrote:
> Ok, I guess the right thing to do at this point is call
>
>cpufreq_table_validate_and_show(policy, powernv_freqs);
>
> Will fix the code to take care of this.
Yes.
___
Linuxppc-dev mailing list
Linux
On 26 March 2014 22:25, Gautham R. Shenoy wrote:
> This is the v4 of the patchset to enable Dynamic Frequency Scaling
> on IBM PowerNV Platforms. I have incorporated the review comments
> from the previous version (can be found at [1]).
I wouldn't have added a cover-letter if I only have a single
Cc'ing Rafael.
On 26 March 2014 22:25, Gautham R. Shenoy wrote:
> From: Vaidyanathan Srinivasan
>
> Backend driver to dynamically set voltage and frequency on
> IBM POWER non-virtualized platforms. Power management SPRs
> are used to set the required PState.
>
> This driver works in conjunction
On 27 March 2014 11:58, Benjamin Herrenschmidt wrote:
> Any other comment ? :-)
Just gave on the patch..
> Because it depends on some other stuff in -next, I think it's best if
> this gets merged via Rafael's tree, unless someone can point me at
> the necessary pre-requisites in the form of a to
On 27 March 2014 15:00, Gautham R Shenoy wrote:
> As of now, I prefer this patch be based on code that is in the -next
> tree. I'll get rid of the per-core locking once the serialization
> patch of the core is accepted.
Okay.. Then divide this patch into two parts, second one doing all
the serial
On 27 March 2014 15:41, Vaidyanathan Srinivasan
wrote:
>> > Why do you need to get these from DT? And not find that yourself here
>> > instead?
> DT provides the values that we should use. Ideally these are the
> upper and lower limits of the PState table, however as per the
> platform spec, w
On 27 March 2014 15:51, Srivatsa S. Bhat
wrote:
> smp_processor_id() maps to debug_smp_processor_id() only if
> CONFIG_DEBUG_PREEMPT is set. Otherwise, it is same as raw_smp_processor_id().
> So I think its best to keep it as it is.
That was the case in .configs and so suggested raw_* variant. Ke
On 27 March 2014 16:50, Gautham R Shenoy wrote:
> (That said, in the future if we want to export additional
> information, say pertaining to the voltage, we will have to keep a
> separate array anyway :-) )
Lets handle that once it comes.
> However, as of now, I am wary about reusing a variable
On 27 March 2014 15:00, Gautham R Shenoy wrote:
> As of now, I prefer this patch be based on code that is in the -next
> tree. I'll get rid of the per-core locking once the serialization
> patch of the core is accepted.
Okay, its pushed in -next now :)
On 29 March 2014 01:41, Gautham R. Shenoy wrote:
> From: "Gautham R. Shenoy"
>
> Enable CPUFreq for PowerNV. Select "performance", "powersave",
> "userspace" and "ondemand" governors. Choose "ondemand" to be the
> default governor.
>
> Signed-off-by: Gautham R. Shenoy
> Signed-off-by: Srivatsa S
serialized
>
> * [PATCH v5 3/3] gets rid of the powernv_pstate_ids[] array that
> was being used to record the pstate ids. After the following
> patch it is safe to use cpufreq_frequency_table.driver_data
> since it is opaque to the cpufreq core:
>
> F
On 17 April 2014 15:23, Geert Uytterhoeven wrote:
> If CONFIG_SMP=n, does not include , causing:
>
> drivers/cpufreq/ppc-corenet-cpufreq.c: In function 'corenet_cpufreq_cpu_init':
> drivers/cpufreq/ppc-corenet-cpufreq.c:173:3: error: implicit declaration of
> function 'get_hard_smp_processor_id'
(12 * NSEC_PER_SEC) / fsl_get_sys_freq();
> + (12ULL * NSEC_PER_SEC) / fsl_get_sys_freq();
> of_node_put(np);
>
> return 0;
Acked-by: Viresh Kumar
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
On 17 April 2014 15:23, Geert Uytterhoeven wrote:
> If the clock doesn't exist, clk_get_rate() returns -EINVAL
You clk_get_rate() isn't written well then, it should return zero.
@Mike: I didn't see this clearly mentioned in clk.h, should we fix
that?
>, which becomes
> a large number (freq is u3
On 14 August 2014 16:49, Shilpasri G Bhat
wrote:
> This patch ensures the cpus to kexec/reboot at nominal frequency.
> Nominal frequency is the highest cpu frequency on PowerPC at
> which the cores can run without getting throttled.
>
> If the host kernel had set the cpus to a low pstate and then
On 21 August 2014 10:36, Shilpasri G Bhat wrote:
> The intention here is stop the cpufreq governor and then to set the cpus to
> nominal frequency so as to ensure that the frequency won't be changed later.
>
> The .suspend callback of the driver is not called during reboot/kexec.
> So we need an e
On 22 August 2014 08:18, Preeti U Murthy wrote:
> At the moment this looks like the best way forward. We need to do this
> cleanly by ensuring that we stop the governors and then call into the
> driver to deal with the cpu frequency in its own way during reboot. The
> best way to do this would be
On 25 August 2014 16:00, Viresh Kumar wrote:
> Its not that I am doubting if this will work or not. But this Hack is using
> routines not meant for this purpose. And that being a core routine,
> things aren't that straightforward anymore.
Well if you want a working HACK for solv
os.
>
> The reboot notifier will set the cpus to nominal frequncy.
>
> Changes v1->v2:
> Invoke .target() driver callback to set the cpus to nominal frequency
> in reboot notifier, instead of calling cpufreq_suspend() as suggested
> by Viresh Kumar.
> Modified the comm
On 1 September 2014 10:48, Shilpa Bhat wrote:
> Hi Viresh,
> On Fri, 2014-08-29 at 05:33 +0530, Viresh Kumar wrote:
>> On 28 August 2014 19:36, Shilpasri G Bhat
>> wrote:
>> >
>> > Changes v1->v2:
>> > Invoke .target() driver callback to set the c
s patchset fixes this issue.
>
> Changes in V2: Changed smp_call_function_any() to smp_call_function_single()
> in Patch[2/2]
Acked-by: Viresh Kumar
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
h scenarios.
>
> The reboot notifier will set the cpus to nominal frequncy.
>
> Signed-off-by: Shilpasri G Bhat
> Suggested-by: Viresh Kumar
> Reviewed-by: Preeti U Murthy
> ---
> Changes v2->v3:
> We return EBUSY when cpufreq governor tries to change the frequency
> a
On 17 October 2014 08:43, wrote:
Hi B29983 :)
> From: Tang Yuantian
>
> Freescale introduced new ARM core-based SoCs which support dynamic
> frequency switch feature. DFS on new SoCs are compatible with current
> PowerPC CoreNet platforms. In order to support those new platforms,
> this driver
On 21 October 2014 14:29, Yuantian Tang wrote:
> If I do so, menuconfig will display like this(on PPC):
> PowerPC CPU frequency scaling drivers
> QorIQ CPU Frequency scaling --->
> <*> CPU frequency scaling driver for Freescale QorIQ SoCs
> On ARM, there should b
On 27 October 2014 09:09, Yuantian Tang wrote:
> Do we have a conclusion yet?
No. You can keep your initial duplication of Kconfig entries for the time being.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/
On 12 November 2014 00:39, Scott Wood wrote:
> What purpose do those " CPU frequency scaling drivers" submenus
> serve, versus just including the options in the main cpufreq menu? It's
> not as if more than one arch would be visible at once (and when a
> situation with multiple visible menus popp
On 21 November 2014 12:58, Tang Yuantian wrote:
> diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
> index 83a75dc..1925ae94 100644
> --- a/drivers/cpufreq/Kconfig.arm
> +++ b/drivers/cpufreq/Kconfig.arm
> @@ -247,3 +247,11 @@ config ARM_TEGRA_CPUFREQ
> default y
>
On 21 November 2014 12:58, Tang Yuantian wrote:
> This driver works on all QorIQ platforms which include
> ARM-based cores and PPC-based cores.
> Rename it in order to represent better.
>
> Signed-off-by: Tang Yuantian
> ---
> drivers/cpufreq/ppc-corenet-cpufreq.c | 371
> --
On 21 November 2014 14:46, Yuantian Tang wrote:
> When I use -C -M options, checkpatch reports error:
>
> [tangyt@titan linux-pm]$ ./scripts/checkpatch.pl
> 0002-cpufreq-qoriq-rename-the-driver.patch
> WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
> #15:
> drivers/cpu
| 9 --
> drivers/cpufreq/ppc-corenet-cpufreq.c | 160
> +-
> 3 files changed, 107 insertions(+), 70 deletions(-)
For both patches:
Acked-by: Viresh Kumar
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
On 24 March 2013 20:07, Francesco Lavra wrote:
> On 03/24/2013 02:48 PM, Viresh Kumar wrote:
>> policy->cpus contains all online cpus that have single shared clock line. And
>> their frequencies are always updated together.
>>
>> Many SMP system's cpufreq driv
On 24 March 2013 19:18, Viresh Kumar wrote:
> policy->cpus contains all online cpus that have single shared clock line. And
> their frequencies are always updated together.
>
> Many SMP system's cpufreq drivers take care of this in individual drivers but
> the best pl
On 25 March 2013 22:18, Stephen Warren wrote:
> On 03/24/2013 11:19 PM, Viresh Kumar wrote:
>> On 24 March 2013 19:18, Viresh Kumar wrote:
>>> policy->cpus contains all online cpus that have single shared clock line.
>>> And
>>> their frequencies are al
This patch moves cpufreq driver of powerpc platform to drivers/cpufreq.
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: Olof Johansson
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Viresh Kumar
---
arch/powerpc/platforms/Kconfig | 31 --
arch
On Tue, Mar 26, 2013 at 8:06 AM, wrote:
> diff --git a/drivers/cpufreq/Kconfig.powerpc b/drivers/cpufreq/Kconfig.powerpc
> index e76992f..6339db4 100644
> --- a/drivers/cpufreq/Kconfig.powerpc
> +++ b/drivers/cpufreq/Kconfig.powerpc
> @@ -5,3 +5,13 @@ config CPU_FREQ_MAPLE
> help
>
On 28 March 2013 15:25, wrote:
> From: Tang Yuantian
>
> Add cpufreq driver for Freescale e500mc, e5500 and e6500 SoCs
> which are capable of changing the frequency of CPU dynamically
>
> Signed-off-by: Tang Yuantian
> Signed-off-by: Li Yang
> ---
> v2:
> - change the per_cpu variable
On 29 March 2013 08:21, Tang Yuantian-B29983 wrote:
>> > +static int corenet_cpufreq_cpu_init(struct cpufreq_policy *policy) {
>> > + unsigned int cpu = policy->cpu;
>> > + struct device_node *np;
>> > + int i, count;
>> > + struct clk *clk;
>> > + struct cpufreq_freq
On 29 March 2013 10:17, Tang Yuantian-B29983 wrote:
> I thought it was OK here. Apparently, sizeof(*table) is better.
> But kcalloc is OK.
Yes yes, Kcalloc is okay... I have misread that part earlier when i
suggested kzalloc.
In last mail i was referring to sizeof() only.
On 29 March 2013 11:22, wrote:
> diff --git a/drivers/cpufreq/ppc-corenet-cpufreq.c
> b/drivers/cpufreq/ppc-corenet-cpufreq.c
> +
Add following here for better debug prints (sorry, i should have done
it earlier)
#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
> +#include
> +#include
> +#include
On Fri, Mar 29, 2013 at 11:22 AM, wrote:
> diff --git a/drivers/cpufreq/ppc-corenet-cpufreq.c
> b/drivers/cpufreq/ppc-corenet-cpufreq.c
> +static int corenet_cpufreq_cpu_init(struct cpufreq_policy *policy)
> +{
> + for (i = 0; i < count; i++) {
> + table[i].index = i;
One
On 25 March 2013 22:24, Viresh Kumar wrote:
> This patch moves cpufreq driver of powerpc platform to drivers/cpufreq.
>
> Cc: Benjamin Herrenschmidt
> Cc: Paul Mackerras
> Cc: Olof Johansson
> Cc: linuxppc-dev@lists.ozlabs.org
> Signed-off-by: Viresh Kumar
> ---
&
On 31 March 2013 09:33, Viresh Kumar wrote:
> On 25 March 2013 22:24, Viresh Kumar wrote:
>> This patch moves cpufreq driver of powerpc platform to drivers/cpufreq.
>>
>> Cc: Benjamin Herrenschmidt
>> Cc: Paul Mackerras
>> Cc: Olof Johansson
>> Cc: linu
On 3 April 2013 16:00, Benjamin Herrenschmidt wrote:
> I'm on vacation until end of April. No objection to the patch but
> somebody needs to test it.
Any input on whom i can ask for that?
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https
On 3 April 2013 16:00, Benjamin Herrenschmidt wrote:
> On Wed, 2013-04-03 at 15:00 +0530, Viresh Kumar wrote:
>> On 31 March 2013 09:33, Viresh Kumar wrote:
>> > Benjamin/Paul/Olof,
>> >
>> > Any comments on this?
>>
>> Ping!!
>
> I'
This patch moves cpufreq driver of powerpc platform to drivers/cpufreq.
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: Olof Johansson
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Viresh Kumar
---
Compile Tested only.
arch/powerpc/platforms/Kconfig | 31
This patch moves cpufreq driver of powerpc platforms/cell to drivers/cpufreq.
Cc: Arnd Bergmann
Cc: Benjamin Herrenschmidt
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Viresh Kumar
---
Compile Tested only.
arch/powerpc/platforms/cell/Kconfig| 26
On 4 April 2013 18:32, Arnd Bergmann wrote:
> Moving the files is good, but I don't see a reason to make the cbe_cpufreq.h
> header globally visible in include/linux/. Isn't it just used by as the
> interface between ppc_cbe_cpufreq_pmi.c and ppc_cbe_cpufreq.c?
When i moved it initially i though
On 4 April 2013 18:24, Viresh Kumar wrote:
> This patch moves cpufreq driver of powerpc platform to drivers/cpufreq.
>
> Cc: Benjamin Herrenschmidt
> Cc: Paul Mackerras
> Cc: Olof Johansson
> Cc: linuxppc-dev@lists.ozlabs.org
> Signed-off-by: Viresh Kumar
> -
On 5 April 2013 12:16, Viresh Kumar wrote:
> On 4 April 2013 18:24, Viresh Kumar wrote:
>> This patch moves cpufreq driver of powerpc platform to drivers/cpufreq.
>>
>> Cc: Benjamin Herrenschmidt
>> Cc: Paul Mackerras
>> Cc: Olof Johansson
>> Cc: linuxpp
Mostly good now, V5 should be the final one.
On 9 April 2013 14:02, wrote:
> diff --git a/drivers/cpufreq/ppc-corenet-cpufreq.c
> b/drivers/cpufreq/ppc-corenet-cpufreq.c
> +static int corenet_cpufreq_target(struct cpufreq_policy *policy,
> + unsigned int target_freq, unsigned int
On 11 April 2013 12:29, Olof Johansson wrote:
> That's not very nice this late in the staging cycle. Give the powerpc
> guys a little more time than a single day to come back with test results,
> please.
Yes we are waiting indefinitely for an Ack from powerpc guys.. If we can
get a Ack soon, we w
On Fri, Apr 19, 2013 at 4:17 PM, Zhao Chenhui
wrote:
> diff --git a/drivers/cpufreq/mpc85xx-cpufreq.c
> b/drivers/cpufreq/mpc85xx-cpufreq.c
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
Would be better to keep them in alphabetical order,
On 9 April 2013 14:05, Viresh Kumar wrote:
> On 5 April 2013 12:16, Viresh Kumar wrote:
>> On 4 April 2013 18:24, Viresh Kumar wrote:
>>> This patch moves cpufreq driver of powerpc platform to drivers/cpufreq.
>>>
>>> Cc: Benjamin Herrenschmidt
>>&g
On 22 April 2013 12:19, Viresh Kumar wrote:
> On 9 April 2013 14:05, Viresh Kumar wrote:
>> On 5 April 2013 12:16, Viresh Kumar wrote:
>>> On 4 April 2013 18:24, Viresh Kumar wrote:
>>>> This patch moves cpufreq driver of powerpc platform to drivers/c
On 13 May 2013 11:34, Viresh Kumar wrote:
> On 22 April 2013 12:19, Viresh Kumar wrote:
>> On 9 April 2013 14:05, Viresh Kumar wrote:
>>> On 5 April 2013 12:16, Viresh Kumar wrote:
>>>> On 4 April 2013 18:24, Viresh Kumar wrote:
>>>>> This patc
On 20 May 2013 10:10, Viresh Kumar wrote:
> On 13 May 2013 11:34, Viresh Kumar wrote:
>> On 22 April 2013 12:19, Viresh Kumar wrote:
>>> On 9 April 2013 14:05, Viresh Kumar wrote:
>>>> On 5 April 2013 12:16, Viresh Kumar wrote:
>>>>> On 4 April
e mode 100644 drivers/cpufreq/ppc-corenet-cpufreq.c
I haven't gone for a very deep review this time and it looked okay.
Acked-by: Viresh Kumar
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
On 31 May 2013 16:20, Viresh Kumar wrote:
> On 20 May 2013 10:10, Viresh Kumar wrote:
>> On 13 May 2013 11:34, Viresh Kumar wrote:
>>> On 22 April 2013 12:19, Viresh Kumar wrote:
>>>> On 9 April 2013 14:05, Viresh Kumar wrote:
>>>>> On 5 April
CPUFreq driver of this platform uses APIs from freq_table.c and so must select
CPU_FREQ_TABLE.
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Viresh Kumar
---
drivers/cpufreq/Kconfig.powerpc | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/cpufreq/Kconfig.powerpc b/drivers/cpufreq
On Mon, Nov 19, 2012 at 11:52 PM, Bill Pemberton wrote:
> CONFIG_HOTPLUG is going away as an option so __devinit is no longer
> needed.
>
> Signed-off-by: Bill Pemberton
> Cc: Viresh Kumar
> Cc: Li Yang
> Cc: Zhang Wei
> Cc: Barry Song
> Cc: linuxppc-dev@lists.ozl
ONFIG_NR_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:
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
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
amically 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. Wysocki
> Cc: linux...@vger.kernel.org
&g
ndle throttling 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
of the code.
Suggested-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/4
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
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 powerp
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 powerp
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/
dr
stuff and so left it
for the right people to handle. :)
Acked-by: Viresh Kumar
--
viresh
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
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 p
0, &offset, 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
eq_pmi.c
> 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
1 - 100 of 261 matches
Mail list logo
