* [PATCH 0/6] Extend mvebu gpio driver to support the controllers of the Marvell Armada 7K/8K
@ 2017-05-19 16:09 ` Gregory CLEMENT
0 siblings, 0 replies; 65+ messages in thread
From: Gregory CLEMENT @ 2017-05-19 16:09 UTC (permalink / raw)
To: Linus Walleij, Alexandre Courbot, linux-gpio, linux-kernel
Cc: Jason Cooper, Andrew Lunn, Sebastian Hesselbarth,
Gregory CLEMENT, Thomas Petazzoni, linux-arm-kernel, Rob Herring,
devicetree, Russell King, Nadav Haklai, Kostya Porotchkin,
Neta Zur Hershkovits, Marcin Wojtas, Omri Itach, Shadi Ammouri
Hi,
This series extends the mvebu gpio driver to support the gpio
controllers found on the Marvell Armada 7K/8K SoCs.
The gpio controllers used on the Marvell Armada 7K/8K SoCs are the
same that the ones used on the ARM32 mvebu SoCs. However, the pinctrl
node in the device tree of theses SoCs are child of a syscon. So the
driver has been converted to use the regamp in patch 2.
Then the remaining patches adds the support for the Armada 7K/8K SoCs.
All the patches can be merged through the gpio subsystem expect the
last that must be go through the mvebu subsystem.
Not that currently I didn't manage to fully test the gpio, indeed I
only have a 7040 DB board which lack of test point for this kind of
test. So any tested-by would be welcome.
Thanks,
Gregory
Gregory CLEMENT (5):
gpio: mvebu: sort header include
gpio: dt-bindings: Add documentation for gpio controllers on Armada 7K/8K
gpio: mvebu: allow building driver for Armada 7K/8K
gpio: mvebu: Add support for the Armada 7K/8K SoCs
arm64: dts: marvell: add gpio support for Armada 7K/8K
Thomas Petazzoni (1):
gpio: mvebu: switch to regmap for register access
Documentation/devicetree/bindings/arm/marvell/ap806-system-controller.txt | 20 +++-
Documentation/devicetree/bindings/arm/marvell/cp110-system-controller0.txt | 24 ++-
Documentation/devicetree/bindings/gpio/gpio-mvebu.txt | 24 ++-
arch/arm64/boot/dts/marvell/armada-70x0.dtsi | 15 ++-
arch/arm64/boot/dts/marvell/armada-80x0.dtsi | 16 ++-
arch/arm64/boot/dts/marvell/armada-ap806.dtsi | 10 +-
arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi | 21 +++-
arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi | 22 +++-
drivers/gpio/Kconfig | 2 +-
drivers/gpio/gpio-mvebu.c | 540 ++++++++++++++++++++++++++++++++++++++++++++----------------------------
10 files changed, 477 insertions(+), 217 deletions(-)
base-commit: 9ad0dc7eff4919523e557edfb2a46c955673d25d
--
git-series 0.9.1
^ permalink raw reply [flat|nested] 65+ messages in thread
* [PATCH 0/6] Extend mvebu gpio driver to support the controllers of the Marvell Armada 7K/8K
@ 2017-05-19 16:09 ` Gregory CLEMENT
0 siblings, 0 replies; 65+ messages in thread
From: Gregory CLEMENT @ 2017-05-19 16:09 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
This series extends the mvebu gpio driver to support the gpio
controllers found on the Marvell Armada 7K/8K SoCs.
The gpio controllers used on the Marvell Armada 7K/8K SoCs are the
same that the ones used on the ARM32 mvebu SoCs. However, the pinctrl
node in the device tree of theses SoCs are child of a syscon. So the
driver has been converted to use the regamp in patch 2.
Then the remaining patches adds the support for the Armada 7K/8K SoCs.
All the patches can be merged through the gpio subsystem expect the
last that must be go through the mvebu subsystem.
Not that currently I didn't manage to fully test the gpio, indeed I
only have a 7040 DB board which lack of test point for this kind of
test. So any tested-by would be welcome.
Thanks,
Gregory
Gregory CLEMENT (5):
gpio: mvebu: sort header include
gpio: dt-bindings: Add documentation for gpio controllers on Armada 7K/8K
gpio: mvebu: allow building driver for Armada 7K/8K
gpio: mvebu: Add support for the Armada 7K/8K SoCs
arm64: dts: marvell: add gpio support for Armada 7K/8K
Thomas Petazzoni (1):
gpio: mvebu: switch to regmap for register access
Documentation/devicetree/bindings/arm/marvell/ap806-system-controller.txt | 20 +++-
Documentation/devicetree/bindings/arm/marvell/cp110-system-controller0.txt | 24 ++-
Documentation/devicetree/bindings/gpio/gpio-mvebu.txt | 24 ++-
arch/arm64/boot/dts/marvell/armada-70x0.dtsi | 15 ++-
arch/arm64/boot/dts/marvell/armada-80x0.dtsi | 16 ++-
arch/arm64/boot/dts/marvell/armada-ap806.dtsi | 10 +-
arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi | 21 +++-
arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi | 22 +++-
drivers/gpio/Kconfig | 2 +-
drivers/gpio/gpio-mvebu.c | 540 ++++++++++++++++++++++++++++++++++++++++++++----------------------------
10 files changed, 477 insertions(+), 217 deletions(-)
base-commit: 9ad0dc7eff4919523e557edfb2a46c955673d25d
--
git-series 0.9.1
^ permalink raw reply [flat|nested] 65+ messages in thread
* [PATCH 1/6] gpio: mvebu: sort header include
2017-05-19 16:09 ` Gregory CLEMENT
@ 2017-05-19 16:09 ` Gregory CLEMENT
-1 siblings, 0 replies; 65+ messages in thread
From: Gregory CLEMENT @ 2017-05-19 16:09 UTC (permalink / raw)
To: Linus Walleij, Alexandre Courbot, linux-gpio, linux-kernel
Cc: Jason Cooper, Andrew Lunn, Sebastian Hesselbarth,
Gregory CLEMENT, Thomas Petazzoni, linux-arm-kernel, Rob Herring,
devicetree, Russell King, Nadav Haklai, Kostya Porotchkin,
Neta Zur Hershkovits, Marcin Wojtas, Omri Itach, Shadi Ammouri
This commit sorts alphabetically the header files.
Reviewed-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
drivers/gpio/gpio-mvebu.c | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/gpio/gpio-mvebu.c b/drivers/gpio/gpio-mvebu.c
index 19a92efabbef..a9e564f3410b 100644
--- a/drivers/gpio/gpio-mvebu.c
+++ b/drivers/gpio/gpio-mvebu.c
@@ -33,21 +33,21 @@
* interrupts.
*/
+#include <linux/bitops.h>
+#include <linux/clk.h>
#include <linux/err.h>
-#include <linux/init.h>
#include <linux/gpio.h>
+#include <linux/init.h>
+#include <linux/io.h>
#include <linux/irq.h>
-#include <linux/slab.h>
+#include <linux/irqchip/chained_irq.h>
#include <linux/irqdomain.h>
-#include <linux/io.h>
-#include <linux/of_irq.h>
#include <linux/of_device.h>
-#include <linux/pwm.h>
-#include <linux/clk.h>
+#include <linux/of_irq.h>
#include <linux/pinctrl/consumer.h>
-#include <linux/irqchip/chained_irq.h>
#include <linux/platform_device.h>
-#include <linux/bitops.h>
+#include <linux/pwm.h>
+#include <linux/slab.h>
#include "gpiolib.h"
--
git-series 0.9.1
^ permalink raw reply related [flat|nested] 65+ messages in thread
* [PATCH 1/6] gpio: mvebu: sort header include
@ 2017-05-19 16:09 ` Gregory CLEMENT
0 siblings, 0 replies; 65+ messages in thread
From: Gregory CLEMENT @ 2017-05-19 16:09 UTC (permalink / raw)
To: linux-arm-kernel
This commit sorts alphabetically the header files.
Reviewed-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
drivers/gpio/gpio-mvebu.c | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/gpio/gpio-mvebu.c b/drivers/gpio/gpio-mvebu.c
index 19a92efabbef..a9e564f3410b 100644
--- a/drivers/gpio/gpio-mvebu.c
+++ b/drivers/gpio/gpio-mvebu.c
@@ -33,21 +33,21 @@
* interrupts.
*/
+#include <linux/bitops.h>
+#include <linux/clk.h>
#include <linux/err.h>
-#include <linux/init.h>
#include <linux/gpio.h>
+#include <linux/init.h>
+#include <linux/io.h>
#include <linux/irq.h>
-#include <linux/slab.h>
+#include <linux/irqchip/chained_irq.h>
#include <linux/irqdomain.h>
-#include <linux/io.h>
-#include <linux/of_irq.h>
#include <linux/of_device.h>
-#include <linux/pwm.h>
-#include <linux/clk.h>
+#include <linux/of_irq.h>
#include <linux/pinctrl/consumer.h>
-#include <linux/irqchip/chained_irq.h>
#include <linux/platform_device.h>
-#include <linux/bitops.h>
+#include <linux/pwm.h>
+#include <linux/slab.h>
#include "gpiolib.h"
--
git-series 0.9.1
^ permalink raw reply related [flat|nested] 65+ messages in thread
* [PATCH 2/6] gpio: mvebu: switch to regmap for register access
2017-05-19 16:09 ` Gregory CLEMENT
@ 2017-05-19 16:09 ` Gregory CLEMENT
-1 siblings, 0 replies; 65+ messages in thread
From: Gregory CLEMENT @ 2017-05-19 16:09 UTC (permalink / raw)
To: Linus Walleij, Alexandre Courbot, linux-gpio, linux-kernel
Cc: Jason Cooper, Andrew Lunn, Sebastian Hesselbarth,
Gregory CLEMENT, Thomas Petazzoni, linux-arm-kernel, Rob Herring,
devicetree, Russell King, Nadav Haklai, Kostya Porotchkin,
Neta Zur Hershkovits, Marcin Wojtas, Omri Itach, Shadi Ammouri
From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
In order to be able to use this driver with the Armada 7K/8K SoCs, we
need to use the regmap to access the registers. Indeed for these new SoCs,
the gpio node will be part of a syscon.
[gregory.clement@free-electrons.com:
- fixed merge conflcit from 4.10 to 4.12-rc1
- added a commit log]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
drivers/gpio/gpio-mvebu.c | 436 +++++++++++++++++++++------------------
1 file changed, 245 insertions(+), 191 deletions(-)
diff --git a/drivers/gpio/gpio-mvebu.c b/drivers/gpio/gpio-mvebu.c
index a9e564f3410b..3d03740a20e7 100644
--- a/drivers/gpio/gpio-mvebu.c
+++ b/drivers/gpio/gpio-mvebu.c
@@ -47,6 +47,7 @@
#include <linux/pinctrl/consumer.h>
#include <linux/platform_device.h>
#include <linux/pwm.h>
+#include <linux/regmap.h>
#include <linux/slab.h>
#include "gpiolib.h"
@@ -106,9 +107,8 @@ struct mvebu_pwm {
struct mvebu_gpio_chip {
struct gpio_chip chip;
- spinlock_t lock;
- void __iomem *membase;
- void __iomem *percpu_membase;
+ struct regmap *regs;
+ struct regmap *percpu_regs;
int irqbase;
struct irq_domain *domain;
int soc_variant;
@@ -130,92 +130,149 @@ struct mvebu_gpio_chip {
* Functions returning addresses of individual registers for a given
* GPIO controller.
*/
-static void __iomem *mvebu_gpioreg_out(struct mvebu_gpio_chip *mvchip)
-{
- return mvchip->membase + GPIO_OUT_OFF;
-}
-static void __iomem *mvebu_gpioreg_blink(struct mvebu_gpio_chip *mvchip)
+static void mvebu_gpioreg_edge_cause(struct mvebu_gpio_chip *mvchip,
+ struct regmap **map, unsigned int *offset)
{
- return mvchip->membase + GPIO_BLINK_EN_OFF;
-}
+ int cpu;
-static void __iomem *mvebu_gpioreg_blink_counter_select(struct mvebu_gpio_chip
- *mvchip)
-{
- return mvchip->membase + GPIO_BLINK_CNT_SELECT_OFF;
+ switch (mvchip->soc_variant) {
+ case MVEBU_GPIO_SOC_VARIANT_ORION:
+ case MVEBU_GPIO_SOC_VARIANT_MV78200:
+ *map = mvchip->regs;
+ *offset = GPIO_EDGE_CAUSE_OFF;
+ break;
+ case MVEBU_GPIO_SOC_VARIANT_ARMADAXP:
+ cpu = smp_processor_id();
+ *map = mvchip->percpu_regs;
+ *offset = GPIO_EDGE_CAUSE_ARMADAXP_OFF(cpu);
+ break;
+ default:
+ BUG();
+ }
}
-static void __iomem *mvebu_gpioreg_io_conf(struct mvebu_gpio_chip *mvchip)
+static u32
+mvebu_gpio_read_edge_cause(struct mvebu_gpio_chip *mvchip)
{
- return mvchip->membase + GPIO_IO_CONF_OFF;
-}
+ struct regmap *map;
+ unsigned int offset;
+ u32 val;
-static void __iomem *mvebu_gpioreg_in_pol(struct mvebu_gpio_chip *mvchip)
-{
- return mvchip->membase + GPIO_IN_POL_OFF;
+ mvebu_gpioreg_edge_cause(mvchip, &map, &offset);
+ regmap_read(map, offset, &val);
+
+ return val;
}
-static void __iomem *mvebu_gpioreg_data_in(struct mvebu_gpio_chip *mvchip)
+static void
+mvebu_gpio_write_edge_cause(struct mvebu_gpio_chip *mvchip, u32 val)
{
- return mvchip->membase + GPIO_DATA_IN_OFF;
+ struct regmap *map;
+ unsigned int offset;
+
+ mvebu_gpioreg_edge_cause(mvchip, &map, &offset);
+ regmap_write(map, offset, val);
}
-static void __iomem *mvebu_gpioreg_edge_cause(struct mvebu_gpio_chip *mvchip)
+static inline void
+mvebu_gpioreg_edge_mask(struct mvebu_gpio_chip *mvchip,
+ struct regmap **map, unsigned int *offset)
{
int cpu;
switch (mvchip->soc_variant) {
case MVEBU_GPIO_SOC_VARIANT_ORION:
+ *map = mvchip->regs;
+ *offset = GPIO_EDGE_MASK_OFF;
+ break;
case MVEBU_GPIO_SOC_VARIANT_MV78200:
- return mvchip->membase + GPIO_EDGE_CAUSE_OFF;
+ cpu = smp_processor_id();
+ *map = mvchip->regs;
+ *offset = GPIO_EDGE_MASK_MV78200_OFF(cpu);
+ break;
case MVEBU_GPIO_SOC_VARIANT_ARMADAXP:
cpu = smp_processor_id();
- return mvchip->percpu_membase +
- GPIO_EDGE_CAUSE_ARMADAXP_OFF(cpu);
+ *map = mvchip->percpu_regs;
+ *offset = GPIO_EDGE_MASK_ARMADAXP_OFF(cpu);
+ break;
default:
BUG();
}
}
-static void __iomem *mvebu_gpioreg_edge_mask(struct mvebu_gpio_chip *mvchip)
+static u32
+mvebu_gpio_read_edge_mask(struct mvebu_gpio_chip *mvchip)
{
- int cpu;
+ struct regmap *map;
+ unsigned int offset;
+ u32 val;
- switch (mvchip->soc_variant) {
- case MVEBU_GPIO_SOC_VARIANT_ORION:
- return mvchip->membase + GPIO_EDGE_MASK_OFF;
- case MVEBU_GPIO_SOC_VARIANT_MV78200:
- cpu = smp_processor_id();
- return mvchip->membase + GPIO_EDGE_MASK_MV78200_OFF(cpu);
- case MVEBU_GPIO_SOC_VARIANT_ARMADAXP:
- cpu = smp_processor_id();
- return mvchip->percpu_membase +
- GPIO_EDGE_MASK_ARMADAXP_OFF(cpu);
- default:
- BUG();
- }
+ mvebu_gpioreg_edge_mask(mvchip, &map, &offset);
+ regmap_read(map, offset, &val);
+
+ return val;
}
-static void __iomem *mvebu_gpioreg_level_mask(struct mvebu_gpio_chip *mvchip)
+static void
+mvebu_gpio_write_edge_mask(struct mvebu_gpio_chip *mvchip, u32 val)
+{
+ struct regmap *map;
+ unsigned int offset;
+
+ mvebu_gpioreg_edge_mask(mvchip, &map, &offset);
+ regmap_write(map, offset, val);
+}
+
+static void
+mvebu_gpioreg_level_mask(struct mvebu_gpio_chip *mvchip,
+ struct regmap **map, unsigned int *offset)
{
int cpu;
switch (mvchip->soc_variant) {
case MVEBU_GPIO_SOC_VARIANT_ORION:
- return mvchip->membase + GPIO_LEVEL_MASK_OFF;
+ *map = mvchip->regs;
+ *offset = GPIO_LEVEL_MASK_OFF;
+ break;
case MVEBU_GPIO_SOC_VARIANT_MV78200:
cpu = smp_processor_id();
- return mvchip->membase + GPIO_LEVEL_MASK_MV78200_OFF(cpu);
+ *map = mvchip->regs;
+ *offset = GPIO_LEVEL_MASK_MV78200_OFF(cpu);
+ break;
case MVEBU_GPIO_SOC_VARIANT_ARMADAXP:
cpu = smp_processor_id();
- return mvchip->percpu_membase +
- GPIO_LEVEL_MASK_ARMADAXP_OFF(cpu);
+ *map = mvchip->percpu_regs;
+ *offset = GPIO_LEVEL_MASK_ARMADAXP_OFF(cpu);
+ break;
default:
BUG();
}
}
+static u32
+mvebu_gpio_read_level_mask(struct mvebu_gpio_chip *mvchip)
+{
+ struct regmap *map;
+ unsigned int offset;
+ u32 val;
+
+ mvebu_gpioreg_level_mask(mvchip, &map, &offset);
+ regmap_read(map, offset, &val);
+
+ return val;
+}
+
+static void
+mvebu_gpio_write_level_mask(struct mvebu_gpio_chip *mvchip, u32 val)
+{
+ struct regmap *map;
+ unsigned int offset;
+
+ mvebu_gpioreg_level_mask(mvchip, &map, &offset);
+ regmap_write(map, offset, val);
+}
+
/*
* Functions returning addresses of individual registers for a given
* PWM controller.
@@ -236,17 +293,9 @@ static void __iomem *mvebu_pwmreg_blink_off_duration(struct mvebu_pwm *mvpwm)
static void mvebu_gpio_set(struct gpio_chip *chip, unsigned int pin, int value)
{
struct mvebu_gpio_chip *mvchip = gpiochip_get_data(chip);
- unsigned long flags;
- u32 u;
- spin_lock_irqsave(&mvchip->lock, flags);
- u = readl_relaxed(mvebu_gpioreg_out(mvchip));
- if (value)
- u |= BIT(pin);
- else
- u &= ~BIT(pin);
- writel_relaxed(u, mvebu_gpioreg_out(mvchip));
- spin_unlock_irqrestore(&mvchip->lock, flags);
+ regmap_update_bits(mvchip->regs, GPIO_OUT_OFF,
+ BIT(pin), value ? BIT(pin) : 0);
}
static int mvebu_gpio_get(struct gpio_chip *chip, unsigned int pin)
@@ -254,11 +303,16 @@ static int mvebu_gpio_get(struct gpio_chip *chip, unsigned int pin)
struct mvebu_gpio_chip *mvchip = gpiochip_get_data(chip);
u32 u;
- if (readl_relaxed(mvebu_gpioreg_io_conf(mvchip)) & BIT(pin)) {
- u = readl_relaxed(mvebu_gpioreg_data_in(mvchip)) ^
- readl_relaxed(mvebu_gpioreg_in_pol(mvchip));
+ regmap_read(mvchip->regs, GPIO_IO_CONF_OFF, &u);
+
+ if (u & BIT(pin)) {
+ u32 data_in, in_pol;
+
+ regmap_read(mvchip->regs, GPIO_DATA_IN_OFF, &data_in);
+ regmap_read(mvchip->regs, GPIO_IN_POL_OFF, &in_pol);
+ u = data_in ^ in_pol;
} else {
- u = readl_relaxed(mvebu_gpioreg_out(mvchip));
+ regmap_read(mvchip->regs, GPIO_OUT_OFF, &u);
}
return (u >> pin) & 1;
@@ -268,25 +322,15 @@ static void mvebu_gpio_blink(struct gpio_chip *chip, unsigned int pin,
int value)
{
struct mvebu_gpio_chip *mvchip = gpiochip_get_data(chip);
- unsigned long flags;
- u32 u;
- spin_lock_irqsave(&mvchip->lock, flags);
- u = readl_relaxed(mvebu_gpioreg_blink(mvchip));
- if (value)
- u |= BIT(pin);
- else
- u &= ~BIT(pin);
- writel_relaxed(u, mvebu_gpioreg_blink(mvchip));
- spin_unlock_irqrestore(&mvchip->lock, flags);
+ regmap_update_bits(mvchip->regs, GPIO_BLINK_EN_OFF,
+ BIT(pin), value ? BIT(pin) : 0);
}
static int mvebu_gpio_direction_input(struct gpio_chip *chip, unsigned int pin)
{
struct mvebu_gpio_chip *mvchip = gpiochip_get_data(chip);
- unsigned long flags;
int ret;
- u32 u;
/*
* Check with the pinctrl driver whether this pin is usable as
@@ -296,11 +340,8 @@ static int mvebu_gpio_direction_input(struct gpio_chip *chip, unsigned int pin)
if (ret)
return ret;
- spin_lock_irqsave(&mvchip->lock, flags);
- u = readl_relaxed(mvebu_gpioreg_io_conf(mvchip));
- u |= BIT(pin);
- writel_relaxed(u, mvebu_gpioreg_io_conf(mvchip));
- spin_unlock_irqrestore(&mvchip->lock, flags);
+ regmap_update_bits(mvchip->regs, GPIO_IO_CONF_OFF,
+ BIT(pin), 1);
return 0;
}
@@ -309,9 +350,7 @@ static int mvebu_gpio_direction_output(struct gpio_chip *chip, unsigned int pin,
int value)
{
struct mvebu_gpio_chip *mvchip = gpiochip_get_data(chip);
- unsigned long flags;
int ret;
- u32 u;
/*
* Check with the pinctrl driver whether this pin is usable as
@@ -324,11 +363,8 @@ static int mvebu_gpio_direction_output(struct gpio_chip *chip, unsigned int pin,
mvebu_gpio_blink(chip, pin, 0);
mvebu_gpio_set(chip, pin, value);
- spin_lock_irqsave(&mvchip->lock, flags);
- u = readl_relaxed(mvebu_gpioreg_io_conf(mvchip));
- u &= ~BIT(pin);
- writel_relaxed(u, mvebu_gpioreg_io_conf(mvchip));
- spin_unlock_irqrestore(&mvchip->lock, flags);
+ regmap_update_bits(mvchip->regs, GPIO_IO_CONF_OFF,
+ BIT(pin), 0);
return 0;
}
@@ -350,7 +386,7 @@ static void mvebu_gpio_irq_ack(struct irq_data *d)
u32 mask = d->mask;
irq_gc_lock(gc);
- writel_relaxed(~mask, mvebu_gpioreg_edge_cause(mvchip));
+ mvebu_gpio_write_edge_cause(mvchip, ~mask);
irq_gc_unlock(gc);
}
@@ -363,8 +399,7 @@ static void mvebu_gpio_edge_irq_mask(struct irq_data *d)
irq_gc_lock(gc);
ct->mask_cache_priv &= ~mask;
-
- writel_relaxed(ct->mask_cache_priv, mvebu_gpioreg_edge_mask(mvchip));
+ mvebu_gpio_write_edge_mask(mvchip, ct->mask_cache_priv);
irq_gc_unlock(gc);
}
@@ -377,7 +412,7 @@ static void mvebu_gpio_edge_irq_unmask(struct irq_data *d)
irq_gc_lock(gc);
ct->mask_cache_priv |= mask;
- writel_relaxed(ct->mask_cache_priv, mvebu_gpioreg_edge_mask(mvchip));
+ mvebu_gpio_write_edge_mask(mvchip, ct->mask_cache_priv);
irq_gc_unlock(gc);
}
@@ -390,7 +425,7 @@ static void mvebu_gpio_level_irq_mask(struct irq_data *d)
irq_gc_lock(gc);
ct->mask_cache_priv &= ~mask;
- writel_relaxed(ct->mask_cache_priv, mvebu_gpioreg_level_mask(mvchip));
+ mvebu_gpio_write_level_mask(mvchip, ct->mask_cache_priv);
irq_gc_unlock(gc);
}
@@ -403,7 +438,7 @@ static void mvebu_gpio_level_irq_unmask(struct irq_data *d)
irq_gc_lock(gc);
ct->mask_cache_priv |= mask;
- writel_relaxed(ct->mask_cache_priv, mvebu_gpioreg_level_mask(mvchip));
+ mvebu_gpio_write_level_mask(mvchip, ct->mask_cache_priv);
irq_gc_unlock(gc);
}
@@ -443,8 +478,8 @@ static int mvebu_gpio_irq_set_type(struct irq_data *d, unsigned int type)
pin = d->hwirq;
- u = readl_relaxed(mvebu_gpioreg_io_conf(mvchip)) & BIT(pin);
- if (!u)
+ regmap_read(mvchip->regs, GPIO_IO_CONF_OFF, &u);
+ if ((u & BIT(pin)) == 0)
return -EINVAL;
type &= IRQ_TYPE_SENSE_MASK;
@@ -462,31 +497,30 @@ static int mvebu_gpio_irq_set_type(struct irq_data *d, unsigned int type)
switch (type) {
case IRQ_TYPE_EDGE_RISING:
case IRQ_TYPE_LEVEL_HIGH:
- u = readl_relaxed(mvebu_gpioreg_in_pol(mvchip));
- u &= ~BIT(pin);
- writel_relaxed(u, mvebu_gpioreg_in_pol(mvchip));
+ regmap_update_bits(mvchip->regs, GPIO_IN_POL_OFF,
+ BIT(pin), 0);
break;
case IRQ_TYPE_EDGE_FALLING:
case IRQ_TYPE_LEVEL_LOW:
- u = readl_relaxed(mvebu_gpioreg_in_pol(mvchip));
- u |= BIT(pin);
- writel_relaxed(u, mvebu_gpioreg_in_pol(mvchip));
+ regmap_update_bits(mvchip->regs, GPIO_IN_POL_OFF,
+ BIT(pin), 1);
break;
case IRQ_TYPE_EDGE_BOTH: {
- u32 v;
+ u32 data_in, in_pol, val;
- v = readl_relaxed(mvebu_gpioreg_in_pol(mvchip)) ^
- readl_relaxed(mvebu_gpioreg_data_in(mvchip));
+ regmap_read(mvchip->regs, GPIO_IN_POL_OFF, &in_pol);
+ regmap_read(mvchip->regs, GPIO_DATA_IN_OFF, &data_in);
/*
* set initial polarity based on current input level
*/
- u = readl_relaxed(mvebu_gpioreg_in_pol(mvchip));
- if (v & BIT(pin))
- u |= BIT(pin); /* falling */
+ if ((data_in ^ in_pol) & BIT(pin))
+ val = BIT(pin); /* falling */
else
- u &= ~BIT(pin); /* rising */
- writel_relaxed(u, mvebu_gpioreg_in_pol(mvchip));
+ val = 0; /* raising */
+
+ regmap_update_bits(mvchip->regs, GPIO_IN_POL_OFF,
+ BIT(pin), val);
break;
}
}
@@ -497,7 +531,7 @@ static void mvebu_gpio_irq_handler(struct irq_desc *desc)
{
struct mvebu_gpio_chip *mvchip = irq_desc_get_handler_data(desc);
struct irq_chip *chip = irq_desc_get_chip(desc);
- u32 cause, type;
+ u32 cause, type, data_in, level_mask, edge_cause, edge_mask;
int i;
if (mvchip == NULL)
@@ -505,10 +539,12 @@ static void mvebu_gpio_irq_handler(struct irq_desc *desc)
chained_irq_enter(chip, desc);
- cause = readl_relaxed(mvebu_gpioreg_data_in(mvchip)) &
- readl_relaxed(mvebu_gpioreg_level_mask(mvchip));
- cause |= readl_relaxed(mvebu_gpioreg_edge_cause(mvchip)) &
- readl_relaxed(mvebu_gpioreg_edge_mask(mvchip));
+ regmap_read(mvchip->regs, GPIO_DATA_IN_OFF, &data_in);
+ level_mask = mvebu_gpio_read_level_mask(mvchip);
+ edge_cause = mvebu_gpio_read_edge_cause(mvchip);
+ edge_mask = mvebu_gpio_read_edge_mask(mvchip);
+
+ cause = (data_in ^ level_mask) | (edge_cause & edge_mask);
for (i = 0; i < mvchip->chip.ngpio; i++) {
int irq;
@@ -523,9 +559,9 @@ static void mvebu_gpio_irq_handler(struct irq_desc *desc)
/* Swap polarity (race with GPIO line) */
u32 polarity;
- polarity = readl_relaxed(mvebu_gpioreg_in_pol(mvchip));
+ regmap_read(mvchip->regs, GPIO_IN_POL_OFF, &polarity);
polarity ^= BIT(i);
- writel_relaxed(polarity, mvebu_gpioreg_in_pol(mvchip));
+ regmap_write(mvchip->regs, GPIO_IN_POL_OFF, polarity);
}
generic_handle_irq(irq);
@@ -628,7 +664,7 @@ static void mvebu_pwm_get_state(struct pwm_chip *chip,
state->period = 1;
}
- u = readl_relaxed(mvebu_gpioreg_blink(mvchip));
+ regmap_read(mvchip->regs, GPIO_BLINK_EN_OFF, &u);
if (u)
state->enabled = true;
else
@@ -691,8 +727,8 @@ static void __maybe_unused mvebu_pwm_suspend(struct mvebu_gpio_chip *mvchip)
{
struct mvebu_pwm *mvpwm = mvchip->mvpwm;
- mvpwm->blink_select =
- readl_relaxed(mvebu_gpioreg_blink_counter_select(mvchip));
+ regmap_read(mvchip->regs, GPIO_BLINK_CNT_SELECT_OFF,
+ &mvpwm->blink_select);
mvpwm->blink_on_duration =
readl_relaxed(mvebu_pwmreg_blink_on_duration(mvpwm));
mvpwm->blink_off_duration =
@@ -703,8 +739,8 @@ static void __maybe_unused mvebu_pwm_resume(struct mvebu_gpio_chip *mvchip)
{
struct mvebu_pwm *mvpwm = mvchip->mvpwm;
- writel_relaxed(mvpwm->blink_select,
- mvebu_gpioreg_blink_counter_select(mvchip));
+ regmap_write(mvchip->regs, GPIO_BLINK_CNT_SELECT_OFF,
+ mvpwm->blink_select);
writel_relaxed(mvpwm->blink_on_duration,
mvebu_pwmreg_blink_on_duration(mvpwm));
writel_relaxed(mvpwm->blink_off_duration,
@@ -747,7 +783,7 @@ static int mvebu_pwm_probe(struct platform_device *pdev,
set = U32_MAX;
else
return -EINVAL;
- writel_relaxed(0, mvebu_gpioreg_blink_counter_select(mvchip));
+ regmap_write(mvchip->regs, GPIO_BLINK_CNT_SELECT_OFF, 0);
mvpwm = devm_kzalloc(dev, sizeof(struct mvebu_pwm), GFP_KERNEL);
if (!mvpwm)
@@ -783,14 +819,14 @@ static void mvebu_gpio_dbg_show(struct seq_file *s, struct gpio_chip *chip)
u32 out, io_conf, blink, in_pol, data_in, cause, edg_msk, lvl_msk;
int i;
- out = readl_relaxed(mvebu_gpioreg_out(mvchip));
- io_conf = readl_relaxed(mvebu_gpioreg_io_conf(mvchip));
- blink = readl_relaxed(mvebu_gpioreg_blink(mvchip));
- in_pol = readl_relaxed(mvebu_gpioreg_in_pol(mvchip));
- data_in = readl_relaxed(mvebu_gpioreg_data_in(mvchip));
- cause = readl_relaxed(mvebu_gpioreg_edge_cause(mvchip));
- edg_msk = readl_relaxed(mvebu_gpioreg_edge_mask(mvchip));
- lvl_msk = readl_relaxed(mvebu_gpioreg_level_mask(mvchip));
+ regmap_read(mvchip->regs, GPIO_OUT_OFF, &out);
+ regmap_read(mvchip->regs, GPIO_IO_CONF_OFF, &io_conf);
+ regmap_read(mvchip->regs, GPIO_BLINK_EN_OFF, &blink);
+ regmap_read(mvchip->regs, GPIO_IN_POL_OFF, &in_pol);
+ regmap_read(mvchip->regs, GPIO_DATA_IN_OFF, &data_in);
+ cause = mvebu_gpio_read_edge_cause(mvchip);
+ edg_msk = mvebu_gpio_read_edge_mask(mvchip);
+ lvl_msk = mvebu_gpio_read_level_mask(mvchip);
for (i = 0; i < chip->ngpio; i++) {
const char *label;
@@ -858,36 +894,36 @@ static int mvebu_gpio_suspend(struct platform_device *pdev, pm_message_t state)
struct mvebu_gpio_chip *mvchip = platform_get_drvdata(pdev);
int i;
- mvchip->out_reg = readl(mvebu_gpioreg_out(mvchip));
- mvchip->io_conf_reg = readl(mvebu_gpioreg_io_conf(mvchip));
- mvchip->blink_en_reg = readl(mvebu_gpioreg_blink(mvchip));
- mvchip->in_pol_reg = readl(mvebu_gpioreg_in_pol(mvchip));
+ regmap_read(mvchip->regs, GPIO_OUT_OFF, &mvchip->out_reg);
+ regmap_read(mvchip->regs, GPIO_IO_CONF_OFF, &mvchip->io_conf_reg);
+ regmap_read(mvchip->regs, GPIO_BLINK_EN_OFF, &mvchip->blink_en_reg);
+ regmap_read(mvchip->regs, GPIO_IN_POL_OFF, &mvchip->in_pol_reg);
switch (mvchip->soc_variant) {
case MVEBU_GPIO_SOC_VARIANT_ORION:
- mvchip->edge_mask_regs[0] =
- readl(mvchip->membase + GPIO_EDGE_MASK_OFF);
- mvchip->level_mask_regs[0] =
- readl(mvchip->membase + GPIO_LEVEL_MASK_OFF);
+ regmap_read(mvchip->regs, GPIO_EDGE_MASK_OFF,
+ &mvchip->edge_mask_regs[0]);
+ regmap_read(mvchip->regs, GPIO_LEVEL_MASK_OFF,
+ &mvchip->level_mask_regs[0]);
break;
case MVEBU_GPIO_SOC_VARIANT_MV78200:
for (i = 0; i < 2; i++) {
- mvchip->edge_mask_regs[i] =
- readl(mvchip->membase +
- GPIO_EDGE_MASK_MV78200_OFF(i));
- mvchip->level_mask_regs[i] =
- readl(mvchip->membase +
- GPIO_LEVEL_MASK_MV78200_OFF(i));
+ regmap_read(mvchip->regs,
+ GPIO_EDGE_MASK_MV78200_OFF(i),
+ &mvchip->edge_mask_regs[i]);
+ regmap_read(mvchip->regs,
+ GPIO_LEVEL_MASK_MV78200_OFF(i),
+ &mvchip->level_mask_regs[i]);
}
break;
case MVEBU_GPIO_SOC_VARIANT_ARMADAXP:
for (i = 0; i < 4; i++) {
- mvchip->edge_mask_regs[i] =
- readl(mvchip->membase +
- GPIO_EDGE_MASK_ARMADAXP_OFF(i));
- mvchip->level_mask_regs[i] =
- readl(mvchip->membase +
- GPIO_LEVEL_MASK_ARMADAXP_OFF(i));
+ regmap_read(mvchip->regs,
+ GPIO_EDGE_MASK_ARMADAXP_OFF(i),
+ &mvchip->edge_mask_regs[i]);
+ regmap_read(mvchip->regs,
+ GPIO_LEVEL_MASK_ARMADAXP_OFF(i),
+ &mvchip->level_mask_regs[i]);
}
break;
default:
@@ -905,35 +941,36 @@ static int mvebu_gpio_resume(struct platform_device *pdev)
struct mvebu_gpio_chip *mvchip = platform_get_drvdata(pdev);
int i;
- writel(mvchip->out_reg, mvebu_gpioreg_out(mvchip));
- writel(mvchip->io_conf_reg, mvebu_gpioreg_io_conf(mvchip));
- writel(mvchip->blink_en_reg, mvebu_gpioreg_blink(mvchip));
- writel(mvchip->in_pol_reg, mvebu_gpioreg_in_pol(mvchip));
+ regmap_write(mvchip->regs, GPIO_OUT_OFF, mvchip->out_reg);
+ regmap_write(mvchip->regs, GPIO_IO_CONF_OFF, mvchip->io_conf_reg);
+ regmap_write(mvchip->regs, GPIO_BLINK_EN_OFF, mvchip->blink_en_reg);
+ regmap_write(mvchip->regs, GPIO_IN_POL_OFF, mvchip->in_pol_reg);
switch (mvchip->soc_variant) {
case MVEBU_GPIO_SOC_VARIANT_ORION:
- writel(mvchip->edge_mask_regs[0],
- mvchip->membase + GPIO_EDGE_MASK_OFF);
- writel(mvchip->level_mask_regs[0],
- mvchip->membase + GPIO_LEVEL_MASK_OFF);
+ regmap_write(mvchip->regs, GPIO_EDGE_MASK_OFF,
+ mvchip->edge_mask_regs[0]);
+ regmap_write(mvchip->regs, GPIO_LEVEL_MASK_OFF,
+ mvchip->level_mask_regs[0]);
break;
case MVEBU_GPIO_SOC_VARIANT_MV78200:
for (i = 0; i < 2; i++) {
- writel(mvchip->edge_mask_regs[i],
- mvchip->membase + GPIO_EDGE_MASK_MV78200_OFF(i));
- writel(mvchip->level_mask_regs[i],
- mvchip->membase +
- GPIO_LEVEL_MASK_MV78200_OFF(i));
+ regmap_write(mvchip->regs,
+ GPIO_EDGE_MASK_MV78200_OFF(i),
+ mvchip->edge_mask_regs[i]);
+ regmap_write(mvchip->regs,
+ GPIO_LEVEL_MASK_MV78200_OFF(i),
+ mvchip->level_mask_regs[i]);
}
break;
case MVEBU_GPIO_SOC_VARIANT_ARMADAXP:
for (i = 0; i < 4; i++) {
- writel(mvchip->edge_mask_regs[i],
- mvchip->membase +
- GPIO_EDGE_MASK_ARMADAXP_OFF(i));
- writel(mvchip->level_mask_regs[i],
- mvchip->membase +
- GPIO_LEVEL_MASK_ARMADAXP_OFF(i));
+ regmap_write(mvchip->regs,
+ GPIO_EDGE_MASK_ARMADAXP_OFF(i),
+ mvchip->edge_mask_regs[i]);
+ regmap_write(mvchip->regs,
+ GPIO_LEVEL_MASK_ARMADAXP_OFF(i),
+ mvchip->level_mask_regs[i]);
}
break;
default:
@@ -946,6 +983,13 @@ static int mvebu_gpio_resume(struct platform_device *pdev)
return 0;
}
+static const struct regmap_config mvebu_gpio_regmap_config = {
+ .reg_bits = 32,
+ .reg_stride = 4,
+ .val_bits = 32,
+ .fast_io = true,
+};
+
static int mvebu_gpio_probe(struct platform_device *pdev)
{
struct mvebu_gpio_chip *mvchip;
@@ -954,6 +998,7 @@ static int mvebu_gpio_probe(struct platform_device *pdev)
struct resource *res;
struct irq_chip_generic *gc;
struct irq_chip_type *ct;
+ void __iomem *base;
unsigned int ngpios;
bool have_irqs;
int soc_variant;
@@ -1009,11 +1054,15 @@ static int mvebu_gpio_probe(struct platform_device *pdev)
mvchip->chip.of_node = np;
mvchip->chip.dbg_show = mvebu_gpio_dbg_show;
- spin_lock_init(&mvchip->lock);
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- mvchip->membase = devm_ioremap_resource(&pdev->dev, res);
- if (IS_ERR(mvchip->membase))
- return PTR_ERR(mvchip->membase);
+ base = devm_ioremap_resource(&pdev->dev, res);
+ if (IS_ERR(base))
+ return PTR_ERR(base);
+
+ mvchip->regs = devm_regmap_init_mmio(&pdev->dev, base,
+ &mvebu_gpio_regmap_config);
+ if (IS_ERR(mvchip->regs))
+ return PTR_ERR(mvchip->regs);
/*
* The Armada XP has a second range of registers for the
@@ -1021,10 +1070,15 @@ static int mvebu_gpio_probe(struct platform_device *pdev)
*/
if (soc_variant == MVEBU_GPIO_SOC_VARIANT_ARMADAXP) {
res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
- mvchip->percpu_membase = devm_ioremap_resource(&pdev->dev,
- res);
- if (IS_ERR(mvchip->percpu_membase))
- return PTR_ERR(mvchip->percpu_membase);
+ base = devm_ioremap_resource(&pdev->dev, res);
+ if (IS_ERR(base))
+ return PTR_ERR(base);
+
+ mvchip->percpu_regs =
+ devm_regmap_init_mmio(&pdev->dev, base,
+ &mvebu_gpio_regmap_config);
+ if (IS_ERR(mvchip->percpu_regs))
+ return PTR_ERR(mvchip->percpu_regs);
}
/*
@@ -1032,30 +1086,30 @@ static int mvebu_gpio_probe(struct platform_device *pdev)
*/
switch (soc_variant) {
case MVEBU_GPIO_SOC_VARIANT_ORION:
- writel_relaxed(0, mvchip->membase + GPIO_EDGE_CAUSE_OFF);
- writel_relaxed(0, mvchip->membase + GPIO_EDGE_MASK_OFF);
- writel_relaxed(0, mvchip->membase + GPIO_LEVEL_MASK_OFF);
+ regmap_write(mvchip->regs, GPIO_EDGE_CAUSE_OFF, 0);
+ regmap_write(mvchip->regs, GPIO_EDGE_MASK_OFF, 0);
+ regmap_write(mvchip->regs, GPIO_LEVEL_MASK_OFF, 0);
break;
case MVEBU_GPIO_SOC_VARIANT_MV78200:
- writel_relaxed(0, mvchip->membase + GPIO_EDGE_CAUSE_OFF);
+ regmap_write(mvchip->regs, GPIO_EDGE_CAUSE_OFF, 0);
for (cpu = 0; cpu < 2; cpu++) {
- writel_relaxed(0, mvchip->membase +
- GPIO_EDGE_MASK_MV78200_OFF(cpu));
- writel_relaxed(0, mvchip->membase +
- GPIO_LEVEL_MASK_MV78200_OFF(cpu));
+ regmap_write(mvchip->regs,
+ GPIO_EDGE_MASK_MV78200_OFF(cpu), 0);
+ regmap_write(mvchip->regs,
+ GPIO_LEVEL_MASK_MV78200_OFF(cpu), 0);
}
break;
case MVEBU_GPIO_SOC_VARIANT_ARMADAXP:
- writel_relaxed(0, mvchip->membase + GPIO_EDGE_CAUSE_OFF);
- writel_relaxed(0, mvchip->membase + GPIO_EDGE_MASK_OFF);
- writel_relaxed(0, mvchip->membase + GPIO_LEVEL_MASK_OFF);
+ regmap_write(mvchip->regs, GPIO_EDGE_CAUSE_OFF, 0);
+ regmap_write(mvchip->regs, GPIO_EDGE_MASK_OFF, 0);
+ regmap_write(mvchip->regs, GPIO_LEVEL_MASK_OFF, 0);
for (cpu = 0; cpu < 4; cpu++) {
- writel_relaxed(0, mvchip->percpu_membase +
- GPIO_EDGE_CAUSE_ARMADAXP_OFF(cpu));
- writel_relaxed(0, mvchip->percpu_membase +
- GPIO_EDGE_MASK_ARMADAXP_OFF(cpu));
- writel_relaxed(0, mvchip->percpu_membase +
- GPIO_LEVEL_MASK_ARMADAXP_OFF(cpu));
+ regmap_write(mvchip->percpu_regs,
+ GPIO_EDGE_CAUSE_ARMADAXP_OFF(cpu), 0);
+ regmap_write(mvchip->percpu_regs,
+ GPIO_EDGE_MASK_ARMADAXP_OFF(cpu), 0);
+ regmap_write(mvchip->percpu_regs,
+ GPIO_LEVEL_MASK_ARMADAXP_OFF(cpu), 0);
}
break;
default:
--
git-series 0.9.1
^ permalink raw reply related [flat|nested] 65+ messages in thread
* [PATCH 2/6] gpio: mvebu: switch to regmap for register access
@ 2017-05-19 16:09 ` Gregory CLEMENT
0 siblings, 0 replies; 65+ messages in thread
From: Gregory CLEMENT @ 2017-05-19 16:09 UTC (permalink / raw)
To: linux-arm-kernel
From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
In order to be able to use this driver with the Armada 7K/8K SoCs, we
need to use the regmap to access the registers. Indeed for these new SoCs,
the gpio node will be part of a syscon.
[gregory.clement at free-electrons.com:
- fixed merge conflcit from 4.10 to 4.12-rc1
- added a commit log]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
drivers/gpio/gpio-mvebu.c | 436 +++++++++++++++++++++------------------
1 file changed, 245 insertions(+), 191 deletions(-)
diff --git a/drivers/gpio/gpio-mvebu.c b/drivers/gpio/gpio-mvebu.c
index a9e564f3410b..3d03740a20e7 100644
--- a/drivers/gpio/gpio-mvebu.c
+++ b/drivers/gpio/gpio-mvebu.c
@@ -47,6 +47,7 @@
#include <linux/pinctrl/consumer.h>
#include <linux/platform_device.h>
#include <linux/pwm.h>
+#include <linux/regmap.h>
#include <linux/slab.h>
#include "gpiolib.h"
@@ -106,9 +107,8 @@ struct mvebu_pwm {
struct mvebu_gpio_chip {
struct gpio_chip chip;
- spinlock_t lock;
- void __iomem *membase;
- void __iomem *percpu_membase;
+ struct regmap *regs;
+ struct regmap *percpu_regs;
int irqbase;
struct irq_domain *domain;
int soc_variant;
@@ -130,92 +130,149 @@ struct mvebu_gpio_chip {
* Functions returning addresses of individual registers for a given
* GPIO controller.
*/
-static void __iomem *mvebu_gpioreg_out(struct mvebu_gpio_chip *mvchip)
-{
- return mvchip->membase + GPIO_OUT_OFF;
-}
-static void __iomem *mvebu_gpioreg_blink(struct mvebu_gpio_chip *mvchip)
+static void mvebu_gpioreg_edge_cause(struct mvebu_gpio_chip *mvchip,
+ struct regmap **map, unsigned int *offset)
{
- return mvchip->membase + GPIO_BLINK_EN_OFF;
-}
+ int cpu;
-static void __iomem *mvebu_gpioreg_blink_counter_select(struct mvebu_gpio_chip
- *mvchip)
-{
- return mvchip->membase + GPIO_BLINK_CNT_SELECT_OFF;
+ switch (mvchip->soc_variant) {
+ case MVEBU_GPIO_SOC_VARIANT_ORION:
+ case MVEBU_GPIO_SOC_VARIANT_MV78200:
+ *map = mvchip->regs;
+ *offset = GPIO_EDGE_CAUSE_OFF;
+ break;
+ case MVEBU_GPIO_SOC_VARIANT_ARMADAXP:
+ cpu = smp_processor_id();
+ *map = mvchip->percpu_regs;
+ *offset = GPIO_EDGE_CAUSE_ARMADAXP_OFF(cpu);
+ break;
+ default:
+ BUG();
+ }
}
-static void __iomem *mvebu_gpioreg_io_conf(struct mvebu_gpio_chip *mvchip)
+static u32
+mvebu_gpio_read_edge_cause(struct mvebu_gpio_chip *mvchip)
{
- return mvchip->membase + GPIO_IO_CONF_OFF;
-}
+ struct regmap *map;
+ unsigned int offset;
+ u32 val;
-static void __iomem *mvebu_gpioreg_in_pol(struct mvebu_gpio_chip *mvchip)
-{
- return mvchip->membase + GPIO_IN_POL_OFF;
+ mvebu_gpioreg_edge_cause(mvchip, &map, &offset);
+ regmap_read(map, offset, &val);
+
+ return val;
}
-static void __iomem *mvebu_gpioreg_data_in(struct mvebu_gpio_chip *mvchip)
+static void
+mvebu_gpio_write_edge_cause(struct mvebu_gpio_chip *mvchip, u32 val)
{
- return mvchip->membase + GPIO_DATA_IN_OFF;
+ struct regmap *map;
+ unsigned int offset;
+
+ mvebu_gpioreg_edge_cause(mvchip, &map, &offset);
+ regmap_write(map, offset, val);
}
-static void __iomem *mvebu_gpioreg_edge_cause(struct mvebu_gpio_chip *mvchip)
+static inline void
+mvebu_gpioreg_edge_mask(struct mvebu_gpio_chip *mvchip,
+ struct regmap **map, unsigned int *offset)
{
int cpu;
switch (mvchip->soc_variant) {
case MVEBU_GPIO_SOC_VARIANT_ORION:
+ *map = mvchip->regs;
+ *offset = GPIO_EDGE_MASK_OFF;
+ break;
case MVEBU_GPIO_SOC_VARIANT_MV78200:
- return mvchip->membase + GPIO_EDGE_CAUSE_OFF;
+ cpu = smp_processor_id();
+ *map = mvchip->regs;
+ *offset = GPIO_EDGE_MASK_MV78200_OFF(cpu);
+ break;
case MVEBU_GPIO_SOC_VARIANT_ARMADAXP:
cpu = smp_processor_id();
- return mvchip->percpu_membase +
- GPIO_EDGE_CAUSE_ARMADAXP_OFF(cpu);
+ *map = mvchip->percpu_regs;
+ *offset = GPIO_EDGE_MASK_ARMADAXP_OFF(cpu);
+ break;
default:
BUG();
}
}
-static void __iomem *mvebu_gpioreg_edge_mask(struct mvebu_gpio_chip *mvchip)
+static u32
+mvebu_gpio_read_edge_mask(struct mvebu_gpio_chip *mvchip)
{
- int cpu;
+ struct regmap *map;
+ unsigned int offset;
+ u32 val;
- switch (mvchip->soc_variant) {
- case MVEBU_GPIO_SOC_VARIANT_ORION:
- return mvchip->membase + GPIO_EDGE_MASK_OFF;
- case MVEBU_GPIO_SOC_VARIANT_MV78200:
- cpu = smp_processor_id();
- return mvchip->membase + GPIO_EDGE_MASK_MV78200_OFF(cpu);
- case MVEBU_GPIO_SOC_VARIANT_ARMADAXP:
- cpu = smp_processor_id();
- return mvchip->percpu_membase +
- GPIO_EDGE_MASK_ARMADAXP_OFF(cpu);
- default:
- BUG();
- }
+ mvebu_gpioreg_edge_mask(mvchip, &map, &offset);
+ regmap_read(map, offset, &val);
+
+ return val;
}
-static void __iomem *mvebu_gpioreg_level_mask(struct mvebu_gpio_chip *mvchip)
+static void
+mvebu_gpio_write_edge_mask(struct mvebu_gpio_chip *mvchip, u32 val)
+{
+ struct regmap *map;
+ unsigned int offset;
+
+ mvebu_gpioreg_edge_mask(mvchip, &map, &offset);
+ regmap_write(map, offset, val);
+}
+
+static void
+mvebu_gpioreg_level_mask(struct mvebu_gpio_chip *mvchip,
+ struct regmap **map, unsigned int *offset)
{
int cpu;
switch (mvchip->soc_variant) {
case MVEBU_GPIO_SOC_VARIANT_ORION:
- return mvchip->membase + GPIO_LEVEL_MASK_OFF;
+ *map = mvchip->regs;
+ *offset = GPIO_LEVEL_MASK_OFF;
+ break;
case MVEBU_GPIO_SOC_VARIANT_MV78200:
cpu = smp_processor_id();
- return mvchip->membase + GPIO_LEVEL_MASK_MV78200_OFF(cpu);
+ *map = mvchip->regs;
+ *offset = GPIO_LEVEL_MASK_MV78200_OFF(cpu);
+ break;
case MVEBU_GPIO_SOC_VARIANT_ARMADAXP:
cpu = smp_processor_id();
- return mvchip->percpu_membase +
- GPIO_LEVEL_MASK_ARMADAXP_OFF(cpu);
+ *map = mvchip->percpu_regs;
+ *offset = GPIO_LEVEL_MASK_ARMADAXP_OFF(cpu);
+ break;
default:
BUG();
}
}
+static u32
+mvebu_gpio_read_level_mask(struct mvebu_gpio_chip *mvchip)
+{
+ struct regmap *map;
+ unsigned int offset;
+ u32 val;
+
+ mvebu_gpioreg_level_mask(mvchip, &map, &offset);
+ regmap_read(map, offset, &val);
+
+ return val;
+}
+
+static void
+mvebu_gpio_write_level_mask(struct mvebu_gpio_chip *mvchip, u32 val)
+{
+ struct regmap *map;
+ unsigned int offset;
+
+ mvebu_gpioreg_level_mask(mvchip, &map, &offset);
+ regmap_write(map, offset, val);
+}
+
/*
* Functions returning addresses of individual registers for a given
* PWM controller.
@@ -236,17 +293,9 @@ static void __iomem *mvebu_pwmreg_blink_off_duration(struct mvebu_pwm *mvpwm)
static void mvebu_gpio_set(struct gpio_chip *chip, unsigned int pin, int value)
{
struct mvebu_gpio_chip *mvchip = gpiochip_get_data(chip);
- unsigned long flags;
- u32 u;
- spin_lock_irqsave(&mvchip->lock, flags);
- u = readl_relaxed(mvebu_gpioreg_out(mvchip));
- if (value)
- u |= BIT(pin);
- else
- u &= ~BIT(pin);
- writel_relaxed(u, mvebu_gpioreg_out(mvchip));
- spin_unlock_irqrestore(&mvchip->lock, flags);
+ regmap_update_bits(mvchip->regs, GPIO_OUT_OFF,
+ BIT(pin), value ? BIT(pin) : 0);
}
static int mvebu_gpio_get(struct gpio_chip *chip, unsigned int pin)
@@ -254,11 +303,16 @@ static int mvebu_gpio_get(struct gpio_chip *chip, unsigned int pin)
struct mvebu_gpio_chip *mvchip = gpiochip_get_data(chip);
u32 u;
- if (readl_relaxed(mvebu_gpioreg_io_conf(mvchip)) & BIT(pin)) {
- u = readl_relaxed(mvebu_gpioreg_data_in(mvchip)) ^
- readl_relaxed(mvebu_gpioreg_in_pol(mvchip));
+ regmap_read(mvchip->regs, GPIO_IO_CONF_OFF, &u);
+
+ if (u & BIT(pin)) {
+ u32 data_in, in_pol;
+
+ regmap_read(mvchip->regs, GPIO_DATA_IN_OFF, &data_in);
+ regmap_read(mvchip->regs, GPIO_IN_POL_OFF, &in_pol);
+ u = data_in ^ in_pol;
} else {
- u = readl_relaxed(mvebu_gpioreg_out(mvchip));
+ regmap_read(mvchip->regs, GPIO_OUT_OFF, &u);
}
return (u >> pin) & 1;
@@ -268,25 +322,15 @@ static void mvebu_gpio_blink(struct gpio_chip *chip, unsigned int pin,
int value)
{
struct mvebu_gpio_chip *mvchip = gpiochip_get_data(chip);
- unsigned long flags;
- u32 u;
- spin_lock_irqsave(&mvchip->lock, flags);
- u = readl_relaxed(mvebu_gpioreg_blink(mvchip));
- if (value)
- u |= BIT(pin);
- else
- u &= ~BIT(pin);
- writel_relaxed(u, mvebu_gpioreg_blink(mvchip));
- spin_unlock_irqrestore(&mvchip->lock, flags);
+ regmap_update_bits(mvchip->regs, GPIO_BLINK_EN_OFF,
+ BIT(pin), value ? BIT(pin) : 0);
}
static int mvebu_gpio_direction_input(struct gpio_chip *chip, unsigned int pin)
{
struct mvebu_gpio_chip *mvchip = gpiochip_get_data(chip);
- unsigned long flags;
int ret;
- u32 u;
/*
* Check with the pinctrl driver whether this pin is usable as
@@ -296,11 +340,8 @@ static int mvebu_gpio_direction_input(struct gpio_chip *chip, unsigned int pin)
if (ret)
return ret;
- spin_lock_irqsave(&mvchip->lock, flags);
- u = readl_relaxed(mvebu_gpioreg_io_conf(mvchip));
- u |= BIT(pin);
- writel_relaxed(u, mvebu_gpioreg_io_conf(mvchip));
- spin_unlock_irqrestore(&mvchip->lock, flags);
+ regmap_update_bits(mvchip->regs, GPIO_IO_CONF_OFF,
+ BIT(pin), 1);
return 0;
}
@@ -309,9 +350,7 @@ static int mvebu_gpio_direction_output(struct gpio_chip *chip, unsigned int pin,
int value)
{
struct mvebu_gpio_chip *mvchip = gpiochip_get_data(chip);
- unsigned long flags;
int ret;
- u32 u;
/*
* Check with the pinctrl driver whether this pin is usable as
@@ -324,11 +363,8 @@ static int mvebu_gpio_direction_output(struct gpio_chip *chip, unsigned int pin,
mvebu_gpio_blink(chip, pin, 0);
mvebu_gpio_set(chip, pin, value);
- spin_lock_irqsave(&mvchip->lock, flags);
- u = readl_relaxed(mvebu_gpioreg_io_conf(mvchip));
- u &= ~BIT(pin);
- writel_relaxed(u, mvebu_gpioreg_io_conf(mvchip));
- spin_unlock_irqrestore(&mvchip->lock, flags);
+ regmap_update_bits(mvchip->regs, GPIO_IO_CONF_OFF,
+ BIT(pin), 0);
return 0;
}
@@ -350,7 +386,7 @@ static void mvebu_gpio_irq_ack(struct irq_data *d)
u32 mask = d->mask;
irq_gc_lock(gc);
- writel_relaxed(~mask, mvebu_gpioreg_edge_cause(mvchip));
+ mvebu_gpio_write_edge_cause(mvchip, ~mask);
irq_gc_unlock(gc);
}
@@ -363,8 +399,7 @@ static void mvebu_gpio_edge_irq_mask(struct irq_data *d)
irq_gc_lock(gc);
ct->mask_cache_priv &= ~mask;
-
- writel_relaxed(ct->mask_cache_priv, mvebu_gpioreg_edge_mask(mvchip));
+ mvebu_gpio_write_edge_mask(mvchip, ct->mask_cache_priv);
irq_gc_unlock(gc);
}
@@ -377,7 +412,7 @@ static void mvebu_gpio_edge_irq_unmask(struct irq_data *d)
irq_gc_lock(gc);
ct->mask_cache_priv |= mask;
- writel_relaxed(ct->mask_cache_priv, mvebu_gpioreg_edge_mask(mvchip));
+ mvebu_gpio_write_edge_mask(mvchip, ct->mask_cache_priv);
irq_gc_unlock(gc);
}
@@ -390,7 +425,7 @@ static void mvebu_gpio_level_irq_mask(struct irq_data *d)
irq_gc_lock(gc);
ct->mask_cache_priv &= ~mask;
- writel_relaxed(ct->mask_cache_priv, mvebu_gpioreg_level_mask(mvchip));
+ mvebu_gpio_write_level_mask(mvchip, ct->mask_cache_priv);
irq_gc_unlock(gc);
}
@@ -403,7 +438,7 @@ static void mvebu_gpio_level_irq_unmask(struct irq_data *d)
irq_gc_lock(gc);
ct->mask_cache_priv |= mask;
- writel_relaxed(ct->mask_cache_priv, mvebu_gpioreg_level_mask(mvchip));
+ mvebu_gpio_write_level_mask(mvchip, ct->mask_cache_priv);
irq_gc_unlock(gc);
}
@@ -443,8 +478,8 @@ static int mvebu_gpio_irq_set_type(struct irq_data *d, unsigned int type)
pin = d->hwirq;
- u = readl_relaxed(mvebu_gpioreg_io_conf(mvchip)) & BIT(pin);
- if (!u)
+ regmap_read(mvchip->regs, GPIO_IO_CONF_OFF, &u);
+ if ((u & BIT(pin)) == 0)
return -EINVAL;
type &= IRQ_TYPE_SENSE_MASK;
@@ -462,31 +497,30 @@ static int mvebu_gpio_irq_set_type(struct irq_data *d, unsigned int type)
switch (type) {
case IRQ_TYPE_EDGE_RISING:
case IRQ_TYPE_LEVEL_HIGH:
- u = readl_relaxed(mvebu_gpioreg_in_pol(mvchip));
- u &= ~BIT(pin);
- writel_relaxed(u, mvebu_gpioreg_in_pol(mvchip));
+ regmap_update_bits(mvchip->regs, GPIO_IN_POL_OFF,
+ BIT(pin), 0);
break;
case IRQ_TYPE_EDGE_FALLING:
case IRQ_TYPE_LEVEL_LOW:
- u = readl_relaxed(mvebu_gpioreg_in_pol(mvchip));
- u |= BIT(pin);
- writel_relaxed(u, mvebu_gpioreg_in_pol(mvchip));
+ regmap_update_bits(mvchip->regs, GPIO_IN_POL_OFF,
+ BIT(pin), 1);
break;
case IRQ_TYPE_EDGE_BOTH: {
- u32 v;
+ u32 data_in, in_pol, val;
- v = readl_relaxed(mvebu_gpioreg_in_pol(mvchip)) ^
- readl_relaxed(mvebu_gpioreg_data_in(mvchip));
+ regmap_read(mvchip->regs, GPIO_IN_POL_OFF, &in_pol);
+ regmap_read(mvchip->regs, GPIO_DATA_IN_OFF, &data_in);
/*
* set initial polarity based on current input level
*/
- u = readl_relaxed(mvebu_gpioreg_in_pol(mvchip));
- if (v & BIT(pin))
- u |= BIT(pin); /* falling */
+ if ((data_in ^ in_pol) & BIT(pin))
+ val = BIT(pin); /* falling */
else
- u &= ~BIT(pin); /* rising */
- writel_relaxed(u, mvebu_gpioreg_in_pol(mvchip));
+ val = 0; /* raising */
+
+ regmap_update_bits(mvchip->regs, GPIO_IN_POL_OFF,
+ BIT(pin), val);
break;
}
}
@@ -497,7 +531,7 @@ static void mvebu_gpio_irq_handler(struct irq_desc *desc)
{
struct mvebu_gpio_chip *mvchip = irq_desc_get_handler_data(desc);
struct irq_chip *chip = irq_desc_get_chip(desc);
- u32 cause, type;
+ u32 cause, type, data_in, level_mask, edge_cause, edge_mask;
int i;
if (mvchip == NULL)
@@ -505,10 +539,12 @@ static void mvebu_gpio_irq_handler(struct irq_desc *desc)
chained_irq_enter(chip, desc);
- cause = readl_relaxed(mvebu_gpioreg_data_in(mvchip)) &
- readl_relaxed(mvebu_gpioreg_level_mask(mvchip));
- cause |= readl_relaxed(mvebu_gpioreg_edge_cause(mvchip)) &
- readl_relaxed(mvebu_gpioreg_edge_mask(mvchip));
+ regmap_read(mvchip->regs, GPIO_DATA_IN_OFF, &data_in);
+ level_mask = mvebu_gpio_read_level_mask(mvchip);
+ edge_cause = mvebu_gpio_read_edge_cause(mvchip);
+ edge_mask = mvebu_gpio_read_edge_mask(mvchip);
+
+ cause = (data_in ^ level_mask) | (edge_cause & edge_mask);
for (i = 0; i < mvchip->chip.ngpio; i++) {
int irq;
@@ -523,9 +559,9 @@ static void mvebu_gpio_irq_handler(struct irq_desc *desc)
/* Swap polarity (race with GPIO line) */
u32 polarity;
- polarity = readl_relaxed(mvebu_gpioreg_in_pol(mvchip));
+ regmap_read(mvchip->regs, GPIO_IN_POL_OFF, &polarity);
polarity ^= BIT(i);
- writel_relaxed(polarity, mvebu_gpioreg_in_pol(mvchip));
+ regmap_write(mvchip->regs, GPIO_IN_POL_OFF, polarity);
}
generic_handle_irq(irq);
@@ -628,7 +664,7 @@ static void mvebu_pwm_get_state(struct pwm_chip *chip,
state->period = 1;
}
- u = readl_relaxed(mvebu_gpioreg_blink(mvchip));
+ regmap_read(mvchip->regs, GPIO_BLINK_EN_OFF, &u);
if (u)
state->enabled = true;
else
@@ -691,8 +727,8 @@ static void __maybe_unused mvebu_pwm_suspend(struct mvebu_gpio_chip *mvchip)
{
struct mvebu_pwm *mvpwm = mvchip->mvpwm;
- mvpwm->blink_select =
- readl_relaxed(mvebu_gpioreg_blink_counter_select(mvchip));
+ regmap_read(mvchip->regs, GPIO_BLINK_CNT_SELECT_OFF,
+ &mvpwm->blink_select);
mvpwm->blink_on_duration =
readl_relaxed(mvebu_pwmreg_blink_on_duration(mvpwm));
mvpwm->blink_off_duration =
@@ -703,8 +739,8 @@ static void __maybe_unused mvebu_pwm_resume(struct mvebu_gpio_chip *mvchip)
{
struct mvebu_pwm *mvpwm = mvchip->mvpwm;
- writel_relaxed(mvpwm->blink_select,
- mvebu_gpioreg_blink_counter_select(mvchip));
+ regmap_write(mvchip->regs, GPIO_BLINK_CNT_SELECT_OFF,
+ mvpwm->blink_select);
writel_relaxed(mvpwm->blink_on_duration,
mvebu_pwmreg_blink_on_duration(mvpwm));
writel_relaxed(mvpwm->blink_off_duration,
@@ -747,7 +783,7 @@ static int mvebu_pwm_probe(struct platform_device *pdev,
set = U32_MAX;
else
return -EINVAL;
- writel_relaxed(0, mvebu_gpioreg_blink_counter_select(mvchip));
+ regmap_write(mvchip->regs, GPIO_BLINK_CNT_SELECT_OFF, 0);
mvpwm = devm_kzalloc(dev, sizeof(struct mvebu_pwm), GFP_KERNEL);
if (!mvpwm)
@@ -783,14 +819,14 @@ static void mvebu_gpio_dbg_show(struct seq_file *s, struct gpio_chip *chip)
u32 out, io_conf, blink, in_pol, data_in, cause, edg_msk, lvl_msk;
int i;
- out = readl_relaxed(mvebu_gpioreg_out(mvchip));
- io_conf = readl_relaxed(mvebu_gpioreg_io_conf(mvchip));
- blink = readl_relaxed(mvebu_gpioreg_blink(mvchip));
- in_pol = readl_relaxed(mvebu_gpioreg_in_pol(mvchip));
- data_in = readl_relaxed(mvebu_gpioreg_data_in(mvchip));
- cause = readl_relaxed(mvebu_gpioreg_edge_cause(mvchip));
- edg_msk = readl_relaxed(mvebu_gpioreg_edge_mask(mvchip));
- lvl_msk = readl_relaxed(mvebu_gpioreg_level_mask(mvchip));
+ regmap_read(mvchip->regs, GPIO_OUT_OFF, &out);
+ regmap_read(mvchip->regs, GPIO_IO_CONF_OFF, &io_conf);
+ regmap_read(mvchip->regs, GPIO_BLINK_EN_OFF, &blink);
+ regmap_read(mvchip->regs, GPIO_IN_POL_OFF, &in_pol);
+ regmap_read(mvchip->regs, GPIO_DATA_IN_OFF, &data_in);
+ cause = mvebu_gpio_read_edge_cause(mvchip);
+ edg_msk = mvebu_gpio_read_edge_mask(mvchip);
+ lvl_msk = mvebu_gpio_read_level_mask(mvchip);
for (i = 0; i < chip->ngpio; i++) {
const char *label;
@@ -858,36 +894,36 @@ static int mvebu_gpio_suspend(struct platform_device *pdev, pm_message_t state)
struct mvebu_gpio_chip *mvchip = platform_get_drvdata(pdev);
int i;
- mvchip->out_reg = readl(mvebu_gpioreg_out(mvchip));
- mvchip->io_conf_reg = readl(mvebu_gpioreg_io_conf(mvchip));
- mvchip->blink_en_reg = readl(mvebu_gpioreg_blink(mvchip));
- mvchip->in_pol_reg = readl(mvebu_gpioreg_in_pol(mvchip));
+ regmap_read(mvchip->regs, GPIO_OUT_OFF, &mvchip->out_reg);
+ regmap_read(mvchip->regs, GPIO_IO_CONF_OFF, &mvchip->io_conf_reg);
+ regmap_read(mvchip->regs, GPIO_BLINK_EN_OFF, &mvchip->blink_en_reg);
+ regmap_read(mvchip->regs, GPIO_IN_POL_OFF, &mvchip->in_pol_reg);
switch (mvchip->soc_variant) {
case MVEBU_GPIO_SOC_VARIANT_ORION:
- mvchip->edge_mask_regs[0] =
- readl(mvchip->membase + GPIO_EDGE_MASK_OFF);
- mvchip->level_mask_regs[0] =
- readl(mvchip->membase + GPIO_LEVEL_MASK_OFF);
+ regmap_read(mvchip->regs, GPIO_EDGE_MASK_OFF,
+ &mvchip->edge_mask_regs[0]);
+ regmap_read(mvchip->regs, GPIO_LEVEL_MASK_OFF,
+ &mvchip->level_mask_regs[0]);
break;
case MVEBU_GPIO_SOC_VARIANT_MV78200:
for (i = 0; i < 2; i++) {
- mvchip->edge_mask_regs[i] =
- readl(mvchip->membase +
- GPIO_EDGE_MASK_MV78200_OFF(i));
- mvchip->level_mask_regs[i] =
- readl(mvchip->membase +
- GPIO_LEVEL_MASK_MV78200_OFF(i));
+ regmap_read(mvchip->regs,
+ GPIO_EDGE_MASK_MV78200_OFF(i),
+ &mvchip->edge_mask_regs[i]);
+ regmap_read(mvchip->regs,
+ GPIO_LEVEL_MASK_MV78200_OFF(i),
+ &mvchip->level_mask_regs[i]);
}
break;
case MVEBU_GPIO_SOC_VARIANT_ARMADAXP:
for (i = 0; i < 4; i++) {
- mvchip->edge_mask_regs[i] =
- readl(mvchip->membase +
- GPIO_EDGE_MASK_ARMADAXP_OFF(i));
- mvchip->level_mask_regs[i] =
- readl(mvchip->membase +
- GPIO_LEVEL_MASK_ARMADAXP_OFF(i));
+ regmap_read(mvchip->regs,
+ GPIO_EDGE_MASK_ARMADAXP_OFF(i),
+ &mvchip->edge_mask_regs[i]);
+ regmap_read(mvchip->regs,
+ GPIO_LEVEL_MASK_ARMADAXP_OFF(i),
+ &mvchip->level_mask_regs[i]);
}
break;
default:
@@ -905,35 +941,36 @@ static int mvebu_gpio_resume(struct platform_device *pdev)
struct mvebu_gpio_chip *mvchip = platform_get_drvdata(pdev);
int i;
- writel(mvchip->out_reg, mvebu_gpioreg_out(mvchip));
- writel(mvchip->io_conf_reg, mvebu_gpioreg_io_conf(mvchip));
- writel(mvchip->blink_en_reg, mvebu_gpioreg_blink(mvchip));
- writel(mvchip->in_pol_reg, mvebu_gpioreg_in_pol(mvchip));
+ regmap_write(mvchip->regs, GPIO_OUT_OFF, mvchip->out_reg);
+ regmap_write(mvchip->regs, GPIO_IO_CONF_OFF, mvchip->io_conf_reg);
+ regmap_write(mvchip->regs, GPIO_BLINK_EN_OFF, mvchip->blink_en_reg);
+ regmap_write(mvchip->regs, GPIO_IN_POL_OFF, mvchip->in_pol_reg);
switch (mvchip->soc_variant) {
case MVEBU_GPIO_SOC_VARIANT_ORION:
- writel(mvchip->edge_mask_regs[0],
- mvchip->membase + GPIO_EDGE_MASK_OFF);
- writel(mvchip->level_mask_regs[0],
- mvchip->membase + GPIO_LEVEL_MASK_OFF);
+ regmap_write(mvchip->regs, GPIO_EDGE_MASK_OFF,
+ mvchip->edge_mask_regs[0]);
+ regmap_write(mvchip->regs, GPIO_LEVEL_MASK_OFF,
+ mvchip->level_mask_regs[0]);
break;
case MVEBU_GPIO_SOC_VARIANT_MV78200:
for (i = 0; i < 2; i++) {
- writel(mvchip->edge_mask_regs[i],
- mvchip->membase + GPIO_EDGE_MASK_MV78200_OFF(i));
- writel(mvchip->level_mask_regs[i],
- mvchip->membase +
- GPIO_LEVEL_MASK_MV78200_OFF(i));
+ regmap_write(mvchip->regs,
+ GPIO_EDGE_MASK_MV78200_OFF(i),
+ mvchip->edge_mask_regs[i]);
+ regmap_write(mvchip->regs,
+ GPIO_LEVEL_MASK_MV78200_OFF(i),
+ mvchip->level_mask_regs[i]);
}
break;
case MVEBU_GPIO_SOC_VARIANT_ARMADAXP:
for (i = 0; i < 4; i++) {
- writel(mvchip->edge_mask_regs[i],
- mvchip->membase +
- GPIO_EDGE_MASK_ARMADAXP_OFF(i));
- writel(mvchip->level_mask_regs[i],
- mvchip->membase +
- GPIO_LEVEL_MASK_ARMADAXP_OFF(i));
+ regmap_write(mvchip->regs,
+ GPIO_EDGE_MASK_ARMADAXP_OFF(i),
+ mvchip->edge_mask_regs[i]);
+ regmap_write(mvchip->regs,
+ GPIO_LEVEL_MASK_ARMADAXP_OFF(i),
+ mvchip->level_mask_regs[i]);
}
break;
default:
@@ -946,6 +983,13 @@ static int mvebu_gpio_resume(struct platform_device *pdev)
return 0;
}
+static const struct regmap_config mvebu_gpio_regmap_config = {
+ .reg_bits = 32,
+ .reg_stride = 4,
+ .val_bits = 32,
+ .fast_io = true,
+};
+
static int mvebu_gpio_probe(struct platform_device *pdev)
{
struct mvebu_gpio_chip *mvchip;
@@ -954,6 +998,7 @@ static int mvebu_gpio_probe(struct platform_device *pdev)
struct resource *res;
struct irq_chip_generic *gc;
struct irq_chip_type *ct;
+ void __iomem *base;
unsigned int ngpios;
bool have_irqs;
int soc_variant;
@@ -1009,11 +1054,15 @@ static int mvebu_gpio_probe(struct platform_device *pdev)
mvchip->chip.of_node = np;
mvchip->chip.dbg_show = mvebu_gpio_dbg_show;
- spin_lock_init(&mvchip->lock);
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- mvchip->membase = devm_ioremap_resource(&pdev->dev, res);
- if (IS_ERR(mvchip->membase))
- return PTR_ERR(mvchip->membase);
+ base = devm_ioremap_resource(&pdev->dev, res);
+ if (IS_ERR(base))
+ return PTR_ERR(base);
+
+ mvchip->regs = devm_regmap_init_mmio(&pdev->dev, base,
+ &mvebu_gpio_regmap_config);
+ if (IS_ERR(mvchip->regs))
+ return PTR_ERR(mvchip->regs);
/*
* The Armada XP has a second range of registers for the
@@ -1021,10 +1070,15 @@ static int mvebu_gpio_probe(struct platform_device *pdev)
*/
if (soc_variant == MVEBU_GPIO_SOC_VARIANT_ARMADAXP) {
res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
- mvchip->percpu_membase = devm_ioremap_resource(&pdev->dev,
- res);
- if (IS_ERR(mvchip->percpu_membase))
- return PTR_ERR(mvchip->percpu_membase);
+ base = devm_ioremap_resource(&pdev->dev, res);
+ if (IS_ERR(base))
+ return PTR_ERR(base);
+
+ mvchip->percpu_regs =
+ devm_regmap_init_mmio(&pdev->dev, base,
+ &mvebu_gpio_regmap_config);
+ if (IS_ERR(mvchip->percpu_regs))
+ return PTR_ERR(mvchip->percpu_regs);
}
/*
@@ -1032,30 +1086,30 @@ static int mvebu_gpio_probe(struct platform_device *pdev)
*/
switch (soc_variant) {
case MVEBU_GPIO_SOC_VARIANT_ORION:
- writel_relaxed(0, mvchip->membase + GPIO_EDGE_CAUSE_OFF);
- writel_relaxed(0, mvchip->membase + GPIO_EDGE_MASK_OFF);
- writel_relaxed(0, mvchip->membase + GPIO_LEVEL_MASK_OFF);
+ regmap_write(mvchip->regs, GPIO_EDGE_CAUSE_OFF, 0);
+ regmap_write(mvchip->regs, GPIO_EDGE_MASK_OFF, 0);
+ regmap_write(mvchip->regs, GPIO_LEVEL_MASK_OFF, 0);
break;
case MVEBU_GPIO_SOC_VARIANT_MV78200:
- writel_relaxed(0, mvchip->membase + GPIO_EDGE_CAUSE_OFF);
+ regmap_write(mvchip->regs, GPIO_EDGE_CAUSE_OFF, 0);
for (cpu = 0; cpu < 2; cpu++) {
- writel_relaxed(0, mvchip->membase +
- GPIO_EDGE_MASK_MV78200_OFF(cpu));
- writel_relaxed(0, mvchip->membase +
- GPIO_LEVEL_MASK_MV78200_OFF(cpu));
+ regmap_write(mvchip->regs,
+ GPIO_EDGE_MASK_MV78200_OFF(cpu), 0);
+ regmap_write(mvchip->regs,
+ GPIO_LEVEL_MASK_MV78200_OFF(cpu), 0);
}
break;
case MVEBU_GPIO_SOC_VARIANT_ARMADAXP:
- writel_relaxed(0, mvchip->membase + GPIO_EDGE_CAUSE_OFF);
- writel_relaxed(0, mvchip->membase + GPIO_EDGE_MASK_OFF);
- writel_relaxed(0, mvchip->membase + GPIO_LEVEL_MASK_OFF);
+ regmap_write(mvchip->regs, GPIO_EDGE_CAUSE_OFF, 0);
+ regmap_write(mvchip->regs, GPIO_EDGE_MASK_OFF, 0);
+ regmap_write(mvchip->regs, GPIO_LEVEL_MASK_OFF, 0);
for (cpu = 0; cpu < 4; cpu++) {
- writel_relaxed(0, mvchip->percpu_membase +
- GPIO_EDGE_CAUSE_ARMADAXP_OFF(cpu));
- writel_relaxed(0, mvchip->percpu_membase +
- GPIO_EDGE_MASK_ARMADAXP_OFF(cpu));
- writel_relaxed(0, mvchip->percpu_membase +
- GPIO_LEVEL_MASK_ARMADAXP_OFF(cpu));
+ regmap_write(mvchip->percpu_regs,
+ GPIO_EDGE_CAUSE_ARMADAXP_OFF(cpu), 0);
+ regmap_write(mvchip->percpu_regs,
+ GPIO_EDGE_MASK_ARMADAXP_OFF(cpu), 0);
+ regmap_write(mvchip->percpu_regs,
+ GPIO_LEVEL_MASK_ARMADAXP_OFF(cpu), 0);
}
break;
default:
--
git-series 0.9.1
^ permalink raw reply related [flat|nested] 65+ messages in thread
* [PATCH 3/6] gpio: dt-bindings: Add documentation for gpio controllers on Armada 7K/8K
2017-05-19 16:09 ` Gregory CLEMENT
@ 2017-05-19 16:09 ` Gregory CLEMENT
-1 siblings, 0 replies; 65+ messages in thread
From: Gregory CLEMENT @ 2017-05-19 16:09 UTC (permalink / raw)
To: Linus Walleij, Alexandre Courbot, linux-gpio, linux-kernel
Cc: Jason Cooper, Andrew Lunn, Sebastian Hesselbarth,
Gregory CLEMENT, Thomas Petazzoni, linux-arm-kernel, Rob Herring,
devicetree, Russell King, Nadav Haklai, Kostya Porotchkin,
Neta Zur Hershkovits, Marcin Wojtas, Omri Itach, Shadi Ammouri
Document the device tree binding for the gpio controllers found on the
Marvell Armada 7K and Armada 8K SoCs.
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
Documentation/devicetree/bindings/arm/marvell/ap806-system-controller.txt | 20 ++++++++++++++++++++
Documentation/devicetree/bindings/arm/marvell/cp110-system-controller0.txt | 24 +++++++++++++++++++++++-
Documentation/devicetree/bindings/gpio/gpio-mvebu.txt | 24 +++++++++++++++++-------
3 files changed, 60 insertions(+), 8 deletions(-)
diff --git a/Documentation/devicetree/bindings/arm/marvell/ap806-system-controller.txt b/Documentation/devicetree/bindings/arm/marvell/ap806-system-controller.txt
index 4228d158fb31..0b887440e08a 100644
--- a/Documentation/devicetree/bindings/arm/marvell/ap806-system-controller.txt
+++ b/Documentation/devicetree/bindings/arm/marvell/ap806-system-controller.txt
@@ -64,6 +64,17 @@ mpp17 17 gpio
mpp18 18 gpio
mpp19 19 gpio, uart0(rxd), sdio(pw_off)
+GPIO:
+-----
+For common binding part and usage, refer to
+Documentation/devicetree/bindings/gpio/gpio-mvebu.txt.
+
+Required properties:
+
+- compatible: "marvell,armada-8k-gpio"
+
+- offset: offset address inside the syscon block
+
Example:
ap_syscon: system-controller@6f4000 {
compatible = "syscon", "simple-mfd";
@@ -77,4 +88,13 @@ ap_syscon: system-controller@6f4000 {
ap_pinctrl: pinctrl {
compatible = "marvell,ap806-pinctrl";
};
+
+ ap_gpio: gpio {
+ compatible = "marvell,armada-8k-gpio";
+ offset = <0x1040>;
+ ngpios = <19>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ gpio-ranges = <&ap_pinctrl 0 0 19>;
+ };
};
diff --git a/Documentation/devicetree/bindings/arm/marvell/cp110-system-controller0.txt b/Documentation/devicetree/bindings/arm/marvell/cp110-system-controller0.txt
index 733beac7724e..655c114ef584 100644
--- a/Documentation/devicetree/bindings/arm/marvell/cp110-system-controller0.txt
+++ b/Documentation/devicetree/bindings/arm/marvell/cp110-system-controller0.txt
@@ -149,6 +149,18 @@ mpp60 60 gpio, mss_gpio6, ptp(pulse), tdm(dtx), au(i2smclk), spi0(csn1), uart0(r
mpp61 61 gpio, mss_gpio5, ptp(clk), tdm(pclk), au(i2sextclk), spi0(csn2), uart0(txd), uart2(txd), sata1(present_act), ge(mdio), sdio(d3)
mpp62 62 gpio, mss_gpio4, synce1(clk), ptp(pclk_out), sata1(present_act), spi0(csn3), uart0(rxd), uart2(rxd), sata0(present_act), ge(mdc)
+GPIO:
+-----
+
+For common binding part and usage, refer to
+Documentation/devicetree/bindings/gpio/gpio-mvebu.txt.
+
+Required properties:
+
+- compatible: "marvell,armada-8k-gpio"
+
+- offset: offset address inside the syscon block
+
Example:
cpm_syscon0: system-controller@440000 {
@@ -163,5 +175,15 @@ cpm_syscon0: system-controller@440000 {
cpm_pinctrl: pinctrl {
compatible = "marvell,armada-8k-cpm-pinctrl";
};
-};
+ cpm_gpio1: gpio@100 {
+ compatible = "marvell,armada-8k-gpio";
+ offset = <0x100>;
+ ngpios = <32>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ gpio-ranges = <&cpm_pinctrl 0 0 32>;
+ status = "disabled";
+ };
+
+};
diff --git a/Documentation/devicetree/bindings/gpio/gpio-mvebu.txt b/Documentation/devicetree/bindings/gpio/gpio-mvebu.txt
index 42c3bb2d53e8..2c5304ff467c 100644
--- a/Documentation/devicetree/bindings/gpio/gpio-mvebu.txt
+++ b/Documentation/devicetree/bindings/gpio/gpio-mvebu.txt
@@ -2,17 +2,27 @@
Required properties:
-- compatible : Should be "marvell,orion-gpio", "marvell,mv78200-gpio"
- or "marvell,armadaxp-gpio". "marvell,orion-gpio" should be used for
- Orion, Kirkwood, Dove, Discovery (except MV78200) and Armada
- 370. "marvell,mv78200-gpio" should be used for the Discovery
- MV78200. "marvel,armadaxp-gpio" should be used for all Armada XP
- SoCs (MV78230, MV78260, MV78460).
+- compatible : Should be "marvell,orion-gpio", "marvell,mv78200-gpio",
+ "marvell,armadaxp-gpio" or "marvell,armada-8k-gpio".
+
+ "marvell,orion-gpio" should be used for Orion, Kirkwood, Dove,
+ Discovery (except MV78200) and Armada 370. "marvell,mv78200-gpio"
+ should be used for the Discovery MV78200.
+
+ "marvel,armadaxp-gpio" should be used for all Armada XP SoCs
+ (MV78230, MV78260, MV78460).
+
+ "marvell,armada-8k-gpio" should be used for the Armada 7K and 8K
+ SoCs (either from AP or CP), see
+ Documentation/devicetree/bindings/arm/marvell/cp110-system-controller0.txt
+ and
+ Documentation/devicetree/bindings/arm/marvell/ap806-system-controller.txt
+ for specific details about the offset property.
- reg: Address and length of the register set for the device. Only one
entry is expected, except for the "marvell,armadaxp-gpio" variant
for which two entries are expected: one for the general registers,
- one for the per-cpu registers.
+ one for the per-cpu registers. Not used for marvell,armada-8k-gpio.
- interrupts: The list of interrupts that are used for all the pins
managed by this GPIO bank. There can be more than one interrupt
--
git-series 0.9.1
^ permalink raw reply related [flat|nested] 65+ messages in thread
* [PATCH 3/6] gpio: dt-bindings: Add documentation for gpio controllers on Armada 7K/8K
@ 2017-05-19 16:09 ` Gregory CLEMENT
0 siblings, 0 replies; 65+ messages in thread
From: Gregory CLEMENT @ 2017-05-19 16:09 UTC (permalink / raw)
To: linux-arm-kernel
Document the device tree binding for the gpio controllers found on the
Marvell Armada 7K and Armada 8K SoCs.
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
Documentation/devicetree/bindings/arm/marvell/ap806-system-controller.txt | 20 ++++++++++++++++++++
Documentation/devicetree/bindings/arm/marvell/cp110-system-controller0.txt | 24 +++++++++++++++++++++++-
Documentation/devicetree/bindings/gpio/gpio-mvebu.txt | 24 +++++++++++++++++-------
3 files changed, 60 insertions(+), 8 deletions(-)
diff --git a/Documentation/devicetree/bindings/arm/marvell/ap806-system-controller.txt b/Documentation/devicetree/bindings/arm/marvell/ap806-system-controller.txt
index 4228d158fb31..0b887440e08a 100644
--- a/Documentation/devicetree/bindings/arm/marvell/ap806-system-controller.txt
+++ b/Documentation/devicetree/bindings/arm/marvell/ap806-system-controller.txt
@@ -64,6 +64,17 @@ mpp17 17 gpio
mpp18 18 gpio
mpp19 19 gpio, uart0(rxd), sdio(pw_off)
+GPIO:
+-----
+For common binding part and usage, refer to
+Documentation/devicetree/bindings/gpio/gpio-mvebu.txt.
+
+Required properties:
+
+- compatible: "marvell,armada-8k-gpio"
+
+- offset: offset address inside the syscon block
+
Example:
ap_syscon: system-controller at 6f4000 {
compatible = "syscon", "simple-mfd";
@@ -77,4 +88,13 @@ ap_syscon: system-controller at 6f4000 {
ap_pinctrl: pinctrl {
compatible = "marvell,ap806-pinctrl";
};
+
+ ap_gpio: gpio {
+ compatible = "marvell,armada-8k-gpio";
+ offset = <0x1040>;
+ ngpios = <19>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ gpio-ranges = <&ap_pinctrl 0 0 19>;
+ };
};
diff --git a/Documentation/devicetree/bindings/arm/marvell/cp110-system-controller0.txt b/Documentation/devicetree/bindings/arm/marvell/cp110-system-controller0.txt
index 733beac7724e..655c114ef584 100644
--- a/Documentation/devicetree/bindings/arm/marvell/cp110-system-controller0.txt
+++ b/Documentation/devicetree/bindings/arm/marvell/cp110-system-controller0.txt
@@ -149,6 +149,18 @@ mpp60 60 gpio, mss_gpio6, ptp(pulse), tdm(dtx), au(i2smclk), spi0(csn1), uart0(r
mpp61 61 gpio, mss_gpio5, ptp(clk), tdm(pclk), au(i2sextclk), spi0(csn2), uart0(txd), uart2(txd), sata1(present_act), ge(mdio), sdio(d3)
mpp62 62 gpio, mss_gpio4, synce1(clk), ptp(pclk_out), sata1(present_act), spi0(csn3), uart0(rxd), uart2(rxd), sata0(present_act), ge(mdc)
+GPIO:
+-----
+
+For common binding part and usage, refer to
+Documentation/devicetree/bindings/gpio/gpio-mvebu.txt.
+
+Required properties:
+
+- compatible: "marvell,armada-8k-gpio"
+
+- offset: offset address inside the syscon block
+
Example:
cpm_syscon0: system-controller at 440000 {
@@ -163,5 +175,15 @@ cpm_syscon0: system-controller at 440000 {
cpm_pinctrl: pinctrl {
compatible = "marvell,armada-8k-cpm-pinctrl";
};
-};
+ cpm_gpio1: gpio at 100 {
+ compatible = "marvell,armada-8k-gpio";
+ offset = <0x100>;
+ ngpios = <32>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ gpio-ranges = <&cpm_pinctrl 0 0 32>;
+ status = "disabled";
+ };
+
+};
diff --git a/Documentation/devicetree/bindings/gpio/gpio-mvebu.txt b/Documentation/devicetree/bindings/gpio/gpio-mvebu.txt
index 42c3bb2d53e8..2c5304ff467c 100644
--- a/Documentation/devicetree/bindings/gpio/gpio-mvebu.txt
+++ b/Documentation/devicetree/bindings/gpio/gpio-mvebu.txt
@@ -2,17 +2,27 @@
Required properties:
-- compatible : Should be "marvell,orion-gpio", "marvell,mv78200-gpio"
- or "marvell,armadaxp-gpio". "marvell,orion-gpio" should be used for
- Orion, Kirkwood, Dove, Discovery (except MV78200) and Armada
- 370. "marvell,mv78200-gpio" should be used for the Discovery
- MV78200. "marvel,armadaxp-gpio" should be used for all Armada XP
- SoCs (MV78230, MV78260, MV78460).
+- compatible : Should be "marvell,orion-gpio", "marvell,mv78200-gpio",
+ "marvell,armadaxp-gpio" or "marvell,armada-8k-gpio".
+
+ "marvell,orion-gpio" should be used for Orion, Kirkwood, Dove,
+ Discovery (except MV78200) and Armada 370. "marvell,mv78200-gpio"
+ should be used for the Discovery MV78200.
+
+ "marvel,armadaxp-gpio" should be used for all Armada XP SoCs
+ (MV78230, MV78260, MV78460).
+
+ "marvell,armada-8k-gpio" should be used for the Armada 7K and 8K
+ SoCs (either from AP or CP), see
+ Documentation/devicetree/bindings/arm/marvell/cp110-system-controller0.txt
+ and
+ Documentation/devicetree/bindings/arm/marvell/ap806-system-controller.txt
+ for specific details about the offset property.
- reg: Address and length of the register set for the device. Only one
entry is expected, except for the "marvell,armadaxp-gpio" variant
for which two entries are expected: one for the general registers,
- one for the per-cpu registers.
+ one for the per-cpu registers. Not used for marvell,armada-8k-gpio.
- interrupts: The list of interrupts that are used for all the pins
managed by this GPIO bank. There can be more than one interrupt
--
git-series 0.9.1
^ permalink raw reply related [flat|nested] 65+ messages in thread
* [PATCH 4/6] gpio: mvebu: allow building driver for Armada 7K/8K
2017-05-19 16:09 ` Gregory CLEMENT
(?)
@ 2017-05-19 16:09 ` Gregory CLEMENT
-1 siblings, 0 replies; 65+ messages in thread
From: Gregory CLEMENT @ 2017-05-19 16:09 UTC (permalink / raw)
To: Linus Walleij, Alexandre Courbot, linux-gpio, linux-kernel
Cc: Thomas Petazzoni, Andrew Lunn, Jason Cooper, devicetree,
Omri Itach, Nadav Haklai, Kostya Porotchkin, Russell King,
Rob Herring, Neta Zur Hershkovits, Gregory CLEMENT,
Shadi Ammouri, Marcin Wojtas, linux-arm-kernel,
Sebastian Hesselbarth
The mvebu gpio driver can also be used on arm64 mvebu SoC such as the
Armada 7K/8K. This commit allows to build the driver for them (when only
ARCH_MVEBU is defined)
Reviewed-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
drivers/gpio/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index 23ca51ee6b28..418316b82bd2 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -326,7 +326,7 @@ config GPIO_MPC8XXX
config GPIO_MVEBU
def_bool y
- depends on PLAT_ORION
+ depends on PLAT_ORION || ARCH_MVEBU
depends on OF_GPIO
select GENERIC_IRQ_CHIP
--
git-series 0.9.1
^ permalink raw reply related [flat|nested] 65+ messages in thread
* [PATCH 4/6] gpio: mvebu: allow building driver for Armada 7K/8K
@ 2017-05-19 16:09 ` Gregory CLEMENT
0 siblings, 0 replies; 65+ messages in thread
From: Gregory CLEMENT @ 2017-05-19 16:09 UTC (permalink / raw)
To: Linus Walleij, Alexandre Courbot, linux-gpio, linux-kernel
Cc: Jason Cooper, Andrew Lunn, Sebastian Hesselbarth,
Gregory CLEMENT, Thomas Petazzoni, linux-arm-kernel, Rob Herring,
devicetree, Russell King, Nadav Haklai, Kostya Porotchkin,
Neta Zur Hershkovits, Marcin Wojtas, Omri Itach, Shadi Ammouri
The mvebu gpio driver can also be used on arm64 mvebu SoC such as the
Armada 7K/8K. This commit allows to build the driver for them (when only
ARCH_MVEBU is defined)
Reviewed-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
drivers/gpio/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index 23ca51ee6b28..418316b82bd2 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -326,7 +326,7 @@ config GPIO_MPC8XXX
config GPIO_MVEBU
def_bool y
- depends on PLAT_ORION
+ depends on PLAT_ORION || ARCH_MVEBU
depends on OF_GPIO
select GENERIC_IRQ_CHIP
--
git-series 0.9.1
^ permalink raw reply related [flat|nested] 65+ messages in thread
* [PATCH 4/6] gpio: mvebu: allow building driver for Armada 7K/8K
@ 2017-05-19 16:09 ` Gregory CLEMENT
0 siblings, 0 replies; 65+ messages in thread
From: Gregory CLEMENT @ 2017-05-19 16:09 UTC (permalink / raw)
To: linux-arm-kernel
The mvebu gpio driver can also be used on arm64 mvebu SoC such as the
Armada 7K/8K. This commit allows to build the driver for them (when only
ARCH_MVEBU is defined)
Reviewed-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
drivers/gpio/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index 23ca51ee6b28..418316b82bd2 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -326,7 +326,7 @@ config GPIO_MPC8XXX
config GPIO_MVEBU
def_bool y
- depends on PLAT_ORION
+ depends on PLAT_ORION || ARCH_MVEBU
depends on OF_GPIO
select GENERIC_IRQ_CHIP
--
git-series 0.9.1
^ permalink raw reply related [flat|nested] 65+ messages in thread
* [PATCH 5/6] gpio: mvebu: Add support for the Armada 7K/8K SoCs
2017-05-19 16:09 ` Gregory CLEMENT
(?)
@ 2017-05-19 16:09 ` Gregory CLEMENT
-1 siblings, 0 replies; 65+ messages in thread
From: Gregory CLEMENT @ 2017-05-19 16:09 UTC (permalink / raw)
To: Linus Walleij, Alexandre Courbot,
linux-gpio-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
Cc: Jason Cooper, Andrew Lunn, Sebastian Hesselbarth,
Gregory CLEMENT, Thomas Petazzoni,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Rob Herring,
devicetree-u79uwXL29TY76Z2rM5mHXA, Russell King, Nadav Haklai,
Kostya Porotchkin, Neta Zur Hershkovits, Marcin Wojtas,
Omri Itach, Shadi Ammouri
The Armada 7K and 8K SoCs use the same gpio controller as most of the
other mvebu SoCs. However, the main difference is that the GPIO
controller is part of a bigger system controller, and a syscon is used to
control the overall system controller. Therefore, the driver needs to be
adjusted to retrieve the regmap of the syscon to access registers, and
account for the fact that registers are located at a certain offset
within the regmap.
This commit add the support of the syscon and introduce a new variant for
this case.
It was based on the preliminary work of Thomas Petazzoni.
Signed-off-by: Gregory CLEMENT <gregory.clement-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
---
drivers/gpio/gpio-mvebu.c | 212 +++++++++++++++++++++++++--------------
1 file changed, 141 insertions(+), 71 deletions(-)
diff --git a/drivers/gpio/gpio-mvebu.c b/drivers/gpio/gpio-mvebu.c
index 3d03740a20e7..5edb04abd7d7 100644
--- a/drivers/gpio/gpio-mvebu.c
+++ b/drivers/gpio/gpio-mvebu.c
@@ -42,6 +42,7 @@
#include <linux/irq.h>
#include <linux/irqchip/chained_irq.h>
#include <linux/irqdomain.h>
+#include <linux/mfd/syscon.h>
#include <linux/of_device.h>
#include <linux/of_irq.h>
#include <linux/pinctrl/consumer.h>
@@ -88,6 +89,7 @@
#define MVEBU_GPIO_SOC_VARIANT_ORION 0x1
#define MVEBU_GPIO_SOC_VARIANT_MV78200 0x2
#define MVEBU_GPIO_SOC_VARIANT_ARMADAXP 0x3
+#define MVEBU_GPIO_SOC_VARIANT_A8K 0x4
#define MVEBU_MAX_GPIO_PER_BANK 32
@@ -108,6 +110,7 @@ struct mvebu_pwm {
struct mvebu_gpio_chip {
struct gpio_chip chip;
struct regmap *regs;
+ u32 offset;
struct regmap *percpu_regs;
int irqbase;
struct irq_domain *domain;
@@ -139,8 +142,9 @@ static void mvebu_gpioreg_edge_cause(struct mvebu_gpio_chip *mvchip,
switch (mvchip->soc_variant) {
case MVEBU_GPIO_SOC_VARIANT_ORION:
case MVEBU_GPIO_SOC_VARIANT_MV78200:
+ case MVEBU_GPIO_SOC_VARIANT_A8K:
*map = mvchip->regs;
- *offset = GPIO_EDGE_CAUSE_OFF;
+ *offset = GPIO_EDGE_CAUSE_OFF + mvchip->offset;
break;
case MVEBU_GPIO_SOC_VARIANT_ARMADAXP:
cpu = smp_processor_id();
@@ -183,8 +187,9 @@ mvebu_gpioreg_edge_mask(struct mvebu_gpio_chip *mvchip,
switch (mvchip->soc_variant) {
case MVEBU_GPIO_SOC_VARIANT_ORION:
+ case MVEBU_GPIO_SOC_VARIANT_A8K:
*map = mvchip->regs;
- *offset = GPIO_EDGE_MASK_OFF;
+ *offset = GPIO_EDGE_MASK_OFF + mvchip->offset;
break;
case MVEBU_GPIO_SOC_VARIANT_MV78200:
cpu = smp_processor_id();
@@ -232,8 +237,9 @@ mvebu_gpioreg_level_mask(struct mvebu_gpio_chip *mvchip,
switch (mvchip->soc_variant) {
case MVEBU_GPIO_SOC_VARIANT_ORION:
+ case MVEBU_GPIO_SOC_VARIANT_A8K:
*map = mvchip->regs;
- *offset = GPIO_LEVEL_MASK_OFF;
+ *offset = GPIO_LEVEL_MASK_OFF + mvchip->offset;
break;
case MVEBU_GPIO_SOC_VARIANT_MV78200:
cpu = smp_processor_id();
@@ -294,7 +300,7 @@ static void mvebu_gpio_set(struct gpio_chip *chip, unsigned int pin, int value)
{
struct mvebu_gpio_chip *mvchip = gpiochip_get_data(chip);
- regmap_update_bits(mvchip->regs, GPIO_OUT_OFF,
+ regmap_update_bits(mvchip->regs, GPIO_OUT_OFF + mvchip->offset,
BIT(pin), value ? BIT(pin) : 0);
}
@@ -303,16 +309,18 @@ static int mvebu_gpio_get(struct gpio_chip *chip, unsigned int pin)
struct mvebu_gpio_chip *mvchip = gpiochip_get_data(chip);
u32 u;
- regmap_read(mvchip->regs, GPIO_IO_CONF_OFF, &u);
+ regmap_read(mvchip->regs, GPIO_IO_CONF_OFF + mvchip->offset, &u);
if (u & BIT(pin)) {
u32 data_in, in_pol;
- regmap_read(mvchip->regs, GPIO_DATA_IN_OFF, &data_in);
- regmap_read(mvchip->regs, GPIO_IN_POL_OFF, &in_pol);
+ regmap_read(mvchip->regs, GPIO_DATA_IN_OFF + mvchip->offset,
+ &data_in);
+ regmap_read(mvchip->regs, GPIO_IN_POL_OFF + mvchip->offset,
+ &in_pol);
u = data_in ^ in_pol;
} else {
- regmap_read(mvchip->regs, GPIO_OUT_OFF, &u);
+ regmap_read(mvchip->regs, GPIO_OUT_OFF + mvchip->offset, &u);
}
return (u >> pin) & 1;
@@ -323,7 +331,7 @@ static void mvebu_gpio_blink(struct gpio_chip *chip, unsigned int pin,
{
struct mvebu_gpio_chip *mvchip = gpiochip_get_data(chip);
- regmap_update_bits(mvchip->regs, GPIO_BLINK_EN_OFF,
+ regmap_update_bits(mvchip->regs, GPIO_BLINK_EN_OFF + mvchip->offset,
BIT(pin), value ? BIT(pin) : 0);
}
@@ -340,7 +348,7 @@ static int mvebu_gpio_direction_input(struct gpio_chip *chip, unsigned int pin)
if (ret)
return ret;
- regmap_update_bits(mvchip->regs, GPIO_IO_CONF_OFF,
+ regmap_update_bits(mvchip->regs, GPIO_IO_CONF_OFF + mvchip->offset,
BIT(pin), 1);
return 0;
@@ -363,7 +371,7 @@ static int mvebu_gpio_direction_output(struct gpio_chip *chip, unsigned int pin,
mvebu_gpio_blink(chip, pin, 0);
mvebu_gpio_set(chip, pin, value);
- regmap_update_bits(mvchip->regs, GPIO_IO_CONF_OFF,
+ regmap_update_bits(mvchip->regs, GPIO_IO_CONF_OFF + mvchip->offset,
BIT(pin), 0);
return 0;
@@ -478,7 +486,7 @@ static int mvebu_gpio_irq_set_type(struct irq_data *d, unsigned int type)
pin = d->hwirq;
- regmap_read(mvchip->regs, GPIO_IO_CONF_OFF, &u);
+ regmap_read(mvchip->regs, GPIO_IO_CONF_OFF + mvchip->offset, &u);
if ((u & BIT(pin)) == 0)
return -EINVAL;
@@ -497,19 +505,23 @@ static int mvebu_gpio_irq_set_type(struct irq_data *d, unsigned int type)
switch (type) {
case IRQ_TYPE_EDGE_RISING:
case IRQ_TYPE_LEVEL_HIGH:
- regmap_update_bits(mvchip->regs, GPIO_IN_POL_OFF,
+ regmap_update_bits(mvchip->regs,
+ GPIO_IN_POL_OFF + mvchip->offset,
BIT(pin), 0);
break;
case IRQ_TYPE_EDGE_FALLING:
case IRQ_TYPE_LEVEL_LOW:
- regmap_update_bits(mvchip->regs, GPIO_IN_POL_OFF,
+ regmap_update_bits(mvchip->regs,
+ GPIO_IN_POL_OFF + mvchip->offset,
BIT(pin), 1);
break;
case IRQ_TYPE_EDGE_BOTH: {
u32 data_in, in_pol, val;
- regmap_read(mvchip->regs, GPIO_IN_POL_OFF, &in_pol);
- regmap_read(mvchip->regs, GPIO_DATA_IN_OFF, &data_in);
+ regmap_read(mvchip->regs,
+ GPIO_IN_POL_OFF + mvchip->offset, &in_pol);
+ regmap_read(mvchip->regs,
+ GPIO_DATA_IN_OFF + mvchip->offset, &data_in);
/*
* set initial polarity based on current input level
@@ -519,7 +531,8 @@ static int mvebu_gpio_irq_set_type(struct irq_data *d, unsigned int type)
else
val = 0; /* raising */
- regmap_update_bits(mvchip->regs, GPIO_IN_POL_OFF,
+ regmap_update_bits(mvchip->regs,
+ GPIO_IN_POL_OFF + mvchip->offset,
BIT(pin), val);
break;
}
@@ -539,7 +552,7 @@ static void mvebu_gpio_irq_handler(struct irq_desc *desc)
chained_irq_enter(chip, desc);
- regmap_read(mvchip->regs, GPIO_DATA_IN_OFF, &data_in);
+ regmap_read(mvchip->regs, GPIO_DATA_IN_OFF + mvchip->offset, &data_in);
level_mask = mvebu_gpio_read_level_mask(mvchip);
edge_cause = mvebu_gpio_read_edge_cause(mvchip);
edge_mask = mvebu_gpio_read_edge_mask(mvchip);
@@ -559,9 +572,13 @@ static void mvebu_gpio_irq_handler(struct irq_desc *desc)
/* Swap polarity (race with GPIO line) */
u32 polarity;
- regmap_read(mvchip->regs, GPIO_IN_POL_OFF, &polarity);
+ regmap_read(mvchip->regs,
+ GPIO_IN_POL_OFF + mvchip->offset,
+ &polarity);
polarity ^= BIT(i);
- regmap_write(mvchip->regs, GPIO_IN_POL_OFF, polarity);
+ regmap_write(mvchip->regs,
+ GPIO_IN_POL_OFF + mvchip->offset,
+ polarity);
}
generic_handle_irq(irq);
@@ -664,7 +681,7 @@ static void mvebu_pwm_get_state(struct pwm_chip *chip,
state->period = 1;
}
- regmap_read(mvchip->regs, GPIO_BLINK_EN_OFF, &u);
+ regmap_read(mvchip->regs, GPIO_BLINK_EN_OFF + mvchip->offset, &u);
if (u)
state->enabled = true;
else
@@ -727,7 +744,7 @@ static void __maybe_unused mvebu_pwm_suspend(struct mvebu_gpio_chip *mvchip)
{
struct mvebu_pwm *mvpwm = mvchip->mvpwm;
- regmap_read(mvchip->regs, GPIO_BLINK_CNT_SELECT_OFF,
+ regmap_read(mvchip->regs, GPIO_BLINK_CNT_SELECT_OFF + mvchip->offset,
&mvpwm->blink_select);
mvpwm->blink_on_duration =
readl_relaxed(mvebu_pwmreg_blink_on_duration(mvpwm));
@@ -739,7 +756,7 @@ static void __maybe_unused mvebu_pwm_resume(struct mvebu_gpio_chip *mvchip)
{
struct mvebu_pwm *mvpwm = mvchip->mvpwm;
- regmap_write(mvchip->regs, GPIO_BLINK_CNT_SELECT_OFF,
+ regmap_write(mvchip->regs, GPIO_BLINK_CNT_SELECT_OFF + mvchip->offset,
mvpwm->blink_select);
writel_relaxed(mvpwm->blink_on_duration,
mvebu_pwmreg_blink_on_duration(mvpwm));
@@ -783,7 +800,8 @@ static int mvebu_pwm_probe(struct platform_device *pdev,
set = U32_MAX;
else
return -EINVAL;
- regmap_write(mvchip->regs, GPIO_BLINK_CNT_SELECT_OFF, 0);
+ regmap_write(mvchip->regs,
+ GPIO_BLINK_CNT_SELECT_OFF + mvchip->offset, 0);
mvpwm = devm_kzalloc(dev, sizeof(struct mvebu_pwm), GFP_KERNEL);
if (!mvpwm)
@@ -819,11 +837,11 @@ static void mvebu_gpio_dbg_show(struct seq_file *s, struct gpio_chip *chip)
u32 out, io_conf, blink, in_pol, data_in, cause, edg_msk, lvl_msk;
int i;
- regmap_read(mvchip->regs, GPIO_OUT_OFF, &out);
- regmap_read(mvchip->regs, GPIO_IO_CONF_OFF, &io_conf);
- regmap_read(mvchip->regs, GPIO_BLINK_EN_OFF, &blink);
- regmap_read(mvchip->regs, GPIO_IN_POL_OFF, &in_pol);
- regmap_read(mvchip->regs, GPIO_DATA_IN_OFF, &data_in);
+ regmap_read(mvchip->regs, GPIO_OUT_OFF + mvchip->offset, &out);
+ regmap_read(mvchip->regs, GPIO_IO_CONF_OFF + mvchip->offset, &io_conf);
+ regmap_read(mvchip->regs, GPIO_BLINK_EN_OFF + mvchip->offset, &blink);
+ regmap_read(mvchip->regs, GPIO_IN_POL_OFF + mvchip->offset, &in_pol);
+ regmap_read(mvchip->regs, GPIO_DATA_IN_OFF + mvchip->offset, &data_in);
cause = mvebu_gpio_read_edge_cause(mvchip);
edg_msk = mvebu_gpio_read_edge_mask(mvchip);
lvl_msk = mvebu_gpio_read_level_mask(mvchip);
@@ -885,6 +903,10 @@ static const struct of_device_id mvebu_gpio_of_match[] = {
.data = (void *) MVEBU_GPIO_SOC_VARIANT_ORION,
},
{
+ .compatible = "marvell,armada-8k-gpio",
+ .data = (void *) MVEBU_GPIO_SOC_VARIANT_A8K,
+ },
+ {
/* sentinel */
},
};
@@ -894,16 +916,21 @@ static int mvebu_gpio_suspend(struct platform_device *pdev, pm_message_t state)
struct mvebu_gpio_chip *mvchip = platform_get_drvdata(pdev);
int i;
- regmap_read(mvchip->regs, GPIO_OUT_OFF, &mvchip->out_reg);
- regmap_read(mvchip->regs, GPIO_IO_CONF_OFF, &mvchip->io_conf_reg);
- regmap_read(mvchip->regs, GPIO_BLINK_EN_OFF, &mvchip->blink_en_reg);
- regmap_read(mvchip->regs, GPIO_IN_POL_OFF, &mvchip->in_pol_reg);
+ regmap_read(mvchip->regs, GPIO_OUT_OFF + mvchip->offset,
+ &mvchip->out_reg);
+ regmap_read(mvchip->regs, GPIO_IO_CONF_OFF + mvchip->offset,
+ &mvchip->io_conf_reg);
+ regmap_read(mvchip->regs, GPIO_BLINK_EN_OFF + mvchip->offset,
+ &mvchip->blink_en_reg);
+ regmap_read(mvchip->regs, GPIO_IN_POL_OFF + mvchip->offset,
+ &mvchip->in_pol_reg);
switch (mvchip->soc_variant) {
case MVEBU_GPIO_SOC_VARIANT_ORION:
- regmap_read(mvchip->regs, GPIO_EDGE_MASK_OFF,
+ case MVEBU_GPIO_SOC_VARIANT_A8K:
+ regmap_read(mvchip->regs, GPIO_EDGE_MASK_OFF + mvchip->offset,
&mvchip->edge_mask_regs[0]);
- regmap_read(mvchip->regs, GPIO_LEVEL_MASK_OFF,
+ regmap_read(mvchip->regs, GPIO_LEVEL_MASK_OFF + mvchip->offset,
&mvchip->level_mask_regs[0]);
break;
case MVEBU_GPIO_SOC_VARIANT_MV78200:
@@ -941,16 +968,21 @@ static int mvebu_gpio_resume(struct platform_device *pdev)
struct mvebu_gpio_chip *mvchip = platform_get_drvdata(pdev);
int i;
- regmap_write(mvchip->regs, GPIO_OUT_OFF, mvchip->out_reg);
- regmap_write(mvchip->regs, GPIO_IO_CONF_OFF, mvchip->io_conf_reg);
- regmap_write(mvchip->regs, GPIO_BLINK_EN_OFF, mvchip->blink_en_reg);
- regmap_write(mvchip->regs, GPIO_IN_POL_OFF, mvchip->in_pol_reg);
+ regmap_write(mvchip->regs, GPIO_OUT_OFF + mvchip->offset,
+ mvchip->out_reg);
+ regmap_write(mvchip->regs, GPIO_IO_CONF_OFF + mvchip->offset,
+ mvchip->io_conf_reg);
+ regmap_write(mvchip->regs, GPIO_BLINK_EN_OFF + mvchip->offset,
+ mvchip->blink_en_reg);
+ regmap_write(mvchip->regs, GPIO_IN_POL_OFF + mvchip->offset,
+ mvchip->in_pol_reg);
switch (mvchip->soc_variant) {
case MVEBU_GPIO_SOC_VARIANT_ORION:
- regmap_write(mvchip->regs, GPIO_EDGE_MASK_OFF,
+ case MVEBU_GPIO_SOC_VARIANT_A8K:
+ regmap_write(mvchip->regs, GPIO_EDGE_MASK_OFF + mvchip->offset,
mvchip->edge_mask_regs[0]);
- regmap_write(mvchip->regs, GPIO_LEVEL_MASK_OFF,
+ regmap_write(mvchip->regs, GPIO_LEVEL_MASK_OFF + mvchip->offset,
mvchip->level_mask_regs[0]);
break;
case MVEBU_GPIO_SOC_VARIANT_MV78200:
@@ -990,15 +1022,68 @@ static const struct regmap_config mvebu_gpio_regmap_config = {
.fast_io = true,
};
+static int mvebu_gpio_probe_raw(struct platform_device *pdev,
+ struct mvebu_gpio_chip *mvchip)
+{
+ struct resource *res;
+ void __iomem *base;
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ base = devm_ioremap_resource(&pdev->dev, res);
+ if (IS_ERR(base))
+ return PTR_ERR(base);
+
+ mvchip->regs = devm_regmap_init_mmio(&pdev->dev, base,
+ &mvebu_gpio_regmap_config);
+ if (IS_ERR(mvchip->regs))
+ return PTR_ERR(mvchip->regs);
+
+ /*
+ * For the legacy SoCs, the regmap directly maps to the GPIO
+ * registers, so no offset is needed.
+ */
+ mvchip->offset = 0;
+
+ /*
+ * The Armada XP has a second range of registers for the
+ * per-CPU registers
+ */
+ if (mvchip->soc_variant == MVEBU_GPIO_SOC_VARIANT_ARMADAXP) {
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
+ base = devm_ioremap_resource(&pdev->dev, res);
+ if (IS_ERR(base))
+ return PTR_ERR(base);
+
+ mvchip->percpu_regs =
+ devm_regmap_init_mmio(&pdev->dev, base,
+ &mvebu_gpio_regmap_config);
+ if (IS_ERR(mvchip->percpu_regs))
+ return PTR_ERR(mvchip->percpu_regs);
+ }
+
+ return 0;
+}
+
+static int mvebu_gpio_probe_syscon(struct platform_device *pdev,
+ struct mvebu_gpio_chip *mvchip)
+{
+ mvchip->regs = syscon_node_to_regmap(pdev->dev.parent->of_node);
+ if (IS_ERR(mvchip->regs))
+ return PTR_ERR(mvchip->regs);
+
+ if (of_property_read_u32(pdev->dev.of_node, "offset", &mvchip->offset))
+ return -EINVAL;
+
+ return 0;
+}
+
static int mvebu_gpio_probe(struct platform_device *pdev)
{
struct mvebu_gpio_chip *mvchip;
const struct of_device_id *match;
struct device_node *np = pdev->dev.of_node;
- struct resource *res;
struct irq_chip_generic *gc;
struct irq_chip_type *ct;
- void __iomem *base;
unsigned int ngpios;
bool have_irqs;
int soc_variant;
@@ -1054,41 +1139,26 @@ static int mvebu_gpio_probe(struct platform_device *pdev)
mvchip->chip.of_node = np;
mvchip->chip.dbg_show = mvebu_gpio_dbg_show;
- res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- base = devm_ioremap_resource(&pdev->dev, res);
- if (IS_ERR(base))
- return PTR_ERR(base);
-
- mvchip->regs = devm_regmap_init_mmio(&pdev->dev, base,
- &mvebu_gpio_regmap_config);
- if (IS_ERR(mvchip->regs))
- return PTR_ERR(mvchip->regs);
+ if (soc_variant == MVEBU_GPIO_SOC_VARIANT_A8K)
+ err = mvebu_gpio_probe_syscon(pdev, mvchip);
+ else
+ err = mvebu_gpio_probe_raw(pdev, mvchip);
- /*
- * The Armada XP has a second range of registers for the
- * per-CPU registers
- */
- if (soc_variant == MVEBU_GPIO_SOC_VARIANT_ARMADAXP) {
- res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
- base = devm_ioremap_resource(&pdev->dev, res);
- if (IS_ERR(base))
- return PTR_ERR(base);
-
- mvchip->percpu_regs =
- devm_regmap_init_mmio(&pdev->dev, base,
- &mvebu_gpio_regmap_config);
- if (IS_ERR(mvchip->percpu_regs))
- return PTR_ERR(mvchip->percpu_regs);
- }
+ if (err)
+ return err;
/*
* Mask and clear GPIO interrupts.
*/
switch (soc_variant) {
case MVEBU_GPIO_SOC_VARIANT_ORION:
- regmap_write(mvchip->regs, GPIO_EDGE_CAUSE_OFF, 0);
- regmap_write(mvchip->regs, GPIO_EDGE_MASK_OFF, 0);
- regmap_write(mvchip->regs, GPIO_LEVEL_MASK_OFF, 0);
+ case MVEBU_GPIO_SOC_VARIANT_A8K:
+ regmap_write(mvchip->regs,
+ GPIO_EDGE_CAUSE_OFF + mvchip->offset, 0);
+ regmap_write(mvchip->regs,
+ GPIO_EDGE_MASK_OFF + mvchip->offset, 0);
+ regmap_write(mvchip->regs,
+ GPIO_LEVEL_MASK_OFF + mvchip->offset, 0);
break;
case MVEBU_GPIO_SOC_VARIANT_MV78200:
regmap_write(mvchip->regs, GPIO_EDGE_CAUSE_OFF, 0);
--
git-series 0.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related [flat|nested] 65+ messages in thread
* [PATCH 5/6] gpio: mvebu: Add support for the Armada 7K/8K SoCs
@ 2017-05-19 16:09 ` Gregory CLEMENT
0 siblings, 0 replies; 65+ messages in thread
From: Gregory CLEMENT @ 2017-05-19 16:09 UTC (permalink / raw)
To: Linus Walleij, Alexandre Courbot, linux-gpio, linux-kernel
Cc: Jason Cooper, Andrew Lunn, Sebastian Hesselbarth,
Gregory CLEMENT, Thomas Petazzoni, linux-arm-kernel, Rob Herring,
devicetree, Russell King, Nadav Haklai, Kostya Porotchkin,
Neta Zur Hershkovits, Marcin Wojtas, Omri Itach, Shadi Ammouri
The Armada 7K and 8K SoCs use the same gpio controller as most of the
other mvebu SoCs. However, the main difference is that the GPIO
controller is part of a bigger system controller, and a syscon is used to
control the overall system controller. Therefore, the driver needs to be
adjusted to retrieve the regmap of the syscon to access registers, and
account for the fact that registers are located at a certain offset
within the regmap.
This commit add the support of the syscon and introduce a new variant for
this case.
It was based on the preliminary work of Thomas Petazzoni.
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
drivers/gpio/gpio-mvebu.c | 212 +++++++++++++++++++++++++--------------
1 file changed, 141 insertions(+), 71 deletions(-)
diff --git a/drivers/gpio/gpio-mvebu.c b/drivers/gpio/gpio-mvebu.c
index 3d03740a20e7..5edb04abd7d7 100644
--- a/drivers/gpio/gpio-mvebu.c
+++ b/drivers/gpio/gpio-mvebu.c
@@ -42,6 +42,7 @@
#include <linux/irq.h>
#include <linux/irqchip/chained_irq.h>
#include <linux/irqdomain.h>
+#include <linux/mfd/syscon.h>
#include <linux/of_device.h>
#include <linux/of_irq.h>
#include <linux/pinctrl/consumer.h>
@@ -88,6 +89,7 @@
#define MVEBU_GPIO_SOC_VARIANT_ORION 0x1
#define MVEBU_GPIO_SOC_VARIANT_MV78200 0x2
#define MVEBU_GPIO_SOC_VARIANT_ARMADAXP 0x3
+#define MVEBU_GPIO_SOC_VARIANT_A8K 0x4
#define MVEBU_MAX_GPIO_PER_BANK 32
@@ -108,6 +110,7 @@ struct mvebu_pwm {
struct mvebu_gpio_chip {
struct gpio_chip chip;
struct regmap *regs;
+ u32 offset;
struct regmap *percpu_regs;
int irqbase;
struct irq_domain *domain;
@@ -139,8 +142,9 @@ static void mvebu_gpioreg_edge_cause(struct mvebu_gpio_chip *mvchip,
switch (mvchip->soc_variant) {
case MVEBU_GPIO_SOC_VARIANT_ORION:
case MVEBU_GPIO_SOC_VARIANT_MV78200:
+ case MVEBU_GPIO_SOC_VARIANT_A8K:
*map = mvchip->regs;
- *offset = GPIO_EDGE_CAUSE_OFF;
+ *offset = GPIO_EDGE_CAUSE_OFF + mvchip->offset;
break;
case MVEBU_GPIO_SOC_VARIANT_ARMADAXP:
cpu = smp_processor_id();
@@ -183,8 +187,9 @@ mvebu_gpioreg_edge_mask(struct mvebu_gpio_chip *mvchip,
switch (mvchip->soc_variant) {
case MVEBU_GPIO_SOC_VARIANT_ORION:
+ case MVEBU_GPIO_SOC_VARIANT_A8K:
*map = mvchip->regs;
- *offset = GPIO_EDGE_MASK_OFF;
+ *offset = GPIO_EDGE_MASK_OFF + mvchip->offset;
break;
case MVEBU_GPIO_SOC_VARIANT_MV78200:
cpu = smp_processor_id();
@@ -232,8 +237,9 @@ mvebu_gpioreg_level_mask(struct mvebu_gpio_chip *mvchip,
switch (mvchip->soc_variant) {
case MVEBU_GPIO_SOC_VARIANT_ORION:
+ case MVEBU_GPIO_SOC_VARIANT_A8K:
*map = mvchip->regs;
- *offset = GPIO_LEVEL_MASK_OFF;
+ *offset = GPIO_LEVEL_MASK_OFF + mvchip->offset;
break;
case MVEBU_GPIO_SOC_VARIANT_MV78200:
cpu = smp_processor_id();
@@ -294,7 +300,7 @@ static void mvebu_gpio_set(struct gpio_chip *chip, unsigned int pin, int value)
{
struct mvebu_gpio_chip *mvchip = gpiochip_get_data(chip);
- regmap_update_bits(mvchip->regs, GPIO_OUT_OFF,
+ regmap_update_bits(mvchip->regs, GPIO_OUT_OFF + mvchip->offset,
BIT(pin), value ? BIT(pin) : 0);
}
@@ -303,16 +309,18 @@ static int mvebu_gpio_get(struct gpio_chip *chip, unsigned int pin)
struct mvebu_gpio_chip *mvchip = gpiochip_get_data(chip);
u32 u;
- regmap_read(mvchip->regs, GPIO_IO_CONF_OFF, &u);
+ regmap_read(mvchip->regs, GPIO_IO_CONF_OFF + mvchip->offset, &u);
if (u & BIT(pin)) {
u32 data_in, in_pol;
- regmap_read(mvchip->regs, GPIO_DATA_IN_OFF, &data_in);
- regmap_read(mvchip->regs, GPIO_IN_POL_OFF, &in_pol);
+ regmap_read(mvchip->regs, GPIO_DATA_IN_OFF + mvchip->offset,
+ &data_in);
+ regmap_read(mvchip->regs, GPIO_IN_POL_OFF + mvchip->offset,
+ &in_pol);
u = data_in ^ in_pol;
} else {
- regmap_read(mvchip->regs, GPIO_OUT_OFF, &u);
+ regmap_read(mvchip->regs, GPIO_OUT_OFF + mvchip->offset, &u);
}
return (u >> pin) & 1;
@@ -323,7 +331,7 @@ static void mvebu_gpio_blink(struct gpio_chip *chip, unsigned int pin,
{
struct mvebu_gpio_chip *mvchip = gpiochip_get_data(chip);
- regmap_update_bits(mvchip->regs, GPIO_BLINK_EN_OFF,
+ regmap_update_bits(mvchip->regs, GPIO_BLINK_EN_OFF + mvchip->offset,
BIT(pin), value ? BIT(pin) : 0);
}
@@ -340,7 +348,7 @@ static int mvebu_gpio_direction_input(struct gpio_chip *chip, unsigned int pin)
if (ret)
return ret;
- regmap_update_bits(mvchip->regs, GPIO_IO_CONF_OFF,
+ regmap_update_bits(mvchip->regs, GPIO_IO_CONF_OFF + mvchip->offset,
BIT(pin), 1);
return 0;
@@ -363,7 +371,7 @@ static int mvebu_gpio_direction_output(struct gpio_chip *chip, unsigned int pin,
mvebu_gpio_blink(chip, pin, 0);
mvebu_gpio_set(chip, pin, value);
- regmap_update_bits(mvchip->regs, GPIO_IO_CONF_OFF,
+ regmap_update_bits(mvchip->regs, GPIO_IO_CONF_OFF + mvchip->offset,
BIT(pin), 0);
return 0;
@@ -478,7 +486,7 @@ static int mvebu_gpio_irq_set_type(struct irq_data *d, unsigned int type)
pin = d->hwirq;
- regmap_read(mvchip->regs, GPIO_IO_CONF_OFF, &u);
+ regmap_read(mvchip->regs, GPIO_IO_CONF_OFF + mvchip->offset, &u);
if ((u & BIT(pin)) == 0)
return -EINVAL;
@@ -497,19 +505,23 @@ static int mvebu_gpio_irq_set_type(struct irq_data *d, unsigned int type)
switch (type) {
case IRQ_TYPE_EDGE_RISING:
case IRQ_TYPE_LEVEL_HIGH:
- regmap_update_bits(mvchip->regs, GPIO_IN_POL_OFF,
+ regmap_update_bits(mvchip->regs,
+ GPIO_IN_POL_OFF + mvchip->offset,
BIT(pin), 0);
break;
case IRQ_TYPE_EDGE_FALLING:
case IRQ_TYPE_LEVEL_LOW:
- regmap_update_bits(mvchip->regs, GPIO_IN_POL_OFF,
+ regmap_update_bits(mvchip->regs,
+ GPIO_IN_POL_OFF + mvchip->offset,
BIT(pin), 1);
break;
case IRQ_TYPE_EDGE_BOTH: {
u32 data_in, in_pol, val;
- regmap_read(mvchip->regs, GPIO_IN_POL_OFF, &in_pol);
- regmap_read(mvchip->regs, GPIO_DATA_IN_OFF, &data_in);
+ regmap_read(mvchip->regs,
+ GPIO_IN_POL_OFF + mvchip->offset, &in_pol);
+ regmap_read(mvchip->regs,
+ GPIO_DATA_IN_OFF + mvchip->offset, &data_in);
/*
* set initial polarity based on current input level
@@ -519,7 +531,8 @@ static int mvebu_gpio_irq_set_type(struct irq_data *d, unsigned int type)
else
val = 0; /* raising */
- regmap_update_bits(mvchip->regs, GPIO_IN_POL_OFF,
+ regmap_update_bits(mvchip->regs,
+ GPIO_IN_POL_OFF + mvchip->offset,
BIT(pin), val);
break;
}
@@ -539,7 +552,7 @@ static void mvebu_gpio_irq_handler(struct irq_desc *desc)
chained_irq_enter(chip, desc);
- regmap_read(mvchip->regs, GPIO_DATA_IN_OFF, &data_in);
+ regmap_read(mvchip->regs, GPIO_DATA_IN_OFF + mvchip->offset, &data_in);
level_mask = mvebu_gpio_read_level_mask(mvchip);
edge_cause = mvebu_gpio_read_edge_cause(mvchip);
edge_mask = mvebu_gpio_read_edge_mask(mvchip);
@@ -559,9 +572,13 @@ static void mvebu_gpio_irq_handler(struct irq_desc *desc)
/* Swap polarity (race with GPIO line) */
u32 polarity;
- regmap_read(mvchip->regs, GPIO_IN_POL_OFF, &polarity);
+ regmap_read(mvchip->regs,
+ GPIO_IN_POL_OFF + mvchip->offset,
+ &polarity);
polarity ^= BIT(i);
- regmap_write(mvchip->regs, GPIO_IN_POL_OFF, polarity);
+ regmap_write(mvchip->regs,
+ GPIO_IN_POL_OFF + mvchip->offset,
+ polarity);
}
generic_handle_irq(irq);
@@ -664,7 +681,7 @@ static void mvebu_pwm_get_state(struct pwm_chip *chip,
state->period = 1;
}
- regmap_read(mvchip->regs, GPIO_BLINK_EN_OFF, &u);
+ regmap_read(mvchip->regs, GPIO_BLINK_EN_OFF + mvchip->offset, &u);
if (u)
state->enabled = true;
else
@@ -727,7 +744,7 @@ static void __maybe_unused mvebu_pwm_suspend(struct mvebu_gpio_chip *mvchip)
{
struct mvebu_pwm *mvpwm = mvchip->mvpwm;
- regmap_read(mvchip->regs, GPIO_BLINK_CNT_SELECT_OFF,
+ regmap_read(mvchip->regs, GPIO_BLINK_CNT_SELECT_OFF + mvchip->offset,
&mvpwm->blink_select);
mvpwm->blink_on_duration =
readl_relaxed(mvebu_pwmreg_blink_on_duration(mvpwm));
@@ -739,7 +756,7 @@ static void __maybe_unused mvebu_pwm_resume(struct mvebu_gpio_chip *mvchip)
{
struct mvebu_pwm *mvpwm = mvchip->mvpwm;
- regmap_write(mvchip->regs, GPIO_BLINK_CNT_SELECT_OFF,
+ regmap_write(mvchip->regs, GPIO_BLINK_CNT_SELECT_OFF + mvchip->offset,
mvpwm->blink_select);
writel_relaxed(mvpwm->blink_on_duration,
mvebu_pwmreg_blink_on_duration(mvpwm));
@@ -783,7 +800,8 @@ static int mvebu_pwm_probe(struct platform_device *pdev,
set = U32_MAX;
else
return -EINVAL;
- regmap_write(mvchip->regs, GPIO_BLINK_CNT_SELECT_OFF, 0);
+ regmap_write(mvchip->regs,
+ GPIO_BLINK_CNT_SELECT_OFF + mvchip->offset, 0);
mvpwm = devm_kzalloc(dev, sizeof(struct mvebu_pwm), GFP_KERNEL);
if (!mvpwm)
@@ -819,11 +837,11 @@ static void mvebu_gpio_dbg_show(struct seq_file *s, struct gpio_chip *chip)
u32 out, io_conf, blink, in_pol, data_in, cause, edg_msk, lvl_msk;
int i;
- regmap_read(mvchip->regs, GPIO_OUT_OFF, &out);
- regmap_read(mvchip->regs, GPIO_IO_CONF_OFF, &io_conf);
- regmap_read(mvchip->regs, GPIO_BLINK_EN_OFF, &blink);
- regmap_read(mvchip->regs, GPIO_IN_POL_OFF, &in_pol);
- regmap_read(mvchip->regs, GPIO_DATA_IN_OFF, &data_in);
+ regmap_read(mvchip->regs, GPIO_OUT_OFF + mvchip->offset, &out);
+ regmap_read(mvchip->regs, GPIO_IO_CONF_OFF + mvchip->offset, &io_conf);
+ regmap_read(mvchip->regs, GPIO_BLINK_EN_OFF + mvchip->offset, &blink);
+ regmap_read(mvchip->regs, GPIO_IN_POL_OFF + mvchip->offset, &in_pol);
+ regmap_read(mvchip->regs, GPIO_DATA_IN_OFF + mvchip->offset, &data_in);
cause = mvebu_gpio_read_edge_cause(mvchip);
edg_msk = mvebu_gpio_read_edge_mask(mvchip);
lvl_msk = mvebu_gpio_read_level_mask(mvchip);
@@ -885,6 +903,10 @@ static const struct of_device_id mvebu_gpio_of_match[] = {
.data = (void *) MVEBU_GPIO_SOC_VARIANT_ORION,
},
{
+ .compatible = "marvell,armada-8k-gpio",
+ .data = (void *) MVEBU_GPIO_SOC_VARIANT_A8K,
+ },
+ {
/* sentinel */
},
};
@@ -894,16 +916,21 @@ static int mvebu_gpio_suspend(struct platform_device *pdev, pm_message_t state)
struct mvebu_gpio_chip *mvchip = platform_get_drvdata(pdev);
int i;
- regmap_read(mvchip->regs, GPIO_OUT_OFF, &mvchip->out_reg);
- regmap_read(mvchip->regs, GPIO_IO_CONF_OFF, &mvchip->io_conf_reg);
- regmap_read(mvchip->regs, GPIO_BLINK_EN_OFF, &mvchip->blink_en_reg);
- regmap_read(mvchip->regs, GPIO_IN_POL_OFF, &mvchip->in_pol_reg);
+ regmap_read(mvchip->regs, GPIO_OUT_OFF + mvchip->offset,
+ &mvchip->out_reg);
+ regmap_read(mvchip->regs, GPIO_IO_CONF_OFF + mvchip->offset,
+ &mvchip->io_conf_reg);
+ regmap_read(mvchip->regs, GPIO_BLINK_EN_OFF + mvchip->offset,
+ &mvchip->blink_en_reg);
+ regmap_read(mvchip->regs, GPIO_IN_POL_OFF + mvchip->offset,
+ &mvchip->in_pol_reg);
switch (mvchip->soc_variant) {
case MVEBU_GPIO_SOC_VARIANT_ORION:
- regmap_read(mvchip->regs, GPIO_EDGE_MASK_OFF,
+ case MVEBU_GPIO_SOC_VARIANT_A8K:
+ regmap_read(mvchip->regs, GPIO_EDGE_MASK_OFF + mvchip->offset,
&mvchip->edge_mask_regs[0]);
- regmap_read(mvchip->regs, GPIO_LEVEL_MASK_OFF,
+ regmap_read(mvchip->regs, GPIO_LEVEL_MASK_OFF + mvchip->offset,
&mvchip->level_mask_regs[0]);
break;
case MVEBU_GPIO_SOC_VARIANT_MV78200:
@@ -941,16 +968,21 @@ static int mvebu_gpio_resume(struct platform_device *pdev)
struct mvebu_gpio_chip *mvchip = platform_get_drvdata(pdev);
int i;
- regmap_write(mvchip->regs, GPIO_OUT_OFF, mvchip->out_reg);
- regmap_write(mvchip->regs, GPIO_IO_CONF_OFF, mvchip->io_conf_reg);
- regmap_write(mvchip->regs, GPIO_BLINK_EN_OFF, mvchip->blink_en_reg);
- regmap_write(mvchip->regs, GPIO_IN_POL_OFF, mvchip->in_pol_reg);
+ regmap_write(mvchip->regs, GPIO_OUT_OFF + mvchip->offset,
+ mvchip->out_reg);
+ regmap_write(mvchip->regs, GPIO_IO_CONF_OFF + mvchip->offset,
+ mvchip->io_conf_reg);
+ regmap_write(mvchip->regs, GPIO_BLINK_EN_OFF + mvchip->offset,
+ mvchip->blink_en_reg);
+ regmap_write(mvchip->regs, GPIO_IN_POL_OFF + mvchip->offset,
+ mvchip->in_pol_reg);
switch (mvchip->soc_variant) {
case MVEBU_GPIO_SOC_VARIANT_ORION:
- regmap_write(mvchip->regs, GPIO_EDGE_MASK_OFF,
+ case MVEBU_GPIO_SOC_VARIANT_A8K:
+ regmap_write(mvchip->regs, GPIO_EDGE_MASK_OFF + mvchip->offset,
mvchip->edge_mask_regs[0]);
- regmap_write(mvchip->regs, GPIO_LEVEL_MASK_OFF,
+ regmap_write(mvchip->regs, GPIO_LEVEL_MASK_OFF + mvchip->offset,
mvchip->level_mask_regs[0]);
break;
case MVEBU_GPIO_SOC_VARIANT_MV78200:
@@ -990,15 +1022,68 @@ static const struct regmap_config mvebu_gpio_regmap_config = {
.fast_io = true,
};
+static int mvebu_gpio_probe_raw(struct platform_device *pdev,
+ struct mvebu_gpio_chip *mvchip)
+{
+ struct resource *res;
+ void __iomem *base;
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ base = devm_ioremap_resource(&pdev->dev, res);
+ if (IS_ERR(base))
+ return PTR_ERR(base);
+
+ mvchip->regs = devm_regmap_init_mmio(&pdev->dev, base,
+ &mvebu_gpio_regmap_config);
+ if (IS_ERR(mvchip->regs))
+ return PTR_ERR(mvchip->regs);
+
+ /*
+ * For the legacy SoCs, the regmap directly maps to the GPIO
+ * registers, so no offset is needed.
+ */
+ mvchip->offset = 0;
+
+ /*
+ * The Armada XP has a second range of registers for the
+ * per-CPU registers
+ */
+ if (mvchip->soc_variant == MVEBU_GPIO_SOC_VARIANT_ARMADAXP) {
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
+ base = devm_ioremap_resource(&pdev->dev, res);
+ if (IS_ERR(base))
+ return PTR_ERR(base);
+
+ mvchip->percpu_regs =
+ devm_regmap_init_mmio(&pdev->dev, base,
+ &mvebu_gpio_regmap_config);
+ if (IS_ERR(mvchip->percpu_regs))
+ return PTR_ERR(mvchip->percpu_regs);
+ }
+
+ return 0;
+}
+
+static int mvebu_gpio_probe_syscon(struct platform_device *pdev,
+ struct mvebu_gpio_chip *mvchip)
+{
+ mvchip->regs = syscon_node_to_regmap(pdev->dev.parent->of_node);
+ if (IS_ERR(mvchip->regs))
+ return PTR_ERR(mvchip->regs);
+
+ if (of_property_read_u32(pdev->dev.of_node, "offset", &mvchip->offset))
+ return -EINVAL;
+
+ return 0;
+}
+
static int mvebu_gpio_probe(struct platform_device *pdev)
{
struct mvebu_gpio_chip *mvchip;
const struct of_device_id *match;
struct device_node *np = pdev->dev.of_node;
- struct resource *res;
struct irq_chip_generic *gc;
struct irq_chip_type *ct;
- void __iomem *base;
unsigned int ngpios;
bool have_irqs;
int soc_variant;
@@ -1054,41 +1139,26 @@ static int mvebu_gpio_probe(struct platform_device *pdev)
mvchip->chip.of_node = np;
mvchip->chip.dbg_show = mvebu_gpio_dbg_show;
- res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- base = devm_ioremap_resource(&pdev->dev, res);
- if (IS_ERR(base))
- return PTR_ERR(base);
-
- mvchip->regs = devm_regmap_init_mmio(&pdev->dev, base,
- &mvebu_gpio_regmap_config);
- if (IS_ERR(mvchip->regs))
- return PTR_ERR(mvchip->regs);
+ if (soc_variant == MVEBU_GPIO_SOC_VARIANT_A8K)
+ err = mvebu_gpio_probe_syscon(pdev, mvchip);
+ else
+ err = mvebu_gpio_probe_raw(pdev, mvchip);
- /*
- * The Armada XP has a second range of registers for the
- * per-CPU registers
- */
- if (soc_variant == MVEBU_GPIO_SOC_VARIANT_ARMADAXP) {
- res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
- base = devm_ioremap_resource(&pdev->dev, res);
- if (IS_ERR(base))
- return PTR_ERR(base);
-
- mvchip->percpu_regs =
- devm_regmap_init_mmio(&pdev->dev, base,
- &mvebu_gpio_regmap_config);
- if (IS_ERR(mvchip->percpu_regs))
- return PTR_ERR(mvchip->percpu_regs);
- }
+ if (err)
+ return err;
/*
* Mask and clear GPIO interrupts.
*/
switch (soc_variant) {
case MVEBU_GPIO_SOC_VARIANT_ORION:
- regmap_write(mvchip->regs, GPIO_EDGE_CAUSE_OFF, 0);
- regmap_write(mvchip->regs, GPIO_EDGE_MASK_OFF, 0);
- regmap_write(mvchip->regs, GPIO_LEVEL_MASK_OFF, 0);
+ case MVEBU_GPIO_SOC_VARIANT_A8K:
+ regmap_write(mvchip->regs,
+ GPIO_EDGE_CAUSE_OFF + mvchip->offset, 0);
+ regmap_write(mvchip->regs,
+ GPIO_EDGE_MASK_OFF + mvchip->offset, 0);
+ regmap_write(mvchip->regs,
+ GPIO_LEVEL_MASK_OFF + mvchip->offset, 0);
break;
case MVEBU_GPIO_SOC_VARIANT_MV78200:
regmap_write(mvchip->regs, GPIO_EDGE_CAUSE_OFF, 0);
--
git-series 0.9.1
^ permalink raw reply related [flat|nested] 65+ messages in thread
* [PATCH 5/6] gpio: mvebu: Add support for the Armada 7K/8K SoCs
@ 2017-05-19 16:09 ` Gregory CLEMENT
0 siblings, 0 replies; 65+ messages in thread
From: Gregory CLEMENT @ 2017-05-19 16:09 UTC (permalink / raw)
To: linux-arm-kernel
The Armada 7K and 8K SoCs use the same gpio controller as most of the
other mvebu SoCs. However, the main difference is that the GPIO
controller is part of a bigger system controller, and a syscon is used to
control the overall system controller. Therefore, the driver needs to be
adjusted to retrieve the regmap of the syscon to access registers, and
account for the fact that registers are located at a certain offset
within the regmap.
This commit add the support of the syscon and introduce a new variant for
this case.
It was based on the preliminary work of Thomas Petazzoni.
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
drivers/gpio/gpio-mvebu.c | 212 +++++++++++++++++++++++++--------------
1 file changed, 141 insertions(+), 71 deletions(-)
diff --git a/drivers/gpio/gpio-mvebu.c b/drivers/gpio/gpio-mvebu.c
index 3d03740a20e7..5edb04abd7d7 100644
--- a/drivers/gpio/gpio-mvebu.c
+++ b/drivers/gpio/gpio-mvebu.c
@@ -42,6 +42,7 @@
#include <linux/irq.h>
#include <linux/irqchip/chained_irq.h>
#include <linux/irqdomain.h>
+#include <linux/mfd/syscon.h>
#include <linux/of_device.h>
#include <linux/of_irq.h>
#include <linux/pinctrl/consumer.h>
@@ -88,6 +89,7 @@
#define MVEBU_GPIO_SOC_VARIANT_ORION 0x1
#define MVEBU_GPIO_SOC_VARIANT_MV78200 0x2
#define MVEBU_GPIO_SOC_VARIANT_ARMADAXP 0x3
+#define MVEBU_GPIO_SOC_VARIANT_A8K 0x4
#define MVEBU_MAX_GPIO_PER_BANK 32
@@ -108,6 +110,7 @@ struct mvebu_pwm {
struct mvebu_gpio_chip {
struct gpio_chip chip;
struct regmap *regs;
+ u32 offset;
struct regmap *percpu_regs;
int irqbase;
struct irq_domain *domain;
@@ -139,8 +142,9 @@ static void mvebu_gpioreg_edge_cause(struct mvebu_gpio_chip *mvchip,
switch (mvchip->soc_variant) {
case MVEBU_GPIO_SOC_VARIANT_ORION:
case MVEBU_GPIO_SOC_VARIANT_MV78200:
+ case MVEBU_GPIO_SOC_VARIANT_A8K:
*map = mvchip->regs;
- *offset = GPIO_EDGE_CAUSE_OFF;
+ *offset = GPIO_EDGE_CAUSE_OFF + mvchip->offset;
break;
case MVEBU_GPIO_SOC_VARIANT_ARMADAXP:
cpu = smp_processor_id();
@@ -183,8 +187,9 @@ mvebu_gpioreg_edge_mask(struct mvebu_gpio_chip *mvchip,
switch (mvchip->soc_variant) {
case MVEBU_GPIO_SOC_VARIANT_ORION:
+ case MVEBU_GPIO_SOC_VARIANT_A8K:
*map = mvchip->regs;
- *offset = GPIO_EDGE_MASK_OFF;
+ *offset = GPIO_EDGE_MASK_OFF + mvchip->offset;
break;
case MVEBU_GPIO_SOC_VARIANT_MV78200:
cpu = smp_processor_id();
@@ -232,8 +237,9 @@ mvebu_gpioreg_level_mask(struct mvebu_gpio_chip *mvchip,
switch (mvchip->soc_variant) {
case MVEBU_GPIO_SOC_VARIANT_ORION:
+ case MVEBU_GPIO_SOC_VARIANT_A8K:
*map = mvchip->regs;
- *offset = GPIO_LEVEL_MASK_OFF;
+ *offset = GPIO_LEVEL_MASK_OFF + mvchip->offset;
break;
case MVEBU_GPIO_SOC_VARIANT_MV78200:
cpu = smp_processor_id();
@@ -294,7 +300,7 @@ static void mvebu_gpio_set(struct gpio_chip *chip, unsigned int pin, int value)
{
struct mvebu_gpio_chip *mvchip = gpiochip_get_data(chip);
- regmap_update_bits(mvchip->regs, GPIO_OUT_OFF,
+ regmap_update_bits(mvchip->regs, GPIO_OUT_OFF + mvchip->offset,
BIT(pin), value ? BIT(pin) : 0);
}
@@ -303,16 +309,18 @@ static int mvebu_gpio_get(struct gpio_chip *chip, unsigned int pin)
struct mvebu_gpio_chip *mvchip = gpiochip_get_data(chip);
u32 u;
- regmap_read(mvchip->regs, GPIO_IO_CONF_OFF, &u);
+ regmap_read(mvchip->regs, GPIO_IO_CONF_OFF + mvchip->offset, &u);
if (u & BIT(pin)) {
u32 data_in, in_pol;
- regmap_read(mvchip->regs, GPIO_DATA_IN_OFF, &data_in);
- regmap_read(mvchip->regs, GPIO_IN_POL_OFF, &in_pol);
+ regmap_read(mvchip->regs, GPIO_DATA_IN_OFF + mvchip->offset,
+ &data_in);
+ regmap_read(mvchip->regs, GPIO_IN_POL_OFF + mvchip->offset,
+ &in_pol);
u = data_in ^ in_pol;
} else {
- regmap_read(mvchip->regs, GPIO_OUT_OFF, &u);
+ regmap_read(mvchip->regs, GPIO_OUT_OFF + mvchip->offset, &u);
}
return (u >> pin) & 1;
@@ -323,7 +331,7 @@ static void mvebu_gpio_blink(struct gpio_chip *chip, unsigned int pin,
{
struct mvebu_gpio_chip *mvchip = gpiochip_get_data(chip);
- regmap_update_bits(mvchip->regs, GPIO_BLINK_EN_OFF,
+ regmap_update_bits(mvchip->regs, GPIO_BLINK_EN_OFF + mvchip->offset,
BIT(pin), value ? BIT(pin) : 0);
}
@@ -340,7 +348,7 @@ static int mvebu_gpio_direction_input(struct gpio_chip *chip, unsigned int pin)
if (ret)
return ret;
- regmap_update_bits(mvchip->regs, GPIO_IO_CONF_OFF,
+ regmap_update_bits(mvchip->regs, GPIO_IO_CONF_OFF + mvchip->offset,
BIT(pin), 1);
return 0;
@@ -363,7 +371,7 @@ static int mvebu_gpio_direction_output(struct gpio_chip *chip, unsigned int pin,
mvebu_gpio_blink(chip, pin, 0);
mvebu_gpio_set(chip, pin, value);
- regmap_update_bits(mvchip->regs, GPIO_IO_CONF_OFF,
+ regmap_update_bits(mvchip->regs, GPIO_IO_CONF_OFF + mvchip->offset,
BIT(pin), 0);
return 0;
@@ -478,7 +486,7 @@ static int mvebu_gpio_irq_set_type(struct irq_data *d, unsigned int type)
pin = d->hwirq;
- regmap_read(mvchip->regs, GPIO_IO_CONF_OFF, &u);
+ regmap_read(mvchip->regs, GPIO_IO_CONF_OFF + mvchip->offset, &u);
if ((u & BIT(pin)) == 0)
return -EINVAL;
@@ -497,19 +505,23 @@ static int mvebu_gpio_irq_set_type(struct irq_data *d, unsigned int type)
switch (type) {
case IRQ_TYPE_EDGE_RISING:
case IRQ_TYPE_LEVEL_HIGH:
- regmap_update_bits(mvchip->regs, GPIO_IN_POL_OFF,
+ regmap_update_bits(mvchip->regs,
+ GPIO_IN_POL_OFF + mvchip->offset,
BIT(pin), 0);
break;
case IRQ_TYPE_EDGE_FALLING:
case IRQ_TYPE_LEVEL_LOW:
- regmap_update_bits(mvchip->regs, GPIO_IN_POL_OFF,
+ regmap_update_bits(mvchip->regs,
+ GPIO_IN_POL_OFF + mvchip->offset,
BIT(pin), 1);
break;
case IRQ_TYPE_EDGE_BOTH: {
u32 data_in, in_pol, val;
- regmap_read(mvchip->regs, GPIO_IN_POL_OFF, &in_pol);
- regmap_read(mvchip->regs, GPIO_DATA_IN_OFF, &data_in);
+ regmap_read(mvchip->regs,
+ GPIO_IN_POL_OFF + mvchip->offset, &in_pol);
+ regmap_read(mvchip->regs,
+ GPIO_DATA_IN_OFF + mvchip->offset, &data_in);
/*
* set initial polarity based on current input level
@@ -519,7 +531,8 @@ static int mvebu_gpio_irq_set_type(struct irq_data *d, unsigned int type)
else
val = 0; /* raising */
- regmap_update_bits(mvchip->regs, GPIO_IN_POL_OFF,
+ regmap_update_bits(mvchip->regs,
+ GPIO_IN_POL_OFF + mvchip->offset,
BIT(pin), val);
break;
}
@@ -539,7 +552,7 @@ static void mvebu_gpio_irq_handler(struct irq_desc *desc)
chained_irq_enter(chip, desc);
- regmap_read(mvchip->regs, GPIO_DATA_IN_OFF, &data_in);
+ regmap_read(mvchip->regs, GPIO_DATA_IN_OFF + mvchip->offset, &data_in);
level_mask = mvebu_gpio_read_level_mask(mvchip);
edge_cause = mvebu_gpio_read_edge_cause(mvchip);
edge_mask = mvebu_gpio_read_edge_mask(mvchip);
@@ -559,9 +572,13 @@ static void mvebu_gpio_irq_handler(struct irq_desc *desc)
/* Swap polarity (race with GPIO line) */
u32 polarity;
- regmap_read(mvchip->regs, GPIO_IN_POL_OFF, &polarity);
+ regmap_read(mvchip->regs,
+ GPIO_IN_POL_OFF + mvchip->offset,
+ &polarity);
polarity ^= BIT(i);
- regmap_write(mvchip->regs, GPIO_IN_POL_OFF, polarity);
+ regmap_write(mvchip->regs,
+ GPIO_IN_POL_OFF + mvchip->offset,
+ polarity);
}
generic_handle_irq(irq);
@@ -664,7 +681,7 @@ static void mvebu_pwm_get_state(struct pwm_chip *chip,
state->period = 1;
}
- regmap_read(mvchip->regs, GPIO_BLINK_EN_OFF, &u);
+ regmap_read(mvchip->regs, GPIO_BLINK_EN_OFF + mvchip->offset, &u);
if (u)
state->enabled = true;
else
@@ -727,7 +744,7 @@ static void __maybe_unused mvebu_pwm_suspend(struct mvebu_gpio_chip *mvchip)
{
struct mvebu_pwm *mvpwm = mvchip->mvpwm;
- regmap_read(mvchip->regs, GPIO_BLINK_CNT_SELECT_OFF,
+ regmap_read(mvchip->regs, GPIO_BLINK_CNT_SELECT_OFF + mvchip->offset,
&mvpwm->blink_select);
mvpwm->blink_on_duration =
readl_relaxed(mvebu_pwmreg_blink_on_duration(mvpwm));
@@ -739,7 +756,7 @@ static void __maybe_unused mvebu_pwm_resume(struct mvebu_gpio_chip *mvchip)
{
struct mvebu_pwm *mvpwm = mvchip->mvpwm;
- regmap_write(mvchip->regs, GPIO_BLINK_CNT_SELECT_OFF,
+ regmap_write(mvchip->regs, GPIO_BLINK_CNT_SELECT_OFF + mvchip->offset,
mvpwm->blink_select);
writel_relaxed(mvpwm->blink_on_duration,
mvebu_pwmreg_blink_on_duration(mvpwm));
@@ -783,7 +800,8 @@ static int mvebu_pwm_probe(struct platform_device *pdev,
set = U32_MAX;
else
return -EINVAL;
- regmap_write(mvchip->regs, GPIO_BLINK_CNT_SELECT_OFF, 0);
+ regmap_write(mvchip->regs,
+ GPIO_BLINK_CNT_SELECT_OFF + mvchip->offset, 0);
mvpwm = devm_kzalloc(dev, sizeof(struct mvebu_pwm), GFP_KERNEL);
if (!mvpwm)
@@ -819,11 +837,11 @@ static void mvebu_gpio_dbg_show(struct seq_file *s, struct gpio_chip *chip)
u32 out, io_conf, blink, in_pol, data_in, cause, edg_msk, lvl_msk;
int i;
- regmap_read(mvchip->regs, GPIO_OUT_OFF, &out);
- regmap_read(mvchip->regs, GPIO_IO_CONF_OFF, &io_conf);
- regmap_read(mvchip->regs, GPIO_BLINK_EN_OFF, &blink);
- regmap_read(mvchip->regs, GPIO_IN_POL_OFF, &in_pol);
- regmap_read(mvchip->regs, GPIO_DATA_IN_OFF, &data_in);
+ regmap_read(mvchip->regs, GPIO_OUT_OFF + mvchip->offset, &out);
+ regmap_read(mvchip->regs, GPIO_IO_CONF_OFF + mvchip->offset, &io_conf);
+ regmap_read(mvchip->regs, GPIO_BLINK_EN_OFF + mvchip->offset, &blink);
+ regmap_read(mvchip->regs, GPIO_IN_POL_OFF + mvchip->offset, &in_pol);
+ regmap_read(mvchip->regs, GPIO_DATA_IN_OFF + mvchip->offset, &data_in);
cause = mvebu_gpio_read_edge_cause(mvchip);
edg_msk = mvebu_gpio_read_edge_mask(mvchip);
lvl_msk = mvebu_gpio_read_level_mask(mvchip);
@@ -885,6 +903,10 @@ static const struct of_device_id mvebu_gpio_of_match[] = {
.data = (void *) MVEBU_GPIO_SOC_VARIANT_ORION,
},
{
+ .compatible = "marvell,armada-8k-gpio",
+ .data = (void *) MVEBU_GPIO_SOC_VARIANT_A8K,
+ },
+ {
/* sentinel */
},
};
@@ -894,16 +916,21 @@ static int mvebu_gpio_suspend(struct platform_device *pdev, pm_message_t state)
struct mvebu_gpio_chip *mvchip = platform_get_drvdata(pdev);
int i;
- regmap_read(mvchip->regs, GPIO_OUT_OFF, &mvchip->out_reg);
- regmap_read(mvchip->regs, GPIO_IO_CONF_OFF, &mvchip->io_conf_reg);
- regmap_read(mvchip->regs, GPIO_BLINK_EN_OFF, &mvchip->blink_en_reg);
- regmap_read(mvchip->regs, GPIO_IN_POL_OFF, &mvchip->in_pol_reg);
+ regmap_read(mvchip->regs, GPIO_OUT_OFF + mvchip->offset,
+ &mvchip->out_reg);
+ regmap_read(mvchip->regs, GPIO_IO_CONF_OFF + mvchip->offset,
+ &mvchip->io_conf_reg);
+ regmap_read(mvchip->regs, GPIO_BLINK_EN_OFF + mvchip->offset,
+ &mvchip->blink_en_reg);
+ regmap_read(mvchip->regs, GPIO_IN_POL_OFF + mvchip->offset,
+ &mvchip->in_pol_reg);
switch (mvchip->soc_variant) {
case MVEBU_GPIO_SOC_VARIANT_ORION:
- regmap_read(mvchip->regs, GPIO_EDGE_MASK_OFF,
+ case MVEBU_GPIO_SOC_VARIANT_A8K:
+ regmap_read(mvchip->regs, GPIO_EDGE_MASK_OFF + mvchip->offset,
&mvchip->edge_mask_regs[0]);
- regmap_read(mvchip->regs, GPIO_LEVEL_MASK_OFF,
+ regmap_read(mvchip->regs, GPIO_LEVEL_MASK_OFF + mvchip->offset,
&mvchip->level_mask_regs[0]);
break;
case MVEBU_GPIO_SOC_VARIANT_MV78200:
@@ -941,16 +968,21 @@ static int mvebu_gpio_resume(struct platform_device *pdev)
struct mvebu_gpio_chip *mvchip = platform_get_drvdata(pdev);
int i;
- regmap_write(mvchip->regs, GPIO_OUT_OFF, mvchip->out_reg);
- regmap_write(mvchip->regs, GPIO_IO_CONF_OFF, mvchip->io_conf_reg);
- regmap_write(mvchip->regs, GPIO_BLINK_EN_OFF, mvchip->blink_en_reg);
- regmap_write(mvchip->regs, GPIO_IN_POL_OFF, mvchip->in_pol_reg);
+ regmap_write(mvchip->regs, GPIO_OUT_OFF + mvchip->offset,
+ mvchip->out_reg);
+ regmap_write(mvchip->regs, GPIO_IO_CONF_OFF + mvchip->offset,
+ mvchip->io_conf_reg);
+ regmap_write(mvchip->regs, GPIO_BLINK_EN_OFF + mvchip->offset,
+ mvchip->blink_en_reg);
+ regmap_write(mvchip->regs, GPIO_IN_POL_OFF + mvchip->offset,
+ mvchip->in_pol_reg);
switch (mvchip->soc_variant) {
case MVEBU_GPIO_SOC_VARIANT_ORION:
- regmap_write(mvchip->regs, GPIO_EDGE_MASK_OFF,
+ case MVEBU_GPIO_SOC_VARIANT_A8K:
+ regmap_write(mvchip->regs, GPIO_EDGE_MASK_OFF + mvchip->offset,
mvchip->edge_mask_regs[0]);
- regmap_write(mvchip->regs, GPIO_LEVEL_MASK_OFF,
+ regmap_write(mvchip->regs, GPIO_LEVEL_MASK_OFF + mvchip->offset,
mvchip->level_mask_regs[0]);
break;
case MVEBU_GPIO_SOC_VARIANT_MV78200:
@@ -990,15 +1022,68 @@ static const struct regmap_config mvebu_gpio_regmap_config = {
.fast_io = true,
};
+static int mvebu_gpio_probe_raw(struct platform_device *pdev,
+ struct mvebu_gpio_chip *mvchip)
+{
+ struct resource *res;
+ void __iomem *base;
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ base = devm_ioremap_resource(&pdev->dev, res);
+ if (IS_ERR(base))
+ return PTR_ERR(base);
+
+ mvchip->regs = devm_regmap_init_mmio(&pdev->dev, base,
+ &mvebu_gpio_regmap_config);
+ if (IS_ERR(mvchip->regs))
+ return PTR_ERR(mvchip->regs);
+
+ /*
+ * For the legacy SoCs, the regmap directly maps to the GPIO
+ * registers, so no offset is needed.
+ */
+ mvchip->offset = 0;
+
+ /*
+ * The Armada XP has a second range of registers for the
+ * per-CPU registers
+ */
+ if (mvchip->soc_variant == MVEBU_GPIO_SOC_VARIANT_ARMADAXP) {
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
+ base = devm_ioremap_resource(&pdev->dev, res);
+ if (IS_ERR(base))
+ return PTR_ERR(base);
+
+ mvchip->percpu_regs =
+ devm_regmap_init_mmio(&pdev->dev, base,
+ &mvebu_gpio_regmap_config);
+ if (IS_ERR(mvchip->percpu_regs))
+ return PTR_ERR(mvchip->percpu_regs);
+ }
+
+ return 0;
+}
+
+static int mvebu_gpio_probe_syscon(struct platform_device *pdev,
+ struct mvebu_gpio_chip *mvchip)
+{
+ mvchip->regs = syscon_node_to_regmap(pdev->dev.parent->of_node);
+ if (IS_ERR(mvchip->regs))
+ return PTR_ERR(mvchip->regs);
+
+ if (of_property_read_u32(pdev->dev.of_node, "offset", &mvchip->offset))
+ return -EINVAL;
+
+ return 0;
+}
+
static int mvebu_gpio_probe(struct platform_device *pdev)
{
struct mvebu_gpio_chip *mvchip;
const struct of_device_id *match;
struct device_node *np = pdev->dev.of_node;
- struct resource *res;
struct irq_chip_generic *gc;
struct irq_chip_type *ct;
- void __iomem *base;
unsigned int ngpios;
bool have_irqs;
int soc_variant;
@@ -1054,41 +1139,26 @@ static int mvebu_gpio_probe(struct platform_device *pdev)
mvchip->chip.of_node = np;
mvchip->chip.dbg_show = mvebu_gpio_dbg_show;
- res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- base = devm_ioremap_resource(&pdev->dev, res);
- if (IS_ERR(base))
- return PTR_ERR(base);
-
- mvchip->regs = devm_regmap_init_mmio(&pdev->dev, base,
- &mvebu_gpio_regmap_config);
- if (IS_ERR(mvchip->regs))
- return PTR_ERR(mvchip->regs);
+ if (soc_variant == MVEBU_GPIO_SOC_VARIANT_A8K)
+ err = mvebu_gpio_probe_syscon(pdev, mvchip);
+ else
+ err = mvebu_gpio_probe_raw(pdev, mvchip);
- /*
- * The Armada XP has a second range of registers for the
- * per-CPU registers
- */
- if (soc_variant == MVEBU_GPIO_SOC_VARIANT_ARMADAXP) {
- res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
- base = devm_ioremap_resource(&pdev->dev, res);
- if (IS_ERR(base))
- return PTR_ERR(base);
-
- mvchip->percpu_regs =
- devm_regmap_init_mmio(&pdev->dev, base,
- &mvebu_gpio_regmap_config);
- if (IS_ERR(mvchip->percpu_regs))
- return PTR_ERR(mvchip->percpu_regs);
- }
+ if (err)
+ return err;
/*
* Mask and clear GPIO interrupts.
*/
switch (soc_variant) {
case MVEBU_GPIO_SOC_VARIANT_ORION:
- regmap_write(mvchip->regs, GPIO_EDGE_CAUSE_OFF, 0);
- regmap_write(mvchip->regs, GPIO_EDGE_MASK_OFF, 0);
- regmap_write(mvchip->regs, GPIO_LEVEL_MASK_OFF, 0);
+ case MVEBU_GPIO_SOC_VARIANT_A8K:
+ regmap_write(mvchip->regs,
+ GPIO_EDGE_CAUSE_OFF + mvchip->offset, 0);
+ regmap_write(mvchip->regs,
+ GPIO_EDGE_MASK_OFF + mvchip->offset, 0);
+ regmap_write(mvchip->regs,
+ GPIO_LEVEL_MASK_OFF + mvchip->offset, 0);
break;
case MVEBU_GPIO_SOC_VARIANT_MV78200:
regmap_write(mvchip->regs, GPIO_EDGE_CAUSE_OFF, 0);
--
git-series 0.9.1
^ permalink raw reply related [flat|nested] 65+ messages in thread
* [PATCH 6/6] arm64: dts: marvell: add gpio support for Armada 7K/8K
2017-05-19 16:09 ` Gregory CLEMENT
(?)
@ 2017-05-19 16:09 ` Gregory CLEMENT
-1 siblings, 0 replies; 65+ messages in thread
From: Gregory CLEMENT @ 2017-05-19 16:09 UTC (permalink / raw)
To: Linus Walleij, Alexandre Courbot,
linux-gpio-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
Cc: Jason Cooper, Andrew Lunn, Sebastian Hesselbarth,
Gregory CLEMENT, Thomas Petazzoni,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Rob Herring,
devicetree-u79uwXL29TY76Z2rM5mHXA, Russell King, Nadav Haklai,
Kostya Porotchkin, Neta Zur Hershkovits, Marcin Wojtas,
Omri Itach, Shadi Ammouri
Enable gpio support for CP and AP on the Marvell Armada 7K/8K SoCs.
The Armada 8K has two CP110 blocks, each having two GPIO controllers.
However, in each CP110 block, one of the GPIO controller cannot be
used: in the master CP110, only the second GPIO controller can be used,
while on the slave CP110, only the first GPIO controller can be used.
On the other side, the Armada 7K has only one CP110, but both its GPIO
controllers can be used.
For this reason, the GPIO controllers are marked as "disabled" in the
armada-cp110-master.dtsi and armada-cp110-slave.dtsi files, and only
enabled in the per-SoC dtsi files.
Signed-off-by: Gregory CLEMENT <gregory.clement-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
---
arch/arm64/boot/dts/marvell/armada-70x0.dtsi | 15 +++++++++-
arch/arm64/boot/dts/marvell/armada-80x0.dtsi | 16 +++++++++-
arch/arm64/boot/dts/marvell/armada-ap806.dtsi | 10 ++++++-
arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi | 21 ++++++++++++-
arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi | 22 +++++++++++++-
5 files changed, 84 insertions(+)
diff --git a/arch/arm64/boot/dts/marvell/armada-70x0.dtsi b/arch/arm64/boot/dts/marvell/armada-70x0.dtsi
index f6c22665d091..860b6ae9dcc5 100644
--- a/arch/arm64/boot/dts/marvell/armada-70x0.dtsi
+++ b/arch/arm64/boot/dts/marvell/armada-70x0.dtsi
@@ -46,6 +46,21 @@
#include "armada-cp110-master.dtsi"
+/ {
+ aliases {
+ gpio1 = &cpm_gpio1;
+ gpio2 = &cpm_gpio2;
+ };
+};
+
+&cpm_gpio1 {
+ status = "okay";
+};
+
+&cpm_gpio2 {
+ status = "okay";
+};
+
&cpm_syscon0 {
cpm_pinctrl: pinctrl {
compatible = "marvell,armada-7k-pinctrl";
diff --git a/arch/arm64/boot/dts/marvell/armada-80x0.dtsi b/arch/arm64/boot/dts/marvell/armada-80x0.dtsi
index 93d1de03b39a..666ebe96ba0d 100644
--- a/arch/arm64/boot/dts/marvell/armada-80x0.dtsi
+++ b/arch/arm64/boot/dts/marvell/armada-80x0.dtsi
@@ -47,6 +47,22 @@
#include "armada-cp110-master.dtsi"
#include "armada-cp110-slave.dtsi"
+/ {
+ aliases {
+ gpio1 = &cps_gpio1;
+ gpio2 = &cpm_gpio2;
+ };
+};
+
+/* The 80x0 has two CP blocks, but uses only one block from each. */
+&cps_gpio1 {
+ status = "okay";
+};
+
+&cpm_gpio2 {
+ status = "okay";
+};
+
&cpm_syscon0 {
cpm_pinctrl: pinctrl {
compatible = "marvell,armada-8k-cpm-pinctrl";
diff --git a/arch/arm64/boot/dts/marvell/armada-ap806.dtsi b/arch/arm64/boot/dts/marvell/armada-ap806.dtsi
index 4a1b6e0a604a..64608658de5a 100644
--- a/arch/arm64/boot/dts/marvell/armada-ap806.dtsi
+++ b/arch/arm64/boot/dts/marvell/armada-ap806.dtsi
@@ -57,6 +57,7 @@
aliases {
serial0 = &uart0;
serial1 = &uart1;
+ gpio0 = &ap_gpio;
};
psci {
@@ -252,6 +253,15 @@
ap_pinctrl: pinctrl {
compatible = "marvell,ap806-pinctrl";
};
+
+ ap_gpio: gpio {
+ compatible = "marvell,armada-8k-gpio";
+ offset = <0x1040>;
+ ngpios = <19>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ gpio-ranges = <&ap_pinctrl 0 0 19>;
+ };
};
};
};
diff --git a/arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi b/arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi
index 96a4ff75b3b0..f88618185d58 100644
--- a/arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi
+++ b/arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi
@@ -104,6 +104,27 @@
compatible = "marvell,cp110-clock";
#clock-cells = <2>;
};
+
+ cpm_gpio1: gpio@100 {
+ compatible = "marvell,armada-8k-gpio";
+ offset = <0x100>;
+ ngpios = <32>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ gpio-ranges = <&cpm_pinctrl 0 0 32>;
+ status = "disabled";
+
+ };
+
+ cpm_gpio2: gpio@140 {
+ compatible = "marvell,armada-8k-gpio";
+ offset = <0x140>;
+ ngpios = <31>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ gpio-ranges = <&cpm_pinctrl 0 32 31>;
+ status = "disabled";
+ };
};
cpm_rtc: rtc@284000 {
diff --git a/arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi b/arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi
index 48a658aa5b32..f3a6e6742442 100644
--- a/arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi
+++ b/arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi
@@ -111,6 +111,28 @@
compatible = "marvell,cp110-clock";
#clock-cells = <2>;
};
+
+ cps_gpio1: gpio@100 {
+ compatible = "marvell,armada-8k-gpio";
+ offset = <0x100>;
+ ngpios = <32>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ gpio-ranges = <&cps_pinctrl 0 0 32>;
+ status = "disabled";
+
+ };
+
+ cps_gpio2: gpio@140 {
+ compatible = "marvell,armada-8k-gpio";
+ offset = <0x140>;
+ ngpios = <31>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ gpio-ranges = <&cps_pinctrl 0 32 31>;
+ status = "disabled";
+ };
+
};
cps_sata0: sata@540000 {
--
git-series 0.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related [flat|nested] 65+ messages in thread
* [PATCH 6/6] arm64: dts: marvell: add gpio support for Armada 7K/8K
@ 2017-05-19 16:09 ` Gregory CLEMENT
0 siblings, 0 replies; 65+ messages in thread
From: Gregory CLEMENT @ 2017-05-19 16:09 UTC (permalink / raw)
To: Linus Walleij, Alexandre Courbot, linux-gpio, linux-kernel
Cc: Jason Cooper, Andrew Lunn, Sebastian Hesselbarth,
Gregory CLEMENT, Thomas Petazzoni, linux-arm-kernel, Rob Herring,
devicetree, Russell King, Nadav Haklai, Kostya Porotchkin,
Neta Zur Hershkovits, Marcin Wojtas, Omri Itach, Shadi Ammouri
Enable gpio support for CP and AP on the Marvell Armada 7K/8K SoCs.
The Armada 8K has two CP110 blocks, each having two GPIO controllers.
However, in each CP110 block, one of the GPIO controller cannot be
used: in the master CP110, only the second GPIO controller can be used,
while on the slave CP110, only the first GPIO controller can be used.
On the other side, the Armada 7K has only one CP110, but both its GPIO
controllers can be used.
For this reason, the GPIO controllers are marked as "disabled" in the
armada-cp110-master.dtsi and armada-cp110-slave.dtsi files, and only
enabled in the per-SoC dtsi files.
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
arch/arm64/boot/dts/marvell/armada-70x0.dtsi | 15 +++++++++-
arch/arm64/boot/dts/marvell/armada-80x0.dtsi | 16 +++++++++-
arch/arm64/boot/dts/marvell/armada-ap806.dtsi | 10 ++++++-
arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi | 21 ++++++++++++-
arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi | 22 +++++++++++++-
5 files changed, 84 insertions(+)
diff --git a/arch/arm64/boot/dts/marvell/armada-70x0.dtsi b/arch/arm64/boot/dts/marvell/armada-70x0.dtsi
index f6c22665d091..860b6ae9dcc5 100644
--- a/arch/arm64/boot/dts/marvell/armada-70x0.dtsi
+++ b/arch/arm64/boot/dts/marvell/armada-70x0.dtsi
@@ -46,6 +46,21 @@
#include "armada-cp110-master.dtsi"
+/ {
+ aliases {
+ gpio1 = &cpm_gpio1;
+ gpio2 = &cpm_gpio2;
+ };
+};
+
+&cpm_gpio1 {
+ status = "okay";
+};
+
+&cpm_gpio2 {
+ status = "okay";
+};
+
&cpm_syscon0 {
cpm_pinctrl: pinctrl {
compatible = "marvell,armada-7k-pinctrl";
diff --git a/arch/arm64/boot/dts/marvell/armada-80x0.dtsi b/arch/arm64/boot/dts/marvell/armada-80x0.dtsi
index 93d1de03b39a..666ebe96ba0d 100644
--- a/arch/arm64/boot/dts/marvell/armada-80x0.dtsi
+++ b/arch/arm64/boot/dts/marvell/armada-80x0.dtsi
@@ -47,6 +47,22 @@
#include "armada-cp110-master.dtsi"
#include "armada-cp110-slave.dtsi"
+/ {
+ aliases {
+ gpio1 = &cps_gpio1;
+ gpio2 = &cpm_gpio2;
+ };
+};
+
+/* The 80x0 has two CP blocks, but uses only one block from each. */
+&cps_gpio1 {
+ status = "okay";
+};
+
+&cpm_gpio2 {
+ status = "okay";
+};
+
&cpm_syscon0 {
cpm_pinctrl: pinctrl {
compatible = "marvell,armada-8k-cpm-pinctrl";
diff --git a/arch/arm64/boot/dts/marvell/armada-ap806.dtsi b/arch/arm64/boot/dts/marvell/armada-ap806.dtsi
index 4a1b6e0a604a..64608658de5a 100644
--- a/arch/arm64/boot/dts/marvell/armada-ap806.dtsi
+++ b/arch/arm64/boot/dts/marvell/armada-ap806.dtsi
@@ -57,6 +57,7 @@
aliases {
serial0 = &uart0;
serial1 = &uart1;
+ gpio0 = &ap_gpio;
};
psci {
@@ -252,6 +253,15 @@
ap_pinctrl: pinctrl {
compatible = "marvell,ap806-pinctrl";
};
+
+ ap_gpio: gpio {
+ compatible = "marvell,armada-8k-gpio";
+ offset = <0x1040>;
+ ngpios = <19>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ gpio-ranges = <&ap_pinctrl 0 0 19>;
+ };
};
};
};
diff --git a/arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi b/arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi
index 96a4ff75b3b0..f88618185d58 100644
--- a/arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi
+++ b/arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi
@@ -104,6 +104,27 @@
compatible = "marvell,cp110-clock";
#clock-cells = <2>;
};
+
+ cpm_gpio1: gpio@100 {
+ compatible = "marvell,armada-8k-gpio";
+ offset = <0x100>;
+ ngpios = <32>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ gpio-ranges = <&cpm_pinctrl 0 0 32>;
+ status = "disabled";
+
+ };
+
+ cpm_gpio2: gpio@140 {
+ compatible = "marvell,armada-8k-gpio";
+ offset = <0x140>;
+ ngpios = <31>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ gpio-ranges = <&cpm_pinctrl 0 32 31>;
+ status = "disabled";
+ };
};
cpm_rtc: rtc@284000 {
diff --git a/arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi b/arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi
index 48a658aa5b32..f3a6e6742442 100644
--- a/arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi
+++ b/arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi
@@ -111,6 +111,28 @@
compatible = "marvell,cp110-clock";
#clock-cells = <2>;
};
+
+ cps_gpio1: gpio@100 {
+ compatible = "marvell,armada-8k-gpio";
+ offset = <0x100>;
+ ngpios = <32>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ gpio-ranges = <&cps_pinctrl 0 0 32>;
+ status = "disabled";
+
+ };
+
+ cps_gpio2: gpio@140 {
+ compatible = "marvell,armada-8k-gpio";
+ offset = <0x140>;
+ ngpios = <31>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ gpio-ranges = <&cps_pinctrl 0 32 31>;
+ status = "disabled";
+ };
+
};
cps_sata0: sata@540000 {
--
git-series 0.9.1
^ permalink raw reply related [flat|nested] 65+ messages in thread
* [PATCH 6/6] arm64: dts: marvell: add gpio support for Armada 7K/8K
@ 2017-05-19 16:09 ` Gregory CLEMENT
0 siblings, 0 replies; 65+ messages in thread
From: Gregory CLEMENT @ 2017-05-19 16:09 UTC (permalink / raw)
To: linux-arm-kernel
Enable gpio support for CP and AP on the Marvell Armada 7K/8K SoCs.
The Armada 8K has two CP110 blocks, each having two GPIO controllers.
However, in each CP110 block, one of the GPIO controller cannot be
used: in the master CP110, only the second GPIO controller can be used,
while on the slave CP110, only the first GPIO controller can be used.
On the other side, the Armada 7K has only one CP110, but both its GPIO
controllers can be used.
For this reason, the GPIO controllers are marked as "disabled" in the
armada-cp110-master.dtsi and armada-cp110-slave.dtsi files, and only
enabled in the per-SoC dtsi files.
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
arch/arm64/boot/dts/marvell/armada-70x0.dtsi | 15 +++++++++-
arch/arm64/boot/dts/marvell/armada-80x0.dtsi | 16 +++++++++-
arch/arm64/boot/dts/marvell/armada-ap806.dtsi | 10 ++++++-
arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi | 21 ++++++++++++-
arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi | 22 +++++++++++++-
5 files changed, 84 insertions(+)
diff --git a/arch/arm64/boot/dts/marvell/armada-70x0.dtsi b/arch/arm64/boot/dts/marvell/armada-70x0.dtsi
index f6c22665d091..860b6ae9dcc5 100644
--- a/arch/arm64/boot/dts/marvell/armada-70x0.dtsi
+++ b/arch/arm64/boot/dts/marvell/armada-70x0.dtsi
@@ -46,6 +46,21 @@
#include "armada-cp110-master.dtsi"
+/ {
+ aliases {
+ gpio1 = &cpm_gpio1;
+ gpio2 = &cpm_gpio2;
+ };
+};
+
+&cpm_gpio1 {
+ status = "okay";
+};
+
+&cpm_gpio2 {
+ status = "okay";
+};
+
&cpm_syscon0 {
cpm_pinctrl: pinctrl {
compatible = "marvell,armada-7k-pinctrl";
diff --git a/arch/arm64/boot/dts/marvell/armada-80x0.dtsi b/arch/arm64/boot/dts/marvell/armada-80x0.dtsi
index 93d1de03b39a..666ebe96ba0d 100644
--- a/arch/arm64/boot/dts/marvell/armada-80x0.dtsi
+++ b/arch/arm64/boot/dts/marvell/armada-80x0.dtsi
@@ -47,6 +47,22 @@
#include "armada-cp110-master.dtsi"
#include "armada-cp110-slave.dtsi"
+/ {
+ aliases {
+ gpio1 = &cps_gpio1;
+ gpio2 = &cpm_gpio2;
+ };
+};
+
+/* The 80x0 has two CP blocks, but uses only one block from each. */
+&cps_gpio1 {
+ status = "okay";
+};
+
+&cpm_gpio2 {
+ status = "okay";
+};
+
&cpm_syscon0 {
cpm_pinctrl: pinctrl {
compatible = "marvell,armada-8k-cpm-pinctrl";
diff --git a/arch/arm64/boot/dts/marvell/armada-ap806.dtsi b/arch/arm64/boot/dts/marvell/armada-ap806.dtsi
index 4a1b6e0a604a..64608658de5a 100644
--- a/arch/arm64/boot/dts/marvell/armada-ap806.dtsi
+++ b/arch/arm64/boot/dts/marvell/armada-ap806.dtsi
@@ -57,6 +57,7 @@
aliases {
serial0 = &uart0;
serial1 = &uart1;
+ gpio0 = &ap_gpio;
};
psci {
@@ -252,6 +253,15 @@
ap_pinctrl: pinctrl {
compatible = "marvell,ap806-pinctrl";
};
+
+ ap_gpio: gpio {
+ compatible = "marvell,armada-8k-gpio";
+ offset = <0x1040>;
+ ngpios = <19>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ gpio-ranges = <&ap_pinctrl 0 0 19>;
+ };
};
};
};
diff --git a/arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi b/arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi
index 96a4ff75b3b0..f88618185d58 100644
--- a/arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi
+++ b/arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi
@@ -104,6 +104,27 @@
compatible = "marvell,cp110-clock";
#clock-cells = <2>;
};
+
+ cpm_gpio1: gpio at 100 {
+ compatible = "marvell,armada-8k-gpio";
+ offset = <0x100>;
+ ngpios = <32>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ gpio-ranges = <&cpm_pinctrl 0 0 32>;
+ status = "disabled";
+
+ };
+
+ cpm_gpio2: gpio at 140 {
+ compatible = "marvell,armada-8k-gpio";
+ offset = <0x140>;
+ ngpios = <31>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ gpio-ranges = <&cpm_pinctrl 0 32 31>;
+ status = "disabled";
+ };
};
cpm_rtc: rtc at 284000 {
diff --git a/arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi b/arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi
index 48a658aa5b32..f3a6e6742442 100644
--- a/arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi
+++ b/arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi
@@ -111,6 +111,28 @@
compatible = "marvell,cp110-clock";
#clock-cells = <2>;
};
+
+ cps_gpio1: gpio at 100 {
+ compatible = "marvell,armada-8k-gpio";
+ offset = <0x100>;
+ ngpios = <32>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ gpio-ranges = <&cps_pinctrl 0 0 32>;
+ status = "disabled";
+
+ };
+
+ cps_gpio2: gpio at 140 {
+ compatible = "marvell,armada-8k-gpio";
+ offset = <0x140>;
+ ngpios = <31>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ gpio-ranges = <&cps_pinctrl 0 32 31>;
+ status = "disabled";
+ };
+
};
cps_sata0: sata at 540000 {
--
git-series 0.9.1
^ permalink raw reply related [flat|nested] 65+ messages in thread
* Re: [PATCH 5/6] gpio: mvebu: Add support for the Armada 7K/8K SoCs
2017-05-19 16:09 ` Gregory CLEMENT
(?)
@ 2017-05-19 16:24 ` Russell King - ARM Linux
-1 siblings, 0 replies; 65+ messages in thread
From: Russell King - ARM Linux @ 2017-05-19 16:24 UTC (permalink / raw)
To: Gregory CLEMENT
Cc: Linus Walleij, Alexandre Courbot,
linux-gpio-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Jason Cooper, Andrew Lunn,
Sebastian Hesselbarth, Thomas Petazzoni,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Rob Herring,
devicetree-u79uwXL29TY76Z2rM5mHXA, Nadav Haklai,
Kostya Porotchkin, Neta Zur Hershkovits, Marcin Wojtas,
Omri Itach, Shadi Ammouri
On Fri, May 19, 2017 at 06:09:24PM +0200, Gregory CLEMENT wrote:
> The Armada 7K and 8K SoCs use the same gpio controller as most of the
> other mvebu SoCs. However, the main difference is that the GPIO
> controller is part of a bigger system controller, and a syscon is used to
> control the overall system controller. Therefore, the driver needs to be
> adjusted to retrieve the regmap of the syscon to access registers, and
> account for the fact that registers are located at a certain offset
> within the regmap.
>
> This commit add the support of the syscon and introduce a new variant for
> this case.
Do you really need all this complexity of merging what seems to be two
GPIO devices into one for DT purposes? The device itself appears to be
two instances of the orion-gpio controller, one at 0x100 into the
system controller and a second one at 0x140.
If you instantiate two orion-gpio controllers, then you don't need to
add the "mvchip->offset" stuff.
I'd also say that it was the more correct approach, rather than adding
more complexity to GPIO drivers to support whatever incarnation comes
next.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: [PATCH 5/6] gpio: mvebu: Add support for the Armada 7K/8K SoCs
@ 2017-05-19 16:24 ` Russell King - ARM Linux
0 siblings, 0 replies; 65+ messages in thread
From: Russell King - ARM Linux @ 2017-05-19 16:24 UTC (permalink / raw)
To: Gregory CLEMENT
Cc: Linus Walleij, Alexandre Courbot, linux-gpio, linux-kernel,
Jason Cooper, Andrew Lunn, Sebastian Hesselbarth,
Thomas Petazzoni, linux-arm-kernel, Rob Herring, devicetree,
Nadav Haklai, Kostya Porotchkin, Neta Zur Hershkovits,
Marcin Wojtas, Omri Itach, Shadi Ammouri
On Fri, May 19, 2017 at 06:09:24PM +0200, Gregory CLEMENT wrote:
> The Armada 7K and 8K SoCs use the same gpio controller as most of the
> other mvebu SoCs. However, the main difference is that the GPIO
> controller is part of a bigger system controller, and a syscon is used to
> control the overall system controller. Therefore, the driver needs to be
> adjusted to retrieve the regmap of the syscon to access registers, and
> account for the fact that registers are located at a certain offset
> within the regmap.
>
> This commit add the support of the syscon and introduce a new variant for
> this case.
Do you really need all this complexity of merging what seems to be two
GPIO devices into one for DT purposes? The device itself appears to be
two instances of the orion-gpio controller, one at 0x100 into the
system controller and a second one at 0x140.
If you instantiate two orion-gpio controllers, then you don't need to
add the "mvchip->offset" stuff.
I'd also say that it was the more correct approach, rather than adding
more complexity to GPIO drivers to support whatever incarnation comes
next.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply [flat|nested] 65+ messages in thread
* [PATCH 5/6] gpio: mvebu: Add support for the Armada 7K/8K SoCs
@ 2017-05-19 16:24 ` Russell King - ARM Linux
0 siblings, 0 replies; 65+ messages in thread
From: Russell King - ARM Linux @ 2017-05-19 16:24 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, May 19, 2017 at 06:09:24PM +0200, Gregory CLEMENT wrote:
> The Armada 7K and 8K SoCs use the same gpio controller as most of the
> other mvebu SoCs. However, the main difference is that the GPIO
> controller is part of a bigger system controller, and a syscon is used to
> control the overall system controller. Therefore, the driver needs to be
> adjusted to retrieve the regmap of the syscon to access registers, and
> account for the fact that registers are located at a certain offset
> within the regmap.
>
> This commit add the support of the syscon and introduce a new variant for
> this case.
Do you really need all this complexity of merging what seems to be two
GPIO devices into one for DT purposes? The device itself appears to be
two instances of the orion-gpio controller, one at 0x100 into the
system controller and a second one at 0x140.
If you instantiate two orion-gpio controllers, then you don't need to
add the "mvchip->offset" stuff.
I'd also say that it was the more correct approach, rather than adding
more complexity to GPIO drivers to support whatever incarnation comes
next.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: [PATCH 5/6] gpio: mvebu: Add support for the Armada 7K/8K SoCs
2017-05-19 16:24 ` Russell King - ARM Linux
@ 2017-05-19 16:27 ` Russell King - ARM Linux
-1 siblings, 0 replies; 65+ messages in thread
From: Russell King - ARM Linux @ 2017-05-19 16:27 UTC (permalink / raw)
To: Gregory CLEMENT
Cc: Thomas Petazzoni, Alexandre Courbot, Jason Cooper, Andrew Lunn,
Linus Walleij, Omri Itach, linux-kernel, Nadav Haklai,
linux-gpio, devicetree, Rob Herring, Neta Zur Hershkovits,
Kostya Porotchkin, Shadi Ammouri, Marcin Wojtas,
linux-arm-kernel, Sebastian Hesselbarth
On Fri, May 19, 2017 at 05:24:10PM +0100, Russell King - ARM Linux wrote:
> On Fri, May 19, 2017 at 06:09:24PM +0200, Gregory CLEMENT wrote:
> > The Armada 7K and 8K SoCs use the same gpio controller as most of the
> > other mvebu SoCs. However, the main difference is that the GPIO
> > controller is part of a bigger system controller, and a syscon is used to
> > control the overall system controller. Therefore, the driver needs to be
> > adjusted to retrieve the regmap of the syscon to access registers, and
> > account for the fact that registers are located at a certain offset
> > within the regmap.
> >
> > This commit add the support of the syscon and introduce a new variant for
> > this case.
>
> Do you really need all this complexity of merging what seems to be two
> GPIO devices into one for DT purposes? The device itself appears to be
> two instances of the orion-gpio controller, one at 0x100 into the
> system controller and a second one at 0x140.
>
> If you instantiate two orion-gpio controllers, then you don't need to
> add the "mvchip->offset" stuff.
>
> I'd also say that it was the more correct approach, rather than adding
> more complexity to GPIO drivers to support whatever incarnation comes
> next.
Hmm, in fact, mvebu->offset always appears to be zero in this driver,
so I think the changes that add this member are entirely rendundant to
the function of this patch.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply [flat|nested] 65+ messages in thread
* [PATCH 5/6] gpio: mvebu: Add support for the Armada 7K/8K SoCs
@ 2017-05-19 16:27 ` Russell King - ARM Linux
0 siblings, 0 replies; 65+ messages in thread
From: Russell King - ARM Linux @ 2017-05-19 16:27 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, May 19, 2017 at 05:24:10PM +0100, Russell King - ARM Linux wrote:
> On Fri, May 19, 2017 at 06:09:24PM +0200, Gregory CLEMENT wrote:
> > The Armada 7K and 8K SoCs use the same gpio controller as most of the
> > other mvebu SoCs. However, the main difference is that the GPIO
> > controller is part of a bigger system controller, and a syscon is used to
> > control the overall system controller. Therefore, the driver needs to be
> > adjusted to retrieve the regmap of the syscon to access registers, and
> > account for the fact that registers are located at a certain offset
> > within the regmap.
> >
> > This commit add the support of the syscon and introduce a new variant for
> > this case.
>
> Do you really need all this complexity of merging what seems to be two
> GPIO devices into one for DT purposes? The device itself appears to be
> two instances of the orion-gpio controller, one at 0x100 into the
> system controller and a second one at 0x140.
>
> If you instantiate two orion-gpio controllers, then you don't need to
> add the "mvchip->offset" stuff.
>
> I'd also say that it was the more correct approach, rather than adding
> more complexity to GPIO drivers to support whatever incarnation comes
> next.
Hmm, in fact, mvebu->offset always appears to be zero in this driver,
so I think the changes that add this member are entirely rendundant to
the function of this patch.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: [PATCH 5/6] gpio: mvebu: Add support for the Armada 7K/8K SoCs
2017-05-19 16:27 ` Russell King - ARM Linux
(?)
@ 2017-05-19 17:05 ` Thomas Petazzoni
-1 siblings, 0 replies; 65+ messages in thread
From: Thomas Petazzoni @ 2017-05-19 17:05 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Gregory CLEMENT, Alexandre Courbot, Jason Cooper, Andrew Lunn,
Linus Walleij, Omri Itach, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
Nadav Haklai, linux-gpio-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Rob Herring,
Neta Zur Hershkovits, Kostya Porotchkin, Shadi Ammouri,
Marcin Wojtas, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Sebastian Hesselbarth
Hello,
On Fri, 19 May 2017 17:27:36 +0100, Russell King - ARM Linux wrote:
> Hmm, in fact, mvebu->offset always appears to be zero in this driver,
> so I think the changes that add this member are entirely rendundant to
> the function of this patch.
>From PATCH 6/6:
+ offset = <0x1040>;
+ offset = <0x100>;
+ offset = <0x140>;
So, no mvchip->offset is not always 0.
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: [PATCH 5/6] gpio: mvebu: Add support for the Armada 7K/8K SoCs
@ 2017-05-19 17:05 ` Thomas Petazzoni
0 siblings, 0 replies; 65+ messages in thread
From: Thomas Petazzoni @ 2017-05-19 17:05 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Gregory CLEMENT, Alexandre Courbot, Jason Cooper, Andrew Lunn,
Linus Walleij, Omri Itach, linux-kernel, Nadav Haklai,
linux-gpio, devicetree, Rob Herring, Neta Zur Hershkovits,
Kostya Porotchkin, Shadi Ammouri, Marcin Wojtas,
linux-arm-kernel, Sebastian Hesselbarth
Hello,
On Fri, 19 May 2017 17:27:36 +0100, Russell King - ARM Linux wrote:
> Hmm, in fact, mvebu->offset always appears to be zero in this driver,
> so I think the changes that add this member are entirely rendundant to
> the function of this patch.
>From PATCH 6/6:
+ offset = <0x1040>;
+ offset = <0x100>;
+ offset = <0x140>;
So, no mvchip->offset is not always 0.
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 65+ messages in thread
* [PATCH 5/6] gpio: mvebu: Add support for the Armada 7K/8K SoCs
@ 2017-05-19 17:05 ` Thomas Petazzoni
0 siblings, 0 replies; 65+ messages in thread
From: Thomas Petazzoni @ 2017-05-19 17:05 UTC (permalink / raw)
To: linux-arm-kernel
Hello,
On Fri, 19 May 2017 17:27:36 +0100, Russell King - ARM Linux wrote:
> Hmm, in fact, mvebu->offset always appears to be zero in this driver,
> so I think the changes that add this member are entirely rendundant to
> the function of this patch.
>From PATCH 6/6:
+ offset = <0x1040>;
+ offset = <0x100>;
+ offset = <0x140>;
So, no mvchip->offset is not always 0.
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: [PATCH 1/6] gpio: mvebu: sort header include
2017-05-19 16:09 ` Gregory CLEMENT
(?)
@ 2017-05-23 9:15 ` Linus Walleij
-1 siblings, 0 replies; 65+ messages in thread
From: Linus Walleij @ 2017-05-23 9:15 UTC (permalink / raw)
To: Gregory CLEMENT
Cc: Alexandre Courbot, linux-gpio, linux-kernel, Jason Cooper,
Andrew Lunn, Sebastian Hesselbarth, Thomas Petazzoni,
linux-arm-kernel, Rob Herring, devicetree, Russell King,
Nadav Haklai, Kostya Porotchkin, Neta Zur Hershkovits,
Marcin Wojtas, Omri Itach, Shadi Ammouri
On Fri, May 19, 2017 at 6:09 PM, Gregory CLEMENT
<gregory.clement@free-electrons.com> wrote:
> This commit sorts alphabetically the header files.
>
> Reviewed-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Patch applied.
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: [PATCH 1/6] gpio: mvebu: sort header include
@ 2017-05-23 9:15 ` Linus Walleij
0 siblings, 0 replies; 65+ messages in thread
From: Linus Walleij @ 2017-05-23 9:15 UTC (permalink / raw)
To: Gregory CLEMENT
Cc: Alexandre Courbot, linux-gpio, linux-kernel, Jason Cooper,
Andrew Lunn, Sebastian Hesselbarth, Thomas Petazzoni,
linux-arm-kernel, Rob Herring, devicetree, Russell King,
Nadav Haklai, Kostya Porotchkin, Neta Zur Hershkovits,
Marcin Wojtas, Omri Itach, Shadi Ammouri
On Fri, May 19, 2017 at 6:09 PM, Gregory CLEMENT
<gregory.clement@free-electrons.com> wrote:
> This commit sorts alphabetically the header files.
>
> Reviewed-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Patch applied.
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 65+ messages in thread
* [PATCH 1/6] gpio: mvebu: sort header include
@ 2017-05-23 9:15 ` Linus Walleij
0 siblings, 0 replies; 65+ messages in thread
From: Linus Walleij @ 2017-05-23 9:15 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, May 19, 2017 at 6:09 PM, Gregory CLEMENT
<gregory.clement@free-electrons.com> wrote:
> This commit sorts alphabetically the header files.
>
> Reviewed-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Patch applied.
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: [PATCH 2/6] gpio: mvebu: switch to regmap for register access
2017-05-19 16:09 ` Gregory CLEMENT
(?)
@ 2017-05-23 9:16 ` Linus Walleij
-1 siblings, 0 replies; 65+ messages in thread
From: Linus Walleij @ 2017-05-23 9:16 UTC (permalink / raw)
To: Gregory CLEMENT
Cc: Alexandre Courbot, linux-gpio, linux-kernel, Jason Cooper,
Andrew Lunn, Sebastian Hesselbarth, Thomas Petazzoni,
linux-arm-kernel, Rob Herring, devicetree, Russell King,
Nadav Haklai, Kostya Porotchkin, Neta Zur Hershkovits,
Marcin Wojtas, Omri Itach, Shadi Ammouri
On Fri, May 19, 2017 at 6:09 PM, Gregory CLEMENT
<gregory.clement@free-electrons.com> wrote:
> From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
>
> In order to be able to use this driver with the Armada 7K/8K SoCs, we
> need to use the regmap to access the registers. Indeed for these new SoCs,
> the gpio node will be part of a syscon.
>
> [gregory.clement@free-electrons.com:
> - fixed merge conflcit from 4.10 to 4.12-rc1
> - added a commit log]
>
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Patch applied.
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: [PATCH 2/6] gpio: mvebu: switch to regmap for register access
@ 2017-05-23 9:16 ` Linus Walleij
0 siblings, 0 replies; 65+ messages in thread
From: Linus Walleij @ 2017-05-23 9:16 UTC (permalink / raw)
To: Gregory CLEMENT
Cc: Alexandre Courbot, linux-gpio, linux-kernel, Jason Cooper,
Andrew Lunn, Sebastian Hesselbarth, Thomas Petazzoni,
linux-arm-kernel, Rob Herring, devicetree, Russell King,
Nadav Haklai, Kostya Porotchkin, Neta Zur Hershkovits,
Marcin Wojtas, Omri Itach, Shadi Ammouri
On Fri, May 19, 2017 at 6:09 PM, Gregory CLEMENT
<gregory.clement@free-electrons.com> wrote:
> From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
>
> In order to be able to use this driver with the Armada 7K/8K SoCs, we
> need to use the regmap to access the registers. Indeed for these new SoCs,
> the gpio node will be part of a syscon.
>
> [gregory.clement@free-electrons.com:
> - fixed merge conflcit from 4.10 to 4.12-rc1
> - added a commit log]
>
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Patch applied.
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 65+ messages in thread
* [PATCH 2/6] gpio: mvebu: switch to regmap for register access
@ 2017-05-23 9:16 ` Linus Walleij
0 siblings, 0 replies; 65+ messages in thread
From: Linus Walleij @ 2017-05-23 9:16 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, May 19, 2017 at 6:09 PM, Gregory CLEMENT
<gregory.clement@free-electrons.com> wrote:
> From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
>
> In order to be able to use this driver with the Armada 7K/8K SoCs, we
> need to use the regmap to access the registers. Indeed for these new SoCs,
> the gpio node will be part of a syscon.
>
> [gregory.clement at free-electrons.com:
> - fixed merge conflcit from 4.10 to 4.12-rc1
> - added a commit log]
>
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Patch applied.
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: [PATCH 3/6] gpio: dt-bindings: Add documentation for gpio controllers on Armada 7K/8K
2017-05-19 16:09 ` Gregory CLEMENT
(?)
@ 2017-05-23 9:20 ` Linus Walleij
-1 siblings, 0 replies; 65+ messages in thread
From: Linus Walleij @ 2017-05-23 9:20 UTC (permalink / raw)
To: Gregory CLEMENT
Cc: Alexandre Courbot, linux-gpio, linux-kernel, Jason Cooper,
Andrew Lunn, Sebastian Hesselbarth, Thomas Petazzoni,
linux-arm-kernel, Rob Herring, devicetree, Russell King,
Nadav Haklai, Kostya Porotchkin, Neta Zur Hershkovits,
Marcin Wojtas, Omri Itach, Shadi Ammouri
On Fri, May 19, 2017 at 6:09 PM, Gregory CLEMENT
<gregory.clement@free-electrons.com> wrote:
> Document the device tree binding for the gpio controllers found on the
> Marvell Armada 7K and Armada 8K SoCs.
>
> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
This does not apply at all to the GPIO "devel" branch.
And that is a fairly clean v4.12-rc2.
Please rebase and resend the rest of the patches.
Would be nice with a DT ACK but no controversial changes here.
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: [PATCH 3/6] gpio: dt-bindings: Add documentation for gpio controllers on Armada 7K/8K
@ 2017-05-23 9:20 ` Linus Walleij
0 siblings, 0 replies; 65+ messages in thread
From: Linus Walleij @ 2017-05-23 9:20 UTC (permalink / raw)
To: Gregory CLEMENT
Cc: Alexandre Courbot, linux-gpio, linux-kernel, Jason Cooper,
Andrew Lunn, Sebastian Hesselbarth, Thomas Petazzoni,
linux-arm-kernel, Rob Herring, devicetree, Russell King,
Nadav Haklai, Kostya Porotchkin, Neta Zur Hershkovits,
Marcin Wojtas, Omri Itach, Shadi Ammouri
On Fri, May 19, 2017 at 6:09 PM, Gregory CLEMENT
<gregory.clement@free-electrons.com> wrote:
> Document the device tree binding for the gpio controllers found on the
> Marvell Armada 7K and Armada 8K SoCs.
>
> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
This does not apply at all to the GPIO "devel" branch.
And that is a fairly clean v4.12-rc2.
Please rebase and resend the rest of the patches.
Would be nice with a DT ACK but no controversial changes here.
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 65+ messages in thread
* [PATCH 3/6] gpio: dt-bindings: Add documentation for gpio controllers on Armada 7K/8K
@ 2017-05-23 9:20 ` Linus Walleij
0 siblings, 0 replies; 65+ messages in thread
From: Linus Walleij @ 2017-05-23 9:20 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, May 19, 2017 at 6:09 PM, Gregory CLEMENT
<gregory.clement@free-electrons.com> wrote:
> Document the device tree binding for the gpio controllers found on the
> Marvell Armada 7K and Armada 8K SoCs.
>
> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
This does not apply at all to the GPIO "devel" branch.
And that is a fairly clean v4.12-rc2.
Please rebase and resend the rest of the patches.
Would be nice with a DT ACK but no controversial changes here.
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: [PATCH 4/6] gpio: mvebu: allow building driver for Armada 7K/8K
2017-05-19 16:09 ` Gregory CLEMENT
(?)
@ 2017-05-23 9:21 ` Linus Walleij
-1 siblings, 0 replies; 65+ messages in thread
From: Linus Walleij @ 2017-05-23 9:21 UTC (permalink / raw)
To: Gregory CLEMENT
Cc: Alexandre Courbot, linux-gpio, linux-kernel, Jason Cooper,
Andrew Lunn, Sebastian Hesselbarth, Thomas Petazzoni,
linux-arm-kernel, Rob Herring, devicetree, Russell King,
Nadav Haklai, Kostya Porotchkin, Neta Zur Hershkovits,
Marcin Wojtas, Omri Itach, Shadi Ammouri
On Fri, May 19, 2017 at 6:09 PM, Gregory CLEMENT
<gregory.clement@free-electrons.com> wrote:
> The mvebu gpio driver can also be used on arm64 mvebu SoC such as the
> Armada 7K/8K. This commit allows to build the driver for them (when only
> ARCH_MVEBU is defined)
>
> Reviewed-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Patch applied.
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: [PATCH 4/6] gpio: mvebu: allow building driver for Armada 7K/8K
@ 2017-05-23 9:21 ` Linus Walleij
0 siblings, 0 replies; 65+ messages in thread
From: Linus Walleij @ 2017-05-23 9:21 UTC (permalink / raw)
To: Gregory CLEMENT
Cc: Alexandre Courbot, linux-gpio, linux-kernel, Jason Cooper,
Andrew Lunn, Sebastian Hesselbarth, Thomas Petazzoni,
linux-arm-kernel, Rob Herring, devicetree, Russell King,
Nadav Haklai, Kostya Porotchkin, Neta Zur Hershkovits,
Marcin Wojtas, Omri Itach, Shadi Ammouri
On Fri, May 19, 2017 at 6:09 PM, Gregory CLEMENT
<gregory.clement@free-electrons.com> wrote:
> The mvebu gpio driver can also be used on arm64 mvebu SoC such as the
> Armada 7K/8K. This commit allows to build the driver for them (when only
> ARCH_MVEBU is defined)
>
> Reviewed-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Patch applied.
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 65+ messages in thread
* [PATCH 4/6] gpio: mvebu: allow building driver for Armada 7K/8K
@ 2017-05-23 9:21 ` Linus Walleij
0 siblings, 0 replies; 65+ messages in thread
From: Linus Walleij @ 2017-05-23 9:21 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, May 19, 2017 at 6:09 PM, Gregory CLEMENT
<gregory.clement@free-electrons.com> wrote:
> The mvebu gpio driver can also be used on arm64 mvebu SoC such as the
> Armada 7K/8K. This commit allows to build the driver for them (when only
> ARCH_MVEBU is defined)
>
> Reviewed-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Patch applied.
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: [PATCH 3/6] gpio: dt-bindings: Add documentation for gpio controllers on Armada 7K/8K
2017-05-23 9:20 ` Linus Walleij
(?)
@ 2017-05-23 13:06 ` Gregory CLEMENT
-1 siblings, 0 replies; 65+ messages in thread
From: Gregory CLEMENT @ 2017-05-23 13:06 UTC (permalink / raw)
To: Linus Walleij
Cc: Stephen Boyd, Mike Turquette, Alexandre Courbot, linux-gpio,
linux-kernel, Jason Cooper, Andrew Lunn, Sebastian Hesselbarth,
Thomas Petazzoni, linux-arm-kernel, Rob Herring, devicetree,
Russell King, Nadav Haklai, Kostya Porotchkin,
Neta Zur Hershkovits, Marci
Hi Linus,
On mar., mai 23 2017, Linus Walleij <linus.walleij@linaro.org> wrote:
> On Fri, May 19, 2017 at 6:09 PM, Gregory CLEMENT
> <gregory.clement@free-electrons.com> wrote:
>
>> Document the device tree binding for the gpio controllers found on the
>> Marvell Armada 7K and Armada 8K SoCs.
>>
>> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
>
> This does not apply at all to the GPIO "devel" branch.
> And that is a fairly clean v4.12-rc2.
>
> Please rebase and resend the rest of the patches.
Actually I was wrong with my assumption that there was no dependency.
For the binding documentation there is dependecy accross the series I
sent.
This patch depends on "pinctrl: dt-bindings: add documentation for AP806
pin controllers" [1] and "pinctrl: dt-bindings: add documentation for
CP110 pin controllers" [3] from the series "Add support for the pin
controllers on the Marvell Armada 7K/8K".
As you are maintainer of both gpio and pinctrl subsystem it will be easy
to resolv.
But these last patches depend also on "clk: mvebu: ap806: introduce a
new binding" [3] in the clock series "Improve ap806 clk support on
Marvell Armada 7K/8K" and on "clk: mvebu: cp110: introduce a new
binding" [4] in the clock series "Improve cp110 clk support on Marvell
Armada 7K/8K".
So for these particular patches, either I rebase them on the v4.12-rc2
and there will be a small merge conflict during the merge window for
v4.13, or we can ask a stable branch with only these few patches (I am
adding the clock maintainer to this email).
If we chose this last option I can split the clock patches to have patch
modifying only the binding documentation.
Gregory
[1]: http://lists.infradead.org/pipermail/linux-arm-kernel/2017-May/507399.html
[2]: http://lists.infradead.org/pipermail/linux-arm-kernel/2017-May/507398.html
[3]: http://lists.infradead.org/pipermail/linux-arm-kernel/2017-May/507393.html
[4]: http://lists.infradead.org/pipermail/linux-arm-kernel/2017-May/507384.html
> Would be nice with a DT ACK but no controversial changes here.
>
> Yours,
> Linus Walleij
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: [PATCH 3/6] gpio: dt-bindings: Add documentation for gpio controllers on Armada 7K/8K
@ 2017-05-23 13:06 ` Gregory CLEMENT
0 siblings, 0 replies; 65+ messages in thread
From: Gregory CLEMENT @ 2017-05-23 13:06 UTC (permalink / raw)
To: Linus Walleij
Cc: Stephen Boyd, Mike Turquette, Alexandre Courbot, linux-gpio,
linux-kernel, Jason Cooper, Andrew Lunn, Sebastian Hesselbarth,
Thomas Petazzoni, linux-arm-kernel, Rob Herring, devicetree,
Russell King, Nadav Haklai, Kostya Porotchkin,
Neta Zur Hershkovits, Marcin Wojtas, Omri Itach, Shadi Ammouri
Hi Linus,
On mar., mai 23 2017, Linus Walleij <linus.walleij@linaro.org> wrote:
> On Fri, May 19, 2017 at 6:09 PM, Gregory CLEMENT
> <gregory.clement@free-electrons.com> wrote:
>
>> Document the device tree binding for the gpio controllers found on the
>> Marvell Armada 7K and Armada 8K SoCs.
>>
>> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
>
> This does not apply at all to the GPIO "devel" branch.
> And that is a fairly clean v4.12-rc2.
>
> Please rebase and resend the rest of the patches.
Actually I was wrong with my assumption that there was no dependency.
For the binding documentation there is dependecy accross the series I
sent.
This patch depends on "pinctrl: dt-bindings: add documentation for AP806
pin controllers" [1] and "pinctrl: dt-bindings: add documentation for
CP110 pin controllers" [3] from the series "Add support for the pin
controllers on the Marvell Armada 7K/8K".
As you are maintainer of both gpio and pinctrl subsystem it will be easy
to resolv.
But these last patches depend also on "clk: mvebu: ap806: introduce a
new binding" [3] in the clock series "Improve ap806 clk support on
Marvell Armada 7K/8K" and on "clk: mvebu: cp110: introduce a new
binding" [4] in the clock series "Improve cp110 clk support on Marvell
Armada 7K/8K".
So for these particular patches, either I rebase them on the v4.12-rc2
and there will be a small merge conflict during the merge window for
v4.13, or we can ask a stable branch with only these few patches (I am
adding the clock maintainer to this email).
If we chose this last option I can split the clock patches to have patch
modifying only the binding documentation.
Gregory
[1]: http://lists.infradead.org/pipermail/linux-arm-kernel/2017-May/507399.html
[2]: http://lists.infradead.org/pipermail/linux-arm-kernel/2017-May/507398.html
[3]: http://lists.infradead.org/pipermail/linux-arm-kernel/2017-May/507393.html
[4]: http://lists.infradead.org/pipermail/linux-arm-kernel/2017-May/507384.html
> Would be nice with a DT ACK but no controversial changes here.
>
> Yours,
> Linus Walleij
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply [flat|nested] 65+ messages in thread
* [PATCH 3/6] gpio: dt-bindings: Add documentation for gpio controllers on Armada 7K/8K
@ 2017-05-23 13:06 ` Gregory CLEMENT
0 siblings, 0 replies; 65+ messages in thread
From: Gregory CLEMENT @ 2017-05-23 13:06 UTC (permalink / raw)
To: linux-arm-kernel
Hi Linus,
On mar., mai 23 2017, Linus Walleij <linus.walleij@linaro.org> wrote:
> On Fri, May 19, 2017 at 6:09 PM, Gregory CLEMENT
> <gregory.clement@free-electrons.com> wrote:
>
>> Document the device tree binding for the gpio controllers found on the
>> Marvell Armada 7K and Armada 8K SoCs.
>>
>> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
>
> This does not apply at all to the GPIO "devel" branch.
> And that is a fairly clean v4.12-rc2.
>
> Please rebase and resend the rest of the patches.
Actually I was wrong with my assumption that there was no dependency.
For the binding documentation there is dependecy accross the series I
sent.
This patch depends on "pinctrl: dt-bindings: add documentation for AP806
pin controllers" [1] and "pinctrl: dt-bindings: add documentation for
CP110 pin controllers" [3] from the series "Add support for the pin
controllers on the Marvell Armada 7K/8K".
As you are maintainer of both gpio and pinctrl subsystem it will be easy
to resolv.
But these last patches depend also on "clk: mvebu: ap806: introduce a
new binding" [3] in the clock series "Improve ap806 clk support on
Marvell Armada 7K/8K" and on "clk: mvebu: cp110: introduce a new
binding" [4] in the clock series "Improve cp110 clk support on Marvell
Armada 7K/8K".
So for these particular patches, either I rebase them on the v4.12-rc2
and there will be a small merge conflict during the merge window for
v4.13, or we can ask a stable branch with only these few patches (I am
adding the clock maintainer to this email).
If we chose this last option I can split the clock patches to have patch
modifying only the binding documentation.
Gregory
[1]: http://lists.infradead.org/pipermail/linux-arm-kernel/2017-May/507399.html
[2]: http://lists.infradead.org/pipermail/linux-arm-kernel/2017-May/507398.html
[3]: http://lists.infradead.org/pipermail/linux-arm-kernel/2017-May/507393.html
[4]: http://lists.infradead.org/pipermail/linux-arm-kernel/2017-May/507384.html
> Would be nice with a DT ACK but no controversial changes here.
>
> Yours,
> Linus Walleij
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: [PATCH 3/6] gpio: dt-bindings: Add documentation for gpio controllers on Armada 7K/8K
2017-05-23 13:06 ` Gregory CLEMENT
(?)
@ 2017-05-29 8:08 ` Linus Walleij
-1 siblings, 0 replies; 65+ messages in thread
From: Linus Walleij @ 2017-05-29 8:08 UTC (permalink / raw)
To: Gregory CLEMENT
Cc: Stephen Boyd, Mike Turquette, Alexandre Courbot, linux-gpio,
linux-kernel, Jason Cooper, Andrew Lunn, Sebastian Hesselbarth,
Thomas Petazzoni, linux-arm-kernel, Rob Herring, devicetree,
Russell King, Nadav Haklai, Kostya Porotchkin,
Neta Zur Hershkovits, Marcin
On Tue, May 23, 2017 at 3:06 PM, Gregory CLEMENT
<gregory.clement@free-electrons.com> wrote:
> On mar., mai 23 2017, Linus Walleij <linus.walleij@linaro.org> wrote:
>> Please rebase and resend the rest of the patches.
>
> Actually I was wrong with my assumption that there was no dependency.
> For the binding documentation there is dependecy accross the series I
> sent.
>
> This patch depends on "pinctrl: dt-bindings: add documentation for AP806
> pin controllers" [1] and "pinctrl: dt-bindings: add documentation for
> CP110 pin controllers" [3] from the series "Add support for the pin
> controllers on the Marvell Armada 7K/8K".
>
> As you are maintainer of both gpio and pinctrl subsystem it will be easy
> to resolv.
Please send all patches in one big series in that case, so I can apply
them all to a branch and merge that branch into both trees.
> But these last patches depend also on "clk: mvebu: ap806: introduce a
> new binding" [3] in the clock series "Improve ap806 clk support on
> Marvell Armada 7K/8K" and on "clk: mvebu: cp110: introduce a new
> binding" [4] in the clock series "Improve cp110 clk support on Marvell
> Armada 7K/8K".
That sounds messy.
> So for these particular patches, either I rebase them on the v4.12-rc2
> and there will be a small merge conflict during the merge window for
> v4.13, or we can ask a stable branch with only these few patches (I am
> adding the clock maintainer to this email).
>
> If we chose this last option I can split the clock patches to have patch
> modifying only the binding documentation.
I think you can make a patch just modifying the binding documentation
and then apply that patch to *both* trees, just make sure the patch
is *final* and not applied in different versions in clk and pinctrl.
I think cross-tree branches for documentation clashes is too much
bureaucracy.
Make sure your clock patch is finalized and preferably also applied
to the clk tree then put it in the bottom of the patch set you send
to me as well and I will proceed like above.
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: [PATCH 3/6] gpio: dt-bindings: Add documentation for gpio controllers on Armada 7K/8K
@ 2017-05-29 8:08 ` Linus Walleij
0 siblings, 0 replies; 65+ messages in thread
From: Linus Walleij @ 2017-05-29 8:08 UTC (permalink / raw)
To: Gregory CLEMENT
Cc: Stephen Boyd, Mike Turquette, Alexandre Courbot, linux-gpio,
linux-kernel, Jason Cooper, Andrew Lunn, Sebastian Hesselbarth,
Thomas Petazzoni, linux-arm-kernel, Rob Herring, devicetree,
Russell King, Nadav Haklai, Kostya Porotchkin,
Neta Zur Hershkovits, Marcin Wojtas, Omri Itach, Shadi Ammouri
On Tue, May 23, 2017 at 3:06 PM, Gregory CLEMENT
<gregory.clement@free-electrons.com> wrote:
> On mar., mai 23 2017, Linus Walleij <linus.walleij@linaro.org> wrote:
>> Please rebase and resend the rest of the patches.
>
> Actually I was wrong with my assumption that there was no dependency.
> For the binding documentation there is dependecy accross the series I
> sent.
>
> This patch depends on "pinctrl: dt-bindings: add documentation for AP806
> pin controllers" [1] and "pinctrl: dt-bindings: add documentation for
> CP110 pin controllers" [3] from the series "Add support for the pin
> controllers on the Marvell Armada 7K/8K".
>
> As you are maintainer of both gpio and pinctrl subsystem it will be easy
> to resolv.
Please send all patches in one big series in that case, so I can apply
them all to a branch and merge that branch into both trees.
> But these last patches depend also on "clk: mvebu: ap806: introduce a
> new binding" [3] in the clock series "Improve ap806 clk support on
> Marvell Armada 7K/8K" and on "clk: mvebu: cp110: introduce a new
> binding" [4] in the clock series "Improve cp110 clk support on Marvell
> Armada 7K/8K".
That sounds messy.
> So for these particular patches, either I rebase them on the v4.12-rc2
> and there will be a small merge conflict during the merge window for
> v4.13, or we can ask a stable branch with only these few patches (I am
> adding the clock maintainer to this email).
>
> If we chose this last option I can split the clock patches to have patch
> modifying only the binding documentation.
I think you can make a patch just modifying the binding documentation
and then apply that patch to *both* trees, just make sure the patch
is *final* and not applied in different versions in clk and pinctrl.
I think cross-tree branches for documentation clashes is too much
bureaucracy.
Make sure your clock patch is finalized and preferably also applied
to the clk tree then put it in the bottom of the patch set you send
to me as well and I will proceed like above.
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 65+ messages in thread
* [PATCH 3/6] gpio: dt-bindings: Add documentation for gpio controllers on Armada 7K/8K
@ 2017-05-29 8:08 ` Linus Walleij
0 siblings, 0 replies; 65+ messages in thread
From: Linus Walleij @ 2017-05-29 8:08 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, May 23, 2017 at 3:06 PM, Gregory CLEMENT
<gregory.clement@free-electrons.com> wrote:
> On mar., mai 23 2017, Linus Walleij <linus.walleij@linaro.org> wrote:
>> Please rebase and resend the rest of the patches.
>
> Actually I was wrong with my assumption that there was no dependency.
> For the binding documentation there is dependecy accross the series I
> sent.
>
> This patch depends on "pinctrl: dt-bindings: add documentation for AP806
> pin controllers" [1] and "pinctrl: dt-bindings: add documentation for
> CP110 pin controllers" [3] from the series "Add support for the pin
> controllers on the Marvell Armada 7K/8K".
>
> As you are maintainer of both gpio and pinctrl subsystem it will be easy
> to resolv.
Please send all patches in one big series in that case, so I can apply
them all to a branch and merge that branch into both trees.
> But these last patches depend also on "clk: mvebu: ap806: introduce a
> new binding" [3] in the clock series "Improve ap806 clk support on
> Marvell Armada 7K/8K" and on "clk: mvebu: cp110: introduce a new
> binding" [4] in the clock series "Improve cp110 clk support on Marvell
> Armada 7K/8K".
That sounds messy.
> So for these particular patches, either I rebase them on the v4.12-rc2
> and there will be a small merge conflict during the merge window for
> v4.13, or we can ask a stable branch with only these few patches (I am
> adding the clock maintainer to this email).
>
> If we chose this last option I can split the clock patches to have patch
> modifying only the binding documentation.
I think you can make a patch just modifying the binding documentation
and then apply that patch to *both* trees, just make sure the patch
is *final* and not applied in different versions in clk and pinctrl.
I think cross-tree branches for documentation clashes is too much
bureaucracy.
Make sure your clock patch is finalized and preferably also applied
to the clk tree then put it in the bottom of the patch set you send
to me as well and I will proceed like above.
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: [PATCH 3/6] gpio: dt-bindings: Add documentation for gpio controllers on Armada 7K/8K
2017-05-29 8:08 ` Linus Walleij
(?)
@ 2017-05-30 22:23 ` Rob Herring
-1 siblings, 0 replies; 65+ messages in thread
From: Rob Herring @ 2017-05-30 22:23 UTC (permalink / raw)
To: Linus Walleij
Cc: Gregory CLEMENT, Stephen Boyd, Mike Turquette, Alexandre Courbot,
linux-gpio, linux-kernel, Jason Cooper, Andrew Lunn,
Sebastian Hesselbarth, Thomas Petazzoni, linux-arm-kernel,
devicetree, Russell King, Nadav Haklai, Kostya Porotchkin,
Neta Zur Hershkovits
On Mon, May 29, 2017 at 10:08:16AM +0200, Linus Walleij wrote:
> On Tue, May 23, 2017 at 3:06 PM, Gregory CLEMENT
> <gregory.clement@free-electrons.com> wrote:
> > On mar., mai 23 2017, Linus Walleij <linus.walleij@linaro.org> wrote:
>
> >> Please rebase and resend the rest of the patches.
> >
> > Actually I was wrong with my assumption that there was no dependency.
> > For the binding documentation there is dependecy accross the series I
> > sent.
> >
> > This patch depends on "pinctrl: dt-bindings: add documentation for AP806
> > pin controllers" [1] and "pinctrl: dt-bindings: add documentation for
> > CP110 pin controllers" [3] from the series "Add support for the pin
> > controllers on the Marvell Armada 7K/8K".
> >
> > As you are maintainer of both gpio and pinctrl subsystem it will be easy
> > to resolv.
>
> Please send all patches in one big series in that case, so I can apply
> them all to a branch and merge that branch into both trees.
>
> > But these last patches depend also on "clk: mvebu: ap806: introduce a
> > new binding" [3] in the clock series "Improve ap806 clk support on
> > Marvell Armada 7K/8K" and on "clk: mvebu: cp110: introduce a new
> > binding" [4] in the clock series "Improve cp110 clk support on Marvell
> > Armada 7K/8K".
>
> That sounds messy.
>
> > So for these particular patches, either I rebase them on the v4.12-rc2
> > and there will be a small merge conflict during the merge window for
> > v4.13, or we can ask a stable branch with only these few patches (I am
> > adding the clock maintainer to this email).
> >
> > If we chose this last option I can split the clock patches to have patch
> > modifying only the binding documentation.
>
> I think you can make a patch just modifying the binding documentation
> and then apply that patch to *both* trees, just make sure the patch
> is *final* and not applied in different versions in clk and pinctrl.
I thought we try to avoid doing that.
> I think cross-tree branches for documentation clashes is too much
> bureaucracy.
I can just take all the doc patches separately. Or you can take the
clock one too.
> Make sure your clock patch is finalized and preferably also applied
> to the clk tree then put it in the bottom of the patch set you send
> to me as well and I will proceed like above.
>
> Yours,
> Linus Walleij
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: [PATCH 3/6] gpio: dt-bindings: Add documentation for gpio controllers on Armada 7K/8K
@ 2017-05-30 22:23 ` Rob Herring
0 siblings, 0 replies; 65+ messages in thread
From: Rob Herring @ 2017-05-30 22:23 UTC (permalink / raw)
To: Linus Walleij
Cc: Gregory CLEMENT, Stephen Boyd, Mike Turquette, Alexandre Courbot,
linux-gpio, linux-kernel, Jason Cooper, Andrew Lunn,
Sebastian Hesselbarth, Thomas Petazzoni, linux-arm-kernel,
devicetree, Russell King, Nadav Haklai, Kostya Porotchkin,
Neta Zur Hershkovits, Marcin Wojtas, Omri Itach, Shadi Ammouri
On Mon, May 29, 2017 at 10:08:16AM +0200, Linus Walleij wrote:
> On Tue, May 23, 2017 at 3:06 PM, Gregory CLEMENT
> <gregory.clement@free-electrons.com> wrote:
> > On mar., mai 23 2017, Linus Walleij <linus.walleij@linaro.org> wrote:
>
> >> Please rebase and resend the rest of the patches.
> >
> > Actually I was wrong with my assumption that there was no dependency.
> > For the binding documentation there is dependecy accross the series I
> > sent.
> >
> > This patch depends on "pinctrl: dt-bindings: add documentation for AP806
> > pin controllers" [1] and "pinctrl: dt-bindings: add documentation for
> > CP110 pin controllers" [3] from the series "Add support for the pin
> > controllers on the Marvell Armada 7K/8K".
> >
> > As you are maintainer of both gpio and pinctrl subsystem it will be easy
> > to resolv.
>
> Please send all patches in one big series in that case, so I can apply
> them all to a branch and merge that branch into both trees.
>
> > But these last patches depend also on "clk: mvebu: ap806: introduce a
> > new binding" [3] in the clock series "Improve ap806 clk support on
> > Marvell Armada 7K/8K" and on "clk: mvebu: cp110: introduce a new
> > binding" [4] in the clock series "Improve cp110 clk support on Marvell
> > Armada 7K/8K".
>
> That sounds messy.
>
> > So for these particular patches, either I rebase them on the v4.12-rc2
> > and there will be a small merge conflict during the merge window for
> > v4.13, or we can ask a stable branch with only these few patches (I am
> > adding the clock maintainer to this email).
> >
> > If we chose this last option I can split the clock patches to have patch
> > modifying only the binding documentation.
>
> I think you can make a patch just modifying the binding documentation
> and then apply that patch to *both* trees, just make sure the patch
> is *final* and not applied in different versions in clk and pinctrl.
I thought we try to avoid doing that.
> I think cross-tree branches for documentation clashes is too much
> bureaucracy.
I can just take all the doc patches separately. Or you can take the
clock one too.
> Make sure your clock patch is finalized and preferably also applied
> to the clk tree then put it in the bottom of the patch set you send
> to me as well and I will proceed like above.
>
> Yours,
> Linus Walleij
^ permalink raw reply [flat|nested] 65+ messages in thread
* [PATCH 3/6] gpio: dt-bindings: Add documentation for gpio controllers on Armada 7K/8K
@ 2017-05-30 22:23 ` Rob Herring
0 siblings, 0 replies; 65+ messages in thread
From: Rob Herring @ 2017-05-30 22:23 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, May 29, 2017 at 10:08:16AM +0200, Linus Walleij wrote:
> On Tue, May 23, 2017 at 3:06 PM, Gregory CLEMENT
> <gregory.clement@free-electrons.com> wrote:
> > On mar., mai 23 2017, Linus Walleij <linus.walleij@linaro.org> wrote:
>
> >> Please rebase and resend the rest of the patches.
> >
> > Actually I was wrong with my assumption that there was no dependency.
> > For the binding documentation there is dependecy accross the series I
> > sent.
> >
> > This patch depends on "pinctrl: dt-bindings: add documentation for AP806
> > pin controllers" [1] and "pinctrl: dt-bindings: add documentation for
> > CP110 pin controllers" [3] from the series "Add support for the pin
> > controllers on the Marvell Armada 7K/8K".
> >
> > As you are maintainer of both gpio and pinctrl subsystem it will be easy
> > to resolv.
>
> Please send all patches in one big series in that case, so I can apply
> them all to a branch and merge that branch into both trees.
>
> > But these last patches depend also on "clk: mvebu: ap806: introduce a
> > new binding" [3] in the clock series "Improve ap806 clk support on
> > Marvell Armada 7K/8K" and on "clk: mvebu: cp110: introduce a new
> > binding" [4] in the clock series "Improve cp110 clk support on Marvell
> > Armada 7K/8K".
>
> That sounds messy.
>
> > So for these particular patches, either I rebase them on the v4.12-rc2
> > and there will be a small merge conflict during the merge window for
> > v4.13, or we can ask a stable branch with only these few patches (I am
> > adding the clock maintainer to this email).
> >
> > If we chose this last option I can split the clock patches to have patch
> > modifying only the binding documentation.
>
> I think you can make a patch just modifying the binding documentation
> and then apply that patch to *both* trees, just make sure the patch
> is *final* and not applied in different versions in clk and pinctrl.
I thought we try to avoid doing that.
> I think cross-tree branches for documentation clashes is too much
> bureaucracy.
I can just take all the doc patches separately. Or you can take the
clock one too.
> Make sure your clock patch is finalized and preferably also applied
> to the clk tree then put it in the bottom of the patch set you send
> to me as well and I will proceed like above.
>
> Yours,
> Linus Walleij
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: [PATCH 3/6] gpio: dt-bindings: Add documentation for gpio controllers on Armada 7K/8K
2017-05-19 16:09 ` Gregory CLEMENT
(?)
@ 2017-05-30 22:29 ` Rob Herring
-1 siblings, 0 replies; 65+ messages in thread
From: Rob Herring @ 2017-05-30 22:29 UTC (permalink / raw)
To: Gregory CLEMENT
Cc: Linus Walleij, Alexandre Courbot,
linux-gpio-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Jason Cooper, Andrew Lunn,
Sebastian Hesselbarth, Thomas Petazzoni,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA, Russell King, Nadav Haklai,
Kostya Porotchkin, Neta Zur Hershkovits, Marcin Wojtas,
Omri Itach, Shadi Ammouri
On Fri, May 19, 2017 at 06:09:22PM +0200, Gregory CLEMENT wrote:
> Document the device tree binding for the gpio controllers found on the
> Marvell Armada 7K and Armada 8K SoCs.
>
> Signed-off-by: Gregory CLEMENT <gregory.clement-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
> ---
> Documentation/devicetree/bindings/arm/marvell/ap806-system-controller.txt | 20 ++++++++++++++++++++
> Documentation/devicetree/bindings/arm/marvell/cp110-system-controller0.txt | 24 +++++++++++++++++++++++-
> Documentation/devicetree/bindings/gpio/gpio-mvebu.txt | 24 +++++++++++++++++-------
> 3 files changed, 60 insertions(+), 8 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/arm/marvell/ap806-system-controller.txt b/Documentation/devicetree/bindings/arm/marvell/ap806-system-controller.txt
> index 4228d158fb31..0b887440e08a 100644
> --- a/Documentation/devicetree/bindings/arm/marvell/ap806-system-controller.txt
> +++ b/Documentation/devicetree/bindings/arm/marvell/ap806-system-controller.txt
> @@ -64,6 +64,17 @@ mpp17 17 gpio
> mpp18 18 gpio
> mpp19 19 gpio, uart0(rxd), sdio(pw_off)
>
> +GPIO:
> +-----
> +For common binding part and usage, refer to
> +Documentation/devicetree/bindings/gpio/gpio-mvebu.txt.
> +
> +Required properties:
> +
> +- compatible: "marvell,armada-8k-gpio"
> +
> +- offset: offset address inside the syscon block
> +
> Example:
> ap_syscon: system-controller@6f4000 {
> compatible = "syscon", "simple-mfd";
> @@ -77,4 +88,13 @@ ap_syscon: system-controller@6f4000 {
> ap_pinctrl: pinctrl {
> compatible = "marvell,ap806-pinctrl";
> };
> +
> + ap_gpio: gpio {
> + compatible = "marvell,armada-8k-gpio";
> + offset = <0x1040>;
> + ngpios = <19>;
> + gpio-controller;
> + #gpio-cells = <2>;
> + gpio-ranges = <&ap_pinctrl 0 0 19>;
> + };
> };
> diff --git a/Documentation/devicetree/bindings/arm/marvell/cp110-system-controller0.txt b/Documentation/devicetree/bindings/arm/marvell/cp110-system-controller0.txt
> index 733beac7724e..655c114ef584 100644
> --- a/Documentation/devicetree/bindings/arm/marvell/cp110-system-controller0.txt
> +++ b/Documentation/devicetree/bindings/arm/marvell/cp110-system-controller0.txt
> @@ -149,6 +149,18 @@ mpp60 60 gpio, mss_gpio6, ptp(pulse), tdm(dtx), au(i2smclk), spi0(csn1), uart0(r
> mpp61 61 gpio, mss_gpio5, ptp(clk), tdm(pclk), au(i2sextclk), spi0(csn2), uart0(txd), uart2(txd), sata1(present_act), ge(mdio), sdio(d3)
> mpp62 62 gpio, mss_gpio4, synce1(clk), ptp(pclk_out), sata1(present_act), spi0(csn3), uart0(rxd), uart2(rxd), sata0(present_act), ge(mdc)
>
> +GPIO:
> +-----
> +
> +For common binding part and usage, refer to
> +Documentation/devicetree/bindings/gpio/gpio-mvebu.txt.
> +
> +Required properties:
> +
> +- compatible: "marvell,armada-8k-gpio"
> +
> +- offset: offset address inside the syscon block
> +
> Example:
>
> cpm_syscon0: system-controller@440000 {
> @@ -163,5 +175,15 @@ cpm_syscon0: system-controller@440000 {
> cpm_pinctrl: pinctrl {
> compatible = "marvell,armada-8k-cpm-pinctrl";
> };
> -};
>
> + cpm_gpio1: gpio@100 {
> + compatible = "marvell,armada-8k-gpio";
> + offset = <0x100>;
> + ngpios = <32>;
> + gpio-controller;
> + #gpio-cells = <2>;
> + gpio-ranges = <&cpm_pinctrl 0 0 32>;
> + status = "disabled";
> + };
> +
> +};
> diff --git a/Documentation/devicetree/bindings/gpio/gpio-mvebu.txt b/Documentation/devicetree/bindings/gpio/gpio-mvebu.txt
> index 42c3bb2d53e8..2c5304ff467c 100644
> --- a/Documentation/devicetree/bindings/gpio/gpio-mvebu.txt
> +++ b/Documentation/devicetree/bindings/gpio/gpio-mvebu.txt
> @@ -2,17 +2,27 @@
>
> Required properties:
>
> -- compatible : Should be "marvell,orion-gpio", "marvell,mv78200-gpio"
> - or "marvell,armadaxp-gpio". "marvell,orion-gpio" should be used for
> - Orion, Kirkwood, Dove, Discovery (except MV78200) and Armada
> - 370. "marvell,mv78200-gpio" should be used for the Discovery
> - MV78200. "marvel,armadaxp-gpio" should be used for all Armada XP
> - SoCs (MV78230, MV78260, MV78460).
> +- compatible : Should be "marvell,orion-gpio", "marvell,mv78200-gpio",
> + "marvell,armadaxp-gpio" or "marvell,armada-8k-gpio".
> +
> + "marvell,orion-gpio" should be used for Orion, Kirkwood, Dove,
> + Discovery (except MV78200) and Armada 370. "marvell,mv78200-gpio"
> + should be used for the Discovery MV78200.
> +
> + "marvel,armadaxp-gpio" should be used for all Armada XP SoCs
> + (MV78230, MV78260, MV78460).
> +
> + "marvell,armada-8k-gpio" should be used for the Armada 7K and 8K
> + SoCs (either from AP or CP), see
> + Documentation/devicetree/bindings/arm/marvell/cp110-system-controller0.txt
> + and
> + Documentation/devicetree/bindings/arm/marvell/ap806-system-controller.txt
> + for specific details about the offset property.
>
> - reg: Address and length of the register set for the device. Only one
> entry is expected, except for the "marvell,armadaxp-gpio" variant
> for which two entries are expected: one for the general registers,
> - one for the per-cpu registers.
> + one for the per-cpu registers. Not used for marvell,armada-8k-gpio.
Why can't use you use reg instead of offset?
Rob
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: [PATCH 3/6] gpio: dt-bindings: Add documentation for gpio controllers on Armada 7K/8K
@ 2017-05-30 22:29 ` Rob Herring
0 siblings, 0 replies; 65+ messages in thread
From: Rob Herring @ 2017-05-30 22:29 UTC (permalink / raw)
To: Gregory CLEMENT
Cc: Linus Walleij, Alexandre Courbot, linux-gpio, linux-kernel,
Jason Cooper, Andrew Lunn, Sebastian Hesselbarth,
Thomas Petazzoni, linux-arm-kernel, devicetree, Russell King,
Nadav Haklai, Kostya Porotchkin, Neta Zur Hershkovits,
Marcin Wojtas, Omri Itach, Shadi Ammouri
On Fri, May 19, 2017 at 06:09:22PM +0200, Gregory CLEMENT wrote:
> Document the device tree binding for the gpio controllers found on the
> Marvell Armada 7K and Armada 8K SoCs.
>
> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
> ---
> Documentation/devicetree/bindings/arm/marvell/ap806-system-controller.txt | 20 ++++++++++++++++++++
> Documentation/devicetree/bindings/arm/marvell/cp110-system-controller0.txt | 24 +++++++++++++++++++++++-
> Documentation/devicetree/bindings/gpio/gpio-mvebu.txt | 24 +++++++++++++++++-------
> 3 files changed, 60 insertions(+), 8 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/arm/marvell/ap806-system-controller.txt b/Documentation/devicetree/bindings/arm/marvell/ap806-system-controller.txt
> index 4228d158fb31..0b887440e08a 100644
> --- a/Documentation/devicetree/bindings/arm/marvell/ap806-system-controller.txt
> +++ b/Documentation/devicetree/bindings/arm/marvell/ap806-system-controller.txt
> @@ -64,6 +64,17 @@ mpp17 17 gpio
> mpp18 18 gpio
> mpp19 19 gpio, uart0(rxd), sdio(pw_off)
>
> +GPIO:
> +-----
> +For common binding part and usage, refer to
> +Documentation/devicetree/bindings/gpio/gpio-mvebu.txt.
> +
> +Required properties:
> +
> +- compatible: "marvell,armada-8k-gpio"
> +
> +- offset: offset address inside the syscon block
> +
> Example:
> ap_syscon: system-controller@6f4000 {
> compatible = "syscon", "simple-mfd";
> @@ -77,4 +88,13 @@ ap_syscon: system-controller@6f4000 {
> ap_pinctrl: pinctrl {
> compatible = "marvell,ap806-pinctrl";
> };
> +
> + ap_gpio: gpio {
> + compatible = "marvell,armada-8k-gpio";
> + offset = <0x1040>;
> + ngpios = <19>;
> + gpio-controller;
> + #gpio-cells = <2>;
> + gpio-ranges = <&ap_pinctrl 0 0 19>;
> + };
> };
> diff --git a/Documentation/devicetree/bindings/arm/marvell/cp110-system-controller0.txt b/Documentation/devicetree/bindings/arm/marvell/cp110-system-controller0.txt
> index 733beac7724e..655c114ef584 100644
> --- a/Documentation/devicetree/bindings/arm/marvell/cp110-system-controller0.txt
> +++ b/Documentation/devicetree/bindings/arm/marvell/cp110-system-controller0.txt
> @@ -149,6 +149,18 @@ mpp60 60 gpio, mss_gpio6, ptp(pulse), tdm(dtx), au(i2smclk), spi0(csn1), uart0(r
> mpp61 61 gpio, mss_gpio5, ptp(clk), tdm(pclk), au(i2sextclk), spi0(csn2), uart0(txd), uart2(txd), sata1(present_act), ge(mdio), sdio(d3)
> mpp62 62 gpio, mss_gpio4, synce1(clk), ptp(pclk_out), sata1(present_act), spi0(csn3), uart0(rxd), uart2(rxd), sata0(present_act), ge(mdc)
>
> +GPIO:
> +-----
> +
> +For common binding part and usage, refer to
> +Documentation/devicetree/bindings/gpio/gpio-mvebu.txt.
> +
> +Required properties:
> +
> +- compatible: "marvell,armada-8k-gpio"
> +
> +- offset: offset address inside the syscon block
> +
> Example:
>
> cpm_syscon0: system-controller@440000 {
> @@ -163,5 +175,15 @@ cpm_syscon0: system-controller@440000 {
> cpm_pinctrl: pinctrl {
> compatible = "marvell,armada-8k-cpm-pinctrl";
> };
> -};
>
> + cpm_gpio1: gpio@100 {
> + compatible = "marvell,armada-8k-gpio";
> + offset = <0x100>;
> + ngpios = <32>;
> + gpio-controller;
> + #gpio-cells = <2>;
> + gpio-ranges = <&cpm_pinctrl 0 0 32>;
> + status = "disabled";
> + };
> +
> +};
> diff --git a/Documentation/devicetree/bindings/gpio/gpio-mvebu.txt b/Documentation/devicetree/bindings/gpio/gpio-mvebu.txt
> index 42c3bb2d53e8..2c5304ff467c 100644
> --- a/Documentation/devicetree/bindings/gpio/gpio-mvebu.txt
> +++ b/Documentation/devicetree/bindings/gpio/gpio-mvebu.txt
> @@ -2,17 +2,27 @@
>
> Required properties:
>
> -- compatible : Should be "marvell,orion-gpio", "marvell,mv78200-gpio"
> - or "marvell,armadaxp-gpio". "marvell,orion-gpio" should be used for
> - Orion, Kirkwood, Dove, Discovery (except MV78200) and Armada
> - 370. "marvell,mv78200-gpio" should be used for the Discovery
> - MV78200. "marvel,armadaxp-gpio" should be used for all Armada XP
> - SoCs (MV78230, MV78260, MV78460).
> +- compatible : Should be "marvell,orion-gpio", "marvell,mv78200-gpio",
> + "marvell,armadaxp-gpio" or "marvell,armada-8k-gpio".
> +
> + "marvell,orion-gpio" should be used for Orion, Kirkwood, Dove,
> + Discovery (except MV78200) and Armada 370. "marvell,mv78200-gpio"
> + should be used for the Discovery MV78200.
> +
> + "marvel,armadaxp-gpio" should be used for all Armada XP SoCs
> + (MV78230, MV78260, MV78460).
> +
> + "marvell,armada-8k-gpio" should be used for the Armada 7K and 8K
> + SoCs (either from AP or CP), see
> + Documentation/devicetree/bindings/arm/marvell/cp110-system-controller0.txt
> + and
> + Documentation/devicetree/bindings/arm/marvell/ap806-system-controller.txt
> + for specific details about the offset property.
>
> - reg: Address and length of the register set for the device. Only one
> entry is expected, except for the "marvell,armadaxp-gpio" variant
> for which two entries are expected: one for the general registers,
> - one for the per-cpu registers.
> + one for the per-cpu registers. Not used for marvell,armada-8k-gpio.
Why can't use you use reg instead of offset?
Rob
^ permalink raw reply [flat|nested] 65+ messages in thread
* [PATCH 3/6] gpio: dt-bindings: Add documentation for gpio controllers on Armada 7K/8K
@ 2017-05-30 22:29 ` Rob Herring
0 siblings, 0 replies; 65+ messages in thread
From: Rob Herring @ 2017-05-30 22:29 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, May 19, 2017 at 06:09:22PM +0200, Gregory CLEMENT wrote:
> Document the device tree binding for the gpio controllers found on the
> Marvell Armada 7K and Armada 8K SoCs.
>
> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
> ---
> Documentation/devicetree/bindings/arm/marvell/ap806-system-controller.txt | 20 ++++++++++++++++++++
> Documentation/devicetree/bindings/arm/marvell/cp110-system-controller0.txt | 24 +++++++++++++++++++++++-
> Documentation/devicetree/bindings/gpio/gpio-mvebu.txt | 24 +++++++++++++++++-------
> 3 files changed, 60 insertions(+), 8 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/arm/marvell/ap806-system-controller.txt b/Documentation/devicetree/bindings/arm/marvell/ap806-system-controller.txt
> index 4228d158fb31..0b887440e08a 100644
> --- a/Documentation/devicetree/bindings/arm/marvell/ap806-system-controller.txt
> +++ b/Documentation/devicetree/bindings/arm/marvell/ap806-system-controller.txt
> @@ -64,6 +64,17 @@ mpp17 17 gpio
> mpp18 18 gpio
> mpp19 19 gpio, uart0(rxd), sdio(pw_off)
>
> +GPIO:
> +-----
> +For common binding part and usage, refer to
> +Documentation/devicetree/bindings/gpio/gpio-mvebu.txt.
> +
> +Required properties:
> +
> +- compatible: "marvell,armada-8k-gpio"
> +
> +- offset: offset address inside the syscon block
> +
> Example:
> ap_syscon: system-controller at 6f4000 {
> compatible = "syscon", "simple-mfd";
> @@ -77,4 +88,13 @@ ap_syscon: system-controller at 6f4000 {
> ap_pinctrl: pinctrl {
> compatible = "marvell,ap806-pinctrl";
> };
> +
> + ap_gpio: gpio {
> + compatible = "marvell,armada-8k-gpio";
> + offset = <0x1040>;
> + ngpios = <19>;
> + gpio-controller;
> + #gpio-cells = <2>;
> + gpio-ranges = <&ap_pinctrl 0 0 19>;
> + };
> };
> diff --git a/Documentation/devicetree/bindings/arm/marvell/cp110-system-controller0.txt b/Documentation/devicetree/bindings/arm/marvell/cp110-system-controller0.txt
> index 733beac7724e..655c114ef584 100644
> --- a/Documentation/devicetree/bindings/arm/marvell/cp110-system-controller0.txt
> +++ b/Documentation/devicetree/bindings/arm/marvell/cp110-system-controller0.txt
> @@ -149,6 +149,18 @@ mpp60 60 gpio, mss_gpio6, ptp(pulse), tdm(dtx), au(i2smclk), spi0(csn1), uart0(r
> mpp61 61 gpio, mss_gpio5, ptp(clk), tdm(pclk), au(i2sextclk), spi0(csn2), uart0(txd), uart2(txd), sata1(present_act), ge(mdio), sdio(d3)
> mpp62 62 gpio, mss_gpio4, synce1(clk), ptp(pclk_out), sata1(present_act), spi0(csn3), uart0(rxd), uart2(rxd), sata0(present_act), ge(mdc)
>
> +GPIO:
> +-----
> +
> +For common binding part and usage, refer to
> +Documentation/devicetree/bindings/gpio/gpio-mvebu.txt.
> +
> +Required properties:
> +
> +- compatible: "marvell,armada-8k-gpio"
> +
> +- offset: offset address inside the syscon block
> +
> Example:
>
> cpm_syscon0: system-controller at 440000 {
> @@ -163,5 +175,15 @@ cpm_syscon0: system-controller at 440000 {
> cpm_pinctrl: pinctrl {
> compatible = "marvell,armada-8k-cpm-pinctrl";
> };
> -};
>
> + cpm_gpio1: gpio at 100 {
> + compatible = "marvell,armada-8k-gpio";
> + offset = <0x100>;
> + ngpios = <32>;
> + gpio-controller;
> + #gpio-cells = <2>;
> + gpio-ranges = <&cpm_pinctrl 0 0 32>;
> + status = "disabled";
> + };
> +
> +};
> diff --git a/Documentation/devicetree/bindings/gpio/gpio-mvebu.txt b/Documentation/devicetree/bindings/gpio/gpio-mvebu.txt
> index 42c3bb2d53e8..2c5304ff467c 100644
> --- a/Documentation/devicetree/bindings/gpio/gpio-mvebu.txt
> +++ b/Documentation/devicetree/bindings/gpio/gpio-mvebu.txt
> @@ -2,17 +2,27 @@
>
> Required properties:
>
> -- compatible : Should be "marvell,orion-gpio", "marvell,mv78200-gpio"
> - or "marvell,armadaxp-gpio". "marvell,orion-gpio" should be used for
> - Orion, Kirkwood, Dove, Discovery (except MV78200) and Armada
> - 370. "marvell,mv78200-gpio" should be used for the Discovery
> - MV78200. "marvel,armadaxp-gpio" should be used for all Armada XP
> - SoCs (MV78230, MV78260, MV78460).
> +- compatible : Should be "marvell,orion-gpio", "marvell,mv78200-gpio",
> + "marvell,armadaxp-gpio" or "marvell,armada-8k-gpio".
> +
> + "marvell,orion-gpio" should be used for Orion, Kirkwood, Dove,
> + Discovery (except MV78200) and Armada 370. "marvell,mv78200-gpio"
> + should be used for the Discovery MV78200.
> +
> + "marvel,armadaxp-gpio" should be used for all Armada XP SoCs
> + (MV78230, MV78260, MV78460).
> +
> + "marvell,armada-8k-gpio" should be used for the Armada 7K and 8K
> + SoCs (either from AP or CP), see
> + Documentation/devicetree/bindings/arm/marvell/cp110-system-controller0.txt
> + and
> + Documentation/devicetree/bindings/arm/marvell/ap806-system-controller.txt
> + for specific details about the offset property.
>
> - reg: Address and length of the register set for the device. Only one
> entry is expected, except for the "marvell,armadaxp-gpio" variant
> for which two entries are expected: one for the general registers,
> - one for the per-cpu registers.
> + one for the per-cpu registers. Not used for marvell,armada-8k-gpio.
Why can't use you use reg instead of offset?
Rob
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: [PATCH 0/6] Extend mvebu gpio driver to support the controllers of the Marvell Armada 7K/8K
2017-05-19 16:09 ` Gregory CLEMENT
(?)
@ 2017-05-31 9:16 ` Thomas Petazzoni
-1 siblings, 0 replies; 65+ messages in thread
From: Thomas Petazzoni @ 2017-05-31 9:16 UTC (permalink / raw)
To: Gregory CLEMENT
Cc: Linus Walleij, Alexandre Courbot,
linux-gpio-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Andrew Lunn, Jason Cooper,
devicetree-u79uwXL29TY76Z2rM5mHXA, Omri Itach, Nadav Haklai,
Kostya Porotchkin, Russell King, Rob Herring,
Neta Zur Hershkovits, Shadi Ammouri, Marcin Wojtas,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Sebastian Hesselbarth
Hello,
On Fri, 19 May 2017 18:09:19 +0200, Gregory CLEMENT wrote:
> Not that currently I didn't manage to fully test the gpio, indeed I
> only have a 7040 DB board which lack of test point for this kind of
> test. So any tested-by would be welcome.
I have tested GPIOs on the master CP110 of the Armada 8K on a
MacchiatoBin board, and they worked for me, so you can add my:
Tested-by: Thomas Petazzoni <thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: [PATCH 0/6] Extend mvebu gpio driver to support the controllers of the Marvell Armada 7K/8K
@ 2017-05-31 9:16 ` Thomas Petazzoni
0 siblings, 0 replies; 65+ messages in thread
From: Thomas Petazzoni @ 2017-05-31 9:16 UTC (permalink / raw)
To: Gregory CLEMENT
Cc: Linus Walleij, Alexandre Courbot, linux-gpio, linux-kernel,
Andrew Lunn, Jason Cooper, devicetree, Omri Itach, Nadav Haklai,
Kostya Porotchkin, Russell King, Rob Herring,
Neta Zur Hershkovits, Shadi Ammouri, Marcin Wojtas,
linux-arm-kernel, Sebastian Hesselbarth
Hello,
On Fri, 19 May 2017 18:09:19 +0200, Gregory CLEMENT wrote:
> Not that currently I didn't manage to fully test the gpio, indeed I
> only have a 7040 DB board which lack of test point for this kind of
> test. So any tested-by would be welcome.
I have tested GPIOs on the master CP110 of the Armada 8K on a
MacchiatoBin board, and they worked for me, so you can add my:
Tested-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 65+ messages in thread
* [PATCH 0/6] Extend mvebu gpio driver to support the controllers of the Marvell Armada 7K/8K
@ 2017-05-31 9:16 ` Thomas Petazzoni
0 siblings, 0 replies; 65+ messages in thread
From: Thomas Petazzoni @ 2017-05-31 9:16 UTC (permalink / raw)
To: linux-arm-kernel
Hello,
On Fri, 19 May 2017 18:09:19 +0200, Gregory CLEMENT wrote:
> Not that currently I didn't manage to fully test the gpio, indeed I
> only have a 7040 DB board which lack of test point for this kind of
> test. So any tested-by would be welcome.
I have tested GPIOs on the master CP110 of the Armada 8K on a
MacchiatoBin board, and they worked for me, so you can add my:
Tested-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: [PATCH 3/6] gpio: dt-bindings: Add documentation for gpio controllers on Armada 7K/8K
2017-05-30 22:23 ` Rob Herring
(?)
@ 2017-05-31 10:02 ` Gregory CLEMENT
-1 siblings, 0 replies; 65+ messages in thread
From: Gregory CLEMENT @ 2017-05-31 10:02 UTC (permalink / raw)
To: Rob Herring
Cc: Linus Walleij, Stephen Boyd, Mike Turquette, Alexandre Courbot,
linux-gpio, linux-kernel, Jason Cooper, Andrew Lunn,
Sebastian Hesselbarth, Thomas Petazzoni, linux-arm-kernel,
devicetree, Russell King, Nadav Haklai, Kostya Porotchkin,
Neta Zur Hershkovits
Hi Rob,
On mer., mai 31 2017, Rob Herring <robh@kernel.org> wrote:
> On Mon, May 29, 2017 at 10:08:16AM +0200, Linus Walleij wrote:
>> On Tue, May 23, 2017 at 3:06 PM, Gregory CLEMENT
>> <gregory.clement@free-electrons.com> wrote:
>> > On mar., mai 23 2017, Linus Walleij <linus.walleij@linaro.org> wrote:
>>
>> >> Please rebase and resend the rest of the patches.
>> >
>> > Actually I was wrong with my assumption that there was no dependency.
>> > For the binding documentation there is dependecy accross the series I
>> > sent.
>> >
>> > This patch depends on "pinctrl: dt-bindings: add documentation for AP806
>> > pin controllers" [1] and "pinctrl: dt-bindings: add documentation for
>> > CP110 pin controllers" [3] from the series "Add support for the pin
>> > controllers on the Marvell Armada 7K/8K".
>> >
>> > As you are maintainer of both gpio and pinctrl subsystem it will be easy
>> > to resolv.
>>
>> Please send all patches in one big series in that case, so I can apply
>> them all to a branch and merge that branch into both trees.
>>
>> > But these last patches depend also on "clk: mvebu: ap806: introduce a
>> > new binding" [3] in the clock series "Improve ap806 clk support on
>> > Marvell Armada 7K/8K" and on "clk: mvebu: cp110: introduce a new
>> > binding" [4] in the clock series "Improve cp110 clk support on Marvell
>> > Armada 7K/8K".
>>
>> That sounds messy.
>>
>> > So for these particular patches, either I rebase them on the v4.12-rc2
>> > and there will be a small merge conflict during the merge window for
>> > v4.13, or we can ask a stable branch with only these few patches (I am
>> > adding the clock maintainer to this email).
>> >
>> > If we chose this last option I can split the clock patches to have patch
>> > modifying only the binding documentation.
>>
>> I think you can make a patch just modifying the binding documentation
>> and then apply that patch to *both* trees, just make sure the patch
>> is *final* and not applied in different versions in clk and pinctrl.
>
> I thought we try to avoid doing that.
>
>> I think cross-tree branches for documentation clashes is too much
>> bureaucracy.
>
> I can just take all the doc patches separately. Or you can take the
> clock one too.
If you can take all the doc patches I think we will managed to solve the
issue in a efficient way. So I am going to send a new version of the
clock series by splitting the "clk: mvebu: *: introduce a new binding"
patches so you will be able to only pick the doc part.
Thanks!
Gregory
>
>> Make sure your clock patch is finalized and preferably also applied
>> to the clk tree then put it in the bottom of the patch set you send
>> to me as well and I will proceed like above.
>>
>> Yours,
>> Linus Walleij
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: [PATCH 3/6] gpio: dt-bindings: Add documentation for gpio controllers on Armada 7K/8K
@ 2017-05-31 10:02 ` Gregory CLEMENT
0 siblings, 0 replies; 65+ messages in thread
From: Gregory CLEMENT @ 2017-05-31 10:02 UTC (permalink / raw)
To: Rob Herring
Cc: Linus Walleij, Stephen Boyd, Mike Turquette, Alexandre Courbot,
linux-gpio, linux-kernel, Jason Cooper, Andrew Lunn,
Sebastian Hesselbarth, Thomas Petazzoni, linux-arm-kernel,
devicetree, Russell King, Nadav Haklai, Kostya Porotchkin,
Neta Zur Hershkovits, Marcin Wojtas, Omri Itach, Shadi Ammouri
Hi Rob,
On mer., mai 31 2017, Rob Herring <robh@kernel.org> wrote:
> On Mon, May 29, 2017 at 10:08:16AM +0200, Linus Walleij wrote:
>> On Tue, May 23, 2017 at 3:06 PM, Gregory CLEMENT
>> <gregory.clement@free-electrons.com> wrote:
>> > On mar., mai 23 2017, Linus Walleij <linus.walleij@linaro.org> wrote:
>>
>> >> Please rebase and resend the rest of the patches.
>> >
>> > Actually I was wrong with my assumption that there was no dependency.
>> > For the binding documentation there is dependecy accross the series I
>> > sent.
>> >
>> > This patch depends on "pinctrl: dt-bindings: add documentation for AP806
>> > pin controllers" [1] and "pinctrl: dt-bindings: add documentation for
>> > CP110 pin controllers" [3] from the series "Add support for the pin
>> > controllers on the Marvell Armada 7K/8K".
>> >
>> > As you are maintainer of both gpio and pinctrl subsystem it will be easy
>> > to resolv.
>>
>> Please send all patches in one big series in that case, so I can apply
>> them all to a branch and merge that branch into both trees.
>>
>> > But these last patches depend also on "clk: mvebu: ap806: introduce a
>> > new binding" [3] in the clock series "Improve ap806 clk support on
>> > Marvell Armada 7K/8K" and on "clk: mvebu: cp110: introduce a new
>> > binding" [4] in the clock series "Improve cp110 clk support on Marvell
>> > Armada 7K/8K".
>>
>> That sounds messy.
>>
>> > So for these particular patches, either I rebase them on the v4.12-rc2
>> > and there will be a small merge conflict during the merge window for
>> > v4.13, or we can ask a stable branch with only these few patches (I am
>> > adding the clock maintainer to this email).
>> >
>> > If we chose this last option I can split the clock patches to have patch
>> > modifying only the binding documentation.
>>
>> I think you can make a patch just modifying the binding documentation
>> and then apply that patch to *both* trees, just make sure the patch
>> is *final* and not applied in different versions in clk and pinctrl.
>
> I thought we try to avoid doing that.
>
>> I think cross-tree branches for documentation clashes is too much
>> bureaucracy.
>
> I can just take all the doc patches separately. Or you can take the
> clock one too.
If you can take all the doc patches I think we will managed to solve the
issue in a efficient way. So I am going to send a new version of the
clock series by splitting the "clk: mvebu: *: introduce a new binding"
patches so you will be able to only pick the doc part.
Thanks!
Gregory
>
>> Make sure your clock patch is finalized and preferably also applied
>> to the clk tree then put it in the bottom of the patch set you send
>> to me as well and I will proceed like above.
>>
>> Yours,
>> Linus Walleij
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply [flat|nested] 65+ messages in thread
* [PATCH 3/6] gpio: dt-bindings: Add documentation for gpio controllers on Armada 7K/8K
@ 2017-05-31 10:02 ` Gregory CLEMENT
0 siblings, 0 replies; 65+ messages in thread
From: Gregory CLEMENT @ 2017-05-31 10:02 UTC (permalink / raw)
To: linux-arm-kernel
Hi Rob,
On mer., mai 31 2017, Rob Herring <robh@kernel.org> wrote:
> On Mon, May 29, 2017 at 10:08:16AM +0200, Linus Walleij wrote:
>> On Tue, May 23, 2017 at 3:06 PM, Gregory CLEMENT
>> <gregory.clement@free-electrons.com> wrote:
>> > On mar., mai 23 2017, Linus Walleij <linus.walleij@linaro.org> wrote:
>>
>> >> Please rebase and resend the rest of the patches.
>> >
>> > Actually I was wrong with my assumption that there was no dependency.
>> > For the binding documentation there is dependecy accross the series I
>> > sent.
>> >
>> > This patch depends on "pinctrl: dt-bindings: add documentation for AP806
>> > pin controllers" [1] and "pinctrl: dt-bindings: add documentation for
>> > CP110 pin controllers" [3] from the series "Add support for the pin
>> > controllers on the Marvell Armada 7K/8K".
>> >
>> > As you are maintainer of both gpio and pinctrl subsystem it will be easy
>> > to resolv.
>>
>> Please send all patches in one big series in that case, so I can apply
>> them all to a branch and merge that branch into both trees.
>>
>> > But these last patches depend also on "clk: mvebu: ap806: introduce a
>> > new binding" [3] in the clock series "Improve ap806 clk support on
>> > Marvell Armada 7K/8K" and on "clk: mvebu: cp110: introduce a new
>> > binding" [4] in the clock series "Improve cp110 clk support on Marvell
>> > Armada 7K/8K".
>>
>> That sounds messy.
>>
>> > So for these particular patches, either I rebase them on the v4.12-rc2
>> > and there will be a small merge conflict during the merge window for
>> > v4.13, or we can ask a stable branch with only these few patches (I am
>> > adding the clock maintainer to this email).
>> >
>> > If we chose this last option I can split the clock patches to have patch
>> > modifying only the binding documentation.
>>
>> I think you can make a patch just modifying the binding documentation
>> and then apply that patch to *both* trees, just make sure the patch
>> is *final* and not applied in different versions in clk and pinctrl.
>
> I thought we try to avoid doing that.
>
>> I think cross-tree branches for documentation clashes is too much
>> bureaucracy.
>
> I can just take all the doc patches separately. Or you can take the
> clock one too.
If you can take all the doc patches I think we will managed to solve the
issue in a efficient way. So I am going to send a new version of the
clock series by splitting the "clk: mvebu: *: introduce a new binding"
patches so you will be able to only pick the doc part.
Thanks!
Gregory
>
>> Make sure your clock patch is finalized and preferably also applied
>> to the clk tree then put it in the bottom of the patch set you send
>> to me as well and I will proceed like above.
>>
>> Yours,
>> Linus Walleij
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: [PATCH 3/6] gpio: dt-bindings: Add documentation for gpio controllers on Armada 7K/8K
2017-05-30 22:29 ` Rob Herring
@ 2017-05-31 10:05 ` Gregory CLEMENT
-1 siblings, 0 replies; 65+ messages in thread
From: Gregory CLEMENT @ 2017-05-31 10:05 UTC (permalink / raw)
To: Rob Herring
Cc: Linus Walleij, Alexandre Courbot, linux-gpio, linux-kernel,
Jason Cooper, Andrew Lunn, Sebastian Hesselbarth,
Thomas Petazzoni, linux-arm-kernel, devicetree, Russell King,
Nadav Haklai, Kostya Porotchkin, Neta Zur Hershkovits,
Marcin Wojtas, Omri Itach, Shadi Ammouri
Hi Rob,
On mer., mai 31 2017, Rob Herring <robh@kernel.org> wrote:
>>
>> Required properties:
>>
>> -- compatible : Should be "marvell,orion-gpio", "marvell,mv78200-gpio"
>> - or "marvell,armadaxp-gpio". "marvell,orion-gpio" should be used for
>> - Orion, Kirkwood, Dove, Discovery (except MV78200) and Armada
>> - 370. "marvell,mv78200-gpio" should be used for the Discovery
>> - MV78200. "marvel,armadaxp-gpio" should be used for all Armada XP
>> - SoCs (MV78230, MV78260, MV78460).
>> +- compatible : Should be "marvell,orion-gpio", "marvell,mv78200-gpio",
>> + "marvell,armadaxp-gpio" or "marvell,armada-8k-gpio".
>> +
>> + "marvell,orion-gpio" should be used for Orion, Kirkwood, Dove,
>> + Discovery (except MV78200) and Armada 370. "marvell,mv78200-gpio"
>> + should be used for the Discovery MV78200.
>> +
>> + "marvel,armadaxp-gpio" should be used for all Armada XP SoCs
>> + (MV78230, MV78260, MV78460).
>> +
>> + "marvell,armada-8k-gpio" should be used for the Armada 7K and 8K
>> + SoCs (either from AP or CP), see
>> + Documentation/devicetree/bindings/arm/marvell/cp110-system-controller0.txt
>> + and
>> + Documentation/devicetree/bindings/arm/marvell/ap806-system-controller.txt
>> + for specific details about the offset property.
>>
>> - reg: Address and length of the register set for the device. Only one
>> entry is expected, except for the "marvell,armadaxp-gpio" variant
>> for which two entries are expected: one for the general registers,
>> - one for the per-cpu registers.
>> + one for the per-cpu registers. Not used for marvell,armada-8k-gpio.
>
> Why can't use you use reg instead of offset?
I looked for how the other syscon user did, and I found the offset
usage. So I assumed it was the way to do it. But if you wan I can use a
reg property.
Gregory
>
> Rob
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply [flat|nested] 65+ messages in thread
* [PATCH 3/6] gpio: dt-bindings: Add documentation for gpio controllers on Armada 7K/8K
@ 2017-05-31 10:05 ` Gregory CLEMENT
0 siblings, 0 replies; 65+ messages in thread
From: Gregory CLEMENT @ 2017-05-31 10:05 UTC (permalink / raw)
To: linux-arm-kernel
Hi Rob,
On mer., mai 31 2017, Rob Herring <robh@kernel.org> wrote:
>>
>> Required properties:
>>
>> -- compatible : Should be "marvell,orion-gpio", "marvell,mv78200-gpio"
>> - or "marvell,armadaxp-gpio". "marvell,orion-gpio" should be used for
>> - Orion, Kirkwood, Dove, Discovery (except MV78200) and Armada
>> - 370. "marvell,mv78200-gpio" should be used for the Discovery
>> - MV78200. "marvel,armadaxp-gpio" should be used for all Armada XP
>> - SoCs (MV78230, MV78260, MV78460).
>> +- compatible : Should be "marvell,orion-gpio", "marvell,mv78200-gpio",
>> + "marvell,armadaxp-gpio" or "marvell,armada-8k-gpio".
>> +
>> + "marvell,orion-gpio" should be used for Orion, Kirkwood, Dove,
>> + Discovery (except MV78200) and Armada 370. "marvell,mv78200-gpio"
>> + should be used for the Discovery MV78200.
>> +
>> + "marvel,armadaxp-gpio" should be used for all Armada XP SoCs
>> + (MV78230, MV78260, MV78460).
>> +
>> + "marvell,armada-8k-gpio" should be used for the Armada 7K and 8K
>> + SoCs (either from AP or CP), see
>> + Documentation/devicetree/bindings/arm/marvell/cp110-system-controller0.txt
>> + and
>> + Documentation/devicetree/bindings/arm/marvell/ap806-system-controller.txt
>> + for specific details about the offset property.
>>
>> - reg: Address and length of the register set for the device. Only one
>> entry is expected, except for the "marvell,armadaxp-gpio" variant
>> for which two entries are expected: one for the general registers,
>> - one for the per-cpu registers.
>> + one for the per-cpu registers. Not used for marvell,armada-8k-gpio.
>
> Why can't use you use reg instead of offset?
I looked for how the other syscon user did, and I found the offset
usage. So I assumed it was the way to do it. But if you wan I can use a
reg property.
Gregory
>
> Rob
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: [PATCH 3/6] gpio: dt-bindings: Add documentation for gpio controllers on Armada 7K/8K
2017-05-30 22:23 ` Rob Herring
(?)
@ 2017-05-31 10:43 ` Michael Turquette
-1 siblings, 0 replies; 65+ messages in thread
From: Michael Turquette @ 2017-05-31 10:43 UTC (permalink / raw)
To: Rob Herring, Linus Walleij
Cc: Gregory CLEMENT, Stephen Boyd, Alexandre Courbot, linux-gpio,
linux-kernel, Jason Cooper, Andrew Lunn, Sebastian Hesselbarth,
Thomas Petazzoni, linux-arm-kernel, devicetree, Russell King,
Nadav Haklai, Kostya Porotchkin, Neta Zur Hershkovits
Quoting Rob Herring (2017-05-31 07:23:58)
> On Mon, May 29, 2017 at 10:08:16AM +0200, Linus Walleij wrote:
> > On Tue, May 23, 2017 at 3:06 PM, Gregory CLEMENT
> > <gregory.clement@free-electrons.com> wrote:
> > > On mar., mai 23 2017, Linus Walleij <linus.walleij@linaro.org> wrote:
> >
> > >> Please rebase and resend the rest of the patches.
> > >
> > > Actually I was wrong with my assumption that there was no dependency.
> > > For the binding documentation there is dependecy accross the series I
> > > sent.
> > >
> > > This patch depends on "pinctrl: dt-bindings: add documentation for AP806
> > > pin controllers" [1] and "pinctrl: dt-bindings: add documentation for
> > > CP110 pin controllers" [3] from the series "Add support for the pin
> > > controllers on the Marvell Armada 7K/8K".
> > >
> > > As you are maintainer of both gpio and pinctrl subsystem it will be easy
> > > to resolv.
> >
> > Please send all patches in one big series in that case, so I can apply
> > them all to a branch and merge that branch into both trees.
> >
> > > But these last patches depend also on "clk: mvebu: ap806: introduce a
> > > new binding" [3] in the clock series "Improve ap806 clk support on
> > > Marvell Armada 7K/8K" and on "clk: mvebu: cp110: introduce a new
> > > binding" [4] in the clock series "Improve cp110 clk support on Marvell
> > > Armada 7K/8K".
> >
> > That sounds messy.
> >
> > > So for these particular patches, either I rebase them on the v4.12-rc2
> > > and there will be a small merge conflict during the merge window for
> > > v4.13, or we can ask a stable branch with only these few patches (I am
> > > adding the clock maintainer to this email).
> > >
> > > If we chose this last option I can split the clock patches to have patch
> > > modifying only the binding documentation.
> >
> > I think you can make a patch just modifying the binding documentation
> > and then apply that patch to *both* trees, just make sure the patch
> > is *final* and not applied in different versions in clk and pinctrl.
>
> I thought we try to avoid doing that.
>
> > I think cross-tree branches for documentation clashes is too much
> > bureaucracy.
>
> I can just take all the doc patches separately. Or you can take the
> clock one too.
Stephen and I have started making a -dt branch for each new clk driver
which. This stable branch has only the dt bindings/headers in it (no
driver code).
I'll make such a branch for ap806 this week and everyone can merge that
in as a dep.
Regards,
Mike
>
> > Make sure your clock patch is finalized and preferably also applied
> > to the clk tree then put it in the bottom of the patch set you send
> > to me as well and I will proceed like above.
> >
> > Yours,
> > Linus Walleij
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: [PATCH 3/6] gpio: dt-bindings: Add documentation for gpio controllers on Armada 7K/8K
@ 2017-05-31 10:43 ` Michael Turquette
0 siblings, 0 replies; 65+ messages in thread
From: Michael Turquette @ 2017-05-31 10:43 UTC (permalink / raw)
To: Rob Herring, Linus Walleij
Cc: Gregory CLEMENT, Stephen Boyd, Alexandre Courbot, linux-gpio,
linux-kernel, Jason Cooper, Andrew Lunn, Sebastian Hesselbarth,
Thomas Petazzoni, linux-arm-kernel, devicetree, Russell King,
Nadav Haklai, Kostya Porotchkin, Neta Zur Hershkovits,
Marcin Wojtas, Omri Itach, Shadi Ammouri
Quoting Rob Herring (2017-05-31 07:23:58)
> On Mon, May 29, 2017 at 10:08:16AM +0200, Linus Walleij wrote:
> > On Tue, May 23, 2017 at 3:06 PM, Gregory CLEMENT
> > <gregory.clement@free-electrons.com> wrote:
> > > On mar., mai 23 2017, Linus Walleij <linus.walleij@linaro.org> wrote:
> >
> > >> Please rebase and resend the rest of the patches.
> > >
> > > Actually I was wrong with my assumption that there was no dependency.
> > > For the binding documentation there is dependecy accross the series I
> > > sent.
> > >
> > > This patch depends on "pinctrl: dt-bindings: add documentation for AP806
> > > pin controllers" [1] and "pinctrl: dt-bindings: add documentation for
> > > CP110 pin controllers" [3] from the series "Add support for the pin
> > > controllers on the Marvell Armada 7K/8K".
> > >
> > > As you are maintainer of both gpio and pinctrl subsystem it will be easy
> > > to resolv.
> >
> > Please send all patches in one big series in that case, so I can apply
> > them all to a branch and merge that branch into both trees.
> >
> > > But these last patches depend also on "clk: mvebu: ap806: introduce a
> > > new binding" [3] in the clock series "Improve ap806 clk support on
> > > Marvell Armada 7K/8K" and on "clk: mvebu: cp110: introduce a new
> > > binding" [4] in the clock series "Improve cp110 clk support on Marvell
> > > Armada 7K/8K".
> >
> > That sounds messy.
> >
> > > So for these particular patches, either I rebase them on the v4.12-rc2
> > > and there will be a small merge conflict during the merge window for
> > > v4.13, or we can ask a stable branch with only these few patches (I am
> > > adding the clock maintainer to this email).
> > >
> > > If we chose this last option I can split the clock patches to have patch
> > > modifying only the binding documentation.
> >
> > I think you can make a patch just modifying the binding documentation
> > and then apply that patch to *both* trees, just make sure the patch
> > is *final* and not applied in different versions in clk and pinctrl.
>
> I thought we try to avoid doing that.
>
> > I think cross-tree branches for documentation clashes is too much
> > bureaucracy.
>
> I can just take all the doc patches separately. Or you can take the
> clock one too.
Stephen and I have started making a -dt branch for each new clk driver
which. This stable branch has only the dt bindings/headers in it (no
driver code).
I'll make such a branch for ap806 this week and everyone can merge that
in as a dep.
Regards,
Mike
>
> > Make sure your clock patch is finalized and preferably also applied
> > to the clk tree then put it in the bottom of the patch set you send
> > to me as well and I will proceed like above.
> >
> > Yours,
> > Linus Walleij
^ permalink raw reply [flat|nested] 65+ messages in thread
* [PATCH 3/6] gpio: dt-bindings: Add documentation for gpio controllers on Armada 7K/8K
@ 2017-05-31 10:43 ` Michael Turquette
0 siblings, 0 replies; 65+ messages in thread
From: Michael Turquette @ 2017-05-31 10:43 UTC (permalink / raw)
To: linux-arm-kernel
Quoting Rob Herring (2017-05-31 07:23:58)
> On Mon, May 29, 2017 at 10:08:16AM +0200, Linus Walleij wrote:
> > On Tue, May 23, 2017 at 3:06 PM, Gregory CLEMENT
> > <gregory.clement@free-electrons.com> wrote:
> > > On mar., mai 23 2017, Linus Walleij <linus.walleij@linaro.org> wrote:
> >
> > >> Please rebase and resend the rest of the patches.
> > >
> > > Actually I was wrong with my assumption that there was no dependency.
> > > For the binding documentation there is dependecy accross the series I
> > > sent.
> > >
> > > This patch depends on "pinctrl: dt-bindings: add documentation for AP806
> > > pin controllers" [1] and "pinctrl: dt-bindings: add documentation for
> > > CP110 pin controllers" [3] from the series "Add support for the pin
> > > controllers on the Marvell Armada 7K/8K".
> > >
> > > As you are maintainer of both gpio and pinctrl subsystem it will be easy
> > > to resolv.
> >
> > Please send all patches in one big series in that case, so I can apply
> > them all to a branch and merge that branch into both trees.
> >
> > > But these last patches depend also on "clk: mvebu: ap806: introduce a
> > > new binding" [3] in the clock series "Improve ap806 clk support on
> > > Marvell Armada 7K/8K" and on "clk: mvebu: cp110: introduce a new
> > > binding" [4] in the clock series "Improve cp110 clk support on Marvell
> > > Armada 7K/8K".
> >
> > That sounds messy.
> >
> > > So for these particular patches, either I rebase them on the v4.12-rc2
> > > and there will be a small merge conflict during the merge window for
> > > v4.13, or we can ask a stable branch with only these few patches (I am
> > > adding the clock maintainer to this email).
> > >
> > > If we chose this last option I can split the clock patches to have patch
> > > modifying only the binding documentation.
> >
> > I think you can make a patch just modifying the binding documentation
> > and then apply that patch to *both* trees, just make sure the patch
> > is *final* and not applied in different versions in clk and pinctrl.
>
> I thought we try to avoid doing that.
>
> > I think cross-tree branches for documentation clashes is too much
> > bureaucracy.
>
> I can just take all the doc patches separately. Or you can take the
> clock one too.
Stephen and I have started making a -dt branch for each new clk driver
which. This stable branch has only the dt bindings/headers in it (no
driver code).
I'll make such a branch for ap806 this week and everyone can merge that
in as a dep.
Regards,
Mike
>
> > Make sure your clock patch is finalized and preferably also applied
> > to the clk tree then put it in the bottom of the patch set you send
> > to me as well and I will proceed like above.
> >
> > Yours,
> > Linus Walleij
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: [PATCH 3/6] gpio: dt-bindings: Add documentation for gpio controllers on Armada 7K/8K
2017-05-31 10:43 ` Michael Turquette
(?)
@ 2017-05-31 14:41 ` Gregory CLEMENT
-1 siblings, 0 replies; 65+ messages in thread
From: Gregory CLEMENT @ 2017-05-31 14:41 UTC (permalink / raw)
To: Michael Turquette
Cc: Rob Herring, Linus Walleij, Stephen Boyd, Alexandre Courbot,
linux-gpio@vger.kernel.org, linux-kernel@vger.kernel.org,
Jason Cooper, Andrew Lunn, Sebastian Hesselbarth,
Thomas Petazzoni, linux-arm-kernel@lists.infradead.org,
devicetree@vger.kernel.org, Russell King, Nadav Haklai,
Kostya Porotchkin, Neta Zur Hershkovits
Hi Michael,
On mer., mai 31 2017, Michael Turquette <mturquette-rdvid1DuHRBWk0Htik3J/w@public.gmane.org> wrote:
> Quoting Rob Herring (2017-05-31 07:23:58)
>> On Mon, May 29, 2017 at 10:08:16AM +0200, Linus Walleij wrote:
>> > On Tue, May 23, 2017 at 3:06 PM, Gregory CLEMENT
>> > <gregory.clement-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:
>> > > On mar., mai 23 2017, Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
>> >
>> > >> Please rebase and resend the rest of the patches.
>> > >
>> > > Actually I was wrong with my assumption that there was no dependency.
>> > > For the binding documentation there is dependecy accross the series I
>> > > sent.
>> > >
>> > > This patch depends on "pinctrl: dt-bindings: add documentation for AP806
>> > > pin controllers" [1] and "pinctrl: dt-bindings: add documentation for
>> > > CP110 pin controllers" [3] from the series "Add support for the pin
>> > > controllers on the Marvell Armada 7K/8K".
>> > >
>> > > As you are maintainer of both gpio and pinctrl subsystem it will be easy
>> > > to resolv.
>> >
>> > Please send all patches in one big series in that case, so I can apply
>> > them all to a branch and merge that branch into both trees.
>> >
>> > > But these last patches depend also on "clk: mvebu: ap806: introduce a
>> > > new binding" [3] in the clock series "Improve ap806 clk support on
>> > > Marvell Armada 7K/8K" and on "clk: mvebu: cp110: introduce a new
>> > > binding" [4] in the clock series "Improve cp110 clk support on Marvell
>> > > Armada 7K/8K".
>> >
>> > That sounds messy.
>> >
>> > > So for these particular patches, either I rebase them on the v4.12-rc2
>> > > and there will be a small merge conflict during the merge window for
>> > > v4.13, or we can ask a stable branch with only these few patches (I am
>> > > adding the clock maintainer to this email).
>> > >
>> > > If we chose this last option I can split the clock patches to have patch
>> > > modifying only the binding documentation.
>> >
>> > I think you can make a patch just modifying the binding documentation
>> > and then apply that patch to *both* trees, just make sure the patch
>> > is *final* and not applied in different versions in clk and pinctrl.
>>
>> I thought we try to avoid doing that.
>>
>> > I think cross-tree branches for documentation clashes is too much
>> > bureaucracy.
>>
>> I can just take all the doc patches separately. Or you can take the
>> clock one too.
>
> Stephen and I have started making a -dt branch for each new clk driver
> which. This stable branch has only the dt bindings/headers in it (no
> driver code).
>
> I'll make such a branch for ap806 this week and everyone can merge that
> in as a dep.
So please use the version 2 I've just submitted. I split each patch to
allow you to have a dt binding only branch. See
http://lists.infradead.org/pipermail/linux-arm-kernel/2017-May/509832.html
I did the same for the cp110:
http://lists.infradead.org/pipermail/linux-arm-kernel/2017-May/509816.html
Gregory
>
> Regards,
> Mike
>
>>
>> > Make sure your clock patch is finalized and preferably also applied
>> > to the clk tree then put it in the bottom of the patch set you send
>> > to me as well and I will proceed like above.
>> >
>> > Yours,
>> > Linus Walleij
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: [PATCH 3/6] gpio: dt-bindings: Add documentation for gpio controllers on Armada 7K/8K
@ 2017-05-31 14:41 ` Gregory CLEMENT
0 siblings, 0 replies; 65+ messages in thread
From: Gregory CLEMENT @ 2017-05-31 14:41 UTC (permalink / raw)
To: Michael Turquette
Cc: Rob Herring, Linus Walleij, Stephen Boyd, Alexandre Courbot,
linux-gpio, linux-kernel, Jason Cooper, Andrew Lunn,
Sebastian Hesselbarth, Thomas Petazzoni, linux-arm-kernel,
devicetree, Russell King, Nadav Haklai, Kostya Porotchkin,
Neta Zur Hershkovits, Marcin Wojtas, Omri Itach, Shadi Ammouri
Hi Michael,
On mer., mai 31 2017, Michael Turquette <mturquette@baylibre.com> wrote:
> Quoting Rob Herring (2017-05-31 07:23:58)
>> On Mon, May 29, 2017 at 10:08:16AM +0200, Linus Walleij wrote:
>> > On Tue, May 23, 2017 at 3:06 PM, Gregory CLEMENT
>> > <gregory.clement@free-electrons.com> wrote:
>> > > On mar., mai 23 2017, Linus Walleij <linus.walleij@linaro.org> wrote:
>> >
>> > >> Please rebase and resend the rest of the patches.
>> > >
>> > > Actually I was wrong with my assumption that there was no dependency.
>> > > For the binding documentation there is dependecy accross the series I
>> > > sent.
>> > >
>> > > This patch depends on "pinctrl: dt-bindings: add documentation for AP806
>> > > pin controllers" [1] and "pinctrl: dt-bindings: add documentation for
>> > > CP110 pin controllers" [3] from the series "Add support for the pin
>> > > controllers on the Marvell Armada 7K/8K".
>> > >
>> > > As you are maintainer of both gpio and pinctrl subsystem it will be easy
>> > > to resolv.
>> >
>> > Please send all patches in one big series in that case, so I can apply
>> > them all to a branch and merge that branch into both trees.
>> >
>> > > But these last patches depend also on "clk: mvebu: ap806: introduce a
>> > > new binding" [3] in the clock series "Improve ap806 clk support on
>> > > Marvell Armada 7K/8K" and on "clk: mvebu: cp110: introduce a new
>> > > binding" [4] in the clock series "Improve cp110 clk support on Marvell
>> > > Armada 7K/8K".
>> >
>> > That sounds messy.
>> >
>> > > So for these particular patches, either I rebase them on the v4.12-rc2
>> > > and there will be a small merge conflict during the merge window for
>> > > v4.13, or we can ask a stable branch with only these few patches (I am
>> > > adding the clock maintainer to this email).
>> > >
>> > > If we chose this last option I can split the clock patches to have patch
>> > > modifying only the binding documentation.
>> >
>> > I think you can make a patch just modifying the binding documentation
>> > and then apply that patch to *both* trees, just make sure the patch
>> > is *final* and not applied in different versions in clk and pinctrl.
>>
>> I thought we try to avoid doing that.
>>
>> > I think cross-tree branches for documentation clashes is too much
>> > bureaucracy.
>>
>> I can just take all the doc patches separately. Or you can take the
>> clock one too.
>
> Stephen and I have started making a -dt branch for each new clk driver
> which. This stable branch has only the dt bindings/headers in it (no
> driver code).
>
> I'll make such a branch for ap806 this week and everyone can merge that
> in as a dep.
So please use the version 2 I've just submitted. I split each patch to
allow you to have a dt binding only branch. See
http://lists.infradead.org/pipermail/linux-arm-kernel/2017-May/509832.html
I did the same for the cp110:
http://lists.infradead.org/pipermail/linux-arm-kernel/2017-May/509816.html
Gregory
>
> Regards,
> Mike
>
>>
>> > Make sure your clock patch is finalized and preferably also applied
>> > to the clk tree then put it in the bottom of the patch set you send
>> > to me as well and I will proceed like above.
>> >
>> > Yours,
>> > Linus Walleij
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply [flat|nested] 65+ messages in thread
* [PATCH 3/6] gpio: dt-bindings: Add documentation for gpio controllers on Armada 7K/8K
@ 2017-05-31 14:41 ` Gregory CLEMENT
0 siblings, 0 replies; 65+ messages in thread
From: Gregory CLEMENT @ 2017-05-31 14:41 UTC (permalink / raw)
To: linux-arm-kernel
Hi Michael,
On mer., mai 31 2017, Michael Turquette <mturquette@baylibre.com> wrote:
> Quoting Rob Herring (2017-05-31 07:23:58)
>> On Mon, May 29, 2017 at 10:08:16AM +0200, Linus Walleij wrote:
>> > On Tue, May 23, 2017 at 3:06 PM, Gregory CLEMENT
>> > <gregory.clement@free-electrons.com> wrote:
>> > > On mar., mai 23 2017, Linus Walleij <linus.walleij@linaro.org> wrote:
>> >
>> > >> Please rebase and resend the rest of the patches.
>> > >
>> > > Actually I was wrong with my assumption that there was no dependency.
>> > > For the binding documentation there is dependecy accross the series I
>> > > sent.
>> > >
>> > > This patch depends on "pinctrl: dt-bindings: add documentation for AP806
>> > > pin controllers" [1] and "pinctrl: dt-bindings: add documentation for
>> > > CP110 pin controllers" [3] from the series "Add support for the pin
>> > > controllers on the Marvell Armada 7K/8K".
>> > >
>> > > As you are maintainer of both gpio and pinctrl subsystem it will be easy
>> > > to resolv.
>> >
>> > Please send all patches in one big series in that case, so I can apply
>> > them all to a branch and merge that branch into both trees.
>> >
>> > > But these last patches depend also on "clk: mvebu: ap806: introduce a
>> > > new binding" [3] in the clock series "Improve ap806 clk support on
>> > > Marvell Armada 7K/8K" and on "clk: mvebu: cp110: introduce a new
>> > > binding" [4] in the clock series "Improve cp110 clk support on Marvell
>> > > Armada 7K/8K".
>> >
>> > That sounds messy.
>> >
>> > > So for these particular patches, either I rebase them on the v4.12-rc2
>> > > and there will be a small merge conflict during the merge window for
>> > > v4.13, or we can ask a stable branch with only these few patches (I am
>> > > adding the clock maintainer to this email).
>> > >
>> > > If we chose this last option I can split the clock patches to have patch
>> > > modifying only the binding documentation.
>> >
>> > I think you can make a patch just modifying the binding documentation
>> > and then apply that patch to *both* trees, just make sure the patch
>> > is *final* and not applied in different versions in clk and pinctrl.
>>
>> I thought we try to avoid doing that.
>>
>> > I think cross-tree branches for documentation clashes is too much
>> > bureaucracy.
>>
>> I can just take all the doc patches separately. Or you can take the
>> clock one too.
>
> Stephen and I have started making a -dt branch for each new clk driver
> which. This stable branch has only the dt bindings/headers in it (no
> driver code).
>
> I'll make such a branch for ap806 this week and everyone can merge that
> in as a dep.
So please use the version 2 I've just submitted. I split each patch to
allow you to have a dt binding only branch. See
http://lists.infradead.org/pipermail/linux-arm-kernel/2017-May/509832.html
I did the same for the cp110:
http://lists.infradead.org/pipermail/linux-arm-kernel/2017-May/509816.html
Gregory
>
> Regards,
> Mike
>
>>
>> > Make sure your clock patch is finalized and preferably also applied
>> > to the clk tree then put it in the bottom of the patch set you send
>> > to me as well and I will proceed like above.
>> >
>> > Yours,
>> > Linus Walleij
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: [PATCH 3/6] gpio: dt-bindings: Add documentation for gpio controllers on Armada 7K/8K
2017-05-31 10:05 ` Gregory CLEMENT
@ 2017-06-01 17:33 ` Gregory CLEMENT
-1 siblings, 0 replies; 65+ messages in thread
From: Gregory CLEMENT @ 2017-06-01 17:33 UTC (permalink / raw)
To: Rob Herring
Cc: Thomas Petazzoni, Alexandre Courbot, Jason Cooper, Andrew Lunn,
Linus Walleij, Omri Itach, linux-kernel, Nadav Haklai,
linux-gpio, devicetree, Neta Zur Hershkovits, Kostya Porotchkin,
Shadi Ammouri, Marcin Wojtas, Russell King, linux-arm-kernel,
Sebastian Hesselbarth
Hi Rob,
On mer., mai 31 2017, Gregory CLEMENT <gregory.clement@free-electrons.com> wrote:
> Hi Rob,
>
> On mer., mai 31 2017, Rob Herring <robh@kernel.org> wrote:
>>>
>>> Required properties:
>>>
>>> -- compatible : Should be "marvell,orion-gpio", "marvell,mv78200-gpio"
>>> - or "marvell,armadaxp-gpio". "marvell,orion-gpio" should be used for
>>> - Orion, Kirkwood, Dove, Discovery (except MV78200) and Armada
>>> - 370. "marvell,mv78200-gpio" should be used for the Discovery
>>> - MV78200. "marvel,armadaxp-gpio" should be used for all Armada XP
>>> - SoCs (MV78230, MV78260, MV78460).
>>> +- compatible : Should be "marvell,orion-gpio", "marvell,mv78200-gpio",
>>> + "marvell,armadaxp-gpio" or "marvell,armada-8k-gpio".
>>> +
>>> + "marvell,orion-gpio" should be used for Orion, Kirkwood, Dove,
>>> + Discovery (except MV78200) and Armada 370. "marvell,mv78200-gpio"
>>> + should be used for the Discovery MV78200.
>>> +
>>> + "marvel,armadaxp-gpio" should be used for all Armada XP SoCs
>>> + (MV78230, MV78260, MV78460).
>>> +
>>> + "marvell,armada-8k-gpio" should be used for the Armada 7K and 8K
>>> + SoCs (either from AP or CP), see
>>> + Documentation/devicetree/bindings/arm/marvell/cp110-system-controller0.txt
>>> + and
>>> + Documentation/devicetree/bindings/arm/marvell/ap806-system-controller.txt
>>> + for specific details about the offset property.
>>>
>>> - reg: Address and length of the register set for the device. Only one
>>> entry is expected, except for the "marvell,armadaxp-gpio" variant
>>> for which two entries are expected: one for the general registers,
>>> - one for the per-cpu registers.
>>> + one for the per-cpu registers. Not used for marvell,armada-8k-gpio.
>>
>> Why can't use you use reg instead of offset?
>
> I looked for how the other syscon user did, and I found the offset
> usage. So I assumed it was the way to do it. But if you wan I can use a
> reg property.
I had a closer looked to the binding when syscon is used with several
subnodes. And actually the reg usage is very uncommon, I only find it in
drivers/regulator/pbias-regulator.c but for legacy.
I am not sure that we have any benefit with this reg property: we won't
use the length of the register and we need to add a range property in
the parent node.
An other way to pass this information is to have a different compatible
string which will match the different offset available. In this case the
reg property won't be used in a syscon node. However, while it makes
sens for the difference between AP806 and CP110, it would be strange to
have a different compatible string for gpio bank 1 and gpio bank 2.
So, in the end I would prefer to use the offset. From my point of view
it is better to not use the reg property for two different purposes:
mmio address vs offset in a syscon.
But if you think that from the point of view of the device tree
compliance we have to use the reg property, of course I will change it.
Thanks,
Gregory
>
> Gregory
>
>>
>> Rob
>
> --
> Gregory Clement, Free Electrons
> Kernel, drivers, real-time and embedded Linux
> development, consulting, training and support.
> http://free-electrons.com
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply [flat|nested] 65+ messages in thread
* [PATCH 3/6] gpio: dt-bindings: Add documentation for gpio controllers on Armada 7K/8K
@ 2017-06-01 17:33 ` Gregory CLEMENT
0 siblings, 0 replies; 65+ messages in thread
From: Gregory CLEMENT @ 2017-06-01 17:33 UTC (permalink / raw)
To: linux-arm-kernel
Hi Rob,
On mer., mai 31 2017, Gregory CLEMENT <gregory.clement@free-electrons.com> wrote:
> Hi Rob,
>
> On mer., mai 31 2017, Rob Herring <robh@kernel.org> wrote:
>>>
>>> Required properties:
>>>
>>> -- compatible : Should be "marvell,orion-gpio", "marvell,mv78200-gpio"
>>> - or "marvell,armadaxp-gpio". "marvell,orion-gpio" should be used for
>>> - Orion, Kirkwood, Dove, Discovery (except MV78200) and Armada
>>> - 370. "marvell,mv78200-gpio" should be used for the Discovery
>>> - MV78200. "marvel,armadaxp-gpio" should be used for all Armada XP
>>> - SoCs (MV78230, MV78260, MV78460).
>>> +- compatible : Should be "marvell,orion-gpio", "marvell,mv78200-gpio",
>>> + "marvell,armadaxp-gpio" or "marvell,armada-8k-gpio".
>>> +
>>> + "marvell,orion-gpio" should be used for Orion, Kirkwood, Dove,
>>> + Discovery (except MV78200) and Armada 370. "marvell,mv78200-gpio"
>>> + should be used for the Discovery MV78200.
>>> +
>>> + "marvel,armadaxp-gpio" should be used for all Armada XP SoCs
>>> + (MV78230, MV78260, MV78460).
>>> +
>>> + "marvell,armada-8k-gpio" should be used for the Armada 7K and 8K
>>> + SoCs (either from AP or CP), see
>>> + Documentation/devicetree/bindings/arm/marvell/cp110-system-controller0.txt
>>> + and
>>> + Documentation/devicetree/bindings/arm/marvell/ap806-system-controller.txt
>>> + for specific details about the offset property.
>>>
>>> - reg: Address and length of the register set for the device. Only one
>>> entry is expected, except for the "marvell,armadaxp-gpio" variant
>>> for which two entries are expected: one for the general registers,
>>> - one for the per-cpu registers.
>>> + one for the per-cpu registers. Not used for marvell,armada-8k-gpio.
>>
>> Why can't use you use reg instead of offset?
>
> I looked for how the other syscon user did, and I found the offset
> usage. So I assumed it was the way to do it. But if you wan I can use a
> reg property.
I had a closer looked to the binding when syscon is used with several
subnodes. And actually the reg usage is very uncommon, I only find it in
drivers/regulator/pbias-regulator.c but for legacy.
I am not sure that we have any benefit with this reg property: we won't
use the length of the register and we need to add a range property in
the parent node.
An other way to pass this information is to have a different compatible
string which will match the different offset available. In this case the
reg property won't be used in a syscon node. However, while it makes
sens for the difference between AP806 and CP110, it would be strange to
have a different compatible string for gpio bank 1 and gpio bank 2.
So, in the end I would prefer to use the offset. From my point of view
it is better to not use the reg property for two different purposes:
mmio address vs offset in a syscon.
But if you think that from the point of view of the device tree
compliance we have to use the reg property, of course I will change it.
Thanks,
Gregory
>
> Gregory
>
>>
>> Rob
>
> --
> Gregory Clement, Free Electrons
> Kernel, drivers, real-time and embedded Linux
> development, consulting, training and support.
> http://free-electrons.com
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply [flat|nested] 65+ messages in thread
end of thread, other threads:[~2017-06-01 17:33 UTC | newest]
Thread overview: 65+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-05-19 16:09 [PATCH 0/6] Extend mvebu gpio driver to support the controllers of the Marvell Armada 7K/8K Gregory CLEMENT
2017-05-19 16:09 ` Gregory CLEMENT
2017-05-19 16:09 ` [PATCH 1/6] gpio: mvebu: sort header include Gregory CLEMENT
2017-05-19 16:09 ` Gregory CLEMENT
2017-05-23 9:15 ` Linus Walleij
2017-05-23 9:15 ` Linus Walleij
2017-05-23 9:15 ` Linus Walleij
2017-05-19 16:09 ` [PATCH 2/6] gpio: mvebu: switch to regmap for register access Gregory CLEMENT
2017-05-19 16:09 ` Gregory CLEMENT
2017-05-23 9:16 ` Linus Walleij
2017-05-23 9:16 ` Linus Walleij
2017-05-23 9:16 ` Linus Walleij
2017-05-19 16:09 ` [PATCH 3/6] gpio: dt-bindings: Add documentation for gpio controllers on Armada 7K/8K Gregory CLEMENT
2017-05-19 16:09 ` Gregory CLEMENT
2017-05-23 9:20 ` Linus Walleij
2017-05-23 9:20 ` Linus Walleij
2017-05-23 9:20 ` Linus Walleij
2017-05-23 13:06 ` Gregory CLEMENT
2017-05-23 13:06 ` Gregory CLEMENT
2017-05-23 13:06 ` Gregory CLEMENT
2017-05-29 8:08 ` Linus Walleij
2017-05-29 8:08 ` Linus Walleij
2017-05-29 8:08 ` Linus Walleij
2017-05-30 22:23 ` Rob Herring
2017-05-30 22:23 ` Rob Herring
2017-05-30 22:23 ` Rob Herring
2017-05-31 10:02 ` Gregory CLEMENT
2017-05-31 10:02 ` Gregory CLEMENT
2017-05-31 10:02 ` Gregory CLEMENT
2017-05-31 10:43 ` Michael Turquette
2017-05-31 10:43 ` Michael Turquette
2017-05-31 10:43 ` Michael Turquette
2017-05-31 14:41 ` Gregory CLEMENT
2017-05-31 14:41 ` Gregory CLEMENT
2017-05-31 14:41 ` Gregory CLEMENT
[not found] ` <306395ff39de3d3d3c8f55e5da4de8def29ae8d1.1495210061.git-series.gregory.clement-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
2017-05-30 22:29 ` Rob Herring
2017-05-30 22:29 ` Rob Herring
2017-05-30 22:29 ` Rob Herring
2017-05-31 10:05 ` Gregory CLEMENT
2017-05-31 10:05 ` Gregory CLEMENT
2017-06-01 17:33 ` Gregory CLEMENT
2017-06-01 17:33 ` Gregory CLEMENT
2017-05-19 16:09 ` [PATCH 4/6] gpio: mvebu: allow building driver for " Gregory CLEMENT
2017-05-19 16:09 ` Gregory CLEMENT
2017-05-19 16:09 ` Gregory CLEMENT
2017-05-23 9:21 ` Linus Walleij
2017-05-23 9:21 ` Linus Walleij
2017-05-23 9:21 ` Linus Walleij
[not found] ` <cover.e10718b9c0f9fdd07327ae14e213be8da5b1f7ef.1495210061.git-series.gregory.clement-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
2017-05-19 16:09 ` [PATCH 5/6] gpio: mvebu: Add support for the Armada 7K/8K SoCs Gregory CLEMENT
2017-05-19 16:09 ` Gregory CLEMENT
2017-05-19 16:09 ` Gregory CLEMENT
[not found] ` <54efbdfb0a9800b2c72c6fa1d945c87182b242b4.1495210061.git-series.gregory.clement-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
2017-05-19 16:24 ` Russell King - ARM Linux
2017-05-19 16:24 ` Russell King - ARM Linux
2017-05-19 16:24 ` Russell King - ARM Linux
2017-05-19 16:27 ` Russell King - ARM Linux
2017-05-19 16:27 ` Russell King - ARM Linux
[not found] ` <20170519162736.GU22219-l+eeeJia6m9URfEZ8mYm6t73F7V6hmMc@public.gmane.org>
2017-05-19 17:05 ` Thomas Petazzoni
2017-05-19 17:05 ` Thomas Petazzoni
2017-05-19 17:05 ` Thomas Petazzoni
2017-05-19 16:09 ` [PATCH 6/6] arm64: dts: marvell: add gpio support for Armada 7K/8K Gregory CLEMENT
2017-05-19 16:09 ` Gregory CLEMENT
2017-05-19 16:09 ` Gregory CLEMENT
2017-05-31 9:16 ` [PATCH 0/6] Extend mvebu gpio driver to support the controllers of the Marvell " Thomas Petazzoni
2017-05-31 9:16 ` Thomas Petazzoni
2017-05-31 9:16 ` Thomas Petazzoni
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.