From: rnayak@ti•com (Rajendra Nayak)
To: linux-arm-kernel@lists•infradead.org
Subject: [PATCH] OMAP4: clockdomain: Follow recommended enable sequence
Date: Sat, 12 Mar 2011 13:23:44 +0530 [thread overview]
Message-ID: <4D7B2688.9040506@ti.com> (raw)
In-Reply-To: <871v2dbo3q.fsf@ti.com>
Hi Kevin,
On 3/11/2011 10:17 PM, Kevin Hilman wrote:
> Rajendra Nayak<rnayak@ti•com> writes:
>
> [...]
>
>>>
>>> It's also breaking boot on OMAP35xx BeagleBoard rev C2. The kernel
>>> boot messages are below - omap2plus_defconfig + DEBUG_LL. Reverting
>>> the patch fixes it. Could you please take a look?
>>
>> I got hold of a Beagle, a sticker on which says rev C1D.
>> Not sure if there is a better way to identify the rev, but
>> this one seems to boot fine for me even with this patch.
>> I just applied this one patch on top of the the tag
>> 'integration-2.6.39-20110310-008' of git://git.pwsan.com/linux-
>> integration.
>
> In the process of testing Santosh's OMAP4 PM series (which includes
> $SUBJECT patch) on OMAP3, I also noticed some problems on beagle (mine
> is a C3.)
>
> Specifially, with $SUBJECT patch applied, none of the powerdomains ever
> reach inactive or RET during idle (suspend seems to work fine.)
>
> Just reverting $SUBJECT patch makes things go back to working normally.
>
> I pushed the test branch I used which is a merge of Santosh's v3 branch
> with my pm branch (branch: tmp/santosh-omap4-pm)
>
> I tested by first doing a suspend test and confirming all the
> powerdomains hit retention. That worked fine. Then I did an idle test:
>
> echo 5> /sys/devices/platform/omap/omap_uart.0/sleep_timeout
> echo 5> /sys/devices/platform/omap/omap_uart.1/sleep_timeout
> echo 5> /sys/devices/platform/omap/omap_uart.2/sleep_timeout
> echo 1> /debug/pm_debug/sleep_while_idle
>
> and waited for the UARTs to timeout.
>
> Well after the UART timeouts expired, I do not see any powerdomains
> transitioning from ON.
>
> What's even more strange is that the same thing is working fine on all
> the other OMAP3 platforms I tested: 3430/n900, 3630/zoom3 and even a
> different 3530-based platform, the OMAP3EVM.
I probably know whats going wrong with this patch, even though I
haven't really been able to reproduce any of these issues myself.
The below change which should be the only one affecting non-OMAP4
platforms actually is calling clkdm_allow_idle() for all clkdms
without really checking for a CLKDM_CAN_ENABLE_AUTO flag, which
seems wrong. I was somehow under the impression that the
clkdm_allow_idle() function would internally do this check but
that does not seem to be the case.
+ /* If clockdomain supports hardware control, enable it */
+ if (clk->clkdm)
+ clkdm_allow_idle(clk->clkdm);
I could see that emu_clkdm on OMAP3 is one clockdomain for
which CLKDM_CAN_ENABLE_AUTO is been disabled.
From clockdomains2xxx_3xxx_data.c file..
--------
/*
* Disable hw supervised mode for emu_clkdm, because emu_pwrdm is
* switched of even if sdti is in use
*/
static struct clockdomain emu_clkdm = {
.name = "emu_clkdm",
.pwrdm = { .name = "emu_pwrdm" },
.flags = /* CLKDM_CAN_ENABLE_AUTO | */CLKDM_CAN_SWSUP,
.clktrctrl_mask = OMAP3430_CLKTRCTRL_EMU_MASK,
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430),
};
--------
Maybe programming emu_clkdm in HW_AUTO is the one that shows
up these strange behavior on select BeagleBoard's.
Not sure if this would fix the issue but this does seem
like a necessary fix needed for this patch.
Paul,
To handle this I was thinking of adding another clockdomain
framework api, something like a clkdm_post_clk_enable, to do
the post clock/module enable sequencing of clockdomain
programming. Or is it ok to check for a clockdomain specific
flag in clock framework? Any thoughts?
Now that its too late for this to make it to .39, I can
experiment with this sequence on OMAP2/3 as well and see
if all the autodeps can then be removed.
regards,
Rajendra
>
> Kevin
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2011-03-12 7:53 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-04 13:25 [PATCH] OMAP4: clockdomain: Follow recommended enable sequence Rajendra Nayak
2011-03-09 3:50 ` Paul Walmsley
2011-03-09 10:19 ` Rajendra Nayak
2011-03-09 16:28 ` Kevin Hilman
2011-03-09 21:44 ` Paul Walmsley
2011-03-10 12:18 ` Paul Walmsley
2011-03-10 12:58 ` Rajendra Nayak
2011-03-10 13:16 ` Paul Walmsley
2011-03-10 13:17 ` Paul Walmsley
2011-03-10 13:34 ` Ben Dooks
2011-03-10 13:36 ` Paul Walmsley
2011-03-10 14:39 ` Paul Walmsley
2011-03-11 13:26 ` Rajendra Nayak
2011-03-11 16:47 ` Kevin Hilman
2011-03-12 7:53 ` Rajendra Nayak [this message]
2011-03-14 10:58 ` Rajendra Nayak
2011-03-21 8:51 ` Rajendra Nayak
2011-03-28 17:04 ` Paul Walmsley
2011-03-29 6:55 ` Rajendra Nayak
2011-04-01 14:51 ` Rajendra Nayak
2011-04-01 15:40 ` Rajendra Nayak
2011-04-04 6:47 ` Paul Walmsley
2011-04-04 6:57 ` Santosh Shilimkar
2011-04-05 12:47 ` Rajendra Nayak
2011-03-23 23:29 ` Paul Walmsley
2011-04-20 19:42 ` Paul Walmsley
2011-04-21 4:47 ` Santosh Shilimkar
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=4D7B2688.9040506@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