From: Tero Kristo <t-kristo@ti.com>
To: Russell King - ARM Linux <linux@arm.linux.org.uk>
Cc: linux-omap@vger.kernel.org, paul@pwsan.com, khilman@ti.com,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCHv5 02/10] ARM: OMAP3+: voltage: add support for voltagedomain usecounts
Date: Tue, 25 Sep 2012 15:02:35 +0300 [thread overview]
Message-ID: <1348574555.10702.298.camel@sokoban> (raw)
In-Reply-To: <20120925094100.GK31374@n2100.arm.linux.org.uk>
On Tue, 2012-09-25 at 10:41 +0100, Russell King - ARM Linux wrote:
> On Tue, Sep 25, 2012 at 12:32:37PM +0300, Tero Kristo wrote:
> > diff --git a/arch/arm/mach-omap2/powerdomain.c b/arch/arm/mach-omap2/powerdomain.c
> > index ba49029..ca54aec 100644
> > --- a/arch/arm/mach-omap2/powerdomain.c
> > +++ b/arch/arm/mach-omap2/powerdomain.c
> > @@ -1475,10 +1477,16 @@ int pwrdm_state_switch(struct powerdomain *pwrdm)
> > */
> > void pwrdm_clkdm_enable(struct powerdomain *pwrdm)
> > {
> > + unsigned long flags;
> > +
> > if (!pwrdm)
> > return;
> >
> > - atomic_inc(&pwrdm->usecount);
> > + if (atomic_inc_return(&pwrdm->usecount) == 1) {
> > + spin_lock_irqsave(&pwrdm->lock, flags);
> > + voltdm_pwrdm_enable(pwrdm->voltdm.ptr);
> > + spin_unlock_irqrestore(&pwrdm->lock, flags);
> > + }
>
> This looks like the classic "I like atomic types because they have magic
> properties" brain-deadness.
Hi Russell,
Thats a good catch, I was actually thinking about this sequence myself
also, but decided to leave it as is here due to similarity with the
existing code in mach-omap2/clockdomain.c, see e.g.
_clkdm_clk_hwmod_enable. Maybe those parts should be fixed also...?
>
> What would happen to users of this if you had this sequence:
>
> pwrdm->usecount starts off as 1.
>
> Thread0 Thread1
> atomic_inc_return() (returns 1)
> atomic_inc_return() (returns 2)
> starts using stuff in power domain
> spin_lock_irqsave()
> voltdm_pwrdm_enable()
> spin_unlock_irqrestore()
>
> ?
That as such wouldn't break anything, as the callback isn't doing
anything too critical, but yes, for the sequencing of events it is bad.
The alternate implementation I was thinking was to drop the atomic_t and
just use an int for the usecount, and protect the usecount also with the
spinlock. However, there might be some performance issues if this is
done (but I think it is actually better than having some rather
mysterious bugs instead.)
-Tero
next prev parent reply other threads:[~2012-09-25 12:02 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-25 9:32 [PATCHv5 00/10] ARM: OMAP: PM usecounting changes Tero Kristo
2012-09-25 9:32 ` [PATCHv5 01/10] ARM: OMAP3+: voltage/pwrdm/clkdm/clock add recursive usecount tracking Tero Kristo
2012-09-25 9:32 ` [PATCHv5 02/10] ARM: OMAP3+: voltage: add support for voltagedomain usecounts Tero Kristo
2012-09-25 9:41 ` Russell King - ARM Linux
2012-09-25 12:02 ` Tero Kristo [this message]
2012-09-25 9:32 ` [PATCHv5 03/10] ARM: OMAP3: add manual control for mpu / core pwrdm usecounting Tero Kristo
2012-09-25 9:32 ` [PATCHv5 04/10] ARM: OMAP3: set autoidle flag for sdrc_ick Tero Kristo
2012-09-25 9:32 ` [PATCHv5 05/10] ARM: OMAP: clockdomain: add support for preventing autodep delete Tero Kristo
2012-09-25 9:32 ` [PATCHv5 06/10] ARM: OMAP3: do not delete per_clkdm autodeps during idle Tero Kristo
2012-09-25 9:32 ` [PATCHv5 07/10] ARM: OMAP4: clock data: set autoidle flag for dss_fck Tero Kristo
2012-09-25 9:32 ` [PATCHv5 08/10] ARM: OMAP4: hwmod: add support for hwmod autoidle flag Tero Kristo
2012-09-25 9:32 ` [PATCHv5 09/10] ARM: OMAP4: hwmod data: set mpu hwmod modulemode to hwauto Tero Kristo
2012-09-25 9:32 ` [PATCHv5 10/10] ARM: OMAP4: clock data: flag hw controlled clocks as autoidle Tero Kristo
2012-09-25 10:26 ` [PATCHv5 00/10] ARM: OMAP: PM usecounting changes Rajendra Nayak
2012-09-25 11:53 ` Tero Kristo
2012-09-25 12:23 ` Rajendra Nayak
2012-09-25 14:17 ` Tero Kristo
2012-09-26 4:15 ` 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=1348574555.10702.298.camel@sokoban \
--to=t-kristo@ti.com \
--cc=khilman@ti.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-omap@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox