[PATCH v2 0/3] meson-gx: Add mali-450 support

[PATCH v2 0/3] meson-gx: Add mali-450 support

[Neil Armstrong]

Since the merge of the Mali dt bindings at [1], add support for Mali clocks
and DT node.

The Mali is clocked by two identical clock paths behind a glitch free mux
to safely change frequency while running.
So these clocks must be added to the meson-gxbb clock controller.

Changes since v1 at [2] :
 - Remove GP0 fixes, this will pushed later, for base frequency it can depend on fclk_div3
 - Add GXL support
 - rebase on clk-next and jbrunet's patchset at [3] and [4]
 - get rid of composite clocks, this adds more clocks IDs and exposes 2 more clocks

[4] http://lkml.kernel.org/r/20170228093016.5624-1-jbrunet@baylibre.com
[3] http://lkml.kernel.org/r/20170228133002.17894-1-jbrunet@baylibre.com
[2] http://lkml.kernel.org/r/1486721084-1383-1-git-send-email-narmstrong@baylibre.com
[1] http://lkml.kernel.org/r/b098c4fa9fce88361cca20417978734d0e1b5cca.1485939041.git-series.maxime.ripard@free-electrons.com

Neil Armstrong (3):
  clk: meson-gxbb: Add MALI clock IDS
  clk: meson-gxbb: Add MALI clocks
  ARM64: dts: meson-gx: Add MALI nodes for GXBB and GXL

 arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi      |  37 ++++++
 arch/arm64/boot/dts/amlogic/meson-gxl-mali.dtsi  |  43 +++++++
 arch/arm64/boot/dts/amlogic/meson-gxl-s905d.dtsi |   1 +
 arch/arm64/boot/dts/amlogic/meson-gxl-s905x.dtsi |   1 +
 drivers/clk/meson/gxbb.c                         | 139 +++++++++++++++++++++++
 drivers/clk/meson/gxbb.h                         |   9 +-
 include/dt-bindings/clock/gxbb-clkc.h            |   5 +
 7 files changed, 234 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm64/boot/dts/amlogic/meson-gxl-mali.dtsi

-- 
1.9.1

[PATCH v2 0/3] meson-gx: Add mali-450 support

[Neil Armstrong]

Since the merge of the Mali dt bindings at [1], add support for Mali clocks
and DT node.

The Mali is clocked by two identical clock paths behind a glitch free mux
to safely change frequency while running.
So these clocks must be added to the meson-gxbb clock controller.

Changes since v1 at [2] :
 - Remove GP0 fixes, this will pushed later, for base frequency it can depend on fclk_div3
 - Add GXL support
 - rebase on clk-next and jbrunet's patchset at [3] and [4]
 - get rid of composite clocks, this adds more clocks IDs and exposes 2 more clocks

[4] http://lkml.kernel.org/r/20170228093016.5624-1-jbrunet@baylibre.com
[3] http://lkml.kernel.org/r/20170228133002.17894-1-jbrunet@baylibre.com
[2] http://lkml.kernel.org/r/1486721084-1383-1-git-send-email-narmstrong@baylibre.com
[1] http://lkml.kernel.org/r/b098c4fa9fce88361cca20417978734d0e1b5cca.1485939041.git-series.maxime.ripard@free-electrons.com

Neil Armstrong (3):
  clk: meson-gxbb: Add MALI clock IDS
  clk: meson-gxbb: Add MALI clocks
  ARM64: dts: meson-gx: Add MALI nodes for GXBB and GXL

 arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi      |  37 ++++++
 arch/arm64/boot/dts/amlogic/meson-gxl-mali.dtsi  |  43 +++++++
 arch/arm64/boot/dts/amlogic/meson-gxl-s905d.dtsi |   1 +
 arch/arm64/boot/dts/amlogic/meson-gxl-s905x.dtsi |   1 +
 drivers/clk/meson/gxbb.c                         | 139 +++++++++++++++++++++++
 drivers/clk/meson/gxbb.h                         |   9 +-
 include/dt-bindings/clock/gxbb-clkc.h            |   5 +
 7 files changed, 234 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm64/boot/dts/amlogic/meson-gxl-mali.dtsi

-- 
1.9.1


_______________________________________________
linux-amlogic mailing list
linux-amlogic@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-amlogic

[PATCH v2 0/3] meson-gx: Add mali-450 support

[Neil Armstrong]

Since the merge of the Mali dt bindings at [1], add support for Mali clocks
and DT node.

The Mali is clocked by two identical clock paths behind a glitch free mux
to safely change frequency while running.
So these clocks must be added to the meson-gxbb clock controller.

Changes since v1 at [2] :
 - Remove GP0 fixes, this will pushed later, for base frequency it can depend on fclk_div3
 - Add GXL support
 - rebase on clk-next and jbrunet's patchset at [3] and [4]
 - get rid of composite clocks, this adds more clocks IDs and exposes 2 more clocks

[4] http://lkml.kernel.org/r/20170228093016.5624-1-jbrunet at baylibre.com
[3] http://lkml.kernel.org/r/20170228133002.17894-1-jbrunet at baylibre.com
[2] http://lkml.kernel.org/r/1486721084-1383-1-git-send-email-narmstrong at baylibre.com
[1] http://lkml.kernel.org/r/b098c4fa9fce88361cca20417978734d0e1b5cca.1485939041.git-series.maxime.ripard at free-electrons.com

Neil Armstrong (3):
  clk: meson-gxbb: Add MALI clock IDS
  clk: meson-gxbb: Add MALI clocks
  ARM64: dts: meson-gx: Add MALI nodes for GXBB and GXL

 arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi      |  37 ++++++
 arch/arm64/boot/dts/amlogic/meson-gxl-mali.dtsi  |  43 +++++++
 arch/arm64/boot/dts/amlogic/meson-gxl-s905d.dtsi |   1 +
 arch/arm64/boot/dts/amlogic/meson-gxl-s905x.dtsi |   1 +
 drivers/clk/meson/gxbb.c                         | 139 +++++++++++++++++++++++
 drivers/clk/meson/gxbb.h                         |   9 +-
 include/dt-bindings/clock/gxbb-clkc.h            |   5 +
 7 files changed, 234 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm64/boot/dts/amlogic/meson-gxl-mali.dtsi

-- 
1.9.1

[PATCH v2 0/3] meson-gx: Add mali-450 support

[Neil Armstrong]

Since the merge of the Mali dt bindings at [1], add support for Mali clocks
and DT node.

The Mali is clocked by two identical clock paths behind a glitch free mux
to safely change frequency while running.
So these clocks must be added to the meson-gxbb clock controller.

Changes since v1 at [2] :
 - Remove GP0 fixes, this will pushed later, for base frequency it can depend on fclk_div3
 - Add GXL support
 - rebase on clk-next and jbrunet's patchset at [3] and [4]
 - get rid of composite clocks, this adds more clocks IDs and exposes 2 more clocks

[4] http://lkml.kernel.org/r/20170228093016.5624-1-jbrunet at baylibre.com
[3] http://lkml.kernel.org/r/20170228133002.17894-1-jbrunet at baylibre.com
[2] http://lkml.kernel.org/r/1486721084-1383-1-git-send-email-narmstrong at baylibre.com
[1] http://lkml.kernel.org/r/b098c4fa9fce88361cca20417978734d0e1b5cca.1485939041.git-series.maxime.ripard at free-electrons.com

Neil Armstrong (3):
  clk: meson-gxbb: Add MALI clock IDS
  clk: meson-gxbb: Add MALI clocks
  ARM64: dts: meson-gx: Add MALI nodes for GXBB and GXL

 arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi      |  37 ++++++
 arch/arm64/boot/dts/amlogic/meson-gxl-mali.dtsi  |  43 +++++++
 arch/arm64/boot/dts/amlogic/meson-gxl-s905d.dtsi |   1 +
 arch/arm64/boot/dts/amlogic/meson-gxl-s905x.dtsi |   1 +
 drivers/clk/meson/gxbb.c                         | 139 +++++++++++++++++++++++
 drivers/clk/meson/gxbb.h                         |   9 +-
 include/dt-bindings/clock/gxbb-clkc.h            |   5 +
 7 files changed, 234 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm64/boot/dts/amlogic/meson-gxl-mali.dtsi

-- 
1.9.1

[PATCH v2 1/3] clk: meson-gxbb: Add MALI clock IDS

[Neil Armstrong]

Add missing MALI clock IDs and expose the muxes and gates in the dt-bindings.

Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
 drivers/clk/meson/gxbb.h              | 9 ++++++++-
 include/dt-bindings/clock/gxbb-clkc.h | 5 +++++
 2 files changed, 13 insertions(+), 1 deletion(-)

diff --git a/drivers/clk/meson/gxbb.h b/drivers/clk/meson/gxbb.h
index 95a83b7..2ec8f8a 100644
--- a/drivers/clk/meson/gxbb.h
+++ b/drivers/clk/meson/gxbb.h
@@ -268,8 +268,15 @@
 /* CLKID_SAR_ADC_CLK */
 /* CLKID_SAR_ADC_SEL */
 #define CLKID_SAR_ADC_DIV	  99
+/* CLKID_MALI_0_SEL */
+#define CLKID_MALI_0_DIV	 101
+/* CLKID_MALI_0	*/
+/* CLKID_MALI_1_SEL */
+#define CLKID_MALI_1_DIV	 104
+/* CLKID_MALI_1	*/
+/* CLKID_MALI	*/
 
-#define NR_CLKS			  100
+#define NR_CLKS			  107
 
 /* include the CLKIDs that have been made part of the stable DT binding */
 #include <dt-bindings/clock/gxbb-clkc.h>
diff --git a/include/dt-bindings/clock/gxbb-clkc.h b/include/dt-bindings/clock/gxbb-clkc.h
index f08f06d..ef7d6b7 100644
--- a/include/dt-bindings/clock/gxbb-clkc.h
+++ b/include/dt-bindings/clock/gxbb-clkc.h
@@ -35,5 +35,10 @@
 #define CLKID_SD_EMMC_C		96
 #define CLKID_SAR_ADC_CLK	97
 #define CLKID_SAR_ADC_SEL	98
+#define CLKID_MALI_0_SEL	100
+#define CLKID_MALI_0		102
+#define CLKID_MALI_1_SEL	103
+#define CLKID_MALI_1		105
+#define CLKID_MALI		106
 
 #endif /* __GXBB_CLKC_H */
-- 
1.9.1

[PATCH v2 1/3] clk: meson-gxbb: Add MALI clock IDS

[Neil Armstrong]

Add missing MALI clock IDs and expose the muxes and gates in the dt-bindings.

Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
 drivers/clk/meson/gxbb.h              | 9 ++++++++-
 include/dt-bindings/clock/gxbb-clkc.h | 5 +++++
 2 files changed, 13 insertions(+), 1 deletion(-)

diff --git a/drivers/clk/meson/gxbb.h b/drivers/clk/meson/gxbb.h
index 95a83b7..2ec8f8a 100644
--- a/drivers/clk/meson/gxbb.h
+++ b/drivers/clk/meson/gxbb.h
@@ -268,8 +268,15 @@
 /* CLKID_SAR_ADC_CLK */
 /* CLKID_SAR_ADC_SEL */
 #define CLKID_SAR_ADC_DIV	  99
+/* CLKID_MALI_0_SEL */
+#define CLKID_MALI_0_DIV	 101
+/* CLKID_MALI_0	*/
+/* CLKID_MALI_1_SEL */
+#define CLKID_MALI_1_DIV	 104
+/* CLKID_MALI_1	*/
+/* CLKID_MALI	*/
 
-#define NR_CLKS			  100
+#define NR_CLKS			  107
 
 /* include the CLKIDs that have been made part of the stable DT binding */
 #include <dt-bindings/clock/gxbb-clkc.h>
diff --git a/include/dt-bindings/clock/gxbb-clkc.h b/include/dt-bindings/clock/gxbb-clkc.h
index f08f06d..ef7d6b7 100644
--- a/include/dt-bindings/clock/gxbb-clkc.h
+++ b/include/dt-bindings/clock/gxbb-clkc.h
@@ -35,5 +35,10 @@
 #define CLKID_SD_EMMC_C		96
 #define CLKID_SAR_ADC_CLK	97
 #define CLKID_SAR_ADC_SEL	98
+#define CLKID_MALI_0_SEL	100
+#define CLKID_MALI_0		102
+#define CLKID_MALI_1_SEL	103
+#define CLKID_MALI_1		105
+#define CLKID_MALI		106
 
 #endif /* __GXBB_CLKC_H */
-- 
1.9.1


_______________________________________________
linux-amlogic mailing list
linux-amlogic@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-amlogic

[PATCH v2 1/3] clk: meson-gxbb: Add MALI clock IDS

[Neil Armstrong]

Add missing MALI clock IDs and expose the muxes and gates in the dt-bindings.

Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
 drivers/clk/meson/gxbb.h              | 9 ++++++++-
 include/dt-bindings/clock/gxbb-clkc.h | 5 +++++
 2 files changed, 13 insertions(+), 1 deletion(-)

diff --git a/drivers/clk/meson/gxbb.h b/drivers/clk/meson/gxbb.h
index 95a83b7..2ec8f8a 100644
--- a/drivers/clk/meson/gxbb.h
+++ b/drivers/clk/meson/gxbb.h
@@ -268,8 +268,15 @@
 /* CLKID_SAR_ADC_CLK */
 /* CLKID_SAR_ADC_SEL */
 #define CLKID_SAR_ADC_DIV	  99
+/* CLKID_MALI_0_SEL */
+#define CLKID_MALI_0_DIV	 101
+/* CLKID_MALI_0	*/
+/* CLKID_MALI_1_SEL */
+#define CLKID_MALI_1_DIV	 104
+/* CLKID_MALI_1	*/
+/* CLKID_MALI	*/
 
-#define NR_CLKS			  100
+#define NR_CLKS			  107
 
 /* include the CLKIDs that have been made part of the stable DT binding */
 #include <dt-bindings/clock/gxbb-clkc.h>
diff --git a/include/dt-bindings/clock/gxbb-clkc.h b/include/dt-bindings/clock/gxbb-clkc.h
index f08f06d..ef7d6b7 100644
--- a/include/dt-bindings/clock/gxbb-clkc.h
+++ b/include/dt-bindings/clock/gxbb-clkc.h
@@ -35,5 +35,10 @@
 #define CLKID_SD_EMMC_C		96
 #define CLKID_SAR_ADC_CLK	97
 #define CLKID_SAR_ADC_SEL	98
+#define CLKID_MALI_0_SEL	100
+#define CLKID_MALI_0		102
+#define CLKID_MALI_1_SEL	103
+#define CLKID_MALI_1		105
+#define CLKID_MALI		106
 
 #endif /* __GXBB_CLKC_H */
-- 
1.9.1

[PATCH v2 1/3] clk: meson-gxbb: Add MALI clock IDS

[Neil Armstrong]

Add missing MALI clock IDs and expose the muxes and gates in the dt-bindings.

Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
 drivers/clk/meson/gxbb.h              | 9 ++++++++-
 include/dt-bindings/clock/gxbb-clkc.h | 5 +++++
 2 files changed, 13 insertions(+), 1 deletion(-)

diff --git a/drivers/clk/meson/gxbb.h b/drivers/clk/meson/gxbb.h
index 95a83b7..2ec8f8a 100644
--- a/drivers/clk/meson/gxbb.h
+++ b/drivers/clk/meson/gxbb.h
@@ -268,8 +268,15 @@
 /* CLKID_SAR_ADC_CLK */
 /* CLKID_SAR_ADC_SEL */
 #define CLKID_SAR_ADC_DIV	  99
+/* CLKID_MALI_0_SEL */
+#define CLKID_MALI_0_DIV	 101
+/* CLKID_MALI_0	*/
+/* CLKID_MALI_1_SEL */
+#define CLKID_MALI_1_DIV	 104
+/* CLKID_MALI_1	*/
+/* CLKID_MALI	*/
 
-#define NR_CLKS			  100
+#define NR_CLKS			  107
 
 /* include the CLKIDs that have been made part of the stable DT binding */
 #include <dt-bindings/clock/gxbb-clkc.h>
diff --git a/include/dt-bindings/clock/gxbb-clkc.h b/include/dt-bindings/clock/gxbb-clkc.h
index f08f06d..ef7d6b7 100644
--- a/include/dt-bindings/clock/gxbb-clkc.h
+++ b/include/dt-bindings/clock/gxbb-clkc.h
@@ -35,5 +35,10 @@
 #define CLKID_SD_EMMC_C		96
 #define CLKID_SAR_ADC_CLK	97
 #define CLKID_SAR_ADC_SEL	98
+#define CLKID_MALI_0_SEL	100
+#define CLKID_MALI_0		102
+#define CLKID_MALI_1_SEL	103
+#define CLKID_MALI_1		105
+#define CLKID_MALI		106
 
 #endif /* __GXBB_CLKC_H */
-- 
1.9.1

[PATCH v2 2/3] clk: meson-gxbb: Add MALI clocks

[Neil Armstrong]

The Mali is clocked by two identical clock paths behind a glitch free mux
to safely change frequency while running.

The two "mali_0" and "mali_1" clocks are composed of a mux, divider and gate.
Expose these two clocks trees using generic clocks.
Finally the glitch free mux is added as "mali" clock.

Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
 drivers/clk/meson/gxbb.c | 139 +++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 139 insertions(+)

diff --git a/drivers/clk/meson/gxbb.c b/drivers/clk/meson/gxbb.c
index a52063f..31f6090 100644
--- a/drivers/clk/meson/gxbb.c
+++ b/drivers/clk/meson/gxbb.c
@@ -634,6 +634,131 @@
 	},
 };
 
+/*
+ * The MALI IP is clocked by two identical clocks (mali_0 and mali_1)
+ * muxed by a glitch-free switch.
+ */
+
+static u32 mux_table_mali_0_1[] = {0, 1, 2, 3, 4, 5, 6, 7};
+const char *gxbb_mali_0_1_parent_names[] = {
+	"xtal", "gp0_pll", "mpll2", "mpll1", "fclk_div7",
+	"fclk_div4", "fclk_div3", "fclk_div5"
+};
+
+static struct clk_mux gxbb_mali_0_sel = {
+	.reg = (void *)HHI_MALI_CLK_CNTL,
+	.mask = 0x7,
+	.shift = 9,
+	.table = mux_table_mali_0_1,
+	.lock = &clk_lock,
+	.hw.init = &(struct clk_init_data){
+		.name = "mali_0_sel",
+		.ops = &clk_mux_ops,
+		/*
+		 * bits 10:9 selects from 8 possible parents:
+		 * xtal, gp0_pll, mpll2, mpll1, fclk_div7,
+		 * fclk_div4, fclk_div3, fclk_div5
+		 */
+		.parent_names = gxbb_mali_0_1_parent_names,
+		.num_parents = 8,
+		.flags = (CLK_SET_RATE_NO_REPARENT | CLK_IGNORE_UNUSED),
+	},
+};
+
+static struct clk_divider gxbb_mali_0_div = {
+	.reg = (void *)HHI_MALI_CLK_CNTL,
+	.shift = 0,
+	.width = 7,
+	.lock = &clk_lock,
+	.hw.init = &(struct clk_init_data){
+		.name = "mali_0_div",
+		.ops = &clk_divider_ops,
+		.parent_names = (const char *[]){ "mali_0_sel" },
+		.num_parents = 1,
+		.flags = (CLK_SET_RATE_NO_REPARENT | CLK_IGNORE_UNUSED),
+	},
+};
+
+static struct clk_gate gxbb_mali_0 = {
+	.reg = (void *)HHI_MALI_CLK_CNTL,
+	.bit_idx = 8,
+	.lock = &clk_lock,
+	.hw.init = &(struct clk_init_data){
+		.name = "mali_0",
+		.ops = &clk_gate_ops,
+		.parent_names = (const char *[]){ "mali_0_div" },
+		.num_parents = 1,
+		.flags = (CLK_SET_RATE_PARENT | CLK_IGNORE_UNUSED),
+	},
+};
+
+static struct clk_mux gxbb_mali_1_sel = {
+	.reg = (void *)HHI_MALI_CLK_CNTL,
+	.mask = 0x7,
+	.shift = 25,
+	.table = mux_table_mali_0_1,
+	.lock = &clk_lock,
+	.hw.init = &(struct clk_init_data){
+		.name = "mali_1_sel",
+		.ops = &clk_mux_ops,
+		/*
+		 * bits 10:9 selects from 8 possible parents:
+		 * xtal, gp0_pll, mpll2, mpll1, fclk_div7,
+		 * fclk_div4, fclk_div3, fclk_div5
+		 */
+		.parent_names = gxbb_mali_0_1_parent_names,
+		.num_parents = 8,
+		.flags = (CLK_SET_RATE_NO_REPARENT | CLK_IGNORE_UNUSED),
+	},
+};
+
+static struct clk_divider gxbb_mali_1_div = {
+	.reg = (void *)HHI_MALI_CLK_CNTL,
+	.shift = 16,
+	.width = 7,
+	.lock = &clk_lock,
+	.hw.init = &(struct clk_init_data){
+		.name = "mali_1_div",
+		.ops = &clk_divider_ops,
+		.parent_names = (const char *[]){ "mali_1_sel" },
+		.num_parents = 1,
+		.flags = (CLK_SET_RATE_NO_REPARENT | CLK_IGNORE_UNUSED),
+	},
+};
+
+static struct clk_gate gxbb_mali_1 = {
+	.reg = (void *)HHI_MALI_CLK_CNTL,
+	.bit_idx = 24,
+	.lock = &clk_lock,
+	.hw.init = &(struct clk_init_data){
+		.name = "mali_1",
+		.ops = &clk_gate_ops,
+		.parent_names = (const char *[]){ "mali_1_div" },
+		.num_parents = 1,
+		.flags = (CLK_SET_RATE_PARENT | CLK_IGNORE_UNUSED),
+	},
+};
+
+static u32 mux_table_mali[] = {0, 1};
+const char *gxbb_mali_parent_names[] = {
+	"mali_0", "mali_1"
+};
+
+static struct clk_mux gxbb_mali = {
+	.reg = (void *)HHI_MALI_CLK_CNTL,
+	.mask = 1,
+	.shift = 31,
+	.table = mux_table_mali,
+	.lock = &clk_lock,
+	.hw.init = &(struct clk_init_data){
+		.name = "mali",
+		.ops = &clk_mux_ops,
+		.parent_names = gxbb_mali_parent_names,
+		.num_parents = 2,
+		.flags = (CLK_SET_RATE_NO_REPARENT | CLK_IGNORE_UNUSED),
+	},
+};
+
 /* Everything Else (EE) domain gates */
 static MESON_GATE(gxbb_ddr, HHI_GCLK_MPEG0, 0);
 static MESON_GATE(gxbb_dos, HHI_GCLK_MPEG0, 1);
@@ -827,6 +952,13 @@
 		[CLKID_SAR_ADC_CLK]	    = &gxbb_sar_adc_clk.hw,
 		[CLKID_SAR_ADC_SEL]	    = &gxbb_sar_adc_clk_sel.hw,
 		[CLKID_SAR_ADC_DIV]	    = &gxbb_sar_adc_clk_div.hw,
+		[CLKID_MALI_0_SEL]	    = &gxbb_mali_0_sel.hw,
+		[CLKID_MALI_0_DIV]	    = &gxbb_mali_0_div.hw,
+		[CLKID_MALI_0]		    = &gxbb_mali_0.hw,
+		[CLKID_MALI_1_SEL]	    = &gxbb_mali_1_sel.hw,
+		[CLKID_MALI_1_DIV]	    = &gxbb_mali_1_div.hw,
+		[CLKID_MALI_1]		    = &gxbb_mali_1.hw,
+		[CLKID_MALI]		    = &gxbb_mali.hw,
 	},
 	.num = NR_CLKS,
 };
@@ -930,16 +1062,23 @@
 	&gxbb_emmc_b,
 	&gxbb_emmc_c,
 	&gxbb_sar_adc_clk,
+	&gxbb_mali_0,
+	&gxbb_mali_1,
 };
 
 static struct clk_mux *gxbb_clk_muxes[] = {
 	&gxbb_mpeg_clk_sel,
 	&gxbb_sar_adc_clk_sel,
+	&gxbb_mali_0_sel,
+	&gxbb_mali_1_sel,
+	&gxbb_mali,
 };
 
 static struct clk_divider *gxbb_clk_dividers[] = {
 	&gxbb_mpeg_clk_div,
 	&gxbb_sar_adc_clk_div,
+	&gxbb_mali_0_div,
+	&gxbb_mali_1_div,
 };
 
 static int gxbb_clkc_probe(struct platform_device *pdev)
-- 
1.9.1

[PATCH v2 2/3] clk: meson-gxbb: Add MALI clocks

[Neil Armstrong]

The Mali is clocked by two identical clock paths behind a glitch free mux
to safely change frequency while running.

The two "mali_0" and "mali_1" clocks are composed of a mux, divider and gate.
Expose these two clocks trees using generic clocks.
Finally the glitch free mux is added as "mali" clock.

Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
 drivers/clk/meson/gxbb.c | 139 +++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 139 insertions(+)

diff --git a/drivers/clk/meson/gxbb.c b/drivers/clk/meson/gxbb.c
index a52063f..31f6090 100644
--- a/drivers/clk/meson/gxbb.c
+++ b/drivers/clk/meson/gxbb.c
@@ -634,6 +634,131 @@
 	},
 };
 
+/*
+ * The MALI IP is clocked by two identical clocks (mali_0 and mali_1)
+ * muxed by a glitch-free switch.
+ */
+
+static u32 mux_table_mali_0_1[] = {0, 1, 2, 3, 4, 5, 6, 7};
+const char *gxbb_mali_0_1_parent_names[] = {
+	"xtal", "gp0_pll", "mpll2", "mpll1", "fclk_div7",
+	"fclk_div4", "fclk_div3", "fclk_div5"
+};
+
+static struct clk_mux gxbb_mali_0_sel = {
+	.reg = (void *)HHI_MALI_CLK_CNTL,
+	.mask = 0x7,
+	.shift = 9,
+	.table = mux_table_mali_0_1,
+	.lock = &clk_lock,
+	.hw.init = &(struct clk_init_data){
+		.name = "mali_0_sel",
+		.ops = &clk_mux_ops,
+		/*
+		 * bits 10:9 selects from 8 possible parents:
+		 * xtal, gp0_pll, mpll2, mpll1, fclk_div7,
+		 * fclk_div4, fclk_div3, fclk_div5
+		 */
+		.parent_names = gxbb_mali_0_1_parent_names,
+		.num_parents = 8,
+		.flags = (CLK_SET_RATE_NO_REPARENT | CLK_IGNORE_UNUSED),
+	},
+};
+
+static struct clk_divider gxbb_mali_0_div = {
+	.reg = (void *)HHI_MALI_CLK_CNTL,
+	.shift = 0,
+	.width = 7,
+	.lock = &clk_lock,
+	.hw.init = &(struct clk_init_data){
+		.name = "mali_0_div",
+		.ops = &clk_divider_ops,
+		.parent_names = (const char *[]){ "mali_0_sel" },
+		.num_parents = 1,
+		.flags = (CLK_SET_RATE_NO_REPARENT | CLK_IGNORE_UNUSED),
+	},
+};
+
+static struct clk_gate gxbb_mali_0 = {
+	.reg = (void *)HHI_MALI_CLK_CNTL,
+	.bit_idx = 8,
+	.lock = &clk_lock,
+	.hw.init = &(struct clk_init_data){
+		.name = "mali_0",
+		.ops = &clk_gate_ops,
+		.parent_names = (const char *[]){ "mali_0_div" },
+		.num_parents = 1,
+		.flags = (CLK_SET_RATE_PARENT | CLK_IGNORE_UNUSED),
+	},
+};
+
+static struct clk_mux gxbb_mali_1_sel = {
+	.reg = (void *)HHI_MALI_CLK_CNTL,
+	.mask = 0x7,
+	.shift = 25,
+	.table = mux_table_mali_0_1,
+	.lock = &clk_lock,
+	.hw.init = &(struct clk_init_data){
+		.name = "mali_1_sel",
+		.ops = &clk_mux_ops,
+		/*
+		 * bits 10:9 selects from 8 possible parents:
+		 * xtal, gp0_pll, mpll2, mpll1, fclk_div7,
+		 * fclk_div4, fclk_div3, fclk_div5
+		 */
+		.parent_names = gxbb_mali_0_1_parent_names,
+		.num_parents = 8,
+		.flags = (CLK_SET_RATE_NO_REPARENT | CLK_IGNORE_UNUSED),
+	},
+};
+
+static struct clk_divider gxbb_mali_1_div = {
+	.reg = (void *)HHI_MALI_CLK_CNTL,
+	.shift = 16,
+	.width = 7,
+	.lock = &clk_lock,
+	.hw.init = &(struct clk_init_data){
+		.name = "mali_1_div",
+		.ops = &clk_divider_ops,
+		.parent_names = (const char *[]){ "mali_1_sel" },
+		.num_parents = 1,
+		.flags = (CLK_SET_RATE_NO_REPARENT | CLK_IGNORE_UNUSED),
+	},
+};
+
+static struct clk_gate gxbb_mali_1 = {
+	.reg = (void *)HHI_MALI_CLK_CNTL,
+	.bit_idx = 24,
+	.lock = &clk_lock,
+	.hw.init = &(struct clk_init_data){
+		.name = "mali_1",
+		.ops = &clk_gate_ops,
+		.parent_names = (const char *[]){ "mali_1_div" },
+		.num_parents = 1,
+		.flags = (CLK_SET_RATE_PARENT | CLK_IGNORE_UNUSED),
+	},
+};
+
+static u32 mux_table_mali[] = {0, 1};
+const char *gxbb_mali_parent_names[] = {
+	"mali_0", "mali_1"
+};
+
+static struct clk_mux gxbb_mali = {
+	.reg = (void *)HHI_MALI_CLK_CNTL,
+	.mask = 1,
+	.shift = 31,
+	.table = mux_table_mali,
+	.lock = &clk_lock,
+	.hw.init = &(struct clk_init_data){
+		.name = "mali",
+		.ops = &clk_mux_ops,
+		.parent_names = gxbb_mali_parent_names,
+		.num_parents = 2,
+		.flags = (CLK_SET_RATE_NO_REPARENT | CLK_IGNORE_UNUSED),
+	},
+};
+
 /* Everything Else (EE) domain gates */
 static MESON_GATE(gxbb_ddr, HHI_GCLK_MPEG0, 0);
 static MESON_GATE(gxbb_dos, HHI_GCLK_MPEG0, 1);
@@ -827,6 +952,13 @@
 		[CLKID_SAR_ADC_CLK]	    = &gxbb_sar_adc_clk.hw,
 		[CLKID_SAR_ADC_SEL]	    = &gxbb_sar_adc_clk_sel.hw,
 		[CLKID_SAR_ADC_DIV]	    = &gxbb_sar_adc_clk_div.hw,
+		[CLKID_MALI_0_SEL]	    = &gxbb_mali_0_sel.hw,
+		[CLKID_MALI_0_DIV]	    = &gxbb_mali_0_div.hw,
+		[CLKID_MALI_0]		    = &gxbb_mali_0.hw,
+		[CLKID_MALI_1_SEL]	    = &gxbb_mali_1_sel.hw,
+		[CLKID_MALI_1_DIV]	    = &gxbb_mali_1_div.hw,
+		[CLKID_MALI_1]		    = &gxbb_mali_1.hw,
+		[CLKID_MALI]		    = &gxbb_mali.hw,
 	},
 	.num = NR_CLKS,
 };
@@ -930,16 +1062,23 @@
 	&gxbb_emmc_b,
 	&gxbb_emmc_c,
 	&gxbb_sar_adc_clk,
+	&gxbb_mali_0,
+	&gxbb_mali_1,
 };
 
 static struct clk_mux *gxbb_clk_muxes[] = {
 	&gxbb_mpeg_clk_sel,
 	&gxbb_sar_adc_clk_sel,
+	&gxbb_mali_0_sel,
+	&gxbb_mali_1_sel,
+	&gxbb_mali,
 };
 
 static struct clk_divider *gxbb_clk_dividers[] = {
 	&gxbb_mpeg_clk_div,
 	&gxbb_sar_adc_clk_div,
+	&gxbb_mali_0_div,
+	&gxbb_mali_1_div,
 };
 
 static int gxbb_clkc_probe(struct platform_device *pdev)
-- 
1.9.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v2 2/3] clk: meson-gxbb: Add MALI clocks

[Neil Armstrong]

The Mali is clocked by two identical clock paths behind a glitch free mux
to safely change frequency while running.

The two "mali_0" and "mali_1" clocks are composed of a mux, divider and gate.
Expose these two clocks trees using generic clocks.
Finally the glitch free mux is added as "mali" clock.

Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
 drivers/clk/meson/gxbb.c | 139 +++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 139 insertions(+)

diff --git a/drivers/clk/meson/gxbb.c b/drivers/clk/meson/gxbb.c
index a52063f..31f6090 100644
--- a/drivers/clk/meson/gxbb.c
+++ b/drivers/clk/meson/gxbb.c
@@ -634,6 +634,131 @@
 	},
 };
 
+/*
+ * The MALI IP is clocked by two identical clocks (mali_0 and mali_1)
+ * muxed by a glitch-free switch.
+ */
+
+static u32 mux_table_mali_0_1[] = {0, 1, 2, 3, 4, 5, 6, 7};
+const char *gxbb_mali_0_1_parent_names[] = {
+	"xtal", "gp0_pll", "mpll2", "mpll1", "fclk_div7",
+	"fclk_div4", "fclk_div3", "fclk_div5"
+};
+
+static struct clk_mux gxbb_mali_0_sel = {
+	.reg = (void *)HHI_MALI_CLK_CNTL,
+	.mask = 0x7,
+	.shift = 9,
+	.table = mux_table_mali_0_1,
+	.lock = &clk_lock,
+	.hw.init = &(struct clk_init_data){
+		.name = "mali_0_sel",
+		.ops = &clk_mux_ops,
+		/*
+		 * bits 10:9 selects from 8 possible parents:
+		 * xtal, gp0_pll, mpll2, mpll1, fclk_div7,
+		 * fclk_div4, fclk_div3, fclk_div5
+		 */
+		.parent_names = gxbb_mali_0_1_parent_names,
+		.num_parents = 8,
+		.flags = (CLK_SET_RATE_NO_REPARENT | CLK_IGNORE_UNUSED),
+	},
+};
+
+static struct clk_divider gxbb_mali_0_div = {
+	.reg = (void *)HHI_MALI_CLK_CNTL,
+	.shift = 0,
+	.width = 7,
+	.lock = &clk_lock,
+	.hw.init = &(struct clk_init_data){
+		.name = "mali_0_div",
+		.ops = &clk_divider_ops,
+		.parent_names = (const char *[]){ "mali_0_sel" },
+		.num_parents = 1,
+		.flags = (CLK_SET_RATE_NO_REPARENT | CLK_IGNORE_UNUSED),
+	},
+};
+
+static struct clk_gate gxbb_mali_0 = {
+	.reg = (void *)HHI_MALI_CLK_CNTL,
+	.bit_idx = 8,
+	.lock = &clk_lock,
+	.hw.init = &(struct clk_init_data){
+		.name = "mali_0",
+		.ops = &clk_gate_ops,
+		.parent_names = (const char *[]){ "mali_0_div" },
+		.num_parents = 1,
+		.flags = (CLK_SET_RATE_PARENT | CLK_IGNORE_UNUSED),
+	},
+};
+
+static struct clk_mux gxbb_mali_1_sel = {
+	.reg = (void *)HHI_MALI_CLK_CNTL,
+	.mask = 0x7,
+	.shift = 25,
+	.table = mux_table_mali_0_1,
+	.lock = &clk_lock,
+	.hw.init = &(struct clk_init_data){
+		.name = "mali_1_sel",
+		.ops = &clk_mux_ops,
+		/*
+		 * bits 10:9 selects from 8 possible parents:
+		 * xtal, gp0_pll, mpll2, mpll1, fclk_div7,
+		 * fclk_div4, fclk_div3, fclk_div5
+		 */
+		.parent_names = gxbb_mali_0_1_parent_names,
+		.num_parents = 8,
+		.flags = (CLK_SET_RATE_NO_REPARENT | CLK_IGNORE_UNUSED),
+	},
+};
+
+static struct clk_divider gxbb_mali_1_div = {
+	.reg = (void *)HHI_MALI_CLK_CNTL,
+	.shift = 16,
+	.width = 7,
+	.lock = &clk_lock,
+	.hw.init = &(struct clk_init_data){
+		.name = "mali_1_div",
+		.ops = &clk_divider_ops,
+		.parent_names = (const char *[]){ "mali_1_sel" },
+		.num_parents = 1,
+		.flags = (CLK_SET_RATE_NO_REPARENT | CLK_IGNORE_UNUSED),
+	},
+};
+
+static struct clk_gate gxbb_mali_1 = {
+	.reg = (void *)HHI_MALI_CLK_CNTL,
+	.bit_idx = 24,
+	.lock = &clk_lock,
+	.hw.init = &(struct clk_init_data){
+		.name = "mali_1",
+		.ops = &clk_gate_ops,
+		.parent_names = (const char *[]){ "mali_1_div" },
+		.num_parents = 1,
+		.flags = (CLK_SET_RATE_PARENT | CLK_IGNORE_UNUSED),
+	},
+};
+
+static u32 mux_table_mali[] = {0, 1};
+const char *gxbb_mali_parent_names[] = {
+	"mali_0", "mali_1"
+};
+
+static struct clk_mux gxbb_mali = {
+	.reg = (void *)HHI_MALI_CLK_CNTL,
+	.mask = 1,
+	.shift = 31,
+	.table = mux_table_mali,
+	.lock = &clk_lock,
+	.hw.init = &(struct clk_init_data){
+		.name = "mali",
+		.ops = &clk_mux_ops,
+		.parent_names = gxbb_mali_parent_names,
+		.num_parents = 2,
+		.flags = (CLK_SET_RATE_NO_REPARENT | CLK_IGNORE_UNUSED),
+	},
+};
+
 /* Everything Else (EE) domain gates */
 static MESON_GATE(gxbb_ddr, HHI_GCLK_MPEG0, 0);
 static MESON_GATE(gxbb_dos, HHI_GCLK_MPEG0, 1);
@@ -827,6 +952,13 @@
 		[CLKID_SAR_ADC_CLK]	    = &gxbb_sar_adc_clk.hw,
 		[CLKID_SAR_ADC_SEL]	    = &gxbb_sar_adc_clk_sel.hw,
 		[CLKID_SAR_ADC_DIV]	    = &gxbb_sar_adc_clk_div.hw,
+		[CLKID_MALI_0_SEL]	    = &gxbb_mali_0_sel.hw,
+		[CLKID_MALI_0_DIV]	    = &gxbb_mali_0_div.hw,
+		[CLKID_MALI_0]		    = &gxbb_mali_0.hw,
+		[CLKID_MALI_1_SEL]	    = &gxbb_mali_1_sel.hw,
+		[CLKID_MALI_1_DIV]	    = &gxbb_mali_1_div.hw,
+		[CLKID_MALI_1]		    = &gxbb_mali_1.hw,
+		[CLKID_MALI]		    = &gxbb_mali.hw,
 	},
 	.num = NR_CLKS,
 };
@@ -930,16 +1062,23 @@
 	&gxbb_emmc_b,
 	&gxbb_emmc_c,
 	&gxbb_sar_adc_clk,
+	&gxbb_mali_0,
+	&gxbb_mali_1,
 };
 
 static struct clk_mux *gxbb_clk_muxes[] = {
 	&gxbb_mpeg_clk_sel,
 	&gxbb_sar_adc_clk_sel,
+	&gxbb_mali_0_sel,
+	&gxbb_mali_1_sel,
+	&gxbb_mali,
 };
 
 static struct clk_divider *gxbb_clk_dividers[] = {
 	&gxbb_mpeg_clk_div,
 	&gxbb_sar_adc_clk_div,
+	&gxbb_mali_0_div,
+	&gxbb_mali_1_div,
 };
 
 static int gxbb_clkc_probe(struct platform_device *pdev)
-- 
1.9.1

[PATCH v2 2/3] clk: meson-gxbb: Add MALI clocks

[Neil Armstrong]

The Mali is clocked by two identical clock paths behind a glitch free mux
to safely change frequency while running.

The two "mali_0" and "mali_1" clocks are composed of a mux, divider and gate.
Expose these two clocks trees using generic clocks.
Finally the glitch free mux is added as "mali" clock.

Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
 drivers/clk/meson/gxbb.c | 139 +++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 139 insertions(+)

diff --git a/drivers/clk/meson/gxbb.c b/drivers/clk/meson/gxbb.c
index a52063f..31f6090 100644
--- a/drivers/clk/meson/gxbb.c
+++ b/drivers/clk/meson/gxbb.c
@@ -634,6 +634,131 @@
 	},
 };
 
+/*
+ * The MALI IP is clocked by two identical clocks (mali_0 and mali_1)
+ * muxed by a glitch-free switch.
+ */
+
+static u32 mux_table_mali_0_1[] = {0, 1, 2, 3, 4, 5, 6, 7};
+const char *gxbb_mali_0_1_parent_names[] = {
+	"xtal", "gp0_pll", "mpll2", "mpll1", "fclk_div7",
+	"fclk_div4", "fclk_div3", "fclk_div5"
+};
+
+static struct clk_mux gxbb_mali_0_sel = {
+	.reg = (void *)HHI_MALI_CLK_CNTL,
+	.mask = 0x7,
+	.shift = 9,
+	.table = mux_table_mali_0_1,
+	.lock = &clk_lock,
+	.hw.init = &(struct clk_init_data){
+		.name = "mali_0_sel",
+		.ops = &clk_mux_ops,
+		/*
+		 * bits 10:9 selects from 8 possible parents:
+		 * xtal, gp0_pll, mpll2, mpll1, fclk_div7,
+		 * fclk_div4, fclk_div3, fclk_div5
+		 */
+		.parent_names = gxbb_mali_0_1_parent_names,
+		.num_parents = 8,
+		.flags = (CLK_SET_RATE_NO_REPARENT | CLK_IGNORE_UNUSED),
+	},
+};
+
+static struct clk_divider gxbb_mali_0_div = {
+	.reg = (void *)HHI_MALI_CLK_CNTL,
+	.shift = 0,
+	.width = 7,
+	.lock = &clk_lock,
+	.hw.init = &(struct clk_init_data){
+		.name = "mali_0_div",
+		.ops = &clk_divider_ops,
+		.parent_names = (const char *[]){ "mali_0_sel" },
+		.num_parents = 1,
+		.flags = (CLK_SET_RATE_NO_REPARENT | CLK_IGNORE_UNUSED),
+	},
+};
+
+static struct clk_gate gxbb_mali_0 = {
+	.reg = (void *)HHI_MALI_CLK_CNTL,
+	.bit_idx = 8,
+	.lock = &clk_lock,
+	.hw.init = &(struct clk_init_data){
+		.name = "mali_0",
+		.ops = &clk_gate_ops,
+		.parent_names = (const char *[]){ "mali_0_div" },
+		.num_parents = 1,
+		.flags = (CLK_SET_RATE_PARENT | CLK_IGNORE_UNUSED),
+	},
+};
+
+static struct clk_mux gxbb_mali_1_sel = {
+	.reg = (void *)HHI_MALI_CLK_CNTL,
+	.mask = 0x7,
+	.shift = 25,
+	.table = mux_table_mali_0_1,
+	.lock = &clk_lock,
+	.hw.init = &(struct clk_init_data){
+		.name = "mali_1_sel",
+		.ops = &clk_mux_ops,
+		/*
+		 * bits 10:9 selects from 8 possible parents:
+		 * xtal, gp0_pll, mpll2, mpll1, fclk_div7,
+		 * fclk_div4, fclk_div3, fclk_div5
+		 */
+		.parent_names = gxbb_mali_0_1_parent_names,
+		.num_parents = 8,
+		.flags = (CLK_SET_RATE_NO_REPARENT | CLK_IGNORE_UNUSED),
+	},
+};
+
+static struct clk_divider gxbb_mali_1_div = {
+	.reg = (void *)HHI_MALI_CLK_CNTL,
+	.shift = 16,
+	.width = 7,
+	.lock = &clk_lock,
+	.hw.init = &(struct clk_init_data){
+		.name = "mali_1_div",
+		.ops = &clk_divider_ops,
+		.parent_names = (const char *[]){ "mali_1_sel" },
+		.num_parents = 1,
+		.flags = (CLK_SET_RATE_NO_REPARENT | CLK_IGNORE_UNUSED),
+	},
+};
+
+static struct clk_gate gxbb_mali_1 = {
+	.reg = (void *)HHI_MALI_CLK_CNTL,
+	.bit_idx = 24,
+	.lock = &clk_lock,
+	.hw.init = &(struct clk_init_data){
+		.name = "mali_1",
+		.ops = &clk_gate_ops,
+		.parent_names = (const char *[]){ "mali_1_div" },
+		.num_parents = 1,
+		.flags = (CLK_SET_RATE_PARENT | CLK_IGNORE_UNUSED),
+	},
+};
+
+static u32 mux_table_mali[] = {0, 1};
+const char *gxbb_mali_parent_names[] = {
+	"mali_0", "mali_1"
+};
+
+static struct clk_mux gxbb_mali = {
+	.reg = (void *)HHI_MALI_CLK_CNTL,
+	.mask = 1,
+	.shift = 31,
+	.table = mux_table_mali,
+	.lock = &clk_lock,
+	.hw.init = &(struct clk_init_data){
+		.name = "mali",
+		.ops = &clk_mux_ops,
+		.parent_names = gxbb_mali_parent_names,
+		.num_parents = 2,
+		.flags = (CLK_SET_RATE_NO_REPARENT | CLK_IGNORE_UNUSED),
+	},
+};
+
 /* Everything Else (EE) domain gates */
 static MESON_GATE(gxbb_ddr, HHI_GCLK_MPEG0, 0);
 static MESON_GATE(gxbb_dos, HHI_GCLK_MPEG0, 1);
@@ -827,6 +952,13 @@
 		[CLKID_SAR_ADC_CLK]	    = &gxbb_sar_adc_clk.hw,
 		[CLKID_SAR_ADC_SEL]	    = &gxbb_sar_adc_clk_sel.hw,
 		[CLKID_SAR_ADC_DIV]	    = &gxbb_sar_adc_clk_div.hw,
+		[CLKID_MALI_0_SEL]	    = &gxbb_mali_0_sel.hw,
+		[CLKID_MALI_0_DIV]	    = &gxbb_mali_0_div.hw,
+		[CLKID_MALI_0]		    = &gxbb_mali_0.hw,
+		[CLKID_MALI_1_SEL]	    = &gxbb_mali_1_sel.hw,
+		[CLKID_MALI_1_DIV]	    = &gxbb_mali_1_div.hw,
+		[CLKID_MALI_1]		    = &gxbb_mali_1.hw,
+		[CLKID_MALI]		    = &gxbb_mali.hw,
 	},
 	.num = NR_CLKS,
 };
@@ -930,16 +1062,23 @@
 	&gxbb_emmc_b,
 	&gxbb_emmc_c,
 	&gxbb_sar_adc_clk,
+	&gxbb_mali_0,
+	&gxbb_mali_1,
 };
 
 static struct clk_mux *gxbb_clk_muxes[] = {
 	&gxbb_mpeg_clk_sel,
 	&gxbb_sar_adc_clk_sel,
+	&gxbb_mali_0_sel,
+	&gxbb_mali_1_sel,
+	&gxbb_mali,
 };
 
 static struct clk_divider *gxbb_clk_dividers[] = {
 	&gxbb_mpeg_clk_div,
 	&gxbb_sar_adc_clk_div,
+	&gxbb_mali_0_div,
+	&gxbb_mali_1_div,
 };
 
 static int gxbb_clkc_probe(struct platform_device *pdev)
-- 
1.9.1

[PATCH v2 3/3] ARM64: dts: meson-gx: Add MALI nodes for GXBB and GXL

[Neil Armstrong]

The same MALI-450 MP3 GPU is present in the GXBB and GXL SoCs.

The node is simply added in the meson-gxbb.dtsi file.

For GXL, since a lot is shared with the GXM that has a MALI-T820 IP, this
patch adds a new meson-gxl-mali.dtsi and is included in the SoC specific
dtsi files.

Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
 arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi      | 37 ++++++++++++++++++++
 arch/arm64/boot/dts/amlogic/meson-gxl-mali.dtsi  | 43 ++++++++++++++++++++++++
 arch/arm64/boot/dts/amlogic/meson-gxl-s905d.dtsi |  1 +
 arch/arm64/boot/dts/amlogic/meson-gxl-s905x.dtsi |  1 +
 4 files changed, 82 insertions(+)
 create mode 100644 arch/arm64/boot/dts/amlogic/meson-gxl-mali.dtsi

diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi b/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
index b353073..4f7ae6a 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
@@ -474,6 +474,43 @@
 	};
 };
 
+&apb {
+	mali: gpu@c0000 {
+		compatible = "amlogic,meson-gxbb-mali", "arm,mali-450";
+		reg = <0x0 0xc0000 0x0 0x40000>;
+		interrupts = <GIC_SPI 160 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 161 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 162 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 163 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 164 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 165 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 166 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 167 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 168 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 169 IRQ_TYPE_LEVEL_HIGH>;
+		interrupt-names = "gp", "gpmmu", "pp", "pmu",
+			"pp0", "ppmmu0", "pp1", "ppmmu1",
+			"pp2", "ppmmu2";
+		clocks = <&clkc CLKID_CLK81>, <&clkc CLKID_MALI>;
+		clock-names = "bus", "core";
+
+		/*
+		 * Mali clocking is provided by two identical clock paths
+		 * MALI_0 and MALI_1 muxed to a single clock by a glitch
+		 * free mux to safely change frequency while running.
+		 */
+		assigned-clocks = <&clkc CLKID_MALI_0_SEL>,
+				  <&clkc CLKID_MALI_0>,
+				  <&clkc CLKID_MALI>; /* Glitch free mux */
+		assigned-clock-parents = <&clkc CLKID_FCLK_DIV3>,
+					 <0>, /* Do Nothing */
+					 <&clkc CLKID_MALI_0>;
+		assigned-clock-rates = <0>, /* Do Nothing */
+				       <666666666>,
+				       <0>; /* Do Nothing */
+	};
+};
+
 &i2c_A {
 	clocks = <&clkc CLKID_I2C>;
 };
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl-mali.dtsi b/arch/arm64/boot/dts/amlogic/meson-gxl-mali.dtsi
new file mode 100644
index 0000000..f06cc234
--- /dev/null
+++ b/arch/arm64/boot/dts/amlogic/meson-gxl-mali.dtsi
@@ -0,0 +1,43 @@
+/*
+ * Copyright (c) 2017 BayLibre SAS
+ * Author: Neil Armstrong <narmstrong@baylibre.com>
+ *
+ * SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+ */
+
+&apb {
+	mali: gpu@c0000 {
+		compatible = "amlogic,meson-gxbb-mali", "arm,mali-450";
+		reg = <0x0 0xc0000 0x0 0x40000>;
+		interrupts = <GIC_SPI 160 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 161 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 162 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 163 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 164 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 165 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 166 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 167 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 168 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 169 IRQ_TYPE_LEVEL_HIGH>;
+		interrupt-names = "gp", "gpmmu", "pp", "pmu",
+			"pp0", "ppmmu0", "pp1", "ppmmu1",
+			"pp2", "ppmmu2";
+		clocks = <&clkc CLKID_CLK81>, <&clkc CLKID_MALI>;
+		clock-names = "bus", "core";
+
+		/*
+		 * Mali clocking is provided by two identical clock paths
+		 * MALI_0 and MALI_1 muxed to a single clock by a glitch
+		 * free mux to safely change frequency while running.
+		 */
+		assigned-clocks = <&clkc CLKID_MALI_0_SEL>,
+				  <&clkc CLKID_MALI_0>,
+				  <&clkc CLKID_MALI>; /* Glitch free mux */
+		assigned-clock-parents = <&clkc CLKID_FCLK_DIV3>,
+					 <0>, /* Do Nothing */
+					 <&clkc CLKID_MALI_0>;
+		assigned-clock-rates = <0>, /* Do Nothing */
+				       <666666666>,
+				       <0>; /* Do Nothing */
+	};
+};
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl-s905d.dtsi b/arch/arm64/boot/dts/amlogic/meson-gxl-s905d.dtsi
index 615308e..5a90e30 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxl-s905d.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gxl-s905d.dtsi
@@ -42,6 +42,7 @@
  */
 
 #include "meson-gxl.dtsi"
+#include "meson-gxl-mali.dtsi"
 
 / {
 	compatible = "amlogic,s905d", "amlogic,meson-gxl";
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl-s905x.dtsi b/arch/arm64/boot/dts/amlogic/meson-gxl-s905x.dtsi
index 08237ee..0f78d83 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxl-s905x.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gxl-s905x.dtsi
@@ -42,6 +42,7 @@
  */
 
 #include "meson-gxl.dtsi"
+#include "meson-gxl-mali.dtsi"
 
 / {
 	compatible = "amlogic,s905x", "amlogic,meson-gxl";
-- 
1.9.1

[PATCH v2 3/3] ARM64: dts: meson-gx: Add MALI nodes for GXBB and GXL

[Neil Armstrong]

The same MALI-450 MP3 GPU is present in the GXBB and GXL SoCs.

The node is simply added in the meson-gxbb.dtsi file.

For GXL, since a lot is shared with the GXM that has a MALI-T820 IP, this
patch adds a new meson-gxl-mali.dtsi and is included in the SoC specific
dtsi files.

Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
 arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi      | 37 ++++++++++++++++++++
 arch/arm64/boot/dts/amlogic/meson-gxl-mali.dtsi  | 43 ++++++++++++++++++++++++
 arch/arm64/boot/dts/amlogic/meson-gxl-s905d.dtsi |  1 +
 arch/arm64/boot/dts/amlogic/meson-gxl-s905x.dtsi |  1 +
 4 files changed, 82 insertions(+)
 create mode 100644 arch/arm64/boot/dts/amlogic/meson-gxl-mali.dtsi

diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi b/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
index b353073..4f7ae6a 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
@@ -474,6 +474,43 @@
 	};
 };
 
+&apb {
+	mali: gpu@c0000 {
+		compatible = "amlogic,meson-gxbb-mali", "arm,mali-450";
+		reg = <0x0 0xc0000 0x0 0x40000>;
+		interrupts = <GIC_SPI 160 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 161 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 162 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 163 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 164 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 165 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 166 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 167 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 168 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 169 IRQ_TYPE_LEVEL_HIGH>;
+		interrupt-names = "gp", "gpmmu", "pp", "pmu",
+			"pp0", "ppmmu0", "pp1", "ppmmu1",
+			"pp2", "ppmmu2";
+		clocks = <&clkc CLKID_CLK81>, <&clkc CLKID_MALI>;
+		clock-names = "bus", "core";
+
+		/*
+		 * Mali clocking is provided by two identical clock paths
+		 * MALI_0 and MALI_1 muxed to a single clock by a glitch
+		 * free mux to safely change frequency while running.
+		 */
+		assigned-clocks = <&clkc CLKID_MALI_0_SEL>,
+				  <&clkc CLKID_MALI_0>,
+				  <&clkc CLKID_MALI>; /* Glitch free mux */
+		assigned-clock-parents = <&clkc CLKID_FCLK_DIV3>,
+					 <0>, /* Do Nothing */
+					 <&clkc CLKID_MALI_0>;
+		assigned-clock-rates = <0>, /* Do Nothing */
+				       <666666666>,
+				       <0>; /* Do Nothing */
+	};
+};
+
 &i2c_A {
 	clocks = <&clkc CLKID_I2C>;
 };
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl-mali.dtsi b/arch/arm64/boot/dts/amlogic/meson-gxl-mali.dtsi
new file mode 100644
index 0000000..f06cc234
--- /dev/null
+++ b/arch/arm64/boot/dts/amlogic/meson-gxl-mali.dtsi
@@ -0,0 +1,43 @@
+/*
+ * Copyright (c) 2017 BayLibre SAS
+ * Author: Neil Armstrong <narmstrong@baylibre.com>
+ *
+ * SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+ */
+
+&apb {
+	mali: gpu@c0000 {
+		compatible = "amlogic,meson-gxbb-mali", "arm,mali-450";
+		reg = <0x0 0xc0000 0x0 0x40000>;
+		interrupts = <GIC_SPI 160 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 161 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 162 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 163 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 164 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 165 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 166 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 167 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 168 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 169 IRQ_TYPE_LEVEL_HIGH>;
+		interrupt-names = "gp", "gpmmu", "pp", "pmu",
+			"pp0", "ppmmu0", "pp1", "ppmmu1",
+			"pp2", "ppmmu2";
+		clocks = <&clkc CLKID_CLK81>, <&clkc CLKID_MALI>;
+		clock-names = "bus", "core";
+
+		/*
+		 * Mali clocking is provided by two identical clock paths
+		 * MALI_0 and MALI_1 muxed to a single clock by a glitch
+		 * free mux to safely change frequency while running.
+		 */
+		assigned-clocks = <&clkc CLKID_MALI_0_SEL>,
+				  <&clkc CLKID_MALI_0>,
+				  <&clkc CLKID_MALI>; /* Glitch free mux */
+		assigned-clock-parents = <&clkc CLKID_FCLK_DIV3>,
+					 <0>, /* Do Nothing */
+					 <&clkc CLKID_MALI_0>;
+		assigned-clock-rates = <0>, /* Do Nothing */
+				       <666666666>,
+				       <0>; /* Do Nothing */
+	};
+};
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl-s905d.dtsi b/arch/arm64/boot/dts/amlogic/meson-gxl-s905d.dtsi
index 615308e..5a90e30 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxl-s905d.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gxl-s905d.dtsi
@@ -42,6 +42,7 @@
  */
 
 #include "meson-gxl.dtsi"
+#include "meson-gxl-mali.dtsi"
 
 / {
 	compatible = "amlogic,s905d", "amlogic,meson-gxl";
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl-s905x.dtsi b/arch/arm64/boot/dts/amlogic/meson-gxl-s905x.dtsi
index 08237ee..0f78d83 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxl-s905x.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gxl-s905x.dtsi
@@ -42,6 +42,7 @@
  */
 
 #include "meson-gxl.dtsi"
+#include "meson-gxl-mali.dtsi"
 
 / {
 	compatible = "amlogic,s905x", "amlogic,meson-gxl";
-- 
1.9.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v2 3/3] ARM64: dts: meson-gx: Add MALI nodes for GXBB and GXL

[Neil Armstrong]

The same MALI-450 MP3 GPU is present in the GXBB and GXL SoCs.

The node is simply added in the meson-gxbb.dtsi file.

For GXL, since a lot is shared with the GXM that has a MALI-T820 IP, this
patch adds a new meson-gxl-mali.dtsi and is included in the SoC specific
dtsi files.

Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
 arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi      | 37 ++++++++++++++++++++
 arch/arm64/boot/dts/amlogic/meson-gxl-mali.dtsi  | 43 ++++++++++++++++++++++++
 arch/arm64/boot/dts/amlogic/meson-gxl-s905d.dtsi |  1 +
 arch/arm64/boot/dts/amlogic/meson-gxl-s905x.dtsi |  1 +
 4 files changed, 82 insertions(+)
 create mode 100644 arch/arm64/boot/dts/amlogic/meson-gxl-mali.dtsi

diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi b/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
index b353073..4f7ae6a 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
@@ -474,6 +474,43 @@
 	};
 };
 
+&apb {
+	mali: gpu at c0000 {
+		compatible = "amlogic,meson-gxbb-mali", "arm,mali-450";
+		reg = <0x0 0xc0000 0x0 0x40000>;
+		interrupts = <GIC_SPI 160 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 161 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 162 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 163 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 164 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 165 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 166 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 167 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 168 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 169 IRQ_TYPE_LEVEL_HIGH>;
+		interrupt-names = "gp", "gpmmu", "pp", "pmu",
+			"pp0", "ppmmu0", "pp1", "ppmmu1",
+			"pp2", "ppmmu2";
+		clocks = <&clkc CLKID_CLK81>, <&clkc CLKID_MALI>;
+		clock-names = "bus", "core";
+
+		/*
+		 * Mali clocking is provided by two identical clock paths
+		 * MALI_0 and MALI_1 muxed to a single clock by a glitch
+		 * free mux to safely change frequency while running.
+		 */
+		assigned-clocks = <&clkc CLKID_MALI_0_SEL>,
+				  <&clkc CLKID_MALI_0>,
+				  <&clkc CLKID_MALI>; /* Glitch free mux */
+		assigned-clock-parents = <&clkc CLKID_FCLK_DIV3>,
+					 <0>, /* Do Nothing */
+					 <&clkc CLKID_MALI_0>;
+		assigned-clock-rates = <0>, /* Do Nothing */
+				       <666666666>,
+				       <0>; /* Do Nothing */
+	};
+};
+
 &i2c_A {
 	clocks = <&clkc CLKID_I2C>;
 };
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl-mali.dtsi b/arch/arm64/boot/dts/amlogic/meson-gxl-mali.dtsi
new file mode 100644
index 0000000..f06cc234
--- /dev/null
+++ b/arch/arm64/boot/dts/amlogic/meson-gxl-mali.dtsi
@@ -0,0 +1,43 @@
+/*
+ * Copyright (c) 2017 BayLibre SAS
+ * Author: Neil Armstrong <narmstrong@baylibre.com>
+ *
+ * SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+ */
+
+&apb {
+	mali: gpu at c0000 {
+		compatible = "amlogic,meson-gxbb-mali", "arm,mali-450";
+		reg = <0x0 0xc0000 0x0 0x40000>;
+		interrupts = <GIC_SPI 160 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 161 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 162 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 163 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 164 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 165 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 166 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 167 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 168 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 169 IRQ_TYPE_LEVEL_HIGH>;
+		interrupt-names = "gp", "gpmmu", "pp", "pmu",
+			"pp0", "ppmmu0", "pp1", "ppmmu1",
+			"pp2", "ppmmu2";
+		clocks = <&clkc CLKID_CLK81>, <&clkc CLKID_MALI>;
+		clock-names = "bus", "core";
+
+		/*
+		 * Mali clocking is provided by two identical clock paths
+		 * MALI_0 and MALI_1 muxed to a single clock by a glitch
+		 * free mux to safely change frequency while running.
+		 */
+		assigned-clocks = <&clkc CLKID_MALI_0_SEL>,
+				  <&clkc CLKID_MALI_0>,
+				  <&clkc CLKID_MALI>; /* Glitch free mux */
+		assigned-clock-parents = <&clkc CLKID_FCLK_DIV3>,
+					 <0>, /* Do Nothing */
+					 <&clkc CLKID_MALI_0>;
+		assigned-clock-rates = <0>, /* Do Nothing */
+				       <666666666>,
+				       <0>; /* Do Nothing */
+	};
+};
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl-s905d.dtsi b/arch/arm64/boot/dts/amlogic/meson-gxl-s905d.dtsi
index 615308e..5a90e30 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxl-s905d.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gxl-s905d.dtsi
@@ -42,6 +42,7 @@
  */
 
 #include "meson-gxl.dtsi"
+#include "meson-gxl-mali.dtsi"
 
 / {
 	compatible = "amlogic,s905d", "amlogic,meson-gxl";
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl-s905x.dtsi b/arch/arm64/boot/dts/amlogic/meson-gxl-s905x.dtsi
index 08237ee..0f78d83 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxl-s905x.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gxl-s905x.dtsi
@@ -42,6 +42,7 @@
  */
 
 #include "meson-gxl.dtsi"
+#include "meson-gxl-mali.dtsi"
 
 / {
 	compatible = "amlogic,s905x", "amlogic,meson-gxl";
-- 
1.9.1

[PATCH v2 3/3] ARM64: dts: meson-gx: Add MALI nodes for GXBB and GXL

[Neil Armstrong]

The same MALI-450 MP3 GPU is present in the GXBB and GXL SoCs.

The node is simply added in the meson-gxbb.dtsi file.

For GXL, since a lot is shared with the GXM that has a MALI-T820 IP, this
patch adds a new meson-gxl-mali.dtsi and is included in the SoC specific
dtsi files.

Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
 arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi      | 37 ++++++++++++++++++++
 arch/arm64/boot/dts/amlogic/meson-gxl-mali.dtsi  | 43 ++++++++++++++++++++++++
 arch/arm64/boot/dts/amlogic/meson-gxl-s905d.dtsi |  1 +
 arch/arm64/boot/dts/amlogic/meson-gxl-s905x.dtsi |  1 +
 4 files changed, 82 insertions(+)
 create mode 100644 arch/arm64/boot/dts/amlogic/meson-gxl-mali.dtsi

diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi b/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
index b353073..4f7ae6a 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
@@ -474,6 +474,43 @@
 	};
 };
 
+&apb {
+	mali: gpu at c0000 {
+		compatible = "amlogic,meson-gxbb-mali", "arm,mali-450";
+		reg = <0x0 0xc0000 0x0 0x40000>;
+		interrupts = <GIC_SPI 160 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 161 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 162 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 163 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 164 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 165 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 166 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 167 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 168 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 169 IRQ_TYPE_LEVEL_HIGH>;
+		interrupt-names = "gp", "gpmmu", "pp", "pmu",
+			"pp0", "ppmmu0", "pp1", "ppmmu1",
+			"pp2", "ppmmu2";
+		clocks = <&clkc CLKID_CLK81>, <&clkc CLKID_MALI>;
+		clock-names = "bus", "core";
+
+		/*
+		 * Mali clocking is provided by two identical clock paths
+		 * MALI_0 and MALI_1 muxed to a single clock by a glitch
+		 * free mux to safely change frequency while running.
+		 */
+		assigned-clocks = <&clkc CLKID_MALI_0_SEL>,
+				  <&clkc CLKID_MALI_0>,
+				  <&clkc CLKID_MALI>; /* Glitch free mux */
+		assigned-clock-parents = <&clkc CLKID_FCLK_DIV3>,
+					 <0>, /* Do Nothing */
+					 <&clkc CLKID_MALI_0>;
+		assigned-clock-rates = <0>, /* Do Nothing */
+				       <666666666>,
+				       <0>; /* Do Nothing */
+	};
+};
+
 &i2c_A {
 	clocks = <&clkc CLKID_I2C>;
 };
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl-mali.dtsi b/arch/arm64/boot/dts/amlogic/meson-gxl-mali.dtsi
new file mode 100644
index 0000000..f06cc234
--- /dev/null
+++ b/arch/arm64/boot/dts/amlogic/meson-gxl-mali.dtsi
@@ -0,0 +1,43 @@
+/*
+ * Copyright (c) 2017 BayLibre SAS
+ * Author: Neil Armstrong <narmstrong@baylibre.com>
+ *
+ * SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+ */
+
+&apb {
+	mali: gpu at c0000 {
+		compatible = "amlogic,meson-gxbb-mali", "arm,mali-450";
+		reg = <0x0 0xc0000 0x0 0x40000>;
+		interrupts = <GIC_SPI 160 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 161 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 162 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 163 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 164 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 165 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 166 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 167 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 168 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 169 IRQ_TYPE_LEVEL_HIGH>;
+		interrupt-names = "gp", "gpmmu", "pp", "pmu",
+			"pp0", "ppmmu0", "pp1", "ppmmu1",
+			"pp2", "ppmmu2";
+		clocks = <&clkc CLKID_CLK81>, <&clkc CLKID_MALI>;
+		clock-names = "bus", "core";
+
+		/*
+		 * Mali clocking is provided by two identical clock paths
+		 * MALI_0 and MALI_1 muxed to a single clock by a glitch
+		 * free mux to safely change frequency while running.
+		 */
+		assigned-clocks = <&clkc CLKID_MALI_0_SEL>,
+				  <&clkc CLKID_MALI_0>,
+				  <&clkc CLKID_MALI>; /* Glitch free mux */
+		assigned-clock-parents = <&clkc CLKID_FCLK_DIV3>,
+					 <0>, /* Do Nothing */
+					 <&clkc CLKID_MALI_0>;
+		assigned-clock-rates = <0>, /* Do Nothing */
+				       <666666666>,
+				       <0>; /* Do Nothing */
+	};
+};
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl-s905d.dtsi b/arch/arm64/boot/dts/amlogic/meson-gxl-s905d.dtsi
index 615308e..5a90e30 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxl-s905d.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gxl-s905d.dtsi
@@ -42,6 +42,7 @@
  */
 
 #include "meson-gxl.dtsi"
+#include "meson-gxl-mali.dtsi"
 
 / {
 	compatible = "amlogic,s905d", "amlogic,meson-gxl";
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl-s905x.dtsi b/arch/arm64/boot/dts/amlogic/meson-gxl-s905x.dtsi
index 08237ee..0f78d83 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxl-s905x.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gxl-s905x.dtsi
@@ -42,6 +42,7 @@
  */
 
 #include "meson-gxl.dtsi"
+#include "meson-gxl-mali.dtsi"
 
 / {
 	compatible = "amlogic,s905x", "amlogic,meson-gxl";
-- 
1.9.1

Re: [PATCH v2 2/3] clk: meson-gxbb: Add MALI clocks

[Stephen Boyd]

On 03/01, Neil Armstrong wrote:
> diff --git a/drivers/clk/meson/gxbb.c b/drivers/clk/meson/gxbb.c
> index a52063f..31f6090 100644
> --- a/drivers/clk/meson/gxbb.c
> +++ b/drivers/clk/meson/gxbb.c
> @@ -634,6 +634,131 @@
>  	},
>  };
>  
> +/*
> + * The MALI IP is clocked by two identical clocks (mali_0 and mali_1)
> + * muxed by a glitch-free switch.
> + */
> +
> +static u32 mux_table_mali_0_1[] = {0, 1, 2, 3, 4, 5, 6, 7};
> +const char *gxbb_mali_0_1_parent_names[] = {

static?

> +	"xtal", "gp0_pll", "mpll2", "mpll1", "fclk_div7",
> +	"fclk_div4", "fclk_div3", "fclk_div5"
> +};
> +
[..]
> +	.reg = (void *)HHI_MALI_CLK_CNTL,
> +	.bit_idx = 24,
> +	.lock = &clk_lock,
> +	.hw.init = &(struct clk_init_data){
> +		.name = "mali_1",
> +		.ops = &clk_gate_ops,
> +		.parent_names = (const char *[]){ "mali_1_div" },
> +		.num_parents = 1,
> +		.flags = (CLK_SET_RATE_PARENT | CLK_IGNORE_UNUSED),
> +	},
> +};
> +
> +static u32 mux_table_mali[] = {0, 1};
> +const char *gxbb_mali_parent_names[] = {

static?

> +	"mali_0", "mali_1"
> +};
[...]
>  static struct clk_mux *gxbb_clk_muxes[] = {
>  	&gxbb_mpeg_clk_sel,
>  	&gxbb_sar_adc_clk_sel,
> +	&gxbb_mali_0_sel,
> +	&gxbb_mali_1_sel,
> +	&gxbb_mali,
>  };
>  
>  static struct clk_divider *gxbb_clk_dividers[] = {

Can these arrays be const? If so, please do that in a separate
patch.

>  	&gxbb_mpeg_clk_div,
>  	&gxbb_sar_adc_clk_div,
> +	&gxbb_mali_0_div,
> +	&gxbb_mali_1_div,
>  };
-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH v2 2/3] clk: meson-gxbb: Add MALI clocks

[Stephen Boyd]

On 03/01, Neil Armstrong wrote:
> diff --git a/drivers/clk/meson/gxbb.c b/drivers/clk/meson/gxbb.c
> index a52063f..31f6090 100644
> --- a/drivers/clk/meson/gxbb.c
> +++ b/drivers/clk/meson/gxbb.c
> @@ -634,6 +634,131 @@
>  	},
>  };
>  
> +/*
> + * The MALI IP is clocked by two identical clocks (mali_0 and mali_1)
> + * muxed by a glitch-free switch.
> + */
> +
> +static u32 mux_table_mali_0_1[] = {0, 1, 2, 3, 4, 5, 6, 7};
> +const char *gxbb_mali_0_1_parent_names[] = {

static?

> +	"xtal", "gp0_pll", "mpll2", "mpll1", "fclk_div7",
> +	"fclk_div4", "fclk_div3", "fclk_div5"
> +};
> +
[..]
> +	.reg = (void *)HHI_MALI_CLK_CNTL,
> +	.bit_idx = 24,
> +	.lock = &clk_lock,
> +	.hw.init = &(struct clk_init_data){
> +		.name = "mali_1",
> +		.ops = &clk_gate_ops,
> +		.parent_names = (const char *[]){ "mali_1_div" },
> +		.num_parents = 1,
> +		.flags = (CLK_SET_RATE_PARENT | CLK_IGNORE_UNUSED),
> +	},
> +};
> +
> +static u32 mux_table_mali[] = {0, 1};
> +const char *gxbb_mali_parent_names[] = {

static?

> +	"mali_0", "mali_1"
> +};
[...]
>  static struct clk_mux *gxbb_clk_muxes[] = {
>  	&gxbb_mpeg_clk_sel,
>  	&gxbb_sar_adc_clk_sel,
> +	&gxbb_mali_0_sel,
> +	&gxbb_mali_1_sel,
> +	&gxbb_mali,
>  };
>  
>  static struct clk_divider *gxbb_clk_dividers[] = {

Can these arrays be const? If so, please do that in a separate
patch.

>  	&gxbb_mpeg_clk_div,
>  	&gxbb_sar_adc_clk_div,
> +	&gxbb_mali_0_div,
> +	&gxbb_mali_1_div,
>  };
-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

_______________________________________________
linux-amlogic mailing list
linux-amlogic@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-amlogic

[PATCH v2 2/3] clk: meson-gxbb: Add MALI clocks

[Stephen Boyd]

On 03/01, Neil Armstrong wrote:
> diff --git a/drivers/clk/meson/gxbb.c b/drivers/clk/meson/gxbb.c
> index a52063f..31f6090 100644
> --- a/drivers/clk/meson/gxbb.c
> +++ b/drivers/clk/meson/gxbb.c
> @@ -634,6 +634,131 @@
>  	},
>  };
>  
> +/*
> + * The MALI IP is clocked by two identical clocks (mali_0 and mali_1)
> + * muxed by a glitch-free switch.
> + */
> +
> +static u32 mux_table_mali_0_1[] = {0, 1, 2, 3, 4, 5, 6, 7};
> +const char *gxbb_mali_0_1_parent_names[] = {

static?

> +	"xtal", "gp0_pll", "mpll2", "mpll1", "fclk_div7",
> +	"fclk_div4", "fclk_div3", "fclk_div5"
> +};
> +
[..]
> +	.reg = (void *)HHI_MALI_CLK_CNTL,
> +	.bit_idx = 24,
> +	.lock = &clk_lock,
> +	.hw.init = &(struct clk_init_data){
> +		.name = "mali_1",
> +		.ops = &clk_gate_ops,
> +		.parent_names = (const char *[]){ "mali_1_div" },
> +		.num_parents = 1,
> +		.flags = (CLK_SET_RATE_PARENT | CLK_IGNORE_UNUSED),
> +	},
> +};
> +
> +static u32 mux_table_mali[] = {0, 1};
> +const char *gxbb_mali_parent_names[] = {

static?

> +	"mali_0", "mali_1"
> +};
[...]
>  static struct clk_mux *gxbb_clk_muxes[] = {
>  	&gxbb_mpeg_clk_sel,
>  	&gxbb_sar_adc_clk_sel,
> +	&gxbb_mali_0_sel,
> +	&gxbb_mali_1_sel,
> +	&gxbb_mali,
>  };
>  
>  static struct clk_divider *gxbb_clk_dividers[] = {

Can these arrays be const? If so, please do that in a separate
patch.

>  	&gxbb_mpeg_clk_div,
>  	&gxbb_sar_adc_clk_div,
> +	&gxbb_mali_0_div,
> +	&gxbb_mali_1_div,
>  };
-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v2 2/3] clk: meson-gxbb: Add MALI clocks

[Stephen Boyd]

On 03/01, Neil Armstrong wrote:
> diff --git a/drivers/clk/meson/gxbb.c b/drivers/clk/meson/gxbb.c
> index a52063f..31f6090 100644
> --- a/drivers/clk/meson/gxbb.c
> +++ b/drivers/clk/meson/gxbb.c
> @@ -634,6 +634,131 @@
>  	},
>  };
>  
> +/*
> + * The MALI IP is clocked by two identical clocks (mali_0 and mali_1)
> + * muxed by a glitch-free switch.
> + */
> +
> +static u32 mux_table_mali_0_1[] = {0, 1, 2, 3, 4, 5, 6, 7};
> +const char *gxbb_mali_0_1_parent_names[] = {

static?

> +	"xtal", "gp0_pll", "mpll2", "mpll1", "fclk_div7",
> +	"fclk_div4", "fclk_div3", "fclk_div5"
> +};
> +
[..]
> +	.reg = (void *)HHI_MALI_CLK_CNTL,
> +	.bit_idx = 24,
> +	.lock = &clk_lock,
> +	.hw.init = &(struct clk_init_data){
> +		.name = "mali_1",
> +		.ops = &clk_gate_ops,
> +		.parent_names = (const char *[]){ "mali_1_div" },
> +		.num_parents = 1,
> +		.flags = (CLK_SET_RATE_PARENT | CLK_IGNORE_UNUSED),
> +	},
> +};
> +
> +static u32 mux_table_mali[] = {0, 1};
> +const char *gxbb_mali_parent_names[] = {

static?

> +	"mali_0", "mali_1"
> +};
[...]
>  static struct clk_mux *gxbb_clk_muxes[] = {
>  	&gxbb_mpeg_clk_sel,
>  	&gxbb_sar_adc_clk_sel,
> +	&gxbb_mali_0_sel,
> +	&gxbb_mali_1_sel,
> +	&gxbb_mali,
>  };
>  
>  static struct clk_divider *gxbb_clk_dividers[] = {

Can these arrays be const? If so, please do that in a separate
patch.

>  	&gxbb_mpeg_clk_div,
>  	&gxbb_sar_adc_clk_div,
> +	&gxbb_mali_0_div,
> +	&gxbb_mali_1_div,
>  };
-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH v2 2/3] clk: meson-gxbb: Add MALI clocks

[Neil Armstrong]

Hi Stephen,

On 03/01/2017 08:11 PM, Stephen Boyd wrote:
> On 03/01, Neil Armstrong wrote:
>> diff --git a/drivers/clk/meson/gxbb.c b/drivers/clk/meson/gxbb.c
>> index a52063f..31f6090 100644
>> --- a/drivers/clk/meson/gxbb.c
>> +++ b/drivers/clk/meson/gxbb.c
>> @@ -634,6 +634,131 @@
>>  	},
>>  };
>>  
>> +/*
>> + * The MALI IP is clocked by two identical clocks (mali_0 and mali_1)
>> + * muxed by a glitch-free switch.
>> + */
>> +
>> +static u32 mux_table_mali_0_1[] = {0, 1, 2, 3, 4, 5, 6, 7};
>> +const char *gxbb_mali_0_1_parent_names[] = {
> 
> static?

Will do !

> 
>> +	"xtal", "gp0_pll", "mpll2", "mpll1", "fclk_div7",
>> +	"fclk_div4", "fclk_div3", "fclk_div5"
>> +};
>> +
> [..]
>> +	.reg = (void *)HHI_MALI_CLK_CNTL,
>> +	.bit_idx = 24,
>> +	.lock = &clk_lock,
>> +	.hw.init = &(struct clk_init_data){
>> +		.name = "mali_1",
>> +		.ops = &clk_gate_ops,
>> +		.parent_names = (const char *[]){ "mali_1_div" },
>> +		.num_parents = 1,
>> +		.flags = (CLK_SET_RATE_PARENT | CLK_IGNORE_UNUSED),
>> +	},
>> +};
>> +
>> +static u32 mux_table_mali[] = {0, 1};
>> +const char *gxbb_mali_parent_names[] = {
> 
> static?
> 
>> +	"mali_0", "mali_1"
>> +};
> [...]
>>  static struct clk_mux *gxbb_clk_muxes[] = {
>>  	&gxbb_mpeg_clk_sel,
>>  	&gxbb_sar_adc_clk_sel,
>> +	&gxbb_mali_0_sel,
>> +	&gxbb_mali_1_sel,
>> +	&gxbb_mali,
>>  };
>>  
>>  static struct clk_divider *gxbb_clk_dividers[] = {
> 
> Can these arrays be const? If so, please do that in a separate
> patch.

Hmm, these were introduced by jerome, he should update them accordingly.

>>  	&gxbb_mpeg_clk_div,
>>  	&gxbb_sar_adc_clk_div,
>> +	&gxbb_mali_0_div,
>> +	&gxbb_mali_1_div,
>>  };


Thanks,
Neil

Re: [PATCH v2 2/3] clk: meson-gxbb: Add MALI clocks

[Neil Armstrong]

Hi Stephen,

On 03/01/2017 08:11 PM, Stephen Boyd wrote:
> On 03/01, Neil Armstrong wrote:
>> diff --git a/drivers/clk/meson/gxbb.c b/drivers/clk/meson/gxbb.c
>> index a52063f..31f6090 100644
>> --- a/drivers/clk/meson/gxbb.c
>> +++ b/drivers/clk/meson/gxbb.c
>> @@ -634,6 +634,131 @@
>>  	},
>>  };
>>  
>> +/*
>> + * The MALI IP is clocked by two identical clocks (mali_0 and mali_1)
>> + * muxed by a glitch-free switch.
>> + */
>> +
>> +static u32 mux_table_mali_0_1[] = {0, 1, 2, 3, 4, 5, 6, 7};
>> +const char *gxbb_mali_0_1_parent_names[] = {
> 
> static?

Will do !

> 
>> +	"xtal", "gp0_pll", "mpll2", "mpll1", "fclk_div7",
>> +	"fclk_div4", "fclk_div3", "fclk_div5"
>> +};
>> +
> [..]
>> +	.reg = (void *)HHI_MALI_CLK_CNTL,
>> +	.bit_idx = 24,
>> +	.lock = &clk_lock,
>> +	.hw.init = &(struct clk_init_data){
>> +		.name = "mali_1",
>> +		.ops = &clk_gate_ops,
>> +		.parent_names = (const char *[]){ "mali_1_div" },
>> +		.num_parents = 1,
>> +		.flags = (CLK_SET_RATE_PARENT | CLK_IGNORE_UNUSED),
>> +	},
>> +};
>> +
>> +static u32 mux_table_mali[] = {0, 1};
>> +const char *gxbb_mali_parent_names[] = {
> 
> static?
> 
>> +	"mali_0", "mali_1"
>> +};
> [...]
>>  static struct clk_mux *gxbb_clk_muxes[] = {
>>  	&gxbb_mpeg_clk_sel,
>>  	&gxbb_sar_adc_clk_sel,
>> +	&gxbb_mali_0_sel,
>> +	&gxbb_mali_1_sel,
>> +	&gxbb_mali,
>>  };
>>  
>>  static struct clk_divider *gxbb_clk_dividers[] = {
> 
> Can these arrays be const? If so, please do that in a separate
> patch.

Hmm, these were introduced by jerome, he should update them accordingly.

>>  	&gxbb_mpeg_clk_div,
>>  	&gxbb_sar_adc_clk_div,
>> +	&gxbb_mali_0_div,
>> +	&gxbb_mali_1_div,
>>  };


Thanks,
Neil

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v2 2/3] clk: meson-gxbb: Add MALI clocks

[Neil Armstrong]

Hi Stephen,

On 03/01/2017 08:11 PM, Stephen Boyd wrote:
> On 03/01, Neil Armstrong wrote:
>> diff --git a/drivers/clk/meson/gxbb.c b/drivers/clk/meson/gxbb.c
>> index a52063f..31f6090 100644
>> --- a/drivers/clk/meson/gxbb.c
>> +++ b/drivers/clk/meson/gxbb.c
>> @@ -634,6 +634,131 @@
>>  	},
>>  };
>>  
>> +/*
>> + * The MALI IP is clocked by two identical clocks (mali_0 and mali_1)
>> + * muxed by a glitch-free switch.
>> + */
>> +
>> +static u32 mux_table_mali_0_1[] = {0, 1, 2, 3, 4, 5, 6, 7};
>> +const char *gxbb_mali_0_1_parent_names[] = {
> 
> static?

Will do !

> 
>> +	"xtal", "gp0_pll", "mpll2", "mpll1", "fclk_div7",
>> +	"fclk_div4", "fclk_div3", "fclk_div5"
>> +};
>> +
> [..]
>> +	.reg = (void *)HHI_MALI_CLK_CNTL,
>> +	.bit_idx = 24,
>> +	.lock = &clk_lock,
>> +	.hw.init = &(struct clk_init_data){
>> +		.name = "mali_1",
>> +		.ops = &clk_gate_ops,
>> +		.parent_names = (const char *[]){ "mali_1_div" },
>> +		.num_parents = 1,
>> +		.flags = (CLK_SET_RATE_PARENT | CLK_IGNORE_UNUSED),
>> +	},
>> +};
>> +
>> +static u32 mux_table_mali[] = {0, 1};
>> +const char *gxbb_mali_parent_names[] = {
> 
> static?
> 
>> +	"mali_0", "mali_1"
>> +};
> [...]
>>  static struct clk_mux *gxbb_clk_muxes[] = {
>>  	&gxbb_mpeg_clk_sel,
>>  	&gxbb_sar_adc_clk_sel,
>> +	&gxbb_mali_0_sel,
>> +	&gxbb_mali_1_sel,
>> +	&gxbb_mali,
>>  };
>>  
>>  static struct clk_divider *gxbb_clk_dividers[] = {
> 
> Can these arrays be const? If so, please do that in a separate
> patch.

Hmm, these were introduced by jerome, he should update them accordingly.

>>  	&gxbb_mpeg_clk_div,
>>  	&gxbb_sar_adc_clk_div,
>> +	&gxbb_mali_0_div,
>> +	&gxbb_mali_1_div,
>>  };


Thanks,
Neil

[PATCH v2 2/3] clk: meson-gxbb: Add MALI clocks

[Neil Armstrong]

Hi Stephen,

On 03/01/2017 08:11 PM, Stephen Boyd wrote:
> On 03/01, Neil Armstrong wrote:
>> diff --git a/drivers/clk/meson/gxbb.c b/drivers/clk/meson/gxbb.c
>> index a52063f..31f6090 100644
>> --- a/drivers/clk/meson/gxbb.c
>> +++ b/drivers/clk/meson/gxbb.c
>> @@ -634,6 +634,131 @@
>>  	},
>>  };
>>  
>> +/*
>> + * The MALI IP is clocked by two identical clocks (mali_0 and mali_1)
>> + * muxed by a glitch-free switch.
>> + */
>> +
>> +static u32 mux_table_mali_0_1[] = {0, 1, 2, 3, 4, 5, 6, 7};
>> +const char *gxbb_mali_0_1_parent_names[] = {
> 
> static?

Will do !

> 
>> +	"xtal", "gp0_pll", "mpll2", "mpll1", "fclk_div7",
>> +	"fclk_div4", "fclk_div3", "fclk_div5"
>> +};
>> +
> [..]
>> +	.reg = (void *)HHI_MALI_CLK_CNTL,
>> +	.bit_idx = 24,
>> +	.lock = &clk_lock,
>> +	.hw.init = &(struct clk_init_data){
>> +		.name = "mali_1",
>> +		.ops = &clk_gate_ops,
>> +		.parent_names = (const char *[]){ "mali_1_div" },
>> +		.num_parents = 1,
>> +		.flags = (CLK_SET_RATE_PARENT | CLK_IGNORE_UNUSED),
>> +	},
>> +};
>> +
>> +static u32 mux_table_mali[] = {0, 1};
>> +const char *gxbb_mali_parent_names[] = {
> 
> static?
> 
>> +	"mali_0", "mali_1"
>> +};
> [...]
>>  static struct clk_mux *gxbb_clk_muxes[] = {
>>  	&gxbb_mpeg_clk_sel,
>>  	&gxbb_sar_adc_clk_sel,
>> +	&gxbb_mali_0_sel,
>> +	&gxbb_mali_1_sel,
>> +	&gxbb_mali,
>>  };
>>  
>>  static struct clk_divider *gxbb_clk_dividers[] = {
> 
> Can these arrays be const? If so, please do that in a separate
> patch.

Hmm, these were introduced by jerome, he should update them accordingly.

>>  	&gxbb_mpeg_clk_div,
>>  	&gxbb_sar_adc_clk_div,
>> +	&gxbb_mali_0_div,
>> +	&gxbb_mali_1_div,
>>  };


Thanks,
Neil

Re: [PATCH v2 2/3] clk: meson-gxbb: Add MALI clocks

[Jerome Brunet]

On Thu, 2017-03-02 at 12:07 +0100, Neil Armstrong wrote:
> Hi Stephen,
> 
> On 03/01/2017 08:11 PM, Stephen Boyd wrote:
> > On 03/01, Neil Armstrong wrote:
> > > diff --git a/drivers/clk/meson/gxbb.c b/drivers/clk/meson/gxbb.c
> > > index a52063f..31f6090 100644
> > > --- a/drivers/clk/meson/gxbb.c
> > > +++ b/drivers/clk/meson/gxbb.c
> > > @@ -634,6 +634,131 @@
> > >  	},
> > >  };
> > >  
> > > +/*
> > > + * The MALI IP is clocked by two identical clocks (mali_0 and
> > > mali_1)
> > > + * muxed by a glitch-free switch.
> > > + */
> > > +
> > > +static u32 mux_table_mali_0_1[] = {0, 1, 2, 3, 4, 5, 6, 7};
> > > +const char *gxbb_mali_0_1_parent_names[] = {
> > 
> > static?
> 
> Will do !
> 
> > 
> > > +	"xtal", "gp0_pll", "mpll2", "mpll1", "fclk_div7",
> > > +	"fclk_div4", "fclk_div3", "fclk_div5"
> > > +};
> > > +
> > 
> > [..]
> > > +	.reg = (void *)HHI_MALI_CLK_CNTL,
> > > +	.bit_idx = 24,
> > > +	.lock = &clk_lock,
> > > +	.hw.init = &(struct clk_init_data){
> > > +		.name = "mali_1",
> > > +		.ops = &clk_gate_ops,
> > > +		.parent_names = (const char *[]){ "mali_1_div"
> > > },
> > > +		.num_parents = 1,
> > > +		.flags = (CLK_SET_RATE_PARENT |
> > > CLK_IGNORE_UNUSED),
> > > +	},
> > > +};
> > > +
> > > +static u32 mux_table_mali[] = {0, 1};
> > > +const char *gxbb_mali_parent_names[] = {
> > 
> > static?
> > 
> > > +	"mali_0", "mali_1"
> > > +};
> > 
> > [...]
> > >  static struct clk_mux *gxbb_clk_muxes[] = {
> > >  	&gxbb_mpeg_clk_sel,
> > >  	&gxbb_sar_adc_clk_sel,
> > > +	&gxbb_mali_0_sel,
> > > +	&gxbb_mali_1_sel,
> > > +	&gxbb_mali,
> > >  };
> > >  
> > >  static struct clk_divider *gxbb_clk_dividers[] = {
> > 
> > Can these arrays be const? If so, please do that in a separate
> > patch.
> 
> Hmm, these were introduced by jerome, he should update them
> accordingly.
> 

Will do

> > >  	&gxbb_mpeg_clk_div,
> > >  	&gxbb_sar_adc_clk_div,
> > > +	&gxbb_mali_0_div,
> > > +	&gxbb_mali_1_div,
> > >  };
> 
> 
> Thanks,
> Neil

Re: [PATCH v2 2/3] clk: meson-gxbb: Add MALI clocks

[Jerome Brunet]

T24gVGh1LCAyMDE3LTAzLTAyIGF0IDEyOjA3ICswMTAwLCBOZWlsIEFybXN0cm9uZyB3cm90ZToK
PiBIaSBTdGVwaGVuLAo+IAo+IE9uIDAzLzAxLzIwMTcgMDg6MTEgUE0sIFN0ZXBoZW4gQm95ZCB3
cm90ZToKPiA+IE9uIDAzLzAxLCBOZWlsIEFybXN0cm9uZyB3cm90ZToKPiA+ID4gZGlmZiAtLWdp
dCBhL2RyaXZlcnMvY2xrL21lc29uL2d4YmIuYyBiL2RyaXZlcnMvY2xrL21lc29uL2d4YmIuYwo+
ID4gPiBpbmRleCBhNTIwNjNmLi4zMWY2MDkwIDEwMDY0NAo+ID4gPiAtLS0gYS9kcml2ZXJzL2Ns
ay9tZXNvbi9neGJiLmMKPiA+ID4gKysrIGIvZHJpdmVycy9jbGsvbWVzb24vZ3hiYi5jCj4gPiA+
IEBAIC02MzQsNiArNjM0LDEzMSBAQAo+ID4gPiDCoAl9LAo+ID4gPiDCoH07Cj4gPiA+IMKgCj4g
PiA+ICsvKgo+ID4gPiArICogVGhlIE1BTEkgSVAgaXMgY2xvY2tlZCBieSB0d28gaWRlbnRpY2Fs
IGNsb2NrcyAobWFsaV8wIGFuZAo+ID4gPiBtYWxpXzEpCj4gPiA+ICsgKiBtdXhlZCBieSBhIGds
aXRjaC1mcmVlIHN3aXRjaC4KPiA+ID4gKyAqLwo+ID4gPiArCj4gPiA+ICtzdGF0aWMgdTMyIG11
eF90YWJsZV9tYWxpXzBfMVtdID0gezAsIDEsIDIsIDMsIDQsIDUsIDYsIDd9Owo+ID4gPiArY29u
c3QgY2hhciAqZ3hiYl9tYWxpXzBfMV9wYXJlbnRfbmFtZXNbXSA9IHsKPiA+IAo+ID4gc3RhdGlj
Pwo+IAo+IFdpbGwgZG8gIQo+IAo+ID4gCj4gPiA+ICsJInh0YWwiLCAiZ3AwX3BsbCIsICJtcGxs
MiIsICJtcGxsMSIsICJmY2xrX2RpdjciLAo+ID4gPiArCSJmY2xrX2RpdjQiLCAiZmNsa19kaXYz
IiwgImZjbGtfZGl2NSIKPiA+ID4gK307Cj4gPiA+ICsKPiA+IAo+ID4gWy4uXQo+ID4gPiArCS5y
ZWcgPSAodm9pZCAqKUhISV9NQUxJX0NMS19DTlRMLAo+ID4gPiArCS5iaXRfaWR4ID0gMjQsCj4g
PiA+ICsJLmxvY2sgPSAmY2xrX2xvY2ssCj4gPiA+ICsJLmh3LmluaXQgPSAmKHN0cnVjdCBjbGtf
aW5pdF9kYXRhKXsKPiA+ID4gKwkJLm5hbWUgPSAibWFsaV8xIiwKPiA+ID4gKwkJLm9wcyA9ICZj
bGtfZ2F0ZV9vcHMsCj4gPiA+ICsJCS5wYXJlbnRfbmFtZXMgPSAoY29uc3QgY2hhciAqW10peyAi
bWFsaV8xX2RpdiIKPiA+ID4gfSwKPiA+ID4gKwkJLm51bV9wYXJlbnRzID0gMSwKPiA+ID4gKwkJ
LmZsYWdzID0gKENMS19TRVRfUkFURV9QQVJFTlQgfAo+ID4gPiBDTEtfSUdOT1JFX1VOVVNFRCks
Cj4gPiA+ICsJfSwKPiA+ID4gK307Cj4gPiA+ICsKPiA+ID4gK3N0YXRpYyB1MzIgbXV4X3RhYmxl
X21hbGlbXSA9IHswLCAxfTsKPiA+ID4gK2NvbnN0IGNoYXIgKmd4YmJfbWFsaV9wYXJlbnRfbmFt
ZXNbXSA9IHsKPiA+IAo+ID4gc3RhdGljPwo+ID4gCj4gPiA+ICsJIm1hbGlfMCIsICJtYWxpXzEi
Cj4gPiA+ICt9Owo+ID4gCj4gPiBbLi4uXQo+ID4gPiDCoHN0YXRpYyBzdHJ1Y3QgY2xrX211eCAq
Z3hiYl9jbGtfbXV4ZXNbXSA9IHsKPiA+ID4gwqAJJmd4YmJfbXBlZ19jbGtfc2VsLAo+ID4gPiDC
oAkmZ3hiYl9zYXJfYWRjX2Nsa19zZWwsCj4gPiA+ICsJJmd4YmJfbWFsaV8wX3NlbCwKPiA+ID4g
KwkmZ3hiYl9tYWxpXzFfc2VsLAo+ID4gPiArCSZneGJiX21hbGksCj4gPiA+IMKgfTsKPiA+ID4g
wqAKPiA+ID4gwqBzdGF0aWMgc3RydWN0IGNsa19kaXZpZGVyICpneGJiX2Nsa19kaXZpZGVyc1td
ID0gewo+ID4gCj4gPiBDYW4gdGhlc2UgYXJyYXlzIGJlIGNvbnN0PyBJZiBzbywgcGxlYXNlIGRv
IHRoYXQgaW4gYSBzZXBhcmF0ZQo+ID4gcGF0Y2guCj4gCj4gSG1tLCB0aGVzZSB3ZXJlIGludHJv
ZHVjZWQgYnkgamVyb21lLCBoZSBzaG91bGQgdXBkYXRlIHRoZW0KPiBhY2NvcmRpbmdseS4KPiAK
CldpbGwgZG8KCj4gPiA+IMKgCSZneGJiX21wZWdfY2xrX2RpdiwKPiA+ID4gwqAJJmd4YmJfc2Fy
X2FkY19jbGtfZGl2LAo+ID4gPiArCSZneGJiX21hbGlfMF9kaXYsCj4gPiA+ICsJJmd4YmJfbWFs
aV8xX2RpdiwKPiA+ID4gwqB9Owo+IAo+IAo+IFRoYW5rcywKPiBOZWlsCgpfX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpsaW51eC1hbWxvZ2ljIG1haWxpbmcg
bGlzdApsaW51eC1hbWxvZ2ljQGxpc3RzLmluZnJhZGVhZC5vcmcKaHR0cDovL2xpc3RzLmluZnJh
ZGVhZC5vcmcvbWFpbG1hbi9saXN0aW5mby9saW51eC1hbWxvZ2ljCg==

[PATCH v2 2/3] clk: meson-gxbb: Add MALI clocks

[Jerome Brunet]

On Thu, 2017-03-02 at 12:07 +0100, Neil Armstrong wrote:
> Hi Stephen,
> 
> On 03/01/2017 08:11 PM, Stephen Boyd wrote:
> > On 03/01, Neil Armstrong wrote:
> > > diff --git a/drivers/clk/meson/gxbb.c b/drivers/clk/meson/gxbb.c
> > > index a52063f..31f6090 100644
> > > --- a/drivers/clk/meson/gxbb.c
> > > +++ b/drivers/clk/meson/gxbb.c
> > > @@ -634,6 +634,131 @@
> > > ?	},
> > > ?};
> > > ?
> > > +/*
> > > + * The MALI IP is clocked by two identical clocks (mali_0 and
> > > mali_1)
> > > + * muxed by a glitch-free switch.
> > > + */
> > > +
> > > +static u32 mux_table_mali_0_1[] = {0, 1, 2, 3, 4, 5, 6, 7};
> > > +const char *gxbb_mali_0_1_parent_names[] = {
> > 
> > static?
> 
> Will do !
> 
> > 
> > > +	"xtal", "gp0_pll", "mpll2", "mpll1", "fclk_div7",
> > > +	"fclk_div4", "fclk_div3", "fclk_div5"
> > > +};
> > > +
> > 
> > [..]
> > > +	.reg = (void *)HHI_MALI_CLK_CNTL,
> > > +	.bit_idx = 24,
> > > +	.lock = &clk_lock,
> > > +	.hw.init = &(struct clk_init_data){
> > > +		.name = "mali_1",
> > > +		.ops = &clk_gate_ops,
> > > +		.parent_names = (const char *[]){ "mali_1_div"
> > > },
> > > +		.num_parents = 1,
> > > +		.flags = (CLK_SET_RATE_PARENT |
> > > CLK_IGNORE_UNUSED),
> > > +	},
> > > +};
> > > +
> > > +static u32 mux_table_mali[] = {0, 1};
> > > +const char *gxbb_mali_parent_names[] = {
> > 
> > static?
> > 
> > > +	"mali_0", "mali_1"
> > > +};
> > 
> > [...]
> > > ?static struct clk_mux *gxbb_clk_muxes[] = {
> > > ?	&gxbb_mpeg_clk_sel,
> > > ?	&gxbb_sar_adc_clk_sel,
> > > +	&gxbb_mali_0_sel,
> > > +	&gxbb_mali_1_sel,
> > > +	&gxbb_mali,
> > > ?};
> > > ?
> > > ?static struct clk_divider *gxbb_clk_dividers[] = {
> > 
> > Can these arrays be const? If so, please do that in a separate
> > patch.
> 
> Hmm, these were introduced by jerome, he should update them
> accordingly.
> 

Will do

> > > ?	&gxbb_mpeg_clk_div,
> > > ?	&gxbb_sar_adc_clk_div,
> > > +	&gxbb_mali_0_div,
> > > +	&gxbb_mali_1_div,
> > > ?};
> 
> 
> Thanks,
> Neil

[PATCH v2 2/3] clk: meson-gxbb: Add MALI clocks

[Jerome Brunet]

On Thu, 2017-03-02 at 12:07 +0100, Neil Armstrong wrote:
> Hi Stephen,
> 
> On 03/01/2017 08:11 PM, Stephen Boyd wrote:
> > On 03/01, Neil Armstrong wrote:
> > > diff --git a/drivers/clk/meson/gxbb.c b/drivers/clk/meson/gxbb.c
> > > index a52063f..31f6090 100644
> > > --- a/drivers/clk/meson/gxbb.c
> > > +++ b/drivers/clk/meson/gxbb.c
> > > @@ -634,6 +634,131 @@
> > > ?	},
> > > ?};
> > > ?
> > > +/*
> > > + * The MALI IP is clocked by two identical clocks (mali_0 and
> > > mali_1)
> > > + * muxed by a glitch-free switch.
> > > + */
> > > +
> > > +static u32 mux_table_mali_0_1[] = {0, 1, 2, 3, 4, 5, 6, 7};
> > > +const char *gxbb_mali_0_1_parent_names[] = {
> > 
> > static?
> 
> Will do !
> 
> > 
> > > +	"xtal", "gp0_pll", "mpll2", "mpll1", "fclk_div7",
> > > +	"fclk_div4", "fclk_div3", "fclk_div5"
> > > +};
> > > +
> > 
> > [..]
> > > +	.reg = (void *)HHI_MALI_CLK_CNTL,
> > > +	.bit_idx = 24,
> > > +	.lock = &clk_lock,
> > > +	.hw.init = &(struct clk_init_data){
> > > +		.name = "mali_1",
> > > +		.ops = &clk_gate_ops,
> > > +		.parent_names = (const char *[]){ "mali_1_div"
> > > },
> > > +		.num_parents = 1,
> > > +		.flags = (CLK_SET_RATE_PARENT |
> > > CLK_IGNORE_UNUSED),
> > > +	},
> > > +};
> > > +
> > > +static u32 mux_table_mali[] = {0, 1};
> > > +const char *gxbb_mali_parent_names[] = {
> > 
> > static?
> > 
> > > +	"mali_0", "mali_1"
> > > +};
> > 
> > [...]
> > > ?static struct clk_mux *gxbb_clk_muxes[] = {
> > > ?	&gxbb_mpeg_clk_sel,
> > > ?	&gxbb_sar_adc_clk_sel,
> > > +	&gxbb_mali_0_sel,
> > > +	&gxbb_mali_1_sel,
> > > +	&gxbb_mali,
> > > ?};
> > > ?
> > > ?static struct clk_divider *gxbb_clk_dividers[] = {
> > 
> > Can these arrays be const? If so, please do that in a separate
> > patch.
> 
> Hmm, these were introduced by jerome, he should update them
> accordingly.
> 

Will do

> > > ?	&gxbb_mpeg_clk_div,
> > > ?	&gxbb_sar_adc_clk_div,
> > > +	&gxbb_mali_0_div,
> > > +	&gxbb_mali_1_div,
> > > ?};
> 
> 
> Thanks,
> Neil

Re: [PATCH v2 3/3] ARM64: dts: meson-gx: Add MALI nodes for GXBB and GXL

[Andreas Färber]

Hi Neil,

Am 01.03.2017 um 11:46 schrieb Neil Armstrong:
> The same MALI-450 MP3 GPU is present in the GXBB and GXL SoCs.

First of all, any reason you're upper-casing Mali in the commit message?
ARM doesn't.

> 
> The node is simply added in the meson-gxbb.dtsi file.

The GXBB part looks fine on a quick look.

> 
> For GXL, since a lot is shared with the GXM that has a MALI-T820 IP, this
> patch adds a new meson-gxl-mali.dtsi and is included in the SoC specific
> dtsi files.

This part is slightly confusing though.

What exactly is the GXL vs. GXM difference that this can't be handled by
overriding node properties compatible/interrupts/clocks? I am missing a
GXM patch in this series as rationale for doing it this way.

In particular I am wondering whether the whole GXM-inherits-from-GXL
concept is flawed and should be adjusted if this leads to secondary
.dtsi files like this: My proposal would be to instead create a
meson-gxl-gxm.dtsi, that meson-gxl.dtsi and meson-gxm.dtsi can inherit
the current common parts from, then the Mali bits can simply go into
meson-gxl.dtsi without extra #includes needed in S905X and S905D. While
it's slightly more work to split once again, I think it would be cleaner.

Regards,
Andreas

> 
> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
> ---
>  arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi      | 37 ++++++++++++++++++++
>  arch/arm64/boot/dts/amlogic/meson-gxl-mali.dtsi  | 43 ++++++++++++++++++++++++
>  arch/arm64/boot/dts/amlogic/meson-gxl-s905d.dtsi |  1 +
>  arch/arm64/boot/dts/amlogic/meson-gxl-s905x.dtsi |  1 +
>  4 files changed, 82 insertions(+)
>  create mode 100644 arch/arm64/boot/dts/amlogic/meson-gxl-mali.dtsi
[...]
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl-s905d.dtsi b/arch/arm64/boot/dts/amlogic/meson-gxl-s905d.dtsi
> index 615308e..5a90e30 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gxl-s905d.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/meson-gxl-s905d.dtsi
> @@ -42,6 +42,7 @@
>   */
>  
>  #include "meson-gxl.dtsi"
> +#include "meson-gxl-mali.dtsi"
>  
>  / {
>  	compatible = "amlogic,s905d", "amlogic,meson-gxl";
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl-s905x.dtsi b/arch/arm64/boot/dts/amlogic/meson-gxl-s905x.dtsi
> index 08237ee..0f78d83 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gxl-s905x.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/meson-gxl-s905x.dtsi
> @@ -42,6 +42,7 @@
>   */
>  
>  #include "meson-gxl.dtsi"
> +#include "meson-gxl-mali.dtsi"
>  
>  / {
>  	compatible = "amlogic,s905x", "amlogic,meson-gxl";

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)

Re: [PATCH v2 3/3] ARM64: dts: meson-gx: Add MALI nodes for GXBB and GXL

[Andreas Färber]

Hi Neil,

Am 01.03.2017 um 11:46 schrieb Neil Armstrong:
> The same MALI-450 MP3 GPU is present in the GXBB and GXL SoCs.

First of all, any reason you're upper-casing Mali in the commit message?
ARM doesn't.

> 
> The node is simply added in the meson-gxbb.dtsi file.

The GXBB part looks fine on a quick look.

> 
> For GXL, since a lot is shared with the GXM that has a MALI-T820 IP, this
> patch adds a new meson-gxl-mali.dtsi and is included in the SoC specific
> dtsi files.

This part is slightly confusing though.

What exactly is the GXL vs. GXM difference that this can't be handled by
overriding node properties compatible/interrupts/clocks? I am missing a
GXM patch in this series as rationale for doing it this way.

In particular I am wondering whether the whole GXM-inherits-from-GXL
concept is flawed and should be adjusted if this leads to secondary
.dtsi files like this: My proposal would be to instead create a
meson-gxl-gxm.dtsi, that meson-gxl.dtsi and meson-gxm.dtsi can inherit
the current common parts from, then the Mali bits can simply go into
meson-gxl.dtsi without extra #includes needed in S905X and S905D. While
it's slightly more work to split once again, I think it would be cleaner.

Regards,
Andreas

> 
> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
> ---
>  arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi      | 37 ++++++++++++++++++++
>  arch/arm64/boot/dts/amlogic/meson-gxl-mali.dtsi  | 43 ++++++++++++++++++++++++
>  arch/arm64/boot/dts/amlogic/meson-gxl-s905d.dtsi |  1 +
>  arch/arm64/boot/dts/amlogic/meson-gxl-s905x.dtsi |  1 +
>  4 files changed, 82 insertions(+)
>  create mode 100644 arch/arm64/boot/dts/amlogic/meson-gxl-mali.dtsi
[...]
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl-s905d.dtsi b/arch/arm64/boot/dts/amlogic/meson-gxl-s905d.dtsi
> index 615308e..5a90e30 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gxl-s905d.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/meson-gxl-s905d.dtsi
> @@ -42,6 +42,7 @@
>   */
>  
>  #include "meson-gxl.dtsi"
> +#include "meson-gxl-mali.dtsi"
>  
>  / {
>  	compatible = "amlogic,s905d", "amlogic,meson-gxl";
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl-s905x.dtsi b/arch/arm64/boot/dts/amlogic/meson-gxl-s905x.dtsi
> index 08237ee..0f78d83 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gxl-s905x.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/meson-gxl-s905x.dtsi
> @@ -42,6 +42,7 @@
>   */
>  
>  #include "meson-gxl.dtsi"
> +#include "meson-gxl-mali.dtsi"
>  
>  / {
>  	compatible = "amlogic,s905x", "amlogic,meson-gxl";

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)

Re: [PATCH v2 3/3] ARM64: dts: meson-gx: Add MALI nodes for GXBB and GXL

[Andreas Färber]

Hi Neil,

Am 01.03.2017 um 11:46 schrieb Neil Armstrong:
> The same MALI-450 MP3 GPU is present in the GXBB and GXL SoCs.

First of all, any reason you're upper-casing Mali in the commit message?
ARM doesn't.

> =

> The node is simply added in the meson-gxbb.dtsi file.

The GXBB part looks fine on a quick look.

> =

> For GXL, since a lot is shared with the GXM that has a MALI-T820 IP, this
> patch adds a new meson-gxl-mali.dtsi and is included in the SoC specific
> dtsi files.

This part is slightly confusing though.

What exactly is the GXL vs. GXM difference that this can't be handled by
overriding node properties compatible/interrupts/clocks? I am missing a
GXM patch in this series as rationale for doing it this way.

In particular I am wondering whether the whole GXM-inherits-from-GXL
concept is flawed and should be adjusted if this leads to secondary
.dtsi files like this: My proposal would be to instead create a
meson-gxl-gxm.dtsi, that meson-gxl.dtsi and meson-gxm.dtsi can inherit
the current common parts from, then the Mali bits can simply go into
meson-gxl.dtsi without extra #includes needed in S905X and S905D. While
it's slightly more work to split once again, I think it would be cleaner.

Regards,
Andreas

> =

> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
> ---
>  arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi      | 37 ++++++++++++++++++=
++
>  arch/arm64/boot/dts/amlogic/meson-gxl-mali.dtsi  | 43 ++++++++++++++++++=
++++++
>  arch/arm64/boot/dts/amlogic/meson-gxl-s905d.dtsi |  1 +
>  arch/arm64/boot/dts/amlogic/meson-gxl-s905x.dtsi |  1 +
>  4 files changed, 82 insertions(+)
>  create mode 100644 arch/arm64/boot/dts/amlogic/meson-gxl-mali.dtsi
[...]
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl-s905d.dtsi b/arch/arm6=
4/boot/dts/amlogic/meson-gxl-s905d.dtsi
> index 615308e..5a90e30 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gxl-s905d.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/meson-gxl-s905d.dtsi
> @@ -42,6 +42,7 @@
>   */
>  =

>  #include "meson-gxl.dtsi"
> +#include "meson-gxl-mali.dtsi"
>  =

>  / {
>  	compatible =3D "amlogic,s905d", "amlogic,meson-gxl";
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl-s905x.dtsi b/arch/arm6=
4/boot/dts/amlogic/meson-gxl-s905x.dtsi
> index 08237ee..0f78d83 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gxl-s905x.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/meson-gxl-s905x.dtsi
> @@ -42,6 +42,7 @@
>   */
>  =

>  #include "meson-gxl.dtsi"
> +#include "meson-gxl-mali.dtsi"
>  =

>  / {
>  	compatible =3D "amlogic,s905x", "amlogic,meson-gxl";

-- =

SUSE Linux GmbH, Maxfeldstr. 5, 90409 N=FCrnberg, Germany
GF: Felix Imend=F6rffer, Jane Smithard, Graham Norton
HRB 21284 (AG N=FCrnberg)

_______________________________________________
linux-amlogic mailing list
linux-amlogic@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-amlogic

[PATCH v2 3/3] ARM64: dts: meson-gx: Add MALI nodes for GXBB and GXL

[Andreas Färber]

Hi Neil,

Am 01.03.2017 um 11:46 schrieb Neil Armstrong:
> The same MALI-450 MP3 GPU is present in the GXBB and GXL SoCs.

First of all, any reason you're upper-casing Mali in the commit message?
ARM doesn't.

> 
> The node is simply added in the meson-gxbb.dtsi file.

The GXBB part looks fine on a quick look.

> 
> For GXL, since a lot is shared with the GXM that has a MALI-T820 IP, this
> patch adds a new meson-gxl-mali.dtsi and is included in the SoC specific
> dtsi files.

This part is slightly confusing though.

What exactly is the GXL vs. GXM difference that this can't be handled by
overriding node properties compatible/interrupts/clocks? I am missing a
GXM patch in this series as rationale for doing it this way.

In particular I am wondering whether the whole GXM-inherits-from-GXL
concept is flawed and should be adjusted if this leads to secondary
.dtsi files like this: My proposal would be to instead create a
meson-gxl-gxm.dtsi, that meson-gxl.dtsi and meson-gxm.dtsi can inherit
the current common parts from, then the Mali bits can simply go into
meson-gxl.dtsi without extra #includes needed in S905X and S905D. While
it's slightly more work to split once again, I think it would be cleaner.

Regards,
Andreas

> 
> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
> ---
>  arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi      | 37 ++++++++++++++++++++
>  arch/arm64/boot/dts/amlogic/meson-gxl-mali.dtsi  | 43 ++++++++++++++++++++++++
>  arch/arm64/boot/dts/amlogic/meson-gxl-s905d.dtsi |  1 +
>  arch/arm64/boot/dts/amlogic/meson-gxl-s905x.dtsi |  1 +
>  4 files changed, 82 insertions(+)
>  create mode 100644 arch/arm64/boot/dts/amlogic/meson-gxl-mali.dtsi
[...]
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl-s905d.dtsi b/arch/arm64/boot/dts/amlogic/meson-gxl-s905d.dtsi
> index 615308e..5a90e30 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gxl-s905d.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/meson-gxl-s905d.dtsi
> @@ -42,6 +42,7 @@
>   */
>  
>  #include "meson-gxl.dtsi"
> +#include "meson-gxl-mali.dtsi"
>  
>  / {
>  	compatible = "amlogic,s905d", "amlogic,meson-gxl";
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl-s905x.dtsi b/arch/arm64/boot/dts/amlogic/meson-gxl-s905x.dtsi
> index 08237ee..0f78d83 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gxl-s905x.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/meson-gxl-s905x.dtsi
> @@ -42,6 +42,7 @@
>   */
>  
>  #include "meson-gxl.dtsi"
> +#include "meson-gxl-mali.dtsi"
>  
>  / {
>  	compatible = "amlogic,s905x", "amlogic,meson-gxl";

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany
GF: Felix Imend?rffer, Jane Smithard, Graham Norton
HRB 21284 (AG N?rnberg)

[PATCH v2 3/3] ARM64: dts: meson-gx: Add MALI nodes for GXBB and GXL

[Andreas Färber]

Hi Neil,

Am 01.03.2017 um 11:46 schrieb Neil Armstrong:
> The same MALI-450 MP3 GPU is present in the GXBB and GXL SoCs.

First of all, any reason you're upper-casing Mali in the commit message?
ARM doesn't.

> 
> The node is simply added in the meson-gxbb.dtsi file.

The GXBB part looks fine on a quick look.

> 
> For GXL, since a lot is shared with the GXM that has a MALI-T820 IP, this
> patch adds a new meson-gxl-mali.dtsi and is included in the SoC specific
> dtsi files.

This part is slightly confusing though.

What exactly is the GXL vs. GXM difference that this can't be handled by
overriding node properties compatible/interrupts/clocks? I am missing a
GXM patch in this series as rationale for doing it this way.

In particular I am wondering whether the whole GXM-inherits-from-GXL
concept is flawed and should be adjusted if this leads to secondary
.dtsi files like this: My proposal would be to instead create a
meson-gxl-gxm.dtsi, that meson-gxl.dtsi and meson-gxm.dtsi can inherit
the current common parts from, then the Mali bits can simply go into
meson-gxl.dtsi without extra #includes needed in S905X and S905D. While
it's slightly more work to split once again, I think it would be cleaner.

Regards,
Andreas

> 
> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
> ---
>  arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi      | 37 ++++++++++++++++++++
>  arch/arm64/boot/dts/amlogic/meson-gxl-mali.dtsi  | 43 ++++++++++++++++++++++++
>  arch/arm64/boot/dts/amlogic/meson-gxl-s905d.dtsi |  1 +
>  arch/arm64/boot/dts/amlogic/meson-gxl-s905x.dtsi |  1 +
>  4 files changed, 82 insertions(+)
>  create mode 100644 arch/arm64/boot/dts/amlogic/meson-gxl-mali.dtsi
[...]
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl-s905d.dtsi b/arch/arm64/boot/dts/amlogic/meson-gxl-s905d.dtsi
> index 615308e..5a90e30 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gxl-s905d.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/meson-gxl-s905d.dtsi
> @@ -42,6 +42,7 @@
>   */
>  
>  #include "meson-gxl.dtsi"
> +#include "meson-gxl-mali.dtsi"
>  
>  / {
>  	compatible = "amlogic,s905d", "amlogic,meson-gxl";
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl-s905x.dtsi b/arch/arm64/boot/dts/amlogic/meson-gxl-s905x.dtsi
> index 08237ee..0f78d83 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gxl-s905x.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/meson-gxl-s905x.dtsi
> @@ -42,6 +42,7 @@
>   */
>  
>  #include "meson-gxl.dtsi"
> +#include "meson-gxl-mali.dtsi"
>  
>  / {
>  	compatible = "amlogic,s905x", "amlogic,meson-gxl";

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany
GF: Felix Imend?rffer, Jane Smithard, Graham Norton
HRB 21284 (AG N?rnberg)

Re: [PATCH v2 3/3] ARM64: dts: meson-gx: Add MALI nodes for GXBB and GXL

[Neil Armstrong]

Hi Andreas,
On 03/02/2017 01:31 PM, Andreas Färber wrote:
> Hi Neil,
> 
> Am 01.03.2017 um 11:46 schrieb Neil Armstrong:
>> The same MALI-450 MP3 GPU is present in the GXBB and GXL SoCs.
> 
> First of all, any reason you're upper-casing Mali in the commit message?
> ARM doesn't.

No reason, only a type, indeed it was lower-casing on the v1.
Will fix in v2.

> 
>>
>> The node is simply added in the meson-gxbb.dtsi file.
> 
> The GXBB part looks fine on a quick look.
> 
>>
>> For GXL, since a lot is shared with the GXM that has a MALI-T820 IP, this
>> patch adds a new meson-gxl-mali.dtsi and is included in the SoC specific
>> dtsi files.
> 
> This part is slightly confusing though.
> 
> What exactly is the GXL vs. GXM difference that this can't be handled by
> overriding node properties compatible/interrupts/clocks? I am missing a
> GXM patch in this series as rationale for doing it this way.
> 
> In particular I am wondering whether the whole GXM-inherits-from-GXL
> concept is flawed and should be adjusted if this leads to secondary
> .dtsi files like this: My proposal would be to instead create a
> meson-gxl-gxm.dtsi, that meson-gxl.dtsi and meson-gxm.dtsi can inherit
> the current common parts from, then the Mali bits can simply go into
> meson-gxl.dtsi without extra #includes needed in S905X and S905D. While
> it's slightly more work to split once again, I think it would be cleaner.

The GXL and GXM differences are very small :
 - They share the same clock tree
 - They share the same pinctrl and even the same pinout (S905D and S912 are pin-to-pin compatible)
 - They share all the peripherals

The only changes are :
 - Enhanced video encoding and decoding support, this will need a family-specific compatible when pushed
 - Slightly differences in the Video Processing Unit, this is why I introduced family-specific compatibles
 - A secondary Cortex-A53 cluster
 - A secondary SCPI cpufreq clock entry
 - A different Mali core, but with the same interrupts (less but they share the same lower interrupts), clocks and memory space

This is why it was decided to have a sub-dtsi, having a secondary dtsi will simply copy 99% of the GXL dtsi,
but surely we could also have an intermediate dtsi but for boards I'm ok with it, but less for a SoC dtsi,
since it could lead to some confusion.

Finally, yes I could have added the mali node to the GXL dtsi, but the midgard Mali dt-bindings are not upstream
and the family is too big and recent enough to consider having stable bindings for now.

Nevertheless, nothing is final, this gxl-mali.dtsi could be merged into the GXL dtsi in the future when we
have proper dt-bindings and a real support of the T820 Mali on the S912.

Kevin, what's your thought about this ?

Neil

> Regards,
> Andreas
> 
>>
>> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
>> ---
>>  arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi      | 37 ++++++++++++++++++++
>>  arch/arm64/boot/dts/amlogic/meson-gxl-mali.dtsi  | 43 ++++++++++++++++++++++++
>>  arch/arm64/boot/dts/amlogic/meson-gxl-s905d.dtsi |  1 +
>>  arch/arm64/boot/dts/amlogic/meson-gxl-s905x.dtsi |  1 +
>>  4 files changed, 82 insertions(+)
>>  create mode 100644 arch/arm64/boot/dts/amlogic/meson-gxl-mali.dtsi
> [...]
>> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl-s905d.dtsi b/arch/arm64/boot/dts/amlogic/meson-gxl-s905d.dtsi
>> index 615308e..5a90e30 100644
>> --- a/arch/arm64/boot/dts/amlogic/meson-gxl-s905d.dtsi
>> +++ b/arch/arm64/boot/dts/amlogic/meson-gxl-s905d.dtsi
>> @@ -42,6 +42,7 @@
>>   */
>>  
>>  #include "meson-gxl.dtsi"
>> +#include "meson-gxl-mali.dtsi"
>>  
>>  / {
>>  	compatible = "amlogic,s905d", "amlogic,meson-gxl";
>> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl-s905x.dtsi b/arch/arm64/boot/dts/amlogic/meson-gxl-s905x.dtsi
>> index 08237ee..0f78d83 100644
>> --- a/arch/arm64/boot/dts/amlogic/meson-gxl-s905x.dtsi
>> +++ b/arch/arm64/boot/dts/amlogic/meson-gxl-s905x.dtsi
>> @@ -42,6 +42,7 @@
>>   */
>>  
>>  #include "meson-gxl.dtsi"
>> +#include "meson-gxl-mali.dtsi"
>>  
>>  / {
>>  	compatible = "amlogic,s905x", "amlogic,meson-gxl";
> 

Re: [PATCH v2 3/3] ARM64: dts: meson-gx: Add MALI nodes for GXBB and GXL

[Neil Armstrong]

Hi Andreas,
On 03/02/2017 01:31 PM, Andreas Färber wrote:
> Hi Neil,
> 
> Am 01.03.2017 um 11:46 schrieb Neil Armstrong:
>> The same MALI-450 MP3 GPU is present in the GXBB and GXL SoCs.
> 
> First of all, any reason you're upper-casing Mali in the commit message?
> ARM doesn't.

No reason, only a type, indeed it was lower-casing on the v1.
Will fix in v2.

> 
>>
>> The node is simply added in the meson-gxbb.dtsi file.
> 
> The GXBB part looks fine on a quick look.
> 
>>
>> For GXL, since a lot is shared with the GXM that has a MALI-T820 IP, this
>> patch adds a new meson-gxl-mali.dtsi and is included in the SoC specific
>> dtsi files.
> 
> This part is slightly confusing though.
> 
> What exactly is the GXL vs. GXM difference that this can't be handled by
> overriding node properties compatible/interrupts/clocks? I am missing a
> GXM patch in this series as rationale for doing it this way.
> 
> In particular I am wondering whether the whole GXM-inherits-from-GXL
> concept is flawed and should be adjusted if this leads to secondary
> .dtsi files like this: My proposal would be to instead create a
> meson-gxl-gxm.dtsi, that meson-gxl.dtsi and meson-gxm.dtsi can inherit
> the current common parts from, then the Mali bits can simply go into
> meson-gxl.dtsi without extra #includes needed in S905X and S905D. While
> it's slightly more work to split once again, I think it would be cleaner.

The GXL and GXM differences are very small :
 - They share the same clock tree
 - They share the same pinctrl and even the same pinout (S905D and S912 are pin-to-pin compatible)
 - They share all the peripherals

The only changes are :
 - Enhanced video encoding and decoding support, this will need a family-specific compatible when pushed
 - Slightly differences in the Video Processing Unit, this is why I introduced family-specific compatibles
 - A secondary Cortex-A53 cluster
 - A secondary SCPI cpufreq clock entry
 - A different Mali core, but with the same interrupts (less but they share the same lower interrupts), clocks and memory space

This is why it was decided to have a sub-dtsi, having a secondary dtsi will simply copy 99% of the GXL dtsi,
but surely we could also have an intermediate dtsi but for boards I'm ok with it, but less for a SoC dtsi,
since it could lead to some confusion.

Finally, yes I could have added the mali node to the GXL dtsi, but the midgard Mali dt-bindings are not upstream
and the family is too big and recent enough to consider having stable bindings for now.

Nevertheless, nothing is final, this gxl-mali.dtsi could be merged into the GXL dtsi in the future when we
have proper dt-bindings and a real support of the T820 Mali on the S912.

Kevin, what's your thought about this ?

Neil

> Regards,
> Andreas
> 
>>
>> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
>> ---
>>  arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi      | 37 ++++++++++++++++++++
>>  arch/arm64/boot/dts/amlogic/meson-gxl-mali.dtsi  | 43 ++++++++++++++++++++++++
>>  arch/arm64/boot/dts/amlogic/meson-gxl-s905d.dtsi |  1 +
>>  arch/arm64/boot/dts/amlogic/meson-gxl-s905x.dtsi |  1 +
>>  4 files changed, 82 insertions(+)
>>  create mode 100644 arch/arm64/boot/dts/amlogic/meson-gxl-mali.dtsi
> [...]
>> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl-s905d.dtsi b/arch/arm64/boot/dts/amlogic/meson-gxl-s905d.dtsi
>> index 615308e..5a90e30 100644
>> --- a/arch/arm64/boot/dts/amlogic/meson-gxl-s905d.dtsi
>> +++ b/arch/arm64/boot/dts/amlogic/meson-gxl-s905d.dtsi
>> @@ -42,6 +42,7 @@
>>   */
>>  
>>  #include "meson-gxl.dtsi"
>> +#include "meson-gxl-mali.dtsi"
>>  
>>  / {
>>  	compatible = "amlogic,s905d", "amlogic,meson-gxl";
>> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl-s905x.dtsi b/arch/arm64/boot/dts/amlogic/meson-gxl-s905x.dtsi
>> index 08237ee..0f78d83 100644
>> --- a/arch/arm64/boot/dts/amlogic/meson-gxl-s905x.dtsi
>> +++ b/arch/arm64/boot/dts/amlogic/meson-gxl-s905x.dtsi
>> @@ -42,6 +42,7 @@
>>   */
>>  
>>  #include "meson-gxl.dtsi"
>> +#include "meson-gxl-mali.dtsi"
>>  
>>  / {
>>  	compatible = "amlogic,s905x", "amlogic,meson-gxl";
> 

Re: [PATCH v2 3/3] ARM64: dts: meson-gx: Add MALI nodes for GXBB and GXL

[Neil Armstrong]

Hi Andreas,
On 03/02/2017 01:31 PM, Andreas F=E4rber wrote:
> Hi Neil,
> =

> Am 01.03.2017 um 11:46 schrieb Neil Armstrong:
>> The same MALI-450 MP3 GPU is present in the GXBB and GXL SoCs.
> =

> First of all, any reason you're upper-casing Mali in the commit message?
> ARM doesn't.

No reason, only a type, indeed it was lower-casing on the v1.
Will fix in v2.

> =

>>
>> The node is simply added in the meson-gxbb.dtsi file.
> =

> The GXBB part looks fine on a quick look.
> =

>>
>> For GXL, since a lot is shared with the GXM that has a MALI-T820 IP, this
>> patch adds a new meson-gxl-mali.dtsi and is included in the SoC specific
>> dtsi files.
> =

> This part is slightly confusing though.
> =

> What exactly is the GXL vs. GXM difference that this can't be handled by
> overriding node properties compatible/interrupts/clocks? I am missing a
> GXM patch in this series as rationale for doing it this way.
> =

> In particular I am wondering whether the whole GXM-inherits-from-GXL
> concept is flawed and should be adjusted if this leads to secondary
> .dtsi files like this: My proposal would be to instead create a
> meson-gxl-gxm.dtsi, that meson-gxl.dtsi and meson-gxm.dtsi can inherit
> the current common parts from, then the Mali bits can simply go into
> meson-gxl.dtsi without extra #includes needed in S905X and S905D. While
> it's slightly more work to split once again, I think it would be cleaner.

The GXL and GXM differences are very small :
 - They share the same clock tree
 - They share the same pinctrl and even the same pinout (S905D and S912 are=
 pin-to-pin compatible)
 - They share all the peripherals

The only changes are :
 - Enhanced video encoding and decoding support, this will need a family-sp=
ecific compatible when pushed
 - Slightly differences in the Video Processing Unit, this is why I introdu=
ced family-specific compatibles
 - A secondary Cortex-A53 cluster
 - A secondary SCPI cpufreq clock entry
 - A different Mali core, but with the same interrupts (less but they share=
 the same lower interrupts), clocks and memory space

This is why it was decided to have a sub-dtsi, having a secondary dtsi will=
 simply copy 99% of the GXL dtsi,
but surely we could also have an intermediate dtsi but for boards I'm ok wi=
th it, but less for a SoC dtsi,
since it could lead to some confusion.

Finally, yes I could have added the mali node to the GXL dtsi, but the midg=
ard Mali dt-bindings are not upstream
and the family is too big and recent enough to consider having stable bindi=
ngs for now.

Nevertheless, nothing is final, this gxl-mali.dtsi could be merged into the=
 GXL dtsi in the future when we
have proper dt-bindings and a real support of the T820 Mali on the S912.

Kevin, what's your thought about this ?

Neil

> Regards,
> Andreas
> =

>>
>> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
>> ---
>>  arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi      | 37 +++++++++++++++++=
+++
>>  arch/arm64/boot/dts/amlogic/meson-gxl-mali.dtsi  | 43 +++++++++++++++++=
+++++++
>>  arch/arm64/boot/dts/amlogic/meson-gxl-s905d.dtsi |  1 +
>>  arch/arm64/boot/dts/amlogic/meson-gxl-s905x.dtsi |  1 +
>>  4 files changed, 82 insertions(+)
>>  create mode 100644 arch/arm64/boot/dts/amlogic/meson-gxl-mali.dtsi
> [...]
>> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl-s905d.dtsi b/arch/arm=
64/boot/dts/amlogic/meson-gxl-s905d.dtsi
>> index 615308e..5a90e30 100644
>> --- a/arch/arm64/boot/dts/amlogic/meson-gxl-s905d.dtsi
>> +++ b/arch/arm64/boot/dts/amlogic/meson-gxl-s905d.dtsi
>> @@ -42,6 +42,7 @@
>>   */
>>  =

>>  #include "meson-gxl.dtsi"
>> +#include "meson-gxl-mali.dtsi"
>>  =

>>  / {
>>  	compatible =3D "amlogic,s905d", "amlogic,meson-gxl";
>> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl-s905x.dtsi b/arch/arm=
64/boot/dts/amlogic/meson-gxl-s905x.dtsi
>> index 08237ee..0f78d83 100644
>> --- a/arch/arm64/boot/dts/amlogic/meson-gxl-s905x.dtsi
>> +++ b/arch/arm64/boot/dts/amlogic/meson-gxl-s905x.dtsi
>> @@ -42,6 +42,7 @@
>>   */
>>  =

>>  #include "meson-gxl.dtsi"
>> +#include "meson-gxl-mali.dtsi"
>>  =

>>  / {
>>  	compatible =3D "amlogic,s905x", "amlogic,meson-gxl";
> =



_______________________________________________
linux-amlogic mailing list
linux-amlogic@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-amlogic

[PATCH v2 3/3] ARM64: dts: meson-gx: Add MALI nodes for GXBB and GXL

[Neil Armstrong]

Hi Andreas,
On 03/02/2017 01:31 PM, Andreas F?rber wrote:
> Hi Neil,
> 
> Am 01.03.2017 um 11:46 schrieb Neil Armstrong:
>> The same MALI-450 MP3 GPU is present in the GXBB and GXL SoCs.
> 
> First of all, any reason you're upper-casing Mali in the commit message?
> ARM doesn't.

No reason, only a type, indeed it was lower-casing on the v1.
Will fix in v2.

> 
>>
>> The node is simply added in the meson-gxbb.dtsi file.
> 
> The GXBB part looks fine on a quick look.
> 
>>
>> For GXL, since a lot is shared with the GXM that has a MALI-T820 IP, this
>> patch adds a new meson-gxl-mali.dtsi and is included in the SoC specific
>> dtsi files.
> 
> This part is slightly confusing though.
> 
> What exactly is the GXL vs. GXM difference that this can't be handled by
> overriding node properties compatible/interrupts/clocks? I am missing a
> GXM patch in this series as rationale for doing it this way.
> 
> In particular I am wondering whether the whole GXM-inherits-from-GXL
> concept is flawed and should be adjusted if this leads to secondary
> .dtsi files like this: My proposal would be to instead create a
> meson-gxl-gxm.dtsi, that meson-gxl.dtsi and meson-gxm.dtsi can inherit
> the current common parts from, then the Mali bits can simply go into
> meson-gxl.dtsi without extra #includes needed in S905X and S905D. While
> it's slightly more work to split once again, I think it would be cleaner.

The GXL and GXM differences are very small :
 - They share the same clock tree
 - They share the same pinctrl and even the same pinout (S905D and S912 are pin-to-pin compatible)
 - They share all the peripherals

The only changes are :
 - Enhanced video encoding and decoding support, this will need a family-specific compatible when pushed
 - Slightly differences in the Video Processing Unit, this is why I introduced family-specific compatibles
 - A secondary Cortex-A53 cluster
 - A secondary SCPI cpufreq clock entry
 - A different Mali core, but with the same interrupts (less but they share the same lower interrupts), clocks and memory space

This is why it was decided to have a sub-dtsi, having a secondary dtsi will simply copy 99% of the GXL dtsi,
but surely we could also have an intermediate dtsi but for boards I'm ok with it, but less for a SoC dtsi,
since it could lead to some confusion.

Finally, yes I could have added the mali node to the GXL dtsi, but the midgard Mali dt-bindings are not upstream
and the family is too big and recent enough to consider having stable bindings for now.

Nevertheless, nothing is final, this gxl-mali.dtsi could be merged into the GXL dtsi in the future when we
have proper dt-bindings and a real support of the T820 Mali on the S912.

Kevin, what's your thought about this ?

Neil

> Regards,
> Andreas
> 
>>
>> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
>> ---
>>  arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi      | 37 ++++++++++++++++++++
>>  arch/arm64/boot/dts/amlogic/meson-gxl-mali.dtsi  | 43 ++++++++++++++++++++++++
>>  arch/arm64/boot/dts/amlogic/meson-gxl-s905d.dtsi |  1 +
>>  arch/arm64/boot/dts/amlogic/meson-gxl-s905x.dtsi |  1 +
>>  4 files changed, 82 insertions(+)
>>  create mode 100644 arch/arm64/boot/dts/amlogic/meson-gxl-mali.dtsi
> [...]
>> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl-s905d.dtsi b/arch/arm64/boot/dts/amlogic/meson-gxl-s905d.dtsi
>> index 615308e..5a90e30 100644
>> --- a/arch/arm64/boot/dts/amlogic/meson-gxl-s905d.dtsi
>> +++ b/arch/arm64/boot/dts/amlogic/meson-gxl-s905d.dtsi
>> @@ -42,6 +42,7 @@
>>   */
>>  
>>  #include "meson-gxl.dtsi"
>> +#include "meson-gxl-mali.dtsi"
>>  
>>  / {
>>  	compatible = "amlogic,s905d", "amlogic,meson-gxl";
>> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl-s905x.dtsi b/arch/arm64/boot/dts/amlogic/meson-gxl-s905x.dtsi
>> index 08237ee..0f78d83 100644
>> --- a/arch/arm64/boot/dts/amlogic/meson-gxl-s905x.dtsi
>> +++ b/arch/arm64/boot/dts/amlogic/meson-gxl-s905x.dtsi
>> @@ -42,6 +42,7 @@
>>   */
>>  
>>  #include "meson-gxl.dtsi"
>> +#include "meson-gxl-mali.dtsi"
>>  
>>  / {
>>  	compatible = "amlogic,s905x", "amlogic,meson-gxl";
> 

[PATCH v2 3/3] ARM64: dts: meson-gx: Add MALI nodes for GXBB and GXL

[Neil Armstrong]

Hi Andreas,
On 03/02/2017 01:31 PM, Andreas F?rber wrote:
> Hi Neil,
> 
> Am 01.03.2017 um 11:46 schrieb Neil Armstrong:
>> The same MALI-450 MP3 GPU is present in the GXBB and GXL SoCs.
> 
> First of all, any reason you're upper-casing Mali in the commit message?
> ARM doesn't.

No reason, only a type, indeed it was lower-casing on the v1.
Will fix in v2.

> 
>>
>> The node is simply added in the meson-gxbb.dtsi file.
> 
> The GXBB part looks fine on a quick look.
> 
>>
>> For GXL, since a lot is shared with the GXM that has a MALI-T820 IP, this
>> patch adds a new meson-gxl-mali.dtsi and is included in the SoC specific
>> dtsi files.
> 
> This part is slightly confusing though.
> 
> What exactly is the GXL vs. GXM difference that this can't be handled by
> overriding node properties compatible/interrupts/clocks? I am missing a
> GXM patch in this series as rationale for doing it this way.
> 
> In particular I am wondering whether the whole GXM-inherits-from-GXL
> concept is flawed and should be adjusted if this leads to secondary
> .dtsi files like this: My proposal would be to instead create a
> meson-gxl-gxm.dtsi, that meson-gxl.dtsi and meson-gxm.dtsi can inherit
> the current common parts from, then the Mali bits can simply go into
> meson-gxl.dtsi without extra #includes needed in S905X and S905D. While
> it's slightly more work to split once again, I think it would be cleaner.

The GXL and GXM differences are very small :
 - They share the same clock tree
 - They share the same pinctrl and even the same pinout (S905D and S912 are pin-to-pin compatible)
 - They share all the peripherals

The only changes are :
 - Enhanced video encoding and decoding support, this will need a family-specific compatible when pushed
 - Slightly differences in the Video Processing Unit, this is why I introduced family-specific compatibles
 - A secondary Cortex-A53 cluster
 - A secondary SCPI cpufreq clock entry
 - A different Mali core, but with the same interrupts (less but they share the same lower interrupts), clocks and memory space

This is why it was decided to have a sub-dtsi, having a secondary dtsi will simply copy 99% of the GXL dtsi,
but surely we could also have an intermediate dtsi but for boards I'm ok with it, but less for a SoC dtsi,
since it could lead to some confusion.

Finally, yes I could have added the mali node to the GXL dtsi, but the midgard Mali dt-bindings are not upstream
and the family is too big and recent enough to consider having stable bindings for now.

Nevertheless, nothing is final, this gxl-mali.dtsi could be merged into the GXL dtsi in the future when we
have proper dt-bindings and a real support of the T820 Mali on the S912.

Kevin, what's your thought about this ?

Neil

> Regards,
> Andreas
> 
>>
>> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
>> ---
>>  arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi      | 37 ++++++++++++++++++++
>>  arch/arm64/boot/dts/amlogic/meson-gxl-mali.dtsi  | 43 ++++++++++++++++++++++++
>>  arch/arm64/boot/dts/amlogic/meson-gxl-s905d.dtsi |  1 +
>>  arch/arm64/boot/dts/amlogic/meson-gxl-s905x.dtsi |  1 +
>>  4 files changed, 82 insertions(+)
>>  create mode 100644 arch/arm64/boot/dts/amlogic/meson-gxl-mali.dtsi
> [...]
>> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl-s905d.dtsi b/arch/arm64/boot/dts/amlogic/meson-gxl-s905d.dtsi
>> index 615308e..5a90e30 100644
>> --- a/arch/arm64/boot/dts/amlogic/meson-gxl-s905d.dtsi
>> +++ b/arch/arm64/boot/dts/amlogic/meson-gxl-s905d.dtsi
>> @@ -42,6 +42,7 @@
>>   */
>>  
>>  #include "meson-gxl.dtsi"
>> +#include "meson-gxl-mali.dtsi"
>>  
>>  / {
>>  	compatible = "amlogic,s905d", "amlogic,meson-gxl";
>> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl-s905x.dtsi b/arch/arm64/boot/dts/amlogic/meson-gxl-s905x.dtsi
>> index 08237ee..0f78d83 100644
>> --- a/arch/arm64/boot/dts/amlogic/meson-gxl-s905x.dtsi
>> +++ b/arch/arm64/boot/dts/amlogic/meson-gxl-s905x.dtsi
>> @@ -42,6 +42,7 @@
>>   */
>>  
>>  #include "meson-gxl.dtsi"
>> +#include "meson-gxl-mali.dtsi"
>>  
>>  / {
>>  	compatible = "amlogic,s905x", "amlogic,meson-gxl";
> 

Re: [PATCH v2 3/3] ARM64: dts: meson-gx: Add MALI nodes for GXBB and GXL

[Andreas Färber]

Hi,

Am 02.03.2017 um 13:47 schrieb Neil Armstrong:
> On 03/02/2017 01:31 PM, Andreas Färber wrote:
>> Am 01.03.2017 um 11:46 schrieb Neil Armstrong:
>>> For GXL, since a lot is shared with the GXM that has a MALI-T820 IP, this
>>> patch adds a new meson-gxl-mali.dtsi and is included in the SoC specific
>>> dtsi files.
>>
>> This part is slightly confusing though.
>>
>> What exactly is the GXL vs. GXM difference that this can't be handled by
>> overriding node properties compatible/interrupts/clocks? I am missing a
>> GXM patch in this series as rationale for doing it this way.
>>
>> In particular I am wondering whether the whole GXM-inherits-from-GXL
>> concept is flawed and should be adjusted if this leads to secondary
>> .dtsi files like this: My proposal would be to instead create a
>> meson-gxl-gxm.dtsi, that meson-gxl.dtsi and meson-gxm.dtsi can inherit
>> the current common parts from, then the Mali bits can simply go into
>> meson-gxl.dtsi without extra #includes needed in S905X and S905D. While
>> it's slightly more work to split once again, I think it would be cleaner.
> 
> The GXL and GXM differences are very small :
>  - They share the same clock tree
>  - They share the same pinctrl and even the same pinout (S905D and S912 are pin-to-pin compatible)
>  - They share all the peripherals
> 
> The only changes are :
>  - Enhanced video encoding and decoding support, this will need a family-specific compatible when pushed
>  - Slightly differences in the Video Processing Unit, this is why I introduced family-specific compatibles
>  - A secondary Cortex-A53 cluster
>  - A secondary SCPI cpufreq clock entry
>  - A different Mali core, but with the same interrupts (less but they share the same lower interrupts), clocks and memory space
> 
> This is why it was decided to have a sub-dtsi, having a secondary dtsi will simply copy 99% of the GXL dtsi,
> but surely we could also have an intermediate dtsi but for boards I'm ok with it, but less for a SoC dtsi,
> since it could lead to some confusion.
> 
> Finally, yes I could have added the mali node to the GXL dtsi, but the midgard Mali dt-bindings are not upstream
> and the family is too big and recent enough to consider having stable bindings for now.

OK, my question really was specific to Mali differences. :)

> Nevertheless, nothing is final, this gxl-mali.dtsi could be merged into the GXL dtsi in the future when we
> have proper dt-bindings and a real support of the T820 Mali on the S912.

What about a /delete-node/ &mali; in meson-gxm.dtsi?
That would avoid having any new .dtsi.

Regards,
Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)

Re: [PATCH v2 3/3] ARM64: dts: meson-gx: Add MALI nodes for GXBB and GXL

[Andreas Färber]

Hi,

Am 02.03.2017 um 13:47 schrieb Neil Armstrong:
> On 03/02/2017 01:31 PM, Andreas Färber wrote:
>> Am 01.03.2017 um 11:46 schrieb Neil Armstrong:
>>> For GXL, since a lot is shared with the GXM that has a MALI-T820 IP, this
>>> patch adds a new meson-gxl-mali.dtsi and is included in the SoC specific
>>> dtsi files.
>>
>> This part is slightly confusing though.
>>
>> What exactly is the GXL vs. GXM difference that this can't be handled by
>> overriding node properties compatible/interrupts/clocks? I am missing a
>> GXM patch in this series as rationale for doing it this way.
>>
>> In particular I am wondering whether the whole GXM-inherits-from-GXL
>> concept is flawed and should be adjusted if this leads to secondary
>> .dtsi files like this: My proposal would be to instead create a
>> meson-gxl-gxm.dtsi, that meson-gxl.dtsi and meson-gxm.dtsi can inherit
>> the current common parts from, then the Mali bits can simply go into
>> meson-gxl.dtsi without extra #includes needed in S905X and S905D. While
>> it's slightly more work to split once again, I think it would be cleaner.
> 
> The GXL and GXM differences are very small :
>  - They share the same clock tree
>  - They share the same pinctrl and even the same pinout (S905D and S912 are pin-to-pin compatible)
>  - They share all the peripherals
> 
> The only changes are :
>  - Enhanced video encoding and decoding support, this will need a family-specific compatible when pushed
>  - Slightly differences in the Video Processing Unit, this is why I introduced family-specific compatibles
>  - A secondary Cortex-A53 cluster
>  - A secondary SCPI cpufreq clock entry
>  - A different Mali core, but with the same interrupts (less but they share the same lower interrupts), clocks and memory space
> 
> This is why it was decided to have a sub-dtsi, having a secondary dtsi will simply copy 99% of the GXL dtsi,
> but surely we could also have an intermediate dtsi but for boards I'm ok with it, but less for a SoC dtsi,
> since it could lead to some confusion.
> 
> Finally, yes I could have added the mali node to the GXL dtsi, but the midgard Mali dt-bindings are not upstream
> and the family is too big and recent enough to consider having stable bindings for now.

OK, my question really was specific to Mali differences. :)

> Nevertheless, nothing is final, this gxl-mali.dtsi could be merged into the GXL dtsi in the future when we
> have proper dt-bindings and a real support of the T820 Mali on the S912.

What about a /delete-node/ &mali; in meson-gxm.dtsi?
That would avoid having any new .dtsi.

Regards,
Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)

Re: [PATCH v2 3/3] ARM64: dts: meson-gx: Add MALI nodes for GXBB and GXL

[Andreas Färber]

Hi,

Am 02.03.2017 um 13:47 schrieb Neil Armstrong:
> On 03/02/2017 01:31 PM, Andreas F=E4rber wrote:
>> Am 01.03.2017 um 11:46 schrieb Neil Armstrong:
>>> For GXL, since a lot is shared with the GXM that has a MALI-T820 IP, th=
is
>>> patch adds a new meson-gxl-mali.dtsi and is included in the SoC specific
>>> dtsi files.
>>
>> This part is slightly confusing though.
>>
>> What exactly is the GXL vs. GXM difference that this can't be handled by
>> overriding node properties compatible/interrupts/clocks? I am missing a
>> GXM patch in this series as rationale for doing it this way.
>>
>> In particular I am wondering whether the whole GXM-inherits-from-GXL
>> concept is flawed and should be adjusted if this leads to secondary
>> .dtsi files like this: My proposal would be to instead create a
>> meson-gxl-gxm.dtsi, that meson-gxl.dtsi and meson-gxm.dtsi can inherit
>> the current common parts from, then the Mali bits can simply go into
>> meson-gxl.dtsi without extra #includes needed in S905X and S905D. While
>> it's slightly more work to split once again, I think it would be cleaner.
> =

> The GXL and GXM differences are very small :
>  - They share the same clock tree
>  - They share the same pinctrl and even the same pinout (S905D and S912 a=
re pin-to-pin compatible)
>  - They share all the peripherals
> =

> The only changes are :
>  - Enhanced video encoding and decoding support, this will need a family-=
specific compatible when pushed
>  - Slightly differences in the Video Processing Unit, this is why I intro=
duced family-specific compatibles
>  - A secondary Cortex-A53 cluster
>  - A secondary SCPI cpufreq clock entry
>  - A different Mali core, but with the same interrupts (less but they sha=
re the same lower interrupts), clocks and memory space
> =

> This is why it was decided to have a sub-dtsi, having a secondary dtsi wi=
ll simply copy 99% of the GXL dtsi,
> but surely we could also have an intermediate dtsi but for boards I'm ok =
with it, but less for a SoC dtsi,
> since it could lead to some confusion.
> =

> Finally, yes I could have added the mali node to the GXL dtsi, but the mi=
dgard Mali dt-bindings are not upstream
> and the family is too big and recent enough to consider having stable bin=
dings for now.

OK, my question really was specific to Mali differences. :)

> Nevertheless, nothing is final, this gxl-mali.dtsi could be merged into t=
he GXL dtsi in the future when we
> have proper dt-bindings and a real support of the T820 Mali on the S912.

What about a /delete-node/ &mali; in meson-gxm.dtsi?
That would avoid having any new .dtsi.

Regards,
Andreas

-- =

SUSE Linux GmbH, Maxfeldstr. 5, 90409 N=FCrnberg, Germany
GF: Felix Imend=F6rffer, Jane Smithard, Graham Norton
HRB 21284 (AG N=FCrnberg)

_______________________________________________
linux-amlogic mailing list
linux-amlogic@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-amlogic

[PATCH v2 3/3] ARM64: dts: meson-gx: Add MALI nodes for GXBB and GXL

[Andreas Färber]

Hi,

Am 02.03.2017 um 13:47 schrieb Neil Armstrong:
> On 03/02/2017 01:31 PM, Andreas F?rber wrote:
>> Am 01.03.2017 um 11:46 schrieb Neil Armstrong:
>>> For GXL, since a lot is shared with the GXM that has a MALI-T820 IP, this
>>> patch adds a new meson-gxl-mali.dtsi and is included in the SoC specific
>>> dtsi files.
>>
>> This part is slightly confusing though.
>>
>> What exactly is the GXL vs. GXM difference that this can't be handled by
>> overriding node properties compatible/interrupts/clocks? I am missing a
>> GXM patch in this series as rationale for doing it this way.
>>
>> In particular I am wondering whether the whole GXM-inherits-from-GXL
>> concept is flawed and should be adjusted if this leads to secondary
>> .dtsi files like this: My proposal would be to instead create a
>> meson-gxl-gxm.dtsi, that meson-gxl.dtsi and meson-gxm.dtsi can inherit
>> the current common parts from, then the Mali bits can simply go into
>> meson-gxl.dtsi without extra #includes needed in S905X and S905D. While
>> it's slightly more work to split once again, I think it would be cleaner.
> 
> The GXL and GXM differences are very small :
>  - They share the same clock tree
>  - They share the same pinctrl and even the same pinout (S905D and S912 are pin-to-pin compatible)
>  - They share all the peripherals
> 
> The only changes are :
>  - Enhanced video encoding and decoding support, this will need a family-specific compatible when pushed
>  - Slightly differences in the Video Processing Unit, this is why I introduced family-specific compatibles
>  - A secondary Cortex-A53 cluster
>  - A secondary SCPI cpufreq clock entry
>  - A different Mali core, but with the same interrupts (less but they share the same lower interrupts), clocks and memory space
> 
> This is why it was decided to have a sub-dtsi, having a secondary dtsi will simply copy 99% of the GXL dtsi,
> but surely we could also have an intermediate dtsi but for boards I'm ok with it, but less for a SoC dtsi,
> since it could lead to some confusion.
> 
> Finally, yes I could have added the mali node to the GXL dtsi, but the midgard Mali dt-bindings are not upstream
> and the family is too big and recent enough to consider having stable bindings for now.

OK, my question really was specific to Mali differences. :)

> Nevertheless, nothing is final, this gxl-mali.dtsi could be merged into the GXL dtsi in the future when we
> have proper dt-bindings and a real support of the T820 Mali on the S912.

What about a /delete-node/ &mali; in meson-gxm.dtsi?
That would avoid having any new .dtsi.

Regards,
Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany
GF: Felix Imend?rffer, Jane Smithard, Graham Norton
HRB 21284 (AG N?rnberg)

[PATCH v2 3/3] ARM64: dts: meson-gx: Add MALI nodes for GXBB and GXL

[Andreas Färber]

Hi,

Am 02.03.2017 um 13:47 schrieb Neil Armstrong:
> On 03/02/2017 01:31 PM, Andreas F?rber wrote:
>> Am 01.03.2017 um 11:46 schrieb Neil Armstrong:
>>> For GXL, since a lot is shared with the GXM that has a MALI-T820 IP, this
>>> patch adds a new meson-gxl-mali.dtsi and is included in the SoC specific
>>> dtsi files.
>>
>> This part is slightly confusing though.
>>
>> What exactly is the GXL vs. GXM difference that this can't be handled by
>> overriding node properties compatible/interrupts/clocks? I am missing a
>> GXM patch in this series as rationale for doing it this way.
>>
>> In particular I am wondering whether the whole GXM-inherits-from-GXL
>> concept is flawed and should be adjusted if this leads to secondary
>> .dtsi files like this: My proposal would be to instead create a
>> meson-gxl-gxm.dtsi, that meson-gxl.dtsi and meson-gxm.dtsi can inherit
>> the current common parts from, then the Mali bits can simply go into
>> meson-gxl.dtsi without extra #includes needed in S905X and S905D. While
>> it's slightly more work to split once again, I think it would be cleaner.
> 
> The GXL and GXM differences are very small :
>  - They share the same clock tree
>  - They share the same pinctrl and even the same pinout (S905D and S912 are pin-to-pin compatible)
>  - They share all the peripherals
> 
> The only changes are :
>  - Enhanced video encoding and decoding support, this will need a family-specific compatible when pushed
>  - Slightly differences in the Video Processing Unit, this is why I introduced family-specific compatibles
>  - A secondary Cortex-A53 cluster
>  - A secondary SCPI cpufreq clock entry
>  - A different Mali core, but with the same interrupts (less but they share the same lower interrupts), clocks and memory space
> 
> This is why it was decided to have a sub-dtsi, having a secondary dtsi will simply copy 99% of the GXL dtsi,
> but surely we could also have an intermediate dtsi but for boards I'm ok with it, but less for a SoC dtsi,
> since it could lead to some confusion.
> 
> Finally, yes I could have added the mali node to the GXL dtsi, but the midgard Mali dt-bindings are not upstream
> and the family is too big and recent enough to consider having stable bindings for now.

OK, my question really was specific to Mali differences. :)

> Nevertheless, nothing is final, this gxl-mali.dtsi could be merged into the GXL dtsi in the future when we
> have proper dt-bindings and a real support of the T820 Mali on the S912.

What about a /delete-node/ &mali; in meson-gxm.dtsi?
That would avoid having any new .dtsi.

Regards,
Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany
GF: Felix Imend?rffer, Jane Smithard, Graham Norton
HRB 21284 (AG N?rnberg)

Re: [PATCH v2 3/3] ARM64: dts: meson-gx: Add MALI nodes for GXBB and GXL

[Kevin Hilman]

Neil Armstrong <narmstrong@baylibre.com> writes:

> Hi Andreas,
> On 03/02/2017 01:31 PM, Andreas Färber wrote:
>> Hi Neil,
>> 
>> Am 01.03.2017 um 11:46 schrieb Neil Armstrong:
>>> The same MALI-450 MP3 GPU is present in the GXBB and GXL SoCs.
>> 
>> First of all, any reason you're upper-casing Mali in the commit message?
>> ARM doesn't.
>
> No reason, only a type, indeed it was lower-casing on the v1.
> Will fix in v2.
>
>> 
>>>
>>> The node is simply added in the meson-gxbb.dtsi file.
>> 
>> The GXBB part looks fine on a quick look.
>> 
>>>
>>> For GXL, since a lot is shared with the GXM that has a MALI-T820 IP, this
>>> patch adds a new meson-gxl-mali.dtsi and is included in the SoC specific
>>> dtsi files.
>> 
>> This part is slightly confusing though.
>> 
>> What exactly is the GXL vs. GXM difference that this can't be handled by
>> overriding node properties compatible/interrupts/clocks? I am missing a
>> GXM patch in this series as rationale for doing it this way.
>> 
>> In particular I am wondering whether the whole GXM-inherits-from-GXL
>> concept is flawed and should be adjusted if this leads to secondary
>> .dtsi files like this: My proposal would be to instead create a
>> meson-gxl-gxm.dtsi, that meson-gxl.dtsi and meson-gxm.dtsi can inherit
>> the current common parts from, then the Mali bits can simply go into
>> meson-gxl.dtsi without extra #includes needed in S905X and S905D. While
>> it's slightly more work to split once again, I think it would be cleaner.
>
> The GXL and GXM differences are very small :
>  - They share the same clock tree
>  - They share the same pinctrl and even the same pinout (S905D and S912 are pin-to-pin compatible)
>  - They share all the peripherals
>
> The only changes are :
>  - Enhanced video encoding and decoding support, this will need a family-specific compatible when pushed
>  - Slightly differences in the Video Processing Unit, this is why I introduced family-specific compatibles
>  - A secondary Cortex-A53 cluster
>  - A secondary SCPI cpufreq clock entry
>  - A different Mali core, but with the same interrupts (less but they share the same lower interrupts), clocks and memory space
>
> This is why it was decided to have a sub-dtsi, having a secondary dtsi will simply copy 99% of the GXL dtsi,
> but surely we could also have an intermediate dtsi but for boards I'm ok with it, but less for a SoC dtsi,
> since it could lead to some confusion.
>
> Finally, yes I could have added the mali node to the GXL dtsi, but the midgard Mali dt-bindings are not upstream
> and the family is too big and recent enough to consider having stable bindings for now.
>
> Nevertheless, nothing is final, this gxl-mali.dtsi could be merged into the GXL dtsi in the future when we
> have proper dt-bindings and a real support of the T820 Mali on the S912.
>
> Kevin, what's your thought about this ?

I don't have a strong preference.  I'm OK with a separate Mali .dtsi due
to the signficant overlap between GXL/GXM in terms of clocks, interrupts
etc.

However, if the plan is to #include this from GXM .dts files, whould a
better name be meson-gx-mali.dtsi?

Kevin

Re: [PATCH v2 3/3] ARM64: dts: meson-gx: Add MALI nodes for GXBB and GXL

[Kevin Hilman]

Neil Armstrong <narmstrong@baylibre.com> writes:

> Hi Andreas,
> On 03/02/2017 01:31 PM, Andreas Färber wrote:
>> Hi Neil,
>> 
>> Am 01.03.2017 um 11:46 schrieb Neil Armstrong:
>>> The same MALI-450 MP3 GPU is present in the GXBB and GXL SoCs.
>> 
>> First of all, any reason you're upper-casing Mali in the commit message?
>> ARM doesn't.
>
> No reason, only a type, indeed it was lower-casing on the v1.
> Will fix in v2.
>
>> 
>>>
>>> The node is simply added in the meson-gxbb.dtsi file.
>> 
>> The GXBB part looks fine on a quick look.
>> 
>>>
>>> For GXL, since a lot is shared with the GXM that has a MALI-T820 IP, this
>>> patch adds a new meson-gxl-mali.dtsi and is included in the SoC specific
>>> dtsi files.
>> 
>> This part is slightly confusing though.
>> 
>> What exactly is the GXL vs. GXM difference that this can't be handled by
>> overriding node properties compatible/interrupts/clocks? I am missing a
>> GXM patch in this series as rationale for doing it this way.
>> 
>> In particular I am wondering whether the whole GXM-inherits-from-GXL
>> concept is flawed and should be adjusted if this leads to secondary
>> .dtsi files like this: My proposal would be to instead create a
>> meson-gxl-gxm.dtsi, that meson-gxl.dtsi and meson-gxm.dtsi can inherit
>> the current common parts from, then the Mali bits can simply go into
>> meson-gxl.dtsi without extra #includes needed in S905X and S905D. While
>> it's slightly more work to split once again, I think it would be cleaner.
>
> The GXL and GXM differences are very small :
>  - They share the same clock tree
>  - They share the same pinctrl and even the same pinout (S905D and S912 are pin-to-pin compatible)
>  - They share all the peripherals
>
> The only changes are :
>  - Enhanced video encoding and decoding support, this will need a family-specific compatible when pushed
>  - Slightly differences in the Video Processing Unit, this is why I introduced family-specific compatibles
>  - A secondary Cortex-A53 cluster
>  - A secondary SCPI cpufreq clock entry
>  - A different Mali core, but with the same interrupts (less but they share the same lower interrupts), clocks and memory space
>
> This is why it was decided to have a sub-dtsi, having a secondary dtsi will simply copy 99% of the GXL dtsi,
> but surely we could also have an intermediate dtsi but for boards I'm ok with it, but less for a SoC dtsi,
> since it could lead to some confusion.
>
> Finally, yes I could have added the mali node to the GXL dtsi, but the midgard Mali dt-bindings are not upstream
> and the family is too big and recent enough to consider having stable bindings for now.
>
> Nevertheless, nothing is final, this gxl-mali.dtsi could be merged into the GXL dtsi in the future when we
> have proper dt-bindings and a real support of the T820 Mali on the S912.
>
> Kevin, what's your thought about this ?

I don't have a strong preference.  I'm OK with a separate Mali .dtsi due
to the signficant overlap between GXL/GXM in terms of clocks, interrupts
etc.

However, if the plan is to #include this from GXM .dts files, whould a
better name be meson-gx-mali.dtsi?

Kevin

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v2 3/3] ARM64: dts: meson-gx: Add MALI nodes for GXBB and GXL

[Kevin Hilman]

TmVpbCBBcm1zdHJvbmcgPG5hcm1zdHJvbmdAYmF5bGlicmUuY29tPiB3cml0ZXM6Cgo+IEhpIEFu
ZHJlYXMsCj4gT24gMDMvMDIvMjAxNyAwMTozMSBQTSwgQW5kcmVhcyBGw6RyYmVyIHdyb3RlOgo+
PiBIaSBOZWlsLAo+PiAKPj4gQW0gMDEuMDMuMjAxNyB1bSAxMTo0NiBzY2hyaWViIE5laWwgQXJt
c3Ryb25nOgo+Pj4gVGhlIHNhbWUgTUFMSS00NTAgTVAzIEdQVSBpcyBwcmVzZW50IGluIHRoZSBH
WEJCIGFuZCBHWEwgU29Dcy4KPj4gCj4+IEZpcnN0IG9mIGFsbCwgYW55IHJlYXNvbiB5b3UncmUg
dXBwZXItY2FzaW5nIE1hbGkgaW4gdGhlIGNvbW1pdCBtZXNzYWdlPwo+PiBBUk0gZG9lc24ndC4K
Pgo+IE5vIHJlYXNvbiwgb25seSBhIHR5cGUsIGluZGVlZCBpdCB3YXMgbG93ZXItY2FzaW5nIG9u
IHRoZSB2MS4KPiBXaWxsIGZpeCBpbiB2Mi4KPgo+PiAKPj4+Cj4+PiBUaGUgbm9kZSBpcyBzaW1w
bHkgYWRkZWQgaW4gdGhlIG1lc29uLWd4YmIuZHRzaSBmaWxlLgo+PiAKPj4gVGhlIEdYQkIgcGFy
dCBsb29rcyBmaW5lIG9uIGEgcXVpY2sgbG9vay4KPj4gCj4+Pgo+Pj4gRm9yIEdYTCwgc2luY2Ug
YSBsb3QgaXMgc2hhcmVkIHdpdGggdGhlIEdYTSB0aGF0IGhhcyBhIE1BTEktVDgyMCBJUCwgdGhp
cwo+Pj4gcGF0Y2ggYWRkcyBhIG5ldyBtZXNvbi1neGwtbWFsaS5kdHNpIGFuZCBpcyBpbmNsdWRl
ZCBpbiB0aGUgU29DIHNwZWNpZmljCj4+PiBkdHNpIGZpbGVzLgo+PiAKPj4gVGhpcyBwYXJ0IGlz
IHNsaWdodGx5IGNvbmZ1c2luZyB0aG91Z2guCj4+IAo+PiBXaGF0IGV4YWN0bHkgaXMgdGhlIEdY
TCB2cy4gR1hNIGRpZmZlcmVuY2UgdGhhdCB0aGlzIGNhbid0IGJlIGhhbmRsZWQgYnkKPj4gb3Zl
cnJpZGluZyBub2RlIHByb3BlcnRpZXMgY29tcGF0aWJsZS9pbnRlcnJ1cHRzL2Nsb2Nrcz8gSSBh
bSBtaXNzaW5nIGEKPj4gR1hNIHBhdGNoIGluIHRoaXMgc2VyaWVzIGFzIHJhdGlvbmFsZSBmb3Ig
ZG9pbmcgaXQgdGhpcyB3YXkuCj4+IAo+PiBJbiBwYXJ0aWN1bGFyIEkgYW0gd29uZGVyaW5nIHdo
ZXRoZXIgdGhlIHdob2xlIEdYTS1pbmhlcml0cy1mcm9tLUdYTAo+PiBjb25jZXB0IGlzIGZsYXdl
ZCBhbmQgc2hvdWxkIGJlIGFkanVzdGVkIGlmIHRoaXMgbGVhZHMgdG8gc2Vjb25kYXJ5Cj4+IC5k
dHNpIGZpbGVzIGxpa2UgdGhpczogTXkgcHJvcG9zYWwgd291bGQgYmUgdG8gaW5zdGVhZCBjcmVh
dGUgYQo+PiBtZXNvbi1neGwtZ3htLmR0c2ksIHRoYXQgbWVzb24tZ3hsLmR0c2kgYW5kIG1lc29u
LWd4bS5kdHNpIGNhbiBpbmhlcml0Cj4+IHRoZSBjdXJyZW50IGNvbW1vbiBwYXJ0cyBmcm9tLCB0
aGVuIHRoZSBNYWxpIGJpdHMgY2FuIHNpbXBseSBnbyBpbnRvCj4+IG1lc29uLWd4bC5kdHNpIHdp
dGhvdXQgZXh0cmEgI2luY2x1ZGVzIG5lZWRlZCBpbiBTOTA1WCBhbmQgUzkwNUQuIFdoaWxlCj4+
IGl0J3Mgc2xpZ2h0bHkgbW9yZSB3b3JrIHRvIHNwbGl0IG9uY2UgYWdhaW4sIEkgdGhpbmsgaXQg
d291bGQgYmUgY2xlYW5lci4KPgo+IFRoZSBHWEwgYW5kIEdYTSBkaWZmZXJlbmNlcyBhcmUgdmVy
eSBzbWFsbCA6Cj4gIC0gVGhleSBzaGFyZSB0aGUgc2FtZSBjbG9jayB0cmVlCj4gIC0gVGhleSBz
aGFyZSB0aGUgc2FtZSBwaW5jdHJsIGFuZCBldmVuIHRoZSBzYW1lIHBpbm91dCAoUzkwNUQgYW5k
IFM5MTIgYXJlIHBpbi10by1waW4gY29tcGF0aWJsZSkKPiAgLSBUaGV5IHNoYXJlIGFsbCB0aGUg
cGVyaXBoZXJhbHMKPgo+IFRoZSBvbmx5IGNoYW5nZXMgYXJlIDoKPiAgLSBFbmhhbmNlZCB2aWRl
byBlbmNvZGluZyBhbmQgZGVjb2Rpbmcgc3VwcG9ydCwgdGhpcyB3aWxsIG5lZWQgYSBmYW1pbHkt
c3BlY2lmaWMgY29tcGF0aWJsZSB3aGVuIHB1c2hlZAo+ICAtIFNsaWdodGx5IGRpZmZlcmVuY2Vz
IGluIHRoZSBWaWRlbyBQcm9jZXNzaW5nIFVuaXQsIHRoaXMgaXMgd2h5IEkgaW50cm9kdWNlZCBm
YW1pbHktc3BlY2lmaWMgY29tcGF0aWJsZXMKPiAgLSBBIHNlY29uZGFyeSBDb3J0ZXgtQTUzIGNs
dXN0ZXIKPiAgLSBBIHNlY29uZGFyeSBTQ1BJIGNwdWZyZXEgY2xvY2sgZW50cnkKPiAgLSBBIGRp
ZmZlcmVudCBNYWxpIGNvcmUsIGJ1dCB3aXRoIHRoZSBzYW1lIGludGVycnVwdHMgKGxlc3MgYnV0
IHRoZXkgc2hhcmUgdGhlIHNhbWUgbG93ZXIgaW50ZXJydXB0cyksIGNsb2NrcyBhbmQgbWVtb3J5
IHNwYWNlCj4KPiBUaGlzIGlzIHdoeSBpdCB3YXMgZGVjaWRlZCB0byBoYXZlIGEgc3ViLWR0c2ks
IGhhdmluZyBhIHNlY29uZGFyeSBkdHNpIHdpbGwgc2ltcGx5IGNvcHkgOTklIG9mIHRoZSBHWEwg
ZHRzaSwKPiBidXQgc3VyZWx5IHdlIGNvdWxkIGFsc28gaGF2ZSBhbiBpbnRlcm1lZGlhdGUgZHRz
aSBidXQgZm9yIGJvYXJkcyBJJ20gb2sgd2l0aCBpdCwgYnV0IGxlc3MgZm9yIGEgU29DIGR0c2ks
Cj4gc2luY2UgaXQgY291bGQgbGVhZCB0byBzb21lIGNvbmZ1c2lvbi4KPgo+IEZpbmFsbHksIHll
cyBJIGNvdWxkIGhhdmUgYWRkZWQgdGhlIG1hbGkgbm9kZSB0byB0aGUgR1hMIGR0c2ksIGJ1dCB0
aGUgbWlkZ2FyZCBNYWxpIGR0LWJpbmRpbmdzIGFyZSBub3QgdXBzdHJlYW0KPiBhbmQgdGhlIGZh
bWlseSBpcyB0b28gYmlnIGFuZCByZWNlbnQgZW5vdWdoIHRvIGNvbnNpZGVyIGhhdmluZyBzdGFi
bGUgYmluZGluZ3MgZm9yIG5vdy4KPgo+IE5ldmVydGhlbGVzcywgbm90aGluZyBpcyBmaW5hbCwg
dGhpcyBneGwtbWFsaS5kdHNpIGNvdWxkIGJlIG1lcmdlZCBpbnRvIHRoZSBHWEwgZHRzaSBpbiB0
aGUgZnV0dXJlIHdoZW4gd2UKPiBoYXZlIHByb3BlciBkdC1iaW5kaW5ncyBhbmQgYSByZWFsIHN1
cHBvcnQgb2YgdGhlIFQ4MjAgTWFsaSBvbiB0aGUgUzkxMi4KPgo+IEtldmluLCB3aGF0J3MgeW91
ciB0aG91Z2h0IGFib3V0IHRoaXMgPwoKSSBkb24ndCBoYXZlIGEgc3Ryb25nIHByZWZlcmVuY2Uu
ICBJJ20gT0sgd2l0aCBhIHNlcGFyYXRlIE1hbGkgLmR0c2kgZHVlCnRvIHRoZSBzaWduZmljYW50
IG92ZXJsYXAgYmV0d2VlbiBHWEwvR1hNIGluIHRlcm1zIG9mIGNsb2NrcywgaW50ZXJydXB0cwpl
dGMuCgpIb3dldmVyLCBpZiB0aGUgcGxhbiBpcyB0byAjaW5jbHVkZSB0aGlzIGZyb20gR1hNIC5k
dHMgZmlsZXMsIHdob3VsZCBhCmJldHRlciBuYW1lIGJlIG1lc29uLWd4LW1hbGkuZHRzaT8KCktl
dmluCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpsaW51
eC1hbWxvZ2ljIG1haWxpbmcgbGlzdApsaW51eC1hbWxvZ2ljQGxpc3RzLmluZnJhZGVhZC5vcmcK
aHR0cDovL2xpc3RzLmluZnJhZGVhZC5vcmcvbWFpbG1hbi9saXN0aW5mby9saW51eC1hbWxvZ2lj
Cg==

[PATCH v2 3/3] ARM64: dts: meson-gx: Add MALI nodes for GXBB and GXL

[Kevin Hilman]

Neil Armstrong <narmstrong@baylibre.com> writes:

> Hi Andreas,
> On 03/02/2017 01:31 PM, Andreas F?rber wrote:
>> Hi Neil,
>> 
>> Am 01.03.2017 um 11:46 schrieb Neil Armstrong:
>>> The same MALI-450 MP3 GPU is present in the GXBB and GXL SoCs.
>> 
>> First of all, any reason you're upper-casing Mali in the commit message?
>> ARM doesn't.
>
> No reason, only a type, indeed it was lower-casing on the v1.
> Will fix in v2.
>
>> 
>>>
>>> The node is simply added in the meson-gxbb.dtsi file.
>> 
>> The GXBB part looks fine on a quick look.
>> 
>>>
>>> For GXL, since a lot is shared with the GXM that has a MALI-T820 IP, this
>>> patch adds a new meson-gxl-mali.dtsi and is included in the SoC specific
>>> dtsi files.
>> 
>> This part is slightly confusing though.
>> 
>> What exactly is the GXL vs. GXM difference that this can't be handled by
>> overriding node properties compatible/interrupts/clocks? I am missing a
>> GXM patch in this series as rationale for doing it this way.
>> 
>> In particular I am wondering whether the whole GXM-inherits-from-GXL
>> concept is flawed and should be adjusted if this leads to secondary
>> .dtsi files like this: My proposal would be to instead create a
>> meson-gxl-gxm.dtsi, that meson-gxl.dtsi and meson-gxm.dtsi can inherit
>> the current common parts from, then the Mali bits can simply go into
>> meson-gxl.dtsi without extra #includes needed in S905X and S905D. While
>> it's slightly more work to split once again, I think it would be cleaner.
>
> The GXL and GXM differences are very small :
>  - They share the same clock tree
>  - They share the same pinctrl and even the same pinout (S905D and S912 are pin-to-pin compatible)
>  - They share all the peripherals
>
> The only changes are :
>  - Enhanced video encoding and decoding support, this will need a family-specific compatible when pushed
>  - Slightly differences in the Video Processing Unit, this is why I introduced family-specific compatibles
>  - A secondary Cortex-A53 cluster
>  - A secondary SCPI cpufreq clock entry
>  - A different Mali core, but with the same interrupts (less but they share the same lower interrupts), clocks and memory space
>
> This is why it was decided to have a sub-dtsi, having a secondary dtsi will simply copy 99% of the GXL dtsi,
> but surely we could also have an intermediate dtsi but for boards I'm ok with it, but less for a SoC dtsi,
> since it could lead to some confusion.
>
> Finally, yes I could have added the mali node to the GXL dtsi, but the midgard Mali dt-bindings are not upstream
> and the family is too big and recent enough to consider having stable bindings for now.
>
> Nevertheless, nothing is final, this gxl-mali.dtsi could be merged into the GXL dtsi in the future when we
> have proper dt-bindings and a real support of the T820 Mali on the S912.
>
> Kevin, what's your thought about this ?

I don't have a strong preference.  I'm OK with a separate Mali .dtsi due
to the signficant overlap between GXL/GXM in terms of clocks, interrupts
etc.

However, if the plan is to #include this from GXM .dts files, whould a
better name be meson-gx-mali.dtsi?

Kevin

[PATCH v2 3/3] ARM64: dts: meson-gx: Add MALI nodes for GXBB and GXL

[Kevin Hilman]

Neil Armstrong <narmstrong@baylibre.com> writes:

> Hi Andreas,
> On 03/02/2017 01:31 PM, Andreas F?rber wrote:
>> Hi Neil,
>> 
>> Am 01.03.2017 um 11:46 schrieb Neil Armstrong:
>>> The same MALI-450 MP3 GPU is present in the GXBB and GXL SoCs.
>> 
>> First of all, any reason you're upper-casing Mali in the commit message?
>> ARM doesn't.
>
> No reason, only a type, indeed it was lower-casing on the v1.
> Will fix in v2.
>
>> 
>>>
>>> The node is simply added in the meson-gxbb.dtsi file.
>> 
>> The GXBB part looks fine on a quick look.
>> 
>>>
>>> For GXL, since a lot is shared with the GXM that has a MALI-T820 IP, this
>>> patch adds a new meson-gxl-mali.dtsi and is included in the SoC specific
>>> dtsi files.
>> 
>> This part is slightly confusing though.
>> 
>> What exactly is the GXL vs. GXM difference that this can't be handled by
>> overriding node properties compatible/interrupts/clocks? I am missing a
>> GXM patch in this series as rationale for doing it this way.
>> 
>> In particular I am wondering whether the whole GXM-inherits-from-GXL
>> concept is flawed and should be adjusted if this leads to secondary
>> .dtsi files like this: My proposal would be to instead create a
>> meson-gxl-gxm.dtsi, that meson-gxl.dtsi and meson-gxm.dtsi can inherit
>> the current common parts from, then the Mali bits can simply go into
>> meson-gxl.dtsi without extra #includes needed in S905X and S905D. While
>> it's slightly more work to split once again, I think it would be cleaner.
>
> The GXL and GXM differences are very small :
>  - They share the same clock tree
>  - They share the same pinctrl and even the same pinout (S905D and S912 are pin-to-pin compatible)
>  - They share all the peripherals
>
> The only changes are :
>  - Enhanced video encoding and decoding support, this will need a family-specific compatible when pushed
>  - Slightly differences in the Video Processing Unit, this is why I introduced family-specific compatibles
>  - A secondary Cortex-A53 cluster
>  - A secondary SCPI cpufreq clock entry
>  - A different Mali core, but with the same interrupts (less but they share the same lower interrupts), clocks and memory space
>
> This is why it was decided to have a sub-dtsi, having a secondary dtsi will simply copy 99% of the GXL dtsi,
> but surely we could also have an intermediate dtsi but for boards I'm ok with it, but less for a SoC dtsi,
> since it could lead to some confusion.
>
> Finally, yes I could have added the mali node to the GXL dtsi, but the midgard Mali dt-bindings are not upstream
> and the family is too big and recent enough to consider having stable bindings for now.
>
> Nevertheless, nothing is final, this gxl-mali.dtsi could be merged into the GXL dtsi in the future when we
> have proper dt-bindings and a real support of the T820 Mali on the S912.
>
> Kevin, what's your thought about this ?

I don't have a strong preference.  I'm OK with a separate Mali .dtsi due
to the signficant overlap between GXL/GXM in terms of clocks, interrupts
etc.

However, if the plan is to #include this from GXM .dts files, whould a
better name be meson-gx-mali.dtsi?

Kevin

Re: [PATCH v2 3/3] ARM64: dts: meson-gx: Add MALI nodes for GXBB and GXL

[Andreas Färber]

Am 03.03.2017 um 20:29 schrieb Kevin Hilman:
> Neil Armstrong <narmstrong@baylibre.com> writes:
>> On 03/02/2017 01:31 PM, Andreas Färber wrote:
>>> Am 01.03.2017 um 11:46 schrieb Neil Armstrong:
>>>> The same MALI-450 MP3 GPU is present in the GXBB and GXL SoCs.
[...]
>>>> The node is simply added in the meson-gxbb.dtsi file.
[...]
>>>> For GXL, since a lot is shared with the GXM that has a MALI-T820 IP, this
>>>> patch adds a new meson-gxl-mali.dtsi and is included in the SoC specific
>>>> dtsi files.
>>>
>>> This part is slightly confusing though.
>>>
>>> What exactly is the GXL vs. GXM difference that this can't be handled by
>>> overriding node properties compatible/interrupts/clocks? I am missing a
>>> GXM patch in this series as rationale for doing it this way.
>>>
>>> In particular I am wondering whether the whole GXM-inherits-from-GXL
>>> concept is flawed and should be adjusted if this leads to secondary
>>> .dtsi files like this: My proposal would be to instead create a
>>> meson-gxl-gxm.dtsi, that meson-gxl.dtsi and meson-gxm.dtsi can inherit
>>> the current common parts from, then the Mali bits can simply go into
>>> meson-gxl.dtsi without extra #includes needed in S905X and S905D. While
>>> it's slightly more work to split once again, I think it would be cleaner.
[...]
>> The only changes are :
[...]
>>  - A different Mali core, but with the same interrupts (less but they share the same lower interrupts), clocks and memory space
>>
>> This is why it was decided to have a sub-dtsi, having a secondary dtsi will simply copy 99% of the GXL dtsi,
>> but surely we could also have an intermediate dtsi but for boards I'm ok with it, but less for a SoC dtsi,
>> since it could lead to some confusion.
>>
>> Finally, yes I could have added the mali node to the GXL dtsi, but the midgard Mali dt-bindings are not upstream
>> and the family is too big and recent enough to consider having stable bindings for now.
>>
>> Nevertheless, nothing is final, this gxl-mali.dtsi could be merged into the GXL dtsi in the future when we
>> have proper dt-bindings and a real support of the T820 Mali on the S912.
>>
>> Kevin, what's your thought about this ?
> 
> I don't have a strong preference.  I'm OK with a separate Mali .dtsi due
> to the signficant overlap between GXL/GXM in terms of clocks, interrupts
> etc.
> 
> However, if the plan is to #include this from GXM .dts files, whould a
> better name be meson-gx-mali.dtsi?

I thought the purpose was specifically to not have GXM include it
because it uses a Midgard IP.

If you want to share the fragment with GXBB too (gx), we should rather
use meson-gx-mali-utgard.dtsi, which would differentiate from GXM's
Midgard while still allowing for variation on the 4xx side (e.g., 470).

Regards,
Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)

Re: [PATCH v2 3/3] ARM64: dts: meson-gx: Add MALI nodes for GXBB and GXL

[Andreas Färber]

Am 03.03.2017 um 20:29 schrieb Kevin Hilman:
> Neil Armstrong <narmstrong@baylibre.com> writes:
>> On 03/02/2017 01:31 PM, Andreas Färber wrote:
>>> Am 01.03.2017 um 11:46 schrieb Neil Armstrong:
>>>> The same MALI-450 MP3 GPU is present in the GXBB and GXL SoCs.
[...]
>>>> The node is simply added in the meson-gxbb.dtsi file.
[...]
>>>> For GXL, since a lot is shared with the GXM that has a MALI-T820 IP, this
>>>> patch adds a new meson-gxl-mali.dtsi and is included in the SoC specific
>>>> dtsi files.
>>>
>>> This part is slightly confusing though.
>>>
>>> What exactly is the GXL vs. GXM difference that this can't be handled by
>>> overriding node properties compatible/interrupts/clocks? I am missing a
>>> GXM patch in this series as rationale for doing it this way.
>>>
>>> In particular I am wondering whether the whole GXM-inherits-from-GXL
>>> concept is flawed and should be adjusted if this leads to secondary
>>> .dtsi files like this: My proposal would be to instead create a
>>> meson-gxl-gxm.dtsi, that meson-gxl.dtsi and meson-gxm.dtsi can inherit
>>> the current common parts from, then the Mali bits can simply go into
>>> meson-gxl.dtsi without extra #includes needed in S905X and S905D. While
>>> it's slightly more work to split once again, I think it would be cleaner.
[...]
>> The only changes are :
[...]
>>  - A different Mali core, but with the same interrupts (less but they share the same lower interrupts), clocks and memory space
>>
>> This is why it was decided to have a sub-dtsi, having a secondary dtsi will simply copy 99% of the GXL dtsi,
>> but surely we could also have an intermediate dtsi but for boards I'm ok with it, but less for a SoC dtsi,
>> since it could lead to some confusion.
>>
>> Finally, yes I could have added the mali node to the GXL dtsi, but the midgard Mali dt-bindings are not upstream
>> and the family is too big and recent enough to consider having stable bindings for now.
>>
>> Nevertheless, nothing is final, this gxl-mali.dtsi could be merged into the GXL dtsi in the future when we
>> have proper dt-bindings and a real support of the T820 Mali on the S912.
>>
>> Kevin, what's your thought about this ?
> 
> I don't have a strong preference.  I'm OK with a separate Mali .dtsi due
> to the signficant overlap between GXL/GXM in terms of clocks, interrupts
> etc.
> 
> However, if the plan is to #include this from GXM .dts files, whould a
> better name be meson-gx-mali.dtsi?

I thought the purpose was specifically to not have GXM include it
because it uses a Midgard IP.

If you want to share the fragment with GXBB too (gx), we should rather
use meson-gx-mali-utgard.dtsi, which would differentiate from GXM's
Midgard while still allowing for variation on the 4xx side (e.g., 470).

Regards,
Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v2 3/3] ARM64: dts: meson-gx: Add MALI nodes for GXBB and GXL

[Andreas Färber]

QW0gMDMuMDMuMjAxNyB1bSAyMDoyOSBzY2hyaWViIEtldmluIEhpbG1hbjoKPiBOZWlsIEFybXN0
cm9uZyA8bmFybXN0cm9uZ0BiYXlsaWJyZS5jb20+IHdyaXRlczoKPj4gT24gMDMvMDIvMjAxNyAw
MTozMSBQTSwgQW5kcmVhcyBGw6RyYmVyIHdyb3RlOgo+Pj4gQW0gMDEuMDMuMjAxNyB1bSAxMTo0
NiBzY2hyaWViIE5laWwgQXJtc3Ryb25nOgo+Pj4+IFRoZSBzYW1lIE1BTEktNDUwIE1QMyBHUFUg
aXMgcHJlc2VudCBpbiB0aGUgR1hCQiBhbmQgR1hMIFNvQ3MuClsuLi5dCj4+Pj4gVGhlIG5vZGUg
aXMgc2ltcGx5IGFkZGVkIGluIHRoZSBtZXNvbi1neGJiLmR0c2kgZmlsZS4KWy4uLl0KPj4+PiBG
b3IgR1hMLCBzaW5jZSBhIGxvdCBpcyBzaGFyZWQgd2l0aCB0aGUgR1hNIHRoYXQgaGFzIGEgTUFM
SS1UODIwIElQLCB0aGlzCj4+Pj4gcGF0Y2ggYWRkcyBhIG5ldyBtZXNvbi1neGwtbWFsaS5kdHNp
IGFuZCBpcyBpbmNsdWRlZCBpbiB0aGUgU29DIHNwZWNpZmljCj4+Pj4gZHRzaSBmaWxlcy4KPj4+
Cj4+PiBUaGlzIHBhcnQgaXMgc2xpZ2h0bHkgY29uZnVzaW5nIHRob3VnaC4KPj4+Cj4+PiBXaGF0
IGV4YWN0bHkgaXMgdGhlIEdYTCB2cy4gR1hNIGRpZmZlcmVuY2UgdGhhdCB0aGlzIGNhbid0IGJl
IGhhbmRsZWQgYnkKPj4+IG92ZXJyaWRpbmcgbm9kZSBwcm9wZXJ0aWVzIGNvbXBhdGlibGUvaW50
ZXJydXB0cy9jbG9ja3M/IEkgYW0gbWlzc2luZyBhCj4+PiBHWE0gcGF0Y2ggaW4gdGhpcyBzZXJp
ZXMgYXMgcmF0aW9uYWxlIGZvciBkb2luZyBpdCB0aGlzIHdheS4KPj4+Cj4+PiBJbiBwYXJ0aWN1
bGFyIEkgYW0gd29uZGVyaW5nIHdoZXRoZXIgdGhlIHdob2xlIEdYTS1pbmhlcml0cy1mcm9tLUdY
TAo+Pj4gY29uY2VwdCBpcyBmbGF3ZWQgYW5kIHNob3VsZCBiZSBhZGp1c3RlZCBpZiB0aGlzIGxl
YWRzIHRvIHNlY29uZGFyeQo+Pj4gLmR0c2kgZmlsZXMgbGlrZSB0aGlzOiBNeSBwcm9wb3NhbCB3
b3VsZCBiZSB0byBpbnN0ZWFkIGNyZWF0ZSBhCj4+PiBtZXNvbi1neGwtZ3htLmR0c2ksIHRoYXQg
bWVzb24tZ3hsLmR0c2kgYW5kIG1lc29uLWd4bS5kdHNpIGNhbiBpbmhlcml0Cj4+PiB0aGUgY3Vy
cmVudCBjb21tb24gcGFydHMgZnJvbSwgdGhlbiB0aGUgTWFsaSBiaXRzIGNhbiBzaW1wbHkgZ28g
aW50bwo+Pj4gbWVzb24tZ3hsLmR0c2kgd2l0aG91dCBleHRyYSAjaW5jbHVkZXMgbmVlZGVkIGlu
IFM5MDVYIGFuZCBTOTA1RC4gV2hpbGUKPj4+IGl0J3Mgc2xpZ2h0bHkgbW9yZSB3b3JrIHRvIHNw
bGl0IG9uY2UgYWdhaW4sIEkgdGhpbmsgaXQgd291bGQgYmUgY2xlYW5lci4KWy4uLl0KPj4gVGhl
IG9ubHkgY2hhbmdlcyBhcmUgOgpbLi4uXQo+PiAgLSBBIGRpZmZlcmVudCBNYWxpIGNvcmUsIGJ1
dCB3aXRoIHRoZSBzYW1lIGludGVycnVwdHMgKGxlc3MgYnV0IHRoZXkgc2hhcmUgdGhlIHNhbWUg
bG93ZXIgaW50ZXJydXB0cyksIGNsb2NrcyBhbmQgbWVtb3J5IHNwYWNlCj4+Cj4+IFRoaXMgaXMg
d2h5IGl0IHdhcyBkZWNpZGVkIHRvIGhhdmUgYSBzdWItZHRzaSwgaGF2aW5nIGEgc2Vjb25kYXJ5
IGR0c2kgd2lsbCBzaW1wbHkgY29weSA5OSUgb2YgdGhlIEdYTCBkdHNpLAo+PiBidXQgc3VyZWx5
IHdlIGNvdWxkIGFsc28gaGF2ZSBhbiBpbnRlcm1lZGlhdGUgZHRzaSBidXQgZm9yIGJvYXJkcyBJ
J20gb2sgd2l0aCBpdCwgYnV0IGxlc3MgZm9yIGEgU29DIGR0c2ksCj4+IHNpbmNlIGl0IGNvdWxk
IGxlYWQgdG8gc29tZSBjb25mdXNpb24uCj4+Cj4+IEZpbmFsbHksIHllcyBJIGNvdWxkIGhhdmUg
YWRkZWQgdGhlIG1hbGkgbm9kZSB0byB0aGUgR1hMIGR0c2ksIGJ1dCB0aGUgbWlkZ2FyZCBNYWxp
IGR0LWJpbmRpbmdzIGFyZSBub3QgdXBzdHJlYW0KPj4gYW5kIHRoZSBmYW1pbHkgaXMgdG9vIGJp
ZyBhbmQgcmVjZW50IGVub3VnaCB0byBjb25zaWRlciBoYXZpbmcgc3RhYmxlIGJpbmRpbmdzIGZv
ciBub3cuCj4+Cj4+IE5ldmVydGhlbGVzcywgbm90aGluZyBpcyBmaW5hbCwgdGhpcyBneGwtbWFs
aS5kdHNpIGNvdWxkIGJlIG1lcmdlZCBpbnRvIHRoZSBHWEwgZHRzaSBpbiB0aGUgZnV0dXJlIHdo
ZW4gd2UKPj4gaGF2ZSBwcm9wZXIgZHQtYmluZGluZ3MgYW5kIGEgcmVhbCBzdXBwb3J0IG9mIHRo
ZSBUODIwIE1hbGkgb24gdGhlIFM5MTIuCj4+Cj4+IEtldmluLCB3aGF0J3MgeW91ciB0aG91Z2h0
IGFib3V0IHRoaXMgPwo+IAo+IEkgZG9uJ3QgaGF2ZSBhIHN0cm9uZyBwcmVmZXJlbmNlLiAgSSdt
IE9LIHdpdGggYSBzZXBhcmF0ZSBNYWxpIC5kdHNpIGR1ZQo+IHRvIHRoZSBzaWduZmljYW50IG92
ZXJsYXAgYmV0d2VlbiBHWEwvR1hNIGluIHRlcm1zIG9mIGNsb2NrcywgaW50ZXJydXB0cwo+IGV0
Yy4KPiAKPiBIb3dldmVyLCBpZiB0aGUgcGxhbiBpcyB0byAjaW5jbHVkZSB0aGlzIGZyb20gR1hN
IC5kdHMgZmlsZXMsIHdob3VsZCBhCj4gYmV0dGVyIG5hbWUgYmUgbWVzb24tZ3gtbWFsaS5kdHNp
PwoKSSB0aG91Z2h0IHRoZSBwdXJwb3NlIHdhcyBzcGVjaWZpY2FsbHkgdG8gbm90IGhhdmUgR1hN
IGluY2x1ZGUgaXQKYmVjYXVzZSBpdCB1c2VzIGEgTWlkZ2FyZCBJUC4KCklmIHlvdSB3YW50IHRv
IHNoYXJlIHRoZSBmcmFnbWVudCB3aXRoIEdYQkIgdG9vIChneCksIHdlIHNob3VsZCByYXRoZXIK
dXNlIG1lc29uLWd4LW1hbGktdXRnYXJkLmR0c2ksIHdoaWNoIHdvdWxkIGRpZmZlcmVudGlhdGUg
ZnJvbSBHWE0ncwpNaWRnYXJkIHdoaWxlIHN0aWxsIGFsbG93aW5nIGZvciB2YXJpYXRpb24gb24g
dGhlIDR4eCBzaWRlIChlLmcuLCA0NzApLgoKUmVnYXJkcywKQW5kcmVhcwoKLS0gClNVU0UgTGlu
dXggR21iSCwgTWF4ZmVsZHN0ci4gNSwgOTA0MDkgTsO8cm5iZXJnLCBHZXJtYW55CkdGOiBGZWxp
eCBJbWVuZMO2cmZmZXIsIEphbmUgU21pdGhhcmQsIEdyYWhhbSBOb3J0b24KSFJCIDIxMjg0IChB
RyBOw7xybmJlcmcpCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fXwpsaW51eC1hbWxvZ2ljIG1haWxpbmcgbGlzdApsaW51eC1hbWxvZ2ljQGxpc3RzLmluZnJh
ZGVhZC5vcmcKaHR0cDovL2xpc3RzLmluZnJhZGVhZC5vcmcvbWFpbG1hbi9saXN0aW5mby9saW51
eC1hbWxvZ2ljCg==

[PATCH v2 3/3] ARM64: dts: meson-gx: Add MALI nodes for GXBB and GXL

[Andreas Färber]

Am 03.03.2017 um 20:29 schrieb Kevin Hilman:
> Neil Armstrong <narmstrong@baylibre.com> writes:
>> On 03/02/2017 01:31 PM, Andreas F?rber wrote:
>>> Am 01.03.2017 um 11:46 schrieb Neil Armstrong:
>>>> The same MALI-450 MP3 GPU is present in the GXBB and GXL SoCs.
[...]
>>>> The node is simply added in the meson-gxbb.dtsi file.
[...]
>>>> For GXL, since a lot is shared with the GXM that has a MALI-T820 IP, this
>>>> patch adds a new meson-gxl-mali.dtsi and is included in the SoC specific
>>>> dtsi files.
>>>
>>> This part is slightly confusing though.
>>>
>>> What exactly is the GXL vs. GXM difference that this can't be handled by
>>> overriding node properties compatible/interrupts/clocks? I am missing a
>>> GXM patch in this series as rationale for doing it this way.
>>>
>>> In particular I am wondering whether the whole GXM-inherits-from-GXL
>>> concept is flawed and should be adjusted if this leads to secondary
>>> .dtsi files like this: My proposal would be to instead create a
>>> meson-gxl-gxm.dtsi, that meson-gxl.dtsi and meson-gxm.dtsi can inherit
>>> the current common parts from, then the Mali bits can simply go into
>>> meson-gxl.dtsi without extra #includes needed in S905X and S905D. While
>>> it's slightly more work to split once again, I think it would be cleaner.
[...]
>> The only changes are :
[...]
>>  - A different Mali core, but with the same interrupts (less but they share the same lower interrupts), clocks and memory space
>>
>> This is why it was decided to have a sub-dtsi, having a secondary dtsi will simply copy 99% of the GXL dtsi,
>> but surely we could also have an intermediate dtsi but for boards I'm ok with it, but less for a SoC dtsi,
>> since it could lead to some confusion.
>>
>> Finally, yes I could have added the mali node to the GXL dtsi, but the midgard Mali dt-bindings are not upstream
>> and the family is too big and recent enough to consider having stable bindings for now.
>>
>> Nevertheless, nothing is final, this gxl-mali.dtsi could be merged into the GXL dtsi in the future when we
>> have proper dt-bindings and a real support of the T820 Mali on the S912.
>>
>> Kevin, what's your thought about this ?
> 
> I don't have a strong preference.  I'm OK with a separate Mali .dtsi due
> to the signficant overlap between GXL/GXM in terms of clocks, interrupts
> etc.
> 
> However, if the plan is to #include this from GXM .dts files, whould a
> better name be meson-gx-mali.dtsi?

I thought the purpose was specifically to not have GXM include it
because it uses a Midgard IP.

If you want to share the fragment with GXBB too (gx), we should rather
use meson-gx-mali-utgard.dtsi, which would differentiate from GXM's
Midgard while still allowing for variation on the 4xx side (e.g., 470).

Regards,
Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany
GF: Felix Imend?rffer, Jane Smithard, Graham Norton
HRB 21284 (AG N?rnberg)

[PATCH v2 3/3] ARM64: dts: meson-gx: Add MALI nodes for GXBB and GXL

[Andreas Färber]

Am 03.03.2017 um 20:29 schrieb Kevin Hilman:
> Neil Armstrong <narmstrong@baylibre.com> writes:
>> On 03/02/2017 01:31 PM, Andreas F?rber wrote:
>>> Am 01.03.2017 um 11:46 schrieb Neil Armstrong:
>>>> The same MALI-450 MP3 GPU is present in the GXBB and GXL SoCs.
[...]
>>>> The node is simply added in the meson-gxbb.dtsi file.
[...]
>>>> For GXL, since a lot is shared with the GXM that has a MALI-T820 IP, this
>>>> patch adds a new meson-gxl-mali.dtsi and is included in the SoC specific
>>>> dtsi files.
>>>
>>> This part is slightly confusing though.
>>>
>>> What exactly is the GXL vs. GXM difference that this can't be handled by
>>> overriding node properties compatible/interrupts/clocks? I am missing a
>>> GXM patch in this series as rationale for doing it this way.
>>>
>>> In particular I am wondering whether the whole GXM-inherits-from-GXL
>>> concept is flawed and should be adjusted if this leads to secondary
>>> .dtsi files like this: My proposal would be to instead create a
>>> meson-gxl-gxm.dtsi, that meson-gxl.dtsi and meson-gxm.dtsi can inherit
>>> the current common parts from, then the Mali bits can simply go into
>>> meson-gxl.dtsi without extra #includes needed in S905X and S905D. While
>>> it's slightly more work to split once again, I think it would be cleaner.
[...]
>> The only changes are :
[...]
>>  - A different Mali core, but with the same interrupts (less but they share the same lower interrupts), clocks and memory space
>>
>> This is why it was decided to have a sub-dtsi, having a secondary dtsi will simply copy 99% of the GXL dtsi,
>> but surely we could also have an intermediate dtsi but for boards I'm ok with it, but less for a SoC dtsi,
>> since it could lead to some confusion.
>>
>> Finally, yes I could have added the mali node to the GXL dtsi, but the midgard Mali dt-bindings are not upstream
>> and the family is too big and recent enough to consider having stable bindings for now.
>>
>> Nevertheless, nothing is final, this gxl-mali.dtsi could be merged into the GXL dtsi in the future when we
>> have proper dt-bindings and a real support of the T820 Mali on the S912.
>>
>> Kevin, what's your thought about this ?
> 
> I don't have a strong preference.  I'm OK with a separate Mali .dtsi due
> to the signficant overlap between GXL/GXM in terms of clocks, interrupts
> etc.
> 
> However, if the plan is to #include this from GXM .dts files, whould a
> better name be meson-gx-mali.dtsi?

I thought the purpose was specifically to not have GXM include it
because it uses a Midgard IP.

If you want to share the fragment with GXBB too (gx), we should rather
use meson-gx-mali-utgard.dtsi, which would differentiate from GXM's
Midgard while still allowing for variation on the 4xx side (e.g., 470).

Regards,
Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany
GF: Felix Imend?rffer, Jane Smithard, Graham Norton
HRB 21284 (AG N?rnberg)

Re: [PATCH v2 3/3] ARM64: dts: meson-gx: Add MALI nodes for GXBB and GXL

[Neil Armstrong]

On 03/04/2017 01:38 PM, Andreas Färber wrote:
> Am 03.03.2017 um 20:29 schrieb Kevin Hilman:
>> Neil Armstrong <narmstrong@baylibre.com> writes:
>>> On 03/02/2017 01:31 PM, Andreas Färber wrote:
>>>> Am 01.03.2017 um 11:46 schrieb Neil Armstrong:
>>>>> The same MALI-450 MP3 GPU is present in the GXBB and GXL SoCs.
> [...]
>>>>> The node is simply added in the meson-gxbb.dtsi file.
> [...]
>>>>> For GXL, since a lot is shared with the GXM that has a MALI-T820 IP, this
>>>>> patch adds a new meson-gxl-mali.dtsi and is included in the SoC specific
>>>>> dtsi files.
>>>>
>>>> This part is slightly confusing though.
>>>>
>>>> What exactly is the GXL vs. GXM difference that this can't be handled by
>>>> overriding node properties compatible/interrupts/clocks? I am missing a
>>>> GXM patch in this series as rationale for doing it this way.
>>>>
>>>> In particular I am wondering whether the whole GXM-inherits-from-GXL
>>>> concept is flawed and should be adjusted if this leads to secondary
>>>> .dtsi files like this: My proposal would be to instead create a
>>>> meson-gxl-gxm.dtsi, that meson-gxl.dtsi and meson-gxm.dtsi can inherit
>>>> the current common parts from, then the Mali bits can simply go into
>>>> meson-gxl.dtsi without extra #includes needed in S905X and S905D. While
>>>> it's slightly more work to split once again, I think it would be cleaner.
> [...]
>>> The only changes are :
> [...]
>>>  - A different Mali core, but with the same interrupts (less but they share the same lower interrupts), clocks and memory space
>>>
>>> This is why it was decided to have a sub-dtsi, having a secondary dtsi will simply copy 99% of the GXL dtsi,
>>> but surely we could also have an intermediate dtsi but for boards I'm ok with it, but less for a SoC dtsi,
>>> since it could lead to some confusion.
>>>
>>> Finally, yes I could have added the mali node to the GXL dtsi, but the midgard Mali dt-bindings are not upstream
>>> and the family is too big and recent enough to consider having stable bindings for now.
>>>
>>> Nevertheless, nothing is final, this gxl-mali.dtsi could be merged into the GXL dtsi in the future when we
>>> have proper dt-bindings and a real support of the T820 Mali on the S912.
>>>
>>> Kevin, what's your thought about this ?
>>
>> I don't have a strong preference.  I'm OK with a separate Mali .dtsi due
>> to the signficant overlap between GXL/GXM in terms of clocks, interrupts
>> etc.
>>
>> However, if the plan is to #include this from GXM .dts files, whould a
>> better name be meson-gx-mali.dtsi?
> 
> I thought the purpose was specifically to not have GXM include it
> because it uses a Midgard IP.
> 
> If you want to share the fragment with GXBB too (gx), we should rather
> use meson-gx-mali-utgard.dtsi, which would differentiate from GXM's
> Midgard while still allowing for variation on the 4xx side (e.g., 470).
> 
> Regards,
> Andreas
> 

Exact, there is no plan to include it from GXM.

I'm not fan of having meson-gx-mali-utgard.dtsi, we should still need some attributes additions for
the clocks to the mali node in the gxbb dtsi and each s905x and s905d dtsi files.
I'm not sure this is even cleaner...

Neil

[PATCH v2 3/3] ARM64: dts: meson-gx: Add MALI nodes for GXBB and GXL

[Neil Armstrong]

On 03/04/2017 01:38 PM, Andreas F?rber wrote:
> Am 03.03.2017 um 20:29 schrieb Kevin Hilman:
>> Neil Armstrong <narmstrong@baylibre.com> writes:
>>> On 03/02/2017 01:31 PM, Andreas F?rber wrote:
>>>> Am 01.03.2017 um 11:46 schrieb Neil Armstrong:
>>>>> The same MALI-450 MP3 GPU is present in the GXBB and GXL SoCs.
> [...]
>>>>> The node is simply added in the meson-gxbb.dtsi file.
> [...]
>>>>> For GXL, since a lot is shared with the GXM that has a MALI-T820 IP, this
>>>>> patch adds a new meson-gxl-mali.dtsi and is included in the SoC specific
>>>>> dtsi files.
>>>>
>>>> This part is slightly confusing though.
>>>>
>>>> What exactly is the GXL vs. GXM difference that this can't be handled by
>>>> overriding node properties compatible/interrupts/clocks? I am missing a
>>>> GXM patch in this series as rationale for doing it this way.
>>>>
>>>> In particular I am wondering whether the whole GXM-inherits-from-GXL
>>>> concept is flawed and should be adjusted if this leads to secondary
>>>> .dtsi files like this: My proposal would be to instead create a
>>>> meson-gxl-gxm.dtsi, that meson-gxl.dtsi and meson-gxm.dtsi can inherit
>>>> the current common parts from, then the Mali bits can simply go into
>>>> meson-gxl.dtsi without extra #includes needed in S905X and S905D. While
>>>> it's slightly more work to split once again, I think it would be cleaner.
> [...]
>>> The only changes are :
> [...]
>>>  - A different Mali core, but with the same interrupts (less but they share the same lower interrupts), clocks and memory space
>>>
>>> This is why it was decided to have a sub-dtsi, having a secondary dtsi will simply copy 99% of the GXL dtsi,
>>> but surely we could also have an intermediate dtsi but for boards I'm ok with it, but less for a SoC dtsi,
>>> since it could lead to some confusion.
>>>
>>> Finally, yes I could have added the mali node to the GXL dtsi, but the midgard Mali dt-bindings are not upstream
>>> and the family is too big and recent enough to consider having stable bindings for now.
>>>
>>> Nevertheless, nothing is final, this gxl-mali.dtsi could be merged into the GXL dtsi in the future when we
>>> have proper dt-bindings and a real support of the T820 Mali on the S912.
>>>
>>> Kevin, what's your thought about this ?
>>
>> I don't have a strong preference.  I'm OK with a separate Mali .dtsi due
>> to the signficant overlap between GXL/GXM in terms of clocks, interrupts
>> etc.
>>
>> However, if the plan is to #include this from GXM .dts files, whould a
>> better name be meson-gx-mali.dtsi?
> 
> I thought the purpose was specifically to not have GXM include it
> because it uses a Midgard IP.
> 
> If you want to share the fragment with GXBB too (gx), we should rather
> use meson-gx-mali-utgard.dtsi, which would differentiate from GXM's
> Midgard while still allowing for variation on the 4xx side (e.g., 470).
> 
> Regards,
> Andreas
> 

Exact, there is no plan to include it from GXM.

I'm not fan of having meson-gx-mali-utgard.dtsi, we should still need some attributes additions for
the clocks to the mali node in the gxbb dtsi and each s905x and s905d dtsi files.
I'm not sure this is even cleaner...

Neil

[PATCH v2 3/3] ARM64: dts: meson-gx: Add MALI nodes for GXBB and GXL

[Neil Armstrong]

On 03/04/2017 01:38 PM, Andreas F?rber wrote:
> Am 03.03.2017 um 20:29 schrieb Kevin Hilman:
>> Neil Armstrong <narmstrong@baylibre.com> writes:
>>> On 03/02/2017 01:31 PM, Andreas F?rber wrote:
>>>> Am 01.03.2017 um 11:46 schrieb Neil Armstrong:
>>>>> The same MALI-450 MP3 GPU is present in the GXBB and GXL SoCs.
> [...]
>>>>> The node is simply added in the meson-gxbb.dtsi file.
> [...]
>>>>> For GXL, since a lot is shared with the GXM that has a MALI-T820 IP, this
>>>>> patch adds a new meson-gxl-mali.dtsi and is included in the SoC specific
>>>>> dtsi files.
>>>>
>>>> This part is slightly confusing though.
>>>>
>>>> What exactly is the GXL vs. GXM difference that this can't be handled by
>>>> overriding node properties compatible/interrupts/clocks? I am missing a
>>>> GXM patch in this series as rationale for doing it this way.
>>>>
>>>> In particular I am wondering whether the whole GXM-inherits-from-GXL
>>>> concept is flawed and should be adjusted if this leads to secondary
>>>> .dtsi files like this: My proposal would be to instead create a
>>>> meson-gxl-gxm.dtsi, that meson-gxl.dtsi and meson-gxm.dtsi can inherit
>>>> the current common parts from, then the Mali bits can simply go into
>>>> meson-gxl.dtsi without extra #includes needed in S905X and S905D. While
>>>> it's slightly more work to split once again, I think it would be cleaner.
> [...]
>>> The only changes are :
> [...]
>>>  - A different Mali core, but with the same interrupts (less but they share the same lower interrupts), clocks and memory space
>>>
>>> This is why it was decided to have a sub-dtsi, having a secondary dtsi will simply copy 99% of the GXL dtsi,
>>> but surely we could also have an intermediate dtsi but for boards I'm ok with it, but less for a SoC dtsi,
>>> since it could lead to some confusion.
>>>
>>> Finally, yes I could have added the mali node to the GXL dtsi, but the midgard Mali dt-bindings are not upstream
>>> and the family is too big and recent enough to consider having stable bindings for now.
>>>
>>> Nevertheless, nothing is final, this gxl-mali.dtsi could be merged into the GXL dtsi in the future when we
>>> have proper dt-bindings and a real support of the T820 Mali on the S912.
>>>
>>> Kevin, what's your thought about this ?
>>
>> I don't have a strong preference.  I'm OK with a separate Mali .dtsi due
>> to the signficant overlap between GXL/GXM in terms of clocks, interrupts
>> etc.
>>
>> However, if the plan is to #include this from GXM .dts files, whould a
>> better name be meson-gx-mali.dtsi?
> 
> I thought the purpose was specifically to not have GXM include it
> because it uses a Midgard IP.
> 
> If you want to share the fragment with GXBB too (gx), we should rather
> use meson-gx-mali-utgard.dtsi, which would differentiate from GXM's
> Midgard while still allowing for variation on the 4xx side (e.g., 470).
> 
> Regards,
> Andreas
> 

Exact, there is no plan to include it from GXM.

I'm not fan of having meson-gx-mali-utgard.dtsi, we should still need some attributes additions for
the clocks to the mali node in the gxbb dtsi and each s905x and s905d dtsi files.
I'm not sure this is even cleaner...

Neil

Re: [PATCH v2 3/3] ARM64: dts: meson-gx: Add MALI nodes for GXBB and GXL

[Kevin Hilman]

Neil Armstrong <narmstrong@baylibre.com> writes:

> On 03/04/2017 01:38 PM, Andreas Färber wrote:
>> Am 03.03.2017 um 20:29 schrieb Kevin Hilman:
>>> Neil Armstrong <narmstrong@baylibre.com> writes:
>>>> On 03/02/2017 01:31 PM, Andreas Färber wrote:
>>>>> Am 01.03.2017 um 11:46 schrieb Neil Armstrong:
>>>>>> The same MALI-450 MP3 GPU is present in the GXBB and GXL SoCs.
>> [...]
>>>>>> The node is simply added in the meson-gxbb.dtsi file.
>> [...]
>>>>>> For GXL, since a lot is shared with the GXM that has a MALI-T820 IP, this
>>>>>> patch adds a new meson-gxl-mali.dtsi and is included in the SoC specific
>>>>>> dtsi files.
>>>>>
>>>>> This part is slightly confusing though.
>>>>>
>>>>> What exactly is the GXL vs. GXM difference that this can't be handled by
>>>>> overriding node properties compatible/interrupts/clocks? I am missing a
>>>>> GXM patch in this series as rationale for doing it this way.
>>>>>
>>>>> In particular I am wondering whether the whole GXM-inherits-from-GXL
>>>>> concept is flawed and should be adjusted if this leads to secondary
>>>>> .dtsi files like this: My proposal would be to instead create a
>>>>> meson-gxl-gxm.dtsi, that meson-gxl.dtsi and meson-gxm.dtsi can inherit
>>>>> the current common parts from, then the Mali bits can simply go into
>>>>> meson-gxl.dtsi without extra #includes needed in S905X and S905D. While
>>>>> it's slightly more work to split once again, I think it would be cleaner.
>> [...]
>>>> The only changes are :
>> [...]
>>>>  - A different Mali core, but with the same interrupts (less but they share the same lower interrupts), clocks and memory space
>>>>
>>>> This is why it was decided to have a sub-dtsi, having a secondary dtsi will simply copy 99% of the GXL dtsi,
>>>> but surely we could also have an intermediate dtsi but for boards I'm ok with it, but less for a SoC dtsi,
>>>> since it could lead to some confusion.
>>>>
>>>> Finally, yes I could have added the mali node to the GXL dtsi, but the midgard Mali dt-bindings are not upstream
>>>> and the family is too big and recent enough to consider having stable bindings for now.
>>>>
>>>> Nevertheless, nothing is final, this gxl-mali.dtsi could be merged into the GXL dtsi in the future when we
>>>> have proper dt-bindings and a real support of the T820 Mali on the S912.
>>>>
>>>> Kevin, what's your thought about this ?
>>>
>>> I don't have a strong preference.  I'm OK with a separate Mali .dtsi due
>>> to the signficant overlap between GXL/GXM in terms of clocks, interrupts
>>> etc.
>>>
>>> However, if the plan is to #include this from GXM .dts files, whould a
>>> better name be meson-gx-mali.dtsi?
>> 
>> I thought the purpose was specifically to not have GXM include it
>> because it uses a Midgard IP.
>> 
>> If you want to share the fragment with GXBB too (gx), we should rather
>> use meson-gx-mali-utgard.dtsi, which would differentiate from GXM's
>> Midgard while still allowing for variation on the 4xx side (e.g., 470).
>> 
>> Regards,
>> Andreas
>> 
>
> Exact, there is no plan to include it from GXM.
>
> I'm not fan of having meson-gx-mali-utgard.dtsi, we should still need some attributes additions for
> the clocks to the mali node in the gxbb dtsi and each s905x and s905d dtsi files.
> I'm not sure this is even cleaner...

OK, I misunderstood the intent of having it separated from out from the
GXL .dsti then.  Could you please clarify?

Kevin

Re: [PATCH v2 3/3] ARM64: dts: meson-gx: Add MALI nodes for GXBB and GXL

[Kevin Hilman]

Neil Armstrong <narmstrong@baylibre.com> writes:

> On 03/04/2017 01:38 PM, Andreas Färber wrote:
>> Am 03.03.2017 um 20:29 schrieb Kevin Hilman:
>>> Neil Armstrong <narmstrong@baylibre.com> writes:
>>>> On 03/02/2017 01:31 PM, Andreas Färber wrote:
>>>>> Am 01.03.2017 um 11:46 schrieb Neil Armstrong:
>>>>>> The same MALI-450 MP3 GPU is present in the GXBB and GXL SoCs.
>> [...]
>>>>>> The node is simply added in the meson-gxbb.dtsi file.
>> [...]
>>>>>> For GXL, since a lot is shared with the GXM that has a MALI-T820 IP, this
>>>>>> patch adds a new meson-gxl-mali.dtsi and is included in the SoC specific
>>>>>> dtsi files.
>>>>>
>>>>> This part is slightly confusing though.
>>>>>
>>>>> What exactly is the GXL vs. GXM difference that this can't be handled by
>>>>> overriding node properties compatible/interrupts/clocks? I am missing a
>>>>> GXM patch in this series as rationale for doing it this way.
>>>>>
>>>>> In particular I am wondering whether the whole GXM-inherits-from-GXL
>>>>> concept is flawed and should be adjusted if this leads to secondary
>>>>> .dtsi files like this: My proposal would be to instead create a
>>>>> meson-gxl-gxm.dtsi, that meson-gxl.dtsi and meson-gxm.dtsi can inherit
>>>>> the current common parts from, then the Mali bits can simply go into
>>>>> meson-gxl.dtsi without extra #includes needed in S905X and S905D. While
>>>>> it's slightly more work to split once again, I think it would be cleaner.
>> [...]
>>>> The only changes are :
>> [...]
>>>>  - A different Mali core, but with the same interrupts (less but they share the same lower interrupts), clocks and memory space
>>>>
>>>> This is why it was decided to have a sub-dtsi, having a secondary dtsi will simply copy 99% of the GXL dtsi,
>>>> but surely we could also have an intermediate dtsi but for boards I'm ok with it, but less for a SoC dtsi,
>>>> since it could lead to some confusion.
>>>>
>>>> Finally, yes I could have added the mali node to the GXL dtsi, but the midgard Mali dt-bindings are not upstream
>>>> and the family is too big and recent enough to consider having stable bindings for now.
>>>>
>>>> Nevertheless, nothing is final, this gxl-mali.dtsi could be merged into the GXL dtsi in the future when we
>>>> have proper dt-bindings and a real support of the T820 Mali on the S912.
>>>>
>>>> Kevin, what's your thought about this ?
>>>
>>> I don't have a strong preference.  I'm OK with a separate Mali .dtsi due
>>> to the signficant overlap between GXL/GXM in terms of clocks, interrupts
>>> etc.
>>>
>>> However, if the plan is to #include this from GXM .dts files, whould a
>>> better name be meson-gx-mali.dtsi?
>> 
>> I thought the purpose was specifically to not have GXM include it
>> because it uses a Midgard IP.
>> 
>> If you want to share the fragment with GXBB too (gx), we should rather
>> use meson-gx-mali-utgard.dtsi, which would differentiate from GXM's
>> Midgard while still allowing for variation on the 4xx side (e.g., 470).
>> 
>> Regards,
>> Andreas
>> 
>
> Exact, there is no plan to include it from GXM.
>
> I'm not fan of having meson-gx-mali-utgard.dtsi, we should still need some attributes additions for
> the clocks to the mali node in the gxbb dtsi and each s905x and s905d dtsi files.
> I'm not sure this is even cleaner...

OK, I misunderstood the intent of having it separated from out from the
GXL .dsti then.  Could you please clarify?

Kevin




_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v2 3/3] ARM64: dts: meson-gx: Add MALI nodes for GXBB and GXL

[Kevin Hilman]

TmVpbCBBcm1zdHJvbmcgPG5hcm1zdHJvbmdAYmF5bGlicmUuY29tPiB3cml0ZXM6Cgo+IE9uIDAz
LzA0LzIwMTcgMDE6MzggUE0sIEFuZHJlYXMgRsOkcmJlciB3cm90ZToKPj4gQW0gMDMuMDMuMjAx
NyB1bSAyMDoyOSBzY2hyaWViIEtldmluIEhpbG1hbjoKPj4+IE5laWwgQXJtc3Ryb25nIDxuYXJt
c3Ryb25nQGJheWxpYnJlLmNvbT4gd3JpdGVzOgo+Pj4+IE9uIDAzLzAyLzIwMTcgMDE6MzEgUE0s
IEFuZHJlYXMgRsOkcmJlciB3cm90ZToKPj4+Pj4gQW0gMDEuMDMuMjAxNyB1bSAxMTo0NiBzY2hy
aWViIE5laWwgQXJtc3Ryb25nOgo+Pj4+Pj4gVGhlIHNhbWUgTUFMSS00NTAgTVAzIEdQVSBpcyBw
cmVzZW50IGluIHRoZSBHWEJCIGFuZCBHWEwgU29Dcy4KPj4gWy4uLl0KPj4+Pj4+IFRoZSBub2Rl
IGlzIHNpbXBseSBhZGRlZCBpbiB0aGUgbWVzb24tZ3hiYi5kdHNpIGZpbGUuCj4+IFsuLi5dCj4+
Pj4+PiBGb3IgR1hMLCBzaW5jZSBhIGxvdCBpcyBzaGFyZWQgd2l0aCB0aGUgR1hNIHRoYXQgaGFz
IGEgTUFMSS1UODIwIElQLCB0aGlzCj4+Pj4+PiBwYXRjaCBhZGRzIGEgbmV3IG1lc29uLWd4bC1t
YWxpLmR0c2kgYW5kIGlzIGluY2x1ZGVkIGluIHRoZSBTb0Mgc3BlY2lmaWMKPj4+Pj4+IGR0c2kg
ZmlsZXMuCj4+Pj4+Cj4+Pj4+IFRoaXMgcGFydCBpcyBzbGlnaHRseSBjb25mdXNpbmcgdGhvdWdo
Lgo+Pj4+Pgo+Pj4+PiBXaGF0IGV4YWN0bHkgaXMgdGhlIEdYTCB2cy4gR1hNIGRpZmZlcmVuY2Ug
dGhhdCB0aGlzIGNhbid0IGJlIGhhbmRsZWQgYnkKPj4+Pj4gb3ZlcnJpZGluZyBub2RlIHByb3Bl
cnRpZXMgY29tcGF0aWJsZS9pbnRlcnJ1cHRzL2Nsb2Nrcz8gSSBhbSBtaXNzaW5nIGEKPj4+Pj4g
R1hNIHBhdGNoIGluIHRoaXMgc2VyaWVzIGFzIHJhdGlvbmFsZSBmb3IgZG9pbmcgaXQgdGhpcyB3
YXkuCj4+Pj4+Cj4+Pj4+IEluIHBhcnRpY3VsYXIgSSBhbSB3b25kZXJpbmcgd2hldGhlciB0aGUg
d2hvbGUgR1hNLWluaGVyaXRzLWZyb20tR1hMCj4+Pj4+IGNvbmNlcHQgaXMgZmxhd2VkIGFuZCBz
aG91bGQgYmUgYWRqdXN0ZWQgaWYgdGhpcyBsZWFkcyB0byBzZWNvbmRhcnkKPj4+Pj4gLmR0c2kg
ZmlsZXMgbGlrZSB0aGlzOiBNeSBwcm9wb3NhbCB3b3VsZCBiZSB0byBpbnN0ZWFkIGNyZWF0ZSBh
Cj4+Pj4+IG1lc29uLWd4bC1neG0uZHRzaSwgdGhhdCBtZXNvbi1neGwuZHRzaSBhbmQgbWVzb24t
Z3htLmR0c2kgY2FuIGluaGVyaXQKPj4+Pj4gdGhlIGN1cnJlbnQgY29tbW9uIHBhcnRzIGZyb20s
IHRoZW4gdGhlIE1hbGkgYml0cyBjYW4gc2ltcGx5IGdvIGludG8KPj4+Pj4gbWVzb24tZ3hsLmR0
c2kgd2l0aG91dCBleHRyYSAjaW5jbHVkZXMgbmVlZGVkIGluIFM5MDVYIGFuZCBTOTA1RC4gV2hp
bGUKPj4+Pj4gaXQncyBzbGlnaHRseSBtb3JlIHdvcmsgdG8gc3BsaXQgb25jZSBhZ2FpbiwgSSB0
aGluayBpdCB3b3VsZCBiZSBjbGVhbmVyLgo+PiBbLi4uXQo+Pj4+IFRoZSBvbmx5IGNoYW5nZXMg
YXJlIDoKPj4gWy4uLl0KPj4+PiAgLSBBIGRpZmZlcmVudCBNYWxpIGNvcmUsIGJ1dCB3aXRoIHRo
ZSBzYW1lIGludGVycnVwdHMgKGxlc3MgYnV0IHRoZXkgc2hhcmUgdGhlIHNhbWUgbG93ZXIgaW50
ZXJydXB0cyksIGNsb2NrcyBhbmQgbWVtb3J5IHNwYWNlCj4+Pj4KPj4+PiBUaGlzIGlzIHdoeSBp
dCB3YXMgZGVjaWRlZCB0byBoYXZlIGEgc3ViLWR0c2ksIGhhdmluZyBhIHNlY29uZGFyeSBkdHNp
IHdpbGwgc2ltcGx5IGNvcHkgOTklIG9mIHRoZSBHWEwgZHRzaSwKPj4+PiBidXQgc3VyZWx5IHdl
IGNvdWxkIGFsc28gaGF2ZSBhbiBpbnRlcm1lZGlhdGUgZHRzaSBidXQgZm9yIGJvYXJkcyBJJ20g
b2sgd2l0aCBpdCwgYnV0IGxlc3MgZm9yIGEgU29DIGR0c2ksCj4+Pj4gc2luY2UgaXQgY291bGQg
bGVhZCB0byBzb21lIGNvbmZ1c2lvbi4KPj4+Pgo+Pj4+IEZpbmFsbHksIHllcyBJIGNvdWxkIGhh
dmUgYWRkZWQgdGhlIG1hbGkgbm9kZSB0byB0aGUgR1hMIGR0c2ksIGJ1dCB0aGUgbWlkZ2FyZCBN
YWxpIGR0LWJpbmRpbmdzIGFyZSBub3QgdXBzdHJlYW0KPj4+PiBhbmQgdGhlIGZhbWlseSBpcyB0
b28gYmlnIGFuZCByZWNlbnQgZW5vdWdoIHRvIGNvbnNpZGVyIGhhdmluZyBzdGFibGUgYmluZGlu
Z3MgZm9yIG5vdy4KPj4+Pgo+Pj4+IE5ldmVydGhlbGVzcywgbm90aGluZyBpcyBmaW5hbCwgdGhp
cyBneGwtbWFsaS5kdHNpIGNvdWxkIGJlIG1lcmdlZCBpbnRvIHRoZSBHWEwgZHRzaSBpbiB0aGUg
ZnV0dXJlIHdoZW4gd2UKPj4+PiBoYXZlIHByb3BlciBkdC1iaW5kaW5ncyBhbmQgYSByZWFsIHN1
cHBvcnQgb2YgdGhlIFQ4MjAgTWFsaSBvbiB0aGUgUzkxMi4KPj4+Pgo+Pj4+IEtldmluLCB3aGF0
J3MgeW91ciB0aG91Z2h0IGFib3V0IHRoaXMgPwo+Pj4KPj4+IEkgZG9uJ3QgaGF2ZSBhIHN0cm9u
ZyBwcmVmZXJlbmNlLiAgSSdtIE9LIHdpdGggYSBzZXBhcmF0ZSBNYWxpIC5kdHNpIGR1ZQo+Pj4g
dG8gdGhlIHNpZ25maWNhbnQgb3ZlcmxhcCBiZXR3ZWVuIEdYTC9HWE0gaW4gdGVybXMgb2YgY2xv
Y2tzLCBpbnRlcnJ1cHRzCj4+PiBldGMuCj4+Pgo+Pj4gSG93ZXZlciwgaWYgdGhlIHBsYW4gaXMg
dG8gI2luY2x1ZGUgdGhpcyBmcm9tIEdYTSAuZHRzIGZpbGVzLCB3aG91bGQgYQo+Pj4gYmV0dGVy
IG5hbWUgYmUgbWVzb24tZ3gtbWFsaS5kdHNpPwo+PiAKPj4gSSB0aG91Z2h0IHRoZSBwdXJwb3Nl
IHdhcyBzcGVjaWZpY2FsbHkgdG8gbm90IGhhdmUgR1hNIGluY2x1ZGUgaXQKPj4gYmVjYXVzZSBp
dCB1c2VzIGEgTWlkZ2FyZCBJUC4KPj4gCj4+IElmIHlvdSB3YW50IHRvIHNoYXJlIHRoZSBmcmFn
bWVudCB3aXRoIEdYQkIgdG9vIChneCksIHdlIHNob3VsZCByYXRoZXIKPj4gdXNlIG1lc29uLWd4
LW1hbGktdXRnYXJkLmR0c2ksIHdoaWNoIHdvdWxkIGRpZmZlcmVudGlhdGUgZnJvbSBHWE0ncwo+
PiBNaWRnYXJkIHdoaWxlIHN0aWxsIGFsbG93aW5nIGZvciB2YXJpYXRpb24gb24gdGhlIDR4eCBz
aWRlIChlLmcuLCA0NzApLgo+PiAKPj4gUmVnYXJkcywKPj4gQW5kcmVhcwo+PiAKPgo+IEV4YWN0
LCB0aGVyZSBpcyBubyBwbGFuIHRvIGluY2x1ZGUgaXQgZnJvbSBHWE0uCj4KPiBJJ20gbm90IGZh
biBvZiBoYXZpbmcgbWVzb24tZ3gtbWFsaS11dGdhcmQuZHRzaSwgd2Ugc2hvdWxkIHN0aWxsIG5l
ZWQgc29tZSBhdHRyaWJ1dGVzIGFkZGl0aW9ucyBmb3IKPiB0aGUgY2xvY2tzIHRvIHRoZSBtYWxp
IG5vZGUgaW4gdGhlIGd4YmIgZHRzaSBhbmQgZWFjaCBzOTA1eCBhbmQgczkwNWQgZHRzaSBmaWxl
cy4KPiBJJ20gbm90IHN1cmUgdGhpcyBpcyBldmVuIGNsZWFuZXIuLi4KCk9LLCBJIG1pc3VuZGVy
c3Rvb2QgdGhlIGludGVudCBvZiBoYXZpbmcgaXQgc2VwYXJhdGVkIGZyb20gb3V0IGZyb20gdGhl
CkdYTCAuZHN0aSB0aGVuLiAgQ291bGQgeW91IHBsZWFzZSBjbGFyaWZ5PwoKS2V2aW4KCgoKCl9f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCmxpbnV4LWFtbG9n
aWMgbWFpbGluZyBsaXN0CmxpbnV4LWFtbG9naWNAbGlzdHMuaW5mcmFkZWFkLm9yZwpodHRwOi8v
bGlzdHMuaW5mcmFkZWFkLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xpbnV4LWFtbG9naWMK

[PATCH v2 3/3] ARM64: dts: meson-gx: Add MALI nodes for GXBB and GXL

[Kevin Hilman]

Neil Armstrong <narmstrong@baylibre.com> writes:

> On 03/04/2017 01:38 PM, Andreas F?rber wrote:
>> Am 03.03.2017 um 20:29 schrieb Kevin Hilman:
>>> Neil Armstrong <narmstrong@baylibre.com> writes:
>>>> On 03/02/2017 01:31 PM, Andreas F?rber wrote:
>>>>> Am 01.03.2017 um 11:46 schrieb Neil Armstrong:
>>>>>> The same MALI-450 MP3 GPU is present in the GXBB and GXL SoCs.
>> [...]
>>>>>> The node is simply added in the meson-gxbb.dtsi file.
>> [...]
>>>>>> For GXL, since a lot is shared with the GXM that has a MALI-T820 IP, this
>>>>>> patch adds a new meson-gxl-mali.dtsi and is included in the SoC specific
>>>>>> dtsi files.
>>>>>
>>>>> This part is slightly confusing though.
>>>>>
>>>>> What exactly is the GXL vs. GXM difference that this can't be handled by
>>>>> overriding node properties compatible/interrupts/clocks? I am missing a
>>>>> GXM patch in this series as rationale for doing it this way.
>>>>>
>>>>> In particular I am wondering whether the whole GXM-inherits-from-GXL
>>>>> concept is flawed and should be adjusted if this leads to secondary
>>>>> .dtsi files like this: My proposal would be to instead create a
>>>>> meson-gxl-gxm.dtsi, that meson-gxl.dtsi and meson-gxm.dtsi can inherit
>>>>> the current common parts from, then the Mali bits can simply go into
>>>>> meson-gxl.dtsi without extra #includes needed in S905X and S905D. While
>>>>> it's slightly more work to split once again, I think it would be cleaner.
>> [...]
>>>> The only changes are :
>> [...]
>>>>  - A different Mali core, but with the same interrupts (less but they share the same lower interrupts), clocks and memory space
>>>>
>>>> This is why it was decided to have a sub-dtsi, having a secondary dtsi will simply copy 99% of the GXL dtsi,
>>>> but surely we could also have an intermediate dtsi but for boards I'm ok with it, but less for a SoC dtsi,
>>>> since it could lead to some confusion.
>>>>
>>>> Finally, yes I could have added the mali node to the GXL dtsi, but the midgard Mali dt-bindings are not upstream
>>>> and the family is too big and recent enough to consider having stable bindings for now.
>>>>
>>>> Nevertheless, nothing is final, this gxl-mali.dtsi could be merged into the GXL dtsi in the future when we
>>>> have proper dt-bindings and a real support of the T820 Mali on the S912.
>>>>
>>>> Kevin, what's your thought about this ?
>>>
>>> I don't have a strong preference.  I'm OK with a separate Mali .dtsi due
>>> to the signficant overlap between GXL/GXM in terms of clocks, interrupts
>>> etc.
>>>
>>> However, if the plan is to #include this from GXM .dts files, whould a
>>> better name be meson-gx-mali.dtsi?
>> 
>> I thought the purpose was specifically to not have GXM include it
>> because it uses a Midgard IP.
>> 
>> If you want to share the fragment with GXBB too (gx), we should rather
>> use meson-gx-mali-utgard.dtsi, which would differentiate from GXM's
>> Midgard while still allowing for variation on the 4xx side (e.g., 470).
>> 
>> Regards,
>> Andreas
>> 
>
> Exact, there is no plan to include it from GXM.
>
> I'm not fan of having meson-gx-mali-utgard.dtsi, we should still need some attributes additions for
> the clocks to the mali node in the gxbb dtsi and each s905x and s905d dtsi files.
> I'm not sure this is even cleaner...

OK, I misunderstood the intent of having it separated from out from the
GXL .dsti then.  Could you please clarify?

Kevin

[PATCH v2 3/3] ARM64: dts: meson-gx: Add MALI nodes for GXBB and GXL

[Kevin Hilman]

Neil Armstrong <narmstrong@baylibre.com> writes:

> On 03/04/2017 01:38 PM, Andreas F?rber wrote:
>> Am 03.03.2017 um 20:29 schrieb Kevin Hilman:
>>> Neil Armstrong <narmstrong@baylibre.com> writes:
>>>> On 03/02/2017 01:31 PM, Andreas F?rber wrote:
>>>>> Am 01.03.2017 um 11:46 schrieb Neil Armstrong:
>>>>>> The same MALI-450 MP3 GPU is present in the GXBB and GXL SoCs.
>> [...]
>>>>>> The node is simply added in the meson-gxbb.dtsi file.
>> [...]
>>>>>> For GXL, since a lot is shared with the GXM that has a MALI-T820 IP, this
>>>>>> patch adds a new meson-gxl-mali.dtsi and is included in the SoC specific
>>>>>> dtsi files.
>>>>>
>>>>> This part is slightly confusing though.
>>>>>
>>>>> What exactly is the GXL vs. GXM difference that this can't be handled by
>>>>> overriding node properties compatible/interrupts/clocks? I am missing a
>>>>> GXM patch in this series as rationale for doing it this way.
>>>>>
>>>>> In particular I am wondering whether the whole GXM-inherits-from-GXL
>>>>> concept is flawed and should be adjusted if this leads to secondary
>>>>> .dtsi files like this: My proposal would be to instead create a
>>>>> meson-gxl-gxm.dtsi, that meson-gxl.dtsi and meson-gxm.dtsi can inherit
>>>>> the current common parts from, then the Mali bits can simply go into
>>>>> meson-gxl.dtsi without extra #includes needed in S905X and S905D. While
>>>>> it's slightly more work to split once again, I think it would be cleaner.
>> [...]
>>>> The only changes are :
>> [...]
>>>>  - A different Mali core, but with the same interrupts (less but they share the same lower interrupts), clocks and memory space
>>>>
>>>> This is why it was decided to have a sub-dtsi, having a secondary dtsi will simply copy 99% of the GXL dtsi,
>>>> but surely we could also have an intermediate dtsi but for boards I'm ok with it, but less for a SoC dtsi,
>>>> since it could lead to some confusion.
>>>>
>>>> Finally, yes I could have added the mali node to the GXL dtsi, but the midgard Mali dt-bindings are not upstream
>>>> and the family is too big and recent enough to consider having stable bindings for now.
>>>>
>>>> Nevertheless, nothing is final, this gxl-mali.dtsi could be merged into the GXL dtsi in the future when we
>>>> have proper dt-bindings and a real support of the T820 Mali on the S912.
>>>>
>>>> Kevin, what's your thought about this ?
>>>
>>> I don't have a strong preference.  I'm OK with a separate Mali .dtsi due
>>> to the signficant overlap between GXL/GXM in terms of clocks, interrupts
>>> etc.
>>>
>>> However, if the plan is to #include this from GXM .dts files, whould a
>>> better name be meson-gx-mali.dtsi?
>> 
>> I thought the purpose was specifically to not have GXM include it
>> because it uses a Midgard IP.
>> 
>> If you want to share the fragment with GXBB too (gx), we should rather
>> use meson-gx-mali-utgard.dtsi, which would differentiate from GXM's
>> Midgard while still allowing for variation on the 4xx side (e.g., 470).
>> 
>> Regards,
>> Andreas
>> 
>
> Exact, there is no plan to include it from GXM.
>
> I'm not fan of having meson-gx-mali-utgard.dtsi, we should still need some attributes additions for
> the clocks to the mali node in the gxbb dtsi and each s905x and s905d dtsi files.
> I'm not sure this is even cleaner...

OK, I misunderstood the intent of having it separated from out from the
GXL .dsti then.  Could you please clarify?

Kevin

Re: [PATCH v2 3/3] ARM64: dts: meson-gx: Add MALI nodes for GXBB and GXL

[Neil Armstrong]

On 03/06/2017 06:27 PM, Kevin Hilman wrote:
> Neil Armstrong <narmstrong@baylibre.com> writes:
> 
>> On 03/04/2017 01:38 PM, Andreas Färber wrote:
>>> Am 03.03.2017 um 20:29 schrieb Kevin Hilman:
>>>> Neil Armstrong <narmstrong@baylibre.com> writes:
>>>>> On 03/02/2017 01:31 PM, Andreas Färber wrote:
>>>>>> Am 01.03.2017 um 11:46 schrieb Neil Armstrong:
>>>>>>> The same MALI-450 MP3 GPU is present in the GXBB and GXL SoCs.
>>> [...]
>>>>>>> The node is simply added in the meson-gxbb.dtsi file.
>>> [...]
>>>>>>> For GXL, since a lot is shared with the GXM that has a MALI-T820 IP, this
>>>>>>> patch adds a new meson-gxl-mali.dtsi and is included in the SoC specific
>>>>>>> dtsi files.
>>>>>>
>>>>>> This part is slightly confusing though.
>>>>>>
>>>>>> What exactly is the GXL vs. GXM difference that this can't be handled by
>>>>>> overriding node properties compatible/interrupts/clocks? I am missing a
>>>>>> GXM patch in this series as rationale for doing it this way.
>>>>>>
>>>>>> In particular I am wondering whether the whole GXM-inherits-from-GXL
>>>>>> concept is flawed and should be adjusted if this leads to secondary
>>>>>> .dtsi files like this: My proposal would be to instead create a
>>>>>> meson-gxl-gxm.dtsi, that meson-gxl.dtsi and meson-gxm.dtsi can inherit
>>>>>> the current common parts from, then the Mali bits can simply go into
>>>>>> meson-gxl.dtsi without extra #includes needed in S905X and S905D. While
>>>>>> it's slightly more work to split once again, I think it would be cleaner.
>>> [...]
>>>>> The only changes are :
>>> [...]
>>>>>  - A different Mali core, but with the same interrupts (less but they share the same lower interrupts), clocks and memory space
>>>>>
>>>>> This is why it was decided to have a sub-dtsi, having a secondary dtsi will simply copy 99% of the GXL dtsi,
>>>>> but surely we could also have an intermediate dtsi but for boards I'm ok with it, but less for a SoC dtsi,
>>>>> since it could lead to some confusion.
>>>>>
>>>>> Finally, yes I could have added the mali node to the GXL dtsi, but the midgard Mali dt-bindings are not upstream
>>>>> and the family is too big and recent enough to consider having stable bindings for now.
>>>>>
>>>>> Nevertheless, nothing is final, this gxl-mali.dtsi could be merged into the GXL dtsi in the future when we
>>>>> have proper dt-bindings and a real support of the T820 Mali on the S912.
>>>>>
>>>>> Kevin, what's your thought about this ?
>>>>
>>>> I don't have a strong preference.  I'm OK with a separate Mali .dtsi due
>>>> to the signficant overlap between GXL/GXM in terms of clocks, interrupts
>>>> etc.
>>>>
>>>> However, if the plan is to #include this from GXM .dts files, whould a
>>>> better name be meson-gx-mali.dtsi?
>>>
>>> I thought the purpose was specifically to not have GXM include it
>>> because it uses a Midgard IP.
>>>
>>> If you want to share the fragment with GXBB too (gx), we should rather
>>> use meson-gx-mali-utgard.dtsi, which would differentiate from GXM's
>>> Midgard while still allowing for variation on the 4xx side (e.g., 470).
>>>
>>> Regards,
>>> Andreas
>>>
>>
>> Exact, there is no plan to include it from GXM.
>>
>> I'm not fan of having meson-gx-mali-utgard.dtsi, we should still need some attributes additions for
>> the clocks to the mali node in the gxbb dtsi and each s905x and s905d dtsi files.
>> I'm not sure this is even cleaner...
> 
> OK, I misunderstood the intent of having it separated from out from the
> GXL .dsti then.  Could you please clarify?
> 
> Kevin

Hi,

Indeed, my changelog was not really clear, here is the reworded one that will land in v2 :
"
This patch add nodes for the Mali-450 MP3 GPU present in the GXBB and GXL SoCs.

For GXBB, the node is simply added in the meson-gxbb.dtsi file.

Fox GXL, since the GXM dtsi is a superset of the GXL dtsi, the Mali node is added to
the GXL SoC specific dtsi files via an intermediate "meson-gxl-mali.dtsi" file to avoid
having an invalid Mali-450 node in the GXM device tree.
"

Thanks,
Neil

Re: [PATCH v2 3/3] ARM64: dts: meson-gx: Add MALI nodes for GXBB and GXL

[Neil Armstrong]

T24gMDMvMDYvMjAxNyAwNjoyNyBQTSwgS2V2aW4gSGlsbWFuIHdyb3RlOgo+IE5laWwgQXJtc3Ry
b25nIDxuYXJtc3Ryb25nQGJheWxpYnJlLmNvbT4gd3JpdGVzOgo+IAo+PiBPbiAwMy8wNC8yMDE3
IDAxOjM4IFBNLCBBbmRyZWFzIEbDpHJiZXIgd3JvdGU6Cj4+PiBBbSAwMy4wMy4yMDE3IHVtIDIw
OjI5IHNjaHJpZWIgS2V2aW4gSGlsbWFuOgo+Pj4+IE5laWwgQXJtc3Ryb25nIDxuYXJtc3Ryb25n
QGJheWxpYnJlLmNvbT4gd3JpdGVzOgo+Pj4+PiBPbiAwMy8wMi8yMDE3IDAxOjMxIFBNLCBBbmRy
ZWFzIEbDpHJiZXIgd3JvdGU6Cj4+Pj4+PiBBbSAwMS4wMy4yMDE3IHVtIDExOjQ2IHNjaHJpZWIg
TmVpbCBBcm1zdHJvbmc6Cj4+Pj4+Pj4gVGhlIHNhbWUgTUFMSS00NTAgTVAzIEdQVSBpcyBwcmVz
ZW50IGluIHRoZSBHWEJCIGFuZCBHWEwgU29Dcy4KPj4+IFsuLi5dCj4+Pj4+Pj4gVGhlIG5vZGUg
aXMgc2ltcGx5IGFkZGVkIGluIHRoZSBtZXNvbi1neGJiLmR0c2kgZmlsZS4KPj4+IFsuLi5dCj4+
Pj4+Pj4gRm9yIEdYTCwgc2luY2UgYSBsb3QgaXMgc2hhcmVkIHdpdGggdGhlIEdYTSB0aGF0IGhh
cyBhIE1BTEktVDgyMCBJUCwgdGhpcwo+Pj4+Pj4+IHBhdGNoIGFkZHMgYSBuZXcgbWVzb24tZ3hs
LW1hbGkuZHRzaSBhbmQgaXMgaW5jbHVkZWQgaW4gdGhlIFNvQyBzcGVjaWZpYwo+Pj4+Pj4+IGR0
c2kgZmlsZXMuCj4+Pj4+Pgo+Pj4+Pj4gVGhpcyBwYXJ0IGlzIHNsaWdodGx5IGNvbmZ1c2luZyB0
aG91Z2guCj4+Pj4+Pgo+Pj4+Pj4gV2hhdCBleGFjdGx5IGlzIHRoZSBHWEwgdnMuIEdYTSBkaWZm
ZXJlbmNlIHRoYXQgdGhpcyBjYW4ndCBiZSBoYW5kbGVkIGJ5Cj4+Pj4+PiBvdmVycmlkaW5nIG5v
ZGUgcHJvcGVydGllcyBjb21wYXRpYmxlL2ludGVycnVwdHMvY2xvY2tzPyBJIGFtIG1pc3Npbmcg
YQo+Pj4+Pj4gR1hNIHBhdGNoIGluIHRoaXMgc2VyaWVzIGFzIHJhdGlvbmFsZSBmb3IgZG9pbmcg
aXQgdGhpcyB3YXkuCj4+Pj4+Pgo+Pj4+Pj4gSW4gcGFydGljdWxhciBJIGFtIHdvbmRlcmluZyB3
aGV0aGVyIHRoZSB3aG9sZSBHWE0taW5oZXJpdHMtZnJvbS1HWEwKPj4+Pj4+IGNvbmNlcHQgaXMg
Zmxhd2VkIGFuZCBzaG91bGQgYmUgYWRqdXN0ZWQgaWYgdGhpcyBsZWFkcyB0byBzZWNvbmRhcnkK
Pj4+Pj4+IC5kdHNpIGZpbGVzIGxpa2UgdGhpczogTXkgcHJvcG9zYWwgd291bGQgYmUgdG8gaW5z
dGVhZCBjcmVhdGUgYQo+Pj4+Pj4gbWVzb24tZ3hsLWd4bS5kdHNpLCB0aGF0IG1lc29uLWd4bC5k
dHNpIGFuZCBtZXNvbi1neG0uZHRzaSBjYW4gaW5oZXJpdAo+Pj4+Pj4gdGhlIGN1cnJlbnQgY29t
bW9uIHBhcnRzIGZyb20sIHRoZW4gdGhlIE1hbGkgYml0cyBjYW4gc2ltcGx5IGdvIGludG8KPj4+
Pj4+IG1lc29uLWd4bC5kdHNpIHdpdGhvdXQgZXh0cmEgI2luY2x1ZGVzIG5lZWRlZCBpbiBTOTA1
WCBhbmQgUzkwNUQuIFdoaWxlCj4+Pj4+PiBpdCdzIHNsaWdodGx5IG1vcmUgd29yayB0byBzcGxp
dCBvbmNlIGFnYWluLCBJIHRoaW5rIGl0IHdvdWxkIGJlIGNsZWFuZXIuCj4+PiBbLi4uXQo+Pj4+
PiBUaGUgb25seSBjaGFuZ2VzIGFyZSA6Cj4+PiBbLi4uXQo+Pj4+PiAgLSBBIGRpZmZlcmVudCBN
YWxpIGNvcmUsIGJ1dCB3aXRoIHRoZSBzYW1lIGludGVycnVwdHMgKGxlc3MgYnV0IHRoZXkgc2hh
cmUgdGhlIHNhbWUgbG93ZXIgaW50ZXJydXB0cyksIGNsb2NrcyBhbmQgbWVtb3J5IHNwYWNlCj4+
Pj4+Cj4+Pj4+IFRoaXMgaXMgd2h5IGl0IHdhcyBkZWNpZGVkIHRvIGhhdmUgYSBzdWItZHRzaSwg
aGF2aW5nIGEgc2Vjb25kYXJ5IGR0c2kgd2lsbCBzaW1wbHkgY29weSA5OSUgb2YgdGhlIEdYTCBk
dHNpLAo+Pj4+PiBidXQgc3VyZWx5IHdlIGNvdWxkIGFsc28gaGF2ZSBhbiBpbnRlcm1lZGlhdGUg
ZHRzaSBidXQgZm9yIGJvYXJkcyBJJ20gb2sgd2l0aCBpdCwgYnV0IGxlc3MgZm9yIGEgU29DIGR0
c2ksCj4+Pj4+IHNpbmNlIGl0IGNvdWxkIGxlYWQgdG8gc29tZSBjb25mdXNpb24uCj4+Pj4+Cj4+
Pj4+IEZpbmFsbHksIHllcyBJIGNvdWxkIGhhdmUgYWRkZWQgdGhlIG1hbGkgbm9kZSB0byB0aGUg
R1hMIGR0c2ksIGJ1dCB0aGUgbWlkZ2FyZCBNYWxpIGR0LWJpbmRpbmdzIGFyZSBub3QgdXBzdHJl
YW0KPj4+Pj4gYW5kIHRoZSBmYW1pbHkgaXMgdG9vIGJpZyBhbmQgcmVjZW50IGVub3VnaCB0byBj
b25zaWRlciBoYXZpbmcgc3RhYmxlIGJpbmRpbmdzIGZvciBub3cuCj4+Pj4+Cj4+Pj4+IE5ldmVy
dGhlbGVzcywgbm90aGluZyBpcyBmaW5hbCwgdGhpcyBneGwtbWFsaS5kdHNpIGNvdWxkIGJlIG1l
cmdlZCBpbnRvIHRoZSBHWEwgZHRzaSBpbiB0aGUgZnV0dXJlIHdoZW4gd2UKPj4+Pj4gaGF2ZSBw
cm9wZXIgZHQtYmluZGluZ3MgYW5kIGEgcmVhbCBzdXBwb3J0IG9mIHRoZSBUODIwIE1hbGkgb24g
dGhlIFM5MTIuCj4+Pj4+Cj4+Pj4+IEtldmluLCB3aGF0J3MgeW91ciB0aG91Z2h0IGFib3V0IHRo
aXMgPwo+Pj4+Cj4+Pj4gSSBkb24ndCBoYXZlIGEgc3Ryb25nIHByZWZlcmVuY2UuICBJJ20gT0sg
d2l0aCBhIHNlcGFyYXRlIE1hbGkgLmR0c2kgZHVlCj4+Pj4gdG8gdGhlIHNpZ25maWNhbnQgb3Zl
cmxhcCBiZXR3ZWVuIEdYTC9HWE0gaW4gdGVybXMgb2YgY2xvY2tzLCBpbnRlcnJ1cHRzCj4+Pj4g
ZXRjLgo+Pj4+Cj4+Pj4gSG93ZXZlciwgaWYgdGhlIHBsYW4gaXMgdG8gI2luY2x1ZGUgdGhpcyBm
cm9tIEdYTSAuZHRzIGZpbGVzLCB3aG91bGQgYQo+Pj4+IGJldHRlciBuYW1lIGJlIG1lc29uLWd4
LW1hbGkuZHRzaT8KPj4+Cj4+PiBJIHRob3VnaHQgdGhlIHB1cnBvc2Ugd2FzIHNwZWNpZmljYWxs
eSB0byBub3QgaGF2ZSBHWE0gaW5jbHVkZSBpdAo+Pj4gYmVjYXVzZSBpdCB1c2VzIGEgTWlkZ2Fy
ZCBJUC4KPj4+Cj4+PiBJZiB5b3Ugd2FudCB0byBzaGFyZSB0aGUgZnJhZ21lbnQgd2l0aCBHWEJC
IHRvbyAoZ3gpLCB3ZSBzaG91bGQgcmF0aGVyCj4+PiB1c2UgbWVzb24tZ3gtbWFsaS11dGdhcmQu
ZHRzaSwgd2hpY2ggd291bGQgZGlmZmVyZW50aWF0ZSBmcm9tIEdYTSdzCj4+PiBNaWRnYXJkIHdo
aWxlIHN0aWxsIGFsbG93aW5nIGZvciB2YXJpYXRpb24gb24gdGhlIDR4eCBzaWRlIChlLmcuLCA0
NzApLgo+Pj4KPj4+IFJlZ2FyZHMsCj4+PiBBbmRyZWFzCj4+Pgo+Pgo+PiBFeGFjdCwgdGhlcmUg
aXMgbm8gcGxhbiB0byBpbmNsdWRlIGl0IGZyb20gR1hNLgo+Pgo+PiBJJ20gbm90IGZhbiBvZiBo
YXZpbmcgbWVzb24tZ3gtbWFsaS11dGdhcmQuZHRzaSwgd2Ugc2hvdWxkIHN0aWxsIG5lZWQgc29t
ZSBhdHRyaWJ1dGVzIGFkZGl0aW9ucyBmb3IKPj4gdGhlIGNsb2NrcyB0byB0aGUgbWFsaSBub2Rl
IGluIHRoZSBneGJiIGR0c2kgYW5kIGVhY2ggczkwNXggYW5kIHM5MDVkIGR0c2kgZmlsZXMuCj4+
IEknbSBub3Qgc3VyZSB0aGlzIGlzIGV2ZW4gY2xlYW5lci4uLgo+IAo+IE9LLCBJIG1pc3VuZGVy
c3Rvb2QgdGhlIGludGVudCBvZiBoYXZpbmcgaXQgc2VwYXJhdGVkIGZyb20gb3V0IGZyb20gdGhl
Cj4gR1hMIC5kc3RpIHRoZW4uICBDb3VsZCB5b3UgcGxlYXNlIGNsYXJpZnk/Cj4gCj4gS2V2aW4K
CkhpLAoKSW5kZWVkLCBteSBjaGFuZ2Vsb2cgd2FzIG5vdCByZWFsbHkgY2xlYXIsIGhlcmUgaXMg
dGhlIHJld29yZGVkIG9uZSB0aGF0IHdpbGwgbGFuZCBpbiB2MiA6CiIKVGhpcyBwYXRjaCBhZGQg
bm9kZXMgZm9yIHRoZSBNYWxpLTQ1MCBNUDMgR1BVIHByZXNlbnQgaW4gdGhlIEdYQkIgYW5kIEdY
TCBTb0NzLgoKRm9yIEdYQkIsIHRoZSBub2RlIGlzIHNpbXBseSBhZGRlZCBpbiB0aGUgbWVzb24t
Z3hiYi5kdHNpIGZpbGUuCgpGb3ggR1hMLCBzaW5jZSB0aGUgR1hNIGR0c2kgaXMgYSBzdXBlcnNl
dCBvZiB0aGUgR1hMIGR0c2ksIHRoZSBNYWxpIG5vZGUgaXMgYWRkZWQgdG8KdGhlIEdYTCBTb0Mg
c3BlY2lmaWMgZHRzaSBmaWxlcyB2aWEgYW4gaW50ZXJtZWRpYXRlICJtZXNvbi1neGwtbWFsaS5k
dHNpIiBmaWxlIHRvIGF2b2lkCmhhdmluZyBhbiBpbnZhbGlkIE1hbGktNDUwIG5vZGUgaW4gdGhl
IEdYTSBkZXZpY2UgdHJlZS4KIgoKVGhhbmtzLApOZWlsCgpfX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fXwpsaW51eC1hbWxvZ2ljIG1haWxpbmcgbGlzdApsaW51
eC1hbWxvZ2ljQGxpc3RzLmluZnJhZGVhZC5vcmcKaHR0cDovL2xpc3RzLmluZnJhZGVhZC5vcmcv
bWFpbG1hbi9saXN0aW5mby9saW51eC1hbWxvZ2ljCg==

[PATCH v2 3/3] ARM64: dts: meson-gx: Add MALI nodes for GXBB and GXL

[Neil Armstrong]

On 03/06/2017 06:27 PM, Kevin Hilman wrote:
> Neil Armstrong <narmstrong@baylibre.com> writes:
> 
>> On 03/04/2017 01:38 PM, Andreas F?rber wrote:
>>> Am 03.03.2017 um 20:29 schrieb Kevin Hilman:
>>>> Neil Armstrong <narmstrong@baylibre.com> writes:
>>>>> On 03/02/2017 01:31 PM, Andreas F?rber wrote:
>>>>>> Am 01.03.2017 um 11:46 schrieb Neil Armstrong:
>>>>>>> The same MALI-450 MP3 GPU is present in the GXBB and GXL SoCs.
>>> [...]
>>>>>>> The node is simply added in the meson-gxbb.dtsi file.
>>> [...]
>>>>>>> For GXL, since a lot is shared with the GXM that has a MALI-T820 IP, this
>>>>>>> patch adds a new meson-gxl-mali.dtsi and is included in the SoC specific
>>>>>>> dtsi files.
>>>>>>
>>>>>> This part is slightly confusing though.
>>>>>>
>>>>>> What exactly is the GXL vs. GXM difference that this can't be handled by
>>>>>> overriding node properties compatible/interrupts/clocks? I am missing a
>>>>>> GXM patch in this series as rationale for doing it this way.
>>>>>>
>>>>>> In particular I am wondering whether the whole GXM-inherits-from-GXL
>>>>>> concept is flawed and should be adjusted if this leads to secondary
>>>>>> .dtsi files like this: My proposal would be to instead create a
>>>>>> meson-gxl-gxm.dtsi, that meson-gxl.dtsi and meson-gxm.dtsi can inherit
>>>>>> the current common parts from, then the Mali bits can simply go into
>>>>>> meson-gxl.dtsi without extra #includes needed in S905X and S905D. While
>>>>>> it's slightly more work to split once again, I think it would be cleaner.
>>> [...]
>>>>> The only changes are :
>>> [...]
>>>>>  - A different Mali core, but with the same interrupts (less but they share the same lower interrupts), clocks and memory space
>>>>>
>>>>> This is why it was decided to have a sub-dtsi, having a secondary dtsi will simply copy 99% of the GXL dtsi,
>>>>> but surely we could also have an intermediate dtsi but for boards I'm ok with it, but less for a SoC dtsi,
>>>>> since it could lead to some confusion.
>>>>>
>>>>> Finally, yes I could have added the mali node to the GXL dtsi, but the midgard Mali dt-bindings are not upstream
>>>>> and the family is too big and recent enough to consider having stable bindings for now.
>>>>>
>>>>> Nevertheless, nothing is final, this gxl-mali.dtsi could be merged into the GXL dtsi in the future when we
>>>>> have proper dt-bindings and a real support of the T820 Mali on the S912.
>>>>>
>>>>> Kevin, what's your thought about this ?
>>>>
>>>> I don't have a strong preference.  I'm OK with a separate Mali .dtsi due
>>>> to the signficant overlap between GXL/GXM in terms of clocks, interrupts
>>>> etc.
>>>>
>>>> However, if the plan is to #include this from GXM .dts files, whould a
>>>> better name be meson-gx-mali.dtsi?
>>>
>>> I thought the purpose was specifically to not have GXM include it
>>> because it uses a Midgard IP.
>>>
>>> If you want to share the fragment with GXBB too (gx), we should rather
>>> use meson-gx-mali-utgard.dtsi, which would differentiate from GXM's
>>> Midgard while still allowing for variation on the 4xx side (e.g., 470).
>>>
>>> Regards,
>>> Andreas
>>>
>>
>> Exact, there is no plan to include it from GXM.
>>
>> I'm not fan of having meson-gx-mali-utgard.dtsi, we should still need some attributes additions for
>> the clocks to the mali node in the gxbb dtsi and each s905x and s905d dtsi files.
>> I'm not sure this is even cleaner...
> 
> OK, I misunderstood the intent of having it separated from out from the
> GXL .dsti then.  Could you please clarify?
> 
> Kevin

Hi,

Indeed, my changelog was not really clear, here is the reworded one that will land in v2 :
"
This patch add nodes for the Mali-450 MP3 GPU present in the GXBB and GXL SoCs.

For GXBB, the node is simply added in the meson-gxbb.dtsi file.

Fox GXL, since the GXM dtsi is a superset of the GXL dtsi, the Mali node is added to
the GXL SoC specific dtsi files via an intermediate "meson-gxl-mali.dtsi" file to avoid
having an invalid Mali-450 node in the GXM device tree.
"

Thanks,
Neil

[PATCH v2 3/3] ARM64: dts: meson-gx: Add MALI nodes for GXBB and GXL

[Neil Armstrong]

On 03/06/2017 06:27 PM, Kevin Hilman wrote:
> Neil Armstrong <narmstrong@baylibre.com> writes:
> 
>> On 03/04/2017 01:38 PM, Andreas F?rber wrote:
>>> Am 03.03.2017 um 20:29 schrieb Kevin Hilman:
>>>> Neil Armstrong <narmstrong@baylibre.com> writes:
>>>>> On 03/02/2017 01:31 PM, Andreas F?rber wrote:
>>>>>> Am 01.03.2017 um 11:46 schrieb Neil Armstrong:
>>>>>>> The same MALI-450 MP3 GPU is present in the GXBB and GXL SoCs.
>>> [...]
>>>>>>> The node is simply added in the meson-gxbb.dtsi file.
>>> [...]
>>>>>>> For GXL, since a lot is shared with the GXM that has a MALI-T820 IP, this
>>>>>>> patch adds a new meson-gxl-mali.dtsi and is included in the SoC specific
>>>>>>> dtsi files.
>>>>>>
>>>>>> This part is slightly confusing though.
>>>>>>
>>>>>> What exactly is the GXL vs. GXM difference that this can't be handled by
>>>>>> overriding node properties compatible/interrupts/clocks? I am missing a
>>>>>> GXM patch in this series as rationale for doing it this way.
>>>>>>
>>>>>> In particular I am wondering whether the whole GXM-inherits-from-GXL
>>>>>> concept is flawed and should be adjusted if this leads to secondary
>>>>>> .dtsi files like this: My proposal would be to instead create a
>>>>>> meson-gxl-gxm.dtsi, that meson-gxl.dtsi and meson-gxm.dtsi can inherit
>>>>>> the current common parts from, then the Mali bits can simply go into
>>>>>> meson-gxl.dtsi without extra #includes needed in S905X and S905D. While
>>>>>> it's slightly more work to split once again, I think it would be cleaner.
>>> [...]
>>>>> The only changes are :
>>> [...]
>>>>>  - A different Mali core, but with the same interrupts (less but they share the same lower interrupts), clocks and memory space
>>>>>
>>>>> This is why it was decided to have a sub-dtsi, having a secondary dtsi will simply copy 99% of the GXL dtsi,
>>>>> but surely we could also have an intermediate dtsi but for boards I'm ok with it, but less for a SoC dtsi,
>>>>> since it could lead to some confusion.
>>>>>
>>>>> Finally, yes I could have added the mali node to the GXL dtsi, but the midgard Mali dt-bindings are not upstream
>>>>> and the family is too big and recent enough to consider having stable bindings for now.
>>>>>
>>>>> Nevertheless, nothing is final, this gxl-mali.dtsi could be merged into the GXL dtsi in the future when we
>>>>> have proper dt-bindings and a real support of the T820 Mali on the S912.
>>>>>
>>>>> Kevin, what's your thought about this ?
>>>>
>>>> I don't have a strong preference.  I'm OK with a separate Mali .dtsi due
>>>> to the signficant overlap between GXL/GXM in terms of clocks, interrupts
>>>> etc.
>>>>
>>>> However, if the plan is to #include this from GXM .dts files, whould a
>>>> better name be meson-gx-mali.dtsi?
>>>
>>> I thought the purpose was specifically to not have GXM include it
>>> because it uses a Midgard IP.
>>>
>>> If you want to share the fragment with GXBB too (gx), we should rather
>>> use meson-gx-mali-utgard.dtsi, which would differentiate from GXM's
>>> Midgard while still allowing for variation on the 4xx side (e.g., 470).
>>>
>>> Regards,
>>> Andreas
>>>
>>
>> Exact, there is no plan to include it from GXM.
>>
>> I'm not fan of having meson-gx-mali-utgard.dtsi, we should still need some attributes additions for
>> the clocks to the mali node in the gxbb dtsi and each s905x and s905d dtsi files.
>> I'm not sure this is even cleaner...
> 
> OK, I misunderstood the intent of having it separated from out from the
> GXL .dsti then.  Could you please clarify?
> 
> Kevin

Hi,

Indeed, my changelog was not really clear, here is the reworded one that will land in v2 :
"
This patch add nodes for the Mali-450 MP3 GPU present in the GXBB and GXL SoCs.

For GXBB, the node is simply added in the meson-gxbb.dtsi file.

Fox GXL, since the GXM dtsi is a superset of the GXL dtsi, the Mali node is added to
the GXL SoC specific dtsi files via an intermediate "meson-gxl-mali.dtsi" file to avoid
having an invalid Mali-450 node in the GXM device tree.
"

Thanks,
Neil