All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Brown <broonie@opensource.wolfsonmicro.com>
To: linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 5/6] clk: Support multiple instances of the same clock
Date: Mon, 11 Jul 2011 10:53:45 +0000	[thread overview]
Message-ID: <20110711105342.GE5092@opensource.wolfsonmicro.com> (raw)
In-Reply-To: <20110711093439.GB3239@n2100.arm.linux.org.uk>

On Mon, Jul 11, 2011 at 10:34:39AM +0100, Russell King - ARM Linux wrote:
> On Mon, Jul 11, 2011 at 11:53:56AM +0900, Mark Brown wrote:

> > +	/* Since we currently match clock providers on a purely string
> > +	 * based method add a prefix based on the device name if a
> > +	 * device is provided.  When we have support for device tree

> This "clk consolidation" is really idiotic.  The clk matching mechanism
> should have _nothing_ to do with the rest of the clk API, especially the
> consolidation effort.

It's not touching clkdev, the comment is somewhat misleading and is
mostly based on me thinking about how we'd deploy off-SoC clocks.
There's also the diagnostic issues Sacha mentioned, if we don't keep
some source information handy it's hard to tell what clock logging is
talking about.

> It should not matter whether clkdev is used, or an alternative method
> to specify this stuff via DT.  Keep the clk_get()/clk_put() _separate_
> from the consolidation of the rest.

We do need some way to have some idea which clocks we're talking about,
and for off-SoC stuff passing around struct clk pointers is rather
painful.  At some point some bit of code is going to have to get hold of
the actual struct clk and then map it onto the devices using it.

For device tree we should be able to do that fairly painlessly with just
the struct devices, without device tree you either have to have the
structs handy or use names.  At the minute the infrastructure is
somewhat lacking here.

WARNING: multiple messages have this Message-ID (diff)
From: Mark Brown <broonie@opensource.wolfsonmicro.com>
To: Russell King - ARM Linux <linux@arm.linux.org.uk>
Cc: Jeremy Kerr <jeremy.kerr@canonical.com>,
	Grant Likely <grant@secretlab.ca>,
	linux-sh@vger.kernel.org, patches@opensource.wolfsonmicro.com,
	linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 5/6] clk: Support multiple instances of the same clock provider
Date: Mon, 11 Jul 2011 19:53:45 +0900	[thread overview]
Message-ID: <20110711105342.GE5092@opensource.wolfsonmicro.com> (raw)
In-Reply-To: <20110711093439.GB3239@n2100.arm.linux.org.uk>

On Mon, Jul 11, 2011 at 10:34:39AM +0100, Russell King - ARM Linux wrote:
> On Mon, Jul 11, 2011 at 11:53:56AM +0900, Mark Brown wrote:

> > +	/* Since we currently match clock providers on a purely string
> > +	 * based method add a prefix based on the device name if a
> > +	 * device is provided.  When we have support for device tree

> This "clk consolidation" is really idiotic.  The clk matching mechanism
> should have _nothing_ to do with the rest of the clk API, especially the
> consolidation effort.

It's not touching clkdev, the comment is somewhat misleading and is
mostly based on me thinking about how we'd deploy off-SoC clocks.
There's also the diagnostic issues Sacha mentioned, if we don't keep
some source information handy it's hard to tell what clock logging is
talking about.

> It should not matter whether clkdev is used, or an alternative method
> to specify this stuff via DT.  Keep the clk_get()/clk_put() _separate_
> from the consolidation of the rest.

We do need some way to have some idea which clocks we're talking about,
and for off-SoC stuff passing around struct clk pointers is rather
painful.  At some point some bit of code is going to have to get hold of
the actual struct clk and then map it onto the devices using it.

For device tree we should be able to do that fairly painlessly with just
the struct devices, without device tree you either have to have the
structs handy or use names.  At the minute the infrastructure is
somewhat lacking here.

WARNING: multiple messages have this Message-ID (diff)
From: broonie@opensource.wolfsonmicro.com (Mark Brown)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 5/6] clk: Support multiple instances of the same clock provider
Date: Mon, 11 Jul 2011 19:53:45 +0900	[thread overview]
Message-ID: <20110711105342.GE5092@opensource.wolfsonmicro.com> (raw)
In-Reply-To: <20110711093439.GB3239@n2100.arm.linux.org.uk>

On Mon, Jul 11, 2011 at 10:34:39AM +0100, Russell King - ARM Linux wrote:
> On Mon, Jul 11, 2011 at 11:53:56AM +0900, Mark Brown wrote:

> > +	/* Since we currently match clock providers on a purely string
> > +	 * based method add a prefix based on the device name if a
> > +	 * device is provided.  When we have support for device tree

> This "clk consolidation" is really idiotic.  The clk matching mechanism
> should have _nothing_ to do with the rest of the clk API, especially the
> consolidation effort.

It's not touching clkdev, the comment is somewhat misleading and is
mostly based on me thinking about how we'd deploy off-SoC clocks.
There's also the diagnostic issues Sacha mentioned, if we don't keep
some source information handy it's hard to tell what clock logging is
talking about.

> It should not matter whether clkdev is used, or an alternative method
> to specify this stuff via DT.  Keep the clk_get()/clk_put() _separate_
> from the consolidation of the rest.

We do need some way to have some idea which clocks we're talking about,
and for off-SoC stuff passing around struct clk pointers is rather
painful.  At some point some bit of code is going to have to get hold of
the actual struct clk and then map it onto the devices using it.

For device tree we should be able to do that fairly painlessly with just
the struct devices, without device tree you either have to have the
structs handy or use names.  At the minute the infrastructure is
somewhat lacking here.

  reply	other threads:[~2011-07-11 10:53 UTC|newest]

Thread overview: 72+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-07-11  2:53 [PATCH 0/6] clk: Initial feedback for off-SoC slow bus clocks Mark Brown
2011-07-11  2:53 ` Mark Brown
2011-07-11  2:53 ` Mark Brown
2011-07-11  2:53 ` [PATCH 1/6] clk: Prototype and document clk_register() Mark Brown
2011-07-11  2:53   ` Mark Brown
2011-07-11  2:53   ` Mark Brown
2011-07-11  2:53   ` [PATCH 2/6] clk: Provide a dummy clk_unregister() Mark Brown
2011-07-11  2:53     ` Mark Brown
2011-07-11  2:53     ` Mark Brown
2011-07-11  2:53   ` [PATCH 3/6] clk: Constify struct clk_hw_ops Mark Brown
2011-07-11  2:53     ` Mark Brown
2011-07-11  2:53     ` Mark Brown
2011-07-11  2:53   ` [PATCH 4/6] clk: Add Kconfig option to build all generic clk drivers Mark Brown
2011-07-11  2:53     ` Mark Brown
2011-07-11  2:53     ` Mark Brown
2011-07-11  2:53   ` [PATCH 5/6] clk: Support multiple instances of the same clock provider Mark Brown
2011-07-11  2:53     ` Mark Brown
2011-07-11  2:53     ` Mark Brown
2011-07-11  9:34     ` [PATCH 5/6] clk: Support multiple instances of the same clock Russell King - ARM Linux
2011-07-11  9:34       ` [PATCH 5/6] clk: Support multiple instances of the same clock provider Russell King - ARM Linux
2011-07-11  9:34       ` Russell King - ARM Linux
2011-07-11 10:53       ` Mark Brown [this message]
2011-07-11 10:53         ` Mark Brown
2011-07-11 10:53         ` Mark Brown
2011-07-11 11:11         ` [PATCH 5/6] clk: Support multiple instances of the same clock Russell King - ARM Linux
2011-07-11 11:11           ` [PATCH 5/6] clk: Support multiple instances of the same clock provider Russell King - ARM Linux
2011-07-11 11:11           ` Russell King - ARM Linux
2011-07-11 11:41           ` [PATCH 5/6] clk: Support multiple instances of the same clock Mark Brown
2011-07-11 11:41             ` [PATCH 5/6] clk: Support multiple instances of the same clock provider Mark Brown
2011-07-11 11:41             ` Mark Brown
2011-07-11  2:53   ` [PATCH 6/6] clk: Add initial WM831x clock driver Mark Brown
2011-07-11  2:53     ` Mark Brown
2011-07-11  2:53     ` Mark Brown
2011-07-15  2:53     ` Grant Likely
2011-07-15  2:53       ` Grant Likely
2011-07-15  2:53       ` Grant Likely
2011-07-15  5:05       ` Mark Brown
2011-07-15  5:05         ` Mark Brown
2011-07-15  5:05         ` Mark Brown
2011-07-15  5:14         ` Ryan Mallon
2011-07-15  5:14           ` Ryan Mallon
2011-07-15  5:14           ` Ryan Mallon
2011-07-15  2:53   ` [PATCH 1/6] clk: Prototype and document clk_register() Grant Likely
2011-07-15  2:53     ` Grant Likely
2011-07-15  2:53     ` Grant Likely
2011-07-11  3:57 ` [PATCH 0/6] clk: Initial feedback for off-SoC slow bus clocks Mark Brown
2011-07-11  3:57   ` Mark Brown
2011-07-11  3:57   ` Mark Brown
2011-07-11  4:30   ` Mike Frysinger
2011-07-11  4:30     ` Mike Frysinger
2011-07-11  4:30     ` Mike Frysinger
2011-07-11  4:56     ` Barry Song
2011-07-11  4:56       ` Barry Song
2011-07-11  4:56       ` Barry Song
2011-07-11  5:01       ` [uclinux-dist-devel] [PATCH 0/6] clk: Initial feedback for Mike Frysinger
2011-07-11  5:01         ` [uclinux-dist-devel] [PATCH 0/6] clk: Initial feedback for off-SoC slow bus clocks Mike Frysinger
2011-07-11  5:01         ` Mike Frysinger
2011-07-11  9:31 ` Russell King - ARM Linux
2011-07-11  9:31   ` Russell King - ARM Linux
2011-07-11  9:31   ` Russell King - ARM Linux
2011-07-11 10:07   ` Sascha Hauer
2011-07-11 10:07     ` Sascha Hauer
2011-07-11 10:07     ` Sascha Hauer
2011-07-11 10:28     ` Russell King - ARM Linux
2011-07-11 10:28       ` Russell King - ARM Linux
2011-07-11 10:28       ` Russell King - ARM Linux
2011-07-11 10:46       ` Sascha Hauer
2011-07-11 10:46         ` Sascha Hauer
2011-07-11 10:46         ` Sascha Hauer
2011-07-11 11:43         ` Mark Brown
2011-07-11 11:43           ` Mark Brown
2011-07-11 11:43           ` Mark Brown

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=20110711105342.GE5092@opensource.wolfsonmicro.com \
    --to=broonie@opensource.wolfsonmicro.com \
    --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.