ARM: OMAP2+: Add powerdomain & PRM support for AM33XX device
Subsystems (5)
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
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.
--- 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
@@ -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
PATCH v3 2/3 ARM: OMAP2+: powerdomain: Add offset & mask fields to struct powerdomain
In reply to Vaibhav HiremathIn 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.
--- arch/arm/mach-omap2/powerdomain.h | 17 +++++++++++++++++ 1 files changed, 17 insertions(+), 0 deletions(-)
arch/arm/mach-omap2/powerdomain.h +17 -0
@@ -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
PATCH v3 3/3 ARM: OMAP3+: am33xx: Add powerdomain & PRM support
In reply to Vaibhav HiremathAs 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.
--- 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
@@ -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
@@ -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
@@ -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
@@ -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
v3 cover ARM: OMAP2+: Add powerdomain & PRM support for AM33XX device
In reply to Vaibhav HiremathHi 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_RSTSTregister offset to "structomap_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
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_RSTSTregister offset to "structomap_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.cmade 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.
commit c16fa4f2ad19908a47c63d8fa436a1178438c7e7
Author: Linus Torvalds <[email protected]> Date: Sun Mar 18 16:15:34 2012 -0700
Linux 3.3
Quoted 2 lines
Kevin