From: Kevin Hilman <khilman@ti.com>
To: "Munegowda, Keshava" <keshava_mgowda@ti.com>
Cc: Felipe Balbi <balbi@ti.com>, linux-omap <linux-omap@vger.kernel.org>
Subject: Re: MFD USB host: prevents CORE retention in idle
Date: Thu, 24 May 2012 10:02:26 -0700 [thread overview]
Message-ID: <871um9wlzx.fsf@ti.com> (raw)
In-Reply-To: <CAP05o4KNnrKdmgJ=Ky=MS4pwEoEErH+Agkm2EwN1i1UDb-CbPQ@mail.gmail.com> (Keshava Munegowda's message of "Thu, 24 May 2012 12:35:35 +0530")
"Munegowda, Keshava" <keshava_mgowda@ti.com> writes:
> On Thu, May 24, 2012 at 5:55 AM, Kevin Hilman <khilman@ti.com> wrote:
>> On 05/23/2012 05:01 PM, Kevin Hilman wrote:
>>>
>>> Hi Keshava,
>>>
>>> Using current l-o master, I noticed that CORE was not hitting retention
>>> in idle on my 3530/Overo. CORE hits retention on suspend just fine.
>>>
>>> Debugging this, I found that usbtll_fck was still enabled during idle,
>>> thus preventing CORE from hitting retention.
>>>
>>> To test, I disabled USB host (CONFIG_MFD_OMAP_USB_HOST=n in .config) and
>>> was then started seeing CORE hit retention in idle again.
>>>
>>> I have nothing plugged into the USB host port on this board, so I
>>> would've expected that runtime PM would've kicked in and shutdown this
>>> clock.
>>>
>>> Any ideas what's going on here? Is this expected behavior?
>>>
>>
>> If it helps, attached is a bootlog after enabling debug for
>> mfd/omap-usb-host.c as well. Notice there's a couple of clock-related
>> warnings from this driver as well. Not sure if they're relevant:
>>
>> usbhs_omap: alias fck already exists
>> usbhs_omap usbhs_omap: xclk60mhsp2_ck set parentfailed error:-22
>
> these clocks were specific to omap4 and it should not cause any
> problem to omap3 boards.
OK, they seem unrelated to this CORE retention problem, but the warnings
should still be understood and fixed.
> I will try to reproduce this on 3430 sdp to explore further.
Thanks for looking. Note that I only saw this problem on my 3530
platforms (Overo, OMAP3EVM.) My 3430/n900 doesn't support USBHS host
AFAICT, so didn't test there.
FYI, in order to hit core retention, there's another bug in mainline
where the counter_32k IP also prevents retention. You'll need the hack
below[1] (on top of l-o master) to workaround this problem (real patch
with description will be coming soon.)
Also, you'll likely need the UART mux patch from Govindraj[2]. Without
this, UARTs in CORE may have runtime PM disabled, and thus also prevent
CORE from hitting retention.
Kevin
[1]
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index 840929b..42eb39d 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -292,6 +292,7 @@ static int __init omap2_sync32k_clocksource_init(void)
__func__, ret);
return ret;
}
+ omap_hwmod_set_slave_idlemode(oh, SIDLE_FORCE);
ret = omap_init_clocksource_32k(vbase);
if (ret) {
[2] http://marc.info/?l=linux-omap&m=133672962809100&w=2
--
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
next prev parent reply other threads:[~2012-05-24 17:02 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-24 0:01 MFD USB host: prevents CORE retention in idle Kevin Hilman
2012-05-24 0:25 ` Kevin Hilman
2012-05-24 7:05 ` Munegowda, Keshava
2012-05-24 17:02 ` Kevin Hilman [this message]
2012-05-24 22:13 ` Kevin Hilman
2012-06-05 17:50 ` Kevin Hilman
[not found] ` <CAP05o4L+0E6fa1VoP_UPTJgKjXb-VqZorUfzsTB3d-KVoFrXfw@mail.gmail.com>
[not found] ` <CAP05o4KuoQHhTRTCtdpiywgC1HjwzXZHhROKOgSLhoK76Z2aaQ@mail.gmail.com>
[not found] ` <87fwa56gxp.fsf@ti.com>
[not found] ` <CAP05o4JEEp-yXjijeeejN3j8uVBDQ35DMGqP9UKj3f7sNnO8LA@mail.gmail.com>
[not found] ` <CAP05o4LYhFQpEFukyCT2fA7XHPU2L5K8=8W0fncMJk6YEUWdOQ@mail.gmail.com>
2012-06-15 12:04 ` Munegowda, Keshava
2012-06-15 13:47 ` Jean Pihet
2012-06-18 8:09 ` Munegowda, Keshava
2012-06-19 18:02 ` Kevin Hilman
2012-06-20 6:23 ` Munegowda, Keshava
2012-06-20 9:29 ` Munegowda, Keshava
2012-06-20 14:23 ` Kevin Hilman
2012-06-21 7:12 ` Munegowda, Keshava
2012-06-21 10:47 ` Grazvydas Ignotas
2012-06-21 18:32 ` 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=871um9wlzx.fsf@ti.com \
--to=khilman@ti.com \
--cc=balbi@ti.com \
--cc=keshava_mgowda@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.