All of lore.kernel.org
 help / color / mirror / Atom feed
From: Santosh Shilimkar <santosh.shilimkar@ti.com>
To: "Pihet-XID, Jean" <j-pihet@ti.com>
Cc: "Cousson, Benoit" <b-cousson@ti.com>,
	Kevin Hilman <khilman@ti.com>,
	Jean Pihet <jean.pihet@newoldbits.com>,
	linux-omap@vger.kernel.org
Subject: Re: [RFC/PATCH] OMAP3: run the ASM sleep code from DDR
Date: Thu, 16 Jun 2011 21:41:22 +0530	[thread overview]
Message-ID: <4DFA2B2A.7060904@ti.com> (raw)
In-Reply-To: <BANLkTimF4Wd7Kgg6a=wL_6b6Rj7uzvkxeg@mail.gmail.com>

On 6/16/2011 9:00 PM, Pihet-XID, Jean wrote:
> Hi Santosh, Benoit, Kevin,
>
> I would like to revive this discussion. Can you give some feedback on
> the self-refresh problem that is proposed in the latest patch from
> Santosh? Cf. below for more details.
>
Comments below.

> On Fri, Feb 4, 2011 at 12:39 PM, Santosh Shilimkar
> <santosh.shilimkar@ti.com>  wrote:
>> Jean,
>>> -----Original Message-----
>>> From: Santosh Shilimkar [mailto:santosh.shilimkar@ti.com]
>>> Sent: Tuesday, February 01, 2011 5:01 PM
>>> To: Jean Pihet
>>> Cc: linux-omap@vger.kernel.org; Jean Pihet-XID
>>> Subject: RE: [RFC/PATCH] OMAP3: run the ASM sleep code from DDR
>>>
>>>> -----Original Message-----
>>>> From: Jean Pihet [mailto:jean.pihet@newoldbits.com]
>>>> Sent: Tuesday, February 01, 2011 4:53 PM
>>>> To: Santosh Shilimkar
>>>> Cc: linux-omap@vger.kernel.org; Jean Pihet-XID
>>>> Subject: Re: [RFC/PATCH] OMAP3: run the ASM sleep code from DDR
>>>>
>>>
>>> [...]
>>>>>> Does that makes sense?
>>>>>>
>>>>> Actually not. Rather I will separate only the scenario's
>>>>> where CORE low power targets are attempted and only have
>>>>> that code run from SRAM.
>>>>>
>>>>> There are scenario's where CORE can be active because MODEM,
>>>>> DSP and MPU can still hit RET, OFF. And here, the errata
>>>>> isn't applicable.
>>>>>
>>>>> Unless I missed something here, I think in the code we check
>>>>> the the CORE attempted state and based on that we can do a
>>>>> normal WFI from DDR (no self rfersh) or WFI from
>>>>> SRAM with self refresh enabled.
>>>> No. Only the MPU attempted state is checked (this actually is the
>>>> 'save_state' parameter passed to omap_cpu_suspend).
>>>> So it makes sense to check the CORE attempted state in order to
>>>> decide
>>>> to run the WFI from internal SRAM or DDR.
>>>>
>>>> The MPU attempted state is used to decide whether to save the
>>>> MPU/L1/L2 context.
>>>>
>>> Looks like you miss-understood my point. As I understand from
>>> errata, as long as core clock domain can idle with core
>>> dpll divider auto idle enabled, the errata is applicable.
>>>
>>> So the only check needed is to see if the core clockdomain
>>> hw_auto or sw sleep is enabled.
>>>
>>> If it is suppose to be not idle(we force few C-states
>>> where CORE inactive is avoided for faster response),
>>> we can execute WFI from DDR with not enabling
>>> self refresh.
> Is this the way to go?
>
I think so considering we need C-states for
faster responses as well.

>>>
>>> Rest of the scenario can follow the SRAM path.
>>>
>>> Hope this is clear to you.
>>
>> As per further discussion, I have updated your
>> patch to address above by using core clockdomain
>> state.
>>
>> Have tested OFF and RET with this new update and they
>> work as expected. Feel free to update further if needed.
>>
>> ------
>>  From 49fe8164a40431807495638ec23639cc9bc53cb9 Mon Sep 17 00:00:00 2001
>> From: Jean Pihet<j-pihet@ti.com>
>> Date: Sat, 29 Jan 2011 20:51:19 +0530
>> Subject: [PATCH] OMAP3: run the ASM sleep code from DDR
> ...
>
>>
>> -omap3_do_wfi:
>> +do_WFI:
>> +       ldr     r4, cm_clkstctrl_core   @ read the CLKSTCTRL_CORE
>> +       ldr     r5, [r4]                @ read the contents of
>> CLKSTCTRL_CORE
>> +       and     r5, r5, #0x3
>> +       cmp     r5, #0x3
>> +       beq     omap3_do_wfi            @ Jumpt to SRAM function
>> +       mov     r1, #0
>> +       mcr     p15, 0, r1, c7, c10, 4
>> +       mcr     p15, 0, r1, c7, c10, 5
>> +
>> +       wfi                             @ wait for interrupt
>> +
>> +       ldmfd   sp!, {r0-r12, pc}       @ restore regs and return
>
> This code has a few problems:
> - there now are 2 wfi instructions, which I would like to avoid for
> readability and maintainability,
> - are the mcr instructions needed here? From
> arch/arm/include/asm/system.h it seems those are not needed for
> __LINUX_ARM_ARCH__>= 7
The are barriers and in my clean-up I have already fixed them.
Your patch is bit old so has those things. Once you
refresh your patch against mainline, this can be simply
converted to DSB and DMB.

>
> Furthermore the main point of discussion to me is: is it advised to go
> into wfi without self refresh requested? Can anyone confirm this?
>
You can provided you ensure that CORE and SDRC can't idle.

I suggest you to create a patch against mainline and then we
take it from there.

Regards
Santosh

  reply	other threads:[~2011-06-16 16:11 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-01-13 16:19 [RFC/PATCH] OMAP3: run the ASM sleep code from DDR jean.pihet
2011-01-24 14:29 ` Jean Pihet
2011-01-27 10:13   ` Vishwanath Sripathy
2011-01-27 13:50     ` Jean Pihet
2011-01-29 17:14 ` Santosh Shilimkar
2011-01-30  5:57   ` Santosh Shilimkar
2011-01-31 10:36     ` Jean Pihet
2011-01-31 11:00       ` Santosh Shilimkar
2011-02-01 11:23         ` Jean Pihet
2011-02-01 11:31           ` Santosh Shilimkar
2011-02-04 11:39             ` Santosh Shilimkar
2011-06-16 15:30               ` Pihet-XID, Jean
2011-06-16 16:11                 ` Santosh Shilimkar [this message]
2011-06-17  8:58                   ` Jean Pihet
2011-06-17  9:13                     ` Santosh Shilimkar
2011-06-17 15:59                       ` Kevin Hilman
2011-06-17 16:50                         ` Santosh Shilimkar

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4DFA2B2A.7060904@ti.com \
    --to=santosh.shilimkar@ti.com \
    --cc=b-cousson@ti.com \
    --cc=j-pihet@ti.com \
    --cc=jean.pihet@newoldbits.com \
    --cc=khilman@ti.com \
    --cc=linux-omap@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.