[PATCH v2 0/6] clk: mvebu: initial support for AP806 clocks

[PATCH v2 0/6] clk: mvebu: initial support for AP806 clocks

[Thomas Petazzoni]

Hello,

The following set of patches add initial support for the main clocks
found in the AP806 hardware block, which is the central block used in
the newest Marvell 7K and 8K 64-bits processors.

Two new drivers are added, one for the so-called "core" clocks and one
for the "ring" clocks. The latter are child clocks from one of the
core clocks. The "core" clocks are fixed rate clocks, but their rate
is calculated from values in the Sample At Reset register.

Changes since v1:
 - Introduce a minimal DT binding for the AP806 DFX Server register
   area, and make the clock DT nodes child nodes of the DFX server
   node. Implementation-wise, we use the simple-mfd/syscon mechanism.
 - Separate the DT binding documentation into its own patches.

Thanks!

Thomas

Thomas Petazzoni (6):
  dt-bindings: arm/marvell: add DT bindings for AP806 DFX Server
  dt-bindings: clock: add DT bindings for AP806 core clocks
  dt-bindings: clock: add DT bindings for AP806 ring clocks
  clk: unconditionally recurse into clk/mvebu/
  clk: mvebu: add AP806 core clock driver
  clk: mvebu: add AP806 ring clock driver

 .../arm/marvell/marvell,ap806-dfx-server.txt       |  19 ++++
 .../clock/mvebu-armada-ap806-core-clock.txt        |  35 ++++++
 .../clock/mvebu-armada-ap806-ring-clock.txt        |  36 ++++++
 drivers/clk/Makefile                               |   2 +-
 drivers/clk/mvebu/Kconfig                          |   6 +
 drivers/clk/mvebu/Makefile                         |   3 +-
 drivers/clk/mvebu/ap806-core.c                     | 121 +++++++++++++++++++++
 drivers/clk/mvebu/ap806-ring.c                     |  74 +++++++++++++
 8 files changed, 294 insertions(+), 2 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/arm/marvell/marvell,ap806-dfx-server.txt
 create mode 100644 Documentation/devicetree/bindings/clock/mvebu-armada-ap806-core-clock.txt
 create mode 100644 Documentation/devicetree/bindings/clock/mvebu-armada-ap806-ring-clock.txt
 create mode 100644 drivers/clk/mvebu/ap806-core.c
 create mode 100644 drivers/clk/mvebu/ap806-ring.c

-- 
2.6.4

[PATCH v2 1/6] dt-bindings: arm/marvell: add DT bindings for AP806 DFX Server

[Thomas Petazzoni]

The following patch adds a Device Tree binding documentation for the
AP806 DFX Server register area found in Marvell Armada 7K/8K SOCs.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
 .../bindings/arm/marvell/marvell,ap806-dfx-server.txt | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/marvell/marvell,ap806-dfx-server.txt

diff --git a/Documentation/devicetree/bindings/arm/marvell/marvell,ap806-dfx-server.txt b/Documentation/devicetree/bindings/arm/marvell/marvell,ap806-dfx-server.txt
new file mode 100644
index 0000000..44eb3f0
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/marvell/marvell,ap806-dfx-server.txt
@@ -0,0 +1,19 @@
+Marvell AP806 DFX Server
+------------------------
+
+The Marvell AP806 HW block (which is a core component of the Marvell
+Armada 7K and 8K SOCs) has a set of registers called "DFX
+Server". This set of registers contains miscellaneous registers, most
+of them being used for silicon fine-tuning and manufacturing testing,
+and as such are not publicly documented. However, this DFX server
+register range also contains a few documented and useful registers,
+for example for clock control.
+
+This Device Tree binding allows to represent the entire DFX server
+register space as one single DT node.
+
+Required properties:
+- compatible: the first and second values must be:
+	"simple-mfd", "syscon"
+- reg: address and length of following register sets for the DFX
+  server
-- 
2.6.4

[PATCH v2 1/6] dt-bindings: arm/marvell: add DT bindings for AP806 DFX Server

[Stephen Boyd]

On 02/24, Thomas Petazzoni wrote:
> +Marvell AP806 DFX Server
> +------------------------
> +
> +The Marvell AP806 HW block (which is a core component of the Marvell
> +Armada 7K and 8K SOCs) has a set of registers called "DFX
> +Server". This set of registers contains miscellaneous registers, most
> +of them being used for silicon fine-tuning and manufacturing testing,
> +and as such are not publicly documented. However, this DFX server
> +register range also contains a few documented and useful registers,
> +for example for clock control.
> +
> +This Device Tree binding allows to represent the entire DFX server
> +register space as one single DT node.
> +
> +Required properties:
> +- compatible: the first and second values must be:
> +	"simple-mfd", "syscon"
> +- reg: address and length of following register sets for the DFX
> +  server

Example?

I would think the binding would be done in a way that we don't
have to describe every little register in this misc register
block. Instead, dfx server has a compatible:

 node at f00 {
 	reg = <0xf00 0x100>;
	compatible = "marvell,dfx-ap806";
	#clock-cells = <1>;
 };

And then a driver that probes this compatible string and
registers a handful of clks. If we ever get into a situation
where we want to expose non-clk functionality from this device
node, we would make some sort of mfd driver that probes based on
the same compatible string and creates platform devices in
software to register the clk device component and whatever other
device type is used. In that situation, we could assign a regmap
to the mfd device and the clk device would be a child of the mfd
and get a regmap through the dev->parent pointer.

TL;DR I'm still lost why we have to describe each clk in DT.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v2 1/6] dt-bindings: arm/marvell: add DT bindings for AP806 DFX Server

[Thomas Petazzoni]

Stephen,

Thanks for your feedback!

On Thu, 25 Feb 2016 15:37:10 -0800, Stephen Boyd wrote:

> I would think the binding would be done in a way that we don't
> have to describe every little register in this misc register
> block. Instead, dfx server has a compatible:
> 
>  node at f00 {
>  	reg = <0xf00 0x100>;
> 	compatible = "marvell,dfx-ap806";
> 	#clock-cells = <1>;
>  };
> 
> And then a driver that probes this compatible string and
> registers a handful of clks. If we ever get into a situation
> where we want to expose non-clk functionality from this device
> node, we would make some sort of mfd driver that probes based on
> the same compatible string and creates platform devices in
> software to register the clk device component and whatever other
> device type is used. In that situation, we could assign a regmap
> to the mfd device and the clk device would be a child of the mfd
> and get a regmap through the dev->parent pointer.
> 
> TL;DR I'm still lost why we have to describe each clk in DT.

I would entirely agree with you if this DFX Server was some sort of
"system control" IP block that provided clocks, resets, and all sort of
other features.

But this DFX server thing is just a bunch of registers with absolutely
no relation to clocks. Due to this, it would be completely awkward to
have clock references like:

	serial {
		clocks = <&dfxserver 42>;
	};

One will wonder "why the heck this UART controller is using a clock
from this really odd dfxserver thing" ? Currently we have:

	serial {
		clocks = <&coreclk 4>;
	};

which makes a *lot* more sense.

Also, your idea of just hiding everything behind a MFD bothers me quite
a bit. If I push this idea further, then why shouldn't I replace my
entire DT with a single node, that covers the entire register space of
my SoC, and then handle *everything* as a huge MFD. In a way, it would
be quite useful for me, as it would resolve the on-going dispute over
DT binding stability with Rob and Mark.

For sure, I wouldn't have any DT backward compatibility issue, because
everything is hidden in my big MFD. But in terms of the DT as a
representation of the different HW blocks and the relations between
then, such a choice would be quite a failure.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[PATCH v2 1/6] dt-bindings: arm/marvell: add DT bindings for AP806 DFX Server

[Stephen Boyd]

On 02/26, Thomas Petazzoni wrote:
> I would entirely agree with you if this DFX Server was some sort of
> "system control" IP block that provided clocks, resets, and all sort of
> other features.
> 
> But this DFX server thing is just a bunch of registers with absolutely
> no relation to clocks. Due to this, it would be completely awkward to
> have clock references like:
> 
> 	serial {
> 		clocks = <&dfxserver 42>;
> 	};
> 
> One will wonder "why the heck this UART controller is using a clock
> from this really odd dfxserver thing" ? Currently we have:
> 
> 	serial {
> 		clocks = <&coreclk 4>;
> 	};
> 
> which makes a *lot* more sense.

Sorry I don't see the difference and I don't agree with this
argument. dfxserver is just a phandle and possibly a poorly named
one at that. So is coreclk. The second example doesn't make a
*lot* more sense or really any more sense than the first example.
Maybe some #define should be used to make things readable:
&dfxserver CORE_CLK_X or something. Why someone would care what
the name of the phandle is for where the clk is coming from makes
no sense to me.

The miscellaneous register dumping ground, i.e. dfxserver, is a
total mess in hardware, agreed, but it doesn't mean we need to
pick it apart and describe the bits and pieces of it so that our
DT can be read as &coreclk 4 instead of &dfxserver 42.

Somebody delivered this dfxserver hardware block into the SoC.
They decided to put random clk control in there. In terms of
hardware blocks, I would guess that dfxserver has a couple clk
wires coming out and some SoC integration engineer had to wire
those up to the places like the uart that actually use them.
Embrace these hardware design decisions. Represent the hardware
in DT as it is represented in hardware by making one node for the
dfxserver because dfxserver is a hardware block.

> 
> Also, your idea of just hiding everything behind a MFD bothers me quite
> a bit. If I push this idea further, then why shouldn't I replace my
> entire DT with a single node, that covers the entire register space of
> my SoC, and then handle *everything* as a huge MFD. In a way, it would
> be quite useful for me, as it would resolve the on-going dispute over
> DT binding stability with Rob and Mark.

That's a straw man fallacy. Nobody is asking for this. DT is
about describing relations between hardware blocks and the
resources they use. It is *not* about describing register level
details of hardware blocks and providing some data heavy format
so that drivers are nothing besides DT data driven husks of code.
Nor is it about grouping clk subtypes into different DT subnodes
to make writing drivers easier. That's what gets us into the mess
of DT backward compatibility when the data that should have been
in the driver has been put into DT.

> 
> For sure, I wouldn't have any DT backward compatibility issue, because
> everything is hidden in my big MFD. But in terms of the DT as a
> representation of the different HW blocks and the relations between
> then, such a choice would be quite a failure.
> 

I don't see any failure. The dfxserver is a hardware block and
that happens to be a clk provider, plain and simple. Consumers of
those clks are related to the dfxserver and we've properly
expressed the relations between them.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v2 1/6] dt-bindings: arm/marvell: add DT bindings for AP806 DFX Server

[Rob Herring]

On Fri, Feb 26, 2016 at 03:55:49PM -0800, Stephen Boyd wrote:
> On 02/26, Thomas Petazzoni wrote:
> > I would entirely agree with you if this DFX Server was some sort of
> > "system control" IP block that provided clocks, resets, and all sort of
> > other features.
> > 
> > But this DFX server thing is just a bunch of registers with absolutely
> > no relation to clocks. Due to this, it would be completely awkward to
> > have clock references like:
> > 
> > 	serial {
> > 		clocks = <&dfxserver 42>;
> > 	};
> > 
> > One will wonder "why the heck this UART controller is using a clock
> > from this really odd dfxserver thing" ? Currently we have:
> > 
> > 	serial {
> > 		clocks = <&coreclk 4>;
> > 	};
> > 
> > which makes a *lot* more sense.

Really, this is your argument?

> Sorry I don't see the difference and I don't agree with this
> argument. dfxserver is just a phandle and possibly a poorly named
> one at that. So is coreclk. The second example doesn't make a
> *lot* more sense or really any more sense than the first example.
> Maybe some #define should be used to make things readable:
> &dfxserver CORE_CLK_X or something. Why someone would care what
> the name of the phandle is for where the clk is coming from makes
> no sense to me.
> 
> The miscellaneous register dumping ground, i.e. dfxserver, is a
> total mess in hardware, agreed, but it doesn't mean we need to
> pick it apart and describe the bits and pieces of it so that our
> DT can be read as &coreclk 4 instead of &dfxserver 42.
> 
> Somebody delivered this dfxserver hardware block into the SoC.
> They decided to put random clk control in there. In terms of
> hardware blocks, I would guess that dfxserver has a couple clk
> wires coming out and some SoC integration engineer had to wire
> those up to the places like the uart that actually use them.
> Embrace these hardware design decisions. Represent the hardware
> in DT as it is represented in hardware by making one node for the
> dfxserver because dfxserver is a hardware block.

Agreed.

> > Also, your idea of just hiding everything behind a MFD bothers me quite
> > a bit. If I push this idea further, then why shouldn't I replace my
> > entire DT with a single node, that covers the entire register space of
> > my SoC, and then handle *everything* as a huge MFD. In a way, it would
> > be quite useful for me, as it would resolve the on-going dispute over
> > DT binding stability with Rob and Mark.
> 
> That's a straw man fallacy. Nobody is asking for this. DT is
> about describing relations between hardware blocks and the
> resources they use. It is *not* about describing register level
> details of hardware blocks and providing some data heavy format
> so that drivers are nothing besides DT data driven husks of code.
> Nor is it about grouping clk subtypes into different DT subnodes
> to make writing drivers easier. That's what gets us into the mess
> of DT backward compatibility when the data that should have been
> in the driver has been put into DT.
> 
> > 
> > For sure, I wouldn't have any DT backward compatibility issue, because
> > everything is hidden in my big MFD. But in terms of the DT as a
> > representation of the different HW blocks and the relations between
> > then, such a choice would be quite a failure.

What other functions do you have? You previously said the block was DFT 
registers which I would not expect s/w to ever touch.

> I don't see any failure. The dfxserver is a hardware block and
> that happens to be a clk provider, plain and simple. Consumers of
> those clks are related to the dfxserver and we've properly
> expressed the relations between them.

And you could have other types of consumers. Nothing requires nodes and 
providers to be 1-1.

You're being told to do it this way by multiple maintainers both because 
it is the preferred way to describe clocks and it gives a better chance 
for stable bindings. 

Rob

[PATCH v2 2/6] dt-bindings: clock: add DT bindings for AP806 core clocks

[Thomas Petazzoni]

This commit adds the Device Tree binding description for the AP806
core clocks, used on Marvell Armada 7K/8K SOCs.

Since the AP806 core clocks register is part of the "DFX Server"
register area, the DT binding is meant to be used as a sub-node of the
DFX Server DT binding, which is described separately.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
 .../clock/mvebu-armada-ap806-core-clock.txt        | 35 ++++++++++++++++++++++
 1 file changed, 35 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/clock/mvebu-armada-ap806-core-clock.txt

diff --git a/Documentation/devicetree/bindings/clock/mvebu-armada-ap806-core-clock.txt b/Documentation/devicetree/bindings/clock/mvebu-armada-ap806-core-clock.txt
new file mode 100644
index 0000000..996c47f
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/mvebu-armada-ap806-core-clock.txt
@@ -0,0 +1,35 @@
+* Clock bindings for Marvell MVEBU AP806 Core clocks
+
+The Marvell MVEBU Armada 7K/8K SoCs contain a block called AP806,
+hosting the CPU and other core components of the CPU. This Device Tree
+binding allows to describe the core clocks of the AP806, whose
+frequencies are determined by reading the Sample-At-Reset (SAR)
+register. This register is part of the DFX server register area,
+covered by the DT binding described at
+Documentation/devicetree/bindings/arm/marvell/marvell,ap806-dfx-server.txt. Therefore,
+the DT node for the AP806 Core clocks must appear as a child node of
+the DFX server Device Tree node.
+
+Clock consumers must specify the desired clock by having the clock ID
+in its "clocks" phandle cell.
+
+The following is a list of provided IDs and clock names for the core
+Armada AP806 clocks:
+
+ 0 = DDR
+ 1 = Ring
+ 2 = CPU
+
+Required properties:
+- compatible: must be be one of the following:
+	"marvell,armada-ap806-core-clock"
+- #clock-cells: from common clock binding; shall be set to 1
+- clock-output-names: name of the output clocks
+
+Example:
+
+	coreclk: clk at 204 {
+		compatible = "marvell,armada-ap806-core-clock";
+		#clock-cells = <1>;
+		clock-output-names = "ddr", "ring", "cpu";
+	};
-- 
2.6.4

[PATCH v2 3/6] dt-bindings: clock: add DT bindings for AP806 ring clocks

[Thomas Petazzoni]

This commit adds the Device Tree binding description for the AP806
ring clocks, used on Marvell Armada 7K/8K SOCs.

Since the AP806 ring clocks register is part of the "DFX Server"
register area, the DT binding is meant to be used as a sub-node of the
DFX Server DT binding, which is described separately.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
 .../clock/mvebu-armada-ap806-ring-clock.txt        | 36 ++++++++++++++++++++++
 1 file changed, 36 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/clock/mvebu-armada-ap806-ring-clock.txt

diff --git a/Documentation/devicetree/bindings/clock/mvebu-armada-ap806-ring-clock.txt b/Documentation/devicetree/bindings/clock/mvebu-armada-ap806-ring-clock.txt
new file mode 100644
index 0000000..8c8030a
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/mvebu-armada-ap806-ring-clock.txt
@@ -0,0 +1,36 @@
+* Clock bindings for Marvell MVEBU AP806 Ring clocks
+
+The Marvell MVEBU Armada 7K/8K SoCs contain a block called AP806,
+hosting the CPU and other core components of the CPU. This Device Tree
+binding allows to describe the ring clocks of the AP806, which are
+derived from the Ring Core clock, after a dividing factor.
+
+The register giving the dividing factors is part of the DFX server
+register area, covered by the DT binding described at
+Documentation/devicetree/bindings/arm/marvell/marvell,ap806-dfx-server.txt. Therefore,
+the DT node for the AP806 Ring clocks must appear as a child node of
+the DFX server Device Tree node.
+
+The following is a list of provided IDs and clock names on Armada
+AP806 RING dividers:
+
+ 0 = Ring 0
+ 1 = Ring 2
+ 2 = Ring 3
+ 3 = Ring 4
+ 4 = Ring 5
+
+Required properties:
+- compatible: must be one of the following:
+	"marvell,armada-ap806-ring-clock"
+- #clock-cells : from common clock binding; shall be set to 1
+- clock-output-names: name of the output clocks
+
+Example:
+
+	ringclk: clk at 250 {
+		compatible = "marvell,armada-ap806-ring-clock";
+		#clock-cells = <1>;
+		clock-output-names = "ring-0", "ring-2", "ring-3", "ring-4", "ring-5";
+		clocks = <&coreclk 1>;
+	};
-- 
2.6.4

[PATCH v2 4/6] clk: unconditionally recurse into clk/mvebu/

[Thomas Petazzoni]

The drivers/clk/mvebu directory is only being built when
CONFIG_PLAT_ORION=y. As we are going to support additional mvebu
platforms in drivers/clk/mvebu, which don't have CONFIG_PLAT_ORION=y,
we need to recurse into this directory regardless of the value of
CONFIG_PLAT_ORION.

Since all files in drivers/clk/mvebu/ are already conditionally
compiled depending on various Kconfig options, we can recurse
unconditionally into drivers/clk/mvebu without any other change.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
 drivers/clk/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index b038e36..e08bb0e 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -61,7 +61,7 @@ obj-$(CONFIG_ARCH_MEDIATEK)		+= mediatek/
 ifeq ($(CONFIG_COMMON_CLK), y)
 obj-$(CONFIG_ARCH_MMP)			+= mmp/
 endif
-obj-$(CONFIG_PLAT_ORION)		+= mvebu/
+obj-y					+= mvebu/
 obj-$(CONFIG_ARCH_MESON)		+= meson/
 obj-$(CONFIG_ARCH_MXS)			+= mxs/
 obj-$(CONFIG_MACH_PISTACHIO)		+= pistachio/
-- 
2.6.4

[PATCH v2 5/6] clk: mvebu: add AP806 core clock driver

[Thomas Petazzoni]

This commit adds a new driver to handle the core clocks found in the
AP806 HW block, which is the core block of all Armada 7K and 8K
Marvell 64-bits processors. This core clock driver reads the
Sample-At-Reset register to determine the frequencies of several core
clocks: DDR, Ring and CPU clocks.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
 drivers/clk/mvebu/Kconfig      |   3 +
 drivers/clk/mvebu/Makefile     |   2 +-
 drivers/clk/mvebu/ap806-core.c | 121 +++++++++++++++++++++++++++++++++++++++++
 3 files changed, 125 insertions(+), 1 deletion(-)
 create mode 100644 drivers/clk/mvebu/ap806-core.c

diff --git a/drivers/clk/mvebu/Kconfig b/drivers/clk/mvebu/Kconfig
index 2769625..fd84172 100644
--- a/drivers/clk/mvebu/Kconfig
+++ b/drivers/clk/mvebu/Kconfig
@@ -42,3 +42,6 @@ config KIRKWOOD_CLK
 config ORION_CLK
 	bool
 	select MVEBU_CLK_COMMON
+
+config ARMADA_AP806_CORE_CLK
+	bool
diff --git a/drivers/clk/mvebu/Makefile b/drivers/clk/mvebu/Makefile
index 8866115..db5c28c 100644
--- a/drivers/clk/mvebu/Makefile
+++ b/drivers/clk/mvebu/Makefile
@@ -1,11 +1,11 @@
 obj-$(CONFIG_MVEBU_CLK_COMMON)	+= common.o
 obj-$(CONFIG_MVEBU_CLK_CPU) 	+= clk-cpu.o
 obj-$(CONFIG_MVEBU_CLK_COREDIV)	+= clk-corediv.o
-
 obj-$(CONFIG_ARMADA_370_CLK)	+= armada-370.o
 obj-$(CONFIG_ARMADA_375_CLK)	+= armada-375.o
 obj-$(CONFIG_ARMADA_38X_CLK)	+= armada-38x.o
 obj-$(CONFIG_ARMADA_39X_CLK)	+= armada-39x.o
+obj-$(CONFIG_ARMADA_AP806_CORE_CLK) += ap806-core.o
 obj-$(CONFIG_ARMADA_XP_CLK)	+= armada-xp.o
 obj-$(CONFIG_DOVE_CLK)		+= dove.o dove-divider.o
 obj-$(CONFIG_KIRKWOOD_CLK)	+= kirkwood.o
diff --git a/drivers/clk/mvebu/ap806-core.c b/drivers/clk/mvebu/ap806-core.c
new file mode 100644
index 0000000..b858d6b
--- /dev/null
+++ b/drivers/clk/mvebu/ap806-core.c
@@ -0,0 +1,121 @@
+/*
+ * Marvell Armada AP806 core clocks
+ *
+ * Copyright (C) 2016 Marvell
+ *
+ * Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2.  This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#define pr_fmt(fmt) "ap806-core-clk: " fmt
+
+#include <linux/kernel.h>
+#include <linux/clk.h>
+#include <linux/clk-provider.h>
+#include <linux/io.h>
+#include <linux/mfd/syscon.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/regmap.h>
+
+/*
+ * AP806 PLLs:
+ *   0 - DDR
+ *   1 - Ring
+ *   2 - CPU
+ */
+
+#define AP806_SAMPLE_AT_RESET_REG 0x204
+
+#define AP806_PLL_NUM	3
+#define AP806_PLL_FREQ  7
+
+/* SAR parameters to get the PLL data */
+struct apclk_sar {
+	int mask;
+	int offset;
+	const char *name;
+};
+
+static const struct apclk_sar
+ap806_core_clk_sar[AP806_PLL_NUM]  __initconst = {
+	{ .mask = 0x7,	.offset = 21 },
+	{ .mask = 0x7,	.offset = 18 },
+	{ .mask = 0x7,	.offset = 15 },
+};
+
+static struct clk *ap806_core_clks[AP806_PLL_NUM];
+
+static struct clk_onecell_data ap806_core_clk_data = {
+	.clks = ap806_core_clks,
+	.clk_num = AP806_PLL_NUM,
+};
+
+/* mapping between SAR value to frequency */
+static const u32
+ap806_core_clk_freq[AP806_PLL_NUM][AP806_PLL_FREQ] __initconst = {
+	{ 2400000000, 2100000000, 1800000000,
+	  1600000000, 1300000000, 1300000000,
+	  1300000000 },
+	{ 2000000000, 1800000000, 1600000000,
+	  1400000000, 1200000000, 1200000000,
+	  1200000000 },
+	{ 2500000000, 2200000000, 2000000000,
+	  1700000000, 1600000000, 1200000000,
+	  1200000000 },
+};
+
+static unsigned long __init ap806_core_clk_get_freq(u32 reg, int clk_idx)
+{
+	int freq_idx;
+	const struct apclk_sar *clk_info;
+
+	clk_info = &ap806_core_clk_sar[clk_idx];
+
+	freq_idx = (reg >> clk_info->offset) & clk_info->mask;
+	if (WARN_ON(freq_idx > AP806_PLL_FREQ))
+		return 0;
+	else
+		return ap806_core_clk_freq[clk_idx][freq_idx];
+}
+
+static void __init ap806_core_clk_init(struct device_node *np)
+{
+	struct regmap *regmap;
+	u32 reg;
+	int i;
+
+	regmap = syscon_node_to_regmap(np->parent);
+	if (IS_ERR(regmap)) {
+		pr_err("cannot get regmap\n");
+		return;
+	}
+
+	if (regmap_read(regmap, AP806_SAMPLE_AT_RESET_REG, &reg)) {
+		pr_err("cannot read from regmap\n");
+		return;
+	}
+
+	for (i = 0; i < AP806_PLL_NUM; i++) {
+		unsigned long freq;
+		const char *name;
+
+		freq = ap806_core_clk_get_freq(reg, i);
+
+		of_property_read_string_index(np, "clock-output-names",
+					      i, &name);
+
+		ap806_core_clks[i] =
+			clk_register_fixed_rate(NULL, name, NULL,
+						CLK_IS_ROOT, freq);
+	}
+
+	of_clk_add_provider(np, of_clk_src_onecell_get,
+			    &ap806_core_clk_data);
+}
+
+CLK_OF_DECLARE(ap806_core_clk, "marvell,armada-ap806-core-clock",
+	       ap806_core_clk_init);
-- 
2.6.4

[PATCH v2 6/6] clk: mvebu: add AP806 ring clock driver

[Thomas Petazzoni]

This commit adds a new driver to handle the ring clocks found in the
AP806 HW block, which is the core block of all Armada 7K and 8K
Marvell 64-bits processors. Those ring clocks are derived from the
core ring clock handled by the AP806 core clock driver. The ring
clocks are used by various peripherals inside the AP806.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
 drivers/clk/mvebu/Kconfig      |  3 ++
 drivers/clk/mvebu/Makefile     |  1 +
 drivers/clk/mvebu/ap806-ring.c | 74 ++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 78 insertions(+)
 create mode 100644 drivers/clk/mvebu/ap806-ring.c

diff --git a/drivers/clk/mvebu/Kconfig b/drivers/clk/mvebu/Kconfig
index fd84172..5d30aac 100644
--- a/drivers/clk/mvebu/Kconfig
+++ b/drivers/clk/mvebu/Kconfig
@@ -45,3 +45,6 @@ config ORION_CLK
 
 config ARMADA_AP806_CORE_CLK
 	bool
+
+config ARMADA_AP806_RING_CLK
+	bool
diff --git a/drivers/clk/mvebu/Makefile b/drivers/clk/mvebu/Makefile
index db5c28c..48ca2d3 100644
--- a/drivers/clk/mvebu/Makefile
+++ b/drivers/clk/mvebu/Makefile
@@ -6,6 +6,7 @@ obj-$(CONFIG_ARMADA_375_CLK)	+= armada-375.o
 obj-$(CONFIG_ARMADA_38X_CLK)	+= armada-38x.o
 obj-$(CONFIG_ARMADA_39X_CLK)	+= armada-39x.o
 obj-$(CONFIG_ARMADA_AP806_CORE_CLK) += ap806-core.o
+obj-$(CONFIG_ARMADA_AP806_RING_CLK) += ap806-ring.o
 obj-$(CONFIG_ARMADA_XP_CLK)	+= armada-xp.o
 obj-$(CONFIG_DOVE_CLK)		+= dove.o dove-divider.o
 obj-$(CONFIG_KIRKWOOD_CLK)	+= kirkwood.o
diff --git a/drivers/clk/mvebu/ap806-ring.c b/drivers/clk/mvebu/ap806-ring.c
new file mode 100644
index 0000000..f980192
--- /dev/null
+++ b/drivers/clk/mvebu/ap806-ring.c
@@ -0,0 +1,74 @@
+/*
+ * Marvell Armada AP806 ring clocks
+ *
+ * Copyright (C) 2016 Marvell
+ *
+ * Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2.  This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#define pr_fmt(fmt) "ap806-ring-clk: " fmt
+
+#include <linux/kernel.h>
+#include <linux/clk.h>
+#include <linux/clk-provider.h>
+#include <linux/io.h>
+#include <linux/mfd/syscon.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/regmap.h>
+
+#define AP806_RING_DIV_CLK_REG 0x250
+
+#define AP806_RING_DIV_NUM	5
+
+static struct clk *ap806_ring_clks[AP806_RING_DIV_NUM];
+
+static struct clk_onecell_data ap806_ring_clk_data = {
+	.clks = ap806_ring_clks,
+	.clk_num = AP806_RING_DIV_NUM,
+};
+
+static void __init ap806_ring_clk_init(struct device_node *np)
+{
+	struct regmap *regmap;
+	const char *parent;
+	u32 reg;
+	int i;
+
+	regmap = syscon_node_to_regmap(np->parent);
+	if (IS_ERR(regmap)) {
+		pr_err("cannot get regmap\n");
+		return;
+	}
+
+	if (regmap_read(regmap, AP806_RING_DIV_CLK_REG, &reg)) {
+		pr_err("cannot read from regmap\n");
+		return;
+	}
+
+	parent = of_clk_get_parent_name(np, 0);
+
+	for (i = 0; i < AP806_RING_DIV_NUM; i++) {
+		unsigned long divider;
+		const char *name;
+
+		/* Each clock is represented by 6 bits */
+		divider = (reg >> (6 * i)) & 0x3f;
+
+		of_property_read_string_index(np, "clock-output-names",
+					      i, &name);
+
+		ap806_ring_clks[i] =
+			clk_register_fixed_factor(NULL, name, parent,
+						  0, 1, divider);
+	}
+
+	of_clk_add_provider(np, of_clk_src_onecell_get, &ap806_ring_clk_data);
+}
+
+CLK_OF_DECLARE(ap806_ring_clk, "marvell,armada-ap806-ring-clock",
+	       ap806_ring_clk_init);
-- 
2.6.4