From: jouni.hogander@nokia.com (Högander Jouni)
To: ext Paul Walmsley <paul@booyaka.com>
Cc: linux-omap@vger.kernel.org, rnayak@ti.com
Subject: Re: [RFC] OMAP3: CPUIDLE & PM: Modifications and fixes
Date: Tue, 12 Aug 2008 09:53:13 +0300 [thread overview]
Message-ID: <87wsimd8rq.fsf@trdhcp146196.ntc.nokia.com> (raw)
In-Reply-To: <alpine.DEB.1.00.0808112352430.10219@utopia.booyaka.com> (ext Paul Walmsley's message of "Tue, 12 Aug 2008 00:11:44 -0600 (MDT)")
"ext Paul Walmsley" <paul@booyaka.com> writes:
> Hello Jouni,
>
> On Tue, 12 Aug 2008, Högander Jouni wrote:
>
>> "ext Paul Walmsley" <paul@booyaka.com> writes:
>>
>> > On Mon, 11 Aug 2008, Högander Jouni wrote:
>> >
>> >> "ext Paul Walmsley" <paul@booyaka.com> writes:
>> >>
>> >> > Could you explain a little further why PER would have a wakeup dependency
>> >> > on CORE? Is this something that we should only enable under certain
>> >> > conditions, e.g., latency requirements for a device in PER?
>> >>
>> >> This is done to make sure we don't loose any gpio interrupts: GPIO
>> >> wakeup/interrupt doesn't work for GPIOs in PER domain if PER is not
>> >> active.
>> >
>> > I'm probably misunderstanding something, but ... wouldn't it better to
>> > just keep PER powerdomain ON all the time when PER GPIOs are enabled for
>> > interrupts? It seems possible for PER to go to retention or OFF even with
>> > the CORE wkdep in place, which would result in a period of time where the
>> > interrupts would be missed, no?
>>
>> No, it won't, PER goes sleep state only if CORE goes
>> too. There is a hardware sleepdep between PER and CORE, thanks to
>> Rajendra for pointing this out some time ago. This way there are all
>> the time some wakeup mechanism available for PER gpios
>> (gpio/iopad). Leaving PER ON would increase consumption.
>
> Ah, I see.
>
> Do you think we should add a mechanism for the CORE->PER wkdep to be
> dynamically added and removed, based on whether GPIO2-6 balls are enabled
> in IO pad wakeup? Conceivably a board could just use GPIO1 (in WKUP), and
> PER would not need to be awakened along with CORE in those instances,
> correct?
If gpio irq is enabled also iopad wakeup is enabled for related pad
and wkdep is added. Same thing should be done also for core gpios,
because not all of them are capable to generate wakeup when core is
off. Problem with this is how to know in kernel side to which ball
each gpio is connected. To my understanding muxing is mostly/commonly
done in bootloader. Any idea to this? There seems to be also
enable/disable_irq_wake, where this logic could be connected.
>
>
> - Paul
--
Jouni Högander
--
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
prev parent reply other threads:[~2008-08-12 6:53 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-07-08 11:50 [RFC] OMAP3: CPUIDLE & PM: Modifications and fixes Jouni Hogander
2008-07-08 12:17 ` [RFC] OMAP3: CPUIDLE & PM: Modifications and fixes. Suspend part Jouni Hogander
2008-07-09 6:29 ` [PATCH] OMAP3: CPUIDLE & PM: check_bm fix Jouni Hogander
2008-07-09 6:44 ` Rajendra Nayak
2008-07-09 6:58 ` Högander Jouni
2008-07-09 7:15 ` Rajendra Nayak
2008-07-09 8:05 ` Högander Jouni
2008-07-09 8:35 ` Högander Jouni
2008-07-09 8:38 ` Rajendra Nayak
2008-07-09 13:05 ` Woodruff, Richard
2008-07-10 6:12 ` Högander Jouni
2008-07-10 12:20 ` Woodruff, Richard
2008-07-10 12:53 ` Högander Jouni
2008-07-10 13:00 ` Woodruff, Richard
2008-07-11 12:48 ` Högander Jouni
2008-07-11 13:38 ` Woodruff, Richard
2008-07-10 12:54 ` Woodruff, Richard
2008-07-17 12:16 ` Rajendra Nayak
2008-07-09 8:30 ` [RFC] OMAP3: CPUIDLE & PM: Fix slow serial-console Jouni Hogander
2008-08-11 8:34 ` [RFC] OMAP3: CPUIDLE & PM: Modifications and fixes Paul Walmsley
2008-08-11 11:18 ` Högander Jouni
2008-08-11 17:51 ` Paul Walmsley
2008-08-12 5:48 ` Högander Jouni
2008-08-12 6:11 ` Paul Walmsley
2008-08-12 6:53 ` Högander Jouni [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=87wsimd8rq.fsf@trdhcp146196.ntc.nokia.com \
--to=jouni.hogander@nokia.com \
--cc=linux-omap@vger.kernel.org \
--cc=paul@booyaka.com \
--cc=rnayak@ti.com \
/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