From: Russell King - ARM Linux <linux@arm.linux.org.uk>
To: linux-arm-kernel@lists.infradead.org
Subject: Re: Locking in the clk API, part 2: clk_prepare/clk_unprepare
Date: Fri, 04 Feb 2011 11:18:41 +0000 [thread overview]
Message-ID: <20110204111841.GG14627@n2100.arm.linux.org.uk> (raw)
In-Reply-To: <AANLkTi=sfBTHLXejWxAWGa=Tcw+LoQfw6sUtcn6L+JeM@mail.gmail.com>
On Fri, Feb 04, 2011 at 08:04:03PM +0900, Jassi Brar wrote:
> On Fri, Feb 4, 2011 at 7:48 PM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
>
> > int clk_enable(struct clk *clk)
> > {
> > unsigned long flags;
> > int ret = 0;
> >
> > if (clk) {
> > if (WARN_ON(!clk->prepare_count))
> > return -EINVAL;
> >
> > spin_lock_irqsave(&clk->lock, flags);
> > if (clk->enable_count++ = 0)
> > ret = clk->ops->enable(clk);
> > spin_unlock_irqrestore(&clk->lock, flags);
> > }
> > return ret;
> > }
> >
> > is entirely sufficient to catch the case of a single-use clock not being
> > prepared before clk_enable() is called.
> >
> > We're after detecting drivers missing calls to clk_prepare(), we're not
> > after detecting concurrent calls to clk_prepare()/clk_unprepare().
>
> I hope you mean 'making sure the clock is prepared before it's enabled
> ' rather than
> 'catching a driver that doesn't do clk_prepare before clk_enable'.
> Because, the above implementation still doesn't catch a driver that
> doesn't call clk_prepare
> but simply uses a clock that happens to have been already prepare'd by
> some other
> driver or the platform.
No, I mean what I said.
The only way to do what you're asking is to attach a list of identifiers
which have prepared a clock to the struct clk, where each identifier is
unique to each driver instance.
So what that becomes is:
struct prepared_instance {
struct list_head node;
void *driver_id;
};
int clk_prepare(struct clk *clk, void *driver_id)
{
struct prepared_instance *inst;
int ret = 0;
if (clk) {
inst = kmalloc(sizeof(*inst), GFP_KERNEL);
if (!inst)
return -ENOMEM;
inst->driver_id = driver_id;
mutex_lock(&clk->mutex);
if (clk->prepare_count++ = 0)
ret = clk->ops->prepare(clk);
if (ret = 0) {
spin_lock_irqsave(&clk->lock, flags);
list_add(&inst->node, &clk->prepare_list);
spin_unlock_irqrestore(&clk->lock, flags);
} else
clk->prepare_count--;
mutex_unlock(&clk->mutex);
}
return ret;
}
int clk_enable(struct clk *clk, void *driver_id)
{
unsigned long flags;
int ret = 0;
if (clk) {
struct prepare_instance *inst;
spin_lock_irqsave(&clk->lock, flags);
list_for_each_entry(inst, &clk->prepare_list, node)
if (inst = driver_id)
ret = -EINVAL;
if (ret = 0 && clk->enable_count++ = 0) {
ret = clk->ops->enable(clk);
if (ret)
clk->enable_count--;
}
spin_unlock_irqrestore(&clk->lock, flags);
}
return ret;
}
I think that's going completely over the top, and adds needless complexity
to drivers, which now have to pass an instance specific cookie into every
clk API call.
next prev parent reply other threads:[~2011-02-04 11:18 UTC|newest]
Thread overview: 127+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-02-01 9:11 Locking in the clk API, part 2: clk_prepare/clk_unprepare Jeremy Kerr
2011-02-01 10:54 `
2011-02-01 13:05 ` Jassi Brar
2011-02-01 14:00 `
2011-02-01 15:14 ` Russell King - ARM Linux
2011-02-01 15:22 `
2011-02-01 15:28 ` Russell King - ARM Linux
2011-02-01 20:57 ` Saravana Kannan
2011-02-02 2:31 ` Jassi Brar
2011-02-01 13:15 ` Russell King - ARM Linux
2011-02-01 14:18 `
2011-02-01 14:39 ` Russell King - ARM Linux
2011-02-01 15:18 `
2011-02-01 15:24 ` Russell King - ARM Linux
2011-02-01 15:53 `
2011-02-01 17:06 ` Russell King - ARM Linux
2011-02-01 19:32 `
2011-02-01 19:56 ` Russell King - ARM Linux
2011-02-01 20:21 ` Saravana Kannan
2011-02-01 20:43 `
2011-02-04 9:33 ` Richard Zhao
2011-02-01 20:06 ` Nicolas Pitre
2011-02-01 20:33 ` Saravana Kannan
2011-02-01 20:36 ` Russell King - ARM Linux
2011-02-01 20:59 ` Stephen Boyd
2011-02-01 21:24 ` Russell King - ARM Linux
2011-02-04 9:54 ` Richard Zhao
2011-02-04 10:21 `
2011-02-04 10:57 ` Russell King - ARM Linux
2011-02-04 10:48 ` Russell King - ARM Linux
2011-02-04 11:04 ` Jassi Brar
2011-02-04 11:18 ` Russell King - ARM Linux [this message]
2011-02-04 11:51 ` Jassi Brar
2011-02-04 12:05 ` Russell King - ARM Linux
2011-02-01 14:40 ` Jeremy Kerr
2011-02-04 12:45 ` Richard Zhao
2011-02-04 13:20 ` Russell King - ARM Linux
2011-02-07 6:07 ` [RFC,PATCH 1/3] Add a common struct clk Jeremy Kerr
2011-02-07 7:05 `
2011-02-07 7:09 `
2011-02-07 8:08 `
[not found] ` <AANLkTim1S9zpebn3yj1fBZTtOkqj2FLwhYWBZ2HXJajR@mail.gmail.com>
2011-02-07 8:22 ` Jeremy Kerr
2011-02-07 19:59 ` Colin Cross
2011-02-08 1:40 ` Jeremy Kerr
2011-02-07 20:20 ` Ryan Mallon
2011-02-08 2:54 ` Jeremy Kerr
2011-02-08 3:30 ` Ryan Mallon
2011-02-08 7:28 ` Jeremy Kerr
2011-02-07 6:07 ` [RFC,PATCH 2/3] clk: Generic support for fixed-rate clocks Jeremy Kerr
2011-02-07 6:07 ` [RFC,PATCH 0/3] Common struct clk implementation, v11 Jeremy Kerr
2011-02-07 6:07 ` [RFC, Jeremy Kerr
2011-02-07 6:29 ` [RFC, PATCH 3/3] clk: add warnings for incorrect enable/prepare semantics Jassi Brar
2011-02-07 7:00 ` Jeremy Kerr
2011-02-07 8:05 ` [RFC, PATCH 3/3] clk: add warnings for incorrect
2011-02-07 8:08 ` [RFC, PATCH 3/3] clk: add warnings for incorrect enable/prepare semantics Jeremy Kerr
2011-02-07 14:24 ` [RFC, PATCH 3/3] clk: add warnings for incorrect enable/prepare Nicolas Pitre
2011-02-10 4:26 ` Saravana Kannan
2011-02-09 6:41 ` [RFC,PATCH 0/3] Common struct clk implementation, v12 Jeremy Kerr
2011-02-09 6:41 ` [RFC,PATCH 2/3] clk: Generic support for fixed-rate clocks Jeremy Kerr
2011-02-09 6:58 ` Fabio Giovagnini
2011-02-10 23:23 ` Ryan Mallon
2011-02-15 1:41 ` Jeremy Kerr
2011-02-15 4:51 ` Saravana Kannan
2011-02-15 6:18 ` Jeremy Kerr
2011-02-15 6:31 ` Saravana Kannan
2011-02-09 6:41 ` [RFC,PATCH 1/3] Add a common struct clk Jeremy Kerr
2011-02-09 9:00 `
2011-02-09 20:21 ` Ryan Mallon
2011-02-09 20:39 `
2011-02-09 20:42 ` Ryan Mallon
2011-02-10 10:03 ` Richard Zhao
2011-02-10 10:10 ` Ryan Mallon
2011-02-10 12:45 ` Richard Zhao
2011-02-10 10:46 `
2011-02-10 13:08 ` Richard Zhao
2011-02-10 13:13 ` Russell King - ARM Linux
2011-02-15 1:36 ` Jeremy Kerr
2011-02-15 1:43 ` Ryan Mallon
2011-02-10 5:16 ` Saravana Kannan
2011-02-15 2:41 ` Jeremy Kerr
2011-02-15 5:33 ` Saravana Kannan
2011-02-15 7:26 ` Jeremy Kerr
2011-02-15 8:33 ` Saravana Kannan
2011-02-15 8:37 ` Russell King - ARM Linux
2011-02-15 9:33 ` Jeremy Kerr
2011-02-15 14:13 ` Richard Zhao
2011-02-20 13:07 ` Russell King - ARM Linux
2011-02-16 4:53 ` Saravana Kannan
2011-02-20 13:13 ` Russell King - ARM Linux
2011-02-09 6:41 ` [RFC, Jeremy Kerr
2011-02-10 9:37 ` [RFC, PATCH 3/3] clk: add warnings for incorrect Richard Zhao
2011-02-15 2:00 ` [RFC, PATCH 3/3] clk: add warnings for incorrect enable/prepare semantics Jeremy Kerr
2011-02-21 2:50 ` [PATCH 0/2] Common struct clk implementation, v13 Jeremy Kerr
2011-02-21 2:50 ` [PATCH 1/2] Add a common struct clk Jeremy Kerr
2011-02-22 20:17 `
2011-02-23 2:49 ` Jeremy Kerr
2011-02-21 2:50 ` [PATCH 2/2] clk: Generic support for fixed-rate clocks Jeremy Kerr
2011-02-21 19:51 ` Ryan Mallon
2011-02-21 23:29 ` Jeremy Kerr
2011-02-22 23:33 ` [PATCH] wip: convert imx27 to common struct clk
2011-02-23 4:17 ` Saravana Kannan
2011-02-23 8:15 `
2011-03-03 6:40 ` [PATCH 0/2] Common struct clk implementation, v14 Jeremy Kerr
2011-03-03 6:40 ` [PATCH 1/2] Add a common struct clk Jeremy Kerr
2011-04-14 12:49 ` Tony Lindgren
2011-03-03 6:40 ` [PATCH 2/2] clk: Generic support for fixed-rate clocks Jeremy Kerr
2011-03-14 10:16 ` [PATCH 0/2] Common struct clk implementation, v14
2011-03-15 4:31 ` Jeremy Kerr
2011-03-21 2:33 ` Jeremy Kerr
2011-04-14 4:20 ` Jeremy Kerr
2011-04-14 10:00 ` Russell King - ARM Linux
2011-04-14 10:23 ` Jeremy Kerr
2011-04-14 10:26 ` Russell King - ARM Linux
2011-04-14 10:25 ` Benjamin Herrenschmidt
2011-04-14 10:32 ` Russell King - ARM Linux
2011-04-14 11:59 ` Nicolas Pitre
2011-04-14 12:09 ` Russell King - ARM Linux
2011-04-14 13:39 ` Nicolas Pitre
2011-04-14 14:00 ` Mark Brown
2011-04-14 15:38 ` Russell King - ARM Linux
2011-04-14 16:06 ` Nicolas Pitre
2011-04-14 17:20 `
2011-04-18 10:54 ` Paul Mundt
2011-04-20 14:28 `
2011-04-20 16:41 ` Thomas Gleixner
2011-04-14 19:29 ` Saravana Kannan
2011-04-14 16:08 `
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=20110204111841.GG14627@n2100.arm.linux.org.uk \
--to=linux@arm.linux.org.uk \
--cc=linux-arm-kernel@lists.infradead.org \
/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).