From: Kevin Hilman <khilman@deeprootsystems.com>
To: Paul Walmsley <paul@pwsan.com>
Cc: Tero Kristo <t-kristo@ti.com>,
linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
Benoit Cousson <b-cousson@ti.com>,
Venkatraman S <svenkatr@ti.com>
Subject: Re: [RFC] ARM: OMAP: hwmod: wait for sysreset complete after enabling hwmod
Date: Tue, 23 Oct 2012 07:28:12 -0700 [thread overview]
Message-ID: <87txtlb6v7.fsf@deeprootsystems.com> (raw)
In-Reply-To: <alpine.DEB.2.00.1210230745160.32436@utopia.booyaka.com> (Paul Walmsley's message of "Tue, 23 Oct 2012 07:47:44 +0000 (UTC)")
Paul Walmsley <paul@pwsan.com> writes:
> Hi Tero,
>
> On Mon, 22 Oct 2012, Tero Kristo wrote:
>
>> When waking up from off-mode, some IP blocks are reset automatically by
>> hardware. For this reason, software must wait until the reset has
>> completed before attempting to access the IP block.
>>
>> This patch fixes for example the bug introduced by commit
>> 6c31b2150ff96755d24e0ab6d6fea08a7bf5c44c ("mmc: omap_hsmmc: remove access
>> to SYSCONFIG register"), in which the MMC IP block is reset during
>> off-mode entry, but the code expects the module to be already available
>> during the execution of context restore.
>>
>> Signed-off-by: Tero Kristo <t-kristo@ti.com>
>> Cc: Paul Walmsley <paul@pwsan.com>
>> Cc: Benoit Cousson <b-cousson@ti.com>
>> Cc: Venkatraman S <svenkatr@ti.com>
>
> What do you think about these modifications? The code is quite similar to
> what was in the _ocp_softreset() function, so just moved it into a
> function. Also moved the callsite from the end of _enable_sysc() to the
> beginning, which makes more sense to me, but would like to get your
> opinion.
FYI, after some more testing with this patch, I noticed that this patch
(and the original from Tero) cause some sluggishness on UART1 console my
37xx/EVM platform as soon as off-mode is enabled (even without the UART
autosuspend timeouts enabled.) I don't see this on any other OMAP3
platform but all the others I have have UART3 console (in PER), the EVM
is the only one with UART1 console (in CORE.)
I haven't debugged this any furhter, but thought it should be reported
before this gets merged.
Kevin
next prev parent reply other threads:[~2012-10-23 14:27 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-22 16:15 [RFC] ARM: OMAP: hwmod: wait for sysreset complete after enabling hwmod Tero Kristo
2012-10-22 21:46 ` Kevin Hilman
2012-10-23 15:43 ` Shubhrajyoti Datta
2012-10-23 16:09 ` Kevin Hilman
2012-10-23 17:50 ` Shubhrajyoti Datta
2012-10-23 7:47 ` Paul Walmsley
2012-10-23 8:03 ` Tero Kristo
2012-10-30 3:11 ` Paul Walmsley
2012-10-23 14:28 ` Kevin Hilman [this message]
2012-10-23 14:49 ` Santosh Shilimkar
2012-10-23 17:03 ` Kevin Hilman
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=87txtlb6v7.fsf@deeprootsystems.com \
--to=khilman@deeprootsystems.com \
--cc=b-cousson@ti.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-omap@vger.kernel.org \
--cc=paul@pwsan.com \
--cc=svenkatr@ti.com \
--cc=t-kristo@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;
as well as URLs for NNTP newsgroup(s).