From: Archit Taneja <archit@ti.com>
To: Rajendra Nayak <rnayak@ti.com>
Cc: Benoit Cousson <b-cousson@ti.com>,
Tomi Valkeinen <tomi.valkeinen@ti.com>,
paul@pwsan.com, linux-omap@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, "Turquette,
Mike" <mturquette@ti.com>
Subject: Re: OMAP4 clock/pm fixes [was: [PATCH v4 2/3] ARM: omap: hwmod: get rid of all omap_clk_get_by_name usage
Date: Fri, 5 Oct 2012 18:50:51 +0530 [thread overview]
Message-ID: <506EDEB3.3050003@ti.com> (raw)
In-Reply-To: <506ED492.5010709@ti.com>
On Friday 05 October 2012 06:07 PM, Rajendra Nayak wrote:
> On Friday 05 October 2012 05:59 PM, Archit Taneja wrote:
>> The other not so good option to make DSS PM work would be to add
>> OCPIF_SWSUP_IDLE flag to our l3_main_2__dss_* slave interfaces(which
>> have the hack "dss_fck" as slave clock). I gave this approach a try,
>> that too isn't working so well. When I disable DSS, I get
>> CM_DSS_DSS_CLKCTRL.IDLEST as 0x1, and
>> CM_DSS_CLKSTCTRL.CLKACTIVITY_DSS_L3_ICLK is set. I wonder why that's
>> happening.
>
> I have seen DSS get stuck in transition, with just a clkdm state toggle
> (from say HWSUP to SWWKUP) while its optional clocks are not running.
> Thats probably whats happening now.
Oh ok, I can notice that too. So in the _idle() path, the clocks are
disabled first, and then we try to change the clkdm state. I guess that
could be the reason why DSS doesn't sleep.
But then, I don't understand why this problem isn't seen if I try the
alternative option of removing the fake dss_fck slave clock, and tie
modulemode to only the parent hwmod. There DSS IDLEST is 0x3 when I
disable DSS.
I think with this approach, the problem is with _disable_clocks(), in
disable_clocks, main_clk is disabled first, and then the slave clocks.
That translates to DSS_FCK opt clock getting disabled first, and then
MODULEMODE bits. I think DSS doesn't transition to sleep with this
disable sequence.
>
> Did you try keeping the modulemode enabled and see if it really gates
> DSS/system sleep. I remember testing with Teros CORE ret/off patches
> and I was always seeing DSS modulemode enabled but it wasn't gating
> sleep.
If the clkdm is in HW_AUTO, I can get DSS in sleep(STBYST and IDLEST all
set). Is this helpful? Can we just leave modulemode on all the time?
That'll be the best :)
Anyway, I guess it would be the best to have a custom _setup function(or
skip them all together) for DSS as Benoit suggested.
Archit
next prev parent reply other threads:[~2012-10-05 13:21 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-29 8:56 [PATCH v4 0/3] Prepare for OMAP2+ movement to Common Clk Rajendra Nayak
2012-08-29 8:56 ` [PATCH v4 1/3] ARM: omap: clk: add clk_prepare and clk_unprepare Rajendra Nayak
2012-08-30 0:03 ` Turquette, Mike
2012-08-29 8:56 ` [PATCH v4 2/3] ARM: omap: hwmod: get rid of all omap_clk_get_by_name usage Rajendra Nayak
2012-08-30 0:08 ` Russell King - ARM Linux
2012-08-30 8:37 ` Rajendra Nayak
2012-08-30 0:15 ` Turquette, Mike
2012-08-30 8:39 ` Rajendra Nayak
2012-08-30 11:57 ` Benoit Cousson
2012-08-30 16:42 ` Tomi Valkeinen
2012-08-31 6:23 ` Archit Taneja
2012-08-31 7:15 ` Tomi Valkeinen
2012-08-31 8:20 ` Archit Taneja
2012-08-31 8:27 ` Tomi Valkeinen
2012-08-31 8:28 ` Archit Taneja
2012-10-05 9:46 ` OMAP4 clock/pm fixes [was: " Archit Taneja
2012-10-05 12:20 ` Benoit Cousson
2012-10-05 12:29 ` Archit Taneja
2012-10-05 12:37 ` Rajendra Nayak
2012-10-05 13:20 ` Archit Taneja [this message]
2012-10-05 13:31 ` Rajendra Nayak
2012-10-05 13:46 ` Archit Taneja
2012-10-05 13:51 ` Benoit Cousson
2012-09-22 18:55 ` Paul Walmsley
2012-09-24 5:09 ` Rajendra Nayak
2012-08-29 8:56 ` [PATCH v4 3/3] ARM: OMAP2+: clock: Remove all direct dereferencing of struct clk Rajendra Nayak
2012-08-30 20:56 ` [PATCH v4 0/3] Prepare for OMAP2+ movement to Common Clk Paul Walmsley
2012-08-31 5:03 ` Vaibhav Hiremath
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=506EDEB3.3050003@ti.com \
--to=archit@ti.com \
--cc=b-cousson@ti.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-omap@vger.kernel.org \
--cc=mturquette@ti.com \
--cc=paul@pwsan.com \
--cc=rnayak@ti.com \
--cc=tomi.valkeinen@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).