linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Sascha Hauer <s.hauer@pengutronix.de>
To: Jeremy Kerr <jeremy.kerr@canonical.com>
Cc: linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	"Ben Herrenchmidt" <benh@kernel.crashing.org>,
	"Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>
Subject: Re: [PATCH 1/2] Add a common struct clk
Date: Sat, 8 Jan 2011 14:15:21 +0100	[thread overview]
Message-ID: <20110108131520.GE26617@pengutronix.de> (raw)
In-Reply-To: <1294199462.348449.192344022926.1.gpush@pororo>

Hi Jeremy,

On Wed, Jan 05, 2011 at 11:51:02AM +0800, Jeremy Kerr wrote:
> We currently have ~21 definitions of struct clk in the ARM architecture,
> each defined on a per-platform basis. This makes it difficult to define
> platform- (or architecture-) independent clock sources without making
> assumptions about struct clk, and impossible to compile two
> platforms with different struct clks into a single image.
> 
> This change is an effort to unify struct clk where possible, by defining
> a common struct clk, containing a set of clock operations. Different
> clock implementations can set their own operations, and have a standard
> interface for generic code. The callback interface is exposed to the
> kernel proper, while the clock implementations only need to be seen by
> the platform internals.
> 
> This allows us to share clock code among platforms, and makes it
> possible to dynamically create clock devices in platform-independent
> code.
> 
> Platforms can enable the generic struct clock through
> CONFIG_USE_COMMON_STRUCT_CLK. In this case, the clock infrastructure
> consists of a common struct clk:
> 
> struct clk {
> 	const struct clk_ops	*ops;
> 	unsigned int		enable_count;
> 	int			flags;
> 	union {
> 		struct mutex	mutex;
> 		spinlock_t	spinlock;
> 	} lock;
> };

I'm currently thinking about how to get the locking right with this
approach. In the current i.MX implementation we have a global lock which
protects the clock enable counter and also the register accesses in the
clock code. With the common struct clock we have a lock per clock which
only protects the enable counter, so we have to introduce a second lock
to protect the register accesses.
The problem comes with nested calls to for example clk_enable which
happens when the parent clock gets enabled. currently we do this with
clk->enable(clk->parent) which results in an unlocked clk_enable of the
parent. With common struct clk we would have to call
clk_enable(clk_get_parent(clk) which results in taking the lock a second
time.
Any ideas how to solve this?

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

  parent reply	other threads:[~2011-01-08 13:15 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-01-05  3:51 [PATCH 0/2] Common struct clk implementation, v10 Jeremy Kerr
2011-01-05  3:51 ` [PATCH 2/2] clk: Generic support for fixed-rate clocks Jeremy Kerr
2011-01-05  3:51 ` [PATCH 1/2] Add a common struct clk Jeremy Kerr
2011-01-06 16:07   ` Richard Cochran
2011-01-06 20:11     ` Uwe Kleine-König
2011-01-07  0:10       ` Jeremy Kerr
2011-01-07  0:32         ` Russell King - ARM Linux
2011-01-07  9:40           ` Uwe Kleine-König
2011-01-08 13:15   ` Sascha Hauer [this message]
2011-01-10  2:43     ` Jeremy Kerr
2011-01-10 10:41       ` Sascha Hauer
2011-01-10 11:00         ` Russell King - ARM Linux
2011-01-11  0:54           ` Jeremy Kerr
2011-01-16  7:26             ` Grant Likely
2011-01-16 20:41               ` Ryan Mallon
2011-01-16 21:07                 ` Uwe Kleine-König
2011-01-16 21:39                   ` Ryan Mallon
2011-01-11 10:16   ` Sascha Hauer
2011-01-11 10:27     ` Jeremy Kerr
2011-01-11 11:22       ` Sascha Hauer
2011-01-18  8:44         ` Paul Mundt
2011-01-18  9:21           ` Sascha Hauer
2011-01-18  9:23             ` Paul Mundt
2011-01-18 12:21   ` Russell King - ARM Linux
  -- strict thread matches above, loose matches on Subject: below --
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-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   ` Uwe Kleine-König
2011-02-23  2:49     ` Jeremy Kerr
2010-12-08  2:08 [PATCH 0/2] Common struct clk implementation, v8 Jeremy Kerr
2010-12-08  2:08 ` [PATCH 1/2] Add a common struct clk Jeremy Kerr
2010-12-08  2:05 Jeremy Kerr
2010-12-08 10:21 ` Uwe Kleine-König
2010-12-10  1:58   ` Jeremy Kerr
2010-07-12  2:37 [PATCH 0/2] Common struct clk implementation, v6 Jeremy Kerr
2010-07-12  2:37 ` [PATCH 1/2] Add a common struct clk Jeremy Kerr
2010-06-21  5:35 [PATCH 0/2] Common struct clk implementation, v5 Jeremy Kerr
2010-06-21  5:35 ` [PATCH 1/2] Add a common struct clk Jeremy Kerr
2010-06-22  4:43   ` Baruch Siach
2010-07-05  2:33   ` MyungJoo Ham
2010-07-12  2:19     ` Jeremy Kerr

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=20110108131520.GE26617@pengutronix.de \
    --to=s.hauer@pengutronix.de \
    --cc=benh@kernel.crashing.org \
    --cc=jeremy.kerr@canonical.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=u.kleine-koenig@pengutronix.de \
    /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).