diff mbox

[RFC] davinci: poll for sleep completion in resume routine.

Message ID 1359624393-5898-1-git-send-email-manishv.b@ti.com (mailing list archive)
State New, archived
Headers show

Commit Message

Vishwanathrao Badarkhe, Manish Jan. 31, 2013, 9:26 a.m. UTC
As per OMAP-L138 TRM, Software must poll for
SLEEPCOMPLETE bit until it is set to 1 before clearing
SLEEPENABLE bit in DEEPSLEEP register in resume routine.
Modifications are as per datasheet:
http://www.ti.com/lit/ug/spruh77a/spruh77a.pdf
See sections 10.10.2.2 and 11.5.21 for more detailed
explanation.

Tested on da850-evm.

Signed-off-by: Vishwanathrao Badarkhe, Manish <manishv.b@ti.com>
---
:100644 100644 d4e9316... 976f096... M	arch/arm/mach-davinci/sleep.S
 arch/arm/mach-davinci/sleep.S |    8 ++++++++
 1 files changed, 8 insertions(+), 0 deletions(-)

Comments

Sekhar Nori Jan. 31, 2013, 9:51 a.m. UTC | #1
On 1/31/2013 2:56 PM, Vishwanathrao Badarkhe, Manish wrote:
> As per OMAP-L138 TRM, Software must poll for
> SLEEPCOMPLETE bit until it is set to 1 before clearing
> SLEEPENABLE bit in DEEPSLEEP register in resume routine.
> Modifications are as per datasheet:
> http://www.ti.com/lit/ug/spruh77a/spruh77a.pdf
> See sections 10.10.2.2 and 11.5.21 for more detailed
> explanation.
> 
> Tested on da850-evm.
> 
> Signed-off-by: Vishwanathrao Badarkhe, Manish <manishv.b@ti.com>

Is this a bug fix? Do you see any issue without this patch?

Thanks,
Sekhar
Vishwanathrao Badarkhe, Manish Jan. 31, 2013, 10:11 a.m. UTC | #2
Hi Sekhar

On Thu, Jan 31, 2013 at 15:21:42, Nori, Sekhar wrote:
> 
> 
> On 1/31/2013 2:56 PM, Vishwanathrao Badarkhe, Manish wrote:
> > As per OMAP-L138 TRM, Software must poll for SLEEPCOMPLETE bit until 
> > it is set to 1 before clearing SLEEPENABLE bit in DEEPSLEEP register 
> > in resume routine.
> > Modifications are as per datasheet:
> > http://www.ti.com/lit/ug/spruh77a/spruh77a.pdf
> > See sections 10.10.2.2 and 11.5.21 for more detailed explanation.
> > 
> > Tested on da850-evm.
> > 
> > Signed-off-by: Vishwanathrao Badarkhe, Manish <manishv.b@ti.com>
> 
> Is this a bug fix? Do you see any issue without this patch?

This is not a bug fix. I have not seen any issue without this patch. 
Only, modifications are done as per OMAP-L138 TRM.   

> 
> Thanks,
> Sekhar
> 


Regards, 
Manish
Sekhar Nori Feb. 14, 2013, 4:18 a.m. UTC | #3
Manish,

On 1/31/2013 2:56 PM, Vishwanathrao Badarkhe, Manish wrote:
> As per OMAP-L138 TRM, Software must poll for
> SLEEPCOMPLETE bit until it is set to 1 before clearing
> SLEEPENABLE bit in DEEPSLEEP register in resume routine.
> Modifications are as per datasheet:
> http://www.ti.com/lit/ug/spruh77a/spruh77a.pdf
> See sections 10.10.2.2 and 11.5.21 for more detailed
> explanation.

Polling for SLEEPCOMPLETE is not required in RTC controlled wake-up
which is the mode currently supported (see section 10.10.2.1 of the
TRM). Polling for SLEEPCOMPLETE is required for external controlled
wake-up which to my knowledge has never been tested. If you have tested
this with external controlled wakep-up, then I can consider this patch.
Else, I would like to take it only after externally controlled wake-up
is fully tested/supported instead of taking bits and pieces.

Thanks,
Sekhar

> 
> Tested on da850-evm.
> 
> Signed-off-by: Vishwanathrao Badarkhe, Manish <manishv.b@ti.com>
> ---
> :100644 100644 d4e9316... 976f096... M	arch/arm/mach-davinci/sleep.S
>  arch/arm/mach-davinci/sleep.S |    8 ++++++++
>  1 files changed, 8 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/arm/mach-davinci/sleep.S b/arch/arm/mach-davinci/sleep.S
> index d4e9316..976f096 100644
> --- a/arch/arm/mach-davinci/sleep.S
> +++ b/arch/arm/mach-davinci/sleep.S
> @@ -35,6 +35,7 @@
>  #define PLL_LOCK_CYCLES		(PLL_LOCK_TIME * 25)
>  
>  #define DEEPSLEEP_SLEEPENABLE_BIT	BIT(31)
> +#define DEEPSLEEP_SLEEPCOMPLETE_BIT 	BIT(30)
>  
>  	.text
>  /*
> @@ -110,6 +111,13 @@ ENTRY(davinci_cpu_suspend)
>  
>  	/* Wake up from sleep */
>  
> +	/* wait for sleep complete */
> +sleep_complete:
> +	ldr 	ip, [r4]
> +	and 	ip, ip, #DEEPSLEEP_SLEEPCOMPLETE_BIT
> +	cmp 	ip, #DEEPSLEEP_SLEEPCOMPLETE_BIT
> +	bne 	sleep_complete
> +
>  	/* Clear sleep enable */
>  	ldr	ip, [r4]
>  	bic	ip, ip, #DEEPSLEEP_SLEEPENABLE_BIT
>
Vishwanathrao Badarkhe, Manish Feb. 14, 2013, 5:16 a.m. UTC | #4
Hi Sekhar,

On Thu, Feb 14, 2013 at 09:48:59, Nori, Sekhar wrote:
> Manish,

> 

> On 1/31/2013 2:56 PM, Vishwanathrao Badarkhe, Manish wrote:

> > As per OMAP-L138 TRM, Software must poll for SLEEPCOMPLETE bit until 

> > it is set to 1 before clearing SLEEPENABLE bit in DEEPSLEEP register 

> > in resume routine.

> > Modifications are as per datasheet:

> > http://www.ti.com/lit/ug/spruh77a/spruh77a.pdf

> > See sections 10.10.2.2 and 11.5.21 for more detailed explanation.

> 

> Polling for SLEEPCOMPLETE is not required in RTC controlled wake-up which is the mode currently supported (see section 10.10.2.1 of the TRM). Polling for SLEEPCOMPLETE is required for external controlled wake-up which to my knowledge has never been tested. If you have tested this with external controlled wakep-up, then I can consider this patch.

> Else, I would like to take it only after externally controlled wake-up is fully tested/supported instead of taking bits and pieces.


Yes, for RTC controlled wakeup, this polling is not required as per section 10.10.2.1.
But if we see in section 10.10.2.2 (Exiting Deep Sleep Mode) step 2, When sleep count 
completes SLEEPCOMPLETE bit gets sets in DEEPSLEEP register till that it's not safe to 
release clock to devices. So If we don’t poll for SLEEPCOMPLETE, this delay will not
come into picture which we actually set while entering deep sleep in case of RTC 
controlled wakeup (Section 10.10.2.1 step 9). 
Please let me know, whether these understanding is correct?

For external controlled wakeup, we need to do hardware modifications and hence, Yet to 
be tested external controlled wakeup functionality.

Thanks, 
Manish Badarkhe

> > 

> > Tested on da850-evm.

> > 

> > Signed-off-by: Vishwanathrao Badarkhe, Manish <manishv.b@ti.com>

> > ---

> > :100644 100644 d4e9316... 976f096... M	arch/arm/mach-davinci/sleep.S

> >  arch/arm/mach-davinci/sleep.S |    8 ++++++++

> >  1 files changed, 8 insertions(+), 0 deletions(-)

> > 

> > diff --git a/arch/arm/mach-davinci/sleep.S 

> > b/arch/arm/mach-davinci/sleep.S index d4e9316..976f096 100644

> > --- a/arch/arm/mach-davinci/sleep.S

> > +++ b/arch/arm/mach-davinci/sleep.S

> > @@ -35,6 +35,7 @@

> >  #define PLL_LOCK_CYCLES		(PLL_LOCK_TIME * 25)

> >  

> >  #define DEEPSLEEP_SLEEPENABLE_BIT	BIT(31)

> > +#define DEEPSLEEP_SLEEPCOMPLETE_BIT 	BIT(30)

> >  

> >  	.text

> >  /*

> > @@ -110,6 +111,13 @@ ENTRY(davinci_cpu_suspend)

> >  

> >  	/* Wake up from sleep */

> >  

> > +	/* wait for sleep complete */

> > +sleep_complete:

> > +	ldr 	ip, [r4]

> > +	and 	ip, ip, #DEEPSLEEP_SLEEPCOMPLETE_BIT

> > +	cmp 	ip, #DEEPSLEEP_SLEEPCOMPLETE_BIT

> > +	bne 	sleep_complete

> > +

> >  	/* Clear sleep enable */

> >  	ldr	ip, [r4]

> >  	bic	ip, ip, #DEEPSLEEP_SLEEPENABLE_BIT

> > 

>
Sekhar Nori Feb. 14, 2013, 6:59 a.m. UTC | #5
On 2/14/2013 10:46 AM, Vishwanathrao Badarkhe, Manish wrote:
> Hi Sekhar,
> 
> On Thu, Feb 14, 2013 at 09:48:59, Nori, Sekhar wrote:
>> Manish,
>>
>> On 1/31/2013 2:56 PM, Vishwanathrao Badarkhe, Manish wrote:
>>> As per OMAP-L138 TRM, Software must poll for SLEEPCOMPLETE bit until 
>>> it is set to 1 before clearing SLEEPENABLE bit in DEEPSLEEP register 
>>> in resume routine.
>>> Modifications are as per datasheet:
>>> http://www.ti.com/lit/ug/spruh77a/spruh77a.pdf
>>> See sections 10.10.2.2 and 11.5.21 for more detailed explanation.
>>
>> Polling for SLEEPCOMPLETE is not required in RTC controlled wake-up which is the mode currently supported (see section 10.10.2.1 of the TRM). Polling for SLEEPCOMPLETE is required for external controlled wake-up which to my knowledge has never been tested. If you have tested this with external controlled wakep-up, then I can consider this patch.
>> Else, I would like to take it only after externally controlled wake-up is fully tested/supported instead of taking bits and pieces.
> 
> Yes, for RTC controlled wakeup, this polling is not required as per section 10.10.2.1.
> But if we see in section 10.10.2.2 (Exiting Deep Sleep Mode) step 2, When sleep count 
> completes SLEEPCOMPLETE bit gets sets in DEEPSLEEP register till that it's not safe to 
> release clock to devices. So If we don’t poll for SLEEPCOMPLETE, this delay will not
> come into picture which we actually set while entering deep sleep in case of RTC 
> controlled wakeup (Section 10.10.2.1 step 9). 
> Please let me know, whether these understanding is correct?

The  delay is coming from hardware. Till SLEEPCOUNT completes, the clock
to device is not provided. There is no need to poll for SLEEPCOMPLETE
and indeed 10.10.2.2 does not ask for this bit to be polled.

Thanks,
Sekhar
Vishwanathrao Badarkhe, Manish Feb. 14, 2013, 8:52 a.m. UTC | #6
Hi Sekhar,

On Thu, Feb 14, 2013 at 12:29:11, Nori, Sekhar wrote:
> On 2/14/2013 10:46 AM, Vishwanathrao Badarkhe, Manish wrote:

> > Hi Sekhar,

> > 

> > On Thu, Feb 14, 2013 at 09:48:59, Nori, Sekhar wrote:

> >> Manish,

> >>

> >> On 1/31/2013 2:56 PM, Vishwanathrao Badarkhe, Manish wrote:

> >>> As per OMAP-L138 TRM, Software must poll for SLEEPCOMPLETE bit until 

> >>> it is set to 1 before clearing SLEEPENABLE bit in DEEPSLEEP register 

> >>> in resume routine.

> >>> Modifications are as per datasheet:

> >>> http://www.ti.com/lit/ug/spruh77a/spruh77a.pdf

> >>> See sections 10.10.2.2 and 11.5.21 for more detailed explanation.

> >>

> >> Polling for SLEEPCOMPLETE is not required in RTC controlled wake-up which is the mode currently supported (see section 10.10.2.1 of the TRM). Polling for SLEEPCOMPLETE is required for external controlled wake-up which to my knowledge has never been tested. If you have tested this with external controlled wakep-up, then I can consider this patch.

> >> Else, I would like to take it only after externally controlled wake-up is fully tested/supported instead of taking bits and pieces.

> > 

> > Yes, for RTC controlled wakeup, this polling is not required as per section 10.10.2.1.

> > But if we see in section 10.10.2.2 (Exiting Deep Sleep Mode) step 2, 

> > When sleep count completes SLEEPCOMPLETE bit gets sets in DEEPSLEEP 

> > register till that it's not safe to release clock to devices. So If we 

> > don’t poll for SLEEPCOMPLETE, this delay will not come into picture 

> > which we actually set while entering deep sleep in case of RTC controlled wakeup (Section 10.10.2.1 step 9).

> > Please let me know, whether these understanding is correct?

> 

> The  delay is coming from hardware. Till SLEEPCOUNT completes, the clock to device is not provided. There is no need to poll for SLEEPCOMPLETE and indeed 10.10.2.2 does not ask for this bit to be polled.


Thanks for your explanation.
Ok, I will test this patch with external controlled wakeup and update you.

Regards, 
Manish Badarkhe
diff mbox

Patch

diff --git a/arch/arm/mach-davinci/sleep.S b/arch/arm/mach-davinci/sleep.S
index d4e9316..976f096 100644
--- a/arch/arm/mach-davinci/sleep.S
+++ b/arch/arm/mach-davinci/sleep.S
@@ -35,6 +35,7 @@ 
 #define PLL_LOCK_CYCLES		(PLL_LOCK_TIME * 25)
 
 #define DEEPSLEEP_SLEEPENABLE_BIT	BIT(31)
+#define DEEPSLEEP_SLEEPCOMPLETE_BIT 	BIT(30)
 
 	.text
 /*
@@ -110,6 +111,13 @@  ENTRY(davinci_cpu_suspend)
 
 	/* Wake up from sleep */
 
+	/* wait for sleep complete */
+sleep_complete:
+	ldr 	ip, [r4]
+	and 	ip, ip, #DEEPSLEEP_SLEEPCOMPLETE_BIT
+	cmp 	ip, #DEEPSLEEP_SLEEPCOMPLETE_BIT
+	bne 	sleep_complete
+
 	/* Clear sleep enable */
 	ldr	ip, [r4]
 	bic	ip, ip, #DEEPSLEEP_SLEEPENABLE_BIT