and restored by hardware like WakeupGen.
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Kevin Hilman khil...@ti.com
---
arch/arm/mach-omap2/omap-wakeupgen.c | 130
arch/arm/mach-omap2/omap4-sar-layout.h | 15
2 files changed, 145 insertions(+), 0
When MPUSS hits off-mode e, L2 cache is lost. This patch adds L2X0
necessary maintenance operations and context restoration in the
low power code.
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Kevin Hilman khil...@ti.com
---
arch/arm/mach-omap2/include/mach/omap-secure.h |5
These notifiers can be used to isolate non-cpu specific PM
code from CPU idle code.
To start with, we can already leverage VFP handlers using notifier
chain for low power idle code. So use them.
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Kevin Hilman khil...@ti.com
---
arch
with local timers marked with (mis)feature flag CLOCK_EVT_FEAT_C3STOP.
Then notify the clock events layer from idle code using
CLOCK_EVT_NOTIFY_BROADCAST_ENTER/EXIT).
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Kevin Hilman khil...@ti.com
---
arch/arm/mach-omap2/cpuidle44xx.c |8
off mode, it eventually hits off state since memory
contents are lost.
Hence the MPUSS off mode independent state is not attempted without
device off mode. All the necessary infrastructure code for MPUSS
off mode is in place as part of this series.
Signed-off-by: Santosh Shilimkar santosh.shilim
-state latency profiling.
Signed-off-by: Rajendra Nayak rna...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Kevin Hilman khil...@ti.com
---
arch/arm/mach-omap2/Makefile |2 +-
arch/arm/mach-omap2/cpuidle44xx.c | 198 +
arch/arm/mach
dependencies.
Without this system locks up or randomly crashesh.
Signed-off-by: Rajendra Nayak rna...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Acked-by: Paul Walmsley p...@pwsan.com
Cc: Kevin Hilman khil...@ti.com
---
arch/arm/mach-omap2/pm44xx.c | 28
This patch adds SAR RAM support on OMAP4430. SAR RAM used to save
and restore the HW context in low power modes.
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Kevin Hilman khil...@ti.com
---
arch/arm/mach-omap2/include/mach/omap4-common.h |1 +
arch/arm/mach-omap2/omap4
Tomi,
On 8/1/2011 11:31 AM, Tomi Valkeinen wrote:
On Sat, 2011-07-09 at 18:30 -0600, Paul Walmsley wrote:
Hi Santosh,
On Sat, 9 Jul 2011, Santosh Shilimkar wrote:
Sorry for not closing the loop on this thread but I thought Tomi
root-caused the DSS timeout issue to incorrect reset sequence
+ Benoit
On 7/27/2011 11:50 AM, Archit Taneja wrote:
Fix the shift and mask macros for DSIx_PPID fields in CONTROL_DSIPHY. The Latest
TRM mentions the correct fields in the register.
You can mention the TRM version instead of 'latest'
Latest is very much relative :)
Signed-off-by: Archit
description.
- Define fields in decreasing order of the field's end bit.
Thanks for the update.
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
.../include/mach/ctrl_module_pad_core_44xx.h |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2
Shubro,
On 7/21/2011 4:39 PM, Shubhrajyoti D wrote:
Under some conditions the driver may want to do a reset
of the device. Adding a reset field to the platform
data.
Signed-off-by: Shubhrajyoti Dshubhrajy...@ti.com
---
include/linux/i2c-omap.h |1 +
1 files changed, 1 insertions(+), 0
On 7/21/2011 4:39 PM, Shubhrajyoti D wrote:
Under some error conditions the i2c driver may do a reset
adding support in the platform.
Signed-off-by: Shubhrajyoti Dshubhrajy...@ti.com
---
As commented on 1/5, this one should be folded
with 1/5 unless and until you have some valid reason.
On 7/21/2011 4:39 PM, Shubhrajyoti D wrote:
The reset in the driver at init is not needed
anymore as the hwmod framework takes care of
reseting it.
Signed-off-by: Shubhrajyoti Dshubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 73
1 files
On 7/21/2011 4:39 PM, Shubhrajyoti D wrote:
The SYSC register should not accessed in the driver removing the
define from the driver.
Signed-off-by: Shubhrajyoti Dshubhrajy...@ti.com
Looks good.
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
--
To unsubscribe from this list: send
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Keerthy,
On 7/21/2011 4:49 PM, J, KEERTHY wrote:
Hello Russel,
MADC stands for monitoring ADC. It is part of TWL4030 power IC.
TWL4030 is only on OMAP3 and hence not applicable for OMAP4.
The driver is split accross mfd and hwmon. Generic ADC
reading part is in mfd and exposing the individual
On 7/15/2011 12:54 AM, Paul Walmsley wrote:
On Wed, 13 Jul 2011, Santosh Shilimkar wrote:
From: Rajendra Nayakrna...@ti.com
Program all powerdomain target state as ON; This is to
prevent domains from hitting low power states (if bootloader
has target states set to something other than
Hi Paul,
On 7/15/2011 1:03 AM, Paul Walmsley wrote:
cc'ing Patrick
Hi Rajendra, Santosh,
some comments here:
On Wed, 13 Jul 2011, Santosh Shilimkar wrote:
While using clockdomain force wakeup method, not waiting for powerdomain
to be effectively ON may end up locking the clockdomain FSM
From: Rajendra Nayak rna...@ti.com
Program all powerdomain target state as ON; This is to
prevent domains from hitting low power states (if bootloader
has target states set to something other than ON) and potentially
even losing context while PM is not fully initilized.
The PM late init code can
from OSWR to ON.
This issue was reported and investigated by Patrick Titiano p-titi...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Signed-off-by: Rajendra Nayak rna...@ti.com
Reported-by: Patrick Titiano p-titi...@ti.com
Cc: Kevin Hilman khil...@ti.com
Cc: Benoit Cousson b-cous
machine or UP_ON_SMP policy-cpus mask would contain only
the boot CPU.
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
[santosh.shilim...@ti.com: re-based against omap cpufreq
upstream branch and fixed notifiers]
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
Cc: Kevin Hilman khil
On 7/11/2011 4:21 PM, Kevin Hilman wrote:
Fix boot crash in watchdog driver when runtime PM is disabled.
When runtime PM is disabled, devices should be left enabled so that
all device accesses in drivers will succeed even though the runtime PM
get/put calls are noops.
This is already the case
Felipe,
On 7/10/2011 2:52 AM, Felipe Balbi wrote:
From: Felipe Balbiba...@ti.com
Date: Sun, 10 Jul 2011 12:22:20 +0300
Subject: [PATCH] usb: musb: fix build breakage
Organization: Texas Instruments\n
This patch fixes the compilation brekage which
commits 208466dc (usb: otg:OMAP4430: Powerdown
+ Tomi,
On 7/9/2011 3:25 PM, Paul Walmsley wrote:
Hi
On Mon, 9 May 2011, sricharan wrote:
Paul Walmsley reported a kernel hang issue with beagle board
during boot. This is an intermittent bug and the execution was
found to be stuck at the l3 interrupt handler.
This was due to a dss
+ Benoit
On 7/5/2011 5:19 AM, Jan Weitzel wrote:
The gpmc clock on omap44xx is called gpmc_ick not gpmc_ck in
clock44xx_data.c
Signed-off-by: Jan Weitzelj.weit...@phytec.de
This happened after renaming the clock-nodes some time back.
Looks good to me as a fix though in long run GPMC should be
On 7/5/2011 11:35 AM, Kevin Hilman wrote:
Santosh Shilimkarsantosh.shilim...@ti.com writes:
+ Benoit
On 7/5/2011 5:19 AM, Jan Weitzel wrote:
The gpmc clock on omap44xx is called gpmc_ick not gpmc_ck in
clock44xx_data.c
Signed-off-by: Jan Weitzelj.weit...@phytec.de
This happened after
On 6/28/2011 3:29 PM, Colin Cross wrote:
resending as plain text
On Fri, Jun 24, 2011 at 6:53 AM, Sanjeev Premipr...@ti.com wrote:
+#ifdef CONFIG_SMP
+ /* Adjust jiffies before transition */
+ for_each_cpu(i, policy-cpus) {
+ unsigned long lpj = per_cpu(cpu_data,
On 6/28/2011 3:53 PM, Colin Cross wrote:
On Tue, Jun 28, 2011 at 3:45 PM, Santosh Shilimkar
santosh.shilim...@ti.com mailto:santosh.shilim...@ti.com wrote:
[]
Can't this rewrite the loops_per_jiffy for the other CPU while it is
in a udelay? If it has already calculated
On 6/28/2011 4:00 PM, Santosh Shilimkar wrote:
On 6/28/2011 3:53 PM, Colin Cross wrote:
On Tue, Jun 28, 2011 at 3:45 PM, Santosh Shilimkar
santosh.shilim...@ti.com mailto:santosh.shilim...@ti.com wrote:
[]
Can't this rewrite the loops_per_jiffy for the other CPU while it is
in a udelay
On 6/28/2011 4:03 PM, Russell King - ARM Linux wrote:
On Tue, Jun 28, 2011 at 03:45:22PM -0700, Santosh Shilimkar wrote:
The udelay code doesn't use the per-cpu lpj variable. It uses the global
lpj. Secondly the calibration of no. of loops to be done is
precalculateed so overwrite shouldn't
On 6/26/2011 11:53 PM, Jean Pihet wrote:
Hi Santosh,
On Sat, Jun 25, 2011 at 3:23 PM, Santosh Shilimkar
santosh.shilim...@ti.com wrote:
On 6/24/2011 7:38 AM, jean.pi...@newoldbits.com wrote:
From: Jean Pihetj-pi...@ti.com
Since cpuidle is a CPU centric framework it decides the MPU
next
On 6/24/2011 7:38 AM, jean.pi...@newoldbits.com wrote:
From: Jean Pihetj-pi...@ti.com
Since cpuidle is a CPU centric framework it decides the MPU
next power state based on the MPU exit_latency and target_residency
figures.
The rest of the power domains get their next power state programmed
with with reference to the initial values to avoid a progressively
bigger and bigger error in the value over time.
While at this also re-use the notifiers for UP/SMP since on
UP machine or UP_ON_SMP policy-cpus mask would contain only
the one CPU.
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Sanjeev,
On 6/24/2011 4:21 PM, Russell King - ARM Linux wrote:
On Fri, Jun 24, 2011 at 04:18:31PM +0530, Premi, Sanjeev wrote:
-Original Message-
From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk]
Sent: Friday, June 24, 2011 4:14 PM
To: Premi, Sanjeev
Cc:
On 6/24/2011 4:05 PM, Sanjeev Premi wrote:
This patch replaces the use of goto with simple
if...else syntax. No change in functionality.
This also means that the comment describing the
dependency between CONFIG_SMP and calculation
of loops_per_jiffy can be unified.
Signed-off-by: Sanjeev
On 6/24/2011 6:24 PM, Premi, Sanjeev wrote:
-Original Message-
From: Shilimkar, Santosh
Sent: Friday, June 24, 2011 6:18 PM
To: Premi, Sanjeev
Cc: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org
Subject: Re: [PATCH 1/2] omap2+: pm: Use if...else instead of goto
On
On 6/24/2011 6:22 PM, Premi, Sanjeev wrote:
-Original Message-
From: Shilimkar, Santosh
Sent: Friday, June 24, 2011 6:16 PM
To: Russell King - ARM Linux
Cc: Premi, Sanjeev; linux-omap@vger.kernel.org;
linux-arm-ker...@lists.infradead.org
Subject: Re: [PATCH 2/2] omap2+: pm: cpufreq: Fix
On 6/24/2011 7:23 PM, Sanjeev Premi wrote:
Currently, loops_per_jiffy is being calculated twice for
non-SMP processors.
- Before calling cpufreq_notify_transition()
- From within cpufreq_notify_transition()
Double adjustment leads to incorrect value being assigned to
loops_per_jiffy. This
On 6/24/2011 7:40 AM, Premi, Sanjeev wrote:
-Original Message-
From: Shilimkar, Santosh
Sent: Friday, June 24, 2011 8:05 PM
To: Premi, Sanjeev
Cc: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org
Subject: Re: [PATCHv2] omap2+: pm: cpufreq: Fix
loops_per_jiffy calculation
On 6/23/2011 8:35 PM, Kevin Hilman wrote:
Tony Lindgrent...@atomide.com writes:
* Santosh Shilimkarsantosh.shilim...@ti.com [110620 02:35]:
On 6/20/2011 2:53 PM, Tony Lindgren wrote:
This removes the support for setting the wake-up timer for debugging.
Later on we can reserve gptimer1 for
---
This is a nice change. In general now omap3 suspend code
is looking much cleaner and after Jean's DDR patch, it would
be even better.
For this patch, my ack if you need one
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
--
To unsubscribe from this list: send the line unsubscribe linux-omap
On 6/23/2011 2:31 AM, Russell King - ARM Linux wrote:
On Wed, Jun 22, 2011 at 04:08:16PM +0100, Russell King - ARM Linux wrote:
Tested on Assabet (SA1100) and 3430LDP only.
Correction - because suspend only goes into retention mode, these
changes have not been tested on the 3430. Someone who
On 6/22/2011 9:40 PM, Russell King - ARM Linux wrote:
A couple of things to point out here:
On Wed, Jun 22, 2011 at 04:16:58PM +0100, Russell King - ARM Linux wrote:
- mrc p15, 0, r4, c13, c0, 1 @ Context ID
- mrc p15, 0, r5, c13, c0, 2 @ User r/w thread and process ID
-
Russell,
On 6/20/2011 8:24 PM, Santosh Shilimkar wrote:
On 6/20/2011 7:53 PM, Russell King - ARM Linux wrote:
On Mon, Jun 20, 2011 at 12:40:19PM +0100, Russell King - ARM Linux wrote:
[]
So, as loops_per_jiffy is not local to this function, the compiler has
to write out that zero value
On 6/21/2011 3:30 PM, Russell King - ARM Linux wrote:
On Tue, Jun 21, 2011 at 02:38:34PM +0530, Santosh Shilimkar wrote:
Russell,
On 6/20/2011 8:24 PM, Santosh Shilimkar wrote:
On 6/20/2011 7:53 PM, Russell King - ARM Linux wrote:
So, as loops_per_jiffy is not local to this function
On 6/21/2011 3:49 PM, Russell King - ARM Linux wrote:
On Tue, Jun 21, 2011 at 03:47:04PM +0530, Santosh Shilimkar wrote:
[...]
I already have that as a separate change.
Can you point me to both of these commits so that I have
them in my tree for testing.
I won't be committing the init
cpu
and and selects a fallback runqueue.
Secondly marking CPU active before it is online also not desirable behaviour.
Fix this race conditions.
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Thomas Gleixner t...@linutronix.de
Cc: Peter Zijlstra pet...@infradead.org
Cc: Russell
On 6/20/2011 2:53 PM, Tony Lindgren wrote:
This removes the support for setting the wake-up timer for debugging.
Later on we can reserve gptimer1 for PM code only and have similar
functionality.
Signed-off-by: Tony Lindgrent...@atomide.com
Reviewed-by: Kevin Hilmankhil...@ti.com
---
Kevin
On 6/20/2011 3:20 PM, Russell King - ARM Linux wrote:
On Mon, Jun 20, 2011 at 02:53:59PM +0530, Santosh Shilimkar wrote:
The current ARM CPU hotplug code suffers from couple of race conditions
in CPU online path with scheduler.
The ARM CPU hotplug code doesn't wait for hot-plugged CPU
On 6/20/2011 3:44 PM, Russell King - ARM Linux wrote:
On Mon, Jun 20, 2011 at 10:50:53AM +0100, Russell King - ARM Linux wrote:
On Mon, Jun 20, 2011 at 02:53:59PM +0530, Santosh Shilimkar wrote:
The current ARM CPU hotplug code suffers from couple of race conditions
in CPU online path
On 6/20/2011 4:05 PM, Russell King - ARM Linux wrote:
On Mon, Jun 20, 2011 at 03:58:03PM +0530, Santosh Shilimkar wrote:
On 6/20/2011 3:44 PM, Russell King - ARM Linux wrote:
On Mon, Jun 20, 2011 at 10:50:53AM +0100, Russell King - ARM Linux wrote:
On Mon, Jun 20, 2011 at 02:53:59PM +0530
On 6/20/2011 4:14 PM, Russell King - ARM Linux wrote:
On Mon, Jun 20, 2011 at 03:58:03PM +0530, Santosh Shilimkar wrote:
No it doesn't work. I still get the crash. The important point
here is not to enable interrupts before CPU is marked
as online and active.
What is the crash (in full please
On 6/20/2011 4:43 PM, Russell King - ARM Linux wrote:
On Mon, Jun 20, 2011 at 04:17:58PM +0530, Santosh Shilimkar wrote:
Yes. It's because of interrupt and the CPU active-online
race.
I don't see that as a conclusion from this dump.
Here is the chash log..
[ 21.025451] CPU1: Booted
On 6/20/2011 4:15 PM, Santosh Shilimkar wrote:
On 6/20/2011 4:05 PM, Russell King - ARM Linux wrote:
On Mon, Jun 20, 2011 at 03:58:03PM +0530, Santosh Shilimkar wrote:
On 6/20/2011 3:44 PM, Russell King - ARM Linux wrote:
On Mon, Jun 20, 2011 at 10:50:53AM +0100, Russell King - ARM Linux
On 6/20/2011 5:10 PM, Russell King - ARM Linux wrote:
On Mon, Jun 20, 2011 at 04:55:43PM +0530, Santosh Shilimkar wrote:
On 6/20/2011 4:43 PM, Russell King - ARM Linux wrote:
On Mon, Jun 20, 2011 at 04:17:58PM +0530, Santosh Shilimkar wrote:
Yes. It's because of interrupt and the CPU active
On 6/20/2011 5:49 PM, Russell King - ARM Linux wrote:
On Mon, Jun 20, 2011 at 05:21:48PM +0530, Santosh Shilimkar wrote:
On 6/20/2011 5:10 PM, Russell King - ARM Linux wrote:
[...]
Any pointers on the other question about why we need to enable
interrupts before the CPU is ready
On 6/20/2011 7:53 PM, Russell King - ARM Linux wrote:
On Mon, Jun 20, 2011 at 12:40:19PM +0100, Russell King - ARM Linux wrote:
Ok. So loops_per_jiffy must be too small. My guess is you're using an
older kernel without 71c696b1 (calibrate: extract fall-back calculation
into own helper).
On 6/20/2011 8:31 PM, Russell King - ARM Linux wrote:
On Mon, Jun 20, 2011 at 08:24:33PM +0530, Santosh Shilimkar wrote:
I am away from my board now. Will test this change.
btw, the online-active race is still open even with this patch close
and should be fixed.
I have yet to see any evidence
On 6/19/2011 10:37 AM, linx...@ovi.com wrote:
Hi All,
I was wondering whether it is possible to keep the Cortex M3 cores running
while the OMAP processor is suspended.
My testing environment was simple: I used Pandaboard (OMAP4430) and kernel
2.6.35. I wrote an M3 program to toggle one GPIO
On 6/17/2011 2:28 PM, Jean Pihet wrote:
Hi Santosh,
[]
-omap3_do_wfi:
+do_WFI:
+ ldr r4, cm_clkstctrl_core @ read the CLKSTCTRL_CORE
+ ldr r5, [r4]@ read the contents of
CLKSTCTRL_CORE
+ and r5, r5, #0x3
+ cmp r5, #0x3
+
RET and OFF modes.
Signed-off-by: Jean Pihetj-pi...@ti.com
As mentioned in the other thread, with auto-deps set always
which is the case on OMAP3, this patch is safe.
FWIW: Acked-by: Santosh Shilimkar santosh.shilim...@ti.comc
---
arch/arm/mach-omap2/pm.h| 20 ++-
arch/arm/mach
On 6/17/2011 9:29 PM, Kevin Hilman wrote:
Hi Santosh,
Santosh Shilimkarsantosh.shilim...@ti.com writes:
On 6/17/2011 2:28 PM, Jean Pihet wrote:
Hi Santosh,
[]
-omap3_do_wfi:
+do_WFI:
+ ldr r4, cm_clkstctrl_core @ read the CLKSTCTRL_CORE
+ ldr r5, [r4]
PM, Santosh Shilimkar
santosh.shilim...@ti.com wrote:
Jean,
-Original Message-
From: Santosh Shilimkar [mailto:santosh.shilim...@ti.com]
Sent: Tuesday, February 01, 2011 5:01 PM
To: Jean Pihet
Cc: linux-omap@vger.kernel.org; Jean Pihet-XID
Subject: RE: [RFC/PATCH] OMAP3: run the ASM sleep
On 6/14/2011 9:08 PM, Menon, Nishanth wrote:
On Tue, Jun 14, 2011 at 08:03, Santosh Shilimkar
santosh.shilim...@ti.com wrote:
With RCU debug options enabled, below warning is observed.
===
[ INFO: suspicious rcu_dereference_check() usage
!
other info that might help us debug this:
rcu_scheduler_active = 1, debug_locks = 1
no locks held by swapper/1.
...
---
Fix the same by protecting it with rcu_read lock.
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Rafael J
disabling SMP
Signed-off-by: Miguel Vadillovadi...@ti.com
---
arch/arm/mach-omap2/include/mach/omap4-common.h |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
diff --git a/arch/arm/mach-omap2/include/mach/omap4-common.h
b
it's ready for merge.
Tested-by: Santosh Shilimkar santosh.shilim...@ti.com
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
Kevin Hilman (4):
OMAP3: PM debug: remove sleep_while_idle feature
OMAP2: PM debug: remove register dumping
OMAP3: PM debug: remove register dumping
OMAP2: PM
On 6/13/2011 8:05 PM, Tony Lindgren wrote:
* Santosh Shilimkarsantosh.shilim...@ti.com [110612 23:32]:
On 6/13/2011 11:55 AM, Vadillo, Miguel wrote:
Function omap_smc2 is undeclared when disabling SMP
Looks like this won't apply to current mainline kernel, care
to check if it's still
On 6/13/2011 8:19 PM, Vadillo, Miguel wrote:
Yes, sorry about this mistake, the patch its just for an internal tree
and I wasn't careful enough to check the mainline. Sorry about the
noise.
Thanks for confirming it.
Regards
Santosh
--
To unsubscribe from this list: send the line unsubscribe
...@google.com
Looks good to me.
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/omap2plus-cpufreq.c |4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/omap2plus-cpufreq.c
b/arch/arm/mach-omap2/omap2plus-cpufreq.c
index
On 6/7/2011 7:35 AM, Nishanth Menon wrote:
Since we do module_init, cpufreq initializes before power late_init
where many of the required data structures are registered. Move
cpufreq init to late_initcall instead. Further CONFIG_CPU_FREQ
on which the build depends is bool and does'nt support
Shilimkarsantosh.shilim...@ti.com
Signed-off-by: Oleg Drokingr...@linuxhacker.ru
---
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http
.
Signed-off-by: Colin Crossccr...@android.com
Looks good. This needs to be fixed on top of the clean-up
branch where GPIO movemnt to driver/gpio/* happening.
For this change,
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
--
To unsubscribe from this list: send the line unsubscribe linux
On 6/3/2011 4:40 AM, Kevin Hilman wrote:
Santosh Shilimkarsantosh.shilim...@ti.com writes:
Current OMAP2PLUS CPUfreq tagret() functions returns when all
the CPU's are not online. This will break DVFS when secondary
CPUs are offlined.
The intention of that check was just avoid CPU frequency
On 6/3/2011 8:14 AM, Menon, Nishanth wrote:
On Thu, Jun 2, 2011 at 09:51, Santosh Shilimkar
santosh.shilim...@ti.com wrote:
Current OMAP2PLUS CPUfreq tagret() functions returns when all
the CPU's are not online. This will break DVFS when secondary
CPUs are offlined.
The intention
On 6/3/2011 11:56 AM, Santosh Shilimkar wrote:
On 6/3/2011 4:40 AM, Kevin Hilman wrote:
Santosh Shilimkarsantosh.shilim...@ti.com writes:
Current OMAP2PLUS CPUfreq tagret() functions returns when all
the CPU's are not online. This will break DVFS when secondary
CPUs are offlined
Nishant,
On 6/3/2011 12:09 PM, Santosh Shilimkar wrote:
On 6/3/2011 8:14 AM, Menon, Nishanth wrote:
On Thu, Jun 2, 2011 at 09:51, Santosh Shilimkar
santosh.shilim...@ti.com wrote:
Current OMAP2PLUS CPUfreq tagret() functions returns when all
the CPU's are not online. This will break DVFS when
On 6/3/2011 2:01 PM, Santosh Shilimkar wrote:
On 6/3/2011 11:56 AM, Santosh Shilimkar wrote:
On 6/3/2011 4:40 AM, Kevin Hilman wrote:
[...]
Can do that as well.
After re-looking at this, seems not straight forward. This check is
not for cpufreqdriver_init time but per-CPU init functions
().
Thanks for Nishant Menon n...@ti.com for reporting issue
with hot-plug and Kevin Hilman khil...@ti.com for his
comment on excessive check in target().
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Reported-by: Nishanth Menon n...@ti.com
Tested-by: Vishwanath BS vishwanath...@ti.com
HIGMEM support is kernel is quite mature now and we have boards
like ZOOM, PANDA, SDP where 1 GB memories are installed.
Enable HIGMEM to make use of the additional memory.
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
This won't boards which doesn't have excess memory. Tested
Fixing the change log ...
On 6/2/2011 5:36 PM, Santosh Shilimkar wrote:
HIGMEM support is kernel is quite mature now and we have boards
HIGMEM support in kernel is quite mature now and we have boards
like ZOOM, PANDA, SDP where 1 GB memories are installed.
Enable HIGMEM to make use
On 6/2/2011 6:51 PM, Premi, Sanjeev wrote:
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of
Shilimkar, Santosh
Sent: Thursday, June 02, 2011 5:36 PM
To: linux-omap@vger.kernel.org
Cc: Shilimkar, Santosh
Subject: [PATCH RFC]
the check accordingly.
Thanks for Nishant Menon n...@ti.com for reporting it.
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Reported-by: Nishanth Menon n...@ti.com
Tested-by: Vishwanath BS vishwanath...@ti.com
---
There were some question of making the variable atomic etc
in an internal
Missed Kevin in cc. :(
Sorry about that.
Original Message
Subject: [PATCH] OMAP2+: CPUfreq: Allow the CPU scaling when secondary
CPUs are offline.
Date: Thu, 2 Jun 2011 20:21:10 +0530
From: Santosh Shilimkar santosh.shilim...@ti.com
To: linux-omap@vger.kernel.org
CC: Santosh
On 5/31/2011 12:16 PM, T Krishnamoorthy, Balaji wrote:
On Mon, May 30, 2011 at 6:03 PM, Santosh Shilimkar
santosh.shilim...@ti.com wrote:
While trying out V3.0-rc1, I noticed couple of regressions. Am
posting this in case anybody come across same issues.
1.OMAP MMC code keep throwing Pbias
'.
If runtime configuration of this is needed, then adding a debugfs
entry for the ARM-generic hlt/nohlt interface should be added.
Signed-off-by: Kevin Hilmankhil...@ti.com
This makes it easy for future OMAP PM code as well.
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
Regards
Santosh
On 5/27/2011 4:32 AM, Kevin Hilman wrote:
Signed-off-by: Kevin Hilmankhil...@ti.com
Do you plan to keep wroking the patch which dumps registers
before and after WFI ?
Ofcourse this patch is in your pm-debug branch.
For this change
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
and indeed it doesn't scale for OMAP4.
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Kevin,
On 5/27/2011 10:48 AM, Santosh Shilimkar wrote:
On 5/27/2011 4:32 AM, Kevin Hilman wrote:
Move suspend wakeup timer from suspend path to be triggered based
on clockevent suspend path.
When gptimers are eventually converted to be a driver, the wakeup
timer feature can be made
On 5/30/2011 1:38 PM, Jean Pihet wrote:
On Mon, May 30, 2011 at 9:21 AM, Santosh Shilimkar
santosh.shilim...@ti.com wrote:
Kevin,
On 5/27/2011 10:48 AM, Santosh Shilimkar wrote:
On 5/27/2011 4:32 AM, Kevin Hilman wrote:
Move suspend wakeup timer from suspend path to be triggered based
The commit '99aa18278e' removed the boot messege for OMAP3. Do the same
for OMAP2 and OMAP4 since it's really just noise in the boot log
and PM init is always called.
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Kevin Hilman khil...@ti.com
---
Generated against mainline v3.0-rc1
While trying out V3.0-rc1, I noticed couple of regressions. Am
posting this in case anybody come across same issues.
1.OMAP MMC code keep throwing Pbias Voltage is not same as LDO error
continuously.
Balaji is planning post right fix for the same, but just
in case you get around this issue,
Tony,
On 5/30/2011 1:35 PM, Tony Lindgren wrote:
* Kevin Hilmankhil...@ti.com [110527 14:24]:
FYI... I just found this, but won't be able to look into it until next
week, so if anyone needs a weekend debug project...
Using Tony's for-next branch, I'm able to boot an omap2plus_defconfig (+
On 5/30/2011 7:06 PM, Sergei Shtylyov wrote:
Hello.
Santosh Shilimkar wrote:
The commit '99aa18278e' removed the boot messege for OMAP3. Do the same
Please specify that commit's summary in parens -- for the human readers.
Oh, and you don't need quotes around commit ID too.
Yes I missed
Todd,
On 5/28/2011 8:54 AM, Todd Poynor wrote:
* Make variables static.
* Define L3 TARG instance offsets, and read/write STDERRLOG registers
relative to those offsets, rather than defining STDERRLOG_MAIN
instance offsets and accessing other registers via offsets from
that register.
On 5/27/2011 11:37 AM, Menon, Nishanth wrote:
On Thu, May 26, 2011 at 22:06, Santosh Shilimkar
santosh.shilim...@ti.com wrote:
On 5/26/2011 11:40 PM, Kevin Hilman wrote:
So here's a dumb question, being rather ignorant of CPUfreq on SMP.
Should we be running a CPUfreq instance on both CPUs
On 5/27/2011 8:13 PM, Cousson, Benoit wrote:
On 5/27/2011 2:46 PM, Valkeinen, Tomi wrote:
On Fri, 2011-05-27 at 14:38 +0200, Cousson, Benoit wrote:
Hi Tomi,
On 5/27/2011 9:38 AM, Valkeinen, Tomi wrote:
Add omap_device_reset() function which can be used to reset the hwmods
associated with the
On 5/27/2011 8:30 PM, Cousson, Benoit wrote:
On 5/27/2011 4:51 PM, Shilimkar, Santosh wrote:
On 5/27/2011 8:13 PM, Cousson, Benoit wrote:
On 5/27/2011 2:46 PM, Valkeinen, Tomi wrote:
On Fri, 2011-05-27 at 14:38 +0200, Cousson, Benoit wrote:
Hi Tomi,
On 5/27/2011 9:38 AM, Valkeinen, Tomi
On 5/26/2011 6:30 PM, Silesh C V wrote:
Get rid of the following and 8 other similar section mismatch
warnings
I send this [1] patch a month back. It's still not considered
though even after reminder.
Regards
Santosh
[1] https://patchwork.kernel.org/patch/684831/
--
To unsubscribe from this
1001 - 1100 of 1830 matches
Mail list logo
