* [PATCH-V4 0/4] ARM: OMAP2+: Add voltagedomain, powerdomain & PRM support for AM33XX device
@ 2012-03-30 16:03 ` Vaibhav Hiremath
0 siblings, 0 replies; 64+ messages in thread
From: Vaibhav Hiremath @ 2012-03-30 16:03 UTC (permalink / raw)
To: linux-omap
Cc: khilman, paul, b-cousson, tony, rnayak, Vaibhav Hiremath,
linux-arm-kernel
After some healthy discussion, now we have come to the conclusion and
decided to handle AM33XX PRM/CM part 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,
shortly I will submit similar patch for CM, clockdomain and clock-tree
support for AM33xx.
This patch-series is created on top of "linux-omap/cleanup" branch, and
also gets applied to "linux-omap/master" branch.
The patches are also available at -
https://github.com/hvaibhav/am335x-linux/tree/am335x-prm-cm
Changes from previous versions:
===============================
>From V3:
- No code change, only added Voltagedomain patch (from V2 series)
to this series.
>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 (4):
ARM: OMAP3+: am33xx: Add voltage domain data
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 powerdomain & PRM support
arch/arm/mach-omap2/Makefile | 6 +
arch/arm/mach-omap2/io.c | 2 +
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/mach-omap2/voltage.h | 1 +
arch/arm/mach-omap2/voltagedomains33xx_data.c | 43 +++
arch/arm/plat-omap/include/plat/omap_hwmod.h | 2 +
12 files changed, 1139 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
create mode 100644 arch/arm/mach-omap2/voltagedomains33xx_data.c
^ permalink raw reply [flat|nested] 64+ messages in thread* [PATCH-V4 0/4] ARM: OMAP2+: Add voltagedomain, powerdomain & PRM support for AM33XX device @ 2012-03-30 16:03 ` Vaibhav Hiremath 0 siblings, 0 replies; 64+ messages in thread From: Vaibhav Hiremath @ 2012-03-30 16:03 UTC (permalink / raw) To: linux-arm-kernel After some healthy discussion, now we have come to the conclusion and decided to handle AM33XX PRM/CM part 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, shortly I will submit similar patch for CM, clockdomain and clock-tree support for AM33xx. This patch-series is created on top of "linux-omap/cleanup" branch, and also gets applied to "linux-omap/master" branch. The patches are also available at - https://github.com/hvaibhav/am335x-linux/tree/am335x-prm-cm Changes from previous versions: =============================== >From V3: - No code change, only added Voltagedomain patch (from V2 series) to this series. >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 (4): ARM: OMAP3+: am33xx: Add voltage domain data 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 powerdomain & PRM support arch/arm/mach-omap2/Makefile | 6 + arch/arm/mach-omap2/io.c | 2 + 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/mach-omap2/voltage.h | 1 + arch/arm/mach-omap2/voltagedomains33xx_data.c | 43 +++ arch/arm/plat-omap/include/plat/omap_hwmod.h | 2 + 12 files changed, 1139 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 create mode 100644 arch/arm/mach-omap2/voltagedomains33xx_data.c ^ permalink raw reply [flat|nested] 64+ messages in thread
* [PATCH-V4 1/4] ARM: OMAP3+: am33xx: Add voltage domain data 2012-03-30 16:03 ` Vaibhav Hiremath @ 2012-03-30 16:03 ` Vaibhav Hiremath -1 siblings, 0 replies; 64+ messages in thread From: Vaibhav Hiremath @ 2012-03-30 16:03 UTC (permalink / raw) To: linux-omap Cc: khilman, paul, b-cousson, tony, rnayak, Afzal Mohammed, Vaibhav Hiremath, linux-arm-kernel Currently dummy voltage domain data is being created in order to succeed boot process, nothing has been done w.r.t actual hardware (voltage control). Also, hook up the AM33XX voltage domain to OMAP framework. Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com> Signed-off-by: Afzal Mohammed <afzal@ti.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Kevin Hilman <khilman@ti.com> Cc: Paul Walmsley <paul@pwsan.com> Cc: Rajendra Nayak <rnayak@ti.com> --- arch/arm/mach-omap2/Makefile | 2 + arch/arm/mach-omap2/io.c | 1 + arch/arm/mach-omap2/voltage.h | 1 + arch/arm/mach-omap2/voltagedomains33xx_data.c | 43 +++++++++++++++++++++++++ 4 files changed, 47 insertions(+), 0 deletions(-) create mode 100644 arch/arm/mach-omap2/voltagedomains33xx_data.c diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile index 74ae499..8d90f9f 100644 --- a/arch/arm/mach-omap2/Makefile +++ b/arch/arm/mach-omap2/Makefile @@ -99,6 +99,8 @@ obj-$(CONFIG_ARCH_OMAP2) += $(voltagedomain-common) \ voltagedomains2xxx_data.o obj-$(CONFIG_ARCH_OMAP3) += $(voltagedomain-common) \ voltagedomains3xxx_data.o +obj-$(CONFIG_SOC_OMAPAM33XX) += $(voltagedomain-common) \ + voltagedomains33xx_data.o obj-$(CONFIG_ARCH_OMAP4) += $(voltagedomain-common) \ voltagedomains44xx_data.o diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c index 51d4df8..523fb6d 100644 --- a/arch/arm/mach-omap2/io.c +++ b/arch/arm/mach-omap2/io.c @@ -466,6 +466,7 @@ void __init am33xx_init_early(void) { omap2_set_globals_am33xx(); omap_common_init_early(); + am33xx_voltagedomains_init(); omap3xxx_clk_init(); } #endif diff --git a/arch/arm/mach-omap2/voltage.h b/arch/arm/mach-omap2/voltage.h index 16a1b09..a7c43c1 100644 --- a/arch/arm/mach-omap2/voltage.h +++ b/arch/arm/mach-omap2/voltage.h @@ -156,6 +156,7 @@ int omap_voltage_late_init(void); extern void omap2xxx_voltagedomains_init(void); extern void omap3xxx_voltagedomains_init(void); +extern void am33xx_voltagedomains_init(void); extern void omap44xx_voltagedomains_init(void); struct voltagedomain *voltdm_lookup(const char *name); diff --git a/arch/arm/mach-omap2/voltagedomains33xx_data.c b/arch/arm/mach-omap2/voltagedomains33xx_data.c new file mode 100644 index 0000000..965458d --- /dev/null +++ b/arch/arm/mach-omap2/voltagedomains33xx_data.c @@ -0,0 +1,43 @@ +/* + * AM33XX voltage domain data + * + * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com/ + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License as + * published by the Free Software Foundation version 2. + * + * This program is distributed "as is" WITHOUT ANY WARRANTY of any + * kind, whether express or implied; without even the implied warranty + * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + */ + +#include <linux/kernel.h> +#include <linux/init.h> + +#include "voltage.h" + +static struct voltagedomain am33xx_voltdm_mpu = { + .name = "mpu", +}; + +static struct voltagedomain am33xx_voltdm_core = { + .name = "core", +}; + +static struct voltagedomain am33xx_voltdm_rtc = { + .name = "rtc", +}; + +static struct voltagedomain *voltagedomains_am33xx[] __initdata = { + &am33xx_voltdm_mpu, + &am33xx_voltdm_core, + &am33xx_voltdm_rtc, + NULL, +}; + +void __init am33xx_voltagedomains_init(void) +{ + voltdm_init(voltagedomains_am33xx); +} -- 1.7.0.4 ^ permalink raw reply related [flat|nested] 64+ messages in thread
* [PATCH-V4 1/4] ARM: OMAP3+: am33xx: Add voltage domain data @ 2012-03-30 16:03 ` Vaibhav Hiremath 0 siblings, 0 replies; 64+ messages in thread From: Vaibhav Hiremath @ 2012-03-30 16:03 UTC (permalink / raw) To: linux-arm-kernel Currently dummy voltage domain data is being created in order to succeed boot process, nothing has been done w.r.t actual hardware (voltage control). Also, hook up the AM33XX voltage domain to OMAP framework. Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com> Signed-off-by: Afzal Mohammed <afzal@ti.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Kevin Hilman <khilman@ti.com> Cc: Paul Walmsley <paul@pwsan.com> Cc: Rajendra Nayak <rnayak@ti.com> --- arch/arm/mach-omap2/Makefile | 2 + arch/arm/mach-omap2/io.c | 1 + arch/arm/mach-omap2/voltage.h | 1 + arch/arm/mach-omap2/voltagedomains33xx_data.c | 43 +++++++++++++++++++++++++ 4 files changed, 47 insertions(+), 0 deletions(-) create mode 100644 arch/arm/mach-omap2/voltagedomains33xx_data.c diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile index 74ae499..8d90f9f 100644 --- a/arch/arm/mach-omap2/Makefile +++ b/arch/arm/mach-omap2/Makefile @@ -99,6 +99,8 @@ obj-$(CONFIG_ARCH_OMAP2) += $(voltagedomain-common) \ voltagedomains2xxx_data.o obj-$(CONFIG_ARCH_OMAP3) += $(voltagedomain-common) \ voltagedomains3xxx_data.o +obj-$(CONFIG_SOC_OMAPAM33XX) += $(voltagedomain-common) \ + voltagedomains33xx_data.o obj-$(CONFIG_ARCH_OMAP4) += $(voltagedomain-common) \ voltagedomains44xx_data.o diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c index 51d4df8..523fb6d 100644 --- a/arch/arm/mach-omap2/io.c +++ b/arch/arm/mach-omap2/io.c @@ -466,6 +466,7 @@ void __init am33xx_init_early(void) { omap2_set_globals_am33xx(); omap_common_init_early(); + am33xx_voltagedomains_init(); omap3xxx_clk_init(); } #endif diff --git a/arch/arm/mach-omap2/voltage.h b/arch/arm/mach-omap2/voltage.h index 16a1b09..a7c43c1 100644 --- a/arch/arm/mach-omap2/voltage.h +++ b/arch/arm/mach-omap2/voltage.h @@ -156,6 +156,7 @@ int omap_voltage_late_init(void); extern void omap2xxx_voltagedomains_init(void); extern void omap3xxx_voltagedomains_init(void); +extern void am33xx_voltagedomains_init(void); extern void omap44xx_voltagedomains_init(void); struct voltagedomain *voltdm_lookup(const char *name); diff --git a/arch/arm/mach-omap2/voltagedomains33xx_data.c b/arch/arm/mach-omap2/voltagedomains33xx_data.c new file mode 100644 index 0000000..965458d --- /dev/null +++ b/arch/arm/mach-omap2/voltagedomains33xx_data.c @@ -0,0 +1,43 @@ +/* + * AM33XX voltage domain data + * + * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com/ + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License as + * published by the Free Software Foundation version 2. + * + * This program is distributed "as is" WITHOUT ANY WARRANTY of any + * kind, whether express or implied; without even the implied warranty + * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + */ + +#include <linux/kernel.h> +#include <linux/init.h> + +#include "voltage.h" + +static struct voltagedomain am33xx_voltdm_mpu = { + .name = "mpu", +}; + +static struct voltagedomain am33xx_voltdm_core = { + .name = "core", +}; + +static struct voltagedomain am33xx_voltdm_rtc = { + .name = "rtc", +}; + +static struct voltagedomain *voltagedomains_am33xx[] __initdata = { + &am33xx_voltdm_mpu, + &am33xx_voltdm_core, + &am33xx_voltdm_rtc, + NULL, +}; + +void __init am33xx_voltagedomains_init(void) +{ + voltdm_init(voltagedomains_am33xx); +} -- 1.7.0.4 ^ permalink raw reply related [flat|nested] 64+ messages in thread
* Re: [PATCH-V4 1/4] ARM: OMAP3+: am33xx: Add voltage domain data 2012-03-30 16:03 ` Vaibhav Hiremath @ 2012-04-28 0:39 ` Paul Walmsley -1 siblings, 0 replies; 64+ messages in thread From: Paul Walmsley @ 2012-04-28 0:39 UTC (permalink / raw) To: Vaibhav Hiremath, khilman Cc: linux-omap, tony, rnayak, b-cousson, linux-arm-kernel, Afzal Mohammed Hi Vaibhav, Kevin, On Fri, 30 Mar 2012, Vaibhav Hiremath wrote: > Currently dummy voltage domain data is being created > in order to succeed boot process, nothing has been done > w.r.t actual hardware (voltage control). > > Also, hook up the AM33XX voltage domain to OMAP framework. > > Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com> > Signed-off-by: Afzal Mohammed <afzal@ti.com> > Cc: Benoit Cousson <b-cousson@ti.com> > Cc: Tony Lindgren <tony@atomide.com> > Cc: Kevin Hilman <khilman@ti.com> > Cc: Paul Walmsley <paul@pwsan.com> > Cc: Rajendra Nayak <rnayak@ti.com> Looks okay to me. Kevin, you want to ack this one and I will queue it? Either that, or if you want to take it, I will ack it. - Paul ^ permalink raw reply [flat|nested] 64+ messages in thread
* [PATCH-V4 1/4] ARM: OMAP3+: am33xx: Add voltage domain data @ 2012-04-28 0:39 ` Paul Walmsley 0 siblings, 0 replies; 64+ messages in thread From: Paul Walmsley @ 2012-04-28 0:39 UTC (permalink / raw) To: linux-arm-kernel Hi Vaibhav, Kevin, On Fri, 30 Mar 2012, Vaibhav Hiremath wrote: > Currently dummy voltage domain data is being created > in order to succeed boot process, nothing has been done > w.r.t actual hardware (voltage control). > > Also, hook up the AM33XX voltage domain to OMAP framework. > > Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com> > Signed-off-by: Afzal Mohammed <afzal@ti.com> > Cc: Benoit Cousson <b-cousson@ti.com> > Cc: Tony Lindgren <tony@atomide.com> > Cc: Kevin Hilman <khilman@ti.com> > Cc: Paul Walmsley <paul@pwsan.com> > Cc: Rajendra Nayak <rnayak@ti.com> Looks okay to me. Kevin, you want to ack this one and I will queue it? Either that, or if you want to take it, I will ack it. - Paul ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [PATCH-V4 1/4] ARM: OMAP3+: am33xx: Add voltage domain data 2012-04-28 0:39 ` Paul Walmsley @ 2012-04-30 20:41 ` Kevin Hilman -1 siblings, 0 replies; 64+ messages in thread From: Kevin Hilman @ 2012-04-30 20:41 UTC (permalink / raw) To: Paul Walmsley Cc: Vaibhav Hiremath, linux-omap, tony, rnayak, b-cousson, linux-arm-kernel, Afzal Mohammed Paul Walmsley <paul@pwsan.com> writes: > Hi Vaibhav, Kevin, > > On Fri, 30 Mar 2012, Vaibhav Hiremath wrote: > >> Currently dummy voltage domain data is being created >> in order to succeed boot process, nothing has been done >> w.r.t actual hardware (voltage control). >> >> Also, hook up the AM33XX voltage domain to OMAP framework. >> >> Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com> >> Signed-off-by: Afzal Mohammed <afzal@ti.com> >> Cc: Benoit Cousson <b-cousson@ti.com> >> Cc: Tony Lindgren <tony@atomide.com> >> Cc: Kevin Hilman <khilman@ti.com> >> Cc: Paul Walmsley <paul@pwsan.com> >> Cc: Rajendra Nayak <rnayak@ti.com> > > Looks okay to me. Kevin, you want to ack this one and I will queue it? > Either that, or if you want to take it, I will ack it. You can take it with the others. Acked-by: Kevin Hilman <khilman@ti.com> ^ permalink raw reply [flat|nested] 64+ messages in thread
* [PATCH-V4 1/4] ARM: OMAP3+: am33xx: Add voltage domain data @ 2012-04-30 20:41 ` Kevin Hilman 0 siblings, 0 replies; 64+ messages in thread From: Kevin Hilman @ 2012-04-30 20:41 UTC (permalink / raw) To: linux-arm-kernel Paul Walmsley <paul@pwsan.com> writes: > Hi Vaibhav, Kevin, > > On Fri, 30 Mar 2012, Vaibhav Hiremath wrote: > >> Currently dummy voltage domain data is being created >> in order to succeed boot process, nothing has been done >> w.r.t actual hardware (voltage control). >> >> Also, hook up the AM33XX voltage domain to OMAP framework. >> >> Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com> >> Signed-off-by: Afzal Mohammed <afzal@ti.com> >> Cc: Benoit Cousson <b-cousson@ti.com> >> Cc: Tony Lindgren <tony@atomide.com> >> Cc: Kevin Hilman <khilman@ti.com> >> Cc: Paul Walmsley <paul@pwsan.com> >> Cc: Rajendra Nayak <rnayak@ti.com> > > Looks okay to me. Kevin, you want to ack this one and I will queue it? > Either that, or if you want to take it, I will ack it. You can take it with the others. Acked-by: Kevin Hilman <khilman@ti.com> ^ permalink raw reply [flat|nested] 64+ messages in thread
* [PATCH-V4 2/4] ARM: OMAP3/4: omap_hwmod: Add rstst_off field to struct omap_hwmod_omap4_prcm 2012-03-30 16:03 ` Vaibhav Hiremath @ 2012-03-30 16:03 ` Vaibhav Hiremath -1 siblings, 0 replies; 64+ messages in thread From: Vaibhav Hiremath @ 2012-03-30 16:03 UTC (permalink / raw) To: linux-omap Cc: khilman, paul, b-cousson, tony, rnayak, Vaibhav Hiremath, linux-arm-kernel 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. Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Kevin Hilman <khilman@ti.com> Cc: Paul Walmsley <paul@pwsan.com> Cc: Rajendra Nayak <rnayak@ti.com> --- arch/arm/plat-omap/include/plat/omap_hwmod.h | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/arch/arm/plat-omap/include/plat/omap_hwmod.h b/arch/arm/plat-omap/include/plat/omap_hwmod.h index 9ae87eb..50f42ec 100644 --- a/arch/arm/plat-omap/include/plat/omap_hwmod.h +++ b/arch/arm/plat-omap/include/plat/omap_hwmod.h @@ -374,11 +374,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 ^ permalink raw reply related [flat|nested] 64+ messages in thread
* [PATCH-V4 2/4] ARM: OMAP3/4: omap_hwmod: Add rstst_off field to struct omap_hwmod_omap4_prcm @ 2012-03-30 16:03 ` Vaibhav Hiremath 0 siblings, 0 replies; 64+ messages in thread From: Vaibhav Hiremath @ 2012-03-30 16:03 UTC (permalink / raw) To: linux-arm-kernel 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. Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Kevin Hilman <khilman@ti.com> Cc: Paul Walmsley <paul@pwsan.com> Cc: Rajendra Nayak <rnayak@ti.com> --- arch/arm/plat-omap/include/plat/omap_hwmod.h | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/arch/arm/plat-omap/include/plat/omap_hwmod.h b/arch/arm/plat-omap/include/plat/omap_hwmod.h index 9ae87eb..50f42ec 100644 --- a/arch/arm/plat-omap/include/plat/omap_hwmod.h +++ b/arch/arm/plat-omap/include/plat/omap_hwmod.h @@ -374,11 +374,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 ^ permalink raw reply related [flat|nested] 64+ messages in thread
* RE: [PATCH-V4 2/4] ARM: OMAP3/4: omap_hwmod: Add rstst_off field to struct omap_hwmod_omap4_prcm 2012-03-30 16:03 ` Vaibhav Hiremath @ 2012-05-29 6:31 ` Hiremath, Vaibhav -1 siblings, 0 replies; 64+ messages in thread From: Hiremath, Vaibhav @ 2012-05-29 6:31 UTC (permalink / raw) To: Hiremath, Vaibhav, linux-omap Cc: tony, Hilman, Kevin, paul, Nayak, Rajendra, Cousson, Benoit, linux-arm-kernel On Fri, Mar 30, 2012 at 21:33:53, Hiremath, Vaibhav wrote: > 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. > > Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com> > Cc: Benoit Cousson <b-cousson@ti.com> > Cc: Tony Lindgren <tony@atomide.com> > Cc: Kevin Hilman <khilman@ti.com> > Cc: Paul Walmsley <paul@pwsan.com> > Cc: Rajendra Nayak <rnayak@ti.com> > --- > arch/arm/plat-omap/include/plat/omap_hwmod.h | 2 ++ > 1 files changed, 2 insertions(+), 0 deletions(-) > > diff --git a/arch/arm/plat-omap/include/plat/omap_hwmod.h b/arch/arm/plat-omap/include/plat/omap_hwmod.h > index 9ae87eb..50f42ec 100644 > --- a/arch/arm/plat-omap/include/plat/omap_hwmod.h > +++ b/arch/arm/plat-omap/include/plat/omap_hwmod.h > @@ -374,11 +374,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; Paul, We have missed this patch from the series, can you merge this one as well? Thanks, Vaibhav ^ permalink raw reply [flat|nested] 64+ messages in thread
* [PATCH-V4 2/4] ARM: OMAP3/4: omap_hwmod: Add rstst_off field to struct omap_hwmod_omap4_prcm @ 2012-05-29 6:31 ` Hiremath, Vaibhav 0 siblings, 0 replies; 64+ messages in thread From: Hiremath, Vaibhav @ 2012-05-29 6:31 UTC (permalink / raw) To: linux-arm-kernel On Fri, Mar 30, 2012 at 21:33:53, Hiremath, Vaibhav wrote: > 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. > > Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com> > Cc: Benoit Cousson <b-cousson@ti.com> > Cc: Tony Lindgren <tony@atomide.com> > Cc: Kevin Hilman <khilman@ti.com> > Cc: Paul Walmsley <paul@pwsan.com> > Cc: Rajendra Nayak <rnayak@ti.com> > --- > arch/arm/plat-omap/include/plat/omap_hwmod.h | 2 ++ > 1 files changed, 2 insertions(+), 0 deletions(-) > > diff --git a/arch/arm/plat-omap/include/plat/omap_hwmod.h b/arch/arm/plat-omap/include/plat/omap_hwmod.h > index 9ae87eb..50f42ec 100644 > --- a/arch/arm/plat-omap/include/plat/omap_hwmod.h > +++ b/arch/arm/plat-omap/include/plat/omap_hwmod.h > @@ -374,11 +374,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; Paul, We have missed this patch from the series, can you merge this one as well? Thanks, Vaibhav ^ permalink raw reply [flat|nested] 64+ messages in thread
* [PATCH-V4 3/4] ARM: OMAP2+: powerdomain: Add offset & mask fields to struct powerdomain 2012-03-30 16:03 ` Vaibhav Hiremath @ 2012-03-30 16:03 ` Vaibhav Hiremath -1 siblings, 0 replies; 64+ messages in thread From: Vaibhav Hiremath @ 2012-03-30 16:03 UTC (permalink / raw) To: linux-omap Cc: khilman, paul, b-cousson, tony, rnayak, Vaibhav Hiremath, linux-arm-kernel In case of AM33xx family of devices, there is no consistency between PWRSTCTRL & PWRSTST register offsers 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 in 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. Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Kevin Hilman <khilman@ti.com> Cc: Paul Walmsley <paul@pwsan.com> Cc: Rajendra Nayak <rnayak@ti.com> --- arch/arm/mach-omap2/powerdomain.h | 17 +++++++++++++++++ 1 files changed, 17 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/powerdomain.h b/arch/arm/mach-omap2/powerdomain.h index 0d72a8a..8fc50b2 100644 --- a/arch/arm/mach-omap2/powerdomain.h +++ b/arch/arm/mach-omap2/powerdomain.h @@ -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 ^ permalink raw reply related [flat|nested] 64+ messages in thread
* [PATCH-V4 3/4] ARM: OMAP2+: powerdomain: Add offset & mask fields to struct powerdomain @ 2012-03-30 16:03 ` Vaibhav Hiremath 0 siblings, 0 replies; 64+ messages in thread From: Vaibhav Hiremath @ 2012-03-30 16:03 UTC (permalink / raw) To: linux-arm-kernel In case of AM33xx family of devices, there is no consistency between PWRSTCTRL & PWRSTST register offsers 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 in 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. Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Kevin Hilman <khilman@ti.com> Cc: Paul Walmsley <paul@pwsan.com> Cc: Rajendra Nayak <rnayak@ti.com> --- arch/arm/mach-omap2/powerdomain.h | 17 +++++++++++++++++ 1 files changed, 17 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/powerdomain.h b/arch/arm/mach-omap2/powerdomain.h index 0d72a8a..8fc50b2 100644 --- a/arch/arm/mach-omap2/powerdomain.h +++ b/arch/arm/mach-omap2/powerdomain.h @@ -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 ^ permalink raw reply related [flat|nested] 64+ messages in thread
* [PATCH-V4 4/4] ARM: OMAP3+: am33xx: Add powerdomain & PRM support 2012-03-30 16:03 ` Vaibhav Hiremath @ 2012-03-30 16:03 ` Vaibhav Hiremath -1 siblings, 0 replies; 64+ messages in thread From: Vaibhav Hiremath @ 2012-03-30 16:03 UTC (permalink / raw) To: linux-omap Cc: khilman, paul, b-cousson, tony, rnayak, Afzal Mohammed, Vaibhav Hiremath, linux-arm-kernel 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. Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com> Signed-off-by: Afzal Mohammed <afzal@ti.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Kevin Hilman <khilman@ti.com> Cc: Paul Walmsley <paul@pwsan.com> Cc: Rajendra Nayak <rnayak@ti.com> --- 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 diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile index 8d90f9f..8220369 100644 --- a/arch/arm/mach-omap2/Makefile +++ b/arch/arm/mach-omap2/Makefile @@ -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 diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c index 523fb6d..b8fd170 100644 --- a/arch/arm/mach-omap2/io.c +++ b/arch/arm/mach-omap2/io.c @@ -467,6 +467,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 diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c index 5192cab..97b47f2 100644 --- a/arch/arm/mach-omap2/omap_hwmod.c +++ b/arch/arm/mach-omap2/omap_hwmod.c @@ -150,6 +150,7 @@ #include "cminst44xx.h" #include "prm2xxx_3xxx.h" #include "prm44xx.h" +#include "prm33xx.h" #include "prminst44xx.h" #include "mux.h" @@ -1288,7 +1289,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()) @@ -1322,7 +1331,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); @@ -1364,7 +1382,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()) { diff --git a/arch/arm/mach-omap2/powerdomain.h b/arch/arm/mach-omap2/powerdomain.h index 8fc50b2..53e42a9 100644 --- a/arch/arm/mach-omap2/powerdomain.h +++ b/arch/arm/mach-omap2/powerdomain.h @@ -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 */ diff --git a/arch/arm/mach-omap2/powerdomain33xx.c b/arch/arm/mach-omap2/powerdomain33xx.c new file mode 100644 index 0000000..c53f8d8 --- /dev/null +++ b/arch/arm/mach-omap2/powerdomain33xx.c @@ -0,0 +1,230 @@ +/* + * AM33XX Powerdomain control + * + * Copyright (C) 2011-2012 Texas Instruments Incorporated - http://www.ti.com/ + * + * Derived from mach-omap2/powerdomain44xx.c written by Rajendra Nayak + * <rnayak@ti.com> + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License as + * published by the Free Software Foundation version 2. + * + * This program is distributed "as is" WITHOUT ANY WARRANTY of any + * kind, whether express or implied; without even the implied warranty + * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + */ + +#include <linux/io.h> +#include <linux/errno.h> +#include <linux/delay.h> + +#include <plat/prcm.h> + +#include "powerdomain.h" +#include "prm33xx.h" +#include "prm-regbits-33xx.h" + + +static int am33xx_pwrdm_set_next_pwrst(struct powerdomain *pwrdm, u8 pwrst) +{ + am33xx_prm_rmw_reg_bits(OMAP_POWERSTATE_MASK, + (pwrst << OMAP_POWERSTATE_SHIFT), + pwrdm->prcm_offs, pwrdm->pwrstctrl_offs); + return 0; +} + +static int am33xx_pwrdm_read_next_pwrst(struct powerdomain *pwrdm) +{ + u32 v; + + v = am33xx_prm_read_reg(pwrdm->prcm_offs, pwrdm->pwrstctrl_offs); + v &= OMAP_POWERSTATE_MASK; + v >>= OMAP_POWERSTATE_SHIFT; + + return v; +} + +static int am33xx_pwrdm_read_pwrst(struct powerdomain *pwrdm) +{ + u32 v; + + v = am33xx_prm_read_reg(pwrdm->prcm_offs, pwrdm->pwrstst_offs); + v &= OMAP_POWERSTATEST_MASK; + v >>= OMAP_POWERSTATEST_SHIFT; + + return v; +} + +static int am33xx_pwrdm_read_prev_pwrst(struct powerdomain *pwrdm) +{ + u32 v; + + v = am33xx_prm_read_reg(pwrdm->prcm_offs, pwrdm->pwrstst_offs); + v &= AM33XX_LASTPOWERSTATEENTERED_MASK; + v >>= AM33XX_LASTPOWERSTATEENTERED_SHIFT; + + return v; +} + +static int am33xx_pwrdm_set_lowpwrstchange(struct powerdomain *pwrdm) +{ + am33xx_prm_rmw_reg_bits(AM33XX_LOWPOWERSTATECHANGE_MASK, + (1 << AM33XX_LOWPOWERSTATECHANGE_SHIFT), + pwrdm->prcm_offs, pwrdm->pwrstctrl_offs); + return 0; +} + +static int am33xx_pwrdm_clear_all_prev_pwrst(struct powerdomain *pwrdm) +{ + am33xx_prm_rmw_reg_bits(AM33XX_LASTPOWERSTATEENTERED_MASK, + AM33XX_LASTPOWERSTATEENTERED_MASK, + pwrdm->prcm_offs, pwrdm->pwrstst_offs); + return 0; +} + +static int am33xx_pwrdm_set_logic_retst(struct powerdomain *pwrdm, u8 pwrst) +{ + u32 m; + + m = pwrdm->logicretstate_mask; + if (!m) + return -EINVAL; + + am33xx_prm_rmw_reg_bits(m, (pwrst << __ffs(m)), + pwrdm->prcm_offs, pwrdm->pwrstctrl_offs); + + return 0; +} + +static int am33xx_pwrdm_read_logic_pwrst(struct powerdomain *pwrdm) +{ + u32 v; + + v = am33xx_prm_read_reg(pwrdm->prcm_offs, pwrdm->pwrstst_offs); + v &= AM33XX_LOGICSTATEST_MASK; + v >>= AM33XX_LOGICSTATEST_SHIFT; + + return v; +} + +static int am33xx_pwrdm_read_logic_retst(struct powerdomain *pwrdm) +{ + u32 v, m; + + m = pwrdm->logicretstate_mask; + if (!m) + return -EINVAL; + + v = am33xx_prm_read_reg(pwrdm->prcm_offs, pwrdm->pwrstctrl_offs); + v &= m; + v >>= __ffs(m); + + return v; +} + +static int am33xx_pwrdm_set_mem_onst(struct powerdomain *pwrdm, u8 bank, + u8 pwrst) +{ + u32 m; + + m = pwrdm->mem_on_mask[bank]; + if (!m) + return -EINVAL; + + am33xx_prm_rmw_reg_bits(m, (pwrst << __ffs(m)), + pwrdm->prcm_offs, pwrdm->pwrstctrl_offs); + + return 0; +} + +static int am33xx_pwrdm_set_mem_retst(struct powerdomain *pwrdm, u8 bank, + u8 pwrst) +{ + u32 m; + + m = pwrdm->mem_ret_mask[bank]; + if (!m) + return -EINVAL; + + am33xx_prm_rmw_reg_bits(m, (pwrst << __ffs(m)), + pwrdm->prcm_offs, pwrdm->pwrstctrl_offs); + + return 0; +} + +static int am33xx_pwrdm_read_mem_pwrst(struct powerdomain *pwrdm, u8 bank) +{ + u32 m, v; + + m = pwrdm->mem_pwrst_mask[bank]; + if (!m) + return -EINVAL; + + v = am33xx_prm_read_reg(pwrdm->prcm_offs, pwrdm->pwrstst_offs); + v &= m; + v >>= __ffs(m); + + return v; +} + +static int am33xx_pwrdm_read_mem_retst(struct powerdomain *pwrdm, u8 bank) +{ + u32 m, v; + + m = pwrdm->mem_retst_mask[bank]; + if (!m) + return -EINVAL; + + v = am33xx_prm_read_reg(pwrdm->prcm_offs, pwrdm->pwrstctrl_offs); + v &= m; + v >>= __ffs(m); + + return v; +} + +static int am33xx_pwrdm_wait_transition(struct powerdomain *pwrdm) +{ + u32 c = 0; + + /* + * REVISIT: pwrdm_wait_transition() may be better implemented + * via a callback and a periodic timer check -- how long do we expect + * powerdomain transitions to take? + */ + + /* XXX Is this udelay() value meaningful? */ + while ((am33xx_prm_read_reg(pwrdm->prcm_offs, pwrdm->pwrstst_offs) + & OMAP_INTRANSITION_MASK) && + (c++ < PWRDM_TRANSITION_BAILOUT)) + udelay(1); + + if (c > PWRDM_TRANSITION_BAILOUT) { + printk(KERN_ERR "powerdomain: waited too long for " + "powerdomain %s to complete transition\n", + pwrdm->name); + return -EAGAIN; + } + + pr_debug("powerdomain: completed transition in %d loops\n", c); + + return 0; +} + +struct pwrdm_ops am33xx_pwrdm_operations = { + .pwrdm_set_next_pwrst = am33xx_pwrdm_set_next_pwrst, + .pwrdm_read_next_pwrst = am33xx_pwrdm_read_next_pwrst, + .pwrdm_read_pwrst = am33xx_pwrdm_read_pwrst, + .pwrdm_read_prev_pwrst = am33xx_pwrdm_read_prev_pwrst, + .pwrdm_set_logic_retst = am33xx_pwrdm_set_logic_retst, + .pwrdm_read_logic_pwrst = am33xx_pwrdm_read_logic_pwrst, + .pwrdm_read_logic_retst = am33xx_pwrdm_read_logic_retst, + .pwrdm_clear_all_prev_pwrst = am33xx_pwrdm_clear_all_prev_pwrst, + .pwrdm_set_lowpwrstchange = am33xx_pwrdm_set_lowpwrstchange, + .pwrdm_read_mem_pwrst = am33xx_pwrdm_read_mem_pwrst, + .pwrdm_read_mem_retst = am33xx_pwrdm_read_mem_retst, + .pwrdm_set_mem_onst = am33xx_pwrdm_set_mem_onst, + .pwrdm_set_mem_retst = am33xx_pwrdm_set_mem_retst, + .pwrdm_wait_transition = am33xx_pwrdm_wait_transition, +}; diff --git a/arch/arm/mach-omap2/powerdomains33xx_data.c b/arch/arm/mach-omap2/powerdomains33xx_data.c new file mode 100644 index 0000000..869adb8 --- /dev/null +++ b/arch/arm/mach-omap2/powerdomains33xx_data.c @@ -0,0 +1,185 @@ +/* + * AM33XX Power domain data + * + * Copyright (C) 2011-2012 Texas Instruments Incorporated - http://www.ti.com/ + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License as + * published by the Free Software Foundation version 2. + * + * This program is distributed "as is" WITHOUT ANY WARRANTY of any + * kind, whether express or implied; without even the implied warranty + * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + */ + +#include <linux/kernel.h> +#include <linux/init.h> + +#include "powerdomain.h" +#include "prcm-common.h" +#include "prm-regbits-33xx.h" +#include "prm33xx.h" + +static struct powerdomain gfx_33xx_pwrdm = { + .name = "gfx_pwrdm", + .voltdm = { .name = "core" }, + .prcm_offs = AM33XX_PRM_GFX_MOD, + .pwrstctrl_offs = AM33XX_PM_GFX_PWRSTCTRL_OFFSET, + .pwrstst_offs = AM33XX_PM_GFX_PWRSTST_OFFSET, + .pwrsts = PWRSTS_OFF_RET_ON, + .pwrsts_logic_ret = PWRSTS_OFF_RET, + .flags = PWRDM_HAS_LOWPOWERSTATECHANGE, + .banks = 1, + .logicretstate_mask = AM33XX_LOGICRETSTATE_MASK, + .mem_on_mask = { + [0] = AM33XX_GFX_MEM_ONSTATE_MASK, /* gfx_mem */ + }, + .mem_ret_mask = { + [0] = AM33XX_GFX_MEM_RETSTATE_MASK, /* gfx_mem */ + }, + .mem_pwrst_mask = { + [0] = AM33XX_GFX_MEM_STATEST_MASK, /* gfx_mem */ + }, + .mem_retst_mask = { + [0] = AM33XX_GFX_MEM_RETSTATE_MASK, /* gfx_mem */ + }, + .pwrsts_mem_ret = { + [0] = PWRSTS_OFF_RET, /* gfx_mem */ + }, + .pwrsts_mem_on = { + [0] = PWRSTS_ON, /* gfx_mem */ + }, +}; + +static struct powerdomain rtc_33xx_pwrdm = { + .name = "rtc_pwrdm", + .voltdm = { .name = "rtc" }, + .prcm_offs = AM33XX_PRM_RTC_MOD, + .pwrstctrl_offs = AM33XX_PM_RTC_PWRSTCTRL_OFFSET, + .pwrstst_offs = AM33XX_PM_RTC_PWRSTST_OFFSET, + .pwrsts = PWRSTS_ON, + .logicretstate_mask = AM33XX_LOGICRETSTATE_MASK, +}; + +static struct powerdomain wkup_33xx_pwrdm = { + .name = "wkup_pwrdm", + .voltdm = { .name = "core" }, + .prcm_offs = AM33XX_PRM_WKUP_MOD, + .pwrstctrl_offs = AM33XX_PM_WKUP_PWRSTCTRL_OFFSET, + .pwrstst_offs = AM33XX_PM_WKUP_PWRSTST_OFFSET, + .pwrsts = PWRSTS_ON, + .logicretstate_mask = AM33XX_LOGICRETSTATE_3_3_MASK, +}; + +static struct powerdomain per_33xx_pwrdm = { + .name = "per_pwrdm", + .voltdm = { .name = "core" }, + .prcm_offs = AM33XX_PRM_PER_MOD, + .pwrstctrl_offs = AM33XX_PM_PER_PWRSTCTRL_OFFSET, + .pwrstst_offs = AM33XX_PM_PER_PWRSTST_OFFSET, + .pwrsts = PWRSTS_OFF_RET_ON, + .pwrsts_logic_ret = PWRSTS_OFF_RET, + .flags = PWRDM_HAS_LOWPOWERSTATECHANGE, + .banks = 3, + .logicretstate_mask = AM33XX_LOGICRETSTATE_3_3_MASK, + .mem_on_mask = { + [0] = AM33XX_PRUSS_MEM_ONSTATE_MASK, /* pruss_mem */ + [1] = AM33XX_PER_MEM_ONSTATE_MASK, /* per_mem */ + [2] = AM33XX_RAM_MEM_ONSTATE_MASK, /* ram_mem */ + }, + .mem_ret_mask = { + [0] = AM33XX_PRUSS_MEM_RETSTATE_MASK, /* pruss_mem */ + [1] = AM33XX_PER_MEM_RETSTATE_MASK, /* per_mem */ + [2] = AM33XX_RAM_MEM_RETSTATE_MASK, /* ram_mem */ + }, + .mem_pwrst_mask = { + [0] = AM33XX_PRUSS_MEM_STATEST_MASK, /* pruss_mem */ + [1] = AM33XX_PER_MEM_STATEST_MASK, /* per_mem */ + [2] = AM33XX_RAM_MEM_STATEST_MASK, /* ram_mem */ + }, + .mem_retst_mask = { + [0] = AM33XX_PRUSS_MEM_RETSTATE_MASK, /* pruss_mem */ + [1] = AM33XX_PER_MEM_RETSTATE_MASK, /* per_mem */ + [2] = AM33XX_RAM_MEM_RETSTATE_MASK, /* ram_mem */ + }, + .pwrsts_mem_ret = { + [0] = PWRSTS_OFF_RET, /* pruss_mem */ + [1] = PWRSTS_OFF_RET, /* per_mem */ + [2] = PWRSTS_OFF_RET, /* ram_mem */ + }, + .pwrsts_mem_on = { + [0] = PWRSTS_ON, /* pruss_mem */ + [1] = PWRSTS_ON, /* per_mem */ + [2] = PWRSTS_ON, /* ram_mem */ + }, +}; + +static struct powerdomain mpu_33xx_pwrdm = { + .name = "mpu_pwrdm", + .voltdm = { .name = "mpu" }, + .prcm_offs = AM33XX_PRM_MPU_MOD, + .pwrstctrl_offs = AM33XX_PM_MPU_PWRSTCTRL_OFFSET, + .pwrstst_offs = AM33XX_PM_MPU_PWRSTST_OFFSET, + .pwrsts = PWRSTS_OFF_RET_ON, + .pwrsts_logic_ret = PWRSTS_OFF_RET, + .flags = PWRDM_HAS_LOWPOWERSTATECHANGE, + .banks = 3, + .logicretstate_mask = AM33XX_LOGICRETSTATE_MASK, + .mem_on_mask = { + [0] = AM33XX_MPU_L1_ONSTATE_MASK, /* mpu_l1 */ + [1] = AM33XX_MPU_L2_ONSTATE_MASK, /* mpu_l2 */ + [2] = AM33XX_MPU_RAM_ONSTATE_MASK, /* mpu_ram */ + }, + .mem_ret_mask = { + [0] = AM33XX_MPU_L1_RETSTATE_MASK, /* mpu_l1 */ + [1] = AM33XX_MPU_L2_RETSTATE_MASK, /* mpu_l2 */ + [2] = AM33XX_MPU_RAM_RETSTATE_MASK, /* mpu_ram */ + }, + .mem_pwrst_mask = { + [0] = AM33XX_MPU_L1_STATEST_MASK, /* mpu_l1 */ + [1] = AM33XX_MPU_L2_STATEST_MASK, /* mpu_l2 */ + [2] = AM33XX_MPU_RAM_STATEST_MASK, /* mpu_ram */ + }, + .mem_retst_mask = { + [0] = AM33XX_MPU_L1_RETSTATE_MASK, /* mpu_l1 */ + [1] = AM33XX_MPU_L2_RETSTATE_MASK, /* mpu_l2 */ + [2] = AM33XX_MPU_RAM_RETSTATE_MASK, /* mpu_ram */ + }, + .pwrsts_mem_ret = { + [0] = PWRSTS_OFF_RET, /* mpu_l1 */ + [1] = PWRSTS_OFF_RET, /* mpu_l2 */ + [2] = PWRSTS_OFF_RET, /* mpu_ram */ + }, + .pwrsts_mem_on = { + [0] = PWRSTS_ON, /* mpu_l1 */ + [1] = PWRSTS_ON, /* mpu_l2 */ + [2] = PWRSTS_ON, /* mpu_ram */ + }, +}; + +static struct powerdomain cefuse_33xx_pwrdm = { + .name = "cefuse_pwrdm", + .voltdm = { .name = "core" }, + .prcm_offs = AM33XX_PRM_CEFUSE_MOD, + .pwrstctrl_offs = AM33XX_PM_CEFUSE_PWRSTCTRL_OFFSET, + .pwrstst_offs = AM33XX_PM_CEFUSE_PWRSTST_OFFSET, + .pwrsts = PWRSTS_OFF_ON, +}; + +static struct powerdomain *powerdomains_am33xx[] __initdata = { + &gfx_33xx_pwrdm, + &rtc_33xx_pwrdm, + &wkup_33xx_pwrdm, + &per_33xx_pwrdm, + &mpu_33xx_pwrdm, + &cefuse_33xx_pwrdm, + NULL, +}; + +void __init am33xx_powerdomains_init(void) +{ + pwrdm_register_platform_funcs(&am33xx_pwrdm_operations); + pwrdm_register_pwrdms(powerdomains_am33xx); + pwrdm_complete_init(); +} diff --git a/arch/arm/mach-omap2/prm-regbits-33xx.h b/arch/arm/mach-omap2/prm-regbits-33xx.h new file mode 100644 index 0000000..0221b5c --- /dev/null +++ b/arch/arm/mach-omap2/prm-regbits-33xx.h @@ -0,0 +1,357 @@ +/* + * AM33XX PRM_XXX register bits + * + * Copyright (C) 2011-2012 Texas Instruments Incorporated - http://www.ti.com/ + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License as + * published by the Free Software Foundation version 2. + * + * This program is distributed "as is" WITHOUT ANY WARRANTY of any + * kind, whether express or implied; without even the implied warranty + * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + */ + +#ifndef __ARCH_ARM_MACH_OMAP2_PRM_REGBITS_33XX_H +#define __ARCH_ARM_MACH_OMAP2_PRM_REGBITS_33XX_H + +#include "prm.h" + +/* Used by PRM_LDO_SRAM_CORE_SETUP, PRM_LDO_SRAM_MPU_SETUP */ +#define AM33XX_ABBOFF_ACT_EXPORT_SHIFT 1 +#define AM33XX_ABBOFF_ACT_EXPORT_MASK (1 << 1) + +/* Used by PRM_LDO_SRAM_CORE_SETUP, PRM_LDO_SRAM_MPU_SETUP */ +#define AM33XX_ABBOFF_SLEEP_EXPORT_SHIFT 2 +#define AM33XX_ABBOFF_SLEEP_EXPORT_MASK (1 << 2) + +/* Used by PRM_LDO_SRAM_CORE_SETUP, PRM_LDO_SRAM_MPU_SETUP */ +#define AM33XX_AIPOFF_SHIFT 8 +#define AM33XX_AIPOFF_MASK (1 << 8) + +/* Used by PM_WKUP_PWRSTST */ +#define AM33XX_DEBUGSS_MEM_STATEST_SHIFT 17 +#define AM33XX_DEBUGSS_MEM_STATEST_MASK (0x3 << 17) + +/* Used by PRM_LDO_SRAM_CORE_SETUP, PRM_LDO_SRAM_MPU_SETUP */ +#define AM33XX_DISABLE_RTA_EXPORT_SHIFT 0 +#define AM33XX_DISABLE_RTA_EXPORT_MASK (1 << 0) + +/* Used by PRM_IRQENABLE_M3, PRM_IRQENABLE_MPU */ +#define AM33XX_DPLL_CORE_RECAL_EN_SHIFT 12 +#define AM33XX_DPLL_CORE_RECAL_EN_MASK (1 << 12) + +/* Used by PRM_IRQSTATUS_M3, PRM_IRQSTATUS_MPU */ +#define AM33XX_DPLL_CORE_RECAL_ST_SHIFT 12 +#define AM33XX_DPLL_CORE_RECAL_ST_MASK (1 << 12) + +/* Used by PRM_IRQENABLE_M3, PRM_IRQENABLE_MPU */ +#define AM33XX_DPLL_DDR_RECAL_EN_SHIFT 14 +#define AM33XX_DPLL_DDR_RECAL_EN_MASK (1 << 14) + +/* Used by PRM_IRQSTATUS_M3, PRM_IRQSTATUS_MPU */ +#define AM33XX_DPLL_DDR_RECAL_ST_SHIFT 14 +#define AM33XX_DPLL_DDR_RECAL_ST_MASK (1 << 14) + +/* Used by PRM_IRQENABLE_M3, PRM_IRQENABLE_MPU */ +#define AM33XX_DPLL_DISP_RECAL_EN_SHIFT 15 +#define AM33XX_DPLL_DISP_RECAL_EN_MASK (1 << 15) + +/* Used by PRM_IRQSTATUS_M3, PRM_IRQSTATUS_MPU */ +#define AM33XX_DPLL_DISP_RECAL_ST_SHIFT 13 +#define AM33XX_DPLL_DISP_RECAL_ST_MASK (1 << 13) + +/* Used by PRM_IRQENABLE_M3, PRM_IRQENABLE_MPU */ +#define AM33XX_DPLL_MPU_RECAL_EN_SHIFT 11 +#define AM33XX_DPLL_MPU_RECAL_EN_MASK (1 << 11) + +/* Used by PRM_IRQSTATUS_M3, PRM_IRQSTATUS_MPU */ +#define AM33XX_DPLL_MPU_RECAL_ST_SHIFT 11 +#define AM33XX_DPLL_MPU_RECAL_ST_MASK (1 << 11) + +/* Used by PRM_IRQENABLE_M3, PRM_IRQENABLE_MPU */ +#define AM33XX_DPLL_PER_RECAL_EN_SHIFT 13 +#define AM33XX_DPLL_PER_RECAL_EN_MASK (1 << 13) + +/* Used by PRM_IRQSTATUS_M3, PRM_IRQSTATUS_MPU */ +#define AM33XX_DPLL_PER_RECAL_ST_SHIFT 15 +#define AM33XX_DPLL_PER_RECAL_ST_MASK (1 << 15) + +/* Used by RM_WKUP_RSTST */ +#define AM33XX_EMULATION_M3_RST_SHIFT 6 +#define AM33XX_EMULATION_M3_RST_MASK (1 << 6) + +/* Used by RM_MPU_RSTST */ +#define AM33XX_EMULATION_MPU_RST_SHIFT 5 +#define AM33XX_EMULATION_MPU_RST_MASK (1 << 5) + +/* Used by PRM_LDO_SRAM_CORE_SETUP, PRM_LDO_SRAM_MPU_SETUP */ +#define AM33XX_ENFUNC1_EXPORT_SHIFT 3 +#define AM33XX_ENFUNC1_EXPORT_MASK (1 << 3) + +/* Used by PRM_LDO_SRAM_CORE_SETUP, PRM_LDO_SRAM_MPU_SETUP */ +#define AM33XX_ENFUNC3_EXPORT_SHIFT 5 +#define AM33XX_ENFUNC3_EXPORT_MASK (1 << 5) + +/* Used by PRM_LDO_SRAM_CORE_SETUP, PRM_LDO_SRAM_MPU_SETUP */ +#define AM33XX_ENFUNC4_SHIFT 6 +#define AM33XX_ENFUNC4_MASK (1 << 6) + +/* Used by PRM_LDO_SRAM_CORE_SETUP, PRM_LDO_SRAM_MPU_SETUP */ +#define AM33XX_ENFUNC5_SHIFT 7 +#define AM33XX_ENFUNC5_MASK (1 << 7) + +/* Used by PRM_RSTST */ +#define AM33XX_EXTERNAL_WARM_RST_SHIFT 5 +#define AM33XX_EXTERNAL_WARM_RST_MASK (1 << 5) + +/* Used by PRM_IRQENABLE_M3, PRM_IRQENABLE_MPU */ +#define AM33XX_FORCEWKUP_EN_SHIFT 10 +#define AM33XX_FORCEWKUP_EN_MASK (1 << 10) + +/* Used by PRM_IRQSTATUS_M3, PRM_IRQSTATUS_MPU */ +#define AM33XX_FORCEWKUP_ST_SHIFT 10 +#define AM33XX_FORCEWKUP_ST_MASK (1 << 10) + +/* Used by PM_GFX_PWRSTCTRL */ +#define AM33XX_GFX_MEM_ONSTATE_SHIFT 17 +#define AM33XX_GFX_MEM_ONSTATE_MASK (0x3 << 17) + +/* Used by PM_GFX_PWRSTCTRL */ +#define AM33XX_GFX_MEM_RETSTATE_SHIFT 6 +#define AM33XX_GFX_MEM_RETSTATE_MASK (1 << 6) + +/* Used by PM_GFX_PWRSTST */ +#define AM33XX_GFX_MEM_STATEST_SHIFT 4 +#define AM33XX_GFX_MEM_STATEST_MASK (0x3 << 4) + +/* Used by RM_GFX_RSTCTRL, RM_GFX_RSTST */ +#define AM33XX_GFX_RST_SHIFT 0 +#define AM33XX_GFX_RST_MASK (1 << 0) + +/* Used by PRM_RSTST */ +#define AM33XX_GLOBAL_COLD_RST_SHIFT 0 +#define AM33XX_GLOBAL_COLD_RST_MASK (1 << 0) + +/* Used by PRM_RSTST */ +#define AM33XX_GLOBAL_WARM_SW_RST_SHIFT 1 +#define AM33XX_GLOBAL_WARM_SW_RST_MASK (1 << 1) + +/* Used by RM_WKUP_RSTST */ +#define AM33XX_ICECRUSHER_M3_RST_SHIFT 7 +#define AM33XX_ICECRUSHER_M3_RST_MASK (1 << 7) + +/* Used by RM_MPU_RSTST */ +#define AM33XX_ICECRUSHER_MPU_RST_SHIFT 6 +#define AM33XX_ICECRUSHER_MPU_RST_MASK (1 << 6) + +/* Used by PRM_RSTST */ +#define AM33XX_ICEPICK_RST_SHIFT 9 +#define AM33XX_ICEPICK_RST_MASK (1 << 9) + +/* Used by RM_PER_RSTCTRL */ +#define AM33XX_PRUSS_LRST_SHIFT 1 +#define AM33XX_PRUSS_LRST_MASK (1 << 1) + +/* Used by PM_PER_PWRSTCTRL */ +#define AM33XX_PRUSS_MEM_ONSTATE_SHIFT 5 +#define AM33XX_PRUSS_MEM_ONSTATE_MASK (0x3 << 5) + +/* Used by PM_PER_PWRSTCTRL */ +#define AM33XX_PRUSS_MEM_RETSTATE_SHIFT 7 +#define AM33XX_PRUSS_MEM_RETSTATE_MASK (1 << 7) + +/* Used by PM_PER_PWRSTST */ +#define AM33XX_PRUSS_MEM_STATEST_SHIFT 23 +#define AM33XX_PRUSS_MEM_STATEST_MASK (0x3 << 23) + +/* + * Used by PM_GFX_PWRSTST, PM_CEFUSE_PWRSTST, PM_PER_PWRSTST, PM_MPU_PWRSTST, + * PM_WKUP_PWRSTST, PM_RTC_PWRSTST + */ +#define AM33XX_INTRANSITION_SHIFT 20 +#define AM33XX_INTRANSITION_MASK (1 << 20) + +/* Used by PM_CEFUSE_PWRSTST */ +#define AM33XX_LASTPOWERSTATEENTERED_SHIFT 24 +#define AM33XX_LASTPOWERSTATEENTERED_MASK (0x3 << 24) + +/* Used by PM_GFX_PWRSTCTRL, PM_MPU_PWRSTCTRL, PM_RTC_PWRSTCTRL */ +#define AM33XX_LOGICRETSTATE_SHIFT 2 +#define AM33XX_LOGICRETSTATE_MASK (1 << 2) + +/* Renamed from LOGICRETSTATE Used by PM_PER_PWRSTCTRL, PM_WKUP_PWRSTCTRL */ +#define AM33XX_LOGICRETSTATE_3_3_SHIFT 3 +#define AM33XX_LOGICRETSTATE_3_3_MASK (1 << 3) + +/* + * Used by PM_GFX_PWRSTST, PM_CEFUSE_PWRSTST, PM_PER_PWRSTST, PM_MPU_PWRSTST, + * PM_WKUP_PWRSTST, PM_RTC_PWRSTST + */ +#define AM33XX_LOGICSTATEST_SHIFT 2 +#define AM33XX_LOGICSTATEST_MASK (1 << 2) + +/* + * Used by PM_GFX_PWRSTCTRL, PM_CEFUSE_PWRSTCTRL, PM_PER_PWRSTCTRL, + * PM_MPU_PWRSTCTRL, PM_WKUP_PWRSTCTRL, PM_RTC_PWRSTCTRL + */ +#define AM33XX_LOWPOWERSTATECHANGE_SHIFT 4 +#define AM33XX_LOWPOWERSTATECHANGE_MASK (1 << 4) + +/* Used by PM_MPU_PWRSTCTRL */ +#define AM33XX_MPU_L1_ONSTATE_SHIFT 18 +#define AM33XX_MPU_L1_ONSTATE_MASK (0x3 << 18) + +/* Used by PM_MPU_PWRSTCTRL */ +#define AM33XX_MPU_L1_RETSTATE_SHIFT 22 +#define AM33XX_MPU_L1_RETSTATE_MASK (1 << 22) + +/* Used by PM_MPU_PWRSTST */ +#define AM33XX_MPU_L1_STATEST_SHIFT 6 +#define AM33XX_MPU_L1_STATEST_MASK (0x3 << 6) + +/* Used by PM_MPU_PWRSTCTRL */ +#define AM33XX_MPU_L2_ONSTATE_SHIFT 20 +#define AM33XX_MPU_L2_ONSTATE_MASK (0x3 << 20) + +/* Used by PM_MPU_PWRSTCTRL */ +#define AM33XX_MPU_L2_RETSTATE_SHIFT 23 +#define AM33XX_MPU_L2_RETSTATE_MASK (1 << 23) + +/* Used by PM_MPU_PWRSTST */ +#define AM33XX_MPU_L2_STATEST_SHIFT 8 +#define AM33XX_MPU_L2_STATEST_MASK (0x3 << 8) + +/* Used by PM_MPU_PWRSTCTRL */ +#define AM33XX_MPU_RAM_ONSTATE_SHIFT 16 +#define AM33XX_MPU_RAM_ONSTATE_MASK (0x3 << 16) + +/* Used by PM_MPU_PWRSTCTRL */ +#define AM33XX_MPU_RAM_RETSTATE_SHIFT 24 +#define AM33XX_MPU_RAM_RETSTATE_MASK (1 << 24) + +/* Used by PM_MPU_PWRSTST */ +#define AM33XX_MPU_RAM_STATEST_SHIFT 4 +#define AM33XX_MPU_RAM_STATEST_MASK (0x3 << 4) + +/* Used by PRM_RSTST */ +#define AM33XX_MPU_SECURITY_VIOL_RST_SHIFT 2 +#define AM33XX_MPU_SECURITY_VIOL_RST_MASK (1 << 2) + +/* Used by PRM_SRAM_COUNT */ +#define AM33XX_PCHARGECNT_VALUE_SHIFT 0 +#define AM33XX_PCHARGECNT_VALUE_MASK (0x3f << 0) + +/* Used by RM_PER_RSTCTRL */ +#define AM33XX_PCI_LRST_SHIFT 0 +#define AM33XX_PCI_LRST_MASK (1 << 0) + +/* Renamed from PCI_LRST Used by RM_PER_RSTST */ +#define AM33XX_PCI_LRST_5_5_SHIFT 5 +#define AM33XX_PCI_LRST_5_5_MASK (1 << 5) + +/* Used by PM_PER_PWRSTCTRL */ +#define AM33XX_PER_MEM_ONSTATE_SHIFT 25 +#define AM33XX_PER_MEM_ONSTATE_MASK (0x3 << 25) + +/* Used by PM_PER_PWRSTCTRL */ +#define AM33XX_PER_MEM_RETSTATE_SHIFT 29 +#define AM33XX_PER_MEM_RETSTATE_MASK (1 << 29) + +/* Used by PM_PER_PWRSTST */ +#define AM33XX_PER_MEM_STATEST_SHIFT 17 +#define AM33XX_PER_MEM_STATEST_MASK (0x3 << 17) + +/* + * Used by PM_GFX_PWRSTCTRL, PM_CEFUSE_PWRSTCTRL, PM_PER_PWRSTCTRL, + * PM_MPU_PWRSTCTRL + */ +#define AM33XX_POWERSTATE_SHIFT 0 +#define AM33XX_POWERSTATE_MASK (0x3 << 0) + +/* Used by PM_GFX_PWRSTST, PM_CEFUSE_PWRSTST, PM_PER_PWRSTST, PM_MPU_PWRSTST */ +#define AM33XX_POWERSTATEST_SHIFT 0 +#define AM33XX_POWERSTATEST_MASK (0x3 << 0) + +/* Used by PM_PER_PWRSTCTRL */ +#define AM33XX_RAM_MEM_ONSTATE_SHIFT 30 +#define AM33XX_RAM_MEM_ONSTATE_MASK (0x3 << 30) + +/* Used by PM_PER_PWRSTCTRL */ +#define AM33XX_RAM_MEM_RETSTATE_SHIFT 27 +#define AM33XX_RAM_MEM_RETSTATE_MASK (1 << 27) + +/* Used by PM_PER_PWRSTST */ +#define AM33XX_RAM_MEM_STATEST_SHIFT 21 +#define AM33XX_RAM_MEM_STATEST_MASK (0x3 << 21) + +/* Used by PRM_LDO_SRAM_CORE_CTRL, PRM_LDO_SRAM_MPU_CTRL */ +#define AM33XX_RETMODE_ENABLE_SHIFT 0 +#define AM33XX_RETMODE_ENABLE_MASK (1 << 0) + +/* Used by REVISION_PRM */ +#define AM33XX_REV_SHIFT 0 +#define AM33XX_REV_MASK (0xff << 0) + +/* Used by PRM_RSTTIME */ +#define AM33XX_RSTTIME1_SHIFT 0 +#define AM33XX_RSTTIME1_MASK (0xff << 0) + +/* Used by PRM_RSTTIME */ +#define AM33XX_RSTTIME2_SHIFT 8 +#define AM33XX_RSTTIME2_MASK (0x1f << 8) + +/* Used by PRM_RSTCTRL */ +#define AM33XX_RST_GLOBAL_COLD_SW_SHIFT 1 +#define AM33XX_RST_GLOBAL_COLD_SW_MASK (1 << 1) + +/* Used by PRM_RSTCTRL */ +#define AM33XX_RST_GLOBAL_WARM_SW_SHIFT 0 +#define AM33XX_RST_GLOBAL_WARM_SW_MASK (1 << 0) + +/* Used by PRM_SRAM_COUNT */ +#define AM33XX_SLPCNT_VALUE_SHIFT 16 +#define AM33XX_SLPCNT_VALUE_MASK (0xff << 16) + +/* Used by PRM_LDO_SRAM_CORE_CTRL, PRM_LDO_SRAM_MPU_CTRL */ +#define AM33XX_SRAMLDO_STATUS_SHIFT 8 +#define AM33XX_SRAMLDO_STATUS_MASK (1 << 8) + +/* Used by PRM_LDO_SRAM_CORE_CTRL, PRM_LDO_SRAM_MPU_CTRL */ +#define AM33XX_SRAM_IN_TRANSITION_SHIFT 9 +#define AM33XX_SRAM_IN_TRANSITION_MASK (1 << 9) + +/* Used by PRM_SRAM_COUNT */ +#define AM33XX_STARTUP_COUNT_SHIFT 24 +#define AM33XX_STARTUP_COUNT_MASK (0xff << 24) + +/* Used by PRM_IRQENABLE_M3, PRM_IRQENABLE_MPU */ +#define AM33XX_TRANSITION_EN_SHIFT 8 +#define AM33XX_TRANSITION_EN_MASK (1 << 8) + +/* Used by PRM_IRQSTATUS_M3, PRM_IRQSTATUS_MPU */ +#define AM33XX_TRANSITION_ST_SHIFT 8 +#define AM33XX_TRANSITION_ST_MASK (1 << 8) + +/* Used by PRM_SRAM_COUNT */ +#define AM33XX_VSETUPCNT_VALUE_SHIFT 8 +#define AM33XX_VSETUPCNT_VALUE_MASK (0xff << 8) + +/* Used by PRM_RSTST */ +#define AM33XX_WDT0_RST_SHIFT 3 +#define AM33XX_WDT0_RST_MASK (1 << 3) + +/* Used by PRM_RSTST */ +#define AM33XX_WDT1_RST_SHIFT 4 +#define AM33XX_WDT1_RST_MASK (1 << 4) + +/* Used by RM_WKUP_RSTCTRL */ +#define AM33XX_WKUP_M3_LRST_SHIFT 3 +#define AM33XX_WKUP_M3_LRST_MASK (1 << 3) + +/* Renamed from WKUP_M3_LRST Used by RM_WKUP_RSTST */ +#define AM33XX_WKUP_M3_LRST_5_5_SHIFT 5 +#define AM33XX_WKUP_M3_LRST_5_5_MASK (1 << 5) + +#endif diff --git a/arch/arm/mach-omap2/prm33xx.c b/arch/arm/mach-omap2/prm33xx.c new file mode 100644 index 0000000..7444855 --- /dev/null +++ b/arch/arm/mach-omap2/prm33xx.c @@ -0,0 +1,134 @@ +/* + * AM33XX PRM functions + * + * Copyright (C) 2011-2012 Texas Instruments Incorporated - http://www.ti.com/ + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License as + * published by the Free Software Foundation version 2. + * + * This program is distributed "as is" WITHOUT ANY WARRANTY of any + * kind, whether express or implied; without even the implied warranty + * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + */ + +#include <linux/kernel.h> +#include <linux/types.h> +#include <linux/errno.h> +#include <linux/err.h> +#include <linux/io.h> + +#include <plat/common.h> + +#include "common.h" +#include "prm33xx.h" +#include "prm-regbits-33xx.h" + +/* Read a register in a PRM instance */ +u32 am33xx_prm_read_reg(s16 inst, u16 idx) +{ + return __raw_readl(prm_base + inst + idx); +} + +/* Write into a register in a PRM instance */ +void am33xx_prm_write_reg(u32 val, s16 inst, u16 idx) +{ + __raw_writel(val, prm_base + inst + idx); +} + +/* Read-modify-write a register in PRM. Caller must lock */ +u32 am33xx_prm_rmw_reg_bits(u32 mask, u32 bits, s16 inst, s16 idx) +{ + u32 v; + + v = am33xx_prm_read_reg(inst, idx); + v &= ~mask; + v |= bits; + am33xx_prm_write_reg(v, inst, idx); + + return v; +} + +/** + * am33xx_prm_is_hardreset_asserted - read the HW reset line state of + * submodules contained in the hwmod module + * @shift: register bit shift corresponding to the reset line to check + * @inst: CM instance register offset (*_INST macro) + * @rstctrl_offs: RM_RSTCTRL register address offset for this module + * + * Returns 1 if the (sub)module hardreset line is currently asserted, + * 0 if the (sub)module hardreset line is not currently asserted, or + * -EINVAL upon parameter error. + */ +int am33xx_prm_is_hardreset_asserted(u8 shift, s16 inst, u16 rstctrl_offs) +{ + u32 v; + + v = am33xx_prm_read_reg(inst, rstctrl_offs); + v &= 1 << shift; + v >>= shift; + + return v; +} + +/** + * am33xx_prm_assert_hardreset - assert the HW reset line of a submodule + * @shift: register bit shift corresponding to the reset line to assert + * @inst: CM instance register offset (*_INST macro) + * @rstctrl_reg: RM_RSTCTRL register address for this module + * + * Some IPs like dsp, ipu or iva contain processors that require an HW + * reset line to be asserted / deasserted in order to fully enable the + * IP. These modules may have multiple hard-reset lines that reset + * different 'submodules' inside the IP block. This function will + * place the submodule into reset. Returns 0 upon success or -EINVAL + * upon an argument error. + */ +int am33xx_prm_assert_hardreset(u8 shift, s16 inst, u16 rstctrl_offs) +{ + u32 mask = 1 << shift; + + am33xx_prm_rmw_reg_bits(mask, mask, inst, rstctrl_offs); + + return 0; +} + +/** + * am33xx_prm_deassert_hardreset - deassert a submodule hardreset line and + * wait + * @shift: register bit shift corresponding to the reset line to deassert + * @inst: CM instance register offset (*_INST macro) + * @rstctrl_reg: RM_RSTCTRL register address for this module + * @rstst_reg: RM_RSTST register address for this module + * + * Some IPs like dsp, ipu or iva contain processors that require an HW + * reset line to be asserted / deasserted in order to fully enable the + * IP. These modules may have multiple hard-reset lines that reset + * different 'submodules' inside the IP block. This function will + * take the submodule out of reset and wait until the PRCM indicates + * that the reset has completed before returning. Returns 0 upon success or + * -EINVAL upon an argument error, -EEXIST if the submodule was already out + * of reset, or -EBUSY if the submodule did not exit reset promptly. + */ +int am33xx_prm_deassert_hardreset(u8 shift, s16 inst, + u16 rstctrl_offs, u16 rstst_offs) +{ + int c; + u32 mask = 1 << shift; + + /* Check the current status to avoid de-asserting the line twice */ + if (am33xx_prm_is_hardreset_asserted(shift, inst, rstctrl_offs) == 0) + return -EEXIST; + + /* Clear the reset status by writing 1 to the status bit */ + am33xx_prm_rmw_reg_bits(0xffffffff, mask, inst, rstst_offs); + /* de-assert the reset control line */ + am33xx_prm_rmw_reg_bits(mask, 0, inst, rstctrl_offs); + /* wait the status to be set */ + + omap_test_timeout(am33xx_prm_is_hardreset_asserted(shift, inst, + rstst_offs), MAX_MODULE_HARDRESET_WAIT, c); + + return (c == MAX_MODULE_HARDRESET_WAIT) ? -EBUSY : 0; +} diff --git a/arch/arm/mach-omap2/prm33xx.h b/arch/arm/mach-omap2/prm33xx.h new file mode 100644 index 0000000..3f25c56 --- /dev/null +++ b/arch/arm/mach-omap2/prm33xx.h @@ -0,0 +1,129 @@ +/* + * AM33XX PRM instance offset macros + * + * Copyright (C) 2011-2012 Texas Instruments Incorporated - http://www.ti.com/ + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License as + * published by the Free Software Foundation version 2. + * + * This program is distributed "as is" WITHOUT ANY WARRANTY of any + * kind, whether express or implied; without even the implied warranty + * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + */ + +#ifndef __ARCH_ARM_MACH_OMAP2_PRM33XX_H +#define __ARCH_ARM_MACH_OMAP2_PRM33XX_H + +#include "prcm-common.h" +#include "prm.h" + +#define AM33XX_PRM_BASE 0x44E00000 + +#define AM33XX_PRM_REGADDR(inst, reg) \ + AM33XX_L4_WK_IO_ADDRESS(AM33XX_PRM_BASE + (inst) + (reg)) + + +/* PRM instances */ +#define AM33XX_PRM_OCP_SOCKET_MOD 0x0B00 +#define AM33XX_PRM_PER_MOD 0x0C00 +#define AM33XX_PRM_WKUP_MOD 0x0D00 +#define AM33XX_PRM_MPU_MOD 0x0E00 +#define AM33XX_PRM_DEVICE_MOD 0x0F00 +#define AM33XX_PRM_RTC_MOD 0x1000 +#define AM33XX_PRM_GFX_MOD 0x1100 +#define AM33XX_PRM_CEFUSE_MOD 0x1200 + +/* PRM */ + +/* PRM.OCP_SOCKET_PRM register offsets */ +#define AM33XX_REVISION_PRM_OFFSET 0x0000 +#define AM33XX_REVISION_PRM AM33XX_PRM_REGADDR(AM33XX_PRM_OCP_SOCKET_MOD, 0x0000) +#define AM33XX_PRM_IRQSTATUS_MPU_OFFSET 0x0004 +#define AM33XX_PRM_IRQSTATUS_MPU AM33XX_PRM_REGADDR(AM33XX_PRM_OCP_SOCKET_MOD, 0x0004) +#define AM33XX_PRM_IRQENABLE_MPU_OFFSET 0x0008 +#define AM33XX_PRM_IRQENABLE_MPU AM33XX_PRM_REGADDR(AM33XX_PRM_OCP_SOCKET_MOD, 0x0008) +#define AM33XX_PRM_IRQSTATUS_M3_OFFSET 0x000c +#define AM33XX_PRM_IRQSTATUS_M3 AM33XX_PRM_REGADDR(AM33XX_PRM_OCP_SOCKET_MOD, 0x000c) +#define AM33XX_PRM_IRQENABLE_M3_OFFSET 0x0010 +#define AM33XX_PRM_IRQENABLE_M3 AM33XX_PRM_REGADDR(AM33XX_PRM_OCP_SOCKET_MOD, 0x0010) + +/* PRM.PER_PRM register offsets */ +#define AM33XX_RM_PER_RSTCTRL_OFFSET 0x0000 +#define AM33XX_RM_PER_RSTCTRL AM33XX_PRM_REGADDR(AM33XX_PRM_PER_MOD, 0x0000) +#define AM33XX_RM_PER_RSTST_OFFSET 0x0004 +#define AM33XX_RM_PER_RSTST AM33XX_PRM_REGADDR(AM33XX_PRM_PER_MOD, 0x0004) +#define AM33XX_PM_PER_PWRSTST_OFFSET 0x0008 +#define AM33XX_PM_PER_PWRSTST AM33XX_PRM_REGADDR(AM33XX_PRM_PER_MOD, 0x0008) +#define AM33XX_PM_PER_PWRSTCTRL_OFFSET 0x000c +#define AM33XX_PM_PER_PWRSTCTRL AM33XX_PRM_REGADDR(AM33XX_PRM_PER_MOD, 0x000c) + +/* PRM.WKUP_PRM register offsets */ +#define AM33XX_RM_WKUP_RSTCTRL_OFFSET 0x0000 +#define AM33XX_RM_WKUP_RSTCTRL AM33XX_PRM_REGADDR(AM33XX_PRM_WKUP_MOD, 0x0000) +#define AM33XX_PM_WKUP_PWRSTCTRL_OFFSET 0x0004 +#define AM33XX_PM_WKUP_PWRSTCTRL AM33XX_PRM_REGADDR(AM33XX_PRM_WKUP_MOD, 0x0004) +#define AM33XX_PM_WKUP_PWRSTST_OFFSET 0x0008 +#define AM33XX_PM_WKUP_PWRSTST AM33XX_PRM_REGADDR(AM33XX_PRM_WKUP_MOD, 0x0008) +#define AM33XX_RM_WKUP_RSTST_OFFSET 0x000c +#define AM33XX_RM_WKUP_RSTST AM33XX_PRM_REGADDR(AM33XX_PRM_WKUP_MOD, 0x000c) + +/* PRM.MPU_PRM register offsets */ +#define AM33XX_PM_MPU_PWRSTCTRL_OFFSET 0x0000 +#define AM33XX_PM_MPU_PWRSTCTRL AM33XX_PRM_REGADDR(AM33XX_PRM_MPU_MOD, 0x0000) +#define AM33XX_PM_MPU_PWRSTST_OFFSET 0x0004 +#define AM33XX_PM_MPU_PWRSTST AM33XX_PRM_REGADDR(AM33XX_PRM_MPU_MOD, 0x0004) +#define AM33XX_RM_MPU_RSTST_OFFSET 0x0008 +#define AM33XX_RM_MPU_RSTST AM33XX_PRM_REGADDR(AM33XX_PRM_MPU_MOD, 0x0008) + +/* PRM.DEVICE_PRM register offsets */ +#define AM33XX_PRM_RSTCTRL_OFFSET 0x0000 +#define AM33XX_PRM_RSTCTRL AM33XX_PRM_REGADDR(AM33XX_PRM_DEVICE_MOD, 0x0000) +#define AM33XX_PRM_RSTTIME_OFFSET 0x0004 +#define AM33XX_PRM_RSTTIME AM33XX_PRM_REGADDR(AM33XX_PRM_DEVICE_MOD, 0x0004) +#define AM33XX_PRM_RSTST_OFFSET 0x0008 +#define AM33XX_PRM_RSTST AM33XX_PRM_REGADDR(AM33XX_PRM_DEVICE_MOD, 0x0008) +#define AM33XX_PRM_SRAM_COUNT_OFFSET 0x000c +#define AM33XX_PRM_SRAM_COUNT AM33XX_PRM_REGADDR(AM33XX_PRM_DEVICE_MOD, 0x000c) +#define AM33XX_PRM_LDO_SRAM_CORE_SETUP_OFFSET 0x0010 +#define AM33XX_PRM_LDO_SRAM_CORE_SETUP AM33XX_PRM_REGADDR(AM33XX_PRM_DEVICE_MOD, 0x0010) +#define AM33XX_PRM_LDO_SRAM_CORE_CTRL_OFFSET 0x0014 +#define AM33XX_PRM_LDO_SRAM_CORE_CTRL AM33XX_PRM_REGADDR(AM33XX_PRM_DEVICE_MOD, 0x0014) +#define AM33XX_PRM_LDO_SRAM_MPU_SETUP_OFFSET 0x0018 +#define AM33XX_PRM_LDO_SRAM_MPU_SETUP AM33XX_PRM_REGADDR(AM33XX_PRM_DEVICE_MOD, 0x0018) +#define AM33XX_PRM_LDO_SRAM_MPU_CTRL_OFFSET 0x001c +#define AM33XX_PRM_LDO_SRAM_MPU_CTRL AM33XX_PRM_REGADDR(AM33XX_PRM_DEVICE_MOD, 0x001c) + +/* PRM.RTC_PRM register offsets */ +#define AM33XX_PM_RTC_PWRSTCTRL_OFFSET 0x0000 +#define AM33XX_PM_RTC_PWRSTCTRL AM33XX_PRM_REGADDR(AM33XX_PRM_RTC_MOD, 0x0000) +#define AM33XX_PM_RTC_PWRSTST_OFFSET 0x0004 +#define AM33XX_PM_RTC_PWRSTST AM33XX_PRM_REGADDR(AM33XX_PRM_RTC_MOD, 0x0004) + +/* PRM.GFX_PRM register offsets */ +#define AM33XX_PM_GFX_PWRSTCTRL_OFFSET 0x0000 +#define AM33XX_PM_GFX_PWRSTCTRL AM33XX_PRM_REGADDR(AM33XX_PRM_GFX_MOD, 0x0000) +#define AM33XX_RM_GFX_RSTCTRL_OFFSET 0x0004 +#define AM33XX_RM_GFX_RSTCTRL AM33XX_PRM_REGADDR(AM33XX_PRM_GFX_MOD, 0x0004) +#define AM33XX_PM_GFX_PWRSTST_OFFSET 0x0010 +#define AM33XX_PM_GFX_PWRSTST AM33XX_PRM_REGADDR(AM33XX_PRM_GFX_MOD, 0x0010) +#define AM33XX_RM_GFX_RSTST_OFFSET 0x0014 +#define AM33XX_RM_GFX_RSTST AM33XX_PRM_REGADDR(AM33XX_PRM_GFX_MOD, 0x0014) + +/* PRM.CEFUSE_PRM register offsets */ +#define AM33XX_PM_CEFUSE_PWRSTCTRL_OFFSET 0x0000 +#define AM33XX_PM_CEFUSE_PWRSTCTRL AM33XX_PRM_REGADDR(AM33XX_PRM_CEFUSE_MOD, 0x0000) +#define AM33XX_PM_CEFUSE_PWRSTST_OFFSET 0x0004 +#define AM33XX_PM_CEFUSE_PWRSTST AM33XX_PRM_REGADDR(AM33XX_PRM_CEFUSE_MOD, 0x0004) + +extern u32 am33xx_prm_read_reg(s16 inst, u16 idx); +extern void am33xx_prm_write_reg(u32 val, s16 inst, u16 idx); +extern u32 am33xx_prm_rmw_reg_bits(u32 mask, u32 bits, s16 inst, s16 idx); +extern void am33xx_prm_global_warm_sw_reset(void); +extern int am33xx_prm_is_hardreset_asserted(u8 shift, s16 inst, + u16 rstctrl_offs); +extern int am33xx_prm_assert_hardreset(u8 shift, s16 inst, u16 rstctrl_offs); +extern int am33xx_prm_deassert_hardreset(u8 shift, s16 inst, + u16 rstctrl_offs, u16 rstst_offs); +#endif -- 1.7.0.4 ^ permalink raw reply related [flat|nested] 64+ messages in thread
* [PATCH-V4 4/4] ARM: OMAP3+: am33xx: Add powerdomain & PRM support @ 2012-03-30 16:03 ` Vaibhav Hiremath 0 siblings, 0 replies; 64+ messages in thread From: Vaibhav Hiremath @ 2012-03-30 16:03 UTC (permalink / raw) To: linux-arm-kernel 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. Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com> Signed-off-by: Afzal Mohammed <afzal@ti.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Kevin Hilman <khilman@ti.com> Cc: Paul Walmsley <paul@pwsan.com> Cc: Rajendra Nayak <rnayak@ti.com> --- 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 diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile index 8d90f9f..8220369 100644 --- a/arch/arm/mach-omap2/Makefile +++ b/arch/arm/mach-omap2/Makefile @@ -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 diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c index 523fb6d..b8fd170 100644 --- a/arch/arm/mach-omap2/io.c +++ b/arch/arm/mach-omap2/io.c @@ -467,6 +467,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 diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c index 5192cab..97b47f2 100644 --- a/arch/arm/mach-omap2/omap_hwmod.c +++ b/arch/arm/mach-omap2/omap_hwmod.c @@ -150,6 +150,7 @@ #include "cminst44xx.h" #include "prm2xxx_3xxx.h" #include "prm44xx.h" +#include "prm33xx.h" #include "prminst44xx.h" #include "mux.h" @@ -1288,7 +1289,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()) @@ -1322,7 +1331,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); @@ -1364,7 +1382,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()) { diff --git a/arch/arm/mach-omap2/powerdomain.h b/arch/arm/mach-omap2/powerdomain.h index 8fc50b2..53e42a9 100644 --- a/arch/arm/mach-omap2/powerdomain.h +++ b/arch/arm/mach-omap2/powerdomain.h @@ -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 */ diff --git a/arch/arm/mach-omap2/powerdomain33xx.c b/arch/arm/mach-omap2/powerdomain33xx.c new file mode 100644 index 0000000..c53f8d8 --- /dev/null +++ b/arch/arm/mach-omap2/powerdomain33xx.c @@ -0,0 +1,230 @@ +/* + * AM33XX Powerdomain control + * + * Copyright (C) 2011-2012 Texas Instruments Incorporated - http://www.ti.com/ + * + * Derived from mach-omap2/powerdomain44xx.c written by Rajendra Nayak + * <rnayak@ti.com> + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License as + * published by the Free Software Foundation version 2. + * + * This program is distributed "as is" WITHOUT ANY WARRANTY of any + * kind, whether express or implied; without even the implied warranty + * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + */ + +#include <linux/io.h> +#include <linux/errno.h> +#include <linux/delay.h> + +#include <plat/prcm.h> + +#include "powerdomain.h" +#include "prm33xx.h" +#include "prm-regbits-33xx.h" + + +static int am33xx_pwrdm_set_next_pwrst(struct powerdomain *pwrdm, u8 pwrst) +{ + am33xx_prm_rmw_reg_bits(OMAP_POWERSTATE_MASK, + (pwrst << OMAP_POWERSTATE_SHIFT), + pwrdm->prcm_offs, pwrdm->pwrstctrl_offs); + return 0; +} + +static int am33xx_pwrdm_read_next_pwrst(struct powerdomain *pwrdm) +{ + u32 v; + + v = am33xx_prm_read_reg(pwrdm->prcm_offs, pwrdm->pwrstctrl_offs); + v &= OMAP_POWERSTATE_MASK; + v >>= OMAP_POWERSTATE_SHIFT; + + return v; +} + +static int am33xx_pwrdm_read_pwrst(struct powerdomain *pwrdm) +{ + u32 v; + + v = am33xx_prm_read_reg(pwrdm->prcm_offs, pwrdm->pwrstst_offs); + v &= OMAP_POWERSTATEST_MASK; + v >>= OMAP_POWERSTATEST_SHIFT; + + return v; +} + +static int am33xx_pwrdm_read_prev_pwrst(struct powerdomain *pwrdm) +{ + u32 v; + + v = am33xx_prm_read_reg(pwrdm->prcm_offs, pwrdm->pwrstst_offs); + v &= AM33XX_LASTPOWERSTATEENTERED_MASK; + v >>= AM33XX_LASTPOWERSTATEENTERED_SHIFT; + + return v; +} + +static int am33xx_pwrdm_set_lowpwrstchange(struct powerdomain *pwrdm) +{ + am33xx_prm_rmw_reg_bits(AM33XX_LOWPOWERSTATECHANGE_MASK, + (1 << AM33XX_LOWPOWERSTATECHANGE_SHIFT), + pwrdm->prcm_offs, pwrdm->pwrstctrl_offs); + return 0; +} + +static int am33xx_pwrdm_clear_all_prev_pwrst(struct powerdomain *pwrdm) +{ + am33xx_prm_rmw_reg_bits(AM33XX_LASTPOWERSTATEENTERED_MASK, + AM33XX_LASTPOWERSTATEENTERED_MASK, + pwrdm->prcm_offs, pwrdm->pwrstst_offs); + return 0; +} + +static int am33xx_pwrdm_set_logic_retst(struct powerdomain *pwrdm, u8 pwrst) +{ + u32 m; + + m = pwrdm->logicretstate_mask; + if (!m) + return -EINVAL; + + am33xx_prm_rmw_reg_bits(m, (pwrst << __ffs(m)), + pwrdm->prcm_offs, pwrdm->pwrstctrl_offs); + + return 0; +} + +static int am33xx_pwrdm_read_logic_pwrst(struct powerdomain *pwrdm) +{ + u32 v; + + v = am33xx_prm_read_reg(pwrdm->prcm_offs, pwrdm->pwrstst_offs); + v &= AM33XX_LOGICSTATEST_MASK; + v >>= AM33XX_LOGICSTATEST_SHIFT; + + return v; +} + +static int am33xx_pwrdm_read_logic_retst(struct powerdomain *pwrdm) +{ + u32 v, m; + + m = pwrdm->logicretstate_mask; + if (!m) + return -EINVAL; + + v = am33xx_prm_read_reg(pwrdm->prcm_offs, pwrdm->pwrstctrl_offs); + v &= m; + v >>= __ffs(m); + + return v; +} + +static int am33xx_pwrdm_set_mem_onst(struct powerdomain *pwrdm, u8 bank, + u8 pwrst) +{ + u32 m; + + m = pwrdm->mem_on_mask[bank]; + if (!m) + return -EINVAL; + + am33xx_prm_rmw_reg_bits(m, (pwrst << __ffs(m)), + pwrdm->prcm_offs, pwrdm->pwrstctrl_offs); + + return 0; +} + +static int am33xx_pwrdm_set_mem_retst(struct powerdomain *pwrdm, u8 bank, + u8 pwrst) +{ + u32 m; + + m = pwrdm->mem_ret_mask[bank]; + if (!m) + return -EINVAL; + + am33xx_prm_rmw_reg_bits(m, (pwrst << __ffs(m)), + pwrdm->prcm_offs, pwrdm->pwrstctrl_offs); + + return 0; +} + +static int am33xx_pwrdm_read_mem_pwrst(struct powerdomain *pwrdm, u8 bank) +{ + u32 m, v; + + m = pwrdm->mem_pwrst_mask[bank]; + if (!m) + return -EINVAL; + + v = am33xx_prm_read_reg(pwrdm->prcm_offs, pwrdm->pwrstst_offs); + v &= m; + v >>= __ffs(m); + + return v; +} + +static int am33xx_pwrdm_read_mem_retst(struct powerdomain *pwrdm, u8 bank) +{ + u32 m, v; + + m = pwrdm->mem_retst_mask[bank]; + if (!m) + return -EINVAL; + + v = am33xx_prm_read_reg(pwrdm->prcm_offs, pwrdm->pwrstctrl_offs); + v &= m; + v >>= __ffs(m); + + return v; +} + +static int am33xx_pwrdm_wait_transition(struct powerdomain *pwrdm) +{ + u32 c = 0; + + /* + * REVISIT: pwrdm_wait_transition() may be better implemented + * via a callback and a periodic timer check -- how long do we expect + * powerdomain transitions to take? + */ + + /* XXX Is this udelay() value meaningful? */ + while ((am33xx_prm_read_reg(pwrdm->prcm_offs, pwrdm->pwrstst_offs) + & OMAP_INTRANSITION_MASK) && + (c++ < PWRDM_TRANSITION_BAILOUT)) + udelay(1); + + if (c > PWRDM_TRANSITION_BAILOUT) { + printk(KERN_ERR "powerdomain: waited too long for " + "powerdomain %s to complete transition\n", + pwrdm->name); + return -EAGAIN; + } + + pr_debug("powerdomain: completed transition in %d loops\n", c); + + return 0; +} + +struct pwrdm_ops am33xx_pwrdm_operations = { + .pwrdm_set_next_pwrst = am33xx_pwrdm_set_next_pwrst, + .pwrdm_read_next_pwrst = am33xx_pwrdm_read_next_pwrst, + .pwrdm_read_pwrst = am33xx_pwrdm_read_pwrst, + .pwrdm_read_prev_pwrst = am33xx_pwrdm_read_prev_pwrst, + .pwrdm_set_logic_retst = am33xx_pwrdm_set_logic_retst, + .pwrdm_read_logic_pwrst = am33xx_pwrdm_read_logic_pwrst, + .pwrdm_read_logic_retst = am33xx_pwrdm_read_logic_retst, + .pwrdm_clear_all_prev_pwrst = am33xx_pwrdm_clear_all_prev_pwrst, + .pwrdm_set_lowpwrstchange = am33xx_pwrdm_set_lowpwrstchange, + .pwrdm_read_mem_pwrst = am33xx_pwrdm_read_mem_pwrst, + .pwrdm_read_mem_retst = am33xx_pwrdm_read_mem_retst, + .pwrdm_set_mem_onst = am33xx_pwrdm_set_mem_onst, + .pwrdm_set_mem_retst = am33xx_pwrdm_set_mem_retst, + .pwrdm_wait_transition = am33xx_pwrdm_wait_transition, +}; diff --git a/arch/arm/mach-omap2/powerdomains33xx_data.c b/arch/arm/mach-omap2/powerdomains33xx_data.c new file mode 100644 index 0000000..869adb8 --- /dev/null +++ b/arch/arm/mach-omap2/powerdomains33xx_data.c @@ -0,0 +1,185 @@ +/* + * AM33XX Power domain data + * + * Copyright (C) 2011-2012 Texas Instruments Incorporated - http://www.ti.com/ + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License as + * published by the Free Software Foundation version 2. + * + * This program is distributed "as is" WITHOUT ANY WARRANTY of any + * kind, whether express or implied; without even the implied warranty + * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + */ + +#include <linux/kernel.h> +#include <linux/init.h> + +#include "powerdomain.h" +#include "prcm-common.h" +#include "prm-regbits-33xx.h" +#include "prm33xx.h" + +static struct powerdomain gfx_33xx_pwrdm = { + .name = "gfx_pwrdm", + .voltdm = { .name = "core" }, + .prcm_offs = AM33XX_PRM_GFX_MOD, + .pwrstctrl_offs = AM33XX_PM_GFX_PWRSTCTRL_OFFSET, + .pwrstst_offs = AM33XX_PM_GFX_PWRSTST_OFFSET, + .pwrsts = PWRSTS_OFF_RET_ON, + .pwrsts_logic_ret = PWRSTS_OFF_RET, + .flags = PWRDM_HAS_LOWPOWERSTATECHANGE, + .banks = 1, + .logicretstate_mask = AM33XX_LOGICRETSTATE_MASK, + .mem_on_mask = { + [0] = AM33XX_GFX_MEM_ONSTATE_MASK, /* gfx_mem */ + }, + .mem_ret_mask = { + [0] = AM33XX_GFX_MEM_RETSTATE_MASK, /* gfx_mem */ + }, + .mem_pwrst_mask = { + [0] = AM33XX_GFX_MEM_STATEST_MASK, /* gfx_mem */ + }, + .mem_retst_mask = { + [0] = AM33XX_GFX_MEM_RETSTATE_MASK, /* gfx_mem */ + }, + .pwrsts_mem_ret = { + [0] = PWRSTS_OFF_RET, /* gfx_mem */ + }, + .pwrsts_mem_on = { + [0] = PWRSTS_ON, /* gfx_mem */ + }, +}; + +static struct powerdomain rtc_33xx_pwrdm = { + .name = "rtc_pwrdm", + .voltdm = { .name = "rtc" }, + .prcm_offs = AM33XX_PRM_RTC_MOD, + .pwrstctrl_offs = AM33XX_PM_RTC_PWRSTCTRL_OFFSET, + .pwrstst_offs = AM33XX_PM_RTC_PWRSTST_OFFSET, + .pwrsts = PWRSTS_ON, + .logicretstate_mask = AM33XX_LOGICRETSTATE_MASK, +}; + +static struct powerdomain wkup_33xx_pwrdm = { + .name = "wkup_pwrdm", + .voltdm = { .name = "core" }, + .prcm_offs = AM33XX_PRM_WKUP_MOD, + .pwrstctrl_offs = AM33XX_PM_WKUP_PWRSTCTRL_OFFSET, + .pwrstst_offs = AM33XX_PM_WKUP_PWRSTST_OFFSET, + .pwrsts = PWRSTS_ON, + .logicretstate_mask = AM33XX_LOGICRETSTATE_3_3_MASK, +}; + +static struct powerdomain per_33xx_pwrdm = { + .name = "per_pwrdm", + .voltdm = { .name = "core" }, + .prcm_offs = AM33XX_PRM_PER_MOD, + .pwrstctrl_offs = AM33XX_PM_PER_PWRSTCTRL_OFFSET, + .pwrstst_offs = AM33XX_PM_PER_PWRSTST_OFFSET, + .pwrsts = PWRSTS_OFF_RET_ON, + .pwrsts_logic_ret = PWRSTS_OFF_RET, + .flags = PWRDM_HAS_LOWPOWERSTATECHANGE, + .banks = 3, + .logicretstate_mask = AM33XX_LOGICRETSTATE_3_3_MASK, + .mem_on_mask = { + [0] = AM33XX_PRUSS_MEM_ONSTATE_MASK, /* pruss_mem */ + [1] = AM33XX_PER_MEM_ONSTATE_MASK, /* per_mem */ + [2] = AM33XX_RAM_MEM_ONSTATE_MASK, /* ram_mem */ + }, + .mem_ret_mask = { + [0] = AM33XX_PRUSS_MEM_RETSTATE_MASK, /* pruss_mem */ + [1] = AM33XX_PER_MEM_RETSTATE_MASK, /* per_mem */ + [2] = AM33XX_RAM_MEM_RETSTATE_MASK, /* ram_mem */ + }, + .mem_pwrst_mask = { + [0] = AM33XX_PRUSS_MEM_STATEST_MASK, /* pruss_mem */ + [1] = AM33XX_PER_MEM_STATEST_MASK, /* per_mem */ + [2] = AM33XX_RAM_MEM_STATEST_MASK, /* ram_mem */ + }, + .mem_retst_mask = { + [0] = AM33XX_PRUSS_MEM_RETSTATE_MASK, /* pruss_mem */ + [1] = AM33XX_PER_MEM_RETSTATE_MASK, /* per_mem */ + [2] = AM33XX_RAM_MEM_RETSTATE_MASK, /* ram_mem */ + }, + .pwrsts_mem_ret = { + [0] = PWRSTS_OFF_RET, /* pruss_mem */ + [1] = PWRSTS_OFF_RET, /* per_mem */ + [2] = PWRSTS_OFF_RET, /* ram_mem */ + }, + .pwrsts_mem_on = { + [0] = PWRSTS_ON, /* pruss_mem */ + [1] = PWRSTS_ON, /* per_mem */ + [2] = PWRSTS_ON, /* ram_mem */ + }, +}; + +static struct powerdomain mpu_33xx_pwrdm = { + .name = "mpu_pwrdm", + .voltdm = { .name = "mpu" }, + .prcm_offs = AM33XX_PRM_MPU_MOD, + .pwrstctrl_offs = AM33XX_PM_MPU_PWRSTCTRL_OFFSET, + .pwrstst_offs = AM33XX_PM_MPU_PWRSTST_OFFSET, + .pwrsts = PWRSTS_OFF_RET_ON, + .pwrsts_logic_ret = PWRSTS_OFF_RET, + .flags = PWRDM_HAS_LOWPOWERSTATECHANGE, + .banks = 3, + .logicretstate_mask = AM33XX_LOGICRETSTATE_MASK, + .mem_on_mask = { + [0] = AM33XX_MPU_L1_ONSTATE_MASK, /* mpu_l1 */ + [1] = AM33XX_MPU_L2_ONSTATE_MASK, /* mpu_l2 */ + [2] = AM33XX_MPU_RAM_ONSTATE_MASK, /* mpu_ram */ + }, + .mem_ret_mask = { + [0] = AM33XX_MPU_L1_RETSTATE_MASK, /* mpu_l1 */ + [1] = AM33XX_MPU_L2_RETSTATE_MASK, /* mpu_l2 */ + [2] = AM33XX_MPU_RAM_RETSTATE_MASK, /* mpu_ram */ + }, + .mem_pwrst_mask = { + [0] = AM33XX_MPU_L1_STATEST_MASK, /* mpu_l1 */ + [1] = AM33XX_MPU_L2_STATEST_MASK, /* mpu_l2 */ + [2] = AM33XX_MPU_RAM_STATEST_MASK, /* mpu_ram */ + }, + .mem_retst_mask = { + [0] = AM33XX_MPU_L1_RETSTATE_MASK, /* mpu_l1 */ + [1] = AM33XX_MPU_L2_RETSTATE_MASK, /* mpu_l2 */ + [2] = AM33XX_MPU_RAM_RETSTATE_MASK, /* mpu_ram */ + }, + .pwrsts_mem_ret = { + [0] = PWRSTS_OFF_RET, /* mpu_l1 */ + [1] = PWRSTS_OFF_RET, /* mpu_l2 */ + [2] = PWRSTS_OFF_RET, /* mpu_ram */ + }, + .pwrsts_mem_on = { + [0] = PWRSTS_ON, /* mpu_l1 */ + [1] = PWRSTS_ON, /* mpu_l2 */ + [2] = PWRSTS_ON, /* mpu_ram */ + }, +}; + +static struct powerdomain cefuse_33xx_pwrdm = { + .name = "cefuse_pwrdm", + .voltdm = { .name = "core" }, + .prcm_offs = AM33XX_PRM_CEFUSE_MOD, + .pwrstctrl_offs = AM33XX_PM_CEFUSE_PWRSTCTRL_OFFSET, + .pwrstst_offs = AM33XX_PM_CEFUSE_PWRSTST_OFFSET, + .pwrsts = PWRSTS_OFF_ON, +}; + +static struct powerdomain *powerdomains_am33xx[] __initdata = { + &gfx_33xx_pwrdm, + &rtc_33xx_pwrdm, + &wkup_33xx_pwrdm, + &per_33xx_pwrdm, + &mpu_33xx_pwrdm, + &cefuse_33xx_pwrdm, + NULL, +}; + +void __init am33xx_powerdomains_init(void) +{ + pwrdm_register_platform_funcs(&am33xx_pwrdm_operations); + pwrdm_register_pwrdms(powerdomains_am33xx); + pwrdm_complete_init(); +} diff --git a/arch/arm/mach-omap2/prm-regbits-33xx.h b/arch/arm/mach-omap2/prm-regbits-33xx.h new file mode 100644 index 0000000..0221b5c --- /dev/null +++ b/arch/arm/mach-omap2/prm-regbits-33xx.h @@ -0,0 +1,357 @@ +/* + * AM33XX PRM_XXX register bits + * + * Copyright (C) 2011-2012 Texas Instruments Incorporated - http://www.ti.com/ + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License as + * published by the Free Software Foundation version 2. + * + * This program is distributed "as is" WITHOUT ANY WARRANTY of any + * kind, whether express or implied; without even the implied warranty + * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + */ + +#ifndef __ARCH_ARM_MACH_OMAP2_PRM_REGBITS_33XX_H +#define __ARCH_ARM_MACH_OMAP2_PRM_REGBITS_33XX_H + +#include "prm.h" + +/* Used by PRM_LDO_SRAM_CORE_SETUP, PRM_LDO_SRAM_MPU_SETUP */ +#define AM33XX_ABBOFF_ACT_EXPORT_SHIFT 1 +#define AM33XX_ABBOFF_ACT_EXPORT_MASK (1 << 1) + +/* Used by PRM_LDO_SRAM_CORE_SETUP, PRM_LDO_SRAM_MPU_SETUP */ +#define AM33XX_ABBOFF_SLEEP_EXPORT_SHIFT 2 +#define AM33XX_ABBOFF_SLEEP_EXPORT_MASK (1 << 2) + +/* Used by PRM_LDO_SRAM_CORE_SETUP, PRM_LDO_SRAM_MPU_SETUP */ +#define AM33XX_AIPOFF_SHIFT 8 +#define AM33XX_AIPOFF_MASK (1 << 8) + +/* Used by PM_WKUP_PWRSTST */ +#define AM33XX_DEBUGSS_MEM_STATEST_SHIFT 17 +#define AM33XX_DEBUGSS_MEM_STATEST_MASK (0x3 << 17) + +/* Used by PRM_LDO_SRAM_CORE_SETUP, PRM_LDO_SRAM_MPU_SETUP */ +#define AM33XX_DISABLE_RTA_EXPORT_SHIFT 0 +#define AM33XX_DISABLE_RTA_EXPORT_MASK (1 << 0) + +/* Used by PRM_IRQENABLE_M3, PRM_IRQENABLE_MPU */ +#define AM33XX_DPLL_CORE_RECAL_EN_SHIFT 12 +#define AM33XX_DPLL_CORE_RECAL_EN_MASK (1 << 12) + +/* Used by PRM_IRQSTATUS_M3, PRM_IRQSTATUS_MPU */ +#define AM33XX_DPLL_CORE_RECAL_ST_SHIFT 12 +#define AM33XX_DPLL_CORE_RECAL_ST_MASK (1 << 12) + +/* Used by PRM_IRQENABLE_M3, PRM_IRQENABLE_MPU */ +#define AM33XX_DPLL_DDR_RECAL_EN_SHIFT 14 +#define AM33XX_DPLL_DDR_RECAL_EN_MASK (1 << 14) + +/* Used by PRM_IRQSTATUS_M3, PRM_IRQSTATUS_MPU */ +#define AM33XX_DPLL_DDR_RECAL_ST_SHIFT 14 +#define AM33XX_DPLL_DDR_RECAL_ST_MASK (1 << 14) + +/* Used by PRM_IRQENABLE_M3, PRM_IRQENABLE_MPU */ +#define AM33XX_DPLL_DISP_RECAL_EN_SHIFT 15 +#define AM33XX_DPLL_DISP_RECAL_EN_MASK (1 << 15) + +/* Used by PRM_IRQSTATUS_M3, PRM_IRQSTATUS_MPU */ +#define AM33XX_DPLL_DISP_RECAL_ST_SHIFT 13 +#define AM33XX_DPLL_DISP_RECAL_ST_MASK (1 << 13) + +/* Used by PRM_IRQENABLE_M3, PRM_IRQENABLE_MPU */ +#define AM33XX_DPLL_MPU_RECAL_EN_SHIFT 11 +#define AM33XX_DPLL_MPU_RECAL_EN_MASK (1 << 11) + +/* Used by PRM_IRQSTATUS_M3, PRM_IRQSTATUS_MPU */ +#define AM33XX_DPLL_MPU_RECAL_ST_SHIFT 11 +#define AM33XX_DPLL_MPU_RECAL_ST_MASK (1 << 11) + +/* Used by PRM_IRQENABLE_M3, PRM_IRQENABLE_MPU */ +#define AM33XX_DPLL_PER_RECAL_EN_SHIFT 13 +#define AM33XX_DPLL_PER_RECAL_EN_MASK (1 << 13) + +/* Used by PRM_IRQSTATUS_M3, PRM_IRQSTATUS_MPU */ +#define AM33XX_DPLL_PER_RECAL_ST_SHIFT 15 +#define AM33XX_DPLL_PER_RECAL_ST_MASK (1 << 15) + +/* Used by RM_WKUP_RSTST */ +#define AM33XX_EMULATION_M3_RST_SHIFT 6 +#define AM33XX_EMULATION_M3_RST_MASK (1 << 6) + +/* Used by RM_MPU_RSTST */ +#define AM33XX_EMULATION_MPU_RST_SHIFT 5 +#define AM33XX_EMULATION_MPU_RST_MASK (1 << 5) + +/* Used by PRM_LDO_SRAM_CORE_SETUP, PRM_LDO_SRAM_MPU_SETUP */ +#define AM33XX_ENFUNC1_EXPORT_SHIFT 3 +#define AM33XX_ENFUNC1_EXPORT_MASK (1 << 3) + +/* Used by PRM_LDO_SRAM_CORE_SETUP, PRM_LDO_SRAM_MPU_SETUP */ +#define AM33XX_ENFUNC3_EXPORT_SHIFT 5 +#define AM33XX_ENFUNC3_EXPORT_MASK (1 << 5) + +/* Used by PRM_LDO_SRAM_CORE_SETUP, PRM_LDO_SRAM_MPU_SETUP */ +#define AM33XX_ENFUNC4_SHIFT 6 +#define AM33XX_ENFUNC4_MASK (1 << 6) + +/* Used by PRM_LDO_SRAM_CORE_SETUP, PRM_LDO_SRAM_MPU_SETUP */ +#define AM33XX_ENFUNC5_SHIFT 7 +#define AM33XX_ENFUNC5_MASK (1 << 7) + +/* Used by PRM_RSTST */ +#define AM33XX_EXTERNAL_WARM_RST_SHIFT 5 +#define AM33XX_EXTERNAL_WARM_RST_MASK (1 << 5) + +/* Used by PRM_IRQENABLE_M3, PRM_IRQENABLE_MPU */ +#define AM33XX_FORCEWKUP_EN_SHIFT 10 +#define AM33XX_FORCEWKUP_EN_MASK (1 << 10) + +/* Used by PRM_IRQSTATUS_M3, PRM_IRQSTATUS_MPU */ +#define AM33XX_FORCEWKUP_ST_SHIFT 10 +#define AM33XX_FORCEWKUP_ST_MASK (1 << 10) + +/* Used by PM_GFX_PWRSTCTRL */ +#define AM33XX_GFX_MEM_ONSTATE_SHIFT 17 +#define AM33XX_GFX_MEM_ONSTATE_MASK (0x3 << 17) + +/* Used by PM_GFX_PWRSTCTRL */ +#define AM33XX_GFX_MEM_RETSTATE_SHIFT 6 +#define AM33XX_GFX_MEM_RETSTATE_MASK (1 << 6) + +/* Used by PM_GFX_PWRSTST */ +#define AM33XX_GFX_MEM_STATEST_SHIFT 4 +#define AM33XX_GFX_MEM_STATEST_MASK (0x3 << 4) + +/* Used by RM_GFX_RSTCTRL, RM_GFX_RSTST */ +#define AM33XX_GFX_RST_SHIFT 0 +#define AM33XX_GFX_RST_MASK (1 << 0) + +/* Used by PRM_RSTST */ +#define AM33XX_GLOBAL_COLD_RST_SHIFT 0 +#define AM33XX_GLOBAL_COLD_RST_MASK (1 << 0) + +/* Used by PRM_RSTST */ +#define AM33XX_GLOBAL_WARM_SW_RST_SHIFT 1 +#define AM33XX_GLOBAL_WARM_SW_RST_MASK (1 << 1) + +/* Used by RM_WKUP_RSTST */ +#define AM33XX_ICECRUSHER_M3_RST_SHIFT 7 +#define AM33XX_ICECRUSHER_M3_RST_MASK (1 << 7) + +/* Used by RM_MPU_RSTST */ +#define AM33XX_ICECRUSHER_MPU_RST_SHIFT 6 +#define AM33XX_ICECRUSHER_MPU_RST_MASK (1 << 6) + +/* Used by PRM_RSTST */ +#define AM33XX_ICEPICK_RST_SHIFT 9 +#define AM33XX_ICEPICK_RST_MASK (1 << 9) + +/* Used by RM_PER_RSTCTRL */ +#define AM33XX_PRUSS_LRST_SHIFT 1 +#define AM33XX_PRUSS_LRST_MASK (1 << 1) + +/* Used by PM_PER_PWRSTCTRL */ +#define AM33XX_PRUSS_MEM_ONSTATE_SHIFT 5 +#define AM33XX_PRUSS_MEM_ONSTATE_MASK (0x3 << 5) + +/* Used by PM_PER_PWRSTCTRL */ +#define AM33XX_PRUSS_MEM_RETSTATE_SHIFT 7 +#define AM33XX_PRUSS_MEM_RETSTATE_MASK (1 << 7) + +/* Used by PM_PER_PWRSTST */ +#define AM33XX_PRUSS_MEM_STATEST_SHIFT 23 +#define AM33XX_PRUSS_MEM_STATEST_MASK (0x3 << 23) + +/* + * Used by PM_GFX_PWRSTST, PM_CEFUSE_PWRSTST, PM_PER_PWRSTST, PM_MPU_PWRSTST, + * PM_WKUP_PWRSTST, PM_RTC_PWRSTST + */ +#define AM33XX_INTRANSITION_SHIFT 20 +#define AM33XX_INTRANSITION_MASK (1 << 20) + +/* Used by PM_CEFUSE_PWRSTST */ +#define AM33XX_LASTPOWERSTATEENTERED_SHIFT 24 +#define AM33XX_LASTPOWERSTATEENTERED_MASK (0x3 << 24) + +/* Used by PM_GFX_PWRSTCTRL, PM_MPU_PWRSTCTRL, PM_RTC_PWRSTCTRL */ +#define AM33XX_LOGICRETSTATE_SHIFT 2 +#define AM33XX_LOGICRETSTATE_MASK (1 << 2) + +/* Renamed from LOGICRETSTATE Used by PM_PER_PWRSTCTRL, PM_WKUP_PWRSTCTRL */ +#define AM33XX_LOGICRETSTATE_3_3_SHIFT 3 +#define AM33XX_LOGICRETSTATE_3_3_MASK (1 << 3) + +/* + * Used by PM_GFX_PWRSTST, PM_CEFUSE_PWRSTST, PM_PER_PWRSTST, PM_MPU_PWRSTST, + * PM_WKUP_PWRSTST, PM_RTC_PWRSTST + */ +#define AM33XX_LOGICSTATEST_SHIFT 2 +#define AM33XX_LOGICSTATEST_MASK (1 << 2) + +/* + * Used by PM_GFX_PWRSTCTRL, PM_CEFUSE_PWRSTCTRL, PM_PER_PWRSTCTRL, + * PM_MPU_PWRSTCTRL, PM_WKUP_PWRSTCTRL, PM_RTC_PWRSTCTRL + */ +#define AM33XX_LOWPOWERSTATECHANGE_SHIFT 4 +#define AM33XX_LOWPOWERSTATECHANGE_MASK (1 << 4) + +/* Used by PM_MPU_PWRSTCTRL */ +#define AM33XX_MPU_L1_ONSTATE_SHIFT 18 +#define AM33XX_MPU_L1_ONSTATE_MASK (0x3 << 18) + +/* Used by PM_MPU_PWRSTCTRL */ +#define AM33XX_MPU_L1_RETSTATE_SHIFT 22 +#define AM33XX_MPU_L1_RETSTATE_MASK (1 << 22) + +/* Used by PM_MPU_PWRSTST */ +#define AM33XX_MPU_L1_STATEST_SHIFT 6 +#define AM33XX_MPU_L1_STATEST_MASK (0x3 << 6) + +/* Used by PM_MPU_PWRSTCTRL */ +#define AM33XX_MPU_L2_ONSTATE_SHIFT 20 +#define AM33XX_MPU_L2_ONSTATE_MASK (0x3 << 20) + +/* Used by PM_MPU_PWRSTCTRL */ +#define AM33XX_MPU_L2_RETSTATE_SHIFT 23 +#define AM33XX_MPU_L2_RETSTATE_MASK (1 << 23) + +/* Used by PM_MPU_PWRSTST */ +#define AM33XX_MPU_L2_STATEST_SHIFT 8 +#define AM33XX_MPU_L2_STATEST_MASK (0x3 << 8) + +/* Used by PM_MPU_PWRSTCTRL */ +#define AM33XX_MPU_RAM_ONSTATE_SHIFT 16 +#define AM33XX_MPU_RAM_ONSTATE_MASK (0x3 << 16) + +/* Used by PM_MPU_PWRSTCTRL */ +#define AM33XX_MPU_RAM_RETSTATE_SHIFT 24 +#define AM33XX_MPU_RAM_RETSTATE_MASK (1 << 24) + +/* Used by PM_MPU_PWRSTST */ +#define AM33XX_MPU_RAM_STATEST_SHIFT 4 +#define AM33XX_MPU_RAM_STATEST_MASK (0x3 << 4) + +/* Used by PRM_RSTST */ +#define AM33XX_MPU_SECURITY_VIOL_RST_SHIFT 2 +#define AM33XX_MPU_SECURITY_VIOL_RST_MASK (1 << 2) + +/* Used by PRM_SRAM_COUNT */ +#define AM33XX_PCHARGECNT_VALUE_SHIFT 0 +#define AM33XX_PCHARGECNT_VALUE_MASK (0x3f << 0) + +/* Used by RM_PER_RSTCTRL */ +#define AM33XX_PCI_LRST_SHIFT 0 +#define AM33XX_PCI_LRST_MASK (1 << 0) + +/* Renamed from PCI_LRST Used by RM_PER_RSTST */ +#define AM33XX_PCI_LRST_5_5_SHIFT 5 +#define AM33XX_PCI_LRST_5_5_MASK (1 << 5) + +/* Used by PM_PER_PWRSTCTRL */ +#define AM33XX_PER_MEM_ONSTATE_SHIFT 25 +#define AM33XX_PER_MEM_ONSTATE_MASK (0x3 << 25) + +/* Used by PM_PER_PWRSTCTRL */ +#define AM33XX_PER_MEM_RETSTATE_SHIFT 29 +#define AM33XX_PER_MEM_RETSTATE_MASK (1 << 29) + +/* Used by PM_PER_PWRSTST */ +#define AM33XX_PER_MEM_STATEST_SHIFT 17 +#define AM33XX_PER_MEM_STATEST_MASK (0x3 << 17) + +/* + * Used by PM_GFX_PWRSTCTRL, PM_CEFUSE_PWRSTCTRL, PM_PER_PWRSTCTRL, + * PM_MPU_PWRSTCTRL + */ +#define AM33XX_POWERSTATE_SHIFT 0 +#define AM33XX_POWERSTATE_MASK (0x3 << 0) + +/* Used by PM_GFX_PWRSTST, PM_CEFUSE_PWRSTST, PM_PER_PWRSTST, PM_MPU_PWRSTST */ +#define AM33XX_POWERSTATEST_SHIFT 0 +#define AM33XX_POWERSTATEST_MASK (0x3 << 0) + +/* Used by PM_PER_PWRSTCTRL */ +#define AM33XX_RAM_MEM_ONSTATE_SHIFT 30 +#define AM33XX_RAM_MEM_ONSTATE_MASK (0x3 << 30) + +/* Used by PM_PER_PWRSTCTRL */ +#define AM33XX_RAM_MEM_RETSTATE_SHIFT 27 +#define AM33XX_RAM_MEM_RETSTATE_MASK (1 << 27) + +/* Used by PM_PER_PWRSTST */ +#define AM33XX_RAM_MEM_STATEST_SHIFT 21 +#define AM33XX_RAM_MEM_STATEST_MASK (0x3 << 21) + +/* Used by PRM_LDO_SRAM_CORE_CTRL, PRM_LDO_SRAM_MPU_CTRL */ +#define AM33XX_RETMODE_ENABLE_SHIFT 0 +#define AM33XX_RETMODE_ENABLE_MASK (1 << 0) + +/* Used by REVISION_PRM */ +#define AM33XX_REV_SHIFT 0 +#define AM33XX_REV_MASK (0xff << 0) + +/* Used by PRM_RSTTIME */ +#define AM33XX_RSTTIME1_SHIFT 0 +#define AM33XX_RSTTIME1_MASK (0xff << 0) + +/* Used by PRM_RSTTIME */ +#define AM33XX_RSTTIME2_SHIFT 8 +#define AM33XX_RSTTIME2_MASK (0x1f << 8) + +/* Used by PRM_RSTCTRL */ +#define AM33XX_RST_GLOBAL_COLD_SW_SHIFT 1 +#define AM33XX_RST_GLOBAL_COLD_SW_MASK (1 << 1) + +/* Used by PRM_RSTCTRL */ +#define AM33XX_RST_GLOBAL_WARM_SW_SHIFT 0 +#define AM33XX_RST_GLOBAL_WARM_SW_MASK (1 << 0) + +/* Used by PRM_SRAM_COUNT */ +#define AM33XX_SLPCNT_VALUE_SHIFT 16 +#define AM33XX_SLPCNT_VALUE_MASK (0xff << 16) + +/* Used by PRM_LDO_SRAM_CORE_CTRL, PRM_LDO_SRAM_MPU_CTRL */ +#define AM33XX_SRAMLDO_STATUS_SHIFT 8 +#define AM33XX_SRAMLDO_STATUS_MASK (1 << 8) + +/* Used by PRM_LDO_SRAM_CORE_CTRL, PRM_LDO_SRAM_MPU_CTRL */ +#define AM33XX_SRAM_IN_TRANSITION_SHIFT 9 +#define AM33XX_SRAM_IN_TRANSITION_MASK (1 << 9) + +/* Used by PRM_SRAM_COUNT */ +#define AM33XX_STARTUP_COUNT_SHIFT 24 +#define AM33XX_STARTUP_COUNT_MASK (0xff << 24) + +/* Used by PRM_IRQENABLE_M3, PRM_IRQENABLE_MPU */ +#define AM33XX_TRANSITION_EN_SHIFT 8 +#define AM33XX_TRANSITION_EN_MASK (1 << 8) + +/* Used by PRM_IRQSTATUS_M3, PRM_IRQSTATUS_MPU */ +#define AM33XX_TRANSITION_ST_SHIFT 8 +#define AM33XX_TRANSITION_ST_MASK (1 << 8) + +/* Used by PRM_SRAM_COUNT */ +#define AM33XX_VSETUPCNT_VALUE_SHIFT 8 +#define AM33XX_VSETUPCNT_VALUE_MASK (0xff << 8) + +/* Used by PRM_RSTST */ +#define AM33XX_WDT0_RST_SHIFT 3 +#define AM33XX_WDT0_RST_MASK (1 << 3) + +/* Used by PRM_RSTST */ +#define AM33XX_WDT1_RST_SHIFT 4 +#define AM33XX_WDT1_RST_MASK (1 << 4) + +/* Used by RM_WKUP_RSTCTRL */ +#define AM33XX_WKUP_M3_LRST_SHIFT 3 +#define AM33XX_WKUP_M3_LRST_MASK (1 << 3) + +/* Renamed from WKUP_M3_LRST Used by RM_WKUP_RSTST */ +#define AM33XX_WKUP_M3_LRST_5_5_SHIFT 5 +#define AM33XX_WKUP_M3_LRST_5_5_MASK (1 << 5) + +#endif diff --git a/arch/arm/mach-omap2/prm33xx.c b/arch/arm/mach-omap2/prm33xx.c new file mode 100644 index 0000000..7444855 --- /dev/null +++ b/arch/arm/mach-omap2/prm33xx.c @@ -0,0 +1,134 @@ +/* + * AM33XX PRM functions + * + * Copyright (C) 2011-2012 Texas Instruments Incorporated - http://www.ti.com/ + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License as + * published by the Free Software Foundation version 2. + * + * This program is distributed "as is" WITHOUT ANY WARRANTY of any + * kind, whether express or implied; without even the implied warranty + * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + */ + +#include <linux/kernel.h> +#include <linux/types.h> +#include <linux/errno.h> +#include <linux/err.h> +#include <linux/io.h> + +#include <plat/common.h> + +#include "common.h" +#include "prm33xx.h" +#include "prm-regbits-33xx.h" + +/* Read a register in a PRM instance */ +u32 am33xx_prm_read_reg(s16 inst, u16 idx) +{ + return __raw_readl(prm_base + inst + idx); +} + +/* Write into a register in a PRM instance */ +void am33xx_prm_write_reg(u32 val, s16 inst, u16 idx) +{ + __raw_writel(val, prm_base + inst + idx); +} + +/* Read-modify-write a register in PRM. Caller must lock */ +u32 am33xx_prm_rmw_reg_bits(u32 mask, u32 bits, s16 inst, s16 idx) +{ + u32 v; + + v = am33xx_prm_read_reg(inst, idx); + v &= ~mask; + v |= bits; + am33xx_prm_write_reg(v, inst, idx); + + return v; +} + +/** + * am33xx_prm_is_hardreset_asserted - read the HW reset line state of + * submodules contained in the hwmod module + * @shift: register bit shift corresponding to the reset line to check + * @inst: CM instance register offset (*_INST macro) + * @rstctrl_offs: RM_RSTCTRL register address offset for this module + * + * Returns 1 if the (sub)module hardreset line is currently asserted, + * 0 if the (sub)module hardreset line is not currently asserted, or + * -EINVAL upon parameter error. + */ +int am33xx_prm_is_hardreset_asserted(u8 shift, s16 inst, u16 rstctrl_offs) +{ + u32 v; + + v = am33xx_prm_read_reg(inst, rstctrl_offs); + v &= 1 << shift; + v >>= shift; + + return v; +} + +/** + * am33xx_prm_assert_hardreset - assert the HW reset line of a submodule + * @shift: register bit shift corresponding to the reset line to assert + * @inst: CM instance register offset (*_INST macro) + * @rstctrl_reg: RM_RSTCTRL register address for this module + * + * Some IPs like dsp, ipu or iva contain processors that require an HW + * reset line to be asserted / deasserted in order to fully enable the + * IP. These modules may have multiple hard-reset lines that reset + * different 'submodules' inside the IP block. This function will + * place the submodule into reset. Returns 0 upon success or -EINVAL + * upon an argument error. + */ +int am33xx_prm_assert_hardreset(u8 shift, s16 inst, u16 rstctrl_offs) +{ + u32 mask = 1 << shift; + + am33xx_prm_rmw_reg_bits(mask, mask, inst, rstctrl_offs); + + return 0; +} + +/** + * am33xx_prm_deassert_hardreset - deassert a submodule hardreset line and + * wait + * @shift: register bit shift corresponding to the reset line to deassert + * @inst: CM instance register offset (*_INST macro) + * @rstctrl_reg: RM_RSTCTRL register address for this module + * @rstst_reg: RM_RSTST register address for this module + * + * Some IPs like dsp, ipu or iva contain processors that require an HW + * reset line to be asserted / deasserted in order to fully enable the + * IP. These modules may have multiple hard-reset lines that reset + * different 'submodules' inside the IP block. This function will + * take the submodule out of reset and wait until the PRCM indicates + * that the reset has completed before returning. Returns 0 upon success or + * -EINVAL upon an argument error, -EEXIST if the submodule was already out + * of reset, or -EBUSY if the submodule did not exit reset promptly. + */ +int am33xx_prm_deassert_hardreset(u8 shift, s16 inst, + u16 rstctrl_offs, u16 rstst_offs) +{ + int c; + u32 mask = 1 << shift; + + /* Check the current status to avoid de-asserting the line twice */ + if (am33xx_prm_is_hardreset_asserted(shift, inst, rstctrl_offs) == 0) + return -EEXIST; + + /* Clear the reset status by writing 1 to the status bit */ + am33xx_prm_rmw_reg_bits(0xffffffff, mask, inst, rstst_offs); + /* de-assert the reset control line */ + am33xx_prm_rmw_reg_bits(mask, 0, inst, rstctrl_offs); + /* wait the status to be set */ + + omap_test_timeout(am33xx_prm_is_hardreset_asserted(shift, inst, + rstst_offs), MAX_MODULE_HARDRESET_WAIT, c); + + return (c == MAX_MODULE_HARDRESET_WAIT) ? -EBUSY : 0; +} diff --git a/arch/arm/mach-omap2/prm33xx.h b/arch/arm/mach-omap2/prm33xx.h new file mode 100644 index 0000000..3f25c56 --- /dev/null +++ b/arch/arm/mach-omap2/prm33xx.h @@ -0,0 +1,129 @@ +/* + * AM33XX PRM instance offset macros + * + * Copyright (C) 2011-2012 Texas Instruments Incorporated - http://www.ti.com/ + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License as + * published by the Free Software Foundation version 2. + * + * This program is distributed "as is" WITHOUT ANY WARRANTY of any + * kind, whether express or implied; without even the implied warranty + * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + */ + +#ifndef __ARCH_ARM_MACH_OMAP2_PRM33XX_H +#define __ARCH_ARM_MACH_OMAP2_PRM33XX_H + +#include "prcm-common.h" +#include "prm.h" + +#define AM33XX_PRM_BASE 0x44E00000 + +#define AM33XX_PRM_REGADDR(inst, reg) \ + AM33XX_L4_WK_IO_ADDRESS(AM33XX_PRM_BASE + (inst) + (reg)) + + +/* PRM instances */ +#define AM33XX_PRM_OCP_SOCKET_MOD 0x0B00 +#define AM33XX_PRM_PER_MOD 0x0C00 +#define AM33XX_PRM_WKUP_MOD 0x0D00 +#define AM33XX_PRM_MPU_MOD 0x0E00 +#define AM33XX_PRM_DEVICE_MOD 0x0F00 +#define AM33XX_PRM_RTC_MOD 0x1000 +#define AM33XX_PRM_GFX_MOD 0x1100 +#define AM33XX_PRM_CEFUSE_MOD 0x1200 + +/* PRM */ + +/* PRM.OCP_SOCKET_PRM register offsets */ +#define AM33XX_REVISION_PRM_OFFSET 0x0000 +#define AM33XX_REVISION_PRM AM33XX_PRM_REGADDR(AM33XX_PRM_OCP_SOCKET_MOD, 0x0000) +#define AM33XX_PRM_IRQSTATUS_MPU_OFFSET 0x0004 +#define AM33XX_PRM_IRQSTATUS_MPU AM33XX_PRM_REGADDR(AM33XX_PRM_OCP_SOCKET_MOD, 0x0004) +#define AM33XX_PRM_IRQENABLE_MPU_OFFSET 0x0008 +#define AM33XX_PRM_IRQENABLE_MPU AM33XX_PRM_REGADDR(AM33XX_PRM_OCP_SOCKET_MOD, 0x0008) +#define AM33XX_PRM_IRQSTATUS_M3_OFFSET 0x000c +#define AM33XX_PRM_IRQSTATUS_M3 AM33XX_PRM_REGADDR(AM33XX_PRM_OCP_SOCKET_MOD, 0x000c) +#define AM33XX_PRM_IRQENABLE_M3_OFFSET 0x0010 +#define AM33XX_PRM_IRQENABLE_M3 AM33XX_PRM_REGADDR(AM33XX_PRM_OCP_SOCKET_MOD, 0x0010) + +/* PRM.PER_PRM register offsets */ +#define AM33XX_RM_PER_RSTCTRL_OFFSET 0x0000 +#define AM33XX_RM_PER_RSTCTRL AM33XX_PRM_REGADDR(AM33XX_PRM_PER_MOD, 0x0000) +#define AM33XX_RM_PER_RSTST_OFFSET 0x0004 +#define AM33XX_RM_PER_RSTST AM33XX_PRM_REGADDR(AM33XX_PRM_PER_MOD, 0x0004) +#define AM33XX_PM_PER_PWRSTST_OFFSET 0x0008 +#define AM33XX_PM_PER_PWRSTST AM33XX_PRM_REGADDR(AM33XX_PRM_PER_MOD, 0x0008) +#define AM33XX_PM_PER_PWRSTCTRL_OFFSET 0x000c +#define AM33XX_PM_PER_PWRSTCTRL AM33XX_PRM_REGADDR(AM33XX_PRM_PER_MOD, 0x000c) + +/* PRM.WKUP_PRM register offsets */ +#define AM33XX_RM_WKUP_RSTCTRL_OFFSET 0x0000 +#define AM33XX_RM_WKUP_RSTCTRL AM33XX_PRM_REGADDR(AM33XX_PRM_WKUP_MOD, 0x0000) +#define AM33XX_PM_WKUP_PWRSTCTRL_OFFSET 0x0004 +#define AM33XX_PM_WKUP_PWRSTCTRL AM33XX_PRM_REGADDR(AM33XX_PRM_WKUP_MOD, 0x0004) +#define AM33XX_PM_WKUP_PWRSTST_OFFSET 0x0008 +#define AM33XX_PM_WKUP_PWRSTST AM33XX_PRM_REGADDR(AM33XX_PRM_WKUP_MOD, 0x0008) +#define AM33XX_RM_WKUP_RSTST_OFFSET 0x000c +#define AM33XX_RM_WKUP_RSTST AM33XX_PRM_REGADDR(AM33XX_PRM_WKUP_MOD, 0x000c) + +/* PRM.MPU_PRM register offsets */ +#define AM33XX_PM_MPU_PWRSTCTRL_OFFSET 0x0000 +#define AM33XX_PM_MPU_PWRSTCTRL AM33XX_PRM_REGADDR(AM33XX_PRM_MPU_MOD, 0x0000) +#define AM33XX_PM_MPU_PWRSTST_OFFSET 0x0004 +#define AM33XX_PM_MPU_PWRSTST AM33XX_PRM_REGADDR(AM33XX_PRM_MPU_MOD, 0x0004) +#define AM33XX_RM_MPU_RSTST_OFFSET 0x0008 +#define AM33XX_RM_MPU_RSTST AM33XX_PRM_REGADDR(AM33XX_PRM_MPU_MOD, 0x0008) + +/* PRM.DEVICE_PRM register offsets */ +#define AM33XX_PRM_RSTCTRL_OFFSET 0x0000 +#define AM33XX_PRM_RSTCTRL AM33XX_PRM_REGADDR(AM33XX_PRM_DEVICE_MOD, 0x0000) +#define AM33XX_PRM_RSTTIME_OFFSET 0x0004 +#define AM33XX_PRM_RSTTIME AM33XX_PRM_REGADDR(AM33XX_PRM_DEVICE_MOD, 0x0004) +#define AM33XX_PRM_RSTST_OFFSET 0x0008 +#define AM33XX_PRM_RSTST AM33XX_PRM_REGADDR(AM33XX_PRM_DEVICE_MOD, 0x0008) +#define AM33XX_PRM_SRAM_COUNT_OFFSET 0x000c +#define AM33XX_PRM_SRAM_COUNT AM33XX_PRM_REGADDR(AM33XX_PRM_DEVICE_MOD, 0x000c) +#define AM33XX_PRM_LDO_SRAM_CORE_SETUP_OFFSET 0x0010 +#define AM33XX_PRM_LDO_SRAM_CORE_SETUP AM33XX_PRM_REGADDR(AM33XX_PRM_DEVICE_MOD, 0x0010) +#define AM33XX_PRM_LDO_SRAM_CORE_CTRL_OFFSET 0x0014 +#define AM33XX_PRM_LDO_SRAM_CORE_CTRL AM33XX_PRM_REGADDR(AM33XX_PRM_DEVICE_MOD, 0x0014) +#define AM33XX_PRM_LDO_SRAM_MPU_SETUP_OFFSET 0x0018 +#define AM33XX_PRM_LDO_SRAM_MPU_SETUP AM33XX_PRM_REGADDR(AM33XX_PRM_DEVICE_MOD, 0x0018) +#define AM33XX_PRM_LDO_SRAM_MPU_CTRL_OFFSET 0x001c +#define AM33XX_PRM_LDO_SRAM_MPU_CTRL AM33XX_PRM_REGADDR(AM33XX_PRM_DEVICE_MOD, 0x001c) + +/* PRM.RTC_PRM register offsets */ +#define AM33XX_PM_RTC_PWRSTCTRL_OFFSET 0x0000 +#define AM33XX_PM_RTC_PWRSTCTRL AM33XX_PRM_REGADDR(AM33XX_PRM_RTC_MOD, 0x0000) +#define AM33XX_PM_RTC_PWRSTST_OFFSET 0x0004 +#define AM33XX_PM_RTC_PWRSTST AM33XX_PRM_REGADDR(AM33XX_PRM_RTC_MOD, 0x0004) + +/* PRM.GFX_PRM register offsets */ +#define AM33XX_PM_GFX_PWRSTCTRL_OFFSET 0x0000 +#define AM33XX_PM_GFX_PWRSTCTRL AM33XX_PRM_REGADDR(AM33XX_PRM_GFX_MOD, 0x0000) +#define AM33XX_RM_GFX_RSTCTRL_OFFSET 0x0004 +#define AM33XX_RM_GFX_RSTCTRL AM33XX_PRM_REGADDR(AM33XX_PRM_GFX_MOD, 0x0004) +#define AM33XX_PM_GFX_PWRSTST_OFFSET 0x0010 +#define AM33XX_PM_GFX_PWRSTST AM33XX_PRM_REGADDR(AM33XX_PRM_GFX_MOD, 0x0010) +#define AM33XX_RM_GFX_RSTST_OFFSET 0x0014 +#define AM33XX_RM_GFX_RSTST AM33XX_PRM_REGADDR(AM33XX_PRM_GFX_MOD, 0x0014) + +/* PRM.CEFUSE_PRM register offsets */ +#define AM33XX_PM_CEFUSE_PWRSTCTRL_OFFSET 0x0000 +#define AM33XX_PM_CEFUSE_PWRSTCTRL AM33XX_PRM_REGADDR(AM33XX_PRM_CEFUSE_MOD, 0x0000) +#define AM33XX_PM_CEFUSE_PWRSTST_OFFSET 0x0004 +#define AM33XX_PM_CEFUSE_PWRSTST AM33XX_PRM_REGADDR(AM33XX_PRM_CEFUSE_MOD, 0x0004) + +extern u32 am33xx_prm_read_reg(s16 inst, u16 idx); +extern void am33xx_prm_write_reg(u32 val, s16 inst, u16 idx); +extern u32 am33xx_prm_rmw_reg_bits(u32 mask, u32 bits, s16 inst, s16 idx); +extern void am33xx_prm_global_warm_sw_reset(void); +extern int am33xx_prm_is_hardreset_asserted(u8 shift, s16 inst, + u16 rstctrl_offs); +extern int am33xx_prm_assert_hardreset(u8 shift, s16 inst, u16 rstctrl_offs); +extern int am33xx_prm_deassert_hardreset(u8 shift, s16 inst, + u16 rstctrl_offs, u16 rstst_offs); +#endif -- 1.7.0.4 ^ permalink raw reply related [flat|nested] 64+ messages in thread
* Re: [PATCH-V4 4/4] ARM: OMAP3+: am33xx: Add powerdomain & PRM support 2012-03-30 16:03 ` Vaibhav Hiremath @ 2012-04-27 0:49 ` Kevin Hilman -1 siblings, 0 replies; 64+ messages in thread From: Kevin Hilman @ 2012-04-27 0:49 UTC (permalink / raw) To: Vaibhav Hiremath Cc: linux-omap, paul, b-cousson, tony, rnayak, Afzal Mohammed, linux-arm-kernel Vaibhav Hiremath <hvaibhav@ti.com> writes: > 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. [...] > @@ -1288,7 +1289,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); This still troubles me. I *really* don't like that we have a dependence on cpu_is* call ordering. This is very fragile and error prone. I also don't like all the cpu_is* checking currently in omap_hwmod.c (which is here before you added this) and have an idea on how to clean it up, I should have a patch by tomorrow for this. That should help adding am33xx support here without needing all the cpu_is* checking. That being said, I just did a simple experiment[1] to see why cpu_is_omap34xx() needs to be true for AM33xx in the first place. Based on my quick experiment, it does not appear to be needed. I think our lives will be much simpler if cpu_is_omap34xx() is not true for the AM335x family. Can you have a look at my test branch[1] and see what you think? I changed the omap_revision for AM335x so that cpu_is_omap34xx() is no longer true on this platform. Then, I only needed to fixup the SRAM init, and it boots just fine on my BeagleBone. I really think we need to go this route, because having cpu_is_omap34xx() true on AM335x is causing more headaches than it is solving problems. This will require you to rework a little bit these clock/power/voltage domain patches, but I belive it will greatly simplify the maintainability of the end result. Kevin [1] git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git tmp/am335x-cpu-is-hacking ^ permalink raw reply [flat|nested] 64+ messages in thread
* [PATCH-V4 4/4] ARM: OMAP3+: am33xx: Add powerdomain & PRM support @ 2012-04-27 0:49 ` Kevin Hilman 0 siblings, 0 replies; 64+ messages in thread From: Kevin Hilman @ 2012-04-27 0:49 UTC (permalink / raw) To: linux-arm-kernel Vaibhav Hiremath <hvaibhav@ti.com> writes: > 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. [...] > @@ -1288,7 +1289,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); This still troubles me. I *really* don't like that we have a dependence on cpu_is* call ordering. This is very fragile and error prone. I also don't like all the cpu_is* checking currently in omap_hwmod.c (which is here before you added this) and have an idea on how to clean it up, I should have a patch by tomorrow for this. That should help adding am33xx support here without needing all the cpu_is* checking. That being said, I just did a simple experiment[1] to see why cpu_is_omap34xx() needs to be true for AM33xx in the first place. Based on my quick experiment, it does not appear to be needed. I think our lives will be much simpler if cpu_is_omap34xx() is not true for the AM335x family. Can you have a look at my test branch[1] and see what you think? I changed the omap_revision for AM335x so that cpu_is_omap34xx() is no longer true on this platform. Then, I only needed to fixup the SRAM init, and it boots just fine on my BeagleBone. I really think we need to go this route, because having cpu_is_omap34xx() true on AM335x is causing more headaches than it is solving problems. This will require you to rework a little bit these clock/power/voltage domain patches, but I belive it will greatly simplify the maintainability of the end result. Kevin [1] git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git tmp/am335x-cpu-is-hacking ^ permalink raw reply [flat|nested] 64+ messages in thread
* RE: [PATCH-V4 4/4] ARM: OMAP3+: am33xx: Add powerdomain & PRM support 2012-04-27 0:49 ` Kevin Hilman @ 2012-04-27 6:37 ` Hiremath, Vaibhav -1 siblings, 0 replies; 64+ messages in thread From: Hiremath, Vaibhav @ 2012-04-27 6:37 UTC (permalink / raw) To: Hilman, Kevin Cc: linux-omap, paul, Cousson, Benoit, tony, Nayak, Rajendra, Mohammed, Afzal, linux-arm-kernel On Fri, Apr 27, 2012 at 06:19:02, Hilman, Kevin wrote: > Vaibhav Hiremath <hvaibhav@ti.com> writes: > > > 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. > > [...] > > > @@ -1288,7 +1289,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); > > This still troubles me. I *really* don't like that we have a dependence > on cpu_is* call ordering. This is very fragile and error prone. > > I also don't like all the cpu_is* checking currently in omap_hwmod.c > (which is here before you added this) and have an idea on how to clean > it up, I should have a patch by tomorrow for this. That should help > adding am33xx support here without needing all the cpu_is* checking. > > That being said, I just did a simple experiment[1] to see why > cpu_is_omap34xx() needs to be true for AM33xx in the first place. Based > on my quick experiment, it does not appear to be needed. I think our > lives will be much simpler if cpu_is_omap34xx() is not true for the > AM335x family. > > Can you have a look at my test branch[1] and see what you think? I > changed the omap_revision for AM335x so that cpu_is_omap34xx() is no > longer true on this platform. Then, I only needed to fixup the SRAM > init, and it boots just fine on my BeagleBone. > > I really think we need to go this route, because having > cpu_is_omap34xx() true on AM335x is causing more headaches than it is > solving problems. This will require you to rework a little bit these > clock/power/voltage domain patches, but I belive it will greatly > simplify the maintainability of the end result. > Let me spend some time, and explore your changes; I think getting system to boot should not be only criteria here. But honestly, I fully agree with you that, we are creating more issue, adding more cpu_is_xxx() checks, with cpu_is_34xx() true for AM33xx. As I have done in the past initially, I recommend and vote for, 1. Creating separate family cpu_is_am33xx() for AM33xx device. OR 2. Bring it to omap44xx family, since prcm block is closer to omap4 and not with omap3. Also, Tony, I will let tony make a decision on this. By the time, Tony makes his decision, I will spend time to explore your (Kevin's below) branch. Thanks, Vaibhav > Kevin > > [1] git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git tmp/am335x-cpu-is-hacking > > ^ permalink raw reply [flat|nested] 64+ messages in thread
* [PATCH-V4 4/4] ARM: OMAP3+: am33xx: Add powerdomain & PRM support @ 2012-04-27 6:37 ` Hiremath, Vaibhav 0 siblings, 0 replies; 64+ messages in thread From: Hiremath, Vaibhav @ 2012-04-27 6:37 UTC (permalink / raw) To: linux-arm-kernel On Fri, Apr 27, 2012 at 06:19:02, Hilman, Kevin wrote: > Vaibhav Hiremath <hvaibhav@ti.com> writes: > > > 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. > > [...] > > > @@ -1288,7 +1289,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); > > This still troubles me. I *really* don't like that we have a dependence > on cpu_is* call ordering. This is very fragile and error prone. > > I also don't like all the cpu_is* checking currently in omap_hwmod.c > (which is here before you added this) and have an idea on how to clean > it up, I should have a patch by tomorrow for this. That should help > adding am33xx support here without needing all the cpu_is* checking. > > That being said, I just did a simple experiment[1] to see why > cpu_is_omap34xx() needs to be true for AM33xx in the first place. Based > on my quick experiment, it does not appear to be needed. I think our > lives will be much simpler if cpu_is_omap34xx() is not true for the > AM335x family. > > Can you have a look at my test branch[1] and see what you think? I > changed the omap_revision for AM335x so that cpu_is_omap34xx() is no > longer true on this platform. Then, I only needed to fixup the SRAM > init, and it boots just fine on my BeagleBone. > > I really think we need to go this route, because having > cpu_is_omap34xx() true on AM335x is causing more headaches than it is > solving problems. This will require you to rework a little bit these > clock/power/voltage domain patches, but I belive it will greatly > simplify the maintainability of the end result. > Let me spend some time, and explore your changes; I think getting system to boot should not be only criteria here. But honestly, I fully agree with you that, we are creating more issue, adding more cpu_is_xxx() checks, with cpu_is_34xx() true for AM33xx. As I have done in the past initially, I recommend and vote for, 1. Creating separate family cpu_is_am33xx() for AM33xx device. OR 2. Bring it to omap44xx family, since prcm block is closer to omap4 and not with omap3. Also, Tony, I will let tony make a decision on this. By the time, Tony makes his decision, I will spend time to explore your (Kevin's below) branch. Thanks, Vaibhav > Kevin > > [1] git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git tmp/am335x-cpu-is-hacking > > ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [PATCH-V4 4/4] ARM: OMAP3+: am33xx: Add powerdomain & PRM support 2012-04-27 6:37 ` Hiremath, Vaibhav @ 2012-05-04 18:43 ` Tony Lindgren -1 siblings, 0 replies; 64+ messages in thread From: Tony Lindgren @ 2012-05-04 18:43 UTC (permalink / raw) To: Hiremath, Vaibhav Cc: Hilman, Kevin, linux-omap, paul, Cousson, Benoit, Nayak, Rajendra, Mohammed, Afzal, linux-arm-kernel * Hiremath, Vaibhav <hvaibhav@ti.com> [120426 23:40]: > On Fri, Apr 27, 2012 at 06:19:02, Hilman, Kevin wrote: > > Vaibhav Hiremath <hvaibhav@ti.com> writes: > > > > > 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. > > > > [...] > > > > > @@ -1288,7 +1289,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); > > > > This still troubles me. I *really* don't like that we have a dependence > > on cpu_is* call ordering. This is very fragile and error prone. > > > > I also don't like all the cpu_is* checking currently in omap_hwmod.c > > (which is here before you added this) and have an idea on how to clean > > it up, I should have a patch by tomorrow for this. That should help > > adding am33xx support here without needing all the cpu_is* checking. > > > > That being said, I just did a simple experiment[1] to see why > > cpu_is_omap34xx() needs to be true for AM33xx in the first place. Based > > on my quick experiment, it does not appear to be needed. I think our > > lives will be much simpler if cpu_is_omap34xx() is not true for the > > AM335x family. > > > > Can you have a look at my test branch[1] and see what you think? I > > changed the omap_revision for AM335x so that cpu_is_omap34xx() is no > > longer true on this platform. Then, I only needed to fixup the SRAM > > init, and it boots just fine on my BeagleBone. > > > > I really think we need to go this route, because having > > cpu_is_omap34xx() true on AM335x is causing more headaches than it is > > solving problems. This will require you to rework a little bit these > > clock/power/voltage domain patches, but I belive it will greatly > > simplify the maintainability of the end result. > > > > Let me spend some time, and explore your changes; I think getting system to boot should not be only criteria here. > But honestly, I fully agree with you that, we are creating more issue, > adding more cpu_is_xxx() checks, with cpu_is_34xx() true for AM33xx. > > As I have done in the past initially, I recommend and vote for, > > 1. Creating separate family cpu_is_am33xx() for AM33xx device. > OR > 2. Bring it to omap44xx family, since prcm block is closer to omap4 > and not with omap3. Also, > > > Tony, > I will let tony make a decision on this. By the time, Tony makes his > decision, I will spend time to explore your (Kevin's below) branch. Just to summarize, I guess it's pretty obvious that we need cpu_is_am33xx here. In general work on getting rid of the cpu_is_xxxx checks as they are not safe to use with single zImage in initcalls. Tony ^ permalink raw reply [flat|nested] 64+ messages in thread
* [PATCH-V4 4/4] ARM: OMAP3+: am33xx: Add powerdomain & PRM support @ 2012-05-04 18:43 ` Tony Lindgren 0 siblings, 0 replies; 64+ messages in thread From: Tony Lindgren @ 2012-05-04 18:43 UTC (permalink / raw) To: linux-arm-kernel * Hiremath, Vaibhav <hvaibhav@ti.com> [120426 23:40]: > On Fri, Apr 27, 2012 at 06:19:02, Hilman, Kevin wrote: > > Vaibhav Hiremath <hvaibhav@ti.com> writes: > > > > > 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. > > > > [...] > > > > > @@ -1288,7 +1289,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); > > > > This still troubles me. I *really* don't like that we have a dependence > > on cpu_is* call ordering. This is very fragile and error prone. > > > > I also don't like all the cpu_is* checking currently in omap_hwmod.c > > (which is here before you added this) and have an idea on how to clean > > it up, I should have a patch by tomorrow for this. That should help > > adding am33xx support here without needing all the cpu_is* checking. > > > > That being said, I just did a simple experiment[1] to see why > > cpu_is_omap34xx() needs to be true for AM33xx in the first place. Based > > on my quick experiment, it does not appear to be needed. I think our > > lives will be much simpler if cpu_is_omap34xx() is not true for the > > AM335x family. > > > > Can you have a look at my test branch[1] and see what you think? I > > changed the omap_revision for AM335x so that cpu_is_omap34xx() is no > > longer true on this platform. Then, I only needed to fixup the SRAM > > init, and it boots just fine on my BeagleBone. > > > > I really think we need to go this route, because having > > cpu_is_omap34xx() true on AM335x is causing more headaches than it is > > solving problems. This will require you to rework a little bit these > > clock/power/voltage domain patches, but I belive it will greatly > > simplify the maintainability of the end result. > > > > Let me spend some time, and explore your changes; I think getting system to boot should not be only criteria here. > But honestly, I fully agree with you that, we are creating more issue, > adding more cpu_is_xxx() checks, with cpu_is_34xx() true for AM33xx. > > As I have done in the past initially, I recommend and vote for, > > 1. Creating separate family cpu_is_am33xx() for AM33xx device. > OR > 2. Bring it to omap44xx family, since prcm block is closer to omap4 > and not with omap3. Also, > > > Tony, > I will let tony make a decision on this. By the time, Tony makes his > decision, I will spend time to explore your (Kevin's below) branch. Just to summarize, I guess it's pretty obvious that we need cpu_is_am33xx here. In general work on getting rid of the cpu_is_xxxx checks as they are not safe to use with single zImage in initcalls. Tony ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [PATCH-V4 4/4] ARM: OMAP3+: am33xx: Add powerdomain & PRM support 2012-04-27 0:49 ` Kevin Hilman @ 2012-04-27 20:44 ` Kevin Hilman -1 siblings, 0 replies; 64+ messages in thread From: Kevin Hilman @ 2012-04-27 20:44 UTC (permalink / raw) To: Vaibhav Hiremath Cc: linux-omap, paul, b-cousson, tony, rnayak, Afzal Mohammed, linux-arm-kernel Kevin Hilman <khilman@ti.com> writes: [...] > I also don't like all the cpu_is* checking currently in omap_hwmod.c > (which is here before you added this) and have an idea on how to clean > it up, I should have a patch by tomorrow for this. That should help > adding am33xx support here without needing all the cpu_is* checking. Series just posted: http://marc.info/?l=linux-omap&m=133555727831379&w=2 Kevin ^ permalink raw reply [flat|nested] 64+ messages in thread
* [PATCH-V4 4/4] ARM: OMAP3+: am33xx: Add powerdomain & PRM support @ 2012-04-27 20:44 ` Kevin Hilman 0 siblings, 0 replies; 64+ messages in thread From: Kevin Hilman @ 2012-04-27 20:44 UTC (permalink / raw) To: linux-arm-kernel Kevin Hilman <khilman@ti.com> writes: [...] > I also don't like all the cpu_is* checking currently in omap_hwmod.c > (which is here before you added this) and have an idea on how to clean > it up, I should have a patch by tomorrow for this. That should help > adding am33xx support here without needing all the cpu_is* checking. Series just posted: http://marc.info/?l=linux-omap&m=133555727831379&w=2 Kevin ^ permalink raw reply [flat|nested] 64+ messages in thread
* RE: [PATCH-V4 0/4] ARM: OMAP2+: Add voltagedomain, powerdomain & PRM support for AM33XX device 2012-03-30 16:03 ` Vaibhav Hiremath @ 2012-03-30 16:22 ` Hiremath, Vaibhav -1 siblings, 0 replies; 64+ messages in thread From: Hiremath, Vaibhav @ 2012-03-30 16:22 UTC (permalink / raw) To: Hiremath, Vaibhav, linux-omap Cc: tony, Hilman, Kevin, paul, Nayak, Rajendra, Cousson, Benoit, linux-arm-kernel On Fri, Mar 30, 2012 at 21:33:51, Hiremath, Vaibhav wrote: > After some healthy discussion, now we have come to the conclusion and > decided to handle AM33XX PRM/CM part 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, > shortly I will submit similar patch for CM, clockdomain and clock-tree > support for AM33xx. > > This patch-series is created on top of "linux-omap/cleanup" branch, and > also gets applied to "linux-omap/master" branch. > The patches are also available at - > https://github.com/hvaibhav/am335x-linux/tree/am335x-prm-cm > Please use "am335x-upstream-staging" branch, to able to boot on BeagleBone board, due to missing clock & hwmod data. I am in the process of submitting these patches. Thanks, Vaibhav ^ permalink raw reply [flat|nested] 64+ messages in thread
* [PATCH-V4 0/4] ARM: OMAP2+: Add voltagedomain, powerdomain & PRM support for AM33XX device @ 2012-03-30 16:22 ` Hiremath, Vaibhav 0 siblings, 0 replies; 64+ messages in thread From: Hiremath, Vaibhav @ 2012-03-30 16:22 UTC (permalink / raw) To: linux-arm-kernel On Fri, Mar 30, 2012 at 21:33:51, Hiremath, Vaibhav wrote: > After some healthy discussion, now we have come to the conclusion and > decided to handle AM33XX PRM/CM part 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, > shortly I will submit similar patch for CM, clockdomain and clock-tree > support for AM33xx. > > This patch-series is created on top of "linux-omap/cleanup" branch, and > also gets applied to "linux-omap/master" branch. > The patches are also available at - > https://github.com/hvaibhav/am335x-linux/tree/am335x-prm-cm > Please use "am335x-upstream-staging" branch, to able to boot on BeagleBone board, due to missing clock & hwmod data. I am in the process of submitting these patches. Thanks, Vaibhav ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [PATCH-V4 0/4] ARM: OMAP2+: Add voltagedomain, powerdomain & PRM support for AM33XX device 2012-03-30 16:03 ` Vaibhav Hiremath @ 2012-04-12 8:26 ` Paul Walmsley -1 siblings, 0 replies; 64+ messages in thread From: Paul Walmsley @ 2012-04-12 8:26 UTC (permalink / raw) To: Vaibhav Hiremath Cc: linux-omap, tony, khilman, rnayak, b-cousson, linux-arm-kernel Hello Vaibhav, On Fri, 30 Mar 2012, Vaibhav Hiremath wrote: > After some healthy discussion, now we have come to the conclusion and > decided to handle AM33XX PRM/CM part separately; as AM33XX-PRCM module is > different than OMAP3 and OMAP4 architecture. Have been reviewing these patch sets here. Are these associated with any board file? I had to hand-apply several patch sets due to some differences in mach-omap2/io.c. Upon looking more closely, and looking at your GitHub branch: https://github.com/hvaibhav/am335x-linux/tree/am335x-prm-cm it seems that internally you've been modifying the AM3517 EVM board file to test the BeagleBone? But due to the init_early changes, this is presumably not going to work if we want to keep the AM3517EVM working -- is this your understanding as well? I'm kind of wondering how we're to test these... ... BTW, the branch that I'm experimenting with is at git://git.pwsan.com/linux-2.6 -- branch name 'am33xx_support_3.5' -- I am still reviewing the patches there. - Paul ^ permalink raw reply [flat|nested] 64+ messages in thread
* [PATCH-V4 0/4] ARM: OMAP2+: Add voltagedomain, powerdomain & PRM support for AM33XX device @ 2012-04-12 8:26 ` Paul Walmsley 0 siblings, 0 replies; 64+ messages in thread From: Paul Walmsley @ 2012-04-12 8:26 UTC (permalink / raw) To: linux-arm-kernel Hello Vaibhav, On Fri, 30 Mar 2012, Vaibhav Hiremath wrote: > After some healthy discussion, now we have come to the conclusion and > decided to handle AM33XX PRM/CM part separately; as AM33XX-PRCM module is > different than OMAP3 and OMAP4 architecture. Have been reviewing these patch sets here. Are these associated with any board file? I had to hand-apply several patch sets due to some differences in mach-omap2/io.c. Upon looking more closely, and looking at your GitHub branch: https://github.com/hvaibhav/am335x-linux/tree/am335x-prm-cm it seems that internally you've been modifying the AM3517 EVM board file to test the BeagleBone? But due to the init_early changes, this is presumably not going to work if we want to keep the AM3517EVM working -- is this your understanding as well? I'm kind of wondering how we're to test these... ... BTW, the branch that I'm experimenting with is at git://git.pwsan.com/linux-2.6 -- branch name 'am33xx_support_3.5' -- I am still reviewing the patches there. - Paul ^ permalink raw reply [flat|nested] 64+ messages in thread
* RE: [PATCH-V4 0/4] ARM: OMAP2+: Add voltagedomain, powerdomain & PRM support for AM33XX device 2012-04-12 8:26 ` Paul Walmsley @ 2012-04-13 10:36 ` Hiremath, Vaibhav -1 siblings, 0 replies; 64+ messages in thread From: Hiremath, Vaibhav @ 2012-04-13 10:36 UTC (permalink / raw) To: Paul Walmsley Cc: linux-omap, tony, Hilman, Kevin, Nayak, Rajendra, Cousson, Benoit, linux-arm-kernel On Thu, Apr 12, 2012 at 13:56:06, Paul Walmsley wrote: > Hello Vaibhav, > > On Fri, 30 Mar 2012, Vaibhav Hiremath wrote: > > > After some healthy discussion, now we have come to the conclusion and > > decided to handle AM33XX PRM/CM part separately; as AM33XX-PRCM module is > > different than OMAP3 and OMAP4 architecture. > > Have been reviewing these patch sets here. Are these associated with any > board file? I had to hand-apply several patch sets due to some > differences in mach-omap2/io.c. Upon looking more closely, and looking at > your GitHub branch: > > https://github.com/hvaibhav/am335x-linux/tree/am335x-prm-cm > > it seems that internally you've been modifying the AM3517 EVM board file > to test the BeagleBone? But due to the init_early changes, this is > presumably not going to work if we want to keep the AM3517EVM working -- > is this your understanding as well? > Yes, we are using am3517evm file for AM33XX MACHINE_INIT definition here. These patches have been reviewed and accepted in the list, only thing is they couldn't make it to upstream during v3.4 merge window. I believe Tony is going to push them for v3.5 now. > I'm kind of wondering how we're to test these... > I maintain multiple branches along with one superset branch in my gitorious tree, for example, currently I have, Individual features branches: ---------------------------- 32ksync-timer-cleanup : 32k timer cleanup am335x-baseport-for-tony : baseport patches (reviewed & accepted) am335x-prm-cm-hwmod : prm/cm/hwmod patches superset branch: --------------- am335x-upstream-staging: I merge all feature branches into this superset branch and one additional Patch, required to get beaglebone to boot. > ... > > BTW, the branch that I'm experimenting with is at > git://git.pwsan.com/linux-2.6 -- branch name 'am33xx_support_3.5' -- I am > still reviewing the patches there. > Thanks Paul, really appreciate your help here. I will take a look at this and let you know. Also, please let me know if you have any comments in the patch. I really want to target for v3.5 merge window, and atleast get all basic prm/cm/clock/hwmod things upstream. Thanks, Vaibhav > > - Paul > ^ permalink raw reply [flat|nested] 64+ messages in thread
* [PATCH-V4 0/4] ARM: OMAP2+: Add voltagedomain, powerdomain & PRM support for AM33XX device @ 2012-04-13 10:36 ` Hiremath, Vaibhav 0 siblings, 0 replies; 64+ messages in thread From: Hiremath, Vaibhav @ 2012-04-13 10:36 UTC (permalink / raw) To: linux-arm-kernel On Thu, Apr 12, 2012 at 13:56:06, Paul Walmsley wrote: > Hello Vaibhav, > > On Fri, 30 Mar 2012, Vaibhav Hiremath wrote: > > > After some healthy discussion, now we have come to the conclusion and > > decided to handle AM33XX PRM/CM part separately; as AM33XX-PRCM module is > > different than OMAP3 and OMAP4 architecture. > > Have been reviewing these patch sets here. Are these associated with any > board file? I had to hand-apply several patch sets due to some > differences in mach-omap2/io.c. Upon looking more closely, and looking at > your GitHub branch: > > https://github.com/hvaibhav/am335x-linux/tree/am335x-prm-cm > > it seems that internally you've been modifying the AM3517 EVM board file > to test the BeagleBone? But due to the init_early changes, this is > presumably not going to work if we want to keep the AM3517EVM working -- > is this your understanding as well? > Yes, we are using am3517evm file for AM33XX MACHINE_INIT definition here. These patches have been reviewed and accepted in the list, only thing is they couldn't make it to upstream during v3.4 merge window. I believe Tony is going to push them for v3.5 now. > I'm kind of wondering how we're to test these... > I maintain multiple branches along with one superset branch in my gitorious tree, for example, currently I have, Individual features branches: ---------------------------- 32ksync-timer-cleanup : 32k timer cleanup am335x-baseport-for-tony : baseport patches (reviewed & accepted) am335x-prm-cm-hwmod : prm/cm/hwmod patches superset branch: --------------- am335x-upstream-staging: I merge all feature branches into this superset branch and one additional Patch, required to get beaglebone to boot. > ... > > BTW, the branch that I'm experimenting with is at > git://git.pwsan.com/linux-2.6 -- branch name 'am33xx_support_3.5' -- I am > still reviewing the patches there. > Thanks Paul, really appreciate your help here. I will take a look at this and let you know. Also, please let me know if you have any comments in the patch. I really want to target for v3.5 merge window, and atleast get all basic prm/cm/clock/hwmod things upstream. Thanks, Vaibhav > > - Paul > ^ permalink raw reply [flat|nested] 64+ messages in thread
* RE: [PATCH-V4 0/4] ARM: OMAP2+: Add voltagedomain, powerdomain & PRM support for AM33XX device 2012-04-13 10:36 ` Hiremath, Vaibhav @ 2012-04-13 10:43 ` Paul Walmsley -1 siblings, 0 replies; 64+ messages in thread From: Paul Walmsley @ 2012-04-13 10:43 UTC (permalink / raw) To: Hiremath, Vaibhav Cc: linux-omap, tony, Hilman, Kevin, Nayak, Rajendra, Cousson, Benoit, linux-arm-kernel Hi Vaibhav, On Fri, 13 Apr 2012, Hiremath, Vaibhav wrote: > Yes, we are using am3517evm file for AM33XX MACHINE_INIT definition here. > These patches have been reviewed and accepted in the list, only thing is > they couldn't make it to upstream during v3.4 merge window. > > I believe Tony is going to push them for v3.5 now. Hmm, but if you modify the AM3517EVM board file to call am33xx_init_early(), won't that break the AM3517EVM board? Wouldn't a separate board file be needed for the AM33xx? - Paul ^ permalink raw reply [flat|nested] 64+ messages in thread
* [PATCH-V4 0/4] ARM: OMAP2+: Add voltagedomain, powerdomain & PRM support for AM33XX device @ 2012-04-13 10:43 ` Paul Walmsley 0 siblings, 0 replies; 64+ messages in thread From: Paul Walmsley @ 2012-04-13 10:43 UTC (permalink / raw) To: linux-arm-kernel Hi Vaibhav, On Fri, 13 Apr 2012, Hiremath, Vaibhav wrote: > Yes, we are using am3517evm file for AM33XX MACHINE_INIT definition here. > These patches have been reviewed and accepted in the list, only thing is > they couldn't make it to upstream during v3.4 merge window. > > I believe Tony is going to push them for v3.5 now. Hmm, but if you modify the AM3517EVM board file to call am33xx_init_early(), won't that break the AM3517EVM board? Wouldn't a separate board file be needed for the AM33xx? - Paul ^ permalink raw reply [flat|nested] 64+ messages in thread
* RE: [PATCH-V4 0/4] ARM: OMAP2+: Add voltagedomain, powerdomain & PRM support for AM33XX device 2012-04-13 10:43 ` Paul Walmsley @ 2012-04-16 7:18 ` Hiremath, Vaibhav -1 siblings, 0 replies; 64+ messages in thread From: Hiremath, Vaibhav @ 2012-04-16 7:18 UTC (permalink / raw) To: Paul Walmsley Cc: linux-omap, tony, Hilman, Kevin, Nayak, Rajendra, Cousson, Benoit, linux-arm-kernel On Fri, Apr 13, 2012 at 16:13:07, Paul Walmsley wrote: > Hi Vaibhav, > > On Fri, 13 Apr 2012, Hiremath, Vaibhav wrote: > > > Yes, we are using am3517evm file for AM33XX MACHINE_INIT definition here. > > These patches have been reviewed and accepted in the list, only thing is > > they couldn't make it to upstream during v3.4 merge window. > > > > I believe Tony is going to push them for v3.5 now. > > Hmm, but if you modify the AM3517EVM board file to call > am33xx_init_early(), won't that break the AM3517EVM board? > Wouldn't a separate board file be needed for the AM33xx? > Paul, It has been taken care of in Makefile, diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile index 49f92bc..f51ce0b 100644 --- a/arch/arm/mach-omap2/Makefile +++ b/arch/arm/mach-omap2/Makefile @@ -236,6 +236,7 @@ obj-$(CONFIG_MACH_CRANEBOARD) += board-am3517crane.o obj-$(CONFIG_MACH_SBC3530) += board-omap3stalker.o obj-$(CONFIG_MACH_TI8168EVM) += board-ti8168evm.o obj-$(CONFIG_MACH_TI8148EVM) += board-ti8168evm.o +obj-$(CONFIG_MACH_AM335XEVM) += board-am3517evm.o Thanks, Vaibhav > > - Paul > ^ permalink raw reply related [flat|nested] 64+ messages in thread
* [PATCH-V4 0/4] ARM: OMAP2+: Add voltagedomain, powerdomain & PRM support for AM33XX device @ 2012-04-16 7:18 ` Hiremath, Vaibhav 0 siblings, 0 replies; 64+ messages in thread From: Hiremath, Vaibhav @ 2012-04-16 7:18 UTC (permalink / raw) To: linux-arm-kernel On Fri, Apr 13, 2012 at 16:13:07, Paul Walmsley wrote: > Hi Vaibhav, > > On Fri, 13 Apr 2012, Hiremath, Vaibhav wrote: > > > Yes, we are using am3517evm file for AM33XX MACHINE_INIT definition here. > > These patches have been reviewed and accepted in the list, only thing is > > they couldn't make it to upstream during v3.4 merge window. > > > > I believe Tony is going to push them for v3.5 now. > > Hmm, but if you modify the AM3517EVM board file to call > am33xx_init_early(), won't that break the AM3517EVM board? > Wouldn't a separate board file be needed for the AM33xx? > Paul, It has been taken care of in Makefile, diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile index 49f92bc..f51ce0b 100644 --- a/arch/arm/mach-omap2/Makefile +++ b/arch/arm/mach-omap2/Makefile @@ -236,6 +236,7 @@ obj-$(CONFIG_MACH_CRANEBOARD) += board-am3517crane.o obj-$(CONFIG_MACH_SBC3530) += board-omap3stalker.o obj-$(CONFIG_MACH_TI8168EVM) += board-ti8168evm.o obj-$(CONFIG_MACH_TI8148EVM) += board-ti8168evm.o +obj-$(CONFIG_MACH_AM335XEVM) += board-am3517evm.o Thanks, Vaibhav > > - Paul > ^ permalink raw reply related [flat|nested] 64+ messages in thread
* Re: [PATCH-V4 0/4] ARM: OMAP2+: Add voltagedomain, powerdomain & PRM support for AM33XX device 2012-04-13 10:43 ` Paul Walmsley @ 2012-04-18 23:21 ` Tony Lindgren -1 siblings, 0 replies; 64+ messages in thread From: Tony Lindgren @ 2012-04-18 23:21 UTC (permalink / raw) To: Paul Walmsley Cc: Hiremath, Vaibhav, linux-omap, Hilman, Kevin, Nayak, Rajendra, Cousson, Benoit, linux-arm-kernel * Paul Walmsley <paul@pwsan.com> [120413 03:46]: > Hi Vaibhav, > > On Fri, 13 Apr 2012, Hiremath, Vaibhav wrote: > > > Yes, we are using am3517evm file for AM33XX MACHINE_INIT definition here. > > These patches have been reviewed and accepted in the list, only thing is > > they couldn't make it to upstream during v3.4 merge window. > > > > I believe Tony is going to push them for v3.5 now. > > Hmm, but if you modify the AM3517EVM board file to call > am33xx_init_early(), won't that break the AM3517EVM board? > Wouldn't a separate board file be needed for the AM33xx? You can have multiple MACHINE_START entries in a board-*.c file if that's what you're asking. Regards, Tony ^ permalink raw reply [flat|nested] 64+ messages in thread
* [PATCH-V4 0/4] ARM: OMAP2+: Add voltagedomain, powerdomain & PRM support for AM33XX device @ 2012-04-18 23:21 ` Tony Lindgren 0 siblings, 0 replies; 64+ messages in thread From: Tony Lindgren @ 2012-04-18 23:21 UTC (permalink / raw) To: linux-arm-kernel * Paul Walmsley <paul@pwsan.com> [120413 03:46]: > Hi Vaibhav, > > On Fri, 13 Apr 2012, Hiremath, Vaibhav wrote: > > > Yes, we are using am3517evm file for AM33XX MACHINE_INIT definition here. > > These patches have been reviewed and accepted in the list, only thing is > > they couldn't make it to upstream during v3.4 merge window. > > > > I believe Tony is going to push them for v3.5 now. > > Hmm, but if you modify the AM3517EVM board file to call > am33xx_init_early(), won't that break the AM3517EVM board? > Wouldn't a separate board file be needed for the AM33xx? You can have multiple MACHINE_START entries in a board-*.c file if that's what you're asking. Regards, Tony ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [PATCH-V4 0/4] ARM: OMAP2+: Add voltagedomain, powerdomain & PRM support for AM33XX device 2012-04-13 10:36 ` Hiremath, Vaibhav @ 2012-04-18 23:18 ` Tony Lindgren -1 siblings, 0 replies; 64+ messages in thread From: Tony Lindgren @ 2012-04-18 23:18 UTC (permalink / raw) To: Hiremath, Vaibhav Cc: Paul Walmsley, linux-omap, Hilman, Kevin, Nayak, Rajendra, Cousson, Benoit, linux-arm-kernel * Hiremath, Vaibhav <hvaibhav@ti.com> [120413 03:39]: > On Thu, Apr 12, 2012 at 13:56:06, Paul Walmsley wrote: > > Yes, we are using am3517evm file for AM33XX MACHINE_INIT definition here. > These patches have been reviewed and accepted in the list, only thing is > they couldn't make it to upstream during v3.4 merge window. > > I believe Tony is going to push them for v3.5 now. Hmm care to clarify which patches are you talking about here? Tony ^ permalink raw reply [flat|nested] 64+ messages in thread
* [PATCH-V4 0/4] ARM: OMAP2+: Add voltagedomain, powerdomain & PRM support for AM33XX device @ 2012-04-18 23:18 ` Tony Lindgren 0 siblings, 0 replies; 64+ messages in thread From: Tony Lindgren @ 2012-04-18 23:18 UTC (permalink / raw) To: linux-arm-kernel * Hiremath, Vaibhav <hvaibhav@ti.com> [120413 03:39]: > On Thu, Apr 12, 2012 at 13:56:06, Paul Walmsley wrote: > > Yes, we are using am3517evm file for AM33XX MACHINE_INIT definition here. > These patches have been reviewed and accepted in the list, only thing is > they couldn't make it to upstream during v3.4 merge window. > > I believe Tony is going to push them for v3.5 now. Hmm care to clarify which patches are you talking about here? Tony ^ permalink raw reply [flat|nested] 64+ messages in thread
* RE: [PATCH-V4 0/4] ARM: OMAP2+: Add voltagedomain, powerdomain & PRM support for AM33XX device 2012-04-18 23:18 ` Tony Lindgren @ 2012-04-23 18:28 ` Hiremath, Vaibhav -1 siblings, 0 replies; 64+ messages in thread From: Hiremath, Vaibhav @ 2012-04-23 18:28 UTC (permalink / raw) To: Tony Lindgren Cc: Paul Walmsley, linux-omap, Hilman, Kevin, Nayak, Rajendra, Cousson, Benoit, linux-arm-kernel On Thu, Apr 19, 2012 at 04:48:37, Tony Lindgren wrote: > * Hiremath, Vaibhav <hvaibhav@ti.com> [120413 03:39]: > > On Thu, Apr 12, 2012 at 13:56:06, Paul Walmsley wrote: > > > > Yes, we are using am3517evm file for AM33XX MACHINE_INIT definition here. > > These patches have been reviewed and accepted in the list, only thing is > > they couldn't make it to upstream during v3.4 merge window. > > > > I believe Tony is going to push them for v3.5 now. > > Hmm care to clarify which patches are you talking about here? > Tony, I was referring to initial 2 baseport patches which we have dropped due dependency on mach-types. arm:omap:am33xx: Add AM335XEVM machine support arm:omap:am33xx: Add low level debugging support One patch (which was independent) from this series, made its way to upstream, ARM: OMAP2+: id: Add am33xx SoC type detection Can you please make sure that, it gets included into your next pull request? Thanks, Vaibhav > Tony > ^ permalink raw reply [flat|nested] 64+ messages in thread
* [PATCH-V4 0/4] ARM: OMAP2+: Add voltagedomain, powerdomain & PRM support for AM33XX device @ 2012-04-23 18:28 ` Hiremath, Vaibhav 0 siblings, 0 replies; 64+ messages in thread From: Hiremath, Vaibhav @ 2012-04-23 18:28 UTC (permalink / raw) To: linux-arm-kernel On Thu, Apr 19, 2012 at 04:48:37, Tony Lindgren wrote: > * Hiremath, Vaibhav <hvaibhav@ti.com> [120413 03:39]: > > On Thu, Apr 12, 2012 at 13:56:06, Paul Walmsley wrote: > > > > Yes, we are using am3517evm file for AM33XX MACHINE_INIT definition here. > > These patches have been reviewed and accepted in the list, only thing is > > they couldn't make it to upstream during v3.4 merge window. > > > > I believe Tony is going to push them for v3.5 now. > > Hmm care to clarify which patches are you talking about here? > Tony, I was referring to initial 2 baseport patches which we have dropped due dependency on mach-types. arm:omap:am33xx: Add AM335XEVM machine support arm:omap:am33xx: Add low level debugging support One patch (which was independent) from this series, made its way to upstream, ARM: OMAP2+: id: Add am33xx SoC type detection Can you please make sure that, it gets included into your next pull request? Thanks, Vaibhav > Tony > ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [PATCH-V4 0/4] ARM: OMAP2+: Add voltagedomain, powerdomain & PRM support for AM33XX device 2012-04-23 18:28 ` Hiremath, Vaibhav @ 2012-04-26 18:43 ` Tony Lindgren -1 siblings, 0 replies; 64+ messages in thread From: Tony Lindgren @ 2012-04-26 18:43 UTC (permalink / raw) To: Hiremath, Vaibhav Cc: Paul Walmsley, linux-omap, Hilman, Kevin, Nayak, Rajendra, Cousson, Benoit, linux-arm-kernel * Hiremath, Vaibhav <hvaibhav@ti.com> [120423 11:31]: > On Thu, Apr 19, 2012 at 04:48:37, Tony Lindgren wrote: > > * Hiremath, Vaibhav <hvaibhav@ti.com> [120413 03:39]: > > > On Thu, Apr 12, 2012 at 13:56:06, Paul Walmsley wrote: > > > > > > Yes, we are using am3517evm file for AM33XX MACHINE_INIT definition here. > > > These patches have been reviewed and accepted in the list, only thing is > > > they couldn't make it to upstream during v3.4 merge window. > > > > > > I believe Tony is going to push them for v3.5 now. > > > > Hmm care to clarify which patches are you talking about here? > > > > Tony, > I was referring to initial 2 baseport patches which we have dropped due > dependency on mach-types. > > arm:omap:am33xx: Add AM335XEVM machine support > arm:omap:am33xx: Add low level debugging support Can you please repost these against current v3.4-rc4? > One patch (which was independent) from this series, made its way to upstream, > ARM: OMAP2+: id: Add am33xx SoC type detection OK > Can you please make sure that, it gets included into your next pull request? As far as I remember they looked OK for minimal board changes. Regards, Tony ^ permalink raw reply [flat|nested] 64+ messages in thread
* [PATCH-V4 0/4] ARM: OMAP2+: Add voltagedomain, powerdomain & PRM support for AM33XX device @ 2012-04-26 18:43 ` Tony Lindgren 0 siblings, 0 replies; 64+ messages in thread From: Tony Lindgren @ 2012-04-26 18:43 UTC (permalink / raw) To: linux-arm-kernel * Hiremath, Vaibhav <hvaibhav@ti.com> [120423 11:31]: > On Thu, Apr 19, 2012 at 04:48:37, Tony Lindgren wrote: > > * Hiremath, Vaibhav <hvaibhav@ti.com> [120413 03:39]: > > > On Thu, Apr 12, 2012 at 13:56:06, Paul Walmsley wrote: > > > > > > Yes, we are using am3517evm file for AM33XX MACHINE_INIT definition here. > > > These patches have been reviewed and accepted in the list, only thing is > > > they couldn't make it to upstream during v3.4 merge window. > > > > > > I believe Tony is going to push them for v3.5 now. > > > > Hmm care to clarify which patches are you talking about here? > > > > Tony, > I was referring to initial 2 baseport patches which we have dropped due > dependency on mach-types. > > arm:omap:am33xx: Add AM335XEVM machine support > arm:omap:am33xx: Add low level debugging support Can you please repost these against current v3.4-rc4? > One patch (which was independent) from this series, made its way to upstream, > ARM: OMAP2+: id: Add am33xx SoC type detection OK > Can you please make sure that, it gets included into your next pull request? As far as I remember they looked OK for minimal board changes. Regards, Tony ^ permalink raw reply [flat|nested] 64+ messages in thread
* RE: [PATCH-V4 0/4] ARM: OMAP2+: Add voltagedomain, powerdomain & PRM support for AM33XX device 2012-04-26 18:43 ` Tony Lindgren @ 2012-04-26 18:49 ` Hiremath, Vaibhav -1 siblings, 0 replies; 64+ messages in thread From: Hiremath, Vaibhav @ 2012-04-26 18:49 UTC (permalink / raw) To: Tony Lindgren Cc: Paul Walmsley, linux-omap, Hilman, Kevin, Nayak, Rajendra, Cousson, Benoit, linux-arm-kernel On Fri, Apr 27, 2012 at 00:13:13, Tony Lindgren wrote: > * Hiremath, Vaibhav <hvaibhav@ti.com> [120423 11:31]: > > On Thu, Apr 19, 2012 at 04:48:37, Tony Lindgren wrote: > > > * Hiremath, Vaibhav <hvaibhav@ti.com> [120413 03:39]: > > > > On Thu, Apr 12, 2012 at 13:56:06, Paul Walmsley wrote: > > > > > > > > Yes, we are using am3517evm file for AM33XX MACHINE_INIT definition here. > > > > These patches have been reviewed and accepted in the list, only thing is > > > > they couldn't make it to upstream during v3.4 merge window. > > > > > > > > I believe Tony is going to push them for v3.5 now. > > > > > > Hmm care to clarify which patches are you talking about here? > > > > > > > Tony, > > I was referring to initial 2 baseport patches which we have dropped due > > dependency on mach-types. > > > > arm:omap:am33xx: Add AM335XEVM machine support > > arm:omap:am33xx: Add low level debugging support > > Can you please repost these against current v3.4-rc4? > Ok, I will do that. > > One patch (which was independent) from this series, made its way to upstream, > > ARM: OMAP2+: id: Add am33xx SoC type detection > > OK > > > Can you please make sure that, it gets included into your next pull request? > > As far as I remember they looked OK for minimal board changes. > Yes, they were accepted and were also available under linux-omap/soc2 branch for quite some time. Thanks, Vaibhav ^ permalink raw reply [flat|nested] 64+ messages in thread
* [PATCH-V4 0/4] ARM: OMAP2+: Add voltagedomain, powerdomain & PRM support for AM33XX device @ 2012-04-26 18:49 ` Hiremath, Vaibhav 0 siblings, 0 replies; 64+ messages in thread From: Hiremath, Vaibhav @ 2012-04-26 18:49 UTC (permalink / raw) To: linux-arm-kernel On Fri, Apr 27, 2012 at 00:13:13, Tony Lindgren wrote: > * Hiremath, Vaibhav <hvaibhav@ti.com> [120423 11:31]: > > On Thu, Apr 19, 2012 at 04:48:37, Tony Lindgren wrote: > > > * Hiremath, Vaibhav <hvaibhav@ti.com> [120413 03:39]: > > > > On Thu, Apr 12, 2012 at 13:56:06, Paul Walmsley wrote: > > > > > > > > Yes, we are using am3517evm file for AM33XX MACHINE_INIT definition here. > > > > These patches have been reviewed and accepted in the list, only thing is > > > > they couldn't make it to upstream during v3.4 merge window. > > > > > > > > I believe Tony is going to push them for v3.5 now. > > > > > > Hmm care to clarify which patches are you talking about here? > > > > > > > Tony, > > I was referring to initial 2 baseport patches which we have dropped due > > dependency on mach-types. > > > > arm:omap:am33xx: Add AM335XEVM machine support > > arm:omap:am33xx: Add low level debugging support > > Can you please repost these against current v3.4-rc4? > Ok, I will do that. > > One patch (which was independent) from this series, made its way to upstream, > > ARM: OMAP2+: id: Add am33xx SoC type detection > > OK > > > Can you please make sure that, it gets included into your next pull request? > > As far as I remember they looked OK for minimal board changes. > Yes, they were accepted and were also available under linux-omap/soc2 branch for quite some time. Thanks, Vaibhav ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [PATCH-V4 0/4] ARM: OMAP2+: Add voltagedomain, powerdomain & PRM support for AM33XX device 2012-04-26 18:49 ` Hiremath, Vaibhav @ 2012-04-26 19:05 ` Tony Lindgren -1 siblings, 0 replies; 64+ messages in thread From: Tony Lindgren @ 2012-04-26 19:05 UTC (permalink / raw) To: Hiremath, Vaibhav Cc: Paul Walmsley, linux-omap, Hilman, Kevin, Nayak, Rajendra, Cousson, Benoit, linux-arm-kernel * Hiremath, Vaibhav <hvaibhav@ti.com> [120426 11:52]: > > Yes, they were accepted and were also available under linux-omap/soc2 branch > for quite some time. Hmm sorry if I've dropped them accidentally. I tend to drop the branches after each merge window and purge my linux-omap mailbox too. Regards, Tony ^ permalink raw reply [flat|nested] 64+ messages in thread
* [PATCH-V4 0/4] ARM: OMAP2+: Add voltagedomain, powerdomain & PRM support for AM33XX device @ 2012-04-26 19:05 ` Tony Lindgren 0 siblings, 0 replies; 64+ messages in thread From: Tony Lindgren @ 2012-04-26 19:05 UTC (permalink / raw) To: linux-arm-kernel * Hiremath, Vaibhav <hvaibhav@ti.com> [120426 11:52]: > > Yes, they were accepted and were also available under linux-omap/soc2 branch > for quite some time. Hmm sorry if I've dropped them accidentally. I tend to drop the branches after each merge window and purge my linux-omap mailbox too. Regards, Tony ^ permalink raw reply [flat|nested] 64+ messages in thread
* RE: [PATCH-V4 0/4] ARM: OMAP2+: Add voltagedomain, powerdomain & PRM support for AM33XX device 2012-04-26 19:05 ` Tony Lindgren @ 2012-04-27 8:53 ` Hiremath, Vaibhav -1 siblings, 0 replies; 64+ messages in thread From: Hiremath, Vaibhav @ 2012-04-27 8:53 UTC (permalink / raw) To: Tony Lindgren Cc: Paul Walmsley, linux-omap, Hilman, Kevin, Nayak, Rajendra, Cousson, Benoit, linux-arm-kernel On Fri, Apr 27, 2012 at 00:35:25, Tony Lindgren wrote: > * Hiremath, Vaibhav <hvaibhav@ti.com> [120426 11:52]: > > > > Yes, they were accepted and were also available under linux-omap/soc2 branch > > for quite some time. > > Hmm sorry if I've dropped them accidentally. I tend to drop the branches > after each merge window and purge my linux-omap mailbox too. > I can understand, I will submit another version for this. I will be waiting for your comment and conformation on, which family AM33xx device should fall in? Please refer to the mail-chain - http://www.mail-archive.com/linux-omap@vger.kernel.org/msg67275.html Thanks, Vaibhav ^ permalink raw reply [flat|nested] 64+ messages in thread
* [PATCH-V4 0/4] ARM: OMAP2+: Add voltagedomain, powerdomain & PRM support for AM33XX device @ 2012-04-27 8:53 ` Hiremath, Vaibhav 0 siblings, 0 replies; 64+ messages in thread From: Hiremath, Vaibhav @ 2012-04-27 8:53 UTC (permalink / raw) To: linux-arm-kernel On Fri, Apr 27, 2012 at 00:35:25, Tony Lindgren wrote: > * Hiremath, Vaibhav <hvaibhav@ti.com> [120426 11:52]: > > > > Yes, they were accepted and were also available under linux-omap/soc2 branch > > for quite some time. > > Hmm sorry if I've dropped them accidentally. I tend to drop the branches > after each merge window and purge my linux-omap mailbox too. > I can understand, I will submit another version for this. I will be waiting for your comment and conformation on, which family AM33xx device should fall in? Please refer to the mail-chain - http://www.mail-archive.com/linux-omap at vger.kernel.org/msg67275.html Thanks, Vaibhav ^ permalink raw reply [flat|nested] 64+ messages in thread
* RE: [PATCH-V4 0/4] ARM: OMAP2+: Add voltagedomain, powerdomain & PRM support for AM33XX device 2012-04-27 8:53 ` Hiremath, Vaibhav @ 2012-05-02 9:09 ` Paul Walmsley -1 siblings, 0 replies; 64+ messages in thread From: Paul Walmsley @ 2012-05-02 9:09 UTC (permalink / raw) To: Hiremath, Vaibhav Cc: Tony Lindgren, linux-omap, Hilman, Kevin, Nayak, Rajendra, Cousson, Benoit, linux-arm-kernel On Fri, 27 Apr 2012, Hiremath, Vaibhav wrote: > I will be waiting for your comment and conformation on, which family AM33xx > device should fall in? Please refer to the mail-chain - > > http://www.mail-archive.com/linux-omap@vger.kernel.org/msg67275.html This decision turns out to be pretty important; it certainly affects the AM33xx PRM/CM/clockdomain/powerdomain patches that I've been looking at. Here is my suggestion, based on our previous practice. I am not so sure that it is the best way, but it seems pretty reasonable" Using CONFIG_ARCH_OMAP3 for CONFIG_ARCH_OMAPAM33XX doesn't make sense, as far as I can tell. The main area of similarity between the other CONFIG_ARCH_OMAP3 and AM33xx is the Cortex-A8. And even that MPU subsystem is quite different between, say, the 3430/3630 and the AM33xx. Most of the AM33xx is quite different from the 3430/3630: OMAP4-style PRCM interface, OMAP4-style interconnect, etc. Plus, most of the CONFIG_ARCH_OMAP3 code in our codebase is very 3430/3630-specific, like the PM code. This would seem to suggest that we should use CONFIG_ARCH_OMAP4. But that option currently assumes an OMAP4-style MPU subsystem: SMP Cortex-A9, PL310, etc. None of that is true for AM335x. So first we have to decide whether the CONFIG_ARCH_OMAP* options should have a strong dependency on the MPU type, as they currently do; or whether they should focus on the way the SoC is integrated. If we take the former option, then we should add a new CONFIG_ARCH_OMAPAM33XX Kconfig option to arch/arm/Makefile, at the same level as CONFIG_ARCH_OMAP1/2/3/4. Similarly, we should add a CONFIG_ARCH_OMAPTI81XX Kconfig option. However, if we take the second option, then we can probably shoehorn the AM33XX and the TI81xx chips into CONFIG_ARCH_OMAP4. Either way, it would be good to get AM33xx and TI81xx out of CONFIG_ARCH_OMAP3, since keeping them there will require lots of changes across the codebase to stop using CONFIG_ARCH_OMAP3 and use the CONFIG_SOC_* Kconfig options instead. - Paul ^ permalink raw reply [flat|nested] 64+ messages in thread
* [PATCH-V4 0/4] ARM: OMAP2+: Add voltagedomain, powerdomain & PRM support for AM33XX device @ 2012-05-02 9:09 ` Paul Walmsley 0 siblings, 0 replies; 64+ messages in thread From: Paul Walmsley @ 2012-05-02 9:09 UTC (permalink / raw) To: linux-arm-kernel On Fri, 27 Apr 2012, Hiremath, Vaibhav wrote: > I will be waiting for your comment and conformation on, which family AM33xx > device should fall in? Please refer to the mail-chain - > > http://www.mail-archive.com/linux-omap at vger.kernel.org/msg67275.html This decision turns out to be pretty important; it certainly affects the AM33xx PRM/CM/clockdomain/powerdomain patches that I've been looking at. Here is my suggestion, based on our previous practice. I am not so sure that it is the best way, but it seems pretty reasonable" Using CONFIG_ARCH_OMAP3 for CONFIG_ARCH_OMAPAM33XX doesn't make sense, as far as I can tell. The main area of similarity between the other CONFIG_ARCH_OMAP3 and AM33xx is the Cortex-A8. And even that MPU subsystem is quite different between, say, the 3430/3630 and the AM33xx. Most of the AM33xx is quite different from the 3430/3630: OMAP4-style PRCM interface, OMAP4-style interconnect, etc. Plus, most of the CONFIG_ARCH_OMAP3 code in our codebase is very 3430/3630-specific, like the PM code. This would seem to suggest that we should use CONFIG_ARCH_OMAP4. But that option currently assumes an OMAP4-style MPU subsystem: SMP Cortex-A9, PL310, etc. None of that is true for AM335x. So first we have to decide whether the CONFIG_ARCH_OMAP* options should have a strong dependency on the MPU type, as they currently do; or whether they should focus on the way the SoC is integrated. If we take the former option, then we should add a new CONFIG_ARCH_OMAPAM33XX Kconfig option to arch/arm/Makefile, at the same level as CONFIG_ARCH_OMAP1/2/3/4. Similarly, we should add a CONFIG_ARCH_OMAPTI81XX Kconfig option. However, if we take the second option, then we can probably shoehorn the AM33XX and the TI81xx chips into CONFIG_ARCH_OMAP4. Either way, it would be good to get AM33xx and TI81xx out of CONFIG_ARCH_OMAP3, since keeping them there will require lots of changes across the codebase to stop using CONFIG_ARCH_OMAP3 and use the CONFIG_SOC_* Kconfig options instead. - Paul ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [PATCH-V4 0/4] ARM: OMAP2+: Add voltagedomain, powerdomain & PRM support for AM33XX device 2012-05-02 9:09 ` Paul Walmsley @ 2012-05-07 10:32 ` Cousson, Benoit -1 siblings, 0 replies; 64+ messages in thread From: Cousson, Benoit @ 2012-05-07 10:32 UTC (permalink / raw) To: Paul Walmsley Cc: Hiremath, Vaibhav, Tony Lindgren, linux-omap, Hilman, Kevin, Nayak, Rajendra, linux-arm-kernel Hi Paul, On 5/2/2012 11:09 AM, Paul Walmsley wrote: > On Fri, 27 Apr 2012, Hiremath, Vaibhav wrote: > >> I will be waiting for your comment and conformation on, which family AM33xx >> device should fall in? Please refer to the mail-chain - >> >> http://www.mail-archive.com/linux-omap@vger.kernel.org/msg67275.html > > This decision turns out to be pretty important; it certainly affects the > AM33xx PRM/CM/clockdomain/powerdomain patches that I've been looking at. > > Here is my suggestion, based on our previous practice. I am not so > sure that it is the best way, but it seems pretty reasonable" > > Using CONFIG_ARCH_OMAP3 for CONFIG_ARCH_OMAPAM33XX doesn't make sense, as > far as I can tell. The main area of similarity between the other > CONFIG_ARCH_OMAP3 and AM33xx is the Cortex-A8. And even that MPU > subsystem is quite different between, say, the 3430/3630 and the AM33xx. > Most of the AM33xx is quite different from the 3430/3630: OMAP4-style PRCM > interface, OMAP4-style interconnect, etc. Plus, most of the > CONFIG_ARCH_OMAP3 code in our codebase is very 3430/3630-specific, like > the PM code. > > This would seem to suggest that we should use CONFIG_ARCH_OMAP4. But that > option currently assumes an OMAP4-style MPU subsystem: SMP Cortex-A9, > PL310, etc. None of that is true for AM335x. > > So first we have to decide whether the CONFIG_ARCH_OMAP* options should > have a strong dependency on the MPU type, as they currently do; or whether > they should focus on the way the SoC is integrated. I think as well that these devices should be considered as part of the OMAP4 family. The CPU type should not be the parameter that decide the OMAP family, it is just an IP, that can change on some variant, whereas the whole PRCM infrastructure / interconnect is mostly the same. Regards, Benoit ^ permalink raw reply [flat|nested] 64+ messages in thread
* [PATCH-V4 0/4] ARM: OMAP2+: Add voltagedomain, powerdomain & PRM support for AM33XX device @ 2012-05-07 10:32 ` Cousson, Benoit 0 siblings, 0 replies; 64+ messages in thread From: Cousson, Benoit @ 2012-05-07 10:32 UTC (permalink / raw) To: linux-arm-kernel Hi Paul, On 5/2/2012 11:09 AM, Paul Walmsley wrote: > On Fri, 27 Apr 2012, Hiremath, Vaibhav wrote: > >> I will be waiting for your comment and conformation on, which family AM33xx >> device should fall in? Please refer to the mail-chain - >> >> http://www.mail-archive.com/linux-omap at vger.kernel.org/msg67275.html > > This decision turns out to be pretty important; it certainly affects the > AM33xx PRM/CM/clockdomain/powerdomain patches that I've been looking at. > > Here is my suggestion, based on our previous practice. I am not so > sure that it is the best way, but it seems pretty reasonable" > > Using CONFIG_ARCH_OMAP3 for CONFIG_ARCH_OMAPAM33XX doesn't make sense, as > far as I can tell. The main area of similarity between the other > CONFIG_ARCH_OMAP3 and AM33xx is the Cortex-A8. And even that MPU > subsystem is quite different between, say, the 3430/3630 and the AM33xx. > Most of the AM33xx is quite different from the 3430/3630: OMAP4-style PRCM > interface, OMAP4-style interconnect, etc. Plus, most of the > CONFIG_ARCH_OMAP3 code in our codebase is very 3430/3630-specific, like > the PM code. > > This would seem to suggest that we should use CONFIG_ARCH_OMAP4. But that > option currently assumes an OMAP4-style MPU subsystem: SMP Cortex-A9, > PL310, etc. None of that is true for AM335x. > > So first we have to decide whether the CONFIG_ARCH_OMAP* options should > have a strong dependency on the MPU type, as they currently do; or whether > they should focus on the way the SoC is integrated. I think as well that these devices should be considered as part of the OMAP4 family. The CPU type should not be the parameter that decide the OMAP family, it is just an IP, that can change on some variant, whereas the whole PRCM infrastructure / interconnect is mostly the same. Regards, Benoit ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [PATCH-V4 0/4] ARM: OMAP2+: Add voltagedomain, powerdomain & PRM support for AM33XX device 2012-05-07 10:32 ` Cousson, Benoit @ 2012-05-07 10:44 ` Shilimkar, Santosh -1 siblings, 0 replies; 64+ messages in thread From: Shilimkar, Santosh @ 2012-05-07 10:44 UTC (permalink / raw) To: Cousson, Benoit Cc: Paul Walmsley, Hiremath, Vaibhav, Tony Lindgren, linux-omap, Hilman, Kevin, Nayak, Rajendra, linux-arm-kernel On Mon, May 7, 2012 at 4:02 PM, Cousson, Benoit <b-cousson@ti.com> wrote: > Hi Paul, > > > On 5/2/2012 11:09 AM, Paul Walmsley wrote: >> >> On Fri, 27 Apr 2012, Hiremath, Vaibhav wrote: >> >>> I will be waiting for your comment and conformation on, which family >>> AM33xx >>> device should fall in? Please refer to the mail-chain - >>> >>> http://www.mail-archive.com/linux-omap@vger.kernel.org/msg67275.html >> >> >> This decision turns out to be pretty important; it certainly affects the >> AM33xx PRM/CM/clockdomain/powerdomain patches that I've been looking at. >> >> Here is my suggestion, based on our previous practice. I am not so >> sure that it is the best way, but it seems pretty reasonable" >> >> Using CONFIG_ARCH_OMAP3 for CONFIG_ARCH_OMAPAM33XX doesn't make sense, as >> far as I can tell. The main area of similarity between the other >> CONFIG_ARCH_OMAP3 and AM33xx is the Cortex-A8. And even that MPU >> subsystem is quite different between, say, the 3430/3630 and the AM33xx. >> Most of the AM33xx is quite different from the 3430/3630: OMAP4-style PRCM >> interface, OMAP4-style interconnect, etc. Plus, most of the >> CONFIG_ARCH_OMAP3 code in our codebase is very 3430/3630-specific, like >> the PM code. >> >> This would seem to suggest that we should use CONFIG_ARCH_OMAP4. But that >> option currently assumes an OMAP4-style MPU subsystem: SMP Cortex-A9, >> PL310, etc. None of that is true for AM335x. >> >> So first we have to decide whether the CONFIG_ARCH_OMAP* options should >> have a strong dependency on the MPU type, as they currently do; or whether >> they should focus on the way the SoC is integrated. > > > I think as well that these devices should be considered as part of the OMAP4 > family. > The CPU type should not be the parameter that decide the OMAP family, it is > just an IP, that can change on some variant, whereas the whole PRCM > infrastructure / interconnect is mostly the same. > I agree. In fact more and more I think of this problem, looks like we should get rid off ARCH_OMAP* and just is SOC_* going forward. Common ARM code already takes care of different CPU version and as Benoit mentioned it is just one of the IP in the entire SOC. I saw tony commenting in similarly on of the patch set. Regards Santosh -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 64+ messages in thread
* [PATCH-V4 0/4] ARM: OMAP2+: Add voltagedomain, powerdomain & PRM support for AM33XX device @ 2012-05-07 10:44 ` Shilimkar, Santosh 0 siblings, 0 replies; 64+ messages in thread From: Shilimkar, Santosh @ 2012-05-07 10:44 UTC (permalink / raw) To: linux-arm-kernel On Mon, May 7, 2012 at 4:02 PM, Cousson, Benoit <b-cousson@ti.com> wrote: > Hi Paul, > > > On 5/2/2012 11:09 AM, Paul Walmsley wrote: >> >> On Fri, 27 Apr 2012, Hiremath, Vaibhav wrote: >> >>> I will be waiting for your comment and conformation on, which family >>> AM33xx >>> device should fall in? Please refer to the mail-chain - >>> >>> http://www.mail-archive.com/linux-omap at vger.kernel.org/msg67275.html >> >> >> This decision turns out to be pretty important; it certainly affects the >> AM33xx PRM/CM/clockdomain/powerdomain patches that I've been looking at. >> >> Here is my suggestion, based on our previous practice. ?I am not so >> sure that it is the best way, but it seems pretty reasonable" >> >> Using CONFIG_ARCH_OMAP3 for CONFIG_ARCH_OMAPAM33XX doesn't make sense, as >> far as I can tell. ?The main area of similarity between the other >> CONFIG_ARCH_OMAP3 and AM33xx is the Cortex-A8. ?And even that MPU >> subsystem is quite different between, say, the 3430/3630 and the AM33xx. >> Most of the AM33xx is quite different from the 3430/3630: OMAP4-style PRCM >> interface, OMAP4-style interconnect, etc. ?Plus, most of the >> CONFIG_ARCH_OMAP3 code in our codebase is very 3430/3630-specific, like >> the PM code. >> >> This would seem to suggest that we should use CONFIG_ARCH_OMAP4. ?But that >> option currently assumes an OMAP4-style MPU subsystem: SMP Cortex-A9, >> PL310, etc. ?None of that is true for AM335x. >> >> So first we have to decide whether the CONFIG_ARCH_OMAP* options should >> have a strong dependency on the MPU type, as they currently do; or whether >> they should focus on the way the SoC is integrated. > > > I think as well that these devices should be considered as part of the OMAP4 > family. > The CPU type should not be the parameter that decide the OMAP family, it is > just an IP, that can change on some variant, whereas the whole PRCM > infrastructure / interconnect is mostly the same. > I agree. In fact more and more I think of this problem, looks like we should get rid off ARCH_OMAP* and just is SOC_* going forward. Common ARM code already takes care of different CPU version and as Benoit mentioned it is just one of the IP in the entire SOC. I saw tony commenting in similarly on of the patch set. Regards Santosh ^ permalink raw reply [flat|nested] 64+ messages in thread
* RE: [PATCH-V4 0/4] ARM: OMAP2+: Add voltagedomain, powerdomain & PRM support for AM33XX device 2012-05-07 10:44 ` Shilimkar, Santosh @ 2012-05-07 13:59 ` Hiremath, Vaibhav -1 siblings, 0 replies; 64+ messages in thread From: Hiremath, Vaibhav @ 2012-05-07 13:59 UTC (permalink / raw) To: Shilimkar, Santosh, Cousson, Benoit Cc: Paul Walmsley, Tony Lindgren, linux-omap, Hilman, Kevin, Nayak, Rajendra, linux-arm-kernel On Mon, May 07, 2012 at 16:14:42, Shilimkar, Santosh wrote: > On Mon, May 7, 2012 at 4:02 PM, Cousson, Benoit <b-cousson@ti.com> wrote: > > Hi Paul, > > > > > > On 5/2/2012 11:09 AM, Paul Walmsley wrote: > >> > >> On Fri, 27 Apr 2012, Hiremath, Vaibhav wrote: > >> <snip> > >> So first we have to decide whether the CONFIG_ARCH_OMAP* options should > >> have a strong dependency on the MPU type, as they currently do; or whether > >> they should focus on the way the SoC is integrated. > > > > > > I think as well that these devices should be considered as part of the OMAP4 > > family. > > The CPU type should not be the parameter that decide the OMAP family, it is > > just an IP, that can change on some variant, whereas the whole PRCM > > infrastructure / interconnect is mostly the same. > > > I agree. In fact more and more I think of this problem, looks like we > should get rid > off ARCH_OMAP* and just is SOC_* going forward. > > Common ARM code already takes care of different CPU version and as Benoit > mentioned it is just one of the IP in the entire SOC. I saw tony commenting > in similarly on of the patch set. > I am working on creating patch-sets for am33xx device on the same direction, that means, am33xx will not fallow, neither ARCH_OMAP3 nor ARCH_OMAP4. am33xx will be separate device under ARCH_OMAP2PLUS, with "SOC_OMAPAM33XX". This also means, neither cpu_is_omap34xx() not cpu_is_omap44xx() will be true for am33xx. We will have separate cpu_is_am33xx() class for this. Shortly I will submit patch-series for this. Just FYI, I have some cleanup patches, which actually tries to cleanup some of the existing ARCH_OMAPx dependency in code, making addition of devices easier under ARCH_OMAP2PLUS. Thanks, Vaibhav ^ permalink raw reply [flat|nested] 64+ messages in thread
* [PATCH-V4 0/4] ARM: OMAP2+: Add voltagedomain, powerdomain & PRM support for AM33XX device @ 2012-05-07 13:59 ` Hiremath, Vaibhav 0 siblings, 0 replies; 64+ messages in thread From: Hiremath, Vaibhav @ 2012-05-07 13:59 UTC (permalink / raw) To: linux-arm-kernel On Mon, May 07, 2012 at 16:14:42, Shilimkar, Santosh wrote: > On Mon, May 7, 2012 at 4:02 PM, Cousson, Benoit <b-cousson@ti.com> wrote: > > Hi Paul, > > > > > > On 5/2/2012 11:09 AM, Paul Walmsley wrote: > >> > >> On Fri, 27 Apr 2012, Hiremath, Vaibhav wrote: > >> <snip> > >> So first we have to decide whether the CONFIG_ARCH_OMAP* options should > >> have a strong dependency on the MPU type, as they currently do; or whether > >> they should focus on the way the SoC is integrated. > > > > > > I think as well that these devices should be considered as part of the OMAP4 > > family. > > The CPU type should not be the parameter that decide the OMAP family, it is > > just an IP, that can change on some variant, whereas the whole PRCM > > infrastructure / interconnect is mostly the same. > > > I agree. In fact more and more I think of this problem, looks like we > should get rid > off ARCH_OMAP* and just is SOC_* going forward. > > Common ARM code already takes care of different CPU version and as Benoit > mentioned it is just one of the IP in the entire SOC. I saw tony commenting > in similarly on of the patch set. > I am working on creating patch-sets for am33xx device on the same direction, that means, am33xx will not fallow, neither ARCH_OMAP3 nor ARCH_OMAP4. am33xx will be separate device under ARCH_OMAP2PLUS, with "SOC_OMAPAM33XX". This also means, neither cpu_is_omap34xx() not cpu_is_omap44xx() will be true for am33xx. We will have separate cpu_is_am33xx() class for this. Shortly I will submit patch-series for this. Just FYI, I have some cleanup patches, which actually tries to cleanup some of the existing ARCH_OMAPx dependency in code, making addition of devices easier under ARCH_OMAP2PLUS. Thanks, Vaibhav ^ permalink raw reply [flat|nested] 64+ messages in thread
* RE: [PATCH-V4 0/4] ARM: OMAP2+: Add voltagedomain, powerdomain & PRM support for AM33XX device 2012-04-26 18:49 ` Hiremath, Vaibhav @ 2012-05-02 9:30 ` Paul Walmsley -1 siblings, 0 replies; 64+ messages in thread From: Paul Walmsley @ 2012-05-02 9:30 UTC (permalink / raw) To: Hiremath, Vaibhav Cc: Tony Lindgren, linux-omap, Hilman, Kevin, Nayak, Rajendra, Cousson, Benoit, linux-arm-kernel Hello Vaibhav, I've reworked these patches somewhat to separate the PRM and CM changes into their own patches. Also, the omap_hwmod changes have been separated and moved into a different series, as have the clock tree changes. So now, pending for 3.5, there are the SCM, voltagedomain, PRM, CM, powerdomain, and clockdomain changes. Under the (probably incorrect) assumption that Tony will opt to create a CONFIG_ARCH_OMAPAM33XX, you might wish to take a look at the 'am33xx_prcm_devel_3.5' branch of git://git.pwsan.com/linux-2.6. It is based on four patches, not yet upstream, which create the appropriate board file, Kconfig options, etc. Once we're able to reach a conclusion as to which of the CONFIG_ARCH_OMAP* options the AM33xx belongs under, this branch will be updated and reposted, and if everyone is happy with it, proposed for pulling. - Paul ^ permalink raw reply [flat|nested] 64+ messages in thread
* [PATCH-V4 0/4] ARM: OMAP2+: Add voltagedomain, powerdomain & PRM support for AM33XX device @ 2012-05-02 9:30 ` Paul Walmsley 0 siblings, 0 replies; 64+ messages in thread From: Paul Walmsley @ 2012-05-02 9:30 UTC (permalink / raw) To: linux-arm-kernel Hello Vaibhav, I've reworked these patches somewhat to separate the PRM and CM changes into their own patches. Also, the omap_hwmod changes have been separated and moved into a different series, as have the clock tree changes. So now, pending for 3.5, there are the SCM, voltagedomain, PRM, CM, powerdomain, and clockdomain changes. Under the (probably incorrect) assumption that Tony will opt to create a CONFIG_ARCH_OMAPAM33XX, you might wish to take a look at the 'am33xx_prcm_devel_3.5' branch of git://git.pwsan.com/linux-2.6. It is based on four patches, not yet upstream, which create the appropriate board file, Kconfig options, etc. Once we're able to reach a conclusion as to which of the CONFIG_ARCH_OMAP* options the AM33xx belongs under, this branch will be updated and reposted, and if everyone is happy with it, proposed for pulling. - Paul ^ permalink raw reply [flat|nested] 64+ messages in thread
* RE: [PATCH-V4 0/4] ARM: OMAP2+: Add voltagedomain, powerdomain & PRM support for AM33XX device 2012-05-02 9:30 ` Paul Walmsley @ 2012-05-02 9:37 ` Hiremath, Vaibhav -1 siblings, 0 replies; 64+ messages in thread From: Hiremath, Vaibhav @ 2012-05-02 9:37 UTC (permalink / raw) To: Paul Walmsley Cc: Tony Lindgren, linux-omap, Hilman, Kevin, Nayak, Rajendra, Cousson, Benoit, linux-arm-kernel On Wed, May 02, 2012 at 15:00:28, Paul Walmsley wrote: > > Hello Vaibhav, > > I've reworked these patches somewhat to separate the PRM and CM changes > into their own patches. Also, the omap_hwmod changes have been separated > and moved into a different series, as have the clock tree changes. > > So now, pending for 3.5, there are the SCM, voltagedomain, PRM, CM, > powerdomain, and clockdomain changes. Under the (probably incorrect) > assumption that Tony will opt to create a CONFIG_ARCH_OMAPAM33XX, you > might wish to take a look at the 'am33xx_prcm_devel_3.5' branch of > git://git.pwsan.com/linux-2.6. It is based on four patches, not yet > upstream, which create the appropriate board file, Kconfig options, etc. > > Once we're able to reach a conclusion as to which of the CONFIG_ARCH_OMAP* > options the AM33xx belongs under, this branch will be updated and > reposted, and if everyone is happy with it, proposed for pulling. > > Sounds Great and Thanks a lot Paul. I will look at the above branch and update you if I find something wrong/missing. Thanks, Vaibhav ^ permalink raw reply [flat|nested] 64+ messages in thread
* [PATCH-V4 0/4] ARM: OMAP2+: Add voltagedomain, powerdomain & PRM support for AM33XX device @ 2012-05-02 9:37 ` Hiremath, Vaibhav 0 siblings, 0 replies; 64+ messages in thread From: Hiremath, Vaibhav @ 2012-05-02 9:37 UTC (permalink / raw) To: linux-arm-kernel On Wed, May 02, 2012 at 15:00:28, Paul Walmsley wrote: > > Hello Vaibhav, > > I've reworked these patches somewhat to separate the PRM and CM changes > into their own patches. Also, the omap_hwmod changes have been separated > and moved into a different series, as have the clock tree changes. > > So now, pending for 3.5, there are the SCM, voltagedomain, PRM, CM, > powerdomain, and clockdomain changes. Under the (probably incorrect) > assumption that Tony will opt to create a CONFIG_ARCH_OMAPAM33XX, you > might wish to take a look at the 'am33xx_prcm_devel_3.5' branch of > git://git.pwsan.com/linux-2.6. It is based on four patches, not yet > upstream, which create the appropriate board file, Kconfig options, etc. > > Once we're able to reach a conclusion as to which of the CONFIG_ARCH_OMAP* > options the AM33xx belongs under, this branch will be updated and > reposted, and if everyone is happy with it, proposed for pulling. > > Sounds Great and Thanks a lot Paul. I will look at the above branch and update you if I find something wrong/missing. Thanks, Vaibhav ^ permalink raw reply [flat|nested] 64+ messages in thread
* RE: [PATCH-V4 0/4] ARM: OMAP2+: Add voltagedomain, powerdomain & PRM support for AM33XX device 2012-05-02 9:30 ` Paul Walmsley @ 2012-05-03 14:44 ` Hiremath, Vaibhav -1 siblings, 0 replies; 64+ messages in thread From: Hiremath, Vaibhav @ 2012-05-03 14:44 UTC (permalink / raw) To: Paul Walmsley Cc: Tony Lindgren, linux-omap, Hilman, Kevin, Nayak, Rajendra, Cousson, Benoit, linux-arm-kernel On Wed, May 02, 2012 at 15:00:28, Paul Walmsley wrote: > > Hello Vaibhav, > > I've reworked these patches somewhat to separate the PRM and CM changes > into their own patches. Also, the omap_hwmod changes have been separated > and moved into a different series, as have the clock tree changes. > > So now, pending for 3.5, there are the SCM, voltagedomain, PRM, CM, > powerdomain, and clockdomain changes. Under the (probably incorrect) > assumption that Tony will opt to create a CONFIG_ARCH_OMAPAM33XX, you > might wish to take a look at the 'am33xx_prcm_devel_3.5' branch of > git://git.pwsan.com/linux-2.6. It is based on four patches, not yet > upstream, which create the appropriate board file, Kconfig options, etc. > > Once we're able to reach a conclusion as to which of the CONFIG_ARCH_OMAP* > options the AM33xx belongs under, this branch will be updated and > reposted, and if everyone is happy with it, proposed for pulling. > Hi Paul, I have reviewed the "am33xx_prcm_devel_3.5" branch for AM33xx support, and below are few comments I have, 1) ARM: add CONFIG_ARCH_OMAP{AM33XX,TI81XX} Description talks about TI81xx as well, but patch is created only for AM33xx. Isn't same entry should be created for TI81xx in the patch? 2) ARM: OMAP: AM335x: add Kconfig, Makefile glue for CONFIG_ARCH_OMAPAM33XX Looks ok to me. (Acked-by: Vaibhav Hiremath <hvaibhav@ti.com>) 3) ARM: OMAP: AM33xx: Add AM335XEVM machine support Looks ok to me. 4) arm:omap:am33xx: Add low level debugging support Subject line need to change to match it with our convention. ARM: OMAP: am33xx: Add low level debugging support 5) ARM: OMAP2+: control: Add AM33XX control reg & sec clkctrl offset Looks ok to me. 6) ARM: OMAP3+: am33xx: Add voltage domain data Remove multiple entries for voltagedomain-common.o for AM33xx diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile index cc44ea9..3b953c7 100644 --- a/arch/arm/mach-omap2/Makefile +++ b/arch/arm/mach-omap2/Makefile @@ -109,7 +109,6 @@ obj-$(CONFIG_SOC_OMAPAM33XX) += $(voltagedomain-common) \ voltagedomains33xx_data.o obj-$(CONFIG_ARCH_OMAP4) += $(voltagedomain-common) \ voltagedomains44xx_data.o -obj-$(CONFIG_ARCH_OMAPAM33XX) += $(voltagedomain-common) 7) ARM: OMAP3+: am33xx: add PRM support Remove multiple entries for prcm.o for AM33xx diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile index 3b953c7..ae1399b 100644 --- a/arch/arm/mach-omap2/Makefile +++ b/arch/arm/mach-omap2/Makefile @@ -96,7 +96,6 @@ obj-$(CONFIG_ARCH_OMAP4) += prcm.o cm2xxx_3xxx.o cminst44xx.o \ cm44xx.o prcm_mpu44xx.o \ prminst44xx.o vc44xx_data.o \ vp44xx_data.o prm44xx.o -obj-$(CONFIG_ARCH_OMAPAM33XX) += prcm.o 8) ARM: OMAP3+: cm33xx: Introduce AM33xx CM API's and register level details Looks ok to me. 9) ARM: OMAP2+: powerdomain: add AM335x support Remove multiple entries for target powerdomain-common for AM33xx diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile index ae1399b..1147352 100644 --- a/arch/arm/mach-omap2/Makefile +++ b/arch/arm/mach-omap2/Makefile @@ -126,7 +126,6 @@ obj-$(CONFIG_SOC_OMAPAM33XX) += $(powerdomain-common) \ obj-$(CONFIG_ARCH_OMAP4) += $(powerdomain-common) \ powerdomain44xx.o \ powerdomains44xx_data.o -obj-$(CONFIG_ARCH_OMAPAM33XX) += $(powerdomain-common) 10) ARM: OMAP3+: clockdomain33xx: Add clockdomain data and respective operations Looks ok to me. Paul, I have also boot tested it on BeagleBone, since we would not catch any issues from the changes. It is highly impossible to catch just by reviewing the patch or checking for build test. So I ported merged clocktree and hwmod patches to see whether it boots up on BeagleBone, and found that, we need further changes here - =======================diff for BeagleBone boot====================== diff --git a/arch/arm/mach-omap2/board-am335xevm.c b/arch/arm/mach-omap2/board-am335xevm.c index 324752e..69d8aae 100644 --- a/arch/arm/mach-omap2/board-am335xevm.c +++ b/arch/arm/mach-omap2/board-am335xevm.c @@ -41,6 +41,7 @@ MACHINE_START(AM335XEVM, "am335xevm") .map_io = am33xx_map_io, .init_early = am33xx_init_early, .init_irq = ti81xx_init_irq, + .handle_irq = omap3_intc_handle_irq, .timer = &omap3_am33xx_timer, .init_machine = am335x_evm_init, MACHINE_END diff --git a/arch/arm/mach-omap2/common.c b/arch/arm/mach-omap2/common.c index 1549c11..77467b3 100644 --- a/arch/arm/mach-omap2/common.c +++ b/arch/arm/mach-omap2/common.c @@ -134,6 +134,9 @@ void __init ti81xx_map_io(void) { omapti81xx_map_common_io(); } +#endif + +#if defined(CONFIG_ARCH_OMAPAM33XX) #define AM33XX_TAP_BASE (AM33XX_CTRL_BASE + \ TI81XX_CONTROL_DEVICE_ID - 0x204) diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c index 6712199..3c9649a 100644 --- a/arch/arm/mach-omap2/io.c +++ b/arch/arm/mach-omap2/io.c @@ -185,7 +185,7 @@ static struct map_desc omapti81xx_io_desc[] __initdata = { }; #endif -#ifdef CONFIG_SOC_OMAPAM33XX +#ifdef CONFIG_ARCH_OMAPAM33XX static struct map_desc omapam33xx_io_desc[] __initdata = { { .virtual = L4_34XX_VIRT, @@ -294,7 +294,7 @@ void __init omapti81xx_map_common_io(void) } #endif diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c index 6712199..3c9649a 100644 --- a/arch/arm/mach-omap2/io.c +++ b/arch/arm/mach-omap2/io.c @@ -470,10 +470,12 @@ void __init ti81xx_init_early(void) } #endif /* CONFIG_ARCH_OMAP3 */ #ifdef CONFIG_SOC_OMAPAM33XX void __init am33xx_init_early(void) { omap2_set_globals_am33xx(); + omap3xxx_check_revision(); + ti81xx_check_features(); omap_common_init_early(); am33xx_voltagedomains_init(); am33xx_powerdomains_init(); diff --git a/arch/arm/mach-omap2/irq.c b/arch/arm/mach-omap2/irq.c index 80f3ced..c5f8a48 100644 --- a/arch/arm/mach-omap2/irq.c +++ b/arch/arm/mach-omap2/irq.c @@ -280,7 +280,7 @@ int __init omap_intc_of_init(struct device_node *node, return 0; } -#ifdef CONFIG_ARCH_OMAP3 +#if defined (CONFIG_ARCH_OMAP3) || defined (CONFIG_ARCH_OMAPAM33XX) static struct omap3_intc_regs intc_context[ARRAY_SIZE(irq_banks)]; void omap_intc_save_context(void) diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c index 2883f5d..2a25dd9 100644 --- a/arch/arm/mach-omap2/timer.c +++ b/arch/arm/mach-omap2/timer.c @@ -373,6 +373,8 @@ OMAP_SYS_TIMER(3) OMAP_SYS_TIMER_INIT(3_secure, OMAP3_SECURE_TIMER, OMAP3_CLKEV_SOURCE, 2, OMAP3_MPU_SOURCE) OMAP_SYS_TIMER(3_secure) +#endif +#ifdef CONFIG_ARCH_OMAPAM33XX OMAP_SYS_TIMER_INIT(3_am33xx, 1, OMAP4_MPU_SOURCE, 2, OMAP4_MPU_SOURCE) OMAP_SYS_TIMER(3_am33xx) #endif diff --git a/arch/arm/plat-omap/include/plat/cpu.h b/arch/arm/plat-omap/include/plat/cpu.h index dc6a86b..0e8957b 100644 --- a/arch/arm/plat-omap/include/plat/cpu.h +++ b/arch/arm/plat-omap/include/plat/cpu.h @@ -357,8 +357,6 @@ IS_OMAP_TYPE(3517, 0x3517) # undef cpu_is_ti81xx # undef cpu_is_ti816x # undef cpu_is_ti814x -# undef cpu_is_am33xx -# undef cpu_is_am335x # define cpu_is_omap3430() is_omap3430() # define cpu_is_omap3503() (cpu_is_omap3430() && \ (!omap3_has_iva()) && \ @@ -378,6 +376,11 @@ IS_OMAP_TYPE(3517, 0x3517) # define cpu_is_ti81xx() is_ti81xx() # define cpu_is_ti816x() is_ti816x() # define cpu_is_ti814x() is_ti814x() +#endif + +# if defined(CONFIG_ARCH_OMAPAM33XX) +# undef cpu_is_am33xx +# undef cpu_is_am335x # define cpu_is_am33xx() is_am33xx() # define cpu_is_am335x() is_am335x() #endif @@ -397,7 +400,7 @@ IS_OMAP_TYPE(3517, 0x3517) #define cpu_class_is_omap1() (cpu_is_omap7xx() || cpu_is_omap15xx() || \ cpu_is_omap16xx()) #define cpu_class_is_omap2() (cpu_is_omap24xx() || cpu_is_omap34xx() || \ - cpu_is_omap44xx()) + cpu_is_omap44xx() || cpu_is_am33xx()) /* Various silicon revisions for omap2 */ #define OMAP242X_CLASS 0x24200024 @@ -433,7 +436,7 @@ IS_OMAP_TYPE(3517, 0x3517) #define TI8148_REV_ES2_0 (TI814X_CLASS | (0x1 << 8)) #define TI8148_REV_ES2_1 (TI814X_CLASS | (0x2 << 8)) -#define AM335X_CLASS 0x33500034 +#define AM335X_CLASS 0x33500033 #define AM335X_REV_ES1_0 AM335X_CLASS #define OMAP443X_CLASS 0x44300044 ^ permalink raw reply related [flat|nested] 64+ messages in thread
* [PATCH-V4 0/4] ARM: OMAP2+: Add voltagedomain, powerdomain & PRM support for AM33XX device @ 2012-05-03 14:44 ` Hiremath, Vaibhav 0 siblings, 0 replies; 64+ messages in thread From: Hiremath, Vaibhav @ 2012-05-03 14:44 UTC (permalink / raw) To: linux-arm-kernel On Wed, May 02, 2012 at 15:00:28, Paul Walmsley wrote: > > Hello Vaibhav, > > I've reworked these patches somewhat to separate the PRM and CM changes > into their own patches. Also, the omap_hwmod changes have been separated > and moved into a different series, as have the clock tree changes. > > So now, pending for 3.5, there are the SCM, voltagedomain, PRM, CM, > powerdomain, and clockdomain changes. Under the (probably incorrect) > assumption that Tony will opt to create a CONFIG_ARCH_OMAPAM33XX, you > might wish to take a look at the 'am33xx_prcm_devel_3.5' branch of > git://git.pwsan.com/linux-2.6. It is based on four patches, not yet > upstream, which create the appropriate board file, Kconfig options, etc. > > Once we're able to reach a conclusion as to which of the CONFIG_ARCH_OMAP* > options the AM33xx belongs under, this branch will be updated and > reposted, and if everyone is happy with it, proposed for pulling. > Hi Paul, I have reviewed the "am33xx_prcm_devel_3.5" branch for AM33xx support, and below are few comments I have, 1) ARM: add CONFIG_ARCH_OMAP{AM33XX,TI81XX} Description talks about TI81xx as well, but patch is created only for AM33xx. Isn't same entry should be created for TI81xx in the patch? 2) ARM: OMAP: AM335x: add Kconfig, Makefile glue for CONFIG_ARCH_OMAPAM33XX Looks ok to me. (Acked-by: Vaibhav Hiremath <hvaibhav@ti.com>) 3) ARM: OMAP: AM33xx: Add AM335XEVM machine support Looks ok to me. 4) arm:omap:am33xx: Add low level debugging support Subject line need to change to match it with our convention. ARM: OMAP: am33xx: Add low level debugging support 5) ARM: OMAP2+: control: Add AM33XX control reg & sec clkctrl offset Looks ok to me. 6) ARM: OMAP3+: am33xx: Add voltage domain data Remove multiple entries for voltagedomain-common.o for AM33xx diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile index cc44ea9..3b953c7 100644 --- a/arch/arm/mach-omap2/Makefile +++ b/arch/arm/mach-omap2/Makefile @@ -109,7 +109,6 @@ obj-$(CONFIG_SOC_OMAPAM33XX) += $(voltagedomain-common) \ voltagedomains33xx_data.o obj-$(CONFIG_ARCH_OMAP4) += $(voltagedomain-common) \ voltagedomains44xx_data.o -obj-$(CONFIG_ARCH_OMAPAM33XX) += $(voltagedomain-common) 7) ARM: OMAP3+: am33xx: add PRM support Remove multiple entries for prcm.o for AM33xx diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile index 3b953c7..ae1399b 100644 --- a/arch/arm/mach-omap2/Makefile +++ b/arch/arm/mach-omap2/Makefile @@ -96,7 +96,6 @@ obj-$(CONFIG_ARCH_OMAP4) += prcm.o cm2xxx_3xxx.o cminst44xx.o \ cm44xx.o prcm_mpu44xx.o \ prminst44xx.o vc44xx_data.o \ vp44xx_data.o prm44xx.o -obj-$(CONFIG_ARCH_OMAPAM33XX) += prcm.o 8) ARM: OMAP3+: cm33xx: Introduce AM33xx CM API's and register level details Looks ok to me. 9) ARM: OMAP2+: powerdomain: add AM335x support Remove multiple entries for target powerdomain-common for AM33xx diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile index ae1399b..1147352 100644 --- a/arch/arm/mach-omap2/Makefile +++ b/arch/arm/mach-omap2/Makefile @@ -126,7 +126,6 @@ obj-$(CONFIG_SOC_OMAPAM33XX) += $(powerdomain-common) \ obj-$(CONFIG_ARCH_OMAP4) += $(powerdomain-common) \ powerdomain44xx.o \ powerdomains44xx_data.o -obj-$(CONFIG_ARCH_OMAPAM33XX) += $(powerdomain-common) 10) ARM: OMAP3+: clockdomain33xx: Add clockdomain data and respective operations Looks ok to me. Paul, I have also boot tested it on BeagleBone, since we would not catch any issues from the changes. It is highly impossible to catch just by reviewing the patch or checking for build test. So I ported merged clocktree and hwmod patches to see whether it boots up on BeagleBone, and found that, we need further changes here - =======================diff for BeagleBone boot====================== diff --git a/arch/arm/mach-omap2/board-am335xevm.c b/arch/arm/mach-omap2/board-am335xevm.c index 324752e..69d8aae 100644 --- a/arch/arm/mach-omap2/board-am335xevm.c +++ b/arch/arm/mach-omap2/board-am335xevm.c @@ -41,6 +41,7 @@ MACHINE_START(AM335XEVM, "am335xevm") .map_io = am33xx_map_io, .init_early = am33xx_init_early, .init_irq = ti81xx_init_irq, + .handle_irq = omap3_intc_handle_irq, .timer = &omap3_am33xx_timer, .init_machine = am335x_evm_init, MACHINE_END diff --git a/arch/arm/mach-omap2/common.c b/arch/arm/mach-omap2/common.c index 1549c11..77467b3 100644 --- a/arch/arm/mach-omap2/common.c +++ b/arch/arm/mach-omap2/common.c @@ -134,6 +134,9 @@ void __init ti81xx_map_io(void) { omapti81xx_map_common_io(); } +#endif + +#if defined(CONFIG_ARCH_OMAPAM33XX) #define AM33XX_TAP_BASE (AM33XX_CTRL_BASE + \ TI81XX_CONTROL_DEVICE_ID - 0x204) diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c index 6712199..3c9649a 100644 --- a/arch/arm/mach-omap2/io.c +++ b/arch/arm/mach-omap2/io.c @@ -185,7 +185,7 @@ static struct map_desc omapti81xx_io_desc[] __initdata = { }; #endif -#ifdef CONFIG_SOC_OMAPAM33XX +#ifdef CONFIG_ARCH_OMAPAM33XX static struct map_desc omapam33xx_io_desc[] __initdata = { { .virtual = L4_34XX_VIRT, @@ -294,7 +294,7 @@ void __init omapti81xx_map_common_io(void) } #endif diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c index 6712199..3c9649a 100644 --- a/arch/arm/mach-omap2/io.c +++ b/arch/arm/mach-omap2/io.c @@ -470,10 +470,12 @@ void __init ti81xx_init_early(void) } #endif /* CONFIG_ARCH_OMAP3 */ #ifdef CONFIG_SOC_OMAPAM33XX void __init am33xx_init_early(void) { omap2_set_globals_am33xx(); + omap3xxx_check_revision(); + ti81xx_check_features(); omap_common_init_early(); am33xx_voltagedomains_init(); am33xx_powerdomains_init(); diff --git a/arch/arm/mach-omap2/irq.c b/arch/arm/mach-omap2/irq.c index 80f3ced..c5f8a48 100644 --- a/arch/arm/mach-omap2/irq.c +++ b/arch/arm/mach-omap2/irq.c @@ -280,7 +280,7 @@ int __init omap_intc_of_init(struct device_node *node, return 0; } -#ifdef CONFIG_ARCH_OMAP3 +#if defined (CONFIG_ARCH_OMAP3) || defined (CONFIG_ARCH_OMAPAM33XX) static struct omap3_intc_regs intc_context[ARRAY_SIZE(irq_banks)]; void omap_intc_save_context(void) diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c index 2883f5d..2a25dd9 100644 --- a/arch/arm/mach-omap2/timer.c +++ b/arch/arm/mach-omap2/timer.c @@ -373,6 +373,8 @@ OMAP_SYS_TIMER(3) OMAP_SYS_TIMER_INIT(3_secure, OMAP3_SECURE_TIMER, OMAP3_CLKEV_SOURCE, 2, OMAP3_MPU_SOURCE) OMAP_SYS_TIMER(3_secure) +#endif +#ifdef CONFIG_ARCH_OMAPAM33XX OMAP_SYS_TIMER_INIT(3_am33xx, 1, OMAP4_MPU_SOURCE, 2, OMAP4_MPU_SOURCE) OMAP_SYS_TIMER(3_am33xx) #endif diff --git a/arch/arm/plat-omap/include/plat/cpu.h b/arch/arm/plat-omap/include/plat/cpu.h index dc6a86b..0e8957b 100644 --- a/arch/arm/plat-omap/include/plat/cpu.h +++ b/arch/arm/plat-omap/include/plat/cpu.h @@ -357,8 +357,6 @@ IS_OMAP_TYPE(3517, 0x3517) # undef cpu_is_ti81xx # undef cpu_is_ti816x # undef cpu_is_ti814x -# undef cpu_is_am33xx -# undef cpu_is_am335x # define cpu_is_omap3430() is_omap3430() # define cpu_is_omap3503() (cpu_is_omap3430() && \ (!omap3_has_iva()) && \ @@ -378,6 +376,11 @@ IS_OMAP_TYPE(3517, 0x3517) # define cpu_is_ti81xx() is_ti81xx() # define cpu_is_ti816x() is_ti816x() # define cpu_is_ti814x() is_ti814x() +#endif + +# if defined(CONFIG_ARCH_OMAPAM33XX) +# undef cpu_is_am33xx +# undef cpu_is_am335x # define cpu_is_am33xx() is_am33xx() # define cpu_is_am335x() is_am335x() #endif @@ -397,7 +400,7 @@ IS_OMAP_TYPE(3517, 0x3517) #define cpu_class_is_omap1() (cpu_is_omap7xx() || cpu_is_omap15xx() || \ cpu_is_omap16xx()) #define cpu_class_is_omap2() (cpu_is_omap24xx() || cpu_is_omap34xx() || \ - cpu_is_omap44xx()) + cpu_is_omap44xx() || cpu_is_am33xx()) /* Various silicon revisions for omap2 */ #define OMAP242X_CLASS 0x24200024 @@ -433,7 +436,7 @@ IS_OMAP_TYPE(3517, 0x3517) #define TI8148_REV_ES2_0 (TI814X_CLASS | (0x1 << 8)) #define TI8148_REV_ES2_1 (TI814X_CLASS | (0x2 << 8)) -#define AM335X_CLASS 0x33500034 +#define AM335X_CLASS 0x33500033 #define AM335X_REV_ES1_0 AM335X_CLASS #define OMAP443X_CLASS 0x44300044 ^ permalink raw reply related [flat|nested] 64+ messages in thread
* RE: [PATCH-V4 0/4] ARM: OMAP2+: Add voltagedomain, powerdomain & PRM support for AM33XX device 2012-03-30 16:03 ` Vaibhav Hiremath @ 2012-04-25 13:44 ` Hiremath, Vaibhav -1 siblings, 0 replies; 64+ messages in thread From: Hiremath, Vaibhav @ 2012-04-25 13:44 UTC (permalink / raw) To: Hiremath, Vaibhav, linux-omap Cc: tony, Hilman, Kevin, paul, Nayak, Rajendra, Cousson, Benoit, linux-arm-kernel On Fri, Mar 30, 2012 at 21:33:51, Hiremath, Vaibhav wrote: > After some healthy discussion, now we have come to the conclusion and > decided to handle AM33XX PRM/CM part 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, > shortly I will submit similar patch for CM, clockdomain and clock-tree > support for AM33xx. > > This patch-series is created on top of "linux-omap/cleanup" branch, and > also gets applied to "linux-omap/master" branch. > The patches are also available at - > https://github.com/hvaibhav/am335x-linux/tree/am335x-prm-cm > > Changes from previous versions: > =============================== > From V3: > - No code change, only added Voltagedomain patch (from V2 series) > to this series. > > 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 (4): > ARM: OMAP3+: am33xx: Add voltage domain data > 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 powerdomain & PRM support > > arch/arm/mach-omap2/Makefile | 6 + > arch/arm/mach-omap2/io.c | 2 + > 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/mach-omap2/voltage.h | 1 + > arch/arm/mach-omap2/voltagedomains33xx_data.c | 43 +++ > arch/arm/plat-omap/include/plat/omap_hwmod.h | 2 + > 12 files changed, 1139 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 > create mode 100644 arch/arm/mach-omap2/voltagedomains33xx_data.c > > Tony, Paul and Kevin, Any comments on this patch series? Thanks, Vaibhav ^ permalink raw reply [flat|nested] 64+ messages in thread
* [PATCH-V4 0/4] ARM: OMAP2+: Add voltagedomain, powerdomain & PRM support for AM33XX device @ 2012-04-25 13:44 ` Hiremath, Vaibhav 0 siblings, 0 replies; 64+ messages in thread From: Hiremath, Vaibhav @ 2012-04-25 13:44 UTC (permalink / raw) To: linux-arm-kernel On Fri, Mar 30, 2012 at 21:33:51, Hiremath, Vaibhav wrote: > After some healthy discussion, now we have come to the conclusion and > decided to handle AM33XX PRM/CM part 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, > shortly I will submit similar patch for CM, clockdomain and clock-tree > support for AM33xx. > > This patch-series is created on top of "linux-omap/cleanup" branch, and > also gets applied to "linux-omap/master" branch. > The patches are also available at - > https://github.com/hvaibhav/am335x-linux/tree/am335x-prm-cm > > Changes from previous versions: > =============================== > From V3: > - No code change, only added Voltagedomain patch (from V2 series) > to this series. > > 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 (4): > ARM: OMAP3+: am33xx: Add voltage domain data > 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 powerdomain & PRM support > > arch/arm/mach-omap2/Makefile | 6 + > arch/arm/mach-omap2/io.c | 2 + > 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/mach-omap2/voltage.h | 1 + > arch/arm/mach-omap2/voltagedomains33xx_data.c | 43 +++ > arch/arm/plat-omap/include/plat/omap_hwmod.h | 2 + > 12 files changed, 1139 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 > create mode 100644 arch/arm/mach-omap2/voltagedomains33xx_data.c > > Tony, Paul and Kevin, Any comments on this patch series? Thanks, Vaibhav ^ permalink raw reply [flat|nested] 64+ messages in thread
end of thread, other threads:[~2012-05-29 6:31 UTC | newest] Thread overview: 64+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2012-03-30 16:03 [PATCH-V4 0/4] ARM: OMAP2+: Add voltagedomain, powerdomain & PRM support for AM33XX device Vaibhav Hiremath 2012-03-30 16:03 ` Vaibhav Hiremath 2012-03-30 16:03 ` [PATCH-V4 1/4] ARM: OMAP3+: am33xx: Add voltage domain data Vaibhav Hiremath 2012-03-30 16:03 ` Vaibhav Hiremath 2012-04-28 0:39 ` Paul Walmsley 2012-04-28 0:39 ` Paul Walmsley 2012-04-30 20:41 ` Kevin Hilman 2012-04-30 20:41 ` Kevin Hilman 2012-03-30 16:03 ` [PATCH-V4 2/4] ARM: OMAP3/4: omap_hwmod: Add rstst_off field to struct omap_hwmod_omap4_prcm Vaibhav Hiremath 2012-03-30 16:03 ` Vaibhav Hiremath 2012-05-29 6:31 ` Hiremath, Vaibhav 2012-05-29 6:31 ` Hiremath, Vaibhav 2012-03-30 16:03 ` [PATCH-V4 3/4] ARM: OMAP2+: powerdomain: Add offset & mask fields to struct powerdomain Vaibhav Hiremath 2012-03-30 16:03 ` Vaibhav Hiremath 2012-03-30 16:03 ` [PATCH-V4 4/4] ARM: OMAP3+: am33xx: Add powerdomain & PRM support Vaibhav Hiremath 2012-03-30 16:03 ` Vaibhav Hiremath 2012-04-27 0:49 ` Kevin Hilman 2012-04-27 0:49 ` Kevin Hilman 2012-04-27 6:37 ` Hiremath, Vaibhav 2012-04-27 6:37 ` Hiremath, Vaibhav 2012-05-04 18:43 ` Tony Lindgren 2012-05-04 18:43 ` Tony Lindgren 2012-04-27 20:44 ` Kevin Hilman 2012-04-27 20:44 ` Kevin Hilman 2012-03-30 16:22 ` [PATCH-V4 0/4] ARM: OMAP2+: Add voltagedomain, powerdomain & PRM support for AM33XX device Hiremath, Vaibhav 2012-03-30 16:22 ` Hiremath, Vaibhav 2012-04-12 8:26 ` Paul Walmsley 2012-04-12 8:26 ` Paul Walmsley 2012-04-13 10:36 ` Hiremath, Vaibhav 2012-04-13 10:36 ` Hiremath, Vaibhav 2012-04-13 10:43 ` Paul Walmsley 2012-04-13 10:43 ` Paul Walmsley 2012-04-16 7:18 ` Hiremath, Vaibhav 2012-04-16 7:18 ` Hiremath, Vaibhav 2012-04-18 23:21 ` Tony Lindgren 2012-04-18 23:21 ` Tony Lindgren 2012-04-18 23:18 ` Tony Lindgren 2012-04-18 23:18 ` Tony Lindgren 2012-04-23 18:28 ` Hiremath, Vaibhav 2012-04-23 18:28 ` Hiremath, Vaibhav 2012-04-26 18:43 ` Tony Lindgren 2012-04-26 18:43 ` Tony Lindgren 2012-04-26 18:49 ` Hiremath, Vaibhav 2012-04-26 18:49 ` Hiremath, Vaibhav 2012-04-26 19:05 ` Tony Lindgren 2012-04-26 19:05 ` Tony Lindgren 2012-04-27 8:53 ` Hiremath, Vaibhav 2012-04-27 8:53 ` Hiremath, Vaibhav 2012-05-02 9:09 ` Paul Walmsley 2012-05-02 9:09 ` Paul Walmsley 2012-05-07 10:32 ` Cousson, Benoit 2012-05-07 10:32 ` Cousson, Benoit 2012-05-07 10:44 ` Shilimkar, Santosh 2012-05-07 10:44 ` Shilimkar, Santosh 2012-05-07 13:59 ` Hiremath, Vaibhav 2012-05-07 13:59 ` Hiremath, Vaibhav 2012-05-02 9:30 ` Paul Walmsley 2012-05-02 9:30 ` Paul Walmsley 2012-05-02 9:37 ` Hiremath, Vaibhav 2012-05-02 9:37 ` Hiremath, Vaibhav 2012-05-03 14:44 ` Hiremath, Vaibhav 2012-05-03 14:44 ` Hiremath, Vaibhav 2012-04-25 13:44 ` Hiremath, Vaibhav 2012-04-25 13:44 ` Hiremath, Vaibhav
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.