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: [PATCH 0/6] clk: Initial feedback for off-SoC slow bus clocks
Date: Mon, 11 Jul 2011 02:53:44 +0000	[thread overview]
Message-ID: <20110711025344.GA27497@opensource.wolfsonmicro.com> (raw)

I've just been having a go at implementing generic clk API support for
an off-SoC device on a slow bus, the clocking module in the wm831x/2x
series of PMICs.  Unfortunately as I don't currently have access to a
platform that has been converted to use the API I've not actually been
able to test the code but I'm reasonably optimistic that the code will
Just Work(tm) as the API seems fairly straightforward.

The biggest issue I ran into was that as the clocks are all registered
by name with the API if you've got two instances of the same off-SoC
device in the system you'll not be able to disambiguate between the
clocks it provides.  I've added a simple solution for this in the form
of a patch which takes a struct device as an argument and adds that to
the name of the registered clock.  This isn't ideal but should give
stable names which systems can use together with clkdev to match clocks
up with their users.  I believe that when we have device tree bindings
for clocks we should be able to use the device to access the bindings
and avoid this mangling - Grant, is that correct?

Otherwise everything seems to work pretty well from the driver side for
these devices, I've added some minor updates which came up naturally
while writing the driver code and seemed fairly obvious.  One of these
was a change to provide a user visible Kconfig option for building the
clock drivers, the idea being to make it easier to do build tests.  I
did also wonder if it's worth adding a patch to enable the API on x86
(which doesn't currently have a clock API) for coverage.

These patches (which include the two I posted yesterday) are against the
series you posted in May with the exception of the wm831x patch which
also has an additional dependency on "mfd: Add WM831x clock control
register definitions" which is due for merge in the next merge window.
If this stuff is all OK for you it would be good if you could include
the wm831x driver in your tree for this, especially given that there's
nothing in -next.

Mark Brown (6):
      clk: Prototype and document clk_register()
      clk: Provide a dummy clk_unregister()
      clk: Constify struct clk_hw_ops
      clk: Add Kconfig option to build all generic clk drivers
      clk: Support multiple instances of the same clock provider
      clk: Add initial WM831x clock driver

 MAINTAINERS              |    1 +
 drivers/clk/Kconfig      |   16 ++-
 drivers/clk/Makefile     |    1 +
 drivers/clk/clk-wm831x.c |  389 ++++++++++++++++++++++++++++++++++++++++++++++
 drivers/clk/clk.c        |   38 ++++-
 include/linux/clk.h      |   33 ++++
 6 files changed, 472 insertions(+), 6 deletions(-)
 create mode 100644 drivers/clk/clk-wm831x.c

WARNING: multiple messages have this Message-ID (diff)
From: Mark Brown <broonie@opensource.wolfsonmicro.com>
To: Jeremy Kerr <jeremy.kerr@canonical.com>
Cc: linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org, linux-sh@vger.kernel.org,
	patches@opensource.wolfsonmicro.com,
	Grant Likely <grant@secretlab.ca>
Subject: [PATCH 0/6] clk: Initial feedback for off-SoC slow bus clocks
Date: Mon, 11 Jul 2011 11:53:44 +0900	[thread overview]
Message-ID: <20110711025344.GA27497@opensource.wolfsonmicro.com> (raw)

I've just been having a go at implementing generic clk API support for
an off-SoC device on a slow bus, the clocking module in the wm831x/2x
series of PMICs.  Unfortunately as I don't currently have access to a
platform that has been converted to use the API I've not actually been
able to test the code but I'm reasonably optimistic that the code will
Just Work(tm) as the API seems fairly straightforward.

The biggest issue I ran into was that as the clocks are all registered
by name with the API if you've got two instances of the same off-SoC
device in the system you'll not be able to disambiguate between the
clocks it provides.  I've added a simple solution for this in the form
of a patch which takes a struct device as an argument and adds that to
the name of the registered clock.  This isn't ideal but should give
stable names which systems can use together with clkdev to match clocks
up with their users.  I believe that when we have device tree bindings
for clocks we should be able to use the device to access the bindings
and avoid this mangling - Grant, is that correct?

Otherwise everything seems to work pretty well from the driver side for
these devices, I've added some minor updates which came up naturally
while writing the driver code and seemed fairly obvious.  One of these
was a change to provide a user visible Kconfig option for building the
clock drivers, the idea being to make it easier to do build tests.  I
did also wonder if it's worth adding a patch to enable the API on x86
(which doesn't currently have a clock API) for coverage.

These patches (which include the two I posted yesterday) are against the
series you posted in May with the exception of the wm831x patch which
also has an additional dependency on "mfd: Add WM831x clock control
register definitions" which is due for merge in the next merge window.
If this stuff is all OK for you it would be good if you could include
the wm831x driver in your tree for this, especially given that there's
nothing in -next.

Mark Brown (6):
      clk: Prototype and document clk_register()
      clk: Provide a dummy clk_unregister()
      clk: Constify struct clk_hw_ops
      clk: Add Kconfig option to build all generic clk drivers
      clk: Support multiple instances of the same clock provider
      clk: Add initial WM831x clock driver

 MAINTAINERS              |    1 +
 drivers/clk/Kconfig      |   16 ++-
 drivers/clk/Makefile     |    1 +
 drivers/clk/clk-wm831x.c |  389 ++++++++++++++++++++++++++++++++++++++++++++++
 drivers/clk/clk.c        |   38 ++++-
 include/linux/clk.h      |   33 ++++
 6 files changed, 472 insertions(+), 6 deletions(-)
 create mode 100644 drivers/clk/clk-wm831x.c

WARNING: multiple messages have this Message-ID (diff)
From: broonie@opensource.wolfsonmicro.com (Mark Brown)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 0/6] clk: Initial feedback for off-SoC slow bus clocks
Date: Mon, 11 Jul 2011 11:53:44 +0900	[thread overview]
Message-ID: <20110711025344.GA27497@opensource.wolfsonmicro.com> (raw)

I've just been having a go at implementing generic clk API support for
an off-SoC device on a slow bus, the clocking module in the wm831x/2x
series of PMICs.  Unfortunately as I don't currently have access to a
platform that has been converted to use the API I've not actually been
able to test the code but I'm reasonably optimistic that the code will
Just Work(tm) as the API seems fairly straightforward.

The biggest issue I ran into was that as the clocks are all registered
by name with the API if you've got two instances of the same off-SoC
device in the system you'll not be able to disambiguate between the
clocks it provides.  I've added a simple solution for this in the form
of a patch which takes a struct device as an argument and adds that to
the name of the registered clock.  This isn't ideal but should give
stable names which systems can use together with clkdev to match clocks
up with their users.  I believe that when we have device tree bindings
for clocks we should be able to use the device to access the bindings
and avoid this mangling - Grant, is that correct?

Otherwise everything seems to work pretty well from the driver side for
these devices, I've added some minor updates which came up naturally
while writing the driver code and seemed fairly obvious.  One of these
was a change to provide a user visible Kconfig option for building the
clock drivers, the idea being to make it easier to do build tests.  I
did also wonder if it's worth adding a patch to enable the API on x86
(which doesn't currently have a clock API) for coverage.

These patches (which include the two I posted yesterday) are against the
series you posted in May with the exception of the wm831x patch which
also has an additional dependency on "mfd: Add WM831x clock control
register definitions" which is due for merge in the next merge window.
If this stuff is all OK for you it would be good if you could include
the wm831x driver in your tree for this, especially given that there's
nothing in -next.

Mark Brown (6):
      clk: Prototype and document clk_register()
      clk: Provide a dummy clk_unregister()
      clk: Constify struct clk_hw_ops
      clk: Add Kconfig option to build all generic clk drivers
      clk: Support multiple instances of the same clock provider
      clk: Add initial WM831x clock driver

 MAINTAINERS              |    1 +
 drivers/clk/Kconfig      |   16 ++-
 drivers/clk/Makefile     |    1 +
 drivers/clk/clk-wm831x.c |  389 ++++++++++++++++++++++++++++++++++++++++++++++
 drivers/clk/clk.c        |   38 ++++-
 include/linux/clk.h      |   33 ++++
 6 files changed, 472 insertions(+), 6 deletions(-)
 create mode 100644 drivers/clk/clk-wm831x.c

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

Thread overview: 72+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-07-11  2:53 Mark Brown [this message]
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 ` [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       ` [PATCH 5/6] clk: Support multiple instances of the same clock Mark Brown
2011-07-11 10:53         ` [PATCH 5/6] clk: Support multiple instances of the same clock provider 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=20110711025344.GA27497@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.