From: Santosh Shilimkar <santosh.shilimkar@ti.com>
To: Kevin Hilman <khilman@ti.com>
Cc: Jean Pihet <jean.pihet@newoldbits.com>,
"Cousson, Benoit" <b-cousson@ti.com>,
linux-omap@vger.kernel.org
Subject: Re: [RFC/PATCH] OMAP3: run the ASM sleep code from DDR
Date: Fri, 17 Jun 2011 22:20:08 +0530 [thread overview]
Message-ID: <4DFB85C0.7040606@ti.com> (raw)
In-Reply-To: <87aadgcuu7.fsf@ti.com>
On 6/17/2011 9:29 PM, Kevin Hilman wrote:
> Hi Santosh,
>
> Santosh Shilimkar<santosh.shilimkar@ti.com> writes:
>
>> On 6/17/2011 2:28 PM, Jean Pihet wrote:
>>> Hi Santosh,
>>>
>>
>> [....]
>>
>>
>>>>>> -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
>>>>>
>>
>> [....]
>>
>>>>> 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.
>>>
>>> Re-pushed an updated patch on l-o ML: '[PATCH] OMAP3: run the ASM
>>> sleep code from DDR'.
>>>
>> Thanks. We needed this to be in mainline.
>>
>>> I deliberately omitted the code for WFI transition without
>>> self-refresh because of the reasons mentioned here above and repeated
>>> here (quoting myself):
>>> "The DDR self refresh is enabled at each WFI but not necessarily hit.
>>> It is actually triggered by the CORE idle request which depends on the
>>> settings, the dependencies, the HW states... For example the CORE
>>> state depends on the MPU state so if the MPU stays ON running
>>> instructions the CORE will stay ON as well.
>>>
>>> Also the code in wait_sdrc_ok will exit quicker if the CORE DPLL is
>>> already locked, e.g. if the CORE did not hit a low power state. Since
>>> the actual CORE hit state is unknow after wake-up from WFI the
>>> wait_sdrc_ok code always run at wake-up from MPU RET.
>>> "
>>>
>> What is written here is completely right and I never said
>> anything against it. What I mentioned is if the CORE
>> clock-domain is under HW supervision, SDRC can idle
>> and hence the DDR can enter into self refresh.
>>
>> Ofocurse on OMAP3 all clock-domain has static deps set
>> and hence above assumption is ok. The update I mentioned
>> in the code will make it complete even without auto-dep
>> assumption.
>>
>> Anyways if that is the only point we are contesting, I
>> am OK to not have that change part of the patch because
>> it would work becasuse of auto-deps.
>
> Sorry I haven't followed the whole thread...
>
> Can you please clarify what would need to be updated if auto-deps were
> removed? We are hoping to remove them when we have full hwmod
> conversion.
>
Sure.
I sent an update on Jean's original patch to check the CORE clock
domain state(HW_SUP or SW_WKUP). If we are in HW_SUP and the SDRC
self refresh bit enabled, SDRC can idle along with CORE. So
in that case and _only_ that case we need to execute WFI from
SRAM. I thought that's a right way to go and not depend on
auto-deps.
Jean in his refreshed patch dropped that update
with above auto-dep reasoning. For sure, with autodep
set, we won't need that additional logic because
CORE CD can never IDLE without MPU CD being in idle.
Regards
Santosh
prev parent reply other threads:[~2011-06-17 16:50 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
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 [this message]
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=4DFB85C0.7040606@ti.com \
--to=santosh.shilimkar@ti.com \
--cc=b-cousson@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox