Skip to contentSkip to conversation

ARM: OMAP2+: Add powerdomain & PRM support for AM33XX device

PATCH Superseded Vaibhav Hiremath 2 participants 6 messages Mar 15, 2012 – Mar 30, 2012

Subsystems (5)

v3 of 4 Superseded Latest is v4 →

lore
Share & tools
lore
#0 lore raw

v3 cover ARM: OMAP2+: Add powerdomain & PRM support for AM33XX device

After going round-n-round on how to add support for AM33XX family of device into kernel, especially for PRM and CM support, we have decided to handle it separately; as AM33XX-PRCM module is different than OMAP3 and OMAP4 architecture.

The difference becomes very interesting/weird when it comes to the consistency for register offsets in PRM address space and bit-field offsets inside PRM registers,
So along with Powerdomain data and PRM api's required for AM33XX device, this patch series adds,

- XXX_RSTST register offset to "struct omap_hwmod_omap4_prcm"
- PWRSTCTRL & PWRSTST register offsets to "struct powerdomain"
- Logicretstate and mem_on/ret/pwrst/retst mask to "struct powerdomain"

Testing: This patch series has been boot tested on AM37xEVM and AM335x
based BeagleBone community board.

THANKS TO PAUL HERE...for helping and concluding on this, soon I will have similar patch for CM support, then clock-tree and hwmod will follow...

Changes from V1 & V2:
- Rolled back to my original approach, where AM33xx device was handled separately (RFC version).
- As per Paul's comments, added Register offsets & bit-fields masks.

Vaibhav Hiremath (3):
ARM: OMAP3/4: omap_hwmod: Add rstst_off field to struct
omap_hwmod_omap4_prcm
ARM: OMAP2+: powerdomain: Add offset & mask fields to struct
powerdomain
ARM: OMAP3+: am33xx: Add power domain data

 arch/arm/mach-omap2/Makefile                 |    4 +
 arch/arm/mach-omap2/io.c                     |    1 +
 arch/arm/mach-omap2/omap_hwmod.c             |   32 ++-
 arch/arm/mach-omap2/powerdomain.h            |   23 ++-
 arch/arm/mach-omap2/powerdomain33xx.c        |  230 +++++++++++++++++
 arch/arm/mach-omap2/powerdomains33xx_data.c  |  185 +++++++++++++
 arch/arm/mach-omap2/prm-regbits-33xx.h       |  357 ++++++++++++++++++++++++++
 arch/arm/mach-omap2/prm33xx.c                |  134 ++++++++++
 arch/arm/mach-omap2/prm33xx.h                |  129 +++++++++
 arch/arm/plat-omap/include/plat/omap_hwmod.h |    2 +
 10 files changed, 1092 insertions(+), 5 deletions(-)
 create mode 100644 arch/arm/mach-omap2/powerdomain33xx.c
 create mode 100644 arch/arm/mach-omap2/powerdomains33xx_data.c
 create mode 100644 arch/arm/mach-omap2/prm-regbits-33xx.h
 create mode 100644 arch/arm/mach-omap2/prm33xx.c
 create mode 100644 arch/arm/mach-omap2/prm33xx.h
#1 lore raw

PATCH v3 1/3 ARM: OMAP3/4: omap_hwmod: Add rstst_off field to struct omap_hwmod_omap4_prcm

In case of AM33XX device, XXX_RSTST register offset is not consistent across PRM modules/instances,

PRM_XXX RSTST
=========================

PRM_PER_MOD:       0x04
PRM_WKUP_MOD:      0x0C
PRM_MPU_MOD:       NA
PRM_DEVICE_MOD:    0x08

This means, we need to pass on XXX_RSTST register offset information through omap_hwmod data, similar to XXX_RSTCTRL.

Currently, this field is only applicable and used for AM33XX devices.

Cc Paul Walmsley <[email protected]>
Cc Benoit Cousson <[email protected]>
Cc Kevin Hilman <[email protected]>
Cc Tony Lindgren <[email protected]>
---
 arch/arm/plat-omap/include/plat/omap_hwmod.h |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)
arch/arm/plat-omap/include/plat/omap_hwmod.h +2 -0
index ce75c30..1cfa008 100644
@@ -377,11 +377,13 @@ struct omap_hwmod_omap2_prcm {
  * struct omap_hwmod_omap4_prcm - OMAP4-specific PRCM data
  * @clkctrl_reg: PRCM address of the clock control register
  * @rstctrl_reg: address of the XXX_RSTCTRL register located in the PRM
+ * @rstst_reg: (AM33XX Only) address of the XXX_RSTST register located in the PRM
  * @submodule_wkdep_bit: bit shift of the WKDEP range
  */
 struct omap_hwmod_omap4_prcm {
 	u16		clkctrl_offs;
 	u16		rstctrl_offs;
+	u16		rstst_offs;
 	u16		context_offs;
 	u8		submodule_wkdep_bit;
 	u8		modulemode;

--
1.7.0.4

#2 lore raw

PATCH v3 2/3 ARM: OMAP2+: powerdomain: Add offset & mask fields to struct powerdomain

In reply to Vaibhav Hiremath

In case of AM33xx device, there is no consistency between PWRSTCTRL & PWRSTST register offsets in PRM space, for example -

PRM_XXX PWRSTCTRL PWRSTST
=======================================

PRM_PER_MOD:      0x0C,         0x08
PRM_WKUP_MOD:     0x04,         0x08
PRM_MPU_MOD:      0x00,         0x04
PRM_DEVICE_MOD:   NA,           NA

And also, there is no consistency between bit-offsets inside PWRSTCTRL & PWRSTST register, for example -

PRM_XXX LOGICRET MEMON MEMRET
=========================================

GFX_PWRCTRL:      2,        17,    6
PER_PWRCTRL:      3,        25,    29
MPU_PWRCTRL:      2,        18,    22
WKUP_PWRCTRL:     3,        NA,    NA

This means, we need to maintain and pass on all this information through powerdomain handle; so adding fields for,
- PWRSTCTRL/ST register offset
- Logic retention state mask
- mem_on/ret/pwrst/retst mask

Currently, this fields is only applicable and used for AM33XX devices.

Cc Paul Walmsley <[email protected]>
Cc Benoit Cousson <[email protected]>
Cc Kevin Hilman <[email protected]>
Cc Tony Lindgren <[email protected]>
---
 arch/arm/mach-omap2/powerdomain.h |   17 +++++++++++++++++
 1 files changed, 17 insertions(+), 0 deletions(-)
arch/arm/mach-omap2/powerdomain.h +17 -0
index 0d72a8a..8fc50b2 100644
@@ -92,6 +92,15 @@ struct powerdomain;
  * @pwrdm_clkdms: Clockdomains in this powerdomain
  * @node: list_head linking all powerdomains
  * @voltdm_node: list_head linking all powerdomains in a voltagedomain
+ * @pwrstctrl_offs: (AM33XX only) XXX_PWRSTCTRL reg offset from prcm_offs
+ * @pwrstst_offs: (AM33XX only) XXX_PWRSTST reg offset from prcm_offs
+ * @logicretstate_mask: (AM33XX only) mask for logic retention bitfield
+ *	in @pwrstctrl_offs
+ * @mem_on_mask: (AM33XX only) mask for mem on bitfield in @pwrstctrl_offs
+ * @mem_ret_mask: (AM33XX only) mask for mem retention bitfield in @pwrstctrl_offs
+ * @mem_pwrst_mask: (AM33XX only) mask for mem state bitfield in @pwrstst_offs
+ * @mem_retst_mask: (AM33XX only) mask for mem retention state bitfield
+ *	in @pwrstctrl_offs
  * @state:
  * @state_counter:
  * @timer:
@@ -121,6 +130,14 @@ struct powerdomain {
 	unsigned ret_logic_off_counter;
 	unsigned ret_mem_off_counter[PWRDM_MAX_MEM_BANKS];
 
+	const u8 pwrstctrl_offs;
+	const u8 pwrstst_offs;
+	const u32 logicretstate_mask;
+	const u32 mem_on_mask[PWRDM_MAX_MEM_BANKS];
+	const u32 mem_ret_mask[PWRDM_MAX_MEM_BANKS];
+	const u32 mem_pwrst_mask[PWRDM_MAX_MEM_BANKS];
+	const u32 mem_retst_mask[PWRDM_MAX_MEM_BANKS];
+
 #ifdef CONFIG_PM_DEBUG
 	s64 timer;
 	s64 state_timer[PWRDM_MAX_PWRSTS];

--
1.7.0.4

#3 lore raw

PATCH v3 3/3 ARM: OMAP3+: am33xx: Add powerdomain & PRM support

In reply to Vaibhav Hiremath

As far as PRM/CM/PRCM modules are concerned, AM33XX device is different than OMAP3 and OMAP4 architectures; so we need to handle it separately.
This patch adds support for, Powerdomain, Powerdomain data, PRM api's required for AM33XX device.

And also, hooks up AM33XX powerdomain to existing OMAP framework.

Cc Benoit Cousson <[email protected]>
Cc Tony Lindgren <[email protected]>
Cc Kevin Hilman <[email protected]>
Cc Paul Walmsley <[email protected]>
Cc Rajendra Nayak <[email protected]>
---
 arch/arm/mach-omap2/Makefile                |    4 +
 arch/arm/mach-omap2/io.c                    |    1 +
 arch/arm/mach-omap2/omap_hwmod.c            |   32 +++-
 arch/arm/mach-omap2/powerdomain.h           |    6 +-
 arch/arm/mach-omap2/powerdomain33xx.c       |  230 +++++++++++++++++
 arch/arm/mach-omap2/powerdomains33xx_data.c |  185 ++++++++++++++
 arch/arm/mach-omap2/prm-regbits-33xx.h      |  357 +++++++++++++++++++++++++++
 arch/arm/mach-omap2/prm33xx.c               |  134 ++++++++++
 arch/arm/mach-omap2/prm33xx.h               |  129 ++++++++++
 9 files changed, 1073 insertions(+), 5 deletions(-)
 create mode 100644 arch/arm/mach-omap2/powerdomain33xx.c
 create mode 100644 arch/arm/mach-omap2/powerdomains33xx_data.c
 create mode 100644 arch/arm/mach-omap2/prm-regbits-33xx.h
 create mode 100644 arch/arm/mach-omap2/prm33xx.c
 create mode 100644 arch/arm/mach-omap2/prm33xx.h
arch/arm/mach-omap2/Makefile +4 -0
index b4ac21e..fd130e5 100644
@@ -114,6 +114,10 @@ obj-$(CONFIG_ARCH_OMAP3)		+= $(powerdomain-common) \
 					   powerdomain2xxx_3xxx.o \
 					   powerdomains3xxx_data.o \
 					   powerdomains2xxx_3xxx_data.o
+obj-$(CONFIG_SOC_OMAPAM33XX)		+= $(powerdomain-common) \
+					   prm33xx.o \
+					   powerdomain33xx.o \
+					   powerdomains33xx_data.o
 obj-$(CONFIG_ARCH_OMAP4)		+= $(powerdomain-common) \
 					   powerdomain44xx.o \
 					   powerdomains44xx_data.o
arch/arm/mach-omap2/io.c +1 -0
index 11d53df..b594918 100644
@@ -473,6 +473,7 @@ void __init am33xx_init_early(void)
 	omap2_set_globals_am33xx();
 	omap_common_init_early();
 	am33xx_voltagedomains_init();
+	am33xx_powerdomains_init();
 	omap3xxx_clk_init();
 }
 #endif
arch/arm/mach-omap2/omap_hwmod.c +29 -3
index 26928c6..d698010 100644
@@ -151,6 +151,7 @@
 #include "cminst44xx.h"
 #include "prm2xxx_3xxx.h"
 #include "prm44xx.h"
+#include "prm33xx.h"
 #include "prminst44xx.h"
 #include "mux.h"
 
@@ -1418,7 +1419,15 @@ static int _assert_hardreset(struct omap_hwmod *oh, const char *name)
 	if (IS_ERR_VALUE(ret))
 		return ret;
 
-	if (cpu_is_omap24xx() || cpu_is_omap34xx())
+	/*
+	 * cpu_is_omap34xx() is true for am33xx device as well, so
+	 * fist check for cpu_is_am33xx().
+	 */
+	if (cpu_is_am33xx())
+		return am33xx_prm_assert_hardreset(ohri.rst_shift,
+				oh->clkdm->pwrdm.ptr->prcm_offs,
+				oh->prcm.omap4.rstctrl_offs);
+	else if (cpu_is_omap24xx() || cpu_is_omap34xx())
 		return omap2_prm_assert_hardreset(oh->prcm.omap2.module_offs,
 						  ohri.rst_shift);
 	else if (cpu_is_omap44xx())
@@ -1452,7 +1461,16 @@ static int _deassert_hardreset(struct omap_hwmod *oh, const char *name)
 	if (IS_ERR_VALUE(ret))
 		return ret;
 
-	if (cpu_is_omap24xx() || cpu_is_omap34xx()) {
+	/*
+	 * cpu_is_omap34xx() is true for am33xx device as well, so
+	 * fist check for cpu_is_am33xx().
+	 */
+	if (cpu_is_am33xx()) {
+		return am33xx_prm_deassert_hardreset(ohri.rst_shift,
+				oh->clkdm->pwrdm.ptr->prcm_offs,
+				oh->prcm.omap4.rstctrl_offs,
+				oh->prcm.omap4.rstst_offs);
+	} else if (cpu_is_omap24xx() || cpu_is_omap34xx()) {
 		ret = omap2_prm_deassert_hardreset(oh->prcm.omap2.module_offs,
 						   ohri.rst_shift,
 						   ohri.st_shift);
@@ -1494,7 +1512,15 @@ static int _read_hardreset(struct omap_hwmod *oh, const char *name)
 	if (IS_ERR_VALUE(ret))
 		return ret;
 
-	if (cpu_is_omap24xx() || cpu_is_omap34xx()) {
+	/*
+	 * cpu_is_omap34xx() is true for am33xx device as well, so
+	 * fist check for cpu_is_am33xx().
+	 */
+	if (cpu_is_am33xx()) {
+		return am33xx_prm_is_hardreset_asserted(ohri.rst_shift,
+				oh->clkdm->pwrdm.ptr->prcm_offs,
+				oh->prcm.omap4.rstctrl_offs);
+	} else if (cpu_is_omap24xx() || cpu_is_omap34xx()) {
 		return omap2_prm_is_hardreset_asserted(oh->prcm.omap2.module_offs,
 						       ohri.st_shift);
 	} else if (cpu_is_omap44xx()) {
arch/arm/mach-omap2/powerdomain.h +4 -2
index 8fc50b2..53e42a9 100644
@@ -67,9 +67,9 @@
 
 /*
  * Maximum number of clockdomains that can be associated with a powerdomain.
- * CORE powerdomain on OMAP4 is the worst case
+ * PER powerdomain on AM33XX is the worst case
  */
-#define PWRDM_MAX_CLKDMS	9
+#define PWRDM_MAX_CLKDMS	11
 
 /* XXX A completely arbitrary number. What is reasonable here? */
 #define PWRDM_TRANSITION_BAILOUT 100000
@@ -240,10 +240,12 @@ bool pwrdm_can_ever_lose_context(struct powerdomain *pwrdm);
 extern void omap242x_powerdomains_init(void);
 extern void omap243x_powerdomains_init(void);
 extern void omap3xxx_powerdomains_init(void);
+extern void am33xx_powerdomains_init(void);
 extern void omap44xx_powerdomains_init(void);
 
 extern struct pwrdm_ops omap2_pwrdm_operations;
 extern struct pwrdm_ops omap3_pwrdm_operations;
+extern struct pwrdm_ops am33xx_pwrdm_operations;
 extern struct pwrdm_ops omap4_pwrdm_operations;
 
 /* Common Internal functions used across OMAP rev's */
arch/arm/mach-omap2/powerdomain33xx.c new file +230 -0

230 lines not on this page · raw message

arch/arm/mach-omap2/powerdomains33xx_data.c new file +185 -0

185 lines not on this page · raw message

arch/arm/mach-omap2/prm-regbits-33xx.h new file +357 -0

357 lines not on this page · raw message

arch/arm/mach-omap2/prm33xx.c new file +134 -0

134 lines not on this page · raw message

arch/arm/mach-omap2/prm33xx.h new file +129 -0

129 lines not on this page · raw message

--
1.7.0.4

#4 lore raw

v3 cover ARM: OMAP2+: Add powerdomain & PRM support for AM33XX device

In reply to Vaibhav Hiremath

Hi Vaibhav,

Quoted 19 lines · Vaibhav Hiremath

After going round-n-round on how to add support for AM33XX family of device into kernel, especially for PRM and CM support, we have decided to handle it separately; as AM33XX-PRCM module is different than OMAP3 and OMAP4 architecture.

The difference becomes very interesting/weird when it comes to the consistency for register offsets in PRM address space and bit-field offsets inside PRM registers,
So along with Powerdomain data and PRM api's required for AM33XX device, this patch series adds,

- XXX_RSTST register offset to "struct omap_hwmod_omap4_prcm"
- PWRSTCTRL & PWRSTST register offsets to "struct powerdomain"
- Logicretstate and mem_on/ret/pwrst/retst mask to "struct powerdomain"

Testing: This patch series has been boot tested on AM37xEVM and AM335x
based BeagleBone community board.

Quoted 6 lines

THANKS TO PAUL HERE...for helping and concluding on this, soon I will have similar patch for CM support, then clock-tree and hwmod will follow...

Changes from V1 & V2:
- Rolled back to my original approach, where AM33xx device was handled separately (RFC version).

My apologies for causing the run around.

This approach (without the prminst layer) is indeed a better approach.

Thanks for your patience (and persistence.)

I went to give this a test on my BeagleBone, but it doesn't apply to mainline. What upstream commit is this supposed to apply onto. I tried it on v3.3, but patch 3 fails with a conflict in io.c.

Looking at your am335x-staging branch, it seems that it depends on previous changes to io.c made in:

arm:omap:am33xx: Add AM335XEVM machine support

That patch appears to need an update for mainline as well.

Kevin

#5 lore raw

v3 cover ARM: OMAP2+: Add powerdomain & PRM support for AM33XX device

Quoted 30 lines · Kevin

Hi Vaibhav,

Quoted 19 lines · Vaibhav Hiremath

After going round-n-round on how to add support for AM33XX family of device into kernel, especially for PRM and CM support, we have decided to handle it separately; as AM33XX-PRCM module is different than OMAP3 and OMAP4 architecture.

The difference becomes very interesting/weird when it comes to the consistency for register offsets in PRM address space and bit-field offsets inside PRM registers,
So along with Powerdomain data and PRM api's required for AM33XX device, this patch series adds,

- XXX_RSTST register offset to "struct omap_hwmod_omap4_prcm"
- PWRSTCTRL & PWRSTST register offsets to "struct powerdomain"
- Logicretstate and mem_on/ret/pwrst/retst mask to "struct powerdomain"

Testing: This patch series has been boot tested on AM37xEVM and AM335x
based BeagleBone community board.

Quoted 6 lines

THANKS TO PAUL HERE...for helping and concluding on this, soon I will have similar patch for CM support, then clock-tree and hwmod will follow...

Changes from V1 & V2:
- Rolled back to my original approach, where AM33xx device was handled separately (RFC version).

Quoted 8 lines

My apologies for causing the run around.

This approach (without the prminst layer) is indeed a better approach.

Thanks for your patience (and persistence.)

I went to give this a test on my BeagleBone, but it doesn't apply to mainline. What upstream commit is this supposed to apply onto.

I and using, linux-omap/master and/or linux-omap/cleanup branches as a baseline for sending the patches.

Quoted 2 lines

I tried it on v3.3, but patch 3 fails with a conflict in io.c.

My bad. I did not include (or resend) voltage domain patch (had submitted last time itself).
I will resend the all patch-series again including voltage domain addition patch. Just for reference, the series will follow the sequence -

voltagedomains
powerdomains
clockdomains
clock
hwmod

Quoted 7 lines

Looking at your am335x-staging branch, it seems that it depends on previous changes to io.c made in:

arm:omap:am33xx: Add AM335XEVM machine support

That patch appears to need an update for mainline as well.

Can you please clarify on this? I use v3.3 to check on this, and it is Getting applied without any issues for me.

I believe you are using V5 version of this patch series, also you can pick this patch from (created to give pull request to Tony)
https://github.com/hvaibhav/am335x-linux/tree/am335x-baseport-for-tony

Log:
==============
commit 812e168a9584e180c12588ca2b0233e96461e997

Author: Afzal Mohammed <[email protected]>
Date:   Tue Aug 9 14:29:41 2011 +0530

arm:omap:am33xx: Add AM335XEVM machine support

This patch adds minimal support for AM335X EVM. The approach taken here is to add AM335X EVM support to AM3517EVM, considering the fact that with device tree developement we will get rid of board-*.c.

[Changed ti816x_init_irq=>ti81xx_init_irq, due to recent acceptance of patches]

commit c16fa4f2ad19908a47c63d8fa436a1178438c7e7

Author: Linus Torvalds <[email protected]>
Date:   Sun Mar 18 16:15:34 2012 -0700
    Linux 3.3
Quoted 2 lines

Kevin