Skip to contentSkip to conversation

omap4: prcm: Few dpll, clockdomain and powerdomain updates

PATCH New Santosh Shilimkar 3 participants 27 messages Feb 4, 2011 – Feb 25, 2011

Subsystems (5)
Arm (32-bit) Arm sub-architectures OMAP2+ support OMAP power management support +1 more subsystems
lore
Share & tools
lore

Santosh Shilimkar

author
#0 lore raw

v2 cover 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.

Changes in v2:
- All dpll autoidling moved late in boot, (as part of
PM core init) and is done only with CONFIG_PM.
- The autogen script update is added in changelog for
related patches
- CPUx renaming patch is added to be consistent with
the database names

The series is boot tested on OMAP4430/3430 SDP.

The following changes since commit 1bae4ce27c9c90344f23c65ea6966c50ffeae2f5:
Linus Torvalds (1):

        Linux 2.6.38-rc2

are available in the git repository at:

git://dev.omapzoom.org/pub/scm/santosh/kernel-omap4-base.git omap4_prcm_misc_v2

Benoit Cousson (1):
omap4: clockdomain: Fix the CPUx domain name

Rajendra Nayak (5):
omap: clocks: Add checks to see if enable/disable ops are supported
omap: clocks: Add allow_idle/deny_idle support in clkops
omap: dpll: Add allow_idle/deny_idle support for all DPLL's
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.c                 |   25 +++++++++++++---
 arch/arm/mach-omap2/clock.h                 |    5 +++
 arch/arm/mach-omap2/clock3xxx_data.c        |    2 +-
 arch/arm/mach-omap2/clock44xx_data.c        |   42 +++++++++++++-------------
 arch/arm/mach-omap2/clockdomains44xx_data.c |    4 +-
 arch/arm/mach-omap2/dpll3xxx.c              |   42 +++++++++++++++++++++++++++
 arch/arm/mach-omap2/pm44xx.c                |    4 ++
 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/clock.c                  |   26 ++++++++++++++++
 arch/arm/plat-omap/include/plat/clock.h     |    6 ++++
 12 files changed, 156 insertions(+), 46 deletions(-)
author
#1 lore raw

PATCH v2 1/9 omap4: powerdomain: Add supported INACTIVE power state

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.

This patch adds the support to allow power domain INACTIVE programming which is supported on OMAP4.

The powerdomain autogen script is updated accordingly.

Signed-off-by Santosh Shilimkar <[email protected]>
Cc Rajendra Nayak <[email protected]>
Cc Benoit Cousson <[email protected]>
Cc Paul Walmsley <[email protected]>
---
 arch/arm/mach-omap2/powerdomain.h           |   12 ++++++++++++
 arch/arm/mach-omap2/powerdomains44xx_data.c |   26 +++++++++++++-------------
 2 files changed, 25 insertions(+), 13 deletions(-)
arch/arm/mach-omap2/powerdomain.h +12 -0
index c66431e..0e15ca7 100644
@@ -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 */
arch/arm/mach-omap2/powerdomains44xx_data.c +13 -13
index 26d7641..96cde98 100644
@@ -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,
 };
 
 /*
Signature · 1 line
1.6.0.4
maintainer
#2 lore raw

PATCH v2 1/9 omap4: powerdomain: Add supported INACTIVE power state

Hi

Quoted 10 lines · 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.

This patch adds the support to allow power domain INACTIVE programming which is supported on OMAP4.

The powerdomain autogen script is updated accordingly.

Continuing the discussion here:

http://www.mail-archive.com/linux-omap at vger.kernel.org/msg43509.html

1. It appears that the OMAP4 powerdomain ON-ACTIVE state is a new state for OMAP4, and does not exist as such on previous chips (unless the PRM_VOLTCTRL.AUTO_* bits are all disabled)

2. It also appears that the OMAP4 powerdomain ON-INACTIVE state is equivalent to the OMAP3 powerdomain ON state (again, assuming that the PRM_VOLTCTRL.AUTO_SLEEP bit is set on OMAP3).

Could you please comment on whether these statements are true or false?

- Paul

author
#3 lore raw

PATCH v2 1/9 omap4: powerdomain: Add supported INACTIVE power state

Quoted 31 lines

-----Original Message-----
From: Paul Walmsley [mailto:paul at pwsan.com]
Sent: Monday, February 07, 2011 2:12 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 v2 1/9] omap4: powerdomain: Add supported INACTIVE power state

Hi

Quoted 1 line · Santosh Shilimkar

On OMAP4, one can explicitly program INACTIVE as the power state

of

Quoted 1 line

the logic area inside the power domain. Techincally PD state

programmed

Quoted 1 line

to ON and if all the clock domains within the PD are idled, is

equivalent

Quoted 1 line

tp PD programmed to INACTIVE and all the clock domains within the

PD are

Quoted 3 lines

idled. There won't be any power difference in above two.

This patch adds the support to allow power domain INACTIVE

programming

Quoted 3 lines

which is supported on OMAP4.

The powerdomain autogen script is updated accordingly.

Continuing the discussion here:

Quoted 8 lines

http://www.mail-archive.com/linux-
omap at vger.kernel.org/msg43509.html

1. It appears that the OMAP4 powerdomain ON-ACTIVE state is a new state
for OMAP4, and does not exist as such on previous chips (unless the PRM_VOLTCTRL.AUTO_* bits are all disabled)

Actually it's not new state but more of convention change. ON-ACTIVE is like ON in OMAP3.

Quoted 5 lines

2. It also appears that the OMAP4 powerdomain ON-INACTIVE state is equivalent to the OMAP3 powerdomain ON state (again, assuming that the
PRM_VOLTCTRL.AUTO_SLEEP bit is set on OMAP3).

This is correct.

Quoted 3 lines

Could you please comment on whether these statements are true or false?

Just to summarise my undertsnaing of this here.
On OMAP3 too, we had possibility of being in a one of the Two state when programmed to PD ON state.
ON-ACTIVE or ON-INACTIVE. The PD status registers just says INACTIVE or ON based on the clodomains states within PD.

On OMAP4, the difference is we do have a way to program the PD state explicitly as ON or INACTIVE.

Regards,
Santosh

maintainer
#4 lore raw

PATCH v2 1/9 omap4: powerdomain: Add supported INACTIVE power state

Quoted 9 lines · Santosh Shilimkar
Quoted 9 lines

-----Original Message-----
From: Paul Walmsley [mailto:paul at pwsan.com]
Sent: Monday, February 07, 2011 2:12 AM

Continuing the discussion here:

http://www.mail-archive.com/linux-
omap at vger.kernel.org/msg43509.html

Quoted 7 lines
Quoted 5 lines

1. It appears that the OMAP4 powerdomain ON-ACTIVE state is a new state
for OMAP4, and does not exist as such on previous chips (unless the PRM_VOLTCTRL.AUTO_* bits are all disabled)

Actually it's not new state but more of convention change. ON-ACTIVE is like ON in OMAP3.

Hmm, based on our earlier list mails, that seems confusing. Setting an OMAP3 powerdomain next-power-state to 'ON' in OMAP3 allows voltage domain transitions to the SLEEP level. But setting an OMAP4 powerdomain next-power-state to 'ON-ACTIVE' does not allow voltage domain transitions to the SLEEP level. And setting an OMAP4 powerdomain next-power-state to 'ON-INACTIVE' does allow voltage domain transitions to the SLEEP level. Is that correct?

If that's correct, then OMAP4 ON-ACTIVE is a functionally new powerdomain next-power-state setting, and OMAP4 ON-INACTIVE is the same state as OMAP3 ON. Unless there's something obvious that I'm missing?

Quoted 11 lines
Quoted 5 lines

2. It also appears that the OMAP4 powerdomain ON-INACTIVE state is equivalent to the OMAP3 powerdomain ON state (again, assuming that the
PRM_VOLTCTRL.AUTO_SLEEP bit is set on OMAP3).

This is correct.

Quoted 3 lines

Could you please comment on whether these statements are true or false?

Quoted 5 lines

Just to summarise my undertsnaing of this here.
On OMAP3 too, we had possibility of being in a one of the Two state when programmed to PD ON state.
ON-ACTIVE or ON-INACTIVE. The PD status registers just says INACTIVE or ON based on the clodomains states within PD.

Right, but when 'ON' is written into an OMAP3 powerdomain's next-power-state bits, voltage domain transitions are allowed. So I'm just trying to confirm that OMAP3 ON state is functionally equivalent to the OMAP4 ON-INACTIVE state, and not functionally equivalent to the OMAP4 ON-ACTIVE state.

We have to ensure that the core code-internal meaning of the (ON, INACTIVE, RET, OFF) states doesn't vary across SoC types. Otherwise "ON" on OMAP4 won't mean "ON" on OMAP3, and the goal is for the core code to be SoC-independent.

One way to do that would be to add a small mapping layer for the powerdomain set-next-power-state code to:

- allow programming INACTIVE on OMAP3, by ensuring that, when all powerdomains in a voltage domain are in INACTIVE, that AUTO_SLEEP is set to 1, and then setting the hardware next-power-state to ON; and

- allow programming ON on OMAP3, by ensuring that AUTO_SLEEP is set to 0, and setting the hardware next-power-state to ON.

On OMAP4, presumably it wouldn't be needed to mess with the AUTO_SLEEP bit.

Probably to make that work cleanly, either clockdomains or powerdomains would need to be associated with voltage domains; and some kind of counter would need to be implemented in the voltage domains to indicate when it is appropriate to write to the AUTO_SLEEP bit.

- Paul

author
#5 lore raw

PATCH v2 1/9 omap4: powerdomain: Add supported INACTIVE power state

Quoted 31 lines

-----Original Message-----
From: Paul Walmsley [mailto:paul at pwsan.com]
Sent: Tuesday, February 08, 2011 7:02 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 v2 1/9] omap4: powerdomain: Add supported INACTIVE power state

Quoted 10 lines · Santosh Shilimkar
Quoted 10 lines

-----Original Message-----
From: Paul Walmsley [mailto:paul at pwsan.com]
Sent: Monday, February 07, 2011 2:12 AM

Continuing the discussion here:

http://www.mail-archive.com/linux-
omap at vger.kernel.org/msg43509.html

1. It appears that the OMAP4 powerdomain ON-ACTIVE state is a

new

Quoted 2 lines
Quoted 2 lines

state
for OMAP4, and does not exist as such on previous chips (unless

the

Quoted 3 lines
Quoted 2 lines

PRM_VOLTCTRL.AUTO_* bits are all disabled)

Actually it's not new state but more of convention change. ON-

ACTIVE

Quoted 1 line

is like ON in OMAP3.

Quoted 11 lines

Hmm, based on our earlier list mails, that seems confusing. Setting an
OMAP3 powerdomain next-power-state to 'ON' in OMAP3 allows voltage domain
transitions to the SLEEP level. But setting an OMAP4 powerdomain next-power-state to 'ON-ACTIVE' does not allow voltage domain transitions to the SLEEP level. And setting an OMAP4 powerdomain next-power-state to 'ON-INACTIVE' does allow voltage domain transitions to
the SLEEP level. Is that correct?

You have point. And you are absolutely correct.

Quoted 23 lines

If that's correct, then OMAP4 ON-ACTIVE is a functionally new powerdomain
next-power-state setting, and OMAP4 ON-INACTIVE is the same state as OMAP3
ON. Unless there's something obvious that I'm missing?

Quoted 11 lines
Quoted 5 lines

2. It also appears that the OMAP4 powerdomain ON-INACTIVE state is equivalent to the OMAP3 powerdomain ON state (again, assuming that the
PRM_VOLTCTRL.AUTO_SLEEP bit is set on OMAP3).

This is correct.

Quoted 3 lines

Could you please comment on whether these statements are true or false?

Quoted 5 lines

Just to summarise my undertsnaing of this here.
On OMAP3 too, we had possibility of being in a one of the Two state when programmed to PD ON state.
ON-ACTIVE or ON-INACTIVE. The PD status registers just says INACTIVE or ON based on the clodomains states within PD.

Quoted 9 lines

Right, but when 'ON' is written into an OMAP3 powerdomain's next-power-state bits, voltage domain transitions are allowed. So I'm
just trying to confirm that OMAP3 ON state is functionally equivalent to
the OMAP4 ON-INACTIVE state, and not functionally equivalent to the OMAP4
ON-ACTIVE state.

Yep. This is indeed the case.

Quoted 6 lines

We have to ensure that the core code-internal meaning of the (ON, INACTIVE, RET, OFF) states doesn't vary across SoC types. Otherwise "ON"
on OMAP4 won't mean "ON" on OMAP3, and the goal is for the core code to be SoC-independent.

Agree.

Quoted 15 lines

One way to do that would be to add a small mapping layer for the powerdomain set-next-power-state code to:

- allow programming INACTIVE on OMAP3, by ensuring that, when all powerdomains in a voltage domain are in INACTIVE, that AUTO_SLEEP is set to 1, and then setting the hardware next-power-state to ON;
and

- allow programming ON on OMAP3, by ensuring that AUTO_SLEEP is set to 0, and setting the hardware next-power-state to ON.

On OMAP4, presumably it wouldn't be needed to mess with the AUTO_SLEEP
bit.

Quoted 8 lines

Probably to make that work cleanly, either clockdomains or powerdomains
would need to be associated with voltage domains; and some kind of counter
would need to be implemented in the voltage domains to indicate when it is
appropriate to write to the AUTO_SLEEP bit.

Sounds right approach.

Regards,
Santosh

author
#6 lore raw

PATCH v2 2/9 omap4: prcm: Fix the CPUx clockdomain offsets

In reply to 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.

The autogen scripts is fixed thanks to Benoit Cousson

Signed-off-by Santosh Shilimkar <[email protected]>
Cc Paul Walmsley <[email protected]>
Cc Rajendra Nayak <[email protected]>
Cc Benoit Cousson <[email protected]>
---
 arch/arm/mach-omap2/prcm_mpu44xx.h |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)
arch/arm/mach-omap2/prcm_mpu44xx.h +2 -2
index 729a644..3300ff6 100644
@@ -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
 
 
 /*
Signature · 1 line
1.6.0.4
maintainer
#7 lore raw

PATCH v2 2/9 omap4: prcm: Fix the CPUx clockdomain offsets

Quoted 4 lines · 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

Quoted 8 lines

Fix the same.

The autogen scripts is fixed thanks to Benoit Cousson

Signed-off-by Santosh Shilimkar <[email protected]>
Cc Paul Walmsley <[email protected]>
Cc Rajendra Nayak <[email protected]>
Cc Benoit Cousson <[email protected]>

Thanks, queued for 2.6.39.

- Paul

maintainer
#8 lore raw

PATCH v2 2/9 omap4: prcm: Fix the CPUx clockdomain offsets

In reply to Santosh Shilimkar
Quoted 4 lines · 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

Quoted 8 lines

Fix the same.

The autogen scripts is fixed thanks to Benoit Cousson

Signed-off-by Santosh Shilimkar <[email protected]>
Cc Paul Walmsley <[email protected]>
Cc Rajendra Nayak <[email protected]>
Cc Benoit Cousson <[email protected]>

Will submit this one for -rc series, since this could result in writes to an incorrect register. Updated patch below.

- Paul

From: Santosh Shilimkar <[email protected]>
Date: Fri, 4 Feb 2011 15:28:57 +0530
Subject: [PATCH] omap4: prcm: Fix the CPUx clockdomain offsets

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.

The autogen scripts is fixed thanks to Benoit Cousson

With the old value, the clockdomain code would access the *_PWRSTCTRL.POWERSTATE field when it thought it was accessing the *_CLKSTCTRL.CLKTRCTRL field. In the worst case, this could cause system power management to behave incorrectly.

Signed-off-by Santosh Shilimkar <[email protected]>
Cc Paul Walmsley <[email protected]>
Cc Rajendra Nayak <[email protected]>
Cc Benoit Cousson <[email protected]>
[paul at pwsan.com: added second paragraph to commit message]
Signed-off-by Paul Walmsley <[email protected]>
---
 arch/arm/mach-omap2/prcm_mpu44xx.h |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)
arch/arm/mach-omap2/prcm_mpu44xx.h +2 -2
index 729a644..3300ff6 100644
@@ -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
 
 
 /*
Signature · 1 line
1.7.2.3
author
#9 lore raw

PATCH v2 3/9 omap4: powerdomain: Use intended PWRSTS_* flags instead of values

In reply to Santosh Shilimkar

IVAHD and ABE power domain logic state is populated using directly value instead of the capability flags.

Fix the same.

This was getting generated due to a bug 'gen_logicst' macro in powerdomain autogen script bug which is fixed as well.

Signed-off-by Santosh Shilimkar <[email protected]>
Cc Paul Walmsley <[email protected]>
Cc Rajendra Nayak <[email protected]>
Cc Benoit Cousson <[email protected]>
---
 arch/arm/mach-omap2/powerdomains44xx_data.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)
arch/arm/mach-omap2/powerdomains44xx_data.c +2 -2
index 96cde98..daee255 100644
@@ -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 */
Signature · 1 line
1.6.0.4
maintainer
#10 lore raw

PATCH v2 3/9 omap4: powerdomain: Use intended PWRSTS_* flags instead of values

Quoted 7 lines · Santosh Shilimkar

IVAHD and ABE power domain logic state is populated using directly value instead of the capability flags.

Fix the same.

This was getting generated due to a bug 'gen_logicst' macro in powerdomain autogen script bug which is fixed as well.

Should we try to get this one into the -rc series, since it is a bug-fix ?

- Paul

author
#11 lore raw

PATCH v2 3/9 omap4: powerdomain: Use intended PWRSTS_* flags instead of values

Quoted 14 lines

-----Original Message-----
From: Paul Walmsley [mailto:paul at pwsan.com]
Sent: Tuesday, February 08, 2011 7:16 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 v2 3/9] omap4: powerdomain: Use intended PWRSTS_* flags instead of values

Quoted 3 lines · Santosh Shilimkar

IVAHD and ABE power domain logic state is populated using directly value instead of the capability flags.

Quoted 8 lines
Quoted 4 lines

Fix the same.

This was getting generated due to a bug 'gen_logicst' macro in powerdomain autogen script bug which is fixed as well.

Should we try to get this one into the -rc series, since it is a bug-fix ?

Make sense.

maintainer
#12 lore raw

PATCH v2 3/9 omap4: powerdomain: Use intended PWRSTS_* flags instead of values

Quoted 16 lines · Santosh Shilimkar
Quoted 16 lines

-----Original Message-----
From: Paul Walmsley [mailto:paul at pwsan.com]
Sent: Tuesday, February 08, 2011 7:16 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 v2 3/9] omap4: powerdomain: Use intended PWRSTS_* flags instead of values

Quoted 5 lines · Santosh Shilimkar

IVAHD and ABE power domain logic state is populated using directly value instead of the capability flags.

Fix the same.

Quoted 7 lines
Quoted 6 lines
Quoted 2 lines

This was getting generated due to a bug 'gen_logicst' macro in powerdomain autogen script bug which is fixed as well.

Should we try to get this one into the -rc series, since it is a bug-fix ?

Make sense.

Upon further reflection, I don't think that this is needed for 2.6.38-rc, so will queue it for .39 instead.

- Paul

author
#13 lore raw

PATCH v2 4/9 omap: clocks: Add checks to see if enable/disable ops are supported

In reply to Santosh Shilimkar

From: Rajendra Nayak <[email protected]>

Check if enable/disable operations are supported for a given clock node before attempting to call them.

Signed-off-by Rajendra Nayak <[email protected]>
---
 arch/arm/mach-omap2/clock.c |   14 +++++++++-----
 1 files changed, 9 insertions(+), 5 deletions(-)
arch/arm/mach-omap2/clock.c +9 -5
index 2a2f152..5c08c18 100644
@@ -261,7 +261,8 @@ void omap2_clk_disable(struct clk *clk)
 
 	pr_debug("clock: %s: disabling in hardware\n", clk->name);
 
-	clk->ops->disable(clk);
+	if (clk->ops && clk->ops->enable)
+		clk->ops->disable(clk);
 
 	if (clk->clkdm)
 		omap2_clkdm_clk_disable(clk->clkdm, clk);

@@ -312,10 +313,13 @@ int omap2_clk_enable(struct clk *clk)
 		}
 	}
 
-	ret = clk->ops->enable(clk);
-	if (ret) {
-		WARN(1, "clock: %s: could not enable: %d\n", clk->name, ret);
-		goto oce_err3;
+	if (clk->ops && clk->ops->enable) {
+		ret = clk->ops->enable(clk);
+		if (ret) {
+			WARN(1, "clock: %s: could not enable: %d\n",
+			     clk->name, ret);
+			goto oce_err3;
+		}
 	}
 
 	return 0;
Signature · 1 line
1.6.0.4
maintainer
#14 lore raw

PATCH v2 4/9 omap: clocks: Add checks to see if enable/disable ops are supported

Quoted 15 lines · Santosh Shilimkar

From: Rajendra Nayak <[email protected]>

Check if enable/disable operations are supported for a given clock node before attempting to call them.

Signed-off-by Rajendra Nayak <[email protected]>
---
 arch/arm/mach-omap2/clock.c |   14 +++++++++-----
 1 files changed, 9 insertions(+), 5 deletions(-)
arch/arm/mach-omap2/clock.c +0 -0
index 2a2f152..5c08c18 100644

arch/arm/mach-omap2/clock.c void omap2_clk_disable(struct clk *clk) · line 265

Quoted 6 lines
arch/arm/mach-omap2/clock.c +2 -1
@@ -261,7 +261,8 @@ void omap2_clk_disable(struct clk *clk)
 
 	pr_debug("clock: %s: disabling in hardware\n", clk->name);
 
-	clk->ops->disable(clk);
+	if (clk->ops && clk->ops->enable)
+		clk->ops->disable(clk);

Shouldn't that read:

    if (clk->ops && clk->ops->disable)

?

- Paul

#15 lore raw

PATCH v2 4/9 omap: clocks: Add checks to see if enable/disable ops are supported

Quoted 5 lines

-----Original Message-----
From: Paul Walmsley [mailto:paul at pwsan.com]
Sent: Tuesday, February 08, 2011 7:18 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-

Quoted 2 lines

kernel at lists.infradead.org
Subject: Re: [PATCH v2 4/9] omap: clocks: Add checks to see if

enable/disable ops are supported

Quoted 27 lines · Santosh Shilimkar
Quoted 16 lines

From: Rajendra Nayak <[email protected]>

Check if enable/disable operations are supported for a given clock node before attempting to call them.

Signed-off-by Rajendra Nayak <[email protected]>
---
 arch/arm/mach-omap2/clock.c |   14 +++++++++-----
 1 files changed, 9 insertions(+), 5 deletions(-)
arch/arm/mach-omap2/clock.c +0 -0
index 2a2f152..5c08c18 100644

arch/arm/mach-omap2/clock.c void omap2_clk_disable(struct clk *clk) · line 265

Quoted 6 lines
arch/arm/mach-omap2/clock.c +2 -1
@@ -261,7 +261,8 @@ void omap2_clk_disable(struct clk *clk)
 
 	pr_debug("clock: %s: disabling in hardware\n", clk->name);
 
-	clk->ops->disable(clk);
+	if (clk->ops && clk->ops->enable)
+		clk->ops->disable(clk);

Shouldn't that read:

Quoted 3 lines
    if (clk->ops && clk->ops->disable)

?

Oops.. I guess it should. Will fix that and repost.

Quoted 3 lines

- Paul

author
#16 lore raw

PATCH v2 5/9 omap: clocks: Add allow_idle/deny_idle support in clkops

In reply to Santosh Shilimkar

From: Rajendra Nayak <[email protected]>

On OMAP various clock nodes (dpll's, mx post dividers, interface clocks) support hardware level autogating which can be controlled from software.
Support such functionality by adding two new function pointer allow_idle and deny_idle in the clkops structure.

These function pointers can be populated for any clock node which supports hardware level autogating.

Also add 2 new functions (omap_clk_enable_auotidle and omap_clk_disable_autoidle) which can be called from architecture specific PM core code, if hardware level autogating (for all supported clock nodes) is to be enabled or disabled.

Signed-off-by Rajendra Nayak <[email protected]>
---
 arch/arm/plat-omap/clock.c              |   26 ++++++++++++++++++++++++++
 arch/arm/plat-omap/include/plat/clock.h |    6 ++++++
 2 files changed, 32 insertions(+), 0 deletions(-)
arch/arm/plat-omap/clock.c +26 -0
index fc62fb5..6889c5a 100644
@@ -335,6 +335,32 @@ struct clk *omap_clk_get_by_name(const char *name)
 	return ret;
 }
 
+void omap_clk_enable_autoidle(void)
+{
+	struct clk *c;
+
+	mutex_lock(&clocks_mutex);
+
+	list_for_each_entry(c, &clocks, node)
+		if (c->ops->allow_idle)
+			c->ops->allow_idle(c);
+
+	mutex_unlock(&clocks_mutex);
+}
+
+void omap_clk_disable_autoidle(void)
+{
+	struct clk *c;
+
+	mutex_lock(&clocks_mutex);
+
+	list_for_each_entry(c, &clocks, node)
+		if (c->ops->deny_idle)
+			c->ops->deny_idle(c);
+
+	mutex_unlock(&clocks_mutex);
+}
+
 /*
  * Low level helpers
  */
arch/arm/plat-omap/include/plat/clock.h +6 -0
index 8eb0ada..167f1e0 100644
@@ -25,6 +25,8 @@ struct clockdomain;
  * @disable: fn ptr that enables the current clock in hardware
  * @find_idlest: function returning the IDLEST register for the clock's IP blk
  * @find_companion: function returning the "companion" clk reg for the clock
+ * @allow_idle: fn ptr that enables autoidle for the current clock in hardware
+ * @deny_idle: fn ptr that disables autoidle for the current clock in hardware
  *
  * A "companion" clk is an accompanying clock to the one being queried
  * that must be enabled for the IP module connected to the clock to

@@ -42,6 +44,8 @@ struct clkops {
 					       u8 *, u8 *);
 	void			(*find_companion)(struct clk *, void __iomem **,
 						  u8 *);
+	void			(*allow_idle)(struct clk *);
+	void			(*deny_idle)(struct clk *);
 };
 
 #ifdef CONFIG_ARCH_OMAP2PLUS

@@ -292,6 +296,8 @@ extern void clk_init_cpufreq_table(struct cpufreq_frequency_table **table);
 extern void clk_exit_cpufreq_table(struct cpufreq_frequency_table **table);
 #endif
 extern struct clk *omap_clk_get_by_name(const char *name);
+extern void omap_clk_enable_autoidle(void);
+extern void omap_clk_disable_autoidle(void);
 
 extern const struct clkops clkops_null;
Signature · 1 line
1.6.0.4
author
#17 lore raw

PATCH v2 6/9 omap: dpll: Add allow_idle/deny_idle support for all DPLL's

In reply to Santosh Shilimkar

From: Rajendra Nayak <[email protected]>

All OMAP3/4 dpll's support hardware level autogating. Populate allow_idle/deny_idle function pointers for all DPLL's in clkops.

Also for OMAP4, call omap_clk_enable_autoidle() from PM core (only with CONFIG_PM) to enable hardware level autogating on all clock nodes which support it (For now only DPLL nodes)

Signed-off-by Rajendra Nayak <[email protected]>
---
 arch/arm/mach-omap2/clock.c          |    8 +++++++-
 arch/arm/mach-omap2/clock.h          |    1 +
 arch/arm/mach-omap2/clock3xxx_data.c |    2 +-
 arch/arm/mach-omap2/clock44xx_data.c |    2 +-
 arch/arm/mach-omap2/pm44xx.c         |    4 ++++
 5 files changed, 14 insertions(+), 3 deletions(-)
arch/arm/mach-omap2/clock.c +7 -1
index 5c08c18..8ec618e 100644
@@ -377,10 +377,16 @@ int omap2_clk_set_parent(struct clk *clk, struct clk *new_parent)
 const struct clkops clkops_omap3_noncore_dpll_ops = {
 	.enable		= omap3_noncore_dpll_enable,
 	.disable	= omap3_noncore_dpll_disable,
+	.allow_idle	= omap3_dpll_allow_idle,
+	.deny_idle	= omap3_dpll_deny_idle,
 };
 
-#endif
+const struct clkops clkops_omap3_core_dpll_ops = {
+	.allow_idle	= omap3_dpll_allow_idle,
+	.deny_idle	= omap3_dpll_deny_idle,
+};
 
+#endif
 
 /*
  * OMAP2+ clock reset and init functions
arch/arm/mach-omap2/clock.h +1 -0
index 896584e..2a939e5 100644
@@ -146,5 +146,6 @@ extern void omap2_clk_exit_cpufreq_table(struct cpufreq_frequency_table **table)
 #endif
 
 extern const struct clkops clkops_omap3_noncore_dpll_ops;
+extern const struct clkops clkops_omap3_core_dpll_ops;
 
 #endif
arch/arm/mach-omap2/clock3xxx_data.c +1 -1
index 403a4a1..20a7118 100644
@@ -429,7 +429,7 @@ static struct dpll_data dpll3_dd = {
 
 static struct clk dpll3_ck = {
 	.name		= "dpll3_ck",
-	.ops		= &clkops_null,
+	.ops		= &clkops_omap3_core_dpll_ops,
 	.parent		= &sys_ck,
 	.dpll_data	= &dpll3_dd,
 	.round_rate	= &omap2_dpll_round_rate,
arch/arm/mach-omap2/clock44xx_data.c +1 -1
index e8cb32f..3fb8d2b 100644
@@ -444,7 +444,7 @@ static struct clk dpll_core_ck = {
 	.parent		= &sys_clkin_ck,
 	.dpll_data	= &dpll_core_dd,
 	.init		= &omap2_init_dpll_parent,
-	.ops		= &clkops_null,
+	.ops		= &clkops_omap3_core_dpll_ops,
 	.recalc		= &omap3_dpll_recalc,
 };
arch/arm/mach-omap2/pm44xx.c +4 -0
index 76cfff2..8431d41 100644
@@ -15,6 +15,7 @@
 #include <linux/list.h>
 #include <linux/err.h>
 #include <linux/slab.h>
+#include <plat/clock.h>
 
 #include "powerdomain.h"
 #include <mach/omap4-common.h>

@@ -111,6 +112,9 @@ static int __init omap4_pm_init(void)
 		pr_err("Failed to setup powerdomains\n");
 		goto err2;
 	}
+
+	/* Enable autoidle for all clks which support it*/
+	omap_clk_enable_autoidle();
 #endif
 
 #ifdef CONFIG_SUSPEND
Signature · 1 line
1.6.0.4
maintainer
#18 lore raw

PATCH v2 6/9 omap: dpll: Add allow_idle/deny_idle support for all DPLL's

Hi

Quoted 11 lines · Santosh Shilimkar

From: Rajendra Nayak <[email protected]>

All OMAP3/4 dpll's support hardware level autogating. Populate allow_idle/deny_idle function pointers for all DPLL's in clkops.

Also for OMAP4, call omap_clk_enable_autoidle() from PM core (only with CONFIG_PM) to enable hardware level autogating on all clock nodes which support it (For now only DPLL nodes)

Quoted 7 lines
Signed-off-by Rajendra Nayak <[email protected]>
---
 arch/arm/mach-omap2/clock.c          |    8 +++++++-
 arch/arm/mach-omap2/clock.h          |    1 +
 arch/arm/mach-omap2/clock3xxx_data.c |    2 +-
 arch/arm/mach-omap2/clock44xx_data.c |    2 +-
 arch/arm/mach-omap2/pm44xx.c         |    4 ++++

Looks like you add the allow_idle/deny_idle functions for the OMAP3 CORE DPLL, but you don't change mach-omap2/pm34xx.c. Any reason for this? It seems that the current OMAP3 PM code doesn't enable CORE DPLL autoidle. Do you recall why? Perhaps it is due to some of the autoidle bugs, where DPLL3 would enter auto-idle while some OMAP3 IP blocks that used CORE clocks were not idle...

- Paul

#19 lore raw

PATCH v2 6/9 omap: dpll: Add allow_idle/deny_idle support for all DPLL's

Quoted 5 lines

-----Original Message-----
From: Paul Walmsley [mailto:paul at pwsan.com]
Sent: Tuesday, February 08, 2011 8:27 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

Quoted 1 line

Subject: Re: [PATCH v2 6/9] omap: dpll: Add allow_idle/deny_idle support

for all DPLL's

Quoted 24 lines

Hi

Quoted 11 lines · Santosh Shilimkar

From: Rajendra Nayak <[email protected]>

All OMAP3/4 dpll's support hardware level autogating. Populate allow_idle/deny_idle function pointers for all DPLL's in clkops.

Also for OMAP4, call omap_clk_enable_autoidle() from PM core (only with CONFIG_PM) to enable hardware level autogating on all clock nodes which support it (For now only DPLL nodes)

Quoted 7 lines
Signed-off-by Rajendra Nayak <[email protected]>
---
 arch/arm/mach-omap2/clock.c          |    8 +++++++-
 arch/arm/mach-omap2/clock.h          |    1 +
 arch/arm/mach-omap2/clock3xxx_data.c |    2 +-
 arch/arm/mach-omap2/clock44xx_data.c |    2 +-
 arch/arm/mach-omap2/pm44xx.c         |    4 ++++
Quoted 2 lines

Looks like you add the allow_idle/deny_idle functions for the OMAP3 CORE DPLL, but you don't change mach-omap2/pm34xx.c. Any reason for this?

Nothing specifically. My initial patchset was enabling these only for OMAP4,
So I thought will keep it that way.

Quoted 3 lines

It
seems that the current OMAP3 PM code doesn't enable CORE DPLL autoidle. Do you recall why? Perhaps it is due to some of the autoidle bugs,

where

Quoted 2 lines

DPLL3 would enter auto-idle while some OMAP3 IP blocks that used CORE clocks were not idle...

I don't recall any such bug, however I will relook at the errata docs and also
do some validation around this on OMAP3 and report.

Regards,
Rajendra

Quoted 3 lines

- Paul

maintainer
#20 lore raw

PATCH v2 6/9 omap: dpll: Add allow_idle/deny_idle support for all DPLL's

Quoted 10 lines · Rajendra Nayak
Quoted 10 lines

-----Original Message-----
From: Paul Walmsley [mailto:paul at pwsan.com]
Sent: Tuesday, February 08, 2011 8:27 AM

Quoted 5 lines
 arch/arm/mach-omap2/clock.c          |    8 +++++++-
 arch/arm/mach-omap2/clock.h          |    1 +
 arch/arm/mach-omap2/clock3xxx_data.c |    2 +-
 arch/arm/mach-omap2/clock44xx_data.c |    2 +-
 arch/arm/mach-omap2/pm44xx.c         |    4 ++++
Quoted 5 lines
Quoted 2 lines

Looks like you add the allow_idle/deny_idle functions for the OMAP3 CORE DPLL, but you don't change mach-omap2/pm34xx.c. Any reason for this?

Nothing specifically. My initial patchset was enabling these only for OMAP4, So I thought will keep it that way.

That's fine with me, but you might want to drop the OMAP3 part of the changes, or put them into a separate patch.

Also, when you resend the autoidle patches, could you put them into a separate series? There's an autoidle series that I've been working on here, and I will add those into that series, and keep the other patch series separate.

thanks,

- Paul

#21 lore raw

PATCH v2 6/9 omap: dpll: Add allow_idle/deny_idle support for all DPLL's

Quoted 5 lines

-----Original Message-----
From: Paul Walmsley [mailto:paul at pwsan.com]
Sent: Tuesday, February 08, 2011 9:11 AM
To: Rajendra Nayak
Cc: Santosh Shilimkar; linux-omap at vger.kernel.org; Kevin Hilman; Benoit

Cousson; linux-arm-

Quoted 2 lines

kernel at lists.infradead.org
Subject: RE: [PATCH v2 6/9] omap: dpll: Add allow_idle/deny_idle support

for all DPLL's

Quoted 7 lines · Rajendra Nayak
Quoted 5 lines
Quoted 5 lines

-----Original Message-----
From: Paul Walmsley [mailto:paul at pwsan.com]
Sent: Tuesday, February 08, 2011 8:27 AM

Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 5 lines
 arch/arm/mach-omap2/clock.c          |    8 +++++++-
 arch/arm/mach-omap2/clock.h          |    1 +
 arch/arm/mach-omap2/clock3xxx_data.c |    2 +-
 arch/arm/mach-omap2/clock44xx_data.c |    2 +-
 arch/arm/mach-omap2/pm44xx.c         |    4 ++++

Looks like you add the allow_idle/deny_idle functions for the OMAP3

CORE

Quoted 1 line
Quoted 1 line
Quoted 1 line

DPLL, but you don't change mach-omap2/pm34xx.c. Any reason for

this?

Quoted 6 lines
Quoted 3 lines

Nothing specifically. My initial patchset was enabling these only for OMAP4, So I thought will keep it that way.

That's fine with me, but you might want to drop the OMAP3 part of the changes, or put them into a separate patch.

Ok, will add a separate patch for OMAP3 and remove the register writes from mach-omap2/pm34xx.c.

Quoted 5 lines

Also, when you resend the autoidle patches, could you put them into a separate series? There's an autoidle series that I've been working on here, and I will add those into that series, and keep the other patch series separate.

Ok, will repost these patches as a separate series.

Regards,
Rajendra

Quoted 5 lines

thanks,

- Paul

maintainer
#22 lore raw

PATCH v2 6/9 omap: dpll: Add allow_idle/deny_idle support for all DPLL's

In reply to Paul Walmsley
Quoted 3 lines · Paul Walmsley

Looks like you add the allow_idle/deny_idle functions for the OMAP3 CORE DPLL, but you don't change mach-omap2/pm34xx.c. Any reason for this? It seems that the current OMAP3 PM code doesn't enable CORE DPLL autoidle.

Never mind - as Rajendra pointed out via private E-mail, that is done along with the PER DPLL autoidle in pm34xx.c. So, the original patch is okay in this regard.

- Paul

author
#23 lore raw

PATCH v2 7/9 omap4: dpll: Add dpll api to control GATE_CTRL

In reply to Santosh Shilimkar

From: Rajendra Nayak <[email protected]>

On OMAP4, the dpll post divider outputs (MX outputs) provide a way to allow/deny hardware level autogating. 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 for these dpll mx postdividers.

NOTE: The gatectrl bit set to 0 allows gatectrl, and the bit set to 1 denies gatectrl.

Signed-off-by Rajendra Nayak <[email protected]>
---
 arch/arm/mach-omap2/clock.h    |    3 ++
 arch/arm/mach-omap2/dpll3xxx.c |   42 ++++++++++++++++++++++++++++++++++++++++
 2 files changed, 45 insertions(+), 0 deletions(-)
arch/arm/mach-omap2/clock.h +3 -0
index 2a939e5..c450d69 100644
@@ -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);
arch/arm/mach-omap2/dpll3xxx.c +42 -0

51 lines not on this page · raw message

Signature · 1 line
1.6.0.4
author
#24 lore raw

PATCH v2 8/9 omap4: dpll: Enable auto gate control for all MX postdividers

In reply to Santosh Shilimkar

From: Rajendra Nayak <[email protected]>

Enable hardware gate control for all dpll MX postdividers. This requires the allow_idle/deny_idle functions to be populated for all clock nodes (mx post dividers) in clkops.

The autogen script is updated for the same.

Signed-off-by Rajendra Nayak <[email protected]>
---
 arch/arm/mach-omap2/clock.c          |    5 ++++
 arch/arm/mach-omap2/clock.h          |    1 +
 arch/arm/mach-omap2/clock44xx_data.c |   40 +++++++++++++++++-----------------
 3 files changed, 26 insertions(+), 20 deletions(-)
arch/arm/mach-omap2/clock.c +5 -0
index 8ec618e..73a2886 100644
@@ -388,6 +388,11 @@ const struct clkops clkops_omap3_core_dpll_ops = {
 
 #endif
 
+const struct clkops clkops_omap4_dpllmx_ops = {
+	.allow_idle	= omap4_dpllmx_allow_gatectrl,
+	.deny_idle	= omap4_dpllmx_deny_gatectrl,
+};
+
 /*
  * OMAP2+ clock reset and init functions
  */
arch/arm/mach-omap2/clock.h +1 -0
index c450d69..0725a6a 100644
@@ -150,5 +150,6 @@ extern void omap2_clk_exit_cpufreq_table(struct cpufreq_frequency_table **table)
 
 extern const struct clkops clkops_omap3_noncore_dpll_ops;
 extern const struct clkops clkops_omap3_core_dpll_ops;
+extern const struct clkops clkops_omap4_dpllmx_ops;
 
 #endif
arch/arm/mach-omap2/clock44xx_data.c +20 -20
index 3fb8d2b..3ca47ae 100644
@@ -329,7 +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,
-	.ops		= &clkops_null,
+	.ops		= &clkops_omap4_dpllmx_ops,
 	.recalc		= &omap2_clksel_recalc,
 	.round_rate	= &omap2_clksel_round_rate,
 	.set_rate	= &omap2_clksel_set_rate,

@@ -396,7 +396,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,
-	.ops		= &clkops_null,
+	.ops		= &clkops_omap4_dpllmx_ops,
 	.recalc		= &omap2_clksel_recalc,
 	.round_rate	= &omap2_clksel_round_rate,
 	.set_rate	= &omap2_clksel_set_rate,

@@ -466,7 +466,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,
-	.ops		= &clkops_null,
+	.ops		= &clkops_omap4_dpllmx_ops,
 	.recalc		= &omap2_clksel_recalc,
 	.round_rate	= &omap2_clksel_round_rate,
 	.set_rate	= &omap2_clksel_set_rate,

@@ -496,7 +496,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,
-	.ops		= &clkops_null,
+	.ops		= &clkops_omap4_dpllmx_ops,
 	.recalc		= &omap2_clksel_recalc,
 	.round_rate	= &omap2_clksel_round_rate,
 	.set_rate	= &omap2_clksel_set_rate,

@@ -516,7 +516,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,
-	.ops		= &clkops_null,
+	.ops		= &clkops_omap4_dpllmx_ops,
 	.recalc		= &omap2_clksel_recalc,
 	.round_rate	= &omap2_clksel_round_rate,
 	.set_rate	= &omap2_clksel_set_rate,

@@ -582,7 +582,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,
-	.ops		= &clkops_null,
+	.ops		= &clkops_omap4_dpllmx_ops,
 	.recalc		= &omap2_clksel_recalc,
 	.round_rate	= &omap2_clksel_round_rate,
 	.set_rate	= &omap2_clksel_set_rate,

@@ -607,7 +607,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,
-	.ops		= &clkops_null,
+	.ops		= &clkops_omap4_dpllmx_ops,
 	.recalc		= &omap2_clksel_recalc,
 	.round_rate	= &omap2_clksel_round_rate,
 	.set_rate	= &omap2_clksel_set_rate,

@@ -633,7 +633,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,
-	.ops		= &clkops_null,
+	.ops		= &clkops_omap4_dpllmx_ops,
 	.recalc		= &omap2_clksel_recalc,
 	.round_rate	= &omap2_clksel_round_rate,
 	.set_rate	= &omap2_clksel_set_rate,

@@ -705,7 +705,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,
-	.ops		= &clkops_null,
+	.ops		= &clkops_omap4_dpllmx_ops,
 	.recalc		= &omap2_clksel_recalc,
 	.round_rate	= &omap2_clksel_round_rate,
 	.set_rate	= &omap2_clksel_set_rate,

@@ -717,7 +717,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,
-	.ops		= &clkops_null,
+	.ops		= &clkops_omap4_dpllmx_ops,
 	.recalc		= &omap2_clksel_recalc,
 	.round_rate	= &omap2_clksel_round_rate,
 	.set_rate	= &omap2_clksel_set_rate,

@@ -765,7 +765,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,
-	.ops		= &clkops_null,
+	.ops		= &clkops_omap4_dpllmx_ops,
 	.recalc		= &omap2_clksel_recalc,
 	.round_rate	= &omap2_clksel_round_rate,
 	.set_rate	= &omap2_clksel_set_rate,

@@ -838,7 +838,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,
-	.ops		= &clkops_null,
+	.ops		= &clkops_omap4_dpllmx_ops,
 	.recalc		= &omap2_clksel_recalc,
 	.round_rate	= &omap2_clksel_round_rate,
 	.set_rate	= &omap2_clksel_set_rate,

@@ -862,7 +862,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,
-	.ops		= &clkops_null,
+	.ops		= &clkops_omap4_dpllmx_ops,
 	.recalc		= &omap2_clksel_recalc,
 	.round_rate	= &omap2_clksel_round_rate,
 	.set_rate	= &omap2_clksel_set_rate,

@@ -888,7 +888,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,
-	.ops		= &clkops_null,
+	.ops		= &clkops_omap4_dpllmx_ops,
 	.recalc		= &omap2_clksel_recalc,
 	.round_rate	= &omap2_clksel_round_rate,
 	.set_rate	= &omap2_clksel_set_rate,

@@ -900,7 +900,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,
-	.ops		= &clkops_null,
+	.ops		= &clkops_omap4_dpllmx_ops,
 	.recalc		= &omap2_clksel_recalc,
 	.round_rate	= &omap2_clksel_round_rate,
 	.set_rate	= &omap2_clksel_set_rate,

@@ -912,7 +912,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,
-	.ops		= &clkops_null,
+	.ops		= &clkops_omap4_dpllmx_ops,
 	.recalc		= &omap2_clksel_recalc,
 	.round_rate	= &omap2_clksel_round_rate,
 	.set_rate	= &omap2_clksel_set_rate,

@@ -924,7 +924,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,
-	.ops		= &clkops_null,
+	.ops		= &clkops_omap4_dpllmx_ops,
 	.recalc		= &omap2_clksel_recalc,
 	.round_rate	= &omap2_clksel_round_rate,
 	.set_rate	= &omap2_clksel_set_rate,

@@ -980,7 +980,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,
-	.ops		= &clkops_null,
+	.ops		= &clkops_omap4_dpllmx_ops,
 	.recalc		= &omap2_clksel_recalc,
 	.round_rate	= &omap2_clksel_round_rate,
 	.set_rate	= &omap2_clksel_set_rate,

@@ -1029,7 +1029,7 @@ static struct clk dpll_usb_ck = {
 static struct clk dpll_usb_clkdcoldo_ck = {
 	.name		= "dpll_usb_clkdcoldo_ck",
 	.parent		= &dpll_usb_ck,
-	.ops		= &clkops_null,
+	.ops		= &clkops_omap4_dpllmx_ops,
 	.recalc		= &followparent_recalc,
 };
 

@@ -1044,7 +1044,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,
-	.ops		= &clkops_null,
+	.ops		= &clkops_omap4_dpllmx_ops,
 	.recalc		= &omap2_clksel_recalc,
 	.round_rate	= &omap2_clksel_round_rate,
 	.set_rate	= &omap2_clksel_set_rate,
Signature · 1 line
1.6.0.4
author
#25 lore raw

PATCH v2 9/9 omap4: clockdomain: Fix the CPUx domain name

In reply to Santosh Shilimkar

From: Benoit Cousson <[email protected]>

The register naming convention for clock domain control inside power domain instance is:
OMAPXXXX_<partition>_<power_domain>_<clock_domain>_CDOFFS

Both CPU0 and CPU1 use MPU as clock domain name instead of CPU0 and CPU1.

Change the name to stick to the convention.
The autogen scripts are updated accordingly.

Signed-off-by Benoit Cousson <[email protected]>
Signed-off-by Santosh Shilimkar <[email protected]>
Cc Paul Walmsley <[email protected]>
Cc Rajendra Nayak <[email protected]>
---
 arch/arm/mach-omap2/clockdomains44xx_data.c |    4 ++--
 arch/arm/mach-omap2/prcm_mpu44xx.h          |    4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)
arch/arm/mach-omap2/clockdomains44xx_data.c +2 -2
index 51920fc..db1f442 100644
@@ -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),
 };
arch/arm/mach-omap2/prcm_mpu44xx.h +2 -2
index 3300ff6..d22d1b4 100644
@@ -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
 
 
 /*
Signature · 1 line
1.6.0.4
maintainer
#26 lore raw

PATCH v2 9/9 omap4: clockdomain: Fix the CPUx domain name

Quoted 9 lines · Santosh Shilimkar

From: Benoit Cousson <[email protected]>

The register naming convention for clock domain control inside power domain instance is:
OMAPXXXX_<partition>_<power_domain>_<clock_domain>_CDOFFS

Both CPU0 and CPU1 use MPU as clock domain name instead of CPU0 and CPU1.

Quoted 7 lines

Change the name to stick to the convention.
The autogen scripts are updated accordingly.

Signed-off-by Benoit Cousson <[email protected]>
Signed-off-by Santosh Shilimkar <[email protected]>
Cc Paul Walmsley <[email protected]>
Cc Rajendra Nayak <[email protected]>

Thanks, queued for 2.6.39 in the 'pwrdm_clkdm_b_2.6.39' branch of
git://git.pwsan.com/linux-2.6 (along with patch 2/9).

- Paul