From: Kevin Hilman <khilman@ti.com>
To: Paul Walmsley <paul@pwsan.com>
Cc: linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org
Subject: Re: DSS and USBHOST powerdomains not entering low-power states on 37xx EVM
Date: Tue, 07 Aug 2012 13:48:02 -0700 [thread overview]
Message-ID: <87628u2zul.fsf@ti.com> (raw)
In-Reply-To: <alpine.DEB.2.00.1208070401530.21945@utopia.booyaka.com> (Paul Walmsley's message of "Tue, 7 Aug 2012 04:05:33 -0600 (MDT)")
Paul Walmsley <paul@pwsan.com> writes:
> Hi Kevin,
>
> On Mon, 6 Aug 2012, Kevin Hilman wrote:
>
>> Is this only happening on this 37xx platform? Just curious, because
>> it seems to be a problem on any OMAP3xxx SoC.
>
> So far I've only run the baseline tests on 37xx, so wanted to state only
> what was observed here.
>
>> ...it must be the usecounts that are not being updated. This seems to
>> be a side effect of the pre/post transition optimization I did. A quick
>> hack seems to indicate that that's indeed the case[1]. By default,
>> omap_sram_idle() is now only calling the pre/post callbacks for MPU,
>> NEON, PER, and CORE, and only if those domains are transitioning, so any
>> other domains not explicitly managed by the idle path have lots their
>> usecounting. Oops.
>>
>> I guess Tero's usecounting series should fix this up.
>
> Thanks for the diagnosis. Care to put together a patch to fix this for
> v3.6-rc?
Done.
http://marc.info/?l=linux-omap&m=134437239010649&w=2
Kevin
WARNING: multiple messages have this Message-ID (diff)
From: khilman@ti.com (Kevin Hilman)
To: linux-arm-kernel@lists.infradead.org
Subject: DSS and USBHOST powerdomains not entering low-power states on 37xx EVM
Date: Tue, 07 Aug 2012 13:48:02 -0700 [thread overview]
Message-ID: <87628u2zul.fsf@ti.com> (raw)
In-Reply-To: <alpine.DEB.2.00.1208070401530.21945@utopia.booyaka.com> (Paul Walmsley's message of "Tue, 7 Aug 2012 04:05:33 -0600 (MDT)")
Paul Walmsley <paul@pwsan.com> writes:
> Hi Kevin,
>
> On Mon, 6 Aug 2012, Kevin Hilman wrote:
>
>> Is this only happening on this 37xx platform? Just curious, because
>> it seems to be a problem on any OMAP3xxx SoC.
>
> So far I've only run the baseline tests on 37xx, so wanted to state only
> what was observed here.
>
>> ...it must be the usecounts that are not being updated. This seems to
>> be a side effect of the pre/post transition optimization I did. A quick
>> hack seems to indicate that that's indeed the case[1]. By default,
>> omap_sram_idle() is now only calling the pre/post callbacks for MPU,
>> NEON, PER, and CORE, and only if those domains are transitioning, so any
>> other domains not explicitly managed by the idle path have lots their
>> usecounting. Oops.
>>
>> I guess Tero's usecounting series should fix this up.
>
> Thanks for the diagnosis. Care to put together a patch to fix this for
> v3.6-rc?
Done.
http://marc.info/?l=linux-omap&m=134437239010649&w=2
Kevin
next prev parent reply other threads:[~2012-08-07 20:48 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-03 20:05 DSS and USBHOST powerdomains not entering low-power states on 37xx EVM Paul Walmsley
2012-08-03 20:05 ` Paul Walmsley
2012-08-06 21:31 ` Kevin Hilman
2012-08-06 21:31 ` Kevin Hilman
2012-08-07 10:05 ` Paul Walmsley
2012-08-07 10:05 ` Paul Walmsley
2012-08-07 20:48 ` Kevin Hilman [this message]
2012-08-07 20:48 ` 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=87628u2zul.fsf@ti.com \
--to=khilman@ti.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-omap@vger.kernel.org \
--cc=paul@pwsan.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 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.