Texas Instrument's Omap Processor's Linux development mailing list

Tero Kristo | 19 Jul 2012 15:26

[PATCHv7 00/12] ARM: OMAP4: core retention support

Hi,

Changes compared to previous version:

- ported on top of 3.5-rc7
- patch 3: added a few modules here not having context_offs
- patch 8: NEW:
  * ROM code on EMU / HS devices seem to wipe the contents of
    L4PER_PWRSTCTRL register, thus this patch adds an errata +
    save and restore for this register, this was noticed while
    testing cpu_idle on EMU device
- patch 9: NEW:
  * sl2if hwmod is still blocking core retention on omap4, this
    patch comments it out similarly to aess / usb_host_fs
- patch 10: NEW:
  * adds support for lostcontext_mask, this is needed by l4_abe / aess
    hwmods as they will share context register, but use different bits
    within it
- patch 11: NEW:
  * adds the hwmod data for sharing context register for l4_abe / aess
- patch 12: NEW:
  * context lost counter logic update for modules that don't have
    context register

Some of the NEW patches (10..12) are result of comments received on
l-o list, and can be merged with other patches in the set if they are seen
acceptable. Core retention works without these patches fine, but they
address some corner cases.

Tested with omap4460 GP panda + omap4430 EMU blaze, with both suspend +

(Continue reading)

headers

Tero Kristo | 19 Jul 2012 15:26

[PATCHv7 01/12] ARM: OMAP4: PM: add errata support

Added similar PM errata flag support as omap3 has. This should be used
in similar manner, set the flags during init time, and check the flag
values during runtime.

Signed-off-by: Tero Kristo <t-kristo <at> ti.com>
---
 arch/arm/mach-omap2/pm.h     |    7 +++++++
 arch/arm/mach-omap2/pm44xx.c |    1 +
 2 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
index 7856489..46ab9d9 100644
--- a/arch/arm/mach-omap2/pm.h
+++ b/arch/arm/mach-omap2/pm.h
 <at>  <at>  -88,6 +88,13  <at>  <at>  extern void enable_omap3630_toggle_l2_on_restore(void);
 static inline void enable_omap3630_toggle_l2_on_restore(void) { }
 #endif		/* defined(CONFIG_PM) && defined(CONFIG_ARCH_OMAP3) */

+#if defined(CONFIG_ARCH_OMAP4)
+extern u16 pm44xx_errata;
+#define IS_PM44XX_ERRATUM(id)		(pm44xx_errata & (id))
+#else
+#define IS_PM44XX_ERRATUM(id)		0
+#endif
+
 #ifdef CONFIG_OMAP_SMARTREFLEX
 extern int omap_devinit_smartreflex(void);
 extern void omap_enable_smartreflex_on_init(void);
diff --git a/arch/arm/mach-omap2/pm44xx.c b/arch/arm/mach-omap2/pm44xx.c
index c234733..3a484b1 100644

(Continue reading)

headers

Tero Kristo | 19 Jul 2012 15:26

[PATCHv7 03/12] ARM: OMAP4: hwmod: flag hwmods/modules not supporting module level context status

On OMAP4 most modules/hwmods support module level context status. On
OMAP3 and earlier, we relied on the power domain level context status.
Identify all modules that don't support 'context_offs' by marking the
offset as USHRT_MAX. Rest have a valid 'context_offs' populated in
.prcm structure already.

Signed-off-by: Tero Kristo <t-kristo <at> ti.com>
---
 arch/arm/mach-omap2/omap_hwmod_44xx_data.c |   46 ++++++++++++++++++++++++++++
 1 files changed, 46 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index b7bcba5..ad7df4e 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
 <at>  <at>  -204,6 +204,7  <at>  <at>  static struct omap_hwmod omap44xx_l4_abe_hwmod = {
 	.prcm = {
 		.omap4 = {
 			.clkctrl_offs = OMAP4_CM1_ABE_L4ABE_CLKCTRL_OFFSET,
+			.context_offs = USHRT_MAX,
 		},
 	},
 };
 <at>  <at>  -260,6 +261,11  <at>  <at>  static struct omap_hwmod omap44xx_mpu_private_hwmod = {
 	.name		= "mpu_private",
 	.class		= &omap44xx_mpu_bus_hwmod_class,
 	.clkdm_name	= "mpuss_clkdm",
+	.prcm = {
+		.omap4 = {
+			.context_offs = USHRT_MAX,

(Continue reading)

headers

Paul Walmsley | 12 Sep 2012 21:46

Re: [PATCHv7 03/12] ARM: OMAP4: hwmod: flag hwmods/modules not supporting module level context status

Hi Tero,

On Thu, 19 Jul 2012, Tero Kristo wrote:

> On OMAP4 most modules/hwmods support module level context status. On
> OMAP3 and earlier, we relied on the power domain level context status.
> Identify all modules that don't support 'context_offs' by marking the
> offset as USHRT_MAX. Rest have a valid 'context_offs' populated in
> .prcm structure already.
> 
> Signed-off-by: Tero Kristo <t-kristo <at> ti.com>

This one was changed here to use a separate flag rather than adding a 
magic value to the context_offs field -- mostly because I've been burnt by 
missing tests for those kinds of magic values in the past.  It should be 
possible to roll the .modulemode field into this .flags field in a future 
patch to eliminate any kernel object size changes.  

The modified patch is below, queued for 3.7.

- Paul

From: Tero Kristo <t-kristo <at> ti.com>
Date: Wed, 12 Sep 2012 11:53:54 -0600
Subject: [PATCH] ARM: OMAP4: hwmod: flag hwmods/modules not supporting module
 level context status

On OMAP4 most modules/hwmods support module level context status. On
OMAP3 and earlier, we relied on the power domain level context status.
Identify all modules that don't support 'context_offs' by adding a

(Continue reading)

headers

Tero Kristo | 19 Jul 2012 15:26

[PATCHv7 02/12] ARM: OMAP4460: Workaround for ROM bug because of CA9 r2pX GIC control register change.

From: Santosh Shilimkar <santosh.shilimkar <at> ti.com>

On OMAP4+ devices, GIC register context is lost when MPUSS hits
the OSWR(Open Switch Retention). On the CPU wakeup path, ROM code
gets executed and one of the steps in it is to restore the
saved context of the GIC. The ROM Code GIC distributor restoration
is split in two parts: CPU specific register done by each CPU and
common register done by only one CPU.

Below is the abstract flow.

...............................................................
- MPUSS in OSWR state.
- CPU0 wakes up on the event(interrupt) and start executing ROM code.

[..]

- CPU0 executes "GIC Restoration:"

[...]

- CPU0 swicthes to non-secure mode and jumps to OS resume code.

[...]

- CPU0 is online in OS
- CPU0 enables the GIC distributor. GICD.Enable Non-secure = 1
- CPU0 wakes up CPU1 with clock-domain force wakeup method.
- CPU0 continues it's execution.
[..]

(Continue reading)

headers

Tero Kristo | 19 Jul 2012 15:26

[PATCHv7 06/12] ARM: OMAP4: suspend: Program all domains to retention

From: Rajendra Nayak <rnayak <at> ti.com>

Remove the FIXME's in the suspend sequence since
we now intend to support system level RET support.

Signed-off-by: Rajendra Nayak <rnayak <at> ti.com>
Signed-off-by: Tero Kristo <t-kristo <at> ti.com>
[Jean Pihet <j-pihet <at> ti.com>: ported on top of the functional power
states]
Reviewed-by: Santosh Shilimkar <santosh.shilimkar <at> ti.com>
---
 arch/arm/mach-omap2/pm44xx.c |   10 +++-------
 1 files changed, 3 insertions(+), 7 deletions(-)

diff --git a/arch/arm/mach-omap2/pm44xx.c b/arch/arm/mach-omap2/pm44xx.c
index 3a484b1..1e845e8 100644
--- a/arch/arm/mach-omap2/pm44xx.c
+++ b/arch/arm/mach-omap2/pm44xx.c
 <at>  <at>  -97,19 +97,15  <at>  <at>  static int __init pwrdms_setup(struct powerdomain *pwrdm, void *unused)
 	if (!strncmp(pwrdm->name, "cpu", 3))
 		return 0;

-	/*
-	 * FIXME: Remove this check when core retention is supported
-	 * Only MPUSS power domain is added in the list.
-	 */
-	if (strcmp(pwrdm->name, "mpu_pwrdm"))
-		return 0;

 	pwrst = kmalloc(sizeof(struct power_state), GFP_ATOMIC);

(Continue reading)

headers

Sergei Shtylyov | 19 Jul 2012 16:16

Re: [PATCHv7 06/12] ARM: OMAP4: suspend: Program all domains to retention

Hello.

On 07/19/2012 05:26 PM, Tero Kristo wrote:

> From: Rajendra Nayak <rnayak <at> ti.com>

> Remove the FIXME's in the suspend sequence since
> we now intend to support system level RET support.

> Signed-off-by: Rajendra Nayak <rnayak <at> ti.com>
> Signed-off-by: Tero Kristo <t-kristo <at> ti.com>
> [Jean Pihet <j-pihet <at> ti.com>: ported on top of the functional power
> states]

  Shouldn't Jean also have signed off?

> Reviewed-by: Santosh Shilimkar <santosh.shilimkar <at> ti.com>

WBR, Sergei
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

headers

Jean Pihet | 6 Aug 2012 15:29

Re: [PATCHv7 06/12] ARM: OMAP4: suspend: Program all domains to retention

Hi!

On Thu, Jul 19, 2012 at 4:16 PM, Sergei Shtylyov <sshtylyov <at> mvista.com> wrote:
> Hello.
>
> On 07/19/2012 05:26 PM, Tero Kristo wrote:
>
>> From: Rajendra Nayak <rnayak <at> ti.com>
>
>> Remove the FIXME's in the suspend sequence since
>> we now intend to support system level RET support.
>
>> Signed-off-by: Rajendra Nayak <rnayak <at> ti.com>
>> Signed-off-by: Tero Kristo <t-kristo <at> ti.com>
>> [Jean Pihet <j-pihet <at> ti.com>: ported on top of the functional power
>> states]
>
>   Shouldn't Jean also have signed off?
Sure! I am OK with this change, feel free to add:
Acked-by: Jean Pihet <j-pihet <at> ti.com>

Regards,
Jean

>
>> Reviewed-by: Santosh Shilimkar <santosh.shilimkar <at> ti.com>
>
> WBR, Sergei
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in

(Continue reading)

headers

Kevin Hilman | 12 Sep 2012 23:36

Re: [PATCHv7 06/12] ARM: OMAP4: suspend: Program all domains to retention

Tero Kristo <t-kristo <at> ti.com> writes:

> From: Rajendra Nayak <rnayak <at> ti.com>
>
> Remove the FIXME's in the suspend sequence since
> we now intend to support system level RET support.
>
> Signed-off-by: Rajendra Nayak <rnayak <at> ti.com>
> Signed-off-by: Tero Kristo <t-kristo <at> ti.com>
> [Jean Pihet <j-pihet <at> ti.com>: ported on top of the functional power
> states]
> Reviewed-by: Santosh Shilimkar <santosh.shilimkar <at> ti.com>

Acked-by: Kevin Hilman <khilman <at> ti.com>

Paul, go ahead and queue this one with the others.

Kevin
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

headers

Tero Kristo | 19 Jul 2012 15:26

[PATCHv7 04/12] ARM: OMAP: hwmod: Add support for per hwmod/module context lost count

From: Rajendra Nayak <rnayak <at> ti.com>

OMAP4 has module specific context lost registers which makes it now
possible to have module level context loss count, instead of relying
on the powerdomain level context count.

Add 2 private hwmod api's to update/clear the hwmod/module specific
context lost counters/register.

Update the module specific context_lost_counter and clear the hardware
bits just after enabling the module.

omap_hwmod_get_context_loss_count() now returns the hwmod context loss
count them on platforms where they exist (OMAP4), else fall back on
the pwrdm level counters for older platforms.

Signed-off-by: Rajendra Nayak <rnayak <at> ti.com>
[paul <at> pwsan.com: added function kerneldoc, fixed structure kerneldoc,
 rearranged structure to avoid memory waste, marked fns as OMAP4-specific,
 prevent fn entry on non-OMAP4 chips, reduced indentation, merged update
 and clear, merged patches]
Signed-off-by: Paul Walmsley <paul <at> pwsan.com>
[t-kristo <at> ti.com: added support for arch specific hwmod ops, and changed
 the no context offset indicator to USHRT_MAX]
Signed-off-by: Tero Kristo <t-kristo <at> ti.com>
---
 arch/arm/mach-omap2/omap_hwmod.c             |   71 ++++++++++++++++++++++++--
 arch/arm/plat-omap/include/plat/omap_hwmod.h |    8 ++-
 2 files changed, 73 insertions(+), 6 deletions(-)

(Continue reading)

headers

Paul Walmsley | 12 Sep 2012 21:48

Re: [PATCHv7 04/12] ARM: OMAP: hwmod: Add support for per hwmod/module context lost count

On Thu, 19 Jul 2012, Tero Kristo wrote:

> From: Rajendra Nayak <rnayak <at> ti.com>
> 
> OMAP4 has module specific context lost registers which makes it now
> possible to have module level context loss count, instead of relying
> on the powerdomain level context count.
> 
> Add 2 private hwmod api's to update/clear the hwmod/module specific
> context lost counters/register.
> 
> Update the module specific context_lost_counter and clear the hardware
> bits just after enabling the module.
> 
> omap_hwmod_get_context_loss_count() now returns the hwmod context loss
> count them on platforms where they exist (OMAP4), else fall back on
> the pwrdm level counters for older platforms.
> 
> Signed-off-by: Rajendra Nayak <rnayak <at> ti.com>
> [paul <at> pwsan.com: added function kerneldoc, fixed structure kerneldoc,
>  rearranged structure to avoid memory waste, marked fns as OMAP4-specific,
>  prevent fn entry on non-OMAP4 chips, reduced indentation, merged update
>  and clear, merged patches]
> Signed-off-by: Paul Walmsley <paul <at> pwsan.com>
> [t-kristo <at> ti.com: added support for arch specific hwmod ops, and changed
>  the no context offset indicator to USHRT_MAX]
> Signed-off-by: Tero Kristo <t-kristo <at> ti.com>

This one has been modified to align with the changes on patch 3, and 
queued for 3.7.

(Continue reading)

headers

Paul Walmsley | 12 Sep 2012 23:29

Re: [PATCHv7 04/12] ARM: OMAP: hwmod: Add support for per hwmod/module context lost count

Hi

Well, anyway.  This patch had some other issues that were found upon a 
closer inspection:

- it adds a new 'hwmod_ops' set of function pointers rather than using the 
existing 'soc_ops' mechanism

- it returns an unsigned int as a signed integer -- not sure why static 
analysis didn't catch this one 

Here's the updated patch.

- Paul

From: Rajendra Nayak <rnayak <at> ti.com>
Date: Wed, 12 Sep 2012 11:55:55 -0600
Subject: [PATCH] ARM: OMAP: hwmod: Add support for per hwmod/module context
 lost count

OMAP4 has module specific context lost registers which makes it now
possible to have module level context loss count, instead of relying
on the powerdomain level context count.

Add 2 private hwmod api's to update/clear the hwmod/module specific
context lost counters/register.

Update the module specific context_lost_counter and clear the hardware
bits just after enabling the module.

(Continue reading)

headers

Paul Walmsley | 21 Sep 2012 02:38

Re: [PATCHv7 04/12] ARM: OMAP: hwmod: Add support for per hwmod/module context lost count

Hi 

On Wed, 12 Sep 2012, Paul Walmsley wrote:

> On Thu, 19 Jul 2012, Tero Kristo wrote:
> 
> > From: Rajendra Nayak <rnayak <at> ti.com>
> > 
> > OMAP4 has module specific context lost registers which makes it now
> > possible to have module level context loss count, instead of relying
> > on the powerdomain level context count.
> > 
> > Add 2 private hwmod api's to update/clear the hwmod/module specific
> > context lost counters/register.
> 
> This one has been modified to align with the changes on patch 3, and 
> queued for 3.7.

Am sorry to say that I had to drop the code changes from this patch, due 
to the OMAP serial bugs addressed by these two patches:

    http://comments.gmane.org/gmane.linux.ports.arm.omap/84729
    http://www.spinics.net/lists/arm-kernel/msg196034.html

Without those two patches, OMAP4430ES2 Panda crashes after Tero's patches 
are applied, with the same symptom as with the N800 crash.  Applying 
those two patches fixes the problem.

It would be good if you guys could ask Greg to pick up the first patch 
ASAP so we can queue the second one during the early 3.7-rc time frame.

(Continue reading)

headers

Tero Kristo | 19 Jul 2012 15:26

[PATCHv7 05/12] ARM: OMAP4: pwrdm: add support for reading prev logic and mem states

On OMAP4, there is no support to read previous logic state
or previous memory state achieved when a power domain transitions
to RET. Instead there are module level context registers.

In order to support the powerdomain level logic/mem_off_counters
on OMAP4, instead use the previous power state achieved (RET) and
the *programmed* logic/mem RET state to derive if a powerdomain lost
logic or did not.

If the powerdomain is programmed to enter RET state and lose logic
in RET state, knowing that the powerdomain entered RET is good enough
to derive that the logic was lost as well, in such cases.

Signed-off-by: Tero Kristo <t-kristo <at> ti.com>
---
 arch/arm/mach-omap2/powerdomain44xx.c |   59 +++++++++++++++++++++++++++++++++
 1 files changed, 59 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/powerdomain44xx.c b/arch/arm/mach-omap2/powerdomain44xx.c
index 030d10c..ab93f08 100644
--- a/arch/arm/mach-omap2/powerdomain44xx.c
+++ b/arch/arm/mach-omap2/powerdomain44xx.c
 <at>  <at>  -151,6 +151,34  <at>  <at>  static int omap4_pwrdm_read_logic_retst(struct powerdomain *pwrdm)
 	return v;
 }

+/**
+ * omap4_pwrdm_read_prev_logic_pwrst - read the previous logic powerstate
+ *  <at> pwrdm: struct powerdomain * to read the state for
+ *

(Continue reading)

headers

Paul Walmsley | 12 Sep 2012 21:50

Re: [PATCHv7 05/12] ARM: OMAP4: pwrdm: add support for reading prev logic and mem states

On Thu, 19 Jul 2012, Tero Kristo wrote:

> On OMAP4, there is no support to read previous logic state
> or previous memory state achieved when a power domain transitions
> to RET. Instead there are module level context registers.
> 
> In order to support the powerdomain level logic/mem_off_counters
> on OMAP4, instead use the previous power state achieved (RET) and
> the *programmed* logic/mem RET state to derive if a powerdomain lost
> logic or did not.
> 
> If the powerdomain is programmed to enter RET state and lose logic
> in RET state, knowing that the powerdomain entered RET is good enough
> to derive that the logic was lost as well, in such cases.
> 
> Signed-off-by: Tero Kristo <t-kristo <at> ti.com>

This one was modified to remove this patch's dependency on the functional 
powerstate series and queued for 3.7.  The modified patch follows.

- Paul

From: Tero Kristo <t-kristo <at> ti.com>
Date: Thu, 19 Jul 2012 16:26:25 +0300
Subject: [PATCH] ARM: OMAP4: powerdomain: add support for reading prev logic
 and mem states

On OMAP4, there is no support to read previous logic state
or previous memory state achieved when a power domain transitions
to RET. Instead there are module level context registers.

(Continue reading)

headers

Tero Kristo | 19 Jul 2012 15:26

[PATCHv7 07/12] ARM: OMAP4: PM: put all domains to OSWR during suspend

Signed-off-by: Tero Kristo <t-kristo <at> ti.com>
---
 arch/arm/mach-omap2/pm44xx.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-omap2/pm44xx.c b/arch/arm/mach-omap2/pm44xx.c
index 1e845e8..eb3e073 100644
--- a/arch/arm/mach-omap2/pm44xx.c
+++ b/arch/arm/mach-omap2/pm44xx.c
 <at>  <at>  -105,7 +105,7  <at>  <at>  static int __init pwrdms_setup(struct powerdomain *pwrdm, void *unused)
 	pwrst->pwrdm = pwrdm;
 	pwrst->next_state = pwrdm_get_achievable_func_pwrst(
 						pwrdm,
-						PWRDM_FUNC_PWRST_CSWR);
+						PWRDM_FUNC_PWRST_OSWR);
 	list_add(&pwrst->node, &pwrst_list);

 	return omap_set_pwrdm_state(pwrst->pwrdm, pwrst->next_state);
--

-- 
1.7.4.1

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

headers

Paul Walmsley | 19 Jul 2012 16:44

Re: [PATCHv7 07/12] ARM: OMAP4: PM: put all domains to OSWR during suspend

On Thu, 19 Jul 2012, Tero Kristo wrote:

> Signed-off-by: Tero Kristo <t-kristo <at> ti.com>

This one needs at least some short description for the changelog.  Maybe 
just a brief explanation that OSWR saves more energy that CSWR, but has 
higher resume latency, and since resume from system suspend is considered 
to be a high-latency operation, OSWR is appropriate here.

- Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

headers

Tero Kristo | 19 Jul 2012 17:31

Re: [PATCHv7 07/12] ARM: OMAP4: PM: put all domains to OSWR during suspend

On Thu, 2012-07-19 at 08:44 -0600, Paul Walmsley wrote:
> On Thu, 19 Jul 2012, Tero Kristo wrote:
> 
> > Signed-off-by: Tero Kristo <t-kristo <at> ti.com>
> 
> This one needs at least some short description for the changelog.  Maybe 
> just a brief explanation that OSWR saves more energy that CSWR, but has 
> higher resume latency, and since resume from system suspend is considered 
> to be a high-latency operation, OSWR is appropriate here.

Yea, I can add one. How about this:

Subject: [PATCHv7 07/12] ARM: OMAP4: PM: put all domains to OSWR during
suspend

Currently OMAP4 suspend puts all power domains to CSWR. OSWR is a deeper
state that saves more power, but has higher latencies also. As suspend
is considered a high-latency operation, OSWR is appropriate here.

Signed-off-by: Tero Kristo <t-kristo <at> ti.com>
---

I'll update this to next rev if one is requested.

(Kind of hoping this set would be reaching maturity already.)

-Tero

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in

(Continue reading)

headers

Paul Walmsley | 20 Jul 2012 01:30

Re: [PATCHv7 07/12] ARM: OMAP4: PM: put all domains to OSWR during suspend

Hi

On Thu, 19 Jul 2012, Tero Kristo wrote:

> Subject: [PATCHv7 07/12] ARM: OMAP4: PM: put all domains to OSWR during
> suspend
> 
> Currently OMAP4 suspend puts all power domains to CSWR. OSWR is a deeper
> state that saves more power, but has higher latencies also. As suspend
> is considered a high-latency operation, OSWR is appropriate here.
> 
> Signed-off-by: Tero Kristo <t-kristo <at> ti.com>
> ---
> 
> I'll update this to next rev if one is requested.

No need, I'll add it in the local copy here.

> (Kind of hoping this set would be reaching maturity already.)

It kind of looks to me like there are two or three separate sets within 
the series.  My feeling is that Kevin should take the first two, then I 
should take the rest other than 6 and 7.  Then once those are queued, 
we can pull in 6 and 7.  Does that make sense to you?

- Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

(Continue reading)

headers

Tero Kristo | 20 Jul 2012 10:37

Re: [PATCHv7 07/12] ARM: OMAP4: PM: put all domains to OSWR during suspend

On Thu, 2012-07-19 at 17:30 -0600, Paul Walmsley wrote:
> Hi
> 
> On Thu, 19 Jul 2012, Tero Kristo wrote:
> 
> > Subject: [PATCHv7 07/12] ARM: OMAP4: PM: put all domains to OSWR during
> > suspend
> > 
> > Currently OMAP4 suspend puts all power domains to CSWR. OSWR is a deeper
> > state that saves more power, but has higher latencies also. As suspend
> > is considered a high-latency operation, OSWR is appropriate here.
> > 
> > Signed-off-by: Tero Kristo <t-kristo <at> ti.com>
> > ---
> > 
> > I'll update this to next rev if one is requested.
> 
> No need, I'll add it in the local copy here.

Thanks, thats what I thought. :)

> 
> > (Kind of hoping this set would be reaching maturity already.)
> 
> It kind of looks to me like there are two or three separate sets within 
> the series.  My feeling is that Kevin should take the first two, then I 
> should take the rest other than 6 and 7.  Then once those are queued, 
> we can pull in 6 and 7.  Does that make sense to you?

Yea, that looks good to me. Patches up from 6+ should only be pulled

(Continue reading)

headers

Kevin Hilman | 13 Sep 2012 01:11

Re: [PATCHv7 07/12] ARM: OMAP4: PM: put all domains to OSWR during suspend

Paul Walmsley <paul <at> pwsan.com> writes:

[...]

>
> It kind of looks to me like there are two or three separate sets within 
> the series.  My feeling is that Kevin should take the first two, then I 
> should take the rest other than 6 and 7.  Then once those are queued, 
> we can pull in 6 and 7.  Does that make sense to you?
>

Looks like 1, 2 & 7 are needed for OSWR, and the rest can go now via
Paul.

Tero, can create a new OSWR series including 1, 2 & 7?  Can you also
refresh it against Jean's latest functional power state series (v6)?

Thanks,

Kevin

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

headers

Tero Kristo | 13 Sep 2012 09:40

Re: [PATCHv7 07/12] ARM: OMAP4: PM: put all domains to OSWR during suspend

On Wed, 2012-09-12 at 16:11 -0700, Kevin Hilman wrote:
> Paul Walmsley <paul <at> pwsan.com> writes:
> 
> [...]
> 
> >
> > It kind of looks to me like there are two or three separate sets within 
> > the series.  My feeling is that Kevin should take the first two, then I 
> > should take the rest other than 6 and 7.  Then once those are queued, 
> > we can pull in 6 and 7.  Does that make sense to you?
> >
> 
> Looks like 1, 2 & 7 are needed for OSWR, and the rest can go now via
> Paul.
> 
> Tero, can create a new OSWR series including 1, 2 & 7?  Can you also
> refresh it against Jean's latest functional power state series (v6)?

Yes, I already have these patches locally available. I'll just refresh
them against Paul's minor tweaks on rest of the patches and re-post.

-Tero

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

headers

Tero Kristo | 19 Jul 2012 15:26

[PATCHv7 11/12] ARM: OMAP4: hwmod_data: add context lose information for l4_abe hwmod

'l4_abe' hwmod uses the LOSTMEM_AESSMEM bit of RM_ABE_AESS_CONTEXT register,
as l4_abe doesn't have its own dedicated register for this purpose. This
register is shared with 'aess' hwmod, thus both hwmods must also specify
which bits of the register are used for them.

Signed-off-by: Tero Kristo <t-kristo <at> ti.com>
---
 arch/arm/mach-omap2/omap_hwmod_44xx_data.c |    4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 8b60377..48431cb 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
 <at>  <at>  -204,7 +204,8  <at>  <at>  static struct omap_hwmod omap44xx_l4_abe_hwmod = {
 	.prcm = {
 		.omap4 = {
 			.clkctrl_offs = OMAP4_CM1_ABE_L4ABE_CLKCTRL_OFFSET,
-			.context_offs = USHRT_MAX,
+			.context_offs = OMAP4_RM_ABE_AESS_CONTEXT_OFFSET,
+			.lostcontext_mask = OMAP4430_LOSTMEM_AESSMEM_MASK,
 		},
 	},
 };
 <at>  <at>  -350,6 +351,7  <at>  <at>  static struct omap_hwmod omap44xx_aess_hwmod = {
 		.omap4 = {
 			.clkctrl_offs = OMAP4_CM1_ABE_AESS_CLKCTRL_OFFSET,
 			.context_offs = OMAP4_RM_ABE_AESS_CONTEXT_OFFSET,
+			.lostcontext_mask = OMAP4430_LOSTCONTEXT_DFF_MASK,
 			.modulemode   = MODULEMODE_SWCTRL,

(Continue reading)

headers

Tero Kristo | 19 Jul 2012 15:26

[PATCHv7 10/12] ARM: OMAP4: HWMOD: add support for lostcontext_mask

Currently hwmod only provides the offset for the context lose register,
and if we attempt to share the same register between two or more hwmods,
the resulting context loss counts get wrong. Thus, we need a way to
specify which bits are used for the context loss information for each.
This is accomplished by adding a new field to the omap4 prcm struct,
'lostcontext_mask', which specifies a bit-mask to use for filtering
the register. Only the specified bits are read and cleared by the
context lose counter update code. If a hwmod doesn't specify
'lostcontext_mask' (default behavior), the whole contents of the
context register are used without any filtering.

Signed-off-by: Tero Kristo <t-kristo <at> ti.com>
---
 arch/arm/mach-omap2/omap_hwmod.c             |    8 ++++++++
 arch/arm/plat-omap/include/plat/omap_hwmod.h |    6 ++++++
 2 files changed, 14 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index a60dfd2..3ebf93e 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
 <at>  <at>  -1810,11 +1810,19  <at>  <at>  static void _omap4_update_context_lost(struct omap_hwmod *oh)
 					oh->clkdm->pwrdm.ptr->prcm_offs,
 					oh->prcm.omap4.context_offs);

+	/*
+	 * If lostcontext_mask is defined, only check these bits for
+	 * losing context. Otherwise check whole register.
+	 */
+	if (oh->prcm.omap4.lostcontext_mask)

(Continue reading)

headers

Paul Walmsley | 12 Sep 2012 21:52

Re: [PATCHv7 10/12] ARM: OMAP4: HWMOD: add support for lostcontext_mask

On Thu, 19 Jul 2012, Tero Kristo wrote:

> Currently hwmod only provides the offset for the context lose register,
> and if we attempt to share the same register between two or more hwmods,
> the resulting context loss counts get wrong. Thus, we need a way to
> specify which bits are used for the context loss information for each.
> This is accomplished by adding a new field to the omap4 prcm struct,
> 'lostcontext_mask', which specifies a bit-mask to use for filtering
> the register. Only the specified bits are read and cleared by the
> context lose counter update code. If a hwmod doesn't specify
> 'lostcontext_mask' (default behavior), the whole contents of the
> context register are used without any filtering.
> 
> Signed-off-by: Tero Kristo <t-kristo <at> ti.com>

Thanks, queued for 3.7.

- Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

headers

Tero Kristo | 19 Jul 2012 15:26

[PATCHv7 08/12] ARM: OMAP4430: PM: Work-around for ROM code BUG of PER pwrst ctrl

On OMAP4430 HS / EMU chips, ROM code appears to re-configure L4PER domain
next powerstate during wakeup from OSWR / OFF, programming it to ON.
This will prevent successive entries to cpuidle retention / off, until
kernel decices to change the L4PER target state, which can be delayed
for a very long time as kernel is lazy programming the target state.

This patch fixes the issue within the low power OSWR / OFF mode code, so
that this register is saved / restored across MPU OSWR / OFF state.

This problem seems to only occur with OMAP4430 HS/EMU, it does not impact
OMAP4460+ or GP devices.

Signed-off-by: Tero Kristo <t-kristo <at> ti.com>
---
 arch/arm/mach-omap2/omap-mpuss-lowpower.c |   39 ++++++++++++++++++++++++++++-
 arch/arm/mach-omap2/pm.h                  |    1 +
 arch/arm/mach-omap2/pm44xx.c              |   10 +++++++
 3 files changed, 49 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-omap2/omap-mpuss-lowpower.c b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
index 0e5f81b..963a61b 100644
--- a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
+++ b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
 <at>  <at>  -52,6 +52,7  <at>  <at> 

 #include <plat/omap44xx.h>

+#include "iomap.h"
 #include "common.h"
 #include "omap4-sar-layout.h"

(Continue reading)

headers

Paul Walmsley | 20 Jul 2012 01:21

Re: [PATCHv7 08/12] ARM: OMAP4430: PM: Work-around for ROM code BUG of PER pwrst ctrl

Hi

On Thu, 19 Jul 2012, Tero Kristo wrote:

> On OMAP4430 HS / EMU chips, ROM code appears to re-configure L4PER domain
> next powerstate during wakeup from OSWR / OFF, programming it to ON.
> This will prevent successive entries to cpuidle retention / off, until
> kernel decices to change the L4PER target state, which can be delayed
> for a very long time as kernel is lazy programming the target state.
> 
> This patch fixes the issue within the low power OSWR / OFF mode code, so
> that this register is saved / restored across MPU OSWR / OFF state.
> 
> This problem seems to only occur with OMAP4430 HS/EMU, it does not impact
> OMAP4460+ or GP devices.
> 
> Signed-off-by: Tero Kristo <t-kristo <at> ti.com>
> ---
>  arch/arm/mach-omap2/omap-mpuss-lowpower.c |   39 ++++++++++++++++++++++++++++-
>  arch/arm/mach-omap2/pm.h                  |    1 +
>  arch/arm/mach-omap2/pm44xx.c              |   10 +++++++
>  3 files changed, 49 insertions(+), 1 deletions(-)
> 
> diff --git a/arch/arm/mach-omap2/omap-mpuss-lowpower.c b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
> index 0e5f81b..963a61b 100644
> --- a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
> +++ b/arch/arm/mach-omap2/omap-mpuss-lowpower.c

...

(Continue reading)

headers

Tero Kristo | 20 Jul 2012 11:20

Re: [PATCHv7 08/12] ARM: OMAP4430: PM: Work-around for ROM code BUG of PER pwrst ctrl

On Thu, 2012-07-19 at 17:21 -0600, Paul Walmsley wrote:
> Hi
> 
> On Thu, 19 Jul 2012, Tero Kristo wrote:
> 
> > On OMAP4430 HS / EMU chips, ROM code appears to re-configure L4PER domain
> > next powerstate during wakeup from OSWR / OFF, programming it to ON.
> > This will prevent successive entries to cpuidle retention / off, until
> > kernel decices to change the L4PER target state, which can be delayed
> > for a very long time as kernel is lazy programming the target state.
> > 
> > This patch fixes the issue within the low power OSWR / OFF mode code, so
> > that this register is saved / restored across MPU OSWR / OFF state.
> > 
> > This problem seems to only occur with OMAP4430 HS/EMU, it does not impact
> > OMAP4460+ or GP devices.
> > 
> > Signed-off-by: Tero Kristo <t-kristo <at> ti.com>
> > ---
> >  arch/arm/mach-omap2/omap-mpuss-lowpower.c |   39 ++++++++++++++++++++++++++++-
> >  arch/arm/mach-omap2/pm.h                  |    1 +
> >  arch/arm/mach-omap2/pm44xx.c              |   10 +++++++
> >  3 files changed, 49 insertions(+), 1 deletions(-)
> > 
> > diff --git a/arch/arm/mach-omap2/omap-mpuss-lowpower.c b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
> > index 0e5f81b..963a61b 100644
> > --- a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
> > +++ b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
> 
> ...

(Continue reading)

headers

Tero Kristo | 20 Jul 2012 15:25

Re: [PATCHv7 08/12] ARM: OMAP4430: PM: Work-around for ROM code BUG of PER pwrst ctrl

On Thu, 2012-07-19 at 17:21 -0600, Paul Walmsley wrote:
> Hi
> 
> On Thu, 19 Jul 2012, Tero Kristo wrote:
> 
> > On OMAP4430 HS / EMU chips, ROM code appears to re-configure L4PER domain
> > next powerstate during wakeup from OSWR / OFF, programming it to ON.
> > This will prevent successive entries to cpuidle retention / off, until
> > kernel decices to change the L4PER target state, which can be delayed
> > for a very long time as kernel is lazy programming the target state.
> > 
> > This patch fixes the issue within the low power OSWR / OFF mode code, so
> > that this register is saved / restored across MPU OSWR / OFF state.
> > 
> > This problem seems to only occur with OMAP4430 HS/EMU, it does not impact
> > OMAP4460+ or GP devices.
> > 
> > Signed-off-by: Tero Kristo <t-kristo <at> ti.com>
> > ---
> >  arch/arm/mach-omap2/omap-mpuss-lowpower.c |   39 ++++++++++++++++++++++++++++-
> >  arch/arm/mach-omap2/pm.h                  |    1 +
> >  arch/arm/mach-omap2/pm44xx.c              |   10 +++++++
> >  3 files changed, 49 insertions(+), 1 deletions(-)
> > 
> > diff --git a/arch/arm/mach-omap2/omap-mpuss-lowpower.c b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
> > index 0e5f81b..963a61b 100644
> > --- a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
> > +++ b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
> 
> ...

(Continue reading)

headers

Tero Kristo | 19 Jul 2012 15:26

[PATCHv7 12/12] ARM: OMAP4: hwmod: update context lost counter logic for hwmods without context reg

With this patch, the hwmods that don't have context register, will now
increment their context lost counter always unless they belong to an
always on powerdomain which never loses context. The always on pwrdm
type is checked by looking at the the powerdomain registered for the
hwmod, and seeing if it only has ON within its valid powerstates.

Signed-off-by: Tero Kristo <t-kristo <at> ti.com>
---
 arch/arm/mach-omap2/omap_hwmod.c |   21 ++++++++++++++++++++-
 1 files changed, 20 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 3ebf93e..daf5322 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
 <at>  <at>  -1802,9 +1802,28  <at>  <at>  static void _reconfigure_io_chain(void)
 static void _omap4_update_context_lost(struct omap_hwmod *oh)
 {
 	u32 r;
+	struct powerdomain *pwrdm;
+
+	/* Special handling if we have not defined context register */
+	if (oh->prcm.omap4.context_offs == USHRT_MAX) {
+		/* Get powerdomain pointer for this hwmod */
+		if (oh->clkdm)
+			pwrdm = oh->clkdm->pwrdm.ptr;
+		else
+			pwrdm = NULL;

-	if (oh->prcm.omap4.context_offs == USHRT_MAX)

(Continue reading)

headers

Tero Kristo | 19 Jul 2012 15:26

[PATCHv7 09/12] ARM: OMAP4: hwmod data: temporarily comment out data for the sl2if IP block

The OMAP4 sl2if IP block requires some special programming for it to
enter idle. Without this programming, they will prevent the rest of
the chip from entering full chip idle.

This patch comments out the IP block data.

Later, once the appropriate support is available, this patch can be
reverted.

Cc: Paul Walmsley <paul <at> pwsan.com>
Cc: Benoît Cousson <b-cousson <at> ti.com>
Signed-off-by: Tero Kristo <t-kristo <at> ti.com>
---
 arch/arm/mach-omap2/omap_hwmod_44xx_data.c |   12 ++++++------
 1 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index ad7df4e..8b60377 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
 <at>  <at>  -4266,7 +4266,7  <at>  <at>  static struct omap_hwmod_ocp_if omap44xx_dsp__iva = {
 };

 /* dsp -> sl2if */
-static struct omap_hwmod_ocp_if omap44xx_dsp__sl2if = {
+static struct omap_hwmod_ocp_if __maybe_unused omap44xx_dsp__sl2if = {
 	.master		= &omap44xx_dsp_hwmod,
 	.slave		= &omap44xx_sl2if_hwmod,
 	.clk		= "dpll_iva_m5x2_ck",
 <at>  <at>  -4884,7 +4884,7  <at>  <at>  static struct omap_hwmod_ocp_if omap44xx_l3_main_2__iss = {

(Continue reading)

headers

Paul Walmsley | 23 Jul 2012 20:38

Re: [PATCHv7 09/12] ARM: OMAP4: hwmod data: temporarily comment out data for the sl2if IP block

Hi Tero

On Thu, 19 Jul 2012, Tero Kristo wrote:

> The OMAP4 sl2if IP block requires some special programming for it to
> enter idle. Without this programming, they will prevent the rest of
> the chip from entering full chip idle.
> 
> This patch comments out the IP block data.
> 
> Later, once the appropriate support is available, this patch can be
> reverted.
> 
> Cc: Paul Walmsley <paul <at> pwsan.com>
> Cc: Benoît Cousson <b-cousson <at> ti.com>
> Signed-off-by: Tero Kristo <t-kristo <at> ti.com>

Originally I was hoping that we could apply a real fix for this one.  But 
looking at the proposed alternative in the old SL2IF E-mail threads, I'm 
still not convinced by what's proposed there.  So we'd better take this 
one for the time being.

Queued for 3.6-rc.

- Paul