From: rnayak@ti•com (Rajendra Nayak)
To: linux-arm-kernel@lists•infradead.org
Subject: [PATCHv4 4/6] ARM: OMAP3+: PRM: Enable IO wake up
Date: Tue, 06 Mar 2012 10:26:03 +0530 [thread overview]
Message-ID: <4F5598E3.4050506@ti.com> (raw)
In-Reply-To: <4F55978C.7030407@ti.com>
On Tuesday 06 March 2012 10:20 AM, Rajendra Nayak wrote:
> On Tuesday 06 March 2012 09:51 AM, Paul Walmsley wrote:
>> added Rajendra, Nilesh, Vishwa, Mohan
>>
>> Hi
>>
>> On Fri, 2 Mar 2012, Tero Kristo wrote:
>>
>>> Enable IO Wake up for OMAP3/4 as part of PRM Init. Currently this has
>>> been
>>> managed in cpuidle path which is not the right place. Subsequent patch
>>> will remove IO Daisy chain handling in cpuidle path once daisy chain is
>>> handled as part of hwmod mux. This patch also moves the OMAP4 IO wakeup
>>> enable code from the trigger function to init time setup.
>>>
>>> Signed-off-by: Tero Kristo<t-kristo@ti•com>
>>
>> Should we keep the I/O wakeups enabled all the time?
>>
>> Seems like that could result in at least one spurious wake-up event --
>> and
>> thus a PRCM interrupt -- for each I/O pad that has WAKEUPENABLE set.
>> Seems like these interrupts could recur every time the I/O chain is
>> reset.
>> And that the I/O chain is now reset in every hwmod idle and enable
>> operation for an IP block that contains dynamic mux data?
>>
>> Thinking about the problem na?vely... maybe you all can think through
>> this
>> with me:
>>
>> Consider an IP block 'A' that has a signal (like the UART rx_irrx signal)
>> that's mux'ed to a pad with WAKEUPENABLE set. (Some examples of 'A' might
>> include a UART, a GPIO, or a McBSP.)
>>
>> Shouldn't we enable I/O wakeups (by setting EN_IO/GLOBAL_WUEN) only
>> immediately before the powerdomain containing IP block 'A' is going to
>> transition into RETENTION or OFF?
>
> Hi Paul,
>
> I completely agree with your observations and we knew we would have
> additional wakeups with this design. Like I mentioned in the other
> thread, we went ahead with this approach knowing we need to optimize
> with some kind of powerdomain level usecounting in the future, because
> it didn't exist back then when we did it this way.
> But now that we already have it, maybe we can fix this and do
> it such that we completely avoid an additional wakeup interrupt.
>
>>
>> If we do that, then we can avoid needlessly resetting the I/O chain
>> when a
>> powerdomain is not going to go into a low-power state.
>>
>> I haven't measured the time it takes for the I/O chain to be reset.
>> Maybe one of you have. But that 100 microsecond timeout that was
>> specified in two of the other patches in this series has me a little
>> worried.
>
> I haven't profiled it myself but I am guessing the delay isn't much.
Having said that, I do agree with you that, however small the delay,
we end up doing needless IO trigger when the powerdomain isn't
really entering a low power state.
> The 100us comes from the fact that there is no documentation on the
> exact delay, so went around asking whats the *real worst case* delay,
> and we got an answer, 100us should be really big enough :)
>
> regards,
> Rajendra
>
>>
>>
>> - Paul
>
next prev parent reply other threads:[~2012-03-06 4:56 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-02 15:17 [PATCHv4 0/6] ARM: OMAP3+: IO daisychain support fixes Tero Kristo
2012-03-02 15:17 ` [PATCHv4 1/6] ARM: OMAP3 PM: correct enable/disable of daisy io chain Tero Kristo
2012-03-06 2:59 ` Paul Walmsley
2012-03-06 3:53 ` Rajendra Nayak
2012-03-06 3:59 ` Rajendra Nayak
2012-03-06 4:13 ` Paul Walmsley
2012-03-06 4:32 ` Rajendra Nayak
2012-03-02 15:17 ` [PATCHv4 2/6] ARM: OMAP3 PM: Move IO Daisychain function to omap3 prm file Tero Kristo
2012-03-06 5:44 ` Nishanth Menon
2012-03-06 6:00 ` Rajendra Nayak
2012-03-06 8:41 ` Tero Kristo
2012-03-02 15:17 ` [PATCHv4 3/6] ARM: OMAP4 PM: Add IO Daisychain support Tero Kristo
2012-03-02 15:17 ` [PATCHv4 4/6] ARM: OMAP3+: PRM: Enable IO wake up Tero Kristo
2012-03-06 4:21 ` Paul Walmsley
2012-03-06 4:50 ` Rajendra Nayak
2012-03-06 4:56 ` Rajendra Nayak [this message]
2012-03-06 8:44 ` Tero Kristo
2012-03-06 14:10 ` Tero Kristo
2012-03-02 15:17 ` [PATCHv4 5/6] ARM: OMAP3PLUS PM: Add IO Daisychain support via hwmod mux Tero Kristo
2012-03-06 4:02 ` Paul Walmsley
2012-03-06 4:21 ` Rajendra Nayak
2012-03-06 8:51 ` Tero Kristo
2012-03-02 15:17 ` [PATCHv4 6/6] ARM: OMAP3 PM: Remove IO Daisychain control from cpuidle Tero Kristo
2012-03-05 10:01 ` [PATCHv4 0/6] ARM: OMAP3+: IO daisychain support fixes Rajendra Nayak
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=4F5598E3.4050506@ti.com \
--to=rnayak@ti$(echo .)com \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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