* [PATCH v5 1/6] pinctrl: sunxi: v3s: introduce support for V3
From: Icenowy Zheng @ 2019-07-28 3:12 UTC (permalink / raw)
To: Rob Herring, Maxime Ripard, Chen-Yu Tsai, Linus Walleij
Cc: linux-arm-kernel, linux-kernel, linux-clk, linux-gpio,
linux-sunxi, Icenowy Zheng, Maxime Ripard
In-Reply-To: <20190728031227.49140-1-icenowy@aosc.io>
Introduce the GPIO pins that is only available on V3 (not on V3s) to the
V3s pinctrl driver.
Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
Acked-by: Maxime Ripard <maxime.ripard@bootlin.com>
---
No changes in v5.
Changes in v4:
- Removed bogus alignment change.
Changes in v3:
- Fixed code alignment.
- Fixed LVDS function number.
Changes in v2:
- Dropped the driver rename patch and apply the changes directly on V3s
driver.
drivers/pinctrl/sunxi/pinctrl-sun8i-v3s.c | 265 +++++++++++++++++++++-
drivers/pinctrl/sunxi/pinctrl-sunxi.h | 2 +
2 files changed, 262 insertions(+), 5 deletions(-)
diff --git a/drivers/pinctrl/sunxi/pinctrl-sun8i-v3s.c b/drivers/pinctrl/sunxi/pinctrl-sun8i-v3s.c
index 6704ce8e5e3d..ca85438e379a 100644
--- a/drivers/pinctrl/sunxi/pinctrl-sun8i-v3s.c
+++ b/drivers/pinctrl/sunxi/pinctrl-sun8i-v3s.c
@@ -1,5 +1,5 @@
/*
- * Allwinner V3s SoCs pinctrl driver.
+ * Allwinner V3/V3s SoCs pinctrl driver.
*
* Copyright (C) 2016 Icenowy Zheng <icenowy@aosc.xyz>
*
@@ -77,6 +77,30 @@ static const struct sunxi_desc_pin sun8i_v3s_pins[] = {
SUNXI_FUNCTION(0x2, "i2c1"), /* SCK */
SUNXI_FUNCTION(0x3, "uart0"), /* RX */
SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 9)), /* PB_EINT9 */
+ SUNXI_PIN_VARIANT(SUNXI_PINCTRL_PIN(B, 10),
+ PINCTRL_SUN8I_V3,
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out"),
+ SUNXI_FUNCTION(0x2, "jtag"), /* MS */
+ SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 10)), /* PB_EINT10 */
+ SUNXI_PIN_VARIANT(SUNXI_PINCTRL_PIN(B, 11),
+ PINCTRL_SUN8I_V3,
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out"),
+ SUNXI_FUNCTION(0x2, "jtag"), /* CK */
+ SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 11)), /* PB_EINT11 */
+ SUNXI_PIN_VARIANT(SUNXI_PINCTRL_PIN(B, 12),
+ PINCTRL_SUN8I_V3,
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out"),
+ SUNXI_FUNCTION(0x2, "jtag"), /* DO */
+ SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 12)), /* PB_EINT12 */
+ SUNXI_PIN_VARIANT(SUNXI_PINCTRL_PIN(B, 13),
+ PINCTRL_SUN8I_V3,
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out"),
+ SUNXI_FUNCTION(0x2, "jtag"), /* DI */
+ SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 13)), /* PB_EINT13 */
/* Hole */
SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 0),
SUNXI_FUNCTION(0x0, "gpio_in"),
@@ -98,6 +122,180 @@ static const struct sunxi_desc_pin sun8i_v3s_pins[] = {
SUNXI_FUNCTION(0x1, "gpio_out"),
SUNXI_FUNCTION(0x2, "mmc2"), /* D0 */
SUNXI_FUNCTION(0x3, "spi0")), /* MOSI */
+ SUNXI_PIN_VARIANT(SUNXI_PINCTRL_PIN(C, 4),
+ PINCTRL_SUN8I_V3,
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out"),
+ SUNXI_FUNCTION(0x2, "mmc2")), /* D1 */
+ SUNXI_PIN_VARIANT(SUNXI_PINCTRL_PIN(C, 5),
+ PINCTRL_SUN8I_V3,
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out"),
+ SUNXI_FUNCTION(0x2, "mmc2")), /* D2 */
+ SUNXI_PIN_VARIANT(SUNXI_PINCTRL_PIN(C, 6),
+ PINCTRL_SUN8I_V3,
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out"),
+ SUNXI_FUNCTION(0x2, "mmc2")), /* D3 */
+ SUNXI_PIN_VARIANT(SUNXI_PINCTRL_PIN(C, 7),
+ PINCTRL_SUN8I_V3,
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out"),
+ SUNXI_FUNCTION(0x2, "mmc2")), /* D4 */
+ SUNXI_PIN_VARIANT(SUNXI_PINCTRL_PIN(C, 8),
+ PINCTRL_SUN8I_V3,
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out"),
+ SUNXI_FUNCTION(0x2, "mmc2")), /* D5 */
+ SUNXI_PIN_VARIANT(SUNXI_PINCTRL_PIN(C, 9),
+ PINCTRL_SUN8I_V3,
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out"),
+ SUNXI_FUNCTION(0x2, "mmc2")), /* D6 */
+ SUNXI_PIN_VARIANT(SUNXI_PINCTRL_PIN(C, 10),
+ PINCTRL_SUN8I_V3,
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out"),
+ SUNXI_FUNCTION(0x2, "mmc2")), /* D7 */
+ /* Hole */
+ SUNXI_PIN_VARIANT(SUNXI_PINCTRL_PIN(D, 0),
+ PINCTRL_SUN8I_V3,
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out"),
+ SUNXI_FUNCTION(0x2, "lcd"), /* D2 */
+ SUNXI_FUNCTION(0x4, "emac")), /* RXD3 */
+ SUNXI_PIN_VARIANT(SUNXI_PINCTRL_PIN(D, 1),
+ PINCTRL_SUN8I_V3,
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out"),
+ SUNXI_FUNCTION(0x2, "lcd"), /* D3 */
+ SUNXI_FUNCTION(0x4, "emac")), /* RXD2 */
+ SUNXI_PIN_VARIANT(SUNXI_PINCTRL_PIN(D, 2),
+ PINCTRL_SUN8I_V3,
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out"),
+ SUNXI_FUNCTION(0x2, "lcd"), /* D4 */
+ SUNXI_FUNCTION(0x4, "emac")), /* RXD1 */
+ SUNXI_PIN_VARIANT(SUNXI_PINCTRL_PIN(D, 3),
+ PINCTRL_SUN8I_V3,
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out"),
+ SUNXI_FUNCTION(0x2, "lcd"), /* D5 */
+ SUNXI_FUNCTION(0x4, "emac")), /* RXD0 */
+ SUNXI_PIN_VARIANT(SUNXI_PINCTRL_PIN(D, 4),
+ PINCTRL_SUN8I_V3,
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out"),
+ SUNXI_FUNCTION(0x2, "lcd"), /* D6 */
+ SUNXI_FUNCTION(0x4, "emac")), /* RXCK */
+ SUNXI_PIN_VARIANT(SUNXI_PINCTRL_PIN(D, 5),
+ PINCTRL_SUN8I_V3,
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out"),
+ SUNXI_FUNCTION(0x2, "lcd"), /* D7 */
+ SUNXI_FUNCTION(0x4, "emac")), /* RXCTL/RXDV */
+ SUNXI_PIN_VARIANT(SUNXI_PINCTRL_PIN(D, 6),
+ PINCTRL_SUN8I_V3,
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out"),
+ SUNXI_FUNCTION(0x2, "lcd"), /* D10 */
+ SUNXI_FUNCTION(0x4, "emac")), /* RXERR */
+ SUNXI_PIN_VARIANT(SUNXI_PINCTRL_PIN(D, 7),
+ PINCTRL_SUN8I_V3,
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out"),
+ SUNXI_FUNCTION(0x2, "lcd"), /* D11 */
+ SUNXI_FUNCTION(0x4, "emac")), /* TXD3 */
+ SUNXI_PIN_VARIANT(SUNXI_PINCTRL_PIN(D, 8),
+ PINCTRL_SUN8I_V3,
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out"),
+ SUNXI_FUNCTION(0x2, "lcd"), /* D12 */
+ SUNXI_FUNCTION(0x4, "emac")), /* TXD2 */
+ SUNXI_PIN_VARIANT(SUNXI_PINCTRL_PIN(D, 9),
+ PINCTRL_SUN8I_V3,
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out"),
+ SUNXI_FUNCTION(0x2, "lcd"), /* D13 */
+ SUNXI_FUNCTION(0x4, "emac")), /* TXD1 */
+ SUNXI_PIN_VARIANT(SUNXI_PINCTRL_PIN(D, 10),
+ PINCTRL_SUN8I_V3,
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out"),
+ SUNXI_FUNCTION(0x2, "lcd"), /* D14 */
+ SUNXI_FUNCTION(0x4, "emac")), /* TXD0 */
+ SUNXI_PIN_VARIANT(SUNXI_PINCTRL_PIN(D, 11),
+ PINCTRL_SUN8I_V3,
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out"),
+ SUNXI_FUNCTION(0x2, "lcd"), /* D15 */
+ SUNXI_FUNCTION(0x4, "emac")), /* CRS */
+ SUNXI_PIN_VARIANT(SUNXI_PINCTRL_PIN(D, 12),
+ PINCTRL_SUN8I_V3,
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out"),
+ SUNXI_FUNCTION(0x2, "lcd"), /* D18 */
+ SUNXI_FUNCTION(0x3, "lvds"), /* VP0 */
+ SUNXI_FUNCTION(0x4, "emac")), /* TXCK */
+ SUNXI_PIN_VARIANT(SUNXI_PINCTRL_PIN(D, 13),
+ PINCTRL_SUN8I_V3,
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out"),
+ SUNXI_FUNCTION(0x2, "lcd"), /* D19 */
+ SUNXI_FUNCTION(0x3, "lvds"), /* VN0 */
+ SUNXI_FUNCTION(0x4, "emac")), /* TXCTL/TXEN */
+ SUNXI_PIN_VARIANT(SUNXI_PINCTRL_PIN(D, 14),
+ PINCTRL_SUN8I_V3,
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out"),
+ SUNXI_FUNCTION(0x2, "lcd"), /* D20 */
+ SUNXI_FUNCTION(0x3, "lvds"), /* VP1 */
+ SUNXI_FUNCTION(0x4, "emac")), /* TXERR */
+ SUNXI_PIN_VARIANT(SUNXI_PINCTRL_PIN(D, 15),
+ PINCTRL_SUN8I_V3,
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out"),
+ SUNXI_FUNCTION(0x2, "lcd"), /* D21 */
+ SUNXI_FUNCTION(0x3, "lvds"), /* VN1 */
+ SUNXI_FUNCTION(0x4, "emac")), /* CLKIN/COL */
+ SUNXI_PIN_VARIANT(SUNXI_PINCTRL_PIN(D, 16),
+ PINCTRL_SUN8I_V3,
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out"),
+ SUNXI_FUNCTION(0x2, "lcd"), /* D22 */
+ SUNXI_FUNCTION(0x3, "lvds"), /* VP2 */
+ SUNXI_FUNCTION(0x4, "emac")), /* MDC */
+ SUNXI_PIN_VARIANT(SUNXI_PINCTRL_PIN(D, 17),
+ PINCTRL_SUN8I_V3,
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out"),
+ SUNXI_FUNCTION(0x2, "lcd"), /* D23 */
+ SUNXI_FUNCTION(0x3, "lvds"), /* VN2 */
+ SUNXI_FUNCTION(0x4, "emac")), /* MDIO */
+ SUNXI_PIN_VARIANT(SUNXI_PINCTRL_PIN(D, 18),
+ PINCTRL_SUN8I_V3,
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out"),
+ SUNXI_FUNCTION(0x2, "lcd"), /* CLK */
+ SUNXI_FUNCTION(0x3, "lvds")), /* VPC */
+ SUNXI_PIN_VARIANT(SUNXI_PINCTRL_PIN(D, 19),
+ PINCTRL_SUN8I_V3,
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out"),
+ SUNXI_FUNCTION(0x2, "lcd"), /* DE */
+ SUNXI_FUNCTION(0x3, "lvds")), /* VNC */
+ SUNXI_PIN_VARIANT(SUNXI_PINCTRL_PIN(D, 20),
+ PINCTRL_SUN8I_V3,
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out"),
+ SUNXI_FUNCTION(0x2, "lcd"), /* HSYNC */
+ SUNXI_FUNCTION(0x3, "lvds")), /* VP3 */
+ SUNXI_PIN_VARIANT(SUNXI_PINCTRL_PIN(D, 21),
+ PINCTRL_SUN8I_V3,
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out"),
+ SUNXI_FUNCTION(0x2, "lcd"), /* VSYNC */
+ SUNXI_FUNCTION(0x3, "lvds")), /* VN3 */
/* Hole */
SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 0),
SUNXI_FUNCTION(0x0, "gpio_in"),
@@ -291,6 +489,54 @@ static const struct sunxi_desc_pin sun8i_v3s_pins[] = {
SUNXI_FUNCTION(0x1, "gpio_out"),
SUNXI_FUNCTION(0x2, "mmc1"), /* D3 */
SUNXI_FUNCTION_IRQ_BANK(0x6, 1, 5)), /* PG_EINT5 */
+ SUNXI_PIN_VARIANT(SUNXI_PINCTRL_PIN(G, 6),
+ PINCTRL_SUN8I_V3,
+ 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_VARIANT(SUNXI_PINCTRL_PIN(G, 7),
+ PINCTRL_SUN8I_V3,
+ 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_VARIANT(SUNXI_PINCTRL_PIN(G, 8),
+ PINCTRL_SUN8I_V3,
+ 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_VARIANT(SUNXI_PINCTRL_PIN(G, 9),
+ PINCTRL_SUN8I_V3,
+ 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_VARIANT(SUNXI_PINCTRL_PIN(G, 10),
+ PINCTRL_SUN8I_V3,
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out"),
+ SUNXI_FUNCTION(0x2, "i2s"), /* SYNC */
+ SUNXI_FUNCTION_IRQ_BANK(0x6, 1, 10)), /* PG_EINT10 */
+ SUNXI_PIN_VARIANT(SUNXI_PINCTRL_PIN(G, 11),
+ PINCTRL_SUN8I_V3,
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out"),
+ SUNXI_FUNCTION(0x2, "i2s"), /* BCLK */
+ SUNXI_FUNCTION_IRQ_BANK(0x6, 1, 11)), /* PG_EINT11 */
+ SUNXI_PIN_VARIANT(SUNXI_PINCTRL_PIN(G, 12),
+ PINCTRL_SUN8I_V3,
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out"),
+ SUNXI_FUNCTION(0x2, "i2s"), /* DOUT */
+ SUNXI_FUNCTION_IRQ_BANK(0x6, 1, 12)), /* PG_EINT12 */
+ SUNXI_PIN_VARIANT(SUNXI_PINCTRL_PIN(G, 13),
+ PINCTRL_SUN8I_V3,
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out"),
+ SUNXI_FUNCTION(0x2, "i2s"), /* DIN */
+ SUNXI_FUNCTION_IRQ_BANK(0x6, 1, 13)), /* PG_EINT13 */
};
static const unsigned int sun8i_v3s_pinctrl_irq_bank_map[] = { 1, 2 };
@@ -305,13 +551,22 @@ static const struct sunxi_pinctrl_desc sun8i_v3s_pinctrl_data = {
static int sun8i_v3s_pinctrl_probe(struct platform_device *pdev)
{
- return sunxi_pinctrl_init(pdev,
- &sun8i_v3s_pinctrl_data);
+ unsigned long variant = (unsigned long)of_device_get_match_data(&pdev->dev);
+
+ return sunxi_pinctrl_init_with_variant(pdev, &sun8i_v3s_pinctrl_data,
+ variant);
}
static const struct of_device_id sun8i_v3s_pinctrl_match[] = {
- { .compatible = "allwinner,sun8i-v3s-pinctrl", },
- {}
+ {
+ .compatible = "allwinner,sun8i-v3-pinctrl",
+ .data = (void *)PINCTRL_SUN8I_V3
+ },
+ {
+ .compatible = "allwinner,sun8i-v3s-pinctrl",
+ .data = (void *)PINCTRL_SUN8I_V3S
+ },
+ { },
};
static struct platform_driver sun8i_v3s_pinctrl_driver = {
diff --git a/drivers/pinctrl/sunxi/pinctrl-sunxi.h b/drivers/pinctrl/sunxi/pinctrl-sunxi.h
index 44e30deeee38..a32bb5bcb754 100644
--- a/drivers/pinctrl/sunxi/pinctrl-sunxi.h
+++ b/drivers/pinctrl/sunxi/pinctrl-sunxi.h
@@ -94,6 +94,8 @@
#define PINCTRL_SUN4I_A10 BIT(6)
#define PINCTRL_SUN7I_A20 BIT(7)
#define PINCTRL_SUN8I_R40 BIT(8)
+#define PINCTRL_SUN8I_V3 BIT(9)
+#define PINCTRL_SUN8I_V3S BIT(10)
#define PIO_POW_MOD_SEL_REG 0x340
--
2.21.0
^ permalink raw reply related
* [PATCH v5 0/6] Support for Allwinner V3/S3L and Sochip S3
From: Icenowy Zheng @ 2019-07-28 3:12 UTC (permalink / raw)
To: Rob Herring, Maxime Ripard, Chen-Yu Tsai, Linus Walleij
Cc: linux-arm-kernel, linux-kernel, linux-clk, linux-gpio,
linux-sunxi, Icenowy Zheng
This patchset tries to add support for Allwinner V3/S3L and Sochip S3.
Allwinner V3/V3s/S3L and Sochip S3 share the same die, but with
different package. V3 is BGA w/o co-packaged DDR, V3s is QFP w/ DDR2,
S3L is BGA w/ DDR2 and S3 is BGA w/ DDR3. (S3 and S3L is compatible
for pinout, but because of different DDR, DDR voltage is different
between the two variants). Because of the pin count of V3s is
restricted due to the package, some pins are not bound on V3s, but
they're bound on V3/S3/S3L.
Currently the kernel is only prepared for the features available on V3s.
This patchset adds the features missing on V3s for using them on
V3/S3/S3L, and add bindings for V3/S3/S3L. It also adds a S3 SoM by
Sipeed, called Lichee Zero Plus.
Icenowy Zheng (6):
pinctrl: sunxi: v3s: introduce support for V3
clk: sunxi-ng: v3s: add missing clock slices for MMC2 module clocks
clk: sunxi-ng: v3s: add Allwinner V3 support
ARM: sunxi: dts: s3/s3l/v3: add DTSI files for S3/S3L/V3 SoCs
dt-bindings: arm: sunxi: add binding for Lichee Zero Plus core board
ARM: dts: sun8i: s3: add devicetree for Lichee zero plus w/ S3
.../devicetree/bindings/arm/sunxi.yaml | 6 +
arch/arm/boot/dts/Makefile | 1 +
.../boot/dts/sun8i-s3-lichee-zero-plus.dts | 53 ++++
arch/arm/boot/dts/sun8i-v3.dtsi | 14 +
drivers/clk/sunxi-ng/ccu-sun8i-v3s.c | 231 ++++++++++++++-
drivers/clk/sunxi-ng/ccu-sun8i-v3s.h | 2 +-
drivers/pinctrl/sunxi/pinctrl-sun8i-v3s.c | 265 +++++++++++++++++-
drivers/pinctrl/sunxi/pinctrl-sunxi.h | 2 +
include/dt-bindings/clock/sun8i-v3s-ccu.h | 4 +
include/dt-bindings/reset/sun8i-v3s-ccu.h | 3 +
10 files changed, 573 insertions(+), 8 deletions(-)
create mode 100644 arch/arm/boot/dts/sun8i-s3-lichee-zero-plus.dts
create mode 100644 arch/arm/boot/dts/sun8i-v3.dtsi
--
2.21.0
^ permalink raw reply
* [PATCH v1] pinctrl: baytrail: Re-use data structures from pinctrl-intel.h (part 2)
From: Andy Shevchenko @ 2019-07-26 20:16 UTC (permalink / raw)
To: Mika Westerberg, linux-gpio, Linus Walleij; +Cc: Andy Shevchenko
We have some data structures duplicated across the drivers.
Let's deduplicate them by using ones that being provided by
pinctrl-intel.h.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
drivers/pinctrl/intel/pinctrl-baytrail.c | 65 +++++++++---------------
drivers/pinctrl/intel/pinctrl-intel.h | 6 ++-
2 files changed, 27 insertions(+), 44 deletions(-)
diff --git a/drivers/pinctrl/intel/pinctrl-baytrail.c b/drivers/pinctrl/intel/pinctrl-baytrail.c
index 14a81943c5ab..db6c5ca9e2d6 100644
--- a/drivers/pinctrl/intel/pinctrl-baytrail.c
+++ b/drivers/pinctrl/intel/pinctrl-baytrail.c
@@ -98,13 +98,6 @@ struct byt_gpio_pin_context {
u32 val;
};
-struct byt_community {
- unsigned int pin_base;
- size_t npins;
- const unsigned int *pad_map;
- void __iomem *reg_base;
-};
-
#define COMMUNITY(p, n, map) \
{ \
.pin_base = (p), \
@@ -112,26 +105,14 @@ struct byt_community {
.pad_map = (map),\
}
-struct byt_pinctrl_soc_data {
- const char *uid;
- const struct pinctrl_pin_desc *pins;
- size_t npins;
- const struct intel_pingroup *groups;
- size_t ngroups;
- const struct intel_function *functions;
- size_t nfunctions;
- const struct byt_community *communities;
- size_t ncommunities;
-};
-
struct byt_gpio {
struct gpio_chip chip;
struct platform_device *pdev;
struct pinctrl_dev *pctl_dev;
struct pinctrl_desc pctl_desc;
raw_spinlock_t lock;
- const struct byt_pinctrl_soc_data *soc_data;
- struct byt_community *communities_copy;
+ const struct intel_pinctrl_soc_data *soc_data;
+ struct intel_community *communities_copy;
struct byt_gpio_pin_context *saved_context;
};
@@ -383,11 +364,11 @@ static const struct intel_function byt_score_functions[] = {
FUNCTION("gpio", byt_score_gpio_groups),
};
-static const struct byt_community byt_score_communities[] = {
+static const struct intel_community byt_score_communities[] = {
COMMUNITY(0, BYT_NGPIO_SCORE, byt_score_pins_map),
};
-static const struct byt_pinctrl_soc_data byt_score_soc_data = {
+static const struct intel_pinctrl_soc_data byt_score_soc_data = {
.uid = BYT_SCORE_ACPI_UID,
.pins = byt_score_pins,
.npins = ARRAY_SIZE(byt_score_pins),
@@ -496,11 +477,11 @@ static const struct intel_function byt_sus_functions[] = {
FUNCTION("gpio", byt_sus_gpio_groups),
};
-static const struct byt_community byt_sus_communities[] = {
+static const struct intel_community byt_sus_communities[] = {
COMMUNITY(0, BYT_NGPIO_SUS, byt_sus_pins_map),
};
-static const struct byt_pinctrl_soc_data byt_sus_soc_data = {
+static const struct intel_pinctrl_soc_data byt_sus_soc_data = {
.uid = BYT_SUS_ACPI_UID,
.pins = byt_sus_pins,
.npins = ARRAY_SIZE(byt_sus_pins),
@@ -549,11 +530,11 @@ static const unsigned int byt_ncore_pins_map[BYT_NGPIO_NCORE] = {
3, 6, 10, 13, 2, 5, 9, 7,
};
-static const struct byt_community byt_ncore_communities[] = {
+static const struct intel_community byt_ncore_communities[] = {
COMMUNITY(0, BYT_NGPIO_NCORE, byt_ncore_pins_map),
};
-static const struct byt_pinctrl_soc_data byt_ncore_soc_data = {
+static const struct intel_pinctrl_soc_data byt_ncore_soc_data = {
.uid = BYT_NCORE_ACPI_UID,
.pins = byt_ncore_pins,
.npins = ARRAY_SIZE(byt_ncore_pins),
@@ -561,17 +542,17 @@ static const struct byt_pinctrl_soc_data byt_ncore_soc_data = {
.ncommunities = ARRAY_SIZE(byt_ncore_communities),
};
-static const struct byt_pinctrl_soc_data *byt_soc_data[] = {
+static const struct intel_pinctrl_soc_data *byt_soc_data[] = {
&byt_score_soc_data,
&byt_sus_soc_data,
&byt_ncore_soc_data,
NULL
};
-static struct byt_community *byt_get_community(struct byt_gpio *vg,
- unsigned int pin)
+static struct intel_community *byt_get_community(struct byt_gpio *vg,
+ unsigned int pin)
{
- struct byt_community *comm;
+ struct intel_community *comm;
int i;
for (i = 0; i < vg->soc_data->ncommunities; i++) {
@@ -586,7 +567,7 @@ static struct byt_community *byt_get_community(struct byt_gpio *vg,
static void __iomem *byt_gpio_reg(struct byt_gpio *vg, unsigned int offset,
int reg)
{
- struct byt_community *comm = byt_get_community(vg, offset);
+ struct intel_community *comm = byt_get_community(vg, offset);
u32 reg_offset;
if (!comm)
@@ -605,7 +586,7 @@ static void __iomem *byt_gpio_reg(struct byt_gpio *vg, unsigned int offset,
break;
}
- return comm->reg_base + reg_offset + reg;
+ return comm->pad_regs + reg_offset + reg;
}
static int byt_get_groups_count(struct pinctrl_dev *pctldev)
@@ -1211,7 +1192,7 @@ static void byt_gpio_dbg_show(struct seq_file *s, struct gpio_chip *chip)
u32 conf0, val;
for (i = 0; i < vg->soc_data->npins; i++) {
- const struct byt_community *comm;
+ const struct intel_community *comm;
const char *pull_str = NULL;
const char *pull = NULL;
void __iomem *reg;
@@ -1566,7 +1547,7 @@ static int byt_gpio_probe(struct byt_gpio *vg)
}
static int byt_set_soc_data(struct byt_gpio *vg,
- const struct byt_pinctrl_soc_data *soc_data)
+ const struct intel_pinctrl_soc_data *soc_data)
{
int i;
@@ -1579,13 +1560,13 @@ static int byt_set_soc_data(struct byt_gpio *vg,
return -ENOMEM;
for (i = 0; i < soc_data->ncommunities; i++) {
- struct byt_community *comm = vg->communities_copy + i;
+ struct intel_community *comm = vg->communities_copy + i;
*comm = vg->soc_data->communities[i];
- comm->reg_base = devm_platform_ioremap_resource(vg->pdev, 0);
- if (IS_ERR(comm->reg_base))
- return PTR_ERR(comm->reg_base);
+ comm->pad_regs = devm_platform_ioremap_resource(vg->pdev, 0);
+ if (IS_ERR(comm->pad_regs))
+ return PTR_ERR(comm->pad_regs);
}
return 0;
@@ -1599,8 +1580,8 @@ static const struct acpi_device_id byt_gpio_acpi_match[] = {
static int byt_pinctrl_probe(struct platform_device *pdev)
{
- const struct byt_pinctrl_soc_data *soc_data = NULL;
- const struct byt_pinctrl_soc_data **soc_table;
+ const struct intel_pinctrl_soc_data *soc_data = NULL;
+ const struct intel_pinctrl_soc_data **soc_table;
struct acpi_device *acpi_dev;
struct byt_gpio *vg;
int i, ret;
@@ -1609,7 +1590,7 @@ static int byt_pinctrl_probe(struct platform_device *pdev)
if (!acpi_dev)
return -ENODEV;
- soc_table = (const struct byt_pinctrl_soc_data **)device_get_match_data(&pdev->dev);
+ soc_table = (const struct intel_pinctrl_soc_data **)device_get_match_data(&pdev->dev);
for (i = 0; soc_table[i]; i++) {
if (!strcmp(acpi_dev->pnp.unique_id, soc_table[i]->uid)) {
diff --git a/drivers/pinctrl/intel/pinctrl-intel.h b/drivers/pinctrl/intel/pinctrl-intel.h
index a8e958f1dcf5..50a290093ea8 100644
--- a/drivers/pinctrl/intel/pinctrl-intel.h
+++ b/drivers/pinctrl/intel/pinctrl-intel.h
@@ -78,6 +78,7 @@ struct intel_padgroup {
* @is_offset: Register offset of GPI_IS from @regs. If %0 then uses the
* default (%0x100).
* @ie_offset: Register offset of GPI_IE from @regs.
+ * @features: Additional features supported by the hardware
* @pin_base: Starting pin of pins in this community
* @gpp_size: Maximum number of pads in each group, such as PADCFGLOCK,
* HOSTSW_OWN, GPI_IS, GPI_IE, etc. Used when @gpps is %NULL.
@@ -85,9 +86,9 @@ struct intel_padgroup {
* minimum. Use %0 if the number of registers can be
* determined by the size of the group.
* @npins: Number of pins in this community
- * @features: Additional features supported by the hardware
* @gpps: Pad groups if the controller has variable size pad groups
* @ngpps: Number of pad groups in this community
+ * @pad_map: Optional non-linear mapping of the pads
* @regs: Community specific common registers (reserved for core driver)
* @pad_regs: Community specific pad registers (reserved for core driver)
*
@@ -104,13 +105,14 @@ struct intel_community {
unsigned int hostown_offset;
unsigned int is_offset;
unsigned int ie_offset;
+ unsigned int features;
unsigned int pin_base;
unsigned int gpp_size;
unsigned int gpp_num_padown_regs;
size_t npins;
- unsigned int features;
const struct intel_padgroup *gpps;
size_t ngpps;
+ const unsigned int *pad_map;
/* Reserved for the core driver */
void __iomem *regs;
void __iomem *pad_regs;
--
2.20.1
^ permalink raw reply related
* [PATCH v1] pinctrl: intel: Allow to request locked pins
From: Andy Shevchenko @ 2019-07-26 20:08 UTC (permalink / raw)
To: Mika Westerberg, linux-gpio, Linus Walleij; +Cc: Andy Shevchenko
Some firmwares would like to protect pins from being modified by OS
and at the same time provide them to OS as a resource. So, the driver
in such circumstances may request pin and may not change its state.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
drivers/pinctrl/intel/pinctrl-intel.c | 55 +++++++++++++++++++--------
1 file changed, 39 insertions(+), 16 deletions(-)
diff --git a/drivers/pinctrl/intel/pinctrl-intel.c b/drivers/pinctrl/intel/pinctrl-intel.c
index 3a945997b8eb..567fe43b238f 100644
--- a/drivers/pinctrl/intel/pinctrl-intel.c
+++ b/drivers/pinctrl/intel/pinctrl-intel.c
@@ -220,22 +220,30 @@ static bool intel_pad_acpi_mode(struct intel_pinctrl *pctrl, unsigned int pin)
return !(readl(hostown) & BIT(gpp_offset));
}
-static bool intel_pad_locked(struct intel_pinctrl *pctrl, unsigned int pin)
+enum {
+ PAD_UNLOCKED = 0,
+ PAD_LOCKED = 1,
+ PAD_LOCKED_TX = 2,
+ PAD_LOCKED_FULL = PAD_LOCKED | PAD_LOCKED_TX,
+};
+
+static int intel_pad_locked(struct intel_pinctrl *pctrl, unsigned int pin)
{
struct intel_community *community;
const struct intel_padgroup *padgrp;
unsigned int offset, gpp_offset;
u32 value;
+ int ret = PAD_UNLOCKED;
community = intel_get_community(pctrl, pin);
if (!community)
- return true;
+ return PAD_LOCKED_FULL;
if (!community->padcfglock_offset)
- return false;
+ return PAD_UNLOCKED;
padgrp = intel_community_get_padgroup(community, pin);
if (!padgrp)
- return true;
+ return PAD_LOCKED_FULL;
gpp_offset = padgroup_offset(padgrp, pin);
@@ -244,23 +252,27 @@ static bool intel_pad_locked(struct intel_pinctrl *pctrl, unsigned int pin)
* the pad is considered unlocked. Any other case means that it is
* either fully or partially locked and we don't touch it.
*/
- offset = community->padcfglock_offset + padgrp->reg_num * 8;
+ offset = community->padcfglock_offset + 0 + padgrp->reg_num * 8;
value = readl(community->regs + offset);
if (value & BIT(gpp_offset))
- return true;
+ ret |= PAD_LOCKED;
offset = community->padcfglock_offset + 4 + padgrp->reg_num * 8;
value = readl(community->regs + offset);
if (value & BIT(gpp_offset))
- return true;
+ ret |= PAD_LOCKED_TX;
- return false;
+ return ret;
+}
+
+static bool intel_pad_is_unlocked(struct intel_pinctrl *pctrl, unsigned int pin)
+{
+ return (intel_pad_locked(pctrl, pin) & PAD_LOCKED) == PAD_UNLOCKED;
}
static bool intel_pad_usable(struct intel_pinctrl *pctrl, unsigned int pin)
{
- return intel_pad_owned_by_host(pctrl, pin) &&
- !intel_pad_locked(pctrl, pin);
+ return intel_pad_owned_by_host(pctrl, pin) && intel_pad_is_unlocked(pctrl, pin);
}
static int intel_get_groups_count(struct pinctrl_dev *pctldev)
@@ -294,7 +306,8 @@ static void intel_pin_dbg_show(struct pinctrl_dev *pctldev, struct seq_file *s,
struct intel_pinctrl *pctrl = pinctrl_dev_get_drvdata(pctldev);
void __iomem *padcfg;
u32 cfg0, cfg1, mode;
- bool locked, acpi;
+ int locked;
+ bool acpi;
if (!intel_pad_owned_by_host(pctrl, pin)) {
seq_puts(s, "not available");
@@ -322,11 +335,16 @@ static void intel_pin_dbg_show(struct pinctrl_dev *pctldev, struct seq_file *s,
if (locked || acpi) {
seq_puts(s, " [");
- if (locked) {
+ if (locked)
seq_puts(s, "LOCKED");
- if (acpi)
- seq_puts(s, ", ");
- }
+ if ((locked & PAD_LOCKED_FULL) == PAD_LOCKED_TX)
+ seq_puts(s, " TX");
+ else if ((locked & PAD_LOCKED_FULL) == PAD_LOCKED_FULL)
+ seq_puts(s, " FULL");
+
+ if (locked && acpi)
+ seq_puts(s, ", ");
+
if (acpi)
seq_puts(s, "ACPI");
seq_puts(s, "]");
@@ -448,11 +466,16 @@ static int intel_gpio_request_enable(struct pinctrl_dev *pctldev,
raw_spin_lock_irqsave(&pctrl->lock, flags);
- if (!intel_pad_usable(pctrl, pin)) {
+ if (!intel_pad_owned_by_host(pctrl, pin)) {
raw_spin_unlock_irqrestore(&pctrl->lock, flags);
return -EBUSY;
}
+ if (!intel_pad_is_unlocked(pctrl, pin)) {
+ raw_spin_unlock_irqrestore(&pctrl->lock, flags);
+ return 0;
+ }
+
padcfg0 = intel_get_padcfg(pctrl, pin, PADCFG0);
intel_gpio_set_gpio_mode(padcfg0);
/* Disable TX buffer and enable RX (this will be input) */
--
2.20.1
^ permalink raw reply related
* Re: [RFC/RFT v3 04/14] clk: meson: eeclk: add setup callback
From: Neil Armstrong @ 2019-07-26 14:50 UTC (permalink / raw)
To: Jerome Brunet, khilman
Cc: linux-arm-kernel, linux-amlogic, linux-kernel, linux-clk,
martin.blumenstingl, linux-gpio
In-Reply-To: <1jh8836w49.fsf@starbuckisacylon.baylibre.com>
On 03/07/2019 16:17, Jerome Brunet wrote:
> On Mon 01 Jul 2019 at 11:12, Neil Armstrong <narmstrong@baylibre.com> wrote:
>
>> Add a setup() callback in the eeclk structure, to call an optional
>> call() function at end of eeclk probe to setup clocks.
>>
>> It's used for the G12A clock controller to setup the CPU clock
>> notifiers.
>
> I'd prefer if you implement the probe function in the related controller
> have this probe function call meson_eeclkc_probe() for the common part
>
> In your case, I suppose it means implementing the g12a controller probe
> to deal with the notifiers
Sure, but with this eeclk setup callback I can provide a different setup() callback
for g12a and g12b (and later sm1), without this means adding a top data struct
containing a setup() callback pointer and the soc meson_eeclkc_data struct to be able
to call a setup() for each family like done actually, but this will broke eeclk since
the match_data data won't be a meson_eeclkc_data() struct anymore.
If you still prefer this, I can rework it like that.
I'm rebasing all the stuff on v5.3-rc1 and plan to repost an updated version
shortly, solving this would be easier.
Neil
>
>>
>> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
>> ---
>> drivers/clk/meson/meson-eeclk.c | 6 ++++++
>> drivers/clk/meson/meson-eeclk.h | 1 +
>> 2 files changed, 7 insertions(+)
>>
>> diff --git a/drivers/clk/meson/meson-eeclk.c b/drivers/clk/meson/meson-eeclk.c
>> index 6ba2094be257..81fd2abcd173 100644
>> --- a/drivers/clk/meson/meson-eeclk.c
>> +++ b/drivers/clk/meson/meson-eeclk.c
>> @@ -61,6 +61,12 @@ int meson_eeclkc_probe(struct platform_device *pdev)
>> }
>> }
>>
>> + if (data->setup) {
>> + ret = data->setup(pdev);
>> + if (ret)
>> + return ret;
>> + }
>> +
>> return devm_of_clk_add_hw_provider(dev, of_clk_hw_onecell_get,
>> data->hw_onecell_data);
>> }
>> diff --git a/drivers/clk/meson/meson-eeclk.h b/drivers/clk/meson/meson-eeclk.h
>> index 9ab5d6fa7ccb..7fdf424f71a6 100644
>> --- a/drivers/clk/meson/meson-eeclk.h
>> +++ b/drivers/clk/meson/meson-eeclk.h
>> @@ -20,6 +20,7 @@ struct meson_eeclkc_data {
>> const struct reg_sequence *init_regs;
>> unsigned int init_count;
>> struct clk_hw_onecell_data *hw_onecell_data;
>> + int (*setup)(struct platform_device *pdev);
>> };
>>
>> int meson_eeclkc_probe(struct platform_device *pdev);
>> --
>> 2.21.0
^ permalink raw reply
* [PATCH 2/2] pinctrl: qcom: spmi-gpio: Mark expected switch fall-through
From: Anders Roxell @ 2019-07-26 11:28 UTC (permalink / raw)
To: bjorn.andersson, agross, linus.walleij
Cc: heiko, linux-arm-msm, linux-gpio, linux-kernel, Anders Roxell
When fall-through warnings was enabled by default the following warnings
was starting to show up:
../drivers/pinctrl/qcom/pinctrl-spmi-gpio.c: In function ‘pmic_gpio_populate’:
../drivers/pinctrl/qcom/pinctrl-spmi-gpio.c:815:20: warning: this statement may fall
through [-Wimplicit-fallthrough=]
pad->have_buffer = true;
~~~~~~~~~~~~~~~~~^~~~~~
../drivers/pinctrl/qcom/pinctrl-spmi-gpio.c:816:2: note: here
case PMIC_GPIO_SUBTYPE_GPIOC_4CH:
^~~~
../drivers/pinctrl/qcom/pinctrl-spmi-gpio.c:820:20: warning: this statement may fall
through [-Wimplicit-fallthrough=]
pad->have_buffer = true;
~~~~~~~~~~~~~~~~~^~~~~~
../drivers/pinctrl/qcom/pinctrl-spmi-gpio.c:821:2: note: here
case PMIC_GPIO_SUBTYPE_GPIOC_8CH:
^~~~
Rework so that the compiler doesn't warn about fall-through.
Fixes: d93512ef0f0e ("Makefile: Globally enable fall-through warning")
Signed-off-by: Anders Roxell <anders.roxell@linaro.org>
---
drivers/pinctrl/qcom/pinctrl-spmi-gpio.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/pinctrl/qcom/pinctrl-spmi-gpio.c b/drivers/pinctrl/qcom/pinctrl-spmi-gpio.c
index f39da87ea185..ebf33f65c1bc 100644
--- a/drivers/pinctrl/qcom/pinctrl-spmi-gpio.c
+++ b/drivers/pinctrl/qcom/pinctrl-spmi-gpio.c
@@ -813,11 +813,13 @@ static int pmic_gpio_populate(struct pmic_gpio_state *state,
switch (subtype) {
case PMIC_GPIO_SUBTYPE_GPIO_4CH:
pad->have_buffer = true;
+ /* Fall through */
case PMIC_GPIO_SUBTYPE_GPIOC_4CH:
pad->num_sources = 4;
break;
case PMIC_GPIO_SUBTYPE_GPIO_8CH:
pad->have_buffer = true;
+ /* Fall through */
case PMIC_GPIO_SUBTYPE_GPIOC_8CH:
pad->num_sources = 8;
break;
--
2.20.1
^ permalink raw reply related
* [PATCH 1/2] pinctrl: rockchip: Mark expected switch fall-through
From: Anders Roxell @ 2019-07-26 11:28 UTC (permalink / raw)
To: linus.walleij, heiko
Cc: bjorn.andersson, agross, linux-gpio, linux-arm-kernel,
linux-rockchip, linux-kernel, Anders Roxell
When fall-through warnings was enabled by default the following warning
was starting to show up:
../drivers/pinctrl/pinctrl-rockchip.c: In function ‘rockchip_gpio_set_config’:
../drivers/pinctrl/pinctrl-rockchip.c:2783:3: warning: this statement may fall
through [-Wimplicit-fallthrough=]
rockchip_gpio_set_debounce(gc, offset, true);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../drivers/pinctrl/pinctrl-rockchip.c:2795:2: note: here
default:
^~~~~~~
Rework so that the compiler doesn't warn about fall-through. Add
'return -ENOTSUPP;' to match the comment.
Fixes: d93512ef0f0e ("Makefile: Globally enable fall-through warning")
Signed-off-by: Anders Roxell <anders.roxell@linaro.org>
---
drivers/pinctrl/pinctrl-rockchip.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/pinctrl/pinctrl-rockchip.c b/drivers/pinctrl/pinctrl-rockchip.c
index 62a622159006..dc0bbf198cbc 100644
--- a/drivers/pinctrl/pinctrl-rockchip.c
+++ b/drivers/pinctrl/pinctrl-rockchip.c
@@ -2792,6 +2792,7 @@ static int rockchip_gpio_set_config(struct gpio_chip *gc, unsigned int offset,
* still return -ENOTSUPP as before, to make sure the caller
* of gpiod_set_debounce won't change its behaviour.
*/
+ return -ENOTSUPP;
default:
return -ENOTSUPP;
}
--
2.20.1
^ permalink raw reply related
* Re: [PATCH V6 17/21] arm64: tegra: Enable wake from deep sleep on RTC alarm.
From: Dmitry Osipenko @ 2019-07-26 6:30 UTC (permalink / raw)
To: Sowjanya Komatineni
Cc: thierry.reding, jonathanh, tglx, jason, marc.zyngier,
linus.walleij, stefan, mark.rutland, pdeschrijver, pgaikwad,
sboyd, linux-clk, linux-gpio, jckuo, josephl, talho, linux-tegra,
linux-kernel, mperttunen, spatra, robh+dt, devicetree
In-Reply-To: <1563738060-30213-18-git-send-email-skomatineni@nvidia.com>
В Sun, 21 Jul 2019 12:40:56 -0700
Sowjanya Komatineni <skomatineni@nvidia.com> пишет:
> This patch updates device tree for RTC and PMC to allow system wake
> from deep sleep on RTC alarm.
>
> Signed-off-by: Sowjanya Komatineni <skomatineni@nvidia.com>
The dot in the end of the commit's title is unnecessary.
^ permalink raw reply
* [RFC PATCH 10/17] dt-bindings: pinctrl: aspeed: Add reg property as a hint
From: Andrew Jeffery @ 2019-07-26 5:39 UTC (permalink / raw)
To: linux-aspeed
Cc: Andrew Jeffery, robh+dt, mark.rutland, joel, devicetree,
linux-arm-kernel, linux-kernel, Linus Walleij, linux-gpio
In-Reply-To: <20190726053959.2003-1-andrew@aj.id.au>
The pinctrl node sits under a syscon device, and can assume offsets from
the base of the syscon based on the compatible. However, for devicetree
correctness allow a reg property to be specified, which an associated
driver may choose to use to discover associated resources.
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: linux-gpio@vger.kernel.org
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
---
.../devicetree/bindings/pinctrl/aspeed,ast2400-pinctrl.yaml | 3 +++
.../devicetree/bindings/pinctrl/aspeed,ast2500-pinctrl.yaml | 3 +++
2 files changed, 6 insertions(+)
diff --git a/Documentation/devicetree/bindings/pinctrl/aspeed,ast2400-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/aspeed,ast2400-pinctrl.yaml
index 125599a2dc5e..629a55c167ae 100644
--- a/Documentation/devicetree/bindings/pinctrl/aspeed,ast2400-pinctrl.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/aspeed,ast2400-pinctrl.yaml
@@ -25,6 +25,9 @@ properties:
enum:
- aspeed,ast2400-pinctrl
- aspeed,g4-pinctrl
+ reg:
+ description: |
+ A hint for the memory regions associated with the pin-controller
patternProperties:
'^.*$':
diff --git a/Documentation/devicetree/bindings/pinctrl/aspeed,ast2500-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/aspeed,ast2500-pinctrl.yaml
index 3e6d85318577..2e8971e23a02 100644
--- a/Documentation/devicetree/bindings/pinctrl/aspeed,ast2500-pinctrl.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/aspeed,ast2500-pinctrl.yaml
@@ -25,6 +25,9 @@ properties:
enum:
- aspeed,ast2500-pinctrl
- aspeed,g5-pinctrl
+ reg:
+ description: |
+ A hint for the memory regions associated with the pin-controller
aspeed,external-nodes:
minItems: 2
maxItems: 2
--
2.20.1
^ permalink raw reply related
* [RFC-ish PATCH 00/17] Clean up ASPEED devicetree warnings
From: Andrew Jeffery @ 2019-07-26 5:39 UTC (permalink / raw)
To: linux-aspeed
Cc: Andrew Jeffery, robh+dt, mark.rutland, joel, devicetree,
linux-arm-kernel, linux-kernel, anoo, a.filippov, arnd,
yang.brianc.w, minyard, gregkh, haiyue.wang, wangzqbj, chen.kenyy,
linus.walleij, linux-gpio, openipmi-developer, venture, sschaeck,
taoren, xow, yao.yuan
Hello,
The aim of this series is to minimise/eliminate all the warnings from the
ASPEED devicetrees. It mostly achieves its goal, as outlined below.
Using `aspeed_g5_defconfig` we started with the follow warning count:
$ make dtbs 2>&1 >/dev/null | wc -l
218
and after the full series is applied we have:
$ make dtbs 2>&1 >/dev/null | wc -l
2
for a 100x reduction.
Getting there though isn't without some potential controversy, which I've saved
for the last half of the series. The following patches I think are in pretty
good shape:
ARM: dts: aspeed-g5: Move EDAC node to APB
ARM: dts: aspeed-g5: Use recommended generic node name for SDMC
ARM: dts: aspeed-g5: Fix aspeed,external-nodes description
ARM: dts: vesnin: Add unit address for memory node
ARM: dts: fp5280g2: Cleanup gpio-keys-polled properties
ARM: dts: swift: Cleanup gpio-keys-polled properties
ARM: dts: witherspoon: Cleanup gpio-keys-polled properties
ARM: dts: aspeed: Cleanup lpc-ctrl and snoop regs
ARM: dts: ibm-power9-dual: Add a unit address for OCC nodes
With these patches applied we get to:
$ make dtbs 2>&1 >/dev/null | wc -l
144
So they make a dent, but fail to clean up the bulk of the issues. From here
I've mixed in some binding and driver changes with subsequent updates to the
devicetrees:
dt-bindings: pinctrl: aspeed: Add reg property as a hint
dt-bindings: misc: Document reg for aspeed,p2a-ctrl nodes
ARM: dts: aspeed: Add reg hints to syscon children
dt-bindings: ipmi: aspeed: Introduce a v2 binding for KCS
ipmi: kcs: Finish configuring ASPEED KCS device before enable
ipmi: kcs: aspeed: Implement v2 bindings
ARM: dts: aspeed-g5: Change KCS nodes to v2 binding
ARM: dts: aspeed-g5: Sort LPC child nodes by unit address
By `dt-bindings: ipmi: aspeed: Introduce a v2 binding for KCS` the warnings are
reduced to:
$ make dtbs 2>&1 >/dev/null | wc -l
125
The bang-for-buck is in fixing up the KCS bindings which removes all-but-two of
the remaining warnings (which we can't feasibly remove), but doing so forces
code changes (which I'd avoided up until this point).
Reflecting broadly on the fixes, I think I've made a mistake way back by using
syscon/simple-mfds to expose the innards of the SCU and LPC controllers in the
devicetree. This series cleans up what's currently there, but I have half a
mind to rev the SCU and LPC bindings to not use simple-mfd and instead have a
driver implementation that uses `platform_device_register_full()` or similar to
deal with the mess.
Rob - I'm looking for your thoughts here and on the series, I've never felt
entirely comfortable with what I cooked up. Your advice would be appreciated.
Anyway, everyone, please let me know your thoughts on the bits relevant to you.
If we can agree on a way forward I'll split up the series for subsequent
submissions so it isn't such a spam-fest.
Cheers,
Andrew
Andrew Jeffery (17):
ARM: dts: aspeed-g5: Move EDAC node to APB
ARM: dts: aspeed-g5: Use recommended generic node name for SDMC
ARM: dts: aspeed-g5: Fix aspeed,external-nodes description
ARM: dts: vesnin: Add unit address for memory node
ARM: dts: fp5280g2: Cleanup gpio-keys-polled properties
ARM: dts: swift: Cleanup gpio-keys-polled properties
ARM: dts: witherspoon: Cleanup gpio-keys-polled properties
ARM: dts: aspeed: Cleanup lpc-ctrl and snoop regs
ARM: dts: ibm-power9-dual: Add a unit address for OCC nodes
dt-bindings: pinctrl: aspeed: Add reg property as a hint
dt-bindings: misc: Document reg for aspeed,p2a-ctrl nodes
ARM: dts: aspeed: Add reg hints to syscon children
dt-bindings: ipmi: aspeed: Introduce a v2 binding for KCS
ipmi: kcs: Finish configuring ASPEED KCS device before enable
ipmi: kcs: aspeed: Implement v2 bindings
ARM: dts: aspeed-g5: Change KCS nodes to v2 binding
ARM: dts: aspeed-g5: Sort LPC child nodes by unit address
.../bindings/ipmi/aspeed-kcs-bmc.txt | 20 ++-
.../bindings/misc/aspeed-p2a-ctrl.txt | 1 +
.../pinctrl/aspeed,ast2400-pinctrl.yaml | 3 +
.../pinctrl/aspeed,ast2500-pinctrl.yaml | 3 +
.../dts/aspeed-bmc-arm-centriq2400-rep.dts | 4 -
.../aspeed-bmc-arm-stardragon4800-rep2.dts | 4 -
arch/arm/boot/dts/aspeed-bmc-facebook-cmm.dts | 4 -
.../arm/boot/dts/aspeed-bmc-facebook-yamp.dts | 4 -
.../boot/dts/aspeed-bmc-inspur-fp5280g2.dts | 6 -
.../arm/boot/dts/aspeed-bmc-intel-s2600wf.dts | 4 -
arch/arm/boot/dts/aspeed-bmc-opp-lanyang.dts | 4 -
arch/arm/boot/dts/aspeed-bmc-opp-romulus.dts | 4 -
arch/arm/boot/dts/aspeed-bmc-opp-swift.dts | 6 -
arch/arm/boot/dts/aspeed-bmc-opp-vesnin.dts | 2 +-
.../boot/dts/aspeed-bmc-opp-witherspoon.dts | 6 -
arch/arm/boot/dts/aspeed-bmc-opp-zaius.dts | 2 -
arch/arm/boot/dts/aspeed-g4.dtsi | 21 ++-
arch/arm/boot/dts/aspeed-g5.dtsi | 73 ++++----
arch/arm/boot/dts/ibm-power9-dual.dtsi | 4 +-
drivers/char/ipmi/kcs_bmc_aspeed.c | 163 ++++++++++++++----
20 files changed, 205 insertions(+), 133 deletions(-)
--
2.20.1
^ permalink raw reply
* Re: [PATCH V6 01/21] irqchip: tegra: Do not disable COP IRQ during suspend
From: Dmitry Osipenko @ 2019-07-26 4:48 UTC (permalink / raw)
To: Sowjanya Komatineni
Cc: Marc Zyngier, thierry.reding, jonathanh, tglx, jason,
linus.walleij, stefan, mark.rutland, pdeschrijver, pgaikwad,
sboyd, linux-clk, linux-gpio, jckuo, josephl, talho, linux-tegra,
linux-kernel, mperttunen, spatra, robh+dt, devicetree
In-Reply-To: <78d5af07-2556-b60d-01d7-3684ebe7040b@nvidia.com>
В Wed, 24 Jul 2019 16:09:53 -0700
Sowjanya Komatineni <skomatineni@nvidia.com> пишет:
> On 7/22/19 4:35 PM, Dmitry Osipenko wrote:
> > 22.07.2019 21:38, Marc Zyngier пишет:
> >> On Mon, 22 Jul 2019 09:21:21 -0700
> >> Sowjanya Komatineni <skomatineni@nvidia.com> wrote:
> >>
> >>> On 7/22/19 3:57 AM, Dmitry Osipenko wrote:
> >>>> 22.07.2019 13:13, Marc Zyngier пишет:
> >>>>> On 22/07/2019 10:54, Dmitry Osipenko wrote:
> >>>>>> 21.07.2019 22:40, Sowjanya Komatineni пишет:
> >>>>>>> Tegra210 platforms use sc7 entry firmware to program Tegra
> >>>>>>> LP0/SC7 entry sequence and sc7 entry firmware is run from
> >>>>>>> COP/BPMP-Lite.
> >>>>>>>
> >>>>>>> So, COP/BPMP-Lite still need IRQ function to finish SC7
> >>>>>>> suspend sequence for Tegra210.
> >>>>>>>
> >>>>>>> This patch has fix for leaving the COP IRQ enabled for
> >>>>>>> Tegra210 during interrupt controller suspend operation.
> >>>>>>>
> >>>>>>> Acked-by: Thierry Reding <treding@nvidia.com>
> >>>>>>> Signed-off-by: Sowjanya Komatineni <skomatineni@nvidia.com>
> >>>>>>> ---
> >>>>>>> drivers/irqchip/irq-tegra.c | 20 ++++++++++++++++++--
> >>>>>>> 1 file changed, 18 insertions(+), 2 deletions(-)
> >>>>>>>
> >>>>>>> diff --git a/drivers/irqchip/irq-tegra.c
> >>>>>>> b/drivers/irqchip/irq-tegra.c index
> >>>>>>> e1f771c72fc4..851f88cef508 100644 ---
> >>>>>>> a/drivers/irqchip/irq-tegra.c +++
> >>>>>>> b/drivers/irqchip/irq-tegra.c @@ -44,6 +44,7 @@ static
> >>>>>>> unsigned int num_ictlrs;
> >>>>>>> struct tegra_ictlr_soc {
> >>>>>>> unsigned int num_ictlrs;
> >>>>>>> + bool supports_sc7;
> >>>>>>> };
> >>>>>>>
> >>>>>>> static const struct tegra_ictlr_soc tegra20_ictlr_soc = {
> >>>>>>> @@ -56,6 +57,7 @@ static const struct tegra_ictlr_soc
> >>>>>>> tegra30_ictlr_soc = {
> >>>>>>> static const struct tegra_ictlr_soc tegra210_ictlr_soc = {
> >>>>>>> .num_ictlrs = 6,
> >>>>>>> + .supports_sc7 = true,
> >>>>>>> };
> >>>>>>>
> >>>>>>> static const struct of_device_id ictlr_matches[] = {
> >>>>>>> @@ -67,6 +69,7 @@ static const struct of_device_id
> >>>>>>> ictlr_matches[] = {
> >>>>>>> struct tegra_ictlr_info {
> >>>>>>> void __iomem *base[TEGRA_MAX_NUM_ICTLRS];
> >>>>>>> + const struct tegra_ictlr_soc *soc;
> >>>>>>> #ifdef CONFIG_PM_SLEEP
> >>>>>>> u32 cop_ier[TEGRA_MAX_NUM_ICTLRS];
> >>>>>>> u32 cop_iep[TEGRA_MAX_NUM_ICTLRS];
> >>>>>>> @@ -147,8 +150,20 @@ static int tegra_ictlr_suspend(void)
> >>>>>>> lic->cop_ier[i] = readl_relaxed(ictlr +
> >>>>>>> ICTLR_COP_IER); lic->cop_iep[i] = readl_relaxed(ictlr +
> >>>>>>> ICTLR_COP_IEP_CLASS);
> >>>>>>> - /* Disable COP interrupts */
> >>>>>>> - writel_relaxed(~0ul, ictlr +
> >>>>>>> ICTLR_COP_IER_CLR);
> >>>>>>> + /*
> >>>>>>> + * AVP/COP/BPMP-Lite is the Tegra boot
> >>>>>>> processor.
> >>>>>>> + *
> >>>>>>> + * Tegra210 system suspend flow uses
> >>>>>>> sc7entry firmware which
> >>>>>>> + * is executed by COP/BPMP and it includes
> >>>>>>> disabling COP IRQ,
> >>>>>>> + * clamping CPU rail, turning off VDD_CPU,
> >>>>>>> and preparing the
> >>>>>>> + * system to go to SC7/LP0.
> >>>>>>> + *
> >>>>>>> + * COP/BPMP wakes up when COP IRQ is
> >>>>>>> triggered and runs
> >>>>>>> + * sc7entry-firmware. So need to keep COP
> >>>>>>> interrupt enabled.
> >>>>>>> + */
> >>>>>>> + if (!lic->soc->supports_sc7)
> >>>>>>> + /* Disable COP interrupts if SC7 is
> >>>>>>> not supported */
> >>>>>> All Tegra SoCs support SC7, hence the 'supports_sc7' and the
> >>>>>> comment doesn't sound correct to me. Something like
> >>>>>> 'firmware_sc7' should suit better here.
> >>>>> If what you're saying is true, then the whole patch is wrong,
> >>>>> and the SC7 property should come from DT.
> >>>> It should be safe to assume that all of existing Tegra210
> >>>> devices use the firmware for SC7, hence I wouldn't say that the
> >>>> patch is entirely wrong. To me it's not entirely correct.
> >>> Yes, all existing Tegra210 platforms uses sc7 entry firmware for
> >>> SC7 and AVP/COP IRQ need to be kept enabled as during suspend ATF
> >>> triggers IRQ to COP for SC7 entry fw execution.
> > Okay, as I already wrote before, it looks to me that a more proper
> > solution should be to just remove everything related to COP from
> > this driver instead of adding custom quirks for T210.
> >
> > The disabling / restoring of COP interrupts should be relevant only
> > for the multimedia firmware on older Tegra SoCs. That firmware
> > won't be ever supported in the upstream simply because NVIDIA
> > abandoned the support for older hardware in the downstream and
> > because it is not possible due to some legal weirdness (IIUC). The
> > only variant for upstream is reverse-engineering of hardware (not
> > the firmware BLOB) and writing proper opensource drivers for the
> > upstream kernel, which we're already doing and have success to a
> > some extent.
> >> That's not the question. Dmitry says that the SC7 support is not a
> >> property of the SoC, but mostly a platform decision on whether the
> >> firmware supports SC7 or not.
> >>
> >> To me, that's a clear indication that this should not be hardcoded
> >> in the driver, but instead obtained dynamically, via DT or
> >> otherwise.
> > We already have an nvidia,suspend-mode property in the device-tree
> > of the Power Management Controller node (all Tegra SoCs) which
> > defines what suspending type is supported by a particular board.
> >
> >>>>>>> + writel_relaxed(~0ul, ictlr +
> >>>>>>> ICTLR_COP_IER_CLR);
> >>>>>> Secondly, I'm also not sure why COP interrupts need to be
> >>>>>> disabled for pre-T210 at all, since COP is unused. This looks
> >>>>>> to me like it was cut-n-pasted from downstream kernel without
> >>>>>> a good reason and could be simply removed.
> >>>>> Please verify that this is actually the case. Tegra-2
> >>>>> definitely needed some level of poking, and I'm not keen on
> >>>>> changing anything there until you (or someone else) has
> >>>>> verified it on actual HW (see e307cc8941fc).
> >>>> Tested on Tegra20 and Tegra30, LP1 suspend-resume works
> >>>> perfectly fine with all COP bits removed from the driver.
> >>>>
> >>>> AFAIK, the reason why downstream needed that disabling is that
> >>>> it uses proprietary firmware which is running on the COP and
> >>>> that firmware is usually a BLOB audio/video DEC-ENC driver which
> >>>> doesn't cleanup interrupts after itself. That firmware is not
> >>>> applicable for the upstream kernel, hence there is no need to
> >>>> care about it.
> >>>>> Joseph, can you please shed some light here?
> >>> SC7 entry flow uses 3rd party ATF (arm-trusted FW) blob which is
> >>> the one that actually loads SC7 entry firmware and triggers IRQ to
> >>> AVP/COP which causes COP to wakeup and run SC7 entry FW.
> >>>
> >>> So when SC7 support is enabled, IRQ need to be kept enabled and
> >>> when SC7 FW starts execution, it will disable COP IRQ.
> >> This looks like a lot of undocumented assumptions on what firmware
> >> does, as well as what firmware *is*. What I gather from this
> >> thread is that there is at least two versions of firmware (a
> >> "proprietary firmware" for "downstream kernels", and another one
> >> for mainline), and that they do different things.
> >>
> >> Given that we cannot know what people actually run, I don't think
> >> we can safely remove anything unless this gets tested on the full
> >> spectrum of HW/FW combination.
> > I'm not sure whether multiple firmware variations exist in the wild
> > for Tegra210. Maybe Sowjanya or somebody else from NVIDIA could
> > clarify. I think there should be some efforts in regards to a fully
> > opensource firmware on Tegra210, but I'm not following it and have
> > no idea about the status.
> >
> > You're right that there are multiple variants of suspend-resuming
> > flow on Tegra SoCs. The older 32bit Tegra SoC generations have a
> > variety of options in regards to suspend-resuming, including
> > firmware-less variants on platforms that are having kernel running
> > in secure mode (dev boards, most of Tegra20 consumer devices) and
> > Trusted-Foundations firmware variant for insecure platforms
> > (consumer devices). And yes, vendor firmware creates a lot of
> > headache in regards to bringing support into upstream because it
> > usually does a lot of odd undocumented things which may also vary
> > depending on a firmware version (bootloader, etc) and it also
> > usually difficult to replace it with an opensource alternative due
> > to a crypto signing.
>
> Tried without this patch which keeps COP IRQ disabled and I see SC7
> entry FW execution happens still.
>
> Digging through the ATF FW code, I see on SC7 entry firmware loading
> into IRAM, COP processor is reset with RESET VECTOR set to SC7 entry
> firmware location in IRAM and on reset de-assert & unhalt COP, SC7
> firmware starts execution.
>
> Will remove this patch in next version...
>
Good, sounds like you also verified that SC7 COP firmware doesn't use
interrupts.
^ permalink raw reply
* Re: [PATCH 00/18] ARM: Add minimal Raspberry Pi 4 support
From: Stefan Wahren @ 2019-07-25 22:09 UTC (permalink / raw)
To: Nicolas Saenz Julienne, Christoph Hellwig
Cc: Eric Anholt, Florian Fainelli, Ray Jui, Scott Branden,
Matthias Brugger, Rob Herring, Mark Rutland, Linus Walleij,
Michael Turquette, Stephen Boyd, Ulf Hansson, Adrian Hunter,
bcm-kernel-feedback-list, linux-arm-kernel, linux-rpi-kernel,
linux-gpio, linux-mmc
In-Reply-To: <c642de0a85d67f7f758735f1bba083156cca0ddb.camel@suse.de>
Am 25.07.19 um 10:22 schrieb Nicolas Saenz Julienne:
>>>> Any thoughts on this?
>>>>
>>>> diff --git a/arch/arm/mach-bcm/Kconfig b/arch/arm/mach-bcm/Kconfig
>>>> index 5e5f1fabc3d4..3db8deed83a6 100644
>>>> --- a/arch/arm/mach-bcm/Kconfig
>>>> +++ b/arch/arm/mach-bcm/Kconfig
>>>> @@ -168,6 +168,7 @@ config ARCH_BCM2835
>>>> select PINCTRL
>>>> select PINCTRL_BCM2835
>>>> select MFD_CORE
>>>> + select DMABOUNCE
>>>> help
>>>> This enables support for the Broadcom BCM2835 and BCM2836 SoCs.
>>>> This SoC is used in the Raspberry Pi and Roku 2 devices.
>>>> diff --git a/arch/arm/mach-bcm/board_bcm2835.c b/arch/arm/mach-
>>>> bcm/board_bcm2835.c
>>>> index c09cf25596af..be788849c4bb 100644
>>>> --- a/arch/arm/mach-bcm/board_bcm2835.c
>>>> +++ b/arch/arm/mach-bcm/board_bcm2835.c
>>>> @@ -3,6 +3,8 @@
>>>> * Copyright (C) 2010 Broadcom
>>>> */
>>>>
>>>> +#include <linux/device.h>
>>>> +#include <linux/dma-mapping.h>
>>>> #include <linux/init.h>
>>>> #include <linux/irqchip.h>
>>>> #include <linux/of_address.h>
>>>> @@ -24,8 +26,37 @@ static const char * const bcm2835_compat[] = {
>>>> NULL
>>>> };
>>>>
>>>> +static int bcm2835_needs_bounce(struct device *dev, dma_addr_t dma_addr,
>>>> size_t size)
>>>> +{
>>>> + /*
>>>> + * The accepted dma addresses are [0xc0000000, 0xffffffff] which
>>>> map
>>>> to
>>>> + * ram's [0x00000000, 0x3fffffff].
>>>> + */
>>>> + return dma_addr < 3ULL * SZ_1G;
>>>> +}
>>>> +
>>>> +/*
>>>> + * Setup DMA mask to 1GB on devices hanging from soc interconnect
>>>> + */
>>>> +static int bcm2835_platform_notify(struct device *dev)
>>>> +{
>>>> + if (dev->parent && !strcmp("soc", dev_name(dev->parent))) {
>>>> + dev->dma_mask = &dev->coherent_dma_mask;
>>>> + dev->coherent_dma_mask = DMA_BIT_MASK(30); /* 1GB */
>>> Shouldn't this come from the device tree?
>> Yes, actually I could use the 'dma-ranges' parsing code I suggested on the
>> arm64 RFC. The same goes with 'dma_zone_size = SZ_1G', it ideally should be
>> calculated based on the device-tree.
>>
>> The way I see it I'm not sure it's worth the effort, in arm64 we have no
>> choice
>> as there are no board files. But here we seem to be the only ones with this
>> specific DMA addressing constraint, so fixing it in arm/common doesn't seem
>> like it's going to benefit anyone else. Let's see how the arm arch maintainers
>> react though.
>>
>> There is one catch though. I missed it earlier as I was excited to see the
>> board boot, but some devices are failing to set their DMA masks:
>>
>> [ 1.989576] dwc2 fe980000.usb: can't set coherent DMA mask: -5
>>
>> It seems that other users of dmabounce also implement their own
>> dma_supported(). I have to look into it.
> Sadly it seems there are some limitations in dmabounce I didn't take into
> account earlier. Among other things it can't deal with HighMem out of the box
> and even when trying to adapt it to our needs, fails to do so as it allocates
> using GFP_ATOMIC, which rules out using the CMA when allocating coherent
> memory. Sorry for the noise, I got carried away too soon.
>
> I did a dirty hack hooking up dma-direct/swiotlb to the board. It seems to be
> working fine after some tweaks in arm's dma_capable(). That said I want to test
> it further before sending anything ;).
>
Take your time.
But please inform about possible modifications to the devicetree. I will
sent out V2 of my series in a few days.
^ permalink raw reply
* Re: [PATCH] pinctrl: qcom: Pass irqchip when adding gpiochip
From: Lina Iyer @ 2019-07-25 15:16 UTC (permalink / raw)
To: Bjorn Andersson; +Cc: Linus Walleij, linux-gpio, Thierry Reding
In-Reply-To: <20190724200007.GO7234@tuxbook-pro>
On Wed, Jul 24 2019 at 14:00 -0600, Bjorn Andersson wrote:
>On Wed 24 Jul 01:38 PDT 2019, Linus Walleij wrote:
>
>> We need to convert all old gpio irqchips to pass the irqchip
>> setup along when adding the gpio_chip.
>
>Could you please elaborate on why we have this need?
>
>>
>> For chained irqchips this is a pretty straight-forward
>> conversion.
>>
>> Cc: Bjorn Andersson <bjorn.andersson@linaro.org>
>> Cc: Thierry Reding <treding@nvidia.com>
>> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
>> ---
>> drivers/pinctrl/qcom/pinctrl-msm.c | 27 +++++++++++++--------------
>> 1 file changed, 13 insertions(+), 14 deletions(-)
>>
>> diff --git a/drivers/pinctrl/qcom/pinctrl-msm.c b/drivers/pinctrl/qcom/pinctrl-msm.c
>> index 7f35c196bb3e..73062e329f6f 100644
>> --- a/drivers/pinctrl/qcom/pinctrl-msm.c
>> +++ b/drivers/pinctrl/qcom/pinctrl-msm.c
>> @@ -1002,6 +1002,7 @@ static bool msm_gpio_needs_valid_mask(struct msm_pinctrl *pctrl)
>> static int msm_gpio_init(struct msm_pinctrl *pctrl)
>> {
>> struct gpio_chip *chip;
>> + struct gpio_irq_chip *girq;
>> int ret;
>> unsigned ngpio = pctrl->soc->ngpios;
>>
>> @@ -1027,6 +1028,18 @@ static int msm_gpio_init(struct msm_pinctrl *pctrl)
>> pctrl->irq_chip.irq_request_resources = msm_gpio_irq_reqres;
>> pctrl->irq_chip.irq_release_resources = msm_gpio_irq_relres;
>>
>> + girq = &chip->irq;
>> + girq->chip = &pctrl->irq_chip;
>> + girq->parent_handler = msm_gpio_irq_handler;
>> + girq->num_parents = 1;
>> + girq->parents = devm_kcalloc(pctrl->dev, 1, sizeof(*girq->parents),
>> + GFP_KERNEL);
>> + if (!girq->parents)
>> + return -ENOMEM;
>> + girq->default_type = IRQ_TYPE_NONE;
>> + girq->handler = handle_bad_irq;
>
>It's been a while since i poked at this, but I think it's fine to change
>this from handle_edge_irq to handle_bad_irq.
>
>
>So this change does looks like a nice cleanup to me, but adding Lina wrt
>her PDC integration patch series.
>
Thanks Bjorn.
I had something similar in mind [1] as part of my series reworked on top
of Linus's GPIO hierarchy series. This patch is not far from it.
Thanks,
Lina
[1].
https://github.com/i-lina/linux/commit/f88c3fca1739eebdd8111d9baeaf048c9f957473
>Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
>
>Regards,
>Bjorn
>
>> + girq->parents[0] = pctrl->irq;
>> +
>> ret = gpiochip_add_data(&pctrl->chip, pctrl);
>> if (ret) {
>> dev_err(pctrl->dev, "Failed register gpiochip\n");
>> @@ -1053,20 +1066,6 @@ static int msm_gpio_init(struct msm_pinctrl *pctrl)
>> }
>> }
>>
>> - ret = gpiochip_irqchip_add(chip,
>> - &pctrl->irq_chip,
>> - 0,
>> - handle_edge_irq,
>> - IRQ_TYPE_NONE);
>> - if (ret) {
>> - dev_err(pctrl->dev, "Failed to add irqchip to gpiochip\n");
>> - gpiochip_remove(&pctrl->chip);
>> - return -ENOSYS;
>> - }
>> -
>> - gpiochip_set_chained_irqchip(chip, &pctrl->irq_chip, pctrl->irq,
>> - msm_gpio_irq_handler);
>> -
>> return 0;
>> }
>>
>> --
>> 2.21.0
>>
^ permalink raw reply
* [PATCH] pinctrl: oxnas: remove set but not used variable 'arg'
From: YueHaibing @ 2019-07-25 14:24 UTC (permalink / raw)
To: linus.walleij, narmstrong
Cc: linux-kernel, linux-oxnas, linux-arm-kernel, linux-gpio,
YueHaibing
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/pinctrl/pinctrl-oxnas.c: In function oxnas_ox810se_pinconf_set:
drivers/pinctrl/pinctrl-oxnas.c:905:6: warning: variable arg set but not used [-Wunused-but-set-variable]
drivers/pinctrl/pinctrl-oxnas.c: In function oxnas_ox820_pinconf_set:
drivers/pinctrl/pinctrl-oxnas.c:944:6: warning: variable arg set but not used [-Wunused-but-set-variable]
It is never used since commit 4b0c0c25fa79 ("pinctrl:
oxnas: Add support for OX820"), so can be removed.
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
drivers/pinctrl/pinctrl-oxnas.c | 4 ----
1 file changed, 4 deletions(-)
diff --git a/drivers/pinctrl/pinctrl-oxnas.c b/drivers/pinctrl/pinctrl-oxnas.c
index b4edbe0..fa81a09 100644
--- a/drivers/pinctrl/pinctrl-oxnas.c
+++ b/drivers/pinctrl/pinctrl-oxnas.c
@@ -902,7 +902,6 @@ static int oxnas_ox810se_pinconf_set(struct pinctrl_dev *pctldev,
struct oxnas_pinctrl *pctl = pinctrl_dev_get_drvdata(pctldev);
struct oxnas_gpio_bank *bank = pctl_to_bank(pctl, pin);
unsigned int param;
- u32 arg;
unsigned int i;
u32 offset = pin - bank->gpio_chip.base;
u32 mask = BIT(offset);
@@ -912,7 +911,6 @@ static int oxnas_ox810se_pinconf_set(struct pinctrl_dev *pctldev,
for (i = 0; i < num_configs; i++) {
param = pinconf_to_config_param(configs[i]);
- arg = pinconf_to_config_argument(configs[i]);
switch (param) {
case PIN_CONFIG_BIAS_PULL_UP:
@@ -941,7 +939,6 @@ static int oxnas_ox820_pinconf_set(struct pinctrl_dev *pctldev,
struct oxnas_gpio_bank *bank = pctl_to_bank(pctl, pin);
unsigned int bank_offset = (bank->id ? PINMUX_820_BANK_OFFSET : 0);
unsigned int param;
- u32 arg;
unsigned int i;
u32 offset = pin - bank->gpio_chip.base;
u32 mask = BIT(offset);
@@ -951,7 +948,6 @@ static int oxnas_ox820_pinconf_set(struct pinctrl_dev *pctldev,
for (i = 0; i < num_configs; i++) {
param = pinconf_to_config_param(configs[i]);
- arg = pinconf_to_config_argument(configs[i]);
switch (param) {
case PIN_CONFIG_BIAS_PULL_UP:
--
2.7.4
^ permalink raw reply related
* [PATCH] gpio: mockup: don't depend twice on GPIOLIB
From: Uwe Kleine-König @ 2019-07-25 13:10 UTC (permalink / raw)
To: Linus Walleij, Bartosz Golaszewski; +Cc: linux-gpio
config GPIO_MOCKUP is defined in a big if GPIOLIB ... endif block so it
doesn't need to depend explicitly on GPIOLIB.
Signed-off-by: Uwe Kleine-König <uwe@kleine-koenig.org>
---
drivers/gpio/Kconfig | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index bb13c266c329..856fcd260ba2 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -1465,7 +1465,6 @@ endmenu
config GPIO_MOCKUP
tristate "GPIO Testing Driver"
- depends on GPIOLIB
select IRQ_SIM
help
This enables GPIO Testing driver, which provides a way to test GPIO
--
2.20.1
^ permalink raw reply related
* Re: [PATCH v4 7/8] dt-bindings: arm: sunxi: add binding for Lichee Zero Plus core board
From: Maxime Ripard @ 2019-07-24 14:14 UTC (permalink / raw)
To: Icenowy Zheng
Cc: devicetree, Linus Walleij, linux-kernel, linux-gpio, linux-sunxi,
Rob Herring, Chen-Yu Tsai, linux-clk, linux-arm-kernel
In-Reply-To: <7d24576697521f4985617113dbc4cc41@aosc.io>
On Wed, Jul 24, 2019 at 09:09:01PM +0800, Icenowy Zheng wrote:
> 在 2019-07-23 03:29，Maxime Ripard 写道：
> > On Sat, Jul 20, 2019 at 07:39:08PM +0800, Icenowy Zheng wrote:
> > >
> > >
> > > 于 2019年7月20日 GMT+08:00 下午6:13:18, Maxime Ripard
> > > <maxime.ripard@bootlin.com> 写到:
> > > >On Sat, Jul 13, 2019 at 11:46:33AM +0800, Icenowy Zheng wrote:
> > > >> The Lichee Zero Plus is a core board made by Sipeed, with a microUSB
> > > >> connector on it, TF slot or WSON8 SD chip, optional eMMC or SPI
> > > >Flash.
> > > >> It has a gold finger connector for expansion, and UART is available
> > > >from
> > > >> reserved pins w/ 2.54mm pitch. The board can use either SoChip S3 or
> > > >> Allwinner V3L SoCs.
> > > >>
> > > >> Add the device tree binding of the basic version of the core board --
> > > >> w/o eMMC or SPI Flash, w/ TF slot or WSON8 SD, and use S3 SoC.
> > > >>
> > > >> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
> > > >> ---
> > > >> No changes since v3.
> > > >>
> > > >> Patch introduced in v2.
> > > >>
> > > >> Documentation/devicetree/bindings/arm/sunxi.yaml | 5 +++++
> > > >> 1 file changed, 5 insertions(+)
> > > >>
> > > >> diff --git a/Documentation/devicetree/bindings/arm/sunxi.yaml
> > > >b/Documentation/devicetree/bindings/arm/sunxi.yaml
> > > >> index 000a00d12d6a..48c126a7a848 100644
> > > >> --- a/Documentation/devicetree/bindings/arm/sunxi.yaml
> > > >> +++ b/Documentation/devicetree/bindings/arm/sunxi.yaml
> > > >> @@ -353,6 +353,11 @@ properties:
> > > >> - const: licheepi,licheepi-zero
> > > >> - const: allwinner,sun8i-v3s
> > > >>
> > > >> + - description: Lichee Zero Plus (with S3, without eMMC/SPI
> > > >Flash)
> > > >> + items:
> > > >> + - const: sipeed,lichee-zero-plus
> > > >> + - const: allwinner,sun8i-s3
> > > >
> > > >If the S3 is just a rebranded V3, then we should have the v3 compatile
> > > >in that list too.
> > >
> > > S3 is V3 with copackaged DDR3 DRAM.
> > >
> > > It's pin incompatible w/ V3.
> >
> > Does it matter though?
> >
> > If the only thing that changes is the package, we're not manipulating
> > that, and any software that deals with the v3 can deal with the
> > s3. Which is what the compatible is about.
>
> Okay. Should the S3 compatible be kept befoer the V3 one?
Yep, something like (in the DT)
compatible = "sipeed,lichee-zero-plus", "allwinner,sun8i-s3", "allwinner,sun8i-v3"
Maxime
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* [PATCH] pinctrl: stmfx: update pinconf settings
From: Amelie Delaunay @ 2019-07-25 11:16 UTC (permalink / raw)
To: Linus Walleij, Alexandre Torgue, Maxime Coquelin
Cc: linux-gpio, linux-kernel, linux-arm-kernel, linux-stm32,
Amelie Delaunay
From: Alexandre Torgue <alexandre.torgue@st.com>
According to the following tab (coming from STMFX datasheet), updates
have to done in stmfx_pinconf_set function:
-"type" has to be set when "bias" is configured as "pull-up or pull-down"
-PIN_CONFIG_DRIVE_PUSH_PULL should only be used when gpio is configured as
output. There is so no need to check direction.
DIR | TYPE | PUPD | MFX GPIO configuration
----|------|------|---------------------------------------------------
1 | 1 | 1 | OUTPUT open drain with internal pull-up resistor
----|------|------|---------------------------------------------------
1 | 1 | 0 | OUTPUT open drain with internal pull-down resistor
----|------|------|---------------------------------------------------
1 | 0 | 0/1 | OUTPUT push pull no pull
----|------|------|---------------------------------------------------
0 | 1 | 1 | INPUT with internal pull-up resistor
----|------|------|---------------------------------------------------
0 | 1 | 0 | INPUT with internal pull-down resistor
----|------|------|---------------------------------------------------
0 | 0 | 1 | INPUT floating
----|------|------|---------------------------------------------------
0 | 0 | 0 | analog (GPIO not used, default setting)
Signed-off-by: Alexandre Torgue <alexandre.torgue@st.com>
Signed-off-by: Amelie Delaunay <amelie.delaunay@st.com>
---
drivers/pinctrl/pinctrl-stmfx.c | 24 ++++++++++++------------
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/pinctrl/pinctrl-stmfx.c b/drivers/pinctrl/pinctrl-stmfx.c
index d3332da..31b6e51 100644
--- a/drivers/pinctrl/pinctrl-stmfx.c
+++ b/drivers/pinctrl/pinctrl-stmfx.c
@@ -296,29 +296,29 @@ static int stmfx_pinconf_set(struct pinctrl_dev *pctldev, unsigned int pin,
switch (param) {
case PIN_CONFIG_BIAS_PULL_PIN_DEFAULT:
case PIN_CONFIG_BIAS_DISABLE:
+ case PIN_CONFIG_DRIVE_PUSH_PULL:
+ ret = stmfx_pinconf_set_type(pctl, pin, 0);
+ if (ret)
+ return ret;
+ break;
case PIN_CONFIG_BIAS_PULL_DOWN:
+ ret = stmfx_pinconf_set_type(pctl, pin, 1);
+ if (ret)
+ return ret;
ret = stmfx_pinconf_set_pupd(pctl, pin, 0);
if (ret)
return ret;
break;
case PIN_CONFIG_BIAS_PULL_UP:
- ret = stmfx_pinconf_set_pupd(pctl, pin, 1);
+ ret = stmfx_pinconf_set_type(pctl, pin, 1);
if (ret)
return ret;
- break;
- case PIN_CONFIG_DRIVE_OPEN_DRAIN:
- if (!dir)
- ret = stmfx_pinconf_set_type(pctl, pin, 1);
- else
- ret = stmfx_pinconf_set_type(pctl, pin, 0);
+ ret = stmfx_pinconf_set_pupd(pctl, pin, 1);
if (ret)
return ret;
break;
- case PIN_CONFIG_DRIVE_PUSH_PULL:
- if (!dir)
- ret = stmfx_pinconf_set_type(pctl, pin, 0);
- else
- ret = stmfx_pinconf_set_type(pctl, pin, 1);
+ case PIN_CONFIG_DRIVE_OPEN_DRAIN:
+ ret = stmfx_pinconf_set_type(pctl, pin, 1);
if (ret)
return ret;
break;
--
2.7.4
^ permalink raw reply related
* Re: [PATCH V6 01/21] irqchip: tegra: Do not disable COP IRQ during suspend
From: Dmitry Osipenko @ 2019-07-25 10:59 UTC (permalink / raw)
To: Peter De Schrijver
Cc: Sowjanya Komatineni, thierry.reding, jonathanh, tglx, jason,
marc.zyngier, linus.walleij, stefan, mark.rutland, pgaikwad,
sboyd, linux-clk, linux-gpio, jckuo, josephl, talho, linux-tegra,
linux-kernel, mperttunen, spatra, robh+dt, devicetree
In-Reply-To: <20190725103813.GO12715@pdeschrijver-desktop.Nvidia.com>
25.07.2019 13:38, Peter De Schrijver пишет:
> On Thu, Jul 25, 2019 at 01:33:48PM +0300, Peter De Schrijver wrote:
>> On Thu, Jul 25, 2019 at 01:05:13PM +0300, Dmitry Osipenko wrote:
>>> 25.07.2019 12:55, Peter De Schrijver пишет:
>>>> On Mon, Jul 22, 2019 at 12:54:51PM +0300, Dmitry Osipenko wrote:
>>>>>
>>>>> All Tegra SoCs support SC7, hence the 'supports_sc7' and the comment
>>>>> doesn't sound correct to me. Something like 'firmware_sc7' should suit
>>>>> better here.
>>>>>
>>>>>> + writel_relaxed(~0ul, ictlr + ICTLR_COP_IER_CLR);
>>>>>
>>>>> Secondly, I'm also not sure why COP interrupts need to be disabled for
>>>>> pre-T210 at all, since COP is unused. This looks to me like it was
>>>>> cut-n-pasted from downstream kernel without a good reason and could be
>>>>> simply removed.
>>>>
>>>> I don't think we can rely on the fact that COP is unused. People can
>>>> write their own code to run on COP.
>>>
>>> 1. Not upstream - doesn't matter.
>>>
>>
>> The code is not part of the kernel, so obviously it's not upstream?
>>
>>> 2. That's not very good if something unknown is running on COP and then
>>> kernel suddenly intervenes, don't you think so?
>>
>> Unless the code was written with this in mind.
>>
In that case, please see 1. ;)
>
> Looking at this again, I don't think we need to enable the IRQ at all.
Could you please clarify? The code only saves/restores COP's interrupts
context across suspend-resume.
Again, that's absolutely useless code for the upstream kernel which
could be removed safely to avoid the confusion, IMHO. I can type a patch
if you're agreeing.
^ permalink raw reply
* Re: [PATCH V6 01/21] irqchip: tegra: Do not disable COP IRQ during suspend
From: Peter De Schrijver @ 2019-07-25 10:38 UTC (permalink / raw)
To: Dmitry Osipenko
Cc: Sowjanya Komatineni, thierry.reding, jonathanh, tglx, jason,
marc.zyngier, linus.walleij, stefan, mark.rutland, pgaikwad,
sboyd, linux-clk, linux-gpio, jckuo, josephl, talho, linux-tegra,
linux-kernel, mperttunen, spatra, robh+dt, devicetree
In-Reply-To: <20190725103348.GN12715@pdeschrijver-desktop.Nvidia.com>
On Thu, Jul 25, 2019 at 01:33:48PM +0300, Peter De Schrijver wrote:
> On Thu, Jul 25, 2019 at 01:05:13PM +0300, Dmitry Osipenko wrote:
> > 25.07.2019 12:55, Peter De Schrijver пишет:
> > > On Mon, Jul 22, 2019 at 12:54:51PM +0300, Dmitry Osipenko wrote:
> > >>
> > >> All Tegra SoCs support SC7, hence the 'supports_sc7' and the comment
> > >> doesn't sound correct to me. Something like 'firmware_sc7' should suit
> > >> better here.
> > >>
> > >>> + writel_relaxed(~0ul, ictlr + ICTLR_COP_IER_CLR);
> > >>
> > >> Secondly, I'm also not sure why COP interrupts need to be disabled for
> > >> pre-T210 at all, since COP is unused. This looks to me like it was
> > >> cut-n-pasted from downstream kernel without a good reason and could be
> > >> simply removed.
> > >
> > > I don't think we can rely on the fact that COP is unused. People can
> > > write their own code to run on COP.
> >
> > 1. Not upstream - doesn't matter.
> >
>
> The code is not part of the kernel, so obviously it's not upstream?
>
> > 2. That's not very good if something unknown is running on COP and then
> > kernel suddenly intervenes, don't you think so?
>
> Unless the code was written with this in mind.
>
Looking at this again, I don't think we need to enable the IRQ at all.
Peter.
^ permalink raw reply
* Re: [PATCH V6 01/21] irqchip: tegra: Do not disable COP IRQ during suspend
From: Peter De Schrijver @ 2019-07-25 10:33 UTC (permalink / raw)
To: Dmitry Osipenko
Cc: Sowjanya Komatineni, thierry.reding, jonathanh, tglx, jason,
marc.zyngier, linus.walleij, stefan, mark.rutland, pgaikwad,
sboyd, linux-clk, linux-gpio, jckuo, josephl, talho, linux-tegra,
linux-kernel, mperttunen, spatra, robh+dt, devicetree
In-Reply-To: <dd01be5d-bab9-1329-c7ac-c3c893d49dd1@gmail.com>
On Thu, Jul 25, 2019 at 01:05:13PM +0300, Dmitry Osipenko wrote:
> 25.07.2019 12:55, Peter De Schrijver пишет:
> > On Mon, Jul 22, 2019 at 12:54:51PM +0300, Dmitry Osipenko wrote:
> >>
> >> All Tegra SoCs support SC7, hence the 'supports_sc7' and the comment
> >> doesn't sound correct to me. Something like 'firmware_sc7' should suit
> >> better here.
> >>
> >>> + writel_relaxed(~0ul, ictlr + ICTLR_COP_IER_CLR);
> >>
> >> Secondly, I'm also not sure why COP interrupts need to be disabled for
> >> pre-T210 at all, since COP is unused. This looks to me like it was
> >> cut-n-pasted from downstream kernel without a good reason and could be
> >> simply removed.
> >
> > I don't think we can rely on the fact that COP is unused. People can
> > write their own code to run on COP.
>
> 1. Not upstream - doesn't matter.
>
The code is not part of the kernel, so obviously it's not upstream?
> 2. That's not very good if something unknown is running on COP and then
> kernel suddenly intervenes, don't you think so?
Unless the code was written with this in mind.
Peter.
^ permalink raw reply
* Re: [PATCH V6 01/21] irqchip: tegra: Do not disable COP IRQ during suspend
From: Dmitry Osipenko @ 2019-07-25 10:05 UTC (permalink / raw)
To: Peter De Schrijver
Cc: Sowjanya Komatineni, thierry.reding, jonathanh, tglx, jason,
marc.zyngier, linus.walleij, stefan, mark.rutland, pgaikwad,
sboyd, linux-clk, linux-gpio, jckuo, josephl, talho, linux-tegra,
linux-kernel, mperttunen, spatra, robh+dt, devicetree
In-Reply-To: <20190725095502.GM12715@pdeschrijver-desktop.Nvidia.com>
25.07.2019 12:55, Peter De Schrijver пишет:
> On Mon, Jul 22, 2019 at 12:54:51PM +0300, Dmitry Osipenko wrote:
>>
>> All Tegra SoCs support SC7, hence the 'supports_sc7' and the comment
>> doesn't sound correct to me. Something like 'firmware_sc7' should suit
>> better here.
>>
>>> + writel_relaxed(~0ul, ictlr + ICTLR_COP_IER_CLR);
>>
>> Secondly, I'm also not sure why COP interrupts need to be disabled for
>> pre-T210 at all, since COP is unused. This looks to me like it was
>> cut-n-pasted from downstream kernel without a good reason and could be
>> simply removed.
>
> I don't think we can rely on the fact that COP is unused. People can
> write their own code to run on COP.
1. Not upstream - doesn't matter.
2. That's not very good if something unknown is running on COP and then
kernel suddenly intervenes, don't you think so?
^ permalink raw reply
* [PATCH 2/2] pinctrl: sprd: Combine the condition of MISC_PIN and COMMON_PIN
From: Baolin Wang @ 2019-07-25 9:56 UTC (permalink / raw)
To: linus.walleij, orsonzhai, zhang.lyra
Cc: baolin.wang, vincent.guittot, linux-gpio, linux-kernel
In-Reply-To: <ff410d312ed0047b5a36e5113daf7df78bcf1aa8.1564048446.git.baolin.wang@linaro.org>
Since the follow-up pin design on Spreadtrum platform has some changes,
some configuration of MISC_PIN moved to COMMON_PIN. To support current
pin design and keep backward compatibility, we should combine the
condition of MISC_PIN and COMMON_PIN to configure an individual pin.
Signed-off-by: Baolin Wang <baolin.wang@linaro.org>
---
drivers/pinctrl/sprd/pinctrl-sprd.c | 19 ++-----------------
1 file changed, 2 insertions(+), 17 deletions(-)
diff --git a/drivers/pinctrl/sprd/pinctrl-sprd.c b/drivers/pinctrl/sprd/pinctrl-sprd.c
index a32e809..5d40bab 100644
--- a/drivers/pinctrl/sprd/pinctrl-sprd.c
+++ b/drivers/pinctrl/sprd/pinctrl-sprd.c
@@ -454,7 +454,7 @@ static int sprd_pinconf_get(struct pinctrl_dev *pctldev, unsigned int pin_id,
if (pin->type == GLOBAL_CTRL_PIN &&
param == SPRD_PIN_CONFIG_CONTROL) {
arg = reg;
- } else if (pin->type == COMMON_PIN) {
+ } else if (pin->type == COMMON_PIN || pin->type == MISC_PIN) {
switch (param) {
case SPRD_PIN_CONFIG_SLEEP_MODE:
arg = (reg >> SLEEP_MODE_SHIFT) & SLEEP_MODE_MASK;
@@ -465,14 +465,6 @@ static int sprd_pinconf_get(struct pinctrl_dev *pctldev, unsigned int pin_id,
case PIN_CONFIG_OUTPUT:
arg = reg & SLEEP_OUTPUT_MASK;
break;
- case PIN_CONFIG_SLEEP_HARDWARE_STATE:
- arg = 0;
- break;
- default:
- return -ENOTSUPP;
- }
- } else if (pin->type == MISC_PIN) {
- switch (param) {
case PIN_CONFIG_DRIVE_STRENGTH:
arg = (reg >> DRIVE_STRENGTH_SHIFT) &
DRIVE_STRENGTH_MASK;
@@ -606,7 +598,7 @@ static int sprd_pinconf_set(struct pinctrl_dev *pctldev, unsigned int pin_id,
if (pin->type == GLOBAL_CTRL_PIN &&
param == SPRD_PIN_CONFIG_CONTROL) {
val = arg;
- } else if (pin->type == COMMON_PIN) {
+ } else if (pin->type == COMMON_PIN || pin->type == MISC_PIN) {
switch (param) {
case SPRD_PIN_CONFIG_SLEEP_MODE:
if (arg & AP_SLEEP)
@@ -639,13 +631,6 @@ static int sprd_pinconf_set(struct pinctrl_dev *pctldev, unsigned int pin_id,
shift = SLEEP_OUTPUT_SHIFT;
}
break;
- case PIN_CONFIG_SLEEP_HARDWARE_STATE:
- continue;
- default:
- return -ENOTSUPP;
- }
- } else if (pin->type == MISC_PIN) {
- switch (param) {
case PIN_CONFIG_DRIVE_STRENGTH:
if (arg < 2 || arg > 60)
return -EINVAL;
--
1.7.9.5
^ permalink raw reply related
* [PATCH 1/2] pinctrl: sprd: Change to use devm_platform_ioremap_resource()
From: Baolin Wang @ 2019-07-25 9:56 UTC (permalink / raw)
To: linus.walleij, orsonzhai, zhang.lyra
Cc: baolin.wang, vincent.guittot, linux-gpio, linux-kernel
The devm_platform_ioremap_resource() function wraps platform_get_resource()
and devm_ioremap_resource() in a single helper, thus use it to simplify
the code.
Signed-off-by: Baolin Wang <baolin.wang@linaro.org>
---
drivers/pinctrl/sprd/pinctrl-sprd.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/pinctrl/sprd/pinctrl-sprd.c b/drivers/pinctrl/sprd/pinctrl-sprd.c
index c31b581..a32e809 100644
--- a/drivers/pinctrl/sprd/pinctrl-sprd.c
+++ b/drivers/pinctrl/sprd/pinctrl-sprd.c
@@ -1020,7 +1020,6 @@ int sprd_pinctrl_core_probe(struct platform_device *pdev,
struct sprd_pinctrl *sprd_pctl;
struct sprd_pinctrl_soc_info *pinctrl_info;
struct pinctrl_pin_desc *pin_desc;
- struct resource *res;
int ret, i;
sprd_pctl = devm_kzalloc(&pdev->dev, sizeof(struct sprd_pinctrl),
@@ -1028,8 +1027,7 @@ int sprd_pinctrl_core_probe(struct platform_device *pdev,
if (!sprd_pctl)
return -ENOMEM;
- res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- sprd_pctl->base = devm_ioremap_resource(&pdev->dev, res);
+ sprd_pctl->base = devm_platform_ioremap_resource(pdev, 0);
if (IS_ERR(sprd_pctl->base))
return PTR_ERR(sprd_pctl->base);
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH V6 01/21] irqchip: tegra: Do not disable COP IRQ during suspend
From: Peter De Schrijver @ 2019-07-25 9:55 UTC (permalink / raw)
To: Dmitry Osipenko
Cc: Sowjanya Komatineni, thierry.reding, jonathanh, tglx, jason,
marc.zyngier, linus.walleij, stefan, mark.rutland, pgaikwad,
sboyd, linux-clk, linux-gpio, jckuo, josephl, talho, linux-tegra,
linux-kernel, mperttunen, spatra, robh+dt, devicetree
In-Reply-To: <f6582e43-168e-1b7e-9db8-3d263bc3ba0d@gmail.com>
On Mon, Jul 22, 2019 at 12:54:51PM +0300, Dmitry Osipenko wrote:
>
> All Tegra SoCs support SC7, hence the 'supports_sc7' and the comment
> doesn't sound correct to me. Something like 'firmware_sc7' should suit
> better here.
>
> > + writel_relaxed(~0ul, ictlr + ICTLR_COP_IER_CLR);
>
> Secondly, I'm also not sure why COP interrupts need to be disabled for
> pre-T210 at all, since COP is unused. This looks to me like it was
> cut-n-pasted from downstream kernel without a good reason and could be
> simply removed.
I don't think we can rely on the fact that COP is unused. People can
write their own code to run on COP.
Peter.
^ permalink raw reply
* Re: [PATCH 00/18] ARM: Add minimal Raspberry Pi 4 support
From: Nicolas Saenz Julienne @ 2019-07-25 8:22 UTC (permalink / raw)
To: Stefan Wahren, Christoph Hellwig
Cc: Eric Anholt, Florian Fainelli, Ray Jui, Scott Branden,
Matthias Brugger, Rob Herring, Mark Rutland, Linus Walleij,
Michael Turquette, Stephen Boyd, Ulf Hansson, Adrian Hunter,
bcm-kernel-feedback-list, linux-arm-kernel, linux-rpi-kernel,
linux-gpio, linux-mmc
In-Reply-To: <5f9b11f54c66fd0487837f7e58af3adf7f86635f.camel@suse.de>
[-- Attachment #1: Type: text/plain, Size: 3455 bytes --]
> > > Any thoughts on this?
> > >
> > > diff --git a/arch/arm/mach-bcm/Kconfig b/arch/arm/mach-bcm/Kconfig
> > > index 5e5f1fabc3d4..3db8deed83a6 100644
> > > --- a/arch/arm/mach-bcm/Kconfig
> > > +++ b/arch/arm/mach-bcm/Kconfig
> > > @@ -168,6 +168,7 @@ config ARCH_BCM2835
> > > select PINCTRL
> > > select PINCTRL_BCM2835
> > > select MFD_CORE
> > > + select DMABOUNCE
> > > help
> > > This enables support for the Broadcom BCM2835 and BCM2836 SoCs.
> > > This SoC is used in the Raspberry Pi and Roku 2 devices.
> > > diff --git a/arch/arm/mach-bcm/board_bcm2835.c b/arch/arm/mach-
> > > bcm/board_bcm2835.c
> > > index c09cf25596af..be788849c4bb 100644
> > > --- a/arch/arm/mach-bcm/board_bcm2835.c
> > > +++ b/arch/arm/mach-bcm/board_bcm2835.c
> > > @@ -3,6 +3,8 @@
> > > * Copyright (C) 2010 Broadcom
> > > */
> > >
> > > +#include <linux/device.h>
> > > +#include <linux/dma-mapping.h>
> > > #include <linux/init.h>
> > > #include <linux/irqchip.h>
> > > #include <linux/of_address.h>
> > > @@ -24,8 +26,37 @@ static const char * const bcm2835_compat[] = {
> > > NULL
> > > };
> > >
> > > +static int bcm2835_needs_bounce(struct device *dev, dma_addr_t dma_addr,
> > > size_t size)
> > > +{
> > > + /*
> > > + * The accepted dma addresses are [0xc0000000, 0xffffffff] which
> > > map
> > > to
> > > + * ram's [0x00000000, 0x3fffffff].
> > > + */
> > > + return dma_addr < 3ULL * SZ_1G;
> > > +}
> > > +
> > > +/*
> > > + * Setup DMA mask to 1GB on devices hanging from soc interconnect
> > > + */
> > > +static int bcm2835_platform_notify(struct device *dev)
> > > +{
> > > + if (dev->parent && !strcmp("soc", dev_name(dev->parent))) {
> > > + dev->dma_mask = &dev->coherent_dma_mask;
> > > + dev->coherent_dma_mask = DMA_BIT_MASK(30); /* 1GB */
> > Shouldn't this come from the device tree?
>
> Yes, actually I could use the 'dma-ranges' parsing code I suggested on the
> arm64 RFC. The same goes with 'dma_zone_size = SZ_1G', it ideally should be
> calculated based on the device-tree.
>
> The way I see it I'm not sure it's worth the effort, in arm64 we have no
> choice
> as there are no board files. But here we seem to be the only ones with this
> specific DMA addressing constraint, so fixing it in arm/common doesn't seem
> like it's going to benefit anyone else. Let's see how the arm arch maintainers
> react though.
>
> There is one catch though. I missed it earlier as I was excited to see the
> board boot, but some devices are failing to set their DMA masks:
>
> [ 1.989576] dwc2 fe980000.usb: can't set coherent DMA mask: -5
>
> It seems that other users of dmabounce also implement their own
> dma_supported(). I have to look into it.
Sadly it seems there are some limitations in dmabounce I didn't take into
account earlier. Among other things it can't deal with HighMem out of the box
and even when trying to adapt it to our needs, fails to do so as it allocates
using GFP_ATOMIC, which rules out using the CMA when allocating coherent
memory. Sorry for the noise, I got carried away too soon.
I did a dirty hack hooking up dma-direct/swiotlb to the board. It seems to be
working fine after some tweaks in arm's dma_capable(). That said I want to test
it further before sending anything ;).
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox