All of lore.kernel.org
 help / color / mirror / Atom feed
From: Saravana Kannan <skannan@codeaurora.org>
To: linux-arm-kernel@lists.infradead.org
Subject: Re: [RFC,PATCH 1/3] Add a common struct clk
Date: Thu, 10 Feb 2011 05:16:11 +0000	[thread overview]
Message-ID: <4D53749B.6010102@codeaurora.org> (raw)
In-Reply-To: <1297233693.242364.862698430999.1.gpush@pororo>

On 02/08/2011 10:41 PM, Jeremy Kerr wrote:

[snip]

> +
> +int clk_set_rate(struct clk *clk, unsigned long rate)
> +{

Shouldn't you be grabbing the prepare_lock here? Set rate and 
prepare/unprepare would be working on the same shared resource (say, 
PLL). That was the reason we are making set_rate() sleepable too.

As a nice side effect, it will also enforce the "might sleep" nature of 
this API.

You should probably rename the lock to something else since it's not 
limited to prepare/unprepare. How about resource_lock?

> +	if (clk->ops->set_rate)
> +		return clk->ops->set_rate(clk, rate);
> +	return -ENOSYS;
> +}
> +EXPORT_SYMBOL_GPL(clk_set_rate);
> +
> +int clk_set_parent(struct clk *clk, struct clk *parent)
> +{
> +	if (clk->ops->set_parent)
> +		return clk->ops->set_parent(clk, parent);

I'm not sure on this one. If the prepare ops for a clock also calls the 
prepare ops on the parent, shouldn't we prevent changing the parent 
while the prepare/unprepare is going on?


> +	return -ENOSYS;
> +}
> +EXPORT_SYMBOL_GPL(clk_set_parent);
> +

> diff --git a/include/linux/clk.h b/include/linux/clk.h
> index 1d37f42..fe806b7 100644
> --- a/include/linux/clk.h
> +++ b/include/linux/clk.h
> @@ -3,6 +3,7 @@

[snip]

> +
> +/* static initialiser for clocks */
> +#define INIT_CLK(name, o) {						\
> +	.ops		=&o,						\
> +	.enable_count	= 0,						\
> +	.prepare_count	= 0,						\

Do we need these inits? Doesn't check patch complain about initing 
static/global to 0? If it's generally frowned upon, why the exception 
here. I realize that checkpatch won't catch this, but still...

> +	.enable_lock	= __SPIN_LOCK_UNLOCKED(name.enable_lock),	\
> +	.prepare_lock	= __MUTEX_INITIALIZER(name.prepare_lock),	\

After a long day, I'm not able to wrap my head around this. Probably a 
stupid question, but will this name.xxx thing prevent using this 
INIT_CLK macro to initialize an array of clocks? More specifically, 
prevent the sub class macro (like INIT_CLK_FIXED) from being used to 
initialize an array of clocks?

> +}
> +
> +/**
> + * struct clk_ops -  Callback operations for clocks; these are to be provided
> + * by the clock implementation, and will be called by drivers through the clk_*
> + * API.
> + *
> + * @prepare:	Prepare the clock for enabling. This must not return until
> + *		the clock is fully prepared, and it's safe to call clk_enable.
> + *		This callback is intended to allow clock implementations to
> + *		do any initialisation that may block. Called with
> + *		clk->prepare_lock held.
> + *
> + * @unprepare:	Release the clock from its prepared state. This will typically
> + *		undo any work done in the @prepare callback. Called with
> + *		clk->prepare_lock held.
> + *
> + * @enable:	Enable the clock atomically. This must not return until the
> + *		clock is generating a valid clock signal, usable by consumer
> + *		devices. Called with clk->enable_lock held. This function
> + *		must not sleep.
> + *
> + * @disable:	Disable the clock atomically. Called with clk->enable_lock held.
> + *		This function must not sleep.
> + *
> + * @get:	Called by the core clock code when a device driver acquires a
> + *		clock via clk_get(). Optional.
> + *
> + * @put:	Called by the core clock code when a devices driver releases a
> + *		clock via clk_put(). Optional.
> + *
> + * The clk_enable/clk_disable and clk_prepare/clk_unprepare pairs allow
> + * implementations to split any work between atomic (enable) and sleepable
> + * (prepare) contexts.  If a clock requires blocking code to be turned on, this

Aren't all locks blocking? Shouldn't it be, "If turning on a clock 
requires code that might sleep, it should be done in clk_prepare"? 
Replace all "blocking" with "sleepable" or "sleeping" in the comments?

> + * should be done in clk_prepare. Switching that will not block should be done
> + * in clk_enable.
> + *
> + * Typically, drivers will call clk_prepare when a clock may be needed later
> + * (eg. when a device is opened), and clk_enable when the clock is actually
> + * required (eg. from an interrupt). Note that clk_prepare *must* have been
> + * called before clk_enable.
> + *
> + * For other callbacks, see the corresponding clk_* functions. Parameters and
> + * return values are passed directly from/to these API functions, or
> + * -ENOSYS (or zero, in the case of clk_get_rate) is returned if the callback
> + * is NULL, see kernel/clk.c for implementation details. All are optional.

is NULL. See kernel... ?
> + */
> +struct clk_ops {
> +	int		(*prepare)(struct clk *);
> +	void		(*unprepare)(struct clk *);
> +	int		(*enable)(struct clk *);
> +	void		(*disable)(struct clk *);
> +	int		(*get)(struct clk *);
> +	void		(*put)(struct clk *);
> +	unsigned long	(*get_rate)(struct clk *);
> +	long		(*round_rate)(struct clk *, unsigned long);
> +	int		(*set_rate)(struct clk *, unsigned long);
> +	int		(*set_parent)(struct clk *, struct clk *);
> +	struct clk *	(*get_parent)(struct clk *);
> +};
> +

Thanks,
Saravana

-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

WARNING: multiple messages have this Message-ID (diff)
From: skannan@codeaurora.org (Saravana Kannan)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC,PATCH 1/3] Add a common struct clk
Date: Wed, 09 Feb 2011 21:16:11 -0800	[thread overview]
Message-ID: <4D53749B.6010102@codeaurora.org> (raw)
In-Reply-To: <1297233693.242364.862698430999.1.gpush@pororo>

On 02/08/2011 10:41 PM, Jeremy Kerr wrote:

[snip]

> +
> +int clk_set_rate(struct clk *clk, unsigned long rate)
> +{

Shouldn't you be grabbing the prepare_lock here? Set rate and 
prepare/unprepare would be working on the same shared resource (say, 
PLL). That was the reason we are making set_rate() sleepable too.

As a nice side effect, it will also enforce the "might sleep" nature of 
this API.

You should probably rename the lock to something else since it's not 
limited to prepare/unprepare. How about resource_lock?

> +	if (clk->ops->set_rate)
> +		return clk->ops->set_rate(clk, rate);
> +	return -ENOSYS;
> +}
> +EXPORT_SYMBOL_GPL(clk_set_rate);
> +
> +int clk_set_parent(struct clk *clk, struct clk *parent)
> +{
> +	if (clk->ops->set_parent)
> +		return clk->ops->set_parent(clk, parent);

I'm not sure on this one. If the prepare ops for a clock also calls the 
prepare ops on the parent, shouldn't we prevent changing the parent 
while the prepare/unprepare is going on?


> +	return -ENOSYS;
> +}
> +EXPORT_SYMBOL_GPL(clk_set_parent);
> +

> diff --git a/include/linux/clk.h b/include/linux/clk.h
> index 1d37f42..fe806b7 100644
> --- a/include/linux/clk.h
> +++ b/include/linux/clk.h
> @@ -3,6 +3,7 @@

[snip]

> +
> +/* static initialiser for clocks */
> +#define INIT_CLK(name, o) {						\
> +	.ops		=&o,						\
> +	.enable_count	= 0,						\
> +	.prepare_count	= 0,						\

Do we need these inits? Doesn't check patch complain about initing 
static/global to 0? If it's generally frowned upon, why the exception 
here. I realize that checkpatch won't catch this, but still...

> +	.enable_lock	= __SPIN_LOCK_UNLOCKED(name.enable_lock),	\
> +	.prepare_lock	= __MUTEX_INITIALIZER(name.prepare_lock),	\

After a long day, I'm not able to wrap my head around this. Probably a 
stupid question, but will this name.xxx thing prevent using this 
INIT_CLK macro to initialize an array of clocks? More specifically, 
prevent the sub class macro (like INIT_CLK_FIXED) from being used to 
initialize an array of clocks?

> +}
> +
> +/**
> + * struct clk_ops -  Callback operations for clocks; these are to be provided
> + * by the clock implementation, and will be called by drivers through the clk_*
> + * API.
> + *
> + * @prepare:	Prepare the clock for enabling. This must not return until
> + *		the clock is fully prepared, and it's safe to call clk_enable.
> + *		This callback is intended to allow clock implementations to
> + *		do any initialisation that may block. Called with
> + *		clk->prepare_lock held.
> + *
> + * @unprepare:	Release the clock from its prepared state. This will typically
> + *		undo any work done in the @prepare callback. Called with
> + *		clk->prepare_lock held.
> + *
> + * @enable:	Enable the clock atomically. This must not return until the
> + *		clock is generating a valid clock signal, usable by consumer
> + *		devices. Called with clk->enable_lock held. This function
> + *		must not sleep.
> + *
> + * @disable:	Disable the clock atomically. Called with clk->enable_lock held.
> + *		This function must not sleep.
> + *
> + * @get:	Called by the core clock code when a device driver acquires a
> + *		clock via clk_get(). Optional.
> + *
> + * @put:	Called by the core clock code when a devices driver releases a
> + *		clock via clk_put(). Optional.
> + *
> + * The clk_enable/clk_disable and clk_prepare/clk_unprepare pairs allow
> + * implementations to split any work between atomic (enable) and sleepable
> + * (prepare) contexts.  If a clock requires blocking code to be turned on, this

Aren't all locks blocking? Shouldn't it be, "If turning on a clock 
requires code that might sleep, it should be done in clk_prepare"? 
Replace all "blocking" with "sleepable" or "sleeping" in the comments?

> + * should be done in clk_prepare. Switching that will not block should be done
> + * in clk_enable.
> + *
> + * Typically, drivers will call clk_prepare when a clock may be needed later
> + * (eg. when a device is opened), and clk_enable when the clock is actually
> + * required (eg. from an interrupt). Note that clk_prepare *must* have been
> + * called before clk_enable.
> + *
> + * For other callbacks, see the corresponding clk_* functions. Parameters and
> + * return values are passed directly from/to these API functions, or
> + * -ENOSYS (or zero, in the case of clk_get_rate) is returned if the callback
> + * is NULL, see kernel/clk.c for implementation details. All are optional.

is NULL. See kernel... ?
> + */
> +struct clk_ops {
> +	int		(*prepare)(struct clk *);
> +	void		(*unprepare)(struct clk *);
> +	int		(*enable)(struct clk *);
> +	void		(*disable)(struct clk *);
> +	int		(*get)(struct clk *);
> +	void		(*put)(struct clk *);
> +	unsigned long	(*get_rate)(struct clk *);
> +	long		(*round_rate)(struct clk *, unsigned long);
> +	int		(*set_rate)(struct clk *, unsigned long);
> +	int		(*set_parent)(struct clk *, struct clk *);
> +	struct clk *	(*get_parent)(struct clk *);
> +};
> +

Thanks,
Saravana

-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

WARNING: multiple messages have this Message-ID (diff)
From: Saravana Kannan <skannan@codeaurora.org>
To: Jeremy Kerr <jeremy.kerr@canonical.com>
Cc: linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	"Nicolas Pitre" <nicolas.pitre@linaro.org>,
	"Lorenzo Pieralisi" <Lorenzo.Pieralisi@arm.com>,
	"Vincent Guittot" <vincent.guittot@linaro.org>,
	linux-sh@vger.kernel.org,
	"Ben Herrenschmidt" <benh@kernel.crashing.org>,
	"Sascha Hauer" <s.hauer@pengutronix.de>,
	"Paul Mundt" <lethal@linux-sh.org>,
	"Dima Zavin" <dmitriyz@google.com>,
	"Ben Dooks" <ben-linux@fluff.org>,
	"Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>,
	"Russell King" <linux@arm.linux.org.uk>
Subject: Re: [RFC,PATCH 1/3] Add a common struct clk
Date: Wed, 09 Feb 2011 21:16:11 -0800	[thread overview]
Message-ID: <4D53749B.6010102@codeaurora.org> (raw)
In-Reply-To: <1297233693.242364.862698430999.1.gpush@pororo>

On 02/08/2011 10:41 PM, Jeremy Kerr wrote:

[snip]

> +
> +int clk_set_rate(struct clk *clk, unsigned long rate)
> +{

Shouldn't you be grabbing the prepare_lock here? Set rate and 
prepare/unprepare would be working on the same shared resource (say, 
PLL). That was the reason we are making set_rate() sleepable too.

As a nice side effect, it will also enforce the "might sleep" nature of 
this API.

You should probably rename the lock to something else since it's not 
limited to prepare/unprepare. How about resource_lock?

> +	if (clk->ops->set_rate)
> +		return clk->ops->set_rate(clk, rate);
> +	return -ENOSYS;
> +}
> +EXPORT_SYMBOL_GPL(clk_set_rate);
> +
> +int clk_set_parent(struct clk *clk, struct clk *parent)
> +{
> +	if (clk->ops->set_parent)
> +		return clk->ops->set_parent(clk, parent);

I'm not sure on this one. If the prepare ops for a clock also calls the 
prepare ops on the parent, shouldn't we prevent changing the parent 
while the prepare/unprepare is going on?


> +	return -ENOSYS;
> +}
> +EXPORT_SYMBOL_GPL(clk_set_parent);
> +

> diff --git a/include/linux/clk.h b/include/linux/clk.h
> index 1d37f42..fe806b7 100644
> --- a/include/linux/clk.h
> +++ b/include/linux/clk.h
> @@ -3,6 +3,7 @@

[snip]

> +
> +/* static initialiser for clocks */
> +#define INIT_CLK(name, o) {						\
> +	.ops		=&o,						\
> +	.enable_count	= 0,						\
> +	.prepare_count	= 0,						\

Do we need these inits? Doesn't check patch complain about initing 
static/global to 0? If it's generally frowned upon, why the exception 
here. I realize that checkpatch won't catch this, but still...

> +	.enable_lock	= __SPIN_LOCK_UNLOCKED(name.enable_lock),	\
> +	.prepare_lock	= __MUTEX_INITIALIZER(name.prepare_lock),	\

After a long day, I'm not able to wrap my head around this. Probably a 
stupid question, but will this name.xxx thing prevent using this 
INIT_CLK macro to initialize an array of clocks? More specifically, 
prevent the sub class macro (like INIT_CLK_FIXED) from being used to 
initialize an array of clocks?

> +}
> +
> +/**
> + * struct clk_ops -  Callback operations for clocks; these are to be provided
> + * by the clock implementation, and will be called by drivers through the clk_*
> + * API.
> + *
> + * @prepare:	Prepare the clock for enabling. This must not return until
> + *		the clock is fully prepared, and it's safe to call clk_enable.
> + *		This callback is intended to allow clock implementations to
> + *		do any initialisation that may block. Called with
> + *		clk->prepare_lock held.
> + *
> + * @unprepare:	Release the clock from its prepared state. This will typically
> + *		undo any work done in the @prepare callback. Called with
> + *		clk->prepare_lock held.
> + *
> + * @enable:	Enable the clock atomically. This must not return until the
> + *		clock is generating a valid clock signal, usable by consumer
> + *		devices. Called with clk->enable_lock held. This function
> + *		must not sleep.
> + *
> + * @disable:	Disable the clock atomically. Called with clk->enable_lock held.
> + *		This function must not sleep.
> + *
> + * @get:	Called by the core clock code when a device driver acquires a
> + *		clock via clk_get(). Optional.
> + *
> + * @put:	Called by the core clock code when a devices driver releases a
> + *		clock via clk_put(). Optional.
> + *
> + * The clk_enable/clk_disable and clk_prepare/clk_unprepare pairs allow
> + * implementations to split any work between atomic (enable) and sleepable
> + * (prepare) contexts.  If a clock requires blocking code to be turned on, this

Aren't all locks blocking? Shouldn't it be, "If turning on a clock 
requires code that might sleep, it should be done in clk_prepare"? 
Replace all "blocking" with "sleepable" or "sleeping" in the comments?

> + * should be done in clk_prepare. Switching that will not block should be done
> + * in clk_enable.
> + *
> + * Typically, drivers will call clk_prepare when a clock may be needed later
> + * (eg. when a device is opened), and clk_enable when the clock is actually
> + * required (eg. from an interrupt). Note that clk_prepare *must* have been
> + * called before clk_enable.
> + *
> + * For other callbacks, see the corresponding clk_* functions. Parameters and
> + * return values are passed directly from/to these API functions, or
> + * -ENOSYS (or zero, in the case of clk_get_rate) is returned if the callback
> + * is NULL, see kernel/clk.c for implementation details. All are optional.

is NULL. See kernel... ?
> + */
> +struct clk_ops {
> +	int		(*prepare)(struct clk *);
> +	void		(*unprepare)(struct clk *);
> +	int		(*enable)(struct clk *);
> +	void		(*disable)(struct clk *);
> +	int		(*get)(struct clk *);
> +	void		(*put)(struct clk *);
> +	unsigned long	(*get_rate)(struct clk *);
> +	long		(*round_rate)(struct clk *, unsigned long);
> +	int		(*set_rate)(struct clk *, unsigned long);
> +	int		(*set_parent)(struct clk *, struct clk *);
> +	struct clk *	(*get_parent)(struct clk *);
> +};
> +

Thanks,
Saravana

-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

  parent reply	other threads:[~2011-02-10  5:16 UTC|newest]

Thread overview: 381+ 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  9:11 ` Jeremy Kerr
2011-02-01  9:11 ` Jeremy Kerr
2011-02-01 10:54 ` 
2011-02-01 10:54   ` Uwe Kleine-König
2011-02-01 10:54   ` Uwe Kleine-König
2011-02-01 13:05   ` Jassi Brar
2011-02-01 13:05     ` Jassi Brar
2011-02-01 13:05     ` Jassi Brar
2011-02-01 14:00     ` 
2011-02-01 14:00       ` Uwe Kleine-König
2011-02-01 14:00       ` Uwe Kleine-König
2011-02-01 15:14       ` Russell King - ARM Linux
2011-02-01 15:14         ` Russell King - ARM Linux
2011-02-01 15:14         ` Russell King - ARM Linux
2011-02-01 15:22         ` 
2011-02-01 15:22           ` Uwe Kleine-König
2011-02-01 15:22           ` Uwe Kleine-König
2011-02-01 15:28           ` Russell King - ARM Linux
2011-02-01 15:28             ` Russell King - ARM Linux
2011-02-01 15:28             ` Russell King - ARM Linux
2011-02-01 20:57             ` Saravana Kannan
2011-02-01 20:57               ` Saravana Kannan
2011-02-01 20:57               ` Saravana Kannan
2011-02-02  2:31             ` Jassi Brar
2011-02-02  2:31               ` Jassi Brar
2011-02-02  2:31               ` Jassi Brar
2011-02-01 13:15   ` Russell King - ARM Linux
2011-02-01 13:15     ` Russell King - ARM Linux
2011-02-01 13:15     ` Russell King - ARM Linux
2011-02-01 14:18     ` 
2011-02-01 14:18       ` Uwe Kleine-König
2011-02-01 14:18       ` Uwe Kleine-König
2011-02-01 14:39       ` Russell King - ARM Linux
2011-02-01 14:39         ` Russell King - ARM Linux
2011-02-01 14:39         ` Russell King - ARM Linux
2011-02-01 15:18         ` 
2011-02-01 15:18           ` Uwe Kleine-König
2011-02-01 15:18           ` Uwe Kleine-König
2011-02-01 15:24           ` Russell King - ARM Linux
2011-02-01 15:24             ` Russell King - ARM Linux
2011-02-01 15:24             ` Russell King - ARM Linux
2011-02-01 15:53             ` 
2011-02-01 15:53               ` Uwe Kleine-König
2011-02-01 15:53               ` Uwe Kleine-König
2011-02-01 17:06               ` Russell King - ARM Linux
2011-02-01 17:06                 ` Russell King - ARM Linux
2011-02-01 17:06                 ` Russell King - ARM Linux
2011-02-01 19:32                 ` 
2011-02-01 19:32                   ` Uwe Kleine-König
2011-02-01 19:32                   ` Uwe Kleine-König
2011-02-01 19:56                   ` Russell King - ARM Linux
2011-02-01 19:56                     ` Russell King - ARM Linux
2011-02-01 19:56                     ` Russell King - ARM Linux
2011-02-01 20:21                     ` Saravana Kannan
2011-02-01 20:21                       ` Saravana Kannan
2011-02-01 20:21                       ` Saravana Kannan
2011-02-01 20:43                       ` 
2011-02-01 20:43                         ` Uwe Kleine-König
2011-02-01 20:43                         ` Uwe Kleine-König
2011-02-04  9:33                         ` Richard Zhao
2011-02-04  9:33                           ` Richard Zhao
2011-02-04  9:33                           ` Richard Zhao
2011-02-01 20:06                   ` Nicolas Pitre
2011-02-01 20:06                     ` Nicolas Pitre
2011-02-01 20:06                     ` Nicolas Pitre
2011-02-01 20:33             ` Saravana Kannan
2011-02-01 20:33               ` Saravana Kannan
2011-02-01 20:33               ` Saravana Kannan
2011-02-01 20:36               ` Russell King - ARM Linux
2011-02-01 20:36                 ` Russell King - ARM Linux
2011-02-01 20:36                 ` Russell King - ARM Linux
2011-02-01 20:59             ` Stephen Boyd
2011-02-01 20:59               ` Stephen Boyd
2011-02-01 20:59               ` Stephen Boyd
2011-02-01 21:24               ` Russell King - ARM Linux
2011-02-01 21:24                 ` Russell King - ARM Linux
2011-02-01 21:24                 ` Russell King - ARM Linux
2011-02-04  9:54                 ` Richard Zhao
2011-02-04  9:54                   ` Richard Zhao
2011-02-04  9:54                   ` Richard Zhao
2011-02-04 10:21                   ` 
2011-02-04 10:21                     ` Uwe Kleine-König
2011-02-04 10:21                     ` Uwe Kleine-König
2011-02-04 10:57                     ` Russell King - ARM Linux
2011-02-04 10:57                       ` Russell King - ARM Linux
2011-02-04 10:57                       ` Russell King - ARM Linux
2011-02-04 10:48                   ` Russell King - ARM Linux
2011-02-04 10:48                     ` Russell King - ARM Linux
2011-02-04 10:48                     ` Russell King - ARM Linux
2011-02-04 11:04                     ` Jassi Brar
2011-02-04 11:04                       ` Jassi Brar
2011-02-04 11:04                       ` Jassi Brar
2011-02-04 11:18                       ` Russell King - ARM Linux
2011-02-04 11:18                         ` Russell King - ARM Linux
2011-02-04 11:18                         ` Russell King - ARM Linux
2011-02-04 11:51                         ` Jassi Brar
2011-02-04 11:51                           ` Jassi Brar
2011-02-04 11:51                           ` Jassi Brar
2011-02-04 12:05                           ` Russell King - ARM Linux
2011-02-04 12:05                             ` Russell King - ARM Linux
2011-02-04 12:05                             ` Russell King - ARM Linux
2011-02-01 14:40       ` Jeremy Kerr
2011-02-01 14:40         ` Jeremy Kerr
2011-02-01 14:40         ` Jeremy Kerr
2011-02-04 12:45 ` Richard Zhao
2011-02-04 12:45   ` Richard Zhao
2011-02-04 12:45   ` Richard Zhao
2011-02-04 13:20   ` Russell King - ARM Linux
2011-02-04 13:20     ` Russell King - ARM Linux
2011-02-04 13:20     ` Russell King - ARM Linux
2011-02-07  6:07 ` [RFC, Jeremy Kerr
2011-02-07  6:07   ` [RFC, PATCH 3/3] clk: add warnings for incorrect enable/prepare semantics Jeremy Kerr
2011-02-07  6:07   ` Jeremy Kerr
2011-02-07  6:29   ` Jassi Brar
2011-02-07  6:29     ` Jassi Brar
2011-02-07  6:29     ` Jassi Brar
2011-02-07  7:00     ` Jeremy Kerr
2011-02-07  7:00       ` Jeremy Kerr
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:05     ` [RFC, PATCH 3/3] clk: add warnings for incorrect enable/prepare semantics Uwe Kleine-König
2011-02-07  8:05     ` Uwe Kleine-König
2011-02-07  8:08     ` Jeremy Kerr
2011-02-07  8:08       ` Jeremy Kerr
2011-02-07  8:08       ` Jeremy Kerr
2011-02-07 14:24       ` [RFC, PATCH 3/3] clk: add warnings for incorrect enable/prepare Nicolas Pitre
2011-02-07 14:24         ` [RFC, PATCH 3/3] clk: add warnings for incorrect enable/prepare semantics Nicolas Pitre
2011-02-07 14:24         ` Nicolas Pitre
2011-02-10  4:26         ` [RFC, PATCH 3/3] clk: add warnings for incorrect enable/prepare Saravana Kannan
2011-02-10  4:26           ` [RFC, PATCH 3/3] clk: add warnings for incorrect enable/prepare semantics Saravana Kannan
2011-02-10  4:26           ` Saravana Kannan
2011-02-07  6:07 ` [RFC,PATCH 2/3] clk: Generic support for fixed-rate clocks Jeremy Kerr
2011-02-07  6:07   ` Jeremy Kerr
2011-02-07  6:07   ` Jeremy Kerr
2011-02-09  6:41   ` Jeremy Kerr
2011-02-09  6:41     ` Jeremy Kerr
2011-02-09  6:41     ` Jeremy Kerr
2011-02-09  6:58     ` Fabio Giovagnini
2011-02-09  6:58       ` Fabio Giovagnini
2011-02-09  6:58       ` Fabio Giovagnini
2011-02-10 23:23     ` Ryan Mallon
2011-02-10 23:23       ` Ryan Mallon
2011-02-10 23:23       ` Ryan Mallon
2011-02-15  1:41       ` Jeremy Kerr
2011-02-15  1:41         ` Jeremy Kerr
2011-02-15  1:41         ` Jeremy Kerr
2011-02-15  4:51         ` Saravana Kannan
2011-02-15  4:51           ` Saravana Kannan
2011-02-15  4:51           ` Saravana Kannan
2011-02-15  6:18           ` Jeremy Kerr
2011-02-15  6:18             ` Jeremy Kerr
2011-02-15  6:18             ` Jeremy Kerr
2011-02-15  6:31             ` Saravana Kannan
2011-02-15  6:31               ` Saravana Kannan
2011-02-15  6:31               ` Saravana Kannan
2011-02-07  6:07 ` [RFC,PATCH 0/3] Common struct clk implementation, v11 Jeremy Kerr
2011-02-07  6:07   ` Jeremy Kerr
2011-02-07  6:07   ` Jeremy Kerr
2011-02-09  6:41   ` [RFC,PATCH 0/3] Common struct clk implementation, v12 Jeremy Kerr
2011-02-09  6:41     ` Jeremy Kerr
2011-02-09  6:41     ` Jeremy Kerr
2011-02-09  6:41     ` [RFC, Jeremy Kerr
2011-02-09  6:41       ` [RFC, PATCH 3/3] clk: add warnings for incorrect enable/prepare semantics Jeremy Kerr
2011-02-09  6:41       ` Jeremy Kerr
2011-02-10  9:37       ` [RFC, PATCH 3/3] clk: add warnings for incorrect Richard Zhao
2011-02-10  9:37         ` [RFC, PATCH 3/3] clk: add warnings for incorrect enable/prepare semantics Richard Zhao
2011-02-10  9:37         ` Richard Zhao
2011-02-15  2:00         ` Jeremy Kerr
2011-02-15  2:00           ` Jeremy Kerr
2011-02-15  2:00           ` Jeremy Kerr
2011-02-07  6:07 ` [RFC,PATCH 1/3] Add a common struct clk Jeremy Kerr
2011-02-07  6:07   ` Jeremy Kerr
2011-02-07  6:07   ` Jeremy Kerr
2011-02-07  7:05   ` 
2011-02-07  7:05     ` Uwe Kleine-König
2011-02-07  7:05     ` Uwe Kleine-König
2011-02-07  7:09   ` 
2011-02-07  8:08   ` 
2011-02-07  8:08     ` Uwe Kleine-König
2011-02-07  8:08     ` Uwe Kleine-König
2011-02-07  8:21   ` Dima Zavin
2011-02-07  8:22     ` Jeremy Kerr
2011-02-07  8:22       ` Jeremy Kerr
2011-02-07  8:22       ` Jeremy Kerr
2011-02-07 19:59   ` Colin Cross
2011-02-07 19:59     ` Colin Cross
2011-02-07 19:59     ` Colin Cross
2011-02-08  1:40     ` Jeremy Kerr
2011-02-08  1:40       ` Jeremy Kerr
2011-02-08  1:40       ` Jeremy Kerr
2011-02-07 20:20   ` Ryan Mallon
2011-02-07 20:20     ` Ryan Mallon
2011-02-07 20:20     ` Ryan Mallon
2011-02-08  2:54     ` Jeremy Kerr
2011-02-08  2:54       ` Jeremy Kerr
2011-02-08  2:54       ` Jeremy Kerr
2011-02-08  3:30       ` Ryan Mallon
2011-02-08  3:30         ` Ryan Mallon
2011-02-08  3:30         ` Ryan Mallon
2011-02-08  7:28         ` Jeremy Kerr
2011-02-08  7:28           ` Jeremy Kerr
2011-02-08  7:28           ` Jeremy Kerr
2011-02-09  6:41   ` Jeremy Kerr
2011-02-09  6:41     ` Jeremy Kerr
2011-02-09  6:41     ` Jeremy Kerr
2011-02-09  9:00     ` 
2011-02-09  9:00       ` Uwe Kleine-König
2011-02-09  9:00       ` Uwe Kleine-König
2011-02-09 20:21     ` Ryan Mallon
2011-02-09 20:21       ` Ryan Mallon
2011-02-09 20:21       ` Ryan Mallon
2011-02-09 20:39       ` 
2011-02-09 20:39         ` Uwe Kleine-König
2011-02-09 20:39         ` Uwe Kleine-König
2011-02-09 20:42         ` Ryan Mallon
2011-02-09 20:42           ` Ryan Mallon
2011-02-09 20:42           ` Ryan Mallon
2011-02-10 10:03       ` Richard Zhao
2011-02-10 10:03         ` Richard Zhao
2011-02-10 10:03         ` Richard Zhao
2011-02-10 10:10         ` Ryan Mallon
2011-02-10 10:10           ` Ryan Mallon
2011-02-10 10:10           ` Ryan Mallon
2011-02-10 12:45           ` Richard Zhao
2011-02-10 12:45             ` Richard Zhao
2011-02-10 12:45             ` Richard Zhao
2011-02-10 10:46         ` 
2011-02-10 10:46           ` Uwe Kleine-König
2011-02-10 10:46           ` Uwe Kleine-König
2011-02-10 13:08           ` Richard Zhao
2011-02-10 13:08             ` Richard Zhao
2011-02-10 13:08             ` Richard Zhao
2011-02-10 13:13             ` Russell King - ARM Linux
2011-02-10 13:13               ` Russell King - ARM Linux
2011-02-10 13:13               ` Russell King - ARM Linux
2011-02-15  1:36       ` Jeremy Kerr
2011-02-15  1:36         ` Jeremy Kerr
2011-02-15  1:36         ` Jeremy Kerr
2011-02-15  1:43         ` Ryan Mallon
2011-02-15  1:43           ` Ryan Mallon
2011-02-15  1:43           ` Ryan Mallon
2011-02-10  5:16     ` Saravana Kannan [this message]
2011-02-10  5:16       ` Saravana Kannan
2011-02-10  5:16       ` Saravana Kannan
2011-02-15  2:41       ` Jeremy Kerr
2011-02-15  2:41         ` Jeremy Kerr
2011-02-15  2:41         ` Jeremy Kerr
2011-02-15  5:33         ` Saravana Kannan
2011-02-15  5:33           ` Saravana Kannan
2011-02-15  5:33           ` Saravana Kannan
2011-02-15  7:26           ` Jeremy Kerr
2011-02-15  7:26             ` Jeremy Kerr
2011-02-15  7:26             ` Jeremy Kerr
2011-02-15  8:33             ` Saravana Kannan
2011-02-15  8:33               ` Saravana Kannan
2011-02-15  8:33               ` Saravana Kannan
2011-02-15  8:37             ` Russell King - ARM Linux
2011-02-15  8:37               ` Russell King - ARM Linux
2011-02-15  8:37               ` Russell King - ARM Linux
2011-02-15  9:33               ` Jeremy Kerr
2011-02-15  9:33                 ` Jeremy Kerr
2011-02-15  9:33                 ` Jeremy Kerr
2011-02-15 14:13                 ` Richard Zhao
2011-02-15 14:13                   ` Richard Zhao
2011-02-15 14:13                   ` Richard Zhao
2011-02-20 13:07                 ` Russell King - ARM Linux
2011-02-20 13:07                   ` Russell King - ARM Linux
2011-02-20 13:07                   ` Russell King - ARM Linux
2011-02-16  4:53           ` Saravana Kannan
2011-02-16  4:53             ` Saravana Kannan
2011-02-16  4:53             ` Saravana Kannan
2011-02-20 13:13           ` Russell King - ARM Linux
2011-02-20 13:13             ` Russell King - ARM Linux
2011-02-20 13:13             ` Russell King - ARM Linux
2011-02-21  2:50 ` [PATCH 0/2] Common struct clk implementation, v13 Jeremy Kerr
2011-02-21  2:50   ` Jeremy Kerr
2011-02-21  2:50   ` Jeremy Kerr
2011-02-21  2:50   ` [PATCH 2/2] clk: Generic support for fixed-rate clocks Jeremy Kerr
2011-02-21  2:50     ` Jeremy Kerr
2011-02-21  2:50     ` Jeremy Kerr
2011-02-21 19:51     ` Ryan Mallon
2011-02-21 19:51       ` Ryan Mallon
2011-02-21 19:51       ` Ryan Mallon
2011-02-21 23:29       ` Jeremy Kerr
2011-02-21 23:29         ` Jeremy Kerr
2011-02-21 23:29         ` Jeremy Kerr
2011-03-03  6:40       ` Jeremy Kerr
2011-03-03  6:40         ` Jeremy Kerr
2011-03-03  6:40         ` Jeremy Kerr
2011-02-21  2:50   ` [PATCH 1/2] Add a common struct clk Jeremy Kerr
2011-02-21  2:50     ` Jeremy Kerr
2011-02-21  2:50     ` Jeremy Kerr
2011-02-22 20:17     ` 
2011-02-22 20:17       ` Uwe Kleine-König
2011-02-22 20:17       ` Uwe Kleine-König
2011-02-23  2:49       ` Jeremy Kerr
2011-02-23  2:49         ` Jeremy Kerr
2011-02-23  2:49         ` Jeremy Kerr
2011-03-03  6:40     ` Jeremy Kerr
2011-03-03  6:40       ` Jeremy Kerr
2011-03-03  6:40       ` Jeremy Kerr
2011-04-14 12:49       ` Tony Lindgren
2011-04-14 12:49         ` Tony Lindgren
2011-04-14 12:49         ` Tony Lindgren
2011-02-22 23:33   ` [PATCH] wip: convert imx27 to " 
2011-02-22 23:33     ` Uwe Kleine-König
2011-02-22 23:33     ` Uwe Kleine-König
2011-02-23  4:17     ` Saravana Kannan
2011-02-23  4:17       ` Saravana Kannan
2011-02-23  4:17       ` Saravana Kannan
2011-02-23  8:15       ` 
2011-02-23  8:15         ` Uwe Kleine-König
2011-02-23  8:15         ` Uwe Kleine-König
2011-03-03  6:40   ` [PATCH 0/2] Common struct clk implementation, v14 Jeremy Kerr
2011-03-03  6:40     ` Jeremy Kerr
2011-03-03  6:40     ` Jeremy Kerr
2011-03-14 10:16     ` 
2011-03-14 10:16       ` Uwe Kleine-König
2011-03-14 10:16       ` Uwe Kleine-König
2011-03-15  4:31     ` Jeremy Kerr
2011-03-15  4:31       ` Jeremy Kerr
2011-03-15  4:31       ` Jeremy Kerr
2011-03-21  2:33       ` Jeremy Kerr
2011-03-21  2:33         ` Jeremy Kerr
2011-03-21  2:33         ` Jeremy Kerr
2011-04-14  4:20     ` Jeremy Kerr
2011-04-14  4:20       ` Jeremy Kerr
2011-04-14  4:20       ` Jeremy Kerr
2011-04-14 10:00       ` Russell King - ARM Linux
2011-04-14 10:00         ` Russell King - ARM Linux
2011-04-14 10:00         ` Russell King - ARM Linux
2011-04-14 10:23         ` Jeremy Kerr
2011-04-14 10:23           ` Jeremy Kerr
2011-04-14 10:23           ` Jeremy Kerr
2011-04-14 10:26           ` Russell King - ARM Linux
2011-04-14 10:26             ` Russell King - ARM Linux
2011-04-14 10:26             ` Russell King - ARM Linux
2011-04-14 10:25         ` Benjamin Herrenschmidt
2011-04-14 10:25           ` Benjamin Herrenschmidt
2011-04-14 10:25           ` Benjamin Herrenschmidt
2011-04-14 10:32           ` Russell King - ARM Linux
2011-04-14 10:32             ` Russell King - ARM Linux
2011-04-14 10:32             ` Russell King - ARM Linux
2011-04-14 11:59             ` Nicolas Pitre
2011-04-14 11:59               ` Nicolas Pitre
2011-04-14 11:59               ` Nicolas Pitre
2011-04-14 12:09               ` Russell King - ARM Linux
2011-04-14 12:09                 ` Russell King - ARM Linux
2011-04-14 12:09                 ` Russell King - ARM Linux
2011-04-14 13:39                 ` Nicolas Pitre
2011-04-14 13:39                   ` Nicolas Pitre
2011-04-14 13:39                   ` Nicolas Pitre
2011-04-14 14:00                   ` Mark Brown
2011-04-14 14:00                     ` Mark Brown
2011-04-14 14:00                     ` Mark Brown
2011-04-14 15:38                   ` Russell King - ARM Linux
2011-04-14 15:38                     ` Russell King - ARM Linux
2011-04-14 15:38                     ` Russell King - ARM Linux
2011-04-14 16:06                     ` Nicolas Pitre
2011-04-14 16:06                       ` Nicolas Pitre
2011-04-14 16:06                       ` Nicolas Pitre
2011-04-14 17:20                     ` 
2011-04-14 17:20                       ` Uwe Kleine-König
2011-04-14 17:20                       ` Uwe Kleine-König
2011-04-18 10:54                     ` Paul Mundt
2011-04-18 10:54                       ` Paul Mundt
2011-04-18 10:54                       ` Paul Mundt
2011-04-20 14:28                       ` 
2011-04-20 14:28                         ` Uwe Kleine-König
2011-04-20 14:28                         ` Uwe Kleine-König
2011-04-20 16:41                         ` Thomas Gleixner
2011-04-20 16:41                           ` Thomas Gleixner
2011-04-20 16:41                           ` Thomas Gleixner
2011-04-20 21:30                           ` Paul McKenney
2011-04-14 19:29                 ` Saravana Kannan
2011-04-14 19:29                   ` Saravana Kannan
2011-04-14 19:29                   ` Saravana Kannan
2011-04-14 16:08             ` 
2011-04-14 16:08               ` Uwe Kleine-König
2011-04-14 16:08               ` Uwe Kleine-König

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=4D53749B.6010102@codeaurora.org \
    --to=skannan@codeaurora.org \
    --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 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.