[PATCH 00/13] arm64: Allwinner A64 support based on sunxi-ng

linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed

* [PATCH 00/13] arm64: Allwinner A64 support based on sunxi-ng
@ 2016-07-26 20:30 Maxime Ripard
  2016-07-26 20:30 ` [PATCH 01/13] clk: sunxi-ng: mux: Rename mux macro to be consistent Maxime Ripard
                   ` (14 more replies)
  0 siblings, 15 replies; 34+ messages in thread
From: Maxime Ripard @ 2016-07-26 20:30 UTC (permalink / raw)
  To: Rob Herring, Chen-Yu Tsai, Mike Turquette, Stephen Boyd
  Cc: devicetree, Andre Przywara, linux-arm-kernel, linux-kernel,
	linux-clk, Maxime Ripard

Hi,

Here is the previous A64 patches made by Andre [1], reworked to use
the new sunxi-ng clock framework.

This uses the current H3 clock code, as both are really similar. The
first patches are just meant to rework slightly the H3 code, before
introducing the A64-related patches.

Some WiP stuff have been removed, such as the MMC part, but this serie
already has a decent amount of devices supported: uart, i2c, rsb, etc.

Let me know what you think,
Maxime

1: http://lists.infradead.org/pipermail/linux-arm-kernel/2016-February/410338.html

Andre Przywara (5):
  arm64: sunxi: Kconfig: add essential pinctrl driver
  arm64: Kconfig: sunxi: add PINCTRL
  Documentation: devicetree: add vendor prefix for Pine64
  arm64: dts: add Allwinner A64 SoC .dtsi
  arm64: dts: add Pine64 support

Maxime Ripard (8):
  clk: sunxi-ng: mux: Rename mux macro to be consistent
  clk: sunxi-ng: mux: Add mux table support
  clk: sunxi-ng: sun8i: Rename DDR and video plls
  clk: sunxi-ng: sun8i: Fix register offset
  clk: sunxi-ng: sun8i: Rename H3 only clocks
  clk: sunxi-ng: sun8i: Move fixed factors around
  clk: sunxi-ng: sun8i: Prefix clock defines by SoC Name
  clk: sunxi-ng: Add A64 clocks

 Documentation/devicetree/bindings/arm/sunxi.txt    |   1 +
 .../devicetree/bindings/clock/sunxi-ccu.txt        |   1 +
 .../devicetree/bindings/vendor-prefixes.txt        |   1 +
 MAINTAINERS                                        |   1 +
 arch/arm/boot/dts/sun8i-h3.dtsi                    |  62 +-
 arch/arm64/Kconfig.platforms                       |   2 +
 arch/arm64/boot/dts/Makefile                       |   1 +
 arch/arm64/boot/dts/allwinner/Makefile             |   5 +
 .../boot/dts/allwinner/sun50i-a64-pine64-plus.dts  |  50 ++
 .../arm64/boot/dts/allwinner/sun50i-a64-pine64.dts |  70 ++
 arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi      | 273 +++++++
 drivers/clk/sunxi-ng/Kconfig                       |  13 +-
 drivers/clk/sunxi-ng/Makefile                      |   2 +-
 drivers/clk/sunxi-ng/ccu-sun50i-a64.h              |  68 ++
 drivers/clk/sunxi-ng/ccu-sun8i-h3.c                | 896 ++++++++++++++++-----
 drivers/clk/sunxi-ng/ccu-sun8i-h3.h                |  44 +-
 drivers/clk/sunxi-ng/ccu_div.h                     |   2 +-
 drivers/clk/sunxi-ng/ccu_mp.h                      |   2 +-
 drivers/clk/sunxi-ng/ccu_mux.c                     |  14 +
 drivers/clk/sunxi-ng/ccu_mux.h                     |  29 +-
 include/dt-bindings/clock/sun50i-a64-ccu.h         | 132 +++
 include/dt-bindings/clock/sun8i-h3-ccu.h           | 188 ++---
 include/dt-bindings/reset/sun50i-a64-ccu.h         |  97 +++
 23 files changed, 1588 insertions(+), 366 deletions(-)
 create mode 100644 arch/arm64/boot/dts/allwinner/Makefile
 create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-plus.dts
 create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
 create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
 create mode 100644 drivers/clk/sunxi-ng/ccu-sun50i-a64.h
 create mode 100644 include/dt-bindings/clock/sun50i-a64-ccu.h
 create mode 100644 include/dt-bindings/reset/sun50i-a64-ccu.h

-- 
2.9.2

^ permalink raw reply	[flat|nested] 34+ messages in thread

* [PATCH 01/13] clk: sunxi-ng: mux: Rename mux macro to be consistent
  2016-07-26 20:30 [PATCH 00/13] arm64: Allwinner A64 support based on sunxi-ng Maxime Ripard
@ 2016-07-26 20:30 ` Maxime Ripard
  2016-07-26 20:30 ` [PATCH 02/13] clk: sunxi-ng: mux: Add mux table support Maxime Ripard
                   ` (13 subsequent siblings)
  14 siblings, 0 replies; 34+ messages in thread
From: Maxime Ripard @ 2016-07-26 20:30 UTC (permalink / raw)
  To: Rob Herring, Chen-Yu Tsai, Mike Turquette, Stephen Boyd
  Cc: devicetree, Andre Przywara, linux-arm-kernel, linux-kernel,
	linux-clk, Maxime Ripard

Rename the internal mux macro to be consistent with the other internal
structure macros.

Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
---
 drivers/clk/sunxi-ng/ccu_div.h | 2 +-
 drivers/clk/sunxi-ng/ccu_mp.h  | 2 +-
 drivers/clk/sunxi-ng/ccu_mux.h | 6 +++---
 3 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/clk/sunxi-ng/ccu_div.h b/drivers/clk/sunxi-ng/ccu_div.h
index 653ade5769b3..5d98549e23a6 100644
--- a/drivers/clk/sunxi-ng/ccu_div.h
+++ b/drivers/clk/sunxi-ng/ccu_div.h
@@ -83,7 +83,7 @@ struct ccu_div {
 	struct ccu_div _struct = {					\
 		.enable	= _gate,					\
 		.div	= _SUNXI_CCU_DIV(_mshift, _mwidth),		\
-		.mux	= SUNXI_CLK_MUX(_muxshift, _muxwidth),		\
+		.mux	= _SUNXI_CCU_MUX(_muxshift, _muxwidth),		\
 		.common	= {						\
 			.reg		= _reg,				\
 			.hw.init	= CLK_HW_INIT_PARENTS(_name,	\
diff --git a/drivers/clk/sunxi-ng/ccu_mp.h b/drivers/clk/sunxi-ng/ccu_mp.h
index 3cf12bf95962..edf9215ea8cc 100644
--- a/drivers/clk/sunxi-ng/ccu_mp.h
+++ b/drivers/clk/sunxi-ng/ccu_mp.h
@@ -44,7 +44,7 @@ struct ccu_mp {
 		.enable	= _gate,					\
 		.m	= _SUNXI_CCU_DIV(_mshift, _mwidth),		\
 		.p	= _SUNXI_CCU_DIV(_pshift, _pwidth),		\
-		.mux	= SUNXI_CLK_MUX(_muxshift, _muxwidth),		\
+		.mux	= _SUNXI_CCU_MUX(_muxshift, _muxwidth),		\
 		.common	= {						\
 			.reg		= _reg,				\
 			.hw.init	= CLK_HW_INIT_PARENTS(_name,	\
diff --git a/drivers/clk/sunxi-ng/ccu_mux.h b/drivers/clk/sunxi-ng/ccu_mux.h
index 945082631e7d..95cfecec3c39 100644
--- a/drivers/clk/sunxi-ng/ccu_mux.h
+++ b/drivers/clk/sunxi-ng/ccu_mux.h
@@ -21,7 +21,7 @@ struct ccu_mux_internal {
 	} variable_prediv;
 };
 
-#define SUNXI_CLK_MUX(_shift, _width)	\
+#define _SUNXI_CCU_MUX(_shift, _width)		\
 	{					\
 		.shift	= _shift,		\
 		.width	= _width,		\
@@ -37,7 +37,7 @@ struct ccu_mux {
 
 #define SUNXI_CCU_MUX(_struct, _name, _parents, _reg, _shift, _width, _flags) \
 	struct ccu_mux _struct = {					\
-		.mux	= SUNXI_CLK_MUX(_shift, _width),		\
+		.mux	= _SUNXI_CCU_MUX(_shift, _width),		\
 		.common	= {						\
 			.reg		= _reg,				\
 			.hw.init	= CLK_HW_INIT_PARENTS(_name,	\
@@ -51,7 +51,7 @@ struct ccu_mux {
 				_shift, _width, _gate, _flags)		\
 	struct ccu_mux _struct = {					\
 		.enable	= _gate,					\
-		.mux	= SUNXI_CLK_MUX(_shift, _width),		\
+		.mux	= _SUNXI_CCU_MUX(_shift, _width),		\
 		.common	= {						\
 			.reg		= _reg,				\
 			.hw.init	= CLK_HW_INIT_PARENTS(_name,	\
-- 
2.9.2

^ permalink raw reply related	[flat|nested] 34+ messages in thread

* [PATCH 02/13] clk: sunxi-ng: mux: Add mux table support
  2016-07-26 20:30 [PATCH 00/13] arm64: Allwinner A64 support based on sunxi-ng Maxime Ripard
  2016-07-26 20:30 ` [PATCH 01/13] clk: sunxi-ng: mux: Rename mux macro to be consistent Maxime Ripard
@ 2016-07-26 20:30 ` Maxime Ripard
  2016-07-26 20:30 ` [PATCH 03/13] clk: sunxi-ng: sun8i: Rename DDR and video plls Maxime Ripard
                   ` (12 subsequent siblings)
  14 siblings, 0 replies; 34+ messages in thread
From: Maxime Ripard @ 2016-07-26 20:30 UTC (permalink / raw)
  To: Rob Herring, Chen-Yu Tsai, Mike Turquette, Stephen Boyd
  Cc: devicetree, Andre Przywara, linux-arm-kernel, linux-kernel,
	linux-clk, Maxime Ripard

Add support for the table based muxes, and add macros to register them.

Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
---
 drivers/clk/sunxi-ng/ccu_mux.c | 14 ++++++++++++++
 drivers/clk/sunxi-ng/ccu_mux.h | 27 ++++++++++++++++++++-------
 2 files changed, 34 insertions(+), 7 deletions(-)

diff --git a/drivers/clk/sunxi-ng/ccu_mux.c b/drivers/clk/sunxi-ng/ccu_mux.c
index 58fc36e7dcce..f942044b038a 100644
--- a/drivers/clk/sunxi-ng/ccu_mux.c
+++ b/drivers/clk/sunxi-ng/ccu_mux.c
@@ -100,6 +100,7 @@ out:
 u8 ccu_mux_helper_get_parent(struct ccu_common *common,
 			     struct ccu_mux_internal *cm)
 {
+	int num_parents = clk_hw_get_num_parents(&common->hw);
 	u32 reg;
 	u8 parent;
 
@@ -107,6 +108,16 @@ u8 ccu_mux_helper_get_parent(struct ccu_common *common,
 	parent = reg >> cm->shift;
 	parent &= (1 << cm->width) - 1;
 
+	if (cm->table) {
+		int i;
+
+		for (i = 0; i < num_parents; i++)
+			if (cm->table[i] == parent)
+				return i;
+
+		return -EINVAL;
+	}
+
 	return parent;
 }
 
@@ -117,6 +128,9 @@ int ccu_mux_helper_set_parent(struct ccu_common *common,
 	unsigned long flags;
 	u32 reg;
 
+	if (cm->table)
+		index = cm->table[index];
+
 	spin_lock_irqsave(common->lock, flags);
 
 	reg = readl(common->base + common->reg);
diff --git a/drivers/clk/sunxi-ng/ccu_mux.h b/drivers/clk/sunxi-ng/ccu_mux.h
index 95cfecec3c39..00cec8ac6ae3 100644
--- a/drivers/clk/sunxi-ng/ccu_mux.h
+++ b/drivers/clk/sunxi-ng/ccu_mux.h
@@ -9,6 +9,8 @@ struct ccu_mux_internal {
 	u8	shift;
 	u8	width;
 
+	const u8	*table;
+
 	struct {
 		u8	index;
 		u8	div;
@@ -21,12 +23,16 @@ struct ccu_mux_internal {
 	} variable_prediv;
 };
 
-#define _SUNXI_CCU_MUX(_shift, _width)		\
-	{					\
-		.shift	= _shift,		\
-		.width	= _width,		\
+#define _SUNXI_CCU_MUX_TABLE(_shift, _width, _table)	\
+	{						\
+		.shift	= _shift,			\
+		.width	= _width,			\
+		.table	= _table,			\
 	}
 
+#define _SUNXI_CCU_MUX(_shift, _width)			\
+	_SUNXI_CCU_MUX_TABLE(_shift, _width, NULL)
+
 struct ccu_mux {
 	u16			reg;
 	u32			enable;
@@ -47,11 +53,12 @@ struct ccu_mux {
 		}							\
 	}
 
-#define SUNXI_CCU_MUX_WITH_GATE(_struct, _name, _parents, _reg,		\
-				_shift, _width, _gate, _flags)		\
+#define SUNXI_CCU_MUX_TABLE_WITH_GATE(_struct, _name, _parents, _table,	\
+				      _reg,  _shift, _width, _gate,	\
+				      _flags)				\
 	struct ccu_mux _struct = {					\
 		.enable	= _gate,					\
-		.mux	= _SUNXI_CCU_MUX(_shift, _width),		\
+		.mux	= _SUNXI_CCU_MUX_TABLE(_shift, _width, _table),	\
 		.common	= {						\
 			.reg		= _reg,				\
 			.hw.init	= CLK_HW_INIT_PARENTS(_name,	\
@@ -61,6 +68,12 @@ struct ccu_mux {
 		}							\
 	}
 
+#define SUNXI_CCU_MUX_WITH_GATE(_struct, _name, _parents, _reg,		\
+				_shift, _width, _gate, _flags)		\
+	SUNXI_CCU_MUX_TABLE_WITH_GATE(_struct, _name, _parents, NULL,	\
+				      _reg,  _shift, _width, _gate,	\
+				      _flags)
+
 static inline struct ccu_mux *hw_to_ccu_mux(struct clk_hw *hw)
 {
 	struct ccu_common *common = hw_to_ccu_common(hw);
-- 
2.9.2

^ permalink raw reply related	[flat|nested] 34+ messages in thread

* [PATCH 03/13] clk: sunxi-ng: sun8i: Rename DDR and video plls
  2016-07-26 20:30 [PATCH 00/13] arm64: Allwinner A64 support based on sunxi-ng Maxime Ripard
  2016-07-26 20:30 ` [PATCH 01/13] clk: sunxi-ng: mux: Rename mux macro to be consistent Maxime Ripard
  2016-07-26 20:30 ` [PATCH 02/13] clk: sunxi-ng: mux: Add mux table support Maxime Ripard
@ 2016-07-26 20:30 ` Maxime Ripard
  2016-07-27  7:57   ` kbuild test robot
  2016-07-26 20:30 ` [PATCH 04/13] clk: sunxi-ng: sun8i: Fix register offset Maxime Ripard
                   ` (11 subsequent siblings)
  14 siblings, 1 reply; 34+ messages in thread
From: Maxime Ripard @ 2016-07-26 20:30 UTC (permalink / raw)
  To: Rob Herring, Chen-Yu Tsai, Mike Turquette, Stephen Boyd
  Cc: devicetree, Andre Przywara, linux-arm-kernel, linux-kernel,
	linux-clk, Maxime Ripard

In order to deal with the A64 that will have several video and ddr plls,
rename the first ones to add an index.

Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
---
 drivers/clk/sunxi-ng/ccu-sun8i-h3.c | 20 ++++++++++----------
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/drivers/clk/sunxi-ng/ccu-sun8i-h3.c b/drivers/clk/sunxi-ng/ccu-sun8i-h3.c
index 9af359544110..68492808e5fc 100644
--- a/drivers/clk/sunxi-ng/ccu-sun8i-h3.c
+++ b/drivers/clk/sunxi-ng/ccu-sun8i-h3.c
@@ -57,8 +57,8 @@ static SUNXI_CCU_NM_WITH_GATE_LOCK(pll_audio_base_clk, "pll-audio-base",
 				   BIT(28),	/* lock */
 				   0);
 
-static SUNXI_CCU_NM_WITH_FRAC_GATE_LOCK(pll_video_clk, "pll-video",
-					"osc24M", 0x0010,
+static SUNXI_CCU_NM_WITH_FRAC_GATE_LOCK(pll_video0_clk, "pll-video0",
+					"osc24M", 0x010,
 					8, 7,		/* N */
 					0, 4,		/* M */
 					BIT(24),	/* frac enable */
@@ -81,7 +81,7 @@ static SUNXI_CCU_NM_WITH_FRAC_GATE_LOCK(pll_ve_clk, "pll-ve",
 					BIT(28),	/* lock */
 					0);
 
-static SUNXI_CCU_NKM_WITH_GATE_LOCK(pll_ddr_clk, "pll-ddr",
+static SUNXI_CCU_NKM_WITH_GATE_LOCK(pll_ddr0_clk, "pll-ddr0",
 				    "osc24M", 0x020,
 				    8, 5,	/* N */
 				    4, 2,	/* K */
@@ -422,7 +422,7 @@ static SUNXI_CCU_GATE(usb_ohci2_clk,	"usb-ohci2",	"osc24M",
 static SUNXI_CCU_GATE(usb_ohci3_clk,	"usb-ohci3",	"osc24M",
 		      0x0cc, BIT(19), 0);
 
-static const char * const dram_parents[] = { "pll-ddr", "pll-periph0-2x" };
+static const char * const dram_parents[] = { "pll-ddr0", "pll-periph0-2x" };
 static SUNXI_CCU_M_WITH_MUX(dram_clk, "dram", dram_parents,
 			    0x0f4, 0, 4, 20, 2, CLK_IS_CRITICAL);
 
@@ -439,7 +439,7 @@ static const char * const de_parents[] = { "pll-periph0-2x", "pll-de" };
 static SUNXI_CCU_M_WITH_MUX_GATE(de_clk, "de", de_parents,
 				 0x104, 0, 4, 24, 3, BIT(31), 0);
 
-static const char * const tcon_parents[] = { "pll-video" };
+static const char * const tcon_parents[] = { "pll-video0" };
 static SUNXI_CCU_M_WITH_MUX_GATE(tcon_clk, "tcon", tcon_parents,
 				 0x118, 0, 4, 24, 3, BIT(31), 0);
 
@@ -458,7 +458,7 @@ static const char * const csi_sclk_parents[] = { "pll-periph0", "pll-periph1" };
 static SUNXI_CCU_M_WITH_MUX_GATE(csi_sclk_clk, "csi-sclk", csi_sclk_parents,
 				 0x134, 16, 4, 24, 3, BIT(31), 0);
 
-static const char * const csi_mclk_parents[] = { "osc24M", "pll-video", "pll-periph0" };
+static const char * const csi_mclk_parents[] = { "osc24M", "pll-video0", "pll-periph0" };
 static SUNXI_CCU_M_WITH_MUX_GATE(csi_mclk_clk, "csi-mclk", csi_mclk_parents,
 				 0x134, 0, 5, 8, 3, BIT(15), 0);
 
@@ -470,14 +470,14 @@ static SUNXI_CCU_GATE(ac_dig_clk,	"ac-dig",	"pll-audio",
 static SUNXI_CCU_GATE(avs_clk,		"avs",		"osc24M",
 		      0x144, BIT(31), 0);
 
-static const char * const hdmi_parents[] = { "pll-video" };
+static const char * const hdmi_parents[] = { "pll-video0" };
 static SUNXI_CCU_M_WITH_MUX_GATE(hdmi_clk, "hdmi", hdmi_parents,
 				 0x150, 0, 4, 24, 2, BIT(31), 0);
 
 static SUNXI_CCU_GATE(hdmi_ddc_clk,	"hdmi-ddc",	"osc24M",
 		      0x154, BIT(31), 0);
 
-static const char * const mbus_parents[] = { "osc24M", "pll-periph0-2x", "pll-ddr" };
+static const char * const mbus_parents[] = { "osc24M", "pll-periph0-2x", "pll-ddr0" };
 static SUNXI_CCU_M_WITH_MUX_GATE(mbus_clk, "mbus", mbus_parents,
 				 0x15c, 0, 3, 24, 2, BIT(31), CLK_IS_CRITICAL);
 
@@ -487,9 +487,9 @@ static SUNXI_CCU_M_WITH_GATE(gpu_clk, "gpu", "pll-gpu",
 static struct ccu_common *sun8i_h3_ccu_clks[] = {
 	&pll_cpux_clk.common,
 	&pll_audio_base_clk.common,
-	&pll_video_clk.common,
+	&pll_video0_clk.common,
 	&pll_ve_clk.common,
-	&pll_ddr_clk.common,
+	&pll_ddr0_clk.common,
 	&pll_periph0_clk.common,
 	&pll_gpu_clk.common,
 	&pll_periph1_clk.common,
-- 
2.9.2

^ permalink raw reply related	[flat|nested] 34+ messages in thread

* Re: [PATCH 03/13] clk: sunxi-ng: sun8i: Rename DDR and video plls
  2016-07-26 20:30 ` [PATCH 03/13] clk: sunxi-ng: sun8i: Rename DDR and video plls Maxime Ripard
@ 2016-07-27  7:57   ` kbuild test robot
  0 siblings, 0 replies; 34+ messages in thread
From: kbuild test robot @ 2016-07-27  7:57 UTC (permalink / raw)
  To: Maxime Ripard
  Cc: kbuild-all, Rob Herring, Chen-Yu Tsai, Mike Turquette,
	Stephen Boyd, devicetree, Andre Przywara, linux-arm-kernel,
	linux-kernel, linux-clk, Maxime Ripard

[-- Attachment #1: Type: text/plain, Size: 2878 bytes --]

Hi,

[auto build test ERROR on clk/clk-next]
[also build test ERROR on next-20160726]
[cannot apply to v4.7]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]

url:    https://github.com/0day-ci/linux/commits/Maxime-Ripard/arm64-Allwinner-A64-support-based-on-sunxi-ng/20160727-084745
base:   https://git.kernel.org/pub/scm/linux/kernel/git/clk/linux.git clk-next
config: arm64-allmodconfig (attached as .config)
compiler: aarch64-linux-gnu-gcc (Debian 5.4.0-6) 5.4.0 20160609
reproduce:
        wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # save the attached .config to linux build tree
        make.cross ARCH=arm64 

Note: the linux-review/Maxime-Ripard/arm64-Allwinner-A64-support-based-on-sunxi-ng/20160727-084745 HEAD b4837ac76808c0a3584aef785ddfe74589c1b8fb builds fine.
      It only hurts bisectibility.

All errors (new ones prefixed by >>):

>> drivers/clk/sunxi-ng/ccu-sun8i-h3.c:620:23: error: 'pll_video_clk' undeclared here (not in a function)
      [CLK_PLL_VIDEO]  = &pll_video_clk.common.hw,
                          ^
>> drivers/clk/sunxi-ng/ccu-sun8i-h3.c:622:21: error: 'pll_ddr_clk' undeclared here (not in a function)
      [CLK_PLL_DDR]  = &pll_ddr_clk.common.hw,
                        ^

vim +/pll_video_clk +620 drivers/clk/sunxi-ng/ccu-sun8i-h3.c

0577e485 Maxime Ripard 2016-06-29  614  		[CLK_PLL_CPUX]		= &pll_cpux_clk.common.hw,
0577e485 Maxime Ripard 2016-06-29  615  		[CLK_PLL_AUDIO_BASE]	= &pll_audio_base_clk.common.hw,
0577e485 Maxime Ripard 2016-06-29  616  		[CLK_PLL_AUDIO]		= &pll_audio_clk.hw,
0577e485 Maxime Ripard 2016-06-29  617  		[CLK_PLL_AUDIO_2X]	= &pll_audio_2x_clk.hw,
0577e485 Maxime Ripard 2016-06-29  618  		[CLK_PLL_AUDIO_4X]	= &pll_audio_4x_clk.hw,
0577e485 Maxime Ripard 2016-06-29  619  		[CLK_PLL_AUDIO_8X]	= &pll_audio_8x_clk.hw,
0577e485 Maxime Ripard 2016-06-29 @620  		[CLK_PLL_VIDEO]		= &pll_video_clk.common.hw,
0577e485 Maxime Ripard 2016-06-29  621  		[CLK_PLL_VE]		= &pll_ve_clk.common.hw,
0577e485 Maxime Ripard 2016-06-29 @622  		[CLK_PLL_DDR]		= &pll_ddr_clk.common.hw,
0577e485 Maxime Ripard 2016-06-29  623  		[CLK_PLL_PERIPH0]	= &pll_periph0_clk.common.hw,
0577e485 Maxime Ripard 2016-06-29  624  		[CLK_PLL_PERIPH0_2X]	= &pll_periph0_2x_clk.hw,
0577e485 Maxime Ripard 2016-06-29  625  		[CLK_PLL_GPU]		= &pll_gpu_clk.common.hw,

:::::: The code at line 620 was first introduced by commit
:::::: 0577e4853bfb4c65f620fa56d3157692df7f766e clk: sunxi-ng: Add H3 clocks

:::::: TO: Maxime Ripard <maxime.ripard@free-electrons.com>
:::::: CC: Michael Turquette <mturquette@baylibre.com>

---
0-DAY kernel test infrastructure                Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all                   Intel Corporation

[-- Attachment #2: .config.gz --]
[-- Type: application/octet-stream, Size: 50253 bytes --]

^ permalink raw reply	[flat|nested] 34+ messages in thread

* [PATCH 04/13] clk: sunxi-ng: sun8i: Fix register offset
  2016-07-26 20:30 [PATCH 00/13] arm64: Allwinner A64 support based on sunxi-ng Maxime Ripard
                   ` (2 preceding siblings ...)
  2016-07-26 20:30 ` [PATCH 03/13] clk: sunxi-ng: sun8i: Rename DDR and video plls Maxime Ripard
@ 2016-07-26 20:30 ` Maxime Ripard
  2016-07-26 20:30 ` [PATCH 05/13] clk: sunxi-ng: sun8i: Rename H3 only clocks Maxime Ripard
                   ` (10 subsequent siblings)
  14 siblings, 0 replies; 34+ messages in thread
From: Maxime Ripard @ 2016-07-26 20:30 UTC (permalink / raw)
  To: Rob Herring, Chen-Yu Tsai, Mike Turquette, Stephen Boyd
  Cc: devicetree, Andre Przywara, linux-arm-kernel, linux-kernel,
	linux-clk, Maxime Ripard

Some registers offset were having one 0 too many compared to the others.
Remove it.

Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
---
 drivers/clk/sunxi-ng/ccu-sun8i-h3.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/clk/sunxi-ng/ccu-sun8i-h3.c b/drivers/clk/sunxi-ng/ccu-sun8i-h3.c
index 68492808e5fc..3c236eefbb3a 100644
--- a/drivers/clk/sunxi-ng/ccu-sun8i-h3.c
+++ b/drivers/clk/sunxi-ng/ccu-sun8i-h3.c
@@ -70,7 +70,7 @@ static SUNXI_CCU_NM_WITH_FRAC_GATE_LOCK(pll_video0_clk, "pll-video0",
 					0);
 
 static SUNXI_CCU_NM_WITH_FRAC_GATE_LOCK(pll_ve_clk, "pll-ve",
-					"osc24M", 0x0018,
+					"osc24M", 0x018,
 					8, 7,		/* N */
 					0, 4,		/* M */
 					BIT(24),	/* frac enable */
@@ -100,7 +100,7 @@ static SUNXI_CCU_NK_WITH_GATE_LOCK_POSTDIV(pll_periph0_clk, "pll-periph0",
 					   0);
 
 static SUNXI_CCU_NM_WITH_FRAC_GATE_LOCK(pll_gpu_clk, "pll-gpu",
-					"osc24M", 0x0038,
+					"osc24M", 0x038,
 					8, 7,		/* N */
 					0, 4,		/* M */
 					BIT(24),	/* frac enable */
@@ -121,7 +121,7 @@ static SUNXI_CCU_NK_WITH_GATE_LOCK_POSTDIV(pll_periph1_clk, "pll-periph1",
 					   0);
 
 static SUNXI_CCU_NM_WITH_FRAC_GATE_LOCK(pll_de_clk, "pll-de",
-					"osc24M", 0x0048,
+					"osc24M", 0x048,
 					8, 7,		/* N */
 					0, 4,		/* M */
 					BIT(24),	/* frac enable */
-- 
2.9.2

^ permalink raw reply related	[flat|nested] 34+ messages in thread

* [PATCH 05/13] clk: sunxi-ng: sun8i: Rename H3 only clocks
  2016-07-26 20:30 [PATCH 00/13] arm64: Allwinner A64 support based on sunxi-ng Maxime Ripard
                   ` (3 preceding siblings ...)
  2016-07-26 20:30 ` [PATCH 04/13] clk: sunxi-ng: sun8i: Fix register offset Maxime Ripard
@ 2016-07-26 20:30 ` Maxime Ripard
  2016-07-26 20:30 ` [PATCH 06/13] clk: sunxi-ng: sun8i: Move fixed factors around Maxime Ripard
                   ` (9 subsequent siblings)
  14 siblings, 0 replies; 34+ messages in thread
From: Maxime Ripard @ 2016-07-26 20:30 UTC (permalink / raw)
  To: Rob Herring, Chen-Yu Tsai, Mike Turquette, Stephen Boyd
  Cc: devicetree, Andre Przywara, linux-arm-kernel, linux-kernel,
	linux-clk, Maxime Ripard

Add a suffix for the H3-only clocks to prepare the introduction of the A64
clocks.

Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
---
 drivers/clk/sunxi-ng/ccu-sun8i-h3.c | 140 ++++++++++++++++++------------------
 1 file changed, 70 insertions(+), 70 deletions(-)

diff --git a/drivers/clk/sunxi-ng/ccu-sun8i-h3.c b/drivers/clk/sunxi-ng/ccu-sun8i-h3.c
index 3c236eefbb3a..f61d2e245ac4 100644
--- a/drivers/clk/sunxi-ng/ccu-sun8i-h3.c
+++ b/drivers/clk/sunxi-ng/ccu-sun8i-h3.c
@@ -111,7 +111,7 @@ static SUNXI_CCU_NM_WITH_FRAC_GATE_LOCK(pll_gpu_clk, "pll-gpu",
 					BIT(28),	/* lock */
 					0);
 
-static SUNXI_CCU_NK_WITH_GATE_LOCK_POSTDIV(pll_periph1_clk, "pll-periph1",
+static SUNXI_CCU_NK_WITH_GATE_LOCK_POSTDIV(pll_periph1_h3_clk, "pll-periph1",
 					   "osc24M", 0x044,
 					   8, 5,	/* N */
 					   4, 2,	/* K */
@@ -175,9 +175,9 @@ static struct clk_div_table apb1_div_table[] = {
 static SUNXI_CCU_DIV_TABLE(apb1_clk, "apb1", "ahb1",
 			   0x054, 8, 2, apb1_div_table, 0);
 
-static const char * const apb2_parents[] = { "osc32k", "osc24M",
-					     "pll-periph0" , "pll-periph0" };
-static SUNXI_CCU_MP_WITH_MUX(apb2_clk, "apb2", apb2_parents, 0x058,
+static const char * const apb2_h3_parents[] = { "osc32k", "osc24M",
+						"pll-periph0" , "pll-periph0" };
+static SUNXI_CCU_MP_WITH_MUX(apb2_h3_clk, "apb2", apb2_h3_parents, 0x058,
 			     0, 5,	/* M */
 			     16, 2,	/* P */
 			     24, 2,	/* mux */
@@ -235,17 +235,17 @@ static SUNXI_CCU_GATE(bus_ehci0_clk,	"bus-ehci0",	"ahb1",
 		      0x060, BIT(24), 0);
 static SUNXI_CCU_GATE(bus_ehci1_clk,	"bus-ehci1",	"ahb2",
 		      0x060, BIT(25), 0);
-static SUNXI_CCU_GATE(bus_ehci2_clk,	"bus-ehci2",	"ahb2",
+static SUNXI_CCU_GATE(bus_ehci2_h3_clk,	"bus-ehci2",	"ahb2",
 		      0x060, BIT(26), 0);
-static SUNXI_CCU_GATE(bus_ehci3_clk,	"bus-ehci3",	"ahb2",
+static SUNXI_CCU_GATE(bus_ehci3_h3_clk,	"bus-ehci3",	"ahb2",
 		      0x060, BIT(27), 0);
 static SUNXI_CCU_GATE(bus_ohci0_clk,	"bus-ohci0",	"ahb1",
 		      0x060, BIT(28), 0);
 static SUNXI_CCU_GATE(bus_ohci1_clk,	"bus-ohci1",	"ahb2",
 		      0x060, BIT(29), 0);
-static SUNXI_CCU_GATE(bus_ohci2_clk,	"bus-ohci2",	"ahb2",
+static SUNXI_CCU_GATE(bus_ohci2_h3_clk,	"bus-ohci2",	"ahb2",
 		      0x060, BIT(30), 0);
-static SUNXI_CCU_GATE(bus_ohci3_clk,	"bus-ohci3",	"ahb2",
+static SUNXI_CCU_GATE(bus_ohci3_h3_clk,	"bus-ohci3",	"ahb2",
 		      0x060, BIT(31), 0);
 
 static SUNXI_CCU_GATE(bus_ve_clk,	"bus-ve",	"ahb1",
@@ -258,7 +258,7 @@ static SUNXI_CCU_GATE(bus_deinterlace_clk,	"bus-deinterlace",	"ahb1",
 		      0x064, BIT(5), 0);
 static SUNXI_CCU_GATE(bus_csi_clk,	"bus-csi",	"ahb1",
 		      0x064, BIT(8), 0);
-static SUNXI_CCU_GATE(bus_tve_clk,	"bus-tve",	"ahb1",
+static SUNXI_CCU_GATE(bus_tve_h3_clk,	"bus-tve",	"ahb1",
 		      0x064, BIT(9), 0);
 static SUNXI_CCU_GATE(bus_hdmi_clk,	"bus-hdmi",	"ahb1",
 		      0x064, BIT(11), 0);
@@ -300,10 +300,10 @@ static SUNXI_CCU_GATE(bus_uart2_clk,	"bus-uart2",	"apb2",
 		      0x06c, BIT(18), 0);
 static SUNXI_CCU_GATE(bus_uart3_clk,	"bus-uart3",	"apb2",
 		      0x06c, BIT(19), 0);
-static SUNXI_CCU_GATE(bus_scr_clk,	"bus-scr",	"apb2",
+static SUNXI_CCU_GATE(bus_scr_h3_clk,	"bus-scr",	"apb2",
 		      0x06c, BIT(20), 0);
 
-static SUNXI_CCU_GATE(bus_ephy_clk,	"bus-ephy",	"ahb1",
+static SUNXI_CCU_GATE(bus_ephy_h3_clk,	"bus-ephy",	"ahb1",
 		      0x070, BIT(0), 0);
 static SUNXI_CCU_GATE(bus_dbg_clk,	"bus-dbg",	"ahb1",
 		      0x070, BIT(7), 0);
@@ -326,40 +326,40 @@ static SUNXI_CCU_MP_WITH_MUX_GATE(nand_clk, "nand", mod0_default_parents, 0x080,
 				  BIT(31),	/* gate */
 				  0);
 
-static SUNXI_CCU_MP_WITH_MUX_GATE(mmc0_clk, "mmc0", mod0_default_parents, 0x088,
+static SUNXI_CCU_MP_WITH_MUX_GATE(mmc0_h3_clk, "mmc0", mod0_default_parents, 0x088,
 				  0, 4,		/* M */
 				  16, 2,	/* P */
 				  24, 2,	/* mux */
 				  BIT(31),	/* gate */
 				  0);
 
-static SUNXI_CCU_PHASE(mmc0_sample_clk, "mmc0_sample", "mmc0",
+static SUNXI_CCU_PHASE(mmc0_sample_h3_clk, "mmc0_sample", "mmc0",
 		       0x088, 20, 3, 0);
-static SUNXI_CCU_PHASE(mmc0_output_clk, "mmc0_output", "mmc0",
+static SUNXI_CCU_PHASE(mmc0_output_h3_clk, "mmc0_output", "mmc0",
 		       0x088, 8, 3, 0);
 
-static SUNXI_CCU_MP_WITH_MUX_GATE(mmc1_clk, "mmc1", mod0_default_parents, 0x08c,
+static SUNXI_CCU_MP_WITH_MUX_GATE(mmc1_h3_clk, "mmc1", mod0_default_parents, 0x08c,
 				  0, 4,		/* M */
 				  16, 2,	/* P */
 				  24, 2,	/* mux */
 				  BIT(31),	/* gate */
 				  0);
 
-static SUNXI_CCU_PHASE(mmc1_sample_clk, "mmc1_sample", "mmc1",
+static SUNXI_CCU_PHASE(mmc1_sample_h3_clk, "mmc1_sample", "mmc1",
 		       0x08c, 20, 3, 0);
-static SUNXI_CCU_PHASE(mmc1_output_clk, "mmc1_output", "mmc1",
+static SUNXI_CCU_PHASE(mmc1_output_h3_clk, "mmc1_output", "mmc1",
 		       0x08c, 8, 3, 0);
 
-static SUNXI_CCU_MP_WITH_MUX_GATE(mmc2_clk, "mmc2", mod0_default_parents, 0x090,
+static SUNXI_CCU_MP_WITH_MUX_GATE(mmc2_h3_clk, "mmc2", mod0_default_parents, 0x090,
 				  0, 4,		/* M */
 				  16, 2,	/* P */
 				  24, 2,	/* mux */
 				  BIT(31),	/* gate */
 				  0);
 
-static SUNXI_CCU_PHASE(mmc2_sample_clk, "mmc2_sample", "mmc2",
+static SUNXI_CCU_PHASE(mmc2_sample_h3_clk, "mmc2_sample", "mmc2",
 		       0x090, 20, 3, 0);
-static SUNXI_CCU_PHASE(mmc2_output_clk, "mmc2_output", "mmc2",
+static SUNXI_CCU_PHASE(mmc2_output_h3_clk, "mmc2_output", "mmc2",
 		       0x090, 8, 3, 0);
 
 static const char * const ts_parents[] = { "osc24M", "pll-periph0", };
@@ -370,7 +370,7 @@ static SUNXI_CCU_MP_WITH_MUX_GATE(ts_clk, "ts", ts_parents, 0x098,
 				  BIT(31),	/* gate */
 				  0);
 
-static SUNXI_CCU_MP_WITH_MUX_GATE(ce_clk, "ce", mod0_default_parents, 0x09c,
+static SUNXI_CCU_MP_WITH_MUX_GATE(ce_h3_clk, "ce", mod0_default_parents, 0x09c,
 				  0, 4,		/* M */
 				  16, 2,	/* P */
 				  24, 2,	/* mux */
@@ -409,21 +409,21 @@ static SUNXI_CCU_GATE(usb_phy0_clk,	"usb-phy0",	"osc24M",
 		      0x0cc, BIT(8), 0);
 static SUNXI_CCU_GATE(usb_phy1_clk,	"usb-phy1",	"osc24M",
 		      0x0cc, BIT(9), 0);
-static SUNXI_CCU_GATE(usb_phy2_clk,	"usb-phy2",	"osc24M",
+static SUNXI_CCU_GATE(usb_phy2_h3_clk,	"usb-phy2",	"osc24M",
 		      0x0cc, BIT(10), 0);
-static SUNXI_CCU_GATE(usb_phy3_clk,	"usb-phy3",	"osc24M",
+static SUNXI_CCU_GATE(usb_phy3_h3_clk,	"usb-phy3",	"osc24M",
 		      0x0cc, BIT(11), 0);
-static SUNXI_CCU_GATE(usb_ohci0_clk,	"usb-ohci0",	"osc24M",
+static SUNXI_CCU_GATE(usb_ohci0_h3_clk,	"usb-ohci0",	"osc24M",
 		      0x0cc, BIT(16), 0);
-static SUNXI_CCU_GATE(usb_ohci1_clk,	"usb-ohci1",	"osc24M",
+static SUNXI_CCU_GATE(usb_ohci1_h3_clk,	"usb-ohci1",	"osc24M",
 		      0x0cc, BIT(17), 0);
-static SUNXI_CCU_GATE(usb_ohci2_clk,	"usb-ohci2",	"osc24M",
+static SUNXI_CCU_GATE(usb_ohci2_h3_clk,	"usb-ohci2",	"osc24M",
 		      0x0cc, BIT(18), 0);
-static SUNXI_CCU_GATE(usb_ohci3_clk,	"usb-ohci3",	"osc24M",
+static SUNXI_CCU_GATE(usb_ohci3_h3_clk,	"usb-ohci3",	"osc24M",
 		      0x0cc, BIT(19), 0);
 
-static const char * const dram_parents[] = { "pll-ddr0", "pll-periph0-2x" };
-static SUNXI_CCU_M_WITH_MUX(dram_clk, "dram", dram_parents,
+static const char * const dram_h3_parents[] = { "pll-ddr0", "pll-periph0-2x" };
+static SUNXI_CCU_M_WITH_MUX(dram_h3_clk, "dram", dram_h3_parents,
 			    0x0f4, 0, 4, 20, 2, CLK_IS_CRITICAL);
 
 static SUNXI_CCU_GATE(dram_ve_clk,	"dram-ve",	"dram",
@@ -439,12 +439,12 @@ static const char * const de_parents[] = { "pll-periph0-2x", "pll-de" };
 static SUNXI_CCU_M_WITH_MUX_GATE(de_clk, "de", de_parents,
 				 0x104, 0, 4, 24, 3, BIT(31), 0);
 
-static const char * const tcon_parents[] = { "pll-video0" };
-static SUNXI_CCU_M_WITH_MUX_GATE(tcon_clk, "tcon", tcon_parents,
+static const char * const tcon0_h3_parents[] = { "pll-video0" };
+static SUNXI_CCU_M_WITH_MUX_GATE(tcon0_h3_clk, "tcon0", tcon0_h3_parents,
 				 0x118, 0, 4, 24, 3, BIT(31), 0);
 
-static const char * const tve_parents[] = { "pll-de", "pll-periph1" };
-static SUNXI_CCU_M_WITH_MUX_GATE(tve_clk, "tve", tve_parents,
+static const char * const tve_h3_parents[] = { "pll-de", "pll-periph1" };
+static SUNXI_CCU_M_WITH_MUX_GATE(tve_h3_clk, "tve", tve_h3_parents,
 				 0x120, 0, 4, 24, 3, BIT(31), 0);
 
 static const char * const deinterlace_parents[] = { "pll-periph0", "pll-periph1" };
@@ -458,8 +458,8 @@ static const char * const csi_sclk_parents[] = { "pll-periph0", "pll-periph1" };
 static SUNXI_CCU_M_WITH_MUX_GATE(csi_sclk_clk, "csi-sclk", csi_sclk_parents,
 				 0x134, 16, 4, 24, 3, BIT(31), 0);
 
-static const char * const csi_mclk_parents[] = { "osc24M", "pll-video0", "pll-periph0" };
-static SUNXI_CCU_M_WITH_MUX_GATE(csi_mclk_clk, "csi-mclk", csi_mclk_parents,
+static const char * const csi_mclk_h3_parents[] = { "osc24M", "pll-video0", "pll-periph0" };
+static SUNXI_CCU_M_WITH_MUX_GATE(csi_mclk_h3_clk, "csi-mclk", csi_mclk_h3_parents,
 				 0x134, 0, 5, 8, 3, BIT(15), 0);
 
 static SUNXI_CCU_M_WITH_GATE(ve_clk, "ve", "pll-ve",
@@ -470,15 +470,15 @@ static SUNXI_CCU_GATE(ac_dig_clk,	"ac-dig",	"pll-audio",
 static SUNXI_CCU_GATE(avs_clk,		"avs",		"osc24M",
 		      0x144, BIT(31), 0);
 
-static const char * const hdmi_parents[] = { "pll-video0" };
-static SUNXI_CCU_M_WITH_MUX_GATE(hdmi_clk, "hdmi", hdmi_parents,
+static const char * const hdmi_h3_parents[] = { "pll-video0" };
+static SUNXI_CCU_M_WITH_MUX_GATE(hdmi_h3_clk, "hdmi", hdmi_h3_parents,
 				 0x150, 0, 4, 24, 2, BIT(31), 0);
 
 static SUNXI_CCU_GATE(hdmi_ddc_clk,	"hdmi-ddc",	"osc24M",
 		      0x154, BIT(31), 0);
 
-static const char * const mbus_parents[] = { "osc24M", "pll-periph0-2x", "pll-ddr0" };
-static SUNXI_CCU_M_WITH_MUX_GATE(mbus_clk, "mbus", mbus_parents,
+static const char * const mbus_h3_parents[] = { "osc24M", "pll-periph0-2x", "pll-ddr0" };
+static SUNXI_CCU_M_WITH_MUX_GATE(mbus_h3_clk, "mbus", mbus_h3_parents,
 				 0x15c, 0, 3, 24, 2, BIT(31), CLK_IS_CRITICAL);
 
 static SUNXI_CCU_M_WITH_GATE(gpu_clk, "gpu", "pll-gpu",
@@ -492,13 +492,13 @@ static struct ccu_common *sun8i_h3_ccu_clks[] = {
 	&pll_ddr0_clk.common,
 	&pll_periph0_clk.common,
 	&pll_gpu_clk.common,
-	&pll_periph1_clk.common,
+	&pll_periph1_h3_clk.common,
 	&pll_de_clk.common,
 	&cpux_clk.common,
 	&axi_clk.common,
 	&ahb1_clk.common,
 	&apb1_clk.common,
-	&apb2_clk.common,
+	&apb2_h3_clk.common,
 	&ahb2_clk.common,
 	&bus_ce_clk.common,
 	&bus_dma_clk.common,
@@ -515,18 +515,18 @@ static struct ccu_common *sun8i_h3_ccu_clks[] = {
 	&bus_otg_clk.common,
 	&bus_ehci0_clk.common,
 	&bus_ehci1_clk.common,
-	&bus_ehci2_clk.common,
-	&bus_ehci3_clk.common,
+	&bus_ehci2_h3_clk.common,
+	&bus_ehci3_h3_clk.common,
 	&bus_ohci0_clk.common,
 	&bus_ohci1_clk.common,
-	&bus_ohci2_clk.common,
-	&bus_ohci3_clk.common,
+	&bus_ohci2_h3_clk.common,
+	&bus_ohci3_h3_clk.common,
 	&bus_ve_clk.common,
 	&bus_tcon0_clk.common,
 	&bus_tcon1_clk.common,
 	&bus_deinterlace_clk.common,
 	&bus_csi_clk.common,
-	&bus_tve_clk.common,
+	&bus_tve_h3_clk.common,
 	&bus_hdmi_clk.common,
 	&bus_de_clk.common,
 	&bus_gpu_clk.common,
@@ -546,22 +546,22 @@ static struct ccu_common *sun8i_h3_ccu_clks[] = {
 	&bus_uart1_clk.common,
 	&bus_uart2_clk.common,
 	&bus_uart3_clk.common,
-	&bus_scr_clk.common,
-	&bus_ephy_clk.common,
+	&bus_scr_h3_clk.common,
+	&bus_ephy_h3_clk.common,
 	&bus_dbg_clk.common,
 	&ths_clk.common,
 	&nand_clk.common,
-	&mmc0_clk.common,
-	&mmc0_sample_clk.common,
-	&mmc0_output_clk.common,
-	&mmc1_clk.common,
-	&mmc1_sample_clk.common,
-	&mmc1_output_clk.common,
-	&mmc2_clk.common,
-	&mmc2_sample_clk.common,
-	&mmc2_output_clk.common,
+	&mmc0_h3_clk.common,
+	&mmc0_sample_h3_clk.common,
+	&mmc0_output_h3_clk.common,
+	&mmc1_h3_clk.common,
+	&mmc1_sample_h3_clk.common,
+	&mmc1_output_h3_clk.common,
+	&mmc2_h3_clk.common,
+	&mmc2_sample_h3_clk.common,
+	&mmc2_output_h3_clk.common,
 	&ts_clk.common,
-	&ce_clk.common,
+	&ce_h3_clk.common,
 	&spi0_clk.common,
 	&spi1_clk.common,
 	&i2s0_clk.common,
@@ -570,30 +570,30 @@ static struct ccu_common *sun8i_h3_ccu_clks[] = {
 	&spdif_clk.common,
 	&usb_phy0_clk.common,
 	&usb_phy1_clk.common,
-	&usb_phy2_clk.common,
-	&usb_phy3_clk.common,
-	&usb_ohci0_clk.common,
-	&usb_ohci1_clk.common,
-	&usb_ohci2_clk.common,
-	&usb_ohci3_clk.common,
-	&dram_clk.common,
+	&usb_phy2_h3_clk.common,
+	&usb_phy3_h3_clk.common,
+	&usb_ohci0_h3_clk.common,
+	&usb_ohci1_h3_clk.common,
+	&usb_ohci2_h3_clk.common,
+	&usb_ohci3_h3_clk.common,
+	&dram_h3_clk.common,
 	&dram_ve_clk.common,
 	&dram_csi_clk.common,
 	&dram_deinterlace_clk.common,
 	&dram_ts_clk.common,
 	&de_clk.common,
-	&tcon_clk.common,
-	&tve_clk.common,
+	&tcon0_h3_clk.common,
+	&tve_h3_clk.common,
 	&deinterlace_clk.common,
 	&csi_misc_clk.common,
 	&csi_sclk_clk.common,
-	&csi_mclk_clk.common,
+	&csi_mclk_h3_clk.common,
 	&ve_clk.common,
 	&ac_dig_clk.common,
 	&avs_clk.common,
-	&hdmi_clk.common,
+	&hdmi_h3_clk.common,
 	&hdmi_ddc_clk.common,
-	&mbus_clk.common,
+	&mbus_h3_clk.common,
 	&gpu_clk.common,
 };
 
-- 
2.9.2

^ permalink raw reply related	[flat|nested] 34+ messages in thread

* [PATCH 06/13] clk: sunxi-ng: sun8i: Move fixed factors around
  2016-07-26 20:30 [PATCH 00/13] arm64: Allwinner A64 support based on sunxi-ng Maxime Ripard
                   ` (4 preceding siblings ...)
  2016-07-26 20:30 ` [PATCH 05/13] clk: sunxi-ng: sun8i: Rename H3 only clocks Maxime Ripard
@ 2016-07-26 20:30 ` Maxime Ripard
  2016-07-26 20:30 ` [PATCH 07/13] clk: sunxi-ng: sun8i: Prefix clock defines by SoC Name Maxime Ripard
                   ` (8 subsequent siblings)
  14 siblings, 0 replies; 34+ messages in thread
From: Maxime Ripard @ 2016-07-26 20:30 UTC (permalink / raw)
  To: Rob Herring, Chen-Yu Tsai, Mike Turquette, Stephen Boyd
  Cc: devicetree, Andre Przywara, linux-arm-kernel, linux-kernel,
	linux-clk, Maxime Ripard

Move the fixed factors clocks before the ccu_common list so that we can
separate the clocks definitions and the registration part.

Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
---
 drivers/clk/sunxi-ng/ccu-sun8i-h3.c | 25 +++++++++++++------------
 1 file changed, 13 insertions(+), 12 deletions(-)

diff --git a/drivers/clk/sunxi-ng/ccu-sun8i-h3.c b/drivers/clk/sunxi-ng/ccu-sun8i-h3.c
index f61d2e245ac4..ec8c67201e8e 100644
--- a/drivers/clk/sunxi-ng/ccu-sun8i-h3.c
+++ b/drivers/clk/sunxi-ng/ccu-sun8i-h3.c
@@ -484,6 +484,19 @@ static SUNXI_CCU_M_WITH_MUX_GATE(mbus_h3_clk, "mbus", mbus_h3_parents,
 static SUNXI_CCU_M_WITH_GATE(gpu_clk, "gpu", "pll-gpu",
 			     0x1a0, 0, 3, BIT(31), 0);
 
+/* Fixed Factor clocks */
+/* We hardcode the divider to 4 for now */
+static CLK_FIXED_FACTOR(pll_audio_clk, "pll-audio",
+			"pll-audio-base", 4, 1, CLK_SET_RATE_PARENT);
+static CLK_FIXED_FACTOR(pll_audio_2x_clk, "pll-audio-2x",
+			"pll-audio-base", 2, 1, CLK_SET_RATE_PARENT);
+static CLK_FIXED_FACTOR(pll_audio_4x_clk, "pll-audio-4x",
+			"pll-audio-base", 1, 1, CLK_SET_RATE_PARENT);
+static CLK_FIXED_FACTOR(pll_audio_8x_clk, "pll-audio-8x",
+			"pll-audio-base", 1, 2, CLK_SET_RATE_PARENT);
+static CLK_FIXED_FACTOR(pll_periph0_2x_clk, "pll-periph0-2x",
+			"pll-periph0", 1, 2, 0);
+
 static struct ccu_common *sun8i_h3_ccu_clks[] = {
 	&pll_cpux_clk.common,
 	&pll_audio_base_clk.common,
@@ -597,18 +610,6 @@ static struct ccu_common *sun8i_h3_ccu_clks[] = {
 	&gpu_clk.common,
 };
 
-/* We hardcode the divider to 4 for now */
-static CLK_FIXED_FACTOR(pll_audio_clk, "pll-audio",
-			"pll-audio-base", 4, 1, CLK_SET_RATE_PARENT);
-static CLK_FIXED_FACTOR(pll_audio_2x_clk, "pll-audio-2x",
-			"pll-audio-base", 2, 1, CLK_SET_RATE_PARENT);
-static CLK_FIXED_FACTOR(pll_audio_4x_clk, "pll-audio-4x",
-			"pll-audio-base", 1, 1, CLK_SET_RATE_PARENT);
-static CLK_FIXED_FACTOR(pll_audio_8x_clk, "pll-audio-8x",
-			"pll-audio-base", 1, 2, CLK_SET_RATE_PARENT);
-static CLK_FIXED_FACTOR(pll_periph0_2x_clk, "pll-periph0-2x",
-			"pll-periph0", 1, 2, 0);
-
 static struct clk_hw_onecell_data sun8i_h3_hw_clks = {
 	.hws	= {
 		[CLK_PLL_CPUX]		= &pll_cpux_clk.common.hw,
-- 
2.9.2

^ permalink raw reply related	[flat|nested] 34+ messages in thread

* [PATCH 07/13] clk: sunxi-ng: sun8i: Prefix clock defines by SoC Name
  2016-07-26 20:30 [PATCH 00/13] arm64: Allwinner A64 support based on sunxi-ng Maxime Ripard
                   ` (5 preceding siblings ...)
  2016-07-26 20:30 ` [PATCH 06/13] clk: sunxi-ng: sun8i: Move fixed factors around Maxime Ripard
@ 2016-07-26 20:30 ` Maxime Ripard
  2016-07-26 20:30 ` [PATCH 08/13] clk: sunxi-ng: Add A64 clocks Maxime Ripard
                   ` (7 subsequent siblings)
  14 siblings, 0 replies; 34+ messages in thread
From: Maxime Ripard @ 2016-07-26 20:30 UTC (permalink / raw)
  To: Rob Herring, Chen-Yu Tsai, Mike Turquette, Stephen Boyd
  Cc: devicetree, Andre Przywara, linux-arm-kernel, linux-kernel,
	linux-clk, Maxime Ripard

Since the A64 and H3 have a slightly different clock set, they will have
different opaque clock numbers set as well. Make that obvious by using the
SoC name in the defines.

Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
---
 arch/arm/boot/dts/sun8i-h3.dtsi          |  62 ++++-----
 drivers/clk/sunxi-ng/ccu-sun8i-h3.c      | 232 +++++++++++++++----------------
 drivers/clk/sunxi-ng/ccu-sun8i-h3.h      |  44 +++---
 include/dt-bindings/clock/sun8i-h3-ccu.h | 188 ++++++++++++-------------
 4 files changed, 263 insertions(+), 263 deletions(-)

diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi b/arch/arm/boot/dts/sun8i-h3.dtsi
index 9871bad34742..0e7005865e20 100644
--- a/arch/arm/boot/dts/sun8i-h3.dtsi
+++ b/arch/arm/boot/dts/sun8i-h3.dtsi
@@ -144,7 +144,7 @@
 			compatible = "allwinner,sun8i-h3-dma";
 			reg = <0x01c02000 0x1000>;
 			interrupts = <GIC_SPI 50 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&ccu CLK_BUS_DMA>;
+			clocks = <&ccu CLK_H3_BUS_DMA>;
 			resets = <&ccu RST_BUS_DMA>;
 			#dma-cells = <1>;
 		};
@@ -152,10 +152,10 @@
 		mmc0: mmc@01c0f000 {
 			compatible = "allwinner,sun5i-a13-mmc";
 			reg = <0x01c0f000 0x1000>;
-			clocks = <&ccu CLK_BUS_MMC0>,
-				 <&ccu CLK_MMC0>,
-				 <&ccu CLK_MMC0_OUTPUT>,
-				 <&ccu CLK_MMC0_SAMPLE>;
+			clocks = <&ccu CLK_H3_BUS_MMC0>,
+				 <&ccu CLK_H3_MMC0>,
+				 <&ccu CLK_H3_MMC0_OUTPUT>,
+				 <&ccu CLK_H3_MMC0_SAMPLE>;
 			clock-names = "ahb",
 				      "mmc",
 				      "output",
@@ -171,10 +171,10 @@
 		mmc1: mmc@01c10000 {
 			compatible = "allwinner,sun5i-a13-mmc";
 			reg = <0x01c10000 0x1000>;
-			clocks = <&ccu CLK_BUS_MMC1>,
-				 <&ccu CLK_MMC1>,
-				 <&ccu CLK_MMC1_OUTPUT>,
-				 <&ccu CLK_MMC1_SAMPLE>;
+			clocks = <&ccu CLK_H3_BUS_MMC1>,
+				 <&ccu CLK_H3_MMC1>,
+				 <&ccu CLK_H3_MMC1_OUTPUT>,
+				 <&ccu CLK_H3_MMC1_SAMPLE>;
 			clock-names = "ahb",
 				      "mmc",
 				      "output",
@@ -190,10 +190,10 @@
 		mmc2: mmc@01c11000 {
 			compatible = "allwinner,sun5i-a13-mmc";
 			reg = <0x01c11000 0x1000>;
-			clocks = <&ccu CLK_BUS_MMC2>,
-				 <&ccu CLK_MMC2>,
-				 <&ccu CLK_MMC2_OUTPUT>,
-				 <&ccu CLK_MMC2_SAMPLE>;
+			clocks = <&ccu CLK_H3_BUS_MMC2>,
+				 <&ccu CLK_H3_MMC2>,
+				 <&ccu CLK_H3_MMC2_OUTPUT>,
+				 <&ccu CLK_H3_MMC2_SAMPLE>;
 			clock-names = "ahb",
 				      "mmc",
 				      "output",
@@ -218,10 +218,10 @@
 				    "pmu1",
 				    "pmu2",
 				    "pmu3";
-			clocks = <&ccu CLK_USB_PHY0>,
-				 <&ccu CLK_USB_PHY1>,
-				 <&ccu CLK_USB_PHY2>,
-				 <&ccu CLK_USB_PHY3>;
+			clocks = <&ccu CLK_H3_USB_PHY0>,
+				 <&ccu CLK_H3_USB_PHY1>,
+				 <&ccu CLK_H3_USB_PHY2>,
+				 <&ccu CLK_H3_USB_PHY3>;
 			clock-names = "usb0_phy",
 				      "usb1_phy",
 				      "usb2_phy",
@@ -242,7 +242,7 @@
 			compatible = "allwinner,sun8i-h3-ehci", "generic-ehci";
 			reg = <0x01c1b000 0x100>;
 			interrupts = <GIC_SPI 74 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&ccu CLK_BUS_EHCI1>, <&ccu CLK_BUS_OHCI1>;
+			clocks = <&ccu CLK_H3_BUS_EHCI1>, <&ccu CLK_H3_BUS_OHCI1>;
 			resets = <&ccu RST_BUS_EHCI1>, <&ccu RST_BUS_OHCI1>;
 			phys = <&usbphy 1>;
 			phy-names = "usb";
@@ -253,8 +253,8 @@
 			compatible = "allwinner,sun8i-h3-ohci", "generic-ohci";
 			reg = <0x01c1b400 0x100>;
 			interrupts = <GIC_SPI 75 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&ccu CLK_BUS_EHCI1>, <&ccu CLK_BUS_OHCI1>,
-				 <&ccu CLK_USB_OHCI1>;
+			clocks = <&ccu CLK_H3_BUS_EHCI1>, <&ccu CLK_H3_BUS_OHCI1>,
+				 <&ccu CLK_H3_USB_OHCI1>;
 			resets = <&ccu RST_BUS_EHCI1>, <&ccu RST_BUS_OHCI1>;
 			phys = <&usbphy 1>;
 			phy-names = "usb";
@@ -265,7 +265,7 @@
 			compatible = "allwinner,sun8i-h3-ehci", "generic-ehci";
 			reg = <0x01c1c000 0x100>;
 			interrupts = <GIC_SPI 76 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&ccu CLK_BUS_EHCI2>, <&ccu CLK_BUS_OHCI2>;
+			clocks = <&ccu CLK_H3_BUS_EHCI2>, <&ccu CLK_H3_BUS_OHCI2>;
 			resets = <&ccu RST_BUS_EHCI2>, <&ccu RST_BUS_OHCI2>;
 			phys = <&usbphy 2>;
 			phy-names = "usb";
@@ -276,8 +276,8 @@
 			compatible = "allwinner,sun8i-h3-ohci", "generic-ohci";
 			reg = <0x01c1c400 0x100>;
 			interrupts = <GIC_SPI 77 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&ccu CLK_BUS_EHCI2>, <&ccu CLK_BUS_OHCI2>,
-				 <&ccu CLK_USB_OHCI2>;
+			clocks = <&ccu CLK_H3_BUS_EHCI2>, <&ccu CLK_H3_BUS_OHCI2>,
+				 <&ccu CLK_H3_USB_OHCI2>;
 			resets = <&ccu RST_BUS_EHCI2>, <&ccu RST_BUS_OHCI2>;
 			phys = <&usbphy 2>;
 			phy-names = "usb";
@@ -288,7 +288,7 @@
 			compatible = "allwinner,sun8i-h3-ehci", "generic-ehci";
 			reg = <0x01c1d000 0x100>;
 			interrupts = <GIC_SPI 78 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&ccu CLK_BUS_EHCI3>, <&ccu CLK_BUS_OHCI3>;
+			clocks = <&ccu CLK_H3_BUS_EHCI3>, <&ccu CLK_H3_BUS_OHCI3>;
 			resets = <&ccu RST_BUS_EHCI3>, <&ccu RST_BUS_OHCI3>;
 			phys = <&usbphy 3>;
 			phy-names = "usb";
@@ -299,8 +299,8 @@
 			compatible = "allwinner,sun8i-h3-ohci", "generic-ohci";
 			reg = <0x01c1d400 0x100>;
 			interrupts = <GIC_SPI 79 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&ccu CLK_BUS_EHCI3>, <&ccu CLK_BUS_OHCI3>,
-				 <&ccu CLK_USB_OHCI3>;
+			clocks = <&ccu CLK_H3_BUS_EHCI3>, <&ccu CLK_H3_BUS_OHCI3>,
+				 <&ccu CLK_H3_USB_OHCI3>;
 			resets = <&ccu RST_BUS_EHCI3>, <&ccu RST_BUS_OHCI3>;
 			phys = <&usbphy 3>;
 			phy-names = "usb";
@@ -321,7 +321,7 @@
 			reg = <0x01c20800 0x400>;
 			interrupts = <GIC_SPI 11 IRQ_TYPE_LEVEL_HIGH>,
 				     <GIC_SPI 17 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&ccu CLK_BUS_PIO>;
+			clocks = <&ccu CLK_H3_BUS_PIO>;
 			gpio-controller;
 			#gpio-cells = <3>;
 			interrupt-controller;
@@ -388,7 +388,7 @@
 			interrupts = <GIC_SPI 0 IRQ_TYPE_LEVEL_HIGH>;
 			reg-shift = <2>;
 			reg-io-width = <4>;
-			clocks = <&ccu CLK_BUS_UART0>;
+			clocks = <&ccu CLK_H3_BUS_UART0>;
 			resets = <&ccu RST_BUS_UART0>;
 			dmas = <&dma 6>, <&dma 6>;
 			dma-names = "rx", "tx";
@@ -401,7 +401,7 @@
 			interrupts = <GIC_SPI 1 IRQ_TYPE_LEVEL_HIGH>;
 			reg-shift = <2>;
 			reg-io-width = <4>;
-			clocks = <&ccu CLK_BUS_UART1>;
+			clocks = <&ccu CLK_H3_BUS_UART1>;
 			resets = <&ccu RST_BUS_UART1>;
 			dmas = <&dma 7>, <&dma 7>;
 			dma-names = "rx", "tx";
@@ -414,7 +414,7 @@
 			interrupts = <GIC_SPI 2 IRQ_TYPE_LEVEL_HIGH>;
 			reg-shift = <2>;
 			reg-io-width = <4>;
-			clocks = <&ccu CLK_BUS_UART2>;
+			clocks = <&ccu CLK_H3_BUS_UART2>;
 			resets = <&ccu RST_BUS_UART2>;
 			dmas = <&dma 8>, <&dma 8>;
 			dma-names = "rx", "tx";
@@ -427,7 +427,7 @@
 			interrupts = <GIC_SPI 3 IRQ_TYPE_LEVEL_HIGH>;
 			reg-shift = <2>;
 			reg-io-width = <4>;
-			clocks = <&ccu CLK_BUS_UART3>;
+			clocks = <&ccu CLK_H3_BUS_UART3>;
 			resets = <&ccu RST_BUS_UART3>;
 			dmas = <&dma 9>, <&dma 9>;
 			dma-names = "rx", "tx";
diff --git a/drivers/clk/sunxi-ng/ccu-sun8i-h3.c b/drivers/clk/sunxi-ng/ccu-sun8i-h3.c
index ec8c67201e8e..2e91f43937c8 100644
--- a/drivers/clk/sunxi-ng/ccu-sun8i-h3.c
+++ b/drivers/clk/sunxi-ng/ccu-sun8i-h3.c
@@ -612,123 +612,123 @@ static struct ccu_common *sun8i_h3_ccu_clks[] = {
 
 static struct clk_hw_onecell_data sun8i_h3_hw_clks = {
 	.hws	= {
-		[CLK_PLL_CPUX]		= &pll_cpux_clk.common.hw,
-		[CLK_PLL_AUDIO_BASE]	= &pll_audio_base_clk.common.hw,
-		[CLK_PLL_AUDIO]		= &pll_audio_clk.hw,
-		[CLK_PLL_AUDIO_2X]	= &pll_audio_2x_clk.hw,
-		[CLK_PLL_AUDIO_4X]	= &pll_audio_4x_clk.hw,
-		[CLK_PLL_AUDIO_8X]	= &pll_audio_8x_clk.hw,
-		[CLK_PLL_VIDEO]		= &pll_video_clk.common.hw,
-		[CLK_PLL_VE]		= &pll_ve_clk.common.hw,
-		[CLK_PLL_DDR]		= &pll_ddr_clk.common.hw,
-		[CLK_PLL_PERIPH0]	= &pll_periph0_clk.common.hw,
-		[CLK_PLL_PERIPH0_2X]	= &pll_periph0_2x_clk.hw,
-		[CLK_PLL_GPU]		= &pll_gpu_clk.common.hw,
-		[CLK_PLL_PERIPH1]	= &pll_periph1_clk.common.hw,
-		[CLK_PLL_DE]		= &pll_de_clk.common.hw,
-		[CLK_CPUX]		= &cpux_clk.common.hw,
-		[CLK_AXI]		= &axi_clk.common.hw,
-		[CLK_AHB1]		= &ahb1_clk.common.hw,
-		[CLK_APB1]		= &apb1_clk.common.hw,
-		[CLK_APB2]		= &apb2_clk.common.hw,
-		[CLK_AHB2]		= &ahb2_clk.common.hw,
-		[CLK_BUS_CE]		= &bus_ce_clk.common.hw,
-		[CLK_BUS_DMA]		= &bus_dma_clk.common.hw,
-		[CLK_BUS_MMC0]		= &bus_mmc0_clk.common.hw,
-		[CLK_BUS_MMC1]		= &bus_mmc1_clk.common.hw,
-		[CLK_BUS_MMC2]		= &bus_mmc2_clk.common.hw,
-		[CLK_BUS_NAND]		= &bus_nand_clk.common.hw,
-		[CLK_BUS_DRAM]		= &bus_dram_clk.common.hw,
-		[CLK_BUS_EMAC]		= &bus_emac_clk.common.hw,
-		[CLK_BUS_TS]		= &bus_ts_clk.common.hw,
-		[CLK_BUS_HSTIMER]	= &bus_hstimer_clk.common.hw,
-		[CLK_BUS_SPI0]		= &bus_spi0_clk.common.hw,
-		[CLK_BUS_SPI1]		= &bus_spi1_clk.common.hw,
-		[CLK_BUS_OTG]		= &bus_otg_clk.common.hw,
-		[CLK_BUS_EHCI0]		= &bus_ehci0_clk.common.hw,
-		[CLK_BUS_EHCI1]		= &bus_ehci1_clk.common.hw,
-		[CLK_BUS_EHCI2]		= &bus_ehci2_clk.common.hw,
-		[CLK_BUS_EHCI3]		= &bus_ehci3_clk.common.hw,
-		[CLK_BUS_OHCI0]		= &bus_ohci0_clk.common.hw,
-		[CLK_BUS_OHCI1]		= &bus_ohci1_clk.common.hw,
-		[CLK_BUS_OHCI2]		= &bus_ohci2_clk.common.hw,
-		[CLK_BUS_OHCI3]		= &bus_ohci3_clk.common.hw,
-		[CLK_BUS_VE]		= &bus_ve_clk.common.hw,
-		[CLK_BUS_TCON0]		= &bus_tcon0_clk.common.hw,
-		[CLK_BUS_TCON1]		= &bus_tcon1_clk.common.hw,
-		[CLK_BUS_DEINTERLACE]	= &bus_deinterlace_clk.common.hw,
-		[CLK_BUS_CSI]		= &bus_csi_clk.common.hw,
-		[CLK_BUS_TVE]		= &bus_tve_clk.common.hw,
-		[CLK_BUS_HDMI]		= &bus_hdmi_clk.common.hw,
-		[CLK_BUS_DE]		= &bus_de_clk.common.hw,
-		[CLK_BUS_GPU]		= &bus_gpu_clk.common.hw,
-		[CLK_BUS_MSGBOX]	= &bus_msgbox_clk.common.hw,
-		[CLK_BUS_SPINLOCK]	= &bus_spinlock_clk.common.hw,
-		[CLK_BUS_CODEC]		= &bus_codec_clk.common.hw,
-		[CLK_BUS_SPDIF]		= &bus_spdif_clk.common.hw,
-		[CLK_BUS_PIO]		= &bus_pio_clk.common.hw,
-		[CLK_BUS_THS]		= &bus_ths_clk.common.hw,
-		[CLK_BUS_I2S0]		= &bus_i2s0_clk.common.hw,
-		[CLK_BUS_I2S1]		= &bus_i2s1_clk.common.hw,
-		[CLK_BUS_I2S2]		= &bus_i2s2_clk.common.hw,
-		[CLK_BUS_I2C0]		= &bus_i2c0_clk.common.hw,
-		[CLK_BUS_I2C1]		= &bus_i2c1_clk.common.hw,
-		[CLK_BUS_I2C2]		= &bus_i2c2_clk.common.hw,
-		[CLK_BUS_UART0]		= &bus_uart0_clk.common.hw,
-		[CLK_BUS_UART1]		= &bus_uart1_clk.common.hw,
-		[CLK_BUS_UART2]		= &bus_uart2_clk.common.hw,
-		[CLK_BUS_UART3]		= &bus_uart3_clk.common.hw,
-		[CLK_BUS_SCR]		= &bus_scr_clk.common.hw,
-		[CLK_BUS_EPHY]		= &bus_ephy_clk.common.hw,
-		[CLK_BUS_DBG]		= &bus_dbg_clk.common.hw,
-		[CLK_THS]		= &ths_clk.common.hw,
-		[CLK_NAND]		= &nand_clk.common.hw,
-		[CLK_MMC0]		= &mmc0_clk.common.hw,
-		[CLK_MMC0_SAMPLE]	= &mmc0_sample_clk.common.hw,
-		[CLK_MMC0_OUTPUT]	= &mmc0_output_clk.common.hw,
-		[CLK_MMC1]		= &mmc1_clk.common.hw,
-		[CLK_MMC1_SAMPLE]	= &mmc1_sample_clk.common.hw,
-		[CLK_MMC1_OUTPUT]	= &mmc1_output_clk.common.hw,
-		[CLK_MMC2]		= &mmc2_clk.common.hw,
-		[CLK_MMC2_SAMPLE]	= &mmc2_sample_clk.common.hw,
-		[CLK_MMC2_OUTPUT]	= &mmc2_output_clk.common.hw,
-		[CLK_TS]		= &ts_clk.common.hw,
-		[CLK_CE]		= &ce_clk.common.hw,
-		[CLK_SPI0]		= &spi0_clk.common.hw,
-		[CLK_SPI1]		= &spi1_clk.common.hw,
-		[CLK_I2S0]		= &i2s0_clk.common.hw,
-		[CLK_I2S1]		= &i2s1_clk.common.hw,
-		[CLK_I2S2]		= &i2s2_clk.common.hw,
-		[CLK_SPDIF]		= &spdif_clk.common.hw,
-		[CLK_USB_PHY0]		= &usb_phy0_clk.common.hw,
-		[CLK_USB_PHY1]		= &usb_phy1_clk.common.hw,
-		[CLK_USB_PHY2]		= &usb_phy2_clk.common.hw,
-		[CLK_USB_PHY3]		= &usb_phy3_clk.common.hw,
-		[CLK_USB_OHCI0]		= &usb_ohci0_clk.common.hw,
-		[CLK_USB_OHCI1]		= &usb_ohci1_clk.common.hw,
-		[CLK_USB_OHCI2]		= &usb_ohci2_clk.common.hw,
-		[CLK_USB_OHCI3]		= &usb_ohci3_clk.common.hw,
-		[CLK_DRAM]		= &dram_clk.common.hw,
-		[CLK_DRAM_VE]		= &dram_ve_clk.common.hw,
-		[CLK_DRAM_CSI]		= &dram_csi_clk.common.hw,
-		[CLK_DRAM_DEINTERLACE]	= &dram_deinterlace_clk.common.hw,
-		[CLK_DRAM_TS]		= &dram_ts_clk.common.hw,
-		[CLK_DE]		= &de_clk.common.hw,
-		[CLK_TCON0]		= &tcon_clk.common.hw,
-		[CLK_TVE]		= &tve_clk.common.hw,
-		[CLK_DEINTERLACE]	= &deinterlace_clk.common.hw,
-		[CLK_CSI_MISC]		= &csi_misc_clk.common.hw,
-		[CLK_CSI_SCLK]		= &csi_sclk_clk.common.hw,
-		[CLK_CSI_MCLK]		= &csi_mclk_clk.common.hw,
-		[CLK_VE]		= &ve_clk.common.hw,
-		[CLK_AC_DIG]		= &ac_dig_clk.common.hw,
-		[CLK_AVS]		= &avs_clk.common.hw,
-		[CLK_HDMI]		= &hdmi_clk.common.hw,
-		[CLK_HDMI_DDC]		= &hdmi_ddc_clk.common.hw,
-		[CLK_MBUS]		= &mbus_clk.common.hw,
-		[CLK_GPU]		= &gpu_clk.common.hw,
+		[CLK_H3_PLL_CPUX]	= &pll_cpux_clk.common.hw,
+		[CLK_H3_PLL_AUDIO_BASE]	= &pll_audio_base_clk.common.hw,
+		[CLK_H3_PLL_AUDIO]	= &pll_audio_clk.hw,
+		[CLK_H3_PLL_AUDIO_2X]	= &pll_audio_2x_clk.hw,
+		[CLK_H3_PLL_AUDIO_4X]	= &pll_audio_4x_clk.hw,
+		[CLK_H3_PLL_AUDIO_8X]	= &pll_audio_8x_clk.hw,
+		[CLK_H3_PLL_VIDEO]	= &pll_video0_clk.common.hw,
+		[CLK_H3_PLL_VE]		= &pll_ve_clk.common.hw,
+		[CLK_H3_PLL_DDR]	= &pll_ddr0_clk.common.hw,
+		[CLK_H3_PLL_PERIPH0]	= &pll_periph0_clk.common.hw,
+		[CLK_H3_PLL_PERIPH0_2X]	= &pll_periph0_2x_clk.hw,
+		[CLK_H3_PLL_GPU]	= &pll_gpu_clk.common.hw,
+		[CLK_H3_PLL_PERIPH1]	= &pll_periph1_h3_clk.common.hw,
+		[CLK_H3_PLL_DE]		= &pll_de_clk.common.hw,
+		[CLK_H3_CPUX]		= &cpux_clk.common.hw,
+		[CLK_H3_AXI]		= &axi_clk.common.hw,
+		[CLK_H3_AHB1]		= &ahb1_clk.common.hw,
+		[CLK_H3_APB1]		= &apb1_clk.common.hw,
+		[CLK_H3_APB2]		= &apb2_h3_clk.common.hw,
+		[CLK_H3_AHB2]		= &ahb2_clk.common.hw,
+		[CLK_H3_BUS_CE]		= &bus_ce_clk.common.hw,
+		[CLK_H3_BUS_DMA]	= &bus_dma_clk.common.hw,
+		[CLK_H3_BUS_MMC0]	= &bus_mmc0_clk.common.hw,
+		[CLK_H3_BUS_MMC1]	= &bus_mmc1_clk.common.hw,
+		[CLK_H3_BUS_MMC2]	= &bus_mmc2_clk.common.hw,
+		[CLK_H3_BUS_NAND]	= &bus_nand_clk.common.hw,
+		[CLK_H3_BUS_DRAM]	= &bus_dram_clk.common.hw,
+		[CLK_H3_BUS_EMAC]	= &bus_emac_clk.common.hw,
+		[CLK_H3_BUS_TS]		= &bus_ts_clk.common.hw,
+		[CLK_H3_BUS_HSTIMER]	= &bus_hstimer_clk.common.hw,
+		[CLK_H3_BUS_SPI0]	= &bus_spi0_clk.common.hw,
+		[CLK_H3_BUS_SPI1]	= &bus_spi1_clk.common.hw,
+		[CLK_H3_BUS_OTG]	= &bus_otg_clk.common.hw,
+		[CLK_H3_BUS_EHCI0]	= &bus_ehci0_clk.common.hw,
+		[CLK_H3_BUS_EHCI1]	= &bus_ehci1_clk.common.hw,
+		[CLK_H3_BUS_EHCI2]	= &bus_ehci2_h3_clk.common.hw,
+		[CLK_H3_BUS_EHCI3]	= &bus_ehci3_h3_clk.common.hw,
+		[CLK_H3_BUS_OHCI0]	= &bus_ohci0_clk.common.hw,
+		[CLK_H3_BUS_OHCI1]	= &bus_ohci1_clk.common.hw,
+		[CLK_H3_BUS_OHCI2]	= &bus_ohci2_h3_clk.common.hw,
+		[CLK_H3_BUS_OHCI3]	= &bus_ohci3_h3_clk.common.hw,
+		[CLK_H3_BUS_VE]		= &bus_ve_clk.common.hw,
+		[CLK_H3_BUS_TCON0]	= &bus_tcon0_clk.common.hw,
+		[CLK_H3_BUS_TCON1]	= &bus_tcon1_clk.common.hw,
+		[CLK_H3_BUS_DEINTERLACE]	= &bus_deinterlace_clk.common.hw,
+		[CLK_H3_BUS_CSI]	= &bus_csi_clk.common.hw,
+		[CLK_H3_BUS_TVE]	= &bus_tve_h3_clk.common.hw,
+		[CLK_H3_BUS_HDMI]	= &bus_hdmi_clk.common.hw,
+		[CLK_H3_BUS_DE]		= &bus_de_clk.common.hw,
+		[CLK_H3_BUS_GPU]	= &bus_gpu_clk.common.hw,
+		[CLK_H3_BUS_MSGBOX]	= &bus_msgbox_clk.common.hw,
+		[CLK_H3_BUS_SPINLOCK]	= &bus_spinlock_clk.common.hw,
+		[CLK_H3_BUS_CODEC]	= &bus_codec_clk.common.hw,
+		[CLK_H3_BUS_SPDIF]	= &bus_spdif_clk.common.hw,
+		[CLK_H3_BUS_PIO]	= &bus_pio_clk.common.hw,
+		[CLK_H3_BUS_THS]	= &bus_ths_clk.common.hw,
+		[CLK_H3_BUS_I2S0]	= &bus_i2s0_clk.common.hw,
+		[CLK_H3_BUS_I2S1]	= &bus_i2s1_clk.common.hw,
+		[CLK_H3_BUS_I2S2]	= &bus_i2s2_clk.common.hw,
+		[CLK_H3_BUS_I2C0]	= &bus_i2c0_clk.common.hw,
+		[CLK_H3_BUS_I2C1]	= &bus_i2c1_clk.common.hw,
+		[CLK_H3_BUS_I2C2]	= &bus_i2c2_clk.common.hw,
+		[CLK_H3_BUS_UART0]	= &bus_uart0_clk.common.hw,
+		[CLK_H3_BUS_UART1]	= &bus_uart1_clk.common.hw,
+		[CLK_H3_BUS_UART2]	= &bus_uart2_clk.common.hw,
+		[CLK_H3_BUS_UART3]	= &bus_uart3_clk.common.hw,
+		[CLK_H3_BUS_SCR]	= &bus_scr_h3_clk.common.hw,
+		[CLK_H3_BUS_EPHY]	= &bus_ephy_h3_clk.common.hw,
+		[CLK_H3_BUS_DBG]	= &bus_dbg_clk.common.hw,
+		[CLK_H3_THS]		= &ths_clk.common.hw,
+		[CLK_H3_NAND]		= &nand_clk.common.hw,
+		[CLK_H3_MMC0]		= &mmc0_h3_clk.common.hw,
+		[CLK_H3_MMC0_SAMPLE]	= &mmc0_sample_h3_clk.common.hw,
+		[CLK_H3_MMC0_OUTPUT]	= &mmc0_output_h3_clk.common.hw,
+		[CLK_H3_MMC1]		= &mmc1_h3_clk.common.hw,
+		[CLK_H3_MMC1_SAMPLE]	= &mmc1_sample_h3_clk.common.hw,
+		[CLK_H3_MMC1_OUTPUT]	= &mmc1_output_h3_clk.common.hw,
+		[CLK_H3_MMC2]		= &mmc2_h3_clk.common.hw,
+		[CLK_H3_MMC2_SAMPLE]	= &mmc2_sample_h3_clk.common.hw,
+		[CLK_H3_MMC2_OUTPUT]	= &mmc2_output_h3_clk.common.hw,
+		[CLK_H3_TS]		= &ts_clk.common.hw,
+		[CLK_H3_CE]		= &ce_h3_clk.common.hw,
+		[CLK_H3_SPI0]		= &spi0_clk.common.hw,
+		[CLK_H3_SPI1]		= &spi1_clk.common.hw,
+		[CLK_H3_I2S0]		= &i2s0_clk.common.hw,
+		[CLK_H3_I2S1]		= &i2s1_clk.common.hw,
+		[CLK_H3_I2S2]		= &i2s2_clk.common.hw,
+		[CLK_H3_SPDIF]		= &spdif_clk.common.hw,
+		[CLK_H3_USB_PHY0]	= &usb_phy0_clk.common.hw,
+		[CLK_H3_USB_PHY1]	= &usb_phy1_clk.common.hw,
+		[CLK_H3_USB_PHY2]	= &usb_phy2_h3_clk.common.hw,
+		[CLK_H3_USB_PHY3]	= &usb_phy3_h3_clk.common.hw,
+		[CLK_H3_USB_OHCI0]	= &usb_ohci0_h3_clk.common.hw,
+		[CLK_H3_USB_OHCI1]	= &usb_ohci1_h3_clk.common.hw,
+		[CLK_H3_USB_OHCI2]	= &usb_ohci2_h3_clk.common.hw,
+		[CLK_H3_USB_OHCI3]	= &usb_ohci3_h3_clk.common.hw,
+		[CLK_H3_DRAM]		= &dram_h3_clk.common.hw,
+		[CLK_H3_DRAM_VE]	= &dram_ve_clk.common.hw,
+		[CLK_H3_DRAM_CSI]	= &dram_csi_clk.common.hw,
+		[CLK_H3_DRAM_DEINTERLACE]	= &dram_deinterlace_clk.common.hw,
+		[CLK_H3_DRAM_TS]	= &dram_ts_clk.common.hw,
+		[CLK_H3_DE]		= &de_clk.common.hw,
+		[CLK_H3_TCON0]		= &tcon0_h3_clk.common.hw,
+		[CLK_H3_TVE]		= &tve_h3_clk.common.hw,
+		[CLK_H3_DEINTERLACE]	= &deinterlace_clk.common.hw,
+		[CLK_H3_CSI_MISC]	= &csi_misc_clk.common.hw,
+		[CLK_H3_CSI_SCLK]	= &csi_sclk_clk.common.hw,
+		[CLK_H3_CSI_MCLK]	= &csi_mclk_h3_clk.common.hw,
+		[CLK_H3_VE]		= &ve_clk.common.hw,
+		[CLK_H3_AC_DIG]		= &ac_dig_clk.common.hw,
+		[CLK_H3_AVS]		= &avs_clk.common.hw,
+		[CLK_H3_HDMI]		= &hdmi_h3_clk.common.hw,
+		[CLK_H3_HDMI_DDC]	= &hdmi_ddc_clk.common.hw,
+		[CLK_H3_MBUS]		= &mbus_h3_clk.common.hw,
+		[CLK_H3_GPU]		= &gpu_clk.common.hw,
 	},
-	.num	= CLK_NUMBER,
+	.num	= CLK_H3_NUMBER,
 };
 
 static struct ccu_reset_map sun8i_h3_ccu_resets[] = {
diff --git a/drivers/clk/sunxi-ng/ccu-sun8i-h3.h b/drivers/clk/sunxi-ng/ccu-sun8i-h3.h
index 78be712c7487..80a7f34d0fbf 100644
--- a/drivers/clk/sunxi-ng/ccu-sun8i-h3.h
+++ b/drivers/clk/sunxi-ng/ccu-sun8i-h3.h
@@ -20,43 +20,43 @@
 #include <dt-bindings/clock/sun8i-h3-ccu.h>
 #include <dt-bindings/reset/sun8i-h3-ccu.h>
 
-#define CLK_PLL_CPUX		0
-#define CLK_PLL_AUDIO_BASE	1
-#define CLK_PLL_AUDIO		2
-#define CLK_PLL_AUDIO_2X	3
-#define CLK_PLL_AUDIO_4X	4
-#define CLK_PLL_AUDIO_8X	5
-#define CLK_PLL_VIDEO		6
-#define CLK_PLL_VE		7
-#define CLK_PLL_DDR		8
-#define CLK_PLL_PERIPH0		9
-#define CLK_PLL_PERIPH0_2X	10
-#define CLK_PLL_GPU		11
-#define CLK_PLL_PERIPH1		12
-#define CLK_PLL_DE		13
+#define CLK_H3_PLL_CPUX		0
+#define CLK_H3_PLL_AUDIO_BASE	1
+#define CLK_H3_PLL_AUDIO	2
+#define CLK_H3_PLL_AUDIO_2X	3
+#define CLK_H3_PLL_AUDIO_4X	4
+#define CLK_H3_PLL_AUDIO_8X	5
+#define CLK_H3_PLL_VIDEO	6
+#define CLK_H3_PLL_VE		7
+#define CLK_H3_PLL_DDR		8
+#define CLK_H3_PLL_PERIPH0	9
+#define CLK_H3_PLL_PERIPH0_2X	10
+#define CLK_H3_PLL_GPU		11
+#define CLK_H3_PLL_PERIPH1	12
+#define CLK_H3_PLL_DE		13
 
 /* The CPUX clock is exported */
 
-#define CLK_AXI			15
-#define CLK_AHB1		16
-#define CLK_APB1		17
-#define CLK_APB2		18
-#define CLK_AHB2		19
+#define CLK_H3_AXI		15
+#define CLK_H3_AHB1		16
+#define CLK_H3_APB1		17
+#define CLK_H3_APB2		18
+#define CLK_H3_AHB2		19
 
 /* All the bus gates are exported */
 
 /* The first bunch of module clocks are exported */
 
-#define CLK_DRAM		96
+#define CLK_H3_DRAM		96
 
 /* All the DRAM gates are exported */
 
 /* Some more module clocks are exported */
 
-#define CLK_MBUS		113
+#define CLK_H3_MBUS		113
 
 /* And the GPU module clock is exported */
 
-#define CLK_NUMBER		(CLK_GPU + 1)
+#define CLK_H3_NUMBER		(CLK_H3_GPU + 1)
 
 #endif /* _CCU_SUN8I_H3_H_ */
diff --git a/include/dt-bindings/clock/sun8i-h3-ccu.h b/include/dt-bindings/clock/sun8i-h3-ccu.h
index efb7ba2bd515..47a0681b16c7 100644
--- a/include/dt-bindings/clock/sun8i-h3-ccu.h
+++ b/include/dt-bindings/clock/sun8i-h3-ccu.h
@@ -43,103 +43,103 @@
 #ifndef _DT_BINDINGS_CLK_SUN8I_H3_H_
 #define _DT_BINDINGS_CLK_SUN8I_H3_H_
 
-#define CLK_CPUX		14
+#define CLK_H3_CPUX		14
 
-#define CLK_BUS_CE		20
-#define CLK_BUS_DMA		21
-#define CLK_BUS_MMC0		22
-#define CLK_BUS_MMC1		23
-#define CLK_BUS_MMC2		24
-#define CLK_BUS_NAND		25
-#define CLK_BUS_DRAM		26
-#define CLK_BUS_EMAC		27
-#define CLK_BUS_TS		28
-#define CLK_BUS_HSTIMER		29
-#define CLK_BUS_SPI0		30
-#define CLK_BUS_SPI1		31
-#define CLK_BUS_OTG		32
-#define CLK_BUS_EHCI0		33
-#define CLK_BUS_EHCI1		34
-#define CLK_BUS_EHCI2		35
-#define CLK_BUS_EHCI3		36
-#define CLK_BUS_OHCI0		37
-#define CLK_BUS_OHCI1		38
-#define CLK_BUS_OHCI2		39
-#define CLK_BUS_OHCI3		40
-#define CLK_BUS_VE		41
-#define CLK_BUS_TCON0		42
-#define CLK_BUS_TCON1		43
-#define CLK_BUS_DEINTERLACE	44
-#define CLK_BUS_CSI		45
-#define CLK_BUS_TVE		46
-#define CLK_BUS_HDMI		47
-#define CLK_BUS_DE		48
-#define CLK_BUS_GPU		49
-#define CLK_BUS_MSGBOX		50
-#define CLK_BUS_SPINLOCK	51
-#define CLK_BUS_CODEC		52
-#define CLK_BUS_SPDIF		53
-#define CLK_BUS_PIO		54
-#define CLK_BUS_THS		55
-#define CLK_BUS_I2S0		56
-#define CLK_BUS_I2S1		57
-#define CLK_BUS_I2S2		58
-#define CLK_BUS_I2C0		59
-#define CLK_BUS_I2C1		60
-#define CLK_BUS_I2C2		61
-#define CLK_BUS_UART0		62
-#define CLK_BUS_UART1		63
-#define CLK_BUS_UART2		64
-#define CLK_BUS_UART3		65
-#define CLK_BUS_SCR		66
-#define CLK_BUS_EPHY		67
-#define CLK_BUS_DBG		68
+#define CLK_H3_BUS_CE		20
+#define CLK_H3_BUS_DMA		21
+#define CLK_H3_BUS_MMC0		22
+#define CLK_H3_BUS_MMC1		23
+#define CLK_H3_BUS_MMC2		24
+#define CLK_H3_BUS_NAND		25
+#define CLK_H3_BUS_DRAM		26
+#define CLK_H3_BUS_EMAC		27
+#define CLK_H3_BUS_TS		28
+#define CLK_H3_BUS_HSTIMER	29
+#define CLK_H3_BUS_SPI0		30
+#define CLK_H3_BUS_SPI1		31
+#define CLK_H3_BUS_OTG		32
+#define CLK_H3_BUS_EHCI0	33
+#define CLK_H3_BUS_EHCI1	34
+#define CLK_H3_BUS_EHCI2	35
+#define CLK_H3_BUS_EHCI3	36
+#define CLK_H3_BUS_OHCI0	37
+#define CLK_H3_BUS_OHCI1	38
+#define CLK_H3_BUS_OHCI2	39
+#define CLK_H3_BUS_OHCI3	40
+#define CLK_H3_BUS_VE		41
+#define CLK_H3_BUS_TCON0	42
+#define CLK_H3_BUS_TCON1	43
+#define CLK_H3_BUS_DEINTERLACE	44
+#define CLK_H3_BUS_CSI		45
+#define CLK_H3_BUS_TVE		46
+#define CLK_H3_BUS_HDMI		47
+#define CLK_H3_BUS_DE		48
+#define CLK_H3_BUS_GPU		49
+#define CLK_H3_BUS_MSGBOX	50
+#define CLK_H3_BUS_SPINLOCK	51
+#define CLK_H3_BUS_CODEC	52
+#define CLK_H3_BUS_SPDIF	53
+#define CLK_H3_BUS_PIO		54
+#define CLK_H3_BUS_THS		55
+#define CLK_H3_BUS_I2S0		56
+#define CLK_H3_BUS_I2S1		57
+#define CLK_H3_BUS_I2S2		58
+#define CLK_H3_BUS_I2C0		59
+#define CLK_H3_BUS_I2C1		60
+#define CLK_H3_BUS_I2C2		61
+#define CLK_H3_BUS_UART0	62
+#define CLK_H3_BUS_UART1	63
+#define CLK_H3_BUS_UART2	64
+#define CLK_H3_BUS_UART3	65
+#define CLK_H3_BUS_SCR		66
+#define CLK_H3_BUS_EPHY		67
+#define CLK_H3_BUS_DBG		68
 
-#define CLK_THS			69
-#define CLK_NAND		70
-#define CLK_MMC0		71
-#define CLK_MMC0_SAMPLE		72
-#define CLK_MMC0_OUTPUT		73
-#define CLK_MMC1		74
-#define CLK_MMC1_SAMPLE		75
-#define CLK_MMC1_OUTPUT		76
-#define CLK_MMC2		77
-#define CLK_MMC2_SAMPLE		78
-#define CLK_MMC2_OUTPUT		79
-#define CLK_TS			80
-#define CLK_CE			81
-#define CLK_SPI0		82
-#define CLK_SPI1		83
-#define CLK_I2S0		84
-#define CLK_I2S1		85
-#define CLK_I2S2		86
-#define CLK_SPDIF		87
-#define CLK_USB_PHY0		88
-#define CLK_USB_PHY1		89
-#define CLK_USB_PHY2		90
-#define CLK_USB_PHY3		91
-#define CLK_USB_OHCI0		92
-#define CLK_USB_OHCI1		93
-#define CLK_USB_OHCI2		94
-#define CLK_USB_OHCI3		95
+#define CLK_H3_THS		69
+#define CLK_H3_NAND		70
+#define CLK_H3_MMC0		71
+#define CLK_H3_MMC0_SAMPLE	72
+#define CLK_H3_MMC0_OUTPUT	73
+#define CLK_H3_MMC1		74
+#define CLK_H3_MMC1_SAMPLE	75
+#define CLK_H3_MMC1_OUTPUT	76
+#define CLK_H3_MMC2		77
+#define CLK_H3_MMC2_SAMPLE	78
+#define CLK_H3_MMC2_OUTPUT	79
+#define CLK_H3_TS		80
+#define CLK_H3_CE		81
+#define CLK_H3_SPI0		82
+#define CLK_H3_SPI1		83
+#define CLK_H3_I2S0		84
+#define CLK_H3_I2S1		85
+#define CLK_H3_I2S2		86
+#define CLK_H3_SPDIF		87
+#define CLK_H3_USB_PHY0		88
+#define CLK_H3_USB_PHY1		89
+#define CLK_H3_USB_PHY2		90
+#define CLK_H3_USB_PHY3		91
+#define CLK_H3_USB_OHCI0	92
+#define CLK_H3_USB_OHCI1	93
+#define CLK_H3_USB_OHCI2	94
+#define CLK_H3_USB_OHCI3	95
 
-#define CLK_DRAM_VE		97
-#define CLK_DRAM_CSI		98
-#define CLK_DRAM_DEINTERLACE	99
-#define CLK_DRAM_TS		100
-#define CLK_DE			101
-#define CLK_TCON0		102
-#define CLK_TVE			103
-#define CLK_DEINTERLACE		104
-#define CLK_CSI_MISC		105
-#define CLK_CSI_SCLK		106
-#define CLK_CSI_MCLK		107
-#define CLK_VE			108
-#define CLK_AC_DIG		109
-#define CLK_AVS			110
-#define CLK_HDMI		111
-#define CLK_HDMI_DDC		112
+#define CLK_H3_DRAM_VE		97
+#define CLK_H3_DRAM_CSI		98
+#define CLK_H3_DRAM_DEINTERLACE	99
+#define CLK_H3_DRAM_TS		100
+#define CLK_H3_DE		101
+#define CLK_H3_TCON0		102
+#define CLK_H3_TVE		103
+#define CLK_H3_DEINTERLACE	104
+#define CLK_H3_CSI_MISC		105
+#define CLK_H3_CSI_SCLK		106
+#define CLK_H3_CSI_MCLK		107
+#define CLK_H3_VE		108
+#define CLK_H3_AC_DIG		109
+#define CLK_H3_AVS		110
+#define CLK_H3_HDMI		111
+#define CLK_H3_HDMI_DDC		112
 
-#define CLK_GPU			114
+#define CLK_H3_GPU		114
 
 #endif /* _DT_BINDINGS_CLK_SUN8I_H3_H_ */
-- 
2.9.2

^ permalink raw reply related	[flat|nested] 34+ messages in thread

* [PATCH 08/13] clk: sunxi-ng: Add A64 clocks
  2016-07-26 20:30 [PATCH 00/13] arm64: Allwinner A64 support based on sunxi-ng Maxime Ripard
                   ` (6 preceding siblings ...)
  2016-07-26 20:30 ` [PATCH 07/13] clk: sunxi-ng: sun8i: Prefix clock defines by SoC Name Maxime Ripard
@ 2016-07-26 20:30 ` Maxime Ripard
  2016-07-29 21:15   ` Rob Herring
  2016-07-26 20:30 ` [PATCH 09/13] arm64: sunxi: Kconfig: add essential pinctrl driver Maxime Ripard
                   ` (6 subsequent siblings)
  14 siblings, 1 reply; 34+ messages in thread
From: Maxime Ripard @ 2016-07-26 20:30 UTC (permalink / raw)
  To: Rob Herring, Chen-Yu Tsai, Mike Turquette, Stephen Boyd
  Cc: devicetree, Andre Przywara, linux-arm-kernel, linux-kernel,
	linux-clk, Maxime Ripard

Add the A64 CCU clocks set.

Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
---
 .../devicetree/bindings/clock/sunxi-ccu.txt        |   1 +
 drivers/clk/sunxi-ng/Kconfig                       |  13 +-
 drivers/clk/sunxi-ng/Makefile                      |   2 +-
 drivers/clk/sunxi-ng/ccu-sun50i-a64.h              |  68 +++
 drivers/clk/sunxi-ng/ccu-sun8i-h3.c                | 483 +++++++++++++++++++++
 include/dt-bindings/clock/sun50i-a64-ccu.h         | 132 ++++++
 include/dt-bindings/reset/sun50i-a64-ccu.h         |  97 +++++
 7 files changed, 793 insertions(+), 3 deletions(-)
 create mode 100644 drivers/clk/sunxi-ng/ccu-sun50i-a64.h
 create mode 100644 include/dt-bindings/clock/sun50i-a64-ccu.h
 create mode 100644 include/dt-bindings/reset/sun50i-a64-ccu.h

diff --git a/Documentation/devicetree/bindings/clock/sunxi-ccu.txt b/Documentation/devicetree/bindings/clock/sunxi-ccu.txt
index cb91507ffb1e..1502fc6a4aae 100644
--- a/Documentation/devicetree/bindings/clock/sunxi-ccu.txt
+++ b/Documentation/devicetree/bindings/clock/sunxi-ccu.txt
@@ -4,6 +4,7 @@ Allwinner Clock Control Unit Binding
 Required properties :
 - compatible: must contain one of the following compatible:
 		- "allwinner,sun8i-h3-ccu"
+		- "allwinner,sun50i-a64-ccu"
 
 - reg: Must contain the registers base address and length
 - clocks: phandle to the oscillators feeding the CCU. Two are needed:
diff --git a/drivers/clk/sunxi-ng/Kconfig b/drivers/clk/sunxi-ng/Kconfig
index 2afcbd39e41e..81419f63730f 100644
--- a/drivers/clk/sunxi-ng/Kconfig
+++ b/drivers/clk/sunxi-ng/Kconfig
@@ -51,8 +51,8 @@ config SUNXI_CCU_MP
 
 # SoC Drivers
 
-config SUN8I_H3_CCU
-	bool "Support for the Allwinner H3 CCU"
+config SUNXI_H3_A64_CCU_SUPPORT
+	bool
 	select SUNXI_CCU_DIV
 	select SUNXI_CCU_NK
 	select SUNXI_CCU_NKM
@@ -60,6 +60,15 @@ config SUN8I_H3_CCU
 	select SUNXI_CCU_NM
 	select SUNXI_CCU_MP
 	select SUNXI_CCU_PHASE
+
+config SUN8I_H3_CCU
+	bool "Support for the Allwinner H3 CCU"
+	select SUNXI_H3_A64_CCU_SUPPORT
 	default MACH_SUN8I
 
+config SUN50I_A64_CCU
+	bool "Support for the Allwinner A64 CCU"
+	select SUNXI_H3_A64_CCU_SUPPORT
+	default ARM64 && ARCH_SUNXI
+
 endif
diff --git a/drivers/clk/sunxi-ng/Makefile b/drivers/clk/sunxi-ng/Makefile
index 633ce642ffae..d46c460a2cd9 100644
--- a/drivers/clk/sunxi-ng/Makefile
+++ b/drivers/clk/sunxi-ng/Makefile
@@ -17,4 +17,4 @@ obj-$(CONFIG_SUNXI_CCU_NM)	+= ccu_nm.o
 obj-$(CONFIG_SUNXI_CCU_MP)	+= ccu_mp.o
 
 # SoC support
-obj-$(CONFIG_SUN8I_H3_CCU)	+= ccu-sun8i-h3.o
+obj-$(CONFIG_SUNXI_H3_A64_CCU_SUPPORT)	+= ccu-sun8i-h3.o
diff --git a/drivers/clk/sunxi-ng/ccu-sun50i-a64.h b/drivers/clk/sunxi-ng/ccu-sun50i-a64.h
new file mode 100644
index 000000000000..127817ace780
--- /dev/null
+++ b/drivers/clk/sunxi-ng/ccu-sun50i-a64.h
@@ -0,0 +1,68 @@
+/*
+ * Copyright 2016 Maxime Ripard
+ *
+ * Maxime Ripard <maxime.ripard@free-electrons.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#ifndef _CCU_SUN50I_A64_H_
+#define _CCU_SUN50I_A64_H_
+
+#include <dt-bindings/clock/sun50i-a64-ccu.h>
+#include <dt-bindings/reset/sun50i-a64-ccu.h>
+
+#define CLK_A64_OSC_12M			0
+#define CLK_A64_PLL_CPUX		1
+#define CLK_A64_PLL_AUDIO_BASE		2
+#define CLK_A64_PLL_AUDIO		3
+#define CLK_A64_PLL_AUDIO_2X		4
+#define CLK_A64_PLL_AUDIO_4X		5
+#define CLK_A64_PLL_AUDIO_8X		6
+#define CLK_A64_PLL_VIDEO0		7
+#define CLK_A64_PLL_VIDEO0_2X		8
+#define CLK_A64_PLL_VE			9
+#define CLK_A64_PLL_DDR0		10
+#define CLK_A64_PLL_PERIPH0		11
+#define CLK_A64_PLL_PERIPH0_2X		12
+#define CLK_A64_PLL_PERIPH1		13
+#define CLK_A64_PLL_PERIPH1_2X		14
+#define CLK_A64_PLL_VIDEO1		15
+#define CLK_A64_PLL_GPU			16
+#define CLK_A64_PLL_MIPI		17
+#define CLK_A64_PLL_HSIC		18
+#define CLK_A64_PLL_DE			19
+#define CLK_A64_PLL_DDR1		20
+#define CLK_A64_CPUX			21
+#define CLK_A64_AXI			22
+#define CLK_A64_APB			23
+#define CLK_A64_AHB1			24
+#define CLK_A64_APB1			25
+#define CLK_A64_APB2			26
+#define CLK_A64_AHB2			27
+
+/* All the bus gates are exported */
+
+/* The first bunch of module clocks are exported */
+
+#define CLK_A64_DRAM			92
+
+/* All the DRAM gates are exported */
+
+/* Some more module clocks are exported */
+
+#define CLK_A64_MBUS			110
+
+/* And the DSI and GPU module clock is exported */
+
+#define CLK_A64_NUMBER		(CLK_A64_GPU + 1)
+
+#endif /* _CCU_SUN50I_A64_H_ */
diff --git a/drivers/clk/sunxi-ng/ccu-sun8i-h3.c b/drivers/clk/sunxi-ng/ccu-sun8i-h3.c
index 2e91f43937c8..cb0dbeb386b0 100644
--- a/drivers/clk/sunxi-ng/ccu-sun8i-h3.c
+++ b/drivers/clk/sunxi-ng/ccu-sun8i-h3.c
@@ -27,6 +27,7 @@
 #include "ccu_nm.h"
 #include "ccu_phase.h"
 
+#include "ccu-sun50i-a64.h"
 #include "ccu-sun8i-h3.h"
 
 static SUNXI_CCU_NKMP_WITH_GATE_LOCK(pll_cpux_clk, "pll-cpux",
@@ -99,6 +100,27 @@ static SUNXI_CCU_NK_WITH_GATE_LOCK_POSTDIV(pll_periph0_clk, "pll-periph0",
 					   2,		/* post-div */
 					   0);
 
+static SUNXI_CCU_NK_WITH_GATE_LOCK_POSTDIV(pll_periph1_a64_clk, "pll-periph1",
+					   "osc24M", 0x02c,
+					   8, 5,	/* N */
+					   4, 2,	/* K */
+					   BIT(31),	/* gate */
+					   BIT(28),	/* lock */
+					   2,		/* post-div */
+					   0);
+
+static SUNXI_CCU_NM_WITH_FRAC_GATE_LOCK(pll_video1_a64_clk, "pll-video1",
+					"osc24M", 0x030,
+					8, 7,		/* N */
+					0, 4,		/* M */
+					BIT(24),	/* frac enable */
+					BIT(25),	/* frac select */
+					270000000,	/* frac rate 0 */
+					297000000,	/* frac rate 1 */
+					BIT(31),	/* gate */
+					BIT(28),	/* lock */
+					0);
+
 static SUNXI_CCU_NM_WITH_FRAC_GATE_LOCK(pll_gpu_clk, "pll-gpu",
 					"osc24M", 0x038,
 					8, 7,		/* N */
@@ -111,6 +133,35 @@ static SUNXI_CCU_NM_WITH_FRAC_GATE_LOCK(pll_gpu_clk, "pll-gpu",
 					BIT(28),	/* lock */
 					0);
 
+/*
+ * The output function can be changed to something more complex that
+ * we do not handle yet.
+ *
+ * Hardcode the mode so that we don't fall in that case.
+ */
+#define SUN50I_A64_PLL_MIPI_REG		0x040
+
+static SUNXI_CCU_NKM_WITH_GATE_LOCK(pll_mipi_a64_clk, "pll-mipi",
+				    "pll-video0", 0x040,
+				    8, 4,	/* N */
+				    4, 2,	/* K */
+				    0, 4,	/* M */
+				    BIT(31),	/* gate */
+				    BIT(28),	/* lock */
+				    0);
+
+static SUNXI_CCU_NM_WITH_FRAC_GATE_LOCK(pll_hsic_a64_clk, "pll-hsic",
+					"osc24M", 0x044,
+					8, 7,		/* N */
+					0, 4,		/* M */
+					BIT(24),	/* frac enable */
+					BIT(25),	/* frac select */
+					270000000,	/* frac rate 0 */
+					297000000,	/* frac rate 1 */
+					BIT(31),	/* gate */
+					BIT(28),	/* lock */
+					0);
+
 static SUNXI_CCU_NK_WITH_GATE_LOCK_POSTDIV(pll_periph1_h3_clk, "pll-periph1",
 					   "osc24M", 0x044,
 					   8, 5,	/* N */
@@ -132,6 +183,14 @@ static SUNXI_CCU_NM_WITH_FRAC_GATE_LOCK(pll_de_clk, "pll-de",
 					BIT(28),	/* lock */
 					0);
 
+static SUNXI_CCU_NM_WITH_GATE_LOCK(pll_ddr1_a64_clk, "pll-ddr1",
+				   "osc24M", 0x04c,
+				   8, 7,	/* N */
+				   0, 2,	/* M */
+				   BIT(31),	/* gate */
+				   BIT(28),	/* lock */
+				   0);
+
 static const char * const cpux_parents[] = { "osc32k", "osc24M",
 					     "pll-cpux" , "pll-cpux" };
 static SUNXI_CCU_MUX(cpux_clk, "cpux", cpux_parents,
@@ -175,6 +234,15 @@ static struct clk_div_table apb1_div_table[] = {
 static SUNXI_CCU_DIV_TABLE(apb1_clk, "apb1", "ahb1",
 			   0x054, 8, 2, apb1_div_table, 0);
 
+static const char * const apb2_a64_parents[] = { "osc32k", "osc24M",
+						 "pll-periph0-2x" ,
+						 "pll-periph0-2x" };
+static SUNXI_CCU_MP_WITH_MUX(apb2_a64_clk, "apb2", apb2_a64_parents, 0x058,
+			     0, 5,	/* M */
+			     16, 2,	/* P */
+			     24, 2,	/* mux */
+			     0);
+
 static const char * const apb2_h3_parents[] = { "osc32k", "osc24M",
 						"pll-periph0" , "pll-periph0" };
 static SUNXI_CCU_MP_WITH_MUX(apb2_h3_clk, "apb2", apb2_h3_parents, 0x058,
@@ -205,6 +273,8 @@ static struct ccu_mux ahb2_clk = {
 	},
 };
 
+static SUNXI_CCU_GATE(bus_mipi_dsi_a64_clk,	"bus-mipi-dsi",	"ahb1",
+		      0x060, BIT(1), 0);
 static SUNXI_CCU_GATE(bus_ce_clk,	"bus-ce",	"ahb1",
 		      0x060, BIT(5), 0);
 static SUNXI_CCU_GATE(bus_dma_clk,	"bus-dma",	"ahb1",
@@ -292,6 +362,8 @@ static SUNXI_CCU_GATE(bus_i2c1_clk,	"bus-i2c1",	"apb2",
 		      0x06c, BIT(1), 0);
 static SUNXI_CCU_GATE(bus_i2c2_clk,	"bus-i2c2",	"apb2",
 		      0x06c, BIT(2), 0);
+static SUNXI_CCU_GATE(bus_scr_a64_clk,	"bus-scr",	"apb2",
+		      0x06c, BIT(5), 0);
 static SUNXI_CCU_GATE(bus_uart0_clk,	"bus-uart0",	"apb2",
 		      0x06c, BIT(16), 0);
 static SUNXI_CCU_GATE(bus_uart1_clk,	"bus-uart1",	"apb2",
@@ -300,6 +372,8 @@ static SUNXI_CCU_GATE(bus_uart2_clk,	"bus-uart2",	"apb2",
 		      0x06c, BIT(18), 0);
 static SUNXI_CCU_GATE(bus_uart3_clk,	"bus-uart3",	"apb2",
 		      0x06c, BIT(19), 0);
+static SUNXI_CCU_GATE(bus_uart4_a64_clk,	"bus-uart4",	"apb2",
+		      0x06c, BIT(20), 0);
 static SUNXI_CCU_GATE(bus_scr_h3_clk,	"bus-scr",	"apb2",
 		      0x06c, BIT(20), 0);
 
@@ -326,6 +400,15 @@ static SUNXI_CCU_MP_WITH_MUX_GATE(nand_clk, "nand", mod0_default_parents, 0x080,
 				  BIT(31),	/* gate */
 				  0);
 
+static const char * const mmc_default_parents[] = { "osc24M", "pll-periph0-2x",
+						    "pll-periph1-2x" };
+static SUNXI_CCU_MP_WITH_MUX_GATE(mmc0_a64_clk, "mmc0", mmc_default_parents, 0x088,
+				  0, 4,		/* M */
+				  16, 2,	/* P */
+				  24, 2,	/* mux */
+				  BIT(31),	/* gate */
+				  0);
+
 static SUNXI_CCU_MP_WITH_MUX_GATE(mmc0_h3_clk, "mmc0", mod0_default_parents, 0x088,
 				  0, 4,		/* M */
 				  16, 2,	/* P */
@@ -338,6 +421,13 @@ static SUNXI_CCU_PHASE(mmc0_sample_h3_clk, "mmc0_sample", "mmc0",
 static SUNXI_CCU_PHASE(mmc0_output_h3_clk, "mmc0_output", "mmc0",
 		       0x088, 8, 3, 0);
 
+static SUNXI_CCU_MP_WITH_MUX_GATE(mmc1_a64_clk, "mmc1", mmc_default_parents, 0x08c,
+				  0, 4,		/* M */
+				  16, 2,	/* P */
+				  24, 2,	/* mux */
+				  BIT(31),	/* gate */
+				  0);
+
 static SUNXI_CCU_MP_WITH_MUX_GATE(mmc1_h3_clk, "mmc1", mod0_default_parents, 0x08c,
 				  0, 4,		/* M */
 				  16, 2,	/* P */
@@ -350,6 +440,13 @@ static SUNXI_CCU_PHASE(mmc1_sample_h3_clk, "mmc1_sample", "mmc1",
 static SUNXI_CCU_PHASE(mmc1_output_h3_clk, "mmc1_output", "mmc1",
 		       0x08c, 8, 3, 0);
 
+static SUNXI_CCU_MP_WITH_MUX_GATE(mmc2_a64_clk, "mmc2", mmc_default_parents, 0x090,
+				  0, 4,		/* M */
+				  16, 2,	/* P */
+				  24, 2,	/* mux */
+				  BIT(31),	/* gate */
+				  0);
+
 static SUNXI_CCU_MP_WITH_MUX_GATE(mmc2_h3_clk, "mmc2", mod0_default_parents, 0x090,
 				  0, 4,		/* M */
 				  16, 2,	/* P */
@@ -370,6 +467,14 @@ static SUNXI_CCU_MP_WITH_MUX_GATE(ts_clk, "ts", ts_parents, 0x098,
 				  BIT(31),	/* gate */
 				  0);
 
+static SUNXI_CCU_MP_WITH_MUX_GATE(ce_a64_clk, "ce", mmc_default_parents, 0x09c,
+				  0, 4,		/* M */
+				  16, 2,	/* P */
+				  24, 2,	/* mux */
+				  BIT(31),	/* gate */
+				  0);
+
+
 static SUNXI_CCU_MP_WITH_MUX_GATE(ce_h3_clk, "ce", mod0_default_parents, 0x09c,
 				  0, 4,		/* M */
 				  16, 2,	/* P */
@@ -409,12 +514,20 @@ static SUNXI_CCU_GATE(usb_phy0_clk,	"usb-phy0",	"osc24M",
 		      0x0cc, BIT(8), 0);
 static SUNXI_CCU_GATE(usb_phy1_clk,	"usb-phy1",	"osc24M",
 		      0x0cc, BIT(9), 0);
+static SUNXI_CCU_GATE(usb_hsic_a64_clk,	"usb-hsic",	"pll-hsic",
+		      0x0cc, BIT(10), 0);
 static SUNXI_CCU_GATE(usb_phy2_h3_clk,	"usb-phy2",	"osc24M",
 		      0x0cc, BIT(10), 0);
+static SUNXI_CCU_GATE(usb_hsic_12m_a64_clk,	"usb-hsic-12M",	"osc12M",
+		      0x0cc, BIT(11), 0);
 static SUNXI_CCU_GATE(usb_phy3_h3_clk,	"usb-phy3",	"osc24M",
 		      0x0cc, BIT(11), 0);
+static SUNXI_CCU_GATE(usb_ohci0_a64_clk,	"usb-ohci0",	"osc12M",
+		      0x0cc, BIT(16), 0);
 static SUNXI_CCU_GATE(usb_ohci0_h3_clk,	"usb-ohci0",	"osc24M",
 		      0x0cc, BIT(16), 0);
+static SUNXI_CCU_GATE(usb_ohci1_a64_clk,	"usb-ohci1",	"usb-ohci0",
+		      0x0cc, BIT(17), 0);
 static SUNXI_CCU_GATE(usb_ohci1_h3_clk,	"usb-ohci1",	"osc24M",
 		      0x0cc, BIT(17), 0);
 static SUNXI_CCU_GATE(usb_ohci2_h3_clk,	"usb-ohci2",	"osc24M",
@@ -422,6 +535,10 @@ static SUNXI_CCU_GATE(usb_ohci2_h3_clk,	"usb-ohci2",	"osc24M",
 static SUNXI_CCU_GATE(usb_ohci3_h3_clk,	"usb-ohci3",	"osc24M",
 		      0x0cc, BIT(19), 0);
 
+static const char * const dram_a64_parents[] = { "pll-ddr0", "pll-ddr1" };
+static SUNXI_CCU_M_WITH_MUX(dram_a64_clk, "dram", dram_a64_parents,
+			    0x0f4, 0, 4, 20, 2, CLK_IS_CRITICAL);
+
 static const char * const dram_h3_parents[] = { "pll-ddr0", "pll-periph0-2x" };
 static SUNXI_CCU_M_WITH_MUX(dram_h3_clk, "dram", dram_h3_parents,
 			    0x0f4, 0, 4, 20, 2, CLK_IS_CRITICAL);
@@ -439,10 +556,30 @@ static const char * const de_parents[] = { "pll-periph0-2x", "pll-de" };
 static SUNXI_CCU_M_WITH_MUX_GATE(de_clk, "de", de_parents,
 				 0x104, 0, 4, 24, 3, BIT(31), 0);
 
+static const char * const tcon0_a64_parents[] = { "pll-mipi", "pll-video0-2x" };
+static const u8 tcon0_a64_table[] = { 0, 2, };
+static SUNXI_CCU_MUX_TABLE_WITH_GATE(tcon0_a64_clk, "tcon0", tcon0_a64_parents,
+				     tcon0_a64_table, 0x118, 24, 3, BIT(31), 0);
+
 static const char * const tcon0_h3_parents[] = { "pll-video0" };
 static SUNXI_CCU_M_WITH_MUX_GATE(tcon0_h3_clk, "tcon0", tcon0_h3_parents,
 				 0x118, 0, 4, 24, 3, BIT(31), 0);
 
+static const char * const tcon1_a64_parents[] = { "pll-video0", "pll-video1" };
+static const u8 tcon1_a64_table[] = { 0, 2, };
+struct ccu_div tcon1_a64_clk = {
+	.enable		= BIT(31),
+	.div		= _SUNXI_CCU_DIV(0, 4),
+	.mux		= _SUNXI_CCU_MUX_TABLE(24, 3, tcon1_a64_table),
+	.common		= {
+		.reg		= 0x11c,
+		.hw.init	= CLK_HW_INIT_PARENTS("tcon1",
+						      tcon1_a64_parents,
+						      &ccu_div_ops,
+						      0),
+	},
+};
+
 static const char * const tve_h3_parents[] = { "pll-de", "pll-periph1" };
 static SUNXI_CCU_M_WITH_MUX_GATE(tve_h3_clk, "tve", tve_h3_parents,
 				 0x120, 0, 4, 24, 3, BIT(31), 0);
@@ -458,6 +595,10 @@ static const char * const csi_sclk_parents[] = { "pll-periph0", "pll-periph1" };
 static SUNXI_CCU_M_WITH_MUX_GATE(csi_sclk_clk, "csi-sclk", csi_sclk_parents,
 				 0x134, 16, 4, 24, 3, BIT(31), 0);
 
+static const char * const csi_mclk_a64_parents[] = { "osc24M", "pll-video1", "pll-periph1" };
+static SUNXI_CCU_M_WITH_MUX_GATE(csi_mclk_a64_clk, "csi-mclk", csi_mclk_a64_parents,
+				 0x134, 0, 5, 8, 3, BIT(15), 0);
+
 static const char * const csi_mclk_h3_parents[] = { "osc24M", "pll-video0", "pll-periph0" };
 static SUNXI_CCU_M_WITH_MUX_GATE(csi_mclk_h3_clk, "csi-mclk", csi_mclk_h3_parents,
 				 0x134, 0, 5, 8, 3, BIT(15), 0);
@@ -467,9 +608,17 @@ static SUNXI_CCU_M_WITH_GATE(ve_clk, "ve", "pll-ve",
 
 static SUNXI_CCU_GATE(ac_dig_clk,	"ac-dig",	"pll-audio",
 		      0x140, BIT(31), 0);
+
+static SUNXI_CCU_GATE(ac_dig_4x_a64_clk,	"ac-dig-4x",	"pll-audio-4x",
+		      0x140, BIT(30), 0);
+
 static SUNXI_CCU_GATE(avs_clk,		"avs",		"osc24M",
 		      0x144, BIT(31), 0);
 
+static const char * const hdmi_a64_parents[] = { "pll-video0", "pll-video1" };
+static SUNXI_CCU_M_WITH_MUX_GATE(hdmi_a64_clk, "hdmi", hdmi_a64_parents,
+				 0x150, 0, 4, 24, 2, BIT(31), 0);
+
 static const char * const hdmi_h3_parents[] = { "pll-video0" };
 static SUNXI_CCU_M_WITH_MUX_GATE(hdmi_h3_clk, "hdmi", hdmi_h3_parents,
 				 0x150, 0, 4, 24, 2, BIT(31), 0);
@@ -477,14 +626,25 @@ static SUNXI_CCU_M_WITH_MUX_GATE(hdmi_h3_clk, "hdmi", hdmi_h3_parents,
 static SUNXI_CCU_GATE(hdmi_ddc_clk,	"hdmi-ddc",	"osc24M",
 		      0x154, BIT(31), 0);
 
+static const char * const mbus_a64_parents[] = { "osc24M", "pll-periph0-2x",
+						 "pll-ddr0", "pll-ddr1" };
+static SUNXI_CCU_M_WITH_MUX_GATE(mbus_a64_clk, "mbus", mbus_a64_parents,
+				 0x15c, 0, 3, 24, 2, BIT(31), CLK_IS_CRITICAL);
+
 static const char * const mbus_h3_parents[] = { "osc24M", "pll-periph0-2x", "pll-ddr0" };
 static SUNXI_CCU_M_WITH_MUX_GATE(mbus_h3_clk, "mbus", mbus_h3_parents,
 				 0x15c, 0, 3, 24, 2, BIT(31), CLK_IS_CRITICAL);
 
+static const char * const dsi_dphy_a64_parents[] = { "pll-video0", "pll-periph0" };
+static SUNXI_CCU_M_WITH_MUX_GATE(dsi_dphy_a64_clk, "dsi-dphy", dsi_dphy_a64_parents,
+				 0x168, 0, 3, 24, 2, BIT(31), 0);
+
 static SUNXI_CCU_M_WITH_GATE(gpu_clk, "gpu", "pll-gpu",
 			     0x1a0, 0, 3, BIT(31), 0);
 
 /* Fixed Factor clocks */
+static CLK_FIXED_FACTOR(osc12M_a64_clk, "osc12M", "osc24M", 1, 2, 0);
+
 /* We hardcode the divider to 4 for now */
 static CLK_FIXED_FACTOR(pll_audio_clk, "pll-audio",
 			"pll-audio-base", 4, 1, CLK_SET_RATE_PARENT);
@@ -496,6 +656,10 @@ static CLK_FIXED_FACTOR(pll_audio_8x_clk, "pll-audio-8x",
 			"pll-audio-base", 1, 2, CLK_SET_RATE_PARENT);
 static CLK_FIXED_FACTOR(pll_periph0_2x_clk, "pll-periph0-2x",
 			"pll-periph0", 1, 2, 0);
+static CLK_FIXED_FACTOR(pll_periph1_2x_clk, "pll-periph1-2x",
+			"pll-periph1", 1, 2, 0);
+static CLK_FIXED_FACTOR(pll_video0_2x_clk, "pll-video0-2x",
+			"pll-video0", 1, 2, 0);
 
 static struct ccu_common *sun8i_h3_ccu_clks[] = {
 	&pll_cpux_clk.common,
@@ -825,3 +989,322 @@ static void __init sun8i_h3_ccu_setup(struct device_node *node)
 }
 CLK_OF_DECLARE(sun8i_h3_ccu, "allwinner,sun8i-h3-ccu",
 	       sun8i_h3_ccu_setup);
+
+static struct ccu_common *sun50i_a64_ccu_clks[] = {
+	&pll_cpux_clk.common,
+	&pll_audio_base_clk.common,
+	&pll_video0_clk.common,
+	&pll_ve_clk.common,
+	&pll_ddr0_clk.common,
+	&pll_periph0_clk.common,
+	&pll_periph1_a64_clk.common,
+	&pll_video1_a64_clk.common,
+	&pll_gpu_clk.common,
+	&pll_mipi_a64_clk.common,
+	&pll_hsic_a64_clk.common,
+	&pll_de_clk.common,
+	&pll_ddr1_a64_clk.common,
+	&cpux_clk.common,
+	&axi_clk.common,
+	&ahb1_clk.common,
+	&apb1_clk.common,
+	&apb2_a64_clk.common,
+	&ahb2_clk.common,
+	&bus_mipi_dsi_a64_clk.common,
+	&bus_ce_clk.common,
+	&bus_dma_clk.common,
+	&bus_mmc0_clk.common,
+	&bus_mmc1_clk.common,
+	&bus_mmc2_clk.common,
+	&bus_nand_clk.common,
+	&bus_dram_clk.common,
+	&bus_emac_clk.common,
+	&bus_ts_clk.common,
+	&bus_hstimer_clk.common,
+	&bus_spi0_clk.common,
+	&bus_spi1_clk.common,
+	&bus_otg_clk.common,
+	&bus_ehci0_clk.common,
+	&bus_ehci1_clk.common,
+	&bus_ohci0_clk.common,
+	&bus_ohci1_clk.common,
+	&bus_ve_clk.common,
+	&bus_tcon0_clk.common,
+	&bus_tcon1_clk.common,
+	&bus_deinterlace_clk.common,
+	&bus_csi_clk.common,
+	&bus_hdmi_clk.common,
+	&bus_de_clk.common,
+	&bus_gpu_clk.common,
+	&bus_msgbox_clk.common,
+	&bus_spinlock_clk.common,
+	&bus_codec_clk.common,
+	&bus_spdif_clk.common,
+	&bus_pio_clk.common,
+	&bus_ths_clk.common,
+	&bus_i2s0_clk.common,
+	&bus_i2s1_clk.common,
+	&bus_i2s2_clk.common,
+	&bus_i2c0_clk.common,
+	&bus_i2c1_clk.common,
+	&bus_i2c2_clk.common,
+	&bus_scr_a64_clk.common,
+	&bus_uart0_clk.common,
+	&bus_uart1_clk.common,
+	&bus_uart2_clk.common,
+	&bus_uart3_clk.common,
+	&bus_uart4_a64_clk.common,
+	&bus_dbg_clk.common,
+	&ths_clk.common,
+	&nand_clk.common,
+	&mmc0_a64_clk.common,
+	&mmc1_a64_clk.common,
+	&mmc2_a64_clk.common,
+	&ts_clk.common,
+	&ce_a64_clk.common,
+	&spi0_clk.common,
+	&spi1_clk.common,
+	&i2s0_clk.common,
+	&i2s1_clk.common,
+	&i2s2_clk.common,
+	&spdif_clk.common,
+	&usb_phy0_clk.common,
+	&usb_phy1_clk.common,
+	&usb_hsic_a64_clk.common,
+	&usb_hsic_12m_a64_clk.common,
+	&usb_ohci0_a64_clk.common,
+	&usb_ohci1_a64_clk.common,
+	&dram_a64_clk.common,
+	&dram_ve_clk.common,
+	&dram_csi_clk.common,
+	&dram_deinterlace_clk.common,
+	&dram_ts_clk.common,
+	&de_clk.common,
+	&tcon0_a64_clk.common,
+	&tcon1_a64_clk.common,
+	&deinterlace_clk.common,
+	&csi_misc_clk.common,
+	&csi_sclk_clk.common,
+	&csi_mclk_a64_clk.common,
+	&ve_clk.common,
+	&ac_dig_clk.common,
+	&ac_dig_4x_a64_clk.common,
+	&avs_clk.common,
+	&hdmi_a64_clk.common,
+	&hdmi_ddc_clk.common,
+	&mbus_a64_clk.common,
+	&dsi_dphy_a64_clk.common,
+	&gpu_clk.common,
+};
+
+static struct clk_hw_onecell_data sun50i_a64_hw_clks = {
+	.hws	= {
+		[CLK_A64_OSC_12M]	= &osc12M_a64_clk.hw,
+		[CLK_A64_PLL_CPUX]	= &pll_cpux_clk.common.hw,
+		[CLK_A64_PLL_AUDIO_BASE] = &pll_audio_base_clk.common.hw,
+		[CLK_A64_PLL_AUDIO]	= &pll_audio_clk.hw,
+		[CLK_A64_PLL_AUDIO_2X]	= &pll_audio_2x_clk.hw,
+		[CLK_A64_PLL_AUDIO_4X]	= &pll_audio_4x_clk.hw,
+		[CLK_A64_PLL_AUDIO_8X]	= &pll_audio_8x_clk.hw,
+		[CLK_A64_PLL_VIDEO0]	= &pll_video0_clk.common.hw,
+		[CLK_A64_PLL_VIDEO0_2X]	= &pll_video0_2x_clk.hw,
+		[CLK_A64_PLL_VE]	= &pll_ve_clk.common.hw,
+		[CLK_A64_PLL_DDR0]	= &pll_ddr0_clk.common.hw,
+		[CLK_A64_PLL_PERIPH0]	= &pll_periph0_clk.common.hw,
+		[CLK_A64_PLL_PERIPH0_2X] = &pll_periph0_2x_clk.hw,
+		[CLK_A64_PLL_PERIPH1]	= &pll_periph1_a64_clk.common.hw,
+		[CLK_A64_PLL_PERIPH1_2X] = &pll_periph1_2x_clk.hw,
+		[CLK_A64_PLL_VIDEO1]	= &pll_video1_a64_clk.common.hw,
+		[CLK_A64_PLL_GPU]	= &pll_gpu_clk.common.hw,
+		[CLK_A64_PLL_MIPI]  	= &pll_mipi_a64_clk.common.hw,
+		[CLK_A64_PLL_HSIC]	= &pll_hsic_a64_clk.common.hw,
+		[CLK_A64_PLL_DE]	= &pll_de_clk.common.hw,
+		[CLK_A64_PLL_DDR1]	= &pll_ddr1_a64_clk.common.hw,
+		[CLK_A64_CPUX]		= &cpux_clk.common.hw,
+		[CLK_A64_AXI]		= &axi_clk.common.hw,
+		[CLK_A64_AHB1]		= &ahb1_clk.common.hw,
+		[CLK_A64_APB1]		= &apb1_clk.common.hw,
+		[CLK_A64_APB2]		= &apb2_a64_clk.common.hw,
+		[CLK_A64_AHB2]		= &ahb2_clk.common.hw,
+		[CLK_A64_BUS_MIPI_DSI]	= &bus_mipi_dsi_a64_clk.common.hw,
+		[CLK_A64_BUS_CE]	= &bus_ce_clk.common.hw,
+		[CLK_A64_BUS_DMA]	= &bus_dma_clk.common.hw,
+		[CLK_A64_BUS_MMC0]	= &bus_mmc0_clk.common.hw,
+		[CLK_A64_BUS_MMC1]	= &bus_mmc1_clk.common.hw,
+		[CLK_A64_BUS_MMC2]	= &bus_mmc2_clk.common.hw,
+		[CLK_A64_BUS_NAND]	= &bus_nand_clk.common.hw,
+		[CLK_A64_BUS_DRAM]	= &bus_dram_clk.common.hw,
+		[CLK_A64_BUS_EMAC]	= &bus_emac_clk.common.hw,
+		[CLK_A64_BUS_TS]	= &bus_ts_clk.common.hw,
+		[CLK_A64_BUS_HSTIMER]	= &bus_hstimer_clk.common.hw,
+		[CLK_A64_BUS_SPI0]	= &bus_spi0_clk.common.hw,
+		[CLK_A64_BUS_SPI1]	= &bus_spi1_clk.common.hw,
+		[CLK_A64_BUS_OTG]	= &bus_otg_clk.common.hw,
+		[CLK_A64_BUS_EHCI0]	= &bus_ehci0_clk.common.hw,
+		[CLK_A64_BUS_EHCI1]	= &bus_ehci1_clk.common.hw,
+		[CLK_A64_BUS_OHCI0]	= &bus_ohci0_clk.common.hw,
+		[CLK_A64_BUS_OHCI1]	= &bus_ohci1_clk.common.hw,
+		[CLK_A64_BUS_VE]	= &bus_ve_clk.common.hw,
+		[CLK_A64_BUS_TCON0]	= &bus_tcon0_clk.common.hw,
+		[CLK_A64_BUS_TCON1]	= &bus_tcon1_clk.common.hw,
+		[CLK_A64_BUS_DEINTERLACE] = &bus_deinterlace_clk.common.hw,
+		[CLK_A64_BUS_CSI]	= &bus_csi_clk.common.hw,
+		[CLK_A64_BUS_HDMI]	= &bus_hdmi_clk.common.hw,
+		[CLK_A64_BUS_DE]	= &bus_de_clk.common.hw,
+		[CLK_A64_BUS_GPU]	= &bus_gpu_clk.common.hw,
+		[CLK_A64_BUS_MSGBOX]	= &bus_msgbox_clk.common.hw,
+		[CLK_A64_BUS_SPINLOCK]	= &bus_spinlock_clk.common.hw,
+		[CLK_A64_BUS_CODEC]	= &bus_codec_clk.common.hw,
+		[CLK_A64_BUS_SPDIF]	= &bus_spdif_clk.common.hw,
+		[CLK_A64_BUS_PIO]	= &bus_pio_clk.common.hw,
+		[CLK_A64_BUS_THS]	= &bus_ths_clk.common.hw,
+		[CLK_A64_BUS_I2S0]	= &bus_i2s0_clk.common.hw,
+		[CLK_A64_BUS_I2S1]	= &bus_i2s1_clk.common.hw,
+		[CLK_A64_BUS_I2S2]	= &bus_i2s2_clk.common.hw,
+		[CLK_A64_BUS_I2C0]	= &bus_i2c0_clk.common.hw,
+		[CLK_A64_BUS_I2C1]	= &bus_i2c1_clk.common.hw,
+		[CLK_A64_BUS_I2C2]	= &bus_i2c2_clk.common.hw,
+		[CLK_A64_BUS_UART0]	= &bus_uart0_clk.common.hw,
+		[CLK_A64_BUS_UART1]	= &bus_uart1_clk.common.hw,
+		[CLK_A64_BUS_UART2]	= &bus_uart2_clk.common.hw,
+		[CLK_A64_BUS_UART3]	= &bus_uart3_clk.common.hw,
+		[CLK_A64_BUS_UART4]	= &bus_uart4_a64_clk.common.hw,
+		[CLK_A64_BUS_SCR]	= &bus_scr_a64_clk.common.hw,
+		[CLK_A64_BUS_DBG]	= &bus_dbg_clk.common.hw,
+		[CLK_A64_THS]		= &ths_clk.common.hw,
+		[CLK_A64_NAND]		= &nand_clk.common.hw,
+		[CLK_A64_MMC0]		= &mmc0_a64_clk.common.hw,
+		[CLK_A64_MMC1]		= &mmc1_a64_clk.common.hw,
+		[CLK_A64_MMC2]		= &mmc2_a64_clk.common.hw,
+		[CLK_A64_TS]		= &ts_clk.common.hw,
+		[CLK_A64_CE]		= &ce_a64_clk.common.hw,
+		[CLK_A64_SPI0]		= &spi0_clk.common.hw,
+		[CLK_A64_SPI1]		= &spi1_clk.common.hw,
+		[CLK_A64_I2S0]		= &i2s0_clk.common.hw,
+		[CLK_A64_I2S1]		= &i2s1_clk.common.hw,
+		[CLK_A64_I2S2]		= &i2s2_clk.common.hw,
+		[CLK_A64_SPDIF]		= &spdif_clk.common.hw,
+		[CLK_A64_USB_PHY0]	= &usb_phy0_clk.common.hw,
+		[CLK_A64_USB_PHY1]	= &usb_phy1_clk.common.hw,
+		[CLK_A64_USB_HSIC]	= &usb_hsic_a64_clk.common.hw,
+		[CLK_A64_USB_HSIC_12M]	= &usb_hsic_12m_a64_clk.common.hw,
+		[CLK_A64_USB_OHCI0]	= &usb_ohci0_a64_clk.common.hw,
+		[CLK_A64_USB_OHCI1]	= &usb_ohci1_a64_clk.common.hw,
+		[CLK_A64_DRAM]		= &dram_a64_clk.common.hw,
+		[CLK_A64_DRAM_VE]	= &dram_ve_clk.common.hw,
+		[CLK_A64_DRAM_CSI]	= &dram_csi_clk.common.hw,
+		[CLK_A64_DRAM_DEINTERLACE] = &dram_deinterlace_clk.common.hw,
+		[CLK_A64_DRAM_TS]	= &dram_ts_clk.common.hw,
+		[CLK_A64_DE]		= &de_clk.common.hw,
+		[CLK_A64_TCON0]		= &tcon0_a64_clk.common.hw,
+		[CLK_A64_TCON1]		= &tcon1_a64_clk.common.hw,
+		[CLK_A64_DEINTERLACE]	= &deinterlace_clk.common.hw,
+		[CLK_A64_CSI_MISC]	= &csi_misc_clk.common.hw,
+		[CLK_A64_CSI_SCLK]	= &csi_sclk_clk.common.hw,
+		[CLK_A64_CSI_MCLK]	= &csi_mclk_a64_clk.common.hw,
+		[CLK_A64_VE]		= &ve_clk.common.hw,
+		[CLK_A64_AC_DIG]	= &ac_dig_clk.common.hw,
+		[CLK_A64_AC_DIG_4X]	= &ac_dig_4x_a64_clk.common.hw,
+		[CLK_A64_AVS]		= &avs_clk.common.hw,
+		[CLK_A64_HDMI]		= &hdmi_a64_clk.common.hw,
+		[CLK_A64_HDMI_DDC]	= &hdmi_ddc_clk.common.hw,
+		[CLK_A64_MBUS]		= &mbus_a64_clk.common.hw,
+		[CLK_A64_DSI_DPHY]	= &dsi_dphy_a64_clk.common.hw,
+		[CLK_A64_GPU]		= &gpu_clk.common.hw,
+	},
+	.num	= CLK_A64_NUMBER,
+};
+
+static struct ccu_reset_map sun50i_a64_ccu_resets[] = {
+	[RST_A64_USB_PHY0]		=  { 0x0cc, BIT(0) },
+	[RST_A64_USB_PHY1]		=  { 0x0cc, BIT(1) },
+	[RST_A64_USB_HSIC]		=  { 0x0cc, BIT(2) },
+
+
+	[RST_A64_MBUS]			=  { 0x0fc, BIT(31) },
+
+	[RST_A64_BUS_MIPI_DSI]		=  { 0x2c0, BIT(1) },
+	[RST_A64_BUS_CE]		=  { 0x2c0, BIT(5) },
+	[RST_A64_BUS_DMA]		=  { 0x2c0, BIT(6) },
+	[RST_A64_BUS_MMC0]		=  { 0x2c0, BIT(8) },
+	[RST_A64_BUS_MMC1]		=  { 0x2c0, BIT(9) },
+	[RST_A64_BUS_MMC2]		=  { 0x2c0, BIT(10) },
+	[RST_A64_BUS_NAND]		=  { 0x2c0, BIT(13) },
+	[RST_A64_BUS_DRAM]		=  { 0x2c0, BIT(14) },
+	[RST_A64_BUS_EMAC]		=  { 0x2c0, BIT(17) },
+	[RST_A64_BUS_TS]		=  { 0x2c0, BIT(18) },
+	[RST_A64_BUS_HSTIMER]		=  { 0x2c0, BIT(19) },
+	[RST_A64_BUS_SPI0]		=  { 0x2c0, BIT(20) },
+	[RST_A64_BUS_SPI1]		=  { 0x2c0, BIT(21) },
+	[RST_A64_BUS_OTG]		=  { 0x2c0, BIT(23) },
+	[RST_A64_BUS_EHCI0]		=  { 0x2c0, BIT(24) },
+	[RST_A64_BUS_EHCI1]		=  { 0x2c0, BIT(25) },
+	[RST_A64_BUS_OHCI0]		=  { 0x2c0, BIT(28) },
+	[RST_A64_BUS_OHCI1]		=  { 0x2c0, BIT(29) },
+
+	[RST_A64_BUS_VE]		=  { 0x2c4, BIT(0) },
+	[RST_A64_BUS_TCON0]		=  { 0x2c4, BIT(3) },
+	[RST_A64_BUS_TCON1]		=  { 0x2c4, BIT(4) },
+	[RST_A64_BUS_DEINTERLACE]	=  { 0x2c4, BIT(5) },
+	[RST_A64_BUS_CSI]		=  { 0x2c4, BIT(8) },
+	[RST_A64_BUS_HDMI0]		=  { 0x2c4, BIT(10) },
+	[RST_A64_BUS_HDMI1]		=  { 0x2c4, BIT(11) },
+	[RST_A64_BUS_DE]		=  { 0x2c4, BIT(12) },
+	[RST_A64_BUS_GPU]		=  { 0x2c4, BIT(20) },
+	[RST_A64_BUS_MSGBOX]		=  { 0x2c4, BIT(21) },
+	[RST_A64_BUS_SPINLOCK]		=  { 0x2c4, BIT(22) },
+	[RST_A64_BUS_DBG]		=  { 0x2c4, BIT(31) },
+
+	[RST_A64_BUS_LVDS]		=  { 0x2c8, BIT(0) },
+
+	[RST_A64_BUS_CODEC]		=  { 0x2d0, BIT(0) },
+	[RST_A64_BUS_SPDIF]		=  { 0x2d0, BIT(1) },
+	[RST_A64_BUS_THS]		=  { 0x2d0, BIT(8) },
+	[RST_A64_BUS_I2S0]		=  { 0x2d0, BIT(12) },
+	[RST_A64_BUS_I2S1]		=  { 0x2d0, BIT(13) },
+	[RST_A64_BUS_I2S2]		=  { 0x2d0, BIT(14) },
+
+	[RST_A64_BUS_I2C0]		=  { 0x2d4, BIT(0) },
+	[RST_A64_BUS_I2C1]		=  { 0x2d4, BIT(1) },
+	[RST_A64_BUS_I2C2]		=  { 0x2d4, BIT(2) },
+	[RST_A64_BUS_SCR]		=  { 0x2d4, BIT(5) },
+	[RST_A64_BUS_UART0]		=  { 0x2d4, BIT(16) },
+	[RST_A64_BUS_UART1]		=  { 0x2d4, BIT(17) },
+	[RST_A64_BUS_UART2]		=  { 0x2d4, BIT(18) },
+	[RST_A64_BUS_UART3]		=  { 0x2d4, BIT(19) },
+	[RST_A64_BUS_UART4]		=  { 0x2d4, BIT(20) },
+};
+
+static const struct sunxi_ccu_desc sun50i_a64_ccu_desc = {
+	.ccu_clks	= sun50i_a64_ccu_clks,
+	.num_ccu_clks	= ARRAY_SIZE(sun50i_a64_ccu_clks),
+
+	.hw_clks	= &sun50i_a64_hw_clks,
+
+	.resets		= sun50i_a64_ccu_resets,
+	.num_resets	= ARRAY_SIZE(sun50i_a64_ccu_resets),
+};
+
+static void __init sun50i_a64_ccu_setup(struct device_node *node)
+{
+	void __iomem *reg;
+	u32 val;
+
+	reg = of_io_request_and_map(node, 0, of_node_full_name(node));
+	if (IS_ERR(reg)) {
+		pr_err("%s: Could not map the clock registers\n",
+		       of_node_full_name(node));
+		return;
+	}
+
+	/* Force the PLL-Audio-1x divider to 4 */
+	val = readl(reg + SUN8I_H3_PLL_AUDIO_REG);
+	val &= ~GENMASK(19, 16);
+	writel(val | (3 << 16), reg + SUN8I_H3_PLL_AUDIO_REG);
+
+	writel(0x515, reg + SUN50I_A64_PLL_MIPI_REG);
+
+	sunxi_ccu_probe(node, reg, &sun50i_a64_ccu_desc);
+}
+CLK_OF_DECLARE(sun50i_a64_ccu, "allwinner,sun50i-a64-ccu",
+	       sun50i_a64_ccu_setup);
diff --git a/include/dt-bindings/clock/sun50i-a64-ccu.h b/include/dt-bindings/clock/sun50i-a64-ccu.h
new file mode 100644
index 000000000000..192fafc4b443
--- /dev/null
+++ b/include/dt-bindings/clock/sun50i-a64-ccu.h
@@ -0,0 +1,132 @@
+/*
+ * Copyright (C) 2016 Maxime Ripard <maxime.ripard@free-electrons.com>
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ *     modify it under the terms of the GNU General Public License as
+ *     published by the Free Software Foundation; either version 2 of the
+ *     License, or (at your option) any later version.
+ *
+ *     This file is distributed in the hope that it will be useful,
+ *     but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *     GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ *     obtaining a copy of this software and associated documentation
+ *     files (the "Software"), to deal in the Software without
+ *     restriction, including without limitation the rights to use,
+ *     copy, modify, merge, publish, distribute, sublicense, and/or
+ *     sell copies of the Software, and to permit persons to whom the
+ *     Software is furnished to do so, subject to the following
+ *     conditions:
+ *
+ *     The above copyright notice and this permission notice shall be
+ *     included in all copies or substantial portions of the Software.
+ *
+ *     THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ *     OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+#ifndef _DT_BINDINGS_CLK_SUN50I_A64_H_
+#define _DT_BINDINGS_CLK_SUN50I_A64_H_
+
+#define CLK_A64_BUS_MIPI_DSI		28
+#define CLK_A64_BUS_CE			29
+#define CLK_A64_BUS_DMA			30
+#define CLK_A64_BUS_MMC0		31
+#define CLK_A64_BUS_MMC1		32
+#define CLK_A64_BUS_MMC2		33
+#define CLK_A64_BUS_NAND		34
+#define CLK_A64_BUS_DRAM		35
+#define CLK_A64_BUS_EMAC		36
+#define CLK_A64_BUS_TS			37
+#define CLK_A64_BUS_HSTIMER		38
+#define CLK_A64_BUS_SPI0		39
+#define CLK_A64_BUS_SPI1		40
+#define CLK_A64_BUS_OTG			41
+#define CLK_A64_BUS_EHCI0		42
+#define CLK_A64_BUS_EHCI1		43
+#define CLK_A64_BUS_OHCI0		44
+#define CLK_A64_BUS_OHCI1		45
+#define CLK_A64_BUS_VE			46
+#define CLK_A64_BUS_TCON0		47
+#define CLK_A64_BUS_TCON1		48
+#define CLK_A64_BUS_DEINTERLACE		49
+#define CLK_A64_BUS_CSI			50
+#define CLK_A64_BUS_HDMI		51
+#define CLK_A64_BUS_DE			52
+#define CLK_A64_BUS_GPU			53
+#define CLK_A64_BUS_MSGBOX		54
+#define CLK_A64_BUS_SPINLOCK		55
+#define CLK_A64_BUS_CODEC		56
+#define CLK_A64_BUS_SPDIF		57
+#define CLK_A64_BUS_PIO			58
+#define CLK_A64_BUS_THS			59
+#define CLK_A64_BUS_I2S0		60
+#define CLK_A64_BUS_I2S1		61
+#define CLK_A64_BUS_I2S2		62
+#define CLK_A64_BUS_I2C0		63
+#define CLK_A64_BUS_I2C1		64
+#define CLK_A64_BUS_I2C2		65
+#define CLK_A64_BUS_SCR			66
+#define CLK_A64_BUS_UART0		67
+#define CLK_A64_BUS_UART1		68
+#define CLK_A64_BUS_UART2		69
+#define CLK_A64_BUS_UART3		70
+#define CLK_A64_BUS_UART4		71
+#define CLK_A64_BUS_DBG			72
+#define CLK_A64_THS			73
+#define CLK_A64_NAND			74
+#define CLK_A64_MMC0			75
+#define CLK_A64_MMC1			76
+#define CLK_A64_MMC2			77
+#define CLK_A64_TS			78
+#define CLK_A64_CE			79
+#define CLK_A64_SPI0			80
+#define CLK_A64_SPI1			81
+#define CLK_A64_I2S0			82
+#define CLK_A64_I2S1			83
+#define CLK_A64_I2S2			84
+#define CLK_A64_SPDIF			85
+#define CLK_A64_USB_PHY0		86
+#define CLK_A64_USB_PHY1		87
+#define CLK_A64_USB_HSIC		88
+#define CLK_A64_USB_HSIC_12M		89
+#define CLK_A64_USB_OHCI0		90
+#define CLK_A64_USB_OHCI1		91
+
+#define CLK_A64_DRAM_VE			93
+#define CLK_A64_DRAM_CSI		94
+#define CLK_A64_DRAM_DEINTERLACE	95
+#define CLK_A64_DRAM_TS			96
+#define CLK_A64_DE			97
+#define CLK_A64_TCON0			98
+#define CLK_A64_TCON1			99
+#define CLK_A64_DEINTERLACE		100
+#define CLK_A64_CSI_MISC		101
+#define CLK_A64_CSI_SCLK		102
+#define CLK_A64_CSI_MCLK		103
+#define CLK_A64_VE			104
+#define CLK_A64_AC_DIG			105
+#define CLK_A64_AC_DIG_4X		106
+#define CLK_A64_AVS			107
+#define CLK_A64_HDMI			108
+#define CLK_A64_HDMI_DDC		109
+
+#define CLK_A64_DSI_DPHY		111
+#define CLK_A64_GPU			112
+
+#endif /* _DT_BINDINGS_CLK_SUN50I_A64_H_ */
diff --git a/include/dt-bindings/reset/sun50i-a64-ccu.h b/include/dt-bindings/reset/sun50i-a64-ccu.h
new file mode 100644
index 000000000000..bf5932a7725c
--- /dev/null
+++ b/include/dt-bindings/reset/sun50i-a64-ccu.h
@@ -0,0 +1,97 @@
+/*
+ * Copyright (C) 2016 Maxime Ripard <maxime.ripard@free-electrons.com>
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ *     modify it under the terms of the GNU General Public License as
+ *     published by the Free Software Foundation; either version 2 of the
+ *     License, or (at your option) any later version.
+ *
+ *     This file is distributed in the hope that it will be useful,
+ *     but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *     GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ *     obtaining a copy of this software and associated documentation
+ *     files (the "Software"), to deal in the Software without
+ *     restriction, including without limitation the rights to use,
+ *     copy, modify, merge, publish, distribute, sublicense, and/or
+ *     sell copies of the Software, and to permit persons to whom the
+ *     Software is furnished to do so, subject to the following
+ *     conditions:
+ *
+ *     The above copyright notice and this permission notice shall be
+ *     included in all copies or substantial portions of the Software.
+ *
+ *     THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ *     OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+#ifndef _DT_BINDINGS_RST_SUN50I_A64_H_
+#define _DT_BINDINGS_RST_SUN50I_A64_H_
+
+#define RST_A64_USB_PHY0		0
+#define RST_A64_USB_PHY1		1
+#define RST_A64_USB_HSIC		2
+#define RST_A64_MBUS			3
+#define RST_A64_BUS_MIPI_DSI		4
+#define RST_A64_BUS_CE			5
+#define RST_A64_BUS_DMA			6
+#define RST_A64_BUS_MMC0		7
+#define RST_A64_BUS_MMC1		8
+#define RST_A64_BUS_MMC2		9
+#define RST_A64_BUS_NAND		10
+#define RST_A64_BUS_DRAM		11
+#define RST_A64_BUS_EMAC		12
+#define RST_A64_BUS_TS			13
+#define RST_A64_BUS_HSTIMER		14
+#define RST_A64_BUS_SPI0		15
+#define RST_A64_BUS_SPI1		16
+#define RST_A64_BUS_OTG			17
+#define RST_A64_BUS_EHCI0		18
+#define RST_A64_BUS_EHCI1		19
+#define RST_A64_BUS_OHCI0		20
+#define RST_A64_BUS_OHCI1		21
+#define RST_A64_BUS_VE			22
+#define RST_A64_BUS_TCON0		23
+#define RST_A64_BUS_TCON1		24
+#define RST_A64_BUS_DEINTERLACE		25
+#define RST_A64_BUS_CSI			26
+#define RST_A64_BUS_HDMI0		27
+#define RST_A64_BUS_HDMI1		28
+#define RST_A64_BUS_DE			29
+#define RST_A64_BUS_GPU			30
+#define RST_A64_BUS_MSGBOX		31
+#define RST_A64_BUS_SPINLOCK		32
+#define RST_A64_BUS_DBG			33
+#define RST_A64_BUS_LVDS		34
+#define RST_A64_BUS_CODEC		35
+#define RST_A64_BUS_SPDIF		36
+#define RST_A64_BUS_THS			37
+#define RST_A64_BUS_I2S0		38
+#define RST_A64_BUS_I2S1		39
+#define RST_A64_BUS_I2S2		40
+#define RST_A64_BUS_I2C0		41
+#define RST_A64_BUS_I2C1		42
+#define RST_A64_BUS_I2C2		43
+#define RST_A64_BUS_SCR			44
+#define RST_A64_BUS_UART0		45
+#define RST_A64_BUS_UART1		46
+#define RST_A64_BUS_UART2		47
+#define RST_A64_BUS_UART3		48
+#define RST_A64_BUS_UART4		49
+
+#endif /* _DT_BINDINGS_RST_SUN8I_H3_H_ */
-- 
2.9.2

^ permalink raw reply related	[flat|nested] 34+ messages in thread

* Re: [PATCH 08/13] clk: sunxi-ng: Add A64 clocks
  2016-07-26 20:30 ` [PATCH 08/13] clk: sunxi-ng: Add A64 clocks Maxime Ripard
@ 2016-07-29 21:15   ` Rob Herring
  0 siblings, 0 replies; 34+ messages in thread
From: Rob Herring @ 2016-07-29 21:15 UTC (permalink / raw)
  To: Maxime Ripard
  Cc: Chen-Yu Tsai, Mike Turquette, Stephen Boyd, devicetree,
	Andre Przywara, linux-arm-kernel, linux-kernel, linux-clk

On Tue, Jul 26, 2016 at 10:30:36PM +0200, Maxime Ripard wrote:
> Add the A64 CCU clocks set.
> 
> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> ---
>  .../devicetree/bindings/clock/sunxi-ccu.txt        |   1 +

Acked-by: Rob Herring <robh@kernel.org>

>  drivers/clk/sunxi-ng/Kconfig                       |  13 +-
>  drivers/clk/sunxi-ng/Makefile                      |   2 +-
>  drivers/clk/sunxi-ng/ccu-sun50i-a64.h              |  68 +++
>  drivers/clk/sunxi-ng/ccu-sun8i-h3.c                | 483 +++++++++++++++++++++
>  include/dt-bindings/clock/sun50i-a64-ccu.h         | 132 ++++++
>  include/dt-bindings/reset/sun50i-a64-ccu.h         |  97 +++++
>  7 files changed, 793 insertions(+), 3 deletions(-)
>  create mode 100644 drivers/clk/sunxi-ng/ccu-sun50i-a64.h
>  create mode 100644 include/dt-bindings/clock/sun50i-a64-ccu.h
>  create mode 100644 include/dt-bindings/reset/sun50i-a64-ccu.h

^ permalink raw reply	[flat|nested] 34+ messages in thread

* [PATCH 09/13] arm64: sunxi: Kconfig: add essential pinctrl driver
  2016-07-26 20:30 [PATCH 00/13] arm64: Allwinner A64 support based on sunxi-ng Maxime Ripard
                   ` (7 preceding siblings ...)
  2016-07-26 20:30 ` [PATCH 08/13] clk: sunxi-ng: Add A64 clocks Maxime Ripard
@ 2016-07-26 20:30 ` Maxime Ripard
  2016-07-26 20:30 ` [PATCH 10/13] arm64: Kconfig: sunxi: add PINCTRL Maxime Ripard
                   ` (5 subsequent siblings)
  14 siblings, 0 replies; 34+ messages in thread
From: Maxime Ripard @ 2016-07-26 20:30 UTC (permalink / raw)
  To: Rob Herring, Chen-Yu Tsai, Mike Turquette, Stephen Boyd
  Cc: devicetree, Andre Przywara, linux-arm-kernel, linux-kernel,
	linux-clk, Maxime Ripard

From: Andre Przywara <andre.przywara@arm.com>

The pinctrl driver is essential for the Allwinner SoCs to work.
Add the driver's config symbol to the Kconfig entry to always compile
it in. We can't use the arm approach to make the _driver's_ Kconfig
symbol def_bool, because we lack the MACH_* symbols in arm64.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
---
 arch/arm64/Kconfig.platforms | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
index 7ef1d05859ae..4cc444c3c2e9 100644
--- a/arch/arm64/Kconfig.platforms
+++ b/arch/arm64/Kconfig.platforms
@@ -3,6 +3,7 @@ menu "Platform selection"
 config ARCH_SUNXI
 	bool "Allwinner sunxi 64-bit SoC Family"
 	select GENERIC_IRQ_CHIP
+	select PINCTRL_SUN50I_A64
 	help
 	  This enables support for Allwinner sunxi based SoCs like the A64.
 
-- 
2.9.2

^ permalink raw reply related	[flat|nested] 34+ messages in thread

* [PATCH 10/13] arm64: Kconfig: sunxi: add PINCTRL
  2016-07-26 20:30 [PATCH 00/13] arm64: Allwinner A64 support based on sunxi-ng Maxime Ripard
                   ` (8 preceding siblings ...)
  2016-07-26 20:30 ` [PATCH 09/13] arm64: sunxi: Kconfig: add essential pinctrl driver Maxime Ripard
@ 2016-07-26 20:30 ` Maxime Ripard
  2016-07-26 20:30 ` [PATCH 11/13] Documentation: devicetree: add vendor prefix for Pine64 Maxime Ripard
                   ` (4 subsequent siblings)
  14 siblings, 0 replies; 34+ messages in thread
From: Maxime Ripard @ 2016-07-26 20:30 UTC (permalink / raw)
  To: Rob Herring, Chen-Yu Tsai, Mike Turquette, Stephen Boyd
  Cc: devicetree, Andre Przywara, linux-arm-kernel, linux-kernel,
	linux-clk, Maxime Ripard

From: Andre Przywara <andre.przywara@arm.com>

Add required PINCTRL symbol to cover non-defconfig setups.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
---
 arch/arm64/Kconfig.platforms | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
index 4cc444c3c2e9..83bc4bf3513b 100644
--- a/arch/arm64/Kconfig.platforms
+++ b/arch/arm64/Kconfig.platforms
@@ -3,6 +3,7 @@ menu "Platform selection"
 config ARCH_SUNXI
 	bool "Allwinner sunxi 64-bit SoC Family"
 	select GENERIC_IRQ_CHIP
+	select PINCTRL
 	select PINCTRL_SUN50I_A64
 	help
 	  This enables support for Allwinner sunxi based SoCs like the A64.
-- 
2.9.2

^ permalink raw reply related	[flat|nested] 34+ messages in thread

* [PATCH 11/13] Documentation: devicetree: add vendor prefix for Pine64
  2016-07-26 20:30 [PATCH 00/13] arm64: Allwinner A64 support based on sunxi-ng Maxime Ripard
                   ` (9 preceding siblings ...)
  2016-07-26 20:30 ` [PATCH 10/13] arm64: Kconfig: sunxi: add PINCTRL Maxime Ripard
@ 2016-07-26 20:30 ` Maxime Ripard
  2016-07-26 20:30 ` [PATCH 12/13] arm64: dts: add Allwinner A64 SoC .dtsi Maxime Ripard
                   ` (3 subsequent siblings)
  14 siblings, 0 replies; 34+ messages in thread
From: Maxime Ripard @ 2016-07-26 20:30 UTC (permalink / raw)
  To: Rob Herring, Chen-Yu Tsai, Mike Turquette, Stephen Boyd
  Cc: devicetree, Andre Przywara, linux-arm-kernel, linux-kernel,
	linux-clk, Maxime Ripard

From: Andre Przywara <andre.przywara@arm.com>

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Acked-by: Rob Herring <robh@kernel.org>
[Maxime: Change title prefix to match the usual style]
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
---
 Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
index a7440bcd67ff..f25502b28b55 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -198,6 +198,7 @@ parade	Parade Technologies Inc.
 pericom	Pericom Technology Inc.
 phytec	PHYTEC Messtechnik GmbH
 picochip	Picochip Ltd
+pine64	Pine64
 plathome	Plat'Home Co., Ltd.
 plda	PLDA
 pixcir  PIXCIR MICROELECTRONICS Co., Ltd
-- 
2.9.2

^ permalink raw reply related	[flat|nested] 34+ messages in thread

* [PATCH 12/13] arm64: dts: add Allwinner A64 SoC .dtsi
  2016-07-26 20:30 [PATCH 00/13] arm64: Allwinner A64 support based on sunxi-ng Maxime Ripard
                   ` (10 preceding siblings ...)
  2016-07-26 20:30 ` [PATCH 11/13] Documentation: devicetree: add vendor prefix for Pine64 Maxime Ripard
@ 2016-07-26 20:30 ` Maxime Ripard
  2016-09-08  8:41   ` Andre Przywara
  2016-07-26 20:30 ` [PATCH 13/13] arm64: dts: add Pine64 support Maxime Ripard
                   ` (2 subsequent siblings)
  14 siblings, 1 reply; 34+ messages in thread
From: Maxime Ripard @ 2016-07-26 20:30 UTC (permalink / raw)
  To: Rob Herring, Chen-Yu Tsai, Mike Turquette, Stephen Boyd
  Cc: devicetree, Andre Przywara, linux-arm-kernel, linux-kernel,
	linux-clk, Maxime Ripard

From: Andre Przywara <andre.przywara@arm.com>

The Allwinner A64 SoC is a low-cost chip with 4 ARM Cortex-A53 cores
and the typical tablet / TV box peripherals.
The SoC is based on the (32-bit) Allwinner H3 chip, sharing most of
the peripherals and the memory map.
Although the cores are proper 64-bit ones, the whole SoC is actually
limited to 4GB (including all the supported DRAM), so we use 32-bit
address and size cells. This has the nice feature of us being able to
reuse the DT for 32-bit kernels as well.
This .dtsi lists the hardware that we support so far.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Acked-by: Rob Herring <robh@kernel.org>
[Maxime: Convert to CCU binding, drop the MMC support for now]
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
---
 Documentation/devicetree/bindings/arm/sunxi.txt |   1 +
 MAINTAINERS                                     |   1 +
 arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi   | 273 ++++++++++++++++++++++++
 3 files changed, 275 insertions(+)
 create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi

diff --git a/Documentation/devicetree/bindings/arm/sunxi.txt b/Documentation/devicetree/bindings/arm/sunxi.txt
index 7e79fcc36b0d..7e59d8ba86af 100644
--- a/Documentation/devicetree/bindings/arm/sunxi.txt
+++ b/Documentation/devicetree/bindings/arm/sunxi.txt
@@ -14,3 +14,4 @@ using one of the following compatible strings:
   allwinner,sun8i-a83t
   allwinner,sun8i-h3
   allwinner,sun9i-a80
+  allwinner,sun50i-a64
diff --git a/MAINTAINERS b/MAINTAINERS
index 7304d2e37a98..440490126bfb 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -955,6 +955,7 @@ M:	Chen-Yu Tsai <wens@csie.org>
 L:	linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
 S:	Maintained
 N:	sun[x456789]i
+F:	arch/arm64/boot/dts/allwinner/
 
 ARM/Allwinner SoC Clock Support
 M:	Emilio López <emilio@elopez.com.ar>
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
new file mode 100644
index 000000000000..636165d75373
--- /dev/null
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
@@ -0,0 +1,273 @@
+/*
+ * Copyright (C) 2016 ARM Ltd.
+ * based on the Allwinner H3 dtsi:
+ *    Copyright (C) 2015 Jens Kuske <jenskuske@gmail.com>
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ *     modify it under the terms of the GNU General Public License as
+ *     published by the Free Software Foundation; either version 2 of the
+ *     License, or (at your option) any later version.
+ *
+ *     This file is distributed in the hope that it will be useful,
+ *     but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *     GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ *     obtaining a copy of this software and associated documentation
+ *     files (the "Software"), to deal in the Software without
+ *     restriction, including without limitation the rights to use,
+ *     copy, modify, merge, publish, distribute, sublicense, and/or
+ *     sell copies of the Software, and to permit persons to whom the
+ *     Software is furnished to do so, subject to the following
+ *     conditions:
+ *
+ *     The above copyright notice and this permission notice shall be
+ *     included in all copies or substantial portions of the Software.
+ *
+ *     THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ *     OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+#include <dt-bindings/clock/sun50i-a64-ccu.h>
+#include <dt-bindings/interrupt-controller/arm-gic.h>
+#include <dt-bindings/pinctrl/sun4i-a10.h>
+#include <dt-bindings/reset/sun50i-a64-ccu.h>
+
+/ {
+	interrupt-parent = <&gic>;
+	#address-cells = <1>;
+	#size-cells = <1>;
+
+	cpus {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		cpu@0 {
+			compatible = "arm,cortex-a53", "arm,armv8";
+			device_type = "cpu";
+			reg = <0>;
+			enable-method = "psci";
+		};
+
+		cpu@1 {
+			compatible = "arm,cortex-a53", "arm,armv8";
+			device_type = "cpu";
+			reg = <1>;
+			enable-method = "psci";
+		};
+
+		cpu@2 {
+			compatible = "arm,cortex-a53", "arm,armv8";
+			device_type = "cpu";
+			reg = <2>;
+			enable-method = "psci";
+		};
+
+		cpu@3 {
+			compatible = "arm,cortex-a53", "arm,armv8";
+			device_type = "cpu";
+			reg = <3>;
+			enable-method = "psci";
+		};
+	};
+
+	psci {
+		compatible = "arm,psci-0.2";
+		method = "smc";
+	};
+
+	timer {
+		compatible = "arm,armv8-timer";
+		interrupts = <GIC_PPI 13
+			(GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>,
+			     <GIC_PPI 14
+			(GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>,
+			     <GIC_PPI 11
+			(GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>,
+			     <GIC_PPI 10
+			(GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>;
+	};
+
+	clocks {
+		#address-cells = <1>;
+		#size-cells = <1>;
+		ranges;
+
+		osc24M: osc24M_clk {
+			#clock-cells = <0>;
+			compatible = "fixed-clock";
+			clock-frequency = <24000000>;
+			clock-output-names = "osc24M";
+		};
+
+		osc32k: osc32k_clk {
+			#clock-cells = <0>;
+			compatible = "fixed-clock";
+			clock-frequency = <32768>;
+			clock-output-names = "osc32k";
+		};
+	};
+
+	soc {
+		compatible = "simple-bus";
+		#address-cells = <1>;
+		#size-cells = <1>;
+		ranges;
+
+		ccu: clock@01c20000 {
+			compatible = "allwinner,sun50i-a64-ccu";
+			reg = <0x01c20000 0x400>;
+			clocks = <&osc24M>, <&osc32k>;
+			clock-names = "hosc", "losc";
+			#clock-cells = <1>;
+			#reset-cells = <1>;
+		};
+
+		pio: pinctrl@1c20800 {
+			compatible = "allwinner,sun50i-a64-pinctrl";
+			reg = <0x01c20800 0x400>;
+			interrupts = <GIC_SPI 11 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 17 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 21 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&ccu CLK_A64_BUS_PIO>;
+			gpio-controller;
+			#gpio-cells = <3>;
+			interrupt-controller;
+			#interrupt-cells = <2>;
+
+			i2c1_pins: i2c1_pins {
+				allwinner,pins = "PH2", "PH3";
+				allwinner,function = "i2c1";
+				allwinner,drive = <SUN4I_PINCTRL_10_MA>;
+				allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
+			};
+
+			uart0_pins_a: uart0@0 {
+				allwinner,pins = "PB8", "PB9";
+				allwinner,function = "uart0";
+				allwinner,drive = <SUN4I_PINCTRL_10_MA>;
+				allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
+			};
+		};
+
+		uart0: serial@1c28000 {
+			compatible = "snps,dw-apb-uart";
+			reg = <0x01c28000 0x400>;
+			interrupts = <GIC_SPI 0 IRQ_TYPE_LEVEL_HIGH>;
+			reg-shift = <2>;
+			reg-io-width = <4>;
+			clocks = <&ccu CLK_A64_BUS_UART0>;
+			resets = <&ccu RST_A64_BUS_UART0>;
+			status = "disabled";
+		};
+
+		uart1: serial@1c28400 {
+			compatible = "snps,dw-apb-uart";
+			reg = <0x01c28400 0x400>;
+			interrupts = <GIC_SPI 1 IRQ_TYPE_LEVEL_HIGH>;
+			reg-shift = <2>;
+			reg-io-width = <4>;
+			clocks = <&ccu CLK_A64_BUS_UART1>;
+			resets = <&ccu RST_A64_BUS_UART1>;
+			status = "disabled";
+		};
+
+		uart2: serial@1c28800 {
+			compatible = "snps,dw-apb-uart";
+			reg = <0x01c28800 0x400>;
+			interrupts = <GIC_SPI 2 IRQ_TYPE_LEVEL_HIGH>;
+			reg-shift = <2>;
+			reg-io-width = <4>;
+			clocks = <&ccu CLK_A64_BUS_UART2>;
+			resets = <&ccu RST_A64_BUS_UART2>;
+			status = "disabled";
+		};
+
+		uart3: serial@1c28c00 {
+			compatible = "snps,dw-apb-uart";
+			reg = <0x01c28c00 0x400>;
+			interrupts = <GIC_SPI 3 IRQ_TYPE_LEVEL_HIGH>;
+			reg-shift = <2>;
+			reg-io-width = <4>;
+			clocks = <&ccu CLK_A64_BUS_UART3>;
+			resets = <&ccu RST_A64_BUS_UART3>;
+			status = "disabled";
+		};
+
+		uart4: serial@1c29000 {
+			compatible = "snps,dw-apb-uart";
+			reg = <0x01c29000 0x400>;
+			interrupts = <GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH>;
+			reg-shift = <2>;
+			reg-io-width = <4>;
+			clocks = <&ccu CLK_A64_BUS_UART4>;
+			resets = <&ccu RST_A64_BUS_UART4>;
+			status = "disabled";
+		};
+
+		rtc: rtc@1f00000 {
+			compatible = "allwinner,sun6i-a31-rtc";
+			reg = <0x01f00000 0x54>;
+			interrupts = <GIC_SPI 40 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 41 IRQ_TYPE_LEVEL_HIGH>;
+		};
+
+		i2c0: i2c@1c2ac00 {
+			compatible = "allwinner,sun6i-a31-i2c";
+			reg = <0x01c2ac00 0x400>;
+			interrupts = <GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&ccu CLK_A64_BUS_I2C0>;
+			resets = <&ccu RST_A64_BUS_I2C0>;
+			status = "disabled";
+			#address-cells = <1>;
+			#size-cells = <0>;
+		};
+
+		i2c1: i2c@1c2b000 {
+			compatible = "allwinner,sun6i-a31-i2c";
+			reg = <0x01c2b000 0x400>;
+			interrupts = <GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&ccu CLK_A64_BUS_I2C1>;
+			resets = <&ccu RST_A64_BUS_I2C1>;
+			status = "disabled";
+			#address-cells = <1>;
+			#size-cells = <0>;
+		};
+
+		i2c2: i2c@1c2b400 {
+			compatible = "allwinner,sun6i-a31-i2c";
+			reg = <0x01c2b400 0x400>;
+			interrupts = <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&ccu CLK_A64_BUS_I2C2>;
+			resets = <&ccu RST_A64_BUS_I2C2>;
+			status = "disabled";
+			#address-cells = <1>;
+			#size-cells = <0>;
+		};
+
+		gic: interrupt-controller@1c81000 {
+			compatible = "arm,gic-400";
+			reg = <0x01c81000 0x1000>,
+			      <0x01c82000 0x2000>,
+			      <0x01c84000 0x2000>,
+			      <0x01c86000 0x2000>;
+			interrupts = <GIC_PPI 9 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>;
+			interrupt-controller;
+			#interrupt-cells = <3>;
+		};
+	};
+};
-- 
2.9.2

^ permalink raw reply related	[flat|nested] 34+ messages in thread

* Re: [PATCH 12/13] arm64: dts: add Allwinner A64 SoC .dtsi
  2016-07-26 20:30 ` [PATCH 12/13] arm64: dts: add Allwinner A64 SoC .dtsi Maxime Ripard
@ 2016-09-08  8:41   ` Andre Przywara
  2016-09-09 20:04     ` Maxime Ripard
  0 siblings, 1 reply; 34+ messages in thread
From: Andre Przywara @ 2016-09-08  8:41 UTC (permalink / raw)
  To: Maxime Ripard, Rob Herring, Chen-Yu Tsai, Mike Turquette, Stephen Boyd
  Cc: devicetree, linux-arm-kernel, linux-kernel, linux-clk

Hi Maxime,

On 26/07/16 21:30, Maxime Ripard wrote:
> From: Andre Przywara <andre.przywara@arm.com>
> 
> The Allwinner A64 SoC is a low-cost chip with 4 ARM Cortex-A53 cores
> and the typical tablet / TV box peripherals.
> The SoC is based on the (32-bit) Allwinner H3 chip, sharing most of
> the peripherals and the memory map.
> Although the cores are proper 64-bit ones, the whole SoC is actually
> limited to 4GB (including all the supported DRAM), so we use 32-bit
> address and size cells. This has the nice feature of us being able to
> reuse the DT for 32-bit kernels as well.
> This .dtsi lists the hardware that we support so far.
> 
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> Acked-by: Rob Herring <robh@kernel.org>
> [Maxime: Convert to CCU binding, drop the MMC support for now]
> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> ---
>  Documentation/devicetree/bindings/arm/sunxi.txt |   1 +
>  MAINTAINERS                                     |   1 +
>  arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi   | 273 ++++++++++++++++++++++++
>  3 files changed, 275 insertions(+)
>  create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> 
> diff --git a/Documentation/devicetree/bindings/arm/sunxi.txt b/Documentation/devicetree/bindings/arm/sunxi.txt
> index 7e79fcc36b0d..7e59d8ba86af 100644
> --- a/Documentation/devicetree/bindings/arm/sunxi.txt
> +++ b/Documentation/devicetree/bindings/arm/sunxi.txt
> @@ -14,3 +14,4 @@ using one of the following compatible strings:
>    allwinner,sun8i-a83t
>    allwinner,sun8i-h3
>    allwinner,sun9i-a80
> +  allwinner,sun50i-a64
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 7304d2e37a98..440490126bfb 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -955,6 +955,7 @@ M:	Chen-Yu Tsai <wens@csie.org>
>  L:	linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
>  S:	Maintained
>  N:	sun[x456789]i
> +F:	arch/arm64/boot/dts/allwinner/
>  
>  ARM/Allwinner SoC Clock Support
>  M:	Emilio López <emilio@elopez.com.ar>
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> new file mode 100644
> index 000000000000..636165d75373
> --- /dev/null
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> @@ -0,0 +1,273 @@
> +/*
> + * Copyright (C) 2016 ARM Ltd.
> + * based on the Allwinner H3 dtsi:
> + *    Copyright (C) 2015 Jens Kuske <jenskuske@gmail.com>
> + *
> + * This file is dual-licensed: you can use it either under the terms
> + * of the GPL or the X11 license, at your option. Note that this dual
> + * licensing only applies to this file, and not this project as a
> + * whole.
> + *
> + *  a) This file is free software; you can redistribute it and/or
> + *     modify it under the terms of the GNU General Public License as
> + *     published by the Free Software Foundation; either version 2 of the
> + *     License, or (at your option) any later version.
> + *
> + *     This file is distributed in the hope that it will be useful,
> + *     but WITHOUT ANY WARRANTY; without even the implied warranty of
> + *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + *     GNU General Public License for more details.
> + *
> + * Or, alternatively,
> + *
> + *  b) Permission is hereby granted, free of charge, to any person
> + *     obtaining a copy of this software and associated documentation
> + *     files (the "Software"), to deal in the Software without
> + *     restriction, including without limitation the rights to use,
> + *     copy, modify, merge, publish, distribute, sublicense, and/or
> + *     sell copies of the Software, and to permit persons to whom the
> + *     Software is furnished to do so, subject to the following
> + *     conditions:
> + *
> + *     The above copyright notice and this permission notice shall be
> + *     included in all copies or substantial portions of the Software.
> + *
> + *     THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> + *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> + *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> + *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> + *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
> + *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + *     OTHER DEALINGS IN THE SOFTWARE.
> + */
> +
> +#include <dt-bindings/clock/sun50i-a64-ccu.h>
> +#include <dt-bindings/interrupt-controller/arm-gic.h>
> +#include <dt-bindings/pinctrl/sun4i-a10.h>
> +#include <dt-bindings/reset/sun50i-a64-ccu.h>
> +
> +/ {
> +	interrupt-parent = <&gic>;
> +	#address-cells = <1>;
> +	#size-cells = <1>;
> +
> +	cpus {
> +		#address-cells = <1>;
> +		#size-cells = <0>;
> +
> +		cpu@0 {
> +			compatible = "arm,cortex-a53", "arm,armv8";
> +			device_type = "cpu";
> +			reg = <0>;
> +			enable-method = "psci";
> +		};
> +
> +		cpu@1 {
> +			compatible = "arm,cortex-a53", "arm,armv8";
> +			device_type = "cpu";
> +			reg = <1>;
> +			enable-method = "psci";
> +		};
> +
> +		cpu@2 {
> +			compatible = "arm,cortex-a53", "arm,armv8";
> +			device_type = "cpu";
> +			reg = <2>;
> +			enable-method = "psci";
> +		};
> +
> +		cpu@3 {
> +			compatible = "arm,cortex-a53", "arm,armv8";
> +			device_type = "cpu";
> +			reg = <3>;
> +			enable-method = "psci";
> +		};
> +	};
> +
> +	psci {
> +		compatible = "arm,psci-0.2";
> +		method = "smc";
> +	};
> +
> +	timer {
> +		compatible = "arm,armv8-timer";
> +		interrupts = <GIC_PPI 13
> +			(GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>,
> +			     <GIC_PPI 14
> +			(GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>,
> +			     <GIC_PPI 11
> +			(GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>,
> +			     <GIC_PPI 10
> +			(GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>;
> +	};

Can you add a PMU node here? Or shall I send a patch on top of it?
It would be:

	pmu {
        	compatible = "arm,cortex-a53-pmu", "arm,armv8-pmuv3";
		interrupts = <GIC_SPI 120 IRQ_TYPE_LEVEL_HIGH>,
			     <GIC_SPI 121 IRQ_TYPE_LEVEL_HIGH>,	
			     <GIC_SPI 122 IRQ_TYPE_LEVEL_HIGH>,
			     <GIC_SPI 123 IRQ_TYPE_LEVEL_HIGH>;
		interrupt-affinity = <&cpu0>,
				     <&cpu1>,
				     <&cpu2>,
				     <&cpu3>;
	};

This enables perf to use hardware counters (for cycles and instructions,
for instance).

> +
> +	clocks {
> +		#address-cells = <1>;
> +		#size-cells = <1>;
> +		ranges;
> +
> +		osc24M: osc24M_clk {
> +			#clock-cells = <0>;
> +			compatible = "fixed-clock";
> +			clock-frequency = <24000000>;
> +			clock-output-names = "osc24M";
> +		};
> +
> +		osc32k: osc32k_clk {
> +			#clock-cells = <0>;
> +			compatible = "fixed-clock";
> +			clock-frequency = <32768>;
> +			clock-output-names = "osc32k";
> +		};
> +	};

Can you remove this "clocks" node and put the two subnodes directly onto
the top level?
I know that putting clocks into a subnode is quite wide spread, but it
does not represent any hardware hierarchy, especially in this
fixed-clock case.
So if we can (and it is easy here!) we should avoid any clocks subnode.

(Yes, I know that this was in my original DT as well, but Mark Rutland
convinced me of this.)

Cheers,
Andre.

> +
> +	soc {
> +		compatible = "simple-bus";
> +		#address-cells = <1>;
> +		#size-cells = <1>;
> +		ranges;
> +
> +		ccu: clock@01c20000 {
> +			compatible = "allwinner,sun50i-a64-ccu";
> +			reg = <0x01c20000 0x400>;
> +			clocks = <&osc24M>, <&osc32k>;
> +			clock-names = "hosc", "losc";
> +			#clock-cells = <1>;
> +			#reset-cells = <1>;
> +		};
> +
> +		pio: pinctrl@1c20800 {
> +			compatible = "allwinner,sun50i-a64-pinctrl";
> +			reg = <0x01c20800 0x400>;
> +			interrupts = <GIC_SPI 11 IRQ_TYPE_LEVEL_HIGH>,
> +				     <GIC_SPI 17 IRQ_TYPE_LEVEL_HIGH>,
> +				     <GIC_SPI 21 IRQ_TYPE_LEVEL_HIGH>;
> +			clocks = <&ccu CLK_A64_BUS_PIO>;
> +			gpio-controller;
> +			#gpio-cells = <3>;
> +			interrupt-controller;
> +			#interrupt-cells = <2>;
> +
> +			i2c1_pins: i2c1_pins {
> +				allwinner,pins = "PH2", "PH3";
> +				allwinner,function = "i2c1";
> +				allwinner,drive = <SUN4I_PINCTRL_10_MA>;
> +				allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
> +			};
> +
> +			uart0_pins_a: uart0@0 {
> +				allwinner,pins = "PB8", "PB9";
> +				allwinner,function = "uart0";
> +				allwinner,drive = <SUN4I_PINCTRL_10_MA>;
> +				allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
> +			};
> +		};
> +
> +		uart0: serial@1c28000 {
> +			compatible = "snps,dw-apb-uart";
> +			reg = <0x01c28000 0x400>;
> +			interrupts = <GIC_SPI 0 IRQ_TYPE_LEVEL_HIGH>;
> +			reg-shift = <2>;
> +			reg-io-width = <4>;
> +			clocks = <&ccu CLK_A64_BUS_UART0>;
> +			resets = <&ccu RST_A64_BUS_UART0>;
> +			status = "disabled";
> +		};
> +
> +		uart1: serial@1c28400 {
> +			compatible = "snps,dw-apb-uart";
> +			reg = <0x01c28400 0x400>;
> +			interrupts = <GIC_SPI 1 IRQ_TYPE_LEVEL_HIGH>;
> +			reg-shift = <2>;
> +			reg-io-width = <4>;
> +			clocks = <&ccu CLK_A64_BUS_UART1>;
> +			resets = <&ccu RST_A64_BUS_UART1>;
> +			status = "disabled";
> +		};
> +
> +		uart2: serial@1c28800 {
> +			compatible = "snps,dw-apb-uart";
> +			reg = <0x01c28800 0x400>;
> +			interrupts = <GIC_SPI 2 IRQ_TYPE_LEVEL_HIGH>;
> +			reg-shift = <2>;
> +			reg-io-width = <4>;
> +			clocks = <&ccu CLK_A64_BUS_UART2>;
> +			resets = <&ccu RST_A64_BUS_UART2>;
> +			status = "disabled";
> +		};
> +
> +		uart3: serial@1c28c00 {
> +			compatible = "snps,dw-apb-uart";
> +			reg = <0x01c28c00 0x400>;
> +			interrupts = <GIC_SPI 3 IRQ_TYPE_LEVEL_HIGH>;
> +			reg-shift = <2>;
> +			reg-io-width = <4>;
> +			clocks = <&ccu CLK_A64_BUS_UART3>;
> +			resets = <&ccu RST_A64_BUS_UART3>;
> +			status = "disabled";
> +		};
> +
> +		uart4: serial@1c29000 {
> +			compatible = "snps,dw-apb-uart";
> +			reg = <0x01c29000 0x400>;
> +			interrupts = <GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH>;
> +			reg-shift = <2>;
> +			reg-io-width = <4>;
> +			clocks = <&ccu CLK_A64_BUS_UART4>;
> +			resets = <&ccu RST_A64_BUS_UART4>;
> +			status = "disabled";
> +		};
> +
> +		rtc: rtc@1f00000 {
> +			compatible = "allwinner,sun6i-a31-rtc";
> +			reg = <0x01f00000 0x54>;
> +			interrupts = <GIC_SPI 40 IRQ_TYPE_LEVEL_HIGH>,
> +				     <GIC_SPI 41 IRQ_TYPE_LEVEL_HIGH>;
> +		};
> +
> +		i2c0: i2c@1c2ac00 {
> +			compatible = "allwinner,sun6i-a31-i2c";
> +			reg = <0x01c2ac00 0x400>;
> +			interrupts = <GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH>;
> +			clocks = <&ccu CLK_A64_BUS_I2C0>;
> +			resets = <&ccu RST_A64_BUS_I2C0>;
> +			status = "disabled";
> +			#address-cells = <1>;
> +			#size-cells = <0>;
> +		};
> +
> +		i2c1: i2c@1c2b000 {
> +			compatible = "allwinner,sun6i-a31-i2c";
> +			reg = <0x01c2b000 0x400>;
> +			interrupts = <GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>;
> +			clocks = <&ccu CLK_A64_BUS_I2C1>;
> +			resets = <&ccu RST_A64_BUS_I2C1>;
> +			status = "disabled";
> +			#address-cells = <1>;
> +			#size-cells = <0>;
> +		};
> +
> +		i2c2: i2c@1c2b400 {
> +			compatible = "allwinner,sun6i-a31-i2c";
> +			reg = <0x01c2b400 0x400>;
> +			interrupts = <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>;
> +			clocks = <&ccu CLK_A64_BUS_I2C2>;
> +			resets = <&ccu RST_A64_BUS_I2C2>;
> +			status = "disabled";
> +			#address-cells = <1>;
> +			#size-cells = <0>;
> +		};
> +
> +		gic: interrupt-controller@1c81000 {
> +			compatible = "arm,gic-400";
> +			reg = <0x01c81000 0x1000>,
> +			      <0x01c82000 0x2000>,
> +			      <0x01c84000 0x2000>,
> +			      <0x01c86000 0x2000>;
> +			interrupts = <GIC_PPI 9 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>;
> +			interrupt-controller;
> +			#interrupt-cells = <3>;
> +		};
> +	};
> +};
> 

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [PATCH 12/13] arm64: dts: add Allwinner A64 SoC .dtsi
  2016-09-08  8:41   ` Andre Przywara
@ 2016-09-09 20:04     ` Maxime Ripard
  0 siblings, 0 replies; 34+ messages in thread
From: Maxime Ripard @ 2016-09-09 20:04 UTC (permalink / raw)
  To: Andre Przywara
  Cc: Rob Herring, Chen-Yu Tsai, Mike Turquette, Stephen Boyd,
	devicetree, linux-arm-kernel, linux-kernel, linux-clk

[-- Attachment #1: Type: text/plain, Size: 2144 bytes --]

Hi,

On Thu, Sep 08, 2016 at 09:41:10AM +0100, Andre Przywara wrote:
> > +	timer {
> > +		compatible = "arm,armv8-timer";
> > +		interrupts = <GIC_PPI 13
> > +			(GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>,
> > +			     <GIC_PPI 14
> > +			(GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>,
> > +			     <GIC_PPI 11
> > +			(GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>,
> > +			     <GIC_PPI 10
> > +			(GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>;
> > +	};
> 
> Can you add a PMU node here? Or shall I send a patch on top of it?
> It would be:
> 
> 	pmu {
>         	compatible = "arm,cortex-a53-pmu", "arm,armv8-pmuv3";
> 		interrupts = <GIC_SPI 120 IRQ_TYPE_LEVEL_HIGH>,
> 			     <GIC_SPI 121 IRQ_TYPE_LEVEL_HIGH>,	
> 			     <GIC_SPI 122 IRQ_TYPE_LEVEL_HIGH>,
> 			     <GIC_SPI 123 IRQ_TYPE_LEVEL_HIGH>;
> 		interrupt-affinity = <&cpu0>,
> 				     <&cpu1>,
> 				     <&cpu2>,
> 				     <&cpu3>;
> 	};
> 
> This enables perf to use hardware counters (for cycles and instructions,
> for instance).
> 
> > +
> > +	clocks {
> > +		#address-cells = <1>;
> > +		#size-cells = <1>;
> > +		ranges;
> > +
> > +		osc24M: osc24M_clk {
> > +			#clock-cells = <0>;
> > +			compatible = "fixed-clock";
> > +			clock-frequency = <24000000>;
> > +			clock-output-names = "osc24M";
> > +		};
> > +
> > +		osc32k: osc32k_clk {
> > +			#clock-cells = <0>;
> > +			compatible = "fixed-clock";
> > +			clock-frequency = <32768>;
> > +			clock-output-names = "osc32k";
> > +		};
> > +	};
> 
> Can you remove this "clocks" node and put the two subnodes directly onto
> the top level?
> I know that putting clocks into a subnode is quite wide spread, but it
> does not represent any hardware hierarchy, especially in this
> fixed-clock case.
> So if we can (and it is easy here!) we should avoid any clocks subnode.
> 
> (Yes, I know that this was in my original DT as well, but Mark Rutland
> convinced me of this.)

I'll do those changes before sending the new version.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

^ permalink raw reply	[flat|nested] 34+ messages in thread

* [PATCH 13/13] arm64: dts: add Pine64 support
  2016-07-26 20:30 [PATCH 00/13] arm64: Allwinner A64 support based on sunxi-ng Maxime Ripard
                   ` (11 preceding siblings ...)
  2016-07-26 20:30 ` [PATCH 12/13] arm64: dts: add Allwinner A64 SoC .dtsi Maxime Ripard
@ 2016-07-26 20:30 ` Maxime Ripard
  2016-07-27  8:46 ` [PATCH 00/13] arm64: Allwinner A64 support based on sunxi-ng Jean-Francois Moine
  2016-08-01  1:43 ` André Przywara
  14 siblings, 0 replies; 34+ messages in thread
From: Maxime Ripard @ 2016-07-26 20:30 UTC (permalink / raw)
  To: Rob Herring, Chen-Yu Tsai, Mike Turquette, Stephen Boyd
  Cc: devicetree, Andre Przywara, linux-arm-kernel, linux-kernel,
	linux-clk, Maxime Ripard

From: Andre Przywara <andre.przywara@arm.com>

The Pine64 is a cost-efficient development board based on the
Allwinner A64 SoC.
There are three models: the basic version with Fast Ethernet and
512 MB of DRAM (Pine64) and two Pine64+ versions, which both
feature Gigabit Ethernet and additional connectors for touchscreens
and a camera. Or as my son put it: "Those are smaller and these are
missing." ;-)
The two Pine64+ models just differ in the amount of DRAM
(1GB vs. 2GB). Since U-Boot will figure out the right size for us and
patches the DT accordingly we just need to provide one DT for the
Pine64+.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
[Maxime: Removed the common DTSI and include directly the pine64 DTS]
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
---
 arch/arm64/boot/dts/Makefile                       |  1 +
 arch/arm64/boot/dts/allwinner/Makefile             |  5 ++
 .../boot/dts/allwinner/sun50i-a64-pine64-plus.dts  | 50 ++++++++++++++++
 .../arm64/boot/dts/allwinner/sun50i-a64-pine64.dts | 70 ++++++++++++++++++++++
 4 files changed, 126 insertions(+)
 create mode 100644 arch/arm64/boot/dts/allwinner/Makefile
 create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-plus.dts
 create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts

diff --git a/arch/arm64/boot/dts/Makefile b/arch/arm64/boot/dts/Makefile
index 6e199c903676..ddcbf5a2c17e 100644
--- a/arch/arm64/boot/dts/Makefile
+++ b/arch/arm64/boot/dts/Makefile
@@ -1,4 +1,5 @@
 dts-dirs += al
+dts-dirs += allwinner
 dts-dirs += altera
 dts-dirs += amd
 dts-dirs += amlogic
diff --git a/arch/arm64/boot/dts/allwinner/Makefile b/arch/arm64/boot/dts/allwinner/Makefile
new file mode 100644
index 000000000000..1e29a5ae8282
--- /dev/null
+++ b/arch/arm64/boot/dts/allwinner/Makefile
@@ -0,0 +1,5 @@
+dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pine64-plus.dtb sun50i-a64-pine64.dtb
+
+always		:= $(dtb-y)
+subdir-y	:= $(dts-dirs)
+clean-files	:= *.dtb
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-plus.dts b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-plus.dts
new file mode 100644
index 000000000000..790d14daaa6a
--- /dev/null
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-plus.dts
@@ -0,0 +1,50 @@
+/*
+ * Copyright (c) 2016 ARM Ltd.
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This library is free software; you can redistribute it and/or
+ *     modify it under the terms of the GNU General Public License as
+ *     published by the Free Software Foundation; either version 2 of the
+ *     License, or (at your option) any later version.
+ *
+ *     This library is distributed in the hope that it will be useful,
+ *     but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *     GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ *     obtaining a copy of this software and associated documentation
+ *     files (the "Software"), to deal in the Software without
+ *     restriction, including without limitation the rights to use,
+ *     copy, modify, merge, publish, distribute, sublicense, and/or
+ *     sell copies of the Software, and to permit persons to whom the
+ *     Software is furnished to do so, subject to the following
+ *     conditions:
+ *
+ *     The above copyright notice and this permission notice shall be
+ *     included in all copies or substantial portions of the Software.
+ *
+ *     THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ *     OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+#include "sun50i-a64-pine64.dts"
+
+/ {
+	model = "Pine64+";
+	compatible = "pine64,pine64-plus", "allwinner,sun50i-a64";
+
+	/* TODO: Camera, Ethernet PHY, touchscreen, etc. */
+};
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
new file mode 100644
index 000000000000..da9bca51f5a9
--- /dev/null
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
@@ -0,0 +1,70 @@
+/*
+ * Copyright (c) 2016 ARM Ltd.
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This library is free software; you can redistribute it and/or
+ *     modify it under the terms of the GNU General Public License as
+ *     published by the Free Software Foundation; either version 2 of the
+ *     License, or (at your option) any later version.
+ *
+ *     This library is distributed in the hope that it will be useful,
+ *     but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *     GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ *     obtaining a copy of this software and associated documentation
+ *     files (the "Software"), to deal in the Software without
+ *     restriction, including without limitation the rights to use,
+ *     copy, modify, merge, publish, distribute, sublicense, and/or
+ *     sell copies of the Software, and to permit persons to whom the
+ *     Software is furnished to do so, subject to the following
+ *     conditions:
+ *
+ *     The above copyright notice and this permission notice shall be
+ *     included in all copies or substantial portions of the Software.
+ *
+ *     THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ *     OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+
+#include "sun50i-a64.dtsi"
+
+/ {
+	model = "Pine64";
+	compatible = "pine64,pine64", "allwinner,sun50i-a64";
+
+	aliases {
+		serial0 = &uart0;
+	};
+
+	chosen {
+		stdout-path = "serial0:115200n8";
+	};
+};
+
+&uart0 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&uart0_pins_a>;
+	status = "okay";
+};
+
+&i2c1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&i2c1_pins>;
+	status = "okay";
+};
-- 
2.9.2

^ permalink raw reply related	[flat|nested] 34+ messages in thread

* Re: [PATCH 00/13] arm64: Allwinner A64 support based on sunxi-ng
  2016-07-26 20:30 [PATCH 00/13] arm64: Allwinner A64 support based on sunxi-ng Maxime Ripard
                   ` (12 preceding siblings ...)
  2016-07-26 20:30 ` [PATCH 13/13] arm64: dts: add Pine64 support Maxime Ripard
@ 2016-07-27  8:46 ` Jean-Francois Moine
  2016-07-28 20:07   ` Maxime Ripard
  2016-08-01  1:43 ` André Przywara
  14 siblings, 1 reply; 34+ messages in thread
From: Jean-Francois Moine @ 2016-07-27  8:46 UTC (permalink / raw)
  To: Maxime Ripard
  Cc: Rob Herring, Chen-Yu Tsai, Mike Turquette, Stephen Boyd,
	devicetree, Andre Przywara, linux-kernel, linux-clk,
	linux-arm-kernel

On Tue, 26 Jul 2016 22:30:28 +0200
Maxime Ripard <maxime.ripard@free-electrons.com> wrote:

> ere is the previous A64 patches made by Andre [1], reworked to use
> the new sunxi-ng clock framework.
> 
> This uses the current H3 clock code, as both are really similar. The
> first patches are just meant to rework slightly the H3 code, before
> introducing the A64-related patches.
> 
> Some WiP stuff have been removed, such as the MMC part, but this serie
> already has a decent amount of devices supported: uart, i2c, rsb, etc.
> 
> Let me know what you think,

I don't see the interest to have common code for 32bits and 64bits.
The clock driver of a SoC will never evolve, so, it is simpler to
copy the source common with the H3 into a clean A64 clock driver.

-- 
Ken ar c'hentañ	|	      ** Breizh ha Linux atav! **
Jef		|		http://moinejf.free.fr/

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [PATCH 00/13] arm64: Allwinner A64 support based on sunxi-ng
  2016-07-27  8:46 ` [PATCH 00/13] arm64: Allwinner A64 support based on sunxi-ng Jean-Francois Moine
@ 2016-07-28 20:07   ` Maxime Ripard
  2016-07-29  5:48     ` Jean-Francois Moine
  0 siblings, 1 reply; 34+ messages in thread
From: Maxime Ripard @ 2016-07-28 20:07 UTC (permalink / raw)
  To: Jean-Francois Moine
  Cc: Rob Herring, Chen-Yu Tsai, Mike Turquette, Stephen Boyd,
	devicetree, Andre Przywara, linux-kernel, linux-clk,
	linux-arm-kernel

[-- Attachment #1: Type: text/plain, Size: 1315 bytes --]

On Wed, Jul 27, 2016 at 10:46:23AM +0200, Jean-Francois Moine wrote:
> On Tue, 26 Jul 2016 22:30:28 +0200
> Maxime Ripard <maxime.ripard@free-electrons.com> wrote:
> 
> > ere is the previous A64 patches made by Andre [1], reworked to use
> > the new sunxi-ng clock framework.
> > 
> > This uses the current H3 clock code, as both are really similar. The
> > first patches are just meant to rework slightly the H3 code, before
> > introducing the A64-related patches.
> > 
> > Some WiP stuff have been removed, such as the MMC part, but this serie
> > already has a decent amount of devices supported: uart, i2c, rsb, etc.
> > 
> > Let me know what you think,
> 
> I don't see the interest to have common code for 32bits and 64bits.
> The clock driver of a SoC will never evolve, so, it is simpler to
> copy the source common with the H3 into a clean A64 clock driver.

I'm not sure why 32 bits vs 64 bits matters here. We're going to share
a significant number of drivers already between armv7 and armv8, like
MMC, EMAC, I2C, and so on.

And I expect to share the data in other SoCs for the A10, A13 and A20
for example, or A23/A33, which have a lot of clocks in common too.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [PATCH 00/13] arm64: Allwinner A64 support based on sunxi-ng
  2016-07-28 20:07   ` Maxime Ripard
@ 2016-07-29  5:48     ` Jean-Francois Moine
  2016-07-31  8:51       ` Maxime Ripard
  0 siblings, 1 reply; 34+ messages in thread
From: Jean-Francois Moine @ 2016-07-29  5:48 UTC (permalink / raw)
  To: Maxime Ripard
  Cc: Rob Herring, Chen-Yu Tsai, Mike Turquette, Stephen Boyd,
	devicetree, Andre Przywara, linux-kernel, linux-clk,
	linux-arm-kernel

On Thu, 28 Jul 2016 22:07:05 +0200
Maxime Ripard <maxime.ripard@free-electrons.com> wrote:

> > > Let me know what you think,
> > 
> > I don't see the interest to have common code for 32bits and 64bits.
> > The clock driver of a SoC will never evolve, so, it is simpler to
> > copy the source common with the H3 into a clean A64 clock driver.
> 
> I'm not sure why 32 bits vs 64 bits matters here. We're going to share
> a significant number of drivers already between armv7 and armv8, like
> MMC, EMAC, I2C, and so on.
> 
> And I expect to share the data in other SoCs for the A10, A13 and A20
> for example, or A23/A33, which have a lot of clocks in common too.

The interest of your sunxi-ng approach is that the clocks of each SoC
is described in one file. Here you are mixing 2 SoCs in the same source
file. The advantage is lost.

-- 
Ken ar c'hentañ	|	      ** Breizh ha Linux atav! **
Jef		|		http://moinejf.free.fr/

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [PATCH 00/13] arm64: Allwinner A64 support based on sunxi-ng
  2016-07-29  5:48     ` Jean-Francois Moine
@ 2016-07-31  8:51       ` Maxime Ripard
  0 siblings, 0 replies; 34+ messages in thread
From: Maxime Ripard @ 2016-07-31  8:51 UTC (permalink / raw)
  To: Jean-Francois Moine
  Cc: Rob Herring, Chen-Yu Tsai, Mike Turquette, Stephen Boyd,
	devicetree, Andre Przywara, linux-kernel, linux-clk,
	linux-arm-kernel

[-- Attachment #1: Type: text/plain, Size: 1318 bytes --]

On Fri, Jul 29, 2016 at 07:48:00AM +0200, Jean-Francois Moine wrote:
> On Thu, 28 Jul 2016 22:07:05 +0200
> Maxime Ripard <maxime.ripard@free-electrons.com> wrote:
> 
> > > > Let me know what you think,
> > > 
> > > I don't see the interest to have common code for 32bits and 64bits.
> > > The clock driver of a SoC will never evolve, so, it is simpler to
> > > copy the source common with the H3 into a clean A64 clock driver.
> > 
> > I'm not sure why 32 bits vs 64 bits matters here. We're going to share
> > a significant number of drivers already between armv7 and armv8, like
> > MMC, EMAC, I2C, and so on.
> > 
> > And I expect to share the data in other SoCs for the A10, A13 and A20
> > for example, or A23/A33, which have a lot of clocks in common too.
> 
> The interest of your sunxi-ng approach is that the clocks of each SoC
> is described in one file. Here you are mixing 2 SoCs in the same source
> file. The advantage is lost.

Because (and only because) the huge majority of those clocks are
shared between these SoCs.

If it differs in a significant way (like for the A31 that is currently
submitted), there's of course no reason to merge it in the same file.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [PATCH 00/13] arm64: Allwinner A64 support based on sunxi-ng
  2016-07-26 20:30 [PATCH 00/13] arm64: Allwinner A64 support based on sunxi-ng Maxime Ripard
                   ` (13 preceding siblings ...)
  2016-07-27  8:46 ` [PATCH 00/13] arm64: Allwinner A64 support based on sunxi-ng Jean-Francois Moine
@ 2016-08-01  1:43 ` André Przywara
  2016-08-01  8:30   ` Jean-Francois Moine
                     ` (2 more replies)
  14 siblings, 3 replies; 34+ messages in thread
From: André Przywara @ 2016-08-01  1:43 UTC (permalink / raw)
  To: Maxime Ripard, Rob Herring, Chen-Yu Tsai, Mike Turquette, Stephen Boyd
  Cc: devicetree, linux-arm-kernel, linux-kernel, linux-clk

Hi Maxime,

On 26/07/16 21:30, Maxime Ripard wrote:
> Hi,
> 
> Here is the previous A64 patches made by Andre [1], reworked to use
> the new sunxi-ng clock framework.
> 
> This uses the current H3 clock code, as both are really similar. The
> first patches are just meant to rework slightly the H3 code, before
> introducing the A64-related patches.
> 
> Some WiP stuff have been removed, such as the MMC part, but this serie
> already has a decent amount of devices supported: uart, i2c, rsb, etc.

Thanks very much for looking into this and compiling this series!

In general this looks good to me - apart from the sunxi-ng clock usage.
I think I have some small fixes to the DT (have to compare against my
latest local branch), I will comment on this later.

As I think I never officially expressed my concerns about the new sunxi
clock system, so I use that opportunity here ;-)

As this became quite a long read, here a TL;DR:
- We consider using an SCPI based clock system for the A64, alongside
allwinner,simple-gates and fixed clocks. We try to avoid any Allwinner
specific clocks (apart from the simple-gates).
- ARM Trusted Firmware provides the SCPI implementation - for now, later
we may move this into a possible arisc firmware.
- We upstream some basic DT first, possibly omitting any controversial
clock parts at all.

Let me know what you think!


Now the long part ....

Basically I see those issues with the new clocks:
- sunxi-ng requires a complicated SoC specific source file in the
kernel. Although that makes the DT pretty easy (and avoids breaking it
the future), it ultimately requires an explicit code drop for every new
SoC, even if they share 95% of the clocks (as H3 and A64 do, for instance).
- This code file does not actually contain any code, instead it's just
data and looks like it should really be presented in DT - which brings
us back to something like the old sunxi clock scheme, which is
apparently not considered good enough. I still wonder if we could create
a generic sunxi-ng user, which explains the needed clocks in the DT
instead of in code. I admit that looks like quite some work.
- It makes it quite hard for any other DT user (*BSD, U-Boot) to use the
clocks, since they would have to copy quite verbatim the Linux
implementation choice. This is admittedly also true for the old clock
framework, but still unfortunate.

So as mentioned several times before, I am looking into a more firmware
driven clock system using the SCPI[1] framework.
The idea is:
- The basic clocks (OSC24M, OSC32K, AHB1, APB1, APB2, PERIPH0) are
expressed as fixed clocks. If I am not mistaken, Allwinner recommends
certain frequencies for them anyway, so we just use that and set them up
before booting Linux, for instance in ATF.
- The gates clocks are expressed as before, but by defining a generic DT
compatible fallback name. I have no idea why every SoC enters its name
into the simple_gates.c source file, while just mentioning the
compatible string in the DT bindings and using the SoC specific name
together with a generic fallback like "allwinner,sunxi-simple-gates"
would suffice. This means that we don't need to touch simple-gates.c
anymore most of the time.
- Any clock that can (and has to) be programmed with a variable
frequency is expressed as an SCPI clock. This interface allows basically
querying and setting a frequency - not very powerful, but sufficient for
the clocks I checked. Firmware then takes the burden of programming the
respective clock register - which is not rocket science if we lock the
base clocks to a certain frequency.

The advantage of this approach would be:
- The impact to Linux code is minimized. Normally there would be no need
to touch the kernel at all when we introduce a new SoC.
- Any other DT user can quite easily make use of the clock system
without adding tons of complicated Allwinner specific clock code. The
simple-gates driver is almost trivial to implement, and chances are SCPI
is already around anyway.
- If there are any peculiarities with a certain clock (implementation),
we can solve this in firmware. Fixes to code would immediately benefit
all users - existing kernels (from distributions), newer kernels and
other OSes.
- Having SCPI gives us simple regulators and sensors (temperature,
power) for free (in terms of no Linux code required). It also allows for
DVFS support, though this may require more work on the firmware side.
- This approach matches many of the more serious ARM64 machines out
there, which refrain from exposing all of their clock framework to Linux.

Also this opens the door to much easier support for new SoCs - up to a
point where any new chip would actually run out of the box on existing
distributions (thinking of LTS releases here). The pinctrl driver is a
nasty guy around here - but let's not make it worse and try to fix that
guy later ;-)

So I managed to finish a first prototype this weekend.
SCPI requires a mailbox and a shared memory region to work. The latter
is trivial, but we are lacking a proper mailbox driver for sunxi.
Besides that the Allwinner mailbox only works between the arisc and the
ARM cores, not between ARM cores or within one core in different
exception levels. So signalling a mailbox in EL1 and taking the IRQ in
EL3 does not work.
As a quick solution I implemented a synchronous "smc" mailbox, which
uses the ARM smc instruction to transfer control into firmware. Firmware
then reads the payload from the shared memory region, handles the
request and returns to EL1. We then advertise this mailbox in the SCPI
DT node, and the rest of the SCPI framework can happily work with that.
I described the clocks as mentioned above and put the MMC clocks under
SCPI control.
I put a draft DT here [2] to illustrate my ideas.

I know this is quite controversial, so what about these following steps:

- I polish my existing patches and send a prototype this week. We can
then discuss the merits and drawbacks of this approach based on the code.
- It it turns out that sunxi-ng is the way to go, I will test and
comment on this series.
- If we are not sure yet, we can try to go with an almost clock-less DT
for now (drop I2C and make UART0 use osc24M directly, for a start). This
would leave the door open for either approach. Or we use the
simple-gates only for now.

I am happy to discuss this here on the list.

Cheers,
Andre

[1]
http://infocenter.arm.com/help/topic/com.arm.doc.dui0922g/scp_message_interface_v1_2_DUI0922G_en.pdf
[2] https://gist.github.com/apritzel/faa3dc5cbe7591be8c55a439f725578e

> 
> Let me know what you think,
> Maxime
> 
> 1: http://lists.infradead.org/pipermail/linux-arm-kernel/2016-February/410338.html
> 
> Andre Przywara (5):
>   arm64: sunxi: Kconfig: add essential pinctrl driver
>   arm64: Kconfig: sunxi: add PINCTRL
>   Documentation: devicetree: add vendor prefix for Pine64
>   arm64: dts: add Allwinner A64 SoC .dtsi
>   arm64: dts: add Pine64 support
> 
> Maxime Ripard (8):
>   clk: sunxi-ng: mux: Rename mux macro to be consistent
>   clk: sunxi-ng: mux: Add mux table support
>   clk: sunxi-ng: sun8i: Rename DDR and video plls
>   clk: sunxi-ng: sun8i: Fix register offset
>   clk: sunxi-ng: sun8i: Rename H3 only clocks
>   clk: sunxi-ng: sun8i: Move fixed factors around
>   clk: sunxi-ng: sun8i: Prefix clock defines by SoC Name
>   clk: sunxi-ng: Add A64 clocks
> 
>  Documentation/devicetree/bindings/arm/sunxi.txt    |   1 +
>  .../devicetree/bindings/clock/sunxi-ccu.txt        |   1 +
>  .../devicetree/bindings/vendor-prefixes.txt        |   1 +
>  MAINTAINERS                                        |   1 +
>  arch/arm/boot/dts/sun8i-h3.dtsi                    |  62 +-
>  arch/arm64/Kconfig.platforms                       |   2 +
>  arch/arm64/boot/dts/Makefile                       |   1 +
>  arch/arm64/boot/dts/allwinner/Makefile             |   5 +
>  .../boot/dts/allwinner/sun50i-a64-pine64-plus.dts  |  50 ++
>  .../arm64/boot/dts/allwinner/sun50i-a64-pine64.dts |  70 ++
>  arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi      | 273 +++++++
>  drivers/clk/sunxi-ng/Kconfig                       |  13 +-
>  drivers/clk/sunxi-ng/Makefile                      |   2 +-
>  drivers/clk/sunxi-ng/ccu-sun50i-a64.h              |  68 ++
>  drivers/clk/sunxi-ng/ccu-sun8i-h3.c                | 896 ++++++++++++++++-----
>  drivers/clk/sunxi-ng/ccu-sun8i-h3.h                |  44 +-
>  drivers/clk/sunxi-ng/ccu_div.h                     |   2 +-
>  drivers/clk/sunxi-ng/ccu_mp.h                      |   2 +-
>  drivers/clk/sunxi-ng/ccu_mux.c                     |  14 +
>  drivers/clk/sunxi-ng/ccu_mux.h                     |  29 +-
>  include/dt-bindings/clock/sun50i-a64-ccu.h         | 132 +++
>  include/dt-bindings/clock/sun8i-h3-ccu.h           | 188 ++---
>  include/dt-bindings/reset/sun50i-a64-ccu.h         |  97 +++
>  23 files changed, 1588 insertions(+), 366 deletions(-)
>  create mode 100644 arch/arm64/boot/dts/allwinner/Makefile
>  create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-plus.dts
>  create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
>  create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
>  create mode 100644 drivers/clk/sunxi-ng/ccu-sun50i-a64.h
>  create mode 100644 include/dt-bindings/clock/sun50i-a64-ccu.h
>  create mode 100644 include/dt-bindings/reset/sun50i-a64-ccu.h
> 

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [PATCH 00/13] arm64: Allwinner A64 support based on sunxi-ng
  2016-08-01  1:43 ` André Przywara
@ 2016-08-01  8:30   ` Jean-Francois Moine
  2016-08-01  9:13     ` Chen-Yu Tsai
  2016-08-01 10:44     ` Andre Przywara
  2016-08-01  9:11   ` Chen-Yu Tsai
  2016-08-23 19:31   ` Maxime Ripard
  2 siblings, 2 replies; 34+ messages in thread
From: Jean-Francois Moine @ 2016-08-01  8:30 UTC (permalink / raw)
  To: André Przywara
  Cc: Maxime Ripard, Rob Herring, Chen-Yu Tsai, Mike Turquette,
	Stephen Boyd, devicetree, linux-kernel, linux-arm-kernel,
	linux-clk

On Mon, 1 Aug 2016 02:43:06 +0100
André Przywara <andre.przywara@arm.com> wrote:

> As this became quite a long read, here a TL;DR:
> - We consider using an SCPI based clock system for the A64, alongside
> allwinner,simple-gates and fixed clocks. We try to avoid any Allwinner
> specific clocks (apart from the simple-gates).
> - ARM Trusted Firmware provides the SCPI implementation - for now, later
> we may move this into a possible arisc firmware.
> - We upstream some basic DT first, possibly omitting any controversial
> clock parts at all.
> 
> Let me know what you think!

Hi André,

This looks interesting.
As I understand, the clock enable/rate setting functions would be in
the arisc. The arisc firmware would be loaded only once in the Soc and
would contain the code for handling this specific SoC.
>From my calculations, this would save about 1Mb of clock descriptions
in the kernel for a universal Allwinner kernel.

But I don't see why you are keeping the simple-gates. The bus gate may
be ungated/gated when the clock is enabled/disabled, and that's what
Allwinner's software does.

-- 
Ken ar c'hentañ	|	      ** Breizh ha Linux atav! **
Jef		|		http://moinejf.free.fr/

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [PATCH 00/13] arm64: Allwinner A64 support based on sunxi-ng
  2016-08-01  8:30   ` Jean-Francois Moine
@ 2016-08-01  9:13     ` Chen-Yu Tsai
  2016-08-01 12:00       ` Jean-Francois Moine
  2016-08-01 10:44     ` Andre Przywara
  1 sibling, 1 reply; 34+ messages in thread
From: Chen-Yu Tsai @ 2016-08-01  9:13 UTC (permalink / raw)
  To: Jean-Francois Moine
  Cc: André Przywara, Maxime Ripard, Rob Herring, Chen-Yu Tsai,
	Mike Turquette, Stephen Boyd, devicetree, linux-kernel,
	linux-arm-kernel, linux-clk

On Mon, Aug 1, 2016 at 4:30 PM, Jean-Francois Moine <moinejf@free.fr> wrote:
> On Mon, 1 Aug 2016 02:43:06 +0100
> André Przywara <andre.przywara@arm.com> wrote:
>
>> As this became quite a long read, here a TL;DR:
>> - We consider using an SCPI based clock system for the A64, alongside
>> allwinner,simple-gates and fixed clocks. We try to avoid any Allwinner
>> specific clocks (apart from the simple-gates).
>> - ARM Trusted Firmware provides the SCPI implementation - for now, later
>> we may move this into a possible arisc firmware.
>> - We upstream some basic DT first, possibly omitting any controversial
>> clock parts at all.
>>
>> Let me know what you think!
>
> Hi André,
>
> This looks interesting.
> As I understand, the clock enable/rate setting functions would be in
> the arisc. The arisc firmware would be loaded only once in the Soc and
> would contain the code for handling this specific SoC.
> From my calculations, this would save about 1Mb of clock descriptions
> in the kernel for a universal Allwinner kernel.
>
> But I don't see why you are keeping the simple-gates. The bus gate may
> be ungated/gated when the clock is enabled/disabled, and that's what
> Allwinner's software does.

For peripherals that have a separate mod clock, having them separate
is a good thing. One example might be the audio codecs. You could ungate
the bus gate to access its registers to program it, but only enable
the mod clock when you actually play something.

Regards
ChenYu

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [PATCH 00/13] arm64: Allwinner A64 support based on sunxi-ng
  2016-08-01  9:13     ` Chen-Yu Tsai
@ 2016-08-01 12:00       ` Jean-Francois Moine
  2016-08-01 12:01         ` Chen-Yu Tsai
  0 siblings, 1 reply; 34+ messages in thread
From: Jean-Francois Moine @ 2016-08-01 12:00 UTC (permalink / raw)
  To: Chen-Yu Tsai
  Cc: André Przywara, Maxime Ripard, Rob Herring, Mike Turquette,
	Stephen Boyd, devicetree, linux-kernel, linux-arm-kernel,
	linux-clk

On Mon, 1 Aug 2016 17:13:34 +0800
Chen-Yu Tsai <wens@csie.org> wrote:

> > But I don't see why you are keeping the simple-gates. The bus gate may
> > be ungated/gated when the clock is enabled/disabled, and that's what
> > Allwinner's software does.
> 
> For peripherals that have a separate mod clock, having them separate
> is a good thing. One example might be the audio codecs. You could ungate
> the bus gate to access its registers to program it, but only enable
> the mod clock when you actually play something.

The roles of the bus gate and the clock gate are the same. I don't see
any reason to set one gate without setting the other one. More, the
spec says what the bus gate must be enabled before the clock gate (and
reverse order while disabling). So, setting both gates in one function
call seems safer.

Then, if you want to save some power while not playing anything, just do
clk_disable() of the (main and only) i2s clock.

-- 
Ken ar c'hentañ	|	      ** Breizh ha Linux atav! **
Jef		|		http://moinejf.free.fr/

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [PATCH 00/13] arm64: Allwinner A64 support based on sunxi-ng
  2016-08-01 12:00       ` Jean-Francois Moine
@ 2016-08-01 12:01         ` Chen-Yu Tsai
  2016-08-01 12:11           ` Jean-Francois Moine
  0 siblings, 1 reply; 34+ messages in thread
From: Chen-Yu Tsai @ 2016-08-01 12:01 UTC (permalink / raw)
  To: Jean-Francois Moine
  Cc: Chen-Yu Tsai, André Przywara, Maxime Ripard, Rob Herring,
	Mike Turquette, Stephen Boyd, devicetree, linux-kernel,
	linux-arm-kernel, linux-clk

On Mon, Aug 1, 2016 at 8:00 PM, Jean-Francois Moine <moinejf@free.fr> wrote:
> On Mon, 1 Aug 2016 17:13:34 +0800
> Chen-Yu Tsai <wens@csie.org> wrote:
>
>> > But I don't see why you are keeping the simple-gates. The bus gate may
>> > be ungated/gated when the clock is enabled/disabled, and that's what
>> > Allwinner's software does.
>>
>> For peripherals that have a separate mod clock, having them separate
>> is a good thing. One example might be the audio codecs. You could ungate
>> the bus gate to access its registers to program it, but only enable
>> the mod clock when you actually play something.
>
> The roles of the bus gate and the clock gate are the same. I don't see
> any reason to set one gate without setting the other one. More, the
> spec says what the bus gate must be enabled before the clock gate (and
> reverse order while disabling). So, setting both gates in one function
> call seems safer.

Wha? Aren't bus gates and clock gates the same thing in this context?

ChenYu

> Then, if you want to save some power while not playing anything, just do
> clk_disable() of the (main and only) i2s clock.
>
> --
> Ken ar c'hentañ |             ** Breizh ha Linux atav! **
> Jef             |               http://moinejf.free.fr/

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [PATCH 00/13] arm64: Allwinner A64 support based on sunxi-ng
  2016-08-01 12:01         ` Chen-Yu Tsai
@ 2016-08-01 12:11           ` Jean-Francois Moine
  0 siblings, 0 replies; 34+ messages in thread
From: Jean-Francois Moine @ 2016-08-01 12:11 UTC (permalink / raw)
  To: Chen-Yu Tsai
  Cc: André Przywara, Maxime Ripard, Rob Herring, Mike Turquette,
	Stephen Boyd, devicetree, linux-kernel, linux-arm-kernel,
	linux-clk

On Mon, 1 Aug 2016 20:01:49 +0800
Chen-Yu Tsai <wens@csie.org> wrote:

> On Mon, Aug 1, 2016 at 8:00 PM, Jean-Francois Moine <moinejf@free.fr> wrote:
> > On Mon, 1 Aug 2016 17:13:34 +0800
> > Chen-Yu Tsai <wens@csie.org> wrote:
> >
> >> > But I don't see why you are keeping the simple-gates. The bus gate may
> >> > be ungated/gated when the clock is enabled/disabled, and that's what
> >> > Allwinner's software does.
> >>
> >> For peripherals that have a separate mod clock, having them separate
> >> is a good thing. One example might be the audio codecs. You could ungate
> >> the bus gate to access its registers to program it, but only enable
> >> the mod clock when you actually play something.
> >
> > The roles of the bus gate and the clock gate are the same. I don't see
> > any reason to set one gate without setting the other one. More, the
> > spec says what the bus gate must be enabled before the clock gate (and
> > reverse order while disabling). So, setting both gates in one function
> > call seems safer.
> 
> Wha? Aren't bus gates and clock gates the same thing in this context?

Yes. What is the problem?

-- 
Ken ar c'hentañ	|	      ** Breizh ha Linux atav! **
Jef		|		http://moinejf.free.fr/

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [PATCH 00/13] arm64: Allwinner A64 support based on sunxi-ng
  2016-08-01  8:30   ` Jean-Francois Moine
  2016-08-01  9:13     ` Chen-Yu Tsai
@ 2016-08-01 10:44     ` Andre Przywara
  1 sibling, 0 replies; 34+ messages in thread
From: Andre Przywara @ 2016-08-01 10:44 UTC (permalink / raw)
  To: Jean-Francois Moine
  Cc: Maxime Ripard, Rob Herring, Chen-Yu Tsai, Mike Turquette,
	Stephen Boyd, devicetree, linux-kernel, linux-arm-kernel,
	linux-clk

Hi Jean-Francois,

On 01/08/16 09:30, Jean-Francois Moine wrote:
> On Mon, 1 Aug 2016 02:43:06 +0100
> André Przywara <andre.przywara@arm.com> wrote:
> 
>> As this became quite a long read, here a TL;DR:
>> - We consider using an SCPI based clock system for the A64, alongside
>> allwinner,simple-gates and fixed clocks. We try to avoid any Allwinner
>> specific clocks (apart from the simple-gates).
>> - ARM Trusted Firmware provides the SCPI implementation - for now, later
>> we may move this into a possible arisc firmware.
>> - We upstream some basic DT first, possibly omitting any controversial
>> clock parts at all.
>>
>> Let me know what you think!
> 
> Hi André,
> 
> This looks interesting.
> As I understand, the clock enable/rate setting functions would be in
> the arisc. The arisc firmware would be loaded only once in the Soc and
> would contain the code for handling this specific SoC.
> From my calculations, this would save about 1Mb of clock descriptions
> in the kernel for a universal Allwinner kernel.

This is the rough idea, yes. In the moment the clock code sits in the
ARM Trusted Firmware part, but in fact this is an implementation detail.
Theoretically we could also move that clock code to U-Boot on 32-bit
SoCs to sit next to the PSCI implementation, which uses the same smc
call mechanism as I do in this first implementation.
But unfortunately we cannot remove the existing code from the kernel,
since that would break all existing users (unless they upgrade their
firmware). So I am not sure if supporting older SoCs with this mechanism
is worthwhile.

But: yes, I want to avoid adding tedious clock descriptions for each and
every new SoC to the kernel. What really worries me is that sunxi-ng
makes this situation probably worse, as we now have to add SoC specific
"code" (in fact: clock descriptions) for every SoC, even if that chip
doesn't introduce any new clock type.

> But I don't see why you are keeping the simple-gates. The bus gate may
> be ungated/gated when the clock is enabled/disabled, and that's what
> Allwinner's software does.

We could do. But SCPI does not have an explicit enable/disable
interface, it only describes that setting the frequency to 0 disables
the clock. For enabling it one would have to set some frequency (!= 0),
which the firmware could then translate into a "set that bit in the gate
register" for any gate-only clock, which sounds rather hackish to me.
Also it would require to alter the SCPI clock driver to implement the
enable/disable ops, since I think we never call set_rate for those clocks.

So having the quite straight forward "simple-gates" driver around seems
more sane. In the end this driver just translates "clock number x" into
"bit number x" in that register, which is very generic. That's why I
urged to introduce a fallback compatible name to express this very feature.

Cheers,
Andre.

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [PATCH 00/13] arm64: Allwinner A64 support based on sunxi-ng
  2016-08-01  1:43 ` André Przywara
  2016-08-01  8:30   ` Jean-Francois Moine
@ 2016-08-01  9:11   ` Chen-Yu Tsai
  2016-08-11  0:36     ` André Przywara
  2016-08-23 19:31   ` Maxime Ripard
  2 siblings, 1 reply; 34+ messages in thread
From: Chen-Yu Tsai @ 2016-08-01  9:11 UTC (permalink / raw)
  To: André Przywara
  Cc: Maxime Ripard, Rob Herring, Chen-Yu Tsai, Mike Turquette,
	Stephen Boyd, devicetree, linux-arm-kernel, linux-kernel,
	linux-clk

Hi,

On Mon, Aug 1, 2016 at 9:43 AM, André Przywara <andre.przywara@arm.com> wrote:
> Hi Maxime,
>
> On 26/07/16 21:30, Maxime Ripard wrote:
>> Hi,
>>
>> Here is the previous A64 patches made by Andre [1], reworked to use
>> the new sunxi-ng clock framework.
>>
>> This uses the current H3 clock code, as both are really similar. The
>> first patches are just meant to rework slightly the H3 code, before
>> introducing the A64-related patches.
>>
>> Some WiP stuff have been removed, such as the MMC part, but this serie
>> already has a decent amount of devices supported: uart, i2c, rsb, etc.
>
> Thanks very much for looking into this and compiling this series!
>
> In general this looks good to me - apart from the sunxi-ng clock usage.
> I think I have some small fixes to the DT (have to compare against my
> latest local branch), I will comment on this later.
>
> As I think I never officially expressed my concerns about the new sunxi
> clock system, so I use that opportunity here ;-)
>
> As this became quite a long read, here a TL;DR:
> - We consider using an SCPI based clock system for the A64, alongside
> allwinner,simple-gates and fixed clocks. We try to avoid any Allwinner
> specific clocks (apart from the simple-gates).
> - ARM Trusted Firmware provides the SCPI implementation - for now, later
> we may move this into a possible arisc firmware.
> - We upstream some basic DT first, possibly omitting any controversial
> clock parts at all.
>
> Let me know what you think!
>
>
> Now the long part ....
>
> Basically I see those issues with the new clocks:
> - sunxi-ng requires a complicated SoC specific source file in the
> kernel. Although that makes the DT pretty easy (and avoids breaking it
> the future), it ultimately requires an explicit code drop for every new
> SoC, even if they share 95% of the clocks (as H3 and A64 do, for instance).
> - This code file does not actually contain any code, instead it's just
> data and looks like it should really be presented in DT - which brings
> us back to something like the old sunxi clock scheme, which is
> apparently not considered good enough. I still wonder if we could create
> a generic sunxi-ng user, which explains the needed clocks in the DT
> instead of in code. I admit that looks like quite some work.

I'm guessing this was nacked by device tree maintainers and/or clk
maintainers. A recent thread adding display timings in DT to the
simple-panel binding is a similar example.

> - It makes it quite hard for any other DT user (*BSD, U-Boot) to use the
> clocks, since they would have to copy quite verbatim the Linux
> implementation choice. This is admittedly also true for the old clock
> framework, but still unfortunate.
>
> So as mentioned several times before, I am looking into a more firmware
> driven clock system using the SCPI[1] framework.
> The idea is:
> - The basic clocks (OSC24M, OSC32K, AHB1, APB1, APB2, PERIPH0) are
> expressed as fixed clocks. If I am not mistaken, Allwinner recommends
> certain frequencies for them anyway, so we just use that and set them up
> before booting Linux, for instance in ATF.

True. These are set by the bootloader because it uses them.

If you're concerned about the clock rate changing, you can always have
the clocks set to read only, i.e. clock rates cannot be changed.

> - The gates clocks are expressed as before, but by defining a generic DT
> compatible fallback name. I have no idea why every SoC enters its name
> into the simple_gates.c source file, while just mentioning the
> compatible string in the DT bindings and using the SoC specific name
> together with a generic fallback like "allwinner,sunxi-simple-gates"
> would suffice. This means that we don't need to touch simple-gates.c
> anymore most of the time.

My understanding is that because they _are_ different, they are defined
by different compatible strings. The fact that we can have a simple
clk driver supporting all of them, using the clk-indices property to
get the bit offsets, is beside the point.

clk-indices is used for clk name lookup through DT, when the phandle
index is not the same as the one used for clk-output-names. We are
slightly abusing it to get the bit offsets. It is entirely possible
to do a clk binding without them. You would then have that information
in the driver.

> - Any clock that can (and has to) be programmed with a variable
> frequency is expressed as an SCPI clock. This interface allows basically
> querying and setting a frequency - not very powerful, but sufficient for
> the clocks I checked. Firmware then takes the burden of programming the
> respective clock register - which is not rocket science if we lock the
> base clocks to a certain frequency.

Can it also propagate clock rate changes and reparenting such that
we do not need to describe clock relationships in the kernel? If not
then we still need some kind of description somewhere. And the clk
maintainers don't seem too fond of 1 clk per node designs, which
would allow you to describe it in the DT.

We will run into this when we do audio and video. The module clocks
may or may not have dividers or multiple parents. But in some cases
you have to change the PLL clock rate, which in turn changes the clock
rate of all the clocks under it. An example would be playing 44.1 KHz
audio through the internal codec, which requires a different PLL clock
rate than playing 48 KHz audio. But if at the same time you're also
using I2S at 44.1 KHz or some multiple, you would want to know the
clock rate is about to change, and maybe block the change.

Can SCPI notify the kernel about these changes? If not you'd have
some logic in the kernel. Splitting the logic here IMHO is not a
good design.

>
> The advantage of this approach would be:
> - The impact to Linux code is minimized. Normally there would be no need
> to touch the kernel at all when we introduce a new SoC.
> - Any other DT user can quite easily make use of the clock system
> without adding tons of complicated Allwinner specific clock code. The
> simple-gates driver is almost trivial to implement, and chances are SCPI
> is already around anyway.
> - If there are any peculiarities with a certain clock (implementation),
> we can solve this in firmware. Fixes to code would immediately benefit
> all users - existing kernels (from distributions), newer kernels and
> other OSes.

Upgrading firmware is still upgrading something... I'm not sure how
it's better.

> - Having SCPI gives us simple regulators and sensors (temperature,
> power) for free (in terms of no Linux code required). It also allows for
> DVFS support, though this may require more work on the firmware side.

Are you arguing to move PMIC support into SCPI firmware?

> - This approach matches many of the more serious ARM64 machines out
> there, which refrain from exposing all of their clock framework to Linux.

A quick grep through linux-next shows only the Juno platform using
"arm,scpi-clocks". Some other consumer oriented vendors, such as
mediatek, nvidia, qualcomm, renesas and rockchip have monolithic
clock nodes.

>
> Also this opens the door to much easier support for new SoCs - up to a
> point where any new chip would actually run out of the box on existing
> distributions (thinking of LTS releases here). The pinctrl driver is a
> nasty guy around here - but let's not make it worse and try to fix that
> guy later ;-)

Not really. You still have to write the firmware for the new SoCs,
unless you expect Allwinner to adopt our design. And getting the new
firmware to work with the existing bootloader (if upstream support
isn't done yet) may be tricky, as you already went through for the
A64.

>
> So I managed to finish a first prototype this weekend.
> SCPI requires a mailbox and a shared memory region to work. The latter
> is trivial, but we are lacking a proper mailbox driver for sunxi.
> Besides that the Allwinner mailbox only works between the arisc and the
> ARM cores, not between ARM cores or within one core in different
> exception levels. So signalling a mailbox in EL1 and taking the IRQ in
> EL3 does not work.
> As a quick solution I implemented a synchronous "smc" mailbox, which
> uses the ARM smc instruction to transfer control into firmware. Firmware
> then reads the payload from the shared memory region, handles the
> request and returns to EL1. We then advertise this mailbox in the SCPI
> DT node, and the rest of the SCPI framework can happily work with that.
> I described the clocks as mentioned above and put the MMC clocks under
> SCPI control.
> I put a draft DT here [2] to illustrate my ideas.
>
> I know this is quite controversial, so what about these following steps:
>
> - I polish my existing patches and send a prototype this week. We can
> then discuss the merits and drawbacks of this approach based on the code.
> - It it turns out that sunxi-ng is the way to go, I will test and
> comment on this series.
> - If we are not sure yet, we can try to go with an almost clock-less DT
> for now (drop I2C and make UART0 use osc24M directly, for a start). This
> would leave the door open for either approach. Or we use the
> simple-gates only for now.

A clock-less system is quite useless. The only things that work are the
peripherals tied to apb2, namely uarts and i2c busses. And maybe simplefb
if you get the display pipeline working in the bootloader. This is where
A83T has been for some time. :(

Regards
ChenYu

>
> I am happy to discuss this here on the list.
>
> Cheers,
> Andre
>
> [1]
> http://infocenter.arm.com/help/topic/com.arm.doc.dui0922g/scp_message_interface_v1_2_DUI0922G_en.pdf
> [2] https://gist.github.com/apritzel/faa3dc5cbe7591be8c55a439f725578e
>
>>
>> Let me know what you think,
>> Maxime
>>
>> 1: http://lists.infradead.org/pipermail/linux-arm-kernel/2016-February/410338.html
>>
>> Andre Przywara (5):
>>   arm64: sunxi: Kconfig: add essential pinctrl driver
>>   arm64: Kconfig: sunxi: add PINCTRL
>>   Documentation: devicetree: add vendor prefix for Pine64
>>   arm64: dts: add Allwinner A64 SoC .dtsi
>>   arm64: dts: add Pine64 support
>>
>> Maxime Ripard (8):
>>   clk: sunxi-ng: mux: Rename mux macro to be consistent
>>   clk: sunxi-ng: mux: Add mux table support
>>   clk: sunxi-ng: sun8i: Rename DDR and video plls
>>   clk: sunxi-ng: sun8i: Fix register offset
>>   clk: sunxi-ng: sun8i: Rename H3 only clocks
>>   clk: sunxi-ng: sun8i: Move fixed factors around
>>   clk: sunxi-ng: sun8i: Prefix clock defines by SoC Name
>>   clk: sunxi-ng: Add A64 clocks
>>
>>  Documentation/devicetree/bindings/arm/sunxi.txt    |   1 +
>>  .../devicetree/bindings/clock/sunxi-ccu.txt        |   1 +
>>  .../devicetree/bindings/vendor-prefixes.txt        |   1 +
>>  MAINTAINERS                                        |   1 +
>>  arch/arm/boot/dts/sun8i-h3.dtsi                    |  62 +-
>>  arch/arm64/Kconfig.platforms                       |   2 +
>>  arch/arm64/boot/dts/Makefile                       |   1 +
>>  arch/arm64/boot/dts/allwinner/Makefile             |   5 +
>>  .../boot/dts/allwinner/sun50i-a64-pine64-plus.dts  |  50 ++
>>  .../arm64/boot/dts/allwinner/sun50i-a64-pine64.dts |  70 ++
>>  arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi      | 273 +++++++
>>  drivers/clk/sunxi-ng/Kconfig                       |  13 +-
>>  drivers/clk/sunxi-ng/Makefile                      |   2 +-
>>  drivers/clk/sunxi-ng/ccu-sun50i-a64.h              |  68 ++
>>  drivers/clk/sunxi-ng/ccu-sun8i-h3.c                | 896 ++++++++++++++++-----
>>  drivers/clk/sunxi-ng/ccu-sun8i-h3.h                |  44 +-
>>  drivers/clk/sunxi-ng/ccu_div.h                     |   2 +-
>>  drivers/clk/sunxi-ng/ccu_mp.h                      |   2 +-
>>  drivers/clk/sunxi-ng/ccu_mux.c                     |  14 +
>>  drivers/clk/sunxi-ng/ccu_mux.h                     |  29 +-
>>  include/dt-bindings/clock/sun50i-a64-ccu.h         | 132 +++
>>  include/dt-bindings/clock/sun8i-h3-ccu.h           | 188 ++---
>>  include/dt-bindings/reset/sun50i-a64-ccu.h         |  97 +++
>>  23 files changed, 1588 insertions(+), 366 deletions(-)
>>  create mode 100644 arch/arm64/boot/dts/allwinner/Makefile
>>  create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-plus.dts
>>  create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
>>  create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
>>  create mode 100644 drivers/clk/sunxi-ng/ccu-sun50i-a64.h
>>  create mode 100644 include/dt-bindings/clock/sun50i-a64-ccu.h
>>  create mode 100644 include/dt-bindings/reset/sun50i-a64-ccu.h
>>

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [PATCH 00/13] arm64: Allwinner A64 support based on sunxi-ng
  2016-08-01  9:11   ` Chen-Yu Tsai
@ 2016-08-11  0:36     ` André Przywara
  0 siblings, 0 replies; 34+ messages in thread
From: André Przywara @ 2016-08-11  0:36 UTC (permalink / raw)
  To: Chen-Yu Tsai
  Cc: Maxime Ripard, Rob Herring, Mike Turquette, Stephen Boyd,
	devicetree, linux-arm-kernel, linux-kernel, linux-clk

On 01/08/16 10:11, Chen-Yu Tsai wrote:
> Hi,

Hi Chen-Yu,

thanks for your comments, just found some time to come back to this.

> 
> On Mon, Aug 1, 2016 at 9:43 AM, André Przywara <andre.przywara@arm.com> wrote:
>> Hi Maxime,
>>
>> On 26/07/16 21:30, Maxime Ripard wrote:
>>> Hi,
>>>
>>> Here is the previous A64 patches made by Andre [1], reworked to use
>>> the new sunxi-ng clock framework.
>>>
>>> This uses the current H3 clock code, as both are really similar. The
>>> first patches are just meant to rework slightly the H3 code, before
>>> introducing the A64-related patches.
>>>
>>> Some WiP stuff have been removed, such as the MMC part, but this serie
>>> already has a decent amount of devices supported: uart, i2c, rsb, etc.
>>
>> Thanks very much for looking into this and compiling this series!
>>
>> In general this looks good to me - apart from the sunxi-ng clock usage.
>> I think I have some small fixes to the DT (have to compare against my
>> latest local branch), I will comment on this later.
>>
>> As I think I never officially expressed my concerns about the new sunxi
>> clock system, so I use that opportunity here ;-)
>>
>> As this became quite a long read, here a TL;DR:
>> - We consider using an SCPI based clock system for the A64, alongside
>> allwinner,simple-gates and fixed clocks. We try to avoid any Allwinner
>> specific clocks (apart from the simple-gates).
>> - ARM Trusted Firmware provides the SCPI implementation - for now, later
>> we may move this into a possible arisc firmware.
>> - We upstream some basic DT first, possibly omitting any controversial
>> clock parts at all.
>>
>> Let me know what you think!
>>
>>
>> Now the long part ....
>>
>> Basically I see those issues with the new clocks:
>> - sunxi-ng requires a complicated SoC specific source file in the
>> kernel. Although that makes the DT pretty easy (and avoids breaking it
>> the future), it ultimately requires an explicit code drop for every new
>> SoC, even if they share 95% of the clocks (as H3 and A64 do, for instance).
>> - This code file does not actually contain any code, instead it's just
>> data and looks like it should really be presented in DT - which brings
>> us back to something like the old sunxi clock scheme, which is
>> apparently not considered good enough. I still wonder if we could create
>> a generic sunxi-ng user, which explains the needed clocks in the DT
>> instead of in code. I admit that looks like quite some work.
> 
> I'm guessing this was nacked by device tree maintainers and/or clk
> maintainers. A recent thread adding display timings in DT to the
> simple-panel binding is a similar example.
> 
>> - It makes it quite hard for any other DT user (*BSD, U-Boot) to use the
>> clocks, since they would have to copy quite verbatim the Linux
>> implementation choice. This is admittedly also true for the old clock
>> framework, but still unfortunate.
>>
>> So as mentioned several times before, I am looking into a more firmware
>> driven clock system using the SCPI[1] framework.
>> The idea is:
>> - The basic clocks (OSC24M, OSC32K, AHB1, APB1, APB2, PERIPH0) are
>> expressed as fixed clocks. If I am not mistaken, Allwinner recommends
>> certain frequencies for them anyway, so we just use that and set them up
>> before booting Linux, for instance in ATF.
> 
> True. These are set by the bootloader because it uses them.
> 
> If you're concerned about the clock rate changing, you can always have
> the clocks set to read only, i.e. clock rates cannot be changed.
> 
>> - The gates clocks are expressed as before, but by defining a generic DT
>> compatible fallback name. I have no idea why every SoC enters its name
>> into the simple_gates.c source file, while just mentioning the
>> compatible string in the DT bindings and using the SoC specific name
>> together with a generic fallback like "allwinner,sunxi-simple-gates"
>> would suffice. This means that we don't need to touch simple-gates.c
>> anymore most of the time.
> 
> My understanding is that because they _are_ different, they are defined
> by different compatible strings. The fact that we can have a simple
> clk driver supporting all of them, using the clk-indices property to
> get the bit offsets, is beside the point.

Why is that? That's why that property is called "compatible", isn't it?
In my understanding a fallback name can be chosen exactly for that
purpose: where an existing driver for a binding is capable of handling
the new hardware. Yes, we add our new SoC specific name anyway (mostly
to be able to handle future driver fixes without changing all DTs).
But for that gates clock case we can do:
1) Add the new name to the bindings doc, mostly to mark it as used.
2) Use compatible="soc-specific", "generic"; in the DT. This is how it
nicely works for the USB host controllers, for instance.
There would be no pointless "code" change in Linux needed.

> clk-indices is used for clk name lookup through DT, when the phandle
> index is not the same as the one used for clk-output-names. We are
> slightly abusing it to get the bit offsets. It is entirely possible
> to do a clk binding without them. You would then have that information
> in the driver.

But that's not how it should work. The DT is meant to describe the
_hardware_, not the driver, especially not one particular one. And we
should avoid changing the DT just because we found that we need to
rework the Linux driver.
So having the actual bits used as indices makes a lot of sense to me.
Besides: any changes in the references would be DT internal, right? So
changing the clock ID in the bus gates node at the same time as the
clock reference in, say the MMC controller, would be quite natural and
ideally wouldn't break anything.

>> - Any clock that can (and has to) be programmed with a variable
>> frequency is expressed as an SCPI clock. This interface allows basically
>> querying and setting a frequency - not very powerful, but sufficient for
>> the clocks I checked. Firmware then takes the burden of programming the
>> respective clock register - which is not rocket science if we lock the
>> base clocks to a certain frequency.
> 
> Can it also propagate clock rate changes and reparenting such that
> we do not need to describe clock relationships in the kernel? If not
> then we still need some kind of description somewhere. And the clk
> maintainers don't seem too fond of 1 clk per node designs, which
> would allow you to describe it in the DT.

I don't see how rate changes and re-parenting shouldn't be possible with
the new approach. We just do it in firmware, which ideally owns all the
clocks. We can have comparably simple code there since firmware is by
design SoC specific, so we don't need an overly complicated and
abstracted clock framework to cover every clock on the planet.
Also we wouldn't need to expose the basic PLL clocks (like PLL_AUDIO)
themselves if that proves to be problematic, so we can change them at
firmware's discretion.

> We will run into this when we do audio and video. The module clocks
> may or may not have dividers or multiple parents. But in some cases
> you have to change the PLL clock rate, which in turn changes the clock
> rate of all the clocks under it. An example would be playing 44.1 KHz
> audio through the internal codec, which requires a different PLL clock
> rate than playing 48 KHz audio. But if at the same time you're also
> using I2S at 44.1 KHz or some multiple, you would want to know the
> clock rate is about to change, and maybe block the change.

As mentioned, I don't see a reason why this shouldn't be possible. Again
this may be even simpler, since the firmware code is expected to know
about the SoC, so we don't need to think about abstracting these
relations. We could even code a special case for this I2S/codec setup,
if that turns out to be a nasty corner case. Or we find a different
static setup from the beginning.

If you still see an issue, can you detail one example where this would
clash? I am not a clock export, so eager to learn about those cases.

> Can SCPI notify the kernel about these changes? If not you'd have
> some logic in the kernel. Splitting the logic here IMHO is not a
> good design.

Why would the kernel need to know? Those SCPI clocks have no parents
known to the kernel, and ideally we don't expose any (PLL) clock that
would need to change frequency and would be subject to reparenting.

Again, if you can show me a particular counter-example, I'd be grateful.

> 
>>
>> The advantage of this approach would be:
>> - The impact to Linux code is minimized. Normally there would be no need
>> to touch the kernel at all when we introduce a new SoC.
>> - Any other DT user can quite easily make use of the clock system
>> without adding tons of complicated Allwinner specific clock code. The
>> simple-gates driver is almost trivial to implement, and chances are SCPI
>> is already around anyway.
>> - If there are any peculiarities with a certain clock (implementation),
>> we can solve this in firmware. Fixes to code would immediately benefit
>> all users - existing kernels (from distributions), newer kernels and
>> other OSes.
> 
> Upgrading firmware is still upgrading something... I'm not sure how
> it's better.

There is supposed to be _one_ firmware for one SoC (or board), whereas
there as dozens of kernels out there - upstream plus various stable
kernels, from various distributions.
So in the worst case a fix in the kernel would have to be backported to
Debian, Ubuntu 14.04 LTS, Ubuntu 16.04 LTS, Suse, RedHat, you name it.
Also rumor has it that there are kernels beside Linux out there ;-)

>> - Having SCPI gives us simple regulators and sensors (temperature,
>> power) for free (in terms of no Linux code required). It also allows for
>> DVFS support, though this may require more work on the firmware side.
> 
> Are you arguing to move PMIC support into SCPI firmware?

Yes. We can abstract this _and_ protect the PMIC from a rogue driver or
module. Accidentally setting 3.3V to a 2.5V-only Ethernet PHY would be
no longer possible, since firmware knows that his board has a 2.5V PHY.

>> - This approach matches many of the more serious ARM64 machines out
>> there, which refrain from exposing all of their clock framework to Linux.
> 
> A quick grep through linux-next shows only the Juno platform using
> "arm,scpi-clocks". Some other consumer oriented vendors, such as
> mediatek, nvidia, qualcomm, renesas and rockchip have monolithic
> clock nodes.

Yes, SCPI at the moment is more "the Juno interface put into a spec".
But I find it quite useful and think we have to start abstracting those.
Also "the other guys do it as well" is not really a good argument, and I
mentioned that we should look more at the server SoCs than those various
"let's replace the A7s with A53s" SoCs.

>> Also this opens the door to much easier support for new SoCs - up to a
>> point where any new chip would actually run out of the box on existing
>> distributions (thinking of LTS releases here). The pinctrl driver is a
>> nasty guy around here - but let's not make it worse and try to fix that
>> guy later ;-)
> 
> Not really. You still have to write the firmware for the new SoCs,
> unless you expect Allwinner to adopt our design. And getting the new
> firmware to work with the existing bootloader (if upstream support
> isn't done yet) may be tricky, as you already went through for the
> A64.

But frankly "writing" the firmware is more like adapting an existing
version, testing and pushing this out. We don't need to go through a
lengthy process and don't have to wait for distributions to eventually
pick up the upstream kernel with the fixes merged. Look at how much less
changes U-Boot needed to run a (32-bit) version on the Pine64: a few
define's here and some ifdef's there. Then we would push this to some
firmware repository - which would be controlled by linux-sunxi. People
pick up the newest firmware from there and run an _existing_
(distribution) kernel on the board: a few weeks after the board hit some
developer. This is how x86 works (apart from that community firmware
repo) and I don't see why we shouldn't try to reach the same state for
arm (or at least arm64).

Cheers,
Andre

>> So I managed to finish a first prototype this weekend.
>> SCPI requires a mailbox and a shared memory region to work. The latter
>> is trivial, but we are lacking a proper mailbox driver for sunxi.
>> Besides that the Allwinner mailbox only works between the arisc and the
>> ARM cores, not between ARM cores or within one core in different
>> exception levels. So signalling a mailbox in EL1 and taking the IRQ in
>> EL3 does not work.
>> As a quick solution I implemented a synchronous "smc" mailbox, which
>> uses the ARM smc instruction to transfer control into firmware. Firmware
>> then reads the payload from the shared memory region, handles the
>> request and returns to EL1. We then advertise this mailbox in the SCPI
>> DT node, and the rest of the SCPI framework can happily work with that.
>> I described the clocks as mentioned above and put the MMC clocks under
>> SCPI control.
>> I put a draft DT here [2] to illustrate my ideas.
>>
>> I know this is quite controversial, so what about these following steps:
>>
>> - I polish my existing patches and send a prototype this week. We can
>> then discuss the merits and drawbacks of this approach based on the code.
>> - It it turns out that sunxi-ng is the way to go, I will test and
>> comment on this series.
>> - If we are not sure yet, we can try to go with an almost clock-less DT
>> for now (drop I2C and make UART0 use osc24M directly, for a start). This
>> would leave the door open for either approach. Or we use the
>> simple-gates only for now.
> 
> A clock-less system is quite useless. The only things that work are the
> peripherals tied to apb2, namely uarts and i2c busses. And maybe simplefb
> if you get the display pipeline working in the bootloader. This is where
> A83T has been for some time. :(
> 
> Regards
> ChenYu
> 
>>
>> I am happy to discuss this here on the list.
>>
>> Cheers,
>> Andre
>>
>> [1]
>> http://infocenter.arm.com/help/topic/com.arm.doc.dui0922g/scp_message_interface_v1_2_DUI0922G_en.pdf
>> [2] https://gist.github.com/apritzel/faa3dc5cbe7591be8c55a439f725578e
>>
>>>
>>> Let me know what you think,
>>> Maxime
>>>
>>> 1: http://lists.infradead.org/pipermail/linux-arm-kernel/2016-February/410338.html
>>>
>>> Andre Przywara (5):
>>>   arm64: sunxi: Kconfig: add essential pinctrl driver
>>>   arm64: Kconfig: sunxi: add PINCTRL
>>>   Documentation: devicetree: add vendor prefix for Pine64
>>>   arm64: dts: add Allwinner A64 SoC .dtsi
>>>   arm64: dts: add Pine64 support
>>>
>>> Maxime Ripard (8):
>>>   clk: sunxi-ng: mux: Rename mux macro to be consistent
>>>   clk: sunxi-ng: mux: Add mux table support
>>>   clk: sunxi-ng: sun8i: Rename DDR and video plls
>>>   clk: sunxi-ng: sun8i: Fix register offset
>>>   clk: sunxi-ng: sun8i: Rename H3 only clocks
>>>   clk: sunxi-ng: sun8i: Move fixed factors around
>>>   clk: sunxi-ng: sun8i: Prefix clock defines by SoC Name
>>>   clk: sunxi-ng: Add A64 clocks
>>>
>>>  Documentation/devicetree/bindings/arm/sunxi.txt    |   1 +
>>>  .../devicetree/bindings/clock/sunxi-ccu.txt        |   1 +
>>>  .../devicetree/bindings/vendor-prefixes.txt        |   1 +
>>>  MAINTAINERS                                        |   1 +
>>>  arch/arm/boot/dts/sun8i-h3.dtsi                    |  62 +-
>>>  arch/arm64/Kconfig.platforms                       |   2 +
>>>  arch/arm64/boot/dts/Makefile                       |   1 +
>>>  arch/arm64/boot/dts/allwinner/Makefile             |   5 +
>>>  .../boot/dts/allwinner/sun50i-a64-pine64-plus.dts  |  50 ++
>>>  .../arm64/boot/dts/allwinner/sun50i-a64-pine64.dts |  70 ++
>>>  arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi      | 273 +++++++
>>>  drivers/clk/sunxi-ng/Kconfig                       |  13 +-
>>>  drivers/clk/sunxi-ng/Makefile                      |   2 +-
>>>  drivers/clk/sunxi-ng/ccu-sun50i-a64.h              |  68 ++
>>>  drivers/clk/sunxi-ng/ccu-sun8i-h3.c                | 896 ++++++++++++++++-----
>>>  drivers/clk/sunxi-ng/ccu-sun8i-h3.h                |  44 +-
>>>  drivers/clk/sunxi-ng/ccu_div.h                     |   2 +-
>>>  drivers/clk/sunxi-ng/ccu_mp.h                      |   2 +-
>>>  drivers/clk/sunxi-ng/ccu_mux.c                     |  14 +
>>>  drivers/clk/sunxi-ng/ccu_mux.h                     |  29 +-
>>>  include/dt-bindings/clock/sun50i-a64-ccu.h         | 132 +++
>>>  include/dt-bindings/clock/sun8i-h3-ccu.h           | 188 ++---
>>>  include/dt-bindings/reset/sun50i-a64-ccu.h         |  97 +++
>>>  23 files changed, 1588 insertions(+), 366 deletions(-)
>>>  create mode 100644 arch/arm64/boot/dts/allwinner/Makefile
>>>  create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-plus.dts
>>>  create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
>>>  create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
>>>  create mode 100644 drivers/clk/sunxi-ng/ccu-sun50i-a64.h
>>>  create mode 100644 include/dt-bindings/clock/sun50i-a64-ccu.h
>>>  create mode 100644 include/dt-bindings/reset/sun50i-a64-ccu.h
>>>
> 

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [PATCH 00/13] arm64: Allwinner A64 support based on sunxi-ng
  2016-08-01  1:43 ` André Przywara
  2016-08-01  8:30   ` Jean-Francois Moine
  2016-08-01  9:11   ` Chen-Yu Tsai
@ 2016-08-23 19:31   ` Maxime Ripard
  2016-08-24 23:54     ` André Przywara
  2 siblings, 1 reply; 34+ messages in thread
From: Maxime Ripard @ 2016-08-23 19:31 UTC (permalink / raw)
  To: André Przywara
  Cc: Rob Herring, Chen-Yu Tsai, Mike Turquette, Stephen Boyd,
	devicetree, linux-arm-kernel, linux-kernel, linux-clk

[-- Attachment #1: Type: text/plain, Size: 7809 bytes --]

Hi Andre,

On Mon, Aug 01, 2016 at 02:43:06AM +0100, André Przywara wrote:
> Hi Maxime,
> 
> On 26/07/16 21:30, Maxime Ripard wrote:
> > Hi,
> > 
> > Here is the previous A64 patches made by Andre [1], reworked to use
> > the new sunxi-ng clock framework.
> > 
> > This uses the current H3 clock code, as both are really similar. The
> > first patches are just meant to rework slightly the H3 code, before
> > introducing the A64-related patches.
> > 
> > Some WiP stuff have been removed, such as the MMC part, but this serie
> > already has a decent amount of devices supported: uart, i2c, rsb, etc.
> 
> Thanks very much for looking into this and compiling this series!
> 
> In general this looks good to me - apart from the sunxi-ng clock usage.
> I think I have some small fixes to the DT (have to compare against my
> latest local branch), I will comment on this later.
> 
> As I think I never officially expressed my concerns about the new sunxi
> clock system, so I use that opportunity here ;-)
> 
> As this became quite a long read, here a TL;DR:
> - We consider using an SCPI based clock system for the A64, alongside
> allwinner,simple-gates and fixed clocks. We try to avoid any Allwinner
> specific clocks (apart from the simple-gates).
> - ARM Trusted Firmware provides the SCPI implementation - for now, later
> we may move this into a possible arisc firmware.
> - We upstream some basic DT first, possibly omitting any controversial
> clock parts at all.
> 
> Let me know what you think!
> 
> 
> Now the long part ....
> 
> Basically I see those issues with the new clocks:
> - sunxi-ng requires a complicated SoC specific source file in the
> kernel. Although that makes the DT pretty easy (and avoids breaking it
> the future), it ultimately requires an explicit code drop for every new
> SoC, even if they share 95% of the clocks (as H3 and A64 do, for instance).
> - This code file does not actually contain any code, instead it's just
> data and looks like it should really be presented in DT - which brings
> us back to something like the old sunxi clock scheme, which is
> apparently not considered good enough. I still wonder if we could create
> a generic sunxi-ng user, which explains the needed clocks in the DT
> instead of in code. I admit that looks like quite some work.
> - It makes it quite hard for any other DT user (*BSD, U-Boot) to use the
> clocks, since they would have to copy quite verbatim the Linux
> implementation choice. This is admittedly also true for the old clock
> framework, but still unfortunate.

3 - You never get a complete clock support for any SoC, requirining
    for pretty much every driver to create from scratch a new clock
    driver.

4 - You require for all these clocks drivers some Ack from both the DT
    and clocks maintainers, who both said they were fed up with this.

5 - If you realise some day down the road that the parenting
    relationship is not right, or that some clock is not doing what
    you thought it was, you can't really fix it properly because of
    the DT stability you wanted us to enforce.

> So as mentioned several times before, I am looking into a more firmware
> driven clock system using the SCPI[1] framework.
> The idea is:
> - The basic clocks (OSC24M, OSC32K, AHB1, APB1, APB2, PERIPH0) are
> expressed as fixed clocks. If I am not mistaken, Allwinner recommends
> certain frequencies for them anyway, so we just use that and set them up
> before booting Linux, for instance in ATF.
> - The gates clocks are expressed as before, but by defining a generic DT
> compatible fallback name. I have no idea why every SoC enters its name
> into the simple_gates.c source file, while just mentioning the
> compatible string in the DT bindings and using the SoC specific name
> together with a generic fallback like "allwinner,sunxi-simple-gates"
> would suffice. This means that we don't need to touch simple-gates.c
> anymore most of the time.
> - Any clock that can (and has to) be programmed with a variable
> frequency is expressed as an SCPI clock. This interface allows basically
> querying and setting a frequency - not very powerful, but sufficient for
> the clocks I checked. Firmware then takes the burden of programming the
> respective clock register - which is not rocket science if we lock the
> base clocks to a certain frequency.
> 
> The advantage of this approach would be:
> - The impact to Linux code is minimized. Normally there would be no need
> to touch the kernel at all when we introduce a new SoC.

But you duplicate the clock framework entirely, both the core code and
the data you were complaining about, with all the issues that arise
from code duplication. You still have to create that big file you were
complaining about, with exactly the same constraints.

> - Any other DT user can quite easily make use of the clock system
> without adding tons of complicated Allwinner specific clock code. The
> simple-gates driver is almost trivial to implement, and chances are SCPI
> is already around anyway.
> - If there are any peculiarities with a certain clock (implementation),
> we can solve this in firmware. Fixes to code would immediately benefit
> all users - existing kernels (from distributions), newer kernels and
> other OSes.

But no-one would actually be able to use it, because no one upgrades
its firmware, including all the major distributions (Debian, Ubuntu,
Fedora, OpenWRT, Arch, Gento, you name it). So there's effectively no
way to fix a bug that was there.

> - Having SCPI gives us simple regulators and sensors (temperature,
> power) for free (in terms of no Linux code required). It also allows for
> DVFS support, though this may require more work on the firmware side.

And ignoring all the other features that the PMIC support, and the
board uses out there (GPIO, ADCs, Power supplies, battery charger, USB
VBUS monitoring)

> - This approach matches many of the more serious ARM64 machines out
> there, which refrain from exposing all of their clock framework to Linux.

$ git grep -l scpi arch/arm64/boot/dts/**.dtsi
arch/arm64/boot/dts/arm/juno-base.dtsi

Are you saying that only Juno is a serious ARM64 machine?

> Also this opens the door to much easier support for new SoCs - up to a
> point where any new chip would actually run out of the box on existing
> distributions (thinking of LTS releases here). The pinctrl driver is a
> nasty guy around here - but let's not make it worse and try to fix that
> guy later ;-)

That's not true and you know it.

What you actually suggest is to implement a minimal set of clocks in
ATF (the opposite being, the entire set of clocks, which would of
course be untested, so it basically falls down in the exact same
category).

What this means is that, since we will obviously not support all the
clocks client from day one, any user will be *required* for a new
kernel release to operate as it's expected to upgrade the ATF.

Without any help from the distribution (s)he's running, because no one
has that kind of scenario in mind. And let's be honest, I don't see
Ubuntu changing the dependencies for the kernel for the Allwinner SoCs
alone (let alone the fact that it's pretty much impossible in a
generic way to know where and how the ATF is installed).

Apart from being a major pain for any user, upgrading the bootloader
is also a showstopper for most industries.

So, no, we won't do that. The A64 support is something we actually
want to use in real-life products, and our users to be happy with the
support they have.

NAK.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [PATCH 00/13] arm64: Allwinner A64 support based on sunxi-ng
  2016-08-23 19:31   ` Maxime Ripard
@ 2016-08-24 23:54     ` André Przywara
  2016-08-26 22:18       ` Maxime Ripard
  0 siblings, 1 reply; 34+ messages in thread
From: André Przywara @ 2016-08-24 23:54 UTC (permalink / raw)
  To: Maxime Ripard
  Cc: Rob Herring, Chen-Yu Tsai, Mike Turquette, Stephen Boyd,
	devicetree, linux-arm-kernel, linux-kernel, linux-clk

Hi Maxime,

thanks for your answer, much appreciated!

On 23/08/16 20:31, Maxime Ripard wrote:
> Hi Andre,
> 
> On Mon, Aug 01, 2016 at 02:43:06AM +0100, André Przywara wrote:
>> Hi Maxime,
>>
>> On 26/07/16 21:30, Maxime Ripard wrote:
>>> Hi,
>>>
>>> Here is the previous A64 patches made by Andre [1], reworked to use
>>> the new sunxi-ng clock framework.
>>>
>>> This uses the current H3 clock code, as both are really similar. The
>>> first patches are just meant to rework slightly the H3 code, before
>>> introducing the A64-related patches.
>>>
>>> Some WiP stuff have been removed, such as the MMC part, but this serie
>>> already has a decent amount of devices supported: uart, i2c, rsb, etc.
>>
>> Thanks very much for looking into this and compiling this series!
>>
>> In general this looks good to me - apart from the sunxi-ng clock usage.
>> I think I have some small fixes to the DT (have to compare against my
>> latest local branch), I will comment on this later.
>>
>> As I think I never officially expressed my concerns about the new sunxi
>> clock system, so I use that opportunity here ;-)
>>
>> As this became quite a long read, here a TL;DR:
>> - We consider using an SCPI based clock system for the A64, alongside
>> allwinner,simple-gates and fixed clocks. We try to avoid any Allwinner
>> specific clocks (apart from the simple-gates).
>> - ARM Trusted Firmware provides the SCPI implementation - for now, later
>> we may move this into a possible arisc firmware.
>> - We upstream some basic DT first, possibly omitting any controversial
>> clock parts at all.
>>
>> Let me know what you think!
>>
>>
>> Now the long part ....
>>
>> Basically I see those issues with the new clocks:
>> - sunxi-ng requires a complicated SoC specific source file in the
>> kernel. Although that makes the DT pretty easy (and avoids breaking it
>> the future), it ultimately requires an explicit code drop for every new
>> SoC, even if they share 95% of the clocks (as H3 and A64 do, for instance).
>> - This code file does not actually contain any code, instead it's just
>> data and looks like it should really be presented in DT - which brings
>> us back to something like the old sunxi clock scheme, which is
>> apparently not considered good enough. I still wonder if we could create
>> a generic sunxi-ng user, which explains the needed clocks in the DT
>> instead of in code. I admit that looks like quite some work.
>> - It makes it quite hard for any other DT user (*BSD, U-Boot) to use the
>> clocks, since they would have to copy quite verbatim the Linux
>> implementation choice. This is admittedly also true for the old clock
>> framework, but still unfortunate.
> 
> 3 - You never get a complete clock support for any SoC, requirining
>     for pretty much every driver to create from scratch a new clock
>     driver.

I don't understand this. Are you referring to the old clock system? Or
to the proposed SCPI approach? Or to sunxi-ng with DT descriptions?

And why would a *driver* care about a specific clock if it's using the
common clock framework?
Confused ...

> 4 - You require for all these clocks drivers some Ack from both the DT
>     and clocks maintainers, who both said they were fed up with this.

Again which new clock drivers? The old sunxi-clks?
For the SCPI version I propose we don't need any ACKs (apart from the
new .dtsi, maybe), because the clocks are already there.

> 5 - If you realise some day down the road that the parenting
>     relationship is not right, or that some clock is not doing what
>     you thought it was, you can't really fix it properly because of
>     the DT stability you wanted us to enforce.
> 
>> So as mentioned several times before, I am looking into a more firmware
>> driven clock system using the SCPI[1] framework.
>> The idea is:
>> - The basic clocks (OSC24M, OSC32K, AHB1, APB1, APB2, PERIPH0) are
>> expressed as fixed clocks. If I am not mistaken, Allwinner recommends
>> certain frequencies for them anyway, so we just use that and set them up
>> before booting Linux, for instance in ATF.
>> - The gates clocks are expressed as before, but by defining a generic DT
>> compatible fallback name. I have no idea why every SoC enters its name
>> into the simple_gates.c source file, while just mentioning the
>> compatible string in the DT bindings and using the SoC specific name
>> together with a generic fallback like "allwinner,sunxi-simple-gates"
>> would suffice. This means that we don't need to touch simple-gates.c
>> anymore most of the time.
>> - Any clock that can (and has to) be programmed with a variable
>> frequency is expressed as an SCPI clock. This interface allows basically
>> querying and setting a frequency - not very powerful, but sufficient for
>> the clocks I checked. Firmware then takes the burden of programming the
>> respective clock register - which is not rocket science if we lock the
>> base clocks to a certain frequency.
>>
>> The advantage of this approach would be:
>> - The impact to Linux code is minimized. Normally there would be no need
>> to touch the kernel at all when we introduce a new SoC.
> 
> But you duplicate the clock framework entirely, both the core code and
> the data you were complaining about, with all the issues that arise
> from code duplication. You still have to create that big file you were
> complaining about, with exactly the same constraints.

We don't need to comply with some common clock framework in firmware, we
just need to provide implementations for specific clocks. From a
maintainer's point of view the CCF is nice, but its implementation is
quite complicated and hard to understand for mere mortals. Also tweaking
a particular clock is not easy, as it has to fit into the framework and
we may miss the interfaces.

See the MMC clock implementation for instance: it's just a simple
divider clock. My implementation in ATF is probably bad and stupid, but
at the end of the day I just have to provide a way to set a frequency of
one single clock.
I think we win a lot if we go away from possibly tuning the parent's
clocks (AHB, PLL6 & friends), instead leaving them as fixed clocks - my
understanding is that Allwinner recommends this anyway. Then the whole
complex clock tree degrades into just a bunch of more or less
independent clock registers.
Also we can go with a much easier implementation, since we don't need to
support all clocks in one image, but just the clocks for one particular
SoC. This brings the complexity down, so we can get away with a much
simpler implementation (compare U-Boot, though this isn't the best
example, admittedly).

>> - Any other DT user can quite easily make use of the clock system
>> without adding tons of complicated Allwinner specific clock code. The
>> simple-gates driver is almost trivial to implement, and chances are SCPI
>> is already around anyway.
>> - If there are any peculiarities with a certain clock (implementation),
>> we can solve this in firmware. Fixes to code would immediately benefit
>> all users - existing kernels (from distributions), newer kernels and
>> other OSes.
> 
> But no-one would actually be able to use it, because no one upgrades
> its firmware, including all the major distributions (Debian, Ubuntu,
> Fedora, OpenWRT, Arch, Gento, you name it). So there's effectively no
> way to fix a bug that was there.

But currently distributions do upgrade U-Boot, don't they? ATF would be
part of a FIT image, compiled alongside U-Boot and included in one image
with the SPL and the U-Boot proper. In the Allwinner world with firmware
on SD cards or in eMMC I don't see big issues.
Also honestly I don't expect frequent updates. Yes: in the beginning we
may have changes, but at some point we make a (tested) release and maybe
publish updates every now and then. Either these updates fix bugs or
provide new features, so there is some incentive for users to update. Or
they don't care, in which case it may just work for them and they keep
using the old version.

>> - Having SCPI gives us simple regulators and sensors (temperature,
>> power) for free (in terms of no Linux code required). It also allows for
>> DVFS support, though this may require more work on the firmware side.
> 
> And ignoring all the other features that the PMIC support, and the
> board uses out there (GPIO, ADCs, Power supplies, battery charger, USB
> VBUS monitoring)

Replying to that in that other email ...

>> - This approach matches many of the more serious ARM64 machines out
>> there, which refrain from exposing all of their clock framework to Linux.
> 
> $ git grep -l scpi arch/arm64/boot/dts/**.dtsi
> arch/arm64/boot/dts/arm/juno-base.dtsi
> 
> Are you saying that only Juno is a serious ARM64 machine?

I wasn't referring to SCPI in particular (which is indeed used only by
Juno at the moment), but about not exposing the actual internal clock
layout to Linux. PCs certainly don't, but also AMD Seattle and ThunderX
avoid this.

>> Also this opens the door to much easier support for new SoCs - up to a
>> point where any new chip would actually run out of the box on existing
>> distributions (thinking of LTS releases here). The pinctrl driver is a
>> nasty guy around here - but let's not make it worse and try to fix that
>> guy later ;-)
> 
> That's not true and you know it.
> 
> What you actually suggest is to implement a minimal set of clocks in
> ATF (the opposite being, the entire set of clocks, which would of
> course be untested, so it basically falls down in the exact same
> category).
> 
> What this means is that, since we will obviously not support all the
> clocks client from day one, any user will be *required* for a new
> kernel release to operate as it's expected to upgrade the ATF.

I don't see that these are related - unless you consider the DT part of
the kernel - which it clearly isn't (although the current scheme of DT
updates suggests this). Actually the firmware should provide the DT,
just advertising all the clocks it implements.
And as I don't expect implementing an isolated clock as an SCPI clock to
be rocket science, I'd hope for the error rate to be minimal.
So we may publish an early firmware version with support for certain
devices only and later upgrade this. U-Boot gets also upgraded via the
distributions at the moment. We could even introduce some firmware
upgrade infrastructure (or use the Linux one) if we find us in dire need
for.

> Without any help from the distribution (s)he's running, because no one
> has that kind of scenario in mind. And let's be honest, I don't see
> Ubuntu changing the dependencies for the kernel for the Allwinner SoCs
> alone (let alone the fact that it's pretty much impossible in a
> generic way to know where and how the ATF is installed).

Again how does this differ from U-Boot, which I consider firmware as
well and which is handled by the distributions (although I don't like
this approach very much, because it pushes hardware support to Linux
vendors).

> Apart from being a major pain for any user, upgrading the bootloader
> is also a showstopper for most industries.
> 
> So, no, we won't do that. The A64 support is something we actually
> want to use in real-life products, and our users to be happy with the
> support they have.

I can understand that we can just do what we did in the past: Spoon feed
every new SoC as soon as we get our hands on some boards and explicitly
add support for it in the Linux kernel.
But I'd like to revisit this approach, as it actually takes quite some
time for support to trickle in down the kernel road - especially if we
look at major distributions (think LTS).
If we can get closer to a state were new SoCs just require appropriate
firmware and a DT - without any new kernel code - I see a big
opportunity to get much quicker support for new SoCs - up to a point
where the firmware is the only thing that's needed. Maybe some day the
board vendors provide these firmware bits even, who knows?

Another thing that strikes me: Currently we have strict per-SoC pinctrl
drivers, which is unfortunate. But now we are adding new clock
_descriptions_ for new SoCs as well, partly degrading the DT to a mere
"board file selector". IIRC Linus complained about those numerous clock
updates for ARM boards back then in his big ARM rant, I am just afraid
that we go back to this state, bloating the kernel with SoC specific
clock details - that it not necessarily needs to know about. In the end
the kernel just wants to program this MMC clock to 52 MHz.

> 
> NAK.

Cheers,
Andre.

P.S. I am cowardly leaving for a few days off after hitting the Send
button, so don't expect immediate replies.

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [PATCH 00/13] arm64: Allwinner A64 support based on sunxi-ng
  2016-08-24 23:54     ` André Przywara
@ 2016-08-26 22:18       ` Maxime Ripard
  0 siblings, 0 replies; 34+ messages in thread
From: Maxime Ripard @ 2016-08-26 22:18 UTC (permalink / raw)
  To: André Przywara
  Cc: Rob Herring, Chen-Yu Tsai, Mike Turquette, Stephen Boyd,
	devicetree, linux-arm-kernel, linux-kernel, linux-clk

[-- Attachment #1: Type: text/plain, Size: 15657 bytes --]

On Thu, Aug 25, 2016 at 12:54:14AM +0100, André Przywara wrote:
> >> Now the long part ....
> >>
> >> Basically I see those issues with the new clocks:
> >> - sunxi-ng requires a complicated SoC specific source file in the
> >> kernel. Although that makes the DT pretty easy (and avoids breaking it
> >> the future), it ultimately requires an explicit code drop for every new
> >> SoC, even if they share 95% of the clocks (as H3 and A64 do, for instance).
> >> - This code file does not actually contain any code, instead it's just
> >> data and looks like it should really be presented in DT - which brings
> >> us back to something like the old sunxi clock scheme, which is
> >> apparently not considered good enough. I still wonder if we could create
> >> a generic sunxi-ng user, which explains the needed clocks in the DT
> >> instead of in code. I admit that looks like quite some work.
> >> - It makes it quite hard for any other DT user (*BSD, U-Boot) to use the
> >> clocks, since they would have to copy quite verbatim the Linux
> >> implementation choice. This is admittedly also true for the old clock
> >> framework, but still unfortunate.
> > 
> > 3 - You never get a complete clock support for any SoC, requirining
> >     for pretty much every driver to create from scratch a new clock
> >     driver.
> 
> I don't understand this. Are you referring to the old clock system? Or
> to the proposed SCPI approach? Or to sunxi-ng with DT descriptions?

I was referring here to the old clock system.

> And why would a *driver* care about a specific clock if it's using the
> common clock framework?
> Confused ...

Because a driver drives an IP that is fed by a specific clock, and
those clocks entirely change from one controller to the other, and
from one SoC to the other.

So we were in a situation where you had to write that clock driver
before doing something useful, and then debug because obviously it was
not written properly. This is not acceptable.

> > 4 - You require for all these clocks drivers some Ack from both the DT
> >     and clocks maintainers, who both said they were fed up with this.
> 
> Again which new clock drivers? The old sunxi-clks?

Old clks. I was under the impression that you were advocating against
sunxi-ng here, and your patches were using the old system. Sorry if I
mixed things up. Obviously, that wouldn't happen with SCPI.

> For the SCPI version I propose we don't need any ACKs (apart from the
> new .dtsi, maybe), because the clocks are already there.
> 
> > 5 - If you realise some day down the road that the parenting
> >     relationship is not right, or that some clock is not doing what
> >     you thought it was, you can't really fix it properly because of
> >     the DT stability you wanted us to enforce.
> > 
> >> So as mentioned several times before, I am looking into a more firmware
> >> driven clock system using the SCPI[1] framework.
> >> The idea is:
> >> - The basic clocks (OSC24M, OSC32K, AHB1, APB1, APB2, PERIPH0) are
> >> expressed as fixed clocks. If I am not mistaken, Allwinner recommends
> >> certain frequencies for them anyway, so we just use that and set them up
> >> before booting Linux, for instance in ATF.
> >> - The gates clocks are expressed as before, but by defining a generic DT
> >> compatible fallback name. I have no idea why every SoC enters its name
> >> into the simple_gates.c source file, while just mentioning the
> >> compatible string in the DT bindings and using the SoC specific name
> >> together with a generic fallback like "allwinner,sunxi-simple-gates"
> >> would suffice. This means that we don't need to touch simple-gates.c
> >> anymore most of the time.
> >> - Any clock that can (and has to) be programmed with a variable
> >> frequency is expressed as an SCPI clock. This interface allows basically
> >> querying and setting a frequency - not very powerful, but sufficient for
> >> the clocks I checked. Firmware then takes the burden of programming the
> >> respective clock register - which is not rocket science if we lock the
> >> base clocks to a certain frequency.
> >>
> >> The advantage of this approach would be:
> >> - The impact to Linux code is minimized. Normally there would be no need
> >> to touch the kernel at all when we introduce a new SoC.
> > 
> > But you duplicate the clock framework entirely, both the core code and
> > the data you were complaining about, with all the issues that arise
> > from code duplication. You still have to create that big file you were
> > complaining about, with exactly the same constraints.
> 
> We don't need to comply with some common clock framework in firmware, we
> just need to provide implementations for specific clocks. From a
> maintainer's point of view the CCF is nice, but its implementation is
> quite complicated and hard to understand for mere mortals.

Well, it might just be because "dealing with clocks is hard"? And you
would have to reimplement at least part of it anyway.

> Also tweaking a particular clock is not easy, as it has to fit into
> the framework and we may miss the interfaces.

Then add the interface. We do that on a regular basis, and Mike and
Stephen are usually open to it if it's relevant.

> See the MMC clock implementation for instance: it's just a simple
> divider clock. My implementation in ATF is probably bad and stupid, but
> at the end of the day I just have to provide a way to set a frequency of
> one single clock.

For all clock rates that are possible on MMC? With DDR? I seriously
doubt this will be stupid.

> I think we win a lot if we go away from possibly tuning the parent's
> clocks (AHB, PLL6 & friends), instead leaving them as fixed clocks - my
> understanding is that Allwinner recommends this anyway.

Being a fixed clock doesn't help. We had the issue in the past where
we actually had to change those rates to have DMA working (A31's AHB),
or simply because the rate was bad (A13's pll5). A fixed clock removes
that possibility. However, a clock properly modelled can.

Which doesn't mean that we would change it (and we don't!).

> Then the whole complex clock tree degrades into just a bunch of more
> or less independent clock registers.
>
> Also we can go with a much easier implementation, since we don't need to
> support all clocks in one image, but just the clocks for one particular
> SoC. This brings the complexity down, so we can get away with a much
> simpler implementation (compare U-Boot, though this isn't the best
> example, admittedly).

Yeah, ignoring 95% of the problem is usually a very efficient way to
simplify it. Now, throw the audio clocks, the pixel clocks, the SPI
clocks, the camera clocks, the GPU clocks. Had some frequency change
for all of them, with some weird frequencies for the pixel clocks to
deal with all the panels out there, and see how it goes.

For example, during the A13 DRM development, we had to support
changing from TV-out to the panel output. In order to generate the
right frequencies, we had to change the rate of 4 clocks with a direct
relationship, and try to come up with a combination of these four
clocks that would generate the right frequency.

This is trivial with the CCF. Yes, it's complex, but the complexity is
here for a reason. Otherwise no-one would use it (yet everyone does).

> >> - Any other DT user can quite easily make use of the clock system
> >> without adding tons of complicated Allwinner specific clock code. The
> >> simple-gates driver is almost trivial to implement, and chances are SCPI
> >> is already around anyway.
> >> - If there are any peculiarities with a certain clock (implementation),
> >> we can solve this in firmware. Fixes to code would immediately benefit
> >> all users - existing kernels (from distributions), newer kernels and
> >> other OSes.
> > 
> > But no-one would actually be able to use it, because no one upgrades
> > its firmware, including all the major distributions (Debian, Ubuntu,
> > Fedora, OpenWRT, Arch, Gento, you name it). So there's effectively no
> > way to fix a bug that was there.
> 
> But currently distributions do upgrade U-Boot, don't they?

Debian Jessie has a package with U-Boot 2014.10. I don't even know how
they can install it, since there's no generic way to do it.

Fedora, Arch, Gentoo don't have a package.
OpenWRT is made to run on whatever bootloader comes on the board.

So no, really, they don't.

> ATF would be part of a FIT image, compiled alongside U-Boot and
> included in one image with the SPL and the U-Boot proper. In the
> Allwinner world with firmware on SD cards or in eMMC I don't see big
> issues.

And on NAND? SPI-NOR? And on which MMC card would you install it?

> Also honestly I don't expect frequent updates. Yes: in the beginning we
> may have changes, but at some point we make a (tested) release and maybe
> publish updates every now and then. Either these updates fix bugs or
> provide new features, so there is some incentive for users to update. Or
> they don't care, in which case it may just work for them and they keep
> using the old version.

Judging from the past experience, in 4 years, we haven't been able to
complete a single clock tree. And by complete, I mean with all the
clocks defined, and tested properly. This will be much easier with
sunxi-ng, but really, don't count on having everything that works
after a short while.

Even if you have all the clocks exposed quite soon, we don't have any
driver to test them.

So what you suggest is to actually upgrade the bootloader each time,
for the foreseeable future. And that alone is a showstopper.

> >> - This approach matches many of the more serious ARM64 machines out
> >> there, which refrain from exposing all of their clock framework to Linux.
> > 
> > $ git grep -l scpi arch/arm64/boot/dts/**.dtsi
> > arch/arm64/boot/dts/arm/juno-base.dtsi
> > 
> > Are you saying that only Juno is a serious ARM64 machine?
> 
> I wasn't referring to SCPI in particular (which is indeed used only by
> Juno at the moment), but about not exposing the actual internal clock
> layout to Linux. PCs certainly don't, but also AMD Seattle and ThunderX
> avoid this.

I don't need to upgrade my BIOS or UEFI on my PC everytime I get a new
kernel release to have everything working as it should.

And I'm guessing both ThunderX and Seattle had an army of engineers
working on that firmware, and testing every last bit of it.

If we also had such a firmware, I would be all in. But we don't, and
we can't in a reasonable (less than a month) timeframe. It really
boils down to this. This has been stalled for something like 6 monthes
now, waiting for solutions that might or might not happen (and I know
I have my share of responsibilities in this). But I don't want to wait
any longer.

> >> Also this opens the door to much easier support for new SoCs - up to a
> >> point where any new chip would actually run out of the box on existing
> >> distributions (thinking of LTS releases here). The pinctrl driver is a
> >> nasty guy around here - but let's not make it worse and try to fix that
> >> guy later ;-)
> > 
> > That's not true and you know it.
> > 
> > What you actually suggest is to implement a minimal set of clocks in
> > ATF (the opposite being, the entire set of clocks, which would of
> > course be untested, so it basically falls down in the exact same
> > category).
> > 
> > What this means is that, since we will obviously not support all the
> > clocks client from day one, any user will be *required* for a new
> > kernel release to operate as it's expected to upgrade the ATF.
> 
> I don't see that these are related - unless you consider the DT part of
> the kernel - which it clearly isn't (although the current scheme of DT
> updates suggests this). Actually the firmware should provide the DT,
> just advertising all the clocks it implements.

I consider my firmware just like you consider your DT: I really like
the fact that I can go with _one_ known best firmware.

> And as I don't expect implementing an isolated clock as an SCPI clock to
> be rocket science, I'd hope for the error rate to be minimal.

I'm more pessimistic than you are on this, but even with that
assumption, the point still holds: you cannot support all the clocks
from day one.

> So we may publish an early firmware version with support for certain
> devices only and later upgrade this. U-Boot gets also upgraded via the
> distributions at the moment.

Like I said, this is not true.

> We could even introduce some firmware upgrade infrastructure (or use
> the Linux one) if we find us in dire need for.

And I want something that works *today*, not some blurry thing that
redhat, fedora and debian might or might not help us with at some
point in a vague future.

> > Without any help from the distribution (s)he's running, because no one
> > has that kind of scenario in mind. And let's be honest, I don't see
> > Ubuntu changing the dependencies for the kernel for the Allwinner SoCs
> > alone (let alone the fact that it's pretty much impossible in a
> > generic way to know where and how the ATF is installed).
> 
> Again how does this differ from U-Boot, which I consider firmware as
> well and which is handled by the distributions (although I don't like
> this approach very much, because it pushes hardware support to Linux
> vendors).

U-boot configuration is mostly static. The video modes are always the
same. You don't have to do any arbitration between devices. You don't
have audio. It's totally fine for a firmware, but you need something
more advanced in the kernel.

> 
> > Apart from being a major pain for any user, upgrading the bootloader
> > is also a showstopper for most industries.
> > 
> > So, no, we won't do that. The A64 support is something we actually
> > want to use in real-life products, and our users to be happy with the
> > support they have.
> 
> I can understand that we can just do what we did in the past: Spoon feed
> every new SoC as soon as we get our hands on some boards and explicitly
> add support for it in the Linux kernel.
> But I'd like to revisit this approach, as it actually takes quite some
> time for support to trickle in down the kernel road - especially if we
> look at major distributions (think LTS).
> If we can get closer to a state were new SoCs just require appropriate
> firmware and a DT - without any new kernel code - I see a big
> opportunity to get much quicker support for new SoCs - up to a point
> where the firmware is the only thing that's needed. Maybe some day the
> board vendors provide these firmware bits even, who knows?

I understand the need for ARM to find a technical showcase
platform. What I don't understand is why I should feel the pain of
going against the current, and waiting for suffering to (maybe) stop
at some point in the future.

That goal is very noble. I'm under the impression that it's the kind
of soft-lobbying that Marc wanted to do with PSCI too, that we were
basically the first one to implement. And it worked for us because it
worked from day one, and it was an all or nothing.

What you suggest is an entire different story.

Please speak to the vendors, make them provide those firmwares. I'll
be more than happy to switch to them then.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

^ permalink raw reply	[flat|nested] 34+ messages in thread

end of thread, other threads:[~2016-09-09 20:04 UTC | newest]

Thread overview: 34+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-07-26 20:30 [PATCH 00/13] arm64: Allwinner A64 support based on sunxi-ng Maxime Ripard
2016-07-26 20:30 ` [PATCH 01/13] clk: sunxi-ng: mux: Rename mux macro to be consistent Maxime Ripard
2016-07-26 20:30 ` [PATCH 02/13] clk: sunxi-ng: mux: Add mux table support Maxime Ripard
2016-07-26 20:30 ` [PATCH 03/13] clk: sunxi-ng: sun8i: Rename DDR and video plls Maxime Ripard
2016-07-27  7:57   ` kbuild test robot
2016-07-26 20:30 ` [PATCH 04/13] clk: sunxi-ng: sun8i: Fix register offset Maxime Ripard
2016-07-26 20:30 ` [PATCH 05/13] clk: sunxi-ng: sun8i: Rename H3 only clocks Maxime Ripard
2016-07-26 20:30 ` [PATCH 06/13] clk: sunxi-ng: sun8i: Move fixed factors around Maxime Ripard
2016-07-26 20:30 ` [PATCH 07/13] clk: sunxi-ng: sun8i: Prefix clock defines by SoC Name Maxime Ripard
2016-07-26 20:30 ` [PATCH 08/13] clk: sunxi-ng: Add A64 clocks Maxime Ripard
2016-07-29 21:15   ` Rob Herring
2016-07-26 20:30 ` [PATCH 09/13] arm64: sunxi: Kconfig: add essential pinctrl driver Maxime Ripard
2016-07-26 20:30 ` [PATCH 10/13] arm64: Kconfig: sunxi: add PINCTRL Maxime Ripard
2016-07-26 20:30 ` [PATCH 11/13] Documentation: devicetree: add vendor prefix for Pine64 Maxime Ripard
2016-07-26 20:30 ` [PATCH 12/13] arm64: dts: add Allwinner A64 SoC .dtsi Maxime Ripard
2016-09-08  8:41   ` Andre Przywara
2016-09-09 20:04     ` Maxime Ripard
2016-07-26 20:30 ` [PATCH 13/13] arm64: dts: add Pine64 support Maxime Ripard
2016-07-27  8:46 ` [PATCH 00/13] arm64: Allwinner A64 support based on sunxi-ng Jean-Francois Moine
2016-07-28 20:07   ` Maxime Ripard
2016-07-29  5:48     ` Jean-Francois Moine
2016-07-31  8:51       ` Maxime Ripard
2016-08-01  1:43 ` André Przywara
2016-08-01  8:30   ` Jean-Francois Moine
2016-08-01  9:13     ` Chen-Yu Tsai
2016-08-01 12:00       ` Jean-Francois Moine
2016-08-01 12:01         ` Chen-Yu Tsai
2016-08-01 12:11           ` Jean-Francois Moine
2016-08-01 10:44     ` Andre Przywara
2016-08-01  9:11   ` Chen-Yu Tsai
2016-08-11  0:36     ` André Przywara
2016-08-23 19:31   ` Maxime Ripard
2016-08-24 23:54     ` André Przywara
2016-08-26 22:18       ` Maxime Ripard

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).