[PATCH v2 0/6] Introduce Allwinner A33 support

[PATCH v2 0/6] Introduce Allwinner A33 support

[Hans de Goede]

Hi Maxime,

Here is a cleaned up series of Vishnu Patekar's A33 support. This should
address all concerns raised during the posting of v1.

I've tested that all peripherals declared in the shared sun8i-a23-a33.dtsi
work on the A33 too, with the exception of the dma-controller. For the
dma-controller I've compared the A23 vs A33 manual and the entire dma-
controller description including the register description is bit for bit
identical.

This has been tested on a 7" Ippo Q8H v1.2 A23 tablet, a 7" Ippo Q8H v1.2
A33 tablet and a 10" GA10H A33 tablet. The dts for the 10" tablet still
needs some work wrt the lradc button voltages so that is not included
in this set.

Regards,

Hans

[PATCH v2 1/6] ARM: sunxi: Add Machine support for A33

[Hans de Goede]

From: Vishnu Patekar <vishnupatekar0510@gmail.com>

Add machine support for the Allwinner A33 quad core cortex-a7 based SoC,
which is similar to the A23 SoC.

Signed-off-by: Vishnu Patekar <vishnupatekar0510@gmail.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
Changes in v2:
-Do not rename the allwinner,sun8i-a23 compatible to allwinner,sun8i
 instead add a new allwinner,sun8i-a33 compatible
-Squash in changes to use sun6i_init_clocks for A33
-Do *not* rename the cpu method to "allwinner,sun8i"
---
 Documentation/devicetree/bindings/arm/sunxi.txt | 1 +
 arch/arm/mach-sunxi/sunxi.c                     | 1 +
 drivers/clk/sunxi/clk-sunxi.c                   | 1 +
 3 files changed, 3 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/sunxi.txt b/Documentation/devicetree/bindings/arm/sunxi.txt
index 3cb4b94..67da205 100644
--- a/Documentation/devicetree/bindings/arm/sunxi.txt
+++ b/Documentation/devicetree/bindings/arm/sunxi.txt
@@ -9,5 +9,6 @@ using one of the following compatible strings:
   allwinner,sun6i-a31
   allwinner,sun7i-a20
   allwinner,sun8i-a23
+  allwinner,sun8i-a33
   allwinner,sun8i-h3
   allwinner,sun9i-a80
diff --git a/arch/arm/mach-sunxi/sunxi.c b/arch/arm/mach-sunxi/sunxi.c
index 8270902..65bab28 100644
--- a/arch/arm/mach-sunxi/sunxi.c
+++ b/arch/arm/mach-sunxi/sunxi.c
@@ -67,6 +67,7 @@ MACHINE_END
 
 static const char * const sun8i_board_dt_compat[] = {
 	"allwinner,sun8i-a23",
+	"allwinner,sun8i-a33",
 	"allwinner,sun8i-h3",
 	NULL,
 };
diff --git a/drivers/clk/sunxi/clk-sunxi.c b/drivers/clk/sunxi/clk-sunxi.c
index 9a82f17..abf7b37 100644
--- a/drivers/clk/sunxi/clk-sunxi.c
+++ b/drivers/clk/sunxi/clk-sunxi.c
@@ -1391,6 +1391,7 @@ static void __init sun6i_init_clocks(struct device_node *node)
 CLK_OF_DECLARE(sun6i_a31_clk_init, "allwinner,sun6i-a31", sun6i_init_clocks);
 CLK_OF_DECLARE(sun6i_a31s_clk_init, "allwinner,sun6i-a31s", sun6i_init_clocks);
 CLK_OF_DECLARE(sun8i_a23_clk_init, "allwinner,sun8i-a23", sun6i_init_clocks);
+CLK_OF_DECLARE(sun8i_a33_clk_init, "allwinner,sun8i-a33", sun6i_init_clocks);
 
 static void __init sun9i_init_clocks(struct device_node *node)
 {
-- 
2.4.1

[PATCH v2 1/6] ARM: sunxi: Add Machine support for A33

[Maxime Ripard]

On Sat, May 30, 2015 at 04:55:01PM +0200, Hans de Goede wrote:
> From: Vishnu Patekar <vishnupatekar0510@gmail.com>
> 
> Add machine support for the Allwinner A33 quad core cortex-a7 based SoC,
> which is similar to the A23 SoC.
> 
> Signed-off-by: Vishnu Patekar <vishnupatekar0510@gmail.com>
> Signed-off-by: Hans de Goede <hdegoede@redhat.com>

Applied, thanks!

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150602/2980c4d6/attachment.sig>

[PATCH v2 2/6] pinctrl: sunxi: Add allwinner A33 PIO controller support

[Hans de Goede]

From: Vishnu Patekar <vishnupatekar0510@gmail.com>

A33 PIO has 7 ports which starts from PB and has two interrupt ports.

Signed-off-by: Vishnu Patekar <vishnupatekar0510@gmail.com>
Acked-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
 .../bindings/pinctrl/allwinner,sunxi-pinctrl.txt   |   2 +
 drivers/pinctrl/sunxi/Kconfig                      |   4 +
 drivers/pinctrl/sunxi/Makefile                     |   1 +
 drivers/pinctrl/sunxi/pinctrl-sun8i-a33.c          | 513 +++++++++++++++++++++
 4 files changed, 520 insertions(+)
 create mode 100644 drivers/pinctrl/sunxi/pinctrl-sun8i-a33.c

diff --git a/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt
index fdd8046..9462ab7 100644
--- a/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt
+++ b/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt
@@ -16,6 +16,8 @@ Required properties:
   "allwinner,sun7i-a20-pinctrl"
   "allwinner,sun8i-a23-pinctrl"
   "allwinner,sun8i-a23-r-pinctrl"
+  "allwinner,sun8i-a33-pinctrl"
+
 - reg: Should contain the register physical address and length for the
   pin controller.
 
diff --git a/drivers/pinctrl/sunxi/Kconfig b/drivers/pinctrl/sunxi/Kconfig
index 2eb893e..ae27872 100644
--- a/drivers/pinctrl/sunxi/Kconfig
+++ b/drivers/pinctrl/sunxi/Kconfig
@@ -38,6 +38,10 @@ config PINCTRL_SUN8I_A23
 	def_bool MACH_SUN8I
 	select PINCTRL_SUNXI_COMMON
 
+config PINCTRL_SUN8I_A33
+	def_bool MACH_SUN8I
+	select PINCTRL_SUNXI_COMMON
+
 config PINCTRL_SUN8I_A23_R
 	def_bool MACH_SUN8I
 	depends on RESET_CONTROLLER
diff --git a/drivers/pinctrl/sunxi/Makefile b/drivers/pinctrl/sunxi/Makefile
index b796d57..227a121 100644
--- a/drivers/pinctrl/sunxi/Makefile
+++ b/drivers/pinctrl/sunxi/Makefile
@@ -11,4 +11,5 @@ obj-$(CONFIG_PINCTRL_SUN6I_A31_R)	+= pinctrl-sun6i-a31-r.o
 obj-$(CONFIG_PINCTRL_SUN7I_A20)		+= pinctrl-sun7i-a20.o
 obj-$(CONFIG_PINCTRL_SUN8I_A23)		+= pinctrl-sun8i-a23.o
 obj-$(CONFIG_PINCTRL_SUN8I_A23_R)	+= pinctrl-sun8i-a23-r.o
+obj-$(CONFIG_PINCTRL_SUN8I_A33)		+= pinctrl-sun8i-a33.o
 obj-$(CONFIG_PINCTRL_SUN9I_A80)		+= pinctrl-sun9i-a80.o
diff --git a/drivers/pinctrl/sunxi/pinctrl-sun8i-a33.c b/drivers/pinctrl/sunxi/pinctrl-sun8i-a33.c
new file mode 100644
index 0000000..00265f0
--- /dev/null
+++ b/drivers/pinctrl/sunxi/pinctrl-sun8i-a33.c
@@ -0,0 +1,513 @@
+/*
+ * Allwinner a33 SoCs pinctrl driver.
+ *
+ * Copyright (C) 2015 Vishnu Patekar <vishnupatekar0510@gmail.com>
+ *
+ * Based on pinctrl-sun8i-a23.c, which is:
+ * Copyright (C) 2014 Chen-Yu Tsai <wens@csie.org>
+ * Copyright (C) 2014 Maxime Ripard <maxime.ripard@free-electrons.com>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2.  This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/of.h>
+#include <linux/of_device.h>
+#include <linux/pinctrl/pinctrl.h>
+
+#include "pinctrl-sunxi.h"
+
+static const struct sunxi_desc_pin sun8i_a33_pins[] = {
+	/* Hole */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(B, 0),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "uart2"),		/* TX */
+		  SUNXI_FUNCTION(0x3, "uart0"),		/* TX */
+		  SUNXI_FUNCTION_IRQ_BANK(0x4, 0, 0)),	/* PB_EINT0 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(B, 1),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "uart2"),		/* RX */
+		  SUNXI_FUNCTION(0x3, "uart0"),		/* RX */
+		  SUNXI_FUNCTION_IRQ_BANK(0x4, 0, 1)),	/* PB_EINT1 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(B, 2),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "uart2"),		/* RTS */
+		  SUNXI_FUNCTION_IRQ_BANK(0x4, 0, 2)),	/* PB_EINT2 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(B, 3),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "uart2"),		/* CTS */
+		  SUNXI_FUNCTION_IRQ_BANK(0x4, 0, 3)),	/* PB_EINT3 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(B, 4),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "i2s0"),		/* SYNC */
+		  SUNXI_FUNCTION(0x3, "aif2"),		/* SYNC */
+		  SUNXI_FUNCTION_IRQ_BANK(0x4, 0, 4)),	/* PB_EINT4 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(B, 5),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "i2s0"),		/* BCLK */
+		  SUNXI_FUNCTION(0x3, "aif2"),		/* BCLK */
+		  SUNXI_FUNCTION_IRQ_BANK(0x4, 0, 5)),	/* PB_EINT5 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(B, 6),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "i2s0"),		/* DOUT */
+		  SUNXI_FUNCTION(0x3, "aif2"),		/* DOUT */
+		  SUNXI_FUNCTION_IRQ_BANK(0x4, 0, 6)),	/* PB_EINT6 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(B, 7),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "i2s0"),		/* DIN */
+		  SUNXI_FUNCTION(0x3, "aif2"),		/* DIN */
+		  SUNXI_FUNCTION_IRQ_BANK(0x4, 0, 7)),	/* PB_EINT7 */
+	/* Hole */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 0),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "nand0"),		/* WE */
+		  SUNXI_FUNCTION(0x3, "spi0")),		/* MOSI */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 1),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "nand0"),		/* ALE */
+		  SUNXI_FUNCTION(0x3, "spi0")),		/* MISO */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 2),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "nand0"),		/* CLE */
+		  SUNXI_FUNCTION(0x3, "spi0")),		/* CLK */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 3),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "nand0"),		/* CE1 */
+		  SUNXI_FUNCTION(0x3, "spi0")),		/* CS */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 4),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "nand0")),	/* CE0 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 5),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "nand0"),		/* RE */
+		  SUNXI_FUNCTION(0x3, "mmc2")),		/* CLK */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 6),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "nand0"),		/* RB0 */
+		  SUNXI_FUNCTION(0x3, "mmc2")),		/* CMD */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 7),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "nand0")),	/* RB1 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 8),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "nand0"),		/* DQ0 */
+		  SUNXI_FUNCTION(0x3, "mmc2")),		/* D0 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 9),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "nand0"),		/* DQ1 */
+		  SUNXI_FUNCTION(0x3, "mmc2")),		/* D1 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 10),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "nand0"),		/* DQ2 */
+		  SUNXI_FUNCTION(0x3, "mmc2")),		/* D2 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 11),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "nand0"),		/* DQ3 */
+		  SUNXI_FUNCTION(0x3, "mmc2")),		/* D3 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 12),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "nand0"),		/* DQ4 */
+		  SUNXI_FUNCTION(0x3, "mmc2")),		/* D4 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 13),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "nand0"),		/* DQ5 */
+		  SUNXI_FUNCTION(0x3, "mmc2")),		/* D5 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 14),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "nand"),		/* DQ6 */
+		  SUNXI_FUNCTION(0x3, "mmc2")),		/* D6 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 15),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "nand"),		/* DQ7 */
+		  SUNXI_FUNCTION(0x3, "mmc2")),		/* D7 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 16),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "nand"),		/* DQS */
+		  SUNXI_FUNCTION(0x3, "mmc2")),		/* RST */
+	/* Hole */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 2),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "lcd0"),		/* D2 */
+		  SUNXI_FUNCTION(0x3, "mmc1")),		/* CLK */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 3),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "lcd0"),		/* D3 */
+		  SUNXI_FUNCTION(0x3, "mmc1")),		/* CMD */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 4),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "lcd0"),		/* D4 */
+		  SUNXI_FUNCTION(0x3, "mmc1")),		/* D0 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 5),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "lcd0"),		/* D5 */
+		  SUNXI_FUNCTION(0x3, "mmc1")),		/* D1 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 6),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "lcd0"),		/* D6 */
+		  SUNXI_FUNCTION(0x3, "mmc1")),		/* D2 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 7),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "lcd0"),		/* D7 */
+		  SUNXI_FUNCTION(0x3, "mmc1")),		/* D3 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 10),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "lcd0"),		/* D10 */
+		  SUNXI_FUNCTION(0x3, "uart1")),	/* TX */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 11),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "lcd0"),		/* D11 */
+		  SUNXI_FUNCTION(0x3, "uart1")),	/* RX */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 12),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "lcd0"),		/* D12 */
+		  SUNXI_FUNCTION(0x3, "uart1")),	/* RTS */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 13),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "lcd0"),		/* D13 */
+		  SUNXI_FUNCTION(0x3, "uart1")),	/* CTS */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 14),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "lcd0")),		/* D14 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 15),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "lcd0")),		/* D15 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 18),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "lcd0"),		/* D18 */
+		  SUNXI_FUNCTION(0x3, "lvds0")),	/* VP0 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 19),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "lcd0"),		/* D19 */
+		  SUNXI_FUNCTION(0x3, "lvds0")),	/* VN0 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 20),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "lcd0"),		/* D20 */
+		  SUNXI_FUNCTION(0x3, "lvds0")),	/* VP1 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 21),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "lcd0"),		/* D21 */
+		  SUNXI_FUNCTION(0x3, "lvds0")),	/* VN1 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 22),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "lcd0"),		/* D22 */
+		  SUNXI_FUNCTION(0x3, "lvds0")),	/* VP2 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 23),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "lcd0"),		/* D23 */
+		  SUNXI_FUNCTION(0x3, "lvds0")),	/* VN2 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 24),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "lcd0"),		/* CLK */
+		  SUNXI_FUNCTION(0x3, "lvds0")),	/* VPC */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 25),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "lcd0"),		/* DE */
+		  SUNXI_FUNCTION(0x3, "lvds0")),	/* VNC */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 26),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "lcd0"),		/* HSYNC */
+		  SUNXI_FUNCTION(0x3, "lvds0")),	/* VP3 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 27),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "lcd0"),		/* VSYNC */
+		  SUNXI_FUNCTION(0x3, "lvds0")),	/* VN3 */
+	/* Hole */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 0),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "csi")),		/* PCLK */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 1),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "csi")),		/* MCLK */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 2),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "csi")),		/* HSYNC */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 3),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "csi")),		/* VSYNC */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 4),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "csi")),		/* D0 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 5),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "csi")),		/* D1 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 6),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "csi")),		/* D2 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 7),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "csi")),		/* D3 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 8),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "csi")),		/* D4 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 9),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "csi")),		/* D5 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 10),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "csi")),		/* D6 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 11),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "csi")),		/* D7 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 12),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "csi"),		/* SCK */
+		  SUNXI_FUNCTION(0x3, "i2c2")),		/* SCK */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 13),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "csi"),		/* SDA */
+		  SUNXI_FUNCTION(0x3, "i2c2")),		/* SDA */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 14),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out")),
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 15),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out")),
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 16),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out")),
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 17),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out")),
+	/* Hole */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(F, 0),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "mmc0"),		/* D1 */
+		  SUNXI_FUNCTION(0x3, "jtag")),		/* MS1 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(F, 1),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "mmc0"),		/* D0 */
+		  SUNXI_FUNCTION(0x3, "jtag")),		/* DI1 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(F, 2),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "mmc0"),		/* CLK */
+		  SUNXI_FUNCTION(0x3, "uart0")),	/* TX */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(F, 3),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "mmc0"),		/* CMD */
+		  SUNXI_FUNCTION(0x3, "jtag")),		/* DO1 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(F, 4),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "mmc0"),		/* D3 */
+		  SUNXI_FUNCTION(0x3, "uart0")),	/* RX */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(F, 5),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "mmc0"),		/* D2 */
+		  SUNXI_FUNCTION(0x3, "jtag")),		/* CK1 */
+	/* Hole */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(G, 0),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "mmc1"),		/* CLK */
+		  SUNXI_FUNCTION_IRQ_BANK(0x4, 1, 0)),	/* PG_EINT0 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(G, 1),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "mmc1"),		/* CMD */
+		  SUNXI_FUNCTION_IRQ_BANK(0x4, 1, 1)),	/* PG_EINT1 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(G, 2),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "mmc1"),		/* D0 */
+		  SUNXI_FUNCTION_IRQ_BANK(0x4, 1, 2)),	/* PG_EINT2 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(G, 3),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "mmc1"),		/* D1 */
+		  SUNXI_FUNCTION_IRQ_BANK(0x4, 1, 3)),	/* PG_EINT3 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(G, 4),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "mmc1"),		/* D2 */
+		  SUNXI_FUNCTION_IRQ_BANK(0x4, 1, 4)),	/* PG_EINT4 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(G, 5),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "mmc1"),		/* D3 */
+		  SUNXI_FUNCTION_IRQ_BANK(0x4, 1, 5)),	/* PG_EINT5 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(G, 6),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "uart1"),		/* TX */
+		  SUNXI_FUNCTION_IRQ_BANK(0x4, 1, 6)),	/* PG_EINT6 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(G, 7),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "uart1"),		/* RX */
+		  SUNXI_FUNCTION_IRQ_BANK(0x4, 1, 7)),	/* PG_EINT7 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(G, 8),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "uart2"),		/* RTS */
+		  SUNXI_FUNCTION_IRQ_BANK(0x4, 1, 8)),	/* PG_EINT8 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(G, 9),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "uart2"),		/* CTS */
+		  SUNXI_FUNCTION_IRQ_BANK(0x4, 1, 9)),	/* PG_EINT9 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(G, 10),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "i2s1"),		/* SYNC */
+		  SUNXI_FUNCTION_IRQ_BANK(0x4, 1, 10)),	/* PG_EINT10 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(G, 11),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "i2s1"),		/* CLK */
+		  SUNXI_FUNCTION_IRQ_BANK(0x4, 1, 11)),	/* PG_EINT11 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(G, 12),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "i2s1"),		/* DOUT */
+		  SUNXI_FUNCTION_IRQ_BANK(0x4, 1, 12)),	/* PG_EINT12 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(G, 13),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "i2s1"),		/* DIN */
+		  SUNXI_FUNCTION_IRQ_BANK(0x4, 1, 13)),	/* PG_EINT13 */
+	/* Hole */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(H, 0),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "pwm0")),
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(H, 1),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "pwm1")),
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(H, 2),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "i2c0")),		/* SCK */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(H, 3),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "i2c0")),		/* SDA */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(H, 4),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "i2c1")),		/* SCK */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(H, 5),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "i2c1")),		/* SDA */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(H, 6),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "spi0"),		/* CS */
+		  SUNXI_FUNCTION(0x3, "uart3")),	/* TX */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(H, 7),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "spi0"),		/* CLK */
+		  SUNXI_FUNCTION(0x3, "uart3")),	/* RX */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(H, 8),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "spi0"),		/* DOUT */
+		  SUNXI_FUNCTION(0x3, "uart3")),	/* RTS */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(H, 9),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "spi0"),		/* DIN */
+		  SUNXI_FUNCTION(0x3, "uart3")),	/* CTS */
+};
+
+static const struct sunxi_pinctrl_desc sun8i_a33_pinctrl_data = {
+	.pins = sun8i_a33_pins,
+	.npins = ARRAY_SIZE(sun8i_a33_pins),
+	.irq_banks = 2,
+};
+
+static int sun8i_a33_pinctrl_probe(struct platform_device *pdev)
+{
+	return sunxi_pinctrl_init(pdev,
+				  &sun8i_a33_pinctrl_data);
+}
+
+static const struct of_device_id sun8i_a33_pinctrl_match[] = {
+	{ .compatible = "allwinner,sun8i-a33-pinctrl", },
+	{}
+};
+MODULE_DEVICE_TABLE(of, sun8i_a33_pinctrl_match);
+
+static struct platform_driver sun8i_a33_pinctrl_driver = {
+	.probe	= sun8i_a33_pinctrl_probe,
+	.driver	= {
+		.name		= "sun8i-a33-pinctrl",
+		.of_match_table	= sun8i_a33_pinctrl_match,
+	},
+};
+module_platform_driver(sun8i_a33_pinctrl_driver);
+
+MODULE_AUTHOR("Vishnu Patekar <vishnupatekar0510@gmail.com>");
+MODULE_DESCRIPTION("Allwinner a33 pinctrl driver");
+MODULE_LICENSE("GPL");
-- 
2.4.1

[PATCH v2 3/6] ARM: dts: sun8i: Add sun8i-a23-a33 dtsi

[Hans de Goede]

From: Vishnu Patekar <vishnupatekar0510@gmail.com>

Rename sun8i-a23.dtsi to sun8i-a23-a33.dtsi as the base dtsi for the A33
is 99% the same and add a new sun8i-a23.dtsi including sun8i-a23-a33.dtsi
and setting the few things not shared with the A33 (mbus-clk, pio
compatible and interrupts).

Signed-off-by: Vishnu Patekar <vishnupatekar0510@gmail.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
Changes in v2:
-Add a sun8i-a23-a33.dtsi to share between a23 and a33, rather then a
 sun8i.dtsi to share between a23, a33 and h3, since the reset and clock
 bits of the h3 are different, meaning that we also need different clock
 and reset entries for all the peripheral blocks making sharing
 unpractical
---
 .../dts/{sun8i-a23.dtsi => sun8i-a23-a33.dtsi}     |  18 +-
 arch/arm/boot/dts/sun8i-a23.dtsi                   | 576 +--------------------
 2 files changed, 9 insertions(+), 585 deletions(-)
 copy arch/arm/boot/dts/{sun8i-a23.dtsi => sun8i-a23-a33.dtsi} (97%)

diff --git a/arch/arm/boot/dts/sun8i-a23.dtsi b/arch/arm/boot/dts/sun8i-a23-a33.dtsi
similarity index 97%
copy from arch/arm/boot/dts/sun8i-a23.dtsi
copy to arch/arm/boot/dts/sun8i-a23-a33.dtsi
index 7297f96..c73d1d1 100644
--- a/arch/arm/boot/dts/sun8i-a23.dtsi
+++ b/arch/arm/boot/dts/sun8i-a23-a33.dtsi
@@ -93,10 +93,6 @@
 		};
 	};
 
-	memory {
-		reg = <0x40000000 0x40000000>;
-	};
-
 	clocks {
 		#address-cells = <1>;
 		#size-cells = <1>;
@@ -252,14 +248,6 @@
 					     "mmc2_output",
 					     "mmc2_sample";
 		};
-
-		mbus_clk: clk at 01c2015c {
-			#clock-cells = <0>;
-			compatible = "allwinner,sun8i-a23-mbus-clk";
-			reg = <0x01c2015c 0x4>;
-			clocks = <&osc24M>, <&pll6 1>, <&pll5>;
-			clock-output-names = "mbus";
-		};
 	};
 
 	soc at 01c00000 {
@@ -335,11 +323,9 @@
 		};
 
 		pio: pinctrl at 01c20800 {
-			compatible = "allwinner,sun8i-a23-pinctrl";
+			/* compatible gets set in SoC specific dtsi file */
 			reg = <0x01c20800 0x400>;
-			interrupts = <GIC_SPI 11 IRQ_TYPE_LEVEL_HIGH>,
-				     <GIC_SPI 15 IRQ_TYPE_LEVEL_HIGH>,
-				     <GIC_SPI 17 IRQ_TYPE_LEVEL_HIGH>;
+			/* interrupts get set in SoC specific dtsi file */
 			clocks = <&apb1_gates 5>;
 			gpio-controller;
 			interrupt-controller;
diff --git a/arch/arm/boot/dts/sun8i-a23.dtsi b/arch/arm/boot/dts/sun8i-a23.dtsi
index 7297f96..8698f7a 100644
--- a/arch/arm/boot/dts/sun8i-a23.dtsi
+++ b/arch/arm/boot/dts/sun8i-a23.dtsi
@@ -42,217 +42,14 @@
  *     OTHER DEALINGS IN THE SOFTWARE.
  */
 
-#include "skeleton.dtsi"
-
-#include <dt-bindings/interrupt-controller/arm-gic.h>
-
-#include <dt-bindings/pinctrl/sun4i-a10.h>
+#include "sun8i-a23-a33.dtsi"
 
 / {
-	interrupt-parent = <&gic>;
-
-	chosen {
-		#address-cells = <1>;
-		#size-cells = <1>;
-		ranges;
-
-		framebuffer at 0 {
-			compatible = "allwinner,simple-framebuffer",
-				     "simple-framebuffer";
-			allwinner,pipeline = "de_be0-lcd0";
-			clocks = <&pll6 0>;
-			status = "disabled";
-		};
-	};
-
-	timer {
-		compatible = "arm,armv7-timer";
-		interrupts = <GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
-			     <GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
-			     <GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
-			     <GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>;
-		clock-frequency = <24000000>;
-		arm,cpu-registers-not-fw-configured;
-	};
-
-	cpus {
-		enable-method = "allwinner,sun8i-a23";
-		#address-cells = <1>;
-		#size-cells = <0>;
-
-		cpu at 0 {
-			compatible = "arm,cortex-a7";
-			device_type = "cpu";
-			reg = <0>;
-		};
-
-		cpu at 1 {
-			compatible = "arm,cortex-a7";
-			device_type = "cpu";
-			reg = <1>;
-		};
-	};
-
 	memory {
 		reg = <0x40000000 0x40000000>;
 	};
 
 	clocks {
-		#address-cells = <1>;
-		#size-cells = <1>;
-		ranges;
-
-		osc24M: osc24M_clk {
-			#clock-cells = <0>;
-			compatible = "fixed-clock";
-			clock-frequency = <24000000>;
-			clock-output-names = "osc24M";
-		};
-
-		osc32k: osc32k_clk {
-			#clock-cells = <0>;
-			compatible = "fixed-clock";
-			clock-frequency = <32768>;
-			clock-output-names = "osc32k";
-		};
-
-		pll1: clk at 01c20000 {
-			#clock-cells = <0>;
-			compatible = "allwinner,sun8i-a23-pll1-clk";
-			reg = <0x01c20000 0x4>;
-			clocks = <&osc24M>;
-			clock-output-names = "pll1";
-		};
-
-		/* dummy clock until actually implemented */
-		pll5: pll5_clk {
-			#clock-cells = <0>;
-			compatible = "fixed-clock";
-			clock-frequency = <0>;
-			clock-output-names = "pll5";
-		};
-
-		pll6: clk at 01c20028 {
-			#clock-cells = <1>;
-			compatible = "allwinner,sun6i-a31-pll6-clk";
-			reg = <0x01c20028 0x4>;
-			clocks = <&osc24M>;
-			clock-output-names = "pll6", "pll6x2";
-		};
-
-		cpu: cpu_clk at 01c20050 {
-			#clock-cells = <0>;
-			compatible = "allwinner,sun4i-a10-cpu-clk";
-			reg = <0x01c20050 0x4>;
-
-			/*
-			 * PLL1 is listed twice here.
-			 * While it looks suspicious, it's actually documented
-			 * that way both in the datasheet and in the code from
-			 * Allwinner.
-			 */
-			clocks = <&osc32k>, <&osc24M>, <&pll1>, <&pll1>;
-			clock-output-names = "cpu";
-		};
-
-		axi: axi_clk at 01c20050 {
-			#clock-cells = <0>;
-			compatible = "allwinner,sun8i-a23-axi-clk";
-			reg = <0x01c20050 0x4>;
-			clocks = <&cpu>;
-			clock-output-names = "axi";
-		};
-
-		ahb1: ahb1_clk at 01c20054 {
-			#clock-cells = <0>;
-			compatible = "allwinner,sun6i-a31-ahb1-clk";
-			reg = <0x01c20054 0x4>;
-			clocks = <&osc32k>, <&osc24M>, <&axi>, <&pll6 0>;
-			clock-output-names = "ahb1";
-		};
-
-		apb1: apb1_clk at 01c20054 {
-			#clock-cells = <0>;
-			compatible = "allwinner,sun4i-a10-apb0-clk";
-			reg = <0x01c20054 0x4>;
-			clocks = <&ahb1>;
-			clock-output-names = "apb1";
-		};
-
-		ahb1_gates: clk at 01c20060 {
-			#clock-cells = <1>;
-			compatible = "allwinner,sun8i-a23-ahb1-gates-clk";
-			reg = <0x01c20060 0x8>;
-			clocks = <&ahb1>;
-			clock-output-names = "ahb1_mipidsi", "ahb1_dma",
-					"ahb1_mmc0", "ahb1_mmc1", "ahb1_mmc2",
-					"ahb1_nand", "ahb1_sdram",
-					"ahb1_hstimer", "ahb1_spi0",
-					"ahb1_spi1", "ahb1_otg", "ahb1_ehci",
-					"ahb1_ohci", "ahb1_ve", "ahb1_lcd",
-					"ahb1_csi", "ahb1_be",	"ahb1_fe",
-					"ahb1_gpu", "ahb1_spinlock",
-					"ahb1_drc";
-		};
-
-		apb1_gates: clk at 01c20068 {
-			#clock-cells = <1>;
-			compatible = "allwinner,sun8i-a23-apb1-gates-clk";
-			reg = <0x01c20068 0x4>;
-			clocks = <&apb1>;
-			clock-output-names = "apb1_codec", "apb1_pio",
-					"apb1_daudio0",	"apb1_daudio1";
-		};
-
-		apb2: clk at 01c20058 {
-			#clock-cells = <0>;
-			compatible = "allwinner,sun4i-a10-apb1-clk";
-			reg = <0x01c20058 0x4>;
-			clocks = <&osc32k>, <&osc24M>, <&pll6 0>, <&pll6 0>;
-			clock-output-names = "apb2";
-		};
-
-		apb2_gates: clk at 01c2006c {
-			#clock-cells = <1>;
-			compatible = "allwinner,sun8i-a23-apb2-gates-clk";
-			reg = <0x01c2006c 0x4>;
-			clocks = <&apb2>;
-			clock-output-names = "apb2_i2c0", "apb2_i2c1",
-					"apb2_i2c2", "apb2_uart0",
-					"apb2_uart1", "apb2_uart2",
-					"apb2_uart3", "apb2_uart4";
-		};
-
-		mmc0_clk: clk at 01c20088 {
-			#clock-cells = <1>;
-			compatible = "allwinner,sun4i-a10-mmc-clk";
-			reg = <0x01c20088 0x4>;
-			clocks = <&osc24M>, <&pll6 0>;
-			clock-output-names = "mmc0",
-					     "mmc0_output",
-					     "mmc0_sample";
-		};
-
-		mmc1_clk: clk at 01c2008c {
-			#clock-cells = <1>;
-			compatible = "allwinner,sun4i-a10-mmc-clk";
-			reg = <0x01c2008c 0x4>;
-			clocks = <&osc24M>, <&pll6 0>;
-			clock-output-names = "mmc1",
-					     "mmc1_output",
-					     "mmc1_sample";
-		};
-
-		mmc2_clk: clk at 01c20090 {
-			#clock-cells = <1>;
-			compatible = "allwinner,sun4i-a10-mmc-clk";
-			reg = <0x01c20090 0x4>;
-			clocks = <&osc24M>, <&pll6 0>;
-			clock-output-names = "mmc2",
-					     "mmc2_output",
-					     "mmc2_sample";
-		};
-
 		mbus_clk: clk at 01c2015c {
 			#clock-cells = <0>;
 			compatible = "allwinner,sun8i-a23-mbus-clk";
@@ -261,370 +58,11 @@
 			clock-output-names = "mbus";
 		};
 	};
+};
 
-	soc at 01c00000 {
-		compatible = "simple-bus";
-		#address-cells = <1>;
-		#size-cells = <1>;
-		ranges;
-
-		dma: dma-controller at 01c02000 {
-			compatible = "allwinner,sun8i-a23-dma";
-			reg = <0x01c02000 0x1000>;
-			interrupts = <GIC_SPI 50 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&ahb1_gates 6>;
-			resets = <&ahb1_rst 6>;
-			#dma-cells = <1>;
-		};
-
-		mmc0: mmc at 01c0f000 {
-			compatible = "allwinner,sun5i-a13-mmc";
-			reg = <0x01c0f000 0x1000>;
-			clocks = <&ahb1_gates 8>,
-				 <&mmc0_clk 0>,
-				 <&mmc0_clk 1>,
-				 <&mmc0_clk 2>;
-			clock-names = "ahb",
-				      "mmc",
-				      "output",
-				      "sample";
-			resets = <&ahb1_rst 8>;
-			reset-names = "ahb";
-			interrupts = <GIC_SPI 60 IRQ_TYPE_LEVEL_HIGH>;
-			status = "disabled";
-			#address-cells = <1>;
-			#size-cells = <0>;
-		};
-
-		mmc1: mmc at 01c10000 {
-			compatible = "allwinner,sun5i-a13-mmc";
-			reg = <0x01c10000 0x1000>;
-			clocks = <&ahb1_gates 9>,
-				 <&mmc1_clk 0>,
-				 <&mmc1_clk 1>,
-				 <&mmc1_clk 2>;
-			clock-names = "ahb",
-				      "mmc",
-				      "output",
-				      "sample";
-			resets = <&ahb1_rst 9>;
-			reset-names = "ahb";
-			interrupts = <GIC_SPI 61 IRQ_TYPE_LEVEL_HIGH>;
-			status = "disabled";
-			#address-cells = <1>;
-			#size-cells = <0>;
-		};
-
-		mmc2: mmc at 01c11000 {
-			compatible = "allwinner,sun5i-a13-mmc";
-			reg = <0x01c11000 0x1000>;
-			clocks = <&ahb1_gates 10>,
-				 <&mmc2_clk 0>,
-				 <&mmc2_clk 1>,
-				 <&mmc2_clk 2>;
-			clock-names = "ahb",
-				      "mmc",
-				      "output",
-				      "sample";
-			resets = <&ahb1_rst 10>;
-			reset-names = "ahb";
-			interrupts = <GIC_SPI 62 IRQ_TYPE_LEVEL_HIGH>;
-			status = "disabled";
-			#address-cells = <1>;
-			#size-cells = <0>;
-		};
-
-		pio: pinctrl at 01c20800 {
-			compatible = "allwinner,sun8i-a23-pinctrl";
-			reg = <0x01c20800 0x400>;
-			interrupts = <GIC_SPI 11 IRQ_TYPE_LEVEL_HIGH>,
-				     <GIC_SPI 15 IRQ_TYPE_LEVEL_HIGH>,
-				     <GIC_SPI 17 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&apb1_gates 5>;
-			gpio-controller;
-			interrupt-controller;
-			#address-cells = <1>;
-			#size-cells = <0>;
-			#gpio-cells = <3>;
-
-			uart0_pins_a: uart0 at 0 {
-				allwinner,pins = "PF2", "PF4";
-				allwinner,function = "uart0";
-				allwinner,drive = <SUN4I_PINCTRL_10_MA>;
-				allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
-			};
-
-			mmc0_pins_a: mmc0 at 0 {
-				allwinner,pins = "PF0", "PF1", "PF2",
-						 "PF3", "PF4", "PF5";
-				allwinner,function = "mmc0";
-				allwinner,drive = <SUN4I_PINCTRL_30_MA>;
-				allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
-			};
-
-			mmc1_pins_a: mmc1 at 0 {
-				allwinner,pins = "PG0", "PG1", "PG2",
-						 "PG3", "PG4", "PG5";
-				allwinner,function = "mmc1";
-				allwinner,drive = <SUN4I_PINCTRL_30_MA>;
-				allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
-			};
-
-			i2c0_pins_a: i2c0 at 0 {
-				allwinner,pins = "PH2", "PH3";
-				allwinner,function = "i2c0";
-				allwinner,drive = <SUN4I_PINCTRL_10_MA>;
-				allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
-			};
-
-			i2c1_pins_a: i2c1 at 0 {
-				allwinner,pins = "PH4", "PH5";
-				allwinner,function = "i2c1";
-				allwinner,drive = <SUN4I_PINCTRL_10_MA>;
-				allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
-			};
-
-			i2c2_pins_a: i2c2 at 0 {
-				allwinner,pins = "PE12", "PE13";
-				allwinner,function = "i2c2";
-				allwinner,drive = <SUN4I_PINCTRL_10_MA>;
-				allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
-			};
-		};
-
-		ahb1_rst: reset at 01c202c0 {
-			#reset-cells = <1>;
-			compatible = "allwinner,sun6i-a31-clock-reset";
-			reg = <0x01c202c0 0xc>;
-		};
-
-		apb1_rst: reset at 01c202d0 {
-			#reset-cells = <1>;
-			compatible = "allwinner,sun6i-a31-clock-reset";
-			reg = <0x01c202d0 0x4>;
-		};
-
-		apb2_rst: reset at 01c202d8 {
-			#reset-cells = <1>;
-			compatible = "allwinner,sun6i-a31-clock-reset";
-			reg = <0x01c202d8 0x4>;
-		};
-
-		timer at 01c20c00 {
-			compatible = "allwinner,sun4i-a10-timer";
-			reg = <0x01c20c00 0xa0>;
-			interrupts = <GIC_SPI 18 IRQ_TYPE_LEVEL_HIGH>,
-				     <GIC_SPI 19 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&osc24M>;
-		};
-
-		wdt0: watchdog at 01c20ca0 {
-			compatible = "allwinner,sun6i-a31-wdt";
-			reg = <0x01c20ca0 0x20>;
-			interrupts = <GIC_SPI 25 IRQ_TYPE_LEVEL_HIGH>;
-		};
-
-		lradc: lradc at 01c22800 {
-			compatible = "allwinner,sun4i-a10-lradc-keys";
-			reg = <0x01c22800 0x100>;
-			interrupts = <GIC_SPI 30 IRQ_TYPE_LEVEL_HIGH>;
-			status = "disabled";
-		};
-
-		uart0: serial at 01c28000 {
-			compatible = "snps,dw-apb-uart";
-			reg = <0x01c28000 0x400>;
-			interrupts = <GIC_SPI 0 IRQ_TYPE_LEVEL_HIGH>;
-			reg-shift = <2>;
-			reg-io-width = <4>;
-			clocks = <&apb2_gates 16>;
-			resets = <&apb2_rst 16>;
-			dmas = <&dma 6>, <&dma 6>;
-			dma-names = "rx", "tx";
-			status = "disabled";
-		};
-
-		uart1: serial at 01c28400 {
-			compatible = "snps,dw-apb-uart";
-			reg = <0x01c28400 0x400>;
-			interrupts = <GIC_SPI 1 IRQ_TYPE_LEVEL_HIGH>;
-			reg-shift = <2>;
-			reg-io-width = <4>;
-			clocks = <&apb2_gates 17>;
-			resets = <&apb2_rst 17>;
-			dmas = <&dma 7>, <&dma 7>;
-			dma-names = "rx", "tx";
-			status = "disabled";
-		};
-
-		uart2: serial at 01c28800 {
-			compatible = "snps,dw-apb-uart";
-			reg = <0x01c28800 0x400>;
-			interrupts = <GIC_SPI 2 IRQ_TYPE_LEVEL_HIGH>;
-			reg-shift = <2>;
-			reg-io-width = <4>;
-			clocks = <&apb2_gates 18>;
-			resets = <&apb2_rst 18>;
-			dmas = <&dma 8>, <&dma 8>;
-			dma-names = "rx", "tx";
-			status = "disabled";
-		};
-
-		uart3: serial at 01c28c00 {
-			compatible = "snps,dw-apb-uart";
-			reg = <0x01c28c00 0x400>;
-			interrupts = <GIC_SPI 3 IRQ_TYPE_LEVEL_HIGH>;
-			reg-shift = <2>;
-			reg-io-width = <4>;
-			clocks = <&apb2_gates 19>;
-			resets = <&apb2_rst 19>;
-			dmas = <&dma 9>, <&dma 9>;
-			dma-names = "rx", "tx";
-			status = "disabled";
-		};
-
-		uart4: serial at 01c29000 {
-			compatible = "snps,dw-apb-uart";
-			reg = <0x01c29000 0x400>;
-			interrupts = <GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH>;
-			reg-shift = <2>;
-			reg-io-width = <4>;
-			clocks = <&apb2_gates 20>;
-			resets = <&apb2_rst 20>;
-			dmas = <&dma 10>, <&dma 10>;
-			dma-names = "rx", "tx";
-			status = "disabled";
-		};
-
-		i2c0: i2c at 01c2ac00 {
-			compatible = "allwinner,sun6i-a31-i2c";
-			reg = <0x01c2ac00 0x400>;
-			interrupts = <GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&apb2_gates 0>;
-			resets = <&apb2_rst 0>;
-			status = "disabled";
-			#address-cells = <1>;
-			#size-cells = <0>;
-		};
-
-		i2c1: i2c at 01c2b000 {
-			compatible = "allwinner,sun6i-a31-i2c";
-			reg = <0x01c2b000 0x400>;
-			interrupts = <GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&apb2_gates 1>;
-			resets = <&apb2_rst 1>;
-			status = "disabled";
-			#address-cells = <1>;
-			#size-cells = <0>;
-		};
-
-		i2c2: i2c at 01c2b400 {
-			compatible = "allwinner,sun6i-a31-i2c";
-			reg = <0x01c2b400 0x400>;
-			interrupts = <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&apb2_gates 2>;
-			resets = <&apb2_rst 2>;
-			status = "disabled";
-			#address-cells = <1>;
-			#size-cells = <0>;
-		};
-
-		gic: interrupt-controller at 01c81000 {
-			compatible = "arm,cortex-a7-gic", "arm,cortex-a15-gic";
-			reg = <0x01c81000 0x1000>,
-			      <0x01c82000 0x1000>,
-			      <0x01c84000 0x2000>,
-			      <0x01c86000 0x2000>;
-			interrupt-controller;
-			#interrupt-cells = <3>;
-			interrupts = <GIC_PPI 9 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>;
-		};
-
-		rtc: rtc at 01f00000 {
-			compatible = "allwinner,sun6i-a31-rtc";
-			reg = <0x01f00000 0x54>;
-			interrupts = <GIC_SPI 40 IRQ_TYPE_LEVEL_HIGH>,
-				     <GIC_SPI 41 IRQ_TYPE_LEVEL_HIGH>;
-		};
-
-		prcm at 01f01400 {
-			compatible = "allwinner,sun8i-a23-prcm";
-			reg = <0x01f01400 0x200>;
-
-			ar100: ar100_clk {
-				compatible = "fixed-factor-clock";
-				#clock-cells = <0>;
-				clock-div = <1>;
-				clock-mult = <1>;
-				clocks = <&osc24M>;
-				clock-output-names = "ar100";
-			};
-
-			ahb0: ahb0_clk {
-				compatible = "fixed-factor-clock";
-				#clock-cells = <0>;
-				clock-div = <1>;
-				clock-mult = <1>;
-				clocks = <&ar100>;
-				clock-output-names = "ahb0";
-			};
-
-			apb0: apb0_clk {
-				compatible = "allwinner,sun8i-a23-apb0-clk";
-				#clock-cells = <0>;
-				clocks = <&ahb0>;
-				clock-output-names = "apb0";
-			};
-
-			apb0_gates: apb0_gates_clk {
-				compatible = "allwinner,sun8i-a23-apb0-gates-clk";
-				#clock-cells = <1>;
-				clocks = <&apb0>;
-				clock-output-names = "apb0_pio", "apb0_timer",
-						"apb0_rsb", "apb0_uart",
-						"apb0_i2c";
-			};
-
-			apb0_rst: apb0_rst {
-				compatible = "allwinner,sun6i-a31-clock-reset";
-				#reset-cells = <1>;
-			};
-		};
-
-		cpucfg at 01f01c00 {
-			compatible = "allwinner,sun8i-a23-cpuconfig";
-			reg = <0x01f01c00 0x300>;
-		};
-
-		r_uart: serial at 01f02800 {
-			compatible = "snps,dw-apb-uart";
-			reg = <0x01f02800 0x400>;
-			interrupts = <GIC_SPI 38 IRQ_TYPE_LEVEL_HIGH>;
-			reg-shift = <2>;
-			reg-io-width = <4>;
-			clocks = <&apb0_gates 4>;
-			resets = <&apb0_rst 4>;
-			status = "disabled";
-		};
-
-		r_pio: pinctrl at 01f02c00 {
-			compatible = "allwinner,sun8i-a23-r-pinctrl";
-			reg = <0x01f02c00 0x400>;
-			interrupts = <GIC_SPI 45 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&apb0_gates 0>;
-			resets = <&apb0_rst 0>;
-			gpio-controller;
-			interrupt-controller;
-			#address-cells = <1>;
-			#size-cells = <0>;
-			#gpio-cells = <3>;
-
-			r_uart_pins_a: r_uart at 0 {
-				allwinner,pins = "PL2", "PL3";
-				allwinner,function = "s_uart";
-				allwinner,drive = <SUN4I_PINCTRL_10_MA>;
-				allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
-			};
-		};
-	};
+&pio {
+	compatible = "allwinner,sun8i-a23-pinctrl";
+	interrupts = <GIC_SPI 11 IRQ_TYPE_LEVEL_HIGH>,
+		     <GIC_SPI 15 IRQ_TYPE_LEVEL_HIGH>,
+		     <GIC_SPI 17 IRQ_TYPE_LEVEL_HIGH>;
 };
-- 
2.4.1

[PATCH v2 3/6] ARM: dts: sun8i: Add sun8i-a23-a33 dtsi

[Maxime Ripard]

On Sat, May 30, 2015 at 04:55:03PM +0200, Hans de Goede wrote:
> From: Vishnu Patekar <vishnupatekar0510@gmail.com>
> 
> Rename sun8i-a23.dtsi to sun8i-a23-a33.dtsi as the base dtsi for the A33
> is 99% the same and add a new sun8i-a23.dtsi including sun8i-a23-a33.dtsi
> and setting the few things not shared with the A33 (mbus-clk, pio
> compatible and interrupts).
> 
> Signed-off-by: Vishnu Patekar <vishnupatekar0510@gmail.com>
> Signed-off-by: Hans de Goede <hdegoede@redhat.com>

Fixed the conflicts and applied.

Also judging from a quick look at the datasheet, the A33 doesn't seem
to have that clock gates tree but rather one similar to the H3's. That
will probably mean we'll have to move out the gates from this DTSI at
some point.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150602/b43e1c69/attachment.sig>

[PATCH v2 3/6] ARM: dts: sun8i: Add sun8i-a23-a33 dtsi

[Hans de Goede]

Hi,

On 02-06-15 09:51, Maxime Ripard wrote:
> On Sat, May 30, 2015 at 04:55:03PM +0200, Hans de Goede wrote:
>> From: Vishnu Patekar <vishnupatekar0510@gmail.com>
>>
>> Rename sun8i-a23.dtsi to sun8i-a23-a33.dtsi as the base dtsi for the A33
>> is 99% the same and add a new sun8i-a23.dtsi including sun8i-a23-a33.dtsi
>> and setting the few things not shared with the A33 (mbus-clk, pio
>> compatible and interrupts).
>>
>> Signed-off-by: Vishnu Patekar <vishnupatekar0510@gmail.com>
>> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
>
> Fixed the conflicts and applied.
>
> Also judging from a quick look at the datasheet, the A33 doesn't seem
> to have that clock gates tree but rather one similar to the H3's. That
> will probably mean we'll have to move out the gates from this DTSI at
> some point.

Heuh...

Ok so I've done a full bit for bit comparison of the 2 datasheets for
the clk gates, mostly they are mostly the same and the registers seem to
just be renamed.

The only differences are:

01c200060 (AHB1 MODULE CLOCK GATING REGISTER 0 / Bus Clock Gating Register 0):

Only A33 has bit 5 SS gating

01c200064 (AHB1 MODULE CLOCK GATING REGISTER 1 / Bus Clock Gating Register 1):

Only A33 has bit 26 SAT gating, note that if we add support for this we
must add it as a needed clock to the simplefb node

Only A33 has bit 21 MSGBOX_GATING

01c200068 (APB1 MODULE CLOCK GATING REGISTER / Bus Clock Gating Register 2):

No differences

01c20006c (APB2 MODULE CLOCK GATING REGISTER / Bus Clock Gating Register 3):

No differences


So you are right that in the near future we should add a separate compatible
+ clk driver or the ahb1_gates on the A33, but it does not seem that there is
the issue of one gate register having multiple parents like on the H3. Or maybe
the H3 does also not have that issue, and this is a misinterpretation of
the H3 datasheet ?

Note I do not know what the actual parent clock for the new gates is, but
it stands to reason that it is AHB1, I've been unable to find anything to
confirm or deny this.

Regards,

Hans

[PATCH v2 3/6] ARM: dts: sun8i: Add sun8i-a23-a33 dtsi

[Maxime Ripard]

On Tue, Jun 02, 2015 at 10:08:39AM +0200, Hans de Goede wrote:
> Hi,
> 
> On 02-06-15 09:51, Maxime Ripard wrote:
> >On Sat, May 30, 2015 at 04:55:03PM +0200, Hans de Goede wrote:
> >>From: Vishnu Patekar <vishnupatekar0510@gmail.com>
> >>
> >>Rename sun8i-a23.dtsi to sun8i-a23-a33.dtsi as the base dtsi for the A33
> >>is 99% the same and add a new sun8i-a23.dtsi including sun8i-a23-a33.dtsi
> >>and setting the few things not shared with the A33 (mbus-clk, pio
> >>compatible and interrupts).
> >>
> >>Signed-off-by: Vishnu Patekar <vishnupatekar0510@gmail.com>
> >>Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> >
> >Fixed the conflicts and applied.
> >
> >Also judging from a quick look at the datasheet, the A33 doesn't seem
> >to have that clock gates tree but rather one similar to the H3's. That
> >will probably mean we'll have to move out the gates from this DTSI at
> >some point.
> 
> Heuh...
> 
> Ok so I've done a full bit for bit comparison of the 2 datasheets for
> the clk gates, mostly they are mostly the same and the registers seem to
> just be renamed.
> 
> The only differences are:
> 
> 01c200060 (AHB1 MODULE CLOCK GATING REGISTER 0 / Bus Clock Gating Register 0):
> 
> Only A33 has bit 5 SS gating
> 
> 01c200064 (AHB1 MODULE CLOCK GATING REGISTER 1 / Bus Clock Gating Register 1):
> 
> Only A33 has bit 26 SAT gating, note that if we add support for this we
> must add it as a needed clock to the simplefb node
> 
> Only A33 has bit 21 MSGBOX_GATING
> 
> 01c200068 (APB1 MODULE CLOCK GATING REGISTER / Bus Clock Gating Register 2):
> 
> No differences
> 
> 01c20006c (APB2 MODULE CLOCK GATING REGISTER / Bus Clock Gating Register 3):
> 
> No differences
> 
> 
> So you are right that in the near future we should add a separate compatible
> + clk driver or the ahb1_gates on the A33, but it does not seem that there is
> the issue of one gate register having multiple parents like on the H3. Or maybe
> the H3 does also not have that issue, and this is a misinterpretation of
> the H3 datasheet ?

I might have been misguided by the clock name (AHB1, APB1,
etc... gates vs bus gates).

If it's just as simple as that, then yeah, we'll probably don't need
the H3 bus gates driver for this.

> Note I do not know what the actual parent clock for the new gates is, but
> it stands to reason that it is AHB1, I've been unable to find anything to
> confirm or deny this.

That's always something we can change if we find that it's not the
case.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150602/ce9ced6c/attachment.sig>

[PATCH v2 4/6] ARM: dts: sun8i: Add sun8i-a33 dtsi

[Hans de Goede]

From: Vishnu Patekar <vishnupatekar0510@gmail.com>

Add a dtsi file for use with a33 based boards based on the new
sun8i-a23-a33.dtsi file.

Signed-off-by: Vishnu Patekar <vishnupatekar0510@gmail.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
Changes in v2:
-Use the new merged sun8i-a23-a33.dtsi file
---
 arch/arm/boot/dts/sun8i-a33.dtsi | 89 ++++++++++++++++++++++++++++++++++++++++
 1 file changed, 89 insertions(+)
 create mode 100644 arch/arm/boot/dts/sun8i-a33.dtsi

diff --git a/arch/arm/boot/dts/sun8i-a33.dtsi b/arch/arm/boot/dts/sun8i-a33.dtsi
new file mode 100644
index 0000000..9b43bc6
--- /dev/null
+++ b/arch/arm/boot/dts/sun8i-a33.dtsi
@@ -0,0 +1,89 @@
+/*
+ * Copyright 2014 Chen-Yu Tsai
+ *
+ * Chen-Yu Tsai <wens@csie.org>
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ *     modify it under the terms of the GNU General Public License as
+ *     published by the Free Software Foundation; either version 2 of the
+ *     License, or (at your option) any later version.
+ *
+ *     This file is distributed in the hope that it will be useful,
+ *     but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *     GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ *     obtaining a copy of this software and associated documentation
+ *     files (the "Software"), to deal in the Software without
+ *     restriction, including without limitation the rights to use,
+ *     copy, modify, merge, publish, distribute, sublicense, and/or
+ *     sell copies of the Software, and to permit persons to whom the
+ *     Software is furnished to do so, subject to the following
+ *     conditions:
+ *
+ *     The above copyright notice and this permission notice shall be
+ *     included in all copies or substantial portions of the Software.
+ *
+ *     THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ *     OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+#include "sun8i-a23-a33.dtsi"
+
+/ {
+	cpus {
+		cpu at 2 {
+			compatible = "arm,cortex-a7";
+			device_type = "cpu";
+			reg = <2>;
+		};
+
+		cpu at 3 {
+			compatible = "arm,cortex-a7";
+			device_type = "cpu";
+			reg = <3>;
+		};
+	};
+
+	memory {
+		reg = <0x40000000 0x80000000>;
+	};
+
+	clocks {
+		/* Dummy clock for pll11 (DDR1) until actually implemented */
+		pll11: pll11_clk {
+			#clock-cells = <0>;
+			compatible = "fixed-clock";
+			clock-frequency = <0>;
+			clock-output-names = "pll11";
+		};
+
+		mbus_clk: clk at 01c2015c {
+			#clock-cells = <0>;
+			compatible = "allwinner,sun8i-a23-mbus-clk";
+			reg = <0x01c2015c 0x4>;
+			clocks = <&osc24M>, <&pll6 1>, <&pll5>, <&pll11>;
+			clock-output-names = "mbus";
+		};
+	};
+};
+
+&pio {
+	compatible = "allwinner,sun8i-a33-pinctrl";
+	interrupts = <GIC_SPI 15 IRQ_TYPE_LEVEL_HIGH>,
+		     <GIC_SPI 17 IRQ_TYPE_LEVEL_HIGH>;
+};
-- 
2.4.1

[PATCH v2 4/6] ARM: dts: sun8i: Add sun8i-a33 dtsi

[Maxime Ripard]

On Sat, May 30, 2015 at 04:55:04PM +0200, Hans de Goede wrote:
> From: Vishnu Patekar <vishnupatekar0510@gmail.com>
> 
> Add a dtsi file for use with a33 based boards based on the new
> sun8i-a23-a33.dtsi file.
> 
> Signed-off-by: Vishnu Patekar <vishnupatekar0510@gmail.com>
> Signed-off-by: Hans de Goede <hdegoede@redhat.com>

Applied, thanks!

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150602/432952bc/attachment.sig>

[PATCH v2 5/6] ARM: dts: sun8i: Add ET-Q8 A33 support

[Hans de Goede]

From: Vishnu Patekar <vishnupatekar0510@gmail.com>

ET-Q8_A33 is A33 based cheap tablet in common Q8 format.

It has 512MB RAM, 4GB Nand, 7" Display, RDA5900P wifi, GSL1680 touch, etc.

Signed-off-by: Vishnu Patekar <vishnupatekar0510@gmail.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
Changes in v2:
-Cleanup up board model and compatible string
-Use stdout-path instead of bootargs to specify the serial console
-Remove the (presumably untested) i2c nodes
---
 arch/arm/boot/dts/Makefile                 |  3 +-
 arch/arm/boot/dts/sun8i-a33-et-q8-v1.6.dts | 88 ++++++++++++++++++++++++++++++
 2 files changed, 90 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/boot/dts/sun8i-a33-et-q8-v1.6.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index db2e1e5..ae7f25d 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -572,7 +572,8 @@ dtb-$(CONFIG_MACH_SUN7I) += \
 dtb-$(CONFIG_MACH_SUN8I) += \
 	sun8i-a23-evb.dtb \
 	sun8i-a23-ippo-q8h-v5.dtb \
-	sun8i-a23-ippo-q8h-v1.2.dtb
+	sun8i-a23-ippo-q8h-v1.2.dtb \
+	sun8i-a33-et-q8-v1.6.dtb
 dtb-$(CONFIG_MACH_SUN9I) += \
 	sun9i-a80-optimus.dtb \
 	sun9i-a80-cubieboard4.dtb
diff --git a/arch/arm/boot/dts/sun8i-a33-et-q8-v1.6.dts b/arch/arm/boot/dts/sun8i-a33-et-q8-v1.6.dts
new file mode 100644
index 0000000..19db844
--- /dev/null
+++ b/arch/arm/boot/dts/sun8i-a33-et-q8-v1.6.dts
@@ -0,0 +1,88 @@
+/*
+ * Copyright 2015 Vishnu Patekar
+ * Vishnu Patekar <vishnupatekar0510@gmail.com>
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ *     modify it under the terms of the GNU General Public License as
+ *     published by the Free Software Foundation; either version 2 of the
+ *     License, or (at your option) any later version.
+ *
+ *     This file is distributed in the hope that it will be useful,
+ *     but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *     GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ *     obtaining a copy of this software and associated documentation
+ *     files (the "Software"), to deal in the Software without
+ *     restriction, including without limitation the rights to use,
+ *     copy, modify, merge, publish, distribute, sublicense, and/or
+ *     sell copies of the Software, and to permit persons to whom the
+ *     Software is furnished to do so, subject to the following
+ *     conditions:
+ *
+ *     The above copyright notice and this permission notice shall be
+ *     included in all copies or substantial portions of the Software.
+ *
+ *     THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ *     OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+#include "sun8i-a33.dtsi"
+#include "sunxi-common-regulators.dtsi"
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/input.h>
+#include <dt-bindings/pinctrl/sun4i-a10.h>
+
+/ {
+	model = "ET Q8 Quad Core Tablet (v1.6)";
+	compatible = "et,q8-v1.6", "allwinner,sun8i-a33";
+
+	aliases {
+		serial0 = &uart0;
+	};
+
+	chosen {
+		stdout-path = "serial0:115200n8";
+	};
+};
+
+&lradc {
+	vref-supply = <&reg_vcc3v0>;
+	status = "okay";
+
+	button at 200 {
+		label = "Volume Up";
+		linux,code = <KEY_VOLUMEUP>;
+		channel = <0>;
+		voltage = <200000>;
+	};
+
+	button at 400 {
+		label = "Volume Down";
+		linux,code = <KEY_VOLUMEDOWN>;
+		channel = <0>;
+		voltage = <400000>;
+	};
+};
+
+&uart0 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&uart0_pins_a>;
+	status = "okay";
+};
-- 
2.4.1

[PATCH v2 5/6] ARM: dts: sun8i: Add ET-Q8 A33 support

[Maxime Ripard]

On Sat, May 30, 2015 at 04:55:05PM +0200, Hans de Goede wrote:
> From: Vishnu Patekar <vishnupatekar0510@gmail.com>
> 
> ET-Q8_A33 is A33 based cheap tablet in common Q8 format.
> 
> It has 512MB RAM, 4GB Nand, 7" Display, RDA5900P wifi, GSL1680 touch, etc.
> 
> Signed-off-by: Vishnu Patekar <vishnupatekar0510@gmail.com>
> Signed-off-by: Hans de Goede <hdegoede@redhat.com>

Applied, thanks!

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150602/42c133be/attachment.sig>

[PATCH v2 6/6] ARM: sun8i: dts: Add Ippo-q8h v1.2 with A33 and 1024x600 lcd support

[Hans de Goede]

The Ippo-q8h is a tablet circuit board commonly found in cheap Android
tablets. The v1.2 version can be used with either an A23 or A33 SoC.

This adds a dts file for the v1.2 board with an A33 SoC and a 1024x600
LCD screen (most of these tablets have a 800x480 screen).

This version features 512 MB DRAM, 4G NAND, MMC, LCD, capacitive
touchscreen, accelerometer, 2 camera sensors, USB OTG, microphone
and speakers.

i2c0 is connected to the gsl1680 capacitive touch panel controller,
i2c1 is connected to an mma7660 3-axis accelerometer, these peripherals are
not supported by the kernel yet, i2c bus functionality has been tested via
i2c-dev.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
 arch/arm/boot/dts/Makefile                         |   3 +-
 .../dts/sun8i-a33-ippo-q8h-v1.2-lcd1024x600.dts    | 118 +++++++++++++++++++++
 2 files changed, 120 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/boot/dts/sun8i-a33-ippo-q8h-v1.2-lcd1024x600.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index ae7f25d..b308baf 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -573,7 +573,8 @@ dtb-$(CONFIG_MACH_SUN8I) += \
 	sun8i-a23-evb.dtb \
 	sun8i-a23-ippo-q8h-v5.dtb \
 	sun8i-a23-ippo-q8h-v1.2.dtb \
-	sun8i-a33-et-q8-v1.6.dtb
+	sun8i-a33-et-q8-v1.6.dtb \
+	sun8i-a33-ippo-q8h-v1.2-lcd1024x600.dtb
 dtb-$(CONFIG_MACH_SUN9I) += \
 	sun9i-a80-optimus.dtb \
 	sun9i-a80-cubieboard4.dtb
diff --git a/arch/arm/boot/dts/sun8i-a33-ippo-q8h-v1.2-lcd1024x600.dts b/arch/arm/boot/dts/sun8i-a33-ippo-q8h-v1.2-lcd1024x600.dts
new file mode 100644
index 0000000..12dfb1e
--- /dev/null
+++ b/arch/arm/boot/dts/sun8i-a33-ippo-q8h-v1.2-lcd1024x600.dts
@@ -0,0 +1,118 @@
+/*
+ * Copyright 2015 Hans de Goede <hdegoede@redhat.com>
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ *     modify it under the terms of the GNU General Public License as
+ *     published by the Free Software Foundation; either version 2 of the
+ *     License, or (at your option) any later version.
+ *
+ *     This file is distributed in the hope that it will be useful,
+ *     but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *     GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ *     obtaining a copy of this software and associated documentation
+ *     files (the "Software"), to deal in the Software without
+ *     restriction, including without limitation the rights to use,
+ *     copy, modify, merge, publish, distribute, sublicense, and/or
+ *     sell copies of the Software, and to permit persons to whom the
+ *     Software is furnished to do so, subject to the following
+ *     conditions:
+ *
+ *     The above copyright notice and this permission notice shall be
+ *     included in all copies or substantial portions of the Software.
+ *
+ *     THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ *     OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+#include "sun8i-a33.dtsi"
+#include "sunxi-common-regulators.dtsi"
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/input.h>
+#include <dt-bindings/pinctrl/sun4i-a10.h>
+
+/ {
+	model = "Ippo Q8H Quad Core Tablet (v1.2) with 1024x600 LCD";
+	compatible = "ippo,q8h-v1.2", "allwinner,sun8i-a33";
+
+	aliases {
+		serial0 = &r_uart;
+	};
+
+	chosen {
+		stdout-path = "serial0:115200n8";
+	};
+};
+
+&i2c0 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&i2c0_pins_a>;
+	status = "okay";
+};
+
+&i2c1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&i2c1_pins_a>;
+	status = "okay";
+};
+
+&lradc {
+	vref-supply = <&reg_vcc3v0>;
+	status = "okay";
+
+	button at 200 {
+		label = "Volume Up";
+		linux,code = <KEY_VOLUMEUP>;
+		channel = <0>;
+		voltage = <200000>;
+	};
+
+	button at 400 {
+		label = "Volume Down";
+		linux,code = <KEY_VOLUMEDOWN>;
+		channel = <0>;
+		voltage = <400000>;
+	};
+};
+
+&mmc0 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&mmc0_pins_a>, <&mmc0_cd_pin_q8h>;
+	vmmc-supply = <&reg_vcc3v0>;
+	bus-width = <4>;
+	cd-gpios = <&pio 1 4 GPIO_ACTIVE_HIGH>; /* PB4 */
+	cd-inverted;
+	status = "okay";
+};
+
+&pio {
+	mmc0_cd_pin_q8h: mmc0_cd_pin at 0 {
+		allwinner,pins = "PB4";
+		allwinner,function = "gpio_in";
+		allwinner,drive = <SUN4I_PINCTRL_10_MA>;
+		allwinner,pull = <SUN4I_PINCTRL_PULL_UP>;
+	};
+};
+
+&r_uart {
+	pinctrl-names = "default";
+	pinctrl-0 = <&r_uart_pins_a>;
+	status = "okay";
+};
-- 
2.4.1

[PATCH v2 6/6] ARM: sun8i: dts: Add Ippo-q8h v1.2 with A33 and 1024x600 lcd support

[Maxime Ripard]

On Sat, May 30, 2015 at 04:55:06PM +0200, Hans de Goede wrote:
> The Ippo-q8h is a tablet circuit board commonly found in cheap Android
> tablets. The v1.2 version can be used with either an A23 or A33 SoC.
> 
> This adds a dts file for the v1.2 board with an A33 SoC and a 1024x600
> LCD screen (most of these tablets have a 800x480 screen).

I think the difference between the resolution here is more of a case
for the DT quirks interface:
https://lkml.org/lkml/2015/2/18/258

Do you know if there's some way to autodetect the two board versions
(like a board id somewhere in an EEPROM)?

If not, then maybe u-boot can simply add that board compatible to the
list, and we'll base our logic on that when we'll need it.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150602/5112db89/attachment-0001.sig>

[PATCH v2 6/6] ARM: sun8i: dts: Add Ippo-q8h v1.2 with A33 and 1024x600 lcd support

[Hans de Goede]

Hi,

On 02-06-15 10:14, Maxime Ripard wrote:
> On Sat, May 30, 2015 at 04:55:06PM +0200, Hans de Goede wrote:
>> The Ippo-q8h is a tablet circuit board commonly found in cheap Android
>> tablets. The v1.2 version can be used with either an A23 or A33 SoC.
>>
>> This adds a dts file for the v1.2 board with an A33 SoC and a 1024x600
>> LCD screen (most of these tablets have a 800x480 screen).
>
> I think the difference between the resolution here is more of a case
> for the DT quirks interface:
> https://lkml.org/lkml/2015/2/18/258

I would expect the only difference between the 2 dts files to be the
node describing the lcd panel, so yes that makes somewhat sense.

> Do you know if there's some way to autodetect the two board versions
> (like a board id somewhere in an EEPROM)?

No, AFAIK there is no way to tell the difference. There is no eeprom no
the board, and we really cannot rely on the nand contents.

> If not, then maybe u-boot can simply add that board compatible to the
> list, and we'll base our logic on that when we'll need it.

That means extra logic in u-boot, and on the kernel side, for what
benefit exactly? Such logic would make sense if there was one u-boot
image which runtime adjusted itself, but that is not an option.

And we can avoid copy and paste on the dts side by putting all
the common stuff in a common file and including that, I believe
that that is better (KISS = better) since we've no way to runtime
do the right thing AFAICT.

Regards,

Hans

[PATCH v2 6/6] ARM: sun8i: dts: Add Ippo-q8h v1.2 with A33 and 1024x600 lcd support

[Maxime Ripard]

On Tue, Jun 02, 2015 at 10:29:09AM +0200, Hans de Goede wrote:
> Hi,
> 
> On 02-06-15 10:14, Maxime Ripard wrote:
> >On Sat, May 30, 2015 at 04:55:06PM +0200, Hans de Goede wrote:
> >>The Ippo-q8h is a tablet circuit board commonly found in cheap Android
> >>tablets. The v1.2 version can be used with either an A23 or A33 SoC.
> >>
> >>This adds a dts file for the v1.2 board with an A33 SoC and a 1024x600
> >>LCD screen (most of these tablets have a 800x480 screen).
> >
> >I think the difference between the resolution here is more of a case
> >for the DT quirks interface:
> >https://lkml.org/lkml/2015/2/18/258
> 
> I would expect the only difference between the 2 dts files to be the
> node describing the lcd panel, so yes that makes somewhat sense.
> 
> >Do you know if there's some way to autodetect the two board versions
> >(like a board id somewhere in an EEPROM)?
> 
> No, AFAIK there is no way to tell the difference. There is no eeprom no
> the board, and we really cannot rely on the nand contents.

Ok.

> >If not, then maybe u-boot can simply add that board compatible to the
> >list, and we'll base our logic on that when we'll need it.
> 
> That means extra logic in u-boot, and on the kernel side, for what
> benefit exactly? Such logic would make sense if there was one u-boot
> image which runtime adjusted itself, but that is not an option.

For what benefit? One kernel image which runtime adjusts itself. It's
especially possible if u-boot's image is not, which seems to be what
you're saying.

> And we can avoid copy and paste on the dts side by putting all
> the common stuff in a common file and including that, I believe
> that that is better (KISS = better) since we've no way to runtime
> do the right thing AFAICT.

My concern is about the ever-growing number of DTS that just are small
variations of one or the other. What about the time when we'll
discover that this board has a variant that has an emmc, and some that
don't have any button, or the i2c bus 2 not wired, and one other that
doesn't have any HDMI?

Do we really want to have a dts called
sun8i-a33-q8h-emmc-lcd800x600-nohdmi-noi2c2-nobuttons.dts?

Especially when we will have the one that we include here that will
not have followed this convention because it was introduced before
that, and that we have a way to deal with this nicely?

You chose to consider the DTS names an ABI, the best way to handle
this is to have a DTS as generic as possible, and leave all these
small variations outside of the name.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150603/cf19263b/attachment.sig>

[PATCH v2 6/6] ARM: sun8i: dts: Add Ippo-q8h v1.2 with A33 and 1024x600 lcd support

[Hans de Goede]

Hi,

On 03-06-15 11:45, Maxime Ripard wrote:
> On Tue, Jun 02, 2015 at 10:29:09AM +0200, Hans de Goede wrote:
>> Hi,
>>
>> On 02-06-15 10:14, Maxime Ripard wrote:
>>> On Sat, May 30, 2015 at 04:55:06PM +0200, Hans de Goede wrote:
>>>> The Ippo-q8h is a tablet circuit board commonly found in cheap Android
>>>> tablets. The v1.2 version can be used with either an A23 or A33 SoC.
>>>>
>>>> This adds a dts file for the v1.2 board with an A33 SoC and a 1024x600
>>>> LCD screen (most of these tablets have a 800x480 screen).
>>>
>>> I think the difference between the resolution here is more of a case
>>> for the DT quirks interface:
>>> https://lkml.org/lkml/2015/2/18/258
>>
>> I would expect the only difference between the 2 dts files to be the
>> node describing the lcd panel, so yes that makes somewhat sense.
>>
>>> Do you know if there's some way to autodetect the two board versions
>>> (like a board id somewhere in an EEPROM)?
>>
>> No, AFAIK there is no way to tell the difference. There is no eeprom no
>> the board, and we really cannot rely on the nand contents.
>
> Ok.
>
>>> If not, then maybe u-boot can simply add that board compatible to the
>>> list, and we'll base our logic on that when we'll need it.
>>
>> That means extra logic in u-boot, and on the kernel side, for what
>> benefit exactly? Such logic would make sense if there was one u-boot
>> image which runtime adjusted itself, but that is not an option.
>
> For what benefit? One kernel image which runtime adjusts itself.

You mean one dtb right, because the kernel itself already runtime
adjusts itself.

> It's especially possible if u-boot's image is not, which seems to be what
> you're saying.

But we will still need different configs in u-boot, and we need
to add code + config to u-boot to plug in the extra compatibles
to automatically select the right built-in overlays.

>> And we can avoid copy and paste on the dts side by putting all
>> the common stuff in a common file and including that, I believe
>> that that is better (KISS = better) since we've no way to runtime
>> do the right thing AFAICT.
>
> My concern is about the ever-growing number of DTS that just are small
> variations of one or the other. What about the time when we'll
> discover that this board has a variant that has an emmc, and some that
> don't have any button, or the i2c bus 2 not wired, and one other that
> doesn't have any HDMI?
>
> Do we really want to have a dts called
> sun8i-a33-q8h-emmc-lcd800x600-nohdmi-noi2c2-nobuttons.dts?
>
> Especially when we will have the one that we include here that will
> not have followed this convention because it was introduced before
> that, and that we have a way to deal with this nicely?
>
> You chose to consider the DTS names an ABI, the best way to handle
> this is to have a DTS as generic as possible, and leave all these
> small variations outside of the name.

Ok, so for now this is not really an issue at all since the dts
does not yet decribe the lcd at all. So can you merge this one
renamed to a more generic name for 4.2?

That will work fine for now.

Then we can use the DT quirks interface to add different lcd
nodes for different variants once we get lcd support in the kernel,
and teach u-boot to add the extra board compatible to select
the right lcd node at that time.

Regards,

Hans

[PATCH v2 6/6] ARM: sun8i: dts: Add Ippo-q8h v1.2 with A33 and 1024x600 lcd support

[Maxime Ripard]

Hi,

Sorry for the late reply.

On Wed, Jun 03, 2015 at 01:12:04PM +0200, Hans de Goede wrote:
> Hi,
> 
> On 03-06-15 11:45, Maxime Ripard wrote:
> >On Tue, Jun 02, 2015 at 10:29:09AM +0200, Hans de Goede wrote:
> >>Hi,
> >>
> >>On 02-06-15 10:14, Maxime Ripard wrote:
> >>>On Sat, May 30, 2015 at 04:55:06PM +0200, Hans de Goede wrote:
> >>>>The Ippo-q8h is a tablet circuit board commonly found in cheap Android
> >>>>tablets. The v1.2 version can be used with either an A23 or A33 SoC.
> >>>>
> >>>>This adds a dts file for the v1.2 board with an A33 SoC and a 1024x600
> >>>>LCD screen (most of these tablets have a 800x480 screen).
> >>>
> >>>I think the difference between the resolution here is more of a case
> >>>for the DT quirks interface:
> >>>https://lkml.org/lkml/2015/2/18/258
> >>
> >>I would expect the only difference between the 2 dts files to be the
> >>node describing the lcd panel, so yes that makes somewhat sense.
> >>
> >>>Do you know if there's some way to autodetect the two board versions
> >>>(like a board id somewhere in an EEPROM)?
> >>
> >>No, AFAIK there is no way to tell the difference. There is no eeprom no
> >>the board, and we really cannot rely on the nand contents.
> >
> >Ok.
> >
> >>>If not, then maybe u-boot can simply add that board compatible to the
> >>>list, and we'll base our logic on that when we'll need it.
> >>
> >>That means extra logic in u-boot, and on the kernel side, for what
> >>benefit exactly? Such logic would make sense if there was one u-boot
> >>image which runtime adjusted itself, but that is not an option.
> >
> >For what benefit? One kernel image which runtime adjusts itself.
> 
> You mean one dtb right, because the kernel itself already runtime
> adjusts itself.

Well, the kernel will runtime adjust the DT, so, both, I'd say?

> >It's especially possible if u-boot's image is not, which seems to be what
> >you're saying.
> 
> But we will still need different configs in u-boot, and we need
> to add code + config to u-boot to plug in the extra compatibles
> to automatically select the right built-in overlays.

You're going to have a different config anyway, but yeah, that's true.

> >>And we can avoid copy and paste on the dts side by putting all
> >>the common stuff in a common file and including that, I believe
> >>that that is better (KISS = better) since we've no way to runtime
> >>do the right thing AFAICT.
> >
> >My concern is about the ever-growing number of DTS that just are small
> >variations of one or the other. What about the time when we'll
> >discover that this board has a variant that has an emmc, and some that
> >don't have any button, or the i2c bus 2 not wired, and one other that
> >doesn't have any HDMI?
> >
> >Do we really want to have a dts called
> >sun8i-a33-q8h-emmc-lcd800x600-nohdmi-noi2c2-nobuttons.dts?
> >
> >Especially when we will have the one that we include here that will
> >not have followed this convention because it was introduced before
> >that, and that we have a way to deal with this nicely?
> >
> >You chose to consider the DTS names an ABI, the best way to handle
> >this is to have a DTS as generic as possible, and leave all these
> >small variations outside of the name.
> 
> Ok, so for now this is not really an issue at all since the dts
> does not yet decribe the lcd at all. So can you merge this one
> renamed to a more generic name for 4.2?
> 
> That will work fine for now.
> 
> Then we can use the DT quirks interface to add different lcd
> nodes for different variants once we get lcd support in the kernel,
> and teach u-boot to add the extra board compatible to select
> the right lcd node at that time.

I think we need to discuss this with Pantelis and what is his feeling
about this.

Pantelis, to sum things up, we have a case of a tablet that comes with
the exact same board, but coming in two flavours with two differents
screen resolutions. It looks like a great case for your DT quirks
work, but we have no way of runtime detecting the difference between
the two variants. What do you think about this? Should we go with
using the DT quirks or is this simply out of scope?

There's not so much example of similar cases in the kernel, and none
of them use quirks so far (obviously) but they all boil down to either
the solution you were suggesting in that patch or adding the alternate
configuration as a comment.

I don't think the latter would work for you, and I agree with that, so
I guess that depending on what Pantelis says, either we go with a
better solution using the quirks, or we end up using what you
suggested (with a nitpick though, I'd prefer if you used the display
standard instead of the resolution, which would make it xga I guess?)

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150613/f8bc4fef/attachment-0001.sig>

[PATCH v2 6/6] ARM: sun8i: dts: Add Ippo-q8h v1.2 with A33 and 1024x600 lcd support

[Hans de Goede]

Hi,

On 13-06-15 15:50, Maxime Ripard wrote:
> Hi,
>
> Sorry for the late reply.
>
> On Wed, Jun 03, 2015 at 01:12:04PM +0200, Hans de Goede wrote:
>> Hi,
>>
>> On 03-06-15 11:45, Maxime Ripard wrote:
>>> On Tue, Jun 02, 2015 at 10:29:09AM +0200, Hans de Goede wrote:
>>>> Hi,
>>>>
>>>> On 02-06-15 10:14, Maxime Ripard wrote:
>>>>> On Sat, May 30, 2015 at 04:55:06PM +0200, Hans de Goede wrote:
>>>>>> The Ippo-q8h is a tablet circuit board commonly found in cheap Android
>>>>>> tablets. The v1.2 version can be used with either an A23 or A33 SoC.
>>>>>>
>>>>>> This adds a dts file for the v1.2 board with an A33 SoC and a 1024x600
>>>>>> LCD screen (most of these tablets have a 800x480 screen).
>>>>>
>>>>> I think the difference between the resolution here is more of a case
>>>>> for the DT quirks interface:
>>>>> https://lkml.org/lkml/2015/2/18/258
>>>>
>>>> I would expect the only difference between the 2 dts files to be the
>>>> node describing the lcd panel, so yes that makes somewhat sense.
>>>>
>>>>> Do you know if there's some way to autodetect the two board versions
>>>>> (like a board id somewhere in an EEPROM)?
>>>>
>>>> No, AFAIK there is no way to tell the difference. There is no eeprom no
>>>> the board, and we really cannot rely on the nand contents.
>>>
>>> Ok.
>>>
>>>>> If not, then maybe u-boot can simply add that board compatible to the
>>>>> list, and we'll base our logic on that when we'll need it.
>>>>
>>>> That means extra logic in u-boot, and on the kernel side, for what
>>>> benefit exactly? Such logic would make sense if there was one u-boot
>>>> image which runtime adjusted itself, but that is not an option.
>>>
>>> For what benefit? One kernel image which runtime adjusts itself.
>>
>> You mean one dtb right, because the kernel itself already runtime
>> adjusts itself.
>
> Well, the kernel will runtime adjust the DT, so, both, I'd say?
>
>>> It's especially possible if u-boot's image is not, which seems to be what
>>> you're saying.
>>
>> But we will still need different configs in u-boot, and we need
>> to add code + config to u-boot to plug in the extra compatibles
>> to automatically select the right built-in overlays.
>
> You're going to have a different config anyway, but yeah, that's true.
>
>>>> And we can avoid copy and paste on the dts side by putting all
>>>> the common stuff in a common file and including that, I believe
>>>> that that is better (KISS = better) since we've no way to runtime
>>>> do the right thing AFAICT.
>>>
>>> My concern is about the ever-growing number of DTS that just are small
>>> variations of one or the other. What about the time when we'll
>>> discover that this board has a variant that has an emmc, and some that
>>> don't have any button, or the i2c bus 2 not wired, and one other that
>>> doesn't have any HDMI?
>>>
>>> Do we really want to have a dts called
>>> sun8i-a33-q8h-emmc-lcd800x600-nohdmi-noi2c2-nobuttons.dts?
>>>
>>> Especially when we will have the one that we include here that will
>>> not have followed this convention because it was introduced before
>>> that, and that we have a way to deal with this nicely?
>>>
>>> You chose to consider the DTS names an ABI, the best way to handle
>>> this is to have a DTS as generic as possible, and leave all these
>>> small variations outside of the name.
>>
>> Ok, so for now this is not really an issue at all since the dts
>> does not yet decribe the lcd at all. So can you merge this one
>> renamed to a more generic name for 4.2?
>>
>> That will work fine for now.
>>
>> Then we can use the DT quirks interface to add different lcd
>> nodes for different variants once we get lcd support in the kernel,
>> and teach u-boot to add the extra board compatible to select
>> the right lcd node at that time.
>
> I think we need to discuss this with Pantelis and what is his feeling
> about this.

Ok.

> Pantelis, to sum things up, we have a case of a tablet that comes with
> the exact same board, but coming in two flavours with two differents
> screen resolutions. It looks like a great case for your DT quirks
> work, but we have no way of runtime detecting the difference between
> the two variants. What do you think about this? Should we go with
> using the DT quirks or is this simply out of scope?
>
> There's not so much example of similar cases in the kernel, and none
> of them use quirks so far (obviously) but they all boil down to either
> the solution you were suggesting in that patch or adding the alternate
> configuration as a comment.
>
> I don't think the latter would work for you, and I agree with that, so
> I guess that depending on what Pantelis says, either we go with a
> better solution using the quirks, or we end up using what you
> suggested (with a nitpick though, I'd prefer if you used the display
> standard instead of the resolution, which would make it xga I guess?)

If we go with a separate dts file for each of the 800x480 and 1024x600
screens, I would greatly prefer to stick with the lcd1024x600 in the dts
filename instead of using something like xga, the fact that you say:
"I guess" that my answer to that is: I dunno I would need to look this
up in wikipedia or some such makes me think that using a qualifier like
xga is not going the help end users decide which dts file to pick, it
will just lead to them needing to go to wikipedia too. Also note that
the advertising of these tablets on ebay / aliexpress almost always
uses the resolution and not something like "xga".

So all in all if we do not decide to use quirks for this I would like
to keep the filename as is.

Regards,

Hans






>
> Maxime
>

[PATCH v2 6/6] ARM: sun8i: dts: Add Ippo-q8h v1.2 with A33 and 1024x600 lcd support

[Maxime Ripard]

Hi,

On Sat, Jun 13, 2015 at 04:18:59PM +0200, Hans de Goede wrote:
> >Pantelis, to sum things up, we have a case of a tablet that comes with
> >the exact same board, but coming in two flavours with two differents
> >screen resolutions. It looks like a great case for your DT quirks
> >work, but we have no way of runtime detecting the difference between
> >the two variants. What do you think about this? Should we go with
> >using the DT quirks or is this simply out of scope?
> >
> >There's not so much example of similar cases in the kernel, and none
> >of them use quirks so far (obviously) but they all boil down to either
> >the solution you were suggesting in that patch or adding the alternate
> >configuration as a comment.
> >
> >I don't think the latter would work for you, and I agree with that, so
> >I guess that depending on what Pantelis says, either we go with a
> >better solution using the quirks, or we end up using what you
> >suggested (with a nitpick though, I'd prefer if you used the display
> >standard instead of the resolution, which would make it xga I guess?)
> 
> If we go with a separate dts file for each of the 800x480 and 1024x600
> screens, I would greatly prefer to stick with the lcd1024x600 in the dts
> filename instead of using something like xga, the fact that you say:
> "I guess" that my answer to that is: I dunno I would need to look this
> up in wikipedia or some such makes me think that using a qualifier like
> xga is not going the help end users decide which dts file to pick, it
> will just lead to them needing to go to wikipedia too. Also note that
> the advertising of these tablets on ebay / aliexpress almost always
> uses the resolution and not something like "xga".
> 
> So all in all if we do not decide to use quirks for this I would like
> to keep the filename as is.

Yeah, except that the display standard is also encoding the refresh
rate and color depth, that might change from one board to another.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150616/0174be5b/attachment.sig>

[PATCH v2 6/6] ARM: sun8i: dts: Add Ippo-q8h v1.2 with A33 and 1024x600 lcd support

[Hans de Goede]

Hi,

On 16-06-15 19:41, Maxime Ripard wrote:
> Hi,
>
> On Sat, Jun 13, 2015 at 04:18:59PM +0200, Hans de Goede wrote:
>>> Pantelis, to sum things up, we have a case of a tablet that comes with
>>> the exact same board, but coming in two flavours with two differents
>>> screen resolutions. It looks like a great case for your DT quirks
>>> work, but we have no way of runtime detecting the difference between
>>> the two variants. What do you think about this? Should we go with
>>> using the DT quirks or is this simply out of scope?
>>>
>>> There's not so much example of similar cases in the kernel, and none
>>> of them use quirks so far (obviously) but they all boil down to either
>>> the solution you were suggesting in that patch or adding the alternate
>>> configuration as a comment.
>>>
>>> I don't think the latter would work for you, and I agree with that, so
>>> I guess that depending on what Pantelis says, either we go with a
>>> better solution using the quirks, or we end up using what you
>>> suggested (with a nitpick though, I'd prefer if you used the display
>>> standard instead of the resolution, which would make it xga I guess?)
>>
>> If we go with a separate dts file for each of the 800x480 and 1024x600
>> screens, I would greatly prefer to stick with the lcd1024x600 in the dts
>> filename instead of using something like xga, the fact that you say:
>> "I guess" that my answer to that is: I dunno I would need to look this
>> up in wikipedia or some such makes me think that using a qualifier like
>> xga is not going the help end users decide which dts file to pick, it
>> will just lead to them needing to go to wikipedia too. Also note that
>> the advertising of these tablets on ebay / aliexpress almost always
>> uses the resolution and not something like "xga".
>>
>> So all in all if we do not decide to use quirks for this I would like
>> to keep the filename as is.
>
> Yeah, except that the display standard is also encoding the refresh
> rate and color depth

Huh? No it does not, see e.g.:

https://en.wikipedia.org/wiki/Graphics_display_resolution

Note nothing about depth and refresh-rate there, and I've really never
heard anyone use things like xga to refer to colordepth and/or refreshrate

Regards,

Hans

[PATCH v2 6/6] ARM: sun8i: dts: Add Ippo-q8h v1.2 with A33 and 1024x600 lcd support

[Maxime Ripard]

On Wed, Jun 17, 2015 at 09:16:02AM +0200, Hans de Goede wrote:
> Hi,
> 
> On 16-06-15 19:41, Maxime Ripard wrote:
> >Hi,
> >
> >On Sat, Jun 13, 2015 at 04:18:59PM +0200, Hans de Goede wrote:
> >>>Pantelis, to sum things up, we have a case of a tablet that comes with
> >>>the exact same board, but coming in two flavours with two differents
> >>>screen resolutions. It looks like a great case for your DT quirks
> >>>work, but we have no way of runtime detecting the difference between
> >>>the two variants. What do you think about this? Should we go with
> >>>using the DT quirks or is this simply out of scope?
> >>>
> >>>There's not so much example of similar cases in the kernel, and none
> >>>of them use quirks so far (obviously) but they all boil down to either
> >>>the solution you were suggesting in that patch or adding the alternate
> >>>configuration as a comment.
> >>>
> >>>I don't think the latter would work for you, and I agree with that, so
> >>>I guess that depending on what Pantelis says, either we go with a
> >>>better solution using the quirks, or we end up using what you
> >>>suggested (with a nitpick though, I'd prefer if you used the display
> >>>standard instead of the resolution, which would make it xga I guess?)
> >>
> >>If we go with a separate dts file for each of the 800x480 and 1024x600
> >>screens, I would greatly prefer to stick with the lcd1024x600 in the dts
> >>filename instead of using something like xga, the fact that you say:
> >>"I guess" that my answer to that is: I dunno I would need to look this
> >>up in wikipedia or some such makes me think that using a qualifier like
> >>xga is not going the help end users decide which dts file to pick, it
> >>will just lead to them needing to go to wikipedia too. Also note that
> >>the advertising of these tablets on ebay / aliexpress almost always
> >>uses the resolution and not something like "xga".
<> >>
> >>So all in all if we do not decide to use quirks for this I would like
> >>to keep the filename as is.
> >
> >Yeah, except that the display standard is also encoding the refresh
> >rate and color depth
> 
> Huh? No it does not, see e.g.:
> 
> https://en.wikipedia.org/wiki/Graphics_display_resolution
> 
> Note nothing about depth and refresh-rate there, and I've really never
> heard anyone use things like xga to refer to colordepth and/or refreshrate

I was somehow convinced it did, and

https://en.wikipedia.org/wiki/Computer_display_standard

seems to say that as well... Maybe not then, my bad.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150618/527262e6/attachment.sig>

[PATCH v2 6/6] ARM: sun8i: dts: Add Ippo-q8h v1.2 with A33 and 1024x600 lcd support

[Hans de Goede]

Hi,

On 18-06-15 20:37, Maxime Ripard wrote:
> On Wed, Jun 17, 2015 at 09:16:02AM +0200, Hans de Goede wrote:
>> Hi,
>>
>> On 16-06-15 19:41, Maxime Ripard wrote:
>>> Hi,
>>>
>>> On Sat, Jun 13, 2015 at 04:18:59PM +0200, Hans de Goede wrote:
>>>>> Pantelis, to sum things up, we have a case of a tablet that comes with
>>>>> the exact same board, but coming in two flavours with two differents
>>>>> screen resolutions. It looks like a great case for your DT quirks
>>>>> work, but we have no way of runtime detecting the difference between
>>>>> the two variants. What do you think about this? Should we go with
>>>>> using the DT quirks or is this simply out of scope?
>>>>>
>>>>> There's not so much example of similar cases in the kernel, and none
>>>>> of them use quirks so far (obviously) but they all boil down to either
>>>>> the solution you were suggesting in that patch or adding the alternate
>>>>> configuration as a comment.
>>>>>
>>>>> I don't think the latter would work for you, and I agree with that, so
>>>>> I guess that depending on what Pantelis says, either we go with a
>>>>> better solution using the quirks, or we end up using what you
>>>>> suggested (with a nitpick though, I'd prefer if you used the display
>>>>> standard instead of the resolution, which would make it xga I guess?)
>>>>
>>>> If we go with a separate dts file for each of the 800x480 and 1024x600
>>>> screens, I would greatly prefer to stick with the lcd1024x600 in the dts
>>>> filename instead of using something like xga, the fact that you say:
>>>> "I guess" that my answer to that is: I dunno I would need to look this
>>>> up in wikipedia or some such makes me think that using a qualifier like
>>>> xga is not going the help end users decide which dts file to pick, it
>>>> will just lead to them needing to go to wikipedia too. Also note that
>>>> the advertising of these tablets on ebay / aliexpress almost always
>>>> uses the resolution and not something like "xga".
> <> >>
>>>> So all in all if we do not decide to use quirks for this I would like
>>>> to keep the filename as is.
>>>
>>> Yeah, except that the display standard is also encoding the refresh
>>> rate and color depth
>>
>> Huh? No it does not, see e.g.:
>>
>> https://en.wikipedia.org/wiki/Graphics_display_resolution
>>
>> Note nothing about depth and refresh-rate there, and I've really never
>> heard anyone use things like xga to refer to colordepth and/or refreshrate
>
> I was somehow convinced it did, and
>
> https://en.wikipedia.org/wiki/Computer_display_standard

Hmm, that is a weird page it seems to be a rather low quality page for
wikipedia standards, for some reason it throws Atari ST models in there
as being display standards, and the bpp column makes sense for hercules,
cga and ega but not much which comes after that.

Regards,

Hans

[PATCH v2 6/6] ARM: sun8i: dts: Add Ippo-q8h v1.2 with A33 and 1024x600 lcd support

[Pantelis Antoniou]

Hi Maxime,

> On Jun 13, 2015, at 16:50 , Maxime Ripard <maxime.ripard@free-electrons.com> wrote:
> 
> Hi,
> 
> Sorry for the late reply.
> 
> On Wed, Jun 03, 2015 at 01:12:04PM +0200, Hans de Goede wrote:
>> Hi,
>> 
>> On 03-06-15 11:45, Maxime Ripard wrote:
>>> On Tue, Jun 02, 2015 at 10:29:09AM +0200, Hans de Goede wrote:
>>>> Hi,
>>>> 
>>>> On 02-06-15 10:14, Maxime Ripard wrote:
>>>>> On Sat, May 30, 2015 at 04:55:06PM +0200, Hans de Goede wrote:
>>>>>> The Ippo-q8h is a tablet circuit board commonly found in cheap Android
>>>>>> tablets. The v1.2 version can be used with either an A23 or A33 SoC.
>>>>>> 
>>>>>> This adds a dts file for the v1.2 board with an A33 SoC and a 1024x600
>>>>>> LCD screen (most of these tablets have a 800x480 screen).
>>>>> 
>>>>> I think the difference between the resolution here is more of a case
>>>>> for the DT quirks interface:
>>>>> https://lkml.org/lkml/2015/2/18/258
>>>> 
>>>> I would expect the only difference between the 2 dts files to be the
>>>> node describing the lcd panel, so yes that makes somewhat sense.
>>>> 
>>>>> Do you know if there's some way to autodetect the two board versions
>>>>> (like a board id somewhere in an EEPROM)?
>>>> 
>>>> No, AFAIK there is no way to tell the difference. There is no eeprom no
>>>> the board, and we really cannot rely on the nand contents.
>>> 
>>> Ok.
>>> 
>>>>> If not, then maybe u-boot can simply add that board compatible to the
>>>>> list, and we'll base our logic on that when we'll need it.
>>>> 
>>>> That means extra logic in u-boot, and on the kernel side, for what
>>>> benefit exactly? Such logic would make sense if there was one u-boot
>>>> image which runtime adjusted itself, but that is not an option.
>>> 
>>> For what benefit? One kernel image which runtime adjusts itself.
>> 
>> You mean one dtb right, because the kernel itself already runtime
>> adjusts itself.
> 
> Well, the kernel will runtime adjust the DT, so, both, I'd say?
> 
>>> It's especially possible if u-boot's image is not, which seems to be what
>>> you're saying.
>> 
>> But we will still need different configs in u-boot, and we need
>> to add code + config to u-boot to plug in the extra compatibles
>> to automatically select the right built-in overlays.
> 
> You're going to have a different config anyway, but yeah, that's true.
> 
>>>> And we can avoid copy and paste on the dts side by putting all
>>>> the common stuff in a common file and including that, I believe
>>>> that that is better (KISS = better) since we've no way to runtime
>>>> do the right thing AFAICT.
>>> 
>>> My concern is about the ever-growing number of DTS that just are small
>>> variations of one or the other. What about the time when we'll
>>> discover that this board has a variant that has an emmc, and some that
>>> don't have any button, or the i2c bus 2 not wired, and one other that
>>> doesn't have any HDMI?
>>> 
>>> Do we really want to have a dts called
>>> sun8i-a33-q8h-emmc-lcd800x600-nohdmi-noi2c2-nobuttons.dts?
>>> 
>>> Especially when we will have the one that we include here that will
>>> not have followed this convention because it was introduced before
>>> that, and that we have a way to deal with this nicely?
>>> 
>>> You chose to consider the DTS names an ABI, the best way to handle
>>> this is to have a DTS as generic as possible, and leave all these
>>> small variations outside of the name.
>> 
>> Ok, so for now this is not really an issue at all since the dts
>> does not yet decribe the lcd at all. So can you merge this one
>> renamed to a more generic name for 4.2?
>> 
>> That will work fine for now.
>> 
>> Then we can use the DT quirks interface to add different lcd
>> nodes for different variants once we get lcd support in the kernel,
>> and teach u-boot to add the extra board compatible to select
>> the right lcd node at that time.
> 
> I think we need to discuss this with Pantelis and what is his feeling
> about this.
> 
> Pantelis, to sum things up, we have a case of a tablet that comes with
> the exact same board, but coming in two flavours with two differents
> screen resolutions. It looks like a great case for your DT quirks
> work, but we have no way of runtime detecting the difference between
> the two variants. What do you think about this? Should we go with
> using the DT quirks or is this simply out of scope?
> 
> There's not so much example of similar cases in the kernel, and none
> of them use quirks so far (obviously) but they all boil down to either
> the solution you were suggesting in that patch or adding the alternate
> configuration as a comment.
> 
> I don't think the latter would work for you, and I agree with that, so
> I guess that depending on what Pantelis says, either we go with a
> better solution using the quirks, or we end up using what you
> suggested (with a nitpick though, I'd prefer if you used the display
> standard instead of the resolution, which would make it xga I guess?)
> 

First of all, the quirks interface is at an RFC stage (new name suggested is
?variants?); getting that out of the way this seems like what it is designed
to do.

The idea of the DT quirks is to drastically cut down on the number of different
DTs required, each different for each board with minute differences from one another.

In your case you have boards that have no way to be probed about what they ?are?,
but that?s no big problem. You can easily pass the board variant in the kernel command
line and use that to select the quirk to apply.

In fact the original patchset does contain a command line quirk for enabling and disabling
the onboard emmc & hdmi of the beaglebone black for capes that need to use those signals.

Saying that, if you?re in a hurry I?d say go with a different DTSs for now, since that?s
going to go in a near kernel cycle; DT quirks will be discussed at plumber?s in a couple
of months, and then we?ll if it will go in and in what form.

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

Regards

? Pantelis

[PATCH v2 6/6] ARM: sun8i: dts: Add Ippo-q8h v1.2 with A33 and 1024x600 lcd support

[Maxime Ripard]

Hi Pantelis,

On Sun, Jun 14, 2015 at 09:16:21PM +0300, Pantelis Antoniou wrote:
> > I think we need to discuss this with Pantelis and what is his feeling
> > about this.
> > 
> > Pantelis, to sum things up, we have a case of a tablet that comes with
> > the exact same board, but coming in two flavours with two differents
> > screen resolutions. It looks like a great case for your DT quirks
> > work, but we have no way of runtime detecting the difference between
> > the two variants. What do you think about this? Should we go with
> > using the DT quirks or is this simply out of scope?
> > 
> > There's not so much example of similar cases in the kernel, and none
> > of them use quirks so far (obviously) but they all boil down to either
> > the solution you were suggesting in that patch or adding the alternate
> > configuration as a comment.
> > 
> > I don't think the latter would work for you, and I agree with that, so
> > I guess that depending on what Pantelis says, either we go with a
> > better solution using the quirks, or we end up using what you
> > suggested (with a nitpick though, I'd prefer if you used the display
> > standard instead of the resolution, which would make it xga I guess?)
> > 
> 
> First of all, the quirks interface is at an RFC stage (new name
> suggested is ?variants?); getting that out of the way this seems
> like what it is designed to do.
> 
> The idea of the DT quirks is to drastically cut down on the number
> of different DTs required, each different for each board with minute
> differences from one another.

We're on the same page then :)

> In your case you have boards that have no way to be probed about
> what they ?are?, but that?s no big problem. You can easily pass the
> board variant in the kernel command line and use that to select the
> quirk to apply.

Hans actually pointed out that this would just move the logic
somewhere else, but not remove it. In our case, that would mean U-Boot
(Hans being the U-Boot maintainer for the SoCs that are used in this
particular board).

That would still require us to have a different configuration and to
add some logic to pass that extra parameter to the kernel. I'd be glad
to have less stuff in the kernel, but I can understand that he doesn't
want more stuff either.

> In fact the original patchset does contain a command line quirk for
> enabling and disabling the onboard emmc & hdmi of the beaglebone
> black for capes that need to use those signals.

Ah. I somehow overlooked that when reading it.

> Saying that, if you?re in a hurry I?d say go with a different DTSs
> for now, since that?s going to go in a near kernel cycle; DT quirks
> will be discussed at plumber?s in a couple of months, and then we?ll
> if it will go in and in what form.

Ok. I won't be here this year, but if you could raise the topic of how
to handle "non-discoverable boards" then, it would be great.

Hans, I guess we can go for your suggestion then: apply a "generic" DT
for the board right now, we're going to need it anyway. Then, when
will have real display support, depending on the current state of the
discussion for the quirks, we will either merge a different DT
including the generic one, or if the quirks have something that work
for both of us then, use the quirks. Sounds good?

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150616/628f0871/attachment-0001.sig>

[PATCH v2 6/6] ARM: sun8i: dts: Add Ippo-q8h v1.2 with A33 and 1024x600 lcd support

[Pantelis Antoniou]

Hi Maxime,

> On Jun 16, 2015, at 20:55 , Maxime Ripard <maxime.ripard@free-electrons.com> wrote:
> 
> Hi Pantelis,
> 
> On Sun, Jun 14, 2015 at 09:16:21PM +0300, Pantelis Antoniou wrote:
>>> I think we need to discuss this with Pantelis and what is his feeling
>>> about this.
>>> 
>>> Pantelis, to sum things up, we have a case of a tablet that comes with
>>> the exact same board, but coming in two flavours with two differents
>>> screen resolutions. It looks like a great case for your DT quirks
>>> work, but we have no way of runtime detecting the difference between
>>> the two variants. What do you think about this? Should we go with
>>> using the DT quirks or is this simply out of scope?
>>> 
>>> There's not so much example of similar cases in the kernel, and none
>>> of them use quirks so far (obviously) but they all boil down to either
>>> the solution you were suggesting in that patch or adding the alternate
>>> configuration as a comment.
>>> 
>>> I don't think the latter would work for you, and I agree with that, so
>>> I guess that depending on what Pantelis says, either we go with a
>>> better solution using the quirks, or we end up using what you
>>> suggested (with a nitpick though, I'd prefer if you used the display
>>> standard instead of the resolution, which would make it xga I guess?)
>>> 
>> 
>> First of all, the quirks interface is at an RFC stage (new name
>> suggested is ?variants?); getting that out of the way this seems
>> like what it is designed to do.
>> 
>> The idea of the DT quirks is to drastically cut down on the number
>> of different DTs required, each different for each board with minute
>> differences from one another.
> 
> We're on the same page then :)
> 

Heh :)

>> In your case you have boards that have no way to be probed about
>> what they ?are?, but that?s no big problem. You can easily pass the
>> board variant in the kernel command line and use that to select the
>> quirk to apply.
> 
> Hans actually pointed out that this would just move the logic
> somewhere else, but not remove it. In our case, that would mean U-Boot
> (Hans being the U-Boot maintainer for the SoCs that are used in this
> particular board).
> 
> That would still require us to have a different configuration and to
> add some logic to pass that extra parameter to the kernel. I'd be glad
> to have less stuff in the kernel, but I can understand that he doesn't
> want more stuff either.
> 

Well, I don?t know the specifics of your board, but if you have a configuration
subset that works for all the boards and makes it at least possible to load
a kernel (i.e. ram, serial, storage) you can keep a single bootloader that?s not
full featured, but at least can boot any kind of variant.

Afterwards you can just update the bootargs variable to the correct one for
a given board.  
 
>> In fact the original patchset does contain a command line quirk for
>> enabling and disabling the onboard emmc & hdmi of the beaglebone
>> black for capes that need to use those signals.
> 
> Ah. I somehow overlooked that when reading it.
> 
>> Saying that, if you?re in a hurry I?d say go with a different DTSs
>> for now, since that?s going to go in a near kernel cycle; DT quirks
>> will be discussed at plumber?s in a couple of months, and then we?ll
>> if it will go in and in what form.
> 
> Ok. I won't be here this year, but if you could raise the topic of how
> to handle "non-discoverable boards" then, it would be great.
> 
> Hans, I guess we can go for your suggestion then: apply a "generic" DT
> for the board right now, we're going to need it anyway. Then, when
> will have real display support, depending on the current state of the
> discussion for the quirks, we will either merge a different DT
> including the generic one, or if the quirks have something that work
> for both of us then, use the quirks. Sounds good?
> 
> Maxime
> 
> -- 
> Maxime Ripard, Free Electrons
> Embedded Linux, Kernel and Android engineering
> http://free-electrons.com

Regards

? Pantelis

[PATCH v2 6/6] ARM: sun8i: dts: Add Ippo-q8h v1.2 with A33 and 1024x600 lcd support

[Hans de Goede]

Hi,

On 16-06-15 21:33, Pantelis Antoniou wrote:
> Hi Maxime,
>
>> On Jun 16, 2015, at 20:55 , Maxime Ripard <maxime.ripard@free-electrons.com> wrote:
>>
>> Hi Pantelis,
>>
>> On Sun, Jun 14, 2015 at 09:16:21PM +0300, Pantelis Antoniou wrote:
>>>> I think we need to discuss this with Pantelis and what is his feeling
>>>> about this.
>>>>
>>>> Pantelis, to sum things up, we have a case of a tablet that comes with
>>>> the exact same board, but coming in two flavours with two differents
>>>> screen resolutions. It looks like a great case for your DT quirks
>>>> work, but we have no way of runtime detecting the difference between
>>>> the two variants. What do you think about this? Should we go with
>>>> using the DT quirks or is this simply out of scope?
>>>>
>>>> There's not so much example of similar cases in the kernel, and none
>>>> of them use quirks so far (obviously) but they all boil down to either
>>>> the solution you were suggesting in that patch or adding the alternate
>>>> configuration as a comment.
>>>>
>>>> I don't think the latter would work for you, and I agree with that, so
>>>> I guess that depending on what Pantelis says, either we go with a
>>>> better solution using the quirks, or we end up using what you
>>>> suggested (with a nitpick though, I'd prefer if you used the display
>>>> standard instead of the resolution, which would make it xga I guess?)
>>>>
>>>
>>> First of all, the quirks interface is at an RFC stage (new name
>>> suggested is ?variants?); getting that out of the way this seems
>>> like what it is designed to do.
>>>
>>> The idea of the DT quirks is to drastically cut down on the number
>>> of different DTs required, each different for each board with minute
>>> differences from one another.
>>
>> We're on the same page then :)
>>
>
> Heh :)
>
>>> In your case you have boards that have no way to be probed about
>>> what they ?are?, but that?s no big problem. You can easily pass the
>>> board variant in the kernel command line and use that to select the
>>> quirk to apply.
>>
>> Hans actually pointed out that this would just move the logic
>> somewhere else, but not remove it. In our case, that would mean U-Boot
>> (Hans being the U-Boot maintainer for the SoCs that are used in this
>> particular board).
>>
>> That would still require us to have a different configuration and to
>> add some logic to pass that extra parameter to the kernel. I'd be glad
>> to have less stuff in the kernel, but I can understand that he doesn't
>> want more stuff either.
>>
>
> Well, I don?t know the specifics of your board, but if you have a configuration
> subset that works for all the boards and makes it at least possible to load
> a kernel (i.e. ram, serial, storage) you can keep a single bootloader that?s not
> full featured, but at least can boot any kind of variant.
>
> Afterwards you can just update the bootargs variable to the correct one for
> a given board.

We're talking about tablets here and uboot supports the lcd, as that is the only
way to show errors loading the kernel / show a boot menu, etc.

Show u-boot will know which lcd is present (by the user having flashed
the right u-boot binary for his model or so we hope). So I really think
that this is something which u-boot should pass along in our case.

Talking about how this will all work in the future would it be possible
for u-boot to pass this info via devicetree rather then the kernel commandline?

In general we try not to mangle the cmdline in u-boot, while otoh we already
patch plenty of stuff into the dtb like memory size and such :)

Regards,

Hans

[PATCH v2 6/6] ARM: sun8i: dts: Add Ippo-q8h v1.2 with A33 and 1024x600 lcd support

[Pantelis Antoniou]

Hi Hans,

> On Jun 17, 2015, at 10:19 , Hans de Goede <hdegoede@redhat.com> wrote:
> 
> Hi,
> 
> On 16-06-15 21:33, Pantelis Antoniou wrote:
>> Hi Maxime,
>> 
>>> On Jun 16, 2015, at 20:55 , Maxime Ripard <maxime.ripard@free-electrons.com> wrote:
>>> 
>>> Hi Pantelis,
>>> 
>>> On Sun, Jun 14, 2015 at 09:16:21PM +0300, Pantelis Antoniou wrote:
>>>>> I think we need to discuss this with Pantelis and what is his feeling
>>>>> about this.
>>>>> 
>>>>> Pantelis, to sum things up, we have a case of a tablet that comes with
>>>>> the exact same board, but coming in two flavours with two differents
>>>>> screen resolutions. It looks like a great case for your DT quirks
>>>>> work, but we have no way of runtime detecting the difference between
>>>>> the two variants. What do you think about this? Should we go with
>>>>> using the DT quirks or is this simply out of scope?
>>>>> 
>>>>> There's not so much example of similar cases in the kernel, and none
>>>>> of them use quirks so far (obviously) but they all boil down to either
>>>>> the solution you were suggesting in that patch or adding the alternate
>>>>> configuration as a comment.
>>>>> 
>>>>> I don't think the latter would work for you, and I agree with that, so
>>>>> I guess that depending on what Pantelis says, either we go with a
>>>>> better solution using the quirks, or we end up using what you
>>>>> suggested (with a nitpick though, I'd prefer if you used the display
>>>>> standard instead of the resolution, which would make it xga I guess?)
>>>>> 
>>>> 
>>>> First of all, the quirks interface is at an RFC stage (new name
>>>> suggested is ?variants?); getting that out of the way this seems
>>>> like what it is designed to do.
>>>> 
>>>> The idea of the DT quirks is to drastically cut down on the number
>>>> of different DTs required, each different for each board with minute
>>>> differences from one another.
>>> 
>>> We're on the same page then :)
>>> 
>> 
>> Heh :)
>> 
>>>> In your case you have boards that have no way to be probed about
>>>> what they ?are?, but that?s no big problem. You can easily pass the
>>>> board variant in the kernel command line and use that to select the
>>>> quirk to apply.
>>> 
>>> Hans actually pointed out that this would just move the logic
>>> somewhere else, but not remove it. In our case, that would mean U-Boot
>>> (Hans being the U-Boot maintainer for the SoCs that are used in this
>>> particular board).
>>> 
>>> That would still require us to have a different configuration and to
>>> add some logic to pass that extra parameter to the kernel. I'd be glad
>>> to have less stuff in the kernel, but I can understand that he doesn't
>>> want more stuff either.
>>> 
>> 
>> Well, I don?t know the specifics of your board, but if you have a configuration
>> subset that works for all the boards and makes it at least possible to load
>> a kernel (i.e. ram, serial, storage) you can keep a single bootloader that?s not
>> full featured, but at least can boot any kind of variant.
>> 
>> Afterwards you can just update the bootargs variable to the correct one for
>> a given board.
> 
> We're talking about tablets here and uboot supports the lcd, as that is the only
> way to show errors loading the kernel / show a boot menu, etc.
> 

I see.

> Show u-boot will know which lcd is present (by the user having flashed
> the right u-boot binary for his model or so we hope). So I really think
> that this is something which u-boot should pass along in our case.
> 
> Talking about how this will all work in the future would it be possible
> for u-boot to pass this info via devicetree rather then the kernel commandline?
> 

You can already pass it. There?s a compatible property on root in each DT blob.
It?s a string property list that goes from most specific to least specific.

You can always tack a most specific compatible in front and that?s what the
quirks/variant can pick to apply changes. 

I would try to ask Grant or Rob about what they think too however.

> In general we try not to mangle the cmdline in u-boot, while otoh we already
> patch plenty of stuff into the dtb like memory size and such :)
> 

FWIW if you pass a cmdline you already mangle the DT, since it is put in the
chosen node as such.

So there?s mangling already you just got to decide where and what to mangle. :)

> Regards,
> 
> Hans

Regards

? Pantelis

[PATCH v2 6/6] ARM: sun8i: dts: Add Ippo-q8h v1.2 with A33 and 1024x600 lcd support

[Hans de Goede]

Hi,

On 16-06-15 19:55, Maxime Ripard wrote:
> Hi Pantelis,
>
> On Sun, Jun 14, 2015 at 09:16:21PM +0300, Pantelis Antoniou wrote:
>>> I think we need to discuss this with Pantelis and what is his feeling
>>> about this.
>>>
>>> Pantelis, to sum things up, we have a case of a tablet that comes with
>>> the exact same board, but coming in two flavours with two differents
>>> screen resolutions. It looks like a great case for your DT quirks
>>> work, but we have no way of runtime detecting the difference between
>>> the two variants. What do you think about this? Should we go with
>>> using the DT quirks or is this simply out of scope?
>>>
>>> There's not so much example of similar cases in the kernel, and none
>>> of them use quirks so far (obviously) but they all boil down to either
>>> the solution you were suggesting in that patch or adding the alternate
>>> configuration as a comment.
>>>
>>> I don't think the latter would work for you, and I agree with that, so
>>> I guess that depending on what Pantelis says, either we go with a
>>> better solution using the quirks, or we end up using what you
>>> suggested (with a nitpick though, I'd prefer if you used the display
>>> standard instead of the resolution, which would make it xga I guess?)
>>>
>>
>> First of all, the quirks interface is at an RFC stage (new name
>> suggested is ?variants?); getting that out of the way this seems
>> like what it is designed to do.
>>
>> The idea of the DT quirks is to drastically cut down on the number
>> of different DTs required, each different for each board with minute
>> differences from one another.
>
> We're on the same page then :)
>
>> In your case you have boards that have no way to be probed about
>> what they ?are?, but that?s no big problem. You can easily pass the
>> board variant in the kernel command line and use that to select the
>> quirk to apply.
>
> Hans actually pointed out that this would just move the logic
> somewhere else, but not remove it. In our case, that would mean U-Boot
> (Hans being the U-Boot maintainer for the SoCs that are used in this
> particular board).
>
> That would still require us to have a different configuration and to
> add some logic to pass that extra parameter to the kernel. I'd be glad
> to have less stuff in the kernel, but I can understand that he doesn't
> want more stuff either.
>
>> In fact the original patchset does contain a command line quirk for
>> enabling and disabling the onboard emmc & hdmi of the beaglebone
>> black for capes that need to use those signals.
>
> Ah. I somehow overlooked that when reading it.
>
>> Saying that, if you?re in a hurry I?d say go with a different DTSs
>> for now, since that?s going to go in a near kernel cycle; DT quirks
>> will be discussed at plumber?s in a couple of months, and then we?ll
>> if it will go in and in what form.
>
> Ok. I won't be here this year, but if you could raise the topic of how
> to handle "non-discoverable boards" then, it would be great.
>
> Hans, I guess we can go for your suggestion then: apply a "generic" DT
> for the board right now, we're going to need it anyway. Then, when
> will have real display support, depending on the current state of the
> discussion for the quirks, we will either merge a different DT
> including the generic one, or if the quirks have something that work
> for both of us then, use the quirks. Sounds good?

Sounds good to me, will you make the changes while merging, or shall
I do a new version of the patch ?

Regards,

Hans

[PATCH v2 6/6] ARM: sun8i: dts: Add Ippo-q8h v1.2 with A33 and 1024x600 lcd support

[Maxime Ripard]

On Wed, Jun 17, 2015 at 09:16:41AM +0200, Hans de Goede wrote:
> Hi,
> 
> On 16-06-15 19:55, Maxime Ripard wrote:
> >Hi Pantelis,
> >
> >On Sun, Jun 14, 2015 at 09:16:21PM +0300, Pantelis Antoniou wrote:
> >>>I think we need to discuss this with Pantelis and what is his feeling
> >>>about this.
> >>>
> >>>Pantelis, to sum things up, we have a case of a tablet that comes with
> >>>the exact same board, but coming in two flavours with two differents
> >>>screen resolutions. It looks like a great case for your DT quirks
> >>>work, but we have no way of runtime detecting the difference between
> >>>the two variants. What do you think about this? Should we go with
> >>>using the DT quirks or is this simply out of scope?
> >>>
> >>>There's not so much example of similar cases in the kernel, and none
> >>>of them use quirks so far (obviously) but they all boil down to either
> >>>the solution you were suggesting in that patch or adding the alternate
> >>>configuration as a comment.
> >>>
> >>>I don't think the latter would work for you, and I agree with that, so
> >>>I guess that depending on what Pantelis says, either we go with a
> >>>better solution using the quirks, or we end up using what you
> >>>suggested (with a nitpick though, I'd prefer if you used the display
> >>>standard instead of the resolution, which would make it xga I guess?)
> >>>
> >>
> >>First of all, the quirks interface is at an RFC stage (new name
> >>suggested is ?variants?); getting that out of the way this seems
> >>like what it is designed to do.
> >>
> >>The idea of the DT quirks is to drastically cut down on the number
> >>of different DTs required, each different for each board with minute
> >>differences from one another.
> >
> >We're on the same page then :)
> >
> >>In your case you have boards that have no way to be probed about
> >>what they ?are?, but that?s no big problem. You can easily pass the
> >>board variant in the kernel command line and use that to select the
> >>quirk to apply.
> >
> >Hans actually pointed out that this would just move the logic
> >somewhere else, but not remove it. In our case, that would mean U-Boot
> >(Hans being the U-Boot maintainer for the SoCs that are used in this
> >particular board).
> >
> >That would still require us to have a different configuration and to
> >add some logic to pass that extra parameter to the kernel. I'd be glad
> >to have less stuff in the kernel, but I can understand that he doesn't
> >want more stuff either.
> >
> >>In fact the original patchset does contain a command line quirk for
> >>enabling and disabling the onboard emmc & hdmi of the beaglebone
> >>black for capes that need to use those signals.
> >
> >Ah. I somehow overlooked that when reading it.
> >
> >>Saying that, if you?re in a hurry I?d say go with a different DTSs
> >>for now, since that?s going to go in a near kernel cycle; DT quirks
> >>will be discussed at plumber?s in a couple of months, and then we?ll
> >>if it will go in and in what form.
> >
> >Ok. I won't be here this year, but if you could raise the topic of how
> >to handle "non-discoverable boards" then, it would be great.
> >
> >Hans, I guess we can go for your suggestion then: apply a "generic" DT
> >for the board right now, we're going to need it anyway. Then, when
> >will have real display support, depending on the current state of the
> >discussion for the quirks, we will either merge a different DT
> >including the generic one, or if the quirks have something that work
> >for both of us then, use the quirks. Sounds good?
> 
> Sounds good to me, will you make the changes while merging, or shall
> I do a new version of the patch ?

I'll apply and fix.

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150618/f8946e28/attachment.sig>

[linux-sunxi] [PATCH v2 0/6] Introduce Allwinner A33 support

[jonsmirl at gmail.com]

Is the A33 Lollipop SDK somewhere?

On Sat, May 30, 2015 at 10:55 AM, Hans de Goede <hdegoede@redhat.com> wrote:
> Hi Maxime,
>
> Here is a cleaned up series of Vishnu Patekar's A33 support. This should
> address all concerns raised during the posting of v1.
>
> I've tested that all peripherals declared in the shared sun8i-a23-a33.dtsi
> work on the A33 too, with the exception of the dma-controller. For the
> dma-controller I've compared the A23 vs A33 manual and the entire dma-
> controller description including the register description is bit for bit
> identical.
>
> This has been tested on a 7" Ippo Q8H v1.2 A23 tablet, a 7" Ippo Q8H v1.2
> A33 tablet and a 10" GA10H A33 tablet. The dts for the 10" tablet still
> needs some work wrt the lradc button voltages so that is not included
> in this set.
>
> Regards,
>
> Hans
>
> --
> You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe at googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.



-- 
Jon Smirl
jonsmirl at gmail.com

[PATCH v2 0/6] Introduce Allwinner A33 support

[Chen-Yu Tsai]

On Sat, May 30, 2015 at 10:55 PM, Hans de Goede <hdegoede@redhat.com> wrote:
> Hi Maxime,
>
> Here is a cleaned up series of Vishnu Patekar's A33 support. This should
> address all concerns raised during the posting of v1.
>
> I've tested that all peripherals declared in the shared sun8i-a23-a33.dtsi
> work on the A33 too, with the exception of the dma-controller. For the
> dma-controller I've compared the A23 vs A33 manual and the entire dma-
> controller description including the register description is bit for bit
> identical.
>
> This has been tested on a 7" Ippo Q8H v1.2 A23 tablet, a 7" Ippo Q8H v1.2
> A33 tablet and a 10" GA10H A33 tablet. The dts for the 10" tablet still
> needs some work wrt the lradc button voltages so that is not included
> in this set.

Whole series is

Tested-by: Chen-Yu Tsai <wens@csie.org>

on my Sinlinx SinA33 dev board. I'll send patches for it later.

[PATCH v2 0/6] Introduce Allwinner A33 support

[ernestovm07 at gmail.com]

El s?bado, 30 de mayo de 2015, 9:55:10 (UTC-5), Hans de Goede escribi?:
> Hi Maxime,
> 
> Here is a cleaned up series of Vishnu Patekar's A33 support. This should
> address all concerns raised during the posting of v1.
> 
> I've tested that all peripherals declared in the shared sun8i-a23-a33.dtsi
> work on the A33 too, with the exception of the dma-controller. For the
> dma-controller I've compared the A23 vs A33 manual and the entire dma-
> controller description including the register description is bit for bit
> identical.
> 
> This has been tested on a 7" Ippo Q8H v1.2 A23 tablet, a 7" Ippo Q8H v1.2
> A33 tablet and a 10" GA10H A33 tablet. The dts for the 10" tablet still
> needs some work wrt the lradc button voltages so that is not included
> in this set.
> 
> Regards,
> 
> Hans

http://hp7g2.blogspot.com