* [PATCH v2 1/9] omap4: powerdomain: Add supported INACTIVE power state
2011-02-04 9:58 [PATCH v2 0/9] omap4: prcm: Few dpll, clockdomain and powerdomain updates Santosh Shilimkar
@ 2011-02-04 9:58 ` Santosh Shilimkar
2011-02-06 20:42 ` Paul Walmsley
2011-02-04 9:58 ` [PATCH v2 2/9] omap4: prcm: Fix the CPUx clockdomain offsets Santosh Shilimkar
` (7 subsequent siblings)
8 siblings, 1 reply; 27+ messages in thread
From: Santosh Shilimkar @ 2011-02-04 9:58 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.
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 <santosh.shilimkar@ti.com>
Cc: Rajendra Nayak <rnayak@ti.com>
Cc: Benoit Cousson <b-cousson@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] 27+ messages in thread* [PATCH v2 1/9] omap4: powerdomain: Add supported INACTIVE power state
2011-02-04 9:58 ` [PATCH v2 1/9] omap4: powerdomain: Add supported INACTIVE power state Santosh Shilimkar
@ 2011-02-06 20:42 ` Paul Walmsley
2011-02-07 7:03 ` Santosh Shilimkar
0 siblings, 1 reply; 27+ messages in thread
From: Paul Walmsley @ 2011-02-06 20:42 UTC (permalink / raw)
To: linux-arm-kernel
Hi
On Fri, 4 Feb 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.
>
> 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
^ permalink raw reply [flat|nested] 27+ messages in thread
* [PATCH v2 1/9] omap4: powerdomain: Add supported INACTIVE power state
2011-02-06 20:42 ` Paul Walmsley
@ 2011-02-07 7:03 ` Santosh Shilimkar
2011-02-08 1:32 ` Paul Walmsley
0 siblings, 1 reply; 27+ messages in thread
From: Santosh Shilimkar @ 2011-02-07 7:03 UTC (permalink / raw)
To: linux-arm-kernel
> -----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
>
> On Fri, 4 Feb 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.
> >
> > 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)
>
Actually it's not new state but more of convention change. ON-ACTIVE
is like ON in OMAP3.
> 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.
> 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
^ permalink raw reply [flat|nested] 27+ messages in thread
* [PATCH v2 1/9] omap4: powerdomain: Add supported INACTIVE power state
2011-02-07 7:03 ` Santosh Shilimkar
@ 2011-02-08 1:32 ` Paul Walmsley
2011-02-08 6:41 ` Santosh Shilimkar
0 siblings, 1 reply; 27+ messages in thread
From: Paul Walmsley @ 2011-02-08 1:32 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, 7 Feb 2011, Santosh Shilimkar wrote:
> > -----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
> > 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?
> > 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.
>
> > 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.
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
^ permalink raw reply [flat|nested] 27+ messages in thread
* [PATCH v2 1/9] omap4: powerdomain: Add supported INACTIVE power state
2011-02-08 1:32 ` Paul Walmsley
@ 2011-02-08 6:41 ` Santosh Shilimkar
0 siblings, 0 replies; 27+ messages in thread
From: Santosh Shilimkar @ 2011-02-08 6:41 UTC (permalink / raw)
To: linux-arm-kernel
> -----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
>
> On Mon, 7 Feb 2011, Santosh Shilimkar wrote:
>
> > > -----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
> > > 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?
>
You have point. And you are absolutely 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?
>
> > > 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.
> >
> > > 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.
>
> 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.
> 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.
> 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.
>
Sounds right approach.
Regards,
Santosh
^ permalink raw reply [flat|nested] 27+ messages in thread
* [PATCH v2 2/9] omap4: prcm: Fix the CPUx clockdomain offsets
2011-02-04 9:58 [PATCH v2 0/9] omap4: prcm: Few dpll, clockdomain and powerdomain updates Santosh Shilimkar
2011-02-04 9:58 ` [PATCH v2 1/9] omap4: powerdomain: Add supported INACTIVE power state Santosh Shilimkar
@ 2011-02-04 9:58 ` Santosh Shilimkar
2011-02-08 4:55 ` Paul Walmsley
2011-02-25 20:07 ` Paul Walmsley
2011-02-04 9:58 ` [PATCH v2 3/9] omap4: powerdomain: Use intended PWRSTS_* flags instead of values Santosh Shilimkar
` (6 subsequent siblings)
8 siblings, 2 replies; 27+ messages in thread
From: Santosh Shilimkar @ 2011-02-04 9:58 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.
The autogen scripts is fixed thanks to Benoit Cousson
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Rajendra Nayak <rnayak@ti.com>
Cc: Benoit Cousson <b-cousson@ti.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] 27+ messages in thread* [PATCH v2 2/9] omap4: prcm: Fix the CPUx clockdomain offsets
2011-02-04 9:58 ` [PATCH v2 2/9] omap4: prcm: Fix the CPUx clockdomain offsets Santosh Shilimkar
@ 2011-02-08 4:55 ` Paul Walmsley
2011-02-25 20:07 ` Paul Walmsley
1 sibling, 0 replies; 27+ messages in thread
From: Paul Walmsley @ 2011-02-08 4:55 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, 4 Feb 2011, Santosh Shilimkar wrote:
> 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 <santosh.shilimkar@ti.com>
> Cc: Paul Walmsley <paul@pwsan.com>
> Cc: Rajendra Nayak <rnayak@ti.com>
> Cc: Benoit Cousson <b-cousson@ti.com>
Thanks, queued for 2.6.39.
- Paul
^ permalink raw reply [flat|nested] 27+ messages in thread
* [PATCH v2 2/9] omap4: prcm: Fix the CPUx clockdomain offsets
2011-02-04 9:58 ` [PATCH v2 2/9] omap4: prcm: Fix the CPUx clockdomain offsets Santosh Shilimkar
2011-02-08 4:55 ` Paul Walmsley
@ 2011-02-25 20:07 ` Paul Walmsley
1 sibling, 0 replies; 27+ messages in thread
From: Paul Walmsley @ 2011-02-25 20:07 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, 4 Feb 2011, Santosh Shilimkar wrote:
> 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 <santosh.shilimkar@ti.com>
> Cc: Paul Walmsley <paul@pwsan.com>
> Cc: Rajendra Nayak <rnayak@ti.com>
> Cc: Benoit Cousson <b-cousson@ti.com>
Will submit this one for -rc series, since this could result in writes to
an incorrect register. Updated patch below.
- Paul
From: Santosh Shilimkar <santosh.shilimkar@ti.com>
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 <santosh.shilimkar@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Rajendra Nayak <rnayak@ti.com>
Cc: Benoit Cousson <b-cousson@ti.com>
[paul at pwsan.com: added second paragraph to commit message]
Signed-off-by: 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.7.2.3
^ permalink raw reply related [flat|nested] 27+ messages in thread
* [PATCH v2 3/9] omap4: powerdomain: Use intended PWRSTS_* flags instead of values
2011-02-04 9:58 [PATCH v2 0/9] omap4: prcm: Few dpll, clockdomain and powerdomain updates Santosh Shilimkar
2011-02-04 9:58 ` [PATCH v2 1/9] omap4: powerdomain: Add supported INACTIVE power state Santosh Shilimkar
2011-02-04 9:58 ` [PATCH v2 2/9] omap4: prcm: Fix the CPUx clockdomain offsets Santosh Shilimkar
@ 2011-02-04 9:58 ` Santosh Shilimkar
2011-02-08 1:45 ` Paul Walmsley
2011-02-04 9:58 ` [PATCH v2 4/9] omap: clocks: Add checks to see if enable/disable ops are supported Santosh Shilimkar
` (5 subsequent siblings)
8 siblings, 1 reply; 27+ messages in thread
From: Santosh Shilimkar @ 2011-02-04 9:58 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.
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 <santosh.shilimkar@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Rajendra Nayak <rnayak@ti.com>
Cc: Benoit Cousson <b-cousson@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] 27+ messages in thread* [PATCH v2 3/9] omap4: powerdomain: Use intended PWRSTS_* flags instead of values
2011-02-04 9:58 ` [PATCH v2 3/9] omap4: powerdomain: Use intended PWRSTS_* flags instead of values Santosh Shilimkar
@ 2011-02-08 1:45 ` Paul Walmsley
2011-02-08 6:37 ` Santosh Shilimkar
0 siblings, 1 reply; 27+ messages in thread
From: Paul Walmsley @ 2011-02-08 1:45 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, 4 Feb 2011, Santosh Shilimkar wrote:
> 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
^ permalink raw reply [flat|nested] 27+ messages in thread
* [PATCH v2 3/9] omap4: powerdomain: Use intended PWRSTS_* flags instead of values
2011-02-08 1:45 ` Paul Walmsley
@ 2011-02-08 6:37 ` Santosh Shilimkar
2011-02-25 20:10 ` Paul Walmsley
0 siblings, 1 reply; 27+ messages in thread
From: Santosh Shilimkar @ 2011-02-08 6:37 UTC (permalink / raw)
To: linux-arm-kernel
> -----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
>
> On Fri, 4 Feb 2011, Santosh Shilimkar wrote:
>
> > 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 ?
>
Make sense.
^ permalink raw reply [flat|nested] 27+ messages in thread
* [PATCH v2 3/9] omap4: powerdomain: Use intended PWRSTS_* flags instead of values
2011-02-08 6:37 ` Santosh Shilimkar
@ 2011-02-25 20:10 ` Paul Walmsley
0 siblings, 0 replies; 27+ messages in thread
From: Paul Walmsley @ 2011-02-25 20:10 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, 8 Feb 2011, Santosh Shilimkar wrote:
> > -----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
> >
> > On Fri, 4 Feb 2011, Santosh Shilimkar wrote:
> >
> > > 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 ?
> >
> 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
^ permalink raw reply [flat|nested] 27+ messages in thread
* [PATCH v2 4/9] omap: clocks: Add checks to see if enable/disable ops are supported
2011-02-04 9:58 [PATCH v2 0/9] omap4: prcm: Few dpll, clockdomain and powerdomain updates Santosh Shilimkar
` (2 preceding siblings ...)
2011-02-04 9:58 ` [PATCH v2 3/9] omap4: powerdomain: Use intended PWRSTS_* flags instead of values Santosh Shilimkar
@ 2011-02-04 9:58 ` Santosh Shilimkar
2011-02-08 1:48 ` Paul Walmsley
2011-02-04 9:59 ` [PATCH v2 5/9] omap: clocks: Add allow_idle/deny_idle support in clkops Santosh Shilimkar
` (4 subsequent siblings)
8 siblings, 1 reply; 27+ messages in thread
From: Santosh Shilimkar @ 2011-02-04 9:58 UTC (permalink / raw)
To: linux-arm-kernel
From: Rajendra Nayak <rnayak@ti.com>
Check if enable/disable operations are supported for a given
clock node before attempting to call them.
Signed-off-by: Rajendra Nayak <rnayak@ti.com>
---
arch/arm/mach-omap2/clock.c | 14 +++++++++-----
1 files changed, 9 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap2/clock.c b/arch/arm/mach-omap2/clock.c
index 2a2f152..5c08c18 100644
--- a/arch/arm/mach-omap2/clock.c
+++ b/arch/arm/mach-omap2/clock.c
@@ -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;
--
1.6.0.4
^ permalink raw reply related [flat|nested] 27+ messages in thread* [PATCH v2 4/9] omap: clocks: Add checks to see if enable/disable ops are supported
2011-02-04 9:58 ` [PATCH v2 4/9] omap: clocks: Add checks to see if enable/disable ops are supported Santosh Shilimkar
@ 2011-02-08 1:48 ` Paul Walmsley
2011-02-08 3:25 ` Rajendra Nayak
0 siblings, 1 reply; 27+ messages in thread
From: Paul Walmsley @ 2011-02-08 1:48 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, 4 Feb 2011, Santosh Shilimkar wrote:
> From: Rajendra Nayak <rnayak@ti.com>
>
> Check if enable/disable operations are supported for a given
> clock node before attempting to call them.
>
> Signed-off-by: Rajendra Nayak <rnayak@ti.com>
> ---
> arch/arm/mach-omap2/clock.c | 14 +++++++++-----
> 1 files changed, 9 insertions(+), 5 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/clock.c b/arch/arm/mach-omap2/clock.c
> index 2a2f152..5c08c18 100644
> --- a/arch/arm/mach-omap2/clock.c
> +++ b/arch/arm/mach-omap2/clock.c
> @@ -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
^ permalink raw reply [flat|nested] 27+ messages in thread* [PATCH v2 4/9] omap: clocks: Add checks to see if enable/disable ops are supported
2011-02-08 1:48 ` Paul Walmsley
@ 2011-02-08 3:25 ` Rajendra Nayak
0 siblings, 0 replies; 27+ messages in thread
From: Rajendra Nayak @ 2011-02-08 3:25 UTC (permalink / raw)
To: linux-arm-kernel
> -----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-
> kernel at lists.infradead.org
> Subject: Re: [PATCH v2 4/9] omap: clocks: Add checks to see if
enable/disable ops are supported
>
> On Fri, 4 Feb 2011, Santosh Shilimkar wrote:
>
> > From: Rajendra Nayak <rnayak@ti.com>
> >
> > Check if enable/disable operations are supported for a given
> > clock node before attempting to call them.
> >
> > Signed-off-by: Rajendra Nayak <rnayak@ti.com>
> > ---
> > arch/arm/mach-omap2/clock.c | 14 +++++++++-----
> > 1 files changed, 9 insertions(+), 5 deletions(-)
> >
> > diff --git a/arch/arm/mach-omap2/clock.c b/arch/arm/mach-omap2/clock.c
> > index 2a2f152..5c08c18 100644
> > --- a/arch/arm/mach-omap2/clock.c
> > +++ b/arch/arm/mach-omap2/clock.c
> > @@ -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)
>
> ?
Oops.. I guess it should. Will fix that and repost.
>
>
> - Paul
^ permalink raw reply [flat|nested] 27+ messages in thread
* [PATCH v2 5/9] omap: clocks: Add allow_idle/deny_idle support in clkops
2011-02-04 9:58 [PATCH v2 0/9] omap4: prcm: Few dpll, clockdomain and powerdomain updates Santosh Shilimkar
` (3 preceding siblings ...)
2011-02-04 9:58 ` [PATCH v2 4/9] omap: clocks: Add checks to see if enable/disable ops are supported Santosh Shilimkar
@ 2011-02-04 9:59 ` Santosh Shilimkar
2011-02-04 9:59 ` [PATCH v2 6/9] omap: dpll: Add allow_idle/deny_idle support for all DPLL's Santosh Shilimkar
` (3 subsequent siblings)
8 siblings, 0 replies; 27+ messages in thread
From: Santosh Shilimkar @ 2011-02-04 9:59 UTC (permalink / raw)
To: linux-arm-kernel
From: Rajendra Nayak <rnayak@ti.com>
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 <rnayak@ti.com>
---
arch/arm/plat-omap/clock.c | 26 ++++++++++++++++++++++++++
arch/arm/plat-omap/include/plat/clock.h | 6 ++++++
2 files changed, 32 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-omap/clock.c b/arch/arm/plat-omap/clock.c
index fc62fb5..6889c5a 100644
--- a/arch/arm/plat-omap/clock.c
+++ b/arch/arm/plat-omap/clock.c
@@ -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
*/
diff --git a/arch/arm/plat-omap/include/plat/clock.h b/arch/arm/plat-omap/include/plat/clock.h
index 8eb0ada..167f1e0 100644
--- a/arch/arm/plat-omap/include/plat/clock.h
+++ b/arch/arm/plat-omap/include/plat/clock.h
@@ -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;
--
1.6.0.4
^ permalink raw reply related [flat|nested] 27+ messages in thread* [PATCH v2 6/9] omap: dpll: Add allow_idle/deny_idle support for all DPLL's
2011-02-04 9:58 [PATCH v2 0/9] omap4: prcm: Few dpll, clockdomain and powerdomain updates Santosh Shilimkar
` (4 preceding siblings ...)
2011-02-04 9:59 ` [PATCH v2 5/9] omap: clocks: Add allow_idle/deny_idle support in clkops Santosh Shilimkar
@ 2011-02-04 9:59 ` Santosh Shilimkar
2011-02-08 2:57 ` Paul Walmsley
2011-02-04 9:59 ` [PATCH v2 7/9] omap4: dpll: Add dpll api to control GATE_CTRL Santosh Shilimkar
` (2 subsequent siblings)
8 siblings, 1 reply; 27+ messages in thread
From: Santosh Shilimkar @ 2011-02-04 9:59 UTC (permalink / raw)
To: linux-arm-kernel
From: Rajendra Nayak <rnayak@ti.com>
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 <rnayak@ti.com>
---
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(-)
diff --git a/arch/arm/mach-omap2/clock.c b/arch/arm/mach-omap2/clock.c
index 5c08c18..8ec618e 100644
--- a/arch/arm/mach-omap2/clock.c
+++ b/arch/arm/mach-omap2/clock.c
@@ -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
diff --git a/arch/arm/mach-omap2/clock.h b/arch/arm/mach-omap2/clock.h
index 896584e..2a939e5 100644
--- a/arch/arm/mach-omap2/clock.h
+++ b/arch/arm/mach-omap2/clock.h
@@ -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
diff --git a/arch/arm/mach-omap2/clock3xxx_data.c b/arch/arm/mach-omap2/clock3xxx_data.c
index 403a4a1..20a7118 100644
--- a/arch/arm/mach-omap2/clock3xxx_data.c
+++ b/arch/arm/mach-omap2/clock3xxx_data.c
@@ -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,
diff --git a/arch/arm/mach-omap2/clock44xx_data.c b/arch/arm/mach-omap2/clock44xx_data.c
index e8cb32f..3fb8d2b 100644
--- a/arch/arm/mach-omap2/clock44xx_data.c
+++ b/arch/arm/mach-omap2/clock44xx_data.c
@@ -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,
};
diff --git a/arch/arm/mach-omap2/pm44xx.c b/arch/arm/mach-omap2/pm44xx.c
index 76cfff2..8431d41 100644
--- a/arch/arm/mach-omap2/pm44xx.c
+++ b/arch/arm/mach-omap2/pm44xx.c
@@ -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
--
1.6.0.4
^ permalink raw reply related [flat|nested] 27+ messages in thread* [PATCH v2 6/9] omap: dpll: Add allow_idle/deny_idle support for all DPLL's
2011-02-04 9:59 ` [PATCH v2 6/9] omap: dpll: Add allow_idle/deny_idle support for all DPLL's Santosh Shilimkar
@ 2011-02-08 2:57 ` Paul Walmsley
2011-02-08 3:28 ` Rajendra Nayak
2011-02-08 4:16 ` Paul Walmsley
0 siblings, 2 replies; 27+ messages in thread
From: Paul Walmsley @ 2011-02-08 2:57 UTC (permalink / raw)
To: linux-arm-kernel
Hi
On Fri, 4 Feb 2011, Santosh Shilimkar wrote:
> From: Rajendra Nayak <rnayak@ti.com>
>
> 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 <rnayak@ti.com>
> ---
> 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
^ permalink raw reply [flat|nested] 27+ messages in thread
* [PATCH v2 6/9] omap: dpll: Add allow_idle/deny_idle support for all DPLL's
2011-02-08 2:57 ` Paul Walmsley
@ 2011-02-08 3:28 ` Rajendra Nayak
2011-02-08 3:40 ` Paul Walmsley
2011-02-08 4:16 ` Paul Walmsley
1 sibling, 1 reply; 27+ messages in thread
From: Rajendra Nayak @ 2011-02-08 3:28 UTC (permalink / raw)
To: linux-arm-kernel
> -----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
> Subject: Re: [PATCH v2 6/9] omap: dpll: Add allow_idle/deny_idle support
for all DPLL's
>
> Hi
>
> On Fri, 4 Feb 2011, Santosh Shilimkar wrote:
>
> > From: Rajendra Nayak <rnayak@ti.com>
> >
> > 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 <rnayak@ti.com>
> > ---
> > 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?
Nothing specifically. My initial patchset was enabling these only for
OMAP4,
So I thought will keep it that way.
> 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...
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
>
>
> - Paul
^ permalink raw reply [flat|nested] 27+ messages in thread
* [PATCH v2 6/9] omap: dpll: Add allow_idle/deny_idle support for all DPLL's
2011-02-08 3:28 ` Rajendra Nayak
@ 2011-02-08 3:40 ` Paul Walmsley
2011-02-08 4:17 ` Rajendra Nayak
0 siblings, 1 reply; 27+ messages in thread
From: Paul Walmsley @ 2011-02-08 3:40 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, 8 Feb 2011, Rajendra Nayak wrote:
> > -----Original Message-----
> > From: Paul Walmsley [mailto:paul at pwsan.com]
> > Sent: Tuesday, February 08, 2011 8:27 AM
> >
> > > 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?
>
> 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
^ permalink raw reply [flat|nested] 27+ messages in thread
* [PATCH v2 6/9] omap: dpll: Add allow_idle/deny_idle support for all DPLL's
2011-02-08 3:40 ` Paul Walmsley
@ 2011-02-08 4:17 ` Rajendra Nayak
0 siblings, 0 replies; 27+ messages in thread
From: Rajendra Nayak @ 2011-02-08 4:17 UTC (permalink / raw)
To: linux-arm-kernel
> -----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-
> kernel at lists.infradead.org
> Subject: RE: [PATCH v2 6/9] omap: dpll: Add allow_idle/deny_idle support
for all DPLL's
>
> On Tue, 8 Feb 2011, Rajendra Nayak wrote:
>
> > > -----Original Message-----
> > > From: Paul Walmsley [mailto:paul at pwsan.com]
> > > Sent: Tuesday, February 08, 2011 8:27 AM
> > >
> > > > 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?
> >
> > 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.
>
> 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
>
>
> thanks,
>
> - Paul
^ permalink raw reply [flat|nested] 27+ messages in thread
* [PATCH v2 6/9] omap: dpll: Add allow_idle/deny_idle support for all DPLL's
2011-02-08 2:57 ` Paul Walmsley
2011-02-08 3:28 ` Rajendra Nayak
@ 2011-02-08 4:16 ` Paul Walmsley
1 sibling, 0 replies; 27+ messages in thread
From: Paul Walmsley @ 2011-02-08 4:16 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, 7 Feb 2011, Paul Walmsley wrote:
> 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
^ permalink raw reply [flat|nested] 27+ messages in thread
* [PATCH v2 7/9] omap4: dpll: Add dpll api to control GATE_CTRL
2011-02-04 9:58 [PATCH v2 0/9] omap4: prcm: Few dpll, clockdomain and powerdomain updates Santosh Shilimkar
` (5 preceding siblings ...)
2011-02-04 9:59 ` [PATCH v2 6/9] omap: dpll: Add allow_idle/deny_idle support for all DPLL's Santosh Shilimkar
@ 2011-02-04 9:59 ` Santosh Shilimkar
2011-02-04 9:59 ` [PATCH v2 8/9] omap4: dpll: Enable auto gate control for all MX postdividers Santosh Shilimkar
2011-02-04 9:59 ` [PATCH v2 9/9] omap4: clockdomain: Fix the CPUx domain name Santosh Shilimkar
8 siblings, 0 replies; 27+ messages in thread
From: Santosh Shilimkar @ 2011-02-04 9:59 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 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 <rnayak@ti.com>
---
arch/arm/mach-omap2/clock.h | 3 ++
arch/arm/mach-omap2/dpll3xxx.c | 42 ++++++++++++++++++++++++++++++++++++++++
2 files changed, 45 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/clock.h b/arch/arm/mach-omap2/clock.h
index 2a939e5..c450d69 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..4571e94 100644
--- a/arch/arm/mach-omap2/dpll3xxx.c
+++ b/arch/arm/mach-omap2/dpll3xxx.c
@@ -34,6 +34,7 @@
#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
@@ -612,3 +613,44 @@ unsigned long omap3_clkoutx2_recalc(struct clk *clk)
rate = clk->parent->rate * 2;
return rate;
}
+
+/* Supported only on OMAP4 */
+int omap4_dpllmx_gatectrl_read(struct clk *clk)
+{
+ u32 v;
+
+ if (!clk || !clk->clksel_reg || !cpu_is_omap44xx())
+ 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->clksel_reg || !cpu_is_omap44xx())
+ return;
+
+ v = __raw_readl(clk->clksel_reg);
+ /* Clear the bit to allow gatectrl */
+ v &= ~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->clksel_reg || !cpu_is_omap44xx())
+ return;
+
+ v = __raw_readl(clk->clksel_reg);
+ /* Set the bit to deny gatectrl */
+ v |= OMAP4430_DPLL_CLKOUT_GATE_CTRL_MASK;
+ __raw_writel(v, clk->clksel_reg);
+}
--
1.6.0.4
^ permalink raw reply related [flat|nested] 27+ messages in thread* [PATCH v2 8/9] omap4: dpll: Enable auto gate control for all MX postdividers
2011-02-04 9:58 [PATCH v2 0/9] omap4: prcm: Few dpll, clockdomain and powerdomain updates Santosh Shilimkar
` (6 preceding siblings ...)
2011-02-04 9:59 ` [PATCH v2 7/9] omap4: dpll: Add dpll api to control GATE_CTRL Santosh Shilimkar
@ 2011-02-04 9:59 ` Santosh Shilimkar
2011-02-04 9:59 ` [PATCH v2 9/9] omap4: clockdomain: Fix the CPUx domain name Santosh Shilimkar
8 siblings, 0 replies; 27+ messages in thread
From: Santosh Shilimkar @ 2011-02-04 9:59 UTC (permalink / raw)
To: linux-arm-kernel
From: Rajendra Nayak <rnayak@ti.com>
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 <rnayak@ti.com>
---
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(-)
diff --git a/arch/arm/mach-omap2/clock.c b/arch/arm/mach-omap2/clock.c
index 8ec618e..73a2886 100644
--- a/arch/arm/mach-omap2/clock.c
+++ b/arch/arm/mach-omap2/clock.c
@@ -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
*/
diff --git a/arch/arm/mach-omap2/clock.h b/arch/arm/mach-omap2/clock.h
index c450d69..0725a6a 100644
--- a/arch/arm/mach-omap2/clock.h
+++ b/arch/arm/mach-omap2/clock.h
@@ -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
diff --git a/arch/arm/mach-omap2/clock44xx_data.c b/arch/arm/mach-omap2/clock44xx_data.c
index 3fb8d2b..3ca47ae 100644
--- a/arch/arm/mach-omap2/clock44xx_data.c
+++ b/arch/arm/mach-omap2/clock44xx_data.c
@@ -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,
--
1.6.0.4
^ permalink raw reply related [flat|nested] 27+ messages in thread* [PATCH v2 9/9] omap4: clockdomain: Fix the CPUx domain name
2011-02-04 9:58 [PATCH v2 0/9] omap4: prcm: Few dpll, clockdomain and powerdomain updates Santosh Shilimkar
` (7 preceding siblings ...)
2011-02-04 9:59 ` [PATCH v2 8/9] omap4: dpll: Enable auto gate control for all MX postdividers Santosh Shilimkar
@ 2011-02-04 9:59 ` Santosh Shilimkar
2011-02-08 4:58 ` Paul Walmsley
8 siblings, 1 reply; 27+ messages in thread
From: Santosh Shilimkar @ 2011-02-04 9:59 UTC (permalink / raw)
To: linux-arm-kernel
From: Benoit Cousson <b-cousson@ti.com>
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 <b-cousson@ti.com>
Signed-off-by: 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.6.0.4
^ permalink raw reply related [flat|nested] 27+ messages in thread* [PATCH v2 9/9] omap4: clockdomain: Fix the CPUx domain name
2011-02-04 9:59 ` [PATCH v2 9/9] omap4: clockdomain: Fix the CPUx domain name Santosh Shilimkar
@ 2011-02-08 4:58 ` Paul Walmsley
0 siblings, 0 replies; 27+ messages in thread
From: Paul Walmsley @ 2011-02-08 4:58 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, 4 Feb 2011, Santosh Shilimkar wrote:
> From: Benoit Cousson <b-cousson@ti.com>
>
> 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 <b-cousson@ti.com>
> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
> Cc: Paul Walmsley <paul@pwsan.com>
> Cc: Rajendra Nayak <rnayak@ti.com>
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
^ permalink raw reply [flat|nested] 27+ messages in thread