* [PATCH 0/6] omap4: prcm: Few dpll, clockdomain and powerdomain updates
@ 2011-01-28 11:04 ` Santosh Shilimkar
0 siblings, 0 replies; 48+ messages in thread
From: Santosh Shilimkar @ 2011-01-28 11:04 UTC (permalink / raw)
To: linux-arm-kernel
The series mainly contains dpll initialisation, CPUx clock
domain offset fix, addiing INACTIVE power domain state and
fixing logic flag for IVAHD and ABE power domains.
The series is boot tested on OMAP4430 SDP.
The following changes since commit 1bae4ce27c9c90344f23c65ea6966c50ffeae2f5:
Linus Torvalds (1):
Linux 2.6.38-rc2
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git omap4_prcm_misc
Rajendra Nayak (3):
omap4: dpll: Enable all DPLL autoidle at boot
omap4: dpll: Add dpll api to control GATE_CTRL
omap4: dpll: Enable auto gate control for all MX postdividers
Santosh Shilimkar (3):
omap4: powerdomain: Add supported INACTIVE power state
omap4: prcm: Fix the CPUx clockdomain offsets
omap4: powerdomain: Use intended PWRSTS_* flags instead of values
arch/arm/mach-omap2/clock.h | 3 ++
arch/arm/mach-omap2/clock44xx_data.c | 24 +++++++++++++++
arch/arm/mach-omap2/dpll3xxx.c | 43 +++++++++++++++++++++++++++
arch/arm/mach-omap2/powerdomain.h | 12 +++++++
arch/arm/mach-omap2/powerdomains44xx_data.c | 30 +++++++++---------
arch/arm/mach-omap2/prcm_mpu44xx.h | 4 +-
arch/arm/plat-omap/include/plat/clock.h | 1 +
7 files changed, 100 insertions(+), 17 deletions(-)
^ permalink raw reply [flat|nested] 48+ messages in thread* [PATCH 1/6] omap4: powerdomain: Add supported INACTIVE power state
2011-01-28 11:04 ` Santosh Shilimkar
@ 2011-01-28 11:04 ` Santosh Shilimkar
-1 siblings, 0 replies; 48+ messages in thread
From: Santosh Shilimkar @ 2011-01-28 11:04 UTC (permalink / raw)
To: linux-omap
Cc: khilman, paul, b-cousson, rnayak, linux-arm-kernel, Santosh Shilimkar
On OMAP4, one can explicitly program INACTIVE as the power state of
the logic area inside the power domain. Techincally PD state programmed
to ON and if all the clock domains within the PD are idled, is equivalent
tp PD programmed to INACTIVE and all the clock domains within the PD are
idled. There won't be any power difference in above two.
Since the CPUIDLE C-states explicitly make use of INACTIVE as a PD
targeted state and also there is some additional latancy involved
with PD INACTIVE vs PD ON, it's better to support it as an explcit
PD state.
This patch adds the support to allow explicit PD INACTIVE
programming if supported.
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
---
arch/arm/mach-omap2/powerdomain.h | 12 ++++++++++++
arch/arm/mach-omap2/powerdomains44xx_data.c | 26 +++++++++++++-------------
2 files changed, 25 insertions(+), 13 deletions(-)
diff --git a/arch/arm/mach-omap2/powerdomain.h b/arch/arm/mach-omap2/powerdomain.h
index c66431e..0e15ca7 100644
--- a/arch/arm/mach-omap2/powerdomain.h
+++ b/arch/arm/mach-omap2/powerdomain.h
@@ -46,6 +46,18 @@
#define PWRSTS_OFF_RET_ON (PWRSTS_OFF_RET | (1 << PWRDM_POWER_ON))
+#define PWRSTS_RET_INA_ON ((1 << PWRDM_POWER_RET) | \
+ (1 << PWRDM_POWER_INACTIVE) | \
+ (1 << PWRDM_POWER_ON))
+
+#define PWRSTS_OFF_INA_ON ((1 << PWRDM_POWER_OFF) | \
+ (1 << PWRDM_POWER_INACTIVE) | \
+ (1 << PWRDM_POWER_ON))
+
+#define PWRSTS_OFF_RET_INA_ON ((1 << PWRDM_POWER_OFF) | \
+ (1 << PWRDM_POWER_RET) | \
+ (1 << PWRDM_POWER_INACTIVE) | \
+ (1 << PWRDM_POWER_ON))
/* Powerdomain flags */
#define PWRDM_HAS_HDWR_SAR (1 << 0) /* hardware save-and-restore support */
diff --git a/arch/arm/mach-omap2/powerdomains44xx_data.c b/arch/arm/mach-omap2/powerdomains44xx_data.c
index 26d7641..96cde98 100644
--- a/arch/arm/mach-omap2/powerdomains44xx_data.c
+++ b/arch/arm/mach-omap2/powerdomains44xx_data.c
@@ -36,7 +36,7 @@ static struct powerdomain core_44xx_pwrdm = {
.prcm_offs = OMAP4430_PRM_CORE_INST,
.prcm_partition = OMAP4430_PRM_PARTITION,
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
- .pwrsts = PWRSTS_RET_ON,
+ .pwrsts = PWRSTS_RET_INA_ON,
.pwrsts_logic_ret = PWRSTS_OFF_RET,
.banks = 5,
.pwrsts_mem_ret = {
@@ -62,7 +62,7 @@ static struct powerdomain gfx_44xx_pwrdm = {
.prcm_offs = OMAP4430_PRM_GFX_INST,
.prcm_partition = OMAP4430_PRM_PARTITION,
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
- .pwrsts = PWRSTS_OFF_ON,
+ .pwrsts = PWRSTS_OFF_INA_ON,
.banks = 1,
.pwrsts_mem_ret = {
[0] = PWRDM_POWER_OFF, /* gfx_mem */
@@ -79,7 +79,7 @@ static struct powerdomain abe_44xx_pwrdm = {
.prcm_offs = OMAP4430_PRM_ABE_INST,
.prcm_partition = OMAP4430_PRM_PARTITION,
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
- .pwrsts = PWRSTS_OFF_RET_ON,
+ .pwrsts = PWRSTS_OFF_RET_INA_ON,
.pwrsts_logic_ret = PWRDM_POWER_OFF,
.banks = 2,
.pwrsts_mem_ret = {
@@ -99,7 +99,7 @@ static struct powerdomain dss_44xx_pwrdm = {
.prcm_offs = OMAP4430_PRM_DSS_INST,
.prcm_partition = OMAP4430_PRM_PARTITION,
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
- .pwrsts = PWRSTS_OFF_RET_ON,
+ .pwrsts = PWRSTS_OFF_RET_INA_ON,
.pwrsts_logic_ret = PWRSTS_OFF,
.banks = 1,
.pwrsts_mem_ret = {
@@ -117,7 +117,7 @@ static struct powerdomain tesla_44xx_pwrdm = {
.prcm_offs = OMAP4430_PRM_TESLA_INST,
.prcm_partition = OMAP4430_PRM_PARTITION,
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
- .pwrsts = PWRSTS_OFF_RET_ON,
+ .pwrsts = PWRSTS_OFF_RET_INA_ON,
.pwrsts_logic_ret = PWRSTS_OFF_RET,
.banks = 3,
.pwrsts_mem_ret = {
@@ -155,7 +155,7 @@ static struct powerdomain cpu0_44xx_pwrdm = {
.prcm_offs = OMAP4430_PRCM_MPU_CPU0_INST,
.prcm_partition = OMAP4430_PRCM_MPU_PARTITION,
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
- .pwrsts = PWRSTS_OFF_RET_ON,
+ .pwrsts = PWRSTS_OFF_RET_INA_ON,
.pwrsts_logic_ret = PWRSTS_OFF_RET,
.banks = 1,
.pwrsts_mem_ret = {
@@ -172,7 +172,7 @@ static struct powerdomain cpu1_44xx_pwrdm = {
.prcm_offs = OMAP4430_PRCM_MPU_CPU1_INST,
.prcm_partition = OMAP4430_PRCM_MPU_PARTITION,
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
- .pwrsts = PWRSTS_OFF_RET_ON,
+ .pwrsts = PWRSTS_OFF_RET_INA_ON,
.pwrsts_logic_ret = PWRSTS_OFF_RET,
.banks = 1,
.pwrsts_mem_ret = {
@@ -205,7 +205,7 @@ static struct powerdomain mpu_44xx_pwrdm = {
.prcm_offs = OMAP4430_PRM_MPU_INST,
.prcm_partition = OMAP4430_PRM_PARTITION,
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
- .pwrsts = PWRSTS_OFF_RET_ON,
+ .pwrsts = PWRSTS_OFF_RET_INA_ON,
.pwrsts_logic_ret = PWRSTS_OFF_RET,
.banks = 3,
.pwrsts_mem_ret = {
@@ -226,7 +226,7 @@ static struct powerdomain ivahd_44xx_pwrdm = {
.prcm_offs = OMAP4430_PRM_IVAHD_INST,
.prcm_partition = OMAP4430_PRM_PARTITION,
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
- .pwrsts = PWRSTS_OFF_RET_ON,
+ .pwrsts = PWRSTS_OFF_RET_INA_ON,
.pwrsts_logic_ret = PWRDM_POWER_OFF,
.banks = 4,
.pwrsts_mem_ret = {
@@ -250,7 +250,7 @@ static struct powerdomain cam_44xx_pwrdm = {
.prcm_offs = OMAP4430_PRM_CAM_INST,
.prcm_partition = OMAP4430_PRM_PARTITION,
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
- .pwrsts = PWRSTS_OFF_ON,
+ .pwrsts = PWRSTS_OFF_INA_ON,
.banks = 1,
.pwrsts_mem_ret = {
[0] = PWRDM_POWER_OFF, /* cam_mem */
@@ -267,7 +267,7 @@ static struct powerdomain l3init_44xx_pwrdm = {
.prcm_offs = OMAP4430_PRM_L3INIT_INST,
.prcm_partition = OMAP4430_PRM_PARTITION,
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
- .pwrsts = PWRSTS_RET_ON,
+ .pwrsts = PWRSTS_OFF_RET_INA_ON,
.pwrsts_logic_ret = PWRSTS_OFF_RET,
.banks = 1,
.pwrsts_mem_ret = {
@@ -285,7 +285,7 @@ static struct powerdomain l4per_44xx_pwrdm = {
.prcm_offs = OMAP4430_PRM_L4PER_INST,
.prcm_partition = OMAP4430_PRM_PARTITION,
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
- .pwrsts = PWRSTS_RET_ON,
+ .pwrsts = PWRSTS_RET_INA_ON,
.pwrsts_logic_ret = PWRSTS_OFF_RET,
.banks = 2,
.pwrsts_mem_ret = {
@@ -317,7 +317,7 @@ static struct powerdomain cefuse_44xx_pwrdm = {
.prcm_offs = OMAP4430_PRM_CEFUSE_INST,
.prcm_partition = OMAP4430_PRM_PARTITION,
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
- .pwrsts = PWRSTS_OFF_ON,
+ .pwrsts = PWRSTS_OFF_INA_ON,
};
/*
--
1.6.0.4
^ permalink raw reply related [flat|nested] 48+ messages in thread* [PATCH 1/6] omap4: powerdomain: Add supported INACTIVE power state
@ 2011-01-28 11:04 ` Santosh Shilimkar
0 siblings, 0 replies; 48+ messages in thread
From: Santosh Shilimkar @ 2011-01-28 11:04 UTC (permalink / raw)
To: linux-arm-kernel
On OMAP4, one can explicitly program INACTIVE as the power state of
the logic area inside the power domain. Techincally PD state programmed
to ON and if all the clock domains within the PD are idled, is equivalent
tp PD programmed to INACTIVE and all the clock domains within the PD are
idled. There won't be any power difference in above two.
Since the CPUIDLE C-states explicitly make use of INACTIVE as a PD
targeted state and also there is some additional latancy involved
with PD INACTIVE vs PD ON, it's better to support it as an explcit
PD state.
This patch adds the support to allow explicit PD INACTIVE
programming if supported.
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
---
arch/arm/mach-omap2/powerdomain.h | 12 ++++++++++++
arch/arm/mach-omap2/powerdomains44xx_data.c | 26 +++++++++++++-------------
2 files changed, 25 insertions(+), 13 deletions(-)
diff --git a/arch/arm/mach-omap2/powerdomain.h b/arch/arm/mach-omap2/powerdomain.h
index c66431e..0e15ca7 100644
--- a/arch/arm/mach-omap2/powerdomain.h
+++ b/arch/arm/mach-omap2/powerdomain.h
@@ -46,6 +46,18 @@
#define PWRSTS_OFF_RET_ON (PWRSTS_OFF_RET | (1 << PWRDM_POWER_ON))
+#define PWRSTS_RET_INA_ON ((1 << PWRDM_POWER_RET) | \
+ (1 << PWRDM_POWER_INACTIVE) | \
+ (1 << PWRDM_POWER_ON))
+
+#define PWRSTS_OFF_INA_ON ((1 << PWRDM_POWER_OFF) | \
+ (1 << PWRDM_POWER_INACTIVE) | \
+ (1 << PWRDM_POWER_ON))
+
+#define PWRSTS_OFF_RET_INA_ON ((1 << PWRDM_POWER_OFF) | \
+ (1 << PWRDM_POWER_RET) | \
+ (1 << PWRDM_POWER_INACTIVE) | \
+ (1 << PWRDM_POWER_ON))
/* Powerdomain flags */
#define PWRDM_HAS_HDWR_SAR (1 << 0) /* hardware save-and-restore support */
diff --git a/arch/arm/mach-omap2/powerdomains44xx_data.c b/arch/arm/mach-omap2/powerdomains44xx_data.c
index 26d7641..96cde98 100644
--- a/arch/arm/mach-omap2/powerdomains44xx_data.c
+++ b/arch/arm/mach-omap2/powerdomains44xx_data.c
@@ -36,7 +36,7 @@ static struct powerdomain core_44xx_pwrdm = {
.prcm_offs = OMAP4430_PRM_CORE_INST,
.prcm_partition = OMAP4430_PRM_PARTITION,
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
- .pwrsts = PWRSTS_RET_ON,
+ .pwrsts = PWRSTS_RET_INA_ON,
.pwrsts_logic_ret = PWRSTS_OFF_RET,
.banks = 5,
.pwrsts_mem_ret = {
@@ -62,7 +62,7 @@ static struct powerdomain gfx_44xx_pwrdm = {
.prcm_offs = OMAP4430_PRM_GFX_INST,
.prcm_partition = OMAP4430_PRM_PARTITION,
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
- .pwrsts = PWRSTS_OFF_ON,
+ .pwrsts = PWRSTS_OFF_INA_ON,
.banks = 1,
.pwrsts_mem_ret = {
[0] = PWRDM_POWER_OFF, /* gfx_mem */
@@ -79,7 +79,7 @@ static struct powerdomain abe_44xx_pwrdm = {
.prcm_offs = OMAP4430_PRM_ABE_INST,
.prcm_partition = OMAP4430_PRM_PARTITION,
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
- .pwrsts = PWRSTS_OFF_RET_ON,
+ .pwrsts = PWRSTS_OFF_RET_INA_ON,
.pwrsts_logic_ret = PWRDM_POWER_OFF,
.banks = 2,
.pwrsts_mem_ret = {
@@ -99,7 +99,7 @@ static struct powerdomain dss_44xx_pwrdm = {
.prcm_offs = OMAP4430_PRM_DSS_INST,
.prcm_partition = OMAP4430_PRM_PARTITION,
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
- .pwrsts = PWRSTS_OFF_RET_ON,
+ .pwrsts = PWRSTS_OFF_RET_INA_ON,
.pwrsts_logic_ret = PWRSTS_OFF,
.banks = 1,
.pwrsts_mem_ret = {
@@ -117,7 +117,7 @@ static struct powerdomain tesla_44xx_pwrdm = {
.prcm_offs = OMAP4430_PRM_TESLA_INST,
.prcm_partition = OMAP4430_PRM_PARTITION,
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
- .pwrsts = PWRSTS_OFF_RET_ON,
+ .pwrsts = PWRSTS_OFF_RET_INA_ON,
.pwrsts_logic_ret = PWRSTS_OFF_RET,
.banks = 3,
.pwrsts_mem_ret = {
@@ -155,7 +155,7 @@ static struct powerdomain cpu0_44xx_pwrdm = {
.prcm_offs = OMAP4430_PRCM_MPU_CPU0_INST,
.prcm_partition = OMAP4430_PRCM_MPU_PARTITION,
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
- .pwrsts = PWRSTS_OFF_RET_ON,
+ .pwrsts = PWRSTS_OFF_RET_INA_ON,
.pwrsts_logic_ret = PWRSTS_OFF_RET,
.banks = 1,
.pwrsts_mem_ret = {
@@ -172,7 +172,7 @@ static struct powerdomain cpu1_44xx_pwrdm = {
.prcm_offs = OMAP4430_PRCM_MPU_CPU1_INST,
.prcm_partition = OMAP4430_PRCM_MPU_PARTITION,
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
- .pwrsts = PWRSTS_OFF_RET_ON,
+ .pwrsts = PWRSTS_OFF_RET_INA_ON,
.pwrsts_logic_ret = PWRSTS_OFF_RET,
.banks = 1,
.pwrsts_mem_ret = {
@@ -205,7 +205,7 @@ static struct powerdomain mpu_44xx_pwrdm = {
.prcm_offs = OMAP4430_PRM_MPU_INST,
.prcm_partition = OMAP4430_PRM_PARTITION,
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
- .pwrsts = PWRSTS_OFF_RET_ON,
+ .pwrsts = PWRSTS_OFF_RET_INA_ON,
.pwrsts_logic_ret = PWRSTS_OFF_RET,
.banks = 3,
.pwrsts_mem_ret = {
@@ -226,7 +226,7 @@ static struct powerdomain ivahd_44xx_pwrdm = {
.prcm_offs = OMAP4430_PRM_IVAHD_INST,
.prcm_partition = OMAP4430_PRM_PARTITION,
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
- .pwrsts = PWRSTS_OFF_RET_ON,
+ .pwrsts = PWRSTS_OFF_RET_INA_ON,
.pwrsts_logic_ret = PWRDM_POWER_OFF,
.banks = 4,
.pwrsts_mem_ret = {
@@ -250,7 +250,7 @@ static struct powerdomain cam_44xx_pwrdm = {
.prcm_offs = OMAP4430_PRM_CAM_INST,
.prcm_partition = OMAP4430_PRM_PARTITION,
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
- .pwrsts = PWRSTS_OFF_ON,
+ .pwrsts = PWRSTS_OFF_INA_ON,
.banks = 1,
.pwrsts_mem_ret = {
[0] = PWRDM_POWER_OFF, /* cam_mem */
@@ -267,7 +267,7 @@ static struct powerdomain l3init_44xx_pwrdm = {
.prcm_offs = OMAP4430_PRM_L3INIT_INST,
.prcm_partition = OMAP4430_PRM_PARTITION,
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
- .pwrsts = PWRSTS_RET_ON,
+ .pwrsts = PWRSTS_OFF_RET_INA_ON,
.pwrsts_logic_ret = PWRSTS_OFF_RET,
.banks = 1,
.pwrsts_mem_ret = {
@@ -285,7 +285,7 @@ static struct powerdomain l4per_44xx_pwrdm = {
.prcm_offs = OMAP4430_PRM_L4PER_INST,
.prcm_partition = OMAP4430_PRM_PARTITION,
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
- .pwrsts = PWRSTS_RET_ON,
+ .pwrsts = PWRSTS_RET_INA_ON,
.pwrsts_logic_ret = PWRSTS_OFF_RET,
.banks = 2,
.pwrsts_mem_ret = {
@@ -317,7 +317,7 @@ static struct powerdomain cefuse_44xx_pwrdm = {
.prcm_offs = OMAP4430_PRM_CEFUSE_INST,
.prcm_partition = OMAP4430_PRM_PARTITION,
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
- .pwrsts = PWRSTS_OFF_ON,
+ .pwrsts = PWRSTS_OFF_INA_ON,
};
/*
--
1.6.0.4
^ permalink raw reply related [flat|nested] 48+ messages in thread* Re: [PATCH 1/6] omap4: powerdomain: Add supported INACTIVE power state
2011-01-28 11:04 ` Santosh Shilimkar
@ 2011-01-31 23:14 ` Paul Walmsley
-1 siblings, 0 replies; 48+ messages in thread
From: Paul Walmsley @ 2011-01-31 23:14 UTC (permalink / raw)
To: Santosh Shilimkar
Cc: linux-omap, khilman, b-cousson, rnayak, linux-arm-kernel
Hello Santosh,
On Fri, 28 Jan 2011, Santosh Shilimkar wrote:
> On OMAP4, one can explicitly program INACTIVE as the power state of
> the logic area inside the power domain. Techincally PD state programmed
> to ON and if all the clock domains within the PD are idled, is equivalent
> tp PD programmed to INACTIVE and all the clock domains within the PD are
> idled. There won't be any power difference in above two.
>
> Since the CPUIDLE C-states explicitly make use of INACTIVE as a PD
> targeted state and also there is some additional latancy involved
> with PD INACTIVE vs PD ON, it's better to support it as an explcit
> PD state.
>
> This patch adds the support to allow explicit PD INACTIVE
> programming if supported.
What does the hardware do when the powerdomain is programmed to INACTIVE?
Does it actually force the clockdomains idle?
- Paul
^ permalink raw reply [flat|nested] 48+ messages in thread
* [PATCH 1/6] omap4: powerdomain: Add supported INACTIVE power state
@ 2011-01-31 23:14 ` Paul Walmsley
0 siblings, 0 replies; 48+ messages in thread
From: Paul Walmsley @ 2011-01-31 23:14 UTC (permalink / raw)
To: linux-arm-kernel
Hello Santosh,
On Fri, 28 Jan 2011, Santosh Shilimkar wrote:
> On OMAP4, one can explicitly program INACTIVE as the power state of
> the logic area inside the power domain. Techincally PD state programmed
> to ON and if all the clock domains within the PD are idled, is equivalent
> tp PD programmed to INACTIVE and all the clock domains within the PD are
> idled. There won't be any power difference in above two.
>
> Since the CPUIDLE C-states explicitly make use of INACTIVE as a PD
> targeted state and also there is some additional latancy involved
> with PD INACTIVE vs PD ON, it's better to support it as an explcit
> PD state.
>
> This patch adds the support to allow explicit PD INACTIVE
> programming if supported.
What does the hardware do when the powerdomain is programmed to INACTIVE?
Does it actually force the clockdomains idle?
- Paul
^ permalink raw reply [flat|nested] 48+ messages in thread
* RE: [PATCH 1/6] omap4: powerdomain: Add supported INACTIVE power state
2011-01-31 23:14 ` Paul Walmsley
@ 2011-02-01 6:29 ` Santosh Shilimkar
-1 siblings, 0 replies; 48+ messages in thread
From: Santosh Shilimkar @ 2011-02-01 6:29 UTC (permalink / raw)
To: Paul Walmsley
Cc: linux-omap, Kevin Hilman, Benoit Cousson, Rajendra Nayak,
linux-arm-kernel
> -----Original Message-----
> From: Paul Walmsley [mailto:paul@pwsan.com]
> Sent: Tuesday, February 01, 2011 4:44 AM
> To: Santosh Shilimkar
> Cc: linux-omap@vger.kernel.org; khilman@ti.com; b-cousson@ti.com;
> rnayak@ti.com; linux-arm-kernel@lists.infradead.org
> Subject: Re: [PATCH 1/6] omap4: powerdomain: Add supported INACTIVE
> power state
>
> Hello Santosh,
>
> On Fri, 28 Jan 2011, Santosh Shilimkar wrote:
>
> > On OMAP4, one can explicitly program INACTIVE as the power state
> of
> > the logic area inside the power domain. Techincally PD state
> programmed
> > to ON and if all the clock domains within the PD are idled, is
> equivalent
> > tp PD programmed to INACTIVE and all the clock domains within the
> PD are
> > idled. There won't be any power difference in above two.
> >
> > Since the CPUIDLE C-states explicitly make use of INACTIVE as a PD
> > targeted state and also there is some additional latancy involved
> > with PD INACTIVE vs PD ON, it's better to support it as an explcit
> > PD state.
> >
> > This patch adds the support to allow explicit PD INACTIVE
> > programming if supported.
>
> What does the hardware do when the powerdomain is programmed to
> INACTIVE?
> Does it actually force the clockdomains idle?
>
No. It doesn't force it. The power domain to hit INACTIVE, the
clockdomain within the power domain needs to idle and it is
still a prerequisite. With INACTIVE being programmed, we could
issue a sleep transition.
PD_ON:
No power transition, only clocks are gated. Power domain stays ON.
PD_INA:
Power domain transitions to INACTIVE state. All logic and
memory stay powered. This state allows for a voltage
sleep transition.
Regards,
Santosh
^ permalink raw reply [flat|nested] 48+ messages in thread
* [PATCH 1/6] omap4: powerdomain: Add supported INACTIVE power state
@ 2011-02-01 6:29 ` Santosh Shilimkar
0 siblings, 0 replies; 48+ messages in thread
From: Santosh Shilimkar @ 2011-02-01 6:29 UTC (permalink / raw)
To: linux-arm-kernel
> -----Original Message-----
> From: Paul Walmsley [mailto:paul at pwsan.com]
> Sent: Tuesday, February 01, 2011 4:44 AM
> To: Santosh Shilimkar
> Cc: linux-omap at vger.kernel.org; khilman at ti.com; b-cousson at ti.com;
> rnayak at ti.com; linux-arm-kernel at lists.infradead.org
> Subject: Re: [PATCH 1/6] omap4: powerdomain: Add supported INACTIVE
> power state
>
> Hello Santosh,
>
> On Fri, 28 Jan 2011, Santosh Shilimkar wrote:
>
> > On OMAP4, one can explicitly program INACTIVE as the power state
> of
> > the logic area inside the power domain. Techincally PD state
> programmed
> > to ON and if all the clock domains within the PD are idled, is
> equivalent
> > tp PD programmed to INACTIVE and all the clock domains within the
> PD are
> > idled. There won't be any power difference in above two.
> >
> > Since the CPUIDLE C-states explicitly make use of INACTIVE as a PD
> > targeted state and also there is some additional latancy involved
> > with PD INACTIVE vs PD ON, it's better to support it as an explcit
> > PD state.
> >
> > This patch adds the support to allow explicit PD INACTIVE
> > programming if supported.
>
> What does the hardware do when the powerdomain is programmed to
> INACTIVE?
> Does it actually force the clockdomains idle?
>
No. It doesn't force it. The power domain to hit INACTIVE, the
clockdomain within the power domain needs to idle and it is
still a prerequisite. With INACTIVE being programmed, we could
issue a sleep transition.
PD_ON:
No power transition, only clocks are gated. Power domain stays ON.
PD_INA:
Power domain transitions to INACTIVE state. All logic and
memory stay powered. This state allows for a voltage
sleep transition.
Regards,
Santosh
^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: [PATCH 1/6] omap4: powerdomain: Add supported INACTIVE power state
2011-02-01 6:29 ` Santosh Shilimkar
@ 2011-02-01 12:39 ` Cousson, Benoit
-1 siblings, 0 replies; 48+ messages in thread
From: Cousson, Benoit @ 2011-02-01 12:39 UTC (permalink / raw)
To: Santosh Shilimkar
Cc: Paul Walmsley, linux-omap, Hilman, Kevin, Nayak, Rajendra,
linux-arm-kernel
On 2/1/2011 7:29 AM, Santosh Shilimkar wrote:
>> From: Paul Walmsley [mailto:paul@pwsan.com]
>> Sent: Tuesday, February 01, 2011 4:44 AM
>>
>> Hello Santosh,
>>
>> On Fri, 28 Jan 2011, Santosh Shilimkar wrote:
>>
>>> On OMAP4, one can explicitly program INACTIVE as the power state
>> of
>>> the logic area inside the power domain. Techincally PD state
>> programmed
>>> to ON and if all the clock domains within the PD are idled, is
>> equivalent
>>> tp PD programmed to INACTIVE and all the clock domains within the
>> PD are
>>> idled. There won't be any power difference in above two.
>>>
>>> Since the CPUIDLE C-states explicitly make use of INACTIVE as a PD
>>> targeted state and also there is some additional latancy involved
>>> with PD INACTIVE vs PD ON, it's better to support it as an explcit
>>> PD state.
>>>
>>> This patch adds the support to allow explicit PD INACTIVE
>>> programming if supported.
>>
>> What does the hardware do when the powerdomain is programmed to
>> INACTIVE?
>> Does it actually force the clockdomains idle?
>>
> No. It doesn't force it. The power domain to hit INACTIVE, the
> clockdomain within the power domain needs to idle and it is
> still a prerequisite. With INACTIVE being programmed, we could
> issue a sleep transition.
>
> PD_ON:
> No power transition, only clocks are gated. Power domain stays ON.
>
> PD_INA:
> Power domain transitions to INACTIVE state. All logic and
> memory stay powered. This state allows for a voltage
> sleep transition.
Just a small note on the latest point:
The voltage sleep transition can occur only if all power domains inside
a voltage domain are INACTIVE, RET or OFF.
Regards,
Benoit
^ permalink raw reply [flat|nested] 48+ messages in thread
* [PATCH 1/6] omap4: powerdomain: Add supported INACTIVE power state
@ 2011-02-01 12:39 ` Cousson, Benoit
0 siblings, 0 replies; 48+ messages in thread
From: Cousson, Benoit @ 2011-02-01 12:39 UTC (permalink / raw)
To: linux-arm-kernel
On 2/1/2011 7:29 AM, Santosh Shilimkar wrote:
>> From: Paul Walmsley [mailto:paul at pwsan.com]
>> Sent: Tuesday, February 01, 2011 4:44 AM
>>
>> Hello Santosh,
>>
>> On Fri, 28 Jan 2011, Santosh Shilimkar wrote:
>>
>>> On OMAP4, one can explicitly program INACTIVE as the power state
>> of
>>> the logic area inside the power domain. Techincally PD state
>> programmed
>>> to ON and if all the clock domains within the PD are idled, is
>> equivalent
>>> tp PD programmed to INACTIVE and all the clock domains within the
>> PD are
>>> idled. There won't be any power difference in above two.
>>>
>>> Since the CPUIDLE C-states explicitly make use of INACTIVE as a PD
>>> targeted state and also there is some additional latancy involved
>>> with PD INACTIVE vs PD ON, it's better to support it as an explcit
>>> PD state.
>>>
>>> This patch adds the support to allow explicit PD INACTIVE
>>> programming if supported.
>>
>> What does the hardware do when the powerdomain is programmed to
>> INACTIVE?
>> Does it actually force the clockdomains idle?
>>
> No. It doesn't force it. The power domain to hit INACTIVE, the
> clockdomain within the power domain needs to idle and it is
> still a prerequisite. With INACTIVE being programmed, we could
> issue a sleep transition.
>
> PD_ON:
> No power transition, only clocks are gated. Power domain stays ON.
>
> PD_INA:
> Power domain transitions to INACTIVE state. All logic and
> memory stay powered. This state allows for a voltage
> sleep transition.
Just a small note on the latest point:
The voltage sleep transition can occur only if all power domains inside
a voltage domain are INACTIVE, RET or OFF.
Regards,
Benoit
^ permalink raw reply [flat|nested] 48+ messages in thread
* RE: [PATCH 1/6] omap4: powerdomain: Add supported INACTIVE power state
2011-02-01 6:29 ` Santosh Shilimkar
@ 2011-02-02 21:40 ` Paul Walmsley
-1 siblings, 0 replies; 48+ messages in thread
From: Paul Walmsley @ 2011-02-02 21:40 UTC (permalink / raw)
To: Santosh Shilimkar
Cc: linux-omap, Kevin Hilman, Benoit Cousson, Rajendra Nayak,
linux-arm-kernel
On Tue, 1 Feb 2011, Santosh Shilimkar wrote:
> > -----Original Message-----
> > From: Paul Walmsley [mailto:paul@pwsan.com]
> > Sent: Tuesday, February 01, 2011 4:44 AM
> >
> > What does the hardware do when the powerdomain is programmed to
> > INACTIVE?
> > Does it actually force the clockdomains idle?
>
> No. It doesn't force it. The power domain to hit INACTIVE, the
> clockdomain within the power domain needs to idle and it is
> still a prerequisite. With INACTIVE being programmed, we could
> issue a sleep transition.
>
> PD_ON:
> No power transition, only clocks are gated. Power domain stays ON.
>
> PD_INA:
> Power domain transitions to INACTIVE state. All logic and
> memory stay powered. This state allows for a voltage
> sleep transition.
Okay. So programming an OMAP4 powerdomain to INACTIVE is equivalent to
programming an OMAP3 powerdomain to ON with the PRM_VOLTCTRL.AUTO_SLEEP
bit to 1?
Are there any other dependencies with the PRM_VOLTCTRL_AUTO_CTRL_VDD*
registers, e.g., does the appropriate VDD bitfield there need to be set to
0x1 also to allow the sleep transition to occur?
- Paul
^ permalink raw reply [flat|nested] 48+ messages in thread
* [PATCH 1/6] omap4: powerdomain: Add supported INACTIVE power state
@ 2011-02-02 21:40 ` Paul Walmsley
0 siblings, 0 replies; 48+ messages in thread
From: Paul Walmsley @ 2011-02-02 21:40 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, 1 Feb 2011, Santosh Shilimkar wrote:
> > -----Original Message-----
> > From: Paul Walmsley [mailto:paul at pwsan.com]
> > Sent: Tuesday, February 01, 2011 4:44 AM
> >
> > What does the hardware do when the powerdomain is programmed to
> > INACTIVE?
> > Does it actually force the clockdomains idle?
>
> No. It doesn't force it. The power domain to hit INACTIVE, the
> clockdomain within the power domain needs to idle and it is
> still a prerequisite. With INACTIVE being programmed, we could
> issue a sleep transition.
>
> PD_ON:
> No power transition, only clocks are gated. Power domain stays ON.
>
> PD_INA:
> Power domain transitions to INACTIVE state. All logic and
> memory stay powered. This state allows for a voltage
> sleep transition.
Okay. So programming an OMAP4 powerdomain to INACTIVE is equivalent to
programming an OMAP3 powerdomain to ON with the PRM_VOLTCTRL.AUTO_SLEEP
bit to 1?
Are there any other dependencies with the PRM_VOLTCTRL_AUTO_CTRL_VDD*
registers, e.g., does the appropriate VDD bitfield there need to be set to
0x1 also to allow the sleep transition to occur?
- Paul
^ permalink raw reply [flat|nested] 48+ messages in thread
* RE: [PATCH 1/6] omap4: powerdomain: Add supported INACTIVE power state
2011-02-02 21:40 ` Paul Walmsley
@ 2011-02-03 8:55 ` Santosh Shilimkar
-1 siblings, 0 replies; 48+ messages in thread
From: Santosh Shilimkar @ 2011-02-03 8:55 UTC (permalink / raw)
To: Paul Walmsley
Cc: linux-omap, Kevin Hilman, Benoit Cousson, Rajendra Nayak,
linux-arm-kernel
> -----Original Message-----
> From: Paul Walmsley [mailto:paul@pwsan.com]
> Sent: Thursday, February 03, 2011 3:11 AM
> To: Santosh Shilimkar
> Cc: linux-omap@vger.kernel.org; Kevin Hilman; Benoit Cousson;
> Rajendra Nayak; linux-arm-kernel@lists.infradead.org
> Subject: RE: [PATCH 1/6] omap4: powerdomain: Add supported INACTIVE
> power state
>
> On Tue, 1 Feb 2011, Santosh Shilimkar wrote:
>
> > > -----Original Message-----
> > > From: Paul Walmsley [mailto:paul@pwsan.com]
> > > Sent: Tuesday, February 01, 2011 4:44 AM
> > >
> > > What does the hardware do when the powerdomain is programmed to
> > > INACTIVE?
> > > Does it actually force the clockdomains idle?
> >
> > No. It doesn't force it. The power domain to hit INACTIVE, the
> > clockdomain within the power domain needs to idle and it is
> > still a prerequisite. With INACTIVE being programmed, we could
> > issue a sleep transition.
> >
> > PD_ON:
> > No power transition, only clocks are gated. Power domain stays ON.
> >
> > PD_INA:
> > Power domain transitions to INACTIVE state. All logic and
> > memory stay powered. This state allows for a voltage
> > sleep transition.
>
> Okay. So programming an OMAP4 powerdomain to INACTIVE is equivalent
> to
> programming an OMAP3 powerdomain to ON with the
> PRM_VOLTCTRL.AUTO_SLEEP
> bit to 1?
>
> Are there any other dependencies with the
> PRM_VOLTCTRL_AUTO_CTRL_VDD*
> registers, e.g., does the appropriate VDD bitfield there need to be
> set to
> 0x1 also to allow the sleep transition to occur?
>
If we plan to do sleep transions, then DEVICE PRM needs to be
programmed for voltage level and the control bit enable.
Regards,
Santosh
^ permalink raw reply [flat|nested] 48+ messages in thread
* [PATCH 1/6] omap4: powerdomain: Add supported INACTIVE power state
@ 2011-02-03 8:55 ` Santosh Shilimkar
0 siblings, 0 replies; 48+ messages in thread
From: Santosh Shilimkar @ 2011-02-03 8:55 UTC (permalink / raw)
To: linux-arm-kernel
> -----Original Message-----
> From: Paul Walmsley [mailto:paul at pwsan.com]
> Sent: Thursday, February 03, 2011 3:11 AM
> To: Santosh Shilimkar
> Cc: linux-omap at vger.kernel.org; Kevin Hilman; Benoit Cousson;
> Rajendra Nayak; linux-arm-kernel at lists.infradead.org
> Subject: RE: [PATCH 1/6] omap4: powerdomain: Add supported INACTIVE
> power state
>
> On Tue, 1 Feb 2011, Santosh Shilimkar wrote:
>
> > > -----Original Message-----
> > > From: Paul Walmsley [mailto:paul at pwsan.com]
> > > Sent: Tuesday, February 01, 2011 4:44 AM
> > >
> > > What does the hardware do when the powerdomain is programmed to
> > > INACTIVE?
> > > Does it actually force the clockdomains idle?
> >
> > No. It doesn't force it. The power domain to hit INACTIVE, the
> > clockdomain within the power domain needs to idle and it is
> > still a prerequisite. With INACTIVE being programmed, we could
> > issue a sleep transition.
> >
> > PD_ON:
> > No power transition, only clocks are gated. Power domain stays ON.
> >
> > PD_INA:
> > Power domain transitions to INACTIVE state. All logic and
> > memory stay powered. This state allows for a voltage
> > sleep transition.
>
> Okay. So programming an OMAP4 powerdomain to INACTIVE is equivalent
> to
> programming an OMAP3 powerdomain to ON with the
> PRM_VOLTCTRL.AUTO_SLEEP
> bit to 1?
>
> Are there any other dependencies with the
> PRM_VOLTCTRL_AUTO_CTRL_VDD*
> registers, e.g., does the appropriate VDD bitfield there need to be
> set to
> 0x1 also to allow the sleep transition to occur?
>
If we plan to do sleep transions, then DEVICE PRM needs to be
programmed for voltage level and the control bit enable.
Regards,
Santosh
^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: [PATCH 1/6] omap4: powerdomain: Add supported INACTIVE power state
2011-01-28 11:04 ` Santosh Shilimkar
@ 2011-02-02 1:19 ` Kevin Hilman
-1 siblings, 0 replies; 48+ messages in thread
From: Kevin Hilman @ 2011-02-02 1:19 UTC (permalink / raw)
To: Santosh Shilimkar; +Cc: linux-omap, paul, b-cousson, rnayak, linux-arm-kernel
Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
> On OMAP4, one can explicitly program INACTIVE as the power state of
> the logic area inside the power domain. Techincally PD state programmed
> to ON and if all the clock domains within the PD are idled, is equivalent
> tp PD programmed to INACTIVE and all the clock domains within the PD are
> idled. There won't be any power difference in above two.
>
> Since the CPUIDLE C-states explicitly make use of INACTIVE as a PD
> targeted state
I think you're referring to code that is not upstream here. I'm not
aware of any C-states targetting INACTIVE.
Kevin
> and also there is some additional latancy involved
> with PD INACTIVE vs PD ON, it's better to support it as an explcit
> PD state.
>
> This patch adds the support to allow explicit PD INACTIVE
> programming if supported.
>
> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
> Cc: Paul Walmsley <paul@pwsan.com>
> ---
> arch/arm/mach-omap2/powerdomain.h | 12 ++++++++++++
> arch/arm/mach-omap2/powerdomains44xx_data.c | 26 +++++++++++++-------------
> 2 files changed, 25 insertions(+), 13 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/powerdomain.h b/arch/arm/mach-omap2/powerdomain.h
> index c66431e..0e15ca7 100644
> --- a/arch/arm/mach-omap2/powerdomain.h
> +++ b/arch/arm/mach-omap2/powerdomain.h
> @@ -46,6 +46,18 @@
>
> #define PWRSTS_OFF_RET_ON (PWRSTS_OFF_RET | (1 << PWRDM_POWER_ON))
>
> +#define PWRSTS_RET_INA_ON ((1 << PWRDM_POWER_RET) | \
> + (1 << PWRDM_POWER_INACTIVE) | \
> + (1 << PWRDM_POWER_ON))
> +
> +#define PWRSTS_OFF_INA_ON ((1 << PWRDM_POWER_OFF) | \
> + (1 << PWRDM_POWER_INACTIVE) | \
> + (1 << PWRDM_POWER_ON))
> +
> +#define PWRSTS_OFF_RET_INA_ON ((1 << PWRDM_POWER_OFF) | \
> + (1 << PWRDM_POWER_RET) | \
> + (1 << PWRDM_POWER_INACTIVE) | \
> + (1 << PWRDM_POWER_ON))
>
> /* Powerdomain flags */
> #define PWRDM_HAS_HDWR_SAR (1 << 0) /* hardware save-and-restore support */
> diff --git a/arch/arm/mach-omap2/powerdomains44xx_data.c b/arch/arm/mach-omap2/powerdomains44xx_data.c
> index 26d7641..96cde98 100644
> --- a/arch/arm/mach-omap2/powerdomains44xx_data.c
> +++ b/arch/arm/mach-omap2/powerdomains44xx_data.c
> @@ -36,7 +36,7 @@ static struct powerdomain core_44xx_pwrdm = {
> .prcm_offs = OMAP4430_PRM_CORE_INST,
> .prcm_partition = OMAP4430_PRM_PARTITION,
> .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
> - .pwrsts = PWRSTS_RET_ON,
> + .pwrsts = PWRSTS_RET_INA_ON,
> .pwrsts_logic_ret = PWRSTS_OFF_RET,
> .banks = 5,
> .pwrsts_mem_ret = {
> @@ -62,7 +62,7 @@ static struct powerdomain gfx_44xx_pwrdm = {
> .prcm_offs = OMAP4430_PRM_GFX_INST,
> .prcm_partition = OMAP4430_PRM_PARTITION,
> .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
> - .pwrsts = PWRSTS_OFF_ON,
> + .pwrsts = PWRSTS_OFF_INA_ON,
> .banks = 1,
> .pwrsts_mem_ret = {
> [0] = PWRDM_POWER_OFF, /* gfx_mem */
> @@ -79,7 +79,7 @@ static struct powerdomain abe_44xx_pwrdm = {
> .prcm_offs = OMAP4430_PRM_ABE_INST,
> .prcm_partition = OMAP4430_PRM_PARTITION,
> .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
> - .pwrsts = PWRSTS_OFF_RET_ON,
> + .pwrsts = PWRSTS_OFF_RET_INA_ON,
> .pwrsts_logic_ret = PWRDM_POWER_OFF,
> .banks = 2,
> .pwrsts_mem_ret = {
> @@ -99,7 +99,7 @@ static struct powerdomain dss_44xx_pwrdm = {
> .prcm_offs = OMAP4430_PRM_DSS_INST,
> .prcm_partition = OMAP4430_PRM_PARTITION,
> .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
> - .pwrsts = PWRSTS_OFF_RET_ON,
> + .pwrsts = PWRSTS_OFF_RET_INA_ON,
> .pwrsts_logic_ret = PWRSTS_OFF,
> .banks = 1,
> .pwrsts_mem_ret = {
> @@ -117,7 +117,7 @@ static struct powerdomain tesla_44xx_pwrdm = {
> .prcm_offs = OMAP4430_PRM_TESLA_INST,
> .prcm_partition = OMAP4430_PRM_PARTITION,
> .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
> - .pwrsts = PWRSTS_OFF_RET_ON,
> + .pwrsts = PWRSTS_OFF_RET_INA_ON,
> .pwrsts_logic_ret = PWRSTS_OFF_RET,
> .banks = 3,
> .pwrsts_mem_ret = {
> @@ -155,7 +155,7 @@ static struct powerdomain cpu0_44xx_pwrdm = {
> .prcm_offs = OMAP4430_PRCM_MPU_CPU0_INST,
> .prcm_partition = OMAP4430_PRCM_MPU_PARTITION,
> .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
> - .pwrsts = PWRSTS_OFF_RET_ON,
> + .pwrsts = PWRSTS_OFF_RET_INA_ON,
> .pwrsts_logic_ret = PWRSTS_OFF_RET,
> .banks = 1,
> .pwrsts_mem_ret = {
> @@ -172,7 +172,7 @@ static struct powerdomain cpu1_44xx_pwrdm = {
> .prcm_offs = OMAP4430_PRCM_MPU_CPU1_INST,
> .prcm_partition = OMAP4430_PRCM_MPU_PARTITION,
> .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
> - .pwrsts = PWRSTS_OFF_RET_ON,
> + .pwrsts = PWRSTS_OFF_RET_INA_ON,
> .pwrsts_logic_ret = PWRSTS_OFF_RET,
> .banks = 1,
> .pwrsts_mem_ret = {
> @@ -205,7 +205,7 @@ static struct powerdomain mpu_44xx_pwrdm = {
> .prcm_offs = OMAP4430_PRM_MPU_INST,
> .prcm_partition = OMAP4430_PRM_PARTITION,
> .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
> - .pwrsts = PWRSTS_OFF_RET_ON,
> + .pwrsts = PWRSTS_OFF_RET_INA_ON,
> .pwrsts_logic_ret = PWRSTS_OFF_RET,
> .banks = 3,
> .pwrsts_mem_ret = {
> @@ -226,7 +226,7 @@ static struct powerdomain ivahd_44xx_pwrdm = {
> .prcm_offs = OMAP4430_PRM_IVAHD_INST,
> .prcm_partition = OMAP4430_PRM_PARTITION,
> .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
> - .pwrsts = PWRSTS_OFF_RET_ON,
> + .pwrsts = PWRSTS_OFF_RET_INA_ON,
> .pwrsts_logic_ret = PWRDM_POWER_OFF,
> .banks = 4,
> .pwrsts_mem_ret = {
> @@ -250,7 +250,7 @@ static struct powerdomain cam_44xx_pwrdm = {
> .prcm_offs = OMAP4430_PRM_CAM_INST,
> .prcm_partition = OMAP4430_PRM_PARTITION,
> .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
> - .pwrsts = PWRSTS_OFF_ON,
> + .pwrsts = PWRSTS_OFF_INA_ON,
> .banks = 1,
> .pwrsts_mem_ret = {
> [0] = PWRDM_POWER_OFF, /* cam_mem */
> @@ -267,7 +267,7 @@ static struct powerdomain l3init_44xx_pwrdm = {
> .prcm_offs = OMAP4430_PRM_L3INIT_INST,
> .prcm_partition = OMAP4430_PRM_PARTITION,
> .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
> - .pwrsts = PWRSTS_RET_ON,
> + .pwrsts = PWRSTS_OFF_RET_INA_ON,
> .pwrsts_logic_ret = PWRSTS_OFF_RET,
> .banks = 1,
> .pwrsts_mem_ret = {
> @@ -285,7 +285,7 @@ static struct powerdomain l4per_44xx_pwrdm = {
> .prcm_offs = OMAP4430_PRM_L4PER_INST,
> .prcm_partition = OMAP4430_PRM_PARTITION,
> .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
> - .pwrsts = PWRSTS_RET_ON,
> + .pwrsts = PWRSTS_RET_INA_ON,
> .pwrsts_logic_ret = PWRSTS_OFF_RET,
> .banks = 2,
> .pwrsts_mem_ret = {
> @@ -317,7 +317,7 @@ static struct powerdomain cefuse_44xx_pwrdm = {
> .prcm_offs = OMAP4430_PRM_CEFUSE_INST,
> .prcm_partition = OMAP4430_PRM_PARTITION,
> .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
> - .pwrsts = PWRSTS_OFF_ON,
> + .pwrsts = PWRSTS_OFF_INA_ON,
> };
>
> /*
^ permalink raw reply [flat|nested] 48+ messages in thread* [PATCH 1/6] omap4: powerdomain: Add supported INACTIVE power state
@ 2011-02-02 1:19 ` Kevin Hilman
0 siblings, 0 replies; 48+ messages in thread
From: Kevin Hilman @ 2011-02-02 1:19 UTC (permalink / raw)
To: linux-arm-kernel
Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
> On OMAP4, one can explicitly program INACTIVE as the power state of
> the logic area inside the power domain. Techincally PD state programmed
> to ON and if all the clock domains within the PD are idled, is equivalent
> tp PD programmed to INACTIVE and all the clock domains within the PD are
> idled. There won't be any power difference in above two.
>
> Since the CPUIDLE C-states explicitly make use of INACTIVE as a PD
> targeted state
I think you're referring to code that is not upstream here. I'm not
aware of any C-states targetting INACTIVE.
Kevin
> and also there is some additional latancy involved
> with PD INACTIVE vs PD ON, it's better to support it as an explcit
> PD state.
>
> This patch adds the support to allow explicit PD INACTIVE
> programming if supported.
>
> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
> Cc: Paul Walmsley <paul@pwsan.com>
> ---
> arch/arm/mach-omap2/powerdomain.h | 12 ++++++++++++
> arch/arm/mach-omap2/powerdomains44xx_data.c | 26 +++++++++++++-------------
> 2 files changed, 25 insertions(+), 13 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/powerdomain.h b/arch/arm/mach-omap2/powerdomain.h
> index c66431e..0e15ca7 100644
> --- a/arch/arm/mach-omap2/powerdomain.h
> +++ b/arch/arm/mach-omap2/powerdomain.h
> @@ -46,6 +46,18 @@
>
> #define PWRSTS_OFF_RET_ON (PWRSTS_OFF_RET | (1 << PWRDM_POWER_ON))
>
> +#define PWRSTS_RET_INA_ON ((1 << PWRDM_POWER_RET) | \
> + (1 << PWRDM_POWER_INACTIVE) | \
> + (1 << PWRDM_POWER_ON))
> +
> +#define PWRSTS_OFF_INA_ON ((1 << PWRDM_POWER_OFF) | \
> + (1 << PWRDM_POWER_INACTIVE) | \
> + (1 << PWRDM_POWER_ON))
> +
> +#define PWRSTS_OFF_RET_INA_ON ((1 << PWRDM_POWER_OFF) | \
> + (1 << PWRDM_POWER_RET) | \
> + (1 << PWRDM_POWER_INACTIVE) | \
> + (1 << PWRDM_POWER_ON))
>
> /* Powerdomain flags */
> #define PWRDM_HAS_HDWR_SAR (1 << 0) /* hardware save-and-restore support */
> diff --git a/arch/arm/mach-omap2/powerdomains44xx_data.c b/arch/arm/mach-omap2/powerdomains44xx_data.c
> index 26d7641..96cde98 100644
> --- a/arch/arm/mach-omap2/powerdomains44xx_data.c
> +++ b/arch/arm/mach-omap2/powerdomains44xx_data.c
> @@ -36,7 +36,7 @@ static struct powerdomain core_44xx_pwrdm = {
> .prcm_offs = OMAP4430_PRM_CORE_INST,
> .prcm_partition = OMAP4430_PRM_PARTITION,
> .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
> - .pwrsts = PWRSTS_RET_ON,
> + .pwrsts = PWRSTS_RET_INA_ON,
> .pwrsts_logic_ret = PWRSTS_OFF_RET,
> .banks = 5,
> .pwrsts_mem_ret = {
> @@ -62,7 +62,7 @@ static struct powerdomain gfx_44xx_pwrdm = {
> .prcm_offs = OMAP4430_PRM_GFX_INST,
> .prcm_partition = OMAP4430_PRM_PARTITION,
> .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
> - .pwrsts = PWRSTS_OFF_ON,
> + .pwrsts = PWRSTS_OFF_INA_ON,
> .banks = 1,
> .pwrsts_mem_ret = {
> [0] = PWRDM_POWER_OFF, /* gfx_mem */
> @@ -79,7 +79,7 @@ static struct powerdomain abe_44xx_pwrdm = {
> .prcm_offs = OMAP4430_PRM_ABE_INST,
> .prcm_partition = OMAP4430_PRM_PARTITION,
> .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
> - .pwrsts = PWRSTS_OFF_RET_ON,
> + .pwrsts = PWRSTS_OFF_RET_INA_ON,
> .pwrsts_logic_ret = PWRDM_POWER_OFF,
> .banks = 2,
> .pwrsts_mem_ret = {
> @@ -99,7 +99,7 @@ static struct powerdomain dss_44xx_pwrdm = {
> .prcm_offs = OMAP4430_PRM_DSS_INST,
> .prcm_partition = OMAP4430_PRM_PARTITION,
> .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
> - .pwrsts = PWRSTS_OFF_RET_ON,
> + .pwrsts = PWRSTS_OFF_RET_INA_ON,
> .pwrsts_logic_ret = PWRSTS_OFF,
> .banks = 1,
> .pwrsts_mem_ret = {
> @@ -117,7 +117,7 @@ static struct powerdomain tesla_44xx_pwrdm = {
> .prcm_offs = OMAP4430_PRM_TESLA_INST,
> .prcm_partition = OMAP4430_PRM_PARTITION,
> .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
> - .pwrsts = PWRSTS_OFF_RET_ON,
> + .pwrsts = PWRSTS_OFF_RET_INA_ON,
> .pwrsts_logic_ret = PWRSTS_OFF_RET,
> .banks = 3,
> .pwrsts_mem_ret = {
> @@ -155,7 +155,7 @@ static struct powerdomain cpu0_44xx_pwrdm = {
> .prcm_offs = OMAP4430_PRCM_MPU_CPU0_INST,
> .prcm_partition = OMAP4430_PRCM_MPU_PARTITION,
> .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
> - .pwrsts = PWRSTS_OFF_RET_ON,
> + .pwrsts = PWRSTS_OFF_RET_INA_ON,
> .pwrsts_logic_ret = PWRSTS_OFF_RET,
> .banks = 1,
> .pwrsts_mem_ret = {
> @@ -172,7 +172,7 @@ static struct powerdomain cpu1_44xx_pwrdm = {
> .prcm_offs = OMAP4430_PRCM_MPU_CPU1_INST,
> .prcm_partition = OMAP4430_PRCM_MPU_PARTITION,
> .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
> - .pwrsts = PWRSTS_OFF_RET_ON,
> + .pwrsts = PWRSTS_OFF_RET_INA_ON,
> .pwrsts_logic_ret = PWRSTS_OFF_RET,
> .banks = 1,
> .pwrsts_mem_ret = {
> @@ -205,7 +205,7 @@ static struct powerdomain mpu_44xx_pwrdm = {
> .prcm_offs = OMAP4430_PRM_MPU_INST,
> .prcm_partition = OMAP4430_PRM_PARTITION,
> .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
> - .pwrsts = PWRSTS_OFF_RET_ON,
> + .pwrsts = PWRSTS_OFF_RET_INA_ON,
> .pwrsts_logic_ret = PWRSTS_OFF_RET,
> .banks = 3,
> .pwrsts_mem_ret = {
> @@ -226,7 +226,7 @@ static struct powerdomain ivahd_44xx_pwrdm = {
> .prcm_offs = OMAP4430_PRM_IVAHD_INST,
> .prcm_partition = OMAP4430_PRM_PARTITION,
> .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
> - .pwrsts = PWRSTS_OFF_RET_ON,
> + .pwrsts = PWRSTS_OFF_RET_INA_ON,
> .pwrsts_logic_ret = PWRDM_POWER_OFF,
> .banks = 4,
> .pwrsts_mem_ret = {
> @@ -250,7 +250,7 @@ static struct powerdomain cam_44xx_pwrdm = {
> .prcm_offs = OMAP4430_PRM_CAM_INST,
> .prcm_partition = OMAP4430_PRM_PARTITION,
> .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
> - .pwrsts = PWRSTS_OFF_ON,
> + .pwrsts = PWRSTS_OFF_INA_ON,
> .banks = 1,
> .pwrsts_mem_ret = {
> [0] = PWRDM_POWER_OFF, /* cam_mem */
> @@ -267,7 +267,7 @@ static struct powerdomain l3init_44xx_pwrdm = {
> .prcm_offs = OMAP4430_PRM_L3INIT_INST,
> .prcm_partition = OMAP4430_PRM_PARTITION,
> .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
> - .pwrsts = PWRSTS_RET_ON,
> + .pwrsts = PWRSTS_OFF_RET_INA_ON,
> .pwrsts_logic_ret = PWRSTS_OFF_RET,
> .banks = 1,
> .pwrsts_mem_ret = {
> @@ -285,7 +285,7 @@ static struct powerdomain l4per_44xx_pwrdm = {
> .prcm_offs = OMAP4430_PRM_L4PER_INST,
> .prcm_partition = OMAP4430_PRM_PARTITION,
> .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
> - .pwrsts = PWRSTS_RET_ON,
> + .pwrsts = PWRSTS_RET_INA_ON,
> .pwrsts_logic_ret = PWRSTS_OFF_RET,
> .banks = 2,
> .pwrsts_mem_ret = {
> @@ -317,7 +317,7 @@ static struct powerdomain cefuse_44xx_pwrdm = {
> .prcm_offs = OMAP4430_PRM_CEFUSE_INST,
> .prcm_partition = OMAP4430_PRM_PARTITION,
> .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
> - .pwrsts = PWRSTS_OFF_ON,
> + .pwrsts = PWRSTS_OFF_INA_ON,
> };
>
> /*
^ permalink raw reply [flat|nested] 48+ messages in thread* RE: [PATCH 1/6] omap4: powerdomain: Add supported INACTIVE power state
2011-02-02 1:19 ` Kevin Hilman
@ 2011-02-02 4:19 ` Rajendra Nayak
-1 siblings, 0 replies; 48+ messages in thread
From: Rajendra Nayak @ 2011-02-02 4:19 UTC (permalink / raw)
To: Kevin Hilman, Santosh Shilimkar
Cc: linux-omap, paul, Benoit Cousson, linux-arm-kernel
Hi Kevin,
> -----Original Message-----
> From: Kevin Hilman [mailto:khilman@ti.com]
> Sent: Wednesday, February 02, 2011 6:49 AM
> To: Santosh Shilimkar
> Cc: linux-omap@vger.kernel.org; paul@pwsan.com; b-cousson@ti.com;
rnayak@ti.com; linux-arm-
> kernel@lists.infradead.org
> Subject: Re: [PATCH 1/6] omap4: powerdomain: Add supported INACTIVE
power state
>
> Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
>
> > On OMAP4, one can explicitly program INACTIVE as the power state of
> > the logic area inside the power domain. Techincally PD state
programmed
> > to ON and if all the clock domains within the PD are idled, is
equivalent
> > tp PD programmed to INACTIVE and all the clock domains within the PD
are
> > idled. There won't be any power difference in above two.
> >
> > Since the CPUIDLE C-states explicitly make use of INACTIVE as a PD
> > targeted state
>
> I think you're referring to code that is not upstream here. I'm not
> aware of any C-states targetting INACTIVE.
On OMAP3, C2/3/4 have target state as CORE inactive, while C1 is
CORE active.
Regards,
Rajendra
>
> Kevin
>
> > and also there is some additional latancy involved
> > with PD INACTIVE vs PD ON, it's better to support it as an explcit
> > PD state.
> >
> > This patch adds the support to allow explicit PD INACTIVE
> > programming if supported.
> >
> > Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
> > Cc: Paul Walmsley <paul@pwsan.com>
> > ---
> > arch/arm/mach-omap2/powerdomain.h | 12 ++++++++++++
> > arch/arm/mach-omap2/powerdomains44xx_data.c | 26
+++++++++++++-------------
> > 2 files changed, 25 insertions(+), 13 deletions(-)
> >
> > diff --git a/arch/arm/mach-omap2/powerdomain.h
b/arch/arm/mach-omap2/powerdomain.h
> > index c66431e..0e15ca7 100644
> > --- a/arch/arm/mach-omap2/powerdomain.h
> > +++ b/arch/arm/mach-omap2/powerdomain.h
> > @@ -46,6 +46,18 @@
> >
> > #define PWRSTS_OFF_RET_ON (PWRSTS_OFF_RET | (1 << PWRDM_POWER_ON))
> >
> > +#define PWRSTS_RET_INA_ON ((1 << PWRDM_POWER_RET) | \
> > + (1 << PWRDM_POWER_INACTIVE) | \
> > + (1 << PWRDM_POWER_ON))
> > +
> > +#define PWRSTS_OFF_INA_ON ((1 << PWRDM_POWER_OFF) | \
> > + (1 << PWRDM_POWER_INACTIVE) | \
> > + (1 << PWRDM_POWER_ON))
> > +
> > +#define PWRSTS_OFF_RET_INA_ON ((1 << PWRDM_POWER_OFF) | \
> > + (1 << PWRDM_POWER_RET) | \
> > + (1 << PWRDM_POWER_INACTIVE) | \
> > + (1 << PWRDM_POWER_ON))
> >
> > /* Powerdomain flags */
> > #define PWRDM_HAS_HDWR_SAR (1 << 0) /* hardware save-and-restore
support */
> > diff --git a/arch/arm/mach-omap2/powerdomains44xx_data.c
b/arch/arm/mach-omap2/powerdomains44xx_data.c
> > index 26d7641..96cde98 100644
> > --- a/arch/arm/mach-omap2/powerdomains44xx_data.c
> > +++ b/arch/arm/mach-omap2/powerdomains44xx_data.c
> > @@ -36,7 +36,7 @@ static struct powerdomain core_44xx_pwrdm = {
> > .prcm_offs = OMAP4430_PRM_CORE_INST,
> > .prcm_partition = OMAP4430_PRM_PARTITION,
> > .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
> > - .pwrsts = PWRSTS_RET_ON,
> > + .pwrsts = PWRSTS_RET_INA_ON,
> > .pwrsts_logic_ret = PWRSTS_OFF_RET,
> > .banks = 5,
> > .pwrsts_mem_ret = {
> > @@ -62,7 +62,7 @@ static struct powerdomain gfx_44xx_pwrdm = {
> > .prcm_offs = OMAP4430_PRM_GFX_INST,
> > .prcm_partition = OMAP4430_PRM_PARTITION,
> > .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
> > - .pwrsts = PWRSTS_OFF_ON,
> > + .pwrsts = PWRSTS_OFF_INA_ON,
> > .banks = 1,
> > .pwrsts_mem_ret = {
> > [0] = PWRDM_POWER_OFF, /* gfx_mem */
> > @@ -79,7 +79,7 @@ static struct powerdomain abe_44xx_pwrdm = {
> > .prcm_offs = OMAP4430_PRM_ABE_INST,
> > .prcm_partition = OMAP4430_PRM_PARTITION,
> > .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
> > - .pwrsts = PWRSTS_OFF_RET_ON,
> > + .pwrsts = PWRSTS_OFF_RET_INA_ON,
> > .pwrsts_logic_ret = PWRDM_POWER_OFF,
> > .banks = 2,
> > .pwrsts_mem_ret = {
> > @@ -99,7 +99,7 @@ static struct powerdomain dss_44xx_pwrdm = {
> > .prcm_offs = OMAP4430_PRM_DSS_INST,
> > .prcm_partition = OMAP4430_PRM_PARTITION,
> > .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
> > - .pwrsts = PWRSTS_OFF_RET_ON,
> > + .pwrsts = PWRSTS_OFF_RET_INA_ON,
> > .pwrsts_logic_ret = PWRSTS_OFF,
> > .banks = 1,
> > .pwrsts_mem_ret = {
> > @@ -117,7 +117,7 @@ static struct powerdomain tesla_44xx_pwrdm = {
> > .prcm_offs = OMAP4430_PRM_TESLA_INST,
> > .prcm_partition = OMAP4430_PRM_PARTITION,
> > .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
> > - .pwrsts = PWRSTS_OFF_RET_ON,
> > + .pwrsts = PWRSTS_OFF_RET_INA_ON,
> > .pwrsts_logic_ret = PWRSTS_OFF_RET,
> > .banks = 3,
> > .pwrsts_mem_ret = {
> > @@ -155,7 +155,7 @@ static struct powerdomain cpu0_44xx_pwrdm = {
> > .prcm_offs = OMAP4430_PRCM_MPU_CPU0_INST,
> > .prcm_partition = OMAP4430_PRCM_MPU_PARTITION,
> > .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
> > - .pwrsts = PWRSTS_OFF_RET_ON,
> > + .pwrsts = PWRSTS_OFF_RET_INA_ON,
> > .pwrsts_logic_ret = PWRSTS_OFF_RET,
> > .banks = 1,
> > .pwrsts_mem_ret = {
> > @@ -172,7 +172,7 @@ static struct powerdomain cpu1_44xx_pwrdm = {
> > .prcm_offs = OMAP4430_PRCM_MPU_CPU1_INST,
> > .prcm_partition = OMAP4430_PRCM_MPU_PARTITION,
> > .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
> > - .pwrsts = PWRSTS_OFF_RET_ON,
> > + .pwrsts = PWRSTS_OFF_RET_INA_ON,
> > .pwrsts_logic_ret = PWRSTS_OFF_RET,
> > .banks = 1,
> > .pwrsts_mem_ret = {
> > @@ -205,7 +205,7 @@ static struct powerdomain mpu_44xx_pwrdm = {
> > .prcm_offs = OMAP4430_PRM_MPU_INST,
> > .prcm_partition = OMAP4430_PRM_PARTITION,
> > .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
> > - .pwrsts = PWRSTS_OFF_RET_ON,
> > + .pwrsts = PWRSTS_OFF_RET_INA_ON,
> > .pwrsts_logic_ret = PWRSTS_OFF_RET,
> > .banks = 3,
> > .pwrsts_mem_ret = {
> > @@ -226,7 +226,7 @@ static struct powerdomain ivahd_44xx_pwrdm = {
> > .prcm_offs = OMAP4430_PRM_IVAHD_INST,
> > .prcm_partition = OMAP4430_PRM_PARTITION,
> > .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
> > - .pwrsts = PWRSTS_OFF_RET_ON,
> > + .pwrsts = PWRSTS_OFF_RET_INA_ON,
> > .pwrsts_logic_ret = PWRDM_POWER_OFF,
> > .banks = 4,
> > .pwrsts_mem_ret = {
> > @@ -250,7 +250,7 @@ static struct powerdomain cam_44xx_pwrdm = {
> > .prcm_offs = OMAP4430_PRM_CAM_INST,
> > .prcm_partition = OMAP4430_PRM_PARTITION,
> > .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
> > - .pwrsts = PWRSTS_OFF_ON,
> > + .pwrsts = PWRSTS_OFF_INA_ON,
> > .banks = 1,
> > .pwrsts_mem_ret = {
> > [0] = PWRDM_POWER_OFF, /* cam_mem */
> > @@ -267,7 +267,7 @@ static struct powerdomain l3init_44xx_pwrdm = {
> > .prcm_offs = OMAP4430_PRM_L3INIT_INST,
> > .prcm_partition = OMAP4430_PRM_PARTITION,
> > .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
> > - .pwrsts = PWRSTS_RET_ON,
> > + .pwrsts = PWRSTS_OFF_RET_INA_ON,
> > .pwrsts_logic_ret = PWRSTS_OFF_RET,
> > .banks = 1,
> > .pwrsts_mem_ret = {
> > @@ -285,7 +285,7 @@ static struct powerdomain l4per_44xx_pwrdm = {
> > .prcm_offs = OMAP4430_PRM_L4PER_INST,
> > .prcm_partition = OMAP4430_PRM_PARTITION,
> > .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
> > - .pwrsts = PWRSTS_RET_ON,
> > + .pwrsts = PWRSTS_RET_INA_ON,
> > .pwrsts_logic_ret = PWRSTS_OFF_RET,
> > .banks = 2,
> > .pwrsts_mem_ret = {
> > @@ -317,7 +317,7 @@ static struct powerdomain cefuse_44xx_pwrdm = {
> > .prcm_offs = OMAP4430_PRM_CEFUSE_INST,
> > .prcm_partition = OMAP4430_PRM_PARTITION,
> > .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
> > - .pwrsts = PWRSTS_OFF_ON,
> > + .pwrsts = PWRSTS_OFF_INA_ON,
> > };
> >
> > /*
^ permalink raw reply [flat|nested] 48+ messages in thread* [PATCH 1/6] omap4: powerdomain: Add supported INACTIVE power state
@ 2011-02-02 4:19 ` Rajendra Nayak
0 siblings, 0 replies; 48+ messages in thread
From: Rajendra Nayak @ 2011-02-02 4:19 UTC (permalink / raw)
To: linux-arm-kernel
Hi Kevin,
> -----Original Message-----
> From: Kevin Hilman [mailto:khilman at ti.com]
> Sent: Wednesday, February 02, 2011 6:49 AM
> To: Santosh Shilimkar
> Cc: linux-omap at vger.kernel.org; paul at pwsan.com; b-cousson at ti.com;
rnayak at ti.com; linux-arm-
> kernel at lists.infradead.org
> Subject: Re: [PATCH 1/6] omap4: powerdomain: Add supported INACTIVE
power state
>
> Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
>
> > On OMAP4, one can explicitly program INACTIVE as the power state of
> > the logic area inside the power domain. Techincally PD state
programmed
> > to ON and if all the clock domains within the PD are idled, is
equivalent
> > tp PD programmed to INACTIVE and all the clock domains within the PD
are
> > idled. There won't be any power difference in above two.
> >
> > Since the CPUIDLE C-states explicitly make use of INACTIVE as a PD
> > targeted state
>
> I think you're referring to code that is not upstream here. I'm not
> aware of any C-states targetting INACTIVE.
On OMAP3, C2/3/4 have target state as CORE inactive, while C1 is
CORE active.
Regards,
Rajendra
>
> Kevin
>
> > and also there is some additional latancy involved
> > with PD INACTIVE vs PD ON, it's better to support it as an explcit
> > PD state.
> >
> > This patch adds the support to allow explicit PD INACTIVE
> > programming if supported.
> >
> > Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
> > Cc: Paul Walmsley <paul@pwsan.com>
> > ---
> > arch/arm/mach-omap2/powerdomain.h | 12 ++++++++++++
> > arch/arm/mach-omap2/powerdomains44xx_data.c | 26
+++++++++++++-------------
> > 2 files changed, 25 insertions(+), 13 deletions(-)
> >
> > diff --git a/arch/arm/mach-omap2/powerdomain.h
b/arch/arm/mach-omap2/powerdomain.h
> > index c66431e..0e15ca7 100644
> > --- a/arch/arm/mach-omap2/powerdomain.h
> > +++ b/arch/arm/mach-omap2/powerdomain.h
> > @@ -46,6 +46,18 @@
> >
> > #define PWRSTS_OFF_RET_ON (PWRSTS_OFF_RET | (1 << PWRDM_POWER_ON))
> >
> > +#define PWRSTS_RET_INA_ON ((1 << PWRDM_POWER_RET) | \
> > + (1 << PWRDM_POWER_INACTIVE) | \
> > + (1 << PWRDM_POWER_ON))
> > +
> > +#define PWRSTS_OFF_INA_ON ((1 << PWRDM_POWER_OFF) | \
> > + (1 << PWRDM_POWER_INACTIVE) | \
> > + (1 << PWRDM_POWER_ON))
> > +
> > +#define PWRSTS_OFF_RET_INA_ON ((1 << PWRDM_POWER_OFF) | \
> > + (1 << PWRDM_POWER_RET) | \
> > + (1 << PWRDM_POWER_INACTIVE) | \
> > + (1 << PWRDM_POWER_ON))
> >
> > /* Powerdomain flags */
> > #define PWRDM_HAS_HDWR_SAR (1 << 0) /* hardware save-and-restore
support */
> > diff --git a/arch/arm/mach-omap2/powerdomains44xx_data.c
b/arch/arm/mach-omap2/powerdomains44xx_data.c
> > index 26d7641..96cde98 100644
> > --- a/arch/arm/mach-omap2/powerdomains44xx_data.c
> > +++ b/arch/arm/mach-omap2/powerdomains44xx_data.c
> > @@ -36,7 +36,7 @@ static struct powerdomain core_44xx_pwrdm = {
> > .prcm_offs = OMAP4430_PRM_CORE_INST,
> > .prcm_partition = OMAP4430_PRM_PARTITION,
> > .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
> > - .pwrsts = PWRSTS_RET_ON,
> > + .pwrsts = PWRSTS_RET_INA_ON,
> > .pwrsts_logic_ret = PWRSTS_OFF_RET,
> > .banks = 5,
> > .pwrsts_mem_ret = {
> > @@ -62,7 +62,7 @@ static struct powerdomain gfx_44xx_pwrdm = {
> > .prcm_offs = OMAP4430_PRM_GFX_INST,
> > .prcm_partition = OMAP4430_PRM_PARTITION,
> > .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
> > - .pwrsts = PWRSTS_OFF_ON,
> > + .pwrsts = PWRSTS_OFF_INA_ON,
> > .banks = 1,
> > .pwrsts_mem_ret = {
> > [0] = PWRDM_POWER_OFF, /* gfx_mem */
> > @@ -79,7 +79,7 @@ static struct powerdomain abe_44xx_pwrdm = {
> > .prcm_offs = OMAP4430_PRM_ABE_INST,
> > .prcm_partition = OMAP4430_PRM_PARTITION,
> > .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
> > - .pwrsts = PWRSTS_OFF_RET_ON,
> > + .pwrsts = PWRSTS_OFF_RET_INA_ON,
> > .pwrsts_logic_ret = PWRDM_POWER_OFF,
> > .banks = 2,
> > .pwrsts_mem_ret = {
> > @@ -99,7 +99,7 @@ static struct powerdomain dss_44xx_pwrdm = {
> > .prcm_offs = OMAP4430_PRM_DSS_INST,
> > .prcm_partition = OMAP4430_PRM_PARTITION,
> > .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
> > - .pwrsts = PWRSTS_OFF_RET_ON,
> > + .pwrsts = PWRSTS_OFF_RET_INA_ON,
> > .pwrsts_logic_ret = PWRSTS_OFF,
> > .banks = 1,
> > .pwrsts_mem_ret = {
> > @@ -117,7 +117,7 @@ static struct powerdomain tesla_44xx_pwrdm = {
> > .prcm_offs = OMAP4430_PRM_TESLA_INST,
> > .prcm_partition = OMAP4430_PRM_PARTITION,
> > .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
> > - .pwrsts = PWRSTS_OFF_RET_ON,
> > + .pwrsts = PWRSTS_OFF_RET_INA_ON,
> > .pwrsts_logic_ret = PWRSTS_OFF_RET,
> > .banks = 3,
> > .pwrsts_mem_ret = {
> > @@ -155,7 +155,7 @@ static struct powerdomain cpu0_44xx_pwrdm = {
> > .prcm_offs = OMAP4430_PRCM_MPU_CPU0_INST,
> > .prcm_partition = OMAP4430_PRCM_MPU_PARTITION,
> > .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
> > - .pwrsts = PWRSTS_OFF_RET_ON,
> > + .pwrsts = PWRSTS_OFF_RET_INA_ON,
> > .pwrsts_logic_ret = PWRSTS_OFF_RET,
> > .banks = 1,
> > .pwrsts_mem_ret = {
> > @@ -172,7 +172,7 @@ static struct powerdomain cpu1_44xx_pwrdm = {
> > .prcm_offs = OMAP4430_PRCM_MPU_CPU1_INST,
> > .prcm_partition = OMAP4430_PRCM_MPU_PARTITION,
> > .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
> > - .pwrsts = PWRSTS_OFF_RET_ON,
> > + .pwrsts = PWRSTS_OFF_RET_INA_ON,
> > .pwrsts_logic_ret = PWRSTS_OFF_RET,
> > .banks = 1,
> > .pwrsts_mem_ret = {
> > @@ -205,7 +205,7 @@ static struct powerdomain mpu_44xx_pwrdm = {
> > .prcm_offs = OMAP4430_PRM_MPU_INST,
> > .prcm_partition = OMAP4430_PRM_PARTITION,
> > .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
> > - .pwrsts = PWRSTS_OFF_RET_ON,
> > + .pwrsts = PWRSTS_OFF_RET_INA_ON,
> > .pwrsts_logic_ret = PWRSTS_OFF_RET,
> > .banks = 3,
> > .pwrsts_mem_ret = {
> > @@ -226,7 +226,7 @@ static struct powerdomain ivahd_44xx_pwrdm = {
> > .prcm_offs = OMAP4430_PRM_IVAHD_INST,
> > .prcm_partition = OMAP4430_PRM_PARTITION,
> > .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
> > - .pwrsts = PWRSTS_OFF_RET_ON,
> > + .pwrsts = PWRSTS_OFF_RET_INA_ON,
> > .pwrsts_logic_ret = PWRDM_POWER_OFF,
> > .banks = 4,
> > .pwrsts_mem_ret = {
> > @@ -250,7 +250,7 @@ static struct powerdomain cam_44xx_pwrdm = {
> > .prcm_offs = OMAP4430_PRM_CAM_INST,
> > .prcm_partition = OMAP4430_PRM_PARTITION,
> > .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
> > - .pwrsts = PWRSTS_OFF_ON,
> > + .pwrsts = PWRSTS_OFF_INA_ON,
> > .banks = 1,
> > .pwrsts_mem_ret = {
> > [0] = PWRDM_POWER_OFF, /* cam_mem */
> > @@ -267,7 +267,7 @@ static struct powerdomain l3init_44xx_pwrdm = {
> > .prcm_offs = OMAP4430_PRM_L3INIT_INST,
> > .prcm_partition = OMAP4430_PRM_PARTITION,
> > .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
> > - .pwrsts = PWRSTS_RET_ON,
> > + .pwrsts = PWRSTS_OFF_RET_INA_ON,
> > .pwrsts_logic_ret = PWRSTS_OFF_RET,
> > .banks = 1,
> > .pwrsts_mem_ret = {
> > @@ -285,7 +285,7 @@ static struct powerdomain l4per_44xx_pwrdm = {
> > .prcm_offs = OMAP4430_PRM_L4PER_INST,
> > .prcm_partition = OMAP4430_PRM_PARTITION,
> > .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
> > - .pwrsts = PWRSTS_RET_ON,
> > + .pwrsts = PWRSTS_RET_INA_ON,
> > .pwrsts_logic_ret = PWRSTS_OFF_RET,
> > .banks = 2,
> > .pwrsts_mem_ret = {
> > @@ -317,7 +317,7 @@ static struct powerdomain cefuse_44xx_pwrdm = {
> > .prcm_offs = OMAP4430_PRM_CEFUSE_INST,
> > .prcm_partition = OMAP4430_PRM_PARTITION,
> > .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
> > - .pwrsts = PWRSTS_OFF_ON,
> > + .pwrsts = PWRSTS_OFF_INA_ON,
> > };
> >
> > /*
^ permalink raw reply [flat|nested] 48+ messages in thread* Re: [PATCH 1/6] omap4: powerdomain: Add supported INACTIVE power state
2011-02-02 4:19 ` Rajendra Nayak
@ 2011-02-02 21:28 ` Kevin Hilman
-1 siblings, 0 replies; 48+ messages in thread
From: Kevin Hilman @ 2011-02-02 21:28 UTC (permalink / raw)
To: Rajendra Nayak
Cc: Santosh Shilimkar, linux-omap, paul, Benoit Cousson, linux-arm-kernel
Rajendra Nayak <rnayak@ti.com> writes:
> Hi Kevin,
>
>> -----Original Message-----
>> From: Kevin Hilman [mailto:khilman@ti.com]
>> Sent: Wednesday, February 02, 2011 6:49 AM
>> To: Santosh Shilimkar
>> Cc: linux-omap@vger.kernel.org; paul@pwsan.com; b-cousson@ti.com;
> rnayak@ti.com; linux-arm-
>> kernel@lists.infradead.org
>> Subject: Re: [PATCH 1/6] omap4: powerdomain: Add supported INACTIVE
> power state
>>
>> Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
>>
>> > On OMAP4, one can explicitly program INACTIVE as the power state of
>> > the logic area inside the power domain. Techincally PD state
> programmed
>> > to ON and if all the clock domains within the PD are idled, is
> equivalent
>> > tp PD programmed to INACTIVE and all the clock domains within the PD
> are
>> > idled. There won't be any power difference in above two.
>> >
>> > Since the CPUIDLE C-states explicitly make use of INACTIVE as a PD
>> > targeted state
>>
>> I think you're referring to code that is not upstream here. I'm not
>> aware of any C-states targetting INACTIVE.
>
> On OMAP3, C2/3/4 have target state as CORE inactive, while C1 is
> CORE active.
I see what you're saying now.
However, from a code point of view, all of those C-states are programmed
to PWRDM_POWER_ON.
Therefore the changelog is not accurate. Specifically the use of
"explicitly" is wrong, because the use of INACTIVE is most certainly not
explicit.
Kevin
>>
>> Kevin
>>
>> > and also there is some additional latancy involved
>> > with PD INACTIVE vs PD ON, it's better to support it as an explcit
>> > PD state.
>> >
>> > This patch adds the support to allow explicit PD INACTIVE
>> > programming if supported.
>> >
>> > Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
>> > Cc: Paul Walmsley <paul@pwsan.com>
>> > ---
>> > arch/arm/mach-omap2/powerdomain.h | 12 ++++++++++++
>> > arch/arm/mach-omap2/powerdomains44xx_data.c | 26
> +++++++++++++-------------
>> > 2 files changed, 25 insertions(+), 13 deletions(-)
>> >
>> > diff --git a/arch/arm/mach-omap2/powerdomain.h
> b/arch/arm/mach-omap2/powerdomain.h
>> > index c66431e..0e15ca7 100644
>> > --- a/arch/arm/mach-omap2/powerdomain.h
>> > +++ b/arch/arm/mach-omap2/powerdomain.h
>> > @@ -46,6 +46,18 @@
>> >
>> > #define PWRSTS_OFF_RET_ON (PWRSTS_OFF_RET | (1 << PWRDM_POWER_ON))
>> >
>> > +#define PWRSTS_RET_INA_ON ((1 << PWRDM_POWER_RET) | \
>> > + (1 << PWRDM_POWER_INACTIVE) | \
>> > + (1 << PWRDM_POWER_ON))
>> > +
>> > +#define PWRSTS_OFF_INA_ON ((1 << PWRDM_POWER_OFF) | \
>> > + (1 << PWRDM_POWER_INACTIVE) | \
>> > + (1 << PWRDM_POWER_ON))
>> > +
>> > +#define PWRSTS_OFF_RET_INA_ON ((1 << PWRDM_POWER_OFF) | \
>> > + (1 << PWRDM_POWER_RET) | \
>> > + (1 << PWRDM_POWER_INACTIVE) | \
>> > + (1 << PWRDM_POWER_ON))
>> >
>> > /* Powerdomain flags */
>> > #define PWRDM_HAS_HDWR_SAR (1 << 0) /* hardware save-and-restore
> support */
>> > diff --git a/arch/arm/mach-omap2/powerdomains44xx_data.c
> b/arch/arm/mach-omap2/powerdomains44xx_data.c
>> > index 26d7641..96cde98 100644
>> > --- a/arch/arm/mach-omap2/powerdomains44xx_data.c
>> > +++ b/arch/arm/mach-omap2/powerdomains44xx_data.c
>> > @@ -36,7 +36,7 @@ static struct powerdomain core_44xx_pwrdm = {
>> > .prcm_offs = OMAP4430_PRM_CORE_INST,
>> > .prcm_partition = OMAP4430_PRM_PARTITION,
>> > .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
>> > - .pwrsts = PWRSTS_RET_ON,
>> > + .pwrsts = PWRSTS_RET_INA_ON,
>> > .pwrsts_logic_ret = PWRSTS_OFF_RET,
>> > .banks = 5,
>> > .pwrsts_mem_ret = {
>> > @@ -62,7 +62,7 @@ static struct powerdomain gfx_44xx_pwrdm = {
>> > .prcm_offs = OMAP4430_PRM_GFX_INST,
>> > .prcm_partition = OMAP4430_PRM_PARTITION,
>> > .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
>> > - .pwrsts = PWRSTS_OFF_ON,
>> > + .pwrsts = PWRSTS_OFF_INA_ON,
>> > .banks = 1,
>> > .pwrsts_mem_ret = {
>> > [0] = PWRDM_POWER_OFF, /* gfx_mem */
>> > @@ -79,7 +79,7 @@ static struct powerdomain abe_44xx_pwrdm = {
>> > .prcm_offs = OMAP4430_PRM_ABE_INST,
>> > .prcm_partition = OMAP4430_PRM_PARTITION,
>> > .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
>> > - .pwrsts = PWRSTS_OFF_RET_ON,
>> > + .pwrsts = PWRSTS_OFF_RET_INA_ON,
>> > .pwrsts_logic_ret = PWRDM_POWER_OFF,
>> > .banks = 2,
>> > .pwrsts_mem_ret = {
>> > @@ -99,7 +99,7 @@ static struct powerdomain dss_44xx_pwrdm = {
>> > .prcm_offs = OMAP4430_PRM_DSS_INST,
>> > .prcm_partition = OMAP4430_PRM_PARTITION,
>> > .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
>> > - .pwrsts = PWRSTS_OFF_RET_ON,
>> > + .pwrsts = PWRSTS_OFF_RET_INA_ON,
>> > .pwrsts_logic_ret = PWRSTS_OFF,
>> > .banks = 1,
>> > .pwrsts_mem_ret = {
>> > @@ -117,7 +117,7 @@ static struct powerdomain tesla_44xx_pwrdm = {
>> > .prcm_offs = OMAP4430_PRM_TESLA_INST,
>> > .prcm_partition = OMAP4430_PRM_PARTITION,
>> > .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
>> > - .pwrsts = PWRSTS_OFF_RET_ON,
>> > + .pwrsts = PWRSTS_OFF_RET_INA_ON,
>> > .pwrsts_logic_ret = PWRSTS_OFF_RET,
>> > .banks = 3,
>> > .pwrsts_mem_ret = {
>> > @@ -155,7 +155,7 @@ static struct powerdomain cpu0_44xx_pwrdm = {
>> > .prcm_offs = OMAP4430_PRCM_MPU_CPU0_INST,
>> > .prcm_partition = OMAP4430_PRCM_MPU_PARTITION,
>> > .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
>> > - .pwrsts = PWRSTS_OFF_RET_ON,
>> > + .pwrsts = PWRSTS_OFF_RET_INA_ON,
>> > .pwrsts_logic_ret = PWRSTS_OFF_RET,
>> > .banks = 1,
>> > .pwrsts_mem_ret = {
>> > @@ -172,7 +172,7 @@ static struct powerdomain cpu1_44xx_pwrdm = {
>> > .prcm_offs = OMAP4430_PRCM_MPU_CPU1_INST,
>> > .prcm_partition = OMAP4430_PRCM_MPU_PARTITION,
>> > .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
>> > - .pwrsts = PWRSTS_OFF_RET_ON,
>> > + .pwrsts = PWRSTS_OFF_RET_INA_ON,
>> > .pwrsts_logic_ret = PWRSTS_OFF_RET,
>> > .banks = 1,
>> > .pwrsts_mem_ret = {
>> > @@ -205,7 +205,7 @@ static struct powerdomain mpu_44xx_pwrdm = {
>> > .prcm_offs = OMAP4430_PRM_MPU_INST,
>> > .prcm_partition = OMAP4430_PRM_PARTITION,
>> > .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
>> > - .pwrsts = PWRSTS_OFF_RET_ON,
>> > + .pwrsts = PWRSTS_OFF_RET_INA_ON,
>> > .pwrsts_logic_ret = PWRSTS_OFF_RET,
>> > .banks = 3,
>> > .pwrsts_mem_ret = {
>> > @@ -226,7 +226,7 @@ static struct powerdomain ivahd_44xx_pwrdm = {
>> > .prcm_offs = OMAP4430_PRM_IVAHD_INST,
>> > .prcm_partition = OMAP4430_PRM_PARTITION,
>> > .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
>> > - .pwrsts = PWRSTS_OFF_RET_ON,
>> > + .pwrsts = PWRSTS_OFF_RET_INA_ON,
>> > .pwrsts_logic_ret = PWRDM_POWER_OFF,
>> > .banks = 4,
>> > .pwrsts_mem_ret = {
>> > @@ -250,7 +250,7 @@ static struct powerdomain cam_44xx_pwrdm = {
>> > .prcm_offs = OMAP4430_PRM_CAM_INST,
>> > .prcm_partition = OMAP4430_PRM_PARTITION,
>> > .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
>> > - .pwrsts = PWRSTS_OFF_ON,
>> > + .pwrsts = PWRSTS_OFF_INA_ON,
>> > .banks = 1,
>> > .pwrsts_mem_ret = {
>> > [0] = PWRDM_POWER_OFF, /* cam_mem */
>> > @@ -267,7 +267,7 @@ static struct powerdomain l3init_44xx_pwrdm = {
>> > .prcm_offs = OMAP4430_PRM_L3INIT_INST,
>> > .prcm_partition = OMAP4430_PRM_PARTITION,
>> > .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
>> > - .pwrsts = PWRSTS_RET_ON,
>> > + .pwrsts = PWRSTS_OFF_RET_INA_ON,
>> > .pwrsts_logic_ret = PWRSTS_OFF_RET,
>> > .banks = 1,
>> > .pwrsts_mem_ret = {
>> > @@ -285,7 +285,7 @@ static struct powerdomain l4per_44xx_pwrdm = {
>> > .prcm_offs = OMAP4430_PRM_L4PER_INST,
>> > .prcm_partition = OMAP4430_PRM_PARTITION,
>> > .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
>> > - .pwrsts = PWRSTS_RET_ON,
>> > + .pwrsts = PWRSTS_RET_INA_ON,
>> > .pwrsts_logic_ret = PWRSTS_OFF_RET,
>> > .banks = 2,
>> > .pwrsts_mem_ret = {
>> > @@ -317,7 +317,7 @@ static struct powerdomain cefuse_44xx_pwrdm = {
>> > .prcm_offs = OMAP4430_PRM_CEFUSE_INST,
>> > .prcm_partition = OMAP4430_PRM_PARTITION,
>> > .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
>> > - .pwrsts = PWRSTS_OFF_ON,
>> > + .pwrsts = PWRSTS_OFF_INA_ON,
>> > };
>> >
>> > /*
^ permalink raw reply [flat|nested] 48+ messages in thread* [PATCH 1/6] omap4: powerdomain: Add supported INACTIVE power state
@ 2011-02-02 21:28 ` Kevin Hilman
0 siblings, 0 replies; 48+ messages in thread
From: Kevin Hilman @ 2011-02-02 21:28 UTC (permalink / raw)
To: linux-arm-kernel
Rajendra Nayak <rnayak@ti.com> writes:
> Hi Kevin,
>
>> -----Original Message-----
>> From: Kevin Hilman [mailto:khilman at ti.com]
>> Sent: Wednesday, February 02, 2011 6:49 AM
>> To: Santosh Shilimkar
>> Cc: linux-omap at vger.kernel.org; paul at pwsan.com; b-cousson at ti.com;
> rnayak at ti.com; linux-arm-
>> kernel at lists.infradead.org
>> Subject: Re: [PATCH 1/6] omap4: powerdomain: Add supported INACTIVE
> power state
>>
>> Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
>>
>> > On OMAP4, one can explicitly program INACTIVE as the power state of
>> > the logic area inside the power domain. Techincally PD state
> programmed
>> > to ON and if all the clock domains within the PD are idled, is
> equivalent
>> > tp PD programmed to INACTIVE and all the clock domains within the PD
> are
>> > idled. There won't be any power difference in above two.
>> >
>> > Since the CPUIDLE C-states explicitly make use of INACTIVE as a PD
>> > targeted state
>>
>> I think you're referring to code that is not upstream here. I'm not
>> aware of any C-states targetting INACTIVE.
>
> On OMAP3, C2/3/4 have target state as CORE inactive, while C1 is
> CORE active.
I see what you're saying now.
However, from a code point of view, all of those C-states are programmed
to PWRDM_POWER_ON.
Therefore the changelog is not accurate. Specifically the use of
"explicitly" is wrong, because the use of INACTIVE is most certainly not
explicit.
Kevin
>>
>> Kevin
>>
>> > and also there is some additional latancy involved
>> > with PD INACTIVE vs PD ON, it's better to support it as an explcit
>> > PD state.
>> >
>> > This patch adds the support to allow explicit PD INACTIVE
>> > programming if supported.
>> >
>> > Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
>> > Cc: Paul Walmsley <paul@pwsan.com>
>> > ---
>> > arch/arm/mach-omap2/powerdomain.h | 12 ++++++++++++
>> > arch/arm/mach-omap2/powerdomains44xx_data.c | 26
> +++++++++++++-------------
>> > 2 files changed, 25 insertions(+), 13 deletions(-)
>> >
>> > diff --git a/arch/arm/mach-omap2/powerdomain.h
> b/arch/arm/mach-omap2/powerdomain.h
>> > index c66431e..0e15ca7 100644
>> > --- a/arch/arm/mach-omap2/powerdomain.h
>> > +++ b/arch/arm/mach-omap2/powerdomain.h
>> > @@ -46,6 +46,18 @@
>> >
>> > #define PWRSTS_OFF_RET_ON (PWRSTS_OFF_RET | (1 << PWRDM_POWER_ON))
>> >
>> > +#define PWRSTS_RET_INA_ON ((1 << PWRDM_POWER_RET) | \
>> > + (1 << PWRDM_POWER_INACTIVE) | \
>> > + (1 << PWRDM_POWER_ON))
>> > +
>> > +#define PWRSTS_OFF_INA_ON ((1 << PWRDM_POWER_OFF) | \
>> > + (1 << PWRDM_POWER_INACTIVE) | \
>> > + (1 << PWRDM_POWER_ON))
>> > +
>> > +#define PWRSTS_OFF_RET_INA_ON ((1 << PWRDM_POWER_OFF) | \
>> > + (1 << PWRDM_POWER_RET) | \
>> > + (1 << PWRDM_POWER_INACTIVE) | \
>> > + (1 << PWRDM_POWER_ON))
>> >
>> > /* Powerdomain flags */
>> > #define PWRDM_HAS_HDWR_SAR (1 << 0) /* hardware save-and-restore
> support */
>> > diff --git a/arch/arm/mach-omap2/powerdomains44xx_data.c
> b/arch/arm/mach-omap2/powerdomains44xx_data.c
>> > index 26d7641..96cde98 100644
>> > --- a/arch/arm/mach-omap2/powerdomains44xx_data.c
>> > +++ b/arch/arm/mach-omap2/powerdomains44xx_data.c
>> > @@ -36,7 +36,7 @@ static struct powerdomain core_44xx_pwrdm = {
>> > .prcm_offs = OMAP4430_PRM_CORE_INST,
>> > .prcm_partition = OMAP4430_PRM_PARTITION,
>> > .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
>> > - .pwrsts = PWRSTS_RET_ON,
>> > + .pwrsts = PWRSTS_RET_INA_ON,
>> > .pwrsts_logic_ret = PWRSTS_OFF_RET,
>> > .banks = 5,
>> > .pwrsts_mem_ret = {
>> > @@ -62,7 +62,7 @@ static struct powerdomain gfx_44xx_pwrdm = {
>> > .prcm_offs = OMAP4430_PRM_GFX_INST,
>> > .prcm_partition = OMAP4430_PRM_PARTITION,
>> > .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
>> > - .pwrsts = PWRSTS_OFF_ON,
>> > + .pwrsts = PWRSTS_OFF_INA_ON,
>> > .banks = 1,
>> > .pwrsts_mem_ret = {
>> > [0] = PWRDM_POWER_OFF, /* gfx_mem */
>> > @@ -79,7 +79,7 @@ static struct powerdomain abe_44xx_pwrdm = {
>> > .prcm_offs = OMAP4430_PRM_ABE_INST,
>> > .prcm_partition = OMAP4430_PRM_PARTITION,
>> > .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
>> > - .pwrsts = PWRSTS_OFF_RET_ON,
>> > + .pwrsts = PWRSTS_OFF_RET_INA_ON,
>> > .pwrsts_logic_ret = PWRDM_POWER_OFF,
>> > .banks = 2,
>> > .pwrsts_mem_ret = {
>> > @@ -99,7 +99,7 @@ static struct powerdomain dss_44xx_pwrdm = {
>> > .prcm_offs = OMAP4430_PRM_DSS_INST,
>> > .prcm_partition = OMAP4430_PRM_PARTITION,
>> > .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
>> > - .pwrsts = PWRSTS_OFF_RET_ON,
>> > + .pwrsts = PWRSTS_OFF_RET_INA_ON,
>> > .pwrsts_logic_ret = PWRSTS_OFF,
>> > .banks = 1,
>> > .pwrsts_mem_ret = {
>> > @@ -117,7 +117,7 @@ static struct powerdomain tesla_44xx_pwrdm = {
>> > .prcm_offs = OMAP4430_PRM_TESLA_INST,
>> > .prcm_partition = OMAP4430_PRM_PARTITION,
>> > .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
>> > - .pwrsts = PWRSTS_OFF_RET_ON,
>> > + .pwrsts = PWRSTS_OFF_RET_INA_ON,
>> > .pwrsts_logic_ret = PWRSTS_OFF_RET,
>> > .banks = 3,
>> > .pwrsts_mem_ret = {
>> > @@ -155,7 +155,7 @@ static struct powerdomain cpu0_44xx_pwrdm = {
>> > .prcm_offs = OMAP4430_PRCM_MPU_CPU0_INST,
>> > .prcm_partition = OMAP4430_PRCM_MPU_PARTITION,
>> > .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
>> > - .pwrsts = PWRSTS_OFF_RET_ON,
>> > + .pwrsts = PWRSTS_OFF_RET_INA_ON,
>> > .pwrsts_logic_ret = PWRSTS_OFF_RET,
>> > .banks = 1,
>> > .pwrsts_mem_ret = {
>> > @@ -172,7 +172,7 @@ static struct powerdomain cpu1_44xx_pwrdm = {
>> > .prcm_offs = OMAP4430_PRCM_MPU_CPU1_INST,
>> > .prcm_partition = OMAP4430_PRCM_MPU_PARTITION,
>> > .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
>> > - .pwrsts = PWRSTS_OFF_RET_ON,
>> > + .pwrsts = PWRSTS_OFF_RET_INA_ON,
>> > .pwrsts_logic_ret = PWRSTS_OFF_RET,
>> > .banks = 1,
>> > .pwrsts_mem_ret = {
>> > @@ -205,7 +205,7 @@ static struct powerdomain mpu_44xx_pwrdm = {
>> > .prcm_offs = OMAP4430_PRM_MPU_INST,
>> > .prcm_partition = OMAP4430_PRM_PARTITION,
>> > .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
>> > - .pwrsts = PWRSTS_OFF_RET_ON,
>> > + .pwrsts = PWRSTS_OFF_RET_INA_ON,
>> > .pwrsts_logic_ret = PWRSTS_OFF_RET,
>> > .banks = 3,
>> > .pwrsts_mem_ret = {
>> > @@ -226,7 +226,7 @@ static struct powerdomain ivahd_44xx_pwrdm = {
>> > .prcm_offs = OMAP4430_PRM_IVAHD_INST,
>> > .prcm_partition = OMAP4430_PRM_PARTITION,
>> > .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
>> > - .pwrsts = PWRSTS_OFF_RET_ON,
>> > + .pwrsts = PWRSTS_OFF_RET_INA_ON,
>> > .pwrsts_logic_ret = PWRDM_POWER_OFF,
>> > .banks = 4,
>> > .pwrsts_mem_ret = {
>> > @@ -250,7 +250,7 @@ static struct powerdomain cam_44xx_pwrdm = {
>> > .prcm_offs = OMAP4430_PRM_CAM_INST,
>> > .prcm_partition = OMAP4430_PRM_PARTITION,
>> > .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
>> > - .pwrsts = PWRSTS_OFF_ON,
>> > + .pwrsts = PWRSTS_OFF_INA_ON,
>> > .banks = 1,
>> > .pwrsts_mem_ret = {
>> > [0] = PWRDM_POWER_OFF, /* cam_mem */
>> > @@ -267,7 +267,7 @@ static struct powerdomain l3init_44xx_pwrdm = {
>> > .prcm_offs = OMAP4430_PRM_L3INIT_INST,
>> > .prcm_partition = OMAP4430_PRM_PARTITION,
>> > .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
>> > - .pwrsts = PWRSTS_RET_ON,
>> > + .pwrsts = PWRSTS_OFF_RET_INA_ON,
>> > .pwrsts_logic_ret = PWRSTS_OFF_RET,
>> > .banks = 1,
>> > .pwrsts_mem_ret = {
>> > @@ -285,7 +285,7 @@ static struct powerdomain l4per_44xx_pwrdm = {
>> > .prcm_offs = OMAP4430_PRM_L4PER_INST,
>> > .prcm_partition = OMAP4430_PRM_PARTITION,
>> > .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
>> > - .pwrsts = PWRSTS_RET_ON,
>> > + .pwrsts = PWRSTS_RET_INA_ON,
>> > .pwrsts_logic_ret = PWRSTS_OFF_RET,
>> > .banks = 2,
>> > .pwrsts_mem_ret = {
>> > @@ -317,7 +317,7 @@ static struct powerdomain cefuse_44xx_pwrdm = {
>> > .prcm_offs = OMAP4430_PRM_CEFUSE_INST,
>> > .prcm_partition = OMAP4430_PRM_PARTITION,
>> > .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
>> > - .pwrsts = PWRSTS_OFF_ON,
>> > + .pwrsts = PWRSTS_OFF_INA_ON,
>> > };
>> >
>> > /*
^ permalink raw reply [flat|nested] 48+ messages in thread* RE: [PATCH 1/6] omap4: powerdomain: Add supported INACTIVE power state
2011-02-02 21:28 ` Kevin Hilman
@ 2011-02-03 9:00 ` Santosh Shilimkar
-1 siblings, 0 replies; 48+ messages in thread
From: Santosh Shilimkar @ 2011-02-03 9:00 UTC (permalink / raw)
To: Kevin Hilman, Rajendra Nayak
Cc: linux-omap, paul, Benoit Cousson, linux-arm-kernel
> -----Original Message-----
> From: Kevin Hilman [mailto:khilman@ti.com]
> Sent: Thursday, February 03, 2011 2:58 AM
> To: Rajendra Nayak
> Cc: Santosh Shilimkar; linux-omap@vger.kernel.org; paul@pwsan.com;
> Benoit Cousson; linux-arm-kernel@lists.infradead.org
> Subject: Re: [PATCH 1/6] omap4: powerdomain: Add supported INACTIVE
> power state
>
> Rajendra Nayak <rnayak@ti.com> writes:
>
> > Hi Kevin,
> >
> >> -----Original Message-----
> >> From: Kevin Hilman [mailto:khilman@ti.com]
> >> Sent: Wednesday, February 02, 2011 6:49 AM
> >> To: Santosh Shilimkar
> >> Cc: linux-omap@vger.kernel.org; paul@pwsan.com; b-cousson@ti.com;
> > rnayak@ti.com; linux-arm-
> >> kernel@lists.infradead.org
> >> Subject: Re: [PATCH 1/6] omap4: powerdomain: Add supported
> INACTIVE
> > power state
> >>
> >> Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
> >>
> >> > On OMAP4, one can explicitly program INACTIVE as the power
> state of
> >> > the logic area inside the power domain. Techincally PD state
> > programmed
> >> > to ON and if all the clock domains within the PD are idled, is
> > equivalent
> >> > tp PD programmed to INACTIVE and all the clock domains within
> the PD
> > are
> >> > idled. There won't be any power difference in above two.
> >> >
> >> > Since the CPUIDLE C-states explicitly make use of INACTIVE as a
> PD
> >> > targeted state
> >>
> >> I think you're referring to code that is not upstream here. I'm
> not
> >> aware of any C-states targetting INACTIVE.
> >
> > On OMAP3, C2/3/4 have target state as CORE inactive, while C1 is
> > CORE active.
>
> I see what you're saying now.
>
> However, from a code point of view, all of those C-states are
> programmed
> to PWRDM_POWER_ON.
>
> Therefore the changelog is not accurate. Specifically the use of
> "explicitly" is wrong, because the use of INACTIVE is most certainly
> not explicit.
>
Ok. The 'explicit' came from OMAP4 where you could program it. I agree
the code is not there in mainline to show this.
I can drop the explicit from change log if it helps.
Regards,
Santosh
^ permalink raw reply [flat|nested] 48+ messages in thread
* [PATCH 1/6] omap4: powerdomain: Add supported INACTIVE power state
@ 2011-02-03 9:00 ` Santosh Shilimkar
0 siblings, 0 replies; 48+ messages in thread
From: Santosh Shilimkar @ 2011-02-03 9:00 UTC (permalink / raw)
To: linux-arm-kernel
> -----Original Message-----
> From: Kevin Hilman [mailto:khilman at ti.com]
> Sent: Thursday, February 03, 2011 2:58 AM
> To: Rajendra Nayak
> Cc: Santosh Shilimkar; linux-omap at vger.kernel.org; paul at pwsan.com;
> Benoit Cousson; linux-arm-kernel at lists.infradead.org
> Subject: Re: [PATCH 1/6] omap4: powerdomain: Add supported INACTIVE
> power state
>
> Rajendra Nayak <rnayak@ti.com> writes:
>
> > Hi Kevin,
> >
> >> -----Original Message-----
> >> From: Kevin Hilman [mailto:khilman at ti.com]
> >> Sent: Wednesday, February 02, 2011 6:49 AM
> >> To: Santosh Shilimkar
> >> Cc: linux-omap at vger.kernel.org; paul at pwsan.com; b-cousson at ti.com;
> > rnayak at ti.com; linux-arm-
> >> kernel at lists.infradead.org
> >> Subject: Re: [PATCH 1/6] omap4: powerdomain: Add supported
> INACTIVE
> > power state
> >>
> >> Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
> >>
> >> > On OMAP4, one can explicitly program INACTIVE as the power
> state of
> >> > the logic area inside the power domain. Techincally PD state
> > programmed
> >> > to ON and if all the clock domains within the PD are idled, is
> > equivalent
> >> > tp PD programmed to INACTIVE and all the clock domains within
> the PD
> > are
> >> > idled. There won't be any power difference in above two.
> >> >
> >> > Since the CPUIDLE C-states explicitly make use of INACTIVE as a
> PD
> >> > targeted state
> >>
> >> I think you're referring to code that is not upstream here. I'm
> not
> >> aware of any C-states targetting INACTIVE.
> >
> > On OMAP3, C2/3/4 have target state as CORE inactive, while C1 is
> > CORE active.
>
> I see what you're saying now.
>
> However, from a code point of view, all of those C-states are
> programmed
> to PWRDM_POWER_ON.
>
> Therefore the changelog is not accurate. Specifically the use of
> "explicitly" is wrong, because the use of INACTIVE is most certainly
> not explicit.
>
Ok. The 'explicit' came from OMAP4 where you could program it. I agree
the code is not there in mainline to show this.
I can drop the explicit from change log if it helps.
Regards,
Santosh
^ permalink raw reply [flat|nested] 48+ messages in thread
* [PATCH 2/6] omap4: prcm: Fix the CPUx clockdomain offsets
2011-01-28 11:04 ` Santosh Shilimkar
@ 2011-01-28 11:04 ` Santosh Shilimkar
-1 siblings, 0 replies; 48+ messages in thread
From: Santosh Shilimkar @ 2011-01-28 11:04 UTC (permalink / raw)
To: linux-omap
Cc: khilman, paul, b-cousson, rnayak, linux-arm-kernel, Santosh Shilimkar
CPU0 and CPU1 clockdomain is at the offset of 0x18 from the LPRM base.
The header file has set it wrongly to 0x0. Offset 0x0 is for CPUx power
domain control register
Fix the same.
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
---
arch/arm/mach-omap2/prcm_mpu44xx.h | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/prcm_mpu44xx.h b/arch/arm/mach-omap2/prcm_mpu44xx.h
index 729a644..3300ff6 100644
--- a/arch/arm/mach-omap2/prcm_mpu44xx.h
+++ b/arch/arm/mach-omap2/prcm_mpu44xx.h
@@ -38,8 +38,8 @@
#define OMAP4430_PRCM_MPU_CPU1_INST 0x0800
/* PRCM_MPU clockdomain register offsets (from instance start) */
-#define OMAP4430_PRCM_MPU_CPU0_MPU_CDOFFS 0x0000
-#define OMAP4430_PRCM_MPU_CPU1_MPU_CDOFFS 0x0000
+#define OMAP4430_PRCM_MPU_CPU0_MPU_CDOFFS 0x0018
+#define OMAP4430_PRCM_MPU_CPU1_MPU_CDOFFS 0x0018
/*
--
1.6.0.4
^ permalink raw reply related [flat|nested] 48+ messages in thread
* [PATCH 2/6] omap4: prcm: Fix the CPUx clockdomain offsets
@ 2011-01-28 11:04 ` Santosh Shilimkar
0 siblings, 0 replies; 48+ messages in thread
From: Santosh Shilimkar @ 2011-01-28 11:04 UTC (permalink / raw)
To: linux-arm-kernel
CPU0 and CPU1 clockdomain is at the offset of 0x18 from the LPRM base.
The header file has set it wrongly to 0x0. Offset 0x0 is for CPUx power
domain control register
Fix the same.
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
---
arch/arm/mach-omap2/prcm_mpu44xx.h | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/prcm_mpu44xx.h b/arch/arm/mach-omap2/prcm_mpu44xx.h
index 729a644..3300ff6 100644
--- a/arch/arm/mach-omap2/prcm_mpu44xx.h
+++ b/arch/arm/mach-omap2/prcm_mpu44xx.h
@@ -38,8 +38,8 @@
#define OMAP4430_PRCM_MPU_CPU1_INST 0x0800
/* PRCM_MPU clockdomain register offsets (from instance start) */
-#define OMAP4430_PRCM_MPU_CPU0_MPU_CDOFFS 0x0000
-#define OMAP4430_PRCM_MPU_CPU1_MPU_CDOFFS 0x0000
+#define OMAP4430_PRCM_MPU_CPU0_MPU_CDOFFS 0x0018
+#define OMAP4430_PRCM_MPU_CPU1_MPU_CDOFFS 0x0018
/*
--
1.6.0.4
^ permalink raw reply related [flat|nested] 48+ messages in thread
* Re: [PATCH 2/6] omap4: prcm: Fix the CPUx clockdomain offsets
2011-01-28 11:04 ` Santosh Shilimkar
@ 2011-02-02 1:20 ` Kevin Hilman
-1 siblings, 0 replies; 48+ messages in thread
From: Kevin Hilman @ 2011-02-02 1:20 UTC (permalink / raw)
To: Santosh Shilimkar; +Cc: linux-omap, paul, b-cousson, rnayak, linux-arm-kernel
Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
> CPU0 and CPU1 clockdomain is at the offset of 0x18 from the LPRM base.
> The header file has set it wrongly to 0x0. Offset 0x0 is for CPUx power
> domain control register
>
> Fix the same.
Has this also been updated in the autogen scripts?
Benoit?
Kevin
> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
> Cc: Paul Walmsley <paul@pwsan.com>
> ---
> arch/arm/mach-omap2/prcm_mpu44xx.h | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/prcm_mpu44xx.h b/arch/arm/mach-omap2/prcm_mpu44xx.h
> index 729a644..3300ff6 100644
> --- a/arch/arm/mach-omap2/prcm_mpu44xx.h
> +++ b/arch/arm/mach-omap2/prcm_mpu44xx.h
> @@ -38,8 +38,8 @@
> #define OMAP4430_PRCM_MPU_CPU1_INST 0x0800
>
> /* PRCM_MPU clockdomain register offsets (from instance start) */
> -#define OMAP4430_PRCM_MPU_CPU0_MPU_CDOFFS 0x0000
> -#define OMAP4430_PRCM_MPU_CPU1_MPU_CDOFFS 0x0000
> +#define OMAP4430_PRCM_MPU_CPU0_MPU_CDOFFS 0x0018
> +#define OMAP4430_PRCM_MPU_CPU1_MPU_CDOFFS 0x0018
>
>
> /*
^ permalink raw reply [flat|nested] 48+ messages in thread
* [PATCH 2/6] omap4: prcm: Fix the CPUx clockdomain offsets
@ 2011-02-02 1:20 ` Kevin Hilman
0 siblings, 0 replies; 48+ messages in thread
From: Kevin Hilman @ 2011-02-02 1:20 UTC (permalink / raw)
To: linux-arm-kernel
Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
> CPU0 and CPU1 clockdomain is at the offset of 0x18 from the LPRM base.
> The header file has set it wrongly to 0x0. Offset 0x0 is for CPUx power
> domain control register
>
> Fix the same.
Has this also been updated in the autogen scripts?
Benoit?
Kevin
> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
> Cc: Paul Walmsley <paul@pwsan.com>
> ---
> arch/arm/mach-omap2/prcm_mpu44xx.h | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/prcm_mpu44xx.h b/arch/arm/mach-omap2/prcm_mpu44xx.h
> index 729a644..3300ff6 100644
> --- a/arch/arm/mach-omap2/prcm_mpu44xx.h
> +++ b/arch/arm/mach-omap2/prcm_mpu44xx.h
> @@ -38,8 +38,8 @@
> #define OMAP4430_PRCM_MPU_CPU1_INST 0x0800
>
> /* PRCM_MPU clockdomain register offsets (from instance start) */
> -#define OMAP4430_PRCM_MPU_CPU0_MPU_CDOFFS 0x0000
> -#define OMAP4430_PRCM_MPU_CPU1_MPU_CDOFFS 0x0000
> +#define OMAP4430_PRCM_MPU_CPU0_MPU_CDOFFS 0x0018
> +#define OMAP4430_PRCM_MPU_CPU1_MPU_CDOFFS 0x0018
>
>
> /*
^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: [PATCH 2/6] omap4: prcm: Fix the CPUx clockdomain offsets
2011-02-02 1:20 ` Kevin Hilman
@ 2011-02-02 9:24 ` Cousson, Benoit
-1 siblings, 0 replies; 48+ messages in thread
From: Cousson, Benoit @ 2011-02-02 9:24 UTC (permalink / raw)
To: Hilman, Kevin
Cc: Shilimkar, Santosh, linux-omap, paul, Nayak, Rajendra, linux-arm-kernel
On 2/2/2011 2:20 AM, Hilman, Kevin wrote:
> Santosh Shilimkar<santosh.shilimkar@ti.com> writes:
>
>> CPU0 and CPU1 clockdomain is at the offset of 0x18 from the LPRM base.
>> The header file has set it wrongly to 0x0. Offset 0x0 is for CPUx power
>> domain control register
>>
>> Fix the same.
>
> Has this also been updated in the autogen scripts?
>
> Benoit?
No, I didn't see any patch to update that yet.
Santosh or Rajendra,
Did you already fix it?
Benoit
>
> Kevin
>
>> Signed-off-by: Santosh Shilimkar<santosh.shilimkar@ti.com>
>> Cc: Paul Walmsley<paul@pwsan.com>
>> ---
>> arch/arm/mach-omap2/prcm_mpu44xx.h | 4 ++--
>> 1 files changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/arm/mach-omap2/prcm_mpu44xx.h b/arch/arm/mach-omap2/prcm_mpu44xx.h
>> index 729a644..3300ff6 100644
>> --- a/arch/arm/mach-omap2/prcm_mpu44xx.h
>> +++ b/arch/arm/mach-omap2/prcm_mpu44xx.h
>> @@ -38,8 +38,8 @@
>> #define OMAP4430_PRCM_MPU_CPU1_INST 0x0800
>>
>> /* PRCM_MPU clockdomain register offsets (from instance start) */
>> -#define OMAP4430_PRCM_MPU_CPU0_MPU_CDOFFS 0x0000
>> -#define OMAP4430_PRCM_MPU_CPU1_MPU_CDOFFS 0x0000
>> +#define OMAP4430_PRCM_MPU_CPU0_MPU_CDOFFS 0x0018
>> +#define OMAP4430_PRCM_MPU_CPU1_MPU_CDOFFS 0x0018
>>
>>
>> /*
^ permalink raw reply [flat|nested] 48+ messages in thread
* [PATCH 2/6] omap4: prcm: Fix the CPUx clockdomain offsets
@ 2011-02-02 9:24 ` Cousson, Benoit
0 siblings, 0 replies; 48+ messages in thread
From: Cousson, Benoit @ 2011-02-02 9:24 UTC (permalink / raw)
To: linux-arm-kernel
On 2/2/2011 2:20 AM, Hilman, Kevin wrote:
> Santosh Shilimkar<santosh.shilimkar@ti.com> writes:
>
>> CPU0 and CPU1 clockdomain is at the offset of 0x18 from the LPRM base.
>> The header file has set it wrongly to 0x0. Offset 0x0 is for CPUx power
>> domain control register
>>
>> Fix the same.
>
> Has this also been updated in the autogen scripts?
>
> Benoit?
No, I didn't see any patch to update that yet.
Santosh or Rajendra,
Did you already fix it?
Benoit
>
> Kevin
>
>> Signed-off-by: Santosh Shilimkar<santosh.shilimkar@ti.com>
>> Cc: Paul Walmsley<paul@pwsan.com>
>> ---
>> arch/arm/mach-omap2/prcm_mpu44xx.h | 4 ++--
>> 1 files changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/arm/mach-omap2/prcm_mpu44xx.h b/arch/arm/mach-omap2/prcm_mpu44xx.h
>> index 729a644..3300ff6 100644
>> --- a/arch/arm/mach-omap2/prcm_mpu44xx.h
>> +++ b/arch/arm/mach-omap2/prcm_mpu44xx.h
>> @@ -38,8 +38,8 @@
>> #define OMAP4430_PRCM_MPU_CPU1_INST 0x0800
>>
>> /* PRCM_MPU clockdomain register offsets (from instance start) */
>> -#define OMAP4430_PRCM_MPU_CPU0_MPU_CDOFFS 0x0000
>> -#define OMAP4430_PRCM_MPU_CPU1_MPU_CDOFFS 0x0000
>> +#define OMAP4430_PRCM_MPU_CPU0_MPU_CDOFFS 0x0018
>> +#define OMAP4430_PRCM_MPU_CPU1_MPU_CDOFFS 0x0018
>>
>>
>> /*
^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: [PATCH 2/6] omap4: prcm: Fix the CPUx clockdomain offsets
2011-02-02 9:24 ` Cousson, Benoit
@ 2011-02-03 12:51 ` Cousson, Benoit
-1 siblings, 0 replies; 48+ messages in thread
From: Cousson, Benoit @ 2011-02-03 12:51 UTC (permalink / raw)
To: Hilman, Kevin
Cc: Shilimkar, Santosh, linux-omap, paul, Nayak, Rajendra, linux-arm-kernel
Hi Kevin,
On 2/2/2011 10:24 AM, Cousson, Benoit wrote:
> On 2/2/2011 2:20 AM, Hilman, Kevin wrote:
>> Santosh Shilimkar<santosh.shilimkar@ti.com> writes:
>>
>>> CPU0 and CPU1 clockdomain is at the offset of 0x18 from the LPRM base.
>>> The header file has set it wrongly to 0x0. Offset 0x0 is for CPUx power
>>> domain control register
>>>
>>> Fix the same.
>>
>> Has this also been updated in the autogen scripts?
>>
>> Benoit?
>
> No, I didn't see any patch to update that yet.
>
> Santosh or Rajendra,
> Did you already fix it?
I updated the scripts with Santosh fixes and found a register name issue in this file.
The fix is inlined at the end.
Santosh will include it in a new revision of the series.
Regards,
Benoit
---
>From ea148474504429fe5ae94406ea5e39c2847c5e31 Mon Sep 17 00:00:00 2001
From: Benoit Cousson <b-cousson@ti.com>
Date: Thu, 3 Feb 2011 12:04:03 +0100
Subject: [PATCH] OMAP4: clockdomain: Fix the CPUx domain name
The register naming convention for module control inside clock domain is: OMAPXXXX_<partition>_<clock_domain>_<module>_CDOFFS
Both CPU0 and CPU1 use MPU as module name instead of CPU0 and CPU1.
Change the name to stick to the convention.
Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Rajendra Nayak <rnayak@ti.com>
---
arch/arm/mach-omap2/clockdomains44xx_data.c | 4 ++--
arch/arm/mach-omap2/prcm_mpu44xx.h | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/clockdomains44xx_data.c b/arch/arm/mach-omap2/clockdomains44xx_data.c
index 51920fc..db1f442 100644
--- a/arch/arm/mach-omap2/clockdomains44xx_data.c
+++ b/arch/arm/mach-omap2/clockdomains44xx_data.c
@@ -152,7 +152,7 @@ static struct clockdomain mpu0_44xx_clkdm = {
.pwrdm = { .name = "cpu0_pwrdm" },
.prcm_partition = OMAP4430_PRCM_MPU_PARTITION,
.cm_inst = OMAP4430_PRCM_MPU_CPU0_INST,
- .clkdm_offs = OMAP4430_PRCM_MPU_CPU0_MPU_CDOFFS,
+ .clkdm_offs = OMAP4430_PRCM_MPU_CPU0_CPU0_CDOFFS,
.flags = CLKDM_CAN_FORCE_WAKEUP | CLKDM_CAN_HWSUP,
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
};
@@ -162,7 +162,7 @@ static struct clockdomain mpu1_44xx_clkdm = {
.pwrdm = { .name = "cpu1_pwrdm" },
.prcm_partition = OMAP4430_PRCM_MPU_PARTITION,
.cm_inst = OMAP4430_PRCM_MPU_CPU1_INST,
- .clkdm_offs = OMAP4430_PRCM_MPU_CPU1_MPU_CDOFFS,
+ .clkdm_offs = OMAP4430_PRCM_MPU_CPU1_CPU1_CDOFFS,
.flags = CLKDM_CAN_FORCE_WAKEUP | CLKDM_CAN_HWSUP,
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
};
diff --git a/arch/arm/mach-omap2/prcm_mpu44xx.h b/arch/arm/mach-omap2/prcm_mpu44xx.h
index 3300ff6..d22d1b4 100644
--- a/arch/arm/mach-omap2/prcm_mpu44xx.h
+++ b/arch/arm/mach-omap2/prcm_mpu44xx.h
@@ -38,8 +38,8 @@
#define OMAP4430_PRCM_MPU_CPU1_INST 0x0800
/* PRCM_MPU clockdomain register offsets (from instance start) */
-#define OMAP4430_PRCM_MPU_CPU0_MPU_CDOFFS 0x0018
-#define OMAP4430_PRCM_MPU_CPU1_MPU_CDOFFS 0x0018
+#define OMAP4430_PRCM_MPU_CPU0_CPU0_CDOFFS 0x0018
+#define OMAP4430_PRCM_MPU_CPU1_CPU1_CDOFFS 0x0018
/*
--
1.7.0.4
^ permalink raw reply related [flat|nested] 48+ messages in thread* [PATCH 2/6] omap4: prcm: Fix the CPUx clockdomain offsets
@ 2011-02-03 12:51 ` Cousson, Benoit
0 siblings, 0 replies; 48+ messages in thread
From: Cousson, Benoit @ 2011-02-03 12:51 UTC (permalink / raw)
To: linux-arm-kernel
Hi Kevin,
On 2/2/2011 10:24 AM, Cousson, Benoit wrote:
> On 2/2/2011 2:20 AM, Hilman, Kevin wrote:
>> Santosh Shilimkar<santosh.shilimkar@ti.com> writes:
>>
>>> CPU0 and CPU1 clockdomain is at the offset of 0x18 from the LPRM base.
>>> The header file has set it wrongly to 0x0. Offset 0x0 is for CPUx power
>>> domain control register
>>>
>>> Fix the same.
>>
>> Has this also been updated in the autogen scripts?
>>
>> Benoit?
>
> No, I didn't see any patch to update that yet.
>
> Santosh or Rajendra,
> Did you already fix it?
I updated the scripts with Santosh fixes and found a register name issue in this file.
The fix is inlined at the end.
Santosh will include it in a new revision of the series.
Regards,
Benoit
---
^ permalink raw reply [flat|nested] 48+ messages in thread
* [PATCH 3/6] omap4: powerdomain: Use intended PWRSTS_* flags instead of values
2011-01-28 11:04 ` Santosh Shilimkar
@ 2011-01-28 11:04 ` Santosh Shilimkar
-1 siblings, 0 replies; 48+ messages in thread
From: Santosh Shilimkar @ 2011-01-28 11:04 UTC (permalink / raw)
To: linux-omap
Cc: khilman, paul, b-cousson, rnayak, linux-arm-kernel, Santosh Shilimkar
IVAHD and ABE power domain logic state is populated using directly
value instead of the capability flags.
Fix the same.
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
---
arch/arm/mach-omap2/powerdomains44xx_data.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/powerdomains44xx_data.c b/arch/arm/mach-omap2/powerdomains44xx_data.c
index 96cde98..daee255 100644
--- a/arch/arm/mach-omap2/powerdomains44xx_data.c
+++ b/arch/arm/mach-omap2/powerdomains44xx_data.c
@@ -80,7 +80,7 @@ static struct powerdomain abe_44xx_pwrdm = {
.prcm_partition = OMAP4430_PRM_PARTITION,
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
.pwrsts = PWRSTS_OFF_RET_INA_ON,
- .pwrsts_logic_ret = PWRDM_POWER_OFF,
+ .pwrsts_logic_ret = PWRSTS_OFF,
.banks = 2,
.pwrsts_mem_ret = {
[0] = PWRDM_POWER_RET, /* aessmem */
@@ -227,7 +227,7 @@ static struct powerdomain ivahd_44xx_pwrdm = {
.prcm_partition = OMAP4430_PRM_PARTITION,
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
.pwrsts = PWRSTS_OFF_RET_INA_ON,
- .pwrsts_logic_ret = PWRDM_POWER_OFF,
+ .pwrsts_logic_ret = PWRSTS_OFF,
.banks = 4,
.pwrsts_mem_ret = {
[0] = PWRDM_POWER_OFF, /* hwa_mem */
--
1.6.0.4
^ permalink raw reply related [flat|nested] 48+ messages in thread* [PATCH 3/6] omap4: powerdomain: Use intended PWRSTS_* flags instead of values
@ 2011-01-28 11:04 ` Santosh Shilimkar
0 siblings, 0 replies; 48+ messages in thread
From: Santosh Shilimkar @ 2011-01-28 11:04 UTC (permalink / raw)
To: linux-arm-kernel
IVAHD and ABE power domain logic state is populated using directly
value instead of the capability flags.
Fix the same.
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
---
arch/arm/mach-omap2/powerdomains44xx_data.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/powerdomains44xx_data.c b/arch/arm/mach-omap2/powerdomains44xx_data.c
index 96cde98..daee255 100644
--- a/arch/arm/mach-omap2/powerdomains44xx_data.c
+++ b/arch/arm/mach-omap2/powerdomains44xx_data.c
@@ -80,7 +80,7 @@ static struct powerdomain abe_44xx_pwrdm = {
.prcm_partition = OMAP4430_PRM_PARTITION,
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
.pwrsts = PWRSTS_OFF_RET_INA_ON,
- .pwrsts_logic_ret = PWRDM_POWER_OFF,
+ .pwrsts_logic_ret = PWRSTS_OFF,
.banks = 2,
.pwrsts_mem_ret = {
[0] = PWRDM_POWER_RET, /* aessmem */
@@ -227,7 +227,7 @@ static struct powerdomain ivahd_44xx_pwrdm = {
.prcm_partition = OMAP4430_PRM_PARTITION,
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
.pwrsts = PWRSTS_OFF_RET_INA_ON,
- .pwrsts_logic_ret = PWRDM_POWER_OFF,
+ .pwrsts_logic_ret = PWRSTS_OFF,
.banks = 4,
.pwrsts_mem_ret = {
[0] = PWRDM_POWER_OFF, /* hwa_mem */
--
1.6.0.4
^ permalink raw reply related [flat|nested] 48+ messages in thread* Re: [PATCH 3/6] omap4: powerdomain: Use intended PWRSTS_* flags instead of values
2011-01-28 11:04 ` Santosh Shilimkar
@ 2011-02-02 1:21 ` Kevin Hilman
-1 siblings, 0 replies; 48+ messages in thread
From: Kevin Hilman @ 2011-02-02 1:21 UTC (permalink / raw)
To: Santosh Shilimkar; +Cc: linux-omap, paul, b-cousson, rnayak, linux-arm-kernel
Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
> IVAHD and ABE power domain logic state is populated using directly
> value instead of the capability flags.
>
> Fix the same.
Again, has this been fixed in the scripts?
For future reference, It will be helpful to note in the changelog that
this kind of thing has been fixed in the autogen scripts.
Thanks,
Kevin
> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
> ---
> arch/arm/mach-omap2/powerdomains44xx_data.c | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/powerdomains44xx_data.c b/arch/arm/mach-omap2/powerdomains44xx_data.c
> index 96cde98..daee255 100644
> --- a/arch/arm/mach-omap2/powerdomains44xx_data.c
> +++ b/arch/arm/mach-omap2/powerdomains44xx_data.c
> @@ -80,7 +80,7 @@ static struct powerdomain abe_44xx_pwrdm = {
> .prcm_partition = OMAP4430_PRM_PARTITION,
> .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
> .pwrsts = PWRSTS_OFF_RET_INA_ON,
> - .pwrsts_logic_ret = PWRDM_POWER_OFF,
> + .pwrsts_logic_ret = PWRSTS_OFF,
> .banks = 2,
> .pwrsts_mem_ret = {
> [0] = PWRDM_POWER_RET, /* aessmem */
> @@ -227,7 +227,7 @@ static struct powerdomain ivahd_44xx_pwrdm = {
> .prcm_partition = OMAP4430_PRM_PARTITION,
> .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
> .pwrsts = PWRSTS_OFF_RET_INA_ON,
> - .pwrsts_logic_ret = PWRDM_POWER_OFF,
> + .pwrsts_logic_ret = PWRSTS_OFF,
> .banks = 4,
> .pwrsts_mem_ret = {
> [0] = PWRDM_POWER_OFF, /* hwa_mem */
^ permalink raw reply [flat|nested] 48+ messages in thread* [PATCH 3/6] omap4: powerdomain: Use intended PWRSTS_* flags instead of values
@ 2011-02-02 1:21 ` Kevin Hilman
0 siblings, 0 replies; 48+ messages in thread
From: Kevin Hilman @ 2011-02-02 1:21 UTC (permalink / raw)
To: linux-arm-kernel
Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
> IVAHD and ABE power domain logic state is populated using directly
> value instead of the capability flags.
>
> Fix the same.
Again, has this been fixed in the scripts?
For future reference, It will be helpful to note in the changelog that
this kind of thing has been fixed in the autogen scripts.
Thanks,
Kevin
> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
> ---
> arch/arm/mach-omap2/powerdomains44xx_data.c | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/powerdomains44xx_data.c b/arch/arm/mach-omap2/powerdomains44xx_data.c
> index 96cde98..daee255 100644
> --- a/arch/arm/mach-omap2/powerdomains44xx_data.c
> +++ b/arch/arm/mach-omap2/powerdomains44xx_data.c
> @@ -80,7 +80,7 @@ static struct powerdomain abe_44xx_pwrdm = {
> .prcm_partition = OMAP4430_PRM_PARTITION,
> .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
> .pwrsts = PWRSTS_OFF_RET_INA_ON,
> - .pwrsts_logic_ret = PWRDM_POWER_OFF,
> + .pwrsts_logic_ret = PWRSTS_OFF,
> .banks = 2,
> .pwrsts_mem_ret = {
> [0] = PWRDM_POWER_RET, /* aessmem */
> @@ -227,7 +227,7 @@ static struct powerdomain ivahd_44xx_pwrdm = {
> .prcm_partition = OMAP4430_PRM_PARTITION,
> .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
> .pwrsts = PWRSTS_OFF_RET_INA_ON,
> - .pwrsts_logic_ret = PWRDM_POWER_OFF,
> + .pwrsts_logic_ret = PWRSTS_OFF,
> .banks = 4,
> .pwrsts_mem_ret = {
> [0] = PWRDM_POWER_OFF, /* hwa_mem */
^ permalink raw reply [flat|nested] 48+ messages in thread* RE: [PATCH 3/6] omap4: powerdomain: Use intended PWRSTS_* flags instead of values
2011-02-02 1:21 ` Kevin Hilman
@ 2011-02-02 6:15 ` Santosh Shilimkar
-1 siblings, 0 replies; 48+ messages in thread
From: Santosh Shilimkar @ 2011-02-02 6:15 UTC (permalink / raw)
To: Kevin Hilman
Cc: linux-omap, paul, Benoit Cousson, Rajendra Nayak, linux-arm-kernel
> -----Original Message-----
> From: Kevin Hilman [mailto:khilman@ti.com]
> Sent: Wednesday, February 02, 2011 6:52 AM
> To: Santosh Shilimkar
> Cc: linux-omap@vger.kernel.org; paul@pwsan.com; b-cousson@ti.com;
> rnayak@ti.com; linux-arm-kernel@lists.infradead.org
> Subject: Re: [PATCH 3/6] omap4: powerdomain: Use intended PWRSTS_*
> flags instead of values
>
> Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
>
> > IVAHD and ABE power domain logic state is populated using directly
> > value instead of the capability flags.
> >
> > Fix the same.
>
> Again, has this been fixed in the scripts?
>
> For future reference, It will be helpful to note in the changelog
> that
> this kind of thing has been fixed in the autogen scripts.
>
The power domain scripts was out of sync with code.
And hence its not mentioned.
Benoit has merged the changes from Paul and we will
update this additional change on top of it
Regards,
Santosh
^ permalink raw reply [flat|nested] 48+ messages in thread
* [PATCH 3/6] omap4: powerdomain: Use intended PWRSTS_* flags instead of values
@ 2011-02-02 6:15 ` Santosh Shilimkar
0 siblings, 0 replies; 48+ messages in thread
From: Santosh Shilimkar @ 2011-02-02 6:15 UTC (permalink / raw)
To: linux-arm-kernel
> -----Original Message-----
> From: Kevin Hilman [mailto:khilman at ti.com]
> Sent: Wednesday, February 02, 2011 6:52 AM
> To: Santosh Shilimkar
> Cc: linux-omap at vger.kernel.org; paul at pwsan.com; b-cousson at ti.com;
> rnayak at ti.com; linux-arm-kernel at lists.infradead.org
> Subject: Re: [PATCH 3/6] omap4: powerdomain: Use intended PWRSTS_*
> flags instead of values
>
> Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
>
> > IVAHD and ABE power domain logic state is populated using directly
> > value instead of the capability flags.
> >
> > Fix the same.
>
> Again, has this been fixed in the scripts?
>
> For future reference, It will be helpful to note in the changelog
> that
> this kind of thing has been fixed in the autogen scripts.
>
The power domain scripts was out of sync with code.
And hence its not mentioned.
Benoit has merged the changes from Paul and we will
update this additional change on top of it
Regards,
Santosh
^ permalink raw reply [flat|nested] 48+ messages in thread
* [PATCH 4/6] omap4: dpll: Enable all DPLL autoidle at boot
2011-01-28 11:04 ` Santosh Shilimkar
@ 2011-01-28 11:04 ` Santosh Shilimkar
-1 siblings, 0 replies; 48+ messages in thread
From: Santosh Shilimkar @ 2011-01-28 11:04 UTC (permalink / raw)
To: linux-omap; +Cc: khilman, paul, b-cousson, rnayak, linux-arm-kernel
From: Rajendra Nayak <rnayak@ti.com>
Enable all DPLL autoidle at boot on OMAP4.
Signed-off-by: Rajendra Nayak <rnayak@ti.com>
---
arch/arm/mach-omap2/clock44xx_data.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/clock44xx_data.c b/arch/arm/mach-omap2/clock44xx_data.c
index e8cb32f..e5c59a0 100644
--- a/arch/arm/mach-omap2/clock44xx_data.c
+++ b/arch/arm/mach-omap2/clock44xx_data.c
@@ -3300,6 +3300,8 @@ int __init omap4xxx_clk_init(void)
clkdev_add(&c->lk);
clk_register(c->lk.clk);
omap2_init_clk_clkdm(c->lk.clk);
+ if (c->lk.clk->dpll_data)
+ omap3_dpll_allow_idle(c->lk.clk);
}
recalculate_root_clocks();
--
1.6.0.4
^ permalink raw reply related [flat|nested] 48+ messages in thread
* [PATCH 4/6] omap4: dpll: Enable all DPLL autoidle at boot
@ 2011-01-28 11:04 ` Santosh Shilimkar
0 siblings, 0 replies; 48+ messages in thread
From: Santosh Shilimkar @ 2011-01-28 11:04 UTC (permalink / raw)
To: linux-arm-kernel
From: Rajendra Nayak <rnayak@ti.com>
Enable all DPLL autoidle at boot on OMAP4.
Signed-off-by: Rajendra Nayak <rnayak@ti.com>
---
arch/arm/mach-omap2/clock44xx_data.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/clock44xx_data.c b/arch/arm/mach-omap2/clock44xx_data.c
index e8cb32f..e5c59a0 100644
--- a/arch/arm/mach-omap2/clock44xx_data.c
+++ b/arch/arm/mach-omap2/clock44xx_data.c
@@ -3300,6 +3300,8 @@ int __init omap4xxx_clk_init(void)
clkdev_add(&c->lk);
clk_register(c->lk.clk);
omap2_init_clk_clkdm(c->lk.clk);
+ if (c->lk.clk->dpll_data)
+ omap3_dpll_allow_idle(c->lk.clk);
}
recalculate_root_clocks();
--
1.6.0.4
^ permalink raw reply related [flat|nested] 48+ messages in thread
* Re: [PATCH 4/6] omap4: dpll: Enable all DPLL autoidle at boot
2011-01-28 11:04 ` Santosh Shilimkar
@ 2011-01-31 23:17 ` Paul Walmsley
-1 siblings, 0 replies; 48+ messages in thread
From: Paul Walmsley @ 2011-01-31 23:17 UTC (permalink / raw)
To: rnayak, Santosh Shilimkar
Cc: linux-omap, khilman, b-cousson, linux-arm-kernel
Hi guys
On Fri, 28 Jan 2011, Santosh Shilimkar wrote:
> From: Rajendra Nayak <rnayak@ti.com>
>
> Enable all DPLL autoidle at boot on OMAP4.
Is there some reason why we can't do this in the OMAP4 PM code? At some
point, I think it would be good to essentially disable all PM at boot, and
then let the PM code specifically enable autoidle later in the boot
process, etc. The idea being that !CONFIG_PM would result in a chip
programmed for lowest latency, etc.
> Signed-off-by: Rajendra Nayak <rnayak@ti.com>
> ---
> arch/arm/mach-omap2/clock44xx_data.c | 2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/clock44xx_data.c b/arch/arm/mach-omap2/clock44xx_data.c
> index e8cb32f..e5c59a0 100644
> --- a/arch/arm/mach-omap2/clock44xx_data.c
> +++ b/arch/arm/mach-omap2/clock44xx_data.c
> @@ -3300,6 +3300,8 @@ int __init omap4xxx_clk_init(void)
> clkdev_add(&c->lk);
> clk_register(c->lk.clk);
> omap2_init_clk_clkdm(c->lk.clk);
> + if (c->lk.clk->dpll_data)
> + omap3_dpll_allow_idle(c->lk.clk);
> }
>
> recalculate_root_clocks();
> --
> 1.6.0.4
>
- Paul
^ permalink raw reply [flat|nested] 48+ messages in thread
* [PATCH 4/6] omap4: dpll: Enable all DPLL autoidle at boot
@ 2011-01-31 23:17 ` Paul Walmsley
0 siblings, 0 replies; 48+ messages in thread
From: Paul Walmsley @ 2011-01-31 23:17 UTC (permalink / raw)
To: linux-arm-kernel
Hi guys
On Fri, 28 Jan 2011, Santosh Shilimkar wrote:
> From: Rajendra Nayak <rnayak@ti.com>
>
> Enable all DPLL autoidle at boot on OMAP4.
Is there some reason why we can't do this in the OMAP4 PM code? At some
point, I think it would be good to essentially disable all PM at boot, and
then let the PM code specifically enable autoidle later in the boot
process, etc. The idea being that !CONFIG_PM would result in a chip
programmed for lowest latency, etc.
> Signed-off-by: Rajendra Nayak <rnayak@ti.com>
> ---
> arch/arm/mach-omap2/clock44xx_data.c | 2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/clock44xx_data.c b/arch/arm/mach-omap2/clock44xx_data.c
> index e8cb32f..e5c59a0 100644
> --- a/arch/arm/mach-omap2/clock44xx_data.c
> +++ b/arch/arm/mach-omap2/clock44xx_data.c
> @@ -3300,6 +3300,8 @@ int __init omap4xxx_clk_init(void)
> clkdev_add(&c->lk);
> clk_register(c->lk.clk);
> omap2_init_clk_clkdm(c->lk.clk);
> + if (c->lk.clk->dpll_data)
> + omap3_dpll_allow_idle(c->lk.clk);
> }
>
> recalculate_root_clocks();
> --
> 1.6.0.4
>
- Paul
^ permalink raw reply [flat|nested] 48+ messages in thread
* RE: [PATCH 4/6] omap4: dpll: Enable all DPLL autoidle at boot
2011-01-31 23:17 ` Paul Walmsley
@ 2011-02-01 5:24 ` Rajendra Nayak
-1 siblings, 0 replies; 48+ messages in thread
From: Rajendra Nayak @ 2011-02-01 5:24 UTC (permalink / raw)
To: Paul Walmsley, Santosh Shilimkar
Cc: linux-omap, Kevin Hilman, Benoit Cousson, linux-arm-kernel
Hi Paul,
> -----Original Message-----
> From: Paul Walmsley [mailto:paul@pwsan.com]
> Sent: Tuesday, February 01, 2011 4:47 AM
> To: rnayak@ti.com; Santosh Shilimkar
> Cc: linux-omap@vger.kernel.org; khilman@ti.com; b-cousson@ti.com;
linux-arm-kernel@lists.infradead.org
> Subject: Re: [PATCH 4/6] omap4: dpll: Enable all DPLL autoidle at boot
>
> Hi guys
>
> On Fri, 28 Jan 2011, Santosh Shilimkar wrote:
>
> > From: Rajendra Nayak <rnayak@ti.com>
> >
> > Enable all DPLL autoidle at boot on OMAP4.
>
> Is there some reason why we can't do this in the OMAP4 PM code? At some
> point, I think it would be good to essentially disable all PM at boot,
and
> then let the PM code specifically enable autoidle later in the boot
> process, etc. The idea being that !CONFIG_PM would result in a chip
> programmed for lowest latency, etc.
I guess it makes sense to do this late in boot and only if CONFIG_PM
is enabled. Will make the necessary changes and repost.
Regards,
Rajendra
>
> > Signed-off-by: Rajendra Nayak <rnayak@ti.com>
> > ---
> > arch/arm/mach-omap2/clock44xx_data.c | 2 ++
> > 1 files changed, 2 insertions(+), 0 deletions(-)
> >
> > diff --git a/arch/arm/mach-omap2/clock44xx_data.c
b/arch/arm/mach-omap2/clock44xx_data.c
> > index e8cb32f..e5c59a0 100644
> > --- a/arch/arm/mach-omap2/clock44xx_data.c
> > +++ b/arch/arm/mach-omap2/clock44xx_data.c
> > @@ -3300,6 +3300,8 @@ int __init omap4xxx_clk_init(void)
> > clkdev_add(&c->lk);
> > clk_register(c->lk.clk);
> > omap2_init_clk_clkdm(c->lk.clk);
> > + if (c->lk.clk->dpll_data)
> > + omap3_dpll_allow_idle(c->lk.clk);
> > }
> >
> > recalculate_root_clocks();
> > --
> > 1.6.0.4
> >
>
>
> - Paul
^ permalink raw reply [flat|nested] 48+ messages in thread
* [PATCH 4/6] omap4: dpll: Enable all DPLL autoidle at boot
@ 2011-02-01 5:24 ` Rajendra Nayak
0 siblings, 0 replies; 48+ messages in thread
From: Rajendra Nayak @ 2011-02-01 5:24 UTC (permalink / raw)
To: linux-arm-kernel
Hi Paul,
> -----Original Message-----
> From: Paul Walmsley [mailto:paul at pwsan.com]
> Sent: Tuesday, February 01, 2011 4:47 AM
> To: rnayak at ti.com; Santosh Shilimkar
> Cc: linux-omap at vger.kernel.org; khilman at ti.com; b-cousson at ti.com;
linux-arm-kernel at lists.infradead.org
> Subject: Re: [PATCH 4/6] omap4: dpll: Enable all DPLL autoidle at boot
>
> Hi guys
>
> On Fri, 28 Jan 2011, Santosh Shilimkar wrote:
>
> > From: Rajendra Nayak <rnayak@ti.com>
> >
> > Enable all DPLL autoidle at boot on OMAP4.
>
> Is there some reason why we can't do this in the OMAP4 PM code? At some
> point, I think it would be good to essentially disable all PM at boot,
and
> then let the PM code specifically enable autoidle later in the boot
> process, etc. The idea being that !CONFIG_PM would result in a chip
> programmed for lowest latency, etc.
I guess it makes sense to do this late in boot and only if CONFIG_PM
is enabled. Will make the necessary changes and repost.
Regards,
Rajendra
>
> > Signed-off-by: Rajendra Nayak <rnayak@ti.com>
> > ---
> > arch/arm/mach-omap2/clock44xx_data.c | 2 ++
> > 1 files changed, 2 insertions(+), 0 deletions(-)
> >
> > diff --git a/arch/arm/mach-omap2/clock44xx_data.c
b/arch/arm/mach-omap2/clock44xx_data.c
> > index e8cb32f..e5c59a0 100644
> > --- a/arch/arm/mach-omap2/clock44xx_data.c
> > +++ b/arch/arm/mach-omap2/clock44xx_data.c
> > @@ -3300,6 +3300,8 @@ int __init omap4xxx_clk_init(void)
> > clkdev_add(&c->lk);
> > clk_register(c->lk.clk);
> > omap2_init_clk_clkdm(c->lk.clk);
> > + if (c->lk.clk->dpll_data)
> > + omap3_dpll_allow_idle(c->lk.clk);
> > }
> >
> > recalculate_root_clocks();
> > --
> > 1.6.0.4
> >
>
>
> - Paul
^ permalink raw reply [flat|nested] 48+ messages in thread
* [PATCH 5/6] omap4: dpll: Add dpll api to control GATE_CTRL
2011-01-28 11:04 ` Santosh Shilimkar
@ 2011-01-28 11:04 ` Santosh Shilimkar
-1 siblings, 0 replies; 48+ messages in thread
From: Santosh Shilimkar @ 2011-01-28 11:04 UTC (permalink / raw)
To: linux-omap; +Cc: khilman, paul, b-cousson, rnayak, linux-arm-kernel
From: Rajendra Nayak <rnayak@ti.com>
On OMAP4, the dpll post divider outputs (MX outputs)
provide a way to allow/deny autoidle.
Allowing autoidle would mean that the hw would autogate
this clock when there is no dependency for it.
Denying idle would mean that this clock output will be
forced to stay enabled.
Add dpll api's to read/allow/deny idle control.
Signed-off-by: Rajendra Nayak <rnayak@ti.com>
---
arch/arm/mach-omap2/clock.h | 3 ++
arch/arm/mach-omap2/dpll3xxx.c | 43 +++++++++++++++++++++++++++++++
arch/arm/plat-omap/include/plat/clock.h | 1 +
3 files changed, 47 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/clock.h b/arch/arm/mach-omap2/clock.h
index 896584e..19617f0 100644
--- a/arch/arm/mach-omap2/clock.h
+++ b/arch/arm/mach-omap2/clock.h
@@ -65,6 +65,9 @@ u32 omap3_dpll_autoidle_read(struct clk *clk);
int omap3_noncore_dpll_set_rate(struct clk *clk, unsigned long rate);
int omap3_noncore_dpll_enable(struct clk *clk);
void omap3_noncore_dpll_disable(struct clk *clk);
+int omap4_dpllmx_gatectrl_read(struct clk *clk);
+void omap4_dpllmx_allow_gatectrl(struct clk *clk);
+void omap4_dpllmx_deny_gatectrl(struct clk *clk);
#ifdef CONFIG_OMAP_RESET_CLOCKS
void omap2_clk_disable_unused(struct clk *clk);
diff --git a/arch/arm/mach-omap2/dpll3xxx.c b/arch/arm/mach-omap2/dpll3xxx.c
index f77022b..4ce06d5 100644
--- a/arch/arm/mach-omap2/dpll3xxx.c
+++ b/arch/arm/mach-omap2/dpll3xxx.c
@@ -34,11 +34,14 @@
#include "clock.h"
#include "cm2xxx_3xxx.h"
#include "cm-regbits-34xx.h"
+#include "cm-regbits-44xx.h"
/* CM_AUTOIDLE_PLL*.AUTO_* bit values */
#define DPLL_AUTOIDLE_DISABLE 0x0
#define DPLL_AUTOIDLE_LOW_POWER_STOP 0x1
+#define DPLL_GATECTRL_DISABLE 0x0
+
#define MAX_DPLL_WAIT_TRIES 1000000
/* Private functions */
@@ -612,3 +615,43 @@ unsigned long omap3_clkoutx2_recalc(struct clk *clk)
rate = clk->parent->rate * 2;
return rate;
}
+
+int omap4_dpllmx_gatectrl_read(struct clk *clk)
+{
+ u32 v;
+
+ if (!clk || !(clk->flags & CLOCK_MX_IDLE_CONTROL) || !clk->clksel_reg)
+ return -EINVAL;
+
+ v = __raw_readl(clk->clksel_reg);
+ v &= OMAP4430_DPLL_CLKOUT_GATE_CTRL_MASK;
+ v >>= __ffs(OMAP4430_DPLL_CLKOUT_GATE_CTRL_MASK);
+
+ return v;
+}
+
+void omap4_dpllmx_allow_gatectrl(struct clk *clk)
+{
+ u32 v;
+
+ if (!clk || !(clk->flags & CLOCK_MX_IDLE_CONTROL) || !clk->clksel_reg)
+ return;
+
+ v = __raw_readl(clk->clksel_reg);
+ v &= ~OMAP4430_DPLL_CLKOUT_GATE_CTRL_MASK;
+ v |= __ffs(OMAP4430_DPLL_CLKOUT_GATE_CTRL_MASK);
+ __raw_writel(v, clk->clksel_reg);
+}
+
+void omap4_dpllmx_deny_gatectrl(struct clk *clk)
+{
+ u32 v;
+
+ if (!clk || !(clk->flags & CLOCK_MX_IDLE_CONTROL) || !clk->clksel_reg)
+ return;
+
+ v = __raw_readl(clk->clksel_reg);
+ v &= ~OMAP4430_DPLL_CLKOUT_GATE_CTRL_MASK;
+ v |= DPLL_GATECTRL_DISABLE << __ffs(OMAP4430_DPLL_CLKOUT_GATE_CTRL_MASK);
+ __raw_writel(v, clk->clksel_reg);
+}
diff --git a/arch/arm/plat-omap/include/plat/clock.h b/arch/arm/plat-omap/include/plat/clock.h
index 8eb0ada..2937f5d 100644
--- a/arch/arm/plat-omap/include/plat/clock.h
+++ b/arch/arm/plat-omap/include/plat/clock.h
@@ -177,6 +177,7 @@ struct dpll_data {
#define CLOCK_NO_IDLE_PARENT (1 << 2)
#define ENABLE_ON_INIT (1 << 3) /* Enable upon framework init */
#define INVERT_ENABLE (1 << 4) /* 0 enables, 1 disables */
+#define CLOCK_MX_IDLE_CONTROL (1 << 5)
/**
* struct clk - OMAP struct clk
--
1.6.0.4
^ permalink raw reply related [flat|nested] 48+ messages in thread* [PATCH 5/6] omap4: dpll: Add dpll api to control GATE_CTRL
@ 2011-01-28 11:04 ` Santosh Shilimkar
0 siblings, 0 replies; 48+ messages in thread
From: Santosh Shilimkar @ 2011-01-28 11:04 UTC (permalink / raw)
To: linux-arm-kernel
From: Rajendra Nayak <rnayak@ti.com>
On OMAP4, the dpll post divider outputs (MX outputs)
provide a way to allow/deny autoidle.
Allowing autoidle would mean that the hw would autogate
this clock when there is no dependency for it.
Denying idle would mean that this clock output will be
forced to stay enabled.
Add dpll api's to read/allow/deny idle control.
Signed-off-by: Rajendra Nayak <rnayak@ti.com>
---
arch/arm/mach-omap2/clock.h | 3 ++
arch/arm/mach-omap2/dpll3xxx.c | 43 +++++++++++++++++++++++++++++++
arch/arm/plat-omap/include/plat/clock.h | 1 +
3 files changed, 47 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/clock.h b/arch/arm/mach-omap2/clock.h
index 896584e..19617f0 100644
--- a/arch/arm/mach-omap2/clock.h
+++ b/arch/arm/mach-omap2/clock.h
@@ -65,6 +65,9 @@ u32 omap3_dpll_autoidle_read(struct clk *clk);
int omap3_noncore_dpll_set_rate(struct clk *clk, unsigned long rate);
int omap3_noncore_dpll_enable(struct clk *clk);
void omap3_noncore_dpll_disable(struct clk *clk);
+int omap4_dpllmx_gatectrl_read(struct clk *clk);
+void omap4_dpllmx_allow_gatectrl(struct clk *clk);
+void omap4_dpllmx_deny_gatectrl(struct clk *clk);
#ifdef CONFIG_OMAP_RESET_CLOCKS
void omap2_clk_disable_unused(struct clk *clk);
diff --git a/arch/arm/mach-omap2/dpll3xxx.c b/arch/arm/mach-omap2/dpll3xxx.c
index f77022b..4ce06d5 100644
--- a/arch/arm/mach-omap2/dpll3xxx.c
+++ b/arch/arm/mach-omap2/dpll3xxx.c
@@ -34,11 +34,14 @@
#include "clock.h"
#include "cm2xxx_3xxx.h"
#include "cm-regbits-34xx.h"
+#include "cm-regbits-44xx.h"
/* CM_AUTOIDLE_PLL*.AUTO_* bit values */
#define DPLL_AUTOIDLE_DISABLE 0x0
#define DPLL_AUTOIDLE_LOW_POWER_STOP 0x1
+#define DPLL_GATECTRL_DISABLE 0x0
+
#define MAX_DPLL_WAIT_TRIES 1000000
/* Private functions */
@@ -612,3 +615,43 @@ unsigned long omap3_clkoutx2_recalc(struct clk *clk)
rate = clk->parent->rate * 2;
return rate;
}
+
+int omap4_dpllmx_gatectrl_read(struct clk *clk)
+{
+ u32 v;
+
+ if (!clk || !(clk->flags & CLOCK_MX_IDLE_CONTROL) || !clk->clksel_reg)
+ return -EINVAL;
+
+ v = __raw_readl(clk->clksel_reg);
+ v &= OMAP4430_DPLL_CLKOUT_GATE_CTRL_MASK;
+ v >>= __ffs(OMAP4430_DPLL_CLKOUT_GATE_CTRL_MASK);
+
+ return v;
+}
+
+void omap4_dpllmx_allow_gatectrl(struct clk *clk)
+{
+ u32 v;
+
+ if (!clk || !(clk->flags & CLOCK_MX_IDLE_CONTROL) || !clk->clksel_reg)
+ return;
+
+ v = __raw_readl(clk->clksel_reg);
+ v &= ~OMAP4430_DPLL_CLKOUT_GATE_CTRL_MASK;
+ v |= __ffs(OMAP4430_DPLL_CLKOUT_GATE_CTRL_MASK);
+ __raw_writel(v, clk->clksel_reg);
+}
+
+void omap4_dpllmx_deny_gatectrl(struct clk *clk)
+{
+ u32 v;
+
+ if (!clk || !(clk->flags & CLOCK_MX_IDLE_CONTROL) || !clk->clksel_reg)
+ return;
+
+ v = __raw_readl(clk->clksel_reg);
+ v &= ~OMAP4430_DPLL_CLKOUT_GATE_CTRL_MASK;
+ v |= DPLL_GATECTRL_DISABLE << __ffs(OMAP4430_DPLL_CLKOUT_GATE_CTRL_MASK);
+ __raw_writel(v, clk->clksel_reg);
+}
diff --git a/arch/arm/plat-omap/include/plat/clock.h b/arch/arm/plat-omap/include/plat/clock.h
index 8eb0ada..2937f5d 100644
--- a/arch/arm/plat-omap/include/plat/clock.h
+++ b/arch/arm/plat-omap/include/plat/clock.h
@@ -177,6 +177,7 @@ struct dpll_data {
#define CLOCK_NO_IDLE_PARENT (1 << 2)
#define ENABLE_ON_INIT (1 << 3) /* Enable upon framework init */
#define INVERT_ENABLE (1 << 4) /* 0 enables, 1 disables */
+#define CLOCK_MX_IDLE_CONTROL (1 << 5)
/**
* struct clk - OMAP struct clk
--
1.6.0.4
^ permalink raw reply related [flat|nested] 48+ messages in thread
* [PATCH 6/6] omap4: dpll: Enable auto gate control for all MX postdividers
2011-01-28 11:04 ` Santosh Shilimkar
@ 2011-01-28 11:04 ` Santosh Shilimkar
-1 siblings, 0 replies; 48+ messages in thread
From: Santosh Shilimkar @ 2011-01-28 11:04 UTC (permalink / raw)
To: linux-omap; +Cc: khilman, paul, b-cousson, rnayak, linux-arm-kernel
From: Rajendra Nayak <rnayak@ti.com>
Enable auto/hw gate control for all dpll MX postdividers.
This requires the corresponding CLOCK_MX_IDLE_CONTROL to
be populated for all respective clock nodes.
Signed-off-by: Rajendra Nayak <rnayak@ti.com>
---
arch/arm/mach-omap2/clock44xx_data.c | 22 ++++++++++++++++++++++
1 files changed, 22 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/clock44xx_data.c b/arch/arm/mach-omap2/clock44xx_data.c
index e5c59a0..0f06dd2 100644
--- a/arch/arm/mach-omap2/clock44xx_data.c
+++ b/arch/arm/mach-omap2/clock44xx_data.c
@@ -329,6 +329,7 @@ static struct clk dpll_abe_m2x2_ck = {
.clksel = dpll_abe_m2x2_div,
.clksel_reg = OMAP4430_CM_DIV_M2_DPLL_ABE,
.clksel_mask = OMAP4430_DPLL_CLKOUT_DIV_MASK,
+ .flags = CLOCK_MX_IDLE_CONTROL,
.ops = &clkops_null,
.recalc = &omap2_clksel_recalc,
.round_rate = &omap2_clksel_round_rate,
@@ -396,6 +397,7 @@ static struct clk dpll_abe_m3x2_ck = {
.clksel = dpll_abe_m2x2_div,
.clksel_reg = OMAP4430_CM_DIV_M3_DPLL_ABE,
.clksel_mask = OMAP4430_DPLL_CLKOUTHIF_DIV_MASK,
+ .flags = CLOCK_MX_IDLE_CONTROL,
.ops = &clkops_null,
.recalc = &omap2_clksel_recalc,
.round_rate = &omap2_clksel_round_rate,
@@ -466,6 +468,7 @@ static struct clk dpll_core_m6x2_ck = {
.clksel = dpll_core_m6x2_div,
.clksel_reg = OMAP4430_CM_DIV_M6_DPLL_CORE,
.clksel_mask = OMAP4430_HSDIVIDER_CLKOUT3_DIV_MASK,
+ .flags = CLOCK_MX_IDLE_CONTROL,
.ops = &clkops_null,
.recalc = &omap2_clksel_recalc,
.round_rate = &omap2_clksel_round_rate,
@@ -496,6 +499,7 @@ static struct clk dpll_core_m2_ck = {
.clksel = dpll_core_m2_div,
.clksel_reg = OMAP4430_CM_DIV_M2_DPLL_CORE,
.clksel_mask = OMAP4430_DPLL_CLKOUT_DIV_MASK,
+ .flags = CLOCK_MX_IDLE_CONTROL,
.ops = &clkops_null,
.recalc = &omap2_clksel_recalc,
.round_rate = &omap2_clksel_round_rate,
@@ -516,6 +520,7 @@ static struct clk dpll_core_m5x2_ck = {
.clksel = dpll_core_m6x2_div,
.clksel_reg = OMAP4430_CM_DIV_M5_DPLL_CORE,
.clksel_mask = OMAP4430_HSDIVIDER_CLKOUT2_DIV_MASK,
+ .flags = CLOCK_MX_IDLE_CONTROL,
.ops = &clkops_null,
.recalc = &omap2_clksel_recalc,
.round_rate = &omap2_clksel_round_rate,
@@ -582,6 +587,7 @@ static struct clk dpll_core_m4x2_ck = {
.clksel = dpll_core_m6x2_div,
.clksel_reg = OMAP4430_CM_DIV_M4_DPLL_CORE,
.clksel_mask = OMAP4430_HSDIVIDER_CLKOUT1_DIV_MASK,
+ .flags = CLOCK_MX_IDLE_CONTROL,
.ops = &clkops_null,
.recalc = &omap2_clksel_recalc,
.round_rate = &omap2_clksel_round_rate,
@@ -607,6 +613,7 @@ static struct clk dpll_abe_m2_ck = {
.clksel = dpll_abe_m2_div,
.clksel_reg = OMAP4430_CM_DIV_M2_DPLL_ABE,
.clksel_mask = OMAP4430_DPLL_CLKOUT_DIV_MASK,
+ .flags = CLOCK_MX_IDLE_CONTROL,
.ops = &clkops_null,
.recalc = &omap2_clksel_recalc,
.round_rate = &omap2_clksel_round_rate,
@@ -633,6 +640,7 @@ static struct clk dpll_core_m7x2_ck = {
.clksel = dpll_core_m6x2_div,
.clksel_reg = OMAP4430_CM_DIV_M7_DPLL_CORE,
.clksel_mask = OMAP4430_HSDIVIDER_CLKOUT4_DIV_MASK,
+ .flags = CLOCK_MX_IDLE_CONTROL,
.ops = &clkops_null,
.recalc = &omap2_clksel_recalc,
.round_rate = &omap2_clksel_round_rate,
@@ -705,6 +713,7 @@ static struct clk dpll_iva_m4x2_ck = {
.clksel = dpll_iva_m4x2_div,
.clksel_reg = OMAP4430_CM_DIV_M4_DPLL_IVA,
.clksel_mask = OMAP4430_HSDIVIDER_CLKOUT1_DIV_MASK,
+ .flags = CLOCK_MX_IDLE_CONTROL,
.ops = &clkops_null,
.recalc = &omap2_clksel_recalc,
.round_rate = &omap2_clksel_round_rate,
@@ -717,6 +726,7 @@ static struct clk dpll_iva_m5x2_ck = {
.clksel = dpll_iva_m4x2_div,
.clksel_reg = OMAP4430_CM_DIV_M5_DPLL_IVA,
.clksel_mask = OMAP4430_HSDIVIDER_CLKOUT2_DIV_MASK,
+ .flags = CLOCK_MX_IDLE_CONTROL,
.ops = &clkops_null,
.recalc = &omap2_clksel_recalc,
.round_rate = &omap2_clksel_round_rate,
@@ -765,6 +775,7 @@ static struct clk dpll_mpu_m2_ck = {
.clksel = dpll_mpu_m2_div,
.clksel_reg = OMAP4430_CM_DIV_M2_DPLL_MPU,
.clksel_mask = OMAP4430_DPLL_CLKOUT_DIV_MASK,
+ .flags = CLOCK_MX_IDLE_CONTROL,
.ops = &clkops_null,
.recalc = &omap2_clksel_recalc,
.round_rate = &omap2_clksel_round_rate,
@@ -838,6 +849,7 @@ static struct clk dpll_per_m2_ck = {
.clksel = dpll_per_m2_div,
.clksel_reg = OMAP4430_CM_DIV_M2_DPLL_PER,
.clksel_mask = OMAP4430_DPLL_CLKOUT_DIV_MASK,
+ .flags = CLOCK_MX_IDLE_CONTROL,
.ops = &clkops_null,
.recalc = &omap2_clksel_recalc,
.round_rate = &omap2_clksel_round_rate,
@@ -862,6 +874,7 @@ static struct clk dpll_per_m2x2_ck = {
.clksel = dpll_per_m2x2_div,
.clksel_reg = OMAP4430_CM_DIV_M2_DPLL_PER,
.clksel_mask = OMAP4430_DPLL_CLKOUT_DIV_MASK,
+ .flags = CLOCK_MX_IDLE_CONTROL,
.ops = &clkops_null,
.recalc = &omap2_clksel_recalc,
.round_rate = &omap2_clksel_round_rate,
@@ -888,6 +901,7 @@ static struct clk dpll_per_m4x2_ck = {
.clksel = dpll_per_m2x2_div,
.clksel_reg = OMAP4430_CM_DIV_M4_DPLL_PER,
.clksel_mask = OMAP4430_HSDIVIDER_CLKOUT1_DIV_MASK,
+ .flags = CLOCK_MX_IDLE_CONTROL,
.ops = &clkops_null,
.recalc = &omap2_clksel_recalc,
.round_rate = &omap2_clksel_round_rate,
@@ -900,6 +914,7 @@ static struct clk dpll_per_m5x2_ck = {
.clksel = dpll_per_m2x2_div,
.clksel_reg = OMAP4430_CM_DIV_M5_DPLL_PER,
.clksel_mask = OMAP4430_HSDIVIDER_CLKOUT2_DIV_MASK,
+ .flags = CLOCK_MX_IDLE_CONTROL,
.ops = &clkops_null,
.recalc = &omap2_clksel_recalc,
.round_rate = &omap2_clksel_round_rate,
@@ -912,6 +927,7 @@ static struct clk dpll_per_m6x2_ck = {
.clksel = dpll_per_m2x2_div,
.clksel_reg = OMAP4430_CM_DIV_M6_DPLL_PER,
.clksel_mask = OMAP4430_HSDIVIDER_CLKOUT3_DIV_MASK,
+ .flags = CLOCK_MX_IDLE_CONTROL,
.ops = &clkops_null,
.recalc = &omap2_clksel_recalc,
.round_rate = &omap2_clksel_round_rate,
@@ -924,6 +940,7 @@ static struct clk dpll_per_m7x2_ck = {
.clksel = dpll_per_m2x2_div,
.clksel_reg = OMAP4430_CM_DIV_M7_DPLL_PER,
.clksel_mask = OMAP4430_HSDIVIDER_CLKOUT4_DIV_MASK,
+ .flags = CLOCK_MX_IDLE_CONTROL,
.ops = &clkops_null,
.recalc = &omap2_clksel_recalc,
.round_rate = &omap2_clksel_round_rate,
@@ -980,6 +997,7 @@ static struct clk dpll_unipro_m2x2_ck = {
.clksel = dpll_unipro_m2x2_div,
.clksel_reg = OMAP4430_CM_DIV_M2_DPLL_UNIPRO,
.clksel_mask = OMAP4430_DPLL_CLKOUT_DIV_MASK,
+ .flags = CLOCK_MX_IDLE_CONTROL,
.ops = &clkops_null,
.recalc = &omap2_clksel_recalc,
.round_rate = &omap2_clksel_round_rate,
@@ -1029,6 +1047,7 @@ static struct clk dpll_usb_ck = {
static struct clk dpll_usb_clkdcoldo_ck = {
.name = "dpll_usb_clkdcoldo_ck",
.parent = &dpll_usb_ck,
+ .flags = CLOCK_MX_IDLE_CONTROL,
.ops = &clkops_null,
.recalc = &followparent_recalc,
};
@@ -1044,6 +1063,7 @@ static struct clk dpll_usb_m2_ck = {
.clksel = dpll_usb_m2_div,
.clksel_reg = OMAP4430_CM_DIV_M2_DPLL_USB,
.clksel_mask = OMAP4430_DPLL_CLKOUT_DIV_0_6_MASK,
+ .flags = CLOCK_MX_IDLE_CONTROL,
.ops = &clkops_null,
.recalc = &omap2_clksel_recalc,
.round_rate = &omap2_clksel_round_rate,
@@ -3302,6 +3322,8 @@ int __init omap4xxx_clk_init(void)
omap2_init_clk_clkdm(c->lk.clk);
if (c->lk.clk->dpll_data)
omap3_dpll_allow_idle(c->lk.clk);
+ if (c->lk.clk->flags & CLOCK_MX_IDLE_CONTROL)
+ omap4_dpllmx_allow_gatectrl(c->lk.clk);
}
recalculate_root_clocks();
--
1.6.0.4
^ permalink raw reply related [flat|nested] 48+ messages in thread* [PATCH 6/6] omap4: dpll: Enable auto gate control for all MX postdividers
@ 2011-01-28 11:04 ` Santosh Shilimkar
0 siblings, 0 replies; 48+ messages in thread
From: Santosh Shilimkar @ 2011-01-28 11:04 UTC (permalink / raw)
To: linux-arm-kernel
From: Rajendra Nayak <rnayak@ti.com>
Enable auto/hw gate control for all dpll MX postdividers.
This requires the corresponding CLOCK_MX_IDLE_CONTROL to
be populated for all respective clock nodes.
Signed-off-by: Rajendra Nayak <rnayak@ti.com>
---
arch/arm/mach-omap2/clock44xx_data.c | 22 ++++++++++++++++++++++
1 files changed, 22 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/clock44xx_data.c b/arch/arm/mach-omap2/clock44xx_data.c
index e5c59a0..0f06dd2 100644
--- a/arch/arm/mach-omap2/clock44xx_data.c
+++ b/arch/arm/mach-omap2/clock44xx_data.c
@@ -329,6 +329,7 @@ static struct clk dpll_abe_m2x2_ck = {
.clksel = dpll_abe_m2x2_div,
.clksel_reg = OMAP4430_CM_DIV_M2_DPLL_ABE,
.clksel_mask = OMAP4430_DPLL_CLKOUT_DIV_MASK,
+ .flags = CLOCK_MX_IDLE_CONTROL,
.ops = &clkops_null,
.recalc = &omap2_clksel_recalc,
.round_rate = &omap2_clksel_round_rate,
@@ -396,6 +397,7 @@ static struct clk dpll_abe_m3x2_ck = {
.clksel = dpll_abe_m2x2_div,
.clksel_reg = OMAP4430_CM_DIV_M3_DPLL_ABE,
.clksel_mask = OMAP4430_DPLL_CLKOUTHIF_DIV_MASK,
+ .flags = CLOCK_MX_IDLE_CONTROL,
.ops = &clkops_null,
.recalc = &omap2_clksel_recalc,
.round_rate = &omap2_clksel_round_rate,
@@ -466,6 +468,7 @@ static struct clk dpll_core_m6x2_ck = {
.clksel = dpll_core_m6x2_div,
.clksel_reg = OMAP4430_CM_DIV_M6_DPLL_CORE,
.clksel_mask = OMAP4430_HSDIVIDER_CLKOUT3_DIV_MASK,
+ .flags = CLOCK_MX_IDLE_CONTROL,
.ops = &clkops_null,
.recalc = &omap2_clksel_recalc,
.round_rate = &omap2_clksel_round_rate,
@@ -496,6 +499,7 @@ static struct clk dpll_core_m2_ck = {
.clksel = dpll_core_m2_div,
.clksel_reg = OMAP4430_CM_DIV_M2_DPLL_CORE,
.clksel_mask = OMAP4430_DPLL_CLKOUT_DIV_MASK,
+ .flags = CLOCK_MX_IDLE_CONTROL,
.ops = &clkops_null,
.recalc = &omap2_clksel_recalc,
.round_rate = &omap2_clksel_round_rate,
@@ -516,6 +520,7 @@ static struct clk dpll_core_m5x2_ck = {
.clksel = dpll_core_m6x2_div,
.clksel_reg = OMAP4430_CM_DIV_M5_DPLL_CORE,
.clksel_mask = OMAP4430_HSDIVIDER_CLKOUT2_DIV_MASK,
+ .flags = CLOCK_MX_IDLE_CONTROL,
.ops = &clkops_null,
.recalc = &omap2_clksel_recalc,
.round_rate = &omap2_clksel_round_rate,
@@ -582,6 +587,7 @@ static struct clk dpll_core_m4x2_ck = {
.clksel = dpll_core_m6x2_div,
.clksel_reg = OMAP4430_CM_DIV_M4_DPLL_CORE,
.clksel_mask = OMAP4430_HSDIVIDER_CLKOUT1_DIV_MASK,
+ .flags = CLOCK_MX_IDLE_CONTROL,
.ops = &clkops_null,
.recalc = &omap2_clksel_recalc,
.round_rate = &omap2_clksel_round_rate,
@@ -607,6 +613,7 @@ static struct clk dpll_abe_m2_ck = {
.clksel = dpll_abe_m2_div,
.clksel_reg = OMAP4430_CM_DIV_M2_DPLL_ABE,
.clksel_mask = OMAP4430_DPLL_CLKOUT_DIV_MASK,
+ .flags = CLOCK_MX_IDLE_CONTROL,
.ops = &clkops_null,
.recalc = &omap2_clksel_recalc,
.round_rate = &omap2_clksel_round_rate,
@@ -633,6 +640,7 @@ static struct clk dpll_core_m7x2_ck = {
.clksel = dpll_core_m6x2_div,
.clksel_reg = OMAP4430_CM_DIV_M7_DPLL_CORE,
.clksel_mask = OMAP4430_HSDIVIDER_CLKOUT4_DIV_MASK,
+ .flags = CLOCK_MX_IDLE_CONTROL,
.ops = &clkops_null,
.recalc = &omap2_clksel_recalc,
.round_rate = &omap2_clksel_round_rate,
@@ -705,6 +713,7 @@ static struct clk dpll_iva_m4x2_ck = {
.clksel = dpll_iva_m4x2_div,
.clksel_reg = OMAP4430_CM_DIV_M4_DPLL_IVA,
.clksel_mask = OMAP4430_HSDIVIDER_CLKOUT1_DIV_MASK,
+ .flags = CLOCK_MX_IDLE_CONTROL,
.ops = &clkops_null,
.recalc = &omap2_clksel_recalc,
.round_rate = &omap2_clksel_round_rate,
@@ -717,6 +726,7 @@ static struct clk dpll_iva_m5x2_ck = {
.clksel = dpll_iva_m4x2_div,
.clksel_reg = OMAP4430_CM_DIV_M5_DPLL_IVA,
.clksel_mask = OMAP4430_HSDIVIDER_CLKOUT2_DIV_MASK,
+ .flags = CLOCK_MX_IDLE_CONTROL,
.ops = &clkops_null,
.recalc = &omap2_clksel_recalc,
.round_rate = &omap2_clksel_round_rate,
@@ -765,6 +775,7 @@ static struct clk dpll_mpu_m2_ck = {
.clksel = dpll_mpu_m2_div,
.clksel_reg = OMAP4430_CM_DIV_M2_DPLL_MPU,
.clksel_mask = OMAP4430_DPLL_CLKOUT_DIV_MASK,
+ .flags = CLOCK_MX_IDLE_CONTROL,
.ops = &clkops_null,
.recalc = &omap2_clksel_recalc,
.round_rate = &omap2_clksel_round_rate,
@@ -838,6 +849,7 @@ static struct clk dpll_per_m2_ck = {
.clksel = dpll_per_m2_div,
.clksel_reg = OMAP4430_CM_DIV_M2_DPLL_PER,
.clksel_mask = OMAP4430_DPLL_CLKOUT_DIV_MASK,
+ .flags = CLOCK_MX_IDLE_CONTROL,
.ops = &clkops_null,
.recalc = &omap2_clksel_recalc,
.round_rate = &omap2_clksel_round_rate,
@@ -862,6 +874,7 @@ static struct clk dpll_per_m2x2_ck = {
.clksel = dpll_per_m2x2_div,
.clksel_reg = OMAP4430_CM_DIV_M2_DPLL_PER,
.clksel_mask = OMAP4430_DPLL_CLKOUT_DIV_MASK,
+ .flags = CLOCK_MX_IDLE_CONTROL,
.ops = &clkops_null,
.recalc = &omap2_clksel_recalc,
.round_rate = &omap2_clksel_round_rate,
@@ -888,6 +901,7 @@ static struct clk dpll_per_m4x2_ck = {
.clksel = dpll_per_m2x2_div,
.clksel_reg = OMAP4430_CM_DIV_M4_DPLL_PER,
.clksel_mask = OMAP4430_HSDIVIDER_CLKOUT1_DIV_MASK,
+ .flags = CLOCK_MX_IDLE_CONTROL,
.ops = &clkops_null,
.recalc = &omap2_clksel_recalc,
.round_rate = &omap2_clksel_round_rate,
@@ -900,6 +914,7 @@ static struct clk dpll_per_m5x2_ck = {
.clksel = dpll_per_m2x2_div,
.clksel_reg = OMAP4430_CM_DIV_M5_DPLL_PER,
.clksel_mask = OMAP4430_HSDIVIDER_CLKOUT2_DIV_MASK,
+ .flags = CLOCK_MX_IDLE_CONTROL,
.ops = &clkops_null,
.recalc = &omap2_clksel_recalc,
.round_rate = &omap2_clksel_round_rate,
@@ -912,6 +927,7 @@ static struct clk dpll_per_m6x2_ck = {
.clksel = dpll_per_m2x2_div,
.clksel_reg = OMAP4430_CM_DIV_M6_DPLL_PER,
.clksel_mask = OMAP4430_HSDIVIDER_CLKOUT3_DIV_MASK,
+ .flags = CLOCK_MX_IDLE_CONTROL,
.ops = &clkops_null,
.recalc = &omap2_clksel_recalc,
.round_rate = &omap2_clksel_round_rate,
@@ -924,6 +940,7 @@ static struct clk dpll_per_m7x2_ck = {
.clksel = dpll_per_m2x2_div,
.clksel_reg = OMAP4430_CM_DIV_M7_DPLL_PER,
.clksel_mask = OMAP4430_HSDIVIDER_CLKOUT4_DIV_MASK,
+ .flags = CLOCK_MX_IDLE_CONTROL,
.ops = &clkops_null,
.recalc = &omap2_clksel_recalc,
.round_rate = &omap2_clksel_round_rate,
@@ -980,6 +997,7 @@ static struct clk dpll_unipro_m2x2_ck = {
.clksel = dpll_unipro_m2x2_div,
.clksel_reg = OMAP4430_CM_DIV_M2_DPLL_UNIPRO,
.clksel_mask = OMAP4430_DPLL_CLKOUT_DIV_MASK,
+ .flags = CLOCK_MX_IDLE_CONTROL,
.ops = &clkops_null,
.recalc = &omap2_clksel_recalc,
.round_rate = &omap2_clksel_round_rate,
@@ -1029,6 +1047,7 @@ static struct clk dpll_usb_ck = {
static struct clk dpll_usb_clkdcoldo_ck = {
.name = "dpll_usb_clkdcoldo_ck",
.parent = &dpll_usb_ck,
+ .flags = CLOCK_MX_IDLE_CONTROL,
.ops = &clkops_null,
.recalc = &followparent_recalc,
};
@@ -1044,6 +1063,7 @@ static struct clk dpll_usb_m2_ck = {
.clksel = dpll_usb_m2_div,
.clksel_reg = OMAP4430_CM_DIV_M2_DPLL_USB,
.clksel_mask = OMAP4430_DPLL_CLKOUT_DIV_0_6_MASK,
+ .flags = CLOCK_MX_IDLE_CONTROL,
.ops = &clkops_null,
.recalc = &omap2_clksel_recalc,
.round_rate = &omap2_clksel_round_rate,
@@ -3302,6 +3322,8 @@ int __init omap4xxx_clk_init(void)
omap2_init_clk_clkdm(c->lk.clk);
if (c->lk.clk->dpll_data)
omap3_dpll_allow_idle(c->lk.clk);
+ if (c->lk.clk->flags & CLOCK_MX_IDLE_CONTROL)
+ omap4_dpllmx_allow_gatectrl(c->lk.clk);
}
recalculate_root_clocks();
--
1.6.0.4
^ permalink raw reply related [flat|nested] 48+ messages in thread
* RE: [PATCH 0/6] omap4: prcm: Few dpll, clockdomain and powerdomain updates
2011-01-28 11:04 ` Santosh Shilimkar
@ 2011-01-28 12:37 ` Santosh Shilimkar
-1 siblings, 0 replies; 48+ messages in thread
From: Santosh Shilimkar @ 2011-01-28 12:37 UTC (permalink / raw)
To: linux-omap
Cc: Kevin Hilman, paul, Benoit Cousson, Rajendra Nayak, linux-arm-kernel
> -----Original Message-----
> From: Santosh Shilimkar [mailto:santosh.shilimkar@ti.com]
> Sent: Friday, January 28, 2011 4:35 PM
> To: linux-omap@vger.kernel.org
> Cc: khilman@ti.com; paul@pwsan.com; b-cousson@ti.com; rnayak@ti.com;
> linux-arm-kernel@lists.infradead.org; Santosh Shilimkar
> Subject: [PATCH 0/6] omap4: prcm: Few dpll, clockdomain and
> powerdomain updates
>
> The series mainly contains dpll initialisation, CPUx clock
> domain offset fix, addiing INACTIVE power domain state and
> fixing logic flag for IVAHD and ABE power domains.
>
> The series is boot tested on OMAP4430 SDP.
>
> The following changes since commit
> 1bae4ce27c9c90344f23c65ea6966c50ffeae2f5:
> Linus Torvalds (1):
> Linux 2.6.38-rc2
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-
> 2.6.git omap4_prcm_misc
>
With corrected git URL:
git://dev.omapzoom.org/pub/scm/santosh/kernel-omap4-base.git
omap4_prcm_misc
Regards,
Santosh
^ permalink raw reply [flat|nested] 48+ messages in thread
* [PATCH 0/6] omap4: prcm: Few dpll, clockdomain and powerdomain updates
@ 2011-01-28 12:37 ` Santosh Shilimkar
0 siblings, 0 replies; 48+ messages in thread
From: Santosh Shilimkar @ 2011-01-28 12:37 UTC (permalink / raw)
To: linux-arm-kernel
> -----Original Message-----
> From: Santosh Shilimkar [mailto:santosh.shilimkar at ti.com]
> Sent: Friday, January 28, 2011 4:35 PM
> To: linux-omap at vger.kernel.org
> Cc: khilman at ti.com; paul at pwsan.com; b-cousson at ti.com; rnayak at ti.com;
> linux-arm-kernel at lists.infradead.org; Santosh Shilimkar
> Subject: [PATCH 0/6] omap4: prcm: Few dpll, clockdomain and
> powerdomain updates
>
> The series mainly contains dpll initialisation, CPUx clock
> domain offset fix, addiing INACTIVE power domain state and
> fixing logic flag for IVAHD and ABE power domains.
>
> The series is boot tested on OMAP4430 SDP.
>
> The following changes since commit
> 1bae4ce27c9c90344f23c65ea6966c50ffeae2f5:
> Linus Torvalds (1):
> Linux 2.6.38-rc2
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-
> 2.6.git omap4_prcm_misc
>
With corrected git URL:
git://dev.omapzoom.org/pub/scm/santosh/kernel-omap4-base.git
omap4_prcm_misc
Regards,
Santosh
^ permalink raw reply [flat|nested] 48+ messages in thread