From: rnayak@ti•com (Rajendra Nayak)
To: linux-arm-kernel@lists•infradead.org
Subject: [PATCHv4 1/6] ARM: OMAP3 PM: correct enable/disable of daisy io chain
Date: Tue, 06 Mar 2012 10:02:56 +0530 [thread overview]
Message-ID: <4F559378.3010204@ti.com> (raw)
In-Reply-To: <alpine.DEB.2.00.1203052103440.6649@utopia.booyaka.com>
On Tuesday 06 March 2012 09:43 AM, Paul Walmsley wrote:
> Hi Rajendra
>
> (thanks for adding in Nilesh, added him again here)
>
> On Tue, 6 Mar 2012, Rajendra Nayak wrote:
>
>> Yes, thats my understanding too, again based on taking to people like
>> Nilesh, because the documentation just doesn't mention this clearly.
>> The 4430 TRM is a tad bit better like you said.
>>
>> I guess your confusion of IO wakeups working with EN_IO_CHAIN set to '0'
>> is also probably coming from the fact that the bit itself is called
>> *EN_IO_CHAIN* which is a completely *wrong* name for the bit, as
>> compared to what it does.
>> That bit is actually used to send a WUCLK pulse through the chain, so
>> you set it to '1' and wait for it to propagate through the chain, then
>> you set it to '0' and again wait for it to propagate through.
>
> Okay. So to confirm: EN_IO_CHAIN doesn't enable a continuous clock, it
> just controls the WUCLKIN line directly?
Right.
>
>> The control to enable/disable is at 2 levels, a global switch which is
>> 'EN_IO' in case of OMAP3 and the one at the individual pad level.
>
> Do you happen to know what EN_IO/GLOBAL_WUEN does? For example, if it's
> 0, will the I/O chain not latch in wakeup events occuring on the pads?
Yes, it wouldn't. Figure 3-74 in OMAP4430_ES2.x Public TRM vO
explains this better.
The WUEN signal to each pad (which can be used to enable IO-daisy
for the given pad) is a AND of a signal from PRCM and
one from SCM.
The signal from PRCM can be enabled by writing into
EN_IO/GLOBAL_WUEN bit.
The signal from SCM can be enabled by writing to the individual
pad registers in SCM
CONTROL.CONTROL_PADCONF_<IOpad>[14] WAKEUPENABLE0
CONTROL.CONTROL_PADCONF_<IOpad>[30] WAKEUPENABLE1.
If either one of them is not enabled the IO wakeups on the pads won't
be latched. So if EN_IO/GLOBAL_WUEN is disabled, none of the pads will
be able to generate IO wakeups.
> Or does it just cause the PRCM to ignore any PRCM wakeups coming from the
> I/O chain? (Or something else, heh)
>
>> You can also read this thread which has some more explanation based on
>> my understanding of how this works
>> http://www.spinics.net/lists/linux-serial/msg04480.html
>
> I've been reading that post; it's been quite helpful.
>
>
> - Paul
next prev parent reply other threads:[~2012-03-06 4:32 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 [this message]
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
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=4F559378.3010204@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