[PATCHv3 0/4] ARM: OMAP4: core retention support

[PATCHv3 0/4] ARM: OMAP4: core retention support

[Tero Kristo]

Hi,

Changes compared to previous version:

- split out the io_chain set as a separate set
- marked patch 3 as TEMP, this is only needed until Paul's pwrdm fixes
  get merged (http://marc.info/?l=linux-omap&m=133040749621183&w=2)

Depends on the io_chain set to provide wakeup capability from
retention.

Tested with omap4430 blaze : suspend / resume works okay.

-Tero

[PATCHv3 0/4] ARM: OMAP4: core retention support

[Tero Kristo]

Hi,

Changes compared to previous version:

- split out the io_chain set as a separate set
- marked patch 3 as TEMP, this is only needed until Paul's pwrdm fixes
  get merged (http://marc.info/?l=linux-omap&m=133040749621183&w=2)

Depends on the io_chain set to provide wakeup capability from
retention.

Tested with omap4430 blaze : suspend / resume works okay.

-Tero

[PATCHv3 1/4] ARM: OMAP4: suspend: Program all domains to retention

[Tero Kristo]

From: Rajendra Nayak <rnayak@ti.com>

Remove the FIXME's in the suspend sequence since
we now intend to support system level RET support.

Signed-off-by: Rajendra Nayak <rnayak@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Reviewed-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
---
 arch/arm/mach-omap2/pm44xx.c |    6 ------
 1 files changed, 0 insertions(+), 6 deletions(-)

diff --git a/arch/arm/mach-omap2/pm44xx.c b/arch/arm/mach-omap2/pm44xx.c
index c264ef7..1ab30a3 100644
--- a/arch/arm/mach-omap2/pm44xx.c
+++ b/arch/arm/mach-omap2/pm44xx.c
@@ -151,12 +151,6 @@ static int __init pwrdms_setup(struct powerdomain *pwrdm, void *unused)
 	if (!strncmp(pwrdm->name, "cpu", 3))
 		return 0;
 
-	/*
-	 * FIXME: Remove this check when core retention is supported
-	 * Only MPUSS power domain is added in the list.
-	 */
-	if (strcmp(pwrdm->name, "mpu_pwrdm"))
-		return 0;
 
 	pwrst = kmalloc(sizeof(struct power_state), GFP_ATOMIC);
 	if (!pwrst)
-- 
1.7.4.1

[PATCHv3 1/4] ARM: OMAP4: suspend: Program all domains to retention

[Tero Kristo]

From: Rajendra Nayak <rnayak@ti.com>

Remove the FIXME's in the suspend sequence since
we now intend to support system level RET support.

Signed-off-by: Rajendra Nayak <rnayak@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Reviewed-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
---
 arch/arm/mach-omap2/pm44xx.c |    6 ------
 1 files changed, 0 insertions(+), 6 deletions(-)

diff --git a/arch/arm/mach-omap2/pm44xx.c b/arch/arm/mach-omap2/pm44xx.c
index c264ef7..1ab30a3 100644
--- a/arch/arm/mach-omap2/pm44xx.c
+++ b/arch/arm/mach-omap2/pm44xx.c
@@ -151,12 +151,6 @@ static int __init pwrdms_setup(struct powerdomain *pwrdm, void *unused)
 	if (!strncmp(pwrdm->name, "cpu", 3))
 		return 0;
 
-	/*
-	 * FIXME: Remove this check when core retention is supported
-	 * Only MPUSS power domain is added in the list.
-	 */
-	if (strcmp(pwrdm->name, "mpu_pwrdm"))
-		return 0;
 
 	pwrst = kmalloc(sizeof(struct power_state), GFP_ATOMIC);
 	if (!pwrst)
-- 
1.7.4.1

Re: [PATCHv3 1/4] ARM: OMAP4: suspend: Program all domains to retention

[Kevin Hilman]

Tero Kristo <t-kristo@ti.com> writes:

> From: Rajendra Nayak <rnayak@ti.com>
>
> Remove the FIXME's in the suspend sequence since
> we now intend to support system level RET support.
>
> Signed-off-by: Rajendra Nayak <rnayak@ti.com>
> Signed-off-by: Tero Kristo <t-kristo@ti.com>
> Reviewed-by: Santosh Shilimkar <santosh.shilimkar@ti.com>

So this is the only patch in this series that is still needed.  However...

It doesn't seem like this all by itself is ready for mainline as we'll
suddenly start putting all powerdomains in retention without any
additional support.

I guess at a minimum it needs working IO wakeup support from the IO
daisy chain series.  Are there other dependencies here?

If not, I can queue this when Paul is ready to merge the IO wakeup
stuff.

Kevin

> ---
>  arch/arm/mach-omap2/pm44xx.c |    6 ------
>  1 files changed, 0 insertions(+), 6 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/pm44xx.c b/arch/arm/mach-omap2/pm44xx.c
> index c264ef7..1ab30a3 100644
> --- a/arch/arm/mach-omap2/pm44xx.c
> +++ b/arch/arm/mach-omap2/pm44xx.c
> @@ -151,12 +151,6 @@ static int __init pwrdms_setup(struct powerdomain *pwrdm, void *unused)
>  	if (!strncmp(pwrdm->name, "cpu", 3))
>  		return 0;
>  
> -	/*
> -	 * FIXME: Remove this check when core retention is supported
> -	 * Only MPUSS power domain is added in the list.
> -	 */
> -	if (strcmp(pwrdm->name, "mpu_pwrdm"))
> -		return 0;
>  
>  	pwrst = kmalloc(sizeof(struct power_state), GFP_ATOMIC);
>  	if (!pwrst)

[PATCHv3 1/4] ARM: OMAP4: suspend: Program all domains to retention

[Kevin Hilman]

Tero Kristo <t-kristo@ti.com> writes:

> From: Rajendra Nayak <rnayak@ti.com>
>
> Remove the FIXME's in the suspend sequence since
> we now intend to support system level RET support.
>
> Signed-off-by: Rajendra Nayak <rnayak@ti.com>
> Signed-off-by: Tero Kristo <t-kristo@ti.com>
> Reviewed-by: Santosh Shilimkar <santosh.shilimkar@ti.com>

So this is the only patch in this series that is still needed.  However...

It doesn't seem like this all by itself is ready for mainline as we'll
suddenly start putting all powerdomains in retention without any
additional support.

I guess at a minimum it needs working IO wakeup support from the IO
daisy chain series.  Are there other dependencies here?

If not, I can queue this when Paul is ready to merge the IO wakeup
stuff.

Kevin

> ---
>  arch/arm/mach-omap2/pm44xx.c |    6 ------
>  1 files changed, 0 insertions(+), 6 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/pm44xx.c b/arch/arm/mach-omap2/pm44xx.c
> index c264ef7..1ab30a3 100644
> --- a/arch/arm/mach-omap2/pm44xx.c
> +++ b/arch/arm/mach-omap2/pm44xx.c
> @@ -151,12 +151,6 @@ static int __init pwrdms_setup(struct powerdomain *pwrdm, void *unused)
>  	if (!strncmp(pwrdm->name, "cpu", 3))
>  		return 0;
>  
> -	/*
> -	 * FIXME: Remove this check when core retention is supported
> -	 * Only MPUSS power domain is added in the list.
> -	 */
> -	if (strcmp(pwrdm->name, "mpu_pwrdm"))
> -		return 0;
>  
>  	pwrst = kmalloc(sizeof(struct power_state), GFP_ATOMIC);
>  	if (!pwrst)

Re: [PATCHv3 1/4] ARM: OMAP4: suspend: Program all domains to retention

[Tero Kristo]

On Mon, 2012-03-05 at 16:33 -0800, Kevin Hilman wrote:
> Tero Kristo <t-kristo@ti.com> writes:
> 
> > From: Rajendra Nayak <rnayak@ti.com>
> >
> > Remove the FIXME's in the suspend sequence since
> > we now intend to support system level RET support.
> >
> > Signed-off-by: Rajendra Nayak <rnayak@ti.com>
> > Signed-off-by: Tero Kristo <t-kristo@ti.com>
> > Reviewed-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
> 
> So this is the only patch in this series that is still needed.  However...
> 
> It doesn't seem like this all by itself is ready for mainline as we'll
> suddenly start putting all powerdomains in retention without any
> additional support.
>
> I guess at a minimum it needs working IO wakeup support from the IO
> daisy chain series.  Are there other dependencies here?

Only IO chain is needed for wakeup capability. Actually even with the
current mainline kernel, I am unable to wake-up the device from MPU
retention, as there are no wakeup sources. So this patch doesn't really
change the behavior to worse even without any additional patches. :) But
yea, good to wait until IO chain is in.

The other dependencies are that the stuff handled by patches 2,3 and 4
have to be handled somehow:

-patch2: must be in (this patch is queued by Paul)
-patch3: will be taken care of by Paul's pwrdm fixes (I guess this is
queued by Paul himself already)
-patch4: OMAP interrupt count must be increased (this is handled by
Benoit's patch, which is queued by Tony)

-Tero

> 
> If not, I can queue this when Paul is ready to merge the IO wakeup
> stuff.
> 
> Kevin
> 
> > ---
> >  arch/arm/mach-omap2/pm44xx.c |    6 ------
> >  1 files changed, 0 insertions(+), 6 deletions(-)
> >
> > diff --git a/arch/arm/mach-omap2/pm44xx.c b/arch/arm/mach-omap2/pm44xx.c
> > index c264ef7..1ab30a3 100644
> > --- a/arch/arm/mach-omap2/pm44xx.c
> > +++ b/arch/arm/mach-omap2/pm44xx.c
> > @@ -151,12 +151,6 @@ static int __init pwrdms_setup(struct powerdomain *pwrdm, void *unused)
> >  	if (!strncmp(pwrdm->name, "cpu", 3))
> >  		return 0;
> >  
> > -	/*
> > -	 * FIXME: Remove this check when core retention is supported
> > -	 * Only MPUSS power domain is added in the list.
> > -	 */
> > -	if (strcmp(pwrdm->name, "mpu_pwrdm"))
> > -		return 0;
> >  
> >  	pwrst = kmalloc(sizeof(struct power_state), GFP_ATOMIC);
> >  	if (!pwrst)

[PATCHv3 1/4] ARM: OMAP4: suspend: Program all domains to retention

[Tero Kristo]

On Mon, 2012-03-05 at 16:33 -0800, Kevin Hilman wrote:
> Tero Kristo <t-kristo@ti.com> writes:
> 
> > From: Rajendra Nayak <rnayak@ti.com>
> >
> > Remove the FIXME's in the suspend sequence since
> > we now intend to support system level RET support.
> >
> > Signed-off-by: Rajendra Nayak <rnayak@ti.com>
> > Signed-off-by: Tero Kristo <t-kristo@ti.com>
> > Reviewed-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
> 
> So this is the only patch in this series that is still needed.  However...
> 
> It doesn't seem like this all by itself is ready for mainline as we'll
> suddenly start putting all powerdomains in retention without any
> additional support.
>
> I guess at a minimum it needs working IO wakeup support from the IO
> daisy chain series.  Are there other dependencies here?

Only IO chain is needed for wakeup capability. Actually even with the
current mainline kernel, I am unable to wake-up the device from MPU
retention, as there are no wakeup sources. So this patch doesn't really
change the behavior to worse even without any additional patches. :) But
yea, good to wait until IO chain is in.

The other dependencies are that the stuff handled by patches 2,3 and 4
have to be handled somehow:

-patch2: must be in (this patch is queued by Paul)
-patch3: will be taken care of by Paul's pwrdm fixes (I guess this is
queued by Paul himself already)
-patch4: OMAP interrupt count must be increased (this is handled by
Benoit's patch, which is queued by Tony)

-Tero

> 
> If not, I can queue this when Paul is ready to merge the IO wakeup
> stuff.
> 
> Kevin
> 
> > ---
> >  arch/arm/mach-omap2/pm44xx.c |    6 ------
> >  1 files changed, 0 insertions(+), 6 deletions(-)
> >
> > diff --git a/arch/arm/mach-omap2/pm44xx.c b/arch/arm/mach-omap2/pm44xx.c
> > index c264ef7..1ab30a3 100644
> > --- a/arch/arm/mach-omap2/pm44xx.c
> > +++ b/arch/arm/mach-omap2/pm44xx.c
> > @@ -151,12 +151,6 @@ static int __init pwrdms_setup(struct powerdomain *pwrdm, void *unused)
> >  	if (!strncmp(pwrdm->name, "cpu", 3))
> >  		return 0;
> >  
> > -	/*
> > -	 * FIXME: Remove this check when core retention is supported
> > -	 * Only MPUSS power domain is added in the list.
> > -	 */
> > -	if (strcmp(pwrdm->name, "mpu_pwrdm"))
> > -		return 0;
> >  
> >  	pwrst = kmalloc(sizeof(struct power_state), GFP_ATOMIC);
> >  	if (!pwrst)

Re: [PATCHv3 1/4] ARM: OMAP4: suspend: Program all domains to retention

[Rajendra Nayak]

On Tuesday 06 March 2012 02:01 PM, Tero Kristo wrote:
> On Mon, 2012-03-05 at 16:33 -0800, Kevin Hilman wrote:
>> Tero Kristo<t-kristo@ti.com>  writes:
>>
>>> From: Rajendra Nayak<rnayak@ti.com>
>>>
>>> Remove the FIXME's in the suspend sequence since
>>> we now intend to support system level RET support.
>>>
>>> Signed-off-by: Rajendra Nayak<rnayak@ti.com>
>>> Signed-off-by: Tero Kristo<t-kristo@ti.com>
>>> Reviewed-by: Santosh Shilimkar<santosh.shilimkar@ti.com>
>>
>> So this is the only patch in this series that is still needed.  However...
>>
>> It doesn't seem like this all by itself is ready for mainline as we'll
>> suddenly start putting all powerdomains in retention without any
>> additional support.
>>
>> I guess at a minimum it needs working IO wakeup support from the IO
>> daisy chain series.  Are there other dependencies here?
>
> Only IO chain is needed for wakeup capability. Actually even with the
> current mainline kernel, I am unable to wake-up the device from MPU
> retention, as there are no wakeup sources. So this patch doesn't really

Why?, doesn't debug console wakeup work?

> change the behavior to worse even without any additional patches. :) But
> yea, good to wait until IO chain is in.

IO chain, according to documentation :) should be needed only if you
hit OSWR or OFF, async wakeups should be functional as long as you
only hit CSWR.

>
> The other dependencies are that the stuff handled by patches 2,3 and 4
> have to be handled somehow:
>
> -patch2: must be in (this patch is queued by Paul)
> -patch3: will be taken care of by Paul's pwrdm fixes (I guess this is
> queued by Paul himself already)
> -patch4: OMAP interrupt count must be increased (this is handled by
> Benoit's patch, which is queued by Tony)
>
> -Tero
>
>>
>> If not, I can queue this when Paul is ready to merge the IO wakeup
>> stuff.
>>
>> Kevin
>>
>>> ---
>>>   arch/arm/mach-omap2/pm44xx.c |    6 ------
>>>   1 files changed, 0 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/arch/arm/mach-omap2/pm44xx.c b/arch/arm/mach-omap2/pm44xx.c
>>> index c264ef7..1ab30a3 100644
>>> --- a/arch/arm/mach-omap2/pm44xx.c
>>> +++ b/arch/arm/mach-omap2/pm44xx.c
>>> @@ -151,12 +151,6 @@ static int __init pwrdms_setup(struct powerdomain *pwrdm, void *unused)
>>>   	if (!strncmp(pwrdm->name, "cpu", 3))
>>>   		return 0;
>>>
>>> -	/*
>>> -	 * FIXME: Remove this check when core retention is supported
>>> -	 * Only MPUSS power domain is added in the list.
>>> -	 */
>>> -	if (strcmp(pwrdm->name, "mpu_pwrdm"))
>>> -		return 0;
>>>
>>>   	pwrst = kmalloc(sizeof(struct power_state), GFP_ATOMIC);
>>>   	if (!pwrst)
>
>

[PATCHv3 1/4] ARM: OMAP4: suspend: Program all domains to retention

[Rajendra Nayak]

On Tuesday 06 March 2012 02:01 PM, Tero Kristo wrote:
> On Mon, 2012-03-05 at 16:33 -0800, Kevin Hilman wrote:
>> Tero Kristo<t-kristo@ti.com>  writes:
>>
>>> From: Rajendra Nayak<rnayak@ti.com>
>>>
>>> Remove the FIXME's in the suspend sequence since
>>> we now intend to support system level RET support.
>>>
>>> Signed-off-by: Rajendra Nayak<rnayak@ti.com>
>>> Signed-off-by: Tero Kristo<t-kristo@ti.com>
>>> Reviewed-by: Santosh Shilimkar<santosh.shilimkar@ti.com>
>>
>> So this is the only patch in this series that is still needed.  However...
>>
>> It doesn't seem like this all by itself is ready for mainline as we'll
>> suddenly start putting all powerdomains in retention without any
>> additional support.
>>
>> I guess at a minimum it needs working IO wakeup support from the IO
>> daisy chain series.  Are there other dependencies here?
>
> Only IO chain is needed for wakeup capability. Actually even with the
> current mainline kernel, I am unable to wake-up the device from MPU
> retention, as there are no wakeup sources. So this patch doesn't really

Why?, doesn't debug console wakeup work?

> change the behavior to worse even without any additional patches. :) But
> yea, good to wait until IO chain is in.

IO chain, according to documentation :) should be needed only if you
hit OSWR or OFF, async wakeups should be functional as long as you
only hit CSWR.

>
> The other dependencies are that the stuff handled by patches 2,3 and 4
> have to be handled somehow:
>
> -patch2: must be in (this patch is queued by Paul)
> -patch3: will be taken care of by Paul's pwrdm fixes (I guess this is
> queued by Paul himself already)
> -patch4: OMAP interrupt count must be increased (this is handled by
> Benoit's patch, which is queued by Tony)
>
> -Tero
>
>>
>> If not, I can queue this when Paul is ready to merge the IO wakeup
>> stuff.
>>
>> Kevin
>>
>>> ---
>>>   arch/arm/mach-omap2/pm44xx.c |    6 ------
>>>   1 files changed, 0 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/arch/arm/mach-omap2/pm44xx.c b/arch/arm/mach-omap2/pm44xx.c
>>> index c264ef7..1ab30a3 100644
>>> --- a/arch/arm/mach-omap2/pm44xx.c
>>> +++ b/arch/arm/mach-omap2/pm44xx.c
>>> @@ -151,12 +151,6 @@ static int __init pwrdms_setup(struct powerdomain *pwrdm, void *unused)
>>>   	if (!strncmp(pwrdm->name, "cpu", 3))
>>>   		return 0;
>>>
>>> -	/*
>>> -	 * FIXME: Remove this check when core retention is supported
>>> -	 * Only MPUSS power domain is added in the list.
>>> -	 */
>>> -	if (strcmp(pwrdm->name, "mpu_pwrdm"))
>>> -		return 0;
>>>
>>>   	pwrst = kmalloc(sizeof(struct power_state), GFP_ATOMIC);
>>>   	if (!pwrst)
>
>

Re: [PATCHv3 1/4] ARM: OMAP4: suspend: Program all domains to retention

[Tero Kristo]

On Tue, 2012-03-06 at 14:13 +0530, Rajendra Nayak wrote:
> On Tuesday 06 March 2012 02:01 PM, Tero Kristo wrote:
> > On Mon, 2012-03-05 at 16:33 -0800, Kevin Hilman wrote:
> >> Tero Kristo<t-kristo@ti.com>  writes:
> >>
> >>> From: Rajendra Nayak<rnayak@ti.com>
> >>>
> >>> Remove the FIXME's in the suspend sequence since
> >>> we now intend to support system level RET support.
> >>>
> >>> Signed-off-by: Rajendra Nayak<rnayak@ti.com>
> >>> Signed-off-by: Tero Kristo<t-kristo@ti.com>
> >>> Reviewed-by: Santosh Shilimkar<santosh.shilimkar@ti.com>
> >>
> >> So this is the only patch in this series that is still needed.  However...
> >>
> >> It doesn't seem like this all by itself is ready for mainline as we'll
> >> suddenly start putting all powerdomains in retention without any
> >> additional support.
> >>
> >> I guess at a minimum it needs working IO wakeup support from the IO
> >> daisy chain series.  Are there other dependencies here?
> >
> > Only IO chain is needed for wakeup capability. Actually even with the
> > current mainline kernel, I am unable to wake-up the device from MPU
> > retention, as there are no wakeup sources. So this patch doesn't really
> 
> Why?, doesn't debug console wakeup work?

At least I couldn't get it to work. I tried with no_console_suspend
kernel param to no avail. Don't know if I was missing something else.

-Tero

> 
> > change the behavior to worse even without any additional patches. :) But
> > yea, good to wait until IO chain is in.
> 
> IO chain, according to documentation :) should be needed only if you
> hit OSWR or OFF, async wakeups should be functional as long as you
> only hit CSWR.
> 
> >
> > The other dependencies are that the stuff handled by patches 2,3 and 4
> > have to be handled somehow:
> >
> > -patch2: must be in (this patch is queued by Paul)
> > -patch3: will be taken care of by Paul's pwrdm fixes (I guess this is
> > queued by Paul himself already)
> > -patch4: OMAP interrupt count must be increased (this is handled by
> > Benoit's patch, which is queued by Tony)
> >
> > -Tero
> >
> >>
> >> If not, I can queue this when Paul is ready to merge the IO wakeup
> >> stuff.
> >>
> >> Kevin
> >>
> >>> ---
> >>>   arch/arm/mach-omap2/pm44xx.c |    6 ------
> >>>   1 files changed, 0 insertions(+), 6 deletions(-)
> >>>
> >>> diff --git a/arch/arm/mach-omap2/pm44xx.c b/arch/arm/mach-omap2/pm44xx.c
> >>> index c264ef7..1ab30a3 100644
> >>> --- a/arch/arm/mach-omap2/pm44xx.c
> >>> +++ b/arch/arm/mach-omap2/pm44xx.c
> >>> @@ -151,12 +151,6 @@ static int __init pwrdms_setup(struct powerdomain *pwrdm, void *unused)
> >>>   	if (!strncmp(pwrdm->name, "cpu", 3))
> >>>   		return 0;
> >>>
> >>> -	/*
> >>> -	 * FIXME: Remove this check when core retention is supported
> >>> -	 * Only MPUSS power domain is added in the list.
> >>> -	 */
> >>> -	if (strcmp(pwrdm->name, "mpu_pwrdm"))
> >>> -		return 0;
> >>>
> >>>   	pwrst = kmalloc(sizeof(struct power_state), GFP_ATOMIC);
> >>>   	if (!pwrst)
> >
> >
> 

[PATCHv3 1/4] ARM: OMAP4: suspend: Program all domains to retention

[Tero Kristo]

On Tue, 2012-03-06 at 14:13 +0530, Rajendra Nayak wrote:
> On Tuesday 06 March 2012 02:01 PM, Tero Kristo wrote:
> > On Mon, 2012-03-05 at 16:33 -0800, Kevin Hilman wrote:
> >> Tero Kristo<t-kristo@ti.com>  writes:
> >>
> >>> From: Rajendra Nayak<rnayak@ti.com>
> >>>
> >>> Remove the FIXME's in the suspend sequence since
> >>> we now intend to support system level RET support.
> >>>
> >>> Signed-off-by: Rajendra Nayak<rnayak@ti.com>
> >>> Signed-off-by: Tero Kristo<t-kristo@ti.com>
> >>> Reviewed-by: Santosh Shilimkar<santosh.shilimkar@ti.com>
> >>
> >> So this is the only patch in this series that is still needed.  However...
> >>
> >> It doesn't seem like this all by itself is ready for mainline as we'll
> >> suddenly start putting all powerdomains in retention without any
> >> additional support.
> >>
> >> I guess at a minimum it needs working IO wakeup support from the IO
> >> daisy chain series.  Are there other dependencies here?
> >
> > Only IO chain is needed for wakeup capability. Actually even with the
> > current mainline kernel, I am unable to wake-up the device from MPU
> > retention, as there are no wakeup sources. So this patch doesn't really
> 
> Why?, doesn't debug console wakeup work?

At least I couldn't get it to work. I tried with no_console_suspend
kernel param to no avail. Don't know if I was missing something else.

-Tero

> 
> > change the behavior to worse even without any additional patches. :) But
> > yea, good to wait until IO chain is in.
> 
> IO chain, according to documentation :) should be needed only if you
> hit OSWR or OFF, async wakeups should be functional as long as you
> only hit CSWR.
> 
> >
> > The other dependencies are that the stuff handled by patches 2,3 and 4
> > have to be handled somehow:
> >
> > -patch2: must be in (this patch is queued by Paul)
> > -patch3: will be taken care of by Paul's pwrdm fixes (I guess this is
> > queued by Paul himself already)
> > -patch4: OMAP interrupt count must be increased (this is handled by
> > Benoit's patch, which is queued by Tony)
> >
> > -Tero
> >
> >>
> >> If not, I can queue this when Paul is ready to merge the IO wakeup
> >> stuff.
> >>
> >> Kevin
> >>
> >>> ---
> >>>   arch/arm/mach-omap2/pm44xx.c |    6 ------
> >>>   1 files changed, 0 insertions(+), 6 deletions(-)
> >>>
> >>> diff --git a/arch/arm/mach-omap2/pm44xx.c b/arch/arm/mach-omap2/pm44xx.c
> >>> index c264ef7..1ab30a3 100644
> >>> --- a/arch/arm/mach-omap2/pm44xx.c
> >>> +++ b/arch/arm/mach-omap2/pm44xx.c
> >>> @@ -151,12 +151,6 @@ static int __init pwrdms_setup(struct powerdomain *pwrdm, void *unused)
> >>>   	if (!strncmp(pwrdm->name, "cpu", 3))
> >>>   		return 0;
> >>>
> >>> -	/*
> >>> -	 * FIXME: Remove this check when core retention is supported
> >>> -	 * Only MPUSS power domain is added in the list.
> >>> -	 */
> >>> -	if (strcmp(pwrdm->name, "mpu_pwrdm"))
> >>> -		return 0;
> >>>
> >>>   	pwrst = kmalloc(sizeof(struct power_state), GFP_ATOMIC);
> >>>   	if (!pwrst)
> >
> >
> 

Re: [PATCHv3 1/4] ARM: OMAP4: suspend: Program all domains to retention

[Rajendra Nayak]

On Tuesday 06 March 2012 02:24 PM, Tero Kristo wrote:
> On Tue, 2012-03-06 at 14:13 +0530, Rajendra Nayak wrote:
>> On Tuesday 06 March 2012 02:01 PM, Tero Kristo wrote:
>>> On Mon, 2012-03-05 at 16:33 -0800, Kevin Hilman wrote:
>>>> Tero Kristo<t-kristo@ti.com>   writes:
>>>>
>>>>> From: Rajendra Nayak<rnayak@ti.com>
>>>>>
>>>>> Remove the FIXME's in the suspend sequence since
>>>>> we now intend to support system level RET support.
>>>>>
>>>>> Signed-off-by: Rajendra Nayak<rnayak@ti.com>
>>>>> Signed-off-by: Tero Kristo<t-kristo@ti.com>
>>>>> Reviewed-by: Santosh Shilimkar<santosh.shilimkar@ti.com>
>>>>
>>>> So this is the only patch in this series that is still needed.  However...
>>>>
>>>> It doesn't seem like this all by itself is ready for mainline as we'll
>>>> suddenly start putting all powerdomains in retention without any
>>>> additional support.
>>>>
>>>> I guess at a minimum it needs working IO wakeup support from the IO
>>>> daisy chain series.  Are there other dependencies here?
>>>
>>> Only IO chain is needed for wakeup capability. Actually even with the
>>> current mainline kernel, I am unable to wake-up the device from MPU
>>> retention, as there are no wakeup sources. So this patch doesn't really
>>
>> Why?, doesn't debug console wakeup work?
>
> At least I couldn't get it to work. I tried with no_console_suspend
> kernel param to no avail. Don't know if I was missing something else.

Did you try enabling wakeup for the debug console?
echo enabled > /sys/devices/platform/omap/omap_uart.2/tty/ttyO2/power/wakeup

>
> -Tero
>
>>
>>> change the behavior to worse even without any additional patches. :) But
>>> yea, good to wait until IO chain is in.
>>
>> IO chain, according to documentation :) should be needed only if you
>> hit OSWR or OFF, async wakeups should be functional as long as you
>> only hit CSWR.
>>
>>>
>>> The other dependencies are that the stuff handled by patches 2,3 and 4
>>> have to be handled somehow:
>>>
>>> -patch2: must be in (this patch is queued by Paul)
>>> -patch3: will be taken care of by Paul's pwrdm fixes (I guess this is
>>> queued by Paul himself already)
>>> -patch4: OMAP interrupt count must be increased (this is handled by
>>> Benoit's patch, which is queued by Tony)
>>>
>>> -Tero
>>>
>>>>
>>>> If not, I can queue this when Paul is ready to merge the IO wakeup
>>>> stuff.
>>>>
>>>> Kevin
>>>>
>>>>> ---
>>>>>    arch/arm/mach-omap2/pm44xx.c |    6 ------
>>>>>    1 files changed, 0 insertions(+), 6 deletions(-)
>>>>>
>>>>> diff --git a/arch/arm/mach-omap2/pm44xx.c b/arch/arm/mach-omap2/pm44xx.c
>>>>> index c264ef7..1ab30a3 100644
>>>>> --- a/arch/arm/mach-omap2/pm44xx.c
>>>>> +++ b/arch/arm/mach-omap2/pm44xx.c
>>>>> @@ -151,12 +151,6 @@ static int __init pwrdms_setup(struct powerdomain *pwrdm, void *unused)
>>>>>    	if (!strncmp(pwrdm->name, "cpu", 3))
>>>>>    		return 0;
>>>>>
>>>>> -	/*
>>>>> -	 * FIXME: Remove this check when core retention is supported
>>>>> -	 * Only MPUSS power domain is added in the list.
>>>>> -	 */
>>>>> -	if (strcmp(pwrdm->name, "mpu_pwrdm"))
>>>>> -		return 0;
>>>>>
>>>>>    	pwrst = kmalloc(sizeof(struct power_state), GFP_ATOMIC);
>>>>>    	if (!pwrst)
>>>
>>>
>>
>
>

[PATCHv3 1/4] ARM: OMAP4: suspend: Program all domains to retention

[Rajendra Nayak]

On Tuesday 06 March 2012 02:24 PM, Tero Kristo wrote:
> On Tue, 2012-03-06 at 14:13 +0530, Rajendra Nayak wrote:
>> On Tuesday 06 March 2012 02:01 PM, Tero Kristo wrote:
>>> On Mon, 2012-03-05 at 16:33 -0800, Kevin Hilman wrote:
>>>> Tero Kristo<t-kristo@ti.com>   writes:
>>>>
>>>>> From: Rajendra Nayak<rnayak@ti.com>
>>>>>
>>>>> Remove the FIXME's in the suspend sequence since
>>>>> we now intend to support system level RET support.
>>>>>
>>>>> Signed-off-by: Rajendra Nayak<rnayak@ti.com>
>>>>> Signed-off-by: Tero Kristo<t-kristo@ti.com>
>>>>> Reviewed-by: Santosh Shilimkar<santosh.shilimkar@ti.com>
>>>>
>>>> So this is the only patch in this series that is still needed.  However...
>>>>
>>>> It doesn't seem like this all by itself is ready for mainline as we'll
>>>> suddenly start putting all powerdomains in retention without any
>>>> additional support.
>>>>
>>>> I guess at a minimum it needs working IO wakeup support from the IO
>>>> daisy chain series.  Are there other dependencies here?
>>>
>>> Only IO chain is needed for wakeup capability. Actually even with the
>>> current mainline kernel, I am unable to wake-up the device from MPU
>>> retention, as there are no wakeup sources. So this patch doesn't really
>>
>> Why?, doesn't debug console wakeup work?
>
> At least I couldn't get it to work. I tried with no_console_suspend
> kernel param to no avail. Don't know if I was missing something else.

Did you try enabling wakeup for the debug console?
echo enabled > /sys/devices/platform/omap/omap_uart.2/tty/ttyO2/power/wakeup

>
> -Tero
>
>>
>>> change the behavior to worse even without any additional patches. :) But
>>> yea, good to wait until IO chain is in.
>>
>> IO chain, according to documentation :) should be needed only if you
>> hit OSWR or OFF, async wakeups should be functional as long as you
>> only hit CSWR.
>>
>>>
>>> The other dependencies are that the stuff handled by patches 2,3 and 4
>>> have to be handled somehow:
>>>
>>> -patch2: must be in (this patch is queued by Paul)
>>> -patch3: will be taken care of by Paul's pwrdm fixes (I guess this is
>>> queued by Paul himself already)
>>> -patch4: OMAP interrupt count must be increased (this is handled by
>>> Benoit's patch, which is queued by Tony)
>>>
>>> -Tero
>>>
>>>>
>>>> If not, I can queue this when Paul is ready to merge the IO wakeup
>>>> stuff.
>>>>
>>>> Kevin
>>>>
>>>>> ---
>>>>>    arch/arm/mach-omap2/pm44xx.c |    6 ------
>>>>>    1 files changed, 0 insertions(+), 6 deletions(-)
>>>>>
>>>>> diff --git a/arch/arm/mach-omap2/pm44xx.c b/arch/arm/mach-omap2/pm44xx.c
>>>>> index c264ef7..1ab30a3 100644
>>>>> --- a/arch/arm/mach-omap2/pm44xx.c
>>>>> +++ b/arch/arm/mach-omap2/pm44xx.c
>>>>> @@ -151,12 +151,6 @@ static int __init pwrdms_setup(struct powerdomain *pwrdm, void *unused)
>>>>>    	if (!strncmp(pwrdm->name, "cpu", 3))
>>>>>    		return 0;
>>>>>
>>>>> -	/*
>>>>> -	 * FIXME: Remove this check when core retention is supported
>>>>> -	 * Only MPUSS power domain is added in the list.
>>>>> -	 */
>>>>> -	if (strcmp(pwrdm->name, "mpu_pwrdm"))
>>>>> -		return 0;
>>>>>
>>>>>    	pwrst = kmalloc(sizeof(struct power_state), GFP_ATOMIC);
>>>>>    	if (!pwrst)
>>>
>>>
>>
>
>

Re: [PATCHv3 1/4] ARM: OMAP4: suspend: Program all domains to retention

[Tero Kristo]

On Tue, 2012-03-06 at 14:29 +0530, Rajendra Nayak wrote:
> On Tuesday 06 March 2012 02:24 PM, Tero Kristo wrote:
> > On Tue, 2012-03-06 at 14:13 +0530, Rajendra Nayak wrote:
> >> On Tuesday 06 March 2012 02:01 PM, Tero Kristo wrote:
> >>> On Mon, 2012-03-05 at 16:33 -0800, Kevin Hilman wrote:
> >>>> Tero Kristo<t-kristo@ti.com>   writes:
> >>>>
> >>>>> From: Rajendra Nayak<rnayak@ti.com>
> >>>>>
> >>>>> Remove the FIXME's in the suspend sequence since
> >>>>> we now intend to support system level RET support.
> >>>>>
> >>>>> Signed-off-by: Rajendra Nayak<rnayak@ti.com>
> >>>>> Signed-off-by: Tero Kristo<t-kristo@ti.com>
> >>>>> Reviewed-by: Santosh Shilimkar<santosh.shilimkar@ti.com>
> >>>>
> >>>> So this is the only patch in this series that is still needed.  However...
> >>>>
> >>>> It doesn't seem like this all by itself is ready for mainline as we'll
> >>>> suddenly start putting all powerdomains in retention without any
> >>>> additional support.
> >>>>
> >>>> I guess at a minimum it needs working IO wakeup support from the IO
> >>>> daisy chain series.  Are there other dependencies here?
> >>>
> >>> Only IO chain is needed for wakeup capability. Actually even with the
> >>> current mainline kernel, I am unable to wake-up the device from MPU
> >>> retention, as there are no wakeup sources. So this patch doesn't really
> >>
> >> Why?, doesn't debug console wakeup work?
> >
> > At least I couldn't get it to work. I tried with no_console_suspend
> > kernel param to no avail. Don't know if I was missing something else.
> 
> Did you try enabling wakeup for the debug console?
> echo enabled > /sys/devices/platform/omap/omap_uart.2/tty/ttyO2/power/wakeup

I think not, however I wonder why the wakeups are not enabled by default
if this helps?

> 
> >
> > -Tero
> >
> >>
> >>> change the behavior to worse even without any additional patches. :) But
> >>> yea, good to wait until IO chain is in.
> >>
> >> IO chain, according to documentation :) should be needed only if you
> >> hit OSWR or OFF, async wakeups should be functional as long as you
> >> only hit CSWR.
> >>
> >>>
> >>> The other dependencies are that the stuff handled by patches 2,3 and 4
> >>> have to be handled somehow:
> >>>
> >>> -patch2: must be in (this patch is queued by Paul)
> >>> -patch3: will be taken care of by Paul's pwrdm fixes (I guess this is
> >>> queued by Paul himself already)
> >>> -patch4: OMAP interrupt count must be increased (this is handled by
> >>> Benoit's patch, which is queued by Tony)
> >>>
> >>> -Tero
> >>>
> >>>>
> >>>> If not, I can queue this when Paul is ready to merge the IO wakeup
> >>>> stuff.
> >>>>
> >>>> Kevin
> >>>>
> >>>>> ---
> >>>>>    arch/arm/mach-omap2/pm44xx.c |    6 ------
> >>>>>    1 files changed, 0 insertions(+), 6 deletions(-)
> >>>>>
> >>>>> diff --git a/arch/arm/mach-omap2/pm44xx.c b/arch/arm/mach-omap2/pm44xx.c
> >>>>> index c264ef7..1ab30a3 100644
> >>>>> --- a/arch/arm/mach-omap2/pm44xx.c
> >>>>> +++ b/arch/arm/mach-omap2/pm44xx.c
> >>>>> @@ -151,12 +151,6 @@ static int __init pwrdms_setup(struct powerdomain *pwrdm, void *unused)
> >>>>>    	if (!strncmp(pwrdm->name, "cpu", 3))
> >>>>>    		return 0;
> >>>>>
> >>>>> -	/*
> >>>>> -	 * FIXME: Remove this check when core retention is supported
> >>>>> -	 * Only MPUSS power domain is added in the list.
> >>>>> -	 */
> >>>>> -	if (strcmp(pwrdm->name, "mpu_pwrdm"))
> >>>>> -		return 0;
> >>>>>
> >>>>>    	pwrst = kmalloc(sizeof(struct power_state), GFP_ATOMIC);
> >>>>>    	if (!pwrst)
> >>>
> >>>
> >>
> >
> >
> 

[PATCHv3 1/4] ARM: OMAP4: suspend: Program all domains to retention

[Tero Kristo]

On Tue, 2012-03-06 at 14:29 +0530, Rajendra Nayak wrote:
> On Tuesday 06 March 2012 02:24 PM, Tero Kristo wrote:
> > On Tue, 2012-03-06 at 14:13 +0530, Rajendra Nayak wrote:
> >> On Tuesday 06 March 2012 02:01 PM, Tero Kristo wrote:
> >>> On Mon, 2012-03-05 at 16:33 -0800, Kevin Hilman wrote:
> >>>> Tero Kristo<t-kristo@ti.com>   writes:
> >>>>
> >>>>> From: Rajendra Nayak<rnayak@ti.com>
> >>>>>
> >>>>> Remove the FIXME's in the suspend sequence since
> >>>>> we now intend to support system level RET support.
> >>>>>
> >>>>> Signed-off-by: Rajendra Nayak<rnayak@ti.com>
> >>>>> Signed-off-by: Tero Kristo<t-kristo@ti.com>
> >>>>> Reviewed-by: Santosh Shilimkar<santosh.shilimkar@ti.com>
> >>>>
> >>>> So this is the only patch in this series that is still needed.  However...
> >>>>
> >>>> It doesn't seem like this all by itself is ready for mainline as we'll
> >>>> suddenly start putting all powerdomains in retention without any
> >>>> additional support.
> >>>>
> >>>> I guess at a minimum it needs working IO wakeup support from the IO
> >>>> daisy chain series.  Are there other dependencies here?
> >>>
> >>> Only IO chain is needed for wakeup capability. Actually even with the
> >>> current mainline kernel, I am unable to wake-up the device from MPU
> >>> retention, as there are no wakeup sources. So this patch doesn't really
> >>
> >> Why?, doesn't debug console wakeup work?
> >
> > At least I couldn't get it to work. I tried with no_console_suspend
> > kernel param to no avail. Don't know if I was missing something else.
> 
> Did you try enabling wakeup for the debug console?
> echo enabled > /sys/devices/platform/omap/omap_uart.2/tty/ttyO2/power/wakeup

I think not, however I wonder why the wakeups are not enabled by default
if this helps?

> 
> >
> > -Tero
> >
> >>
> >>> change the behavior to worse even without any additional patches. :) But
> >>> yea, good to wait until IO chain is in.
> >>
> >> IO chain, according to documentation :) should be needed only if you
> >> hit OSWR or OFF, async wakeups should be functional as long as you
> >> only hit CSWR.
> >>
> >>>
> >>> The other dependencies are that the stuff handled by patches 2,3 and 4
> >>> have to be handled somehow:
> >>>
> >>> -patch2: must be in (this patch is queued by Paul)
> >>> -patch3: will be taken care of by Paul's pwrdm fixes (I guess this is
> >>> queued by Paul himself already)
> >>> -patch4: OMAP interrupt count must be increased (this is handled by
> >>> Benoit's patch, which is queued by Tony)
> >>>
> >>> -Tero
> >>>
> >>>>
> >>>> If not, I can queue this when Paul is ready to merge the IO wakeup
> >>>> stuff.
> >>>>
> >>>> Kevin
> >>>>
> >>>>> ---
> >>>>>    arch/arm/mach-omap2/pm44xx.c |    6 ------
> >>>>>    1 files changed, 0 insertions(+), 6 deletions(-)
> >>>>>
> >>>>> diff --git a/arch/arm/mach-omap2/pm44xx.c b/arch/arm/mach-omap2/pm44xx.c
> >>>>> index c264ef7..1ab30a3 100644
> >>>>> --- a/arch/arm/mach-omap2/pm44xx.c
> >>>>> +++ b/arch/arm/mach-omap2/pm44xx.c
> >>>>> @@ -151,12 +151,6 @@ static int __init pwrdms_setup(struct powerdomain *pwrdm, void *unused)
> >>>>>    	if (!strncmp(pwrdm->name, "cpu", 3))
> >>>>>    		return 0;
> >>>>>
> >>>>> -	/*
> >>>>> -	 * FIXME: Remove this check when core retention is supported
> >>>>> -	 * Only MPUSS power domain is added in the list.
> >>>>> -	 */
> >>>>> -	if (strcmp(pwrdm->name, "mpu_pwrdm"))
> >>>>> -		return 0;
> >>>>>
> >>>>>    	pwrst = kmalloc(sizeof(struct power_state), GFP_ATOMIC);
> >>>>>    	if (!pwrst)
> >>>
> >>>
> >>
> >
> >
> 

[PATCHv3 2/4] ARM: OMAP4: prm: fix interrupt register offsets

[Tero Kristo]

Previous code used wrong instance for the interrupt register access.
Use the right one which is OCP_SOCKET.

Signed-off-by: Tero Kristo <t-kristo@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
---
 arch/arm/mach-omap2/prm44xx.c |   21 +++++++++++----------
 1 files changed, 11 insertions(+), 10 deletions(-)

diff --git a/arch/arm/mach-omap2/prm44xx.c b/arch/arm/mach-omap2/prm44xx.c
index a931f8f..caa5e0f 100644
--- a/arch/arm/mach-omap2/prm44xx.c
+++ b/arch/arm/mach-omap2/prm44xx.c
@@ -145,8 +145,9 @@ static inline u32 _read_pending_irq_reg(u16 irqen_offs, u16 irqst_offs)
 	u32 mask, st;
 
 	/* XXX read mask from RAM? */
-	mask = omap4_prm_read_inst_reg(OMAP4430_PRM_DEVICE_INST, irqen_offs);
-	st = omap4_prm_read_inst_reg(OMAP4430_PRM_DEVICE_INST, irqst_offs);
+	mask = omap4_prm_read_inst_reg(OMAP4430_PRM_OCP_SOCKET_INST,
+				       irqen_offs);
+	st = omap4_prm_read_inst_reg(OMAP4430_PRM_OCP_SOCKET_INST, irqst_offs);
 
 	return mask & st;
 }
@@ -178,7 +179,7 @@ void omap44xx_prm_read_pending_irqs(unsigned long *events)
  */
 void omap44xx_prm_ocp_barrier(void)
 {
-	omap4_prm_read_inst_reg(OMAP4430_PRM_DEVICE_INST,
+	omap4_prm_read_inst_reg(OMAP4430_PRM_OCP_SOCKET_INST,
 				OMAP4_REVISION_PRM_OFFSET);
 }
 
@@ -196,19 +197,19 @@ void omap44xx_prm_ocp_barrier(void)
 void omap44xx_prm_save_and_clear_irqen(u32 *saved_mask)
 {
 	saved_mask[0] =
-		omap4_prm_read_inst_reg(OMAP4430_PRM_DEVICE_INST,
+		omap4_prm_read_inst_reg(OMAP4430_PRM_OCP_SOCKET_INST,
 					OMAP4_PRM_IRQSTATUS_MPU_OFFSET);
 	saved_mask[1] =
-		omap4_prm_read_inst_reg(OMAP4430_PRM_DEVICE_INST,
+		omap4_prm_read_inst_reg(OMAP4430_PRM_OCP_SOCKET_INST,
 					OMAP4_PRM_IRQSTATUS_MPU_2_OFFSET);
 
-	omap4_prm_write_inst_reg(0, OMAP4430_PRM_DEVICE_INST,
+	omap4_prm_write_inst_reg(0, OMAP4430_PRM_OCP_SOCKET_INST,
 				 OMAP4_PRM_IRQENABLE_MPU_OFFSET);
-	omap4_prm_write_inst_reg(0, OMAP4430_PRM_DEVICE_INST,
+	omap4_prm_write_inst_reg(0, OMAP4430_PRM_OCP_SOCKET_INST,
 				 OMAP4_PRM_IRQENABLE_MPU_2_OFFSET);
 
 	/* OCP barrier */
-	omap4_prm_read_inst_reg(OMAP4430_PRM_DEVICE_INST,
+	omap4_prm_read_inst_reg(OMAP4430_PRM_OCP_SOCKET_INST,
 				OMAP4_REVISION_PRM_OFFSET);
 }
 
@@ -224,9 +225,9 @@ void omap44xx_prm_save_and_clear_irqen(u32 *saved_mask)
  */
 void omap44xx_prm_restore_irqen(u32 *saved_mask)
 {
-	omap4_prm_write_inst_reg(saved_mask[0], OMAP4430_PRM_DEVICE_INST,
+	omap4_prm_write_inst_reg(saved_mask[0], OMAP4430_PRM_OCP_SOCKET_INST,
 				 OMAP4_PRM_IRQENABLE_MPU_OFFSET);
-	omap4_prm_write_inst_reg(saved_mask[1], OMAP4430_PRM_DEVICE_INST,
+	omap4_prm_write_inst_reg(saved_mask[1], OMAP4430_PRM_OCP_SOCKET_INST,
 				 OMAP4_PRM_IRQENABLE_MPU_2_OFFSET);
 }
 
-- 
1.7.4.1

[PATCHv3 2/4] ARM: OMAP4: prm: fix interrupt register offsets

[Tero Kristo]

Previous code used wrong instance for the interrupt register access.
Use the right one which is OCP_SOCKET.

Signed-off-by: Tero Kristo <t-kristo@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
---
 arch/arm/mach-omap2/prm44xx.c |   21 +++++++++++----------
 1 files changed, 11 insertions(+), 10 deletions(-)

diff --git a/arch/arm/mach-omap2/prm44xx.c b/arch/arm/mach-omap2/prm44xx.c
index a931f8f..caa5e0f 100644
--- a/arch/arm/mach-omap2/prm44xx.c
+++ b/arch/arm/mach-omap2/prm44xx.c
@@ -145,8 +145,9 @@ static inline u32 _read_pending_irq_reg(u16 irqen_offs, u16 irqst_offs)
 	u32 mask, st;
 
 	/* XXX read mask from RAM? */
-	mask = omap4_prm_read_inst_reg(OMAP4430_PRM_DEVICE_INST, irqen_offs);
-	st = omap4_prm_read_inst_reg(OMAP4430_PRM_DEVICE_INST, irqst_offs);
+	mask = omap4_prm_read_inst_reg(OMAP4430_PRM_OCP_SOCKET_INST,
+				       irqen_offs);
+	st = omap4_prm_read_inst_reg(OMAP4430_PRM_OCP_SOCKET_INST, irqst_offs);
 
 	return mask & st;
 }
@@ -178,7 +179,7 @@ void omap44xx_prm_read_pending_irqs(unsigned long *events)
  */
 void omap44xx_prm_ocp_barrier(void)
 {
-	omap4_prm_read_inst_reg(OMAP4430_PRM_DEVICE_INST,
+	omap4_prm_read_inst_reg(OMAP4430_PRM_OCP_SOCKET_INST,
 				OMAP4_REVISION_PRM_OFFSET);
 }
 
@@ -196,19 +197,19 @@ void omap44xx_prm_ocp_barrier(void)
 void omap44xx_prm_save_and_clear_irqen(u32 *saved_mask)
 {
 	saved_mask[0] =
-		omap4_prm_read_inst_reg(OMAP4430_PRM_DEVICE_INST,
+		omap4_prm_read_inst_reg(OMAP4430_PRM_OCP_SOCKET_INST,
 					OMAP4_PRM_IRQSTATUS_MPU_OFFSET);
 	saved_mask[1] =
-		omap4_prm_read_inst_reg(OMAP4430_PRM_DEVICE_INST,
+		omap4_prm_read_inst_reg(OMAP4430_PRM_OCP_SOCKET_INST,
 					OMAP4_PRM_IRQSTATUS_MPU_2_OFFSET);
 
-	omap4_prm_write_inst_reg(0, OMAP4430_PRM_DEVICE_INST,
+	omap4_prm_write_inst_reg(0, OMAP4430_PRM_OCP_SOCKET_INST,
 				 OMAP4_PRM_IRQENABLE_MPU_OFFSET);
-	omap4_prm_write_inst_reg(0, OMAP4430_PRM_DEVICE_INST,
+	omap4_prm_write_inst_reg(0, OMAP4430_PRM_OCP_SOCKET_INST,
 				 OMAP4_PRM_IRQENABLE_MPU_2_OFFSET);
 
 	/* OCP barrier */
-	omap4_prm_read_inst_reg(OMAP4430_PRM_DEVICE_INST,
+	omap4_prm_read_inst_reg(OMAP4430_PRM_OCP_SOCKET_INST,
 				OMAP4_REVISION_PRM_OFFSET);
 }
 
@@ -224,9 +225,9 @@ void omap44xx_prm_save_and_clear_irqen(u32 *saved_mask)
  */
 void omap44xx_prm_restore_irqen(u32 *saved_mask)
 {
-	omap4_prm_write_inst_reg(saved_mask[0], OMAP4430_PRM_DEVICE_INST,
+	omap4_prm_write_inst_reg(saved_mask[0], OMAP4430_PRM_OCP_SOCKET_INST,
 				 OMAP4_PRM_IRQENABLE_MPU_OFFSET);
-	omap4_prm_write_inst_reg(saved_mask[1], OMAP4430_PRM_DEVICE_INST,
+	omap4_prm_write_inst_reg(saved_mask[1], OMAP4430_PRM_OCP_SOCKET_INST,
 				 OMAP4_PRM_IRQENABLE_MPU_2_OFFSET);
 }
 
-- 
1.7.4.1

Re: [PATCHv3 2/4] ARM: OMAP4: prm: fix interrupt register offsets

[Paul Walmsley]

On Wed, 29 Feb 2012, Tero Kristo wrote:

> Previous code used wrong instance for the interrupt register access.
> Use the right one which is OCP_SOCKET.
> 
> Signed-off-by: Tero Kristo <t-kristo@ti.com>
> Cc: Paul Walmsley <paul@pwsan.com>

Thanks, queued.


- Paul

[PATCHv3 2/4] ARM: OMAP4: prm: fix interrupt register offsets

[Paul Walmsley]

On Wed, 29 Feb 2012, Tero Kristo wrote:

> Previous code used wrong instance for the interrupt register access.
> Use the right one which is OCP_SOCKET.
> 
> Signed-off-by: Tero Kristo <t-kristo@ti.com>
> Cc: Paul Walmsley <paul@pwsan.com>

Thanks, queued.


- Paul

[PATCHv3 3/4] TEMP: ARM: OMAP4: hwmod_data: Do not get DSP out of reset at boot time

[Tero Kristo]

From: Rajendra Nayak <rnayak@ti.com>

With no driver handling DSP, if brought out of reset, it stays
active and does not assert standby. This leads to IVAHD powerdomain not
transitioning and hence preventing chip retention.

This patch is no longer needed once Paul's powerdomain fixes are merged:
   http://marc.info/?l=linux-omap&m=133040749621183&w=2

Just provided for testing purposes.

Signed-off-by: Rajendra Nayak <rnayak@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
---
 arch/arm/mach-omap2/omap_hwmod_44xx_data.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index ef0524c..81d90da 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -1160,6 +1160,7 @@ static struct omap_hwmod omap44xx_dsp_hwmod = {
 	.name		= "dsp",
 	.class		= &omap44xx_dsp_hwmod_class,
 	.clkdm_name	= "tesla_clkdm",
+	.flags		= HWMOD_INIT_NO_RESET,
 	.mpu_irqs	= omap44xx_dsp_irqs,
 	.rst_lines	= omap44xx_dsp_resets,
 	.rst_lines_cnt	= ARRAY_SIZE(omap44xx_dsp_resets),
-- 
1.7.4.1

[PATCHv3 3/4] TEMP: ARM: OMAP4: hwmod_data: Do not get DSP out of reset at boot time

[Tero Kristo]

From: Rajendra Nayak <rnayak@ti.com>

With no driver handling DSP, if brought out of reset, it stays
active and does not assert standby. This leads to IVAHD powerdomain not
transitioning and hence preventing chip retention.

This patch is no longer needed once Paul's powerdomain fixes are merged:
   http://marc.info/?l=linux-omap&m=133040749621183&w=2

Just provided for testing purposes.

Signed-off-by: Rajendra Nayak <rnayak@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
---
 arch/arm/mach-omap2/omap_hwmod_44xx_data.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index ef0524c..81d90da 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -1160,6 +1160,7 @@ static struct omap_hwmod omap44xx_dsp_hwmod = {
 	.name		= "dsp",
 	.class		= &omap44xx_dsp_hwmod_class,
 	.clkdm_name	= "tesla_clkdm",
+	.flags		= HWMOD_INIT_NO_RESET,
 	.mpu_irqs	= omap44xx_dsp_irqs,
 	.rst_lines	= omap44xx_dsp_resets,
 	.rst_lines_cnt	= ARRAY_SIZE(omap44xx_dsp_resets),
-- 
1.7.4.1

[PATCHv3 4/4] ARM: OMAP3+: add prcm chain interrupts to the interrupt list

[Tero Kristo]

Currently PRCM chain handler for OMAP4 requires SPARSE_IRQ to be enabled
from kernel config, however enabling this option breaks the OMAP kernel
completely and it can't be used. Thus, OMAP_PRCM_IRQ_BASE was added
to the end of the irq list, and the prm_common code was changed to use
this instead of irq_desc allocation scheme.

Once SPARSE_IRQ is enabled for OMAP kernel, this patch can be reverted.

Signed-off-by: Tero Kristo <t-kristo@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
---
 arch/arm/mach-omap2/prm_common.c       |   14 +-------------
 arch/arm/plat-omap/include/plat/irqs.h |    6 +++++-
 2 files changed, 6 insertions(+), 14 deletions(-)

diff --git a/arch/arm/mach-omap2/prm_common.c b/arch/arm/mach-omap2/prm_common.c
index 860118a..9ca829f 100644
--- a/arch/arm/mach-omap2/prm_common.c
+++ b/arch/arm/mach-omap2/prm_common.c
@@ -196,11 +196,6 @@ void omap_prcm_irq_cleanup(void)
 	prcm_irq_setup->priority_mask = NULL;
 
 	irq_set_chained_handler(prcm_irq_setup->irq, NULL);
-
-	if (prcm_irq_setup->base_irq > 0)
-		irq_free_descs(prcm_irq_setup->base_irq,
-			prcm_irq_setup->nr_regs * 32);
-	prcm_irq_setup->base_irq = 0;
 }
 
 void omap_prcm_irq_prepare(void)
@@ -282,14 +277,7 @@ int omap_prcm_register_chain_handler(struct omap_prcm_irq_setup *irq_setup)
 
 	irq_set_chained_handler(irq_setup->irq, omap_prcm_irq_handler);
 
-	irq_setup->base_irq = irq_alloc_descs(-1, 0, irq_setup->nr_regs * 32,
-		0);
-
-	if (irq_setup->base_irq < 0) {
-		pr_err("PRCM: failed to allocate irq descs: %d\n",
-			irq_setup->base_irq);
-		goto err;
-	}
+	irq_setup->base_irq = OMAP_PRCM_IRQ_BASE;
 
 	for (i = 0; i <= irq_setup->nr_regs; i++) {
 		gc = irq_alloc_generic_chip("PRCM", 1,
diff --git a/arch/arm/plat-omap/include/plat/irqs.h b/arch/arm/plat-omap/include/plat/irqs.h
index 2efd645..fe1be1d 100644
--- a/arch/arm/plat-omap/include/plat/irqs.h
+++ b/arch/arm/plat-omap/include/plat/irqs.h
@@ -428,8 +428,12 @@
 #define OMAP_GPMC_NR_IRQS	8
 #define OMAP_GPMC_IRQ_END	(OMAP_GPMC_IRQ_BASE + OMAP_GPMC_NR_IRQS)
 
+/* PRCM chain handler */
+#define OMAP_PRCM_IRQ_BASE	(OMAP_GPMC_IRQ_END)
+#define OMAP_PRCM_NR_IRQS	64
+#define OMAP_PRCM_IRQ_END	(OMAP_PRCM_IRQ_BASE + OMAP_PRCM_NR_IRQS)
 
-#define NR_IRQS			OMAP_GPMC_IRQ_END
+#define NR_IRQS			OMAP_PRCM_IRQ_END
 
 #define OMAP_IRQ_BIT(irq)	(1 << ((irq) % 32))
 
-- 
1.7.4.1

[PATCHv3 4/4] ARM: OMAP3+: add prcm chain interrupts to the interrupt list

[Tero Kristo]

Currently PRCM chain handler for OMAP4 requires SPARSE_IRQ to be enabled
from kernel config, however enabling this option breaks the OMAP kernel
completely and it can't be used. Thus, OMAP_PRCM_IRQ_BASE was added
to the end of the irq list, and the prm_common code was changed to use
this instead of irq_desc allocation scheme.

Once SPARSE_IRQ is enabled for OMAP kernel, this patch can be reverted.

Signed-off-by: Tero Kristo <t-kristo@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
---
 arch/arm/mach-omap2/prm_common.c       |   14 +-------------
 arch/arm/plat-omap/include/plat/irqs.h |    6 +++++-
 2 files changed, 6 insertions(+), 14 deletions(-)

diff --git a/arch/arm/mach-omap2/prm_common.c b/arch/arm/mach-omap2/prm_common.c
index 860118a..9ca829f 100644
--- a/arch/arm/mach-omap2/prm_common.c
+++ b/arch/arm/mach-omap2/prm_common.c
@@ -196,11 +196,6 @@ void omap_prcm_irq_cleanup(void)
 	prcm_irq_setup->priority_mask = NULL;
 
 	irq_set_chained_handler(prcm_irq_setup->irq, NULL);
-
-	if (prcm_irq_setup->base_irq > 0)
-		irq_free_descs(prcm_irq_setup->base_irq,
-			prcm_irq_setup->nr_regs * 32);
-	prcm_irq_setup->base_irq = 0;
 }
 
 void omap_prcm_irq_prepare(void)
@@ -282,14 +277,7 @@ int omap_prcm_register_chain_handler(struct omap_prcm_irq_setup *irq_setup)
 
 	irq_set_chained_handler(irq_setup->irq, omap_prcm_irq_handler);
 
-	irq_setup->base_irq = irq_alloc_descs(-1, 0, irq_setup->nr_regs * 32,
-		0);
-
-	if (irq_setup->base_irq < 0) {
-		pr_err("PRCM: failed to allocate irq descs: %d\n",
-			irq_setup->base_irq);
-		goto err;
-	}
+	irq_setup->base_irq = OMAP_PRCM_IRQ_BASE;
 
 	for (i = 0; i <= irq_setup->nr_regs; i++) {
 		gc = irq_alloc_generic_chip("PRCM", 1,
diff --git a/arch/arm/plat-omap/include/plat/irqs.h b/arch/arm/plat-omap/include/plat/irqs.h
index 2efd645..fe1be1d 100644
--- a/arch/arm/plat-omap/include/plat/irqs.h
+++ b/arch/arm/plat-omap/include/plat/irqs.h
@@ -428,8 +428,12 @@
 #define OMAP_GPMC_NR_IRQS	8
 #define OMAP_GPMC_IRQ_END	(OMAP_GPMC_IRQ_BASE + OMAP_GPMC_NR_IRQS)
 
+/* PRCM chain handler */
+#define OMAP_PRCM_IRQ_BASE	(OMAP_GPMC_IRQ_END)
+#define OMAP_PRCM_NR_IRQS	64
+#define OMAP_PRCM_IRQ_END	(OMAP_PRCM_IRQ_BASE + OMAP_PRCM_NR_IRQS)
 
-#define NR_IRQS			OMAP_GPMC_IRQ_END
+#define NR_IRQS			OMAP_PRCM_IRQ_END
 
 #define OMAP_IRQ_BIT(irq)	(1 << ((irq) % 32))
 
-- 
1.7.4.1

Re: [PATCHv3 4/4] ARM: OMAP3+: add prcm chain interrupts to the interrupt list

[Rajendra Nayak]

On Wednesday 29 February 2012 08:55 PM, Tero Kristo wrote:
> Currently PRCM chain handler for OMAP4 requires SPARSE_IRQ to be enabled
> from kernel config, however enabling this option breaks the OMAP kernel
> completely and it can't be used. Thus, OMAP_PRCM_IRQ_BASE was added
> to the end of the irq list, and the prm_common code was changed to use
> this instead of irq_desc allocation scheme.
>
> Once SPARSE_IRQ is enabled for OMAP kernel, this patch can be reverted.

Do you still need this, despite this fix from Benoit?
http://marc.info/?l=linux-arm-kernel&m=133043468329275&w=2

>
> Signed-off-by: Tero Kristo<t-kristo@ti.com>
> Cc: Paul Walmsley<paul@pwsan.com>
> ---
>   arch/arm/mach-omap2/prm_common.c       |   14 +-------------
>   arch/arm/plat-omap/include/plat/irqs.h |    6 +++++-
>   2 files changed, 6 insertions(+), 14 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/prm_common.c b/arch/arm/mach-omap2/prm_common.c
> index 860118a..9ca829f 100644
> --- a/arch/arm/mach-omap2/prm_common.c
> +++ b/arch/arm/mach-omap2/prm_common.c
> @@ -196,11 +196,6 @@ void omap_prcm_irq_cleanup(void)
>   	prcm_irq_setup->priority_mask = NULL;
>
>   	irq_set_chained_handler(prcm_irq_setup->irq, NULL);
> -
> -	if (prcm_irq_setup->base_irq>  0)
> -		irq_free_descs(prcm_irq_setup->base_irq,
> -			prcm_irq_setup->nr_regs * 32);
> -	prcm_irq_setup->base_irq = 0;
>   }
>
>   void omap_prcm_irq_prepare(void)
> @@ -282,14 +277,7 @@ int omap_prcm_register_chain_handler(struct omap_prcm_irq_setup *irq_setup)
>
>   	irq_set_chained_handler(irq_setup->irq, omap_prcm_irq_handler);
>
> -	irq_setup->base_irq = irq_alloc_descs(-1, 0, irq_setup->nr_regs * 32,
> -		0);
> -
> -	if (irq_setup->base_irq<  0) {
> -		pr_err("PRCM: failed to allocate irq descs: %d\n",
> -			irq_setup->base_irq);
> -		goto err;
> -	}
> +	irq_setup->base_irq = OMAP_PRCM_IRQ_BASE;
>
>   	for (i = 0; i<= irq_setup->nr_regs; i++) {
>   		gc = irq_alloc_generic_chip("PRCM", 1,
> diff --git a/arch/arm/plat-omap/include/plat/irqs.h b/arch/arm/plat-omap/include/plat/irqs.h
> index 2efd645..fe1be1d 100644
> --- a/arch/arm/plat-omap/include/plat/irqs.h
> +++ b/arch/arm/plat-omap/include/plat/irqs.h
> @@ -428,8 +428,12 @@
>   #define OMAP_GPMC_NR_IRQS	8
>   #define OMAP_GPMC_IRQ_END	(OMAP_GPMC_IRQ_BASE + OMAP_GPMC_NR_IRQS)
>
> +/* PRCM chain handler */
> +#define OMAP_PRCM_IRQ_BASE	(OMAP_GPMC_IRQ_END)
> +#define OMAP_PRCM_NR_IRQS	64
> +#define OMAP_PRCM_IRQ_END	(OMAP_PRCM_IRQ_BASE + OMAP_PRCM_NR_IRQS)
>
> -#define NR_IRQS			OMAP_GPMC_IRQ_END
> +#define NR_IRQS			OMAP_PRCM_IRQ_END
>
>   #define OMAP_IRQ_BIT(irq)	(1<<  ((irq) % 32))
>

[PATCHv3 4/4] ARM: OMAP3+: add prcm chain interrupts to the interrupt list

[Rajendra Nayak]

On Wednesday 29 February 2012 08:55 PM, Tero Kristo wrote:
> Currently PRCM chain handler for OMAP4 requires SPARSE_IRQ to be enabled
> from kernel config, however enabling this option breaks the OMAP kernel
> completely and it can't be used. Thus, OMAP_PRCM_IRQ_BASE was added
> to the end of the irq list, and the prm_common code was changed to use
> this instead of irq_desc allocation scheme.
>
> Once SPARSE_IRQ is enabled for OMAP kernel, this patch can be reverted.

Do you still need this, despite this fix from Benoit?
http://marc.info/?l=linux-arm-kernel&m=133043468329275&w=2

>
> Signed-off-by: Tero Kristo<t-kristo@ti.com>
> Cc: Paul Walmsley<paul@pwsan.com>
> ---
>   arch/arm/mach-omap2/prm_common.c       |   14 +-------------
>   arch/arm/plat-omap/include/plat/irqs.h |    6 +++++-
>   2 files changed, 6 insertions(+), 14 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/prm_common.c b/arch/arm/mach-omap2/prm_common.c
> index 860118a..9ca829f 100644
> --- a/arch/arm/mach-omap2/prm_common.c
> +++ b/arch/arm/mach-omap2/prm_common.c
> @@ -196,11 +196,6 @@ void omap_prcm_irq_cleanup(void)
>   	prcm_irq_setup->priority_mask = NULL;
>
>   	irq_set_chained_handler(prcm_irq_setup->irq, NULL);
> -
> -	if (prcm_irq_setup->base_irq>  0)
> -		irq_free_descs(prcm_irq_setup->base_irq,
> -			prcm_irq_setup->nr_regs * 32);
> -	prcm_irq_setup->base_irq = 0;
>   }
>
>   void omap_prcm_irq_prepare(void)
> @@ -282,14 +277,7 @@ int omap_prcm_register_chain_handler(struct omap_prcm_irq_setup *irq_setup)
>
>   	irq_set_chained_handler(irq_setup->irq, omap_prcm_irq_handler);
>
> -	irq_setup->base_irq = irq_alloc_descs(-1, 0, irq_setup->nr_regs * 32,
> -		0);
> -
> -	if (irq_setup->base_irq<  0) {
> -		pr_err("PRCM: failed to allocate irq descs: %d\n",
> -			irq_setup->base_irq);
> -		goto err;
> -	}
> +	irq_setup->base_irq = OMAP_PRCM_IRQ_BASE;
>
>   	for (i = 0; i<= irq_setup->nr_regs; i++) {
>   		gc = irq_alloc_generic_chip("PRCM", 1,
> diff --git a/arch/arm/plat-omap/include/plat/irqs.h b/arch/arm/plat-omap/include/plat/irqs.h
> index 2efd645..fe1be1d 100644
> --- a/arch/arm/plat-omap/include/plat/irqs.h
> +++ b/arch/arm/plat-omap/include/plat/irqs.h
> @@ -428,8 +428,12 @@
>   #define OMAP_GPMC_NR_IRQS	8
>   #define OMAP_GPMC_IRQ_END	(OMAP_GPMC_IRQ_BASE + OMAP_GPMC_NR_IRQS)
>
> +/* PRCM chain handler */
> +#define OMAP_PRCM_IRQ_BASE	(OMAP_GPMC_IRQ_END)
> +#define OMAP_PRCM_NR_IRQS	64
> +#define OMAP_PRCM_IRQ_END	(OMAP_PRCM_IRQ_BASE + OMAP_PRCM_NR_IRQS)
>
> -#define NR_IRQS			OMAP_GPMC_IRQ_END
> +#define NR_IRQS			OMAP_PRCM_IRQ_END
>
>   #define OMAP_IRQ_BIT(irq)	(1<<  ((irq) % 32))
>

Re: [PATCHv3 4/4] ARM: OMAP3+: add prcm chain interrupts to the interrupt list

[Tero Kristo]

On Thu, 2012-03-01 at 12:31 +0530, Rajendra Nayak wrote:
> On Wednesday 29 February 2012 08:55 PM, Tero Kristo wrote:
> > Currently PRCM chain handler for OMAP4 requires SPARSE_IRQ to be enabled
> > from kernel config, however enabling this option breaks the OMAP kernel
> > completely and it can't be used. Thus, OMAP_PRCM_IRQ_BASE was added
> > to the end of the irq list, and the prm_common code was changed to use
> > this instead of irq_desc allocation scheme.
> >
> > Once SPARSE_IRQ is enabled for OMAP kernel, this patch can be reverted.
> 
> Do you still need this, despite this fix from Benoit?
> http://marc.info/?l=linux-arm-kernel&m=133043468329275&w=2

Not sure, I haven't tested that yet.

-Tero

> 
> >
> > Signed-off-by: Tero Kristo<t-kristo@ti.com>
> > Cc: Paul Walmsley<paul@pwsan.com>
> > ---
> >   arch/arm/mach-omap2/prm_common.c       |   14 +-------------
> >   arch/arm/plat-omap/include/plat/irqs.h |    6 +++++-
> >   2 files changed, 6 insertions(+), 14 deletions(-)
> >
> > diff --git a/arch/arm/mach-omap2/prm_common.c b/arch/arm/mach-omap2/prm_common.c
> > index 860118a..9ca829f 100644
> > --- a/arch/arm/mach-omap2/prm_common.c
> > +++ b/arch/arm/mach-omap2/prm_common.c
> > @@ -196,11 +196,6 @@ void omap_prcm_irq_cleanup(void)
> >   	prcm_irq_setup->priority_mask = NULL;
> >
> >   	irq_set_chained_handler(prcm_irq_setup->irq, NULL);
> > -
> > -	if (prcm_irq_setup->base_irq>  0)
> > -		irq_free_descs(prcm_irq_setup->base_irq,
> > -			prcm_irq_setup->nr_regs * 32);
> > -	prcm_irq_setup->base_irq = 0;
> >   }
> >
> >   void omap_prcm_irq_prepare(void)
> > @@ -282,14 +277,7 @@ int omap_prcm_register_chain_handler(struct omap_prcm_irq_setup *irq_setup)
> >
> >   	irq_set_chained_handler(irq_setup->irq, omap_prcm_irq_handler);
> >
> > -	irq_setup->base_irq = irq_alloc_descs(-1, 0, irq_setup->nr_regs * 32,
> > -		0);
> > -
> > -	if (irq_setup->base_irq<  0) {
> > -		pr_err("PRCM: failed to allocate irq descs: %d\n",
> > -			irq_setup->base_irq);
> > -		goto err;
> > -	}
> > +	irq_setup->base_irq = OMAP_PRCM_IRQ_BASE;
> >
> >   	for (i = 0; i<= irq_setup->nr_regs; i++) {
> >   		gc = irq_alloc_generic_chip("PRCM", 1,
> > diff --git a/arch/arm/plat-omap/include/plat/irqs.h b/arch/arm/plat-omap/include/plat/irqs.h
> > index 2efd645..fe1be1d 100644
> > --- a/arch/arm/plat-omap/include/plat/irqs.h
> > +++ b/arch/arm/plat-omap/include/plat/irqs.h
> > @@ -428,8 +428,12 @@
> >   #define OMAP_GPMC_NR_IRQS	8
> >   #define OMAP_GPMC_IRQ_END	(OMAP_GPMC_IRQ_BASE + OMAP_GPMC_NR_IRQS)
> >
> > +/* PRCM chain handler */
> > +#define OMAP_PRCM_IRQ_BASE	(OMAP_GPMC_IRQ_END)
> > +#define OMAP_PRCM_NR_IRQS	64
> > +#define OMAP_PRCM_IRQ_END	(OMAP_PRCM_IRQ_BASE + OMAP_PRCM_NR_IRQS)
> >
> > -#define NR_IRQS			OMAP_GPMC_IRQ_END
> > +#define NR_IRQS			OMAP_PRCM_IRQ_END
> >
> >   #define OMAP_IRQ_BIT(irq)	(1<<  ((irq) % 32))
> >
> 

[PATCHv3 4/4] ARM: OMAP3+: add prcm chain interrupts to the interrupt list

[Tero Kristo]

On Thu, 2012-03-01 at 12:31 +0530, Rajendra Nayak wrote:
> On Wednesday 29 February 2012 08:55 PM, Tero Kristo wrote:
> > Currently PRCM chain handler for OMAP4 requires SPARSE_IRQ to be enabled
> > from kernel config, however enabling this option breaks the OMAP kernel
> > completely and it can't be used. Thus, OMAP_PRCM_IRQ_BASE was added
> > to the end of the irq list, and the prm_common code was changed to use
> > this instead of irq_desc allocation scheme.
> >
> > Once SPARSE_IRQ is enabled for OMAP kernel, this patch can be reverted.
> 
> Do you still need this, despite this fix from Benoit?
> http://marc.info/?l=linux-arm-kernel&m=133043468329275&w=2

Not sure, I haven't tested that yet.

-Tero

> 
> >
> > Signed-off-by: Tero Kristo<t-kristo@ti.com>
> > Cc: Paul Walmsley<paul@pwsan.com>
> > ---
> >   arch/arm/mach-omap2/prm_common.c       |   14 +-------------
> >   arch/arm/plat-omap/include/plat/irqs.h |    6 +++++-
> >   2 files changed, 6 insertions(+), 14 deletions(-)
> >
> > diff --git a/arch/arm/mach-omap2/prm_common.c b/arch/arm/mach-omap2/prm_common.c
> > index 860118a..9ca829f 100644
> > --- a/arch/arm/mach-omap2/prm_common.c
> > +++ b/arch/arm/mach-omap2/prm_common.c
> > @@ -196,11 +196,6 @@ void omap_prcm_irq_cleanup(void)
> >   	prcm_irq_setup->priority_mask = NULL;
> >
> >   	irq_set_chained_handler(prcm_irq_setup->irq, NULL);
> > -
> > -	if (prcm_irq_setup->base_irq>  0)
> > -		irq_free_descs(prcm_irq_setup->base_irq,
> > -			prcm_irq_setup->nr_regs * 32);
> > -	prcm_irq_setup->base_irq = 0;
> >   }
> >
> >   void omap_prcm_irq_prepare(void)
> > @@ -282,14 +277,7 @@ int omap_prcm_register_chain_handler(struct omap_prcm_irq_setup *irq_setup)
> >
> >   	irq_set_chained_handler(irq_setup->irq, omap_prcm_irq_handler);
> >
> > -	irq_setup->base_irq = irq_alloc_descs(-1, 0, irq_setup->nr_regs * 32,
> > -		0);
> > -
> > -	if (irq_setup->base_irq<  0) {
> > -		pr_err("PRCM: failed to allocate irq descs: %d\n",
> > -			irq_setup->base_irq);
> > -		goto err;
> > -	}
> > +	irq_setup->base_irq = OMAP_PRCM_IRQ_BASE;
> >
> >   	for (i = 0; i<= irq_setup->nr_regs; i++) {
> >   		gc = irq_alloc_generic_chip("PRCM", 1,
> > diff --git a/arch/arm/plat-omap/include/plat/irqs.h b/arch/arm/plat-omap/include/plat/irqs.h
> > index 2efd645..fe1be1d 100644
> > --- a/arch/arm/plat-omap/include/plat/irqs.h
> > +++ b/arch/arm/plat-omap/include/plat/irqs.h
> > @@ -428,8 +428,12 @@
> >   #define OMAP_GPMC_NR_IRQS	8
> >   #define OMAP_GPMC_IRQ_END	(OMAP_GPMC_IRQ_BASE + OMAP_GPMC_NR_IRQS)
> >
> > +/* PRCM chain handler */
> > +#define OMAP_PRCM_IRQ_BASE	(OMAP_GPMC_IRQ_END)
> > +#define OMAP_PRCM_NR_IRQS	64
> > +#define OMAP_PRCM_IRQ_END	(OMAP_PRCM_IRQ_BASE + OMAP_PRCM_NR_IRQS)
> >
> > -#define NR_IRQS			OMAP_GPMC_IRQ_END
> > +#define NR_IRQS			OMAP_PRCM_IRQ_END
> >
> >   #define OMAP_IRQ_BIT(irq)	(1<<  ((irq) % 32))
> >
> 

Re: [PATCHv3 4/4] ARM: OMAP3+: add prcm chain interrupts to the interrupt list

[Russell King - ARM Linux]

On Wed, Feb 29, 2012 at 05:25:06PM +0200, Tero Kristo wrote:
> Currently PRCM chain handler for OMAP4 requires SPARSE_IRQ to be enabled
> from kernel config, however enabling this option breaks the OMAP kernel
> completely and it can't be used.

No it does not.  Look:

	irq_alloc_descs(start, from, num, -1)

will allocate num interrupt descriptors from within from..NR_IRQS if
sparse IRQ is disabled.  So, provided there is sufficient space within
the available NR_IRQS, irq_alloc_descs() works for non-sparse IRQ.
There is no need to get rid of it at all.

If start is -1, then it will allocate from where-ever it can in the
range from..NR_IRQS.  Otherwise, it will fail if it can't get an
allocation starting at 'start'.

If sparse IRQ is enabled, then it will start allocating from whatever
the last figure output from the:

	NR_IRQS:%d nr_irqs:%d %d

line.

[PATCHv3 4/4] ARM: OMAP3+: add prcm chain interrupts to the interrupt list

[Russell King - ARM Linux]

On Wed, Feb 29, 2012 at 05:25:06PM +0200, Tero Kristo wrote:
> Currently PRCM chain handler for OMAP4 requires SPARSE_IRQ to be enabled
> from kernel config, however enabling this option breaks the OMAP kernel
> completely and it can't be used.

No it does not.  Look:

	irq_alloc_descs(start, from, num, -1)

will allocate num interrupt descriptors from within from..NR_IRQS if
sparse IRQ is disabled.  So, provided there is sufficient space within
the available NR_IRQS, irq_alloc_descs() works for non-sparse IRQ.
There is no need to get rid of it at all.

If start is -1, then it will allocate from where-ever it can in the
range from..NR_IRQS.  Otherwise, it will fail if it can't get an
allocation starting at 'start'.

If sparse IRQ is enabled, then it will start allocating from whatever
the last figure output from the:

	NR_IRQS:%d nr_irqs:%d %d

line.

Re: [PATCHv3 4/4] ARM: OMAP3+: add prcm chain interrupts to the interrupt list

[Tero Kristo]

On Thu, 2012-03-01 at 09:46 +0000, Russell King - ARM Linux wrote:
> On Wed, Feb 29, 2012 at 05:25:06PM +0200, Tero Kristo wrote:
> > Currently PRCM chain handler for OMAP4 requires SPARSE_IRQ to be enabled
> > from kernel config, however enabling this option breaks the OMAP kernel
> > completely and it can't be used.
> 
> No it does not.  Look:
> 
> 	irq_alloc_descs(start, from, num, -1)
> 
> will allocate num interrupt descriptors from within from..NR_IRQS if
> sparse IRQ is disabled.  So, provided there is sufficient space within
> the available NR_IRQS, irq_alloc_descs() works for non-sparse IRQ.
> There is no need to get rid of it at all.
> 
> If start is -1, then it will allocate from where-ever it can in the
> range from..NR_IRQS.  Otherwise, it will fail if it can't get an
> allocation starting at 'start'.
> 
> If sparse IRQ is enabled, then it will start allocating from whatever
> the last figure output from the:
> 
> 	NR_IRQS:%d nr_irqs:%d %d
> 
> line.

With the patch from Benoit
(http://marc.info/?l=linux-arm-kernel&m=133043468329275&w=2) this patch
is no longer needed. Previously the NR_IRQS definition was too small for
omap4 and the alloc_descs was failing because of that. It seems I
overshoot with this patch of mine and dropped also the irq_alloc_desc
implementation while fixing the problem.

-Tero

[PATCHv3 4/4] ARM: OMAP3+: add prcm chain interrupts to the interrupt list

[Tero Kristo]

On Thu, 2012-03-01 at 09:46 +0000, Russell King - ARM Linux wrote:
> On Wed, Feb 29, 2012 at 05:25:06PM +0200, Tero Kristo wrote:
> > Currently PRCM chain handler for OMAP4 requires SPARSE_IRQ to be enabled
> > from kernel config, however enabling this option breaks the OMAP kernel
> > completely and it can't be used.
> 
> No it does not.  Look:
> 
> 	irq_alloc_descs(start, from, num, -1)
> 
> will allocate num interrupt descriptors from within from..NR_IRQS if
> sparse IRQ is disabled.  So, provided there is sufficient space within
> the available NR_IRQS, irq_alloc_descs() works for non-sparse IRQ.
> There is no need to get rid of it at all.
> 
> If start is -1, then it will allocate from where-ever it can in the
> range from..NR_IRQS.  Otherwise, it will fail if it can't get an
> allocation starting at 'start'.
> 
> If sparse IRQ is enabled, then it will start allocating from whatever
> the last figure output from the:
> 
> 	NR_IRQS:%d nr_irqs:%d %d
> 
> line.

With the patch from Benoit
(http://marc.info/?l=linux-arm-kernel&m=133043468329275&w=2) this patch
is no longer needed. Previously the NR_IRQS definition was too small for
omap4 and the alloc_descs was failing because of that. It seems I
overshoot with this patch of mine and dropped also the irq_alloc_desc
implementation while fixing the problem.

-Tero

Re: [PATCHv3 0/4] ARM: OMAP4: core retention support

[Shilimkar, Santosh]

On Wed, Feb 29, 2012 at 8:55 PM, Tero Kristo <t-kristo@ti.com> wrote:
> Hi,
>
> Changes compared to previous version:
>
> - split out the io_chain set as a separate set
> - marked patch 3 as TEMP, this is only needed until Paul's pwrdm fixes
>  get merged (http://marc.info/?l=linux-omap&m=133040749621183&w=2)
>
> Depends on the io_chain set to provide wakeup capability from
> retention.
>
> Tested with omap4430 blaze : suspend / resume works okay.

Thanks for fixing answering the comments on last version.
For entire series you can add
Reviewed-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCHv3 0/4] ARM: OMAP4: core retention support

[Shilimkar, Santosh]

On Wed, Feb 29, 2012 at 8:55 PM, Tero Kristo <t-kristo@ti.com> wrote:
> Hi,
>
> Changes compared to previous version:
>
> - split out the io_chain set as a separate set
> - marked patch 3 as TEMP, this is only needed until Paul's pwrdm fixes
> ?get merged (http://marc.info/?l=linux-omap&m=133040749621183&w=2)
>
> Depends on the io_chain set to provide wakeup capability from
> retention.
>
> Tested with omap4430 blaze : suspend / resume works okay.

Thanks for fixing answering the comments on last version.
For entire series you can add
Reviewed-by: Santosh Shilimkar <santosh.shilimkar@ti.com>