* Re: [linux-sunxi] [PATCH 1/2] drivers: pinctrl: add driver for Allwinner H5 SoC [not found] <20161223125001.1176-1-icenowy@aosc.xyz> @ 2016-12-26 14:33 ` André Przywara 2016-12-30 12:55 ` Linus Walleij 0 siblings, 1 reply; 11+ messages in thread From: André Przywara @ 2016-12-26 14:33 UTC (permalink / raw) To: icenowy, Linus Walleij, Catalin Marinas, Maxime Ripard, Chen-Yu Tsai, Andre Przywara Cc: linux-arm-kernel, linux-kernel, linux-gpio, linux-sunxi Hi, On 23/12/16 12:50, Icenowy Zheng wrote: > Based on the Allwinner H5 datasheet and the pinctrl driver of the > backward-compatible H3 this introduces the pin multiplex assignments for > the H5 SoC. > > H5 introduced some more pin functions (e.g. three more groups of TS > pins, and one more groups of SIM pins) than H3. More importantly you should mention the addition of the MMC2 DS pin, since this is actually the only one we care about (I am not aware of a driver for the SIM or TS IP blocks). So while this patch technically looks correct, I was wondering if we should really explore the possibility of making the whole of sunxi pinctrl DT controlled. I brought this up a while ago, but people weren't overly enthusiastic about it, though their argument weren't really convincing to me[1]. So: As this "driver" here is basically a table linking GPIO bit settings (the actual mux value) to names and every pin we care about needs to be enumerated in the DT anyway, why not just add something like: allwinner,pinmux = <4>; to each pin(group) in the DT and get rid of this "driver" file here entirely? Apart from saving us to dump tables for each and every SoC into the kernel as a rather mechanical exercise, this would allow us to support new SoCs without having to add explicit kernel support for pinctrl. Icenowy, since you seem to have excess spare time ;-), could you imagine to have a look what would be needed to make this happen or if there are showstoppers preventing us from doing so without significant reworks? >From a 10,000 feet I'd imagine that we need to add some properties for the interrupts (number of banks?), maybe one property to set the number of used GPIO banks (to help enumeration). Also I guess the common sunxi pinctrl driver code needs some significant rework. Cheers, Andre. [1] http://marc.info/?l=linux-arm-kernel&m=145216133518718&w=2 > > Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz> > --- > drivers/pinctrl/sunxi/Kconfig | 4 + > drivers/pinctrl/sunxi/Makefile | 1 + > drivers/pinctrl/sunxi/pinctrl-sun50i-h5.c | 551 ++++++++++++++++++++++++++++++ > 3 files changed, 556 insertions(+) > create mode 100644 drivers/pinctrl/sunxi/pinctrl-sun50i-h5.c > > diff --git a/drivers/pinctrl/sunxi/Kconfig b/drivers/pinctrl/sunxi/Kconfig > index bff1ffc6f01e..e9c47e8b2ee0 100644 > --- a/drivers/pinctrl/sunxi/Kconfig > +++ b/drivers/pinctrl/sunxi/Kconfig > @@ -76,4 +76,8 @@ config PINCTRL_SUN50I_A64 > bool > select PINCTRL_SUNXI > > +config PINCTRL_SUN50I_H5 > + bool > + select PINCTRL_SUNXI > + > endif > diff --git a/drivers/pinctrl/sunxi/Makefile b/drivers/pinctrl/sunxi/Makefile > index 95f93d0561fc..bab215d25440 100644 > --- a/drivers/pinctrl/sunxi/Makefile > +++ b/drivers/pinctrl/sunxi/Makefile > @@ -17,5 +17,6 @@ obj-$(CONFIG_PINCTRL_SUN50I_A64) += pinctrl-sun50i-a64.o > obj-$(CONFIG_PINCTRL_SUN8I_A83T) += pinctrl-sun8i-a83t.o > obj-$(CONFIG_PINCTRL_SUN8I_H3) += pinctrl-sun8i-h3.o > obj-$(CONFIG_PINCTRL_SUN8I_H3_R) += pinctrl-sun8i-h3-r.o > +obj-$(CONFIG_PINCTRL_SUN50I_H5) += pinctrl-sun50i-h5.o > obj-$(CONFIG_PINCTRL_SUN9I_A80) += pinctrl-sun9i-a80.o > obj-$(CONFIG_PINCTRL_SUN9I_A80_R) += pinctrl-sun9i-a80-r.o > diff --git a/drivers/pinctrl/sunxi/pinctrl-sun50i-h5.c b/drivers/pinctrl/sunxi/pinctrl-sun50i-h5.c > new file mode 100644 > index 000000000000..98f2a6ee7634 > --- /dev/null > +++ b/drivers/pinctrl/sunxi/pinctrl-sun50i-h5.c > @@ -0,0 +1,551 @@ > +/* > + * Allwinner H5 SoC pinctrl driver. > + * > + * Copyright (C) 2016 Icenowy Zheng <icenowy@aosc.xyz> > + * > + * Based on pinctrl-sun8i-h3.c, which is: > + * Copyright (C) 2015 Jens Kuske <jenskuske@gmail.com> > + * > + * Based on pinctrl-sun8i-a23.c, which is: > + * Copyright (C) 2014 Chen-Yu Tsai <wens@csie.org> > + * Copyright (C) 2014 Maxime Ripard <maxime.ripard@free-electrons.com> > + * > + * This file is licensed under the terms of the GNU General Public > + * License version 2. This program is licensed "as is" without any > + * warranty of any kind, whether express or implied. > + */ > + > +#include <linux/module.h> > +#include <linux/platform_device.h> > +#include <linux/of.h> > +#include <linux/of_device.h> > +#include <linux/pinctrl/pinctrl.h> > + > +#include "pinctrl-sunxi.h" > + > +static const struct sunxi_desc_pin sun50i_h5_pins[] = { > + SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 0), > + SUNXI_FUNCTION(0x0, "gpio_in"), > + SUNXI_FUNCTION(0x1, "gpio_out"), > + SUNXI_FUNCTION(0x2, "uart2"), /* TX */ > + SUNXI_FUNCTION(0x3, "jtag"), /* MS */ > + SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 0)), /* PA_EINT0 */ > + SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 1), > + SUNXI_FUNCTION(0x0, "gpio_in"), > + SUNXI_FUNCTION(0x1, "gpio_out"), > + SUNXI_FUNCTION(0x2, "uart2"), /* RX */ > + SUNXI_FUNCTION(0x3, "jtag"), /* CK */ > + SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 1)), /* PA_EINT1 */ > + SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 2), > + SUNXI_FUNCTION(0x0, "gpio_in"), > + SUNXI_FUNCTION(0x1, "gpio_out"), > + SUNXI_FUNCTION(0x2, "uart2"), /* RTS */ > + SUNXI_FUNCTION(0x3, "jtag"), /* DO */ > + SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 2)), /* PA_EINT2 */ > + SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 3), > + SUNXI_FUNCTION(0x0, "gpio_in"), > + SUNXI_FUNCTION(0x1, "gpio_out"), > + SUNXI_FUNCTION(0x2, "uart2"), /* CTS */ > + SUNXI_FUNCTION(0x3, "jtag"), /* DI */ > + SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 3)), /* PA_EINT3 */ > + SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 4), > + SUNXI_FUNCTION(0x0, "gpio_in"), > + SUNXI_FUNCTION(0x1, "gpio_out"), > + SUNXI_FUNCTION(0x2, "uart0"), /* TX */ > + SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 4)), /* PA_EINT4 */ > + SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 5), > + SUNXI_FUNCTION(0x0, "gpio_in"), > + SUNXI_FUNCTION(0x1, "gpio_out"), > + SUNXI_FUNCTION(0x2, "uart0"), /* RX */ > + SUNXI_FUNCTION(0x3, "pwm0"), > + SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 5)), /* PA_EINT5 */ > + SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 6), > + SUNXI_FUNCTION(0x0, "gpio_in"), > + SUNXI_FUNCTION(0x1, "gpio_out"), > + SUNXI_FUNCTION(0x2, "sim"), /* PWREN */ > + SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 6)), /* PA_EINT6 */ > + SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 7), > + SUNXI_FUNCTION(0x0, "gpio_in"), > + SUNXI_FUNCTION(0x1, "gpio_out"), > + SUNXI_FUNCTION(0x2, "sim"), /* CLK */ > + SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 7)), /* PA_EINT7 */ > + SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 8), > + SUNXI_FUNCTION(0x0, "gpio_in"), > + SUNXI_FUNCTION(0x1, "gpio_out"), > + SUNXI_FUNCTION(0x2, "sim"), /* DATA */ > + SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 8)), /* PA_EINT8 */ > + SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 9), > + SUNXI_FUNCTION(0x0, "gpio_in"), > + SUNXI_FUNCTION(0x1, "gpio_out"), > + SUNXI_FUNCTION(0x2, "sim"), /* RST */ > + SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 9)), /* PA_EINT9 */ > + SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 10), > + SUNXI_FUNCTION(0x0, "gpio_in"), > + SUNXI_FUNCTION(0x1, "gpio_out"), > + SUNXI_FUNCTION(0x2, "sim"), /* DET */ > + SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 10)), /* PA_EINT10 */ > + SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 11), > + SUNXI_FUNCTION(0x0, "gpio_in"), > + SUNXI_FUNCTION(0x1, "gpio_out"), > + SUNXI_FUNCTION(0x2, "i2c0"), /* SCK */ > + SUNXI_FUNCTION(0x3, "di"), /* TX */ > + SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 11)), /* PA_EINT11 */ > + SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 12), > + SUNXI_FUNCTION(0x0, "gpio_in"), > + SUNXI_FUNCTION(0x1, "gpio_out"), > + SUNXI_FUNCTION(0x2, "i2c0"), /* SDA */ > + SUNXI_FUNCTION(0x3, "di"), /* RX */ > + SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 12)), /* PA_EINT12 */ > + SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 13), > + SUNXI_FUNCTION(0x0, "gpio_in"), > + SUNXI_FUNCTION(0x1, "gpio_out"), > + SUNXI_FUNCTION(0x2, "spi1"), /* CS */ > + SUNXI_FUNCTION(0x3, "uart3"), /* TX */ > + SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 13)), /* PA_EINT13 */ > + SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 14), > + SUNXI_FUNCTION(0x0, "gpio_in"), > + SUNXI_FUNCTION(0x1, "gpio_out"), > + SUNXI_FUNCTION(0x2, "spi1"), /* CLK */ > + SUNXI_FUNCTION(0x3, "uart3"), /* RX */ > + SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 14)), /* PA_EINT14 */ > + SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 15), > + SUNXI_FUNCTION(0x0, "gpio_in"), > + SUNXI_FUNCTION(0x1, "gpio_out"), > + SUNXI_FUNCTION(0x2, "spi1"), /* MOSI */ > + SUNXI_FUNCTION(0x3, "uart3"), /* RTS */ > + SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 15)), /* PA_EINT15 */ > + SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 16), > + SUNXI_FUNCTION(0x0, "gpio_in"), > + SUNXI_FUNCTION(0x1, "gpio_out"), > + SUNXI_FUNCTION(0x2, "spi1"), /* MISO */ > + SUNXI_FUNCTION(0x3, "uart3"), /* CTS */ > + SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 16)), /* PA_EINT16 */ > + SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 17), > + SUNXI_FUNCTION(0x0, "gpio_in"), > + SUNXI_FUNCTION(0x1, "gpio_out"), > + SUNXI_FUNCTION(0x2, "spdif"), /* OUT */ > + SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 17)), /* PA_EINT17 */ > + SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 18), > + SUNXI_FUNCTION(0x0, "gpio_in"), > + SUNXI_FUNCTION(0x1, "gpio_out"), > + SUNXI_FUNCTION(0x2, "i2s0"), /* SYNC */ > + SUNXI_FUNCTION(0x3, "i2c1"), /* SCK */ > + SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 18)), /* PA_EINT18 */ > + SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 19), > + SUNXI_FUNCTION(0x0, "gpio_in"), > + SUNXI_FUNCTION(0x1, "gpio_out"), > + SUNXI_FUNCTION(0x2, "i2s0"), /* CLK */ > + SUNXI_FUNCTION(0x3, "i2c1"), /* SDA */ > + SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 19)), /* PA_EINT19 */ > + SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 20), > + SUNXI_FUNCTION(0x0, "gpio_in"), > + SUNXI_FUNCTION(0x1, "gpio_out"), > + SUNXI_FUNCTION(0x2, "i2s0"), /* DOUT */ > + SUNXI_FUNCTION(0x3, "sim"), /* VPPEN */ > + SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 20)), /* PA_EINT20 */ > + SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 21), > + SUNXI_FUNCTION(0x0, "gpio_in"), > + SUNXI_FUNCTION(0x1, "gpio_out"), > + SUNXI_FUNCTION(0x2, "i2s0"), /* DIN */ > + SUNXI_FUNCTION(0x3, "sim"), /* VPPPP */ > + SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 21)), /* PA_EINT21 */ > + /* 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_FUNCTION(0x4, "mmc2")), /* DS */ > + 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_FUNCTION(0x4, "spi0"), /* MISO */ > + 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, "nand0"), /* 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, "nand0"), /* 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, "nand0"), /* DQS */ > + 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, "emac"), /* RXD3 */ > + SUNXI_FUNCTION(0x3, "di"), /* TX */ > + SUNXI_FUNCTION(0x4, "ts2")), /* CLK */ > + SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 1), > + SUNXI_FUNCTION(0x0, "gpio_in"), > + SUNXI_FUNCTION(0x1, "gpio_out"), > + SUNXI_FUNCTION(0x2, "emac"), /* RXD2 */ > + SUNXI_FUNCTION(0x3, "di"), /* RX */ > + SUNXI_FUNCTION(0x4, "ts2")), /* ERR */ > + SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 2), > + SUNXI_FUNCTION(0x0, "gpio_in"), > + SUNXI_FUNCTION(0x1, "gpio_out"), > + SUNXI_FUNCTION(0x2, "emac"), /* RXD1 */ > + SUNXI_FUNCTION(0x4, "ts2")), /* SYNC */ > + SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 3), > + SUNXI_FUNCTION(0x0, "gpio_in"), > + SUNXI_FUNCTION(0x1, "gpio_out"), > + SUNXI_FUNCTION(0x2, "emac"), /* RXD0 */ > + SUNXI_FUNCTION(0x4, "ts2")), /* DVLD */ > + SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 4), > + SUNXI_FUNCTION(0x0, "gpio_in"), > + SUNXI_FUNCTION(0x1, "gpio_out"), > + SUNXI_FUNCTION(0x2, "emac"), /* RXCK */ > + SUNXI_FUNCTION(0x4, "ts2")), /* D0 */ > + SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 5), > + SUNXI_FUNCTION(0x0, "gpio_in"), > + SUNXI_FUNCTION(0x1, "gpio_out"), > + SUNXI_FUNCTION(0x2, "emac"), /* RXCTL/RXDV */ > + SUNXI_FUNCTION(0x4, "ts2")), /* D1 */ > + SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 6), > + SUNXI_FUNCTION(0x0, "gpio_in"), > + SUNXI_FUNCTION(0x1, "gpio_out"), > + SUNXI_FUNCTION(0x2, "emac"), /* RXERR */ > + SUNXI_FUNCTION(0x4, "ts2")), /* D2 */ > + SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 7), > + SUNXI_FUNCTION(0x0, "gpio_in"), > + SUNXI_FUNCTION(0x1, "gpio_out"), > + SUNXI_FUNCTION(0x2, "emac"), /* TXD3 */ > + SUNXI_FUNCTION(0x4, "ts2"), /* D3 */ > + SUNXI_FUNCTION(0x5, "ts3")), /* CLK */ > + SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 8), > + SUNXI_FUNCTION(0x0, "gpio_in"), > + SUNXI_FUNCTION(0x1, "gpio_out"), > + SUNXI_FUNCTION(0x2, "emac"), /* TXD2 */ > + SUNXI_FUNCTION(0x4, "ts2"), /* D4 */ > + SUNXI_FUNCTION(0x5, "ts3")), /* ERR */ > + SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 9), > + SUNXI_FUNCTION(0x0, "gpio_in"), > + SUNXI_FUNCTION(0x1, "gpio_out"), > + SUNXI_FUNCTION(0x2, "emac"), /* TXD1 */ > + SUNXI_FUNCTION(0x4, "ts2"), /* D5 */ > + SUNXI_FUNCTION(0x5, "ts3")), /* SYNC */ > + SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 10), > + SUNXI_FUNCTION(0x0, "gpio_in"), > + SUNXI_FUNCTION(0x1, "gpio_out"), > + SUNXI_FUNCTION(0x2, "emac"), /* TXD0 */ > + SUNXI_FUNCTION(0x4, "ts2"), /* D6 */ > + SUNXI_FUNCTION(0x5, "ts3")), /* DVLD */ > + SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 11), > + SUNXI_FUNCTION(0x0, "gpio_in"), > + SUNXI_FUNCTION(0x1, "gpio_out"), > + SUNXI_FUNCTION(0x2, "emac"), /* CRS */ > + SUNXI_FUNCTION(0x4, "ts2"), /* D7 */ > + SUNXI_FUNCTION(0x5, "ts3")), /* D0 */ > + SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 12), > + SUNXI_FUNCTION(0x0, "gpio_in"), > + SUNXI_FUNCTION(0x1, "gpio_out"), > + SUNXI_FUNCTION(0x2, "emac"), /* TXCK */ > + SUNXI_FUNCTION(0x4, "sim")), /* PWREN */ > + SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 13), > + SUNXI_FUNCTION(0x0, "gpio_in"), > + SUNXI_FUNCTION(0x1, "gpio_out"), > + SUNXI_FUNCTION(0x2, "emac"), /* TXCTL/TXEN */ > + SUNXI_FUNCTION(0x4, "sim")), /* CLK */ > + SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 14), > + SUNXI_FUNCTION(0x0, "gpio_in"), > + SUNXI_FUNCTION(0x1, "gpio_out"), > + SUNXI_FUNCTION(0x2, "emac"), /* TXERR */ > + SUNXI_FUNCTION(0x4, "sim")), /* DATA */ > + SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 15), > + SUNXI_FUNCTION(0x0, "gpio_in"), > + SUNXI_FUNCTION(0x1, "gpio_out"), > + SUNXI_FUNCTION(0x2, "emac"), /* CLKIN/COL */ > + SUNXI_FUNCTION(0x4, "sim")), /* RST */ > + SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 16), > + SUNXI_FUNCTION(0x0, "gpio_in"), > + SUNXI_FUNCTION(0x1, "gpio_out"), > + SUNXI_FUNCTION(0x2, "emac"), /* MDC */ > + SUNXI_FUNCTION(0x4, "sim")), /* DET */ > + SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 17), > + SUNXI_FUNCTION(0x0, "gpio_in"), > + SUNXI_FUNCTION(0x1, "gpio_out"), > + SUNXI_FUNCTION(0x2, "emac")), /* MDIO */ > + /* Hole */ > + SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 0), > + SUNXI_FUNCTION(0x0, "gpio_in"), > + SUNXI_FUNCTION(0x1, "gpio_out"), > + SUNXI_FUNCTION(0x2, "csi"), /* PCLK */ > + SUNXI_FUNCTION(0x3, "ts0")), /* CLK */ > + SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 1), > + SUNXI_FUNCTION(0x0, "gpio_in"), > + SUNXI_FUNCTION(0x1, "gpio_out"), > + SUNXI_FUNCTION(0x2, "csi"), /* MCLK */ > + SUNXI_FUNCTION(0x3, "ts0")), /* ERR */ > + SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 2), > + SUNXI_FUNCTION(0x0, "gpio_in"), > + SUNXI_FUNCTION(0x1, "gpio_out"), > + SUNXI_FUNCTION(0x2, "csi"), /* HSYNC */ > + SUNXI_FUNCTION(0x3, "ts0")), /* SYNC */ > + SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 3), > + SUNXI_FUNCTION(0x0, "gpio_in"), > + SUNXI_FUNCTION(0x1, "gpio_out"), > + SUNXI_FUNCTION(0x2, "csi"), /* VSYNC */ > + SUNXI_FUNCTION(0x3, "ts0")), /* DVLD */ > + SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 4), > + SUNXI_FUNCTION(0x0, "gpio_in"), > + SUNXI_FUNCTION(0x1, "gpio_out"), > + SUNXI_FUNCTION(0x2, "csi"), /* D0 */ > + SUNXI_FUNCTION(0x3, "ts0")), /* D0 */ > + SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 5), > + SUNXI_FUNCTION(0x0, "gpio_in"), > + SUNXI_FUNCTION(0x1, "gpio_out"), > + SUNXI_FUNCTION(0x2, "csi"), /* D1 */ > + SUNXI_FUNCTION(0x3, "ts0")), /* D1 */ > + SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 6), > + SUNXI_FUNCTION(0x0, "gpio_in"), > + SUNXI_FUNCTION(0x1, "gpio_out"), > + SUNXI_FUNCTION(0x2, "csi"), /* D2 */ > + SUNXI_FUNCTION(0x3, "ts0")), /* D2 */ > + SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 7), > + SUNXI_FUNCTION(0x0, "gpio_in"), > + SUNXI_FUNCTION(0x1, "gpio_out"), > + SUNXI_FUNCTION(0x2, "csi"), /* D3 */ > + SUNXI_FUNCTION(0x3, "ts0"), /* D3 */ > + SUNXI_FUNCTION(0x4, "ts1")), /* CLK */ > + SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 8), > + SUNXI_FUNCTION(0x0, "gpio_in"), > + SUNXI_FUNCTION(0x1, "gpio_out"), > + SUNXI_FUNCTION(0x2, "csi"), /* D4 */ > + SUNXI_FUNCTION(0x3, "ts0"), /* D4 */ > + SUNXI_FUNCTION(0x4, "ts1")), /* ERR */ > + SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 9), > + SUNXI_FUNCTION(0x0, "gpio_in"), > + SUNXI_FUNCTION(0x1, "gpio_out"), > + SUNXI_FUNCTION(0x2, "csi"), /* D5 */ > + SUNXI_FUNCTION(0x3, "ts0"), /* D5 */ > + SUNXI_FUNCTION(0x4, "ts1"), /* SYNC */ > + SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 10), > + SUNXI_FUNCTION(0x0, "gpio_in"), > + SUNXI_FUNCTION(0x1, "gpio_out"), > + SUNXI_FUNCTION(0x2, "csi"), /* D6 */ > + SUNXI_FUNCTION(0x3, "ts0"), /* D6 */ > + SUNXI_FUNCTION(0x4, "ts1")), /* DVLD */ > + SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 11), > + SUNXI_FUNCTION(0x0, "gpio_in"), > + SUNXI_FUNCTION(0x1, "gpio_out"), > + SUNXI_FUNCTION(0x2, "csi"), /* D7 */ > + SUNXI_FUNCTION(0x3, "ts"), /* D7 */ > + SUNXI_FUNCTION(0x4, "ts1")), /* D0 */ > + 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_FUNCTION(0x3, "sim")), /* VPPEN */ > + SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 15), > + SUNXI_FUNCTION(0x0, "gpio_in"), > + SUNXI_FUNCTION(0x1, "gpio_out"), > + SUNXI_FUNCTION(0x3, "sim")), /* VPPPP */ > + /* 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")), /* MS */ > + 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")), /* DI */ > + 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")), /* DO */ > + 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")), /* CK */ > + 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)), /* 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(0x6, 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(0x6, 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(0x6, 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(0x6, 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(0x6, 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(0x6, 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(0x6, 1, 7)), /* PG_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)), /* PG_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)), /* 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(0x6, 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(0x6, 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(0x6, 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(0x6, 1, 13)), /* PG_EINT13 */ > +}; > + > +static const struct sunxi_pinctrl_desc sun50i_h5_pinctrl_data = { > + .pins = sun50i_h5_pins, > + .npins = ARRAY_SIZE(sun50i_h5_pins), > + .irq_banks = 2, > + .irq_read_needs_mux = true > +}; > + > +static int sun50i_h5_pinctrl_probe(struct platform_device *pdev) > +{ > + return sunxi_pinctrl_init(pdev, > + &sun50i_h5_pinctrl_data); > +} > + > +static const struct of_device_id sun50i_h5_pinctrl_match[] = { > + { .compatible = "allwinner,sun50i-h5-pinctrl", }, > + {} > +}; > + > +static struct platform_driver sun50i_h5_pinctrl_driver = { > + .probe = sun50i_h5_pinctrl_probe, > + .driver = { > + .name = "sun50i-h5-pinctrl", > + .of_match_table = sun50i_h5_pinctrl_match, > + }, > +}; > +builtin_platform_driver(sun50i_h5_pinctrl_driver); > ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [linux-sunxi] [PATCH 1/2] drivers: pinctrl: add driver for Allwinner H5 SoC 2016-12-26 14:33 ` [linux-sunxi] [PATCH 1/2] drivers: pinctrl: add driver for Allwinner H5 SoC André Przywara @ 2016-12-30 12:55 ` Linus Walleij 2016-12-30 19:42 ` Tony Lindgren 2017-01-05 22:42 ` Maxime Ripard 0 siblings, 2 replies; 11+ messages in thread From: Linus Walleij @ 2016-12-30 12:55 UTC (permalink / raw) To: André Przywara, ext Tony Lindgren Cc: Icenowy Zheng, Catalin Marinas, Maxime Ripard, Chen-Yu Tsai, linux-arm-kernel, linux-kernel, linux-gpio, linux-sunxi On Mon, Dec 26, 2016 at 3:33 PM, André Przywara <andre.przywara@arm.com> wrote: > So while this patch technically looks correct, I was wondering if we > should really explore the possibility of making the whole of sunxi > pinctrl DT controlled. > I brought this up a while ago, but people weren't overly enthusiastic > about it, though their argument weren't really convincing to me[1]. > > So: > As this "driver" here is basically a table linking GPIO bit settings > (the actual mux value) to names and every pin we care about needs to be > enumerated in the DT anyway, why not just add something like: > allwinner,pinmux = <4>; > to each pin(group) in the DT and get rid of this "driver" file here > entirely? I'm open to that if you can use pinctrl-single which is in the kernel for this purpose only, and is used with both OMAPs and HiSilicon. It recently was improved and will be improved more in this cycle, see for example: commit 42124bc598f64f84b3335d5a058304207695b84f pinctrl: Introduce generic #pinctrl-cells and pinctrl_parse_index_with_args > (...) Also I guess the common sunxi > pinctrl driver code needs some significant rework. I would guess is just needs replacing with pinctrl-single in that case. Yours, Linus Walleij ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [linux-sunxi] [PATCH 1/2] drivers: pinctrl: add driver for Allwinner H5 SoC 2016-12-30 12:55 ` Linus Walleij @ 2016-12-30 19:42 ` Tony Lindgren 2017-01-05 22:42 ` Maxime Ripard 1 sibling, 0 replies; 11+ messages in thread From: Tony Lindgren @ 2016-12-30 19:42 UTC (permalink / raw) To: Linus Walleij Cc: André Przywara, Icenowy Zheng, Catalin Marinas, Maxime Ripard, Chen-Yu Tsai, linux-arm-kernel, linux-kernel, linux-gpio, linux-sunxi * Linus Walleij <linus.walleij@linaro.org> [161230 04:56]: > On Mon, Dec 26, 2016 at 3:33 PM, André Przywara <andre.przywara@arm.com> wrote: > > > So while this patch technically looks correct, I was wondering if we > > should really explore the possibility of making the whole of sunxi > > pinctrl DT controlled. > > I brought this up a while ago, but people weren't overly enthusiastic > > about it, though their argument weren't really convincing to me[1]. > > > > So: > > As this "driver" here is basically a table linking GPIO bit settings > > (the actual mux value) to names and every pin we care about needs to be > > enumerated in the DT anyway, why not just add something like: > > allwinner,pinmux = <4>; > > to each pin(group) in the DT and get rid of this "driver" file here > > entirely? > > I'm open to that if you can use pinctrl-single which is in the kernel > for this purpose only, and is used with both OMAPs and HiSilicon. > > It recently was improved and will be improved more in this cycle, > see for example: > commit 42124bc598f64f84b3335d5a058304207695b84f > pinctrl: Introduce generic #pinctrl-cells and pinctrl_parse_index_with_args > > > (...) Also I guess the common sunxi > > pinctrl driver code needs some significant rework. > > I would guess is just needs replacing with pinctrl-single in that case. And if pinctrl-single won't work then it is now also be easier to make hardware specific drivers too using #pinctrl-cells + GENERIC_PINCTRL_GROUPS + GENERIC_PINMUX_FUNCTIONS. Regards, Tony ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [linux-sunxi] [PATCH 1/2] drivers: pinctrl: add driver for Allwinner H5 SoC 2016-12-30 12:55 ` Linus Walleij 2016-12-30 19:42 ` Tony Lindgren @ 2017-01-05 22:42 ` Maxime Ripard 2017-01-09 0:16 ` André Przywara 1 sibling, 1 reply; 11+ messages in thread From: Maxime Ripard @ 2017-01-05 22:42 UTC (permalink / raw) To: Linus Walleij Cc: André Przywara, ext Tony Lindgren, Icenowy Zheng, Catalin Marinas, Chen-Yu Tsai, linux-arm-kernel, linux-kernel, linux-gpio, linux-sunxi [-- Attachment #1: Type: text/plain, Size: 1265 bytes --] On Fri, Dec 30, 2016 at 01:55:44PM +0100, Linus Walleij wrote: > On Mon, Dec 26, 2016 at 3:33 PM, André Przywara <andre.przywara@arm.com> wrote: > > > So while this patch technically looks correct, I was wondering if we > > should really explore the possibility of making the whole of sunxi > > pinctrl DT controlled. > > I brought this up a while ago, but people weren't overly enthusiastic > > about it, though their argument weren't really convincing to me[1]. > > > > So: > > As this "driver" here is basically a table linking GPIO bit settings > > (the actual mux value) to names and every pin we care about needs to be > > enumerated in the DT anyway, why not just add something like: > > allwinner,pinmux = <4>; > > to each pin(group) in the DT and get rid of this "driver" file here > > entirely? > > I'm open to that if you can use pinctrl-single which is in the kernel > for this purpose only, and is used with both OMAPs and HiSilicon. I'm not open to that, and I'm getting tired of discussing it over and over again. Andre, if you want to be convinced again, please read the last discussion we had on this topic. Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 801 bytes --] ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [linux-sunxi] [PATCH 1/2] drivers: pinctrl: add driver for Allwinner H5 SoC 2017-01-05 22:42 ` Maxime Ripard @ 2017-01-09 0:16 ` André Przywara 2017-01-16 16:31 ` Maxime Ripard 0 siblings, 1 reply; 11+ messages in thread From: André Przywara @ 2017-01-09 0:16 UTC (permalink / raw) To: Maxime Ripard, Linus Walleij Cc: ext Tony Lindgren, Icenowy Zheng, Catalin Marinas, Chen-Yu Tsai, linux-arm-kernel, linux-kernel, linux-gpio, linux-sunxi On 05/01/17 22:42, Maxime Ripard wrote: > On Fri, Dec 30, 2016 at 01:55:44PM +0100, Linus Walleij wrote: >> On Mon, Dec 26, 2016 at 3:33 PM, André Przywara <andre.przywara@arm.com> wrote: >> >>> So while this patch technically looks correct, I was wondering if we >>> should really explore the possibility of making the whole of sunxi >>> pinctrl DT controlled. >>> I brought this up a while ago, but people weren't overly enthusiastic >>> about it, though their argument weren't really convincing to me[1]. >>> >>> So: >>> As this "driver" here is basically a table linking GPIO bit settings >>> (the actual mux value) to names and every pin we care about needs to be >>> enumerated in the DT anyway, why not just add something like: >>> allwinner,pinmux = <4>; >>> to each pin(group) in the DT and get rid of this "driver" file here >>> entirely? >> >> I'm open to that if you can use pinctrl-single which is in the kernel >> for this purpose only, and is used with both OMAPs and HiSilicon. > > I'm not open to that, and I'm getting tired of discussing it over and > over again. Andre, if you want to be convinced again, please read the > last discussion we had on this topic. As I said: It didn't convince me back then. And frankly we didn't really discuss it back then, I just refrained from entering a discussion against _two_ maintainers at this time, since my capacity on this kind of email threads is really very limited - especially for something that is a hobby to me. It isn't the highest priority on my list, but I am still planning on sketching something, so that we can discuss about actual code. As it seems like your new patches bring some relief to the immediate copy&paste pain (though the actual DT aspect still remains), I will shut up - for now ;-) Cheers, Andre. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [linux-sunxi] [PATCH 1/2] drivers: pinctrl: add driver for Allwinner H5 SoC 2017-01-09 0:16 ` André Przywara @ 2017-01-16 16:31 ` Maxime Ripard 2017-01-18 9:44 ` Andre Przywara 0 siblings, 1 reply; 11+ messages in thread From: Maxime Ripard @ 2017-01-16 16:31 UTC (permalink / raw) To: André Przywara Cc: Linus Walleij, ext Tony Lindgren, Icenowy Zheng, Catalin Marinas, Chen-Yu Tsai, linux-arm-kernel, linux-kernel, linux-gpio, linux-sunxi [-- Attachment #1: Type: text/plain, Size: 3034 bytes --] On Mon, Jan 09, 2017 at 12:16:00AM +0000, André Przywara wrote: > On 05/01/17 22:42, Maxime Ripard wrote: > > On Fri, Dec 30, 2016 at 01:55:44PM +0100, Linus Walleij wrote: > >> On Mon, Dec 26, 2016 at 3:33 PM, André Przywara <andre.przywara@arm.com> wrote: > >> > >>> So while this patch technically looks correct, I was wondering if we > >>> should really explore the possibility of making the whole of sunxi > >>> pinctrl DT controlled. > >>> I brought this up a while ago, but people weren't overly enthusiastic > >>> about it, though their argument weren't really convincing to me[1]. > >>> > >>> So: > >>> As this "driver" here is basically a table linking GPIO bit settings > >>> (the actual mux value) to names and every pin we care about needs to be > >>> enumerated in the DT anyway, why not just add something like: > >>> allwinner,pinmux = <4>; > >>> to each pin(group) in the DT and get rid of this "driver" file here > >>> entirely? > >> > >> I'm open to that if you can use pinctrl-single which is in the kernel > >> for this purpose only, and is used with both OMAPs and HiSilicon. > > > > I'm not open to that, and I'm getting tired of discussing it over and > > over again. Andre, if you want to be convinced again, please read the > > last discussion we had on this topic. > > As I said: It didn't convince me back then. And frankly we didn't really > discuss it back then, I just refrained from entering a discussion > against _two_ maintainers at this time, since my capacity on this kind > of email threads is really very limited - especially for something that > is a hobby to me. This is also (mostly) a hobby to me, which is exactly why I prefer to work on something actually useful, rather than just discussing this over and over again. Just like I don't want (myself, or anyone, really, since we're all in the same boat) to have to maintain two separate pinctrl drivers. We're having a documented, simple, pinctrl binding, using the generic bindings now (that almost everyone else is using now, or is very close to), and we can leverage as much documentation and code from that. Why would we want to create and maintain a new driver with a new binding, that will need to be documented again, learned by everyone, and will lead only to confusion across the people who just want to have their board supported? And imagine the kind of mess we would be in if everyone getting a bit involved in the support of one platform at one point wanted to trash one big part of its infrastructure and start all over again because he likes it better this way. I'm sorry, but this is also our jobs as maintainers to prevent all these kind of issues, and to maintain consistency. Switching to one binding to another breaks that consistency on many level, both in pinctrl and in the platform support itself. So sorry, but that's not going to happen. Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 801 bytes --] ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [linux-sunxi] [PATCH 1/2] drivers: pinctrl: add driver for Allwinner H5 SoC 2017-01-16 16:31 ` Maxime Ripard @ 2017-01-18 9:44 ` Andre Przywara 2017-01-19 9:23 ` Linus Walleij 2017-01-19 17:41 ` Maxime Ripard 0 siblings, 2 replies; 11+ messages in thread From: Andre Przywara @ 2017-01-18 9:44 UTC (permalink / raw) To: Maxime Ripard Cc: Linus Walleij, ext Tony Lindgren, Icenowy Zheng, Catalin Marinas, Chen-Yu Tsai, linux-arm-kernel, linux-kernel, linux-gpio, linux-sunxi Hi, On 16/01/17 16:31, Maxime Ripard wrote: > On Mon, Jan 09, 2017 at 12:16:00AM +0000, André Przywara wrote: >> On 05/01/17 22:42, Maxime Ripard wrote: >>> On Fri, Dec 30, 2016 at 01:55:44PM +0100, Linus Walleij wrote: >>>> On Mon, Dec 26, 2016 at 3:33 PM, André Przywara <andre.przywara@arm.com> wrote: >>>> >>>>> So while this patch technically looks correct, I was wondering if we >>>>> should really explore the possibility of making the whole of sunxi >>>>> pinctrl DT controlled. >>>>> I brought this up a while ago, but people weren't overly enthusiastic >>>>> about it, though their argument weren't really convincing to me[1]. >>>>> >>>>> So: >>>>> As this "driver" here is basically a table linking GPIO bit settings >>>>> (the actual mux value) to names and every pin we care about needs to be >>>>> enumerated in the DT anyway, why not just add something like: >>>>> allwinner,pinmux = <4>; >>>>> to each pin(group) in the DT and get rid of this "driver" file here >>>>> entirely? >>>> >>>> I'm open to that if you can use pinctrl-single which is in the kernel >>>> for this purpose only, and is used with both OMAPs and HiSilicon. >>> >>> I'm not open to that, and I'm getting tired of discussing it over and >>> over again. Andre, if you want to be convinced again, please read the >>> last discussion we had on this topic. >> >> As I said: It didn't convince me back then. And frankly we didn't really >> discuss it back then, I just refrained from entering a discussion >> against _two_ maintainers at this time, since my capacity on this kind >> of email threads is really very limited - especially for something that >> is a hobby to me. > > This is also (mostly) a hobby to me, which is exactly why I prefer to > work on something actually useful, rather than just discussing this > over and over again. Just like I don't want (myself, or anyone, > really, since we're all in the same boat) to have to maintain two > separate pinctrl drivers. > > We're having a documented, simple, pinctrl binding, using the generic > bindings now (that almost everyone else is using now, or is very close > to), and we can leverage as much documentation and code from that. Why > would we want to create and maintain a new driver with a new binding, > that will need to be documented again, learned by everyone, and will > lead only to confusion across the people who just want to have their > board supported? I agree, and thus was proposing a _slightly changed_ pinctrl driver which actually *reduces* the maintenance burden in the kernel. In the moment we need to add _both_ a pinctrl .dtsi node _and_ a kernel "driver" file, which is really boilerplate code plus a table. Also we need to make sure that both these files match. If a new SoC is really 99% similar to an existing one, atm we still need explicit kernel support if only one pin is changed (see the H5). So my idea was to basically add the mux value as a DT property, thus making the kernel pinctrl-sun[x]i-a[yz].c files obsolete and greatly _reduce_ the maintenance burden. Ideally there wouldn't be any pinctrl code changes in the kernel for future SoCs anymore - at least if Allwinner sticks with their current pace of releasing copy&pasted SoC designs. Changes beyond that would require a driver change anyway, even with the current model. I gave Linus' proposal to use the pinctrl-single binding a quick look and don't think it's a match for Allwinner SoC. So my idea was to basically just add a new compatible and the muxsel property to the existing driver and binding. It would basically look the same, apart from one or two additions (to cover interrupts, for instance). Any future SoCs could then just use that compatible and would describe the SoC details in the DT, like it's meant to be and like we do already, but extended by putting the mux value in there as well. So the only kernel contribution would then be the DT, really, which technically could be delivered on some device storage as well, but that's a different discussion ... > And imagine the kind of mess we would be in if everyone getting a bit > involved in the support of one platform at one point wanted to trash > one big part of its infrastructure and start all over again because he > likes it better this way. Like I said above, I didn't mean to trash the current pinctrl binding, just make it a bit more generic and simplify future kernel support. > I'm sorry, but this is also our jobs as maintainers to prevent all > these kind of issues, and to maintain consistency. Switching to one > binding to another breaks that consistency on many level, Yet we did it for the clocks. The very same argumentation that you gave above applies there as well (two different bindings, two sets of drivers in the kernel, new learnings for people, etc.) One difference would be that the new pinctrl binding wouldn't be fundamentally different to the old one, up to the point where the old driver could possibly use the very same DT nodes (but that would need to be worked out). Cheers, Andre. > both in > pinctrl and in the platform support itself. So sorry, but that's not > going to happen. > > Maxime > ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [linux-sunxi] [PATCH 1/2] drivers: pinctrl: add driver for Allwinner H5 SoC 2017-01-18 9:44 ` Andre Przywara @ 2017-01-19 9:23 ` Linus Walleij [not found] ` <128701484831509@web34m.yandex.ru> 2017-01-19 17:41 ` Maxime Ripard 1 sibling, 1 reply; 11+ messages in thread From: Linus Walleij @ 2017-01-19 9:23 UTC (permalink / raw) To: Andre Przywara Cc: Maxime Ripard, ext Tony Lindgren, Icenowy Zheng, Catalin Marinas, Chen-Yu Tsai, linux-arm-kernel, linux-kernel, linux-gpio, linux-sunxi On Wed, Jan 18, 2017 at 10:44 AM, Andre Przywara <andre.przywara@arm.com> wrote: > Any future SoCs could then just use that compatible and would describe > the SoC details in the DT, like it's meant to be and like we do already, > but extended by putting the mux value in there as well. > So the only kernel contribution would then be the DT, really, (...) Your different positions have existed since the inception of the pinctrl subsystem: - One camp (myself included) wanted to describe the hardware mostly in the driver: functions, groups etc are tables in the driver file. - Another camp (OMAP included) think that the device tree should take store most things: groups functions, etc. What we know for sure should be described in DT is how different IP blocks are connected in an SoC (e.g. interrupts, clocks, DMA channels, regulators) and on the of course outside of the SoC, on the board. The question here is whether the way a hardware has instantiated a certain IP block when doing physical compilation in their Verilog, VHDL or SystemC files, is something that should be described in DT. Many companies have developed tools to extract this data from their hardware design files and provide it to developers as a blob och incomprehensible data, such was the situation for OMAP for example. So to them it made most sense to implement pinctrl-single, just parsing that data into DTS(I) files. Other companies (such as STMicroelectronics) instead put a team of people to write a datasheet with a special chapter on how pins etc are connected, and programmers are given this datasheet and need to again type in the data and define groups etc. Whether parametrization of a HW block should be done in the driver file from the compatible string or with custom attributes in the node is not a simple answer to the question. OF is vague on this kind of things: both solutions exist. Allwinner and Qualcomm authors faced a situation such as that they were given a code dump and no datasheet and no data tables either. That creates an especially complicated situation where none of the above scenarios apply. What we/you need to ask: what is most helpful for the Allwinner community? What makes the barrier low for new contributions, and makes it easiest to cooperate? I try to live by this motto from IETF: "rough consensus and running code" Please do the same. Yours, Linus Walleij ^ permalink raw reply [flat|nested] 11+ messages in thread
[parent not found: <128701484831509@web34m.yandex.ru>]
* Re: [linux-sunxi] [PATCH 1/2] drivers: pinctrl: add driver for Allwinner H5 SoC [not found] ` <128701484831509@web34m.yandex.ru> @ 2017-01-19 17:29 ` Maxime Ripard 0 siblings, 0 replies; 11+ messages in thread From: Maxime Ripard @ 2017-01-19 17:29 UTC (permalink / raw) To: Icenowy Zheng Cc: Linus Walleij, Andre Przywara, ext Tony Lindgren, Catalin Marinas, Chen-Yu Tsai, linux-arm-kernel, linux-kernel, linux-gpio, linux-sunxi [-- Attachment #1: Type: text/plain, Size: 2819 bytes --] On Thu, Jan 19, 2017 at 09:11:49PM +0800, Icenowy Zheng wrote: > 19.01.2017, 17:23, "Linus Walleij" <linus.walleij@linaro.org>: > > On Wed, Jan 18, 2017 at 10:44 AM, Andre Przywara <andre.przywara@arm.com> wrote: > > > >> Any future SoCs could then just use that compatible and would describe > >> the SoC details in the DT, like it's meant to be and like we do already, > >> but extended by putting the mux value in there as well. > >> So the only kernel contribution would then be the DT, really, (...) > > > > Your different positions have existed since the inception of the > > pinctrl subsystem: > > > > - One camp (myself included) wanted to describe the hardware mostly > > in the driver: functions, groups etc are tables in the driver file. > > > > - Another camp (OMAP included) think that the device tree should take > > store most things: groups functions, etc. > > > > What we know for sure should be described in DT is how different > > IP blocks are connected in an SoC (e.g. interrupts, clocks, DMA > > channels, regulators) and on the of course outside of the SoC, on > > the board. > > > > The question here is whether the way a hardware has instantiated > > a certain IP block when doing physical compilation in their > > Verilog, VHDL or SystemC files, is something that should be > > described in DT. > > > > Many companies have developed tools to > > extract this data from their hardware design files and provide > > it to developers as a blob och incomprehensible data, such was > > the situation for OMAP for example. So to them it made most > > sense to implement pinctrl-single, just parsing that data into > > DTS(I) files. > > > > Other companies (such as STMicroelectronics) instead put a > > team of people to write a datasheet with a special chapter > > on how pins etc are connected, and programmers are given > > this datasheet and need to again type in the data and define > > groups etc. > > > > Whether parametrization of a HW block should be done in the > > driver file from the compatible string or with custom attributes > > in the node is not a simple answer to the question. OF is vague > > on this kind of things: both solutions exist. > > > > Allwinner and Qualcomm authors faced a situation such as that > > they were given a code dump and no datasheet and no data > > tables either. That creates an especially complicated situation > > where none of the above scenarios apply. > > Allwinner do give user manual about the pin controller, and they're > used when we write the pinctrl-sunxi driver. That has not always been true for all the SoCs, and it's still not the case, even for newer SoCs. Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 801 bytes --] ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [linux-sunxi] [PATCH 1/2] drivers: pinctrl: add driver for Allwinner H5 SoC 2017-01-18 9:44 ` Andre Przywara 2017-01-19 9:23 ` Linus Walleij @ 2017-01-19 17:41 ` Maxime Ripard 2017-01-26 10:03 ` Linus Walleij 1 sibling, 1 reply; 11+ messages in thread From: Maxime Ripard @ 2017-01-19 17:41 UTC (permalink / raw) To: Andre Przywara Cc: Linus Walleij, ext Tony Lindgren, Icenowy Zheng, Catalin Marinas, Chen-Yu Tsai, linux-arm-kernel, linux-kernel, linux-gpio, linux-sunxi [-- Attachment #1: Type: text/plain, Size: 5061 bytes --] On Wed, Jan 18, 2017 at 09:44:37AM +0000, Andre Przywara wrote: > Hi, > > On 16/01/17 16:31, Maxime Ripard wrote: > > On Mon, Jan 09, 2017 at 12:16:00AM +0000, André Przywara wrote: > >> On 05/01/17 22:42, Maxime Ripard wrote: > >>> On Fri, Dec 30, 2016 at 01:55:44PM +0100, Linus Walleij wrote: > >>>> On Mon, Dec 26, 2016 at 3:33 PM, André Przywara <andre.przywara@arm.com> wrote: > >>>> > >>>>> So while this patch technically looks correct, I was wondering if we > >>>>> should really explore the possibility of making the whole of sunxi > >>>>> pinctrl DT controlled. > >>>>> I brought this up a while ago, but people weren't overly enthusiastic > >>>>> about it, though their argument weren't really convincing to me[1]. > >>>>> > >>>>> So: > >>>>> As this "driver" here is basically a table linking GPIO bit settings > >>>>> (the actual mux value) to names and every pin we care about needs to be > >>>>> enumerated in the DT anyway, why not just add something like: > >>>>> allwinner,pinmux = <4>; > >>>>> to each pin(group) in the DT and get rid of this "driver" file here > >>>>> entirely? > >>>> > >>>> I'm open to that if you can use pinctrl-single which is in the kernel > >>>> for this purpose only, and is used with both OMAPs and HiSilicon. > >>> > >>> I'm not open to that, and I'm getting tired of discussing it over and > >>> over again. Andre, if you want to be convinced again, please read the > >>> last discussion we had on this topic. > >> > >> As I said: It didn't convince me back then. And frankly we didn't really > >> discuss it back then, I just refrained from entering a discussion > >> against _two_ maintainers at this time, since my capacity on this kind > >> of email threads is really very limited - especially for something that > >> is a hobby to me. > > > > This is also (mostly) a hobby to me, which is exactly why I prefer to > > work on something actually useful, rather than just discussing this > > over and over again. Just like I don't want (myself, or anyone, > > really, since we're all in the same boat) to have to maintain two > > separate pinctrl drivers. > > > > We're having a documented, simple, pinctrl binding, using the generic > > bindings now (that almost everyone else is using now, or is very close > > to), and we can leverage as much documentation and code from that. Why > > would we want to create and maintain a new driver with a new binding, > > that will need to be documented again, learned by everyone, and will > > lead only to confusion across the people who just want to have their > > board supported? > > I agree, and thus was proposing a _slightly changed_ pinctrl driver > which actually *reduces* the maintenance burden in the kernel. > In the moment we need to add _both_ a pinctrl .dtsi node _and_ a kernel > "driver" file, which is really boilerplate code plus a table. > Also we need to make sure that both these files match. > If a new SoC is really 99% similar to an existing one, atm we still need > explicit kernel support if only one pin is changed (see the H5). That's not true anymore. And while it's true that it reduces the amount of maintainance on the kernel side and more on the DT side. And from what you're constantly saying, the thing we can't plan on fixing / upgrading is the DT, while the kernel is easy to change. Which means that if we ever want to fix a non-upgradable DT, the only way to do that would be to add quirks fixing it in the kernel itself. Adding more maintainance burden to the kernel. But really, this is not up for debate. You're 4 years too late for that for the original binding, and almost 2 years for the generic binding. > > I'm sorry, but this is also our jobs as maintainers to prevent all > > these kind of issues, and to maintain consistency. Switching to one > > binding to another breaks that consistency on many level, > > Yet we did it for the clocks. The very same argumentation that you gave > above applies there as well (two different bindings, two sets of drivers > in the kernel, new learnings for people, etc.) No, this is very different. An end user just wanting to plug a dumb device on his i2c bus will never even see how clocks are described. This is not true for pinctrl. And all the other arguments for the clocks have been the same than the pinctrl driver: every driver is converging to the new binding we've been using, the table in the kernel is easier to fix, etc. > One difference would be that the new pinctrl binding wouldn't be > fundamentally different to the old one, up to the point where the old > driver could possibly use the very same DT nodes (but that would need to > be worked out). The story is different if you manage to keep the binding. Every platform (but TI's) is converging to the generic bindings. Not using them is not an option. Having a different implementation is. Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 801 bytes --] ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [linux-sunxi] [PATCH 1/2] drivers: pinctrl: add driver for Allwinner H5 SoC 2017-01-19 17:41 ` Maxime Ripard @ 2017-01-26 10:03 ` Linus Walleij 0 siblings, 0 replies; 11+ messages in thread From: Linus Walleij @ 2017-01-26 10:03 UTC (permalink / raw) To: Maxime Ripard Cc: Andre Przywara, ext Tony Lindgren, Icenowy Zheng, Catalin Marinas, Chen-Yu Tsai, linux-arm-kernel, linux-kernel, linux-gpio, linux-sunxi On Thu, Jan 19, 2017 at 6:41 PM, Maxime Ripard <maxime.ripard@free-electrons.com> wrote: > That's not true anymore. And while it's true that it reduces the > amount of maintainance on the kernel side and more on the DT side. And > from what you're constantly saying, the thing we can't plan on fixing > / upgrading is the DT, while the kernel is easy to change. > > Which means that if we ever want to fix a non-upgradable DT, the only > way to do that would be to add quirks fixing it in the kernel > itself. Adding more maintainance burden to the kernel. This is a good argument to not put groups and functions into the DT at all. If the following propositions hold: - Functions and group definitions will contain bugs - Those bugs will need to be fixed by changing the buggy definitions - It is hard to change the DTB, it is easy to change the zImage Then by logical deduction the definitions should be in the kernel to minimize maintenance burden. There is a pattern amongst firmware people that they think that they always get the group and function definitions right on first try. As long as there are humans involved in the process, this stance is provedly wrong, just use git log and you will see how much of such bugs we fix, even in drivers and DTSes produced by the vendors themselves. Yours, Linus Walleij ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2017-01-26 10:03 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <20161223125001.1176-1-icenowy@aosc.xyz>
2016-12-26 14:33 ` [linux-sunxi] [PATCH 1/2] drivers: pinctrl: add driver for Allwinner H5 SoC André Przywara
2016-12-30 12:55 ` Linus Walleij
2016-12-30 19:42 ` Tony Lindgren
2017-01-05 22:42 ` Maxime Ripard
2017-01-09 0:16 ` André Przywara
2017-01-16 16:31 ` Maxime Ripard
2017-01-18 9:44 ` Andre Przywara
2017-01-19 9:23 ` Linus Walleij
[not found] ` <128701484831509@web34m.yandex.ru>
2017-01-19 17:29 ` Maxime Ripard
2017-01-19 17:41 ` Maxime Ripard
2017-01-26 10:03 ` Linus Walleij
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).