* [PATCH 05/11] drivers: pinctrl: add driver for Allwinner A64 SoC [not found] ` <1454348370-3816-1-git-send-email-andre.przywara-5wv7dgnIgG8@public.gmane.org> @ 2016-02-01 17:39 ` Andre Przywara [not found] ` <20160201182754.GA14737@excalibur.cnev.de> 0 siblings, 1 reply; 13+ messages in thread From: Andre Przywara @ 2016-02-01 17:39 UTC (permalink / raw) To: Maxime Ripard, Chen-Yu Tsai, linux-sunxi-/JYPxA39Uh5TLH3MbocFFw Cc: Arnd Bergmann, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, linux-kernel-u79uwXL29TY76Z2rM5mHXA, Linus Walleij, Vishnu Patekar, linux-gpio-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, devicetree-u79uwXL29TY76Z2rM5mHXA Based on the Allwinner A64 user manual and on the previous sunxi pinctrl drivers this introduces the pin multiplex assignments for the ARMv8 Allwinner A64 SoC. Port A is apparently used for the fixed function DRAM controller, so the ports start at B here (the manual mentions "n from 1 to 7", so not starting at 0). Signed-off-by: Andre Przywara <andre.przywara-5wv7dgnIgG8@public.gmane.org> --- .../bindings/pinctrl/allwinner,sunxi-pinctrl.txt | 1 + arch/arm64/Kconfig.platforms | 1 + drivers/pinctrl/sunxi/Kconfig | 4 + drivers/pinctrl/sunxi/Makefile | 1 + drivers/pinctrl/sunxi/pinctrl-a64.c | 606 +++++++++++++++++++++ 5 files changed, 613 insertions(+) create mode 100644 drivers/pinctrl/sunxi/pinctrl-a64.c diff --git a/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt index 9213b27..9050002 100644 --- a/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt +++ b/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt @@ -21,6 +21,7 @@ Required properties: "allwinner,sun9i-a80-r-pinctrl" "allwinner,sun8i-a83t-pinctrl" "allwinner,sun8i-h3-pinctrl" + "allwinner,a64-pinctrl" - reg: Should contain the register physical address and length for the pin controller. diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms index fc7cf4b..03f0f9d 100644 --- a/arch/arm64/Kconfig.platforms +++ b/arch/arm64/Kconfig.platforms @@ -2,6 +2,7 @@ menu "Platform selection" config ARCH_SUNXI bool "Allwinner sunxi 64-bit SoC Family" + select PINCTRL_A64 select SUNXI_MMC help This enables support for Allwinner sunxi based SoCs like the A64. diff --git a/drivers/pinctrl/sunxi/Kconfig b/drivers/pinctrl/sunxi/Kconfig index f8dbc8b..68873f2 100644 --- a/drivers/pinctrl/sunxi/Kconfig +++ b/drivers/pinctrl/sunxi/Kconfig @@ -64,4 +64,8 @@ config PINCTRL_SUN9I_A80_R depends on RESET_CONTROLLER select PINCTRL_SUNXI_COMMON +config PINCTRL_A64 + bool + select PINCTRL_SUNXI_COMMON + endif diff --git a/drivers/pinctrl/sunxi/Makefile b/drivers/pinctrl/sunxi/Makefile index ef82f22..e00ccde 100644 --- a/drivers/pinctrl/sunxi/Makefile +++ b/drivers/pinctrl/sunxi/Makefile @@ -12,6 +12,7 @@ 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_A64) += pinctrl-a64.o obj-$(CONFIG_PINCTRL_SUN8I_A83T) += pinctrl-sun8i-a83t.o obj-$(CONFIG_PINCTRL_SUN8I_H3) += pinctrl-sun8i-h3.o obj-$(CONFIG_PINCTRL_SUN9I_A80) += pinctrl-sun9i-a80.o diff --git a/drivers/pinctrl/sunxi/pinctrl-a64.c b/drivers/pinctrl/sunxi/pinctrl-a64.c new file mode 100644 index 0000000..e72b079 --- /dev/null +++ b/drivers/pinctrl/sunxi/pinctrl-a64.c @@ -0,0 +1,606 @@ +/* + * Allwinner A64 SoCs pinctrl driver. + * + * Copyright (C) 2016 - ARM Ltd. + * Author: Andre Przywara <andre.przywara-5wv7dgnIgG8@public.gmane.org> + * + * Based on pinctrl-sun7i-a20.c, which is: + * 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 a64_pins[] = { + SUNXI_PIN(SUNXI_PINCTRL_PIN(B, 0), + SUNXI_FUNCTION(0x0, "gpio_in"), + SUNXI_FUNCTION(0x1, "gpio_out"), + SUNXI_FUNCTION(0x2, "uart2"), /* TX */ + SUNXI_FUNCTION(0x4, "jtag"), /* MS0 */ + SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 0)), /* 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(0x4, "jtag"), /* CK0 */ + SUNXI_FUNCTION(0x5, "sim"), /* VCCEN */ + SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 1)), /* 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(0x4, "jtag"), /* DO0 */ + SUNXI_FUNCTION(0x5, "sim"), /* VPPEN */ + SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 2)), /* 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(0x3, "i2s0"), /* MCLK */ + SUNXI_FUNCTION(0x4, "jtag"), /* DI0 */ + SUNXI_FUNCTION(0x5, "sim"), /* VPPPP */ + SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 3)), /* EINT3 */ + SUNXI_PIN(SUNXI_PINCTRL_PIN(B, 4), + SUNXI_FUNCTION(0x0, "gpio_in"), + SUNXI_FUNCTION(0x1, "gpio_out"), + SUNXI_FUNCTION(0x2, "aif2"), /* SYNC */ + SUNXI_FUNCTION(0x3, "i2s0"), /* SYNC */ + SUNXI_FUNCTION(0x5, "sim"), /* CLK */ + SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 4)), /* EINT4 */ + SUNXI_PIN(SUNXI_PINCTRL_PIN(B, 5), + SUNXI_FUNCTION(0x0, "gpio_in"), + SUNXI_FUNCTION(0x1, "gpio_out"), + SUNXI_FUNCTION(0x2, "aif2"), /* BCLK */ + SUNXI_FUNCTION(0x3, "i2s0"), /* BCLK */ + SUNXI_FUNCTION(0x5, "sim"), /* DATA */ + SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 5)), /* EINT5 */ + SUNXI_PIN(SUNXI_PINCTRL_PIN(B, 6), + SUNXI_FUNCTION(0x0, "gpio_in"), + SUNXI_FUNCTION(0x1, "gpio_out"), + SUNXI_FUNCTION(0x2, "aif2"), /* DOUT */ + SUNXI_FUNCTION(0x3, "i2s0"), /* DOUT */ + SUNXI_FUNCTION(0x5, "sim"), /* RST */ + SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 6)), /* EINT6 */ + SUNXI_PIN(SUNXI_PINCTRL_PIN(B, 7), + SUNXI_FUNCTION(0x0, "gpio_in"), + SUNXI_FUNCTION(0x1, "gpio_out"), + SUNXI_FUNCTION(0x2, "aif2"), /* DIN */ + SUNXI_FUNCTION(0x3, "i2s0"), /* DIN */ + SUNXI_FUNCTION(0x5, "sim"), /* DET */ + SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 7)), /* EINT7 */ + SUNXI_PIN(SUNXI_PINCTRL_PIN(B, 8), + SUNXI_FUNCTION(0x0, "gpio_in"), + SUNXI_FUNCTION(0x1, "gpio_out"), + SUNXI_FUNCTION(0x4, "uart0"), /* TX */ + SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 8)), /* EINT8 */ + SUNXI_PIN(SUNXI_PINCTRL_PIN(B, 9), + SUNXI_FUNCTION(0x0, "gpio_in"), + SUNXI_FUNCTION(0x1, "gpio_out"), + SUNXI_FUNCTION(0x4, "uart0"), /* RX */ + SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 9)), /* EINT9 */ + /* Hole */ + SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 0), + SUNXI_FUNCTION(0x0, "gpio_in"), + SUNXI_FUNCTION(0x1, "gpio_out"), + SUNXI_FUNCTION(0x2, "nand0"), /* NWE */ + SUNXI_FUNCTION(0x4, "spi0")), /* MOSI */ + SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 1), + SUNXI_FUNCTION(0x0, "gpio_in"), + SUNXI_FUNCTION(0x1, "gpio_out"), + SUNXI_FUNCTION(0x2, "nand0"), /* NALE */ + SUNXI_FUNCTION(0x3, "mmc2"), /* DS */ + SUNXI_FUNCTION(0x4, "spi0")), /* MISO */ + SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 2), + SUNXI_FUNCTION(0x0, "gpio_in"), + SUNXI_FUNCTION(0x1, "gpio_out"), + SUNXI_FUNCTION(0x2, "nand0"), /* NCLE */ + SUNXI_FUNCTION(0x4, "spi0")), /* SCK */ + SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 3), + SUNXI_FUNCTION(0x0, "gpio_in"), + SUNXI_FUNCTION(0x1, "gpio_out"), + SUNXI_FUNCTION(0x2, "nand0"), /* NCE1 */ + SUNXI_FUNCTION(0x4, "spi0")), /* CS */ + SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 4), + SUNXI_FUNCTION(0x0, "gpio_in"), + SUNXI_FUNCTION(0x1, "gpio_out"), + SUNXI_FUNCTION(0x2, "nand0")), /* NCE0 */ + SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 5), + SUNXI_FUNCTION(0x0, "gpio_in"), + SUNXI_FUNCTION(0x1, "gpio_out"), + SUNXI_FUNCTION(0x2, "nand0"), /* NRE# */ + 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"), /* NRB0 */ + 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")), /* NRB1 */ + SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 8), + SUNXI_FUNCTION(0x0, "gpio_in"), + SUNXI_FUNCTION(0x1, "gpio_out"), + SUNXI_FUNCTION(0x2, "nand0"), /* NDQ0 */ + 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"), /* NDQ1 */ + 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"), /* NDQ2 */ + 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"), /* NDQ3 */ + 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"), /* NDQ4 */ + 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"), /* NDQ5 */ + 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, "nand0"), /* NDQ6 */ + 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, "nand0"), /* NDQ7 */ + 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, "nand0"), /* NDQS */ + SUNXI_FUNCTION(0x3, "mmc2")), /* RST */ + /* Hole */ + SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 0), + SUNXI_FUNCTION(0x0, "gpio_in"), + SUNXI_FUNCTION(0x1, "gpio_out"), + SUNXI_FUNCTION(0x2, "lcd0"), /* D2 */ + SUNXI_FUNCTION(0x3, "uart3"), /* TX */ + SUNXI_FUNCTION(0x4, "spi1"), /* CS */ + SUNXI_FUNCTION(0x5, "ccir")), /* CLK */ + SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 1), + SUNXI_FUNCTION(0x0, "gpio_in"), + SUNXI_FUNCTION(0x1, "gpio_out"), + SUNXI_FUNCTION(0x2, "lcd0"), /* D3 */ + SUNXI_FUNCTION(0x3, "uart3"), /* RX */ + SUNXI_FUNCTION(0x4, "spi1"), /* CLK */ + SUNXI_FUNCTION(0x5, "ccir")), /* DE */ + SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 2), + SUNXI_FUNCTION(0x0, "gpio_in"), + SUNXI_FUNCTION(0x1, "gpio_out"), + SUNXI_FUNCTION(0x2, "lcd0"), /* D4 */ + SUNXI_FUNCTION(0x3, "uart4"), /* TX */ + SUNXI_FUNCTION(0x4, "spi1"), /* MOSI */ + SUNXI_FUNCTION(0x5, "ccir")), /* HSYNC */ + SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 3), + SUNXI_FUNCTION(0x0, "gpio_in"), + SUNXI_FUNCTION(0x1, "gpio_out"), + SUNXI_FUNCTION(0x2, "lcd0"), /* D5 */ + SUNXI_FUNCTION(0x3, "uart4"), /* RX */ + SUNXI_FUNCTION(0x4, "spi1"), /* MISO */ + SUNXI_FUNCTION(0x5, "ccir")), /* VSYNC */ + SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 4), + SUNXI_FUNCTION(0x0, "gpio_in"), + SUNXI_FUNCTION(0x1, "gpio_out"), + SUNXI_FUNCTION(0x2, "lcd0"), /* D6 */ + SUNXI_FUNCTION(0x3, "uart4"), /* RTS */ + SUNXI_FUNCTION(0x5, "ccir")), /* D0 */ + SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 5), + SUNXI_FUNCTION(0x0, "gpio_in"), + SUNXI_FUNCTION(0x1, "gpio_out"), + SUNXI_FUNCTION(0x2, "lcd0"), /* D7 */ + SUNXI_FUNCTION(0x3, "uart4"), /* CTS */ + SUNXI_FUNCTION(0x5, "ccir")), /* D1 */ + SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 6), + SUNXI_FUNCTION(0x0, "gpio_in"), + SUNXI_FUNCTION(0x1, "gpio_out"), + SUNXI_FUNCTION(0x2, "lcd0"), /* D10 */ + SUNXI_FUNCTION(0x5, "ccir")), /* D2 */ + SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 7), + SUNXI_FUNCTION(0x0, "gpio_in"), + SUNXI_FUNCTION(0x1, "gpio_out"), + SUNXI_FUNCTION(0x2, "lcd0"), /* D11 */ + SUNXI_FUNCTION(0x5, "ccir")), /* D3 */ + SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 8), + SUNXI_FUNCTION(0x0, "gpio_in"), + SUNXI_FUNCTION(0x1, "gpio_out"), + SUNXI_FUNCTION(0x2, "lcd0"), /* D12 */ + SUNXI_FUNCTION(0x4, "emac"), /* ERXD3 */ + SUNXI_FUNCTION(0x5, "ccir")), /* D4 */ + SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 9), + SUNXI_FUNCTION(0x0, "gpio_in"), + SUNXI_FUNCTION(0x1, "gpio_out"), + SUNXI_FUNCTION(0x2, "lcd0"), /* D13 */ + SUNXI_FUNCTION(0x4, "emac"), /* ERXD2 */ + SUNXI_FUNCTION(0x5, "ccir")), /* D5 */ + SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 10), + SUNXI_FUNCTION(0x0, "gpio_in"), + SUNXI_FUNCTION(0x1, "gpio_out"), + SUNXI_FUNCTION(0x2, "lcd0"), /* D14 */ + SUNXI_FUNCTION(0x4, "emac")), /* ERXD1 */ + SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 11), + SUNXI_FUNCTION(0x0, "gpio_in"), + SUNXI_FUNCTION(0x1, "gpio_out"), + SUNXI_FUNCTION(0x2, "lcd0"), /* D15 */ + SUNXI_FUNCTION(0x4, "emac")), /* ERXD0 */ + SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 12), + SUNXI_FUNCTION(0x0, "gpio_in"), + SUNXI_FUNCTION(0x1, "gpio_out"), + SUNXI_FUNCTION(0x2, "lcd0"), /* D18 */ + SUNXI_FUNCTION(0x3, "lvds0"), /* VP0 */ + SUNXI_FUNCTION(0x4, "emac")), /* ERXCK */ + SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 13), + SUNXI_FUNCTION(0x0, "gpio_in"), + SUNXI_FUNCTION(0x1, "gpio_out"), + SUNXI_FUNCTION(0x2, "lcd0"), /* D19 */ + SUNXI_FUNCTION(0x3, "lvds0"), /* VN0 */ + SUNXI_FUNCTION(0x4, "emac")), /* ERXCTL */ + SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 14), + SUNXI_FUNCTION(0x0, "gpio_in"), + SUNXI_FUNCTION(0x1, "gpio_out"), + SUNXI_FUNCTION(0x2, "lcd0"), /* D20 */ + SUNXI_FUNCTION(0x3, "lvds0"), /* VP1 */ + SUNXI_FUNCTION(0x4, "emac")), /* ENULL */ + SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 15), + SUNXI_FUNCTION(0x0, "gpio_in"), + SUNXI_FUNCTION(0x1, "gpio_out"), + SUNXI_FUNCTION(0x2, "lcd0"), /* D21 */ + SUNXI_FUNCTION(0x3, "lvds0"), /* VN1 */ + SUNXI_FUNCTION(0x4, "emac"), /* ETXD3 */ + SUNXI_FUNCTION(0x5, "ccir")), /* D6 */ + SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 16), + SUNXI_FUNCTION(0x0, "gpio_in"), + SUNXI_FUNCTION(0x1, "gpio_out"), + SUNXI_FUNCTION(0x2, "lcd0"), /* D22 */ + SUNXI_FUNCTION(0x3, "lvds0"), /* VP2 */ + SUNXI_FUNCTION(0x4, "emac"), /* ETXD2 */ + SUNXI_FUNCTION(0x5, "ccir")), /* D7 */ + SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 17), + SUNXI_FUNCTION(0x0, "gpio_in"), + SUNXI_FUNCTION(0x1, "gpio_out"), + SUNXI_FUNCTION(0x2, "lcd0"), /* D23 */ + SUNXI_FUNCTION(0x3, "lvds0"), /* VN2 */ + SUNXI_FUNCTION(0x4, "emac")), /* ETXD1 */ + SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 18), + SUNXI_FUNCTION(0x0, "gpio_in"), + SUNXI_FUNCTION(0x1, "gpio_out"), + SUNXI_FUNCTION(0x2, "lcd0"), /* CLK */ + SUNXI_FUNCTION(0x3, "lvds0"), /* VPC */ + SUNXI_FUNCTION(0x4, "emac")), /* ETXD0 */ + SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 19), + SUNXI_FUNCTION(0x0, "gpio_in"), + SUNXI_FUNCTION(0x1, "gpio_out"), + SUNXI_FUNCTION(0x2, "lcd0"), /* DE */ + SUNXI_FUNCTION(0x3, "lvds0"), /* VNC */ + SUNXI_FUNCTION(0x4, "emac")), /* ETXCK */ + SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 20), + SUNXI_FUNCTION(0x0, "gpio_in"), + SUNXI_FUNCTION(0x1, "gpio_out"), + SUNXI_FUNCTION(0x2, "lcd0"), /* HSYNC */ + SUNXI_FUNCTION(0x3, "lvds0"), /* VP3 */ + SUNXI_FUNCTION(0x4, "emac")), /* ETXCTL */ + SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 21), + SUNXI_FUNCTION(0x0, "gpio_in"), + SUNXI_FUNCTION(0x1, "gpio_out"), + SUNXI_FUNCTION(0x2, "lcd0"), /* VSYNC */ + SUNXI_FUNCTION(0x3, "lvds0"), /* VN3 */ + SUNXI_FUNCTION(0x4, "emac")), /* ECLKIN */ + SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 22), + SUNXI_FUNCTION(0x0, "gpio_in"), + SUNXI_FUNCTION(0x1, "gpio_out"), + SUNXI_FUNCTION(0x2, "pwm"), /* PWM0 */ + SUNXI_FUNCTION(0x4, "emac")), /* EMDC */ + SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 23), + SUNXI_FUNCTION(0x0, "gpio_in"), + SUNXI_FUNCTION(0x1, "gpio_out"), + SUNXI_FUNCTION(0x4, "emac")), /* EMDIO */ + SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 24), + SUNXI_FUNCTION(0x0, "gpio_in"), + SUNXI_FUNCTION(0x1, "gpio_out")), + /* Hole */ + SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 0), + SUNXI_FUNCTION(0x0, "gpio_in"), + SUNXI_FUNCTION(0x1, "gpio_out"), + SUNXI_FUNCTION(0x2, "csi0"), /* PCK */ + SUNXI_FUNCTION(0x4, "ts0")), /* CLK */ + SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 1), + SUNXI_FUNCTION(0x0, "gpio_in"), + SUNXI_FUNCTION(0x1, "gpio_out"), + SUNXI_FUNCTION(0x2, "csi0"), /* CK */ + SUNXI_FUNCTION(0x4, "ts0")), /* ERR */ + SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 2), + SUNXI_FUNCTION(0x0, "gpio_in"), + SUNXI_FUNCTION(0x1, "gpio_out"), + SUNXI_FUNCTION(0x2, "csi0"), /* HSYNC */ + SUNXI_FUNCTION(0x4, "ts0")), /* SYNC */ + SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 3), + SUNXI_FUNCTION(0x0, "gpio_in"), + SUNXI_FUNCTION(0x1, "gpio_out"), + SUNXI_FUNCTION(0x2, "csi0"), /* VSYNC */ + SUNXI_FUNCTION(0x4, "ts0")), /* DVLD */ + SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 4), + SUNXI_FUNCTION(0x0, "gpio_in"), + SUNXI_FUNCTION(0x1, "gpio_out"), + SUNXI_FUNCTION(0x2, "csi0"), /* D0 */ + SUNXI_FUNCTION(0x4, "ts0")), /* D0 */ + SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 5), + SUNXI_FUNCTION(0x0, "gpio_in"), + SUNXI_FUNCTION(0x1, "gpio_out"), + SUNXI_FUNCTION(0x2, "csi0"), /* D1 */ + SUNXI_FUNCTION(0x4, "ts0")), /* D1 */ + SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 6), + SUNXI_FUNCTION(0x0, "gpio_in"), + SUNXI_FUNCTION(0x1, "gpio_out"), + SUNXI_FUNCTION(0x2, "csi0"), /* D2 */ + SUNXI_FUNCTION(0x4, "ts0")), /* D2 */ + SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 7), + SUNXI_FUNCTION(0x0, "gpio_in"), + SUNXI_FUNCTION(0x1, "gpio_out"), + SUNXI_FUNCTION(0x2, "csi0"), /* D3 */ + SUNXI_FUNCTION(0x4, "ts0")), /* D3 */ + SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 8), + SUNXI_FUNCTION(0x0, "gpio_in"), + SUNXI_FUNCTION(0x1, "gpio_out"), + SUNXI_FUNCTION(0x2, "csi0"), /* D4 */ + SUNXI_FUNCTION(0x4, "ts0")), /* D4 */ + SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 9), + SUNXI_FUNCTION(0x0, "gpio_in"), + SUNXI_FUNCTION(0x1, "gpio_out"), + SUNXI_FUNCTION(0x2, "csi0"), /* D5 */ + SUNXI_FUNCTION(0x4, "ts0")), /* D5 */ + SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 10), + SUNXI_FUNCTION(0x0, "gpio_in"), + SUNXI_FUNCTION(0x1, "gpio_out"), + SUNXI_FUNCTION(0x2, "csi0"), /* D6 */ + SUNXI_FUNCTION(0x4, "ts0")), /* D6 */ + SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 11), + SUNXI_FUNCTION(0x0, "gpio_in"), + SUNXI_FUNCTION(0x1, "gpio_out"), + SUNXI_FUNCTION(0x2, "csi0"), /* D7 */ + SUNXI_FUNCTION(0x4, "ts0")), /* D7 */ + SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 12), + SUNXI_FUNCTION(0x0, "gpio_in"), + SUNXI_FUNCTION(0x1, "gpio_out"), + SUNXI_FUNCTION(0x2, "csi0")), /* SCK */ + SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 13), + SUNXI_FUNCTION(0x0, "gpio_in"), + SUNXI_FUNCTION(0x1, "gpio_out"), + SUNXI_FUNCTION(0x2, "csi0")), /* SDA */ + SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 14), + SUNXI_FUNCTION(0x0, "gpio_in"), + SUNXI_FUNCTION(0x1, "gpio_out"), + SUNXI_FUNCTION(0x2, "pll"), /* LOCK_DBG */ + SUNXI_FUNCTION(0x3, "i2c2")), /* SCK */ + SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 15), + SUNXI_FUNCTION(0x0, "gpio_in"), + SUNXI_FUNCTION(0x1, "gpio_out"), + SUNXI_FUNCTION(0x3, "i2c2")), /* SDA */ + 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")), /* MSI */ + 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(0x4, "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 */ + SUNXI_PIN(SUNXI_PINCTRL_PIN(F, 6), + SUNXI_FUNCTION(0x0, "gpio_in"), + SUNXI_FUNCTION(0x1, "gpio_out")), + /* 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(0x6, 1, 0)), /* 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(0x6, 1, 1)), /* 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(0x6, 1, 2)), /* 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(0x6, 1, 3)), /* 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(0x6, 1, 4)), /* 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(0x6, 1, 5)), /* 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(0x6, 1, 6)), /* 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(0x6, 1, 7)), /* EINT7 */ + SUNXI_PIN(SUNXI_PINCTRL_PIN(G, 8), + SUNXI_FUNCTION(0x0, "gpio_in"), + SUNXI_FUNCTION(0x1, "gpio_out"), + SUNXI_FUNCTION(0x2, "uart1"), /* RTS */ + SUNXI_FUNCTION_IRQ_BANK(0x6, 1, 8)), /* EINT8 */ + SUNXI_PIN(SUNXI_PINCTRL_PIN(G, 9), + SUNXI_FUNCTION(0x0, "gpio_in"), + SUNXI_FUNCTION(0x1, "gpio_out"), + SUNXI_FUNCTION(0x2, "uart1"), /* CTS */ + SUNXI_FUNCTION_IRQ_BANK(0x6, 1, 9)), /* EINT9 */ + SUNXI_PIN(SUNXI_PINCTRL_PIN(G, 10), + SUNXI_FUNCTION(0x0, "gpio_in"), + SUNXI_FUNCTION(0x1, "gpio_out"), + SUNXI_FUNCTION(0x2, "aif3"), /* SYNC */ + SUNXI_FUNCTION(0x3, "i2s1"), /* SYNC */ + SUNXI_FUNCTION_IRQ_BANK(0x6, 1, 10)), /* EINT10 */ + SUNXI_PIN(SUNXI_PINCTRL_PIN(G, 11), + SUNXI_FUNCTION(0x0, "gpio_in"), + SUNXI_FUNCTION(0x1, "gpio_out"), + SUNXI_FUNCTION(0x2, "aif3"), /* BCLK */ + SUNXI_FUNCTION(0x3, "i2s1"), /* BCLK */ + SUNXI_FUNCTION_IRQ_BANK(0x6, 1, 11)), /* EINT11 */ + SUNXI_PIN(SUNXI_PINCTRL_PIN(G, 12), + SUNXI_FUNCTION(0x0, "gpio_in"), + SUNXI_FUNCTION(0x1, "gpio_out"), + SUNXI_FUNCTION(0x2, "aif3"), /* DOUT */ + SUNXI_FUNCTION(0x3, "i2s1"), /* DOUT */ + SUNXI_FUNCTION_IRQ_BANK(0x6, 1, 12)), /* EINT12 */ + SUNXI_PIN(SUNXI_PINCTRL_PIN(G, 13), + SUNXI_FUNCTION(0x0, "gpio_in"), + SUNXI_FUNCTION(0x1, "gpio_out"), + SUNXI_FUNCTION(0x2, "aif3"), /* DIN */ + SUNXI_FUNCTION(0x3, "i2s1"), /* DIN */ + SUNXI_FUNCTION_IRQ_BANK(0x6, 1, 13)), /* EINT13 */ + /* Hole */ + SUNXI_PIN(SUNXI_PINCTRL_PIN(H, 0), + SUNXI_FUNCTION(0x0, "gpio_in"), + SUNXI_FUNCTION(0x1, "gpio_out"), + SUNXI_FUNCTION(0x2, "i2c0"), /* SCK */ + SUNXI_FUNCTION_IRQ_BANK(0x6, 2, 0)), /* EINT0 */ + SUNXI_PIN(SUNXI_PINCTRL_PIN(H, 1), + SUNXI_FUNCTION(0x0, "gpio_in"), + SUNXI_FUNCTION(0x1, "gpio_out"), + SUNXI_FUNCTION(0x2, "i2c0"), /* SDA */ + SUNXI_FUNCTION_IRQ_BANK(0x6, 2, 1)), /* EINT1 */ + SUNXI_PIN(SUNXI_PINCTRL_PIN(H, 2), + SUNXI_FUNCTION(0x0, "gpio_in"), + SUNXI_FUNCTION(0x1, "gpio_out"), + SUNXI_FUNCTION(0x2, "i2c1"), /* SCK */ + SUNXI_FUNCTION_IRQ_BANK(0x6, 2, 2)), /* EINT2 */ + SUNXI_PIN(SUNXI_PINCTRL_PIN(H, 3), + SUNXI_FUNCTION(0x0, "gpio_in"), + SUNXI_FUNCTION(0x1, "gpio_out"), + SUNXI_FUNCTION(0x2, "i2c1"), /* SDA */ + SUNXI_FUNCTION_IRQ_BANK(0x6, 2, 3)), /* EINT3 */ + SUNXI_PIN(SUNXI_PINCTRL_PIN(H, 4), + SUNXI_FUNCTION(0x0, "gpio_in"), + SUNXI_FUNCTION(0x1, "gpio_out"), + SUNXI_FUNCTION(0x2, "uart3"), /* TX */ + SUNXI_FUNCTION_IRQ_BANK(0x6, 2, 4)), /* EINT4 */ + SUNXI_PIN(SUNXI_PINCTRL_PIN(H, 5), + SUNXI_FUNCTION(0x0, "gpio_in"), + SUNXI_FUNCTION(0x1, "gpio_out"), + SUNXI_FUNCTION(0x2, "uart3"), /* RX */ + SUNXI_FUNCTION_IRQ_BANK(0x6, 2, 5)), /* EINT5 */ + SUNXI_PIN(SUNXI_PINCTRL_PIN(H, 6), + SUNXI_FUNCTION(0x0, "gpio_in"), + SUNXI_FUNCTION(0x1, "gpio_out"), + SUNXI_FUNCTION(0x2, "uart3"), /* RTS */ + SUNXI_FUNCTION_IRQ_BANK(0x6, 2, 6)), /* EINT6 */ + SUNXI_PIN(SUNXI_PINCTRL_PIN(H, 7), + SUNXI_FUNCTION(0x0, "gpio_in"), + SUNXI_FUNCTION(0x1, "gpio_out"), + SUNXI_FUNCTION(0x2, "uart3"), /* CTS */ + SUNXI_FUNCTION_IRQ_BANK(0x6, 2, 7)), /* EINT7 */ + SUNXI_PIN(SUNXI_PINCTRL_PIN(H, 8), + SUNXI_FUNCTION(0x0, "gpio_in"), + SUNXI_FUNCTION(0x1, "gpio_out"), + SUNXI_FUNCTION(0x2, "owa"), /* OUT */ + SUNXI_FUNCTION_IRQ_BANK(0x6, 2, 8)), /* EINT8 */ + SUNXI_PIN(SUNXI_PINCTRL_PIN(H, 9), + SUNXI_FUNCTION(0x0, "gpio_in"), + SUNXI_FUNCTION(0x1, "gpio_out"), + SUNXI_FUNCTION_IRQ_BANK(0x6, 2, 9)), /* EINT9 */ + SUNXI_PIN(SUNXI_PINCTRL_PIN(H, 10), + SUNXI_FUNCTION(0x0, "gpio_in"), + SUNXI_FUNCTION(0x1, "gpio_out"), + SUNXI_FUNCTION(0x2, "mic"), /* CLK */ + SUNXI_FUNCTION_IRQ_BANK(0x6, 2, 10)), /* EINT10 */ + SUNXI_PIN(SUNXI_PINCTRL_PIN(H, 11), + SUNXI_FUNCTION(0x0, "gpio_in"), + SUNXI_FUNCTION(0x1, "gpio_out"), + SUNXI_FUNCTION(0x2, "mic"), /* DATA */ + SUNXI_FUNCTION_IRQ_BANK(0x6, 2, 11)), /* EINT11 */ +}; + +static const struct sunxi_pinctrl_desc a64_pinctrl_data = { + .pins = a64_pins, + .npins = ARRAY_SIZE(a64_pins), + .irq_banks = 3, +}; + +static int a64_pinctrl_probe(struct platform_device *pdev) +{ + return sunxi_pinctrl_init(pdev, + &a64_pinctrl_data); +} + +static const struct of_device_id a64_pinctrl_match[] = { + { .compatible = "allwinner,a64-pinctrl", }, + {} +}; +MODULE_DEVICE_TABLE(of, a64_pinctrl_match); + +static struct platform_driver a64_pinctrl_driver = { + .probe = a64_pinctrl_probe, + .driver = { + .name = "a64-pinctrl", + .of_match_table = a64_pinctrl_match, + }, +}; +module_platform_driver(a64_pinctrl_driver); + +MODULE_AUTHOR("Andre Przywara <andre.przywara-5wv7dgnIgG8@public.gmane.org>"); +MODULE_DESCRIPTION("Allwinner A64 pinctrl driver"); +MODULE_LICENSE("GPL"); -- 2.6.4 ^ permalink raw reply related [flat|nested] 13+ messages in thread
[parent not found: <20160201182754.GA14737@excalibur.cnev.de>]
[parent not found: <20160201182754.GA14737-Hlt6eto4P0pdWf7zwHaZWbNAH6kLmebB@public.gmane.org>]
* Re: [PATCH 05/11] drivers: pinctrl: add driver for Allwinner A64 SoC [not found] ` <20160201182754.GA14737-Hlt6eto4P0pdWf7zwHaZWbNAH6kLmebB@public.gmane.org> @ 2016-02-01 22:49 ` André Przywara [not found] ` <56AFE0EC.8080207-5wv7dgnIgG8@public.gmane.org> 0 siblings, 1 reply; 13+ messages in thread From: André Przywara @ 2016-02-01 22:49 UTC (permalink / raw) To: Karsten Merker Cc: Maxime Ripard, Chen-Yu Tsai, linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, Arnd Bergmann, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, linux-kernel-u79uwXL29TY76Z2rM5mHXA, Linus Walleij, Vishnu Patekar, linux-gpio-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, devicetree-u79uwXL29TY76Z2rM5mHXA On 01/02/16 18:27, Karsten Merker wrote: Hi Karsten, thank you very much for your feedback! > On Mon, Feb 01, 2016 at 05:39:24PM +0000, Andre Przywara wrote: >> Based on the Allwinner A64 user manual and on the previous sunxi >> pinctrl drivers this introduces the pin multiplex assignments for >> the ARMv8 Allwinner A64 SoC. >> Port A is apparently used for the fixed function DRAM controller, so >> the ports start at B here (the manual mentions "n from 1 to 7", so >> not starting at 0). >> >> Signed-off-by: Andre Przywara <andre.przywara-5wv7dgnIgG8@public.gmane.org> >> --- >> .../bindings/pinctrl/allwinner,sunxi-pinctrl.txt | 1 + >> arch/arm64/Kconfig.platforms | 1 + >> drivers/pinctrl/sunxi/Kconfig | 4 + >> drivers/pinctrl/sunxi/Makefile | 1 + >> drivers/pinctrl/sunxi/pinctrl-a64.c | 606 +++++++++++++++++++++ >> 5 files changed, 613 insertions(+) >> create mode 100644 drivers/pinctrl/sunxi/pinctrl-a64.c >> >> diff --git a/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt >> index 9213b27..9050002 100644 >> --- a/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt >> +++ b/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt >> @@ -21,6 +21,7 @@ Required properties: >> "allwinner,sun9i-a80-r-pinctrl" >> "allwinner,sun8i-a83t-pinctrl" >> "allwinner,sun8i-h3-pinctrl" >> + "allwinner,a64-pinctrl" > > Hello, > > on all other Allwinner SoCs we use the SoC family as part of the > compatible, as well as in the names of the Kconfig options. To > keep things consistent, I would like to propose doing the same on > Arm64, i.e. using allwinner,sun50i-a64-pinctrl instead of > allwinner,a64-pinctrl. Yes, I have been told this already. However I don't like this idea so much, for the following reasons: a) It is mostly redundant. The actual SoC (marketing) name is unique, there is no sun6i-a20 or sun7i-a23. b) It is not even helpful. If I got Maxime correctly, then the newer sunxi generation numbers depend on the ARM _cores_ used in the SoC, which is frankly the least interesting part from a Linux support perspective. I would see some sense if it would reflect the generation of IP blocks used, but so it is even more confusing to see that sun7i-a20 and sun8i-a23 are related, but sun8i-h3 is a completely different beast. The Allwinner marketing name tells you that, but the sunxi one does not. c) It is very confusing for people not dealing with it everyday. Just because I own a BananaPi I know that the A20 is sun7i, but I am totally lost when it comes to all the other names. And even now it took me about a minute to find the appropriate Wiki page which explains part of that story. d) Most importantly ;-): It kills TAB completion, unless you know the sunxi number, which is mostly not true as pointed out in c) So while I see that just a<somenumber> is not really very specific, I'd rather do away with current naming scheme for the future. In this particular case we have the vendor name as a name space identifier already, so there is no possible confusion with ARM Cortex naming, for instance. Also as this is now moving into the arm64 world, I'd like to use the opportunity to fix things that are not really optimal, the naming is one of them. >> - reg: Should contain the register physical address and length for the >> pin controller. >> diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms >> index fc7cf4b..03f0f9d 100644 >> --- a/arch/arm64/Kconfig.platforms >> +++ b/arch/arm64/Kconfig.platforms >> @@ -2,6 +2,7 @@ menu "Platform selection" >> >> config ARCH_SUNXI >> bool "Allwinner sunxi 64-bit SoC Family" >> + select PINCTRL_A64 > > Same as above, just with the name of the Kconfig option. > s/PINCTRL_A64/PINCTRL_SUN50I_A64/ ? I can see the reasoning behind this particular one, as A64 is not very specific. And indeed I had planned to replace this, but forgot it over merging all the stuff together. However I'd rather go with the generic "sunxi" as a stub name (PINCTRL_SUNXI_A64), as the "50" in there is now completely stupi^Wconfusing and also kills my favorite sun.i regexp ;-) I can see that the term "sunxi" is a shorthand for Allwinner in Linux, so it looks reasonable to me to use that. >> select SUNXI_MMC >> help >> This enables support for Allwinner sunxi based SoCs like the A64. >> diff --git a/drivers/pinctrl/sunxi/Kconfig b/drivers/pinctrl/sunxi/Kconfig >> index f8dbc8b..68873f2 100644 >> --- a/drivers/pinctrl/sunxi/Kconfig >> +++ b/drivers/pinctrl/sunxi/Kconfig >> @@ -64,4 +64,8 @@ config PINCTRL_SUN9I_A80_R >> depends on RESET_CONTROLLER >> select PINCTRL_SUNXI_COMMON >> >> +config PINCTRL_A64 > > see above > >> + bool >> + select PINCTRL_SUNXI_COMMON >> + >> endif >> diff --git a/drivers/pinctrl/sunxi/Makefile b/drivers/pinctrl/sunxi/Makefile >> index ef82f22..e00ccde 100644 >> --- a/drivers/pinctrl/sunxi/Makefile >> +++ b/drivers/pinctrl/sunxi/Makefile >> @@ -12,6 +12,7 @@ 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_A64) += pinctrl-a64.o > > see above same as above, I'd like to go with pinctrl-sunxi-a64.o. >> obj-$(CONFIG_PINCTRL_SUN8I_A83T) += pinctrl-sun8i-a83t.o >> obj-$(CONFIG_PINCTRL_SUN8I_H3) += pinctrl-sun8i-h3.o >> obj-$(CONFIG_PINCTRL_SUN9I_A80) += pinctrl-sun9i-a80.o >> diff --git a/drivers/pinctrl/sunxi/pinctrl-a64.c b/drivers/pinctrl/sunxi/pinctrl-a64.c >> new file mode 100644 >> index 0000000..e72b079 >> --- /dev/null >> +++ b/drivers/pinctrl/sunxi/pinctrl-a64.c >> @@ -0,0 +1,606 @@ >> +/* >> + * Allwinner A64 SoCs pinctrl driver. >> + * >> + * Copyright (C) 2016 - ARM Ltd. >> + * Author: Andre Przywara <andre.przywara-5wv7dgnIgG8@public.gmane.org> >> + * >> + * Based on pinctrl-sun7i-a20.c, which is: >> + * 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 a64_pins[] = { >> + SUNXI_PIN(SUNXI_PINCTRL_PIN(B, 0), >> + SUNXI_FUNCTION(0x0, "gpio_in"), >> + SUNXI_FUNCTION(0x1, "gpio_out"), .... >> + SUNXI_FUNCTION_IRQ_BANK(0x6, 2, 11)), /* EINT11 */ >> +}; >> + >> +static const struct sunxi_pinctrl_desc a64_pinctrl_data = { >> + .pins = a64_pins, >> + .npins = ARRAY_SIZE(a64_pins), >> + .irq_banks = 3, >> +}; >> + >> +static int a64_pinctrl_probe(struct platform_device *pdev) >> +{ >> + return sunxi_pinctrl_init(pdev, >> + &a64_pinctrl_data); >> +} >> + >> +static const struct of_device_id a64_pinctrl_match[] = { >> + { .compatible = "allwinner,a64-pinctrl", }, >> + {} >> +}; >> +MODULE_DEVICE_TABLE(of, a64_pinctrl_match); >> + >> +static struct platform_driver a64_pinctrl_driver = { >> + .probe = a64_pinctrl_probe, >> + .driver = { >> + .name = "a64-pinctrl", >> + .of_match_table = a64_pinctrl_match, >> + }, >> +}; >> +module_platform_driver(a64_pinctrl_driver); >> + >> +MODULE_AUTHOR("Andre Przywara <andre.przywara-5wv7dgnIgG8@public.gmane.org>"); >> +MODULE_DESCRIPTION("Allwinner A64 pinctrl driver"); >> +MODULE_LICENSE("GPL"); > > For the above function names one could also think about using the > existing naming scheme including the SoC family as we do in the > other sunxi pinctrl drivers, but as they are only internal to the > driver, that would really just be a matter of cosmetics :-). Indeed ;-) And it is more to type and may potentially break 80 character lines, so if you don't mind, I keep it that way (or could add a "sunxi_" if that is really asked for). Thanks for looking at this and your input! Cheers, Andre. ^ permalink raw reply [flat|nested] 13+ messages in thread
[parent not found: <56AFE0EC.8080207-5wv7dgnIgG8@public.gmane.org>]
* Re: Re: [PATCH 05/11] drivers: pinctrl: add driver for Allwinner A64 SoC [not found] ` <56AFE0EC.8080207-5wv7dgnIgG8@public.gmane.org> @ 2016-02-02 1:58 ` Siarhei Siamashka 2016-02-02 14:24 ` [linux-sunxi] " Andre Przywara 2016-02-02 17:37 ` Maxime Ripard 2016-02-02 10:00 ` Maxime Ripard 1 sibling, 2 replies; 13+ messages in thread From: Siarhei Siamashka @ 2016-02-02 1:58 UTC (permalink / raw) To: André Przywara Cc: Karsten Merker, Maxime Ripard, Chen-Yu Tsai, linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, Arnd Bergmann, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, linux-kernel-u79uwXL29TY76Z2rM5mHXA, Linus Walleij, Vishnu Patekar, linux-gpio-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, devicetree-u79uwXL29TY76Z2rM5mHXA On Mon, 1 Feb 2016 22:49:16 +0000 André Przywara <andre.przywara-5wv7dgnIgG8@public.gmane.org> wrote: > On 01/02/16 18:27, Karsten Merker wrote: > > Hi Karsten, > > thank you very much for your feedback! > > > On Mon, Feb 01, 2016 at 05:39:24PM +0000, Andre Przywara wrote: > >> Based on the Allwinner A64 user manual and on the previous sunxi > >> pinctrl drivers this introduces the pin multiplex assignments for > >> the ARMv8 Allwinner A64 SoC. > >> Port A is apparently used for the fixed function DRAM controller, so > >> the ports start at B here (the manual mentions "n from 1 to 7", so > >> not starting at 0). > >> > >> Signed-off-by: Andre Przywara <andre.przywara-5wv7dgnIgG8@public.gmane.org> > >> --- > >> .../bindings/pinctrl/allwinner,sunxi-pinctrl.txt | 1 + > >> arch/arm64/Kconfig.platforms | 1 + > >> drivers/pinctrl/sunxi/Kconfig | 4 + > >> drivers/pinctrl/sunxi/Makefile | 1 + > >> drivers/pinctrl/sunxi/pinctrl-a64.c | 606 +++++++++++++++++++++ > >> 5 files changed, 613 insertions(+) > >> create mode 100644 drivers/pinctrl/sunxi/pinctrl-a64.c > >> > >> diff --git a/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt > >> index 9213b27..9050002 100644 > >> --- a/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt > >> +++ b/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt > >> @@ -21,6 +21,7 @@ Required properties: > >> "allwinner,sun9i-a80-r-pinctrl" > >> "allwinner,sun8i-a83t-pinctrl" > >> "allwinner,sun8i-h3-pinctrl" > >> + "allwinner,a64-pinctrl" > > > > Hello, > > > > on all other Allwinner SoCs we use the SoC family as part of the > > compatible, as well as in the names of the Kconfig options. To > > keep things consistent, I would like to propose doing the same on > > Arm64, i.e. using allwinner,sun50i-a64-pinctrl instead of > > allwinner,a64-pinctrl. > > Yes, I have been told this already. However I don't like this idea so > much, for the following reasons: > a) It is mostly redundant. The actual SoC (marketing) name is unique, > there is no sun6i-a20 or sun7i-a23. > b) It is not even helpful. If I got Maxime correctly, then the newer > sunxi generation numbers depend on the ARM _cores_ used in the SoC, > which is frankly the least interesting part from a Linux support > perspective. I would see some sense if it would reflect the generation > of IP blocks used, but so it is even more confusing to see that > sun7i-a20 and sun8i-a23 are related, but sun8i-h3 is a completely > different beast. The Allwinner marketing name tells you that, but the > sunxi one does not. > c) It is very confusing for people not dealing with it everyday. Just > because I own a BananaPi I know that the A20 is sun7i, but I am totally > lost when it comes to all the other names. And even now it took me about > a minute to find the appropriate Wiki page which explains part of that > story. > d) Most importantly ;-): It kills TAB completion, unless you know the > sunxi number, which is mostly not true as pointed out in c) > > So while I see that just a<somenumber> is not really very specific, I'd > rather do away with current naming scheme for the future. In this > particular case we have the vendor name as a name space identifier > already, so there is no possible confusion with ARM Cortex naming, for > instance. > > Also as this is now moving into the arm64 world, I'd like to use the > opportunity to fix things that are not really optimal, the naming is one > of them. One of the problems is that A64 name is not unique. We have reasons to believe that there are also H64 and R18 out there using exactly the same die, but possibly available in different packaging (a different ball grid pitch? or maybe a different set of peripherals routed to the outside?). Early prototypes of the Pine64 board were using Allwinner R18 and the Jide Remix Mini HTPC box is using Allwinner H64. The bootloader sources from Allwinner are also referring to A64 as AW1689, which makes some sense because it is the chip id number that is accessible for runtime identification via reading the SRAM_VER_REG hardware register: http://linux-sunxi.org/SRAM_Controller_Register_Guide#SRAM_VER_REG So would it be a good idea to use "aw1689" as a compatible property in the DT instead of "a64"? Or maybe have "aw1689-a64" and "aw1689-h64", which would be similar to the existing "sun5i-a13" and "sun5i-a10s" naming convention? -- Best regards, Siarhei Siamashka -- 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] 13+ messages in thread
* Re: [linux-sunxi] Re: [PATCH 05/11] drivers: pinctrl: add driver for Allwinner A64 SoC 2016-02-02 1:58 ` Siarhei Siamashka @ 2016-02-02 14:24 ` Andre Przywara 2016-02-02 17:37 ` Maxime Ripard 1 sibling, 0 replies; 13+ messages in thread From: Andre Przywara @ 2016-02-02 14:24 UTC (permalink / raw) To: Siarhei Siamashka Cc: Karsten Merker, Maxime Ripard, Chen-Yu Tsai, linux-sunxi, Arnd Bergmann, linux-arm-kernel, linux-kernel, Linus Walleij, Vishnu Patekar, linux-gpio, Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, devicetree Hi, On 02/02/16 01:58, Siarhei Siamashka wrote: > On Mon, 1 Feb 2016 22:49:16 +0000 > André Przywara <andre.przywara@arm.com> wrote: > >> On 01/02/16 18:27, Karsten Merker wrote: >> >> Hi Karsten, >> >> thank you very much for your feedback! >> >>> On Mon, Feb 01, 2016 at 05:39:24PM +0000, Andre Przywara wrote: >>>> Based on the Allwinner A64 user manual and on the previous sunxi >>>> pinctrl drivers this introduces the pin multiplex assignments for >>>> the ARMv8 Allwinner A64 SoC. >>>> Port A is apparently used for the fixed function DRAM controller, so >>>> the ports start at B here (the manual mentions "n from 1 to 7", so >>>> not starting at 0). >>>> >>>> Signed-off-by: Andre Przywara <andre.przywara@arm.com> >>>> --- >>>> .../bindings/pinctrl/allwinner,sunxi-pinctrl.txt | 1 + >>>> arch/arm64/Kconfig.platforms | 1 + >>>> drivers/pinctrl/sunxi/Kconfig | 4 + >>>> drivers/pinctrl/sunxi/Makefile | 1 + >>>> drivers/pinctrl/sunxi/pinctrl-a64.c | 606 +++++++++++++++++++++ >>>> 5 files changed, 613 insertions(+) >>>> create mode 100644 drivers/pinctrl/sunxi/pinctrl-a64.c >>>> >>>> diff --git a/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt >>>> index 9213b27..9050002 100644 >>>> --- a/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt >>>> +++ b/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt >>>> @@ -21,6 +21,7 @@ Required properties: >>>> "allwinner,sun9i-a80-r-pinctrl" >>>> "allwinner,sun8i-a83t-pinctrl" >>>> "allwinner,sun8i-h3-pinctrl" >>>> + "allwinner,a64-pinctrl" >>> >>> Hello, >>> >>> on all other Allwinner SoCs we use the SoC family as part of the >>> compatible, as well as in the names of the Kconfig options. To >>> keep things consistent, I would like to propose doing the same on >>> Arm64, i.e. using allwinner,sun50i-a64-pinctrl instead of >>> allwinner,a64-pinctrl. >> >> Yes, I have been told this already. However I don't like this idea so >> much, for the following reasons: >> a) It is mostly redundant. The actual SoC (marketing) name is unique, >> there is no sun6i-a20 or sun7i-a23. >> b) It is not even helpful. If I got Maxime correctly, then the newer >> sunxi generation numbers depend on the ARM _cores_ used in the SoC, >> which is frankly the least interesting part from a Linux support >> perspective. I would see some sense if it would reflect the generation >> of IP blocks used, but so it is even more confusing to see that >> sun7i-a20 and sun8i-a23 are related, but sun8i-h3 is a completely >> different beast. The Allwinner marketing name tells you that, but the >> sunxi one does not. >> c) It is very confusing for people not dealing with it everyday. Just >> because I own a BananaPi I know that the A20 is sun7i, but I am totally >> lost when it comes to all the other names. And even now it took me about >> a minute to find the appropriate Wiki page which explains part of that >> story. >> d) Most importantly ;-): It kills TAB completion, unless you know the >> sunxi number, which is mostly not true as pointed out in c) >> >> So while I see that just a<somenumber> is not really very specific, I'd >> rather do away with current naming scheme for the future. In this >> particular case we have the vendor name as a name space identifier >> already, so there is no possible confusion with ARM Cortex naming, for >> instance. >> >> Also as this is now moving into the arm64 world, I'd like to use the >> opportunity to fix things that are not really optimal, the naming is one >> of them. > > One of the problems is that A64 name is not unique. We have reasons > to believe that there are also H64 and R18 out there using exactly > the same die, but possibly available in different packaging (a different > ball grid pitch? or maybe a different set of peripherals routed to the > outside?). Early prototypes of the Pine64 board were using Allwinner R18 > and the Jide Remix Mini HTPC box is using Allwinner H64. So if the differences are actually hidden from software, why would we care? See below for an example on using DT to cover this. > The bootloader sources from Allwinner are also referring to A64 as > AW1689, which makes some sense because it is the chip id number that > is accessible for runtime identification via reading the SRAM_VER_REG > hardware register: > > http://linux-sunxi.org/SRAM_Controller_Register_Guide#SRAM_VER_REG > > So would it be a good idea to use "aw1689" as a compatible property > in the DT instead of "a64"? Or maybe have "aw1689-a64" and > "aw1689-h64", which would be similar to the existing "sun5i-a13" > and "sun5i-a10s" naming convention? I would be fine with that if it really reflects something in the hardware. And I like it more than the rather arbitrary sun50i name. But on the other hand it seems to be completely unknown so far (Google just turns up this email and your sunxi-fel setup, basically). So I am not sure we should introduce yet another naming scheme. So looking at the compatible definition in the DT, this looks like a perfect example of a fall-back name to me: For the Pine64 we use "allwinner,a64", any other board could use say a: "allwinner,h64", "allwinner,a64" compatible naming. So as long as we don't need any h64 specifics, going with the A64 support code is fine. Should later the need arise to fix something for the H64 only, we can add this easily and be covered automatically. FWIW, I just have received this Remix Mini PC thing, which I ordered to see what's with the H64 and to make sure the SoC/board abstraction is right. So let me see what this version register looks like there and how it behaves with the proposed kernel patches (should I be able to hack it). Cheers, Andre. -- To unsubscribe from this list: send the line "unsubscribe linux-gpio" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Re: [PATCH 05/11] drivers: pinctrl: add driver for Allwinner A64 SoC 2016-02-02 1:58 ` Siarhei Siamashka 2016-02-02 14:24 ` [linux-sunxi] " Andre Przywara @ 2016-02-02 17:37 ` Maxime Ripard 1 sibling, 0 replies; 13+ messages in thread From: Maxime Ripard @ 2016-02-02 17:37 UTC (permalink / raw) To: Siarhei Siamashka Cc: André Przywara, Karsten Merker, Chen-Yu Tsai, linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, Arnd Bergmann, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, linux-kernel-u79uwXL29TY76Z2rM5mHXA, Linus Walleij, Vishnu Patekar, linux-gpio-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, devicetree-u79uwXL29TY76Z2rM5mHXA [-- Attachment #1: Type: text/plain, Size: 4888 bytes --] Hi, On Tue, Feb 02, 2016 at 03:58:52AM +0200, Siarhei Siamashka wrote: > > > On Mon, Feb 01, 2016 at 05:39:24PM +0000, Andre Przywara wrote: > > >> Based on the Allwinner A64 user manual and on the previous sunxi > > >> pinctrl drivers this introduces the pin multiplex assignments for > > >> the ARMv8 Allwinner A64 SoC. > > >> Port A is apparently used for the fixed function DRAM controller, so > > >> the ports start at B here (the manual mentions "n from 1 to 7", so > > >> not starting at 0). > > >> > > >> Signed-off-by: Andre Przywara <andre.przywara-5wv7dgnIgG8@public.gmane.org> > > >> --- > > >> .../bindings/pinctrl/allwinner,sunxi-pinctrl.txt | 1 + > > >> arch/arm64/Kconfig.platforms | 1 + > > >> drivers/pinctrl/sunxi/Kconfig | 4 + > > >> drivers/pinctrl/sunxi/Makefile | 1 + > > >> drivers/pinctrl/sunxi/pinctrl-a64.c | 606 +++++++++++++++++++++ > > >> 5 files changed, 613 insertions(+) > > >> create mode 100644 drivers/pinctrl/sunxi/pinctrl-a64.c > > >> > > >> diff --git a/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt > > >> index 9213b27..9050002 100644 > > >> --- a/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt > > >> +++ b/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt > > >> @@ -21,6 +21,7 @@ Required properties: > > >> "allwinner,sun9i-a80-r-pinctrl" > > >> "allwinner,sun8i-a83t-pinctrl" > > >> "allwinner,sun8i-h3-pinctrl" > > >> + "allwinner,a64-pinctrl" > > > > > > Hello, > > > > > > on all other Allwinner SoCs we use the SoC family as part of the > > > compatible, as well as in the names of the Kconfig options. To > > > keep things consistent, I would like to propose doing the same on > > > Arm64, i.e. using allwinner,sun50i-a64-pinctrl instead of > > > allwinner,a64-pinctrl. > > > > Yes, I have been told this already. However I don't like this idea so > > much, for the following reasons: > > a) It is mostly redundant. The actual SoC (marketing) name is unique, > > there is no sun6i-a20 or sun7i-a23. > > b) It is not even helpful. If I got Maxime correctly, then the newer > > sunxi generation numbers depend on the ARM _cores_ used in the SoC, > > which is frankly the least interesting part from a Linux support > > perspective. I would see some sense if it would reflect the generation > > of IP blocks used, but so it is even more confusing to see that > > sun7i-a20 and sun8i-a23 are related, but sun8i-h3 is a completely > > different beast. The Allwinner marketing name tells you that, but the > > sunxi one does not. > > c) It is very confusing for people not dealing with it everyday. Just > > because I own a BananaPi I know that the A20 is sun7i, but I am totally > > lost when it comes to all the other names. And even now it took me about > > a minute to find the appropriate Wiki page which explains part of that > > story. > > d) Most importantly ;-): It kills TAB completion, unless you know the > > sunxi number, which is mostly not true as pointed out in c) > > > > So while I see that just a<somenumber> is not really very specific, I'd > > rather do away with current naming scheme for the future. In this > > particular case we have the vendor name as a name space identifier > > already, so there is no possible confusion with ARM Cortex naming, for > > instance. > > > > Also as this is now moving into the arm64 world, I'd like to use the > > opportunity to fix things that are not really optimal, the naming is one > > of them. > > One of the problems is that A64 name is not unique. We have reasons > to believe that there are also H64 and R18 out there using exactly > the same die, but possibly available in different packaging (a different > ball grid pitch? or maybe a different set of peripherals routed to the > outside?). Early prototypes of the Pine64 board were using Allwinner R18 > and the Jide Remix Mini HTPC box is using Allwinner H64. > > The bootloader sources from Allwinner are also referring to A64 as > AW1689, which makes some sense because it is the chip id number that > is accessible for runtime identification via reading the SRAM_VER_REG > hardware register: > > http://linux-sunxi.org/SRAM_Controller_Register_Guide#SRAM_VER_REG > > So would it be a good idea to use "aw1689" as a compatible property > in the DT instead of "a64"? Or maybe have "aw1689-a64" and > "aw1689-h64", which would be similar to the existing "sun5i-a13" > and "sun5i-a10s" naming convention? If someone cannot find out the family name that is documented on several places, I'm not sure he'll find the obscure, internal code name. Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 05/11] drivers: pinctrl: add driver for Allwinner A64 SoC [not found] ` <56AFE0EC.8080207-5wv7dgnIgG8@public.gmane.org> 2016-02-02 1:58 ` Siarhei Siamashka @ 2016-02-02 10:00 ` Maxime Ripard 2016-02-02 10:09 ` Chen-Yu Tsai 2016-02-02 16:53 ` Andre Przywara 1 sibling, 2 replies; 13+ messages in thread From: Maxime Ripard @ 2016-02-02 10:00 UTC (permalink / raw) To: André Przywara Cc: Karsten Merker, Chen-Yu Tsai, linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, Arnd Bergmann, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, linux-kernel-u79uwXL29TY76Z2rM5mHXA, Linus Walleij, Vishnu Patekar, linux-gpio-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, devicetree-u79uwXL29TY76Z2rM5mHXA [-- Attachment #1: Type: text/plain, Size: 4678 bytes --] Hi Andre, On Mon, Feb 01, 2016 at 10:49:16PM +0000, André Przywara wrote: > On 01/02/16 18:27, Karsten Merker wrote: > > Hi Karsten, > > thank you very much for your feedback! > > > On Mon, Feb 01, 2016 at 05:39:24PM +0000, Andre Przywara wrote: > >> Based on the Allwinner A64 user manual and on the previous sunxi > >> pinctrl drivers this introduces the pin multiplex assignments for > >> the ARMv8 Allwinner A64 SoC. > >> Port A is apparently used for the fixed function DRAM controller, so > >> the ports start at B here (the manual mentions "n from 1 to 7", so > >> not starting at 0). > >> > >> Signed-off-by: Andre Przywara <andre.przywara-5wv7dgnIgG8@public.gmane.org> > >> --- > >> .../bindings/pinctrl/allwinner,sunxi-pinctrl.txt | 1 + > >> arch/arm64/Kconfig.platforms | 1 + > >> drivers/pinctrl/sunxi/Kconfig | 4 + > >> drivers/pinctrl/sunxi/Makefile | 1 + > >> drivers/pinctrl/sunxi/pinctrl-a64.c | 606 +++++++++++++++++++++ > >> 5 files changed, 613 insertions(+) > >> create mode 100644 drivers/pinctrl/sunxi/pinctrl-a64.c > >> > >> diff --git a/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt > >> index 9213b27..9050002 100644 > >> --- a/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt > >> +++ b/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt > >> @@ -21,6 +21,7 @@ Required properties: > >> "allwinner,sun9i-a80-r-pinctrl" > >> "allwinner,sun8i-a83t-pinctrl" > >> "allwinner,sun8i-h3-pinctrl" > >> + "allwinner,a64-pinctrl" > > > > Hello, > > > > on all other Allwinner SoCs we use the SoC family as part of the > > compatible, as well as in the names of the Kconfig options. To > > keep things consistent, I would like to propose doing the same on > > Arm64, i.e. using allwinner,sun50i-a64-pinctrl instead of > > allwinner,a64-pinctrl. > > Yes, I have been told this already. However I don't like this idea so > much, for the following reasons: > a) It is mostly redundant. The actual SoC (marketing) name is unique, > there is no sun6i-a20 or sun7i-a23. At the same time, the family name is mostly valid too. We do share some DTSI across some SoCs already by their family name (sun5i.dtsi for the A10s/A13/R8, sun8i-a23-a33.dtsi for the A23 and A33, etc.) > b) It is not even helpful. If I got Maxime correctly, then the newer > sunxi generation numbers depend on the ARM _cores_ used in the SoC, > which is frankly the least interesting part from a Linux support > perspective. I would see some sense if it would reflect the generation > of IP blocks used, but so it is even more confusing to see that > sun7i-a20 and sun8i-a23 are related, but sun8i-h3 is a completely > different beast. The Allwinner marketing name tells you that, but the > sunxi one does not. The opposite can be said too. The A31 is quite different from the A33, while the A83 is much closer to the H3 than it is to the A80. Their marketing scheme is messy. In all aspects. We have a scheme that worked, I'd really like to stick with it. > c) It is very confusing for people not dealing with it everyday. Just > because I own a BananaPi I know that the A20 is sun7i, but I am totally > lost when it comes to all the other names. And even now it took me about > a minute to find the appropriate Wiki page which explains part of that > story. > d) Most importantly ;-): It kills TAB completion, unless you know the > sunxi number, which is mostly not true as pointed out in c) Both of these are true, but are about the DT filenames, and not the compatibles. I'd agree with you on this one now that we have per-vendor subfolders in boot/dts, but it was not the case before, and I'm pretty sure that to anyone that is not aware of the Allwinner SoCs names, having an A<number>.dtsi in arch/arm/boot/dts, it would be about a Cortex-A<number>, and definitely not an SoC from some random vendor. So, droping it in the filenames, why not. But I'd really like to keep the same compatible scheme. 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] 13+ messages in thread
* Re: [PATCH 05/11] drivers: pinctrl: add driver for Allwinner A64 SoC 2016-02-02 10:00 ` Maxime Ripard @ 2016-02-02 10:09 ` Chen-Yu Tsai 2016-02-02 16:53 ` Andre Przywara 1 sibling, 0 replies; 13+ messages in thread From: Chen-Yu Tsai @ 2016-02-02 10:09 UTC (permalink / raw) To: André Przywara Cc: Maxime Ripard, Karsten Merker, Chen-Yu Tsai, linux-sunxi, Arnd Bergmann, linux-arm-kernel, linux-kernel, Linus Walleij, Vishnu Patekar, linux-gpio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, devicetree On Tue, Feb 2, 2016 at 6:00 PM, Maxime Ripard <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote: > Hi Andre, > > On Mon, Feb 01, 2016 at 10:49:16PM +0000, André Przywara wrote: >> On 01/02/16 18:27, Karsten Merker wrote: >> >> Hi Karsten, >> >> thank you very much for your feedback! >> >> > On Mon, Feb 01, 2016 at 05:39:24PM +0000, Andre Przywara wrote: >> >> Based on the Allwinner A64 user manual and on the previous sunxi >> >> pinctrl drivers this introduces the pin multiplex assignments for >> >> the ARMv8 Allwinner A64 SoC. >> >> Port A is apparently used for the fixed function DRAM controller, so >> >> the ports start at B here (the manual mentions "n from 1 to 7", so >> >> not starting at 0). >> >> >> >> Signed-off-by: Andre Przywara <andre.przywara-5wv7dgnIgG8@public.gmane.org> >> >> --- >> >> .../bindings/pinctrl/allwinner,sunxi-pinctrl.txt | 1 + >> >> arch/arm64/Kconfig.platforms | 1 + >> >> drivers/pinctrl/sunxi/Kconfig | 4 + >> >> drivers/pinctrl/sunxi/Makefile | 1 + >> >> drivers/pinctrl/sunxi/pinctrl-a64.c | 606 +++++++++++++++++++++ >> >> 5 files changed, 613 insertions(+) >> >> create mode 100644 drivers/pinctrl/sunxi/pinctrl-a64.c >> >> >> >> diff --git a/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt >> >> index 9213b27..9050002 100644 >> >> --- a/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt >> >> +++ b/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt >> >> @@ -21,6 +21,7 @@ Required properties: >> >> "allwinner,sun9i-a80-r-pinctrl" >> >> "allwinner,sun8i-a83t-pinctrl" >> >> "allwinner,sun8i-h3-pinctrl" >> >> + "allwinner,a64-pinctrl" >> > >> > Hello, >> > >> > on all other Allwinner SoCs we use the SoC family as part of the >> > compatible, as well as in the names of the Kconfig options. To >> > keep things consistent, I would like to propose doing the same on >> > Arm64, i.e. using allwinner,sun50i-a64-pinctrl instead of >> > allwinner,a64-pinctrl. >> >> Yes, I have been told this already. However I don't like this idea so >> much, for the following reasons: >> a) It is mostly redundant. The actual SoC (marketing) name is unique, >> there is no sun6i-a20 or sun7i-a23. > > At the same time, the family name is mostly valid too. > > We do share some DTSI across some SoCs already by their family name > (sun5i.dtsi for the A10s/A13/R8, sun8i-a23-a33.dtsi for the A23 and > A33, etc.) > >> b) It is not even helpful. If I got Maxime correctly, then the newer >> sunxi generation numbers depend on the ARM _cores_ used in the SoC, >> which is frankly the least interesting part from a Linux support >> perspective. I would see some sense if it would reflect the generation >> of IP blocks used, but so it is even more confusing to see that >> sun7i-a20 and sun8i-a23 are related, but sun8i-h3 is a completely >> different beast. The Allwinner marketing name tells you that, but the >> sunxi one does not. > > The opposite can be said too. > > The A31 is quite different from the A33, while the A83 is much closer > to the H3 than it is to the A80. Their marketing scheme is messy. In > all aspects. We have a scheme that worked, I'd really like to stick > with it. > >> c) It is very confusing for people not dealing with it everyday. Just >> because I own a BananaPi I know that the A20 is sun7i, but I am totally >> lost when it comes to all the other names. And even now it took me about >> a minute to find the appropriate Wiki page which explains part of that >> story. >> d) Most importantly ;-): It kills TAB completion, unless you know the >> sunxi number, which is mostly not true as pointed out in c) > > Both of these are true, but are about the DT filenames, and not the > compatibles. I'd agree with you on this one now that we have > per-vendor subfolders in boot/dts, but it was not the case before, and > I'm pretty sure that to anyone that is not aware of the Allwinner SoCs > names, having an A<number>.dtsi in arch/arm/boot/dts, it would be > about a Cortex-A<number>, and definitely not an SoC from some random > vendor. > > So, droping it in the filenames, why not. But I'd really like to keep > the same compatible scheme. If we do end up dropping it from the filenames, can you (André) update MAINTAINERS to add "arch/arm64/boot/dts/sunxi/" to the sunxi entry? Thanks. ChenYu -- 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] 13+ messages in thread
* Re: [PATCH 05/11] drivers: pinctrl: add driver for Allwinner A64 SoC 2016-02-02 10:00 ` Maxime Ripard 2016-02-02 10:09 ` Chen-Yu Tsai @ 2016-02-02 16:53 ` Andre Przywara [not found] ` <56B0DF26.10203-5wv7dgnIgG8@public.gmane.org> 1 sibling, 1 reply; 13+ messages in thread From: Andre Przywara @ 2016-02-02 16:53 UTC (permalink / raw) To: Maxime Ripard Cc: Karsten Merker, Chen-Yu Tsai, linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, Arnd Bergmann, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, linux-kernel-u79uwXL29TY76Z2rM5mHXA, Linus Walleij, Vishnu Patekar, linux-gpio-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, devicetree-u79uwXL29TY76Z2rM5mHXA Hi, On 02/02/16 10:00, Maxime Ripard wrote: > Hi Andre, > > On Mon, Feb 01, 2016 at 10:49:16PM +0000, André Przywara wrote: >> On 01/02/16 18:27, Karsten Merker wrote: >> >> Hi Karsten, >> >> thank you very much for your feedback! >> >>> On Mon, Feb 01, 2016 at 05:39:24PM +0000, Andre Przywara wrote: >>>> Based on the Allwinner A64 user manual and on the previous sunxi >>>> pinctrl drivers this introduces the pin multiplex assignments for >>>> the ARMv8 Allwinner A64 SoC. >>>> Port A is apparently used for the fixed function DRAM controller, so >>>> the ports start at B here (the manual mentions "n from 1 to 7", so >>>> not starting at 0). >>>> >>>> Signed-off-by: Andre Przywara <andre.przywara-5wv7dgnIgG8@public.gmane.org> >>>> --- >>>> .../bindings/pinctrl/allwinner,sunxi-pinctrl.txt | 1 + >>>> arch/arm64/Kconfig.platforms | 1 + >>>> drivers/pinctrl/sunxi/Kconfig | 4 + >>>> drivers/pinctrl/sunxi/Makefile | 1 + >>>> drivers/pinctrl/sunxi/pinctrl-a64.c | 606 +++++++++++++++++++++ >>>> 5 files changed, 613 insertions(+) >>>> create mode 100644 drivers/pinctrl/sunxi/pinctrl-a64.c >>>> >>>> diff --git a/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt >>>> index 9213b27..9050002 100644 >>>> --- a/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt >>>> +++ b/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt >>>> @@ -21,6 +21,7 @@ Required properties: >>>> "allwinner,sun9i-a80-r-pinctrl" >>>> "allwinner,sun8i-a83t-pinctrl" >>>> "allwinner,sun8i-h3-pinctrl" >>>> + "allwinner,a64-pinctrl" >>> >>> Hello, >>> >>> on all other Allwinner SoCs we use the SoC family as part of the >>> compatible, as well as in the names of the Kconfig options. To >>> keep things consistent, I would like to propose doing the same on >>> Arm64, i.e. using allwinner,sun50i-a64-pinctrl instead of >>> allwinner,a64-pinctrl. >> >> Yes, I have been told this already. However I don't like this idea so >> much, for the following reasons: >> a) It is mostly redundant. The actual SoC (marketing) name is unique, >> there is no sun6i-a20 or sun7i-a23. > > At the same time, the family name is mostly valid too. > > We do share some DTSI across some SoCs already by their family name > (sun5i.dtsi for the A10s/A13/R8, sun8i-a23-a33.dtsi for the A23 and > A33, etc.) > >> b) It is not even helpful. If I got Maxime correctly, then the newer >> sunxi generation numbers depend on the ARM _cores_ used in the SoC, >> which is frankly the least interesting part from a Linux support >> perspective. I would see some sense if it would reflect the generation >> of IP blocks used, but so it is even more confusing to see that >> sun7i-a20 and sun8i-a23 are related, but sun8i-h3 is a completely >> different beast. The Allwinner marketing name tells you that, but the >> sunxi one does not. > > The opposite can be said too. > > The A31 is quite different from the A33, while the A83 is much closer > to the H3 than it is to the A80. Their marketing scheme is messy. In > all aspects. We have a scheme that worked, I'd really like to stick > with it. But also H3 and A64 are closely related, still having a totally different sunxi name. I guess we could give examples and counter-examples for hours, and just making it possible to have two contradicting rationales lets me think this whole naming scheme is inconsistent ;-) I see that it may have fulfilled a purpose in the past (sun3i-sun7i, maybe sun8i), but I am not very happy with proliferating this into the (arm64) future. Allwinner A<something> is a perfectly google-able and well understood naming, also unique. So why add some mysterious sun{4,5,6,7,8,9,50}i to it? So I will amend identifiers/filenames where the name was just A64, without any Allwinner reference (like in the pinctrl driver). I am in for using sunxi as a shorthand for Allwinner, since this is a) shorter, b) is already all over the kernel and c) doesn't give direct credit to a company that apparently doesn't care ;-) >> c) It is very confusing for people not dealing with it everyday. Just >> because I own a BananaPi I know that the A20 is sun7i, but I am totally >> lost when it comes to all the other names. And even now it took me about >> a minute to find the appropriate Wiki page which explains part of that >> story. >> d) Most importantly ;-): It kills TAB completion, unless you know the >> sunxi number, which is mostly not true as pointed out in c) > > Both of these are true, but are about the DT filenames, and not the > compatibles. I'd agree with you on this one now that we have > per-vendor subfolders in boot/dts, but it was not the case before, and > I'm pretty sure that to anyone that is not aware of the Allwinner SoCs > names, having an A<number>.dtsi in arch/arm/boot/dts, it would be > about a Cortex-A<number>, and definitely not an SoC from some random > vendor. I completely agree on that, but this is in arch/arm64/boot/dts/allwinner, so it's pretty unique. Other vendors in there seem to think the same. I also see that just an "a" as a prefix is pretty short, so should we go with "aw" instead? But actually I would just leave it as it is. > So, droping it in the filenames, why not. But I'd really like to keep > the same compatible scheme. And I still don't get this: in the DT compatible scheme we always have a vendor prefix, so allwinner,a64 is surely not a mysterious ARM Ltd. core or a new Apple SoC. Instead it is the A64 from Allwinner, full stop. So why should we add an arbitrary and confusing sun50i naming to it (when it actually should be more like "sun8i-a64"). Cheers, Andre. -- 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] 13+ messages in thread
[parent not found: <56B0DF26.10203-5wv7dgnIgG8@public.gmane.org>]
* Re: [PATCH 05/11] drivers: pinctrl: add driver for Allwinner A64 SoC [not found] ` <56B0DF26.10203-5wv7dgnIgG8@public.gmane.org> @ 2016-02-04 16:51 ` Maxime Ripard 2016-02-08 15:54 ` Rob Herring 0 siblings, 1 reply; 13+ messages in thread From: Maxime Ripard @ 2016-02-04 16:51 UTC (permalink / raw) To: Andre Przywara Cc: Karsten Merker, Chen-Yu Tsai, linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, Arnd Bergmann, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, linux-kernel-u79uwXL29TY76Z2rM5mHXA, Linus Walleij, Vishnu Patekar, linux-gpio-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, devicetree-u79uwXL29TY76Z2rM5mHXA [-- Attachment #1: Type: text/plain, Size: 941 bytes --] Hi Andre, On Tue, Feb 02, 2016 at 04:53:58PM +0000, Andre Przywara wrote: > > So, droping it in the filenames, why not. But I'd really like to keep > > the same compatible scheme. > > And I still don't get this: in the DT compatible scheme we always have a > vendor prefix, so allwinner,a64 is surely not a mysterious ARM Ltd. core > or a new Apple SoC. Instead it is the A64 from Allwinner, full stop. So > why should we add an arbitrary and confusing sun50i naming to it (when > it actually should be more like "sun8i-a64"). I don't decide on their marketing names. And I know you want to start anew with the arm64 SoCs, but the truth is, you don't. Most of the compatibles in the DTSI are from earlier SoCs, and we have to keep that legacy and remain consistent with it. With all the good and bad things a legacy imply. Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 05/11] drivers: pinctrl: add driver for Allwinner A64 SoC 2016-02-04 16:51 ` Maxime Ripard @ 2016-02-08 15:54 ` Rob Herring 2016-02-08 15:58 ` Andre Przywara 0 siblings, 1 reply; 13+ messages in thread From: Rob Herring @ 2016-02-08 15:54 UTC (permalink / raw) To: Maxime Ripard Cc: Andre Przywara, Karsten Merker, Chen-Yu Tsai, linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, Arnd Bergmann, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, linux-kernel-u79uwXL29TY76Z2rM5mHXA, Linus Walleij, Vishnu Patekar, linux-gpio-u79uwXL29TY76Z2rM5mHXA, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, devicetree-u79uwXL29TY76Z2rM5mHXA On Thu, Feb 04, 2016 at 05:51:51PM +0100, Maxime Ripard wrote: > Hi Andre, > > On Tue, Feb 02, 2016 at 04:53:58PM +0000, Andre Przywara wrote: > > > So, droping it in the filenames, why not. But I'd really like to keep > > > the same compatible scheme. > > > > And I still don't get this: in the DT compatible scheme we always have a > > vendor prefix, so allwinner,a64 is surely not a mysterious ARM Ltd. core > > or a new Apple SoC. Instead it is the A64 from Allwinner, full stop. So > > why should we add an arbitrary and confusing sun50i naming to it (when > > it actually should be more like "sun8i-a64"). > > I don't decide on their marketing names. And I know you want to start > anew with the arm64 SoCs, but the truth is, you don't. Most of the > compatibles in the DTSI are from earlier SoCs, and we have to keep > that legacy and remain consistent with it. With all the good and bad > things a legacy imply. I have to agree. Unless there is some agreement to move to another naming scheme, then just follow the same pattern. If sunXi is just a made up name outside of Allwinner to provide some logical grouping of SoCs, then yes, that probably should not have been done. Rob ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 05/11] drivers: pinctrl: add driver for Allwinner A64 SoC 2016-02-08 15:54 ` Rob Herring @ 2016-02-08 15:58 ` Andre Przywara [not found] ` <56B8BB1A.8010705-5wv7dgnIgG8@public.gmane.org> 0 siblings, 1 reply; 13+ messages in thread From: Andre Przywara @ 2016-02-08 15:58 UTC (permalink / raw) To: Rob Herring, Maxime Ripard Cc: Karsten Merker, Chen-Yu Tsai, linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, Arnd Bergmann, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, linux-kernel-u79uwXL29TY76Z2rM5mHXA, Linus Walleij, Vishnu Patekar, linux-gpio-u79uwXL29TY76Z2rM5mHXA, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, devicetree-u79uwXL29TY76Z2rM5mHXA Hi, On 08/02/16 15:54, Rob Herring wrote: > On Thu, Feb 04, 2016 at 05:51:51PM +0100, Maxime Ripard wrote: >> Hi Andre, >> >> On Tue, Feb 02, 2016 at 04:53:58PM +0000, Andre Przywara wrote: >>>> So, droping it in the filenames, why not. But I'd really like to keep >>>> the same compatible scheme. >>> >>> And I still don't get this: in the DT compatible scheme we always have a >>> vendor prefix, so allwinner,a64 is surely not a mysterious ARM Ltd. core >>> or a new Apple SoC. Instead it is the A64 from Allwinner, full stop. So >>> why should we add an arbitrary and confusing sun50i naming to it (when >>> it actually should be more like "sun8i-a64"). >> >> I don't decide on their marketing names. And I know you want to start >> anew with the arm64 SoCs, but the truth is, you don't. Most of the >> compatibles in the DTSI are from earlier SoCs, and we have to keep >> that legacy and remain consistent with it. With all the good and bad >> things a legacy imply. > > I have to agree. Unless there is some agreement to move to another > naming scheme, then just follow the same pattern. If sunXi is just a > made up name outside of Allwinner to provide some logical grouping of > SoCs, then yes, that probably should not have been done. So I still don't like it, but will not waste my time or energy on that front. Maxime, do you want "allwinner,sun50i-a64" or would "allwinner,sunxi-a64" be OK as well? Cheers, Andre. -- 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] 13+ messages in thread
[parent not found: <56B8BB1A.8010705-5wv7dgnIgG8@public.gmane.org>]
* Re: [PATCH 05/11] drivers: pinctrl: add driver for Allwinner A64 SoC [not found] ` <56B8BB1A.8010705-5wv7dgnIgG8@public.gmane.org> @ 2016-02-09 17:12 ` Maxime Ripard 0 siblings, 0 replies; 13+ messages in thread From: Maxime Ripard @ 2016-02-09 17:12 UTC (permalink / raw) To: Andre Przywara Cc: Rob Herring, Karsten Merker, Chen-Yu Tsai, linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, Arnd Bergmann, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, linux-kernel-u79uwXL29TY76Z2rM5mHXA, Linus Walleij, Vishnu Patekar, linux-gpio-u79uwXL29TY76Z2rM5mHXA, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, devicetree-u79uwXL29TY76Z2rM5mHXA [-- Attachment #1: Type: text/plain, Size: 1695 bytes --] On Mon, Feb 08, 2016 at 03:58:18PM +0000, Andre Przywara wrote: > Hi, > > On 08/02/16 15:54, Rob Herring wrote: > > On Thu, Feb 04, 2016 at 05:51:51PM +0100, Maxime Ripard wrote: > >> Hi Andre, > >> > >> On Tue, Feb 02, 2016 at 04:53:58PM +0000, Andre Przywara wrote: > >>>> So, droping it in the filenames, why not. But I'd really like to keep > >>>> the same compatible scheme. > >>> > >>> And I still don't get this: in the DT compatible scheme we always have a > >>> vendor prefix, so allwinner,a64 is surely not a mysterious ARM Ltd. core > >>> or a new Apple SoC. Instead it is the A64 from Allwinner, full stop. So > >>> why should we add an arbitrary and confusing sun50i naming to it (when > >>> it actually should be more like "sun8i-a64"). > >> > >> I don't decide on their marketing names. And I know you want to start > >> anew with the arm64 SoCs, but the truth is, you don't. Most of the > >> compatibles in the DTSI are from earlier SoCs, and we have to keep > >> that legacy and remain consistent with it. With all the good and bad > >> things a legacy imply. > > > > I have to agree. Unless there is some agreement to move to another > > naming scheme, then just follow the same pattern. If sunXi is just a > > made up name outside of Allwinner to provide some logical grouping of > > SoCs, then yes, that probably should not have been done. > > So I still don't like it, but will not waste my time or energy on that > front. > > Maxime, do you want "allwinner,sun50i-a64" or would > "allwinner,sunxi-a64" be OK as well? The former will be fine. Thanks! Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com ^ permalink raw reply [flat|nested] 13+ messages in thread
[parent not found: <20160201184505.GB14737@excalibur.cnev.de>]
[parent not found: <20160201184505.GB14737-Hlt6eto4P0pdWf7zwHaZWbNAH6kLmebB@public.gmane.org>]
* Re: Re: [PATCH 05/11] drivers: pinctrl: add driver for Allwinner A64 SoC [not found] ` <20160201184505.GB14737-Hlt6eto4P0pdWf7zwHaZWbNAH6kLmebB@public.gmane.org> @ 2016-02-01 23:02 ` André Przywara 0 siblings, 0 replies; 13+ messages in thread From: André Przywara @ 2016-02-01 23:02 UTC (permalink / raw) To: Karsten Merker, Maxime Ripard, Chen-Yu Tsai, linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, Arnd Bergmann, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, linux-kernel-u79uwXL29TY76Z2rM5mHXA, Linus Walleij, Vishnu Patekar, linux-gpio-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, devicetree-u79uwXL29TY76Z2rM5mHXA On 01/02/16 18:45, Karsten Merker wrote: > Hello, > > I by mistake pressed "send" on my previous mail when I intended > to further edit it, so here comes a followup. > I definitely need more coffee ;-). Or less? ;-) vvvvvvvvvv Thinking of twitchy fingers... > On Mon, Feb 01, 2016 at 07:27:54PM +0100, Karsten Merker wrote: >> On Mon, Feb 01, 2016 at 05:39:24PM +0000, Andre Przywara wrote: > >>> +static const struct sunxi_pinctrl_desc a64_pinctrl_data = { >>> + .pins = a64_pins, >>> + .npins = ARRAY_SIZE(a64_pins), >>> + .irq_banks = 3, >>> +}; >>> + >>> +static int a64_pinctrl_probe(struct platform_device *pdev) >>> +{ >>> + return sunxi_pinctrl_init(pdev, >>> + &a64_pinctrl_data); >>> +} >>> + >>> +static const struct of_device_id a64_pinctrl_match[] = { >>> + { .compatible = "allwinner,a64-pinctrl", }, > > s/allwinner,a64-pinctrl/allwinner,sun50i-a64-pinctrl/ ? As mentioned in the other mail, allwinner should be enough to make the naming unique. Especially as this is about DT namings, which should be valid outside of the Linux world even. Cheers, Andre. > >>> + {} >>> +}; >>> +MODULE_DEVICE_TABLE(of, a64_pinctrl_match); >>> + >>> +static struct platform_driver a64_pinctrl_driver = { >>> + .probe = a64_pinctrl_probe, >>> + .driver = { >>> + .name = "a64-pinctrl", >>> + .of_match_table = a64_pinctrl_match, >>> + }, >>> +}; >>> +module_platform_driver(a64_pinctrl_driver); >>> + >>> +MODULE_AUTHOR("Andre Przywara <andre.przywara-5wv7dgnIgG8@public.gmane.org>"); >>> +MODULE_DESCRIPTION("Allwinner A64 pinctrl driver"); >>> +MODULE_LICENSE("GPL"); >> >> For the above function names one could also think about using the > > s/function names/variable definitions/ > >> existing naming scheme including the SoC family as we do in the >> other sunxi pinctrl drivers, but as they are only internal to the >> driver, that would really just be a matter of cosmetics :-). > > Regards, > Karsten > ^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2016-02-09 17:12 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <1454348370-3816-1-git-send-email-andre.przywara@arm.com>
[not found] ` <1454348370-3816-1-git-send-email-andre.przywara-5wv7dgnIgG8@public.gmane.org>
2016-02-01 17:39 ` [PATCH 05/11] drivers: pinctrl: add driver for Allwinner A64 SoC Andre Przywara
[not found] ` <20160201182754.GA14737@excalibur.cnev.de>
[not found] ` <20160201182754.GA14737-Hlt6eto4P0pdWf7zwHaZWbNAH6kLmebB@public.gmane.org>
2016-02-01 22:49 ` André Przywara
[not found] ` <56AFE0EC.8080207-5wv7dgnIgG8@public.gmane.org>
2016-02-02 1:58 ` Siarhei Siamashka
2016-02-02 14:24 ` [linux-sunxi] " Andre Przywara
2016-02-02 17:37 ` Maxime Ripard
2016-02-02 10:00 ` Maxime Ripard
2016-02-02 10:09 ` Chen-Yu Tsai
2016-02-02 16:53 ` Andre Przywara
[not found] ` <56B0DF26.10203-5wv7dgnIgG8@public.gmane.org>
2016-02-04 16:51 ` Maxime Ripard
2016-02-08 15:54 ` Rob Herring
2016-02-08 15:58 ` Andre Przywara
[not found] ` <56B8BB1A.8010705-5wv7dgnIgG8@public.gmane.org>
2016-02-09 17:12 ` Maxime Ripard
[not found] ` <20160201184505.GB14737@excalibur.cnev.de>
[not found] ` <20160201184505.GB14737-Hlt6eto4P0pdWf7zwHaZWbNAH6kLmebB@public.gmane.org>
2016-02-01 23:02 ` André Przywara
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).