On Monday 25 March 2013 05:57 PM, Sourav Poddar wrote:
> Hi Santosh,
> On Monday 25 March 2013 03:34 PM, Santosh Shilimkar wrote:
>> Kevin,
>>
>> Here is the refreshed version(v2) of the OMAP5 PM suspport which was posted
>> earlier (March 1st 2013). Patch-set incorporates comments from Nishant
>>
On Monday 25 March 2013 05:07 PM, Vaibhav Hiremath wrote:
> During common-clock migration, .clkdm_name field got missed
> for "clkdiv32k_ick" clock, which leaves "clk_24mhz_clkdm"
> unused; so boot process will try to disable the clockdomain
> even childs of this clock is enabled, which keeps child
Tero,
On Thursday 21 March 2013 11:05 PM, Tero Kristo wrote:
> Hi,
>
> This is an RFC version of the clock data move under drivers/clk.
> Tested under 3.8 and boots fine, but don't try this out unless
> you are experimental sort (I quickly tried with 3.9-rc3 and it failed to
> boot with that.)
>
On Thursday 21 March 2013 07:24 PM, Roger Quadros wrote:
> On 03/21/2013 03:08 PM, Rajendra Nayak wrote:
>> []..
>>
>>> diff --git a/arch/arm/mach-omap2/board-generic.c
>>> b/arch/arm/mach-omap2/board-generic.c
>>> index 0274ff7..23f2064 100644
>
[]..
> diff --git a/arch/arm/mach-omap2/board-generic.c
> b/arch/arm/mach-omap2/board-generic.c
> index 0274ff7..23f2064 100644
> --- a/arch/arm/mach-omap2/board-generic.c
> +++ b/arch/arm/mach-omap2/board-generic.c
> @@ -158,7 +158,7 @@ DT_MACHINE_START(OMAP4_DT, "Generic OMAP4 (Flattened
> Dev
atic macros defined in
clk-private.h.
The issue with kernel panic while CONFIG_DEBUG_SLAB is enabled
was reported by Piotr Haber and Tony Lindgren and this patch
fixes the reported issue as well.
Reported-by: Piotr Haber
Reported-by: Tony Lindgren
Signed-off-by: Rajendra Nayak
---
applies on 3.
Lindgren and this patch
fixes the reported issue as well.
Reported-by: Piotr Haber
Reported-by: Tony Lindgren
Signed-off-by: Rajendra Nayak
---
applies on 3.9-rc3 and tested on omap4 pandaES, omap3 beagle XM,
and am335x bone.
arch/arm/mach-omap2/common.h |3 +++
arch/arm/mach-omap2/io.c
On Tuesday 19 March 2013 06:53 AM, Mike Turquette wrote:
> Quoting Tony Lindgren (2013-03-18 09:37:58)
>> * Rajendra Nayak [130318 01:25]:
>>> On Friday 15 March 2013 09:50 PM, Tony Lindgren wrote:
>>>> * Rajendra Nayak [130315 05:31]:
>>>>> On T
On Friday 15 March 2013 09:50 PM, Tony Lindgren wrote:
> * Rajendra Nayak [130315 05:31]:
>> On Thursday 14 March 2013 10:36 PM, Tony Lindgren wrote:
>>> * Rajendra Nayak [130314 05:44]:
>>>> OMAP clock inits happen quite early, even before the slab is available.
On Thursday 14 March 2013 10:36 PM, Tony Lindgren wrote:
> * Rajendra Nayak [130314 05:44]:
>> OMAP clock inits happen quite early, even before the slab is available.
>> As part of the clock init, the common clock core tries to cache parent
>> pointers (if not passed by the c
Missed out Mike, copied now.
On Thursday 14 March 2013 06:06 PM, Rajendra Nayak wrote:
> These patches mainly fix the crash that was reported with
> CONFIG_DEBUG_SLAB enabled on OMAPs, due to the early clock
> initializations.
>
> Tested on Panda ES (omap4460), beagle Xm
arent pointers to the common clock core
while registering clocks.
Reported-by: Piotr Haber
Reported-by: Tony Lindgren
Signed-off-by: Rajendra Nayak
---
arch/arm/mach-omap2/cclock2420_data.c | 56 +++-
arch/arm/mach-omap2/cclock2430_data.c | 56 +++-
arch/arm/mach-omap2/cclock33xx_d
These patches mainly fix the crash that was reported with
CONFIG_DEBUG_SLAB enabled on OMAPs, due to the early clock
initializations.
Tested on Panda ES (omap4460), beagle Xm (omap3630) and
BeagleBoneBlack (AM335x)
Rajendra Nayak (2):
ARM: OMAP2+: clocks: Have consistent naming for parent name
On Thursday 07 March 2013 02:03 AM, Tony Lindgren wrote:
> So basically what's going is that __clk_init() calls kzalloc() before
> kmem_cache_init() is done. This happens the first time for sys_clkin_ck
> where we do have clk->num_parents.
>
> With CONFIG_DEBUG_SLAB we actually get an error in __f
The .init_late callback for OMAP3 has been missing for DT
builds, which causes a lot of late PM initializations to
be missed in turn.
Signed-off-by: Rajendra Nayak
---
arch/arm/mach-omap2/board-generic.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/mach-omap2/board
[]...
diff --git a/Documentation/devicetree/bindings/usb/omap-usb.txt
b/Documentation/devicetree/bindings/usb/omap-usb.txt
index 29a043e..4688265 100644
--- a/Documentation/devicetree/bindings/usb/omap-usb.txt
+++ b/Documentation/devicetree/bindings/usb/omap-usb.txt
@@ -15,6 +15,7 @@ OMAP MUSB
On Tuesday 05 February 2013 08:22 PM, Roger Quadros wrote:
Doesn't look very elegant to me, but I wouldn't mind if there is no better
option.
Even then, we can't rely on the device name as its index can change based on
where it is
Well, thats what I said in the first mail, that *if* you are a
On Tuesday 05 February 2013 07:59 PM, Roger Quadros wrote:
On 02/05/2013 04:21 PM, Rajendra Nayak wrote:
On Tuesday 05 February 2013 07:48 PM, Roger Quadros wrote:
On 02/05/2013 04:13 PM, Rajendra Nayak wrote:
On Tuesday 05 February 2013 07:16 PM, Roger Quadros wrote:
Fixing the device name
On Tuesday 05 February 2013 07:48 PM, Roger Quadros wrote:
On 02/05/2013 04:13 PM, Rajendra Nayak wrote:
On Tuesday 05 February 2013 07:16 PM, Roger Quadros wrote:
Fixing the device name doesn't really solve the problem.
Not all OMAP boards will use the same clock for the external d
On Tuesday 05 February 2013 07:16 PM, Roger Quadros wrote:
Fixing the device name doesn't really solve the problem.
Not all OMAP boards will use the same clock for the external device.
Are you saying different OMAP boards will use different Internal clocks?
Or different OMAP boards will use a s
On Monday 04 February 2013 09:28 PM, Roger Quadros wrote:
This patchset adds device tree support for OMAP's High Speed USB Host
subsystem. Board adaptation for Panda and Beagleboard is also provided.
Tested on Beagleboard.
Will only work with Panda if we provide a reference to the PHY clock
B
On Tuesday 05 February 2013 03:04 PM, Roger Quadros wrote:
Hi Rajendra,
On 02/04/2013 05:58 PM, Roger Quadros wrote:
Provide the RESET and Power regulators for the USB PHY,
the USB Host port mode and the PHY device.
Also provide pin multiplexer information for the USB host
pins.
Signed-off-by
them about the bootloader being a possible
cause.
Signed-off-by: Rajendra Nayak
Cc: Tero Kristo
Cc: Santosh Shilimkar
Cc: R Sricharan
---
arch/arm/mach-omap2/pm44xx.c | 18 +-
1 file changed, 17 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/pm44xx.c b/arch/arm
On Wednesday 30 January 2013 11:07 PM, Jon Hunter wrote:
On 01/18/2013 09:27 AM, Santosh Shilimkar wrote:
From: Rajendra Nayak
Add the clock tree related data for OMAP54xx platforms.
[snip]
+ CLK("omap_timer.1", "32k_ck", &sys_32k_ck,
Hi Paul,
dpll_usb needs the clkdm association so the clkdm can be
turned on before a relock. All other dplls for omap4 belong
to the ALWON (always on) domain.
The association was present as part of the older data file
(clock44xx_data.c) but looks like was accidently dropped with
the common clk
.
Signed-off-by: Rajendra Nayak
---
arch/arm/mach-omap2/cclock44xx_data.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/cclock44xx_data.c
b/arch/arm/mach-omap2/cclock44xx_data.c
index a2cc046..e71a19c 100644
--- a/arch/arm/mach-omap2
Tero,
On Thursday 31 January 2013 02:30 PM, Tero Kristo wrote:
Personally I don't like too much to have just extra spam during boot,
which in many cases is even unnecessary (e.g. people who actually have
good u-boot in use.) Personally I would like to have some sort of test
during boot which det
.
More details of the patch which fixed this up in the older
data file can be dound here..
http://www.spinics.net/lists/linux-omap/msg63076.html
Signed-off-by: Rajendra Nayak
---
arch/arm/mach-omap2/cclock44xx_data.c |1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-omap2
On Wednesday 23 January 2013 12:09 AM, Tony Lindgren wrote:
It seems that we should have the iospace available in the driver
at that point. And it should be also available to the runtime PM
code in hwmod in the device somewhere?
I couldn't find anything as part of the device. Definitely not the
Hi Tony,
So I looked at this one with help of Rajendra. We can get rid of the
IRQ and DMA data(needs DMA biding updates) easily. The address
space though is needed since hwmod code uses it to setup the
sysconfig registers.
OK great. The address space tinkering in hwmod code should be
moved to
On Tuesday 22 January 2013 01:52 PM, Linus Walleij wrote:
In the Nomadik I had a similar situation with a GPIO used for the
ethernet IRQ. I put the GPIO number in a special board-specific
node and added this to the machine,
Thanks Linus. Are there any bindings already available on how these
spe
On Monday 10 December 2012 03:50 PM, Roger Quadros wrote:
clk_set_parent is expected to fail on OMAP3 platforms. We don't
consider that as fatal so don't spam console.
And what if it fails on a non-OMAP3 platform?
Signed-off-by: Roger Quadros
---
drivers/mfd/omap-usb-host.c | 18 +++
On Thursday 08 November 2012 06:42 AM, Mike Turquette wrote:
I also tested on OMAP4460 Panda-ES. Boot is fine and PRCM programming
appears sane. However Panda-ES never comes back from suspend/resume.
This problem exists on the PRM/CM branch I based on and was not
introduced by this series. I a
centralize low-level CM and PRM register accesses
into the cm*.[ch] and prm*.[ch] files, and then to export an OMAP
SoC-independent API to higher-level OMAP power management code.
Signed-off-by: Paul Walmsley
Cc: Rajendra Nayak
Acked-by: Rajendra Nayak
Cc: Vaibhav Hiremath
---
arch/arm/mach
low-level PRM register accesses into
the prm*.[ch] files, and then to export an OMAP SoC-independent API to
higher-level OMAP power management code.
Signed-off-by: Paul Walmsley
Cc: Rajendra Nayak
Acked-by: Rajendra Nayak
Cc: Vaibhav Hiremath
---
arch/arm/mach-omap2/Makefile
On Thursday 18 October 2012 02:07 AM, Jon Hunter wrote:
Ok, thanks. Yes, only updating the register when the cache value changed
would not work due to the possibility of context being lost. So
Rajendra's change makes sense. However, I think there is room to
optimise this.
With this change, on id
If the clkdm is in HW_AUTO, I can get DSS in sleep(STBYST and IDLEST all
set). Is this helpful? Can we just leave modulemode on all the time?
That'll be the best :)
Is everything around DSS enabled by default in omap2plus? If so, I
haven't seen Tero (who has been working on getting OMAP4 to slee
On Friday 05 October 2012 05:59 PM, Archit Taneja wrote:
The other not so good option to make DSS PM work would be to add
OCPIF_SWSUP_IDLE flag to our l3_main_2__dss_* slave interfaces(which
have the hack "dss_fck" as slave clock). I gave this approach a try,
that too isn't working so well. When
On Tuesday 25 September 2012 07:47 PM, Tero Kristo wrote:
Actually I think I accidentally fixed this problem with the latest rev,
due to the fact that I am using generic clkdm_clk_enable / disable calls
from iclk now.
I also just tested this (while fixing the complaint from Russell), and
it look
On Tuesday 25 September 2012 05:23 PM, Tero Kristo wrote:
On Tue, 2012-09-25 at 15:56 +0530, Rajendra Nayak wrote:
Hi Tero,
On Tuesday 25 September 2012 03:02 PM, Tero Kristo wrote:
Hi,
Changes compared to previous version:
Did you get a chance to look at the issue I reported about
Hi Tero,
On Tuesday 25 September 2012 03:02 PM, Tero Kristo wrote:
Hi,
Changes compared to previous version:
Did you get a chance to look at the issue I reported about autodeps?
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg72876.html
regards,
Rajendra
- Fixed OMAP4 support (p
On Sunday 23 September 2012 12:25 AM, Paul Walmsley wrote:
Updated this one to include several missing clock aliases and to fix a bug
it introduced with omap_96m_alwon_fck_3630; modified patch below.
Thanks Paul, for the updates and the fix. Updated patch looks good to
me.
regards,
Rajendra
--
On Thursday 30 August 2012 05:45 AM, Turquette, Mike wrote:
On Wed, Aug 29, 2012 at 1:56 AM, Rajendra Nayak wrote:
diff --git a/arch/arm/mach-omap2/clock44xx_data.c
b/arch/arm/mach-omap2/clock44xx_data.c
index d7f55e4..a3831a2 100644
--- a/arch/arm/mach-omap2/clock44xx_data.c
+++ b/arch/arm
On Thursday 30 August 2012 05:38 AM, Russell King - ARM Linux wrote:
On Wed, Aug 29, 2012 at 02:26:15PM +0530, Rajendra Nayak wrote:
Moving to Common clk framework for OMAP would mean we no longer use
internal lookup mechanism like omap_clk_get_by_name().
get rid of all its usage mostly from
cross multiple lines
which seem to be needed anyway.
Signed-off-by: Rajendra Nayak
[p...@pwsan.com: simplified some compound expressions; reformatted some
messages]
Signed-off-by: Paul Walmsley
Cc: Mike Turquette
---
arch/arm/mach-omap2/clkt2xxx_apll.c |2 +-
arch/arm/mach-
something meaningful with
clk_prepare/clk_unprepare like doing voltage scaling or something
that involves i2c.
This is in preparation of OMAP moving to CCF.
Based on initial changes from Mike turquette.
Signed-off-by: Rajendra Nayak
---
arch/arm/mach-omap2/board-apollon.c|4 ++--
arch/arm/
the clkdev tables updated with an entry for all clocks
used by hwmod to have clock name same as the alias.
Based on original changes from Mike Turquette.
Signed-off-by: Rajendra Nayak
---
arch/arm/mach-omap2/clock2420_data.c | 17 +
arch/arm/mach-omap2/clock2430_data.c | 21
.
Patches are boot tested on OMAP2430sdp, 3630 Beagle-Xm
and 4430/4460 Panda and suspend tested on 3630 Beagle-Xm
and 4430 Panda. Patches apply on 3.6-rc3.
Rajendra Nayak (3):
ARM: omap: clk: add clk_prepare and clk_unprepare
ARM: omap: hwmod: get rid of all omap_clk_get_by_name usage
ARM: OMA
Hi Tony,
* Rajendra Nayak [120730 06:17]:
regulators do not have a 'reg' property, hence the regulator@0,
regulator@1 do not make sense. get rid of it.
Looks like this needs to be refreshed to apply. Care to
refresh against current devel-dt branch in case other
places need the s
. This patch changes the fixed one to be VINTANA1.
Thanks for the fix, the commit does seem to have mixed up things.
Acked-by: Rajendra Nayak
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo inf
should be populated seperately. As long as that
> happens, let the OPP table registeration happen only on 4430 device.
>
> Signed-off-by: Rajendra Nayak
Thanks, adding to PM fixes for v3.6-rc (branch: for_3.6/fixes/pm)
I just posted a v2 of this series addressing the issues raised by
happen only on 4430 device.
Signed-off-by: Rajendra Nayak
---
arch/arm/mach-omap2/opp4xxx_data.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/opp4xxx_data.c
b/arch/arm/mach-omap2/opp4xxx_data.c
index 2293ba2..c95415d 100644
--- a/arch/arm/mach-omap2
the freq_table_users only if the table is sucessfully
created.
Signed-off-by: Rajendra Nayak
Signed-off-by: Santosh Shilimkar
Cc:
---
drivers/cpufreq/omap-cpufreq.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/cpufreq/omap-cpufreq.c b/drivers/cpufreq/omap
s like 4460 and 4470 (and hence causing random issues)
and also fixes a subsequent bug uncovered by doing this in
OMAP cpufreq driver.
regards,
Rajendra
Rajendra Nayak (2):
cpufreq: OMAP: Handle missing frequency table on SMP systems
ARM: OMAP4: Register the OPP table only for 4430 device
happen only on 4430 device.
Signed-off-by: Rajendra Nayak
---
arch/arm/mach-omap2/opp4xxx_data.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/opp4xxx_data.c
b/arch/arm/mach-omap2/opp4xxx_data.c
index 2293ba2..c95415d 100644
--- a/arch/arm/mach-omap2
.
Signed-off-by: Rajendra Nayak
Cc:
---
drivers/cpufreq/omap-cpufreq.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/cpufreq/omap-cpufreq.c b/drivers/cpufreq/omap-cpufreq.c
index 17fa04d..0ee824c 100644
--- a/drivers/cpufreq/omap-cpufreq.c
+++ b/drivers/cpufreq/omap
OMAP cpufreq driver.
regards,
Rajendra
Rajendra Nayak (2):
cpufreq: OMAP: Handle missing frequency table on SMP systems
ARM: OMAP4: Register the OPP table only for 4430 device
arch/arm/mach-omap2/opp4xxx_data.c |2 +-
drivers/cpufreq/omap-cpufreq.c |2 +-
2 files changed, 2 insert
On Tuesday 31 July 2012 12:26 AM, Paul Walmsley wrote:
On Mon, 30 Jul 2012, Rajendra Nayak wrote:
Are you sure you are using the v3 of this patch? You already mentioned
about these in the v2 [1] and I fixed all these in v3. I went back and
looked at the v3 of this patch, and it does not
Hi Jon,
On Tuesday 31 July 2012 10:11 AM, Jon Hunter wrote:
Hi Paul, Rajendra,
On 07/27/2012 12:43 AM, Rajendra Nayak wrote:
On Friday 27 July 2012 02:34 AM, Paul Walmsley wrote:
Commit 4da71ae6 ("OMAP: clockdomain: Arch specific funcs for
clkdm_clk_enable/disable") called th
shon Vijay Abraham I
Reported-by: J Keerthy
Signed-off-by: Rajendra nayak
---
arch/arm/boot/dts/twl6030.dtsi |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/twl6030.dtsi b/arch/arm/boot/dts/twl6030.dtsi
index 3b2f351..d351b27 100644
--- a/arch/ar
regulators do not have a 'reg' property, hence the regulator@0,
regulator@1 do not make sense. get rid of it.
Reported-by: David Brown
Signed-off-by: Rajendra Nayak
---
arch/arm/boot/dts/omap3-beagle.dts |2 +-
arch/arm/boot/dts/omap4-sdp.dts|4 ++--
arch/arm/boot/dts/tw
Hi Tony,
These are couple of DT fixes for OMAP, first fixes a lockup
/boot failure on OMAP4 boards (SDP and panda) on mainline,
second is a long pending cleanup.
regards,
Rajendra
Rajendra Nayak (2):
arm/dts: Mark vcxio, v2v1 and v1v8 regulators as always on
arm/dts: Cleanup regulator
Hi Paul,
On Monday 30 July 2012 12:42 PM, Paul Walmsley wrote:
Hi Rajendra
On Mon, 2 Jul 2012, Rajendra Nayak wrote:
While we move to Common Clk Framework (CCF), direct deferencing of
struct clk wouldn't be possible anymore. Hence get rid of all such
instances in the current clock cod
On Monday 30 July 2012 11:54 AM, NeilBrown wrote:
On Mon, 30 Jul 2012 10:50:36 +0530 Rajendra Nayak wrote:
On Monday 30 July 2012 05:42 AM, NeilBrown wrote:
1/ if regulator_get fails, return an error. This is important
if it failed with EPROBE_DEFER, as the probe needs to be
On Monday 30 July 2012 05:42 AM, NeilBrown wrote:
1/ if regulator_get fails, return an error. This is important
if it failed with EPROBE_DEFER, as the probe needs to be
deferred.
2/ Don't set .set_power until the regulator has been found, or
the deferred probe will not bother calli
Hi Tero,
On Friday 27 July 2012 12:16 PM, Rajendra Nayak wrote:
However a quick test with just your latest usecounting series (without
any of my RFC patches) seems to make me think I am still missing
something.
If you see the counts below for usbhost and dss, they both seem to
go in and out of
Hi Tero,
On Thursday 26 July 2012 11:57 PM, Tero Kristo wrote:
Yeah, this is definitely a problem.
>
> As long as we have autodeps, everything is centralized around CPU
> transitions anyways, so it makes sense to keep the accounting
> centralized too.
>
> > I think as long as we have autod
wakeup and sleep on OMAP3.
Its strange this went unnoticed for so long. Thanks for this fix and
sorry about introducing the bug in the first place.
Acked-by: Rajendra Nayak
Signed-off-by: Paul Walmsley
Cc: Rajendra Nayak
Cc: Jon Hunter
---
arch/arm/mach-omap2/clockdomain2xxx_3xx
On Thursday 26 July 2012 04:13 AM, Kevin Hilman wrote:
Tero Kristo writes:
On Fri, 2012-07-20 at 13:38 +0530, Rajendra Nayak wrote:
On Friday 20 July 2012 12:55 PM, Shilimkar, Santosh wrote:
On Fri, Jul 20, 2012 at 11:34 AM, Rajendra Nayak wrote:
pwrdm_pre_transition
On Thursday 26 July 2012 04:13 AM, Kevin Hilman wrote:
Tero Kristo writes:
> On Fri, 2012-07-20 at 13:38 +0530, Rajendra Nayak wrote:
>> On Friday 20 July 2012 12:55 PM, Shilimkar, Santosh wrote:
>> > On Fri, Jul 20, 2012 at 11:34 AM, Raje
Hi Paul,
On Friday 20 July 2012 11:55 PM, Paul Walmsley wrote:
On Fri, 20 Jul 2012, Rajendra Nayak wrote:
We do not support MPU OSWR on OMAP3. Get rid of the complex/multiple
save_state handling in omap_sram_idle() and just use 2 save_state
definitions
save_state = 1, all logic and memory
On Friday 20 July 2012 02:29 PM, Tero Kristo wrote:
On Fri, 2012-07-20 at 11:34 +0530, Rajendra Nayak wrote:
Hi,
Here are some CPUidle/Suspend cleanup patches done by adding
some more functionality in the OMAP Powerdomain framework.
They mostly cleanup OMAP3 but the same ideas can be used
On Friday 20 July 2012 12:55 PM, Shilimkar, Santosh wrote:
On Fri, Jul 20, 2012 at 11:34 AM, Rajendra Nayak wrote:
pwrdm_pre_transition()/pwrdm_post_transition() have always been high latency
operations done within cpuidle to do Powerdomain level book-keeping to know
what state transitions for
OMAP Powerdomain framework.
The patches are tested with RET/OFF in CPUidle and Suspend
on 3630 beagle Xm and 3430 SDP.
regards,
Rajendra
[1] http://www.mail-archive.com/linux-omap@vger.kernel.org/msg72163.html
Rajendra Nayak (4):
ARM: OMAP3: cpuidle: Remove unused MPU OSWR support code
ARM:
within
CPUidle and Suspend code.
Signed-off-by: Rajendra Nayak
---
arch/arm/mach-omap2/powerdomain.c | 12 +++-
arch/arm/mach-omap2/powerdomain.h |4
2 files changed, 15 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/powerdomain.c
b/arch/arm/mach-omap2
CPUidle when attempting deeper C states, to prevent a core
domain context save when a device in core is still active.
The current code in such cases does a blind context save and
tries to put core domain down, even while devices are active.
Signed-off-by: Rajendra Nayak
---
arch/arm/mach-omap2
() functions.
Also rename _pwrdm_pre/post_transition_cb() to pwrdm_pre/post_transition()
and get rid of the original ones which iterate over all powerdomains.
Signed-off-by: Rajendra Nayak
---
arch/arm/mach-omap2/omap-mpuss-lowpower.c |4 ++--
arch/arm/mach-omap2/pm34xx.c |4
We do not support MPU OSWR on OMAP3. Get rid of the complex/multiple
save_state handling in omap_sram_idle() and just use 2 save_state
definitions
save_state = 1, all logic and memory lost, MPU hits OFF
save_state = 0, nothing lost, MPU hits CSWR or shallower state
Signed-off-by: Rajendra Nayak
On Friday 20 July 2012 10:31 AM, Bedia, Vaibhav wrote:
On Fri, Jul 20, 2012 at 10:09:43, Nayak, Rajendra wrote:
On Thursday 19 July 2012 05:38 PM, Vaibhav Bedia wrote:
As per the comment in omap2_common_late_init() looks like the
original intent of the DT check was to treat only the PMIC
and SR
On Thursday 19 July 2012 05:38 PM, Vaibhav Bedia wrote:
As per the comment in omap2_common_late_init() looks like the
original intent of the DT check was to treat only the PMIC
and SR initialization differently. Recent changes to consolidate
the suspend-resume code across OMAP3/4 resulted into th
On Wednesday 18 July 2012 01:35 PM, Tero Kristo wrote:
On Wed, 2012-07-18 at 12:45 +0530, Rajendra Nayak wrote:
On Tuesday 17 July 2012 08:26 PM, Tero Kristo wrote:
Anyway, it also looks like this fix is no longer needed with the latest
kernel, something has changed with the gpio code / or
On Tuesday 17 July 2012 08:26 PM, Tero Kristo wrote:
Anyway, it also looks like this fix is no longer needed with the latest
kernel, something has changed with the gpio code / or latencies and it
doesn't crash anymore. Thus, it looks like patches 7& 8 can be dropped
from this set for now. This i
On Tuesday 17 July 2012 07:16 PM, Rob Herring wrote:
So how is this expected to work on platforms (like OMAP) which have
> CONFIG_OF enabled but not CONFIG_COMMON_CLK?
>
As I mentioned in my other reply, this really belongs with Shawn's patch
that changes the return value checking from NULL to
On Tuesday 17 July 2012 06:49 PM, Rajendra Nayak wrote:
struct clk *clk_get(struct device *dev, const char *con_id)
{
const char *dev_id = dev ? dev_name(dev) : NULL;
struct clk *clk;
if (dev) {
>
Any reason why this isn't
if (dev->of_node) {
Rob, Mike,
On Tuesday 17 July 2012 07:38 AM, Rob Herring wrote:
On 07/16/2012 07:12 PM, Mike Turquette wrote:
On 20120716-16:46, Rob Herring wrote:
From: Rob Herring
With commit 766e6a4ec602d0c107 (clk: add DT clock binding support),
compiling with OF&& !COMMON_CLK is broken.
Hi Rob,
Tha
On Tuesday 17 July 2012 02:53 PM, Archit Taneja wrote:
Hi,
The linux-next tree gives this with omap2plus_defconfig:
...
...
LD init/built-in.o
drivers/built-in.o: In function `of_clk_get':
/home/a0393947/source_trees/linux-next/drivers/clk/clkdev.c:42:
undefined reference to `of_clk_get_from_pr
On Monday 16 July 2012 05:15 PM, Tero Kristo wrote:
> >
> > This patch also provices a way to do printk dumps from kernel code,
> > by calling the pm_dbg_dump_X functions. The plan is to call these
> > functions once an error condition is detected, e.g. failed suspend.
^
|
This part is th
Sorry, I seemed to have messed up with the underlining.
On Monday 16 July 2012 05:38 PM, Rajendra Nayak wrote:
[0.337341] V1V8: 1800 mV normal standby
[0.338531] V2V1: 2100 mV normal standby
[0.339813] VMMC: 1200 <--> 3000 mV at 3100 mV normal s
000 <--> 3000 mV at 1200 mV normal standby
Thanks for the patch.
Tested-by: Rajendra Nayak
---
drivers/regulator/twl-regulator.c | 31 ---
1 file changed, 24 insertions(+), 7 deletions(-)
diff --git a/drivers/regulator/twl-regulator.c
b/drivers/regulator/twl
On Friday 13 July 2012 10:07 PM, Tero Kristo wrote:
PM code doesn't really care about the PRCM wakeup + io interrupts on
OMAP3, as these are used only for acking PRCM internal events, and the
IO chain handler is taken care of by hwmod code. Thus move the interrupt
handling logic from pm34xx.c to
Hi Tero,
On Friday 13 July 2012 07:49 PM, Tero Kristo wrote:
Some clockdomains bug out if their autodeps are deleted before idle.
This happens namely with OMAP3 PER domain, it will bug out if it
doesn't have wakedeps enabled when it enters off-mode. This patch
adds support for new flag 'CLKDM_NO
On Friday 13 July 2012 07:49 PM, Tero Kristo wrote:
Voltdm, pwrdm, clkdm, hwmod and clk usecounts are now separeted to
their own file, 'usecount'. This file shows the usecounts for every
active domain and their children recursively. 'count' file now only
shows power state counts for powerdomains.
w the voltdm->sleep / wakeup calls to work properly.
Signed-off-by: Tero Kristo
Cc: Paul Walmsley
Cc: Kevin Hilman
Reviewed-by: Rajendra Nayak
---
arch/arm/mach-omap2/clock3xxx_data.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/clock3xxx_data.c
pwrdm_cpu_wakeup/idle seems somewhat misleading.
But I don't know either what would be a better name, so..
Reviewed-by: Rajendra Nayak
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordom
olling voltage scaling functionality.
Signed-off-by: Tero Kristo
Cc: Paul Walmsley
Cc: Kevin Hilman
Reviewed-by: Rajendra Nayak
I am working on a series to cleanup CPUidle, on top of this series,
where I add similar callbacks at the pwrdm level too. Something like
pwrdm->power_on and pwrdm-&g
support for usecount
tracking on powerdomain level and autoidle flag for clocks that
are hardware controlled and should be skipped in usecount
calculations.
Signed-off-by: Tero Kristo
Cc: Paul Walmsley
Cc: Kevin Hilman
Reviewed by: Rajendra Nayak
---
arch/arm/mach-omap2/clkt_iclk.c
On Friday 13 July 2012 07:49 PM, Tero Kristo wrote:
This works similarly to e.g. pwrdm_for_each(). Needed by enhanced
usecounting debug functionality that will be added to pm-debug.
OMAP clock framework has its own debugfs entry (/debug/clock) to expose
usecounts for clocks, so does the COMMON
Copying Graeme and linux-omap list.
On Saturday 14 July 2012 11:11 AM, Axel Lin wrote:
Signed-off-by: Axel Lin
---
drivers/regulator/twl-regulator.c | 24 +---
1 file changed, 13 insertions(+), 11 deletions(-)
diff --git a/drivers/regulator/twl-regulator.c
b/drivers/re
Copying Graeme and linux-omap list.
On Saturday 14 July 2012 11:07 AM, Axel Lin wrote:
The voltage selection logic is supposed to find the samllest voltage falls
within specified range. When using equation to calculate vsel, we need to
ensure the requested min_uV meet the range of using the equa
en can be applied
to current Linus' tree.
But while I am tracking back to commit 3e3d3be79c
Author: Rajendra Nayak
Date: Thu Apr 22 14:18:32 2010 +0530
twl6030: regulator: Remove vsel tables and use formula for
calculation
All twl6030 regulators can be programmed from 1.
301 - 400 of 1421 matches
Mail list logo
