* [PATCH v2 0/6] Introduce Allwinner A33 support
@ 2015-05-30 14:55 Hans de Goede
[not found] ` <1432997706-20172-1-git-send-email-hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2016-06-13 19:10 ` ernestovm07
0 siblings, 2 replies; 33+ messages in thread
From: Hans de Goede @ 2015-05-30 14:55 UTC (permalink / raw)
To: Maxime Ripard
Cc: Chen-Yu Tsai, Vishnu Patekar,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, devicetree,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
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
^ permalink raw reply [flat|nested] 33+ messages in thread[parent not found: <1432997706-20172-1-git-send-email-hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>]
* [PATCH v2 1/6] ARM: sunxi: Add Machine support for A33 [not found] ` <1432997706-20172-1-git-send-email-hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> @ 2015-05-30 14:55 ` Hans de Goede [not found] ` <1432997706-20172-2-git-send-email-hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> 2015-05-30 14:55 ` [PATCH v2 2/6] pinctrl: sunxi: Add allwinner A33 PIO controller support Hans de Goede ` (6 subsequent siblings) 7 siblings, 1 reply; 33+ messages in thread From: Hans de Goede @ 2015-05-30 14:55 UTC (permalink / raw) To: Maxime Ripard Cc: Chen-Yu Tsai, Vishnu Patekar, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, devicetree, linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, Hans de Goede From: Vishnu Patekar <vishnupatekar0510-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> Signed-off-by: Hans de Goede <hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> --- 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 ^ permalink raw reply related [flat|nested] 33+ messages in thread
[parent not found: <1432997706-20172-2-git-send-email-hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>]
* Re: [PATCH v2 1/6] ARM: sunxi: Add Machine support for A33 [not found] ` <1432997706-20172-2-git-send-email-hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> @ 2015-06-02 7:28 ` Maxime Ripard 0 siblings, 0 replies; 33+ messages in thread From: Maxime Ripard @ 2015-06-02 7:28 UTC (permalink / raw) To: Hans de Goede Cc: Chen-Yu Tsai, Vishnu Patekar, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, devicetree, linux-sunxi-/JYPxA39Uh5TLH3MbocFFw [-- Attachment #1: Type: text/plain, Size: 569 bytes --] On Sat, May 30, 2015 at 04:55:01PM +0200, Hans de Goede wrote: > From: Vishnu Patekar <vishnupatekar0510-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> > > 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-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> > Signed-off-by: Hans de Goede <hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> Applied, thanks! Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com ^ permalink raw reply [flat|nested] 33+ messages in thread
* [PATCH v2 2/6] pinctrl: sunxi: Add allwinner A33 PIO controller support [not found] ` <1432997706-20172-1-git-send-email-hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> 2015-05-30 14:55 ` [PATCH v2 1/6] ARM: sunxi: Add Machine support for A33 Hans de Goede @ 2015-05-30 14:55 ` Hans de Goede 2015-05-30 14:55 ` [PATCH v2 3/6] ARM: dts: sun8i: Add sun8i-a23-a33 dtsi Hans de Goede ` (5 subsequent siblings) 7 siblings, 0 replies; 33+ messages in thread From: Hans de Goede @ 2015-05-30 14:55 UTC (permalink / raw) To: Maxime Ripard Cc: Chen-Yu Tsai, Vishnu Patekar, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, devicetree, linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, Hans de Goede From: Vishnu Patekar <vishnupatekar0510-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> A33 PIO has 7 ports which starts from PB and has two interrupt ports. Signed-off-by: Vishnu Patekar <vishnupatekar0510-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> Acked-by: Hans de Goede <hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> Acked-by: Maxime Ripard <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> Signed-off-by: Hans de Goede <hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> --- .../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-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> + * + * Based on pinctrl-sun8i-a23.c, which is: + * Copyright (C) 2014 Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org> + * Copyright (C) 2014 Maxime Ripard <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> + * + * 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-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>"); +MODULE_DESCRIPTION("Allwinner a33 pinctrl driver"); +MODULE_LICENSE("GPL"); -- 2.4.1 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply related [flat|nested] 33+ messages in thread
* [PATCH v2 3/6] ARM: dts: sun8i: Add sun8i-a23-a33 dtsi [not found] ` <1432997706-20172-1-git-send-email-hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> 2015-05-30 14:55 ` [PATCH v2 1/6] ARM: sunxi: Add Machine support for A33 Hans de Goede 2015-05-30 14:55 ` [PATCH v2 2/6] pinctrl: sunxi: Add allwinner A33 PIO controller support Hans de Goede @ 2015-05-30 14:55 ` Hans de Goede [not found] ` <1432997706-20172-4-git-send-email-hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> 2015-05-30 14:55 ` [PATCH v2 4/6] ARM: dts: sun8i: Add sun8i-a33 dtsi Hans de Goede ` (4 subsequent siblings) 7 siblings, 1 reply; 33+ messages in thread From: Hans de Goede @ 2015-05-30 14:55 UTC (permalink / raw) To: Maxime Ripard Cc: Chen-Yu Tsai, Vishnu Patekar, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, devicetree, linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, Hans de Goede From: Vishnu Patekar <vishnupatekar0510-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> Signed-off-by: Hans de Goede <hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> --- 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@01c2015c { - #clock-cells = <0>; - compatible = "allwinner,sun8i-a23-mbus-clk"; - reg = <0x01c2015c 0x4>; - clocks = <&osc24M>, <&pll6 1>, <&pll5>; - clock-output-names = "mbus"; - }; }; soc@01c00000 { @@ -335,11 +323,9 @@ }; pio: pinctrl@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@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@0 { - compatible = "arm,cortex-a7"; - device_type = "cpu"; - reg = <0>; - }; - - cpu@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@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@01c20028 { - #clock-cells = <1>; - compatible = "allwinner,sun6i-a31-pll6-clk"; - reg = <0x01c20028 0x4>; - clocks = <&osc24M>; - clock-output-names = "pll6", "pll6x2"; - }; - - cpu: cpu_clk@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@01c20050 { - #clock-cells = <0>; - compatible = "allwinner,sun8i-a23-axi-clk"; - reg = <0x01c20050 0x4>; - clocks = <&cpu>; - clock-output-names = "axi"; - }; - - ahb1: ahb1_clk@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@01c20054 { - #clock-cells = <0>; - compatible = "allwinner,sun4i-a10-apb0-clk"; - reg = <0x01c20054 0x4>; - clocks = <&ahb1>; - clock-output-names = "apb1"; - }; - - ahb1_gates: clk@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@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@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@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@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@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@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@01c2015c { #clock-cells = <0>; compatible = "allwinner,sun8i-a23-mbus-clk"; @@ -261,370 +58,11 @@ clock-output-names = "mbus"; }; }; +}; - soc@01c00000 { - compatible = "simple-bus"; - #address-cells = <1>; - #size-cells = <1>; - ranges; - - dma: dma-controller@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@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@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@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@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@0 { - allwinner,pins = "PF2", "PF4"; - allwinner,function = "uart0"; - allwinner,drive = <SUN4I_PINCTRL_10_MA>; - allwinner,pull = <SUN4I_PINCTRL_NO_PULL>; - }; - - mmc0_pins_a: mmc0@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@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@0 { - allwinner,pins = "PH2", "PH3"; - allwinner,function = "i2c0"; - allwinner,drive = <SUN4I_PINCTRL_10_MA>; - allwinner,pull = <SUN4I_PINCTRL_NO_PULL>; - }; - - i2c1_pins_a: i2c1@0 { - allwinner,pins = "PH4", "PH5"; - allwinner,function = "i2c1"; - allwinner,drive = <SUN4I_PINCTRL_10_MA>; - allwinner,pull = <SUN4I_PINCTRL_NO_PULL>; - }; - - i2c2_pins_a: i2c2@0 { - allwinner,pins = "PE12", "PE13"; - allwinner,function = "i2c2"; - allwinner,drive = <SUN4I_PINCTRL_10_MA>; - allwinner,pull = <SUN4I_PINCTRL_NO_PULL>; - }; - }; - - ahb1_rst: reset@01c202c0 { - #reset-cells = <1>; - compatible = "allwinner,sun6i-a31-clock-reset"; - reg = <0x01c202c0 0xc>; - }; - - apb1_rst: reset@01c202d0 { - #reset-cells = <1>; - compatible = "allwinner,sun6i-a31-clock-reset"; - reg = <0x01c202d0 0x4>; - }; - - apb2_rst: reset@01c202d8 { - #reset-cells = <1>; - compatible = "allwinner,sun6i-a31-clock-reset"; - reg = <0x01c202d8 0x4>; - }; - - timer@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@01c20ca0 { - compatible = "allwinner,sun6i-a31-wdt"; - reg = <0x01c20ca0 0x20>; - interrupts = <GIC_SPI 25 IRQ_TYPE_LEVEL_HIGH>; - }; - - lradc: lradc@01c22800 { - compatible = "allwinner,sun4i-a10-lradc-keys"; - reg = <0x01c22800 0x100>; - interrupts = <GIC_SPI 30 IRQ_TYPE_LEVEL_HIGH>; - status = "disabled"; - }; - - uart0: serial@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@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@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@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@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@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@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@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@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@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@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@01f01c00 { - compatible = "allwinner,sun8i-a23-cpuconfig"; - reg = <0x01f01c00 0x300>; - }; - - r_uart: serial@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@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@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 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply related [flat|nested] 33+ messages in thread
[parent not found: <1432997706-20172-4-git-send-email-hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>]
* Re: [PATCH v2 3/6] ARM: dts: sun8i: Add sun8i-a23-a33 dtsi [not found] ` <1432997706-20172-4-git-send-email-hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> @ 2015-06-02 7:51 ` Maxime Ripard 2015-06-02 8:08 ` Hans de Goede 0 siblings, 1 reply; 33+ messages in thread From: Maxime Ripard @ 2015-06-02 7:51 UTC (permalink / raw) To: Hans de Goede Cc: Chen-Yu Tsai, Vishnu Patekar, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, devicetree, linux-sunxi-/JYPxA39Uh5TLH3MbocFFw [-- Attachment #1: Type: text/plain, Size: 948 bytes --] On Sat, May 30, 2015 at 04:55:03PM +0200, Hans de Goede wrote: > From: Vishnu Patekar <vishnupatekar0510-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> > > 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-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> > Signed-off-by: Hans de Goede <hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> 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 ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [PATCH v2 3/6] ARM: dts: sun8i: Add sun8i-a23-a33 dtsi 2015-06-02 7:51 ` Maxime Ripard @ 2015-06-02 8:08 ` Hans de Goede [not found] ` <556D6487.4010207-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> 0 siblings, 1 reply; 33+ messages in thread From: Hans de Goede @ 2015-06-02 8:08 UTC (permalink / raw) To: Maxime Ripard Cc: Chen-Yu Tsai, Vishnu Patekar, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, devicetree, linux-sunxi-/JYPxA39Uh5TLH3MbocFFw 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-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> >> >> 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-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> >> Signed-off-by: Hans de Goede <hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> > > 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 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 33+ messages in thread
[parent not found: <556D6487.4010207-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>]
* Re: [PATCH v2 3/6] ARM: dts: sun8i: Add sun8i-a23-a33 dtsi [not found] ` <556D6487.4010207-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> @ 2015-06-02 8:21 ` Maxime Ripard 0 siblings, 0 replies; 33+ messages in thread From: Maxime Ripard @ 2015-06-02 8:21 UTC (permalink / raw) To: Hans de Goede Cc: Chen-Yu Tsai, Vishnu Patekar, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, devicetree, linux-sunxi-/JYPxA39Uh5TLH3MbocFFw [-- Attachment #1: Type: text/plain, Size: 2678 bytes --] 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-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> > >> > >>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-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> > >>Signed-off-by: Hans de Goede <hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> > > > >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 ^ permalink raw reply [flat|nested] 33+ messages in thread
* [PATCH v2 4/6] ARM: dts: sun8i: Add sun8i-a33 dtsi [not found] ` <1432997706-20172-1-git-send-email-hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> ` (2 preceding siblings ...) 2015-05-30 14:55 ` [PATCH v2 3/6] ARM: dts: sun8i: Add sun8i-a23-a33 dtsi Hans de Goede @ 2015-05-30 14:55 ` Hans de Goede [not found] ` <1432997706-20172-5-git-send-email-hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> 2015-05-30 14:55 ` [PATCH v2 5/6] ARM: dts: sun8i: Add ET-Q8 A33 support Hans de Goede ` (3 subsequent siblings) 7 siblings, 1 reply; 33+ messages in thread From: Hans de Goede @ 2015-05-30 14:55 UTC (permalink / raw) To: Maxime Ripard Cc: Chen-Yu Tsai, Vishnu Patekar, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, devicetree, linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, Hans de Goede From: Vishnu Patekar <vishnupatekar0510-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> Signed-off-by: Hans de Goede <hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> --- 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-jdAy2FN1RRM@public.gmane.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@2 { + compatible = "arm,cortex-a7"; + device_type = "cpu"; + reg = <2>; + }; + + cpu@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@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 ^ permalink raw reply related [flat|nested] 33+ messages in thread
[parent not found: <1432997706-20172-5-git-send-email-hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>]
* Re: [PATCH v2 4/6] ARM: dts: sun8i: Add sun8i-a33 dtsi [not found] ` <1432997706-20172-5-git-send-email-hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> @ 2015-06-02 7:55 ` Maxime Ripard 0 siblings, 0 replies; 33+ messages in thread From: Maxime Ripard @ 2015-06-02 7:55 UTC (permalink / raw) To: Hans de Goede Cc: Chen-Yu Tsai, Vishnu Patekar, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, devicetree, linux-sunxi-/JYPxA39Uh5TLH3MbocFFw [-- Attachment #1: Type: text/plain, Size: 551 bytes --] On Sat, May 30, 2015 at 04:55:04PM +0200, Hans de Goede wrote: > From: Vishnu Patekar <vishnupatekar0510-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> > > 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-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> > Signed-off-by: Hans de Goede <hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> Applied, thanks! Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com ^ permalink raw reply [flat|nested] 33+ messages in thread
* [PATCH v2 5/6] ARM: dts: sun8i: Add ET-Q8 A33 support [not found] ` <1432997706-20172-1-git-send-email-hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> ` (3 preceding siblings ...) 2015-05-30 14:55 ` [PATCH v2 4/6] ARM: dts: sun8i: Add sun8i-a33 dtsi Hans de Goede @ 2015-05-30 14:55 ` Hans de Goede [not found] ` <1432997706-20172-6-git-send-email-hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> 2015-05-30 14:55 ` [PATCH v2 6/6] ARM: sun8i: dts: Add Ippo-q8h v1.2 with A33 and 1024x600 lcd support Hans de Goede ` (2 subsequent siblings) 7 siblings, 1 reply; 33+ messages in thread From: Hans de Goede @ 2015-05-30 14:55 UTC (permalink / raw) To: Maxime Ripard Cc: Chen-Yu Tsai, Vishnu Patekar, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, devicetree, linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, Hans de Goede From: Vishnu Patekar <vishnupatekar0510-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> Signed-off-by: Hans de Goede <hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> --- 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-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.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. + */ + +/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 = <®_vcc3v0>; + status = "okay"; + + button@200 { + label = "Volume Up"; + linux,code = <KEY_VOLUMEUP>; + channel = <0>; + voltage = <200000>; + }; + + button@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 ^ permalink raw reply related [flat|nested] 33+ messages in thread
[parent not found: <1432997706-20172-6-git-send-email-hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>]
* Re: [PATCH v2 5/6] ARM: dts: sun8i: Add ET-Q8 A33 support [not found] ` <1432997706-20172-6-git-send-email-hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> @ 2015-06-02 7:56 ` Maxime Ripard 0 siblings, 0 replies; 33+ messages in thread From: Maxime Ripard @ 2015-06-02 7:56 UTC (permalink / raw) To: Hans de Goede Cc: Chen-Yu Tsai, Vishnu Patekar, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, devicetree, linux-sunxi-/JYPxA39Uh5TLH3MbocFFw [-- Attachment #1: Type: text/plain, Size: 617 bytes --] On Sat, May 30, 2015 at 04:55:05PM +0200, Hans de Goede wrote: > From: Vishnu Patekar <vishnupatekar0510-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> > > 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-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> > Signed-off-by: Hans de Goede <hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> Applied, thanks! Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 33+ messages in thread
* [PATCH v2 6/6] ARM: sun8i: dts: Add Ippo-q8h v1.2 with A33 and 1024x600 lcd support [not found] ` <1432997706-20172-1-git-send-email-hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> ` (4 preceding siblings ...) 2015-05-30 14:55 ` [PATCH v2 5/6] ARM: dts: sun8i: Add ET-Q8 A33 support Hans de Goede @ 2015-05-30 14:55 ` Hans de Goede [not found] ` <1432997706-20172-7-git-send-email-hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> 2015-05-30 20:43 ` [PATCH v2 0/6] Introduce Allwinner A33 support jonsmirl-Re5JQEeQqe8AvxtiuMwx3w 2015-06-02 7:43 ` Chen-Yu Tsai 7 siblings, 1 reply; 33+ messages in thread From: Hans de Goede @ 2015-05-30 14:55 UTC (permalink / raw) To: Maxime Ripard Cc: Chen-Yu Tsai, Vishnu Patekar, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, devicetree, linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, 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-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> --- 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-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.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. + */ + +/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 = <®_vcc3v0>; + status = "okay"; + + button@200 { + label = "Volume Up"; + linux,code = <KEY_VOLUMEUP>; + channel = <0>; + voltage = <200000>; + }; + + button@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 = <®_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@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 ^ permalink raw reply related [flat|nested] 33+ messages in thread
[parent not found: <1432997706-20172-7-git-send-email-hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>]
* Re: [PATCH v2 6/6] ARM: sun8i: dts: Add Ippo-q8h v1.2 with A33 and 1024x600 lcd support [not found] ` <1432997706-20172-7-git-send-email-hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> @ 2015-06-02 8:14 ` Maxime Ripard 2015-06-02 8:29 ` Hans de Goede 0 siblings, 1 reply; 33+ messages in thread From: Maxime Ripard @ 2015-06-02 8:14 UTC (permalink / raw) To: Hans de Goede Cc: Chen-Yu Tsai, Vishnu Patekar, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, devicetree, linux-sunxi-/JYPxA39Uh5TLH3MbocFFw [-- Attachment #1: Type: text/plain, Size: 835 bytes --] 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 ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [PATCH v2 6/6] ARM: sun8i: dts: Add Ippo-q8h v1.2 with A33 and 1024x600 lcd support 2015-06-02 8:14 ` Maxime Ripard @ 2015-06-02 8:29 ` Hans de Goede [not found] ` <556D6955.8030708-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> 0 siblings, 1 reply; 33+ messages in thread From: Hans de Goede @ 2015-06-02 8:29 UTC (permalink / raw) To: Maxime Ripard Cc: Chen-Yu Tsai, Vishnu Patekar, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, devicetree, linux-sunxi-/JYPxA39Uh5TLH3MbocFFw 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 ^ permalink raw reply [flat|nested] 33+ messages in thread
[parent not found: <556D6955.8030708-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>]
* Re: [PATCH v2 6/6] ARM: sun8i: dts: Add Ippo-q8h v1.2 with A33 and 1024x600 lcd support [not found] ` <556D6955.8030708-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> @ 2015-06-03 9:45 ` Maxime Ripard 2015-06-03 11:12 ` Hans de Goede 0 siblings, 1 reply; 33+ messages in thread From: Maxime Ripard @ 2015-06-03 9:45 UTC (permalink / raw) To: Hans de Goede Cc: Chen-Yu Tsai, Vishnu Patekar, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, devicetree, linux-sunxi-/JYPxA39Uh5TLH3MbocFFw [-- Attachment #1: Type: text/plain, Size: 2692 bytes --] 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 [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [PATCH v2 6/6] ARM: sun8i: dts: Add Ippo-q8h v1.2 with A33 and 1024x600 lcd support 2015-06-03 9:45 ` Maxime Ripard @ 2015-06-03 11:12 ` Hans de Goede [not found] ` <556EE104.3090803-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> 0 siblings, 1 reply; 33+ messages in thread From: Hans de Goede @ 2015-06-03 11:12 UTC (permalink / raw) To: Maxime Ripard Cc: Chen-Yu Tsai, Vishnu Patekar, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, devicetree, linux-sunxi-/JYPxA39Uh5TLH3MbocFFw 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 ^ permalink raw reply [flat|nested] 33+ messages in thread
[parent not found: <556EE104.3090803-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>]
* Re: [PATCH v2 6/6] ARM: sun8i: dts: Add Ippo-q8h v1.2 with A33 and 1024x600 lcd support [not found] ` <556EE104.3090803-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> @ 2015-06-13 13:50 ` Maxime Ripard 2015-06-13 14:18 ` Hans de Goede 2015-06-14 18:16 ` Pantelis Antoniou 0 siblings, 2 replies; 33+ messages in thread From: Maxime Ripard @ 2015-06-13 13:50 UTC (permalink / raw) To: Hans de Goede, Pantelis Antoniou Cc: Chen-Yu Tsai, Vishnu Patekar, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, devicetree, linux-sunxi-/JYPxA39Uh5TLH3MbocFFw [-- Attachment #1: Type: text/plain, Size: 4828 bytes --] 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 ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [PATCH v2 6/6] ARM: sun8i: dts: Add Ippo-q8h v1.2 with A33 and 1024x600 lcd support 2015-06-13 13:50 ` Maxime Ripard @ 2015-06-13 14:18 ` Hans de Goede [not found] ` <557C3BD3.6030105-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> 2015-06-14 18:16 ` Pantelis Antoniou 1 sibling, 1 reply; 33+ messages in thread From: Hans de Goede @ 2015-06-13 14:18 UTC (permalink / raw) To: Maxime Ripard, Pantelis Antoniou Cc: Chen-Yu Tsai, Vishnu Patekar, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, devicetree, linux-sunxi-/JYPxA39Uh5TLH3MbocFFw 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 > -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 33+ messages in thread
[parent not found: <557C3BD3.6030105-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>]
* Re: [PATCH v2 6/6] ARM: sun8i: dts: Add Ippo-q8h v1.2 with A33 and 1024x600 lcd support [not found] ` <557C3BD3.6030105-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> @ 2015-06-16 17:41 ` Maxime Ripard 2015-06-17 7:16 ` Hans de Goede 0 siblings, 1 reply; 33+ messages in thread From: Maxime Ripard @ 2015-06-16 17:41 UTC (permalink / raw) To: Hans de Goede Cc: Pantelis Antoniou, Chen-Yu Tsai, Vishnu Patekar, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, devicetree, linux-sunxi-/JYPxA39Uh5TLH3MbocFFw [-- Attachment #1: Type: text/plain, Size: 2082 bytes --] 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 ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [PATCH v2 6/6] ARM: sun8i: dts: Add Ippo-q8h v1.2 with A33 and 1024x600 lcd support 2015-06-16 17:41 ` Maxime Ripard @ 2015-06-17 7:16 ` Hans de Goede [not found] ` <55811EB2.4060302-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> 0 siblings, 1 reply; 33+ messages in thread From: Hans de Goede @ 2015-06-17 7:16 UTC (permalink / raw) To: Maxime Ripard Cc: Pantelis Antoniou, Chen-Yu Tsai, Vishnu Patekar, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, devicetree, linux-sunxi-/JYPxA39Uh5TLH3MbocFFw 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 ^ permalink raw reply [flat|nested] 33+ messages in thread
[parent not found: <55811EB2.4060302-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>]
* Re: [PATCH v2 6/6] ARM: sun8i: dts: Add Ippo-q8h v1.2 with A33 and 1024x600 lcd support [not found] ` <55811EB2.4060302-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> @ 2015-06-18 18:37 ` Maxime Ripard 2015-06-18 20:16 ` Hans de Goede 0 siblings, 1 reply; 33+ messages in thread From: Maxime Ripard @ 2015-06-18 18:37 UTC (permalink / raw) To: Hans de Goede Cc: Pantelis Antoniou, Chen-Yu Tsai, Vishnu Patekar, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, devicetree, linux-sunxi-/JYPxA39Uh5TLH3MbocFFw [-- Attachment #1: Type: text/plain, Size: 2629 bytes --] 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 ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [PATCH v2 6/6] ARM: sun8i: dts: Add Ippo-q8h v1.2 with A33 and 1024x600 lcd support 2015-06-18 18:37 ` Maxime Ripard @ 2015-06-18 20:16 ` Hans de Goede 0 siblings, 0 replies; 33+ messages in thread From: Hans de Goede @ 2015-06-18 20:16 UTC (permalink / raw) To: Maxime Ripard Cc: Pantelis Antoniou, Chen-Yu Tsai, Vishnu Patekar, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, devicetree, linux-sunxi-/JYPxA39Uh5TLH3MbocFFw 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 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [PATCH v2 6/6] ARM: sun8i: dts: Add Ippo-q8h v1.2 with A33 and 1024x600 lcd support 2015-06-13 13:50 ` Maxime Ripard 2015-06-13 14:18 ` Hans de Goede @ 2015-06-14 18:16 ` Pantelis Antoniou [not found] ` <85E62D2D-5387-433B-A944-7F2145459F08-OWPKS81ov/FWk0Htik3J/w@public.gmane.org> 1 sibling, 1 reply; 33+ messages in thread From: Pantelis Antoniou @ 2015-06-14 18:16 UTC (permalink / raw) To: Maxime Ripard Cc: Hans de Goede, Chen-Yu Tsai, Vishnu Patekar, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, devicetree, linux-sunxi-/JYPxA39Uh5TLH3MbocFFw 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 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 33+ messages in thread
[parent not found: <85E62D2D-5387-433B-A944-7F2145459F08-OWPKS81ov/FWk0Htik3J/w@public.gmane.org>]
* Re: [PATCH v2 6/6] ARM: sun8i: dts: Add Ippo-q8h v1.2 with A33 and 1024x600 lcd support [not found] ` <85E62D2D-5387-433B-A944-7F2145459F08-OWPKS81ov/FWk0Htik3J/w@public.gmane.org> @ 2015-06-16 17:55 ` Maxime Ripard 2015-06-16 19:33 ` Pantelis Antoniou 2015-06-17 7:16 ` Hans de Goede 0 siblings, 2 replies; 33+ messages in thread From: Maxime Ripard @ 2015-06-16 17:55 UTC (permalink / raw) To: Pantelis Antoniou Cc: Hans de Goede, Chen-Yu Tsai, Vishnu Patekar, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, devicetree, linux-sunxi-/JYPxA39Uh5TLH3MbocFFw [-- Attachment #1: Type: text/plain, Size: 3825 bytes --] 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 -- 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-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit https://groups.google.com/d/optout. [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [PATCH v2 6/6] ARM: sun8i: dts: Add Ippo-q8h v1.2 with A33 and 1024x600 lcd support 2015-06-16 17:55 ` Maxime Ripard @ 2015-06-16 19:33 ` Pantelis Antoniou [not found] ` <D4216F2D-0556-4849-B1DF-8E4D250006B4-OWPKS81ov/FWk0Htik3J/w@public.gmane.org> 2015-06-17 7:16 ` Hans de Goede 1 sibling, 1 reply; 33+ messages in thread From: Pantelis Antoniou @ 2015-06-16 19:33 UTC (permalink / raw) To: Maxime Ripard Cc: Hans de Goede, Chen-Yu Tsai, Vishnu Patekar, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, devicetree, linux-sunxi-/JYPxA39Uh5TLH3MbocFFw 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 -- 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-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit https://groups.google.com/d/optout. ^ permalink raw reply [flat|nested] 33+ messages in thread
[parent not found: <D4216F2D-0556-4849-B1DF-8E4D250006B4-OWPKS81ov/FWk0Htik3J/w@public.gmane.org>]
* Re: [PATCH v2 6/6] ARM: sun8i: dts: Add Ippo-q8h v1.2 with A33 and 1024x600 lcd support [not found] ` <D4216F2D-0556-4849-B1DF-8E4D250006B4-OWPKS81ov/FWk0Htik3J/w@public.gmane.org> @ 2015-06-17 7:19 ` Hans de Goede [not found] ` <55811F94.3080608-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> 0 siblings, 1 reply; 33+ messages in thread From: Hans de Goede @ 2015-06-17 7:19 UTC (permalink / raw) To: Pantelis Antoniou, Maxime Ripard Cc: Chen-Yu Tsai, Vishnu Patekar, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, devicetree, linux-sunxi-/JYPxA39Uh5TLH3MbocFFw 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 -- 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-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit https://groups.google.com/d/optout. ^ permalink raw reply [flat|nested] 33+ messages in thread
[parent not found: <55811F94.3080608-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>]
* Re: [PATCH v2 6/6] ARM: sun8i: dts: Add Ippo-q8h v1.2 with A33 and 1024x600 lcd support [not found] ` <55811F94.3080608-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> @ 2015-06-17 7:26 ` Pantelis Antoniou 0 siblings, 0 replies; 33+ messages in thread From: Pantelis Antoniou @ 2015-06-17 7:26 UTC (permalink / raw) To: Hans de Goede Cc: Maxime Ripard, Chen-Yu Tsai, Vishnu Patekar, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, devicetree, linux-sunxi-/JYPxA39Uh5TLH3MbocFFw Hi Hans, > On Jun 17, 2015, at 10:19 , Hans de Goede <hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> 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-- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [PATCH v2 6/6] ARM: sun8i: dts: Add Ippo-q8h v1.2 with A33 and 1024x600 lcd support 2015-06-16 17:55 ` Maxime Ripard 2015-06-16 19:33 ` Pantelis Antoniou @ 2015-06-17 7:16 ` Hans de Goede [not found] ` <55811ED9.9090503-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> 1 sibling, 1 reply; 33+ messages in thread From: Hans de Goede @ 2015-06-17 7:16 UTC (permalink / raw) To: Maxime Ripard, Pantelis Antoniou Cc: Chen-Yu Tsai, Vishnu Patekar, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, devicetree, linux-sunxi-/JYPxA39Uh5TLH3MbocFFw 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 -- 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-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit https://groups.google.com/d/optout. ^ permalink raw reply [flat|nested] 33+ messages in thread
[parent not found: <55811ED9.9090503-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>]
* Re: [PATCH v2 6/6] ARM: sun8i: dts: Add Ippo-q8h v1.2 with A33 and 1024x600 lcd support [not found] ` <55811ED9.9090503-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> @ 2015-06-18 17:52 ` Maxime Ripard 0 siblings, 0 replies; 33+ messages in thread From: Maxime Ripard @ 2015-06-18 17:52 UTC (permalink / raw) To: Hans de Goede Cc: Pantelis Antoniou, Chen-Yu Tsai, Vishnu Patekar, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, devicetree, linux-sunxi-/JYPxA39Uh5TLH3MbocFFw [-- Attachment #1: Type: text/plain, Size: 4237 bytes --] 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 -- 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-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit https://groups.google.com/d/optout. [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [PATCH v2 0/6] Introduce Allwinner A33 support [not found] ` <1432997706-20172-1-git-send-email-hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> ` (5 preceding siblings ...) 2015-05-30 14:55 ` [PATCH v2 6/6] ARM: sun8i: dts: Add Ippo-q8h v1.2 with A33 and 1024x600 lcd support Hans de Goede @ 2015-05-30 20:43 ` jonsmirl-Re5JQEeQqe8AvxtiuMwx3w 2015-06-02 7:43 ` Chen-Yu Tsai 7 siblings, 0 replies; 33+ messages in thread From: jonsmirl-Re5JQEeQqe8AvxtiuMwx3w @ 2015-05-30 20:43 UTC (permalink / raw) To: Hans de Goede Cc: Maxime Ripard, Chen-Yu Tsai, Vishnu Patekar, ARM Linux Mailing List, devicetree, linux-sunxi Is the A33 Lollipop SDK somewhere? On Sat, May 30, 2015 at 10:55 AM, Hans de Goede <hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> 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-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org > For more options, visit https://groups.google.com/d/optout. -- Jon Smirl jonsmirl-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [PATCH v2 0/6] Introduce Allwinner A33 support [not found] ` <1432997706-20172-1-git-send-email-hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> ` (6 preceding siblings ...) 2015-05-30 20:43 ` [PATCH v2 0/6] Introduce Allwinner A33 support jonsmirl-Re5JQEeQqe8AvxtiuMwx3w @ 2015-06-02 7:43 ` Chen-Yu Tsai 7 siblings, 0 replies; 33+ messages in thread From: Chen-Yu Tsai @ 2015-06-02 7:43 UTC (permalink / raw) To: Hans de Goede Cc: Maxime Ripard, Chen-Yu Tsai, Vishnu Patekar, linux-arm-kernel, devicetree, linux-sunxi On Sat, May 30, 2015 at 10:55 PM, Hans de Goede <hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> 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-jdAy2FN1RRM@public.gmane.org> on my Sinlinx SinA33 dev board. I'll send patches for it later. ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [PATCH v2 0/6] Introduce Allwinner A33 support 2015-05-30 14:55 [PATCH v2 0/6] Introduce Allwinner A33 support Hans de Goede [not found] ` <1432997706-20172-1-git-send-email-hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> @ 2016-06-13 19:10 ` ernestovm07 1 sibling, 0 replies; 33+ messages in thread From: ernestovm07 @ 2016-06-13 19:10 UTC (permalink / raw) To: linux-sunxi Cc: devicetree, vishnupatekar0510, hdegoede, wens, maxime.ripard, linux-arm-kernel [-- Attachment #1: Type: text/plain, Size: 846 bytes --] 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 [-- Attachment #2: Type: text/plain, Size: 176 bytes --] _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 33+ messages in thread
end of thread, other threads:[~2016-06-13 19:10 UTC | newest]
Thread overview: 33+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-05-30 14:55 [PATCH v2 0/6] Introduce Allwinner A33 support Hans de Goede
[not found] ` <1432997706-20172-1-git-send-email-hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2015-05-30 14:55 ` [PATCH v2 1/6] ARM: sunxi: Add Machine support for A33 Hans de Goede
[not found] ` <1432997706-20172-2-git-send-email-hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2015-06-02 7:28 ` Maxime Ripard
2015-05-30 14:55 ` [PATCH v2 2/6] pinctrl: sunxi: Add allwinner A33 PIO controller support Hans de Goede
2015-05-30 14:55 ` [PATCH v2 3/6] ARM: dts: sun8i: Add sun8i-a23-a33 dtsi Hans de Goede
[not found] ` <1432997706-20172-4-git-send-email-hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2015-06-02 7:51 ` Maxime Ripard
2015-06-02 8:08 ` Hans de Goede
[not found] ` <556D6487.4010207-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2015-06-02 8:21 ` Maxime Ripard
2015-05-30 14:55 ` [PATCH v2 4/6] ARM: dts: sun8i: Add sun8i-a33 dtsi Hans de Goede
[not found] ` <1432997706-20172-5-git-send-email-hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2015-06-02 7:55 ` Maxime Ripard
2015-05-30 14:55 ` [PATCH v2 5/6] ARM: dts: sun8i: Add ET-Q8 A33 support Hans de Goede
[not found] ` <1432997706-20172-6-git-send-email-hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2015-06-02 7:56 ` Maxime Ripard
2015-05-30 14:55 ` [PATCH v2 6/6] ARM: sun8i: dts: Add Ippo-q8h v1.2 with A33 and 1024x600 lcd support Hans de Goede
[not found] ` <1432997706-20172-7-git-send-email-hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2015-06-02 8:14 ` Maxime Ripard
2015-06-02 8:29 ` Hans de Goede
[not found] ` <556D6955.8030708-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2015-06-03 9:45 ` Maxime Ripard
2015-06-03 11:12 ` Hans de Goede
[not found] ` <556EE104.3090803-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2015-06-13 13:50 ` Maxime Ripard
2015-06-13 14:18 ` Hans de Goede
[not found] ` <557C3BD3.6030105-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2015-06-16 17:41 ` Maxime Ripard
2015-06-17 7:16 ` Hans de Goede
[not found] ` <55811EB2.4060302-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2015-06-18 18:37 ` Maxime Ripard
2015-06-18 20:16 ` Hans de Goede
2015-06-14 18:16 ` Pantelis Antoniou
[not found] ` <85E62D2D-5387-433B-A944-7F2145459F08-OWPKS81ov/FWk0Htik3J/w@public.gmane.org>
2015-06-16 17:55 ` Maxime Ripard
2015-06-16 19:33 ` Pantelis Antoniou
[not found] ` <D4216F2D-0556-4849-B1DF-8E4D250006B4-OWPKS81ov/FWk0Htik3J/w@public.gmane.org>
2015-06-17 7:19 ` Hans de Goede
[not found] ` <55811F94.3080608-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2015-06-17 7:26 ` Pantelis Antoniou
2015-06-17 7:16 ` Hans de Goede
[not found] ` <55811ED9.9090503-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2015-06-18 17:52 ` Maxime Ripard
2015-05-30 20:43 ` [PATCH v2 0/6] Introduce Allwinner A33 support jonsmirl-Re5JQEeQqe8AvxtiuMwx3w
2015-06-02 7:43 ` Chen-Yu Tsai
2016-06-13 19:10 ` ernestovm07
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).