On Wednesday 24 July 2013 01:21 PM, Nishanth Menon wrote:
> On 07/24/2013 12:49 AM, Viresh Kumar wrote:
>> Adding more relevant list in cc.
>>
>> On 23 July 2013 16:05, Ryan wrote:
>>> Hi,
>>>
>>> I have some doubts on backup and restore operation. From what i understand:
>>>
>>> We copy all regis
On Thursday 21 February 2013 02:31 PM, Daniel Lezcano wrote:
On 02/21/2013 07:19 AM, Santosh Shilimkar wrote:
On Tuesday 19 February 2013 11:51 PM, Daniel Lezcano wrote:
On 02/19/2013 07:10 PM, Thomas Gleixner wrote:
On Tue, 19 Feb 2013, Daniel Lezcano wrote:
I am working on identifying the
ctiveness of such optimization solely depends
on how well the affinity (in low powers) supported by your IRQ chip.
Hope this is helpful for you.
Regards,
Santosh
From d70f2d48ec08a3f1d73187c49b16e4e60f81a50c Mon Sep 17 00:00:00 2001
From: Santosh Shilimkar
Date: Wed, 25 Jul 2012 03:42:33 +0530
S
Viresh,
On Friday 01 February 2013 02:22 PM, Santosh Shilimkar wrote:
On Friday 01 February 2013 01:32 PM, Viresh Kumar wrote:
On 1 February 2013 13:03, Santosh Shilimkar
wrote:
I am not talking about just notifiers. This is for external users who
has subscribed for notifiers. The point is
On Friday 01 February 2013 01:32 PM, Viresh Kumar wrote:
On 1 February 2013 13:03, Santosh Shilimkar wrote:
I am not talking about just notifiers. This is for external users who
has subscribed for notifiers. The point is whether the core CPUFReq
gets updated without that flag for all affected
On Friday 01 February 2013 12:43 PM, Viresh Kumar wrote:
On 1 February 2013 12:17, Santosh Shilimkar wrote:
I haven't looked at the cpufreq code recently but remember
that it was needed to ensure that all the CPU which
share clock/voltage gets updated (affected cpus) on
freq change. The
ore
http://bugzilla.kernel.org/show_bug.cgi?id=5737
Many non-ACPI systems are filling this field by mistake, which makes its usage
confusing. Lets clean it.
Signed-off-by: Viresh Kumar
Cc: Linus Walleij
Cc: Stephen Warren
Cc: Shawn Guo
Cc: Santosh Shilimkar
---
I haven't looked at the
On Monday 21 January 2013 07:47 PM, Daniel Lezcano wrote:
Hi All,
I have a question regarding the behavior of cpuidle on pandaboard.
1. cpuidle is enabled
2. The deep idle states seem to be reach
for i in $(find /sys/devices/system/cpu -name "usage"); do echo "$i :
$(cat $i)"; done
/sys/devi
On Monday 29 October 2012 06:58 PM, Vincent Guittot wrote:
On 24 October 2012 17:21, Santosh Shilimkar wrote:
On Sunday 07 October 2012 01:13 PM, Vincent Guittot wrote:
The ARM platforms take advantage of packing small tasks on few cores.
This is true even when the cores of a cluster can&#
On Monday 29 October 2012 06:57 PM, Vincent Guittot wrote:
On 24 October 2012 17:21, Santosh Shilimkar wrote:
On Sunday 07 October 2012 01:13 PM, Vincent Guittot wrote:
Look for an idle CPU close the pack buddy CPU whenever possible.
s/close/close to
yes
The goal is to prevent the
On Monday 29 October 2012 06:42 PM, Vincent Guittot wrote:
On 24 October 2012 17:20, Santosh Shilimkar wrote:
Vincent,
Few comments/questions.
On Sunday 07 October 2012 01:13 PM, Vincent Guittot wrote:
During sched_domain creation, we define a pack buddy CPU if available.
On a system
On Monday 29 October 2012 03:20 PM, Vincent Guittot wrote:
It looks like i need to describe more what
On 29 October 2012 10:40, Vincent Guittot wrote:
On 24 October 2012 17:17, Santosh Shilimkar wrote:
Vincent,
Few comments/questions.
On Sunday 07 October 2012 01:13 PM, Vincent Guittot
On Sunday 07 October 2012 01:13 PM, Vincent Guittot wrote:
The ARM platforms take advantage of packing small tasks on few cores.
This is true even when the cores of a cluster can't be powergated
independently.
Signed-off-by: Vincent Guittot
---
arch/arm/kernel/topology.c |5 +
1 file
On Sunday 07 October 2012 01:13 PM, Vincent Guittot wrote:
Look for an idle CPU close the pack buddy CPU whenever possible.
s/close/close to
The goal is to prevent the wake up of a CPU which doesn't share the power
line of the pack CPU
Signed-off-by: Vincent Guittot
---
kernel/sched/fair.c
$subject is bit confusing here.
On Sunday 07 October 2012 01:13 PM, Vincent Guittot wrote:
The atomic update of runnable_avg_sum and runnable_avg_period are ensured
by their size and the toolchain. But we must ensure to not read an old value
for one field and a newly updated value for the other
Vincent,
Few comments/questions.
On Sunday 07 October 2012 01:13 PM, Vincent Guittot wrote:
During sched_domain creation, we define a pack buddy CPU if available.
On a system that share the powerline at all level, the buddy is set to -1
On a dual clusters / dual cores system which can powerga
Vincent,
Few comments/questions.
On Sunday 07 October 2012 01:13 PM, Vincent Guittot wrote:
This new flag SD SHARE_POWERLINE reflects the sharing of the power rail
between the members of a domain. As this is the current assumption of the
scheduler, the flag is added to all sched_domain
Signed-
Daniel,
On Wednesday 21 March 2012 02:57 PM, Daniel Lezcano wrote:
> This patchset is a proposition to improve a bit the code.
> The changes are code cleanup and does not change the behavior of the
> driver itself.
>
> A couple a things call my intention. Why the cpuidle device is set for cpu0
>
On Wednesday 21 March 2012 03:16 PM, Daniel Lezcano wrote:
> On 03/21/2012 10:41 AM, Shilimkar, Santosh wrote:
>> On Wed, Mar 21, 2012 at 2:57 PM, Daniel Lezcano
>> wrote:
>>> The 'valid' field is never used in the code, let's remove it.
>>>
>>> Signed-off-by: Daniel Lezcano
>>> ---
>> It is used
On Wednesday 21 March 2012 03:21 PM, Daniel Lezcano wrote:
> On 03/21/2012 10:36 AM, Shilimkar, Santosh wrote:
>> On Wed, Mar 21, 2012 at 2:57 PM, Daniel Lezcano
>> wrote:
>>> This patchset is a proposition to improve a bit the code.
>>> The changes are code cleanup and does not change the behavi
On Wednesday 21 March 2012 02:57 PM, Daniel Lezcano wrote:
> Signed-off-by: Daniel Lezcano
> ---
> arch/arm/mach-omap2/cpuidle44xx.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/cpuidle44xx.c
> b/arch/arm/mach-omap2/cpuidle44xx.c
> index 045
+ Jean,
On Wednesday 21 March 2012 02:57 PM, Daniel Lezcano wrote:
> The cpuidle API allows to declare statically the states in the driver
> structure. Let's use it.
> We do no longer need the fill_cstate function called at runtime and
> by the way adding more instructions at boot time.
>
> Signe
On 7/22/2011 6:15 PM, Woodruff, Richard wrote:
From: linux-arm-kernel-boun...@lists.infradead.org [mailto:linux-arm-
kernel-boun...@lists.infradead.org] On Behalf Of Shilimkar, Santosh
With fixed IRQ migration and forcing CPU0 into an infinite WFI loop,
I can offline CPU0 and still have a ru
On 7/22/2011 12:36 AM, Colin Cross wrote:
On Thu, Jul 21, 2011 at 3:46 AM, Santosh Shilimkar
wrote:
On 7/21/2011 3:57 PM, Lorenzo Pieralisi wrote:
On Thu, Jul 21, 2011 at 09:32:12AM +0100, Santosh Shilimkar wrote:
Lorenzo, Colin,
On 7/7/2011 9:20 PM, Lorenzo Pieralisi wrote:
From
On 7/21/2011 7:00 PM, Russell King - ARM Linux wrote:
On Thu, Jul 21, 2011 at 11:03:04AM +0530, Santosh Shilimkar wrote:
Just talking on behalf of OMAP, we can't offline CPU0 and limitation
would remain in future OMAPs too.
Apart from the broken IRQ migration, and the way CPU0 immedi
On 7/21/2011 3:57 PM, Lorenzo Pieralisi wrote:
On Thu, Jul 21, 2011 at 09:32:12AM +0100, Santosh Shilimkar wrote:
Lorenzo, Colin,
On 7/7/2011 9:20 PM, Lorenzo Pieralisi wrote:
From: Colin Cross
When the cpu is powered down in a low power mode, the gic cpu
interface may be reset, and when the
Lorenzo, Colin,
On 7/7/2011 9:20 PM, Lorenzo Pieralisi wrote:
From: Colin Cross
When the cpu is powered down in a low power mode, the gic cpu
interface may be reset, and when the cpu complex is powered
down, the gic distributor may also be reset.
This patch uses CPU_PM_ENTER and CPU_PM_EXIT no
On 7/21/2011 8:32 AM, Rob Herring wrote:
On 07/20/2011 06:32 PM, Mike Turquette wrote:
A quick poll of the ARM platforms that implement CPU Hotplug support
shows that every platform treats CPU 0 as a special case that cannot be
hotplugged. In fact every platform has identical code for
platform_
On 7/11/2011 1:14 PM, Russell King - ARM Linux wrote:
On Mon, Jul 11, 2011 at 01:05:20PM -0700, Santosh Shilimkar wrote:
(Just to add few more points on top of what Colin already commented)
On 7/11/2011 11:40 AM, Russell King - ARM Linux wrote:
On Mon, Jul 11, 2011 at 03:00:47PM +0100
On 7/11/2011 12:19 PM, Russell King - ARM Linux wrote:
On Mon, Jul 11, 2011 at 11:51:00AM -0700, Colin Cross wrote:
On Mon, Jul 11, 2011 at 11:40 AM, Russell King - ARM Linux
wrote:
On Mon, Jul 11, 2011 at 03:00:47PM +0100, Lorenzo Pieralisi wrote:
Well, short answer is no. On SMP we do need
(Just to add few more points on top of what Colin already commented)
On 7/11/2011 11:40 AM, Russell King - ARM Linux wrote:
On Mon, Jul 11, 2011 at 03:00:47PM +0100, Lorenzo Pieralisi wrote:
Well, short answer is no. On SMP we do need to save CPU registers
but if just one single cpu is shutdown
On 7/9/2011 4:05 PM, Russell King - ARM Linux wrote:
On Sat, Jul 09, 2011 at 04:01:19PM -0700, Colin Cross wrote:
On Sat, Jul 9, 2011 at 3:33 PM, Russell King - ARM Linux
wrote:
On Sat, Jul 09, 2011 at 03:10:56PM -0700, Colin Cross wrote:
This is necessary for cpuidle states that lose the GI
On 7/7/2011 8:50 AM, Lorenzo Pieralisi wrote:
This patch adds the required Kconfig and Makefile entries to
enable and compile common idle code for ARM kernel.
Common idle code depends on CPU_PM platform notifiers to trigger
save/restore of kernel subsystems like PMU, VFP, GIC.
Signed-off-by: Lo
On 7/7/2011 8:50 AM, Lorenzo Pieralisi wrote:
This patch adds the code required to allocate and populate page tables
that are needed by save/restore code to deal with MMU off/on
transactions.
MMU is enabled early in the resume path which allows to call into
Linux subsystems with init_mm virtual
On 7/7/2011 8:50 AM, Lorenzo Pieralisi wrote:
When the system hits deep low power states the L2 cache controller
can lose its internal logic values and possibly its TAG/DATA RAM content.
This patch adds save/restore hooks to the L2x0 subsystem to save/restore
L2x0 registers and clean/invalidate/
On 7/7/2011 8:50 AM, Lorenzo Pieralisi wrote:
When a CLUSTER is powered down the SCU must be reinitialized on
warm-boot.
This patch adds a hook to reset the SCU, which implies invalidating
TAG RAMs and renabling it.
The scu virtual address is saved in a static variable when the SCU
is first enab
On 7/7/2011 6:41 PM, Colin Cross wrote:
On Thu, Jul 7, 2011 at 6:35 PM, Santosh Shilimkar
wrote:
On 7/7/2011 8:50 AM, Lorenzo Pieralisi wrote:
From: Colin Cross
When the cpu is powered down in a low power mode, the gic cpu
interface may be reset, and when the cpu complex is powered
down
On 7/7/2011 8:50 AM, Lorenzo Pieralisi wrote:
This patch provides the code infrastructure needed to maintain
a generic per-cpu architecture implementation of idle code.
sr_platform.c :
- code manages patchset initialization and memory management
sr_context.c:
- code initializes
On 7/7/2011 8:50 AM, Lorenzo Pieralisi wrote:
In order to define a common idle interface for the kernel
to enter low power modes, this patch provides include files
and code that manages OS calls for low power entry and exit.
[]
diff --git a/arch/arm/kernel/sr_entry.S b/arch/arm/kernel/sr
On 7/7/2011 8:50 AM, Lorenzo Pieralisi wrote:
From: Colin Cross
When the cpu is powered down in a low power mode, the gic cpu
interface may be reset, and when the cpu complex is powered
down, the gic distributor may also be reset.
This patch uses CPU_PM_ENTER and CPU_PM_EXIT notifiers to save
a
On 7/7/2011 8:50 AM, Lorenzo Pieralisi wrote:
From: Colin Cross
During some CPU power modes entered during idle, hotplug and
suspend, peripherals located in the CPU power domain, such as
the GIC and VFP, may be powered down. Add a notifier chain
that allows drivers for those peripherals to be n
Minor nit,
On 7/7/2011 8:50 AM, Lorenzo Pieralisi wrote:
From: Will Deacon
This patch adds simple definitions of cpu_reset for ARMv6 and ARMv7
cores, which disable the MMU via the SCTLR.
Signed-off-by: Will Deacon
---
arch/arm/mm/proc-v6.S |5 +
arch/arm/mm/proc-v7.S |7 +++
On 5/6/2011 7:57 PM, Santosh Shilimkar wrote:
On 5/6/2011 7:03 PM, Paolo Pisati wrote:
On 05/06/2011 03:12 PM, Santosh Shilimkar wrote:
[...]
wrong id on the datasheet?
Not sure. Will confirm with TI hardware team but am quite certain about
the PL310 version used on OMAP4430.
Got
On 5/6/2011 7:03 PM, Paolo Pisati wrote:
On 05/06/2011 03:12 PM, Santosh Shilimkar wrote:
Something wrong in ID decoding. The actual PL310 version used
on OMAP4430 ES2.x is r2p0 and hence errata 753970 is NA for
OMAP4430 PANDA/BLAZE/SDP.
weird since it's just a pci read:
arm/mm/cache
On 5/6/2011 2:22 PM, Paolo Pisati wrote:
flag@omap:~$ dmesg | grep -A 1 L310
[0.219024] L310 cache controller enabled
[0.219055] l2x0: 16 ways, CACHE_ID 0x41c4, AUX_CTRL 0x7e47,
Cache size: 1048576 B
^^
according to [1], t
> -Original Message-
> From: Kevin Hilman [mailto:khil...@ti.com]
> Sent: Tuesday, March 08, 2011 3:05 AM
> To: Santosh Shilimkar
> Cc: Dave Martin; linux-arm-ker...@lists.infradead.org;
> patc...@linaro.org; Tony Lindgren; Jean Pihet-XID; linux-
> o...@vger.kern
Dave,
> -Original Message-
> From: Dave Martin [mailto:dave.mar...@linaro.org]
> Sent: Friday, March 04, 2011 11:05 PM
> To: linux-arm-ker...@lists.infradead.org
> Cc: patc...@linaro.org; Tony Lindgren; Santosh Shilimkar; Jean
> Pihet; Kevin Hilman; linux-o...@vger.k
> -Original Message-
> From: linaro-dev-boun...@lists.linaro.org [mailto:linaro-dev-
> boun...@lists.linaro.org] On Behalf Of Turgis, Frederic
> Sent: Monday, February 21, 2011 11:20 PM
> To: linaro-dev@lists.linaro.org
> Subject: linaro-omap kernel 1003.6 boot failure
>
> Hi, (writing from
> -Original Message-
> From: linaro-dev-boun...@lists.linaro.org [mailto:linaro-dev-
> boun...@lists.linaro.org] On Behalf Of Vincent Guittot
> Sent: Monday, February 07, 2011 5:34 PM
> To: Vishwanath Sripathy
> Cc: linaro-dev@lists.linaro.org
> Subject: Re: [PM] cpufreq test
>
> On 7 Febru
> -Original Message-
> From: Dave Martin [mailto:dave.mar...@linaro.org]
> Sent: Wednesday, December 08, 2010 4:35 PM
> To: Santosh Shilimkar
> Cc: Tony Lindgren; linux-o...@vger.kernel.org; linaro-
> d...@lists.linaro.org; linux-arm-ker...@lists.infradead.org
> Subje
> -Original Message-
> From: Dave Martin [mailto:dave.mar...@linaro.org]
> Sent: Wednesday, December 08, 2010 4:11 PM
> To: Santosh Shilimkar
> Cc: linux-arm-ker...@lists.infradead.org; Tony Lindgren; linux-
> o...@vger.kernel.org; linaro-dev@lists.linaro.org
> Subje
Dave,
> -Original Message-
> From: Santosh Shilimkar [mailto:santosh.shilim...@ti.com]
> Sent: Wednesday, December 08, 2010 11:27 AM
> To: Dave Martin
> Cc: linux-arm-ker...@lists.infradead.org; Tony Lindgren; linux-
> o...@vger.kernel.org; linaro-dev@lists.linaro
> -Original Message-
> From: Dave Martin [mailto:dave.mar...@linaro.org]
> Sent: Tuesday, December 07, 2010 10:21 PM
> To: Santosh Shilimkar
> Cc: linux-arm-ker...@lists.infradead.org; Tony Lindgren; linux-
> o...@vger.kernel.org; linaro-dev@lists.linaro.org
> Subje
Dave,
> -Original Message-
> From: linaro-dev-boun...@lists.linaro.org [mailto:linaro-dev-
> boun...@lists.linaro.org] On Behalf Of Dave Martin
> Sent: Monday, December 06, 2010 11:06 PM
> To: linux-arm-ker...@lists.infradead.org
> Cc: Tony Lindgren; Dave Martin; linux-o...@vger.kernel.org;
bol, which will
> ensure that link-time fixups don't accidentally switch to the
> wrong instruction set.
>
> omap_secondary_startup might still need to be changed to ARM,
> depending on the compatibility status of bootloaders.
>
> Signed-off-by: Dave Martin
> ---
>
Dave,
> -Original Message-
> From: linaro-dev-boun...@lists.linaro.org [mailto:linaro-dev-
> boun...@lists.linaro.org] On Behalf Of Dave Martin
> Sent: Monday, December 06, 2010 11:06 PM
> To: linux-arm-ker...@lists.infradead.org
> Cc: Tony Lindgren; Dave Martin; linux-o...@vger.kernel.org;
56 matches
Mail list logo
