From: Rajendra Nayak <rnayak@ti.com>
To: Paul Walmsley <paul@pwsan.com>
Cc: khilman@ti.com, Todd Poynor <toddpoynor@google.com>,
b-cousson@ti.com, santosh.shilimkar@ti.com,
linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 4/8] OMAP2+: PM: idle clkdms only if already in idle
Date: Mon, 27 Jun 2011 16:36:26 -0700 [thread overview]
Message-ID: <4E0913FA.9030607@ti.com> (raw)
In-Reply-To: <alpine.DEB.2.00.1106270012410.460@utopia.booyaka.com>
Hi Paul,
On 6/26/2011 11:34 PM, Paul Walmsley wrote:
> Hi Rajendra, Todd,
>
> On Fri, 10 Jun 2011, Rajendra Nayak wrote:
>
>> Paul/Benoit any thoughts on if a per-clkdm lock seems reasonable?
>
> Sounds okay to me.
>
> The experimental patch that you sent didn't add the locking to the *wkdep,
> *sleepdep functions; I guess we'd better add it there at the same time,
> since some of the register access there does a read-modify-write.
My initial idea was to just guard the functions which program the
target clockdomain state, since that's something which had a possibility
of racing.
For the sleepdep/wkupdep programming, I thought they are all done from
within frameworks and during pm-core init at boot and might not run into
concurrency issues. But maybe it makes sense to guard those as well.
>
> It should be possible to get rid of the atomic_t usage in the clockdomain
> code as part of the same series.
Sure, I'll get rid of those.
Thanks,
Rajendra
>
> Todd, thanks for pointing this out.
>
>
> - Paul
WARNING: multiple messages have this Message-ID (diff)
From: rnayak@ti.com (Rajendra Nayak)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 4/8] OMAP2+: PM: idle clkdms only if already in idle
Date: Mon, 27 Jun 2011 16:36:26 -0700 [thread overview]
Message-ID: <4E0913FA.9030607@ti.com> (raw)
In-Reply-To: <alpine.DEB.2.00.1106270012410.460@utopia.booyaka.com>
Hi Paul,
On 6/26/2011 11:34 PM, Paul Walmsley wrote:
> Hi Rajendra, Todd,
>
> On Fri, 10 Jun 2011, Rajendra Nayak wrote:
>
>> Paul/Benoit any thoughts on if a per-clkdm lock seems reasonable?
>
> Sounds okay to me.
>
> The experimental patch that you sent didn't add the locking to the *wkdep,
> *sleepdep functions; I guess we'd better add it there at the same time,
> since some of the register access there does a read-modify-write.
My initial idea was to just guard the functions which program the
target clockdomain state, since that's something which had a possibility
of racing.
For the sleepdep/wkupdep programming, I thought they are all done from
within frameworks and during pm-core init at boot and might not run into
concurrency issues. But maybe it makes sense to guard those as well.
>
> It should be possible to get rid of the atomic_t usage in the clockdomain
> code as part of the same series.
Sure, I'll get rid of those.
Thanks,
Rajendra
>
> Todd, thanks for pointing this out.
>
>
> - Paul
next prev parent reply other threads:[~2011-06-27 23:36 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-06-09 10:54 [PATCH 0/8] Fix module-mode enable sequence on OMAP4 Rajendra Nayak
2011-06-09 10:54 ` Rajendra Nayak
2011-06-09 10:54 ` [PATCH 1/8] OMAP2+: clockdomain: Add an api to read idle mode Rajendra Nayak
2011-06-09 10:54 ` Rajendra Nayak
2011-06-09 10:54 ` [PATCH 2/8] OMAP2+: clockdomain: Add SoC support for clkdm_is_idle Rajendra Nayak
2011-06-09 10:54 ` Rajendra Nayak
2011-06-09 10:54 ` [PATCH 3/8] OMAP2+: PM: Initialise sleep_switch to a non-valid value Rajendra Nayak
2011-06-09 10:54 ` Rajendra Nayak
2011-06-09 10:54 ` [PATCH 4/8] OMAP2+: PM: idle clkdms only if already in idle Rajendra Nayak
2011-06-09 10:54 ` Rajendra Nayak
2011-06-09 10:54 ` [PATCH 5/8] OMAP4: PM: TEMP: Prevent l3init from idling/force sleep Rajendra Nayak
2011-06-09 10:54 ` Rajendra Nayak
2011-06-09 10:54 ` [PATCH 6/8] OMAP2+: hwmod: Follow the recomended PRCM clock enable sequence Rajendra Nayak
2011-06-09 10:54 ` Rajendra Nayak
2011-06-09 10:54 ` [PATCH 7/8] OMAP: clock: Add flags to identify optional clock nodes Rajendra Nayak
2011-06-09 10:54 ` Rajendra Nayak
2011-06-09 10:54 ` [PATCH 8/8] OMAP: clock: Enable clockdomain only for optional clocks Rajendra Nayak
2011-06-09 10:54 ` Rajendra Nayak
2011-06-23 15:04 ` [PATCH 5/8] OMAP4: PM: TEMP: Prevent l3init from idling/force sleep Paul Walmsley
2011-06-23 15:04 ` Paul Walmsley
2011-06-23 15:22 ` Russell King - ARM Linux
2011-06-23 15:22 ` Russell King - ARM Linux
2011-07-06 5:30 ` Paul Walmsley
2011-07-06 5:30 ` Paul Walmsley
2011-06-10 0:15 ` [PATCH 4/8] OMAP2+: PM: idle clkdms only if already in idle Todd Poynor
2011-06-10 0:15 ` Todd Poynor
2011-06-10 11:22 ` Rajendra Nayak
2011-06-10 11:22 ` Rajendra Nayak
2011-06-27 6:34 ` Paul Walmsley
2011-06-27 6:34 ` Paul Walmsley
2011-06-27 23:36 ` Rajendra Nayak [this message]
2011-06-27 23:36 ` Rajendra Nayak
2011-06-10 0:07 ` [PATCH 1/8] OMAP2+: clockdomain: Add an api to read idle mode Todd Poynor
2011-06-10 0:07 ` Todd Poynor
2011-06-10 11:08 ` Rajendra Nayak
2011-06-10 11:08 ` Rajendra Nayak
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=4E0913FA.9030607@ti.com \
--to=rnayak@ti.com \
--cc=b-cousson@ti.com \
--cc=khilman@ti.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-omap@vger.kernel.org \
--cc=paul@pwsan.com \
--cc=santosh.shilimkar@ti.com \
--cc=toddpoynor@google.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.