On 26 November 2012 18:55, Lee Jones wrote:
> Why do you need to sort them? Is there _really_ a need?
Many people & maintainers like to have their header files ordered. The
reason for that is:
If they are not ordered, there is a possibility of adding an header file
multiple times in a file. Thi
On 6 November 2012 16:08, Viresh Kumar wrote:
> This is V2 Resend of my sched_select_cpu() work. Resend because didn't got
> much
> attention on V2. Including more guys now in cc :)
>
> In order to save power, it would be useful to schedule work onto non-IDLE cpus
> inste
On 20 November 2012 12:11, Viresh Kumar wrote:
> On 8 November 2012 20:39, Viresh Kumar wrote:
>> From: Vipul Kumar Samar
>>
>> SPEAr sdhci driver expects the clock to be set to 50 MHz for proper
>> functioning.
>> This patch sets clk to 50 MHz in probe.
>&
On 26 November 2012 20:39, Chris Ball wrote:
> On Thu, Nov 08 2012, Viresh Kumar wrote:
>> + ret = clk_set_rate(sdhci->clk, 5000);
>> + if (ret)
>> + dev_dbg(&pdev->dev, "Error setting desired clk, clk=%lu\n",
>> +
On 20 November 2012 14:17, Dmitry Torokhov wrote:
> No, not really, it just does not work well with devm_* patches that got
> applied: on removal you unprepare clock as the very first operation and
> then devm_* does the rest which is wrong order.
>
> I am looking at adding dem_* for clocks.
I ha
On 27 November 2012 00:10, Grant Likely wrote:
> Ah, so it is configuring the way the device emits interrupts; not how
> the interrupt controller processes them. Fair enough.
Finally i am able to convince somebody that stmpe is different :)
> It would actually be good to ask the interrupt contro
On 27 November 2012 08:10, Viresh Kumar wrote:
> On 27 November 2012 00:10, Grant Likely wrote:
>> It would actually be good to ask the interrupt controller driver what
>> kind of interrupt signal it expects for a given interrupt line. That
>> should also solve the problem
Hi Tejun,
On 26 November 2012 22:45, Tejun Heo wrote:
> On Tue, Nov 06, 2012 at 04:08:45PM +0530, Viresh Kumar wrote:
> I'm pretty skeptical about this. queue_work() w/o explicit CPU
> assignment has always guaranteed that the work item will be executed
> on the same CPU. I
On 27 November 2012 10:14, Stephen Rothwell wrote:
> Today's linux-next merge of the arm-soc tree got a conflict in
> arch/arm/mach-spear13xx/spear1310.c between commit b47394911c26 ("ARM:
> SPEAr13xx: Pass DW DMAC platform data from DT") from the slave-dma tree
> and commit 300a6856324a ("ARM: SP
Hi Steven,
Thanks for sharing your opinion. :)
As, this went out to be a long thread of discussion (thanks Paul), i will try to
answer everything here.
On 26 November 2012 22:10, Steven Rostedt wrote:
> This is a really bad time of year to post new patches :-/
> A lot of people are trying to ge
On 27 November 2012 14:10, Lee Jones wrote:
> On Tue, 27 Nov 2012, Viresh Kumar wrote:
>> Problem is with invert polarity, which the interrupt controller is not aware
>> of.
>> For example, suppose interrupt controller needs Rising edge interrupt, but
>> the board ha
On 27 November 2012 18:56, Steven Rostedt wrote:
> A couple of things. The sched_select_cpu() is not cheap. It has a double
> loop of domains/cpus looking for a non idle cpu. If we have 1024 CPUs,
> and we are CPU 1023 and all other CPUs happen to be idle, we could be
> searching 1023 CPUs before
On 28 November 2012 01:25, Rabin Vincent wrote:
> 2012/11/27 Viresh Kumar :
>> On 27 November 2012 14:10, Lee Jones wrote:
>> I haven't seen this in any of SPEAr boards i have worked on. Maybe Rabin
>> would have, that's why he added that part of code :)
>>
On Wed, Nov 28, 2012 at 5:22 PM, Rabin Vincent
wrote:
> In order to provide per-user accounting, this separates the struct clk
> used in the common clock framework into two structures 'struct clk_core'
> and 'struct clk'. struct clk_core will be used for internal
> manipulation and struct clk wil
On Wed, Nov 28, 2012 at 9:31 PM, viresh kumar wrote:
> On Wed, Nov 28, 2012 at 5:22 PM, Rabin Vincent
> Isn't something wrong here? For common clk case shouldn't
> this be:
>
>> +#define clk_to_clk_core(clk) (&clk->clk)
>> +#define clk_core_to_clk(core
earlier discussed here:
https://lkml.org/lkml/2012/11/27/636
Signed-off-by: Viresh Kumar
---
This is actually V1 of this patch.
drivers/mfd/stmpe.c | 7 ---
include/linux/mfd/stmpe.h | 2 --
2 files changed, 9 deletions(-)
diff --git a/drivers/mfd/stmpe.c b/drivers/mfd/stmpe.c
index
: irqd_get_trigger_type() routine.
So, now we don't need to pass it via platform data. This is earlier discussed
here:
https://lkml.org/lkml/2012/11/26/711
Signed-off-by: Viresh Kumar
---
Linus/Shiraz: Can you please test this patch? You don't really need to test 1/3
and 3/3, but would be good
Kumar Samar
Signed-off-by: Viresh Kumar
---
V3->V4:
- Remove need to pass irq type and polarity from DT.
- Remove need to pass id from platform data.
Documentation/devicetree/bindings/mfd/stmpe.txt | 9 ++---
drivers/mfd/stmpe-i2c.c | 15 +++
drivers/
On 29 November 2012 00:05, Viresh Kumar wrote:
> Since the very first patch, stmpe core driver is using irq_invert_polarity as
> part of platform data. But, nobody is actually using it in kernel till now.
>
> Also, this is not something part of hardware specs, but is included to
earlier discussed here:
https://lkml.org/lkml/2012/11/27/636
Signed-off-by: Viresh Kumar
---
This is actually V1 of this patch.
drivers/mfd/stmpe.c | 7 ---
include/linux/mfd/stmpe.h | 2 --
2 files changed, 9 deletions(-)
diff --git a/drivers/mfd/stmpe.c b/drivers/mfd/stmpe.c
index
: irqd_get_trigger_type() routine.
So, now we don't need to pass it via platform data. This is earlier discussed
here:
https://lkml.org/lkml/2012/11/26/711
Signed-off-by: Viresh Kumar
---
@Linus/Shiraz: Can you please test this patch? You don't really need to test 1/3
and 3/3, but would be g
Kumar Samar
Signed-off-by: Viresh Kumar
---
V3->V4:
- Remove need to pass irq type and polarity from DT.
- Remove need to pass id from platform data.
Documentation/devicetree/bindings/mfd/stmpe.txt | 9 ++---
drivers/mfd/stmpe-i2c.c | 15 +++
drivers/
On 29 November 2012 09:10, Stephen Rothwell wrote:
> diff --cc drivers/dma/dw_dmac.c
> +#ifdef CONFIG_OF
> +static struct dw_dma_platform_data *
> +__devinit dw_dma_parse_dt(struct platform_device *pdev)
Do we need a separate patch to fix this place? I believe yes.
> - static int __devinit d
On 29 November 2012 14:53, Lee Jones wrote:
>> From: Vipul Kumar Samar
>> + /*
>> + * Distinct names of same cell-type within multiple instances of stmpe
>> + * will be guaranteed by DT.
>> + */
>> + pdata->id = -1;
>
> And what if we're not booting with DT?
Then it is res
On 29 November 2012 15:04, Lee Jones wrote:
> On Thu, 29 Nov 2012, Viresh Kumar wrote:
>
>> STMPE can confige
>
> configure?
>
>> the way the device emits interrupts and till now this
>
> until?
Ahh... Wil
earlier discussed here:
https://lkml.org/lkml/2012/11/27/636
Acked-by: Lee Jones
Signed-off-by: Viresh Kumar
---
Nothing changed from last version.
drivers/mfd/stmpe.c | 7 ---
include/linux/mfd/stmpe.h | 2 --
2 files changed, 9 deletions(-)
diff --git a/drivers/mfd/stmpe.c b
Kumar Samar
Signed-off-by: Viresh Kumar
---
V4->V5:
--
- 2/3 and 3/3 merged.
- irq_trigger is kept same for non-DT booti.
@Lee: I haven't added your Acked-by, because this differs from your Acked
version.
Documentation/devicetree/bindings/mfd/stmpe.txt | 9 ++---
drivers/mfd/stm
lly saved some power.
These patches are applied here for others to test:
http://git.linaro.org/gitweb?p=people/vireshk/linux.git;a=shortlog;h=refs/heads/sched-wq-migration-v3
Viresh Kumar (7):
sched: Create sched_select_cpu() to give preferred CPU for power
saving
timer: hrtimer: Don'
calls to idle_cpu() from timer and hrtimer.
Signed-off-by: Viresh Kumar
---
kernel/hrtimer.c | 2 +-
kernel/timer.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/kernel/hrtimer.c b/kernel/hrtimer.c
index cc47812..c56668d 100644
--- a/kernel/hrtimer.c
+++ b/kernel/hrti
(via scheduling domains) non-idle cpu
(non-idle from schedulers perspective). If the current cpu is not idle or all
cpus are idle, work will be scheduled on local cpu.
Signed-off-by: Viresh Kumar
---
include/linux/workqueue.h | 5 ++
kernel/workqueue.c
er.
These routines would look for the closest (via scheduling domains) non-idle cpu
(non-idle from schedulers perspective). If the current cpu is not idle or all
cpus are idle, work will be scheduled on local cpu.
Cc: "David S. Miller"
Cc: net...@vger.kernel.org
Signed-off-by: Viresh
) non-idle cpu
(non-idle from schedulers perspective). If the current cpu is not idle or all
cpus are idle, work will be scheduled on local cpu.
Cc: Chris Ball
Cc: linux-...@vger.kernel.org
Signed-off-by: Viresh Kumar
---
drivers/mmc/core/core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletio
osest (via scheduling domains) non-idle cpu
(non-idle from schedulers perspective). If the current cpu is not idle or all
cpus are idle, work will be scheduled on local cpu.
Cc: Jens Axboe
Signed-off-by: Viresh Kumar
---
block/blk-core.c | 6 +++---
block/blk-ioc.c | 2 +-
block/genhd.c| 9 ++
n-idle cpu
(non-idle from schedulers perspective). If the current cpu is not idle or all
cpus are idle, work will be scheduled on local cpu.
Cc: Dave Airlie
Cc: linux-fb...@vger.kernel.org
Signed-off-by: Viresh Kumar
---
drivers/video/console/fbcon.c | 2 +-
1 file changed, 1 insertion(+),
et_nohz_timer_target() routine, which had
similar implementation.
Signed-off-by: Viresh Kumar
---
include/linux/sched.h | 21 +++--
kernel/sched/core.c | 63 +--
2 files changed, 55 insertions(+), 29 deletions(-)
diff --git a/inc
On Mon, Mar 18, 2013 at 9:09 PM, Frederic Weisbecker wrote:
> 2013/3/18 Viresh Kumar :
>> +static inline int sched_select_cpu(unsigned int sd_flags)
>> +{
>> + return raw_smp_processor_id();
>
> I feel this should be symetric with the requirement of having
>
On 18 March 2013 20:53, Viresh Kumar wrote:
> In order to save power, it would be useful to schedule light weight work on
> cpus
> that aren't IDLE instead of waking up an IDLE one.
>
> By idle cpu (from scheduler's perspective) we mean:
> - Current task is i
On 18 March 2013 21:27, Frederic Weisbecker wrote:
> 2013/3/18 Viresh Kumar :
>>> It would be nice to have some more precise naming. sched_select_busy_cpu() ?
>>
>> You are correct that name can be improved but busy may give it a different
>> meaning. Maybe sched_s
On 18 March 2013 20:53, Viresh Kumar wrote:
> queue_work() queues work on current cpu. This may wake up an idle CPU, which
> is
> actually not required.
>
> Some of these works can be processed by any CPU and so we must select a
> non-idle
> CPU here. The initi
On 19 March 2013 18:00, Peter Zijlstra wrote:
> On Mon, 2013-03-18 at 20:53 +0530, Viresh Kumar wrote:
>> +/*
>> + * This routine returns the nearest non-idle cpu. It accepts a
>> bitwise OR of
>> + * SD_* flags present in linux/sched.h. If the local CPU isn't idl
On 19 March 2013 18:22, Viresh Kumar wrote:
> On 19 March 2013 18:00, Peter Zijlstra wrote:
>> Why not leave out the sd_flags argument and introduce it once you start
>> using it; at which point we can argue on the interface.
>
> Yes, that can be done. Will fix i
On 19 March 2013 10:45, Viresh Kumar wrote:
> On 18 March 2013 20:53, Viresh Kumar wrote:
>> queue_work() queues work on current cpu. This may wake up an idle CPU, which
>> is
>> actually not required.
>>
>> Some of these works can be processed by any CPU and
On 20 March 2013 05:50, Rafael J. Wysocki wrote:
> On Thursday, March 14, 2013 08:39:55 AM Viresh Kumar wrote:
>> On 14 March 2013 03:11, Rafael J. Wysocki wrote:
>> > On Tuesday, March 12, 2013 08:55:12 AM Viresh Kumar wrote:
>> >> On 12 March 2013 07:38, Rafael
On 20 March 2013 09:53, Viresh Kumar wrote:
> But when do you want me to call this function
Guess what, i got answer to this question: struct cpufreq_driver :)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.ke
On 4 March 2013 13:07, Viresh Kumar wrote:
> Currently, there can't be multiple instances of single governor_type. If we
> have
> a multi-package system, where we have multiple instances of struct policy (per
> package), we can't have multiple instances of same governor.
y: Konrad Rzeszutek Wilk
> ---
> arch/x86/include/uapi/asm/msr-index.h | 1 +
> drivers/cpufreq/intel_pstate.c| 6 +++---
> 2 files changed, 4 insertions(+), 3 deletions(-)
Acked-by: Viresh Kumar
--
To unsubscribe from this list: send the line "unsubscribe linux-k
On 27 November 2012 19:17, Steven Rostedt wrote:
> On Tue, 2012-11-06 at 16:08 +0530, Viresh Kumar wrote:
>> diff --git a/kernel/timer.c b/kernel/timer.c
>> @@ -729,6 +730,12 @@ __mod_timer(struct timer_list *timer, unsigned long
>> expires,
>>
>> bas
if (intel_pstate_msrs_not_valid())
> + return -ENODEV;
> +
> pr_info("Intel P-state driver initializing.\n");
>
> all_cpu_data = vmalloc(sizeof(void *) * num_possible_cpus());
Acked-by: Viresh Kumar
--
To unsubscribe from this list: send th
On 21 March 2013 15:16, Vinod Koul wrote:
> On Fri, Mar 15, 2013 at 02:18:20PM +0530, Viresh Kumar wrote:
>> In of_dma_controller_register() routine we are calling of_get_property() as
>> an
>> parameter to be32_to_cpup(). In case the property doesn't exist we will
!(channel_readl(dwc, CFG_LO) & DWC_CFGL_FIFO_EMPTY))
> - cpu_relax();
> + while (!(channel_readl(dwc, CFG_LO) & DWC_CFGL_FIFO_EMPTY) && count--)
> + udelay(2);
Acked-by: Viresh Kumar
--
To unsubscribe from this list: send the line "unsubscribe linux
On 21 March 2013 05:42, Tejun Heo wrote:
> On Mon, Mar 18, 2013 at 08:53:25PM +0530, Viresh Kumar wrote:
> For some reason, I've been always unsure about this patchset. I've
> been thinking about it past few days and I think I now know why.
I knew this since the beginnin
ernor type, but with different tunables.
This patchset is inclined towards fixing this issue.
Viresh Kumar (4):
cpufreq: Don't check cpu_online(policy->cpu)
cpufreq: stats: Get rid of CPUFREQ_STATDEVICE_ATTR
cpufreq: Add per policy governor-init/exit infrastructure
cpufreq: governo
policy->cpu or cpus in policy->cpus can't be offline anymore. And so we don't
need to check if they are online or not.
Signed-off-by: Viresh Kumar
---
drivers/cpufreq/cpufreq.c | 17 +++--
drivers/cpufreq/cpufreq_governor.c | 2 +-
drivers/cpufreq/cpu
Macro "CPUFREQ_STATDEVICE_ATTR" is defined local to cpufreq_stats.c file and is
almost a copy of the generic version present in cpufreq.h file. Lets use the
generic version instead.
Signed-off-by: Viresh Kumar
---
drivers/cpufreq/cpufreq_stats.c | 18 ++
1 file
ernor type, but with different tunables.
This patch is inclined towards providing this infrastructure. Because we are
required to allocate governor's resources dynamically now, we must do it at
policy creation and end. And so got CPUFREQ_GOV_POLICY_INIT/EXIT.
Signed-off-by: Viresh Kumar
ernor type, but with different tunables.
This patch uses the infrastructure provided by earlier patch and implements
init/exit routines for ondemand and conservative governors.
Signed-off-by: Viresh Kumar
---
drivers/cpufreq/cpufreq.c | 4 -
drivers/cpufreq/cpufreq_conse
On 31 January 2013 07:56, Viresh Kumar wrote:
> With the recent changes in cpufreq core, we just need to set mask of all
> possible cpus into policy->cpus. Rest would be done by core.
>
> Signed-off-by: Viresh Kumar
> ---
> drivers/cpufreq/exynos-cpufreq.c | 14 +--
On 4 February 2013 17:47, Rafael J. Wysocki wrote:
> Well, [1-2/4] are things I can take for v3.9 no problem. The other two I'd
> wait for the next cycle to be honest. We already have 30+ cpufreq patches
> scheduled for v3.9 and some of them quite subtle for that matter.
To be honest, i wanted
On 4 February 2013 18:02, Borislav Petkov wrote:
> On Mon, Feb 04, 2013 at 05:54:18PM +0530, Viresh Kumar wrote:
>> One important point i would like to highlight is: governors directory
>> would be present in cpu/cpu*/cpufreq/ now instead of cpu/cpufreq/.
>
> Uh, hold on,
On 4 February 2013 18:34, Borislav Petkov wrote:
> On Mon, Feb 04, 2013 at 06:24:19PM +0530, Viresh Kumar wrote:
>> What i believe is, the place where this directory was present earlier
>> (cpu/cpufreq/) wasn't the right place. Everything else was in
>> cpu/cpu*/cpufre
On 4 February 2013 19:06, Borislav Petkov wrote:
> On Mon, Feb 04, 2013 at 06:55:25PM +0530, Viresh Kumar wrote:
>> That's not completely true. There lies cpufreq directory in cpu/cpu*/
>> too, where we have per policy stuff in cpu/cpu*/, like policy tunables
>> and s
On 4 February 2013 19:39, Borislav Petkov wrote:
> On Mon, Feb 04, 2013 at 07:28:16PM +0530, Viresh Kumar wrote:
>> All files which are directly present in cpu/cpu*/cpufreq/ folder. I am
>> not talking about governor tunables but policy tunables. Things like
>> scaling_[mi
On 4 February 2013 20:35, Borislav Petkov wrote:
> On Mon, Feb 04, 2013 at 07:51:33PM +0530, Viresh Kumar wrote:
>> We correlate things with cpus rather than policies and so the current
>> directory structure of cpu/cpu*/cpufreq/*** is the best suited ones.
>
> Ok, show m
On 4 February 2013 23:55, Dirk Brandewie wrote:
> Hi Viresh,
>
> I have rebased onto bleeding-edge when I reboot the system I get a kernel
> panic.
> Any idea what I could have done that would have broken the restructured
> cpufreq_{add/remove}_dev.
Dirk, there are two mail chains for similar iss
On Mon, Feb 4, 2013 at 10:20 PM, Borislav Petkov wrote:
> On Mon, Feb 04, 2013 at 09:07:11PM +0530, Viresh Kumar wrote:
>> └── ondemand
>> ├── sampling_rate
>> ├── up_threshold
>> └── ignore_nice
>
> So this is adding the current governor as a per-cp
On Tue, Feb 5, 2013 at 4:15 AM, Nathan Zimmer wrote:
> This completely eliminates the contention I am seeing in __cpufreq_cpu_get.
> It also nicely stages the lock to be replaced by the rcu.
>
> CC: "Rafael J. Wysocki"
> Signed-off-by: Nathan Zimmer
> ---
> drivers/cpufreq/cpufreq.c | 44 ++
On Tue, Feb 5, 2013 at 6:37 AM, Rafael J. Wysocki wrote:
> On Monday, February 04, 2013 04:45:11 PM Nathan Zimmer wrote:
>> I am noticing the cpufreq_driver_lock is quite hot.
>> On an idle 512 system perf shows me most of the system time is spent on this
>> lock. This is quite signifigant as top
On 4 February 2013 19:06, Borislav Petkov wrote:
> On Mon, Feb 04, 2013 at 06:55:25PM +0530, Viresh Kumar wrote:
>> Its not only for multicluster system, but a system where multiple cpus
>> have separate clock control and hence multiple policy structures.
>
> What are th
On 5 February 2013 14:45, Borislav Petkov wrote:
> On Tue, Feb 05, 2013 at 12:50:31PM +0530, Viresh Kumar wrote:
>> > I think this is cleaner but whatever - I don't care that much. My
>> > only strong concern is that this thing should be a Kconfig option and
>>
On Tue, Feb 5, 2013 at 3:33 PM, Rafael J. Wysocki wrote:
> I actually don't agree with that, becuase the Nathan's apprach shows the
> reasoning that leads to the RCU introduction quite clearly. So if you
> don't have technical problems with the patchset, I'm going to take it as is.
Great!!
Okay
On 5 February 2013 15:57, Borislav Petkov wrote:
> Are you kidding me? You're simply not reading what I'm saying to you:
> "... should be optional and selectable in Kconfig so that systems which
> don't need that, don't have to see or use it." Because on those systems
> it doesn't apply.
>
> How a
On 5 February 2013 16:34, Borislav Petkov wrote:
> Here's an even cleaner way:
>
> platform_driver:
> init(struct cpufreq_policy *policy)
> {
> ...
>
> add_additional_sysfs_entries(policy);
>
> ...
> }
>
> ...
>
> static void add_additional_sysfs_entries(struct cpufreq_poli
On 5 February 2013 16:49, Borislav Petkov wrote:
> On Tue, Feb 05, 2013 at 04:42:23PM +0530, Viresh Kumar wrote:
>> Tricky part is the name of this routine: add_additional_sysfs_entries().
>
> Now you're just being silly - this is just an example how to do it. If
> you
On 5 February 2013 17:02, Borislav Petkov wrote:
> On Tue, Feb 05, 2013 at 04:56:03PM +0530, Viresh Kumar wrote:
>> Just some kind of indication from platform driver is required about
>> how/where it wants its governor directory to be present.
>
> The indicatio
On 5 February 2013 18:52, Borislav Petkov wrote:
> On Tue, Feb 05, 2013 at 05:54:57PM +0530, Viresh Kumar wrote:q
>> This indication isn't enough. On a single image solution, we need to
>> identify the system which needs support for multiple policies and i
>> still feel
On 4 February 2013 17:08, Viresh Kumar wrote:
> Currently, there can't be multiple instances of single governor_type. If we
> have
> a multi-package system, where we have multiple instances of struct policy (per
> package), we can't have multiple instances of same governor.
On Tue, Feb 5, 2013 at 11:54 PM, wrote:
> From: Dirk Brandewie
>
> Scaling drivers that implement the cpufreq_driver.setpolicy() versus
> the cpufreq_driver.target() interface do not set policy->cur.
> Signed-off-by: Dirk Brandewie
> From: Dirk Brandewie
> Date: 2013-02-04 18:44:40 -0800
>
>
On Tue, Feb 5, 2013 at 11:54 PM, wrote:
> From: Viresh Kumar
>
> "cpufreq" directory in policy->cpu is never created using sysfs_create_link(),
> but using kobject_init_and_add(). And so we shouldn't call sysfs_remove_link()
> for policy->cpu(). sysfs st
On Tue, Feb 5, 2013 at 11:54 PM, wrote:
> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> index 2817c3c..96bc302 100644
> --- a/drivers/cpufreq/cpufreq.c
> +++ b/drivers/cpufreq/cpufreq.c
> @@ -1181,6 +1181,13 @@ unsigned int cpufreq_quick_get(unsigned int cpu)
> stru
On Tue, Feb 5, 2013 at 11:54 PM, wrote:
> From: Dirk Brandewie
>
> Scaling drivers that implement cpufreq_driver.setpolicy() have
> internal governors and may/will change the current operating frequency
> very frequently this will cause cpufreq_out_of_sync() to be called
> every time. Only call
cpu(cpufreq_cpu_governor, cpu), data->governor->name,
> + if (!cpufreq_driver->setpolicy)
> + strncpy(per_cpu(cpufreq_cpu_governor, cpu),
> + data->governor->name,
> CPUFREQ_NAME_LEN);
Acked-by: Viresh Kumar
On Tue, Feb 5, 2013 at 11:54 PM, wrote:
> From: Dirk Brandewie
>
> There is an additional reference added to the driver in
> cpufreq_add_dev() that is removed in__cpufreq_governor() if the
> driver implements target(). Remove the last reference when the
> driver implements setpolicy()
>
> Sign
On Tue, Feb 5, 2013 at 11:54 PM, wrote:
> From: Dirk Brandewie
>
> The sysfs files for cpufreq_stats are created in cpufreq_stats_create_table()
> called from cpufreq_stat_notifier_policy() when a policy is added to
> the cpu. cpufreq_stats_create_table() will not be called if the
> scaling driv
On Wed, Feb 6, 2013 at 7:45 AM, Dirk Brandewie wrote:
> How about this?
>
> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> index 2817c3c..9c0eac4 100644
> --- a/drivers/cpufreq/cpufreq.c
> +++ b/drivers/cpufreq/cpufreq.c
> @@ -1182,7 +1182,12 @@ unsigned int cpufreq_quick_get
On 6 February 2013 07:36, Dirk Brandewie wrote:
> On 02/05/2013 05:47 PM, Viresh Kumar wrote:
>>
>> On Tue, Feb 5, 2013 at 11:54 PM, wrote:
>>>
>>> From: Dirk Brandewie
>>>
>>> Scaling drivers that implement cpufreq_driver.setpolicy() have
>
On 6 February 2013 07:38, Dirk Brandewie wrote:
> On 02/05/2013 05:58 PM, Viresh Kumar wrote:
>>
>> On Tue, Feb 5, 2013 at 11:54 PM, wrote:
>>>
>>> From: Dirk Brandewie
>>>
>>> There is an additional reference added to the driver in
>>
if (cpufreq_driver && cpufreq_driver->setpolicy &&
> + cpufreq_driver->get)
> + return cpufreq_driver->get(cpu);
> +
> + policy = cpufreq_cpu_get(cpu);
> if (policy) {
> ret_freq = policy->c
On 6 February 2013 07:34, Nathan Zimmer wrote:
> This eliminates the contention I am seeing in __cpufreq_cpu_get.
> It also nicely stages the lock to be replaced by the rcu.
>
> Cc: Viresh Kumar
> Cc: "Rafael J. Wysocki"
> Signed-off-by: Nathan Zimmer
> ---
&g
On 6 February 2013 07:34, Nathan Zimmer wrote:
> In general rwlocks are discourged so we are moving it to use the rcu instead.
>
> Cc: Viresh Kumar
> Cc: "Rafael J. Wysocki"
> Signed-off-by: Nathan Zimmer
> ---
>
ions(+), 7 deletions(-)
Makes sense.
Acked-by: Viresh Kumar
--
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/
On 6 February 2013 08:22, Viresh Kumar wrote:
> On 6 February 2013 07:34, Nathan Zimmer wrote:
>> In general rwlocks are discourged so we are moving it to use the rcu instead.
>>
>> Cc: Viresh Kumar
>> Cc: "Rafael J. Wysocki"
>> Signed-off-by
On 5 February 2013 21:51, Viresh Kumar wrote:
> commit 15b5548c9ccfb8088270f7574710d9d67edfe33b
> Author: Viresh Kumar
> Date: Tue Feb 5 21:29:05 2013 +0530
>
> cpufreq: Make governors directory sysfs location based on
> have_multiple_policies
>
> Until now
On 6 February 2013 15:38, Amit Kucheria wrote:
> On Wed, Feb 6, 2013 at 3:28 PM, Viresh Kumar wrote:
>> I have pushed the complete patchset here:
>>
>> http://git.linaro.org/gitweb?p=people/vireshk/linux.git;a=shortlog;h=refs/heads/cpufreq-updates
>>
>
> Vires
On 6 February 2013 21:41, Dirk Brandewie wrote:
> our files are clearly out of sync :-) The code in cpufreq_add_dev() is
I was at latest bleeding-edge then, but i still have below code in my HEAD.
> #ifdef CONFIG_SMP
> /* check whether a different CPU already registered this
>
On 4 February 2013 17:52, Viresh Kumar wrote:
> On 31 January 2013 07:56, Viresh Kumar wrote:
>> With the recent changes in cpufreq core, we just need to set mask of all
>> possible cpus into policy->cpus. Rest would be done by core.
>>
>> Signed-off-by: Viresh Kum
nd so multiple struct policy exist
simultaneously.
Because this crash can only come on those.
Anyway, i have tested and pushed a fix here:
http://git.linaro.org/gitweb?p=people/vireshk/linux.git;a=shortlog;h=refs/heads/for-valdis
Please test it.
For others, the patch is:
commit 007dda326f1b141584
them in my for-rafael branch at:
http://git.linaro.org/gitweb?p=people/vireshk/linux.git;a=shortlog;h=refs/heads/for-rafael
@Artem & Valdis: Please test them and reply with your Tested-by's (in case they
work :) ).
Viresh Kumar (4):
cpufreq: governors: Fix WARN_ON() for multi
On the lines of macro: lock_policy_rwsem, we can create another macro for
unlock_policy_rwsem. Lets do it.
Signed-off-by: Viresh Kumar
---
drivers/cpufreq/cpufreq.c | 24 +---
1 file changed, 9 insertions(+), 15 deletions(-)
diff --git a/drivers/cpufreq/cpufreq.c b/drivers
against their principle
(present before their definition) at various places. This patch is an attempt to
fix their use.
Signed-off-by: Viresh Kumar
---
drivers/cpufreq/cpufreq.c | 79 +++
1 file changed, 45 insertions(+), 34 deletions(-)
diff --git a/drivers
Because the sibling cpu of any online cpu is identified very early in
cpufreq_add_dev(), below code is never executed. And so can be removed.
Signed-off-by: Viresh Kumar
---
drivers/cpufreq/cpufreq.c | 17 ++---
1 file changed, 2 insertions(+), 15 deletions(-)
diff --git a/drivers
1 - 100 of 9135 matches
Mail list logo
