* [PATCH v2 01/12] ARM: Orion: DT support for IRQ and GPIO Controllers
2012-07-03 14:22 ` Andrew Lunn
@ 2012-07-03 14:22 ` Andrew Lunn
-1 siblings, 0 replies; 130+ messages in thread
From: Andrew Lunn @ 2012-07-03 14:22 UTC (permalink / raw)
To: Jason Cooper
Cc: grant.likely-s3s/WqlpOiPyB63q8FvJNQ,
spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
linux-i2c-u79uwXL29TY76Z2rM5mHXA,
rob.herring-bsGFqQB8/DxBDgjK7y7TUQ,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Michael Walle,
Andrew Lunn
Both IRQ and GPIO controllers can now be represented in DT. The IRQ
controllers are setup first, and then the GPIO controllers. Interrupts
for GPIO lines are placed directly after the main interrupts in the
interrupt space.
Signed-off-by: Andrew Lunn <andrew-g2DYL2Zd6BY@public.gmane.org>
---
.../devicetree/bindings/arm/mrvl/intc.txt | 19 +++
.../devicetree/bindings/gpio/mrvl-gpio.txt | 23 +++
arch/arm/Kconfig | 1 +
arch/arm/boot/dts/kirkwood.dtsi | 27 ++++
arch/arm/mach-dove/irq.c | 58 +++----
arch/arm/mach-kirkwood/board-dt.c | 3 +-
arch/arm/mach-kirkwood/irq.c | 38 ++---
arch/arm/mach-mv78xx0/irq.c | 22 +--
arch/arm/mach-orion5x/irq.c | 22 +--
arch/arm/plat-orion/gpio.c | 166 +++++++++++++++-----
arch/arm/plat-orion/include/plat/gpio.h | 16 +-
arch/arm/plat-orion/include/plat/irq.h | 3 +-
arch/arm/plat-orion/irq.c | 40 +++++
13 files changed, 306 insertions(+), 132 deletions(-)
diff --git a/Documentation/devicetree/bindings/arm/mrvl/intc.txt b/Documentation/devicetree/bindings/arm/mrvl/intc.txt
index 80b9a94..8927e10 100644
--- a/Documentation/devicetree/bindings/arm/mrvl/intc.txt
+++ b/Documentation/devicetree/bindings/arm/mrvl/intc.txt
@@ -38,3 +38,22 @@ Example:
reg-names = "mux status", "mux mask";
mrvl,intc-nr-irqs = <2>;
};
+
+* Marvell Orion Interrupt controller
+
+Required properties
+- compatible : Should be "marvell,orion-intc".
+- #interrupt-cells: Specifies the number of cells needed to encode an
+ interrupt source. Supported value is <1>.
+- interrupt-controller : Declare this node to be an interrupt controller.
+- reg : Interrupt mask address.
+
+Example:
+
+ intc: interrupt-controller {
+ compatible = "marvell,orion-intc", "marvell,intc";
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ reg = <0xfed20204 0x04>,
+ <0xfed20214 0x04>;
+ };
diff --git a/Documentation/devicetree/bindings/gpio/mrvl-gpio.txt b/Documentation/devicetree/bindings/gpio/mrvl-gpio.txt
index 05428f3..e137874 100644
--- a/Documentation/devicetree/bindings/gpio/mrvl-gpio.txt
+++ b/Documentation/devicetree/bindings/gpio/mrvl-gpio.txt
@@ -27,3 +27,26 @@ Example:
interrupt-controller;
#interrupt-cells = <1>;
};
+
+* Marvell Orion GPIO Controller
+
+Required properties:
+- compatible : Should be "marvell,orion-gpio"
+- reg : Address and length of the register set for controller.
+- gpio-controller : So we know this is a gpio controller.
+- ngpio : How many gpios this controller has.
+- interrupts : Up to 4 Interrupts for the controller.
+
+Optional properties:
+- mask-offset : For SMP Orions, offset for Nth CPU
+
+Example:
+
+ gpio0: gpio@10100 {
+ compatible = "marvell,orion-gpio";
+ #gpio-cells = <2>;
+ gpio-controller;
+ reg = <0x10100 0x40>;
+ ngpio = <32>;
+ interrupts = <35>, <36>, <37>, <38>;
+ };
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index a91009c..39bb941 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1105,6 +1105,7 @@ config PLAT_ORION
bool
select CLKSRC_MMIO
select GENERIC_IRQ_CHIP
+ select IRQ_DOMAIN
select COMMON_CLK
config PLAT_PXA
diff --git a/arch/arm/boot/dts/kirkwood.dtsi b/arch/arm/boot/dts/kirkwood.dtsi
index 926528b..66544d7 100644
--- a/arch/arm/boot/dts/kirkwood.dtsi
+++ b/arch/arm/boot/dts/kirkwood.dtsi
@@ -2,6 +2,15 @@
/ {
compatible = "mrvl,kirkwood";
+ interrupt-parent = <&intc>;
+
+ intc: interrupt-controller {
+ compatible = "marvell,orion-intc", "marvell,intc";
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ reg = <0xf1020204 0x04>,
+ <0xf1020214 0x04>;
+ };
ocp@f1000000 {
compatible = "simple-bus";
@@ -9,6 +18,24 @@
#address-cells = <1>;
#size-cells = <1>;
+ gpio0: gpio@10100 {
+ compatible = "marvell,orion-gpio";
+ #gpio-cells = <2>;
+ gpio-controller;
+ reg = <0x10100 0x40>;
+ ngpio = <32>;
+ interrupts = <35>, <36>, <37>, <38>;
+ };
+
+ gpio1: gpio@10140 {
+ compatible = "marvell,orion-gpio";
+ #gpio-cells = <2>;
+ gpio-controller;
+ reg = <0x10140 0x40>;
+ ngpio = <18>;
+ interrupts = <39>, <40>, <41>;
+ };
+
serial@12000 {
compatible = "ns16550a";
reg = <0x12000 0x100>;
diff --git a/arch/arm/mach-dove/irq.c b/arch/arm/mach-dove/irq.c
index f07fd16..9bc97a5 100644
--- a/arch/arm/mach-dove/irq.c
+++ b/arch/arm/mach-dove/irq.c
@@ -20,22 +20,6 @@
#include <mach/bridge-regs.h>
#include "common.h"
-static void gpio_irq_handler(unsigned int irq, struct irq_desc *desc)
-{
- int irqoff;
- BUG_ON(irq < IRQ_DOVE_GPIO_0_7 || irq > IRQ_DOVE_HIGH_GPIO);
-
- irqoff = irq <= IRQ_DOVE_GPIO_16_23 ? irq - IRQ_DOVE_GPIO_0_7 :
- 3 + irq - IRQ_DOVE_GPIO_24_31;
-
- orion_gpio_irq_handler(irqoff << 3);
- if (irq == IRQ_DOVE_HIGH_GPIO) {
- orion_gpio_irq_handler(40);
- orion_gpio_irq_handler(48);
- orion_gpio_irq_handler(56);
- }
-}
-
static void pmu_irq_mask(struct irq_data *d)
{
int pin = irq_to_pmu(d->irq);
@@ -90,6 +74,27 @@ static void pmu_irq_handler(unsigned int irq, struct irq_desc *desc)
}
}
+static int __initdata gpio0_irqs[4] = {
+ IRQ_DOVE_GPIO_0_7,
+ IRQ_DOVE_GPIO_8_15,
+ IRQ_DOVE_GPIO_16_23,
+ IRQ_DOVE_GPIO_24_31,
+};
+
+static int __initdata gpio1_irqs[4] = {
+ IRQ_DOVE_HIGH_GPIO,
+ 0,
+ 0,
+ 0,
+};
+
+static int __initdata gpio2_irqs[4] = {
+ 0,
+ 0,
+ 0,
+ 0,
+};
+
void __init dove_init_irq(void)
{
int i;
@@ -100,19 +105,14 @@ void __init dove_init_irq(void)
/*
* Initialize gpiolib for GPIOs 0-71.
*/
- orion_gpio_init(0, 32, DOVE_GPIO_LO_VIRT_BASE, 0,
- IRQ_DOVE_GPIO_START);
- irq_set_chained_handler(IRQ_DOVE_GPIO_0_7, gpio_irq_handler);
- irq_set_chained_handler(IRQ_DOVE_GPIO_8_15, gpio_irq_handler);
- irq_set_chained_handler(IRQ_DOVE_GPIO_16_23, gpio_irq_handler);
- irq_set_chained_handler(IRQ_DOVE_GPIO_24_31, gpio_irq_handler);
-
- orion_gpio_init(32, 32, DOVE_GPIO_HI_VIRT_BASE, 0,
- IRQ_DOVE_GPIO_START + 32);
- irq_set_chained_handler(IRQ_DOVE_HIGH_GPIO, gpio_irq_handler);
-
- orion_gpio_init(64, 8, DOVE_GPIO2_VIRT_BASE, 0,
- IRQ_DOVE_GPIO_START + 64);
+ orion_gpio_init(NULL, 0, 32, (void __iomem *)DOVE_GPIO_LO_VIRT_BASE, 0,
+ IRQ_DOVE_GPIO_START, gpio0_irqs);
+
+ orion_gpio_init(NULL, 32, 32, (void __iomem *)DOVE_GPIO_HI_VIRT_BASE, 0,
+ IRQ_DOVE_GPIO_START + 32, gpio1_irqs);
+
+ orion_gpio_init(NULL, 64, 8, (void __iomem *)DOVE_GPIO2_VIRT_BASE, 0,
+ IRQ_DOVE_GPIO_START + 64, gpio2_irqs);
/*
* Mask and clear PMU interrupts
diff --git a/arch/arm/mach-kirkwood/board-dt.c b/arch/arm/mach-kirkwood/board-dt.c
index edc3f8a..27ac3d8 100644
--- a/arch/arm/mach-kirkwood/board-dt.c
+++ b/arch/arm/mach-kirkwood/board-dt.c
@@ -18,6 +18,7 @@
#include <asm/mach/arch.h>
#include <asm/mach/map.h>
#include <mach/bridge-regs.h>
+#include <plat/irq.h>
#include "common.h"
static struct of_device_id kirkwood_dt_match_table[] __initdata = {
@@ -84,7 +85,7 @@ DT_MACHINE_START(KIRKWOOD_DT, "Marvell Kirkwood (Flattened Device Tree)")
/* Maintainer: Jason Cooper <jason-NLaQJdtUoK4Be96aLqz0jA@public.gmane.org> */
.map_io = kirkwood_map_io,
.init_early = kirkwood_init_early,
- .init_irq = kirkwood_init_irq,
+ .init_irq = orion_dt_init_irq,
.timer = &kirkwood_timer,
.init_machine = kirkwood_dt_init,
.restart = kirkwood_restart,
diff --git a/arch/arm/mach-kirkwood/irq.c b/arch/arm/mach-kirkwood/irq.c
index c4c68e5..720063f 100644
--- a/arch/arm/mach-kirkwood/irq.c
+++ b/arch/arm/mach-kirkwood/irq.c
@@ -9,20 +9,23 @@
*/
#include <linux/gpio.h>
#include <linux/kernel.h>
-#include <linux/init.h>
#include <linux/irq.h>
-#include <linux/io.h>
#include <mach/bridge-regs.h>
#include <plat/irq.h>
-#include "common.h"
-static void gpio_irq_handler(unsigned int irq, struct irq_desc *desc)
-{
- BUG_ON(irq < IRQ_KIRKWOOD_GPIO_LOW_0_7);
- BUG_ON(irq > IRQ_KIRKWOOD_GPIO_HIGH_16_23);
+static int __initdata gpio0_irqs[4] = {
+ IRQ_KIRKWOOD_GPIO_LOW_0_7,
+ IRQ_KIRKWOOD_GPIO_LOW_8_15,
+ IRQ_KIRKWOOD_GPIO_LOW_16_23,
+ IRQ_KIRKWOOD_GPIO_LOW_24_31,
+};
- orion_gpio_irq_handler((irq - IRQ_KIRKWOOD_GPIO_LOW_0_7) << 3);
-}
+static int __initdata gpio1_irqs[4] = {
+ IRQ_KIRKWOOD_GPIO_HIGH_0_7,
+ IRQ_KIRKWOOD_GPIO_HIGH_8_15,
+ IRQ_KIRKWOOD_GPIO_HIGH_16_23,
+ 0,
+};
void __init kirkwood_init_irq(void)
{
@@ -32,17 +35,8 @@ void __init kirkwood_init_irq(void)
/*
* Initialize gpiolib for GPIOs 0-49.
*/
- orion_gpio_init(0, 32, GPIO_LOW_VIRT_BASE, 0,
- IRQ_KIRKWOOD_GPIO_START);
- irq_set_chained_handler(IRQ_KIRKWOOD_GPIO_LOW_0_7, gpio_irq_handler);
- irq_set_chained_handler(IRQ_KIRKWOOD_GPIO_LOW_8_15, gpio_irq_handler);
- irq_set_chained_handler(IRQ_KIRKWOOD_GPIO_LOW_16_23, gpio_irq_handler);
- irq_set_chained_handler(IRQ_KIRKWOOD_GPIO_LOW_24_31, gpio_irq_handler);
-
- orion_gpio_init(32, 18, GPIO_HIGH_VIRT_BASE, 0,
- IRQ_KIRKWOOD_GPIO_START + 32);
- irq_set_chained_handler(IRQ_KIRKWOOD_GPIO_HIGH_0_7, gpio_irq_handler);
- irq_set_chained_handler(IRQ_KIRKWOOD_GPIO_HIGH_8_15, gpio_irq_handler);
- irq_set_chained_handler(IRQ_KIRKWOOD_GPIO_HIGH_16_23,
- gpio_irq_handler);
+ orion_gpio_init(NULL, 0, 32, (void __iomem *)GPIO_LOW_VIRT_BASE, 0,
+ IRQ_KIRKWOOD_GPIO_START, gpio0_irqs);
+ orion_gpio_init(NULL, 32, 18, (void __iomem *)GPIO_HIGH_VIRT_BASE, 0,
+ IRQ_KIRKWOOD_GPIO_START + 32, gpio1_irqs);
}
diff --git a/arch/arm/mach-mv78xx0/irq.c b/arch/arm/mach-mv78xx0/irq.c
index e421b70..eff9a75 100644
--- a/arch/arm/mach-mv78xx0/irq.c
+++ b/arch/arm/mach-mv78xx0/irq.c
@@ -9,19 +9,17 @@
*/
#include <linux/gpio.h>
#include <linux/kernel.h>
-#include <linux/init.h>
-#include <linux/pci.h>
#include <linux/irq.h>
#include <mach/bridge-regs.h>
#include <plat/irq.h>
#include "common.h"
-static void gpio_irq_handler(unsigned int irq, struct irq_desc *desc)
-{
- BUG_ON(irq < IRQ_MV78XX0_GPIO_0_7 || irq > IRQ_MV78XX0_GPIO_24_31);
-
- orion_gpio_irq_handler((irq - IRQ_MV78XX0_GPIO_0_7) << 3);
-}
+static int __initdata gpio0_irqs[4] = {
+ IRQ_MV78XX0_GPIO_0_7,
+ IRQ_MV78XX0_GPIO_8_15,
+ IRQ_MV78XX0_GPIO_16_23,
+ IRQ_MV78XX0_GPIO_24_31,
+};
void __init mv78xx0_init_irq(void)
{
@@ -34,11 +32,7 @@ void __init mv78xx0_init_irq(void)
* registers for core #1 are at an offset of 0x18 from those of
* core #0.)
*/
- orion_gpio_init(0, 32, GPIO_VIRT_BASE,
+ orion_gpio_init(NULL, 0, 32, (void __iomem *)GPIO_VIRT_BASE,
mv78xx0_core_index() ? 0x18 : 0,
- IRQ_MV78XX0_GPIO_START);
- irq_set_chained_handler(IRQ_MV78XX0_GPIO_0_7, gpio_irq_handler);
- irq_set_chained_handler(IRQ_MV78XX0_GPIO_8_15, gpio_irq_handler);
- irq_set_chained_handler(IRQ_MV78XX0_GPIO_16_23, gpio_irq_handler);
- irq_set_chained_handler(IRQ_MV78XX0_GPIO_24_31, gpio_irq_handler);
+ IRQ_MV78XX0_GPIO_START, gpio0_irqs);
}
diff --git a/arch/arm/mach-orion5x/irq.c b/arch/arm/mach-orion5x/irq.c
index b1b45ff..17da709 100644
--- a/arch/arm/mach-orion5x/irq.c
+++ b/arch/arm/mach-orion5x/irq.c
@@ -11,19 +11,16 @@
*/
#include <linux/gpio.h>
#include <linux/kernel.h>
-#include <linux/init.h>
#include <linux/irq.h>
-#include <linux/io.h>
#include <mach/bridge-regs.h>
#include <plat/irq.h>
-#include "common.h"
-static void gpio_irq_handler(unsigned int irq, struct irq_desc *desc)
-{
- BUG_ON(irq < IRQ_ORION5X_GPIO_0_7 || irq > IRQ_ORION5X_GPIO_24_31);
-
- orion_gpio_irq_handler((irq - IRQ_ORION5X_GPIO_0_7) << 3);
-}
+static int __initdata gpio0_irqs[4] = {
+ IRQ_ORION5X_GPIO_0_7,
+ IRQ_ORION5X_GPIO_8_15,
+ IRQ_ORION5X_GPIO_16_23,
+ IRQ_ORION5X_GPIO_24_31,
+};
void __init orion5x_init_irq(void)
{
@@ -32,9 +29,6 @@ void __init orion5x_init_irq(void)
/*
* Initialize gpiolib for GPIOs 0-31.
*/
- orion_gpio_init(0, 32, GPIO_VIRT_BASE, 0, IRQ_ORION5X_GPIO_START);
- irq_set_chained_handler(IRQ_ORION5X_GPIO_0_7, gpio_irq_handler);
- irq_set_chained_handler(IRQ_ORION5X_GPIO_8_15, gpio_irq_handler);
- irq_set_chained_handler(IRQ_ORION5X_GPIO_16_23, gpio_irq_handler);
- irq_set_chained_handler(IRQ_ORION5X_GPIO_24_31, gpio_irq_handler);
+ orion_gpio_init(NULL, 0, 32, (void __iomem *)GPIO_VIRT_BASE, 0,
+ IRQ_ORION5X_GPIO_START, gpio0_irqs);
}
diff --git a/arch/arm/plat-orion/gpio.c b/arch/arm/plat-orion/gpio.c
index af95af2..dfda74f 100644
--- a/arch/arm/plat-orion/gpio.c
+++ b/arch/arm/plat-orion/gpio.c
@@ -8,15 +8,22 @@
* warranty of any kind, whether express or implied.
*/
+#define DEBUG
+
#include <linux/kernel.h>
#include <linux/init.h>
#include <linux/irq.h>
+#include <linux/irqdomain.h>
#include <linux/module.h>
#include <linux/spinlock.h>
#include <linux/bitops.h>
#include <linux/io.h>
#include <linux/gpio.h>
#include <linux/leds.h>
+#include <linux/of.h>
+#include <linux/of_irq.h>
+#include <linux/of_address.h>
+#include <plat/gpio.h>
/*
* GPIO unit register offsets.
@@ -38,6 +45,7 @@ struct orion_gpio_chip {
unsigned long valid_output;
int mask_offset;
int secondary_irq_base;
+ struct irq_domain *domain;
};
static void __iomem *GPIO_OUT(struct orion_gpio_chip *ochip)
@@ -222,10 +230,10 @@ static int orion_gpio_to_irq(struct gpio_chip *chip, unsigned pin)
struct orion_gpio_chip *ochip =
container_of(chip, struct orion_gpio_chip, chip);
- return ochip->secondary_irq_base + pin;
+ return irq_create_mapping(ochip->domain,
+ ochip->secondary_irq_base + pin);
}
-
/*
* Orion-specific GPIO API extensions.
*/
@@ -353,12 +361,10 @@ static int gpio_irq_set_type(struct irq_data *d, u32 type)
int pin;
u32 u;
- pin = d->irq - gc->irq_base;
+ pin = d->hwirq - ochip->secondary_irq_base;
u = readl(GPIO_IO_CONF(ochip)) & (1 << pin);
if (!u) {
- printk(KERN_ERR "orion gpio_irq_set_type failed "
- "(irq %d, pin %d).\n", d->irq, pin);
return -EINVAL;
}
@@ -397,17 +403,53 @@ static int gpio_irq_set_type(struct irq_data *d, u32 type)
u &= ~(1 << pin); /* rising */
writel(u, GPIO_IN_POL(ochip));
}
-
return 0;
}
-void __init orion_gpio_init(int gpio_base, int ngpio,
- u32 base, int mask_offset, int secondary_irq_base)
+static void gpio_irq_handler(unsigned irq, struct irq_desc *desc)
+{
+ struct orion_gpio_chip *ochip = irq_get_handler_data(irq);
+ u32 cause, type;
+ int i;
+
+ if (ochip == NULL)
+ return;
+
+ cause = readl(GPIO_DATA_IN(ochip)) & readl(GPIO_LEVEL_MASK(ochip));
+ cause |= readl(GPIO_EDGE_CAUSE(ochip)) & readl(GPIO_EDGE_MASK(ochip));
+
+ for (i = 0; i < ochip->chip.ngpio; i++) {
+ int irq;
+
+ irq = ochip->secondary_irq_base + i;
+
+ if (!(cause & (1 << i)))
+ continue;
+
+ type = irqd_get_trigger_type(irq_get_irq_data(irq));
+ if ((type & IRQ_TYPE_SENSE_MASK) == IRQ_TYPE_EDGE_BOTH) {
+ /* Swap polarity (race with GPIO line) */
+ u32 polarity;
+
+ polarity = readl(GPIO_IN_POL(ochip));
+ polarity ^= 1 << i;
+ writel(polarity, GPIO_IN_POL(ochip));
+ }
+ generic_handle_irq(irq);
+ }
+}
+
+void __init orion_gpio_init(struct device_node *np,
+ int gpio_base, int ngpio,
+ void __iomem *base, int mask_offset,
+ int secondary_irq_base,
+ int irqs[4])
{
struct orion_gpio_chip *ochip;
struct irq_chip_generic *gc;
struct irq_chip_type *ct;
char gc_label[16];
+ int i;
if (orion_gpio_chip_count == ARRAY_SIZE(orion_gpio_chips))
return;
@@ -426,6 +468,10 @@ void __init orion_gpio_init(int gpio_base, int ngpio,
ochip->chip.base = gpio_base;
ochip->chip.ngpio = ngpio;
ochip->chip.can_sleep = 0;
+#ifdef CONFIG_OF
+ ochip->chip.of_node = np;
+#endif
+
spin_lock_init(&ochip->lock);
ochip->base = (void __iomem *)base;
ochip->valid_input = 0;
@@ -435,8 +481,6 @@ void __init orion_gpio_init(int gpio_base, int ngpio,
gpiochip_add(&ochip->chip);
- orion_gpio_chip_count++;
-
/*
* Mask and clear GPIO interrupts.
*/
@@ -444,16 +488,28 @@ void __init orion_gpio_init(int gpio_base, int ngpio,
writel(0, GPIO_EDGE_MASK(ochip));
writel(0, GPIO_LEVEL_MASK(ochip));
- gc = irq_alloc_generic_chip("orion_gpio_irq", 2, secondary_irq_base,
+ /* Setup the interrupt handlers. Each chip can have up to 4
+ * interrupt handlers, with each handler dealing with 8 GPIO
+ * pins. */
+
+ for (i = 0; i < 4; i++) {
+ if (irqs[i]) {
+ irq_set_handler_data(irqs[i], ochip);
+ irq_set_chained_handler(irqs[i], gpio_irq_handler);
+ }
+ }
+
+ gc = irq_alloc_generic_chip("orion_gpio_irq", 2,
+ secondary_irq_base,
ochip->base, handle_level_irq);
gc->private = ochip;
-
ct = gc->chip_types;
ct->regs.mask = ochip->mask_offset + GPIO_LEVEL_MASK_OFF;
ct->type = IRQ_TYPE_LEVEL_HIGH | IRQ_TYPE_LEVEL_LOW;
ct->chip.irq_mask = irq_gc_mask_clr_bit;
ct->chip.irq_unmask = irq_gc_mask_set_bit;
ct->chip.irq_set_type = gpio_irq_set_type;
+ ct->chip.name = ochip->chip.label;
ct++;
ct->regs.mask = ochip->mask_offset + GPIO_EDGE_MASK_OFF;
@@ -464,41 +520,69 @@ void __init orion_gpio_init(int gpio_base, int ngpio,
ct->chip.irq_unmask = irq_gc_mask_set_bit;
ct->chip.irq_set_type = gpio_irq_set_type;
ct->handler = handle_edge_irq;
+ ct->chip.name = ochip->chip.label;
irq_setup_generic_chip(gc, IRQ_MSK(ngpio), IRQ_GC_INIT_MASK_CACHE,
IRQ_NOREQUEST, IRQ_LEVEL | IRQ_NOPROBE);
-}
-void orion_gpio_irq_handler(int pinoff)
-{
- struct orion_gpio_chip *ochip;
- u32 cause, type;
- int i;
-
- ochip = orion_gpio_chip_find(pinoff);
- if (ochip == NULL)
- return;
-
- cause = readl(GPIO_DATA_IN(ochip)) & readl(GPIO_LEVEL_MASK(ochip));
- cause |= readl(GPIO_EDGE_CAUSE(ochip)) & readl(GPIO_EDGE_MASK(ochip));
-
- for (i = 0; i < ochip->chip.ngpio; i++) {
- int irq;
+ /* Setup irq domain on top of the generic chip. */
+ ochip->domain = irq_domain_add_legacy(np,
+ ochip->chip.ngpio,
+ ochip->secondary_irq_base,
+ ochip->secondary_irq_base,
+ &irq_domain_simple_ops,
+ ochip);
+ if (!ochip->domain)
+ panic("%s: couldn't allocate irq domain (DT).\n",
+ ochip->chip.label);
- irq = ochip->secondary_irq_base + i;
+ orion_gpio_chip_count++;
+}
- if (!(cause & (1 << i)))
- continue;
+#ifdef CONFIG_OF
+static void __init orion_gpio_of_init_one(struct device_node *np,
+ int irq_gpio_base)
+{
+ int ngpio, gpio_base, mask_offset;
+ void __iomem *base;
+ int ret, i;
+ int irqs[4];
+ int secondary_irq_base;
+
+ ret = of_property_read_u32(np, "ngpio", &ngpio);
+ if (ret)
+ goto out;
+ ret = of_property_read_u32(np, "mask-offset", &mask_offset);
+ if (ret == -EINVAL)
+ mask_offset = 0;
+ else
+ goto out;
+ base = of_iomap(np, 0);
+ if (!base)
+ goto out;
+
+ secondary_irq_base = irq_gpio_base + (32 * orion_gpio_chip_count);
+ gpio_base = 32 * orion_gpio_chip_count;
+
+ /* Get the interrupt numbers. Each chip can have up to 4
+ * interrupt handlers, with each handler dealing with 8 GPIO
+ * pins. */
+
+ for (i = 0; i < 4; i++)
+ irqs[i] = irq_of_parse_and_map(np, i);
+
+ orion_gpio_init(np, gpio_base, ngpio, base, mask_offset,
+ secondary_irq_base, irqs);
+ return;
+out:
+ pr_err("%s: %s: missing mandatory property\n", __func__, np->name);
+}
- type = irqd_get_trigger_type(irq_get_irq_data(irq));
- if ((type & IRQ_TYPE_SENSE_MASK) == IRQ_TYPE_EDGE_BOTH) {
- /* Swap polarity (race with GPIO line) */
- u32 polarity;
+void __init orion_gpio_of_init(int irq_gpio_base)
+{
+ struct device_node *np;
- polarity = readl(GPIO_IN_POL(ochip));
- polarity ^= 1 << i;
- writel(polarity, GPIO_IN_POL(ochip));
- }
- generic_handle_irq(irq);
- }
+ for_each_compatible_node(np, NULL, "marvell,orion-gpio")
+ orion_gpio_of_init_one(np, irq_gpio_base);
}
+#endif
diff --git a/arch/arm/plat-orion/include/plat/gpio.h b/arch/arm/plat-orion/include/plat/gpio.h
index bec0c98..81c6fc8 100644
--- a/arch/arm/plat-orion/include/plat/gpio.h
+++ b/arch/arm/plat-orion/include/plat/gpio.h
@@ -13,7 +13,7 @@
#include <linux/init.h>
#include <linux/types.h>
-
+#include <linux/irqdomain.h>
/*
* Orion-specific GPIO API extensions.
*/
@@ -27,13 +27,11 @@ int orion_gpio_led_blink_set(unsigned gpio, int state,
void orion_gpio_set_valid(unsigned pin, int mode);
/* Initialize gpiolib. */
-void __init orion_gpio_init(int gpio_base, int ngpio,
- u32 base, int mask_offset, int secondary_irq_base);
-
-/*
- * GPIO interrupt handling.
- */
-void orion_gpio_irq_handler(int irqoff);
-
+void __init orion_gpio_init(struct device_node *np,
+ int gpio_base, int ngpio,
+ void __iomem *base, int mask_offset,
+ int secondary_irq_base,
+ int irq[4]);
+void __init orion_gpio_of_init(int irq_gpio_base);
#endif
diff --git a/arch/arm/plat-orion/include/plat/irq.h b/arch/arm/plat-orion/include/plat/irq.h
index f05eeab..50547e4 100644
--- a/arch/arm/plat-orion/include/plat/irq.h
+++ b/arch/arm/plat-orion/include/plat/irq.h
@@ -12,6 +12,5 @@
#define __PLAT_IRQ_H
void orion_irq_init(unsigned int irq_start, void __iomem *maskaddr);
-
-
+void __init orion_dt_init_irq(void);
#endif
diff --git a/arch/arm/plat-orion/irq.c b/arch/arm/plat-orion/irq.c
index 2d5b9c1..d751964 100644
--- a/arch/arm/plat-orion/irq.c
+++ b/arch/arm/plat-orion/irq.c
@@ -11,8 +11,12 @@
#include <linux/kernel.h>
#include <linux/init.h>
#include <linux/irq.h>
+#include <linux/irqdomain.h>
#include <linux/io.h>
+#include <linux/of_address.h>
+#include <linux/of_irq.h>
#include <plat/irq.h>
+#include <plat/gpio.h>
void __init orion_irq_init(unsigned int irq_start, void __iomem *maskaddr)
{
@@ -32,3 +36,39 @@ void __init orion_irq_init(unsigned int irq_start, void __iomem *maskaddr)
irq_setup_generic_chip(gc, IRQ_MSK(32), IRQ_GC_INIT_MASK_CACHE,
IRQ_NOREQUEST, IRQ_LEVEL | IRQ_NOPROBE);
}
+
+#ifdef CONFIG_OF
+static int __init orion_add_irq_domain(struct device_node *np,
+ struct device_node *interrupt_parent)
+{
+ int i = 0, irq_gpio;
+ void __iomem *base;
+
+ do {
+ base = of_iomap(np, i);
+ if (base) {
+ orion_irq_init(i * 32, base);
+ i++;
+ }
+ } while (base);
+
+ irq_domain_add_legacy(np, i * 32, 0, 0,
+ &irq_domain_simple_ops, NULL);
+
+ irq_gpio = i * 32;
+ orion_gpio_of_init(irq_gpio);
+
+ return 0;
+}
+
+static const struct of_device_id orion_irq_match[] = {
+ { .compatible = "marvell,orion-intc",
+ .data = orion_add_irq_domain, },
+ {},
+};
+
+void __init orion_dt_init_irq(void)
+{
+ of_irq_init(orion_irq_match);
+}
+#endif
--
1.7.10
^ permalink raw reply related [flat|nested] 130+ messages in thread* [PATCH v2 01/12] ARM: Orion: DT support for IRQ and GPIO Controllers
@ 2012-07-03 14:22 ` Andrew Lunn
0 siblings, 0 replies; 130+ messages in thread
From: Andrew Lunn @ 2012-07-03 14:22 UTC (permalink / raw)
To: linux-arm-kernel
Both IRQ and GPIO controllers can now be represented in DT. The IRQ
controllers are setup first, and then the GPIO controllers. Interrupts
for GPIO lines are placed directly after the main interrupts in the
interrupt space.
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
---
.../devicetree/bindings/arm/mrvl/intc.txt | 19 +++
.../devicetree/bindings/gpio/mrvl-gpio.txt | 23 +++
arch/arm/Kconfig | 1 +
arch/arm/boot/dts/kirkwood.dtsi | 27 ++++
arch/arm/mach-dove/irq.c | 58 +++----
arch/arm/mach-kirkwood/board-dt.c | 3 +-
arch/arm/mach-kirkwood/irq.c | 38 ++---
arch/arm/mach-mv78xx0/irq.c | 22 +--
arch/arm/mach-orion5x/irq.c | 22 +--
arch/arm/plat-orion/gpio.c | 166 +++++++++++++++-----
arch/arm/plat-orion/include/plat/gpio.h | 16 +-
arch/arm/plat-orion/include/plat/irq.h | 3 +-
arch/arm/plat-orion/irq.c | 40 +++++
13 files changed, 306 insertions(+), 132 deletions(-)
diff --git a/Documentation/devicetree/bindings/arm/mrvl/intc.txt b/Documentation/devicetree/bindings/arm/mrvl/intc.txt
index 80b9a94..8927e10 100644
--- a/Documentation/devicetree/bindings/arm/mrvl/intc.txt
+++ b/Documentation/devicetree/bindings/arm/mrvl/intc.txt
@@ -38,3 +38,22 @@ Example:
reg-names = "mux status", "mux mask";
mrvl,intc-nr-irqs = <2>;
};
+
+* Marvell Orion Interrupt controller
+
+Required properties
+- compatible : Should be "marvell,orion-intc".
+- #interrupt-cells: Specifies the number of cells needed to encode an
+ interrupt source. Supported value is <1>.
+- interrupt-controller : Declare this node to be an interrupt controller.
+- reg : Interrupt mask address.
+
+Example:
+
+ intc: interrupt-controller {
+ compatible = "marvell,orion-intc", "marvell,intc";
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ reg = <0xfed20204 0x04>,
+ <0xfed20214 0x04>;
+ };
diff --git a/Documentation/devicetree/bindings/gpio/mrvl-gpio.txt b/Documentation/devicetree/bindings/gpio/mrvl-gpio.txt
index 05428f3..e137874 100644
--- a/Documentation/devicetree/bindings/gpio/mrvl-gpio.txt
+++ b/Documentation/devicetree/bindings/gpio/mrvl-gpio.txt
@@ -27,3 +27,26 @@ Example:
interrupt-controller;
#interrupt-cells = <1>;
};
+
+* Marvell Orion GPIO Controller
+
+Required properties:
+- compatible : Should be "marvell,orion-gpio"
+- reg : Address and length of the register set for controller.
+- gpio-controller : So we know this is a gpio controller.
+- ngpio : How many gpios this controller has.
+- interrupts : Up to 4 Interrupts for the controller.
+
+Optional properties:
+- mask-offset : For SMP Orions, offset for Nth CPU
+
+Example:
+
+ gpio0: gpio at 10100 {
+ compatible = "marvell,orion-gpio";
+ #gpio-cells = <2>;
+ gpio-controller;
+ reg = <0x10100 0x40>;
+ ngpio = <32>;
+ interrupts = <35>, <36>, <37>, <38>;
+ };
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index a91009c..39bb941 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1105,6 +1105,7 @@ config PLAT_ORION
bool
select CLKSRC_MMIO
select GENERIC_IRQ_CHIP
+ select IRQ_DOMAIN
select COMMON_CLK
config PLAT_PXA
diff --git a/arch/arm/boot/dts/kirkwood.dtsi b/arch/arm/boot/dts/kirkwood.dtsi
index 926528b..66544d7 100644
--- a/arch/arm/boot/dts/kirkwood.dtsi
+++ b/arch/arm/boot/dts/kirkwood.dtsi
@@ -2,6 +2,15 @@
/ {
compatible = "mrvl,kirkwood";
+ interrupt-parent = <&intc>;
+
+ intc: interrupt-controller {
+ compatible = "marvell,orion-intc", "marvell,intc";
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ reg = <0xf1020204 0x04>,
+ <0xf1020214 0x04>;
+ };
ocp at f1000000 {
compatible = "simple-bus";
@@ -9,6 +18,24 @@
#address-cells = <1>;
#size-cells = <1>;
+ gpio0: gpio at 10100 {
+ compatible = "marvell,orion-gpio";
+ #gpio-cells = <2>;
+ gpio-controller;
+ reg = <0x10100 0x40>;
+ ngpio = <32>;
+ interrupts = <35>, <36>, <37>, <38>;
+ };
+
+ gpio1: gpio at 10140 {
+ compatible = "marvell,orion-gpio";
+ #gpio-cells = <2>;
+ gpio-controller;
+ reg = <0x10140 0x40>;
+ ngpio = <18>;
+ interrupts = <39>, <40>, <41>;
+ };
+
serial at 12000 {
compatible = "ns16550a";
reg = <0x12000 0x100>;
diff --git a/arch/arm/mach-dove/irq.c b/arch/arm/mach-dove/irq.c
index f07fd16..9bc97a5 100644
--- a/arch/arm/mach-dove/irq.c
+++ b/arch/arm/mach-dove/irq.c
@@ -20,22 +20,6 @@
#include <mach/bridge-regs.h>
#include "common.h"
-static void gpio_irq_handler(unsigned int irq, struct irq_desc *desc)
-{
- int irqoff;
- BUG_ON(irq < IRQ_DOVE_GPIO_0_7 || irq > IRQ_DOVE_HIGH_GPIO);
-
- irqoff = irq <= IRQ_DOVE_GPIO_16_23 ? irq - IRQ_DOVE_GPIO_0_7 :
- 3 + irq - IRQ_DOVE_GPIO_24_31;
-
- orion_gpio_irq_handler(irqoff << 3);
- if (irq == IRQ_DOVE_HIGH_GPIO) {
- orion_gpio_irq_handler(40);
- orion_gpio_irq_handler(48);
- orion_gpio_irq_handler(56);
- }
-}
-
static void pmu_irq_mask(struct irq_data *d)
{
int pin = irq_to_pmu(d->irq);
@@ -90,6 +74,27 @@ static void pmu_irq_handler(unsigned int irq, struct irq_desc *desc)
}
}
+static int __initdata gpio0_irqs[4] = {
+ IRQ_DOVE_GPIO_0_7,
+ IRQ_DOVE_GPIO_8_15,
+ IRQ_DOVE_GPIO_16_23,
+ IRQ_DOVE_GPIO_24_31,
+};
+
+static int __initdata gpio1_irqs[4] = {
+ IRQ_DOVE_HIGH_GPIO,
+ 0,
+ 0,
+ 0,
+};
+
+static int __initdata gpio2_irqs[4] = {
+ 0,
+ 0,
+ 0,
+ 0,
+};
+
void __init dove_init_irq(void)
{
int i;
@@ -100,19 +105,14 @@ void __init dove_init_irq(void)
/*
* Initialize gpiolib for GPIOs 0-71.
*/
- orion_gpio_init(0, 32, DOVE_GPIO_LO_VIRT_BASE, 0,
- IRQ_DOVE_GPIO_START);
- irq_set_chained_handler(IRQ_DOVE_GPIO_0_7, gpio_irq_handler);
- irq_set_chained_handler(IRQ_DOVE_GPIO_8_15, gpio_irq_handler);
- irq_set_chained_handler(IRQ_DOVE_GPIO_16_23, gpio_irq_handler);
- irq_set_chained_handler(IRQ_DOVE_GPIO_24_31, gpio_irq_handler);
-
- orion_gpio_init(32, 32, DOVE_GPIO_HI_VIRT_BASE, 0,
- IRQ_DOVE_GPIO_START + 32);
- irq_set_chained_handler(IRQ_DOVE_HIGH_GPIO, gpio_irq_handler);
-
- orion_gpio_init(64, 8, DOVE_GPIO2_VIRT_BASE, 0,
- IRQ_DOVE_GPIO_START + 64);
+ orion_gpio_init(NULL, 0, 32, (void __iomem *)DOVE_GPIO_LO_VIRT_BASE, 0,
+ IRQ_DOVE_GPIO_START, gpio0_irqs);
+
+ orion_gpio_init(NULL, 32, 32, (void __iomem *)DOVE_GPIO_HI_VIRT_BASE, 0,
+ IRQ_DOVE_GPIO_START + 32, gpio1_irqs);
+
+ orion_gpio_init(NULL, 64, 8, (void __iomem *)DOVE_GPIO2_VIRT_BASE, 0,
+ IRQ_DOVE_GPIO_START + 64, gpio2_irqs);
/*
* Mask and clear PMU interrupts
diff --git a/arch/arm/mach-kirkwood/board-dt.c b/arch/arm/mach-kirkwood/board-dt.c
index edc3f8a..27ac3d8 100644
--- a/arch/arm/mach-kirkwood/board-dt.c
+++ b/arch/arm/mach-kirkwood/board-dt.c
@@ -18,6 +18,7 @@
#include <asm/mach/arch.h>
#include <asm/mach/map.h>
#include <mach/bridge-regs.h>
+#include <plat/irq.h>
#include "common.h"
static struct of_device_id kirkwood_dt_match_table[] __initdata = {
@@ -84,7 +85,7 @@ DT_MACHINE_START(KIRKWOOD_DT, "Marvell Kirkwood (Flattened Device Tree)")
/* Maintainer: Jason Cooper <jason@lakedaemon.net> */
.map_io = kirkwood_map_io,
.init_early = kirkwood_init_early,
- .init_irq = kirkwood_init_irq,
+ .init_irq = orion_dt_init_irq,
.timer = &kirkwood_timer,
.init_machine = kirkwood_dt_init,
.restart = kirkwood_restart,
diff --git a/arch/arm/mach-kirkwood/irq.c b/arch/arm/mach-kirkwood/irq.c
index c4c68e5..720063f 100644
--- a/arch/arm/mach-kirkwood/irq.c
+++ b/arch/arm/mach-kirkwood/irq.c
@@ -9,20 +9,23 @@
*/
#include <linux/gpio.h>
#include <linux/kernel.h>
-#include <linux/init.h>
#include <linux/irq.h>
-#include <linux/io.h>
#include <mach/bridge-regs.h>
#include <plat/irq.h>
-#include "common.h"
-static void gpio_irq_handler(unsigned int irq, struct irq_desc *desc)
-{
- BUG_ON(irq < IRQ_KIRKWOOD_GPIO_LOW_0_7);
- BUG_ON(irq > IRQ_KIRKWOOD_GPIO_HIGH_16_23);
+static int __initdata gpio0_irqs[4] = {
+ IRQ_KIRKWOOD_GPIO_LOW_0_7,
+ IRQ_KIRKWOOD_GPIO_LOW_8_15,
+ IRQ_KIRKWOOD_GPIO_LOW_16_23,
+ IRQ_KIRKWOOD_GPIO_LOW_24_31,
+};
- orion_gpio_irq_handler((irq - IRQ_KIRKWOOD_GPIO_LOW_0_7) << 3);
-}
+static int __initdata gpio1_irqs[4] = {
+ IRQ_KIRKWOOD_GPIO_HIGH_0_7,
+ IRQ_KIRKWOOD_GPIO_HIGH_8_15,
+ IRQ_KIRKWOOD_GPIO_HIGH_16_23,
+ 0,
+};
void __init kirkwood_init_irq(void)
{
@@ -32,17 +35,8 @@ void __init kirkwood_init_irq(void)
/*
* Initialize gpiolib for GPIOs 0-49.
*/
- orion_gpio_init(0, 32, GPIO_LOW_VIRT_BASE, 0,
- IRQ_KIRKWOOD_GPIO_START);
- irq_set_chained_handler(IRQ_KIRKWOOD_GPIO_LOW_0_7, gpio_irq_handler);
- irq_set_chained_handler(IRQ_KIRKWOOD_GPIO_LOW_8_15, gpio_irq_handler);
- irq_set_chained_handler(IRQ_KIRKWOOD_GPIO_LOW_16_23, gpio_irq_handler);
- irq_set_chained_handler(IRQ_KIRKWOOD_GPIO_LOW_24_31, gpio_irq_handler);
-
- orion_gpio_init(32, 18, GPIO_HIGH_VIRT_BASE, 0,
- IRQ_KIRKWOOD_GPIO_START + 32);
- irq_set_chained_handler(IRQ_KIRKWOOD_GPIO_HIGH_0_7, gpio_irq_handler);
- irq_set_chained_handler(IRQ_KIRKWOOD_GPIO_HIGH_8_15, gpio_irq_handler);
- irq_set_chained_handler(IRQ_KIRKWOOD_GPIO_HIGH_16_23,
- gpio_irq_handler);
+ orion_gpio_init(NULL, 0, 32, (void __iomem *)GPIO_LOW_VIRT_BASE, 0,
+ IRQ_KIRKWOOD_GPIO_START, gpio0_irqs);
+ orion_gpio_init(NULL, 32, 18, (void __iomem *)GPIO_HIGH_VIRT_BASE, 0,
+ IRQ_KIRKWOOD_GPIO_START + 32, gpio1_irqs);
}
diff --git a/arch/arm/mach-mv78xx0/irq.c b/arch/arm/mach-mv78xx0/irq.c
index e421b70..eff9a75 100644
--- a/arch/arm/mach-mv78xx0/irq.c
+++ b/arch/arm/mach-mv78xx0/irq.c
@@ -9,19 +9,17 @@
*/
#include <linux/gpio.h>
#include <linux/kernel.h>
-#include <linux/init.h>
-#include <linux/pci.h>
#include <linux/irq.h>
#include <mach/bridge-regs.h>
#include <plat/irq.h>
#include "common.h"
-static void gpio_irq_handler(unsigned int irq, struct irq_desc *desc)
-{
- BUG_ON(irq < IRQ_MV78XX0_GPIO_0_7 || irq > IRQ_MV78XX0_GPIO_24_31);
-
- orion_gpio_irq_handler((irq - IRQ_MV78XX0_GPIO_0_7) << 3);
-}
+static int __initdata gpio0_irqs[4] = {
+ IRQ_MV78XX0_GPIO_0_7,
+ IRQ_MV78XX0_GPIO_8_15,
+ IRQ_MV78XX0_GPIO_16_23,
+ IRQ_MV78XX0_GPIO_24_31,
+};
void __init mv78xx0_init_irq(void)
{
@@ -34,11 +32,7 @@ void __init mv78xx0_init_irq(void)
* registers for core #1 are@an offset of 0x18 from those of
* core #0.)
*/
- orion_gpio_init(0, 32, GPIO_VIRT_BASE,
+ orion_gpio_init(NULL, 0, 32, (void __iomem *)GPIO_VIRT_BASE,
mv78xx0_core_index() ? 0x18 : 0,
- IRQ_MV78XX0_GPIO_START);
- irq_set_chained_handler(IRQ_MV78XX0_GPIO_0_7, gpio_irq_handler);
- irq_set_chained_handler(IRQ_MV78XX0_GPIO_8_15, gpio_irq_handler);
- irq_set_chained_handler(IRQ_MV78XX0_GPIO_16_23, gpio_irq_handler);
- irq_set_chained_handler(IRQ_MV78XX0_GPIO_24_31, gpio_irq_handler);
+ IRQ_MV78XX0_GPIO_START, gpio0_irqs);
}
diff --git a/arch/arm/mach-orion5x/irq.c b/arch/arm/mach-orion5x/irq.c
index b1b45ff..17da709 100644
--- a/arch/arm/mach-orion5x/irq.c
+++ b/arch/arm/mach-orion5x/irq.c
@@ -11,19 +11,16 @@
*/
#include <linux/gpio.h>
#include <linux/kernel.h>
-#include <linux/init.h>
#include <linux/irq.h>
-#include <linux/io.h>
#include <mach/bridge-regs.h>
#include <plat/irq.h>
-#include "common.h"
-static void gpio_irq_handler(unsigned int irq, struct irq_desc *desc)
-{
- BUG_ON(irq < IRQ_ORION5X_GPIO_0_7 || irq > IRQ_ORION5X_GPIO_24_31);
-
- orion_gpio_irq_handler((irq - IRQ_ORION5X_GPIO_0_7) << 3);
-}
+static int __initdata gpio0_irqs[4] = {
+ IRQ_ORION5X_GPIO_0_7,
+ IRQ_ORION5X_GPIO_8_15,
+ IRQ_ORION5X_GPIO_16_23,
+ IRQ_ORION5X_GPIO_24_31,
+};
void __init orion5x_init_irq(void)
{
@@ -32,9 +29,6 @@ void __init orion5x_init_irq(void)
/*
* Initialize gpiolib for GPIOs 0-31.
*/
- orion_gpio_init(0, 32, GPIO_VIRT_BASE, 0, IRQ_ORION5X_GPIO_START);
- irq_set_chained_handler(IRQ_ORION5X_GPIO_0_7, gpio_irq_handler);
- irq_set_chained_handler(IRQ_ORION5X_GPIO_8_15, gpio_irq_handler);
- irq_set_chained_handler(IRQ_ORION5X_GPIO_16_23, gpio_irq_handler);
- irq_set_chained_handler(IRQ_ORION5X_GPIO_24_31, gpio_irq_handler);
+ orion_gpio_init(NULL, 0, 32, (void __iomem *)GPIO_VIRT_BASE, 0,
+ IRQ_ORION5X_GPIO_START, gpio0_irqs);
}
diff --git a/arch/arm/plat-orion/gpio.c b/arch/arm/plat-orion/gpio.c
index af95af2..dfda74f 100644
--- a/arch/arm/plat-orion/gpio.c
+++ b/arch/arm/plat-orion/gpio.c
@@ -8,15 +8,22 @@
* warranty of any kind, whether express or implied.
*/
+#define DEBUG
+
#include <linux/kernel.h>
#include <linux/init.h>
#include <linux/irq.h>
+#include <linux/irqdomain.h>
#include <linux/module.h>
#include <linux/spinlock.h>
#include <linux/bitops.h>
#include <linux/io.h>
#include <linux/gpio.h>
#include <linux/leds.h>
+#include <linux/of.h>
+#include <linux/of_irq.h>
+#include <linux/of_address.h>
+#include <plat/gpio.h>
/*
* GPIO unit register offsets.
@@ -38,6 +45,7 @@ struct orion_gpio_chip {
unsigned long valid_output;
int mask_offset;
int secondary_irq_base;
+ struct irq_domain *domain;
};
static void __iomem *GPIO_OUT(struct orion_gpio_chip *ochip)
@@ -222,10 +230,10 @@ static int orion_gpio_to_irq(struct gpio_chip *chip, unsigned pin)
struct orion_gpio_chip *ochip =
container_of(chip, struct orion_gpio_chip, chip);
- return ochip->secondary_irq_base + pin;
+ return irq_create_mapping(ochip->domain,
+ ochip->secondary_irq_base + pin);
}
-
/*
* Orion-specific GPIO API extensions.
*/
@@ -353,12 +361,10 @@ static int gpio_irq_set_type(struct irq_data *d, u32 type)
int pin;
u32 u;
- pin = d->irq - gc->irq_base;
+ pin = d->hwirq - ochip->secondary_irq_base;
u = readl(GPIO_IO_CONF(ochip)) & (1 << pin);
if (!u) {
- printk(KERN_ERR "orion gpio_irq_set_type failed "
- "(irq %d, pin %d).\n", d->irq, pin);
return -EINVAL;
}
@@ -397,17 +403,53 @@ static int gpio_irq_set_type(struct irq_data *d, u32 type)
u &= ~(1 << pin); /* rising */
writel(u, GPIO_IN_POL(ochip));
}
-
return 0;
}
-void __init orion_gpio_init(int gpio_base, int ngpio,
- u32 base, int mask_offset, int secondary_irq_base)
+static void gpio_irq_handler(unsigned irq, struct irq_desc *desc)
+{
+ struct orion_gpio_chip *ochip = irq_get_handler_data(irq);
+ u32 cause, type;
+ int i;
+
+ if (ochip == NULL)
+ return;
+
+ cause = readl(GPIO_DATA_IN(ochip)) & readl(GPIO_LEVEL_MASK(ochip));
+ cause |= readl(GPIO_EDGE_CAUSE(ochip)) & readl(GPIO_EDGE_MASK(ochip));
+
+ for (i = 0; i < ochip->chip.ngpio; i++) {
+ int irq;
+
+ irq = ochip->secondary_irq_base + i;
+
+ if (!(cause & (1 << i)))
+ continue;
+
+ type = irqd_get_trigger_type(irq_get_irq_data(irq));
+ if ((type & IRQ_TYPE_SENSE_MASK) == IRQ_TYPE_EDGE_BOTH) {
+ /* Swap polarity (race with GPIO line) */
+ u32 polarity;
+
+ polarity = readl(GPIO_IN_POL(ochip));
+ polarity ^= 1 << i;
+ writel(polarity, GPIO_IN_POL(ochip));
+ }
+ generic_handle_irq(irq);
+ }
+}
+
+void __init orion_gpio_init(struct device_node *np,
+ int gpio_base, int ngpio,
+ void __iomem *base, int mask_offset,
+ int secondary_irq_base,
+ int irqs[4])
{
struct orion_gpio_chip *ochip;
struct irq_chip_generic *gc;
struct irq_chip_type *ct;
char gc_label[16];
+ int i;
if (orion_gpio_chip_count == ARRAY_SIZE(orion_gpio_chips))
return;
@@ -426,6 +468,10 @@ void __init orion_gpio_init(int gpio_base, int ngpio,
ochip->chip.base = gpio_base;
ochip->chip.ngpio = ngpio;
ochip->chip.can_sleep = 0;
+#ifdef CONFIG_OF
+ ochip->chip.of_node = np;
+#endif
+
spin_lock_init(&ochip->lock);
ochip->base = (void __iomem *)base;
ochip->valid_input = 0;
@@ -435,8 +481,6 @@ void __init orion_gpio_init(int gpio_base, int ngpio,
gpiochip_add(&ochip->chip);
- orion_gpio_chip_count++;
-
/*
* Mask and clear GPIO interrupts.
*/
@@ -444,16 +488,28 @@ void __init orion_gpio_init(int gpio_base, int ngpio,
writel(0, GPIO_EDGE_MASK(ochip));
writel(0, GPIO_LEVEL_MASK(ochip));
- gc = irq_alloc_generic_chip("orion_gpio_irq", 2, secondary_irq_base,
+ /* Setup the interrupt handlers. Each chip can have up to 4
+ * interrupt handlers, with each handler dealing with 8 GPIO
+ * pins. */
+
+ for (i = 0; i < 4; i++) {
+ if (irqs[i]) {
+ irq_set_handler_data(irqs[i], ochip);
+ irq_set_chained_handler(irqs[i], gpio_irq_handler);
+ }
+ }
+
+ gc = irq_alloc_generic_chip("orion_gpio_irq", 2,
+ secondary_irq_base,
ochip->base, handle_level_irq);
gc->private = ochip;
-
ct = gc->chip_types;
ct->regs.mask = ochip->mask_offset + GPIO_LEVEL_MASK_OFF;
ct->type = IRQ_TYPE_LEVEL_HIGH | IRQ_TYPE_LEVEL_LOW;
ct->chip.irq_mask = irq_gc_mask_clr_bit;
ct->chip.irq_unmask = irq_gc_mask_set_bit;
ct->chip.irq_set_type = gpio_irq_set_type;
+ ct->chip.name = ochip->chip.label;
ct++;
ct->regs.mask = ochip->mask_offset + GPIO_EDGE_MASK_OFF;
@@ -464,41 +520,69 @@ void __init orion_gpio_init(int gpio_base, int ngpio,
ct->chip.irq_unmask = irq_gc_mask_set_bit;
ct->chip.irq_set_type = gpio_irq_set_type;
ct->handler = handle_edge_irq;
+ ct->chip.name = ochip->chip.label;
irq_setup_generic_chip(gc, IRQ_MSK(ngpio), IRQ_GC_INIT_MASK_CACHE,
IRQ_NOREQUEST, IRQ_LEVEL | IRQ_NOPROBE);
-}
-void orion_gpio_irq_handler(int pinoff)
-{
- struct orion_gpio_chip *ochip;
- u32 cause, type;
- int i;
-
- ochip = orion_gpio_chip_find(pinoff);
- if (ochip == NULL)
- return;
-
- cause = readl(GPIO_DATA_IN(ochip)) & readl(GPIO_LEVEL_MASK(ochip));
- cause |= readl(GPIO_EDGE_CAUSE(ochip)) & readl(GPIO_EDGE_MASK(ochip));
-
- for (i = 0; i < ochip->chip.ngpio; i++) {
- int irq;
+ /* Setup irq domain on top of the generic chip. */
+ ochip->domain = irq_domain_add_legacy(np,
+ ochip->chip.ngpio,
+ ochip->secondary_irq_base,
+ ochip->secondary_irq_base,
+ &irq_domain_simple_ops,
+ ochip);
+ if (!ochip->domain)
+ panic("%s: couldn't allocate irq domain (DT).\n",
+ ochip->chip.label);
- irq = ochip->secondary_irq_base + i;
+ orion_gpio_chip_count++;
+}
- if (!(cause & (1 << i)))
- continue;
+#ifdef CONFIG_OF
+static void __init orion_gpio_of_init_one(struct device_node *np,
+ int irq_gpio_base)
+{
+ int ngpio, gpio_base, mask_offset;
+ void __iomem *base;
+ int ret, i;
+ int irqs[4];
+ int secondary_irq_base;
+
+ ret = of_property_read_u32(np, "ngpio", &ngpio);
+ if (ret)
+ goto out;
+ ret = of_property_read_u32(np, "mask-offset", &mask_offset);
+ if (ret == -EINVAL)
+ mask_offset = 0;
+ else
+ goto out;
+ base = of_iomap(np, 0);
+ if (!base)
+ goto out;
+
+ secondary_irq_base = irq_gpio_base + (32 * orion_gpio_chip_count);
+ gpio_base = 32 * orion_gpio_chip_count;
+
+ /* Get the interrupt numbers. Each chip can have up to 4
+ * interrupt handlers, with each handler dealing with 8 GPIO
+ * pins. */
+
+ for (i = 0; i < 4; i++)
+ irqs[i] = irq_of_parse_and_map(np, i);
+
+ orion_gpio_init(np, gpio_base, ngpio, base, mask_offset,
+ secondary_irq_base, irqs);
+ return;
+out:
+ pr_err("%s: %s: missing mandatory property\n", __func__, np->name);
+}
- type = irqd_get_trigger_type(irq_get_irq_data(irq));
- if ((type & IRQ_TYPE_SENSE_MASK) == IRQ_TYPE_EDGE_BOTH) {
- /* Swap polarity (race with GPIO line) */
- u32 polarity;
+void __init orion_gpio_of_init(int irq_gpio_base)
+{
+ struct device_node *np;
- polarity = readl(GPIO_IN_POL(ochip));
- polarity ^= 1 << i;
- writel(polarity, GPIO_IN_POL(ochip));
- }
- generic_handle_irq(irq);
- }
+ for_each_compatible_node(np, NULL, "marvell,orion-gpio")
+ orion_gpio_of_init_one(np, irq_gpio_base);
}
+#endif
diff --git a/arch/arm/plat-orion/include/plat/gpio.h b/arch/arm/plat-orion/include/plat/gpio.h
index bec0c98..81c6fc8 100644
--- a/arch/arm/plat-orion/include/plat/gpio.h
+++ b/arch/arm/plat-orion/include/plat/gpio.h
@@ -13,7 +13,7 @@
#include <linux/init.h>
#include <linux/types.h>
-
+#include <linux/irqdomain.h>
/*
* Orion-specific GPIO API extensions.
*/
@@ -27,13 +27,11 @@ int orion_gpio_led_blink_set(unsigned gpio, int state,
void orion_gpio_set_valid(unsigned pin, int mode);
/* Initialize gpiolib. */
-void __init orion_gpio_init(int gpio_base, int ngpio,
- u32 base, int mask_offset, int secondary_irq_base);
-
-/*
- * GPIO interrupt handling.
- */
-void orion_gpio_irq_handler(int irqoff);
-
+void __init orion_gpio_init(struct device_node *np,
+ int gpio_base, int ngpio,
+ void __iomem *base, int mask_offset,
+ int secondary_irq_base,
+ int irq[4]);
+void __init orion_gpio_of_init(int irq_gpio_base);
#endif
diff --git a/arch/arm/plat-orion/include/plat/irq.h b/arch/arm/plat-orion/include/plat/irq.h
index f05eeab..50547e4 100644
--- a/arch/arm/plat-orion/include/plat/irq.h
+++ b/arch/arm/plat-orion/include/plat/irq.h
@@ -12,6 +12,5 @@
#define __PLAT_IRQ_H
void orion_irq_init(unsigned int irq_start, void __iomem *maskaddr);
-
-
+void __init orion_dt_init_irq(void);
#endif
diff --git a/arch/arm/plat-orion/irq.c b/arch/arm/plat-orion/irq.c
index 2d5b9c1..d751964 100644
--- a/arch/arm/plat-orion/irq.c
+++ b/arch/arm/plat-orion/irq.c
@@ -11,8 +11,12 @@
#include <linux/kernel.h>
#include <linux/init.h>
#include <linux/irq.h>
+#include <linux/irqdomain.h>
#include <linux/io.h>
+#include <linux/of_address.h>
+#include <linux/of_irq.h>
#include <plat/irq.h>
+#include <plat/gpio.h>
void __init orion_irq_init(unsigned int irq_start, void __iomem *maskaddr)
{
@@ -32,3 +36,39 @@ void __init orion_irq_init(unsigned int irq_start, void __iomem *maskaddr)
irq_setup_generic_chip(gc, IRQ_MSK(32), IRQ_GC_INIT_MASK_CACHE,
IRQ_NOREQUEST, IRQ_LEVEL | IRQ_NOPROBE);
}
+
+#ifdef CONFIG_OF
+static int __init orion_add_irq_domain(struct device_node *np,
+ struct device_node *interrupt_parent)
+{
+ int i = 0, irq_gpio;
+ void __iomem *base;
+
+ do {
+ base = of_iomap(np, i);
+ if (base) {
+ orion_irq_init(i * 32, base);
+ i++;
+ }
+ } while (base);
+
+ irq_domain_add_legacy(np, i * 32, 0, 0,
+ &irq_domain_simple_ops, NULL);
+
+ irq_gpio = i * 32;
+ orion_gpio_of_init(irq_gpio);
+
+ return 0;
+}
+
+static const struct of_device_id orion_irq_match[] = {
+ { .compatible = "marvell,orion-intc",
+ .data = orion_add_irq_domain, },
+ {},
+};
+
+void __init orion_dt_init_irq(void)
+{
+ of_irq_init(orion_irq_match);
+}
+#endif
--
1.7.10
^ permalink raw reply related [flat|nested] 130+ messages in thread* [PATCH v2 01/12] ARM: Orion: DT support for IRQ and GPIO Controllers
2012-07-03 14:22 ` Andrew Lunn
(?)
@ 2012-07-05 8:15 ` Andrew Lunn
-1 siblings, 0 replies; 130+ messages in thread
From: Andrew Lunn @ 2012-07-05 8:15 UTC (permalink / raw)
To: linux-arm-kernel
Hi Rob, Arnd
It would be good if you could ACK, NACK, make comments on this patch.
Its the key patch which most other Orion DT patches build on, and i
would like to get this moving upstream, so allowing more DT conversion
for all Orion platforms.
Thanks
Andrew
On Tue, Jul 03, 2012 at 04:22:34PM +0200, Andrew Lunn wrote:
> Both IRQ and GPIO controllers can now be represented in DT. The IRQ
> controllers are setup first, and then the GPIO controllers. Interrupts
> for GPIO lines are placed directly after the main interrupts in the
> interrupt space.
>
> Signed-off-by: Andrew Lunn <andrew@lunn.ch>
> ---
> .../devicetree/bindings/arm/mrvl/intc.txt | 19 +++
> .../devicetree/bindings/gpio/mrvl-gpio.txt | 23 +++
> arch/arm/Kconfig | 1 +
> arch/arm/boot/dts/kirkwood.dtsi | 27 ++++
> arch/arm/mach-dove/irq.c | 58 +++----
> arch/arm/mach-kirkwood/board-dt.c | 3 +-
> arch/arm/mach-kirkwood/irq.c | 38 ++---
> arch/arm/mach-mv78xx0/irq.c | 22 +--
> arch/arm/mach-orion5x/irq.c | 22 +--
> arch/arm/plat-orion/gpio.c | 166 +++++++++++++++-----
> arch/arm/plat-orion/include/plat/gpio.h | 16 +-
> arch/arm/plat-orion/include/plat/irq.h | 3 +-
> arch/arm/plat-orion/irq.c | 40 +++++
> 13 files changed, 306 insertions(+), 132 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/arm/mrvl/intc.txt b/Documentation/devicetree/bindings/arm/mrvl/intc.txt
> index 80b9a94..8927e10 100644
> --- a/Documentation/devicetree/bindings/arm/mrvl/intc.txt
> +++ b/Documentation/devicetree/bindings/arm/mrvl/intc.txt
> @@ -38,3 +38,22 @@ Example:
> reg-names = "mux status", "mux mask";
> mrvl,intc-nr-irqs = <2>;
> };
> +
> +* Marvell Orion Interrupt controller
> +
> +Required properties
> +- compatible : Should be "marvell,orion-intc".
> +- #interrupt-cells: Specifies the number of cells needed to encode an
> + interrupt source. Supported value is <1>.
> +- interrupt-controller : Declare this node to be an interrupt controller.
> +- reg : Interrupt mask address.
> +
> +Example:
> +
> + intc: interrupt-controller {
> + compatible = "marvell,orion-intc", "marvell,intc";
> + interrupt-controller;
> + #interrupt-cells = <1>;
> + reg = <0xfed20204 0x04>,
> + <0xfed20214 0x04>;
> + };
> diff --git a/Documentation/devicetree/bindings/gpio/mrvl-gpio.txt b/Documentation/devicetree/bindings/gpio/mrvl-gpio.txt
> index 05428f3..e137874 100644
> --- a/Documentation/devicetree/bindings/gpio/mrvl-gpio.txt
> +++ b/Documentation/devicetree/bindings/gpio/mrvl-gpio.txt
> @@ -27,3 +27,26 @@ Example:
> interrupt-controller;
> #interrupt-cells = <1>;
> };
> +
> +* Marvell Orion GPIO Controller
> +
> +Required properties:
> +- compatible : Should be "marvell,orion-gpio"
> +- reg : Address and length of the register set for controller.
> +- gpio-controller : So we know this is a gpio controller.
> +- ngpio : How many gpios this controller has.
> +- interrupts : Up to 4 Interrupts for the controller.
> +
> +Optional properties:
> +- mask-offset : For SMP Orions, offset for Nth CPU
> +
> +Example:
> +
> + gpio0: gpio at 10100 {
> + compatible = "marvell,orion-gpio";
> + #gpio-cells = <2>;
> + gpio-controller;
> + reg = <0x10100 0x40>;
> + ngpio = <32>;
> + interrupts = <35>, <36>, <37>, <38>;
> + };
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index a91009c..39bb941 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -1105,6 +1105,7 @@ config PLAT_ORION
> bool
> select CLKSRC_MMIO
> select GENERIC_IRQ_CHIP
> + select IRQ_DOMAIN
> select COMMON_CLK
>
> config PLAT_PXA
> diff --git a/arch/arm/boot/dts/kirkwood.dtsi b/arch/arm/boot/dts/kirkwood.dtsi
> index 926528b..66544d7 100644
> --- a/arch/arm/boot/dts/kirkwood.dtsi
> +++ b/arch/arm/boot/dts/kirkwood.dtsi
> @@ -2,6 +2,15 @@
>
> / {
> compatible = "mrvl,kirkwood";
> + interrupt-parent = <&intc>;
> +
> + intc: interrupt-controller {
> + compatible = "marvell,orion-intc", "marvell,intc";
> + interrupt-controller;
> + #interrupt-cells = <1>;
> + reg = <0xf1020204 0x04>,
> + <0xf1020214 0x04>;
> + };
>
> ocp at f1000000 {
> compatible = "simple-bus";
> @@ -9,6 +18,24 @@
> #address-cells = <1>;
> #size-cells = <1>;
>
> + gpio0: gpio at 10100 {
> + compatible = "marvell,orion-gpio";
> + #gpio-cells = <2>;
> + gpio-controller;
> + reg = <0x10100 0x40>;
> + ngpio = <32>;
> + interrupts = <35>, <36>, <37>, <38>;
> + };
> +
> + gpio1: gpio at 10140 {
> + compatible = "marvell,orion-gpio";
> + #gpio-cells = <2>;
> + gpio-controller;
> + reg = <0x10140 0x40>;
> + ngpio = <18>;
> + interrupts = <39>, <40>, <41>;
> + };
> +
> serial at 12000 {
> compatible = "ns16550a";
> reg = <0x12000 0x100>;
> diff --git a/arch/arm/mach-dove/irq.c b/arch/arm/mach-dove/irq.c
> index f07fd16..9bc97a5 100644
> --- a/arch/arm/mach-dove/irq.c
> +++ b/arch/arm/mach-dove/irq.c
> @@ -20,22 +20,6 @@
> #include <mach/bridge-regs.h>
> #include "common.h"
>
> -static void gpio_irq_handler(unsigned int irq, struct irq_desc *desc)
> -{
> - int irqoff;
> - BUG_ON(irq < IRQ_DOVE_GPIO_0_7 || irq > IRQ_DOVE_HIGH_GPIO);
> -
> - irqoff = irq <= IRQ_DOVE_GPIO_16_23 ? irq - IRQ_DOVE_GPIO_0_7 :
> - 3 + irq - IRQ_DOVE_GPIO_24_31;
> -
> - orion_gpio_irq_handler(irqoff << 3);
> - if (irq == IRQ_DOVE_HIGH_GPIO) {
> - orion_gpio_irq_handler(40);
> - orion_gpio_irq_handler(48);
> - orion_gpio_irq_handler(56);
> - }
> -}
> -
> static void pmu_irq_mask(struct irq_data *d)
> {
> int pin = irq_to_pmu(d->irq);
> @@ -90,6 +74,27 @@ static void pmu_irq_handler(unsigned int irq, struct irq_desc *desc)
> }
> }
>
> +static int __initdata gpio0_irqs[4] = {
> + IRQ_DOVE_GPIO_0_7,
> + IRQ_DOVE_GPIO_8_15,
> + IRQ_DOVE_GPIO_16_23,
> + IRQ_DOVE_GPIO_24_31,
> +};
> +
> +static int __initdata gpio1_irqs[4] = {
> + IRQ_DOVE_HIGH_GPIO,
> + 0,
> + 0,
> + 0,
> +};
> +
> +static int __initdata gpio2_irqs[4] = {
> + 0,
> + 0,
> + 0,
> + 0,
> +};
> +
> void __init dove_init_irq(void)
> {
> int i;
> @@ -100,19 +105,14 @@ void __init dove_init_irq(void)
> /*
> * Initialize gpiolib for GPIOs 0-71.
> */
> - orion_gpio_init(0, 32, DOVE_GPIO_LO_VIRT_BASE, 0,
> - IRQ_DOVE_GPIO_START);
> - irq_set_chained_handler(IRQ_DOVE_GPIO_0_7, gpio_irq_handler);
> - irq_set_chained_handler(IRQ_DOVE_GPIO_8_15, gpio_irq_handler);
> - irq_set_chained_handler(IRQ_DOVE_GPIO_16_23, gpio_irq_handler);
> - irq_set_chained_handler(IRQ_DOVE_GPIO_24_31, gpio_irq_handler);
> -
> - orion_gpio_init(32, 32, DOVE_GPIO_HI_VIRT_BASE, 0,
> - IRQ_DOVE_GPIO_START + 32);
> - irq_set_chained_handler(IRQ_DOVE_HIGH_GPIO, gpio_irq_handler);
> -
> - orion_gpio_init(64, 8, DOVE_GPIO2_VIRT_BASE, 0,
> - IRQ_DOVE_GPIO_START + 64);
> + orion_gpio_init(NULL, 0, 32, (void __iomem *)DOVE_GPIO_LO_VIRT_BASE, 0,
> + IRQ_DOVE_GPIO_START, gpio0_irqs);
> +
> + orion_gpio_init(NULL, 32, 32, (void __iomem *)DOVE_GPIO_HI_VIRT_BASE, 0,
> + IRQ_DOVE_GPIO_START + 32, gpio1_irqs);
> +
> + orion_gpio_init(NULL, 64, 8, (void __iomem *)DOVE_GPIO2_VIRT_BASE, 0,
> + IRQ_DOVE_GPIO_START + 64, gpio2_irqs);
>
> /*
> * Mask and clear PMU interrupts
> diff --git a/arch/arm/mach-kirkwood/board-dt.c b/arch/arm/mach-kirkwood/board-dt.c
> index edc3f8a..27ac3d8 100644
> --- a/arch/arm/mach-kirkwood/board-dt.c
> +++ b/arch/arm/mach-kirkwood/board-dt.c
> @@ -18,6 +18,7 @@
> #include <asm/mach/arch.h>
> #include <asm/mach/map.h>
> #include <mach/bridge-regs.h>
> +#include <plat/irq.h>
> #include "common.h"
>
> static struct of_device_id kirkwood_dt_match_table[] __initdata = {
> @@ -84,7 +85,7 @@ DT_MACHINE_START(KIRKWOOD_DT, "Marvell Kirkwood (Flattened Device Tree)")
> /* Maintainer: Jason Cooper <jason@lakedaemon.net> */
> .map_io = kirkwood_map_io,
> .init_early = kirkwood_init_early,
> - .init_irq = kirkwood_init_irq,
> + .init_irq = orion_dt_init_irq,
> .timer = &kirkwood_timer,
> .init_machine = kirkwood_dt_init,
> .restart = kirkwood_restart,
> diff --git a/arch/arm/mach-kirkwood/irq.c b/arch/arm/mach-kirkwood/irq.c
> index c4c68e5..720063f 100644
> --- a/arch/arm/mach-kirkwood/irq.c
> +++ b/arch/arm/mach-kirkwood/irq.c
> @@ -9,20 +9,23 @@
> */
> #include <linux/gpio.h>
> #include <linux/kernel.h>
> -#include <linux/init.h>
> #include <linux/irq.h>
> -#include <linux/io.h>
> #include <mach/bridge-regs.h>
> #include <plat/irq.h>
> -#include "common.h"
>
> -static void gpio_irq_handler(unsigned int irq, struct irq_desc *desc)
> -{
> - BUG_ON(irq < IRQ_KIRKWOOD_GPIO_LOW_0_7);
> - BUG_ON(irq > IRQ_KIRKWOOD_GPIO_HIGH_16_23);
> +static int __initdata gpio0_irqs[4] = {
> + IRQ_KIRKWOOD_GPIO_LOW_0_7,
> + IRQ_KIRKWOOD_GPIO_LOW_8_15,
> + IRQ_KIRKWOOD_GPIO_LOW_16_23,
> + IRQ_KIRKWOOD_GPIO_LOW_24_31,
> +};
>
> - orion_gpio_irq_handler((irq - IRQ_KIRKWOOD_GPIO_LOW_0_7) << 3);
> -}
> +static int __initdata gpio1_irqs[4] = {
> + IRQ_KIRKWOOD_GPIO_HIGH_0_7,
> + IRQ_KIRKWOOD_GPIO_HIGH_8_15,
> + IRQ_KIRKWOOD_GPIO_HIGH_16_23,
> + 0,
> +};
>
> void __init kirkwood_init_irq(void)
> {
> @@ -32,17 +35,8 @@ void __init kirkwood_init_irq(void)
> /*
> * Initialize gpiolib for GPIOs 0-49.
> */
> - orion_gpio_init(0, 32, GPIO_LOW_VIRT_BASE, 0,
> - IRQ_KIRKWOOD_GPIO_START);
> - irq_set_chained_handler(IRQ_KIRKWOOD_GPIO_LOW_0_7, gpio_irq_handler);
> - irq_set_chained_handler(IRQ_KIRKWOOD_GPIO_LOW_8_15, gpio_irq_handler);
> - irq_set_chained_handler(IRQ_KIRKWOOD_GPIO_LOW_16_23, gpio_irq_handler);
> - irq_set_chained_handler(IRQ_KIRKWOOD_GPIO_LOW_24_31, gpio_irq_handler);
> -
> - orion_gpio_init(32, 18, GPIO_HIGH_VIRT_BASE, 0,
> - IRQ_KIRKWOOD_GPIO_START + 32);
> - irq_set_chained_handler(IRQ_KIRKWOOD_GPIO_HIGH_0_7, gpio_irq_handler);
> - irq_set_chained_handler(IRQ_KIRKWOOD_GPIO_HIGH_8_15, gpio_irq_handler);
> - irq_set_chained_handler(IRQ_KIRKWOOD_GPIO_HIGH_16_23,
> - gpio_irq_handler);
> + orion_gpio_init(NULL, 0, 32, (void __iomem *)GPIO_LOW_VIRT_BASE, 0,
> + IRQ_KIRKWOOD_GPIO_START, gpio0_irqs);
> + orion_gpio_init(NULL, 32, 18, (void __iomem *)GPIO_HIGH_VIRT_BASE, 0,
> + IRQ_KIRKWOOD_GPIO_START + 32, gpio1_irqs);
> }
> diff --git a/arch/arm/mach-mv78xx0/irq.c b/arch/arm/mach-mv78xx0/irq.c
> index e421b70..eff9a75 100644
> --- a/arch/arm/mach-mv78xx0/irq.c
> +++ b/arch/arm/mach-mv78xx0/irq.c
> @@ -9,19 +9,17 @@
> */
> #include <linux/gpio.h>
> #include <linux/kernel.h>
> -#include <linux/init.h>
> -#include <linux/pci.h>
> #include <linux/irq.h>
> #include <mach/bridge-regs.h>
> #include <plat/irq.h>
> #include "common.h"
>
> -static void gpio_irq_handler(unsigned int irq, struct irq_desc *desc)
> -{
> - BUG_ON(irq < IRQ_MV78XX0_GPIO_0_7 || irq > IRQ_MV78XX0_GPIO_24_31);
> -
> - orion_gpio_irq_handler((irq - IRQ_MV78XX0_GPIO_0_7) << 3);
> -}
> +static int __initdata gpio0_irqs[4] = {
> + IRQ_MV78XX0_GPIO_0_7,
> + IRQ_MV78XX0_GPIO_8_15,
> + IRQ_MV78XX0_GPIO_16_23,
> + IRQ_MV78XX0_GPIO_24_31,
> +};
>
> void __init mv78xx0_init_irq(void)
> {
> @@ -34,11 +32,7 @@ void __init mv78xx0_init_irq(void)
> * registers for core #1 are at an offset of 0x18 from those of
> * core #0.)
> */
> - orion_gpio_init(0, 32, GPIO_VIRT_BASE,
> + orion_gpio_init(NULL, 0, 32, (void __iomem *)GPIO_VIRT_BASE,
> mv78xx0_core_index() ? 0x18 : 0,
> - IRQ_MV78XX0_GPIO_START);
> - irq_set_chained_handler(IRQ_MV78XX0_GPIO_0_7, gpio_irq_handler);
> - irq_set_chained_handler(IRQ_MV78XX0_GPIO_8_15, gpio_irq_handler);
> - irq_set_chained_handler(IRQ_MV78XX0_GPIO_16_23, gpio_irq_handler);
> - irq_set_chained_handler(IRQ_MV78XX0_GPIO_24_31, gpio_irq_handler);
> + IRQ_MV78XX0_GPIO_START, gpio0_irqs);
> }
> diff --git a/arch/arm/mach-orion5x/irq.c b/arch/arm/mach-orion5x/irq.c
> index b1b45ff..17da709 100644
> --- a/arch/arm/mach-orion5x/irq.c
> +++ b/arch/arm/mach-orion5x/irq.c
> @@ -11,19 +11,16 @@
> */
> #include <linux/gpio.h>
> #include <linux/kernel.h>
> -#include <linux/init.h>
> #include <linux/irq.h>
> -#include <linux/io.h>
> #include <mach/bridge-regs.h>
> #include <plat/irq.h>
> -#include "common.h"
>
> -static void gpio_irq_handler(unsigned int irq, struct irq_desc *desc)
> -{
> - BUG_ON(irq < IRQ_ORION5X_GPIO_0_7 || irq > IRQ_ORION5X_GPIO_24_31);
> -
> - orion_gpio_irq_handler((irq - IRQ_ORION5X_GPIO_0_7) << 3);
> -}
> +static int __initdata gpio0_irqs[4] = {
> + IRQ_ORION5X_GPIO_0_7,
> + IRQ_ORION5X_GPIO_8_15,
> + IRQ_ORION5X_GPIO_16_23,
> + IRQ_ORION5X_GPIO_24_31,
> +};
>
> void __init orion5x_init_irq(void)
> {
> @@ -32,9 +29,6 @@ void __init orion5x_init_irq(void)
> /*
> * Initialize gpiolib for GPIOs 0-31.
> */
> - orion_gpio_init(0, 32, GPIO_VIRT_BASE, 0, IRQ_ORION5X_GPIO_START);
> - irq_set_chained_handler(IRQ_ORION5X_GPIO_0_7, gpio_irq_handler);
> - irq_set_chained_handler(IRQ_ORION5X_GPIO_8_15, gpio_irq_handler);
> - irq_set_chained_handler(IRQ_ORION5X_GPIO_16_23, gpio_irq_handler);
> - irq_set_chained_handler(IRQ_ORION5X_GPIO_24_31, gpio_irq_handler);
> + orion_gpio_init(NULL, 0, 32, (void __iomem *)GPIO_VIRT_BASE, 0,
> + IRQ_ORION5X_GPIO_START, gpio0_irqs);
> }
> diff --git a/arch/arm/plat-orion/gpio.c b/arch/arm/plat-orion/gpio.c
> index af95af2..dfda74f 100644
> --- a/arch/arm/plat-orion/gpio.c
> +++ b/arch/arm/plat-orion/gpio.c
> @@ -8,15 +8,22 @@
> * warranty of any kind, whether express or implied.
> */
>
> +#define DEBUG
> +
> #include <linux/kernel.h>
> #include <linux/init.h>
> #include <linux/irq.h>
> +#include <linux/irqdomain.h>
> #include <linux/module.h>
> #include <linux/spinlock.h>
> #include <linux/bitops.h>
> #include <linux/io.h>
> #include <linux/gpio.h>
> #include <linux/leds.h>
> +#include <linux/of.h>
> +#include <linux/of_irq.h>
> +#include <linux/of_address.h>
> +#include <plat/gpio.h>
>
> /*
> * GPIO unit register offsets.
> @@ -38,6 +45,7 @@ struct orion_gpio_chip {
> unsigned long valid_output;
> int mask_offset;
> int secondary_irq_base;
> + struct irq_domain *domain;
> };
>
> static void __iomem *GPIO_OUT(struct orion_gpio_chip *ochip)
> @@ -222,10 +230,10 @@ static int orion_gpio_to_irq(struct gpio_chip *chip, unsigned pin)
> struct orion_gpio_chip *ochip =
> container_of(chip, struct orion_gpio_chip, chip);
>
> - return ochip->secondary_irq_base + pin;
> + return irq_create_mapping(ochip->domain,
> + ochip->secondary_irq_base + pin);
> }
>
> -
> /*
> * Orion-specific GPIO API extensions.
> */
> @@ -353,12 +361,10 @@ static int gpio_irq_set_type(struct irq_data *d, u32 type)
> int pin;
> u32 u;
>
> - pin = d->irq - gc->irq_base;
> + pin = d->hwirq - ochip->secondary_irq_base;
>
> u = readl(GPIO_IO_CONF(ochip)) & (1 << pin);
> if (!u) {
> - printk(KERN_ERR "orion gpio_irq_set_type failed "
> - "(irq %d, pin %d).\n", d->irq, pin);
> return -EINVAL;
> }
>
> @@ -397,17 +403,53 @@ static int gpio_irq_set_type(struct irq_data *d, u32 type)
> u &= ~(1 << pin); /* rising */
> writel(u, GPIO_IN_POL(ochip));
> }
> -
> return 0;
> }
>
> -void __init orion_gpio_init(int gpio_base, int ngpio,
> - u32 base, int mask_offset, int secondary_irq_base)
> +static void gpio_irq_handler(unsigned irq, struct irq_desc *desc)
> +{
> + struct orion_gpio_chip *ochip = irq_get_handler_data(irq);
> + u32 cause, type;
> + int i;
> +
> + if (ochip == NULL)
> + return;
> +
> + cause = readl(GPIO_DATA_IN(ochip)) & readl(GPIO_LEVEL_MASK(ochip));
> + cause |= readl(GPIO_EDGE_CAUSE(ochip)) & readl(GPIO_EDGE_MASK(ochip));
> +
> + for (i = 0; i < ochip->chip.ngpio; i++) {
> + int irq;
> +
> + irq = ochip->secondary_irq_base + i;
> +
> + if (!(cause & (1 << i)))
> + continue;
> +
> + type = irqd_get_trigger_type(irq_get_irq_data(irq));
> + if ((type & IRQ_TYPE_SENSE_MASK) == IRQ_TYPE_EDGE_BOTH) {
> + /* Swap polarity (race with GPIO line) */
> + u32 polarity;
> +
> + polarity = readl(GPIO_IN_POL(ochip));
> + polarity ^= 1 << i;
> + writel(polarity, GPIO_IN_POL(ochip));
> + }
> + generic_handle_irq(irq);
> + }
> +}
> +
> +void __init orion_gpio_init(struct device_node *np,
> + int gpio_base, int ngpio,
> + void __iomem *base, int mask_offset,
> + int secondary_irq_base,
> + int irqs[4])
> {
> struct orion_gpio_chip *ochip;
> struct irq_chip_generic *gc;
> struct irq_chip_type *ct;
> char gc_label[16];
> + int i;
>
> if (orion_gpio_chip_count == ARRAY_SIZE(orion_gpio_chips))
> return;
> @@ -426,6 +468,10 @@ void __init orion_gpio_init(int gpio_base, int ngpio,
> ochip->chip.base = gpio_base;
> ochip->chip.ngpio = ngpio;
> ochip->chip.can_sleep = 0;
> +#ifdef CONFIG_OF
> + ochip->chip.of_node = np;
> +#endif
> +
> spin_lock_init(&ochip->lock);
> ochip->base = (void __iomem *)base;
> ochip->valid_input = 0;
> @@ -435,8 +481,6 @@ void __init orion_gpio_init(int gpio_base, int ngpio,
>
> gpiochip_add(&ochip->chip);
>
> - orion_gpio_chip_count++;
> -
> /*
> * Mask and clear GPIO interrupts.
> */
> @@ -444,16 +488,28 @@ void __init orion_gpio_init(int gpio_base, int ngpio,
> writel(0, GPIO_EDGE_MASK(ochip));
> writel(0, GPIO_LEVEL_MASK(ochip));
>
> - gc = irq_alloc_generic_chip("orion_gpio_irq", 2, secondary_irq_base,
> + /* Setup the interrupt handlers. Each chip can have up to 4
> + * interrupt handlers, with each handler dealing with 8 GPIO
> + * pins. */
> +
> + for (i = 0; i < 4; i++) {
> + if (irqs[i]) {
> + irq_set_handler_data(irqs[i], ochip);
> + irq_set_chained_handler(irqs[i], gpio_irq_handler);
> + }
> + }
> +
> + gc = irq_alloc_generic_chip("orion_gpio_irq", 2,
> + secondary_irq_base,
> ochip->base, handle_level_irq);
> gc->private = ochip;
> -
> ct = gc->chip_types;
> ct->regs.mask = ochip->mask_offset + GPIO_LEVEL_MASK_OFF;
> ct->type = IRQ_TYPE_LEVEL_HIGH | IRQ_TYPE_LEVEL_LOW;
> ct->chip.irq_mask = irq_gc_mask_clr_bit;
> ct->chip.irq_unmask = irq_gc_mask_set_bit;
> ct->chip.irq_set_type = gpio_irq_set_type;
> + ct->chip.name = ochip->chip.label;
>
> ct++;
> ct->regs.mask = ochip->mask_offset + GPIO_EDGE_MASK_OFF;
> @@ -464,41 +520,69 @@ void __init orion_gpio_init(int gpio_base, int ngpio,
> ct->chip.irq_unmask = irq_gc_mask_set_bit;
> ct->chip.irq_set_type = gpio_irq_set_type;
> ct->handler = handle_edge_irq;
> + ct->chip.name = ochip->chip.label;
>
> irq_setup_generic_chip(gc, IRQ_MSK(ngpio), IRQ_GC_INIT_MASK_CACHE,
> IRQ_NOREQUEST, IRQ_LEVEL | IRQ_NOPROBE);
> -}
>
> -void orion_gpio_irq_handler(int pinoff)
> -{
> - struct orion_gpio_chip *ochip;
> - u32 cause, type;
> - int i;
> -
> - ochip = orion_gpio_chip_find(pinoff);
> - if (ochip == NULL)
> - return;
> -
> - cause = readl(GPIO_DATA_IN(ochip)) & readl(GPIO_LEVEL_MASK(ochip));
> - cause |= readl(GPIO_EDGE_CAUSE(ochip)) & readl(GPIO_EDGE_MASK(ochip));
> -
> - for (i = 0; i < ochip->chip.ngpio; i++) {
> - int irq;
> + /* Setup irq domain on top of the generic chip. */
> + ochip->domain = irq_domain_add_legacy(np,
> + ochip->chip.ngpio,
> + ochip->secondary_irq_base,
> + ochip->secondary_irq_base,
> + &irq_domain_simple_ops,
> + ochip);
> + if (!ochip->domain)
> + panic("%s: couldn't allocate irq domain (DT).\n",
> + ochip->chip.label);
>
> - irq = ochip->secondary_irq_base + i;
> + orion_gpio_chip_count++;
> +}
>
> - if (!(cause & (1 << i)))
> - continue;
> +#ifdef CONFIG_OF
> +static void __init orion_gpio_of_init_one(struct device_node *np,
> + int irq_gpio_base)
> +{
> + int ngpio, gpio_base, mask_offset;
> + void __iomem *base;
> + int ret, i;
> + int irqs[4];
> + int secondary_irq_base;
> +
> + ret = of_property_read_u32(np, "ngpio", &ngpio);
> + if (ret)
> + goto out;
> + ret = of_property_read_u32(np, "mask-offset", &mask_offset);
> + if (ret == -EINVAL)
> + mask_offset = 0;
> + else
> + goto out;
> + base = of_iomap(np, 0);
> + if (!base)
> + goto out;
> +
> + secondary_irq_base = irq_gpio_base + (32 * orion_gpio_chip_count);
> + gpio_base = 32 * orion_gpio_chip_count;
> +
> + /* Get the interrupt numbers. Each chip can have up to 4
> + * interrupt handlers, with each handler dealing with 8 GPIO
> + * pins. */
> +
> + for (i = 0; i < 4; i++)
> + irqs[i] = irq_of_parse_and_map(np, i);
> +
> + orion_gpio_init(np, gpio_base, ngpio, base, mask_offset,
> + secondary_irq_base, irqs);
> + return;
> +out:
> + pr_err("%s: %s: missing mandatory property\n", __func__, np->name);
> +}
>
> - type = irqd_get_trigger_type(irq_get_irq_data(irq));
> - if ((type & IRQ_TYPE_SENSE_MASK) == IRQ_TYPE_EDGE_BOTH) {
> - /* Swap polarity (race with GPIO line) */
> - u32 polarity;
> +void __init orion_gpio_of_init(int irq_gpio_base)
> +{
> + struct device_node *np;
>
> - polarity = readl(GPIO_IN_POL(ochip));
> - polarity ^= 1 << i;
> - writel(polarity, GPIO_IN_POL(ochip));
> - }
> - generic_handle_irq(irq);
> - }
> + for_each_compatible_node(np, NULL, "marvell,orion-gpio")
> + orion_gpio_of_init_one(np, irq_gpio_base);
> }
> +#endif
> diff --git a/arch/arm/plat-orion/include/plat/gpio.h b/arch/arm/plat-orion/include/plat/gpio.h
> index bec0c98..81c6fc8 100644
> --- a/arch/arm/plat-orion/include/plat/gpio.h
> +++ b/arch/arm/plat-orion/include/plat/gpio.h
> @@ -13,7 +13,7 @@
>
> #include <linux/init.h>
> #include <linux/types.h>
> -
> +#include <linux/irqdomain.h>
> /*
> * Orion-specific GPIO API extensions.
> */
> @@ -27,13 +27,11 @@ int orion_gpio_led_blink_set(unsigned gpio, int state,
> void orion_gpio_set_valid(unsigned pin, int mode);
>
> /* Initialize gpiolib. */
> -void __init orion_gpio_init(int gpio_base, int ngpio,
> - u32 base, int mask_offset, int secondary_irq_base);
> -
> -/*
> - * GPIO interrupt handling.
> - */
> -void orion_gpio_irq_handler(int irqoff);
> -
> +void __init orion_gpio_init(struct device_node *np,
> + int gpio_base, int ngpio,
> + void __iomem *base, int mask_offset,
> + int secondary_irq_base,
> + int irq[4]);
>
> +void __init orion_gpio_of_init(int irq_gpio_base);
> #endif
> diff --git a/arch/arm/plat-orion/include/plat/irq.h b/arch/arm/plat-orion/include/plat/irq.h
> index f05eeab..50547e4 100644
> --- a/arch/arm/plat-orion/include/plat/irq.h
> +++ b/arch/arm/plat-orion/include/plat/irq.h
> @@ -12,6 +12,5 @@
> #define __PLAT_IRQ_H
>
> void orion_irq_init(unsigned int irq_start, void __iomem *maskaddr);
> -
> -
> +void __init orion_dt_init_irq(void);
> #endif
> diff --git a/arch/arm/plat-orion/irq.c b/arch/arm/plat-orion/irq.c
> index 2d5b9c1..d751964 100644
> --- a/arch/arm/plat-orion/irq.c
> +++ b/arch/arm/plat-orion/irq.c
> @@ -11,8 +11,12 @@
> #include <linux/kernel.h>
> #include <linux/init.h>
> #include <linux/irq.h>
> +#include <linux/irqdomain.h>
> #include <linux/io.h>
> +#include <linux/of_address.h>
> +#include <linux/of_irq.h>
> #include <plat/irq.h>
> +#include <plat/gpio.h>
>
> void __init orion_irq_init(unsigned int irq_start, void __iomem *maskaddr)
> {
> @@ -32,3 +36,39 @@ void __init orion_irq_init(unsigned int irq_start, void __iomem *maskaddr)
> irq_setup_generic_chip(gc, IRQ_MSK(32), IRQ_GC_INIT_MASK_CACHE,
> IRQ_NOREQUEST, IRQ_LEVEL | IRQ_NOPROBE);
> }
> +
> +#ifdef CONFIG_OF
> +static int __init orion_add_irq_domain(struct device_node *np,
> + struct device_node *interrupt_parent)
> +{
> + int i = 0, irq_gpio;
> + void __iomem *base;
> +
> + do {
> + base = of_iomap(np, i);
> + if (base) {
> + orion_irq_init(i * 32, base);
> + i++;
> + }
> + } while (base);
> +
> + irq_domain_add_legacy(np, i * 32, 0, 0,
> + &irq_domain_simple_ops, NULL);
> +
> + irq_gpio = i * 32;
> + orion_gpio_of_init(irq_gpio);
> +
> + return 0;
> +}
> +
> +static const struct of_device_id orion_irq_match[] = {
> + { .compatible = "marvell,orion-intc",
> + .data = orion_add_irq_domain, },
> + {},
> +};
> +
> +void __init orion_dt_init_irq(void)
> +{
> + of_irq_init(orion_irq_match);
> +}
> +#endif
> --
> 1.7.10
>
^ permalink raw reply [flat|nested] 130+ messages in thread[parent not found: <1341325365-21393-2-git-send-email-andrew-g2DYL2Zd6BY@public.gmane.org>]
* Re: [PATCH v2 01/12] ARM: Orion: DT support for IRQ and GPIO Controllers
2012-07-03 14:22 ` Andrew Lunn
@ 2012-07-05 9:02 ` Thomas Petazzoni
-1 siblings, 0 replies; 130+ messages in thread
From: Thomas Petazzoni @ 2012-07-05 9:02 UTC (permalink / raw)
To: Andrew Lunn
Cc: Lior Amsalem, Jason Cooper,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
rob.herring-bsGFqQB8/DxBDgjK7y7TUQ, Maen Suleiman, Michael Walle,
linux-i2c-u79uwXL29TY76Z2rM5mHXA,
spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Hello Andrew,
Le Tue, 3 Jul 2012 16:22:34 +0200,
Andrew Lunn <andrew@lunn.ch> a écrit :
> Both IRQ and GPIO controllers can now be represented in DT. The IRQ
> controllers are setup first, and then the GPIO controllers. Interrupts
> for GPIO lines are placed directly after the main interrupts in the
> interrupt space.
>
> Signed-off-by: Andrew Lunn <andrew@lunn.ch>
I have started working on a pinctrl driver for mvebu, which would
handle pin muxing (MPP) + gpio + gpio interrupts.
So far, the pin muxing part is working (needs some polishing, but the
foundation is here), with device tree bindings. I think the pin muxing
could be used for Orion as well.
Now, I'm planning to start working on the gpio + gpio interrupts parts
of the driver, and I'm wondering how to interact with your work on the
matter. My understanding is that the new way of doing a pinmux+gpio
driver is to implement it in drivers/pinctrl/, which I have started
doing.
Should I continue working on a drivers/pinctrl/ driver for mvebu for
Armada 370/XP, and then we see together if it makes sense to extend to
Orion, and if so, what changes are needed?
Thanks,
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general
^ permalink raw reply [flat|nested] 130+ messages in thread
* [PATCH v2 01/12] ARM: Orion: DT support for IRQ and GPIO Controllers
@ 2012-07-05 9:02 ` Thomas Petazzoni
0 siblings, 0 replies; 130+ messages in thread
From: Thomas Petazzoni @ 2012-07-05 9:02 UTC (permalink / raw)
To: linux-arm-kernel
Hello Andrew,
Le Tue, 3 Jul 2012 16:22:34 +0200,
Andrew Lunn <andrew@lunn.ch> a ?crit :
> Both IRQ and GPIO controllers can now be represented in DT. The IRQ
> controllers are setup first, and then the GPIO controllers. Interrupts
> for GPIO lines are placed directly after the main interrupts in the
> interrupt space.
>
> Signed-off-by: Andrew Lunn <andrew@lunn.ch>
I have started working on a pinctrl driver for mvebu, which would
handle pin muxing (MPP) + gpio + gpio interrupts.
So far, the pin muxing part is working (needs some polishing, but the
foundation is here), with device tree bindings. I think the pin muxing
could be used for Orion as well.
Now, I'm planning to start working on the gpio + gpio interrupts parts
of the driver, and I'm wondering how to interact with your work on the
matter. My understanding is that the new way of doing a pinmux+gpio
driver is to implement it in drivers/pinctrl/, which I have started
doing.
Should I continue working on a drivers/pinctrl/ driver for mvebu for
Armada 370/XP, and then we see together if it makes sense to extend to
Orion, and if so, what changes are needed?
Thanks,
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: [PATCH v2 01/12] ARM: Orion: DT support for IRQ and GPIO Controllers
2012-07-05 9:02 ` Thomas Petazzoni
@ 2012-07-05 9:48 ` Andrew Lunn
-1 siblings, 0 replies; 130+ messages in thread
From: Andrew Lunn @ 2012-07-05 9:48 UTC (permalink / raw)
To: Thomas Petazzoni
Cc: Andrew Lunn, Jason Cooper,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
rob.herring-bsGFqQB8/DxBDgjK7y7TUQ,
grant.likely-s3s/WqlpOiPyB63q8FvJNQ, Michael Walle,
linux-i2c-u79uwXL29TY76Z2rM5mHXA,
spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Lior Amsalem,
Maen Suleiman
On Thu, Jul 05, 2012 at 11:02:51AM +0200, Thomas Petazzoni wrote:
> Hello Andrew,
>
> Le Tue, 3 Jul 2012 16:22:34 +0200,
> Andrew Lunn <andrew-g2DYL2Zd6BY@public.gmane.org> a ??crit :
>
> > Both IRQ and GPIO controllers can now be represented in DT. The IRQ
> > controllers are setup first, and then the GPIO controllers. Interrupts
> > for GPIO lines are placed directly after the main interrupts in the
> > interrupt space.
> >
> > Signed-off-by: Andrew Lunn <andrew-g2DYL2Zd6BY@public.gmane.org>
>
> I have started working on a pinctrl driver for mvebu, which would
> handle pin muxing (MPP) + gpio + gpio interrupts.
Hi Thomas
You are not the only one working in this area. Arnaud Patard said he
was look at this as well.
> So far, the pin muxing part is working (needs some polishing, but the
> foundation is here), with device tree bindings. I think the pin muxing
> could be used for Orion as well.
Great. This is one of the big things which we are missing when moving
a system over the DT. Being able to describe this in DT in a
standardized way is very much welcome.
> Now, I'm planning to start working on the gpio + gpio interrupts parts
> of the driver, and I'm wondering how to interact with your work on the
> matter.
I've publicly said, what i have is enough to get it working, but i
know its not the end solution. What i have is enough that gpio-key,
gpio-led, as described in DT, works. Boards can start using these and
as far as i can tell, the binding should not need to change. The GPIO
controller binding should also be sufficiently generic that it should
also not need changes when we replace the driver with pinctrl.
The biggest problem i had, is the interaction between generic chip
interrupts and irqdomain. There has been work to integrate the two,
but its stalled. Either the work needs restarting and completing, or
you need to throw away the use of generic interrupt so that you can
use irqdomain linear. IMHO, throwing away generic interrupt is the
wrong way.
The other thing you need to keep in mind is the namespace issues
between normal interrupts and GPIO interrupts. The way my patch works
is that normal interrupts are setup first, counting how many have been
created. Then GPIO interrupts are added, starting off where the normal
interrupts ended. Since 370/XP uses different interrupt code, you need
to think how to solve this issue.
> My understanding is that the new way of doing a pinmux+gpio
> driver is to implement it in drivers/pinctrl/, which I have started
> doing.
Great.
> Should I continue working on a drivers/pinctrl/ driver for mvebu for
> Armada 370/XP, and then we see together if it makes sense to extend to
> Orion, and if so, what changes are needed?
I know Marvell has contracted you to port to Armada 370/XP, not mvebu,
aka all chips which might be able to share this code. This IMHO is
wrong. So i personally would put the kirkwood and the Armada 370/XP
data sheets next to each other, and from the beginning on write the
driver so it supports them all. This assumes the ASIC engineers have
not radically changed anything... Please also try to stick to the DT
binding i've used.
If however, you have to focus solely on Armada 370/XP, then the
community can work on making your code generic at a late date.
Andrew
^ permalink raw reply [flat|nested] 130+ messages in thread
* [PATCH v2 01/12] ARM: Orion: DT support for IRQ and GPIO Controllers
@ 2012-07-05 9:48 ` Andrew Lunn
0 siblings, 0 replies; 130+ messages in thread
From: Andrew Lunn @ 2012-07-05 9:48 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Jul 05, 2012 at 11:02:51AM +0200, Thomas Petazzoni wrote:
> Hello Andrew,
>
> Le Tue, 3 Jul 2012 16:22:34 +0200,
> Andrew Lunn <andrew@lunn.ch> a ??crit :
>
> > Both IRQ and GPIO controllers can now be represented in DT. The IRQ
> > controllers are setup first, and then the GPIO controllers. Interrupts
> > for GPIO lines are placed directly after the main interrupts in the
> > interrupt space.
> >
> > Signed-off-by: Andrew Lunn <andrew@lunn.ch>
>
> I have started working on a pinctrl driver for mvebu, which would
> handle pin muxing (MPP) + gpio + gpio interrupts.
Hi Thomas
You are not the only one working in this area. Arnaud Patard said he
was look at this as well.
> So far, the pin muxing part is working (needs some polishing, but the
> foundation is here), with device tree bindings. I think the pin muxing
> could be used for Orion as well.
Great. This is one of the big things which we are missing when moving
a system over the DT. Being able to describe this in DT in a
standardized way is very much welcome.
> Now, I'm planning to start working on the gpio + gpio interrupts parts
> of the driver, and I'm wondering how to interact with your work on the
> matter.
I've publicly said, what i have is enough to get it working, but i
know its not the end solution. What i have is enough that gpio-key,
gpio-led, as described in DT, works. Boards can start using these and
as far as i can tell, the binding should not need to change. The GPIO
controller binding should also be sufficiently generic that it should
also not need changes when we replace the driver with pinctrl.
The biggest problem i had, is the interaction between generic chip
interrupts and irqdomain. There has been work to integrate the two,
but its stalled. Either the work needs restarting and completing, or
you need to throw away the use of generic interrupt so that you can
use irqdomain linear. IMHO, throwing away generic interrupt is the
wrong way.
The other thing you need to keep in mind is the namespace issues
between normal interrupts and GPIO interrupts. The way my patch works
is that normal interrupts are setup first, counting how many have been
created. Then GPIO interrupts are added, starting off where the normal
interrupts ended. Since 370/XP uses different interrupt code, you need
to think how to solve this issue.
> My understanding is that the new way of doing a pinmux+gpio
> driver is to implement it in drivers/pinctrl/, which I have started
> doing.
Great.
> Should I continue working on a drivers/pinctrl/ driver for mvebu for
> Armada 370/XP, and then we see together if it makes sense to extend to
> Orion, and if so, what changes are needed?
I know Marvell has contracted you to port to Armada 370/XP, not mvebu,
aka all chips which might be able to share this code. This IMHO is
wrong. So i personally would put the kirkwood and the Armada 370/XP
data sheets next to each other, and from the beginning on write the
driver so it supports them all. This assumes the ASIC engineers have
not radically changed anything... Please also try to stick to the DT
binding i've used.
If however, you have to focus solely on Armada 370/XP, then the
community can work on making your code generic at a late date.
Andrew
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: [PATCH v2 01/12] ARM: Orion: DT support for IRQ and GPIO Controllers
2012-07-05 9:48 ` Andrew Lunn
@ 2012-07-05 10:11 ` Arnaud Patard (Rtp)
-1 siblings, 0 replies; 130+ messages in thread
From: Arnaud Patard @ 2012-07-05 10:11 UTC (permalink / raw)
To: Thomas Petazzoni
Cc: Lior Amsalem, Andrew Lunn, Jason Cooper, devicetree-discuss,
rob.herring, grant.likely, Maen Suleiman, Michael Walle,
linux-i2c, spi-devel-general, linux-arm-kernel
Andrew Lunn <andrew@lunn.ch> writes:
Hi,
> On Thu, Jul 05, 2012 at 11:02:51AM +0200, Thomas Petazzoni wrote:
>> Hello Andrew,
>>
>> Le Tue, 3 Jul 2012 16:22:34 +0200,
>> Andrew Lunn <andrew@lunn.ch> a ??crit :
>>
>> > Both IRQ and GPIO controllers can now be represented in DT. The IRQ
>> > controllers are setup first, and then the GPIO controllers. Interrupts
>> > for GPIO lines are placed directly after the main interrupts in the
>> > interrupt space.
>> >
>> > Signed-off-by: Andrew Lunn <andrew@lunn.ch>
>>
>> I have started working on a pinctrl driver for mvebu, which would
>> handle pin muxing (MPP) + gpio + gpio interrupts.
>
> Hi Thomas
>
> You are not the only one working in this area. Arnaud Patard said he
> was look at this as well.
yeah, but tbh I've not made anything yet. If Thomas has already some
code for it, we should try to make it "generic" so as to use it on
armada xp and orion platforms.
>
>> So far, the pin muxing part is working (needs some polishing, but the
>> foundation is here), with device tree bindings. I think the pin muxing
>> could be used for Orion as well.
>
> Great. This is one of the big things which we are missing when moving
> a system over the DT. Being able to describe this in DT in a
> standardized way is very much welcome.
>
>> Now, I'm planning to start working on the gpio + gpio interrupts parts
>> of the driver, and I'm wondering how to interact with your work on the
>> matter.
>
> I've publicly said, what i have is enough to get it working, but i
> know its not the end solution. What i have is enough that gpio-key,
> gpio-led, as described in DT, works. Boards can start using these and
> as far as i can tell, the binding should not need to change. The GPIO
> controller binding should also be sufficiently generic that it should
> also not need changes when we replace the driver with pinctrl.
>
> The biggest problem i had, is the interaction between generic chip
> interrupts and irqdomain. There has been work to integrate the two,
> but its stalled. Either the work needs restarting and completing, or
> you need to throw away the use of generic interrupt so that you can
> use irqdomain linear. IMHO, throwing away generic interrupt is the
> wrong way.
>
> The other thing you need to keep in mind is the namespace issues
> between normal interrupts and GPIO interrupts. The way my patch works
> is that normal interrupts are setup first, counting how many have been
> created. Then GPIO interrupts are added, starting off where the normal
> interrupts ended. Since 370/XP uses different interrupt code, you need
> to think how to solve this issue.
>
>> My understanding is that the new way of doing a pinmux+gpio
>> driver is to implement it in drivers/pinctrl/, which I have started
>> doing.
>
> Great.
>
>> Should I continue working on a drivers/pinctrl/ driver for mvebu for
>> Armada 370/XP, and then we see together if it makes sense to extend to
>> Orion, and if so, what changes are needed?
>
> I know Marvell has contracted you to port to Armada 370/XP, not mvebu,
> aka all chips which might be able to share this code. This IMHO is
> wrong. So i personally would put the kirkwood and the Armada 370/XP
> data sheets next to each other, and from the beginning on write the
> driver so it supports them all. This assumes the ASIC engineers have
> not radically changed anything... Please also try to stick to the DT
> binding i've used.
agreed. it should be written with all platforms in mind, as long as
they're compatible. It can only make things better imho.
Arnaud
^ permalink raw reply [flat|nested] 130+ messages in thread
* [PATCH v2 01/12] ARM: Orion: DT support for IRQ and GPIO Controllers
@ 2012-07-05 10:11 ` Arnaud Patard (Rtp)
0 siblings, 0 replies; 130+ messages in thread
From: Arnaud Patard (Rtp) @ 2012-07-05 10:11 UTC (permalink / raw)
To: linux-arm-kernel
Andrew Lunn <andrew@lunn.ch> writes:
Hi,
> On Thu, Jul 05, 2012 at 11:02:51AM +0200, Thomas Petazzoni wrote:
>> Hello Andrew,
>>
>> Le Tue, 3 Jul 2012 16:22:34 +0200,
>> Andrew Lunn <andrew@lunn.ch> a ??crit :
>>
>> > Both IRQ and GPIO controllers can now be represented in DT. The IRQ
>> > controllers are setup first, and then the GPIO controllers. Interrupts
>> > for GPIO lines are placed directly after the main interrupts in the
>> > interrupt space.
>> >
>> > Signed-off-by: Andrew Lunn <andrew@lunn.ch>
>>
>> I have started working on a pinctrl driver for mvebu, which would
>> handle pin muxing (MPP) + gpio + gpio interrupts.
>
> Hi Thomas
>
> You are not the only one working in this area. Arnaud Patard said he
> was look at this as well.
yeah, but tbh I've not made anything yet. If Thomas has already some
code for it, we should try to make it "generic" so as to use it on
armada xp and orion platforms.
>
>> So far, the pin muxing part is working (needs some polishing, but the
>> foundation is here), with device tree bindings. I think the pin muxing
>> could be used for Orion as well.
>
> Great. This is one of the big things which we are missing when moving
> a system over the DT. Being able to describe this in DT in a
> standardized way is very much welcome.
>
>> Now, I'm planning to start working on the gpio + gpio interrupts parts
>> of the driver, and I'm wondering how to interact with your work on the
>> matter.
>
> I've publicly said, what i have is enough to get it working, but i
> know its not the end solution. What i have is enough that gpio-key,
> gpio-led, as described in DT, works. Boards can start using these and
> as far as i can tell, the binding should not need to change. The GPIO
> controller binding should also be sufficiently generic that it should
> also not need changes when we replace the driver with pinctrl.
>
> The biggest problem i had, is the interaction between generic chip
> interrupts and irqdomain. There has been work to integrate the two,
> but its stalled. Either the work needs restarting and completing, or
> you need to throw away the use of generic interrupt so that you can
> use irqdomain linear. IMHO, throwing away generic interrupt is the
> wrong way.
>
> The other thing you need to keep in mind is the namespace issues
> between normal interrupts and GPIO interrupts. The way my patch works
> is that normal interrupts are setup first, counting how many have been
> created. Then GPIO interrupts are added, starting off where the normal
> interrupts ended. Since 370/XP uses different interrupt code, you need
> to think how to solve this issue.
>
>> My understanding is that the new way of doing a pinmux+gpio
>> driver is to implement it in drivers/pinctrl/, which I have started
>> doing.
>
> Great.
>
>> Should I continue working on a drivers/pinctrl/ driver for mvebu for
>> Armada 370/XP, and then we see together if it makes sense to extend to
>> Orion, and if so, what changes are needed?
>
> I know Marvell has contracted you to port to Armada 370/XP, not mvebu,
> aka all chips which might be able to share this code. This IMHO is
> wrong. So i personally would put the kirkwood and the Armada 370/XP
> data sheets next to each other, and from the beginning on write the
> driver so it supports them all. This assumes the ASIC engineers have
> not radically changed anything... Please also try to stick to the DT
> binding i've used.
agreed. it should be written with all platforms in mind, as long as
they're compatible. It can only make things better imho.
Arnaud
^ permalink raw reply [flat|nested] 130+ messages in thread
[parent not found: <87sjd6ikkj.fsf-0gaJ4kiyQU6khWr4QmshqB2eb7JE58TQ@public.gmane.org>]
* Re: [PATCH v2 01/12] ARM: Orion: DT support for IRQ and GPIO Controllers
2012-07-05 10:11 ` Arnaud Patard (Rtp)
@ 2012-07-05 10:20 ` Thomas Petazzoni
-1 siblings, 0 replies; 130+ messages in thread
From: Thomas Petazzoni @ 2012-07-05 10:20 UTC (permalink / raw)
To: Arnaud Patard (Rtp)
Cc: Andrew Lunn, Jason Cooper,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
rob.herring-bsGFqQB8/DxBDgjK7y7TUQ,
grant.likely-s3s/WqlpOiPyB63q8FvJNQ, Michael Walle,
linux-i2c-u79uwXL29TY76Z2rM5mHXA,
spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Lior Amsalem,
Maen Suleiman
Le Thu, 05 Jul 2012 12:11:40 +0200,
Arnaud Patard (Rtp) <arnaud.patard-dQbF7i+pzddAfugRpC6u6w@public.gmane.org> a écrit :
> > You are not the only one working in this area. Arnaud Patard said he
> > was look at this as well.
>
> yeah, but tbh I've not made anything yet. If Thomas has already some
> code for it, we should try to make it "generic" so as to use it on
> armada xp and orion platforms.
The MPP registers are identical on Armada XP/370 and 88F6281 (not sure
which other SoC datasheet I should be checking). Basically, it's just a
range of contiguous registers, with 4 bits per pin to select the
function.
So my pinmux driver should simply work as is for Orion as well. The
only difference between platforms is the number of MPP pins that are
available, but this number also varies between versions of Armada XP
and Armada 370, so I already support this in the driver.
However, using the pinmux driver will require changes in the device
drivers, so that they request the pinmux for their devices.
> > I know Marvell has contracted you to port to Armada 370/XP, not mvebu,
> > aka all chips which might be able to share this code. This IMHO is
> > wrong. So i personally would put the kirkwood and the Armada 370/XP
> > data sheets next to each other, and from the beginning on write the
> > driver so it supports them all. This assumes the ASIC engineers have
> > not radically changed anything... Please also try to stick to the DT
> > binding i've used.
>
> agreed. it should be written with all platforms in mind, as long as
> they're compatible. It can only make things better imho.
Certainly, especially for MPP/GPIO that are definitely very similar.
Best regards,
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply [flat|nested] 130+ messages in thread
* [PATCH v2 01/12] ARM: Orion: DT support for IRQ and GPIO Controllers
@ 2012-07-05 10:20 ` Thomas Petazzoni
0 siblings, 0 replies; 130+ messages in thread
From: Thomas Petazzoni @ 2012-07-05 10:20 UTC (permalink / raw)
To: linux-arm-kernel
Le Thu, 05 Jul 2012 12:11:40 +0200,
Arnaud Patard (Rtp) <arnaud.patard@rtp-net.org> a ?crit :
> > You are not the only one working in this area. Arnaud Patard said he
> > was look at this as well.
>
> yeah, but tbh I've not made anything yet. If Thomas has already some
> code for it, we should try to make it "generic" so as to use it on
> armada xp and orion platforms.
The MPP registers are identical on Armada XP/370 and 88F6281 (not sure
which other SoC datasheet I should be checking). Basically, it's just a
range of contiguous registers, with 4 bits per pin to select the
function.
So my pinmux driver should simply work as is for Orion as well. The
only difference between platforms is the number of MPP pins that are
available, but this number also varies between versions of Armada XP
and Armada 370, so I already support this in the driver.
However, using the pinmux driver will require changes in the device
drivers, so that they request the pinmux for their devices.
> > I know Marvell has contracted you to port to Armada 370/XP, not mvebu,
> > aka all chips which might be able to share this code. This IMHO is
> > wrong. So i personally would put the kirkwood and the Armada 370/XP
> > data sheets next to each other, and from the beginning on write the
> > driver so it supports them all. This assumes the ASIC engineers have
> > not radically changed anything... Please also try to stick to the DT
> > binding i've used.
>
> agreed. it should be written with all platforms in mind, as long as
> they're compatible. It can only make things better imho.
Certainly, especially for MPP/GPIO that are definitely very similar.
Best regards,
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: [PATCH v2 01/12] ARM: Orion: DT support for IRQ and GPIO Controllers
2012-07-05 10:20 ` Thomas Petazzoni
@ 2012-07-05 10:38 ` Arnaud Patard (Rtp)
-1 siblings, 0 replies; 130+ messages in thread
From: Arnaud Patard @ 2012-07-05 10:38 UTC (permalink / raw)
To: Thomas Petazzoni
Cc: Andrew Lunn, Jason Cooper,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
rob.herring-bsGFqQB8/DxBDgjK7y7TUQ,
grant.likely-s3s/WqlpOiPyB63q8FvJNQ, Michael Walle,
linux-i2c-u79uwXL29TY76Z2rM5mHXA,
spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Lior Amsalem,
Maen Suleiman
Thomas Petazzoni <thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> writes:
> Le Thu, 05 Jul 2012 12:11:40 +0200,
> Arnaud Patard (Rtp) <arnaud.patard-dQbF7i+pzddAfugRpC6u6w@public.gmane.org> a écrit :
>
>> > You are not the only one working in this area. Arnaud Patard said he
>> > was look at this as well.
>>
>> yeah, but tbh I've not made anything yet. If Thomas has already some
>> code for it, we should try to make it "generic" so as to use it on
>> armada xp and orion platforms.
>
> The MPP registers are identical on Armada XP/370 and 88F6281 (not sure
> which other SoC datasheet I should be checking). Basically, it's just a
> range of contiguous registers, with 4 bits per pin to select the
> function.
iirc, other SoCs are similar. The small exception being dove I
guess. Dove has a 3rd gpo [the gpios are output only] bank but to be
used as gpio require that a special bit is set and it's for all gpios of
this bank. You'll find this bit in the "general mpp configuration
register" if you look at the datasheet.
>
> So my pinmux driver should simply work as is for Orion as well. The
> only difference between platforms is the number of MPP pins that are
> available, but this number also varies between versions of Armada XP
> and Armada 370, so I already support this in the driver.
>
Are there some output-only gpio on armada xp/370 like on kirkwood/dove ?
Arnaud
^ permalink raw reply [flat|nested] 130+ messages in thread
* [PATCH v2 01/12] ARM: Orion: DT support for IRQ and GPIO Controllers
@ 2012-07-05 10:38 ` Arnaud Patard (Rtp)
0 siblings, 0 replies; 130+ messages in thread
From: Arnaud Patard (Rtp) @ 2012-07-05 10:38 UTC (permalink / raw)
To: linux-arm-kernel
Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:
> Le Thu, 05 Jul 2012 12:11:40 +0200,
> Arnaud Patard (Rtp) <arnaud.patard@rtp-net.org> a ?crit :
>
>> > You are not the only one working in this area. Arnaud Patard said he
>> > was look at this as well.
>>
>> yeah, but tbh I've not made anything yet. If Thomas has already some
>> code for it, we should try to make it "generic" so as to use it on
>> armada xp and orion platforms.
>
> The MPP registers are identical on Armada XP/370 and 88F6281 (not sure
> which other SoC datasheet I should be checking). Basically, it's just a
> range of contiguous registers, with 4 bits per pin to select the
> function.
iirc, other SoCs are similar. The small exception being dove I
guess. Dove has a 3rd gpo [the gpios are output only] bank but to be
used as gpio require that a special bit is set and it's for all gpios of
this bank. You'll find this bit in the "general mpp configuration
register" if you look at the datasheet.
>
> So my pinmux driver should simply work as is for Orion as well. The
> only difference between platforms is the number of MPP pins that are
> available, but this number also varies between versions of Armada XP
> and Armada 370, so I already support this in the driver.
>
Are there some output-only gpio on armada xp/370 like on kirkwood/dove ?
Arnaud
^ permalink raw reply [flat|nested] 130+ messages in thread
[parent not found: <87liiyijb8.fsf-0gaJ4kiyQU6khWr4QmshqB2eb7JE58TQ@public.gmane.org>]
* Re: [PATCH v2 01/12] ARM: Orion: DT support for IRQ and GPIO Controllers
2012-07-05 10:38 ` Arnaud Patard (Rtp)
@ 2012-07-05 11:42 ` Thomas Petazzoni
-1 siblings, 0 replies; 130+ messages in thread
From: Thomas Petazzoni @ 2012-07-05 11:42 UTC (permalink / raw)
To: Arnaud Patard (Rtp)
Cc: Andrew Lunn, Jason Cooper,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
rob.herring-bsGFqQB8/DxBDgjK7y7TUQ,
grant.likely-s3s/WqlpOiPyB63q8FvJNQ, Michael Walle,
linux-i2c-u79uwXL29TY76Z2rM5mHXA,
spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Lior Amsalem,
Maen Suleiman
Le Thu, 05 Jul 2012 12:38:51 +0200,
Arnaud Patard (Rtp) <arnaud.patard-dQbF7i+pzddAfugRpC6u6w@public.gmane.org> a écrit :
> > The MPP registers are identical on Armada XP/370 and 88F6281 (not sure
> > which other SoC datasheet I should be checking). Basically, it's just a
> > range of contiguous registers, with 4 bits per pin to select the
> > function.
>
> iirc, other SoCs are similar. The small exception being dove I
> guess. Dove has a 3rd gpo [the gpios are output only] bank but to be
> used as gpio require that a special bit is set and it's for all gpios of
> this bank. You'll find this bit in the "general mpp configuration
> register" if you look at the datasheet.
Ok, this is a bit trickier, but we can probably do something for it as
well.
> > So my pinmux driver should simply work as is for Orion as well. The
> > only difference between platforms is the number of MPP pins that are
> > available, but this number also varies between versions of Armada XP
> > and Armada 370, so I already support this in the driver.
>
> Are there some output-only gpio on armada xp/370 like on kirkwood/dove ?
Yes. I am not sure yet how to describe those in the DT, or even if it
is actually useful to describe them. Wouldn't it be simpler to just
leave to the user of the GPIO to use a GPIO that's appropriate for its
usage, i.e not use a GPO when input is needed?
Best regards,
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply [flat|nested] 130+ messages in thread
* [PATCH v2 01/12] ARM: Orion: DT support for IRQ and GPIO Controllers
@ 2012-07-05 11:42 ` Thomas Petazzoni
0 siblings, 0 replies; 130+ messages in thread
From: Thomas Petazzoni @ 2012-07-05 11:42 UTC (permalink / raw)
To: linux-arm-kernel
Le Thu, 05 Jul 2012 12:38:51 +0200,
Arnaud Patard (Rtp) <arnaud.patard@rtp-net.org> a ?crit :
> > The MPP registers are identical on Armada XP/370 and 88F6281 (not sure
> > which other SoC datasheet I should be checking). Basically, it's just a
> > range of contiguous registers, with 4 bits per pin to select the
> > function.
>
> iirc, other SoCs are similar. The small exception being dove I
> guess. Dove has a 3rd gpo [the gpios are output only] bank but to be
> used as gpio require that a special bit is set and it's for all gpios of
> this bank. You'll find this bit in the "general mpp configuration
> register" if you look at the datasheet.
Ok, this is a bit trickier, but we can probably do something for it as
well.
> > So my pinmux driver should simply work as is for Orion as well. The
> > only difference between platforms is the number of MPP pins that are
> > available, but this number also varies between versions of Armada XP
> > and Armada 370, so I already support this in the driver.
>
> Are there some output-only gpio on armada xp/370 like on kirkwood/dove ?
Yes. I am not sure yet how to describe those in the DT, or even if it
is actually useful to describe them. Wouldn't it be simpler to just
leave to the user of the GPIO to use a GPIO that's appropriate for its
usage, i.e not use a GPO when input is needed?
Best regards,
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: [PATCH v2 01/12] ARM: Orion: DT support for IRQ and GPIO Controllers
2012-07-05 11:42 ` Thomas Petazzoni
@ 2012-07-05 11:48 ` Andrew Lunn
-1 siblings, 0 replies; 130+ messages in thread
From: Andrew Lunn @ 2012-07-05 11:48 UTC (permalink / raw)
To: Thomas Petazzoni
Cc: Arnaud Patard, Andrew Lunn, Jason Cooper,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
rob.herring-bsGFqQB8/DxBDgjK7y7TUQ,
grant.likely-s3s/WqlpOiPyB63q8FvJNQ, Michael Walle,
linux-i2c-u79uwXL29TY76Z2rM5mHXA,
spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Lior Amsalem,
Maen Suleiman
Hi Thomas
> Yes. I am not sure yet how to describe those in the DT, or even if it
> is actually useful to describe them. Wouldn't it be simpler to just
> leave to the user of the GPIO to use a GPIO that's appropriate for its
> usage, i.e not use a GPO when input is needed?
We assume the hardware designer has got the basic hardware right. Its
not going to work otherwise.
What we are trying to detect is a DT author making a typo, assigning a
gpio-key to a GPO pin, for example. The current MPP scheme will detect
this sort of error and issue a warning to the kernel logs.
Andrew
^ permalink raw reply [flat|nested] 130+ messages in thread
* [PATCH v2 01/12] ARM: Orion: DT support for IRQ and GPIO Controllers
@ 2012-07-05 11:48 ` Andrew Lunn
0 siblings, 0 replies; 130+ messages in thread
From: Andrew Lunn @ 2012-07-05 11:48 UTC (permalink / raw)
To: linux-arm-kernel
Hi Thomas
> Yes. I am not sure yet how to describe those in the DT, or even if it
> is actually useful to describe them. Wouldn't it be simpler to just
> leave to the user of the GPIO to use a GPIO that's appropriate for its
> usage, i.e not use a GPO when input is needed?
We assume the hardware designer has got the basic hardware right. Its
not going to work otherwise.
What we are trying to detect is a DT author making a typo, assigning a
gpio-key to a GPO pin, for example. The current MPP scheme will detect
this sort of error and issue a warning to the kernel logs.
Andrew
^ permalink raw reply [flat|nested] 130+ messages in thread
[parent not found: <20120705114815.GT17534-g2DYL2Zd6BY@public.gmane.org>]
* Re: [PATCH v2 01/12] ARM: Orion: DT support for IRQ and GPIO Controllers
2012-07-05 11:48 ` Andrew Lunn
@ 2012-07-05 12:09 ` Sebastian Hesselbarth
-1 siblings, 0 replies; 130+ messages in thread
From: Sebastian Hesselbarth @ 2012-07-05 12:09 UTC (permalink / raw)
To: Thomas Petazzoni, Arnaud Patard, Andrew Lunn, Jason Cooper,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
rob.herring-bsGFqQB8/DxBDgjK7y7TUQ,
grant.likely-s3s/WqlpOiPyB63q8FvJNQ, Michael Walle,
linux-i2c-u79uwXL29TY76Z2rM5mHXA,
spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Lior Amsalem,
Maen Suleiman
On 07/05/2012 01:48 PM, Andrew Lunn wrote:
>> Yes. I am not sure yet how to describe those in the DT, or even if it
>> is actually useful to describe them. Wouldn't it be simpler to just
>> leave to the user of the GPIO to use a GPIO that's appropriate for its
>> usage, i.e not use a GPO when input is needed?
>
> We assume the hardware designer has got the basic hardware right. Its
> not going to work otherwise.
>
> What we are trying to detect is a DT author making a typo, assigning a
> gpio-key to a GPO pin, for example. The current MPP scheme will detect
> this sort of error and issue a warning to the kernel logs.
The output-only/non-interrupt gpios could be marked as such in DT.
The common code should not install irqs if marked by e.g.
"marvell,gpio-no-irq". The gpio driver already fails to set input
direction on output-only pins. This could be marked by e.g.
"marvell,gpio-output-only" in DT.
Sebastian
^ permalink raw reply [flat|nested] 130+ messages in thread
* [PATCH v2 01/12] ARM: Orion: DT support for IRQ and GPIO Controllers
@ 2012-07-05 12:09 ` Sebastian Hesselbarth
0 siblings, 0 replies; 130+ messages in thread
From: Sebastian Hesselbarth @ 2012-07-05 12:09 UTC (permalink / raw)
To: linux-arm-kernel
On 07/05/2012 01:48 PM, Andrew Lunn wrote:
>> Yes. I am not sure yet how to describe those in the DT, or even if it
>> is actually useful to describe them. Wouldn't it be simpler to just
>> leave to the user of the GPIO to use a GPIO that's appropriate for its
>> usage, i.e not use a GPO when input is needed?
>
> We assume the hardware designer has got the basic hardware right. Its
> not going to work otherwise.
>
> What we are trying to detect is a DT author making a typo, assigning a
> gpio-key to a GPO pin, for example. The current MPP scheme will detect
> this sort of error and issue a warning to the kernel logs.
The output-only/non-interrupt gpios could be marked as such in DT.
The common code should not install irqs if marked by e.g.
"marvell,gpio-no-irq". The gpio driver already fails to set input
direction on output-only pins. This could be marked by e.g.
"marvell,gpio-output-only" in DT.
Sebastian
^ permalink raw reply [flat|nested] 130+ messages in thread
[parent not found: <20120705094824.GO17534-g2DYL2Zd6BY@public.gmane.org>]
* Re: [PATCH v2 01/12] ARM: Orion: DT support for IRQ and GPIO Controllers
2012-07-05 9:48 ` Andrew Lunn
@ 2012-07-05 10:10 ` Thomas Petazzoni
-1 siblings, 0 replies; 130+ messages in thread
From: Thomas Petazzoni @ 2012-07-05 10:10 UTC (permalink / raw)
To: Andrew Lunn
Cc: Jason Cooper, devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
rob.herring-bsGFqQB8/DxBDgjK7y7TUQ,
grant.likely-s3s/WqlpOiPyB63q8FvJNQ, Michael Walle,
linux-i2c-u79uwXL29TY76Z2rM5mHXA,
spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Lior Amsalem,
Maen Suleiman, Arnaud Patard (Rtp)
Hello,
Le Thu, 5 Jul 2012 11:48:24 +0200,
Andrew Lunn <andrew-g2DYL2Zd6BY@public.gmane.org> a écrit :
> Hi Thomas
>
> You are not the only one working in this area. Arnaud Patard said he
> was look at this as well.
Ok, I added Arnaud in the Cc list. Arnaud, what is the status of you
work?
> > So far, the pin muxing part is working (needs some polishing, but the
> > foundation is here), with device tree bindings. I think the pin muxing
> > could be used for Orion as well.
>
> Great. This is one of the big things which we are missing when moving
> a system over the DT. Being able to describe this in DT in a
> standardized way is very much welcome.
For the DT binding, I took my inspiration from the MXS and Samsung
pinctrl drivers, as those platforms also have independent pin muxing
(while some platforms such as Tegra, have hardware pin groups).
The .dtsi side looks like:
pinctrl@d0018000 {
compatible = "marvell,mv78230-pinmux";
reg = <0xd0018000 0x38>;
uart_2: uart-2 {
marvell,pins = <42 43>;
marvell,pins-function = <1>;
};
uart_3: uart-3 {
marvell,pins = <44 45>;
marvell,pins-function = <2>;
};
uart_0_control: uart-0-control {
marvell,pins = <42 43>;
marvell,pins-function = <2>;
};
uart_1_control: uart-1-control {
marvell,pins = <46 47>;
marvell,pins-function = <2>;
};
uart_2_control: uart-2-control {
marvell,pins = <44 45>;
marvell,pins-function = <1>;
};
uart_3_control: uart-3-control {
marvell,pins = <46 47>;
marvell,pins-function = <1>;
};
};
This defines the various pin muxing options, and then when
instantiating a device, you do:
test@12 {
compatible = "marvell,testdrv";
pinctrl-names = "default";
pinctrl-0 = <&uart_0_control>;
};
(This is with a dummy test driver that I'm using for testing). Then
the driver can use the pinctrl API to get the proper muxing for its
pins.
> > Now, I'm planning to start working on the gpio + gpio interrupts parts
> > of the driver, and I'm wondering how to interact with your work on the
> > matter.
>
> I've publicly said, what i have is enough to get it working, but i
> know its not the end solution. What i have is enough that gpio-key,
> gpio-led, as described in DT, works. Boards can start using these and
> as far as i can tell, the binding should not need to change. The GPIO
> controller binding should also be sufficiently generic that it should
> also not need changes when we replace the driver with pinctrl.
>
> The biggest problem i had, is the interaction between generic chip
> interrupts and irqdomain. There has been work to integrate the two,
> but its stalled. Either the work needs restarting and completing, or
> you need to throw away the use of generic interrupt so that you can
> use irqdomain linear. IMHO, throwing away generic interrupt is the
> wrong way.
>
> The other thing you need to keep in mind is the namespace issues
> between normal interrupts and GPIO interrupts. The way my patch works
> is that normal interrupts are setup first, counting how many have been
> created. Then GPIO interrupts are added, starting off where the normal
> interrupts ended. Since 370/XP uses different interrupt code, you need
> to think how to solve this issue.
Ok, thanks for those hints.
> > Should I continue working on a drivers/pinctrl/ driver for mvebu for
> > Armada 370/XP, and then we see together if it makes sense to extend to
> > Orion, and if so, what changes are needed?
>
> I know Marvell has contracted you to port to Armada 370/XP, not mvebu,
> aka all chips which might be able to share this code. This IMHO is
> wrong. So i personally would put the kirkwood and the Armada 370/XP
> data sheets next to each other, and from the beginning on write the
> driver so it supports them all. This assumes the ASIC engineers have
> not radically changed anything... Please also try to stick to the DT
> binding i've used.
I've looked at the datasheet for the 88F6281, and the GPIO registers
look fairly similar with Armada 370/XP, except that:
* On 88F6281, there are two GPIO banks, while on Armada 370/XP it's a
continuous range of registers that control the GPIOs. But it can be
assimilated as one bank handling more than 32 GPIOs. So shouldn't be
a big problem to handle.
* The Armada 370/XP have additional set/clear registers that allow to
modify the GPIO states without having to do a read/mask/write
sequence, which is nicer on SMP. I guess we can handle that as a
variant inside the driver without too much problem.
Marvell has given me a 88F6282 eval board, so I guess they are fine
with me spending some time ensuring that the new code works properly on
the previous platforms, especially in this case where the amount of
work does not seem to be enormous to keep the compatibility.
Thanks,
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply [flat|nested] 130+ messages in thread* [PATCH v2 01/12] ARM: Orion: DT support for IRQ and GPIO Controllers
@ 2012-07-05 10:10 ` Thomas Petazzoni
0 siblings, 0 replies; 130+ messages in thread
From: Thomas Petazzoni @ 2012-07-05 10:10 UTC (permalink / raw)
To: linux-arm-kernel
Hello,
Le Thu, 5 Jul 2012 11:48:24 +0200,
Andrew Lunn <andrew@lunn.ch> a ?crit :
> Hi Thomas
>
> You are not the only one working in this area. Arnaud Patard said he
> was look at this as well.
Ok, I added Arnaud in the Cc list. Arnaud, what is the status of you
work?
> > So far, the pin muxing part is working (needs some polishing, but the
> > foundation is here), with device tree bindings. I think the pin muxing
> > could be used for Orion as well.
>
> Great. This is one of the big things which we are missing when moving
> a system over the DT. Being able to describe this in DT in a
> standardized way is very much welcome.
For the DT binding, I took my inspiration from the MXS and Samsung
pinctrl drivers, as those platforms also have independent pin muxing
(while some platforms such as Tegra, have hardware pin groups).
The .dtsi side looks like:
pinctrl at d0018000 {
compatible = "marvell,mv78230-pinmux";
reg = <0xd0018000 0x38>;
uart_2: uart-2 {
marvell,pins = <42 43>;
marvell,pins-function = <1>;
};
uart_3: uart-3 {
marvell,pins = <44 45>;
marvell,pins-function = <2>;
};
uart_0_control: uart-0-control {
marvell,pins = <42 43>;
marvell,pins-function = <2>;
};
uart_1_control: uart-1-control {
marvell,pins = <46 47>;
marvell,pins-function = <2>;
};
uart_2_control: uart-2-control {
marvell,pins = <44 45>;
marvell,pins-function = <1>;
};
uart_3_control: uart-3-control {
marvell,pins = <46 47>;
marvell,pins-function = <1>;
};
};
This defines the various pin muxing options, and then when
instantiating a device, you do:
test at 12 {
compatible = "marvell,testdrv";
pinctrl-names = "default";
pinctrl-0 = <&uart_0_control>;
};
(This is with a dummy test driver that I'm using for testing). Then
the driver can use the pinctrl API to get the proper muxing for its
pins.
> > Now, I'm planning to start working on the gpio + gpio interrupts parts
> > of the driver, and I'm wondering how to interact with your work on the
> > matter.
>
> I've publicly said, what i have is enough to get it working, but i
> know its not the end solution. What i have is enough that gpio-key,
> gpio-led, as described in DT, works. Boards can start using these and
> as far as i can tell, the binding should not need to change. The GPIO
> controller binding should also be sufficiently generic that it should
> also not need changes when we replace the driver with pinctrl.
>
> The biggest problem i had, is the interaction between generic chip
> interrupts and irqdomain. There has been work to integrate the two,
> but its stalled. Either the work needs restarting and completing, or
> you need to throw away the use of generic interrupt so that you can
> use irqdomain linear. IMHO, throwing away generic interrupt is the
> wrong way.
>
> The other thing you need to keep in mind is the namespace issues
> between normal interrupts and GPIO interrupts. The way my patch works
> is that normal interrupts are setup first, counting how many have been
> created. Then GPIO interrupts are added, starting off where the normal
> interrupts ended. Since 370/XP uses different interrupt code, you need
> to think how to solve this issue.
Ok, thanks for those hints.
> > Should I continue working on a drivers/pinctrl/ driver for mvebu for
> > Armada 370/XP, and then we see together if it makes sense to extend to
> > Orion, and if so, what changes are needed?
>
> I know Marvell has contracted you to port to Armada 370/XP, not mvebu,
> aka all chips which might be able to share this code. This IMHO is
> wrong. So i personally would put the kirkwood and the Armada 370/XP
> data sheets next to each other, and from the beginning on write the
> driver so it supports them all. This assumes the ASIC engineers have
> not radically changed anything... Please also try to stick to the DT
> binding i've used.
I've looked at the datasheet for the 88F6281, and the GPIO registers
look fairly similar with Armada 370/XP, except that:
* On 88F6281, there are two GPIO banks, while on Armada 370/XP it's a
continuous range of registers that control the GPIOs. But it can be
assimilated as one bank handling more than 32 GPIOs. So shouldn't be
a big problem to handle.
* The Armada 370/XP have additional set/clear registers that allow to
modify the GPIO states without having to do a read/mask/write
sequence, which is nicer on SMP. I guess we can handle that as a
variant inside the driver without too much problem.
Marvell has given me a 88F6282 eval board, so I guess they are fine
with me spending some time ensuring that the new code works properly on
the previous platforms, especially in this case where the amount of
work does not seem to be enormous to keep the compatibility.
Thanks,
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply [flat|nested] 130+ messages in thread* Re: [PATCH v2 01/12] ARM: Orion: DT support for IRQ and GPIO Controllers
2012-07-05 10:10 ` Thomas Petazzoni
@ 2012-07-05 10:25 ` Andrew Lunn
-1 siblings, 0 replies; 130+ messages in thread
From: Andrew Lunn @ 2012-07-05 10:25 UTC (permalink / raw)
To: Thomas Petazzoni
Cc: Andrew Lunn, Jason Cooper,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
rob.herring-bsGFqQB8/DxBDgjK7y7TUQ,
grant.likely-s3s/WqlpOiPyB63q8FvJNQ, Michael Walle,
linux-i2c-u79uwXL29TY76Z2rM5mHXA,
spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Lior Amsalem,
Maen Suleiman, Arnaud Patard
> I've looked at the datasheet for the 88F6281, and the GPIO registers
> look fairly similar with Armada 370/XP, except that:
>
> * On 88F6281, there are two GPIO banks, while on Armada 370/XP it's a
> continuous range of registers that control the GPIOs. But it can be
> assimilated as one bank handling more than 32 GPIOs. So shouldn't be
> a big problem to handle.
The number of banks varies. Orion5x has one, Dove has three, etc.
>
> * The Armada 370/XP have additional set/clear registers that allow to
> modify the GPIO states without having to do a read/mask/write
> sequence, which is nicer on SMP. I guess we can handle that as a
> variant inside the driver without too much problem.
>
> Marvell has given me a 88F6282 eval board, so I guess they are fine
> with me spending some time ensuring that the new code works properly on
> the previous platforms, especially in this case where the amount of
> work does not seem to be enormous to keep the compatibility.
That is good to hear.
Thanks
Andrew
^ permalink raw reply [flat|nested] 130+ messages in thread
* [PATCH v2 01/12] ARM: Orion: DT support for IRQ and GPIO Controllers
@ 2012-07-05 10:25 ` Andrew Lunn
0 siblings, 0 replies; 130+ messages in thread
From: Andrew Lunn @ 2012-07-05 10:25 UTC (permalink / raw)
To: linux-arm-kernel
> I've looked at the datasheet for the 88F6281, and the GPIO registers
> look fairly similar with Armada 370/XP, except that:
>
> * On 88F6281, there are two GPIO banks, while on Armada 370/XP it's a
> continuous range of registers that control the GPIOs. But it can be
> assimilated as one bank handling more than 32 GPIOs. So shouldn't be
> a big problem to handle.
The number of banks varies. Orion5x has one, Dove has three, etc.
>
> * The Armada 370/XP have additional set/clear registers that allow to
> modify the GPIO states without having to do a read/mask/write
> sequence, which is nicer on SMP. I guess we can handle that as a
> variant inside the driver without too much problem.
>
> Marvell has given me a 88F6282 eval board, so I guess they are fine
> with me spending some time ensuring that the new code works properly on
> the previous platforms, especially in this case where the amount of
> work does not seem to be enormous to keep the compatibility.
That is good to hear.
Thanks
Andrew
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: [PATCH v2 01/12] ARM: Orion: DT support for IRQ and GPIO Controllers
2012-07-05 9:48 ` Andrew Lunn
@ 2012-07-05 12:58 ` Thomas Petazzoni
-1 siblings, 0 replies; 130+ messages in thread
From: Thomas Petazzoni @ 2012-07-05 12:58 UTC (permalink / raw)
To: Andrew Lunn
Cc: Jason Cooper, devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
rob.herring-bsGFqQB8/DxBDgjK7y7TUQ,
grant.likely-s3s/WqlpOiPyB63q8FvJNQ, Michael Walle,
linux-i2c-u79uwXL29TY76Z2rM5mHXA,
spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Lior Amsalem,
Maen Suleiman
Hello,
Le Thu, 5 Jul 2012 11:48:24 +0200,
Andrew Lunn <andrew-g2DYL2Zd6BY@public.gmane.org> a écrit :
> The biggest problem i had, is the interaction between generic chip
> interrupts and irqdomain. There has been work to integrate the two,
> but its stalled. Either the work needs restarting and completing, or
> you need to throw away the use of generic interrupt so that you can
> use irqdomain linear. IMHO, throwing away generic interrupt is the
> wrong way.
Can you expand on why you think it would be wrong to throw away the
usage of irq_chip_generic, compared to implementing directly an
irq_chip?
Thanks!
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply [flat|nested] 130+ messages in thread
* [PATCH v2 01/12] ARM: Orion: DT support for IRQ and GPIO Controllers
@ 2012-07-05 12:58 ` Thomas Petazzoni
0 siblings, 0 replies; 130+ messages in thread
From: Thomas Petazzoni @ 2012-07-05 12:58 UTC (permalink / raw)
To: linux-arm-kernel
Hello,
Le Thu, 5 Jul 2012 11:48:24 +0200,
Andrew Lunn <andrew@lunn.ch> a ?crit :
> The biggest problem i had, is the interaction between generic chip
> interrupts and irqdomain. There has been work to integrate the two,
> but its stalled. Either the work needs restarting and completing, or
> you need to throw away the use of generic interrupt so that you can
> use irqdomain linear. IMHO, throwing away generic interrupt is the
> wrong way.
Can you expand on why you think it would be wrong to throw away the
usage of irq_chip_generic, compared to implementing directly an
irq_chip?
Thanks!
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: [PATCH v2 01/12] ARM: Orion: DT support for IRQ and GPIO Controllers
2012-07-05 12:58 ` Thomas Petazzoni
@ 2012-07-05 13:15 ` Andrew Lunn
-1 siblings, 0 replies; 130+ messages in thread
From: Andrew Lunn @ 2012-07-05 13:15 UTC (permalink / raw)
To: Thomas Petazzoni
Cc: Andrew Lunn, Jason Cooper,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
rob.herring-bsGFqQB8/DxBDgjK7y7TUQ,
grant.likely-s3s/WqlpOiPyB63q8FvJNQ, Michael Walle,
linux-i2c-u79uwXL29TY76Z2rM5mHXA,
spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Lior Amsalem,
Maen Suleiman
On Thu, Jul 05, 2012 at 02:58:01PM +0200, Thomas Petazzoni wrote:
> Hello,
>
> Le Thu, 5 Jul 2012 11:48:24 +0200,
> Andrew Lunn <andrew-g2DYL2Zd6BY@public.gmane.org> a ??crit :
>
> > The biggest problem i had, is the interaction between generic chip
> > interrupts and irqdomain. There has been work to integrate the two,
> > but its stalled. Either the work needs restarting and completing, or
> > you need to throw away the use of generic interrupt so that you can
> > use irqdomain linear. IMHO, throwing away generic interrupt is the
> > wrong way.
>
> Can you expand on why you think it would be wrong to throw away the
> usage of irq_chip_generic, compared to implementing directly an
> irq_chip?
Basically you are asking, why should i use the framework when i can do
it by hand.
What are the advantages if ignoring the framework and doing it by
hand?
Andrew
^ permalink raw reply [flat|nested] 130+ messages in thread
* [PATCH v2 01/12] ARM: Orion: DT support for IRQ and GPIO Controllers
@ 2012-07-05 13:15 ` Andrew Lunn
0 siblings, 0 replies; 130+ messages in thread
From: Andrew Lunn @ 2012-07-05 13:15 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Jul 05, 2012 at 02:58:01PM +0200, Thomas Petazzoni wrote:
> Hello,
>
> Le Thu, 5 Jul 2012 11:48:24 +0200,
> Andrew Lunn <andrew@lunn.ch> a ??crit :
>
> > The biggest problem i had, is the interaction between generic chip
> > interrupts and irqdomain. There has been work to integrate the two,
> > but its stalled. Either the work needs restarting and completing, or
> > you need to throw away the use of generic interrupt so that you can
> > use irqdomain linear. IMHO, throwing away generic interrupt is the
> > wrong way.
>
> Can you expand on why you think it would be wrong to throw away the
> usage of irq_chip_generic, compared to implementing directly an
> irq_chip?
Basically you are asking, why should i use the framework when i can do
it by hand.
What are the advantages if ignoring the framework and doing it by
hand?
Andrew
^ permalink raw reply [flat|nested] 130+ messages in thread
[parent not found: <20120705131522.GW17534-g2DYL2Zd6BY@public.gmane.org>]
* Re: [PATCH v2 01/12] ARM: Orion: DT support for IRQ and GPIO Controllers
2012-07-05 13:15 ` Andrew Lunn
@ 2012-07-05 13:28 ` Thomas Petazzoni
-1 siblings, 0 replies; 130+ messages in thread
From: Thomas Petazzoni @ 2012-07-05 13:28 UTC (permalink / raw)
To: Andrew Lunn
Cc: Jason Cooper, devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
rob.herring-bsGFqQB8/DxBDgjK7y7TUQ,
grant.likely-s3s/WqlpOiPyB63q8FvJNQ, Michael Walle,
linux-i2c-u79uwXL29TY76Z2rM5mHXA,
spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Lior Amsalem,
Maen Suleiman
Le Thu, 5 Jul 2012 15:15:22 +0200,
Andrew Lunn <andrew-g2DYL2Zd6BY@public.gmane.org> a écrit :
> > > The biggest problem i had, is the interaction between generic chip
> > > interrupts and irqdomain. There has been work to integrate the two,
> > > but its stalled. Either the work needs restarting and completing, or
> > > you need to throw away the use of generic interrupt so that you can
> > > use irqdomain linear. IMHO, throwing away generic interrupt is the
> > > wrong way.
> >
> > Can you expand on why you think it would be wrong to throw away the
> > usage of irq_chip_generic, compared to implementing directly an
> > irq_chip?
>
> Basically you are asking, why should i use the framework when i can do
> it by hand.
Agreed :)
> What are the advantages if ignoring the framework and doing it by
> hand?
Many GPIO drivers directly use irq_chip (though it's true some of them
use irq_chip_generic), and the irq_chip_generic framework doesn't have
really proper support for the other new irqdomain framework, so I was
wondering what the best solution was.
I found the proposal from Rob Herring to improve that situation, but
apparently the conclusion from Grant Likely was "Let's discuss this at
the next Connect". That patch set was posted in January, so two Linaro
Connects happened since them, I don't know if progress has been made
here.
I guess I'll just stick to irq_chip_generic + irqdomain_legacy for now.
Best regards,
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply [flat|nested] 130+ messages in thread
* [PATCH v2 01/12] ARM: Orion: DT support for IRQ and GPIO Controllers
@ 2012-07-05 13:28 ` Thomas Petazzoni
0 siblings, 0 replies; 130+ messages in thread
From: Thomas Petazzoni @ 2012-07-05 13:28 UTC (permalink / raw)
To: linux-arm-kernel
Le Thu, 5 Jul 2012 15:15:22 +0200,
Andrew Lunn <andrew@lunn.ch> a ?crit :
> > > The biggest problem i had, is the interaction between generic chip
> > > interrupts and irqdomain. There has been work to integrate the two,
> > > but its stalled. Either the work needs restarting and completing, or
> > > you need to throw away the use of generic interrupt so that you can
> > > use irqdomain linear. IMHO, throwing away generic interrupt is the
> > > wrong way.
> >
> > Can you expand on why you think it would be wrong to throw away the
> > usage of irq_chip_generic, compared to implementing directly an
> > irq_chip?
>
> Basically you are asking, why should i use the framework when i can do
> it by hand.
Agreed :)
> What are the advantages if ignoring the framework and doing it by
> hand?
Many GPIO drivers directly use irq_chip (though it's true some of them
use irq_chip_generic), and the irq_chip_generic framework doesn't have
really proper support for the other new irqdomain framework, so I was
wondering what the best solution was.
I found the proposal from Rob Herring to improve that situation, but
apparently the conclusion from Grant Likely was "Let's discuss this at
the next Connect". That patch set was posted in January, so two Linaro
Connects happened since them, I don't know if progress has been made
here.
I guess I'll just stick to irq_chip_generic + irqdomain_legacy for now.
Best regards,
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply [flat|nested] 130+ messages in thread
* [PATCH v2 01/12] ARM: Orion: DT support for IRQ and GPIO Controllers
2012-07-05 13:28 ` Thomas Petazzoni
(?)
@ 2012-07-05 13:33 ` Andrew Lunn
2012-07-05 13:36 ` Thomas Petazzoni
-1 siblings, 1 reply; 130+ messages in thread
From: Andrew Lunn @ 2012-07-05 13:33 UTC (permalink / raw)
To: linux-arm-kernel
> I guess I'll just stick to irq_chip_generic + irqdomain_legacy for now.
Hi Thomas
That is what my patch currently does. Feel free to re-use parts of the
orion code.
Andrew
^ permalink raw reply [flat|nested] 130+ messages in thread* [PATCH v2 01/12] ARM: Orion: DT support for IRQ and GPIO Controllers
2012-07-05 13:33 ` Andrew Lunn
@ 2012-07-05 13:36 ` Thomas Petazzoni
0 siblings, 0 replies; 130+ messages in thread
From: Thomas Petazzoni @ 2012-07-05 13:36 UTC (permalink / raw)
To: linux-arm-kernel
Le Thu, 5 Jul 2012 15:33:10 +0200,
Andrew Lunn <andrew@lunn.ch> a ?crit :
> That is what my patch currently does. Feel free to re-use parts of the
> orion code.
Yes, sure! I have applied your patch and read it, I definitely intend
to re-use many parts of it.
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: [PATCH v2 01/12] ARM: Orion: DT support for IRQ and GPIO Controllers
2012-07-03 14:22 ` Andrew Lunn
@ 2012-07-05 12:25 ` Arnd Bergmann
-1 siblings, 0 replies; 130+ messages in thread
From: Arnd Bergmann @ 2012-07-05 12:25 UTC (permalink / raw)
To: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Cc: Andrew Lunn, Jason Cooper,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
rob.herring-bsGFqQB8/DxBDgjK7y7TUQ,
grant.likely-s3s/WqlpOiPyB63q8FvJNQ, Michael Walle,
linux-i2c-u79uwXL29TY76Z2rM5mHXA,
spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
On Tuesday 03 July 2012, Andrew Lunn wrote:
> Both IRQ and GPIO controllers can now be represented in DT. The IRQ
> controllers are setup first, and then the GPIO controllers. Interrupts
> for GPIO lines are placed directly after the main interrupts in the
> interrupt space.
Overall looks very good.
> diff --git a/Documentation/devicetree/bindings/arm/mrvl/intc.txt b/Documentation/devicetree/bindings/arm/mrvl/intc.txt
> index 80b9a94..8927e10 100644
> --- a/Documentation/devicetree/bindings/arm/mrvl/intc.txt
> +++ b/Documentation/devicetree/bindings/arm/mrvl/intc.txt
> @@ -38,3 +38,22 @@ Example:
> reg-names = "mux status", "mux mask";
> mrvl,intc-nr-irqs = <2>;
> };
> +
> +* Marvell Orion Interrupt controller
> +
> +Required properties
> +- compatible : Should be "marvell,orion-intc".
> +- #interrupt-cells: Specifies the number of cells needed to encode an
> + interrupt source. Supported value is <1>.
> +- interrupt-controller : Declare this node to be an interrupt controller.
> +- reg : Interrupt mask address.
I think you should clarify that the "reg" property can be multiple
4-byte ranges, because that is fairly unusual.
> +#ifdef CONFIG_OF
> +static int __init orion_add_irq_domain(struct device_node *np,
> + struct device_node *interrupt_parent)
> +{
> + int i = 0, irq_gpio;
> + void __iomem *base;
> +
> + do {
> + base = of_iomap(np, i);
> + if (base) {
> + orion_irq_init(i * 32, base);
> + i++;
> + }
> + } while (base);
> +
> + irq_domain_add_legacy(np, i * 32, 0, 0,
> + &irq_domain_simple_ops, NULL);
> +
> + irq_gpio = i * 32;
> + orion_gpio_of_init(irq_gpio);
> +
> + return 0;
> +}
> +
> +static const struct of_device_id orion_irq_match[] = {
> + { .compatible = "marvell,orion-intc",
> + .data = orion_add_irq_domain, },
> + {},
> +};
> +
> +void __init orion_dt_init_irq(void)
> +{
> + of_irq_init(orion_irq_match);
> +}
> +#endif
I'm wondering about this one. The other platforms usually put the secondary
interrupt controllers into the same match table, while you call orion_gpio_of_init
from orion_add_irq_domain. Can you explain why you do this? Does it have
any disadvantages?
Arnd
^ permalink raw reply [flat|nested] 130+ messages in thread* [PATCH v2 01/12] ARM: Orion: DT support for IRQ and GPIO Controllers
@ 2012-07-05 12:25 ` Arnd Bergmann
0 siblings, 0 replies; 130+ messages in thread
From: Arnd Bergmann @ 2012-07-05 12:25 UTC (permalink / raw)
To: linux-arm-kernel
On Tuesday 03 July 2012, Andrew Lunn wrote:
> Both IRQ and GPIO controllers can now be represented in DT. The IRQ
> controllers are setup first, and then the GPIO controllers. Interrupts
> for GPIO lines are placed directly after the main interrupts in the
> interrupt space.
Overall looks very good.
> diff --git a/Documentation/devicetree/bindings/arm/mrvl/intc.txt b/Documentation/devicetree/bindings/arm/mrvl/intc.txt
> index 80b9a94..8927e10 100644
> --- a/Documentation/devicetree/bindings/arm/mrvl/intc.txt
> +++ b/Documentation/devicetree/bindings/arm/mrvl/intc.txt
> @@ -38,3 +38,22 @@ Example:
> reg-names = "mux status", "mux mask";
> mrvl,intc-nr-irqs = <2>;
> };
> +
> +* Marvell Orion Interrupt controller
> +
> +Required properties
> +- compatible : Should be "marvell,orion-intc".
> +- #interrupt-cells: Specifies the number of cells needed to encode an
> + interrupt source. Supported value is <1>.
> +- interrupt-controller : Declare this node to be an interrupt controller.
> +- reg : Interrupt mask address.
I think you should clarify that the "reg" property can be multiple
4-byte ranges, because that is fairly unusual.
> +#ifdef CONFIG_OF
> +static int __init orion_add_irq_domain(struct device_node *np,
> + struct device_node *interrupt_parent)
> +{
> + int i = 0, irq_gpio;
> + void __iomem *base;
> +
> + do {
> + base = of_iomap(np, i);
> + if (base) {
> + orion_irq_init(i * 32, base);
> + i++;
> + }
> + } while (base);
> +
> + irq_domain_add_legacy(np, i * 32, 0, 0,
> + &irq_domain_simple_ops, NULL);
> +
> + irq_gpio = i * 32;
> + orion_gpio_of_init(irq_gpio);
> +
> + return 0;
> +}
> +
> +static const struct of_device_id orion_irq_match[] = {
> + { .compatible = "marvell,orion-intc",
> + .data = orion_add_irq_domain, },
> + {},
> +};
> +
> +void __init orion_dt_init_irq(void)
> +{
> + of_irq_init(orion_irq_match);
> +}
> +#endif
I'm wondering about this one. The other platforms usually put the secondary
interrupt controllers into the same match table, while you call orion_gpio_of_init
from orion_add_irq_domain. Can you explain why you do this? Does it have
any disadvantages?
Arnd
^ permalink raw reply [flat|nested] 130+ messages in thread[parent not found: <201207051225.55390.arnd-r2nGTMty4D4@public.gmane.org>]
* Re: [PATCH v2 01/12] ARM: Orion: DT support for IRQ and GPIO Controllers
2012-07-05 12:25 ` Arnd Bergmann
@ 2012-07-05 13:08 ` Andrew Lunn
-1 siblings, 0 replies; 130+ messages in thread
From: Andrew Lunn @ 2012-07-05 13:08 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Andrew Lunn,
Jason Cooper, devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
rob.herring-bsGFqQB8/DxBDgjK7y7TUQ,
grant.likely-s3s/WqlpOiPyB63q8FvJNQ, Michael Walle,
linux-i2c-u79uwXL29TY76Z2rM5mHXA,
spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
> > +Required properties
> > +- compatible : Should be "marvell,orion-intc".
> > +- #interrupt-cells: Specifies the number of cells needed to encode an
> > + interrupt source. Supported value is <1>.
> > +- interrupt-controller : Declare this node to be an interrupt controller.
> > +- reg : Interrupt mask address.
>
> I think you should clarify that the "reg" property can be multiple
> 4-byte ranges, because that is fairly unusual.
O.K. The example is already like this, but i can add some more words.
> > +#ifdef CONFIG_OF
> > +static int __init orion_add_irq_domain(struct device_node *np,
> > + struct device_node *interrupt_parent)
> > +{
> > + int i = 0, irq_gpio;
> > + void __iomem *base;
> > +
> > + do {
> > + base = of_iomap(np, i);
> > + if (base) {
> > + orion_irq_init(i * 32, base);
> > + i++;
> > + }
> > + } while (base);
> > +
> > + irq_domain_add_legacy(np, i * 32, 0, 0,
> > + &irq_domain_simple_ops, NULL);
> > +
> > + irq_gpio = i * 32;
> > + orion_gpio_of_init(irq_gpio);
> > +
> > + return 0;
> > +}
> > +
> > +static const struct of_device_id orion_irq_match[] = {
> > + { .compatible = "marvell,orion-intc",
> > + .data = orion_add_irq_domain, },
> > + {},
> > +};
> > +
> > +void __init orion_dt_init_irq(void)
> > +{
> > + of_irq_init(orion_irq_match);
> > +}
> > +#endif
>
> I'm wondering about this one. The other platforms usually put the secondary
> interrupt controllers into the same match table, while you call orion_gpio_of_init
> from orion_add_irq_domain. Can you explain why you do this? Does it have
> any disadvantages?
The issue is knowing what IRQ number to use for the secondary
interrupts.
Orion use generic chip interrupts, both for the main interrupts and
the GPIO interrupts. This does not yet support irq domain, so i have
to layer a legacy domain on top. The legacy domain needs to know the
first IRQ and the number of IRQs. For the primary IRQs that is
easy. However, GPIO IRQ is not so easy, it depends on how many primary
IRQs there are. This is not fixed. Orion5x has 32, Dove 64, kirkwood,
64, and mv78xx0 has 96. I need to know this number when adding the
GPIO secondary IRQ legacy domain. By calling orion_gpio_of_init() in
the orion_add_irq_domain() i have this number to hand. If i used to
entries in the match table, i would have to put this number into some
global variable, or somehow ask the IRQ subsystem what the next free
IRQ number is.
As for disadvantages, humm. Dove has yet more interrupts, from the
PMU. They are currently unsupported in DT. When we add support for the
PMU interrupt controller, we are going to have the same problem, what
IRQ base should it use. Either we extend the chaining, calling
dove_pmu_of_init from orion_gpio_of_init(), where we know the next
free IRQ. Or we find out how to ask the IRQ subsystem for the next
available. Better still, the work to make generic chip interrupts irq
domain aware would get completed, and we can swap all this code to irq
domain linear and this whole probable probably goes away.
Andrew
^ permalink raw reply [flat|nested] 130+ messages in thread* [PATCH v2 01/12] ARM: Orion: DT support for IRQ and GPIO Controllers
@ 2012-07-05 13:08 ` Andrew Lunn
0 siblings, 0 replies; 130+ messages in thread
From: Andrew Lunn @ 2012-07-05 13:08 UTC (permalink / raw)
To: linux-arm-kernel
> > +Required properties
> > +- compatible : Should be "marvell,orion-intc".
> > +- #interrupt-cells: Specifies the number of cells needed to encode an
> > + interrupt source. Supported value is <1>.
> > +- interrupt-controller : Declare this node to be an interrupt controller.
> > +- reg : Interrupt mask address.
>
> I think you should clarify that the "reg" property can be multiple
> 4-byte ranges, because that is fairly unusual.
O.K. The example is already like this, but i can add some more words.
> > +#ifdef CONFIG_OF
> > +static int __init orion_add_irq_domain(struct device_node *np,
> > + struct device_node *interrupt_parent)
> > +{
> > + int i = 0, irq_gpio;
> > + void __iomem *base;
> > +
> > + do {
> > + base = of_iomap(np, i);
> > + if (base) {
> > + orion_irq_init(i * 32, base);
> > + i++;
> > + }
> > + } while (base);
> > +
> > + irq_domain_add_legacy(np, i * 32, 0, 0,
> > + &irq_domain_simple_ops, NULL);
> > +
> > + irq_gpio = i * 32;
> > + orion_gpio_of_init(irq_gpio);
> > +
> > + return 0;
> > +}
> > +
> > +static const struct of_device_id orion_irq_match[] = {
> > + { .compatible = "marvell,orion-intc",
> > + .data = orion_add_irq_domain, },
> > + {},
> > +};
> > +
> > +void __init orion_dt_init_irq(void)
> > +{
> > + of_irq_init(orion_irq_match);
> > +}
> > +#endif
>
> I'm wondering about this one. The other platforms usually put the secondary
> interrupt controllers into the same match table, while you call orion_gpio_of_init
> from orion_add_irq_domain. Can you explain why you do this? Does it have
> any disadvantages?
The issue is knowing what IRQ number to use for the secondary
interrupts.
Orion use generic chip interrupts, both for the main interrupts and
the GPIO interrupts. This does not yet support irq domain, so i have
to layer a legacy domain on top. The legacy domain needs to know the
first IRQ and the number of IRQs. For the primary IRQs that is
easy. However, GPIO IRQ is not so easy, it depends on how many primary
IRQs there are. This is not fixed. Orion5x has 32, Dove 64, kirkwood,
64, and mv78xx0 has 96. I need to know this number when adding the
GPIO secondary IRQ legacy domain. By calling orion_gpio_of_init() in
the orion_add_irq_domain() i have this number to hand. If i used to
entries in the match table, i would have to put this number into some
global variable, or somehow ask the IRQ subsystem what the next free
IRQ number is.
As for disadvantages, humm. Dove has yet more interrupts, from the
PMU. They are currently unsupported in DT. When we add support for the
PMU interrupt controller, we are going to have the same problem, what
IRQ base should it use. Either we extend the chaining, calling
dove_pmu_of_init from orion_gpio_of_init(), where we know the next
free IRQ. Or we find out how to ask the IRQ subsystem for the next
available. Better still, the work to make generic chip interrupts irq
domain aware would get completed, and we can swap all this code to irq
domain linear and this whole probable probably goes away.
Andrew
^ permalink raw reply [flat|nested] 130+ messages in thread[parent not found: <20120705130819.GV17534-g2DYL2Zd6BY@public.gmane.org>]
* Re: [PATCH v2 01/12] ARM: Orion: DT support for IRQ and GPIO Controllers
2012-07-05 13:08 ` Andrew Lunn
@ 2012-07-05 13:47 ` Arnd Bergmann
-1 siblings, 0 replies; 130+ messages in thread
From: Arnd Bergmann @ 2012-07-05 13:47 UTC (permalink / raw)
To: Andrew Lunn
Cc: Jason Cooper, devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
rob.herring-bsGFqQB8/DxBDgjK7y7TUQ, Michael Walle,
linux-i2c-u79uwXL29TY76Z2rM5mHXA,
spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
On Thursday 05 July 2012, Andrew Lunn wrote:
> >
> > I'm wondering about this one. The other platforms usually put the secondary
> > interrupt controllers into the same match table, while you call orion_gpio_of_init
> > from orion_add_irq_domain. Can you explain why you do this? Does it have
> > any disadvantages?
>
> The issue is knowing what IRQ number to use for the secondary
> interrupts.
>
> Orion use generic chip interrupts, both for the main interrupts and
> the GPIO interrupts. This does not yet support irq domain, so i have
> to layer a legacy domain on top. The legacy domain needs to know the
> first IRQ and the number of IRQs. For the primary IRQs that is
> easy. However, GPIO IRQ is not so easy, it depends on how many primary
> IRQs there are. This is not fixed. Orion5x has 32, Dove 64, kirkwood,
> 64, and mv78xx0 has 96. I need to know this number when adding the
> GPIO secondary IRQ legacy domain. By calling orion_gpio_of_init() in
> the orion_add_irq_domain() i have this number to hand. If i used to
> entries in the match table, i would have to put this number into some
> global variable, or somehow ask the IRQ subsystem what the next free
> IRQ number is.
But couldn't you store the number of interrupts for the primary controller
in a local variable? I think the of_irq code already guarantees that
the parent is probed first.
> As for disadvantages, humm. Dove has yet more interrupts, from the
> PMU. They are currently unsupported in DT. When we add support for the
> PMU interrupt controller, we are going to have the same problem, what
> IRQ base should it use. Either we extend the chaining, calling
> dove_pmu_of_init from orion_gpio_of_init(), where we know the next
> free IRQ. Or we find out how to ask the IRQ subsystem for the next
> available. Better still, the work to make generic chip interrupts irq
> domain aware would get completed, and we can swap all this code to irq
> domain linear and this whole probable probably goes away.
Yes, that makes sense. Using the linear domain should solve all these
nicely.
Arnd
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
^ permalink raw reply [flat|nested] 130+ messages in thread
* [PATCH v2 01/12] ARM: Orion: DT support for IRQ and GPIO Controllers
@ 2012-07-05 13:47 ` Arnd Bergmann
0 siblings, 0 replies; 130+ messages in thread
From: Arnd Bergmann @ 2012-07-05 13:47 UTC (permalink / raw)
To: linux-arm-kernel
On Thursday 05 July 2012, Andrew Lunn wrote:
> >
> > I'm wondering about this one. The other platforms usually put the secondary
> > interrupt controllers into the same match table, while you call orion_gpio_of_init
> > from orion_add_irq_domain. Can you explain why you do this? Does it have
> > any disadvantages?
>
> The issue is knowing what IRQ number to use for the secondary
> interrupts.
>
> Orion use generic chip interrupts, both for the main interrupts and
> the GPIO interrupts. This does not yet support irq domain, so i have
> to layer a legacy domain on top. The legacy domain needs to know the
> first IRQ and the number of IRQs. For the primary IRQs that is
> easy. However, GPIO IRQ is not so easy, it depends on how many primary
> IRQs there are. This is not fixed. Orion5x has 32, Dove 64, kirkwood,
> 64, and mv78xx0 has 96. I need to know this number when adding the
> GPIO secondary IRQ legacy domain. By calling orion_gpio_of_init() in
> the orion_add_irq_domain() i have this number to hand. If i used to
> entries in the match table, i would have to put this number into some
> global variable, or somehow ask the IRQ subsystem what the next free
> IRQ number is.
But couldn't you store the number of interrupts for the primary controller
in a local variable? I think the of_irq code already guarantees that
the parent is probed first.
> As for disadvantages, humm. Dove has yet more interrupts, from the
> PMU. They are currently unsupported in DT. When we add support for the
> PMU interrupt controller, we are going to have the same problem, what
> IRQ base should it use. Either we extend the chaining, calling
> dove_pmu_of_init from orion_gpio_of_init(), where we know the next
> free IRQ. Or we find out how to ask the IRQ subsystem for the next
> available. Better still, the work to make generic chip interrupts irq
> domain aware would get completed, and we can swap all this code to irq
> domain linear and this whole probable probably goes away.
Yes, that makes sense. Using the linear domain should solve all these
nicely.
Arnd
^ permalink raw reply [flat|nested] 130+ messages in thread
[parent not found: <201207051347.38887.arnd-r2nGTMty4D4@public.gmane.org>]
* Re: [PATCH v2 01/12] ARM: Orion: DT support for IRQ and GPIO Controllers
2012-07-05 13:47 ` Arnd Bergmann
@ 2012-07-05 13:54 ` Andrew Lunn
-1 siblings, 0 replies; 130+ messages in thread
From: Andrew Lunn @ 2012-07-05 13:54 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Andrew Lunn, Jason Cooper,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
rob.herring-bsGFqQB8/DxBDgjK7y7TUQ,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
> > Orion use generic chip interrupts, both for the main interrupts and
> > the GPIO interrupts. This does not yet support irq domain, so i have
> > to layer a legacy domain on top. The legacy domain needs to know the
> > first IRQ and the number of IRQs. For the primary IRQs that is
> > easy. However, GPIO IRQ is not so easy, it depends on how many primary
> > IRQs there are. This is not fixed. Orion5x has 32, Dove 64, kirkwood,
> > 64, and mv78xx0 has 96. I need to know this number when adding the
> > GPIO secondary IRQ legacy domain. By calling orion_gpio_of_init() in
> > the orion_add_irq_domain() i have this number to hand. If i used to
> > entries in the match table, i would have to put this number into some
> > global variable, or somehow ask the IRQ subsystem what the next free
> > IRQ number is.
>
> But couldn't you store the number of interrupts for the primary controller
> in a local variable? I think the of_irq code already guarantees that
> the parent is probed first.
Sure i could. But what is the advantage of that?
Andrew
^ permalink raw reply [flat|nested] 130+ messages in thread* [PATCH v2 01/12] ARM: Orion: DT support for IRQ and GPIO Controllers
@ 2012-07-05 13:54 ` Andrew Lunn
0 siblings, 0 replies; 130+ messages in thread
From: Andrew Lunn @ 2012-07-05 13:54 UTC (permalink / raw)
To: linux-arm-kernel
> > Orion use generic chip interrupts, both for the main interrupts and
> > the GPIO interrupts. This does not yet support irq domain, so i have
> > to layer a legacy domain on top. The legacy domain needs to know the
> > first IRQ and the number of IRQs. For the primary IRQs that is
> > easy. However, GPIO IRQ is not so easy, it depends on how many primary
> > IRQs there are. This is not fixed. Orion5x has 32, Dove 64, kirkwood,
> > 64, and mv78xx0 has 96. I need to know this number when adding the
> > GPIO secondary IRQ legacy domain. By calling orion_gpio_of_init() in
> > the orion_add_irq_domain() i have this number to hand. If i used to
> > entries in the match table, i would have to put this number into some
> > global variable, or somehow ask the IRQ subsystem what the next free
> > IRQ number is.
>
> But couldn't you store the number of interrupts for the primary controller
> in a local variable? I think the of_irq code already guarantees that
> the parent is probed first.
Sure i could. But what is the advantage of that?
Andrew
^ permalink raw reply [flat|nested] 130+ messages in thread[parent not found: <20120705135449.GZ17534-g2DYL2Zd6BY@public.gmane.org>]
* Re: [PATCH v2 01/12] ARM: Orion: DT support for IRQ and GPIO Controllers
2012-07-05 13:54 ` Andrew Lunn
@ 2012-07-05 15:47 ` Arnd Bergmann
-1 siblings, 0 replies; 130+ messages in thread
From: Arnd Bergmann @ 2012-07-05 15:47 UTC (permalink / raw)
To: Andrew Lunn
Cc: Jason Cooper, devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
rob.herring-bsGFqQB8/DxBDgjK7y7TUQ,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
On Thursday 05 July 2012, Andrew Lunn wrote:
> > > Orion use generic chip interrupts, both for the main interrupts and
> > > the GPIO interrupts. This does not yet support irq domain, so i have
> > > to layer a legacy domain on top. The legacy domain needs to know the
> > > first IRQ and the number of IRQs. For the primary IRQs that is
> > > easy. However, GPIO IRQ is not so easy, it depends on how many primary
> > > IRQs there are. This is not fixed. Orion5x has 32, Dove 64, kirkwood,
> > > 64, and mv78xx0 has 96. I need to know this number when adding the
> > > GPIO secondary IRQ legacy domain. By calling orion_gpio_of_init() in
> > > the orion_add_irq_domain() i have this number to hand. If i used to
> > > entries in the match table, i would have to put this number into some
> > > global variable, or somehow ask the IRQ subsystem what the next free
> > > IRQ number is.
> >
> > But couldn't you store the number of interrupts for the primary controller
> > in a local variable? I think the of_irq code already guarantees that
> > the parent is probed first.
>
> Sure i could. But what is the advantage of that?
Probably not much. I've reread the of_irq_init code again and it seems that
the effect would be the same, perhaps appearing a little more similar to what
the other platforms do.
Please add my Acked-by: to your patch.
Arnd
^ permalink raw reply [flat|nested] 130+ messages in thread
* [PATCH v2 01/12] ARM: Orion: DT support for IRQ and GPIO Controllers
@ 2012-07-05 15:47 ` Arnd Bergmann
0 siblings, 0 replies; 130+ messages in thread
From: Arnd Bergmann @ 2012-07-05 15:47 UTC (permalink / raw)
To: linux-arm-kernel
On Thursday 05 July 2012, Andrew Lunn wrote:
> > > Orion use generic chip interrupts, both for the main interrupts and
> > > the GPIO interrupts. This does not yet support irq domain, so i have
> > > to layer a legacy domain on top. The legacy domain needs to know the
> > > first IRQ and the number of IRQs. For the primary IRQs that is
> > > easy. However, GPIO IRQ is not so easy, it depends on how many primary
> > > IRQs there are. This is not fixed. Orion5x has 32, Dove 64, kirkwood,
> > > 64, and mv78xx0 has 96. I need to know this number when adding the
> > > GPIO secondary IRQ legacy domain. By calling orion_gpio_of_init() in
> > > the orion_add_irq_domain() i have this number to hand. If i used to
> > > entries in the match table, i would have to put this number into some
> > > global variable, or somehow ask the IRQ subsystem what the next free
> > > IRQ number is.
> >
> > But couldn't you store the number of interrupts for the primary controller
> > in a local variable? I think the of_irq code already guarantees that
> > the parent is probed first.
>
> Sure i could. But what is the advantage of that?
Probably not much. I've reread the of_irq_init code again and it seems that
the effect would be the same, perhaps appearing a little more similar to what
the other platforms do.
Please add my Acked-by: to your patch.
Arnd
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: [PATCH v2 01/12] ARM: Orion: DT support for IRQ and GPIO Controllers
2012-07-05 13:08 ` Andrew Lunn
@ 2012-07-05 14:14 ` Sebastian Hesselbarth
-1 siblings, 0 replies; 130+ messages in thread
From: Sebastian Hesselbarth @ 2012-07-05 14:14 UTC (permalink / raw)
To: Arnd Bergmann, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Andrew Lunn, Jason Cooper,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
rob.herring-bsGFqQB8/DxBDgjK7y7TUQ,
grant.likely-s3s/WqlpOiPyB63q8FvJNQ, Michael Walle,
linux-i2c-u79uwXL29TY76Z2rM5mHXA,
spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
On 07/05/2012 03:08 PM, Andrew Lunn wrote:
> The issue is knowing what IRQ number to use for the secondary
> interrupts.
>
> Orion use generic chip interrupts, both for the main interrupts and
> the GPIO interrupts. This does not yet support irq domain, so i have
> to layer a legacy domain on top. The legacy domain needs to know the
> first IRQ and the number of IRQs. For the primary IRQs that is
> easy. However, GPIO IRQ is not so easy, it depends on how many primary
> IRQs there are. This is not fixed. Orion5x has 32, Dove 64, kirkwood,
> 64, and mv78xx0 has 96. I need to know this number when adding the
> GPIO secondary IRQ legacy domain. By calling orion_gpio_of_init() in
> the orion_add_irq_domain() i have this number to hand. If i used to
> entries in the match table, i would have to put this number into some
> global variable, or somehow ask the IRQ subsystem what the next free
> IRQ number is.
Andrew,
is it possible to group all gpio banks into one DT description?
For mach-dove it could be something like:
gpio: gpio-controller {
compatible = "marvell, orion-gpio";
...
bank0@d0400 {
reg = <0xd0400 0x40>;
ngpio = <8>;
mask-offset = <0>;
interrupts = <12>;
};
bank1@d0400 {
reg = <0xd0400 0x40>;
ngpio = <8>;
mask-offset = <8>;
interrupts = <13>;
};
...
bank4@d0420 {
reg = <0xd0420 0x40>;
ngpio = <32>;
interrupts = <61>;
};
bank5@e8400 {
reg = <0xe8400 0x20>;
ngpio = <8>;
marvell,orion-gpio-output-only;
};
};
This would have the advantage that DT describes gpio-to-irq dependencies.
Moreover, nodes that reference gpios can do gpios = <&gpio 71 0>; instead of
gpios = <&gpio3 7 0>;
Sebastian
^ permalink raw reply [flat|nested] 130+ messages in thread* [PATCH v2 01/12] ARM: Orion: DT support for IRQ and GPIO Controllers
@ 2012-07-05 14:14 ` Sebastian Hesselbarth
0 siblings, 0 replies; 130+ messages in thread
From: Sebastian Hesselbarth @ 2012-07-05 14:14 UTC (permalink / raw)
To: linux-arm-kernel
On 07/05/2012 03:08 PM, Andrew Lunn wrote:
> The issue is knowing what IRQ number to use for the secondary
> interrupts.
>
> Orion use generic chip interrupts, both for the main interrupts and
> the GPIO interrupts. This does not yet support irq domain, so i have
> to layer a legacy domain on top. The legacy domain needs to know the
> first IRQ and the number of IRQs. For the primary IRQs that is
> easy. However, GPIO IRQ is not so easy, it depends on how many primary
> IRQs there are. This is not fixed. Orion5x has 32, Dove 64, kirkwood,
> 64, and mv78xx0 has 96. I need to know this number when adding the
> GPIO secondary IRQ legacy domain. By calling orion_gpio_of_init() in
> the orion_add_irq_domain() i have this number to hand. If i used to
> entries in the match table, i would have to put this number into some
> global variable, or somehow ask the IRQ subsystem what the next free
> IRQ number is.
Andrew,
is it possible to group all gpio banks into one DT description?
For mach-dove it could be something like:
gpio: gpio-controller {
compatible = "marvell, orion-gpio";
...
bank0 at d0400 {
reg = <0xd0400 0x40>;
ngpio = <8>;
mask-offset = <0>;
interrupts = <12>;
};
bank1 at d0400 {
reg = <0xd0400 0x40>;
ngpio = <8>;
mask-offset = <8>;
interrupts = <13>;
};
...
bank4 at d0420 {
reg = <0xd0420 0x40>;
ngpio = <32>;
interrupts = <61>;
};
bank5 at e8400 {
reg = <0xe8400 0x20>;
ngpio = <8>;
marvell,orion-gpio-output-only;
};
};
This would have the advantage that DT describes gpio-to-irq dependencies.
Moreover, nodes that reference gpios can do gpios = <&gpio 71 0>; instead of
gpios = <&gpio3 7 0>;
Sebastian
^ permalink raw reply [flat|nested] 130+ messages in thread[parent not found: <4FF5A15A.8070309-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>]
* Re: [PATCH v2 01/12] ARM: Orion: DT support for IRQ and GPIO Controllers
2012-07-05 14:14 ` Sebastian Hesselbarth
@ 2012-07-05 14:43 ` Andrew Lunn
-1 siblings, 0 replies; 130+ messages in thread
From: Andrew Lunn @ 2012-07-05 14:43 UTC (permalink / raw)
To: Sebastian Hesselbarth
Cc: Andrew Lunn, Jason Cooper,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
rob.herring-bsGFqQB8/DxBDgjK7y7TUQ,
linux-i2c-u79uwXL29TY76Z2rM5mHXA,
spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
On Thu, Jul 05, 2012 at 04:14:50PM +0200, Sebastian Hesselbarth wrote:
> On 07/05/2012 03:08 PM, Andrew Lunn wrote:
> >The issue is knowing what IRQ number to use for the secondary
> >interrupts.
> >
> >Orion use generic chip interrupts, both for the main interrupts and
> >the GPIO interrupts. This does not yet support irq domain, so i have
> >to layer a legacy domain on top. The legacy domain needs to know the
> >first IRQ and the number of IRQs. For the primary IRQs that is
> >easy. However, GPIO IRQ is not so easy, it depends on how many primary
> >IRQs there are. This is not fixed. Orion5x has 32, Dove 64, kirkwood,
> >64, and mv78xx0 has 96. I need to know this number when adding the
> >GPIO secondary IRQ legacy domain. By calling orion_gpio_of_init() in
> >the orion_add_irq_domain() i have this number to hand. If i used to
> >entries in the match table, i would have to put this number into some
> >global variable, or somehow ask the IRQ subsystem what the next free
> >IRQ number is.
>
> Andrew,
>
> is it possible to group all gpio banks into one DT description?
Everything is possible.
I did think about having just one gpio controller, since as you said,
it makes it easier to describe gpios = <&gpio 71 0>; instead of gpios
= <&gpio3 7 0>; But most SoCs seem to have multiple GPIO controllers
in the .dtsi files. Only picoxcell has banks inside a single gpio
controller. So it would be a bit unusual.
What you suggest also adds a lot of complexity to the code and
probably means a lot less of the code can be shared with non-DT GPIO
handling code.
The natural size of a GPIO controller is 32 lines, not 8. The current
interrupt handling does not actually care which IRQ of a bank of 32
lines fired, it looks at all lines. The handler_data in the IRQ points
to the GPIO chip, not a subsection of the GPIO chip.
> bank5@e8400 {
> reg = <0xe8400 0x20>;
> ngpio = <8>;
> marvell,orion-gpio-output-only;
Some Orions mixed GPIOs GPOs and GPIs within one controller. So that
is not generic enough. Probably the pinmux DT description needs to be
able to specify per pin what a line can do.
Andrew
^ permalink raw reply [flat|nested] 130+ messages in thread* [PATCH v2 01/12] ARM: Orion: DT support for IRQ and GPIO Controllers
@ 2012-07-05 14:43 ` Andrew Lunn
0 siblings, 0 replies; 130+ messages in thread
From: Andrew Lunn @ 2012-07-05 14:43 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Jul 05, 2012 at 04:14:50PM +0200, Sebastian Hesselbarth wrote:
> On 07/05/2012 03:08 PM, Andrew Lunn wrote:
> >The issue is knowing what IRQ number to use for the secondary
> >interrupts.
> >
> >Orion use generic chip interrupts, both for the main interrupts and
> >the GPIO interrupts. This does not yet support irq domain, so i have
> >to layer a legacy domain on top. The legacy domain needs to know the
> >first IRQ and the number of IRQs. For the primary IRQs that is
> >easy. However, GPIO IRQ is not so easy, it depends on how many primary
> >IRQs there are. This is not fixed. Orion5x has 32, Dove 64, kirkwood,
> >64, and mv78xx0 has 96. I need to know this number when adding the
> >GPIO secondary IRQ legacy domain. By calling orion_gpio_of_init() in
> >the orion_add_irq_domain() i have this number to hand. If i used to
> >entries in the match table, i would have to put this number into some
> >global variable, or somehow ask the IRQ subsystem what the next free
> >IRQ number is.
>
> Andrew,
>
> is it possible to group all gpio banks into one DT description?
Everything is possible.
I did think about having just one gpio controller, since as you said,
it makes it easier to describe gpios = <&gpio 71 0>; instead of gpios
= <&gpio3 7 0>; But most SoCs seem to have multiple GPIO controllers
in the .dtsi files. Only picoxcell has banks inside a single gpio
controller. So it would be a bit unusual.
What you suggest also adds a lot of complexity to the code and
probably means a lot less of the code can be shared with non-DT GPIO
handling code.
The natural size of a GPIO controller is 32 lines, not 8. The current
interrupt handling does not actually care which IRQ of a bank of 32
lines fired, it looks at all lines. The handler_data in the IRQ points
to the GPIO chip, not a subsection of the GPIO chip.
> bank5 at e8400 {
> reg = <0xe8400 0x20>;
> ngpio = <8>;
> marvell,orion-gpio-output-only;
Some Orions mixed GPIOs GPOs and GPIs within one controller. So that
is not generic enough. Probably the pinmux DT description needs to be
able to specify per pin what a line can do.
Andrew
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: [PATCH v2 01/12] ARM: Orion: DT support for IRQ and GPIO Controllers
2012-07-05 14:14 ` Sebastian Hesselbarth
@ 2012-07-05 14:54 ` Arnd Bergmann
-1 siblings, 0 replies; 130+ messages in thread
From: Arnd Bergmann @ 2012-07-05 14:54 UTC (permalink / raw)
To: Sebastian Hesselbarth
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Andrew Lunn,
Jason Cooper, devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
rob.herring-bsGFqQB8/DxBDgjK7y7TUQ,
grant.likely-s3s/WqlpOiPyB63q8FvJNQ, Michael Walle,
linux-i2c-u79uwXL29TY76Z2rM5mHXA,
spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
On Thursday 05 July 2012, Sebastian Hesselbarth wrote:
> Andrew,
>
> is it possible to group all gpio banks into one DT description?
> For mach-dove it could be something like:
>
> gpio: gpio-controller {
> compatible = "marvell, orion-gpio";
> ...
>
> bank0@d0400 {
> reg = <0xd0400 0x40>;
> ngpio = <8>;
> mask-offset = <0>;
> interrupts = <12>;
> };
>
> bank1@d0400 {
> reg = <0xd0400 0x40>;
> ngpio = <8>;
> mask-offset = <8>;
> interrupts = <13>;
> };
This way you have multiple nodes with the same register
and different names, which is not how it normally works.
>
> This would have the advantage that DT describes gpio-to-irq dependencies.
> Moreover, nodes that reference gpios can do gpios = <&gpio 71 0>; instead of
> gpios = <&gpio3 7 0>;
Is that desired?
The device tree representation should match what is in the data sheet
normally. If they are in a single continuous number range, then we should
probably have a single device node with multiple register ranges
rather than one device node for each 32-bit register. Looking at
arch/arm/plat-orion/gpio.c I think that is not actually the case though
and having separate banks is more logical.
Something completely different I just noticed in the original patch:
> @@ -90,6 +74,27 @@ static void pmu_irq_handler(unsigned int irq, struct irq_desc *desc)
> }
> }
>
> +static int __initdata gpio0_irqs[4] = {
> + IRQ_DOVE_GPIO_0_7,
> + IRQ_DOVE_GPIO_8_15,
> + IRQ_DOVE_GPIO_16_23,
> + IRQ_DOVE_GPIO_24_31,
> +};
> +
> +static int __initdata gpio1_irqs[4] = {
> + IRQ_DOVE_HIGH_GPIO,
> + 0,
> + 0,
> + 0,
> +};
I think the latter one needs to be
+static int __initdata gpio1_irqs[4] = {
+ IRQ_DOVE_HIGH_GPIO,
+ IRQ_DOVE_HIGH_GPIO,
+ IRQ_DOVE_HIGH_GPIO,
+ IRQ_DOVE_HIGH_GPIO,
+};
so we register all four parts to the same primary IRQ. The
same is true for the devicetree representation.
Arnd
^ permalink raw reply [flat|nested] 130+ messages in thread* [PATCH v2 01/12] ARM: Orion: DT support for IRQ and GPIO Controllers
@ 2012-07-05 14:54 ` Arnd Bergmann
0 siblings, 0 replies; 130+ messages in thread
From: Arnd Bergmann @ 2012-07-05 14:54 UTC (permalink / raw)
To: linux-arm-kernel
On Thursday 05 July 2012, Sebastian Hesselbarth wrote:
> Andrew,
>
> is it possible to group all gpio banks into one DT description?
> For mach-dove it could be something like:
>
> gpio: gpio-controller {
> compatible = "marvell, orion-gpio";
> ...
>
> bank0 at d0400 {
> reg = <0xd0400 0x40>;
> ngpio = <8>;
> mask-offset = <0>;
> interrupts = <12>;
> };
>
> bank1 at d0400 {
> reg = <0xd0400 0x40>;
> ngpio = <8>;
> mask-offset = <8>;
> interrupts = <13>;
> };
This way you have multiple nodes with the same register
and different names, which is not how it normally works.
>
> This would have the advantage that DT describes gpio-to-irq dependencies.
> Moreover, nodes that reference gpios can do gpios = <&gpio 71 0>; instead of
> gpios = <&gpio3 7 0>;
Is that desired?
The device tree representation should match what is in the data sheet
normally. If they are in a single continuous number range, then we should
probably have a single device node with multiple register ranges
rather than one device node for each 32-bit register. Looking at
arch/arm/plat-orion/gpio.c I think that is not actually the case though
and having separate banks is more logical.
Something completely different I just noticed in the original patch:
> @@ -90,6 +74,27 @@ static void pmu_irq_handler(unsigned int irq, struct irq_desc *desc)
> }
> }
>
> +static int __initdata gpio0_irqs[4] = {
> + IRQ_DOVE_GPIO_0_7,
> + IRQ_DOVE_GPIO_8_15,
> + IRQ_DOVE_GPIO_16_23,
> + IRQ_DOVE_GPIO_24_31,
> +};
> +
> +static int __initdata gpio1_irqs[4] = {
> + IRQ_DOVE_HIGH_GPIO,
> + 0,
> + 0,
> + 0,
> +};
I think the latter one needs to be
+static int __initdata gpio1_irqs[4] = {
+ IRQ_DOVE_HIGH_GPIO,
+ IRQ_DOVE_HIGH_GPIO,
+ IRQ_DOVE_HIGH_GPIO,
+ IRQ_DOVE_HIGH_GPIO,
+};
so we register all four parts to the same primary IRQ. The
same is true for the devicetree representation.
Arnd
^ permalink raw reply [flat|nested] 130+ messages in thread[parent not found: <201207051454.24475.arnd-r2nGTMty4D4@public.gmane.org>]
* Re: [PATCH v2 01/12] ARM: Orion: DT support for IRQ and GPIO Controllers
2012-07-05 14:54 ` Arnd Bergmann
@ 2012-07-05 15:51 ` Sebastian Hesselbarth
-1 siblings, 0 replies; 130+ messages in thread
From: Sebastian Hesselbarth @ 2012-07-05 15:51 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Andrew Lunn,
Jason Cooper, devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
rob.herring-bsGFqQB8/DxBDgjK7y7TUQ,
grant.likely-s3s/WqlpOiPyB63q8FvJNQ, Michael Walle,
linux-i2c-u79uwXL29TY76Z2rM5mHXA,
spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
On 07/05/2012 04:54 PM, Arnd Bergmann wrote:
> This way you have multiple nodes with the same register
> and different names, which is not how it normally works.
Ok.
>> This would have the advantage that DT describes gpio-to-irq dependencies.
>> Moreover, nodes that reference gpios can do gpios =<&gpio 71 0>; instead of
>> gpios =<&gpio3 7 0>;
>
> Is that desired?
>
> The device tree representation should match what is in the data sheet
> normally. If they are in a single continuous number range, then we should
> probably have a single device node with multiple register ranges
> rather than one device node for each 32-bit register. Looking at
> arch/arm/plat-orion/gpio.c I think that is not actually the case though
> and having separate banks is more logical.
Well, looking at the datasheet of Dove GPIOs are numbered [63:0] plus
GPOs [71:64]. This dt will be a lot shorter and maybe it is describing
the hardware as it is. (Not sure about the syntax for irqs, though)
gpio@d0400 {
compatible = "marvell,orion-gpio";
gpio-controller;
reg = <0xd0400 0x20>, /* GPIO[31: 0] */
<0xd0420 0x20>, /* GPIO[63:32] */
<0xe8400 0x0c>; /* GPO [71:64] */
ngpio = <72>;
interrupts = <12 13 14 15>, <61>;
};
Sebastian
^ permalink raw reply [flat|nested] 130+ messages in thread* [PATCH v2 01/12] ARM: Orion: DT support for IRQ and GPIO Controllers
@ 2012-07-05 15:51 ` Sebastian Hesselbarth
0 siblings, 0 replies; 130+ messages in thread
From: Sebastian Hesselbarth @ 2012-07-05 15:51 UTC (permalink / raw)
To: linux-arm-kernel
On 07/05/2012 04:54 PM, Arnd Bergmann wrote:
> This way you have multiple nodes with the same register
> and different names, which is not how it normally works.
Ok.
>> This would have the advantage that DT describes gpio-to-irq dependencies.
>> Moreover, nodes that reference gpios can do gpios =<&gpio 71 0>; instead of
>> gpios =<&gpio3 7 0>;
>
> Is that desired?
>
> The device tree representation should match what is in the data sheet
> normally. If they are in a single continuous number range, then we should
> probably have a single device node with multiple register ranges
> rather than one device node for each 32-bit register. Looking at
> arch/arm/plat-orion/gpio.c I think that is not actually the case though
> and having separate banks is more logical.
Well, looking at the datasheet of Dove GPIOs are numbered [63:0] plus
GPOs [71:64]. This dt will be a lot shorter and maybe it is describing
the hardware as it is. (Not sure about the syntax for irqs, though)
gpio at d0400 {
compatible = "marvell,orion-gpio";
gpio-controller;
reg = <0xd0400 0x20>, /* GPIO[31: 0] */
<0xd0420 0x20>, /* GPIO[63:32] */
<0xe8400 0x0c>; /* GPO [71:64] */
ngpio = <72>;
interrupts = <12 13 14 15>, <61>;
};
Sebastian
^ permalink raw reply [flat|nested] 130+ messages in thread[parent not found: <4FF5B7F9.9020507-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>]
* Re: [PATCH v2 01/12] ARM: Orion: DT support for IRQ and GPIO Controllers
2012-07-05 15:51 ` Sebastian Hesselbarth
@ 2012-07-05 16:30 ` Arnaud Patard (Rtp)
-1 siblings, 0 replies; 130+ messages in thread
From: Arnaud Patard @ 2012-07-05 16:30 UTC (permalink / raw)
To: Sebastian Hesselbarth
Cc: Arnd Bergmann, Andrew Lunn, Jason Cooper,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
rob.herring-bsGFqQB8/DxBDgjK7y7TUQ,
grant.likely-s3s/WqlpOiPyB63q8FvJNQ, Michael Walle,
linux-i2c-u79uwXL29TY76Z2rM5mHXA,
spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Sebastian Hesselbarth <sebastian.hesselbarth-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org> writes:
> On 07/05/2012 04:54 PM, Arnd Bergmann wrote:
>> This way you have multiple nodes with the same register
>> and different names, which is not how it normally works.
>
> Ok.
>
>>> This would have the advantage that DT describes gpio-to-irq dependencies.
>>> Moreover, nodes that reference gpios can do gpios =<&gpio 71 0>; instead of
>>> gpios =<&gpio3 7 0>;
>>
>> Is that desired?
>>
>> The device tree representation should match what is in the data sheet
>> normally. If they are in a single continuous number range, then we should
>> probably have a single device node with multiple register ranges
>> rather than one device node for each 32-bit register. Looking at
>> arch/arm/plat-orion/gpio.c I think that is not actually the case though
>> and having separate banks is more logical.
>
> Well, looking at the datasheet of Dove GPIOs are numbered [63:0] plus
> GPOs [71:64]. This dt will be a lot shorter and maybe it is describing
> the hardware as it is. (Not sure about the syntax for irqs, though)
They're numbered as [63:0] and [71:64] but they're on 3 different banks.
iirc, there may even be some differences with the way the banks are dealing
interrupts, so I don't see any reason to not represent the 3 banks in DT.
Arnaud
^ permalink raw reply [flat|nested] 130+ messages in thread
* [PATCH v2 01/12] ARM: Orion: DT support for IRQ and GPIO Controllers
@ 2012-07-05 16:30 ` Arnaud Patard (Rtp)
0 siblings, 0 replies; 130+ messages in thread
From: Arnaud Patard (Rtp) @ 2012-07-05 16:30 UTC (permalink / raw)
To: linux-arm-kernel
Sebastian Hesselbarth <sebastian.hesselbarth@googlemail.com> writes:
> On 07/05/2012 04:54 PM, Arnd Bergmann wrote:
>> This way you have multiple nodes with the same register
>> and different names, which is not how it normally works.
>
> Ok.
>
>>> This would have the advantage that DT describes gpio-to-irq dependencies.
>>> Moreover, nodes that reference gpios can do gpios =<&gpio 71 0>; instead of
>>> gpios =<&gpio3 7 0>;
>>
>> Is that desired?
>>
>> The device tree representation should match what is in the data sheet
>> normally. If they are in a single continuous number range, then we should
>> probably have a single device node with multiple register ranges
>> rather than one device node for each 32-bit register. Looking at
>> arch/arm/plat-orion/gpio.c I think that is not actually the case though
>> and having separate banks is more logical.
>
> Well, looking at the datasheet of Dove GPIOs are numbered [63:0] plus
> GPOs [71:64]. This dt will be a lot shorter and maybe it is describing
> the hardware as it is. (Not sure about the syntax for irqs, though)
They're numbered as [63:0] and [71:64] but they're on 3 different banks.
iirc, there may even be some differences with the way the banks are dealing
interrupts, so I don't see any reason to not represent the 3 banks in DT.
Arnaud
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: [PATCH v2 01/12] ARM: Orion: DT support for IRQ and GPIO Controllers
2012-07-05 14:54 ` Arnd Bergmann
@ 2012-07-05 16:16 ` Andrew Lunn
-1 siblings, 0 replies; 130+ messages in thread
From: Andrew Lunn @ 2012-07-05 16:16 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Sebastian Hesselbarth,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Andrew Lunn,
Jason Cooper, devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
rob.herring-bsGFqQB8/DxBDgjK7y7TUQ,
grant.likely-s3s/WqlpOiPyB63q8FvJNQ, Michael Walle,
linux-i2c-u79uwXL29TY76Z2rM5mHXA,
spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
> Something completely different I just noticed in the original patch:
>
> > @@ -90,6 +74,27 @@ static void pmu_irq_handler(unsigned int irq, struct irq_desc *desc)
> > }
> > }
> >
> > +static int __initdata gpio0_irqs[4] = {
> > + IRQ_DOVE_GPIO_0_7,
> > + IRQ_DOVE_GPIO_8_15,
> > + IRQ_DOVE_GPIO_16_23,
> > + IRQ_DOVE_GPIO_24_31,
> > +};
> > +
> > +static int __initdata gpio1_irqs[4] = {
> > + IRQ_DOVE_HIGH_GPIO,
> > + 0,
> > + 0,
> > + 0,
> > +};
>
> I think the latter one needs to be
>
> +static int __initdata gpio1_irqs[4] = {
> + IRQ_DOVE_HIGH_GPIO,
> + IRQ_DOVE_HIGH_GPIO,
> + IRQ_DOVE_HIGH_GPIO,
> + IRQ_DOVE_HIGH_GPIO,
> +};
>
> so we register all four parts to the same primary IRQ. The
> same is true for the devicetree representation.
Nope, does not work like that.
It does not matter which IRQ of a GPIO chip fires. It looks at the IRQ
cause bits for all lines and fires off the secondary ISR as needed for
the whole chip. So in effect, there is a mapping IRQ->GPIO chip, not
IRQ->1/4 of GPIO chip. With what you suggest above, you would end up
with four chained interrupt handlers, all being handled by the same
interrupt handler for one chio, and the last three in the chain would
never do anything since the first one does all the work.
Andrew
^ permalink raw reply [flat|nested] 130+ messages in thread* [PATCH v2 01/12] ARM: Orion: DT support for IRQ and GPIO Controllers
@ 2012-07-05 16:16 ` Andrew Lunn
0 siblings, 0 replies; 130+ messages in thread
From: Andrew Lunn @ 2012-07-05 16:16 UTC (permalink / raw)
To: linux-arm-kernel
> Something completely different I just noticed in the original patch:
>
> > @@ -90,6 +74,27 @@ static void pmu_irq_handler(unsigned int irq, struct irq_desc *desc)
> > }
> > }
> >
> > +static int __initdata gpio0_irqs[4] = {
> > + IRQ_DOVE_GPIO_0_7,
> > + IRQ_DOVE_GPIO_8_15,
> > + IRQ_DOVE_GPIO_16_23,
> > + IRQ_DOVE_GPIO_24_31,
> > +};
> > +
> > +static int __initdata gpio1_irqs[4] = {
> > + IRQ_DOVE_HIGH_GPIO,
> > + 0,
> > + 0,
> > + 0,
> > +};
>
> I think the latter one needs to be
>
> +static int __initdata gpio1_irqs[4] = {
> + IRQ_DOVE_HIGH_GPIO,
> + IRQ_DOVE_HIGH_GPIO,
> + IRQ_DOVE_HIGH_GPIO,
> + IRQ_DOVE_HIGH_GPIO,
> +};
>
> so we register all four parts to the same primary IRQ. The
> same is true for the devicetree representation.
Nope, does not work like that.
It does not matter which IRQ of a GPIO chip fires. It looks at the IRQ
cause bits for all lines and fires off the secondary ISR as needed for
the whole chip. So in effect, there is a mapping IRQ->GPIO chip, not
IRQ->1/4 of GPIO chip. With what you suggest above, you would end up
with four chained interrupt handlers, all being handled by the same
interrupt handler for one chio, and the last three in the chain would
never do anything since the first one does all the work.
Andrew
^ permalink raw reply [flat|nested] 130+ messages in thread[parent not found: <20120705161600.GA28860-g2DYL2Zd6BY@public.gmane.org>]
* Re: [PATCH v2 01/12] ARM: Orion: DT support for IRQ and GPIO Controllers
2012-07-05 16:16 ` Andrew Lunn
@ 2012-07-06 20:08 ` Arnd Bergmann
-1 siblings, 0 replies; 130+ messages in thread
From: Arnd Bergmann @ 2012-07-06 20:08 UTC (permalink / raw)
To: Andrew Lunn
Cc: Sebastian Hesselbarth,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Jason Cooper,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
rob.herring-bsGFqQB8/DxBDgjK7y7TUQ,
grant.likely-s3s/WqlpOiPyB63q8FvJNQ, Michael Walle,
linux-i2c-u79uwXL29TY76Z2rM5mHXA,
spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
On Thursday 05 July 2012, Andrew Lunn wrote:
> > I think the latter one needs to be
> >
> > +static int __initdata gpio1_irqs[4] = {
> > + IRQ_DOVE_HIGH_GPIO,
> > + IRQ_DOVE_HIGH_GPIO,
> > + IRQ_DOVE_HIGH_GPIO,
> > + IRQ_DOVE_HIGH_GPIO,
> > +};
> >
> > so we register all four parts to the same primary IRQ. The
> > same is true for the devicetree representation.
>
> Nope, does not work like that.
>
> It does not matter which IRQ of a GPIO chip fires. It looks at the IRQ
> cause bits for all lines and fires off the secondary ISR as needed for
> the whole chip. So in effect, there is a mapping IRQ->GPIO chip, not
> IRQ->1/4 of GPIO chip. With what you suggest above, you would end up
> with four chained interrupt handlers, all being handled by the same
> interrupt handler for one chio, and the last three in the chain would
> never do anything since the first one does all the work.
Does it really?
The handler function I'm looking at is
static void gpio_irq_handler(unsigned int irq, struct irq_desc *desc)
{
int irqoff;
BUG_ON(irq < IRQ_DOVE_GPIO_0_7 || irq > IRQ_DOVE_HIGH_GPIO);
irqoff = irq <= IRQ_DOVE_GPIO_16_23 ? irq - IRQ_DOVE_GPIO_0_7 :
3 + irq - IRQ_DOVE_GPIO_24_31;
orion_gpio_irq_handler(irqoff << 3);
if (irq == IRQ_DOVE_HIGH_GPIO) {
orion_gpio_irq_handler(40);
orion_gpio_irq_handler(48);
orion_gpio_irq_handler(56);
}
}
My reading of this is a manual hardwired implementation of a
primary handler that triggers the secondary handler four times
when it's called with a specific argument.
If you want to keep that behavior, this handler cannot be
generic across all mvebu socs, whereas registering four
chained handlers for the same primary interrupt would have
the same effect at a very small runtime overhead without the
need for any special case.
Arnd
^ permalink raw reply [flat|nested] 130+ messages in thread* [PATCH v2 01/12] ARM: Orion: DT support for IRQ and GPIO Controllers
@ 2012-07-06 20:08 ` Arnd Bergmann
0 siblings, 0 replies; 130+ messages in thread
From: Arnd Bergmann @ 2012-07-06 20:08 UTC (permalink / raw)
To: linux-arm-kernel
On Thursday 05 July 2012, Andrew Lunn wrote:
> > I think the latter one needs to be
> >
> > +static int __initdata gpio1_irqs[4] = {
> > + IRQ_DOVE_HIGH_GPIO,
> > + IRQ_DOVE_HIGH_GPIO,
> > + IRQ_DOVE_HIGH_GPIO,
> > + IRQ_DOVE_HIGH_GPIO,
> > +};
> >
> > so we register all four parts to the same primary IRQ. The
> > same is true for the devicetree representation.
>
> Nope, does not work like that.
>
> It does not matter which IRQ of a GPIO chip fires. It looks at the IRQ
> cause bits for all lines and fires off the secondary ISR as needed for
> the whole chip. So in effect, there is a mapping IRQ->GPIO chip, not
> IRQ->1/4 of GPIO chip. With what you suggest above, you would end up
> with four chained interrupt handlers, all being handled by the same
> interrupt handler for one chio, and the last three in the chain would
> never do anything since the first one does all the work.
Does it really?
The handler function I'm looking at is
static void gpio_irq_handler(unsigned int irq, struct irq_desc *desc)
{
int irqoff;
BUG_ON(irq < IRQ_DOVE_GPIO_0_7 || irq > IRQ_DOVE_HIGH_GPIO);
irqoff = irq <= IRQ_DOVE_GPIO_16_23 ? irq - IRQ_DOVE_GPIO_0_7 :
3 + irq - IRQ_DOVE_GPIO_24_31;
orion_gpio_irq_handler(irqoff << 3);
if (irq == IRQ_DOVE_HIGH_GPIO) {
orion_gpio_irq_handler(40);
orion_gpio_irq_handler(48);
orion_gpio_irq_handler(56);
}
}
My reading of this is a manual hardwired implementation of a
primary handler that triggers the secondary handler four times
when it's called with a specific argument.
If you want to keep that behavior, this handler cannot be
generic across all mvebu socs, whereas registering four
chained handlers for the same primary interrupt would have
the same effect@a very small runtime overhead without the
need for any special case.
Arnd
^ permalink raw reply [flat|nested] 130+ messages in thread[parent not found: <201207062008.23952.arnd-r2nGTMty4D4@public.gmane.org>]
* Re: [PATCH v2 01/12] ARM: Orion: DT support for IRQ and GPIO Controllers
2012-07-06 20:08 ` Arnd Bergmann
@ 2012-07-06 21:00 ` Andrew Lunn
-1 siblings, 0 replies; 130+ messages in thread
From: Andrew Lunn @ 2012-07-06 21:00 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Andrew Lunn, Sebastian Hesselbarth,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Jason Cooper,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
rob.herring-bsGFqQB8/DxBDgjK7y7TUQ,
grant.likely-s3s/WqlpOiPyB63q8FvJNQ, Michael Walle,
linux-i2c-u79uwXL29TY76Z2rM5mHXA,
spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
On Fri, Jul 06, 2012 at 08:08:23PM +0000, Arnd Bergmann wrote:
> On Thursday 05 July 2012, Andrew Lunn wrote:
> > > I think the latter one needs to be
> > >
> > > +static int __initdata gpio1_irqs[4] = {
> > > + IRQ_DOVE_HIGH_GPIO,
> > > + IRQ_DOVE_HIGH_GPIO,
> > > + IRQ_DOVE_HIGH_GPIO,
> > > + IRQ_DOVE_HIGH_GPIO,
> > > +};
> > >
> > > so we register all four parts to the same primary IRQ. The
> > > same is true for the devicetree representation.
> >
> > Nope, does not work like that.
> >
> > It does not matter which IRQ of a GPIO chip fires. It looks at the IRQ
> > cause bits for all lines and fires off the secondary ISR as needed for
> > the whole chip. So in effect, there is a mapping IRQ->GPIO chip, not
> > IRQ->1/4 of GPIO chip. With what you suggest above, you would end up
> > with four chained interrupt handlers, all being handled by the same
> > interrupt handler for one chio, and the last three in the chain would
> > never do anything since the first one does all the work.
>
> Does it really?
>
> The handler function I'm looking at is
>
>
> static void gpio_irq_handler(unsigned int irq, struct irq_desc *desc)
> {
> int irqoff;
> BUG_ON(irq < IRQ_DOVE_GPIO_0_7 || irq > IRQ_DOVE_HIGH_GPIO);
>
> irqoff = irq <= IRQ_DOVE_GPIO_16_23 ? irq - IRQ_DOVE_GPIO_0_7 :
> 3 + irq - IRQ_DOVE_GPIO_24_31;
>
> orion_gpio_irq_handler(irqoff << 3);
> if (irq == IRQ_DOVE_HIGH_GPIO) {
> orion_gpio_irq_handler(40);
> orion_gpio_irq_handler(48);
> orion_gpio_irq_handler(56);
> }
> }
void orion_gpio_irq_handler(int pinoff)
{
struct orion_gpio_chip *ochip;
u32 cause, type;
int i;
ochip = orion_gpio_chip_find(pinoff);
if (ochip == NULL)
return;
cause = readl(GPIO_DATA_IN(ochip)) & readl(GPIO_LEVEL_MASK(ochip));
cause |= readl(GPIO_EDGE_CAUSE(ochip)) & readl(GPIO_EDGE_MASK(ochip));
for (i = 0; i < ochip->chip.ngpio; i++) {
int irq;
irq = ochip->secondary_irq_base + i;
if (!(cause & (1 << i)))
continue;
type = irqd_get_trigger_type(irq_get_irq_data(irq));
if ((type & IRQ_TYPE_SENSE_MASK) == IRQ_TYPE_EDGE_BOTH) {
/* Swap polarity (race with GPIO line) */
u32 polarity;
polarity = readl(GPIO_IN_POL(ochip));
polarity ^= 1 << i;
writel(polarity, GPIO_IN_POL(ochip));
}
generic_handle_irq(irq);
}
}
orion_gpio_chip_find(pinoff) when called with pinoff 32, 40, 48, or 56
will return the same gpio chip. The loop:
for (i = 0; i < ochip->chip.ngpio; i++) {
will iterate over all lines of the controller.
> My reading of this is a manual hardwired implementation of a
> primary handler that triggers the secondary handler four times
> when it's called with a specific argument.
Here is your mistake. It not a secondary handler. It is a function
which might trigger a secondary handler, if the status bit requires
that the secondary handler should be called..
> If you want to keep that behavior, this handler cannot be
> generic across all mvebu socs, whereas registering four
> chained handlers for the same primary interrupt would have
> the same effect at a very small runtime overhead without the
> need for any special case.
I would say the current code does redundant stuff.
This code has also been tested on a Dove by Sebastian Hesselbarth and
he did not notice anything strange happening on his system.
Andrew
^ permalink raw reply [flat|nested] 130+ messages in thread* [PATCH v2 01/12] ARM: Orion: DT support for IRQ and GPIO Controllers
@ 2012-07-06 21:00 ` Andrew Lunn
0 siblings, 0 replies; 130+ messages in thread
From: Andrew Lunn @ 2012-07-06 21:00 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, Jul 06, 2012 at 08:08:23PM +0000, Arnd Bergmann wrote:
> On Thursday 05 July 2012, Andrew Lunn wrote:
> > > I think the latter one needs to be
> > >
> > > +static int __initdata gpio1_irqs[4] = {
> > > + IRQ_DOVE_HIGH_GPIO,
> > > + IRQ_DOVE_HIGH_GPIO,
> > > + IRQ_DOVE_HIGH_GPIO,
> > > + IRQ_DOVE_HIGH_GPIO,
> > > +};
> > >
> > > so we register all four parts to the same primary IRQ. The
> > > same is true for the devicetree representation.
> >
> > Nope, does not work like that.
> >
> > It does not matter which IRQ of a GPIO chip fires. It looks at the IRQ
> > cause bits for all lines and fires off the secondary ISR as needed for
> > the whole chip. So in effect, there is a mapping IRQ->GPIO chip, not
> > IRQ->1/4 of GPIO chip. With what you suggest above, you would end up
> > with four chained interrupt handlers, all being handled by the same
> > interrupt handler for one chio, and the last three in the chain would
> > never do anything since the first one does all the work.
>
> Does it really?
>
> The handler function I'm looking at is
>
>
> static void gpio_irq_handler(unsigned int irq, struct irq_desc *desc)
> {
> int irqoff;
> BUG_ON(irq < IRQ_DOVE_GPIO_0_7 || irq > IRQ_DOVE_HIGH_GPIO);
>
> irqoff = irq <= IRQ_DOVE_GPIO_16_23 ? irq - IRQ_DOVE_GPIO_0_7 :
> 3 + irq - IRQ_DOVE_GPIO_24_31;
>
> orion_gpio_irq_handler(irqoff << 3);
> if (irq == IRQ_DOVE_HIGH_GPIO) {
> orion_gpio_irq_handler(40);
> orion_gpio_irq_handler(48);
> orion_gpio_irq_handler(56);
> }
> }
void orion_gpio_irq_handler(int pinoff)
{
struct orion_gpio_chip *ochip;
u32 cause, type;
int i;
ochip = orion_gpio_chip_find(pinoff);
if (ochip == NULL)
return;
cause = readl(GPIO_DATA_IN(ochip)) & readl(GPIO_LEVEL_MASK(ochip));
cause |= readl(GPIO_EDGE_CAUSE(ochip)) & readl(GPIO_EDGE_MASK(ochip));
for (i = 0; i < ochip->chip.ngpio; i++) {
int irq;
irq = ochip->secondary_irq_base + i;
if (!(cause & (1 << i)))
continue;
type = irqd_get_trigger_type(irq_get_irq_data(irq));
if ((type & IRQ_TYPE_SENSE_MASK) == IRQ_TYPE_EDGE_BOTH) {
/* Swap polarity (race with GPIO line) */
u32 polarity;
polarity = readl(GPIO_IN_POL(ochip));
polarity ^= 1 << i;
writel(polarity, GPIO_IN_POL(ochip));
}
generic_handle_irq(irq);
}
}
orion_gpio_chip_find(pinoff) when called with pinoff 32, 40, 48, or 56
will return the same gpio chip. The loop:
for (i = 0; i < ochip->chip.ngpio; i++) {
will iterate over all lines of the controller.
> My reading of this is a manual hardwired implementation of a
> primary handler that triggers the secondary handler four times
> when it's called with a specific argument.
Here is your mistake. It not a secondary handler. It is a function
which might trigger a secondary handler, if the status bit requires
that the secondary handler should be called..
> If you want to keep that behavior, this handler cannot be
> generic across all mvebu socs, whereas registering four
> chained handlers for the same primary interrupt would have
> the same effect at a very small runtime overhead without the
> need for any special case.
I would say the current code does redundant stuff.
This code has also been tested on a Dove by Sebastian Hesselbarth and
he did not notice anything strange happening on his system.
Andrew
^ permalink raw reply [flat|nested] 130+ messages in thread[parent not found: <20120706210009.GC11470-g2DYL2Zd6BY@public.gmane.org>]
* Where to put a large bootloader-supplied device tree on ARM ?
2012-07-06 21:00 ` Andrew Lunn
@ 2012-07-07 0:24 ` Mitch Bradley
-1 siblings, 0 replies; 130+ messages in thread
From: Mitch Bradley @ 2012-07-07 0:24 UTC (permalink / raw)
To: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ
I'm passing a flatted device tree from OLPC's bootloader (which
is a full Open Firmware implementation) to the kernel. If I
put the FDT at the "traditional" address 0x100, bad things
happen when the DT is larger than 16K. The FDT extends past
the 0x4000 boundary and gets overwritten by the early page tables
which are written at that address.
I have found various places in memory where I can place it
without it being overwritten, and things work, but that seems
dodgy and likely to break randomly.
Has there been any discussion about where large-ish FDT images
should be located?
^ permalink raw reply [flat|nested] 130+ messages in thread
* Where to put a large bootloader-supplied device tree on ARM ?
@ 2012-07-07 0:24 ` Mitch Bradley
0 siblings, 0 replies; 130+ messages in thread
From: Mitch Bradley @ 2012-07-07 0:24 UTC (permalink / raw)
To: linux-arm-kernel
I'm passing a flatted device tree from OLPC's bootloader (which
is a full Open Firmware implementation) to the kernel. If I
put the FDT at the "traditional" address 0x100, bad things
happen when the DT is larger than 16K. The FDT extends past
the 0x4000 boundary and gets overwritten by the early page tables
which are written at that address.
I have found various places in memory where I can place it
without it being overwritten, and things work, but that seems
dodgy and likely to break randomly.
Has there been any discussion about where large-ish FDT images
should be located?
^ permalink raw reply [flat|nested] 130+ messages in thread
[parent not found: <4FF781D8.3040206-D5eQfiDGL7eakBO8gow8eQ@public.gmane.org>]
* RE: Where to put a large bootloader-supplied device tree on ARM ?
2012-07-07 0:24 ` Mitch Bradley
@ 2012-07-07 1:23 ` David VomLehn (dvomlehn)
-1 siblings, 0 replies; 130+ messages in thread
From: David VomLehn (dvomlehn) @ 2012-07-07 1:23 UTC (permalink / raw)
To: Mitch Bradley, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ
The kernel *must* go where it is linked, but the FDT contains only relative
references and is thus free to go anywhere. The same is true of ramdisks, which
are usually placed after the kernel. How about doing the same with your FDT?
> -----Original Message-----
> From: devicetree-discuss [mailto:devicetree-discuss-
> bounces+dvomlehn=cisco.com-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org] On Behalf Of Mitch Bradley
> Sent: Friday, July 06, 2012 5:25 PM
> To: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org; devicetree-
> discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org
> Subject: Where to put a large bootloader-supplied device tree on ARM ?
>
> I'm passing a flatted device tree from OLPC's bootloader (which
> is a full Open Firmware implementation) to the kernel. If I
> put the FDT at the "traditional" address 0x100, bad things
> happen when the DT is larger than 16K. The FDT extends past
> the 0x4000 boundary and gets overwritten by the early page tables
> which are written at that address.
>
> I have found various places in memory where I can place it
> without it being overwritten, and things work, but that seems
> dodgy and likely to break randomly.
>
> Has there been any discussion about where large-ish FDT images
> should be located?
>
> _______________________________________________
> devicetree-discuss mailing list
> devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org
> https://lists.ozlabs.org/listinfo/devicetree-discuss
^ permalink raw reply [flat|nested] 130+ messages in thread
* Where to put a large bootloader-supplied device tree on ARM ?
@ 2012-07-07 1:23 ` David VomLehn (dvomlehn)
0 siblings, 0 replies; 130+ messages in thread
From: David VomLehn (dvomlehn) @ 2012-07-07 1:23 UTC (permalink / raw)
To: linux-arm-kernel
The kernel *must* go where it is linked, but the FDT contains only relative
references and is thus free to go anywhere. The same is true of ramdisks, which
are usually placed after the kernel. How about doing the same with your FDT?
> -----Original Message-----
> From: devicetree-discuss [mailto:devicetree-discuss-
> bounces+dvomlehn=cisco.com at lists.ozlabs.org] On Behalf Of Mitch Bradley
> Sent: Friday, July 06, 2012 5:25 PM
> To: linux-arm-kernel at lists.infradead.org; devicetree-
> discuss at lists.ozlabs.org
> Subject: Where to put a large bootloader-supplied device tree on ARM ?
>
> I'm passing a flatted device tree from OLPC's bootloader (which
> is a full Open Firmware implementation) to the kernel. If I
> put the FDT at the "traditional" address 0x100, bad things
> happen when the DT is larger than 16K. The FDT extends past
> the 0x4000 boundary and gets overwritten by the early page tables
> which are written at that address.
>
> I have found various places in memory where I can place it
> without it being overwritten, and things work, but that seems
> dodgy and likely to break randomly.
>
> Has there been any discussion about where large-ish FDT images
> should be located?
>
> _______________________________________________
> devicetree-discuss mailing list
> devicetree-discuss at lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/devicetree-discuss
^ permalink raw reply [flat|nested] 130+ messages in thread
[parent not found: <2966DB01BC317A4DA23684BA0F653415013701-WE/xwOPrfQKHONfmNwMhBaBKnGwkPULj@public.gmane.org>]
* Re: Where to put a large bootloader-supplied device tree on ARM ?
2012-07-07 1:23 ` David VomLehn (dvomlehn)
@ 2012-07-07 1:59 ` Mitch Bradley
-1 siblings, 0 replies; 130+ messages in thread
From: Mitch Bradley @ 2012-07-07 1:59 UTC (permalink / raw)
To: David VomLehn (dvomlehn)
Cc: devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
On 7/6/2012 3:23 PM, David VomLehn (dvomlehn) wrote:
> The kernel *must* go where it is linked, but the FDT contains only relative
> references and is thus free to go anywhere. The same is true of ramdisks, which
> are usually placed after the kernel.
Right, but the kernel image is compressed, so after decompression it
expands into the area just after it. Also, the .bss segment is in that
vicinity.
There's some code in arch/arm/boot/compressed/head.S to relocate
device tree blobs, but it requires CONFIG_ARM_APPENDED_DTB which
is not recommended - arch/arm/Kconfig recommends using the
documented boot protocol istead . Documentation/arm/Booting says
to put the dtb "in a region of memory where the kernel decompressor
will not overwrite it", further recommending the first 16KiB.
As noted, the first 16KiB loses if the dtb is too large. And
"where the kernel decompressor will not overwrite it" says what
won't work, not what will. It appears that the decompressor works
out its addresses dynamically, so there's no hard prescription even
for what to avoid.
For now, I'm putting the initrd at the end of memory and the dtb
below that. That seems to work, but I'm unsure whether or not
I'm just "getting lucky".
Thanks,
Mitch
> How about doing the same with your FDT?
>
>> -----Original Message-----
>> From: devicetree-discuss [mailto:devicetree-discuss-
>> bounces+dvomlehn=cisco.com-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org] On Behalf Of Mitch Bradley
>> Sent: Friday, July 06, 2012 5:25 PM
>> To: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org; devicetree-
>> discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org
>> Subject: Where to put a large bootloader-supplied device tree on ARM ?
>>
>> I'm passing a flatted device tree from OLPC's bootloader (which
>> is a full Open Firmware implementation) to the kernel. If I
>> put the FDT at the "traditional" address 0x100, bad things
>> happen when the DT is larger than 16K. The FDT extends past
>> the 0x4000 boundary and gets overwritten by the early page tables
>> which are written at that address.
>>
>> I have found various places in memory where I can place it
>> without it being overwritten, and things work, but that seems
>> dodgy and likely to break randomly.
>>
>> Has there been any discussion about where large-ish FDT images
>> should be located?
>>
>> _______________________________________________
>> devicetree-discuss mailing list
>> devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org
>> https://lists.ozlabs.org/listinfo/devicetree-discuss
>
>
^ permalink raw reply [flat|nested] 130+ messages in thread
* Where to put a large bootloader-supplied device tree on ARM ?
@ 2012-07-07 1:59 ` Mitch Bradley
0 siblings, 0 replies; 130+ messages in thread
From: Mitch Bradley @ 2012-07-07 1:59 UTC (permalink / raw)
To: linux-arm-kernel
On 7/6/2012 3:23 PM, David VomLehn (dvomlehn) wrote:
> The kernel *must* go where it is linked, but the FDT contains only relative
> references and is thus free to go anywhere. The same is true of ramdisks, which
> are usually placed after the kernel.
Right, but the kernel image is compressed, so after decompression it
expands into the area just after it. Also, the .bss segment is in that
vicinity.
There's some code in arch/arm/boot/compressed/head.S to relocate
device tree blobs, but it requires CONFIG_ARM_APPENDED_DTB which
is not recommended - arch/arm/Kconfig recommends using the
documented boot protocol istead . Documentation/arm/Booting says
to put the dtb "in a region of memory where the kernel decompressor
will not overwrite it", further recommending the first 16KiB.
As noted, the first 16KiB loses if the dtb is too large. And
"where the kernel decompressor will not overwrite it" says what
won't work, not what will. It appears that the decompressor works
out its addresses dynamically, so there's no hard prescription even
for what to avoid.
For now, I'm putting the initrd at the end of memory and the dtb
below that. That seems to work, but I'm unsure whether or not
I'm just "getting lucky".
Thanks,
Mitch
> How about doing the same with your FDT?
>
>> -----Original Message-----
>> From: devicetree-discuss [mailto:devicetree-discuss-
>> bounces+dvomlehn=cisco.com at lists.ozlabs.org] On Behalf Of Mitch Bradley
>> Sent: Friday, July 06, 2012 5:25 PM
>> To: linux-arm-kernel at lists.infradead.org; devicetree-
>> discuss at lists.ozlabs.org
>> Subject: Where to put a large bootloader-supplied device tree on ARM ?
>>
>> I'm passing a flatted device tree from OLPC's bootloader (which
>> is a full Open Firmware implementation) to the kernel. If I
>> put the FDT at the "traditional" address 0x100, bad things
>> happen when the DT is larger than 16K. The FDT extends past
>> the 0x4000 boundary and gets overwritten by the early page tables
>> which are written at that address.
>>
>> I have found various places in memory where I can place it
>> without it being overwritten, and things work, but that seems
>> dodgy and likely to break randomly.
>>
>> Has there been any discussion about where large-ish FDT images
>> should be located?
>>
>> _______________________________________________
>> devicetree-discuss mailing list
>> devicetree-discuss at lists.ozlabs.org
>> https://lists.ozlabs.org/listinfo/devicetree-discuss
>
>
^ permalink raw reply [flat|nested] 130+ messages in thread
[parent not found: <4FF7980E.7050705-D5eQfiDGL7eakBO8gow8eQ@public.gmane.org>]
* Re: Where to put a large bootloader-supplied device tree on ARM ?
2012-07-07 1:59 ` Mitch Bradley
@ 2012-07-09 4:30 ` Nicolas Pitre
-1 siblings, 0 replies; 130+ messages in thread
From: Nicolas Pitre @ 2012-07-09 4:30 UTC (permalink / raw)
To: Mitch Bradley
Cc: devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
On Fri, 6 Jul 2012, Mitch Bradley wrote:
> On 7/6/2012 3:23 PM, David VomLehn (dvomlehn) wrote:
> > The kernel *must* go where it is linked, but the FDT contains only relative
> > references and is thus free to go anywhere. The same is true of ramdisks,
> > which
> > are usually placed after the kernel.
The kernel must go where it is linked *only* if you are using the
'Image' output. When using 'zImage' you can put the kernel anywhere in
memory, or in the first 128MB of RAM if CONFIG_AUTO_ZRELADDR is used.
> Right, but the kernel image is compressed, so after decompression it expands
> into the area just after it. Also, the .bss segment is in that vicinity.
To be exact, the compressed kernel moves itself out of the region where
the decompressed kernel will end up before doing the decompression, but
only if necessary. So it is a good idea to load zImage away from the
decompressed kernel area to avoid this extra move and save some fraction
of a second on boot time.
> There's some code in arch/arm/boot/compressed/head.S to relocate
> device tree blobs, but it requires CONFIG_ARM_APPENDED_DTB which
> is not recommended - arch/arm/Kconfig recommends using the
> documented boot protocol istead .
This is in case a DTB is appended to zImage. When the DTB is detected,
the moving of zImage out of the decompressed area must take care of
moving the DTB as well.
> Documentation/arm/Booting says
> to put the dtb "in a region of memory where the kernel decompressor
> will not overwrite it", further recommending the first 16KiB.
>
> As noted, the first 16KiB loses if the dtb is too large. And
> "where the kernel decompressor will not overwrite it" says what
> won't work, not what will. It appears that the decompressor works
> out its addresses dynamically, so there's no hard prescription even
> for what to avoid.
A good rule of thumb is to take the size of the decompressed kernel and
multiply this by 3. Rounding up is also fine. So for example if your
arch/arm/boot/Image is 5MB, then putting anciliary data such as a
ramdisk or a large DTB from 16MB into RAM or above should be fine.
> For now, I'm putting the initrd at the end of memory and the dtb
> below that. That seems to work, but I'm unsure whether or not
> I'm just "getting lucky".
That's also perfectly fine.
Nicolas
^ permalink raw reply [flat|nested] 130+ messages in thread
* Where to put a large bootloader-supplied device tree on ARM ?
@ 2012-07-09 4:30 ` Nicolas Pitre
0 siblings, 0 replies; 130+ messages in thread
From: Nicolas Pitre @ 2012-07-09 4:30 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, 6 Jul 2012, Mitch Bradley wrote:
> On 7/6/2012 3:23 PM, David VomLehn (dvomlehn) wrote:
> > The kernel *must* go where it is linked, but the FDT contains only relative
> > references and is thus free to go anywhere. The same is true of ramdisks,
> > which
> > are usually placed after the kernel.
The kernel must go where it is linked *only* if you are using the
'Image' output. When using 'zImage' you can put the kernel anywhere in
memory, or in the first 128MB of RAM if CONFIG_AUTO_ZRELADDR is used.
> Right, but the kernel image is compressed, so after decompression it expands
> into the area just after it. Also, the .bss segment is in that vicinity.
To be exact, the compressed kernel moves itself out of the region where
the decompressed kernel will end up before doing the decompression, but
only if necessary. So it is a good idea to load zImage away from the
decompressed kernel area to avoid this extra move and save some fraction
of a second on boot time.
> There's some code in arch/arm/boot/compressed/head.S to relocate
> device tree blobs, but it requires CONFIG_ARM_APPENDED_DTB which
> is not recommended - arch/arm/Kconfig recommends using the
> documented boot protocol istead .
This is in case a DTB is appended to zImage. When the DTB is detected,
the moving of zImage out of the decompressed area must take care of
moving the DTB as well.
> Documentation/arm/Booting says
> to put the dtb "in a region of memory where the kernel decompressor
> will not overwrite it", further recommending the first 16KiB.
>
> As noted, the first 16KiB loses if the dtb is too large. And
> "where the kernel decompressor will not overwrite it" says what
> won't work, not what will. It appears that the decompressor works
> out its addresses dynamically, so there's no hard prescription even
> for what to avoid.
A good rule of thumb is to take the size of the decompressed kernel and
multiply this by 3. Rounding up is also fine. So for example if your
arch/arm/boot/Image is 5MB, then putting anciliary data such as a
ramdisk or a large DTB from 16MB into RAM or above should be fine.
> For now, I'm putting the initrd at the end of memory and the dtb
> below that. That seems to work, but I'm unsure whether or not
> I'm just "getting lucky".
That's also perfectly fine.
Nicolas
^ permalink raw reply [flat|nested] 130+ messages in thread
[parent not found: <alpine.LFD.2.02.1207090015270.31100-QuJgVwGFrdf/9pzu0YdTqQ@public.gmane.org>]
* Re: Where to put a large bootloader-supplied device tree on ARM ?
2012-07-09 4:30 ` Nicolas Pitre
@ 2012-07-12 6:52 ` Mitch Bradley
-1 siblings, 0 replies; 130+ messages in thread
From: Mitch Bradley @ 2012-07-12 6:52 UTC (permalink / raw)
To: Nicolas Pitre
Cc: devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
On 7/8/2012 6:30 PM, Nicolas Pitre wrote:
> On Fri, 6 Jul 2012, Mitch Bradley wrote:
>
>> On 7/6/2012 3:23 PM, David VomLehn (dvomlehn) wrote:
>>> The kernel *must* go where it is linked, but the FDT contains only relative
>>> references and is thus free to go anywhere. The same is true of ramdisks,
>>> which
>>> are usually placed after the kernel.
>
> The kernel must go where it is linked *only* if you are using the
> 'Image' output. When using 'zImage' you can put the kernel anywhere in
> memory, or in the first 128MB of RAM if CONFIG_AUTO_ZRELADDR is used.
>
>> Right, but the kernel image is compressed, so after decompression it expands
>> into the area just after it. Also, the .bss segment is in that vicinity.
>
> To be exact, the compressed kernel moves itself out of the region where
> the decompressed kernel will end up before doing the decompression, but
> only if necessary. So it is a good idea to load zImage away from the
> decompressed kernel area to avoid this extra move and save some fraction
> of a second on boot time.
>
>> There's some code in arch/arm/boot/compressed/head.S to relocate
>> device tree blobs, but it requires CONFIG_ARM_APPENDED_DTB which
>> is not recommended - arch/arm/Kconfig recommends using the
>> documented boot protocol istead .
>
> This is in case a DTB is appended to zImage. When the DTB is detected,
> the moving of zImage out of the decompressed area must take care of
> moving the DTB as well.
>
>> Documentation/arm/Booting says
>> to put the dtb "in a region of memory where the kernel decompressor
>> will not overwrite it", further recommending the first 16KiB.
>>
>> As noted, the first 16KiB loses if the dtb is too large. And
>> "where the kernel decompressor will not overwrite it" says what
>> won't work, not what will. It appears that the decompressor works
>> out its addresses dynamically, so there's no hard prescription even
>> for what to avoid.
>
> A good rule of thumb is to take the size of the decompressed kernel and
> multiply this by 3. Rounding up is also fine. So for example if your
> arch/arm/boot/Image is 5MB, then putting anciliary data such as a
> ramdisk or a large DTB from 16MB into RAM or above should be fine.
>
>> For now, I'm putting the initrd at the end of memory and the dtb
>> below that. That seems to work, but I'm unsure whether or not
>> I'm just "getting lucky".
>
> That's also perfectly fine.
Alas, that worked for machines with 512 MiB of main memory, but failed
on 1 GiB machines. My guess is that, when the initrd and dtb are near
the top of a 1 GiB memory, the virtual address gets too near the top of
the kernel's 1 GiB of virtual space (which starts at 0xc0000000),
perhaps colliding with the VMALLOC space.
Putting them just below the 128 MiB boundary seems to work.
>
>
> Nicolas
>
^ permalink raw reply [flat|nested] 130+ messages in thread
* Where to put a large bootloader-supplied device tree on ARM ?
@ 2012-07-12 6:52 ` Mitch Bradley
0 siblings, 0 replies; 130+ messages in thread
From: Mitch Bradley @ 2012-07-12 6:52 UTC (permalink / raw)
To: linux-arm-kernel
On 7/8/2012 6:30 PM, Nicolas Pitre wrote:
> On Fri, 6 Jul 2012, Mitch Bradley wrote:
>
>> On 7/6/2012 3:23 PM, David VomLehn (dvomlehn) wrote:
>>> The kernel *must* go where it is linked, but the FDT contains only relative
>>> references and is thus free to go anywhere. The same is true of ramdisks,
>>> which
>>> are usually placed after the kernel.
>
> The kernel must go where it is linked *only* if you are using the
> 'Image' output. When using 'zImage' you can put the kernel anywhere in
> memory, or in the first 128MB of RAM if CONFIG_AUTO_ZRELADDR is used.
>
>> Right, but the kernel image is compressed, so after decompression it expands
>> into the area just after it. Also, the .bss segment is in that vicinity.
>
> To be exact, the compressed kernel moves itself out of the region where
> the decompressed kernel will end up before doing the decompression, but
> only if necessary. So it is a good idea to load zImage away from the
> decompressed kernel area to avoid this extra move and save some fraction
> of a second on boot time.
>
>> There's some code in arch/arm/boot/compressed/head.S to relocate
>> device tree blobs, but it requires CONFIG_ARM_APPENDED_DTB which
>> is not recommended - arch/arm/Kconfig recommends using the
>> documented boot protocol istead .
>
> This is in case a DTB is appended to zImage. When the DTB is detected,
> the moving of zImage out of the decompressed area must take care of
> moving the DTB as well.
>
>> Documentation/arm/Booting says
>> to put the dtb "in a region of memory where the kernel decompressor
>> will not overwrite it", further recommending the first 16KiB.
>>
>> As noted, the first 16KiB loses if the dtb is too large. And
>> "where the kernel decompressor will not overwrite it" says what
>> won't work, not what will. It appears that the decompressor works
>> out its addresses dynamically, so there's no hard prescription even
>> for what to avoid.
>
> A good rule of thumb is to take the size of the decompressed kernel and
> multiply this by 3. Rounding up is also fine. So for example if your
> arch/arm/boot/Image is 5MB, then putting anciliary data such as a
> ramdisk or a large DTB from 16MB into RAM or above should be fine.
>
>> For now, I'm putting the initrd at the end of memory and the dtb
>> below that. That seems to work, but I'm unsure whether or not
>> I'm just "getting lucky".
>
> That's also perfectly fine.
Alas, that worked for machines with 512 MiB of main memory, but failed
on 1 GiB machines. My guess is that, when the initrd and dtb are near
the top of a 1 GiB memory, the virtual address gets too near the top of
the kernel's 1 GiB of virtual space (which starts at 0xc0000000),
perhaps colliding with the VMALLOC space.
Putting them just below the 128 MiB boundary seems to work.
>
>
> Nicolas
>
^ permalink raw reply [flat|nested] 130+ messages in thread
[parent not found: <4FFE743B.6080504-D5eQfiDGL7eakBO8gow8eQ@public.gmane.org>]
* Re: Where to put a large bootloader-supplied device tree on ARM ?
2012-07-12 6:52 ` Mitch Bradley
@ 2012-07-12 18:16 ` Nicolas Pitre
-1 siblings, 0 replies; 130+ messages in thread
From: Nicolas Pitre @ 2012-07-12 18:16 UTC (permalink / raw)
To: Mitch Bradley
Cc: devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
On Wed, 11 Jul 2012, Mitch Bradley wrote:
> On 7/8/2012 6:30 PM, Nicolas Pitre wrote:
> > On Fri, 6 Jul 2012, Mitch Bradley wrote:
> >
> >> For now, I'm putting the initrd at the end of memory and the dtb
> >> below that. That seems to work, but I'm unsure whether or not
> >> I'm just "getting lucky".
> >
> > That's also perfectly fine.
>
> Alas, that worked for machines with 512 MiB of main memory, but failed
> on 1 GiB machines. My guess is that, when the initrd and dtb are near
> the top of a 1 GiB memory, the virtual address gets too near the top of
> the kernel's 1 GiB of virtual space (which starts at 0xc0000000),
> perhaps colliding with the VMALLOC space.
Indeed, that won't work in that case.
> Putting them just below the 128 MiB boundary seems to work.
Or at the 128MB mark, or any location between 64MB and 512MB should be
fine in practice.
Nicolas
^ permalink raw reply [flat|nested] 130+ messages in thread
* Where to put a large bootloader-supplied device tree on ARM ?
@ 2012-07-12 18:16 ` Nicolas Pitre
0 siblings, 0 replies; 130+ messages in thread
From: Nicolas Pitre @ 2012-07-12 18:16 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, 11 Jul 2012, Mitch Bradley wrote:
> On 7/8/2012 6:30 PM, Nicolas Pitre wrote:
> > On Fri, 6 Jul 2012, Mitch Bradley wrote:
> >
> >> For now, I'm putting the initrd at the end of memory and the dtb
> >> below that. That seems to work, but I'm unsure whether or not
> >> I'm just "getting lucky".
> >
> > That's also perfectly fine.
>
> Alas, that worked for machines with 512 MiB of main memory, but failed
> on 1 GiB machines. My guess is that, when the initrd and dtb are near
> the top of a 1 GiB memory, the virtual address gets too near the top of
> the kernel's 1 GiB of virtual space (which starts at 0xc0000000),
> perhaps colliding with the VMALLOC space.
Indeed, that won't work in that case.
> Putting them just below the 128 MiB boundary seems to work.
Or at the 128MB mark, or any location between 64MB and 512MB should be
fine in practice.
Nicolas
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: Where to put a large bootloader-supplied device tree on ARM ?
2012-07-12 6:52 ` Mitch Bradley
(?)
@ 2012-07-12 20:34 ` Rob Herring
-1 siblings, 0 replies; 130+ messages in thread
From: Rob Herring @ 2012-07-12 20:34 UTC (permalink / raw)
To: Mitch Bradley; +Cc: U-Boot, devicetree-discuss, linux-arm-kernel
[adding u-boot list]
On 07/12/2012 01:52 AM, Mitch Bradley wrote:
> On 7/8/2012 6:30 PM, Nicolas Pitre wrote:
>> On Fri, 6 Jul 2012, Mitch Bradley wrote:
>>
>>> On 7/6/2012 3:23 PM, David VomLehn (dvomlehn) wrote:
>>>> The kernel *must* go where it is linked, but the FDT contains only relative
>>>> references and is thus free to go anywhere. The same is true of ramdisks,
>>>> which
>>>> are usually placed after the kernel.
>>
>> The kernel must go where it is linked *only* if you are using the
>> 'Image' output. When using 'zImage' you can put the kernel anywhere in
>> memory, or in the first 128MB of RAM if CONFIG_AUTO_ZRELADDR is used.
>>
>>> Right, but the kernel image is compressed, so after decompression it expands
>>> into the area just after it. Also, the .bss segment is in that vicinity.
>>
>> To be exact, the compressed kernel moves itself out of the region where
>> the decompressed kernel will end up before doing the decompression, but
>> only if necessary. So it is a good idea to load zImage away from the
>> decompressed kernel area to avoid this extra move and save some fraction
>> of a second on boot time.
>>
>>> There's some code in arch/arm/boot/compressed/head.S to relocate
>>> device tree blobs, but it requires CONFIG_ARM_APPENDED_DTB which
>>> is not recommended - arch/arm/Kconfig recommends using the
>>> documented boot protocol istead .
>>
>> This is in case a DTB is appended to zImage. When the DTB is detected,
>> the moving of zImage out of the decompressed area must take care of
>> moving the DTB as well.
>>
>>> Documentation/arm/Booting says
>>> to put the dtb "in a region of memory where the kernel decompressor
>>> will not overwrite it", further recommending the first 16KiB.
>>>
>>> As noted, the first 16KiB loses if the dtb is too large. And
>>> "where the kernel decompressor will not overwrite it" says what
>>> won't work, not what will. It appears that the decompressor works
>>> out its addresses dynamically, so there's no hard prescription even
>>> for what to avoid.
>>
>> A good rule of thumb is to take the size of the decompressed kernel and
>> multiply this by 3. Rounding up is also fine. So for example if your
>> arch/arm/boot/Image is 5MB, then putting anciliary data such as a
>> ramdisk or a large DTB from 16MB into RAM or above should be fine.
>>
>>> For now, I'm putting the initrd at the end of memory and the dtb
>>> below that. That seems to work, but I'm unsure whether or not
>>> I'm just "getting lucky".
>>
>> That's also perfectly fine.
>
>
> Alas, that worked for machines with 512 MiB of main memory, but failed
> on 1 GiB machines. My guess is that, when the initrd and dtb are near
> the top of a 1 GiB memory, the virtual address gets too near the top of
> the kernel's 1 GiB of virtual space (which starts at 0xc0000000),
> perhaps colliding with the VMALLOC space.
>
> Putting them just below the 128 MiB boundary seems to work.
Interesting. I think this is also a problem on u-boot just waiting to
happen. u-boot locates itself at the end of RAM and likes to copy the
fdt and initrd to just below that. Any machine with 1G+ is going to hit
this. I avoided it because I limited u-boot to 512MB on highbank.
Rob
>
>>
>>
>> Nicolas
>>
>
> _______________________________________________
> devicetree-discuss mailing list
> devicetree-discuss@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/devicetree-discuss
>
^ permalink raw reply [flat|nested] 130+ messages in thread
* [U-Boot] Where to put a large bootloader-supplied device tree on ARM ?
@ 2012-07-12 20:34 ` Rob Herring
0 siblings, 0 replies; 130+ messages in thread
From: Rob Herring @ 2012-07-12 20:34 UTC (permalink / raw)
To: u-boot
[adding u-boot list]
On 07/12/2012 01:52 AM, Mitch Bradley wrote:
> On 7/8/2012 6:30 PM, Nicolas Pitre wrote:
>> On Fri, 6 Jul 2012, Mitch Bradley wrote:
>>
>>> On 7/6/2012 3:23 PM, David VomLehn (dvomlehn) wrote:
>>>> The kernel *must* go where it is linked, but the FDT contains only relative
>>>> references and is thus free to go anywhere. The same is true of ramdisks,
>>>> which
>>>> are usually placed after the kernel.
>>
>> The kernel must go where it is linked *only* if you are using the
>> 'Image' output. When using 'zImage' you can put the kernel anywhere in
>> memory, or in the first 128MB of RAM if CONFIG_AUTO_ZRELADDR is used.
>>
>>> Right, but the kernel image is compressed, so after decompression it expands
>>> into the area just after it. Also, the .bss segment is in that vicinity.
>>
>> To be exact, the compressed kernel moves itself out of the region where
>> the decompressed kernel will end up before doing the decompression, but
>> only if necessary. So it is a good idea to load zImage away from the
>> decompressed kernel area to avoid this extra move and save some fraction
>> of a second on boot time.
>>
>>> There's some code in arch/arm/boot/compressed/head.S to relocate
>>> device tree blobs, but it requires CONFIG_ARM_APPENDED_DTB which
>>> is not recommended - arch/arm/Kconfig recommends using the
>>> documented boot protocol istead .
>>
>> This is in case a DTB is appended to zImage. When the DTB is detected,
>> the moving of zImage out of the decompressed area must take care of
>> moving the DTB as well.
>>
>>> Documentation/arm/Booting says
>>> to put the dtb "in a region of memory where the kernel decompressor
>>> will not overwrite it", further recommending the first 16KiB.
>>>
>>> As noted, the first 16KiB loses if the dtb is too large. And
>>> "where the kernel decompressor will not overwrite it" says what
>>> won't work, not what will. It appears that the decompressor works
>>> out its addresses dynamically, so there's no hard prescription even
>>> for what to avoid.
>>
>> A good rule of thumb is to take the size of the decompressed kernel and
>> multiply this by 3. Rounding up is also fine. So for example if your
>> arch/arm/boot/Image is 5MB, then putting anciliary data such as a
>> ramdisk or a large DTB from 16MB into RAM or above should be fine.
>>
>>> For now, I'm putting the initrd at the end of memory and the dtb
>>> below that. That seems to work, but I'm unsure whether or not
>>> I'm just "getting lucky".
>>
>> That's also perfectly fine.
>
>
> Alas, that worked for machines with 512 MiB of main memory, but failed
> on 1 GiB machines. My guess is that, when the initrd and dtb are near
> the top of a 1 GiB memory, the virtual address gets too near the top of
> the kernel's 1 GiB of virtual space (which starts at 0xc0000000),
> perhaps colliding with the VMALLOC space.
>
> Putting them just below the 128 MiB boundary seems to work.
Interesting. I think this is also a problem on u-boot just waiting to
happen. u-boot locates itself at the end of RAM and likes to copy the
fdt and initrd to just below that. Any machine with 1G+ is going to hit
this. I avoided it because I limited u-boot to 512MB on highbank.
Rob
>
>>
>>
>> Nicolas
>>
>
> _______________________________________________
> devicetree-discuss mailing list
> devicetree-discuss at lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/devicetree-discuss
>
^ permalink raw reply [flat|nested] 130+ messages in thread
* Where to put a large bootloader-supplied device tree on ARM ?
@ 2012-07-12 20:34 ` Rob Herring
0 siblings, 0 replies; 130+ messages in thread
From: Rob Herring @ 2012-07-12 20:34 UTC (permalink / raw)
To: linux-arm-kernel
[adding u-boot list]
On 07/12/2012 01:52 AM, Mitch Bradley wrote:
> On 7/8/2012 6:30 PM, Nicolas Pitre wrote:
>> On Fri, 6 Jul 2012, Mitch Bradley wrote:
>>
>>> On 7/6/2012 3:23 PM, David VomLehn (dvomlehn) wrote:
>>>> The kernel *must* go where it is linked, but the FDT contains only relative
>>>> references and is thus free to go anywhere. The same is true of ramdisks,
>>>> which
>>>> are usually placed after the kernel.
>>
>> The kernel must go where it is linked *only* if you are using the
>> 'Image' output. When using 'zImage' you can put the kernel anywhere in
>> memory, or in the first 128MB of RAM if CONFIG_AUTO_ZRELADDR is used.
>>
>>> Right, but the kernel image is compressed, so after decompression it expands
>>> into the area just after it. Also, the .bss segment is in that vicinity.
>>
>> To be exact, the compressed kernel moves itself out of the region where
>> the decompressed kernel will end up before doing the decompression, but
>> only if necessary. So it is a good idea to load zImage away from the
>> decompressed kernel area to avoid this extra move and save some fraction
>> of a second on boot time.
>>
>>> There's some code in arch/arm/boot/compressed/head.S to relocate
>>> device tree blobs, but it requires CONFIG_ARM_APPENDED_DTB which
>>> is not recommended - arch/arm/Kconfig recommends using the
>>> documented boot protocol istead .
>>
>> This is in case a DTB is appended to zImage. When the DTB is detected,
>> the moving of zImage out of the decompressed area must take care of
>> moving the DTB as well.
>>
>>> Documentation/arm/Booting says
>>> to put the dtb "in a region of memory where the kernel decompressor
>>> will not overwrite it", further recommending the first 16KiB.
>>>
>>> As noted, the first 16KiB loses if the dtb is too large. And
>>> "where the kernel decompressor will not overwrite it" says what
>>> won't work, not what will. It appears that the decompressor works
>>> out its addresses dynamically, so there's no hard prescription even
>>> for what to avoid.
>>
>> A good rule of thumb is to take the size of the decompressed kernel and
>> multiply this by 3. Rounding up is also fine. So for example if your
>> arch/arm/boot/Image is 5MB, then putting anciliary data such as a
>> ramdisk or a large DTB from 16MB into RAM or above should be fine.
>>
>>> For now, I'm putting the initrd at the end of memory and the dtb
>>> below that. That seems to work, but I'm unsure whether or not
>>> I'm just "getting lucky".
>>
>> That's also perfectly fine.
>
>
> Alas, that worked for machines with 512 MiB of main memory, but failed
> on 1 GiB machines. My guess is that, when the initrd and dtb are near
> the top of a 1 GiB memory, the virtual address gets too near the top of
> the kernel's 1 GiB of virtual space (which starts at 0xc0000000),
> perhaps colliding with the VMALLOC space.
>
> Putting them just below the 128 MiB boundary seems to work.
Interesting. I think this is also a problem on u-boot just waiting to
happen. u-boot locates itself at the end of RAM and likes to copy the
fdt and initrd to just below that. Any machine with 1G+ is going to hit
this. I avoided it because I limited u-boot to 512MB on highbank.
Rob
>
>>
>>
>> Nicolas
>>
>
> _______________________________________________
> devicetree-discuss mailing list
> devicetree-discuss at lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/devicetree-discuss
>
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: Where to put a large bootloader-supplied device tree on ARM ?
2012-07-12 20:34 ` Rob Herring
(?)
@ 2012-07-12 21:38 ` Albert ARIBAUD
-1 siblings, 0 replies; 130+ messages in thread
From: Albert ARIBAUD @ 2012-07-12 21:38 UTC (permalink / raw)
To: Rob Herring; +Cc: Mitch Bradley, U-Boot, devicetree-discuss, linux-arm-kernel
Hi Rob,
On Thu, 12 Jul 2012 15:34:17 -0500, Rob Herring <robherring2@gmail.com> wrote:
> [adding u-boot list]
>
> On 07/12/2012 01:52 AM, Mitch Bradley wrote:
> > On 7/8/2012 6:30 PM, Nicolas Pitre wrote:
> >> On Fri, 6 Jul 2012, Mitch Bradley wrote:
> >>
> >>> On 7/6/2012 3:23 PM, David VomLehn (dvomlehn) wrote:
> >>>> The kernel *must* go where it is linked, but the FDT contains only relative
> >>>> references and is thus free to go anywhere. The same is true of ramdisks,
> >>>> which
> >>>> are usually placed after the kernel.
> >>
> >> The kernel must go where it is linked *only* if you are using the
> >> 'Image' output. When using 'zImage' you can put the kernel anywhere in
> >> memory, or in the first 128MB of RAM if CONFIG_AUTO_ZRELADDR is used.
> >>
> >>> Right, but the kernel image is compressed, so after decompression it expands
> >>> into the area just after it. Also, the .bss segment is in that vicinity.
> >>
> >> To be exact, the compressed kernel moves itself out of the region where
> >> the decompressed kernel will end up before doing the decompression, but
> >> only if necessary. So it is a good idea to load zImage away from the
> >> decompressed kernel area to avoid this extra move and save some fraction
> >> of a second on boot time.
> >>
> >>> There's some code in arch/arm/boot/compressed/head.S to relocate
> >>> device tree blobs, but it requires CONFIG_ARM_APPENDED_DTB which
> >>> is not recommended - arch/arm/Kconfig recommends using the
> >>> documented boot protocol istead .
> >>
> >> This is in case a DTB is appended to zImage. When the DTB is detected,
> >> the moving of zImage out of the decompressed area must take care of
> >> moving the DTB as well.
> >>
> >>> Documentation/arm/Booting says
> >>> to put the dtb "in a region of memory where the kernel decompressor
> >>> will not overwrite it", further recommending the first 16KiB.
> >>>
> >>> As noted, the first 16KiB loses if the dtb is too large. And
> >>> "where the kernel decompressor will not overwrite it" says what
> >>> won't work, not what will. It appears that the decompressor works
> >>> out its addresses dynamically, so there's no hard prescription even
> >>> for what to avoid.
> >>
> >> A good rule of thumb is to take the size of the decompressed kernel and
> >> multiply this by 3. Rounding up is also fine. So for example if your
> >> arch/arm/boot/Image is 5MB, then putting anciliary data such as a
> >> ramdisk or a large DTB from 16MB into RAM or above should be fine.
> >>
> >>> For now, I'm putting the initrd at the end of memory and the dtb
> >>> below that. That seems to work, but I'm unsure whether or not
> >>> I'm just "getting lucky".
> >>
> >> That's also perfectly fine.
> >
> >
> > Alas, that worked for machines with 512 MiB of main memory, but failed
> > on 1 GiB machines. My guess is that, when the initrd and dtb are near
> > the top of a 1 GiB memory, the virtual address gets too near the top of
> > the kernel's 1 GiB of virtual space (which starts at 0xc0000000),
> > perhaps colliding with the VMALLOC space.
> >
> > Putting them just below the 128 MiB boundary seems to work.
>
> Interesting. I think this is also a problem on u-boot just waiting to
> happen. u-boot locates itself at the end of RAM and likes to copy the
> fdt and initrd to just below that. Any machine with 1G+ is going to hit
> this. I avoided it because I limited u-boot to 512MB on highbank.
If I'm not mistaken, yes U-Boot loads itself as high as it can, and I don't
know about the FDT, but no, U-Boot does not "like" to load initrd "just
below that": it loads initrd where the boot commands tell it to, and the
boot commands are written by board developers. Nothing in U-Boot forces
initrd to be loaded as high as possible.
That leaves the question of the FDT, though -- I'm not familiar enough
with it (yet) to tell if it is always located just under U-Boot or if
its placement is controllable by board commands.
Amicalement,
--
Albert.
^ permalink raw reply [flat|nested] 130+ messages in thread
* [U-Boot] Where to put a large bootloader-supplied device tree on ARM ?
@ 2012-07-12 21:38 ` Albert ARIBAUD
0 siblings, 0 replies; 130+ messages in thread
From: Albert ARIBAUD @ 2012-07-12 21:38 UTC (permalink / raw)
To: u-boot
Hi Rob,
On Thu, 12 Jul 2012 15:34:17 -0500, Rob Herring <robherring2@gmail.com> wrote:
> [adding u-boot list]
>
> On 07/12/2012 01:52 AM, Mitch Bradley wrote:
> > On 7/8/2012 6:30 PM, Nicolas Pitre wrote:
> >> On Fri, 6 Jul 2012, Mitch Bradley wrote:
> >>
> >>> On 7/6/2012 3:23 PM, David VomLehn (dvomlehn) wrote:
> >>>> The kernel *must* go where it is linked, but the FDT contains only relative
> >>>> references and is thus free to go anywhere. The same is true of ramdisks,
> >>>> which
> >>>> are usually placed after the kernel.
> >>
> >> The kernel must go where it is linked *only* if you are using the
> >> 'Image' output. When using 'zImage' you can put the kernel anywhere in
> >> memory, or in the first 128MB of RAM if CONFIG_AUTO_ZRELADDR is used.
> >>
> >>> Right, but the kernel image is compressed, so after decompression it expands
> >>> into the area just after it. Also, the .bss segment is in that vicinity.
> >>
> >> To be exact, the compressed kernel moves itself out of the region where
> >> the decompressed kernel will end up before doing the decompression, but
> >> only if necessary. So it is a good idea to load zImage away from the
> >> decompressed kernel area to avoid this extra move and save some fraction
> >> of a second on boot time.
> >>
> >>> There's some code in arch/arm/boot/compressed/head.S to relocate
> >>> device tree blobs, but it requires CONFIG_ARM_APPENDED_DTB which
> >>> is not recommended - arch/arm/Kconfig recommends using the
> >>> documented boot protocol istead .
> >>
> >> This is in case a DTB is appended to zImage. When the DTB is detected,
> >> the moving of zImage out of the decompressed area must take care of
> >> moving the DTB as well.
> >>
> >>> Documentation/arm/Booting says
> >>> to put the dtb "in a region of memory where the kernel decompressor
> >>> will not overwrite it", further recommending the first 16KiB.
> >>>
> >>> As noted, the first 16KiB loses if the dtb is too large. And
> >>> "where the kernel decompressor will not overwrite it" says what
> >>> won't work, not what will. It appears that the decompressor works
> >>> out its addresses dynamically, so there's no hard prescription even
> >>> for what to avoid.
> >>
> >> A good rule of thumb is to take the size of the decompressed kernel and
> >> multiply this by 3. Rounding up is also fine. So for example if your
> >> arch/arm/boot/Image is 5MB, then putting anciliary data such as a
> >> ramdisk or a large DTB from 16MB into RAM or above should be fine.
> >>
> >>> For now, I'm putting the initrd at the end of memory and the dtb
> >>> below that. That seems to work, but I'm unsure whether or not
> >>> I'm just "getting lucky".
> >>
> >> That's also perfectly fine.
> >
> >
> > Alas, that worked for machines with 512 MiB of main memory, but failed
> > on 1 GiB machines. My guess is that, when the initrd and dtb are near
> > the top of a 1 GiB memory, the virtual address gets too near the top of
> > the kernel's 1 GiB of virtual space (which starts at 0xc0000000),
> > perhaps colliding with the VMALLOC space.
> >
> > Putting them just below the 128 MiB boundary seems to work.
>
> Interesting. I think this is also a problem on u-boot just waiting to
> happen. u-boot locates itself at the end of RAM and likes to copy the
> fdt and initrd to just below that. Any machine with 1G+ is going to hit
> this. I avoided it because I limited u-boot to 512MB on highbank.
If I'm not mistaken, yes U-Boot loads itself as high as it can, and I don't
know about the FDT, but no, U-Boot does not "like" to load initrd "just
below that": it loads initrd where the boot commands tell it to, and the
boot commands are written by board developers. Nothing in U-Boot forces
initrd to be loaded as high as possible.
That leaves the question of the FDT, though -- I'm not familiar enough
with it (yet) to tell if it is always located just under U-Boot or if
its placement is controllable by board commands.
Amicalement,
--
Albert.
^ permalink raw reply [flat|nested] 130+ messages in thread
* [U-Boot] Where to put a large bootloader-supplied device tree on ARM ?
@ 2012-07-12 21:38 ` Albert ARIBAUD
0 siblings, 0 replies; 130+ messages in thread
From: Albert ARIBAUD @ 2012-07-12 21:38 UTC (permalink / raw)
To: linux-arm-kernel
Hi Rob,
On Thu, 12 Jul 2012 15:34:17 -0500, Rob Herring <robherring2@gmail.com> wrote:
> [adding u-boot list]
>
> On 07/12/2012 01:52 AM, Mitch Bradley wrote:
> > On 7/8/2012 6:30 PM, Nicolas Pitre wrote:
> >> On Fri, 6 Jul 2012, Mitch Bradley wrote:
> >>
> >>> On 7/6/2012 3:23 PM, David VomLehn (dvomlehn) wrote:
> >>>> The kernel *must* go where it is linked, but the FDT contains only relative
> >>>> references and is thus free to go anywhere. The same is true of ramdisks,
> >>>> which
> >>>> are usually placed after the kernel.
> >>
> >> The kernel must go where it is linked *only* if you are using the
> >> 'Image' output. When using 'zImage' you can put the kernel anywhere in
> >> memory, or in the first 128MB of RAM if CONFIG_AUTO_ZRELADDR is used.
> >>
> >>> Right, but the kernel image is compressed, so after decompression it expands
> >>> into the area just after it. Also, the .bss segment is in that vicinity.
> >>
> >> To be exact, the compressed kernel moves itself out of the region where
> >> the decompressed kernel will end up before doing the decompression, but
> >> only if necessary. So it is a good idea to load zImage away from the
> >> decompressed kernel area to avoid this extra move and save some fraction
> >> of a second on boot time.
> >>
> >>> There's some code in arch/arm/boot/compressed/head.S to relocate
> >>> device tree blobs, but it requires CONFIG_ARM_APPENDED_DTB which
> >>> is not recommended - arch/arm/Kconfig recommends using the
> >>> documented boot protocol istead .
> >>
> >> This is in case a DTB is appended to zImage. When the DTB is detected,
> >> the moving of zImage out of the decompressed area must take care of
> >> moving the DTB as well.
> >>
> >>> Documentation/arm/Booting says
> >>> to put the dtb "in a region of memory where the kernel decompressor
> >>> will not overwrite it", further recommending the first 16KiB.
> >>>
> >>> As noted, the first 16KiB loses if the dtb is too large. And
> >>> "where the kernel decompressor will not overwrite it" says what
> >>> won't work, not what will. It appears that the decompressor works
> >>> out its addresses dynamically, so there's no hard prescription even
> >>> for what to avoid.
> >>
> >> A good rule of thumb is to take the size of the decompressed kernel and
> >> multiply this by 3. Rounding up is also fine. So for example if your
> >> arch/arm/boot/Image is 5MB, then putting anciliary data such as a
> >> ramdisk or a large DTB from 16MB into RAM or above should be fine.
> >>
> >>> For now, I'm putting the initrd at the end of memory and the dtb
> >>> below that. That seems to work, but I'm unsure whether or not
> >>> I'm just "getting lucky".
> >>
> >> That's also perfectly fine.
> >
> >
> > Alas, that worked for machines with 512 MiB of main memory, but failed
> > on 1 GiB machines. My guess is that, when the initrd and dtb are near
> > the top of a 1 GiB memory, the virtual address gets too near the top of
> > the kernel's 1 GiB of virtual space (which starts at 0xc0000000),
> > perhaps colliding with the VMALLOC space.
> >
> > Putting them just below the 128 MiB boundary seems to work.
>
> Interesting. I think this is also a problem on u-boot just waiting to
> happen. u-boot locates itself at the end of RAM and likes to copy the
> fdt and initrd to just below that. Any machine with 1G+ is going to hit
> this. I avoided it because I limited u-boot to 512MB on highbank.
If I'm not mistaken, yes U-Boot loads itself as high as it can, and I don't
know about the FDT, but no, U-Boot does not "like" to load initrd "just
below that": it loads initrd where the boot commands tell it to, and the
boot commands are written by board developers. Nothing in U-Boot forces
initrd to be loaded as high as possible.
That leaves the question of the FDT, though -- I'm not familiar enough
with it (yet) to tell if it is always located just under U-Boot or if
its placement is controllable by board commands.
Amicalement,
--
Albert.
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: Where to put a large bootloader-supplied device tree on ARM ?
2012-07-12 21:38 ` Albert ARIBAUD
(?)
@ 2012-07-12 21:47 ` Wolfgang Denk
-1 siblings, 0 replies; 130+ messages in thread
From: Wolfgang Denk @ 2012-07-12 21:47 UTC (permalink / raw)
To: Albert ARIBAUD
Cc: Mitch Bradley, U-Boot, devicetree-discuss, linux-arm-kernel
Dear Albert ARIBAUD,
In message <20120712233801.0411daa7@lilith> you wrote:
>
> If I'm not mistaken, yes U-Boot loads itself as high as it can, and I don't
> know about the FDT, but no, U-Boot does not "like" to load initrd "just
> below that": it loads initrd where the boot commands tell it to, and the
> boot commands are written by board developers. Nothing in U-Boot forces
> initrd to be loaded as high as possible.
>
> That leaves the question of the FDT, though -- I'm not familiar enough
> with it (yet) to tell if it is always located just under U-Boot or if
> its placement is controllable by board commands.
You can always just set the "fdt_high" and "initrd_high" evironment
variables to restrict the positioning of initrd and FDT in RAM; see
the README for details.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
"He was so narrow minded he could see through a keyhole with both
eyes ..."
^ permalink raw reply [flat|nested] 130+ messages in thread
* [U-Boot] Where to put a large bootloader-supplied device tree on ARM ?
@ 2012-07-12 21:47 ` Wolfgang Denk
0 siblings, 0 replies; 130+ messages in thread
From: Wolfgang Denk @ 2012-07-12 21:47 UTC (permalink / raw)
To: u-boot
Dear Albert ARIBAUD,
In message <20120712233801.0411daa7@lilith> you wrote:
>
> If I'm not mistaken, yes U-Boot loads itself as high as it can, and I don't
> know about the FDT, but no, U-Boot does not "like" to load initrd "just
> below that": it loads initrd where the boot commands tell it to, and the
> boot commands are written by board developers. Nothing in U-Boot forces
> initrd to be loaded as high as possible.
>
> That leaves the question of the FDT, though -- I'm not familiar enough
> with it (yet) to tell if it is always located just under U-Boot or if
> its placement is controllable by board commands.
You can always just set the "fdt_high" and "initrd_high" evironment
variables to restrict the positioning of initrd and FDT in RAM; see
the README for details.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"He was so narrow minded he could see through a keyhole with both
eyes ..."
^ permalink raw reply [flat|nested] 130+ messages in thread
* [U-Boot] Where to put a large bootloader-supplied device tree on ARM ?
@ 2012-07-12 21:47 ` Wolfgang Denk
0 siblings, 0 replies; 130+ messages in thread
From: Wolfgang Denk @ 2012-07-12 21:47 UTC (permalink / raw)
To: linux-arm-kernel
Dear Albert ARIBAUD,
In message <20120712233801.0411daa7@lilith> you wrote:
>
> If I'm not mistaken, yes U-Boot loads itself as high as it can, and I don't
> know about the FDT, but no, U-Boot does not "like" to load initrd "just
> below that": it loads initrd where the boot commands tell it to, and the
> boot commands are written by board developers. Nothing in U-Boot forces
> initrd to be loaded as high as possible.
>
> That leaves the question of the FDT, though -- I'm not familiar enough
> with it (yet) to tell if it is always located just under U-Boot or if
> its placement is controllable by board commands.
You can always just set the "fdt_high" and "initrd_high" evironment
variables to restrict the positioning of initrd and FDT in RAM; see
the README for details.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"He was so narrow minded he could see through a keyhole with both
eyes ..."
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: Where to put a large bootloader-supplied device tree on ARM ?
2012-07-12 21:47 ` Wolfgang Denk
(?)
@ 2012-07-13 1:28 ` Rob Herring
-1 siblings, 0 replies; 130+ messages in thread
From: Rob Herring @ 2012-07-13 1:28 UTC (permalink / raw)
To: Wolfgang Denk, Albert ARIBAUD
Cc: Mitch Bradley, U-Boot, devicetree-discuss, linux-arm-kernel
On 07/12/2012 04:47 PM, Wolfgang Denk wrote:
> Dear Albert ARIBAUD,
>
> In message <20120712233801.0411daa7@lilith> you wrote:
>>
>> If I'm not mistaken, yes U-Boot loads itself as high as it can, and I don't
>> know about the FDT, but no, U-Boot does not "like" to load initrd "just
>> below that": it loads initrd where the boot commands tell it to, and the
>> boot commands are written by board developers. Nothing in U-Boot forces
>> initrd to be loaded as high as possible.
u-boot loads the initrd where you tell it, then bootm relocates it for
some reason.
>>
>> That leaves the question of the FDT, though -- I'm not familiar enough
>> with it (yet) to tell if it is always located just under U-Boot or if
>> its placement is controllable by board commands.
>
> You can always just set the "fdt_high" and "initrd_high" evironment
> variables to restrict the positioning of initrd and FDT in RAM; see
> the README for details.
Yes, I'm aware of all this, but this is not the default behavior and the
default behavior will not work in this case. It also has another bug
related to the relocation that I fixed:
http://www.mail-archive.com/u-boot@lists.denx.de/msg86475.html
Rob
^ permalink raw reply [flat|nested] 130+ messages in thread
* [U-Boot] Where to put a large bootloader-supplied device tree on ARM ?
@ 2012-07-13 1:28 ` Rob Herring
0 siblings, 0 replies; 130+ messages in thread
From: Rob Herring @ 2012-07-13 1:28 UTC (permalink / raw)
To: u-boot
On 07/12/2012 04:47 PM, Wolfgang Denk wrote:
> Dear Albert ARIBAUD,
>
> In message <20120712233801.0411daa7@lilith> you wrote:
>>
>> If I'm not mistaken, yes U-Boot loads itself as high as it can, and I don't
>> know about the FDT, but no, U-Boot does not "like" to load initrd "just
>> below that": it loads initrd where the boot commands tell it to, and the
>> boot commands are written by board developers. Nothing in U-Boot forces
>> initrd to be loaded as high as possible.
u-boot loads the initrd where you tell it, then bootm relocates it for
some reason.
>>
>> That leaves the question of the FDT, though -- I'm not familiar enough
>> with it (yet) to tell if it is always located just under U-Boot or if
>> its placement is controllable by board commands.
>
> You can always just set the "fdt_high" and "initrd_high" evironment
> variables to restrict the positioning of initrd and FDT in RAM; see
> the README for details.
Yes, I'm aware of all this, but this is not the default behavior and the
default behavior will not work in this case. It also has another bug
related to the relocation that I fixed:
http://www.mail-archive.com/u-boot at lists.denx.de/msg86475.html
Rob
^ permalink raw reply [flat|nested] 130+ messages in thread
* [U-Boot] Where to put a large bootloader-supplied device tree on ARM ?
@ 2012-07-13 1:28 ` Rob Herring
0 siblings, 0 replies; 130+ messages in thread
From: Rob Herring @ 2012-07-13 1:28 UTC (permalink / raw)
To: linux-arm-kernel
On 07/12/2012 04:47 PM, Wolfgang Denk wrote:
> Dear Albert ARIBAUD,
>
> In message <20120712233801.0411daa7@lilith> you wrote:
>>
>> If I'm not mistaken, yes U-Boot loads itself as high as it can, and I don't
>> know about the FDT, but no, U-Boot does not "like" to load initrd "just
>> below that": it loads initrd where the boot commands tell it to, and the
>> boot commands are written by board developers. Nothing in U-Boot forces
>> initrd to be loaded as high as possible.
u-boot loads the initrd where you tell it, then bootm relocates it for
some reason.
>>
>> That leaves the question of the FDT, though -- I'm not familiar enough
>> with it (yet) to tell if it is always located just under U-Boot or if
>> its placement is controllable by board commands.
>
> You can always just set the "fdt_high" and "initrd_high" evironment
> variables to restrict the positioning of initrd and FDT in RAM; see
> the README for details.
Yes, I'm aware of all this, but this is not the default behavior and the
default behavior will not work in this case. It also has another bug
related to the relocation that I fixed:
http://www.mail-archive.com/u-boot at lists.denx.de/msg86475.html
Rob
^ permalink raw reply [flat|nested] 130+ messages in thread
[parent not found: <4FFF79B6.6040508-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>]
* Re: [U-Boot] Where to put a large bootloader-supplied device tree on ARM ?
2012-07-13 1:28 ` Rob Herring
(?)
@ 2012-07-13 6:45 ` Albert ARIBAUD
-1 siblings, 0 replies; 130+ messages in thread
From: Albert ARIBAUD @ 2012-07-13 6:45 UTC (permalink / raw)
To: Rob Herring
Cc: U-Boot, devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ, Wolfgang Denk,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Hi Rob,
On Thu, 12 Jul 2012 20:28:22 -0500, Rob Herring <robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> On 07/12/2012 04:47 PM, Wolfgang Denk wrote:
> > Dear Albert ARIBAUD,
> >
> > In message <20120712233801.0411daa7@lilith> you wrote:
> >>
> >> If I'm not mistaken, yes U-Boot loads itself as high as it can, and I don't
> >> know about the FDT, but no, U-Boot does not "like" to load initrd "just
> >> below that": it loads initrd where the boot commands tell it to, and the
> >> boot commands are written by board developers. Nothing in U-Boot forces
> >> initrd to be loaded as high as possible.
>
> u-boot loads the initrd where you tell it, then bootm relocates it for
> some reason.
> >>
> >> That leaves the question of the FDT, though -- I'm not familiar enough
> >> with it (yet) to tell if it is always located just under U-Boot or if
> >> its placement is controllable by board commands.
> >
> > You can always just set the "fdt_high" and "initrd_high" evironment
> > variables to restrict the positioning of initrd and FDT in RAM; see
> > the README for details.
>
> Yes, I'm aware of all this, but this is not the default behavior and the
> default behavior will not work in this case. It also has another bug
> related to the relocation that I fixed:
>
> http://www.mail-archive.com/u-boot-0aAXYlwwYIKGBzrmiIFOJg@public.gmane.org/msg86475.html
>
> Rob
As for the default behavior, this becomes a board config issue, not a
U-Boot issue.
Regarding the patch, as a bugfix it will go in u-boot-arm/master
for 2012.07.
With all this, do we have the overall issue covered?
Amicalement,
--
Albert.
^ permalink raw reply [flat|nested] 130+ messages in thread
* [U-Boot] Where to put a large bootloader-supplied device tree on ARM ?
@ 2012-07-13 6:45 ` Albert ARIBAUD
0 siblings, 0 replies; 130+ messages in thread
From: Albert ARIBAUD @ 2012-07-13 6:45 UTC (permalink / raw)
To: u-boot
Hi Rob,
On Thu, 12 Jul 2012 20:28:22 -0500, Rob Herring <robherring2@gmail.com> wrote:
> On 07/12/2012 04:47 PM, Wolfgang Denk wrote:
> > Dear Albert ARIBAUD,
> >
> > In message <20120712233801.0411daa7@lilith> you wrote:
> >>
> >> If I'm not mistaken, yes U-Boot loads itself as high as it can, and I don't
> >> know about the FDT, but no, U-Boot does not "like" to load initrd "just
> >> below that": it loads initrd where the boot commands tell it to, and the
> >> boot commands are written by board developers. Nothing in U-Boot forces
> >> initrd to be loaded as high as possible.
>
> u-boot loads the initrd where you tell it, then bootm relocates it for
> some reason.
> >>
> >> That leaves the question of the FDT, though -- I'm not familiar enough
> >> with it (yet) to tell if it is always located just under U-Boot or if
> >> its placement is controllable by board commands.
> >
> > You can always just set the "fdt_high" and "initrd_high" evironment
> > variables to restrict the positioning of initrd and FDT in RAM; see
> > the README for details.
>
> Yes, I'm aware of all this, but this is not the default behavior and the
> default behavior will not work in this case. It also has another bug
> related to the relocation that I fixed:
>
> http://www.mail-archive.com/u-boot at lists.denx.de/msg86475.html
>
> Rob
As for the default behavior, this becomes a board config issue, not a
U-Boot issue.
Regarding the patch, as a bugfix it will go in u-boot-arm/master
for 2012.07.
With all this, do we have the overall issue covered?
Amicalement,
--
Albert.
^ permalink raw reply [flat|nested] 130+ messages in thread
* [U-Boot] Where to put a large bootloader-supplied device tree on ARM ?
@ 2012-07-13 6:45 ` Albert ARIBAUD
0 siblings, 0 replies; 130+ messages in thread
From: Albert ARIBAUD @ 2012-07-13 6:45 UTC (permalink / raw)
To: linux-arm-kernel
Hi Rob,
On Thu, 12 Jul 2012 20:28:22 -0500, Rob Herring <robherring2@gmail.com> wrote:
> On 07/12/2012 04:47 PM, Wolfgang Denk wrote:
> > Dear Albert ARIBAUD,
> >
> > In message <20120712233801.0411daa7@lilith> you wrote:
> >>
> >> If I'm not mistaken, yes U-Boot loads itself as high as it can, and I don't
> >> know about the FDT, but no, U-Boot does not "like" to load initrd "just
> >> below that": it loads initrd where the boot commands tell it to, and the
> >> boot commands are written by board developers. Nothing in U-Boot forces
> >> initrd to be loaded as high as possible.
>
> u-boot loads the initrd where you tell it, then bootm relocates it for
> some reason.
> >>
> >> That leaves the question of the FDT, though -- I'm not familiar enough
> >> with it (yet) to tell if it is always located just under U-Boot or if
> >> its placement is controllable by board commands.
> >
> > You can always just set the "fdt_high" and "initrd_high" evironment
> > variables to restrict the positioning of initrd and FDT in RAM; see
> > the README for details.
>
> Yes, I'm aware of all this, but this is not the default behavior and the
> default behavior will not work in this case. It also has another bug
> related to the relocation that I fixed:
>
> http://www.mail-archive.com/u-boot at lists.denx.de/msg86475.html
>
> Rob
As for the default behavior, this becomes a board config issue, not a
U-Boot issue.
Regarding the patch, as a bugfix it will go in u-boot-arm/master
for 2012.07.
With all this, do we have the overall issue covered?
Amicalement,
--
Albert.
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: [PATCH v2 01/12] ARM: Orion: DT support for IRQ and GPIO Controllers
2012-07-05 14:54 ` Arnd Bergmann
@ 2012-07-05 18:36 ` Mitch Bradley
-1 siblings, 0 replies; 130+ messages in thread
From: Mitch Bradley @ 2012-07-05 18:36 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Andrew Lunn, Jason Cooper,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
rob.herring-bsGFqQB8/DxBDgjK7y7TUQ,
linux-i2c-u79uwXL29TY76Z2rM5mHXA,
spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
On 7/5/2012 4:54 AM, Arnd Bergmann wrote:
> On Thursday 05 July 2012, Sebastian Hesselbarth wrote:
>> Andrew,
>>
>> is it possible to group all gpio banks into one DT description?
>> For mach-dove it could be something like:
>>
>> gpio: gpio-controller {
>> compatible = "marvell, orion-gpio";
>> ...
>>
>> bank0@d0400 {
>> reg = <0xd0400 0x40>;
>> ngpio = <8>;
>> mask-offset = <0>;
>> interrupts = <12>;
>> };
>>
>> bank1@d0400 {
>> reg = <0xd0400 0x40>;
>> ngpio = <8>;
>> mask-offset = <8>;
>> interrupts = <13>;
>> };
>
> This way you have multiple nodes with the same register
> and different names, which is not how it normally works.
The "mask-offset" property is really a "reg" in disguise.
"reg" is considerably more general than just "memory mapped
register address". It really means "any numeric identifier
that makes sense in the context of a parent device".
Therefore, one could say:
gpio: gpio-controller {
compatible = "marvell, orion-gpio";
reg = <0xd0400 0x40>;
#address-cells = <1>;
#size-cells = <0>;
...
bank0@0 {
reg = <0x0>;
ngpio = <8>;
mask-offset = <0>;
interrupts = <12>;
};
bank1@8 {
reg = <0x8>;
ngpio = <8>;
interrupts = <13>;
};
>
>>
>> This would have the advantage that DT describes gpio-to-irq dependencies.
>> Moreover, nodes that reference gpios can do gpios = <&gpio 71 0>; instead of
>> gpios = <&gpio3 7 0>;
>
> Is that desired?
>
> The device tree representation should match what is in the data sheet
> normally. If they are in a single continuous number range, then we should
> probably have a single device node with multiple register ranges
> rather than one device node for each 32-bit register. Looking at
> arch/arm/plat-orion/gpio.c I think that is not actually the case though
> and having separate banks is more logical.
>
> Something completely different I just noticed in the original patch:
>
>> @@ -90,6 +74,27 @@ static void pmu_irq_handler(unsigned int irq, struct irq_desc *desc)
>> }
>> }
>>
>> +static int __initdata gpio0_irqs[4] = {
>> + IRQ_DOVE_GPIO_0_7,
>> + IRQ_DOVE_GPIO_8_15,
>> + IRQ_DOVE_GPIO_16_23,
>> + IRQ_DOVE_GPIO_24_31,
>> +};
>> +
>> +static int __initdata gpio1_irqs[4] = {
>> + IRQ_DOVE_HIGH_GPIO,
>> + 0,
>> + 0,
>> + 0,
>> +};
>
> I think the latter one needs to be
>
> +static int __initdata gpio1_irqs[4] = {
> + IRQ_DOVE_HIGH_GPIO,
> + IRQ_DOVE_HIGH_GPIO,
> + IRQ_DOVE_HIGH_GPIO,
> + IRQ_DOVE_HIGH_GPIO,
> +};
>
> so we register all four parts to the same primary IRQ. The
> same is true for the devicetree representation.
>
> Arnd
>
> _______________________________________________
> devicetree-discuss mailing list
> devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org
> https://lists.ozlabs.org/listinfo/devicetree-discuss
>
^ permalink raw reply [flat|nested] 130+ messages in thread* [PATCH v2 01/12] ARM: Orion: DT support for IRQ and GPIO Controllers
@ 2012-07-05 18:36 ` Mitch Bradley
0 siblings, 0 replies; 130+ messages in thread
From: Mitch Bradley @ 2012-07-05 18:36 UTC (permalink / raw)
To: linux-arm-kernel
On 7/5/2012 4:54 AM, Arnd Bergmann wrote:
> On Thursday 05 July 2012, Sebastian Hesselbarth wrote:
>> Andrew,
>>
>> is it possible to group all gpio banks into one DT description?
>> For mach-dove it could be something like:
>>
>> gpio: gpio-controller {
>> compatible = "marvell, orion-gpio";
>> ...
>>
>> bank0 at d0400 {
>> reg = <0xd0400 0x40>;
>> ngpio = <8>;
>> mask-offset = <0>;
>> interrupts = <12>;
>> };
>>
>> bank1 at d0400 {
>> reg = <0xd0400 0x40>;
>> ngpio = <8>;
>> mask-offset = <8>;
>> interrupts = <13>;
>> };
>
> This way you have multiple nodes with the same register
> and different names, which is not how it normally works.
The "mask-offset" property is really a "reg" in disguise.
"reg" is considerably more general than just "memory mapped
register address". It really means "any numeric identifier
that makes sense in the context of a parent device".
Therefore, one could say:
gpio: gpio-controller {
compatible = "marvell, orion-gpio";
reg = <0xd0400 0x40>;
#address-cells = <1>;
#size-cells = <0>;
...
bank0 at 0 {
reg = <0x0>;
ngpio = <8>;
mask-offset = <0>;
interrupts = <12>;
};
bank1 at 8 {
reg = <0x8>;
ngpio = <8>;
interrupts = <13>;
};
>
>>
>> This would have the advantage that DT describes gpio-to-irq dependencies.
>> Moreover, nodes that reference gpios can do gpios = <&gpio 71 0>; instead of
>> gpios = <&gpio3 7 0>;
>
> Is that desired?
>
> The device tree representation should match what is in the data sheet
> normally. If they are in a single continuous number range, then we should
> probably have a single device node with multiple register ranges
> rather than one device node for each 32-bit register. Looking at
> arch/arm/plat-orion/gpio.c I think that is not actually the case though
> and having separate banks is more logical.
>
> Something completely different I just noticed in the original patch:
>
>> @@ -90,6 +74,27 @@ static void pmu_irq_handler(unsigned int irq, struct irq_desc *desc)
>> }
>> }
>>
>> +static int __initdata gpio0_irqs[4] = {
>> + IRQ_DOVE_GPIO_0_7,
>> + IRQ_DOVE_GPIO_8_15,
>> + IRQ_DOVE_GPIO_16_23,
>> + IRQ_DOVE_GPIO_24_31,
>> +};
>> +
>> +static int __initdata gpio1_irqs[4] = {
>> + IRQ_DOVE_HIGH_GPIO,
>> + 0,
>> + 0,
>> + 0,
>> +};
>
> I think the latter one needs to be
>
> +static int __initdata gpio1_irqs[4] = {
> + IRQ_DOVE_HIGH_GPIO,
> + IRQ_DOVE_HIGH_GPIO,
> + IRQ_DOVE_HIGH_GPIO,
> + IRQ_DOVE_HIGH_GPIO,
> +};
>
> so we register all four parts to the same primary IRQ. The
> same is true for the devicetree representation.
>
> Arnd
>
> _______________________________________________
> devicetree-discuss mailing list
> devicetree-discuss at lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/devicetree-discuss
>
^ permalink raw reply [flat|nested] 130+ messages in thread
* [PATCH v2 02/12] SPI: Refactor spi-orion to use SPI framework queue.
2012-07-03 14:22 ` Andrew Lunn
@ 2012-07-03 14:22 ` Andrew Lunn
-1 siblings, 0 replies; 130+ messages in thread
From: Andrew Lunn @ 2012-07-03 14:22 UTC (permalink / raw)
To: Jason Cooper
Cc: Andrew Lunn, devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
rob.herring-bsGFqQB8/DxBDgjK7y7TUQ, Michael Walle,
linux-i2c-u79uwXL29TY76Z2rM5mHXA,
spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Replace the deprecated master->transfer with transfer_one_message()
and allow the SPI subsystem handle all the queuing of messages.
Signed-off-by: Andrew Lunn <andrew-g2DYL2Zd6BY@public.gmane.org>
Acked-by: Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
---
drivers/spi/spi-orion.c | 209 ++++++++++++++---------------------------------
1 file changed, 61 insertions(+), 148 deletions(-)
diff --git a/drivers/spi/spi-orion.c b/drivers/spi/spi-orion.c
index dfd04e9..547d983 100644
--- a/drivers/spi/spi-orion.c
+++ b/drivers/spi/spi-orion.c
@@ -35,12 +35,6 @@
#define ORION_SPI_CLK_PRESCALE_MASK 0x1F
struct orion_spi {
- struct work_struct work;
-
- /* Lock access to transfer list. */
- spinlock_t lock;
-
- struct list_head msg_queue;
struct spi_master *master;
void __iomem *base;
unsigned int max_speed;
@@ -49,8 +43,6 @@ struct orion_spi {
struct clk *clk;
};
-static struct workqueue_struct *orion_spi_wq;
-
static inline void __iomem *spi_reg(struct orion_spi *orion_spi, u32 reg)
{
return orion_spi->base + reg;
@@ -277,73 +269,78 @@ out:
}
-static void orion_spi_work(struct work_struct *work)
+static int orion_spi_transfer_one_message(struct spi_master *master,
+ struct spi_message *m)
{
- struct orion_spi *orion_spi =
- container_of(work, struct orion_spi, work);
-
- spin_lock_irq(&orion_spi->lock);
- while (!list_empty(&orion_spi->msg_queue)) {
- struct spi_message *m;
- struct spi_device *spi;
- struct spi_transfer *t = NULL;
- int par_override = 0;
- int status = 0;
- int cs_active = 0;
-
- m = container_of(orion_spi->msg_queue.next, struct spi_message,
- queue);
+ struct orion_spi *orion_spi = spi_master_get_devdata(master);
+ struct spi_device *spi = m->spi;
+ struct spi_transfer *t = NULL;
+ int par_override = 0;
+ int status = 0;
+ int cs_active = 0;
- list_del_init(&m->queue);
- spin_unlock_irq(&orion_spi->lock);
+ /* Load defaults */
+ status = orion_spi_setup_transfer(spi, NULL);
- spi = m->spi;
+ if (status < 0)
+ goto msg_done;
- /* Load defaults */
- status = orion_spi_setup_transfer(spi, NULL);
+ list_for_each_entry(t, &m->transfers, transfer_list) {
+ /* make sure buffer length is even when working in 16
+ * bit mode*/
+ if ((t->bits_per_word == 16) && (t->len & 1)) {
+ dev_err(&spi->dev,
+ "message rejected : "
+ "odd data length %d while in 16 bit mode\n",
+ t->len);
+ status = -EIO;
+ goto msg_done;
+ }
- if (status < 0)
+ if (t->speed_hz && t->speed_hz < orion_spi->min_speed) {
+ dev_err(&spi->dev,
+ "message rejected : "
+ "device min speed (%d Hz) exceeds "
+ "required transfer speed (%d Hz)\n",
+ orion_spi->min_speed, t->speed_hz);
+ status = -EIO;
goto msg_done;
+ }
- list_for_each_entry(t, &m->transfers, transfer_list) {
- if (par_override || t->speed_hz || t->bits_per_word) {
- par_override = 1;
- status = orion_spi_setup_transfer(spi, t);
- if (status < 0)
- break;
- if (!t->speed_hz && !t->bits_per_word)
- par_override = 0;
- }
-
- if (!cs_active) {
- orion_spi_set_cs(orion_spi, 1);
- cs_active = 1;
- }
-
- if (t->len)
- m->actual_length +=
- orion_spi_write_read(spi, t);
-
- if (t->delay_usecs)
- udelay(t->delay_usecs);
-
- if (t->cs_change) {
- orion_spi_set_cs(orion_spi, 0);
- cs_active = 0;
- }
+ if (par_override || t->speed_hz || t->bits_per_word) {
+ par_override = 1;
+ status = orion_spi_setup_transfer(spi, t);
+ if (status < 0)
+ break;
+ if (!t->speed_hz && !t->bits_per_word)
+ par_override = 0;
}
-msg_done:
- if (cs_active)
- orion_spi_set_cs(orion_spi, 0);
+ if (!cs_active) {
+ orion_spi_set_cs(orion_spi, 1);
+ cs_active = 1;
+ }
- m->status = status;
- m->complete(m->context);
+ if (t->len)
+ m->actual_length += orion_spi_write_read(spi, t);
- spin_lock_irq(&orion_spi->lock);
+ if (t->delay_usecs)
+ udelay(t->delay_usecs);
+
+ if (t->cs_change) {
+ orion_spi_set_cs(orion_spi, 0);
+ cs_active = 0;
+ }
}
- spin_unlock_irq(&orion_spi->lock);
+msg_done:
+ if (cs_active)
+ orion_spi_set_cs(orion_spi, 0);
+
+ m->status = status;
+ spi_finalize_current_message(master);
+
+ return 0;
}
static int __init orion_spi_reset(struct orion_spi *orion_spi)
@@ -376,75 +373,6 @@ static int orion_spi_setup(struct spi_device *spi)
return 0;
}
-static int orion_spi_transfer(struct spi_device *spi, struct spi_message *m)
-{
- struct orion_spi *orion_spi;
- struct spi_transfer *t = NULL;
- unsigned long flags;
-
- m->actual_length = 0;
- m->status = 0;
-
- /* reject invalid messages and transfers */
- if (list_empty(&m->transfers) || !m->complete)
- return -EINVAL;
-
- orion_spi = spi_master_get_devdata(spi->master);
-
- list_for_each_entry(t, &m->transfers, transfer_list) {
- unsigned int bits_per_word = spi->bits_per_word;
-
- if (t->tx_buf == NULL && t->rx_buf == NULL && t->len) {
- dev_err(&spi->dev,
- "message rejected : "
- "invalid transfer data buffers\n");
- goto msg_rejected;
- }
-
- if (t->bits_per_word)
- bits_per_word = t->bits_per_word;
-
- if ((bits_per_word != 8) && (bits_per_word != 16)) {
- dev_err(&spi->dev,
- "message rejected : "
- "invalid transfer bits_per_word (%d bits)\n",
- bits_per_word);
- goto msg_rejected;
- }
- /*make sure buffer length is even when working in 16 bit mode*/
- if ((t->bits_per_word == 16) && (t->len & 1)) {
- dev_err(&spi->dev,
- "message rejected : "
- "odd data length (%d) while in 16 bit mode\n",
- t->len);
- goto msg_rejected;
- }
-
- if (t->speed_hz && t->speed_hz < orion_spi->min_speed) {
- dev_err(&spi->dev,
- "message rejected : "
- "device min speed (%d Hz) exceeds "
- "required transfer speed (%d Hz)\n",
- orion_spi->min_speed, t->speed_hz);
- goto msg_rejected;
- }
- }
-
-
- spin_lock_irqsave(&orion_spi->lock, flags);
- list_add_tail(&m->queue, &orion_spi->msg_queue);
- queue_work(orion_spi_wq, &orion_spi->work);
- spin_unlock_irqrestore(&orion_spi->lock, flags);
-
- return 0;
-msg_rejected:
- /* Message rejected and not queued */
- m->status = -EINVAL;
- if (m->complete)
- m->complete(m->context);
- return -EINVAL;
-}
-
static int __init orion_spi_probe(struct platform_device *pdev)
{
struct spi_master *master;
@@ -469,7 +397,7 @@ static int __init orion_spi_probe(struct platform_device *pdev)
master->mode_bits = 0;
master->setup = orion_spi_setup;
- master->transfer = orion_spi_transfer;
+ master->transfer_one_message = orion_spi_transfer_one_message;
master->num_chipselect = ORION_NUM_CHIPSELECTS;
dev_set_drvdata(&pdev->dev, master);
@@ -503,11 +431,6 @@ static int __init orion_spi_probe(struct platform_device *pdev)
}
spi->base = ioremap(r->start, SZ_1K);
- INIT_WORK(&spi->work, orion_spi_work);
-
- spin_lock_init(&spi->lock);
- INIT_LIST_HEAD(&spi->msg_queue);
-
if (orion_spi_reset(spi) < 0)
goto out_rel_mem;
@@ -531,14 +454,12 @@ out:
static int __exit orion_spi_remove(struct platform_device *pdev)
{
struct spi_master *master;
- struct orion_spi *spi;
struct resource *r;
+ struct orion_spi *spi;
master = dev_get_drvdata(&pdev->dev);
spi = spi_master_get_devdata(master);
- cancel_work_sync(&spi->work);
-
clk_disable_unprepare(spi->clk);
clk_put(spi->clk);
@@ -562,21 +483,13 @@ static struct platform_driver orion_spi_driver = {
static int __init orion_spi_init(void)
{
- orion_spi_wq = create_singlethread_workqueue(
- orion_spi_driver.driver.name);
- if (orion_spi_wq == NULL)
- return -ENOMEM;
-
return platform_driver_probe(&orion_spi_driver, orion_spi_probe);
}
module_init(orion_spi_init);
static void __exit orion_spi_exit(void)
{
- flush_workqueue(orion_spi_wq);
platform_driver_unregister(&orion_spi_driver);
-
- destroy_workqueue(orion_spi_wq);
}
module_exit(orion_spi_exit);
--
1.7.10
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
^ permalink raw reply related [flat|nested] 130+ messages in thread* [PATCH v2 02/12] SPI: Refactor spi-orion to use SPI framework queue.
@ 2012-07-03 14:22 ` Andrew Lunn
0 siblings, 0 replies; 130+ messages in thread
From: Andrew Lunn @ 2012-07-03 14:22 UTC (permalink / raw)
To: linux-arm-kernel
Replace the deprecated master->transfer with transfer_one_message()
and allow the SPI subsystem handle all the queuing of messages.
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
---
drivers/spi/spi-orion.c | 209 ++++++++++++++---------------------------------
1 file changed, 61 insertions(+), 148 deletions(-)
diff --git a/drivers/spi/spi-orion.c b/drivers/spi/spi-orion.c
index dfd04e9..547d983 100644
--- a/drivers/spi/spi-orion.c
+++ b/drivers/spi/spi-orion.c
@@ -35,12 +35,6 @@
#define ORION_SPI_CLK_PRESCALE_MASK 0x1F
struct orion_spi {
- struct work_struct work;
-
- /* Lock access to transfer list. */
- spinlock_t lock;
-
- struct list_head msg_queue;
struct spi_master *master;
void __iomem *base;
unsigned int max_speed;
@@ -49,8 +43,6 @@ struct orion_spi {
struct clk *clk;
};
-static struct workqueue_struct *orion_spi_wq;
-
static inline void __iomem *spi_reg(struct orion_spi *orion_spi, u32 reg)
{
return orion_spi->base + reg;
@@ -277,73 +269,78 @@ out:
}
-static void orion_spi_work(struct work_struct *work)
+static int orion_spi_transfer_one_message(struct spi_master *master,
+ struct spi_message *m)
{
- struct orion_spi *orion_spi =
- container_of(work, struct orion_spi, work);
-
- spin_lock_irq(&orion_spi->lock);
- while (!list_empty(&orion_spi->msg_queue)) {
- struct spi_message *m;
- struct spi_device *spi;
- struct spi_transfer *t = NULL;
- int par_override = 0;
- int status = 0;
- int cs_active = 0;
-
- m = container_of(orion_spi->msg_queue.next, struct spi_message,
- queue);
+ struct orion_spi *orion_spi = spi_master_get_devdata(master);
+ struct spi_device *spi = m->spi;
+ struct spi_transfer *t = NULL;
+ int par_override = 0;
+ int status = 0;
+ int cs_active = 0;
- list_del_init(&m->queue);
- spin_unlock_irq(&orion_spi->lock);
+ /* Load defaults */
+ status = orion_spi_setup_transfer(spi, NULL);
- spi = m->spi;
+ if (status < 0)
+ goto msg_done;
- /* Load defaults */
- status = orion_spi_setup_transfer(spi, NULL);
+ list_for_each_entry(t, &m->transfers, transfer_list) {
+ /* make sure buffer length is even when working in 16
+ * bit mode*/
+ if ((t->bits_per_word == 16) && (t->len & 1)) {
+ dev_err(&spi->dev,
+ "message rejected : "
+ "odd data length %d while in 16 bit mode\n",
+ t->len);
+ status = -EIO;
+ goto msg_done;
+ }
- if (status < 0)
+ if (t->speed_hz && t->speed_hz < orion_spi->min_speed) {
+ dev_err(&spi->dev,
+ "message rejected : "
+ "device min speed (%d Hz) exceeds "
+ "required transfer speed (%d Hz)\n",
+ orion_spi->min_speed, t->speed_hz);
+ status = -EIO;
goto msg_done;
+ }
- list_for_each_entry(t, &m->transfers, transfer_list) {
- if (par_override || t->speed_hz || t->bits_per_word) {
- par_override = 1;
- status = orion_spi_setup_transfer(spi, t);
- if (status < 0)
- break;
- if (!t->speed_hz && !t->bits_per_word)
- par_override = 0;
- }
-
- if (!cs_active) {
- orion_spi_set_cs(orion_spi, 1);
- cs_active = 1;
- }
-
- if (t->len)
- m->actual_length +=
- orion_spi_write_read(spi, t);
-
- if (t->delay_usecs)
- udelay(t->delay_usecs);
-
- if (t->cs_change) {
- orion_spi_set_cs(orion_spi, 0);
- cs_active = 0;
- }
+ if (par_override || t->speed_hz || t->bits_per_word) {
+ par_override = 1;
+ status = orion_spi_setup_transfer(spi, t);
+ if (status < 0)
+ break;
+ if (!t->speed_hz && !t->bits_per_word)
+ par_override = 0;
}
-msg_done:
- if (cs_active)
- orion_spi_set_cs(orion_spi, 0);
+ if (!cs_active) {
+ orion_spi_set_cs(orion_spi, 1);
+ cs_active = 1;
+ }
- m->status = status;
- m->complete(m->context);
+ if (t->len)
+ m->actual_length += orion_spi_write_read(spi, t);
- spin_lock_irq(&orion_spi->lock);
+ if (t->delay_usecs)
+ udelay(t->delay_usecs);
+
+ if (t->cs_change) {
+ orion_spi_set_cs(orion_spi, 0);
+ cs_active = 0;
+ }
}
- spin_unlock_irq(&orion_spi->lock);
+msg_done:
+ if (cs_active)
+ orion_spi_set_cs(orion_spi, 0);
+
+ m->status = status;
+ spi_finalize_current_message(master);
+
+ return 0;
}
static int __init orion_spi_reset(struct orion_spi *orion_spi)
@@ -376,75 +373,6 @@ static int orion_spi_setup(struct spi_device *spi)
return 0;
}
-static int orion_spi_transfer(struct spi_device *spi, struct spi_message *m)
-{
- struct orion_spi *orion_spi;
- struct spi_transfer *t = NULL;
- unsigned long flags;
-
- m->actual_length = 0;
- m->status = 0;
-
- /* reject invalid messages and transfers */
- if (list_empty(&m->transfers) || !m->complete)
- return -EINVAL;
-
- orion_spi = spi_master_get_devdata(spi->master);
-
- list_for_each_entry(t, &m->transfers, transfer_list) {
- unsigned int bits_per_word = spi->bits_per_word;
-
- if (t->tx_buf == NULL && t->rx_buf == NULL && t->len) {
- dev_err(&spi->dev,
- "message rejected : "
- "invalid transfer data buffers\n");
- goto msg_rejected;
- }
-
- if (t->bits_per_word)
- bits_per_word = t->bits_per_word;
-
- if ((bits_per_word != 8) && (bits_per_word != 16)) {
- dev_err(&spi->dev,
- "message rejected : "
- "invalid transfer bits_per_word (%d bits)\n",
- bits_per_word);
- goto msg_rejected;
- }
- /*make sure buffer length is even when working in 16 bit mode*/
- if ((t->bits_per_word == 16) && (t->len & 1)) {
- dev_err(&spi->dev,
- "message rejected : "
- "odd data length (%d) while in 16 bit mode\n",
- t->len);
- goto msg_rejected;
- }
-
- if (t->speed_hz && t->speed_hz < orion_spi->min_speed) {
- dev_err(&spi->dev,
- "message rejected : "
- "device min speed (%d Hz) exceeds "
- "required transfer speed (%d Hz)\n",
- orion_spi->min_speed, t->speed_hz);
- goto msg_rejected;
- }
- }
-
-
- spin_lock_irqsave(&orion_spi->lock, flags);
- list_add_tail(&m->queue, &orion_spi->msg_queue);
- queue_work(orion_spi_wq, &orion_spi->work);
- spin_unlock_irqrestore(&orion_spi->lock, flags);
-
- return 0;
-msg_rejected:
- /* Message rejected and not queued */
- m->status = -EINVAL;
- if (m->complete)
- m->complete(m->context);
- return -EINVAL;
-}
-
static int __init orion_spi_probe(struct platform_device *pdev)
{
struct spi_master *master;
@@ -469,7 +397,7 @@ static int __init orion_spi_probe(struct platform_device *pdev)
master->mode_bits = 0;
master->setup = orion_spi_setup;
- master->transfer = orion_spi_transfer;
+ master->transfer_one_message = orion_spi_transfer_one_message;
master->num_chipselect = ORION_NUM_CHIPSELECTS;
dev_set_drvdata(&pdev->dev, master);
@@ -503,11 +431,6 @@ static int __init orion_spi_probe(struct platform_device *pdev)
}
spi->base = ioremap(r->start, SZ_1K);
- INIT_WORK(&spi->work, orion_spi_work);
-
- spin_lock_init(&spi->lock);
- INIT_LIST_HEAD(&spi->msg_queue);
-
if (orion_spi_reset(spi) < 0)
goto out_rel_mem;
@@ -531,14 +454,12 @@ out:
static int __exit orion_spi_remove(struct platform_device *pdev)
{
struct spi_master *master;
- struct orion_spi *spi;
struct resource *r;
+ struct orion_spi *spi;
master = dev_get_drvdata(&pdev->dev);
spi = spi_master_get_devdata(master);
- cancel_work_sync(&spi->work);
-
clk_disable_unprepare(spi->clk);
clk_put(spi->clk);
@@ -562,21 +483,13 @@ static struct platform_driver orion_spi_driver = {
static int __init orion_spi_init(void)
{
- orion_spi_wq = create_singlethread_workqueue(
- orion_spi_driver.driver.name);
- if (orion_spi_wq == NULL)
- return -ENOMEM;
-
return platform_driver_probe(&orion_spi_driver, orion_spi_probe);
}
module_init(orion_spi_init);
static void __exit orion_spi_exit(void)
{
- flush_workqueue(orion_spi_wq);
platform_driver_unregister(&orion_spi_driver);
-
- destroy_workqueue(orion_spi_wq);
}
module_exit(orion_spi_exit);
--
1.7.10
^ permalink raw reply related [flat|nested] 130+ messages in thread
* [PATCH v2 03/12] spi-orion: remove uneeded spi_info
2012-07-03 14:22 ` Andrew Lunn
@ 2012-07-03 14:22 ` Andrew Lunn
-1 siblings, 0 replies; 130+ messages in thread
From: Andrew Lunn @ 2012-07-03 14:22 UTC (permalink / raw)
To: Jason Cooper
Cc: Andrew Lunn, devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
rob.herring-bsGFqQB8/DxBDgjK7y7TUQ, Michael Walle,
linux-i2c-u79uwXL29TY76Z2rM5mHXA,
spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
From: Michael Walle <michael-QKn5cuLxLXY@public.gmane.org>
This was formerly used to store the tclk value. This is now discovered
using the clk API, rather than pass it as platform data.
Signed-off-by: Michael Walle <michael-QKn5cuLxLXY@public.gmane.org>
Acked-by: Jason Cooper <jason-NLaQJdtUoK4Be96aLqz0jA@public.gmane.org>
Signed-off-by: Andrew Lunn <andrew-g2DYL2Zd6BY@public.gmane.org>
---
drivers/spi/spi-orion.c | 5 -----
1 file changed, 5 deletions(-)
diff --git a/drivers/spi/spi-orion.c b/drivers/spi/spi-orion.c
index 547d983..8c3d625 100644
--- a/drivers/spi/spi-orion.c
+++ b/drivers/spi/spi-orion.c
@@ -39,7 +39,6 @@ struct orion_spi {
void __iomem *base;
unsigned int max_speed;
unsigned int min_speed;
- struct orion_spi_info *spi_info;
struct clk *clk;
};
@@ -378,12 +377,9 @@ static int __init orion_spi_probe(struct platform_device *pdev)
struct spi_master *master;
struct orion_spi *spi;
struct resource *r;
- struct orion_spi_info *spi_info;
unsigned long tclk_hz;
int status = 0;
- spi_info = pdev->dev.platform_data;
-
master = spi_alloc_master(&pdev->dev, sizeof *spi);
if (master == NULL) {
dev_dbg(&pdev->dev, "master allocation failed\n");
@@ -404,7 +400,6 @@ static int __init orion_spi_probe(struct platform_device *pdev)
spi = spi_master_get_devdata(master);
spi->master = master;
- spi->spi_info = spi_info;
spi->clk = clk_get(&pdev->dev, NULL);
if (IS_ERR(spi->clk)) {
--
1.7.10
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
^ permalink raw reply related [flat|nested] 130+ messages in thread* [PATCH v2 03/12] spi-orion: remove uneeded spi_info
@ 2012-07-03 14:22 ` Andrew Lunn
0 siblings, 0 replies; 130+ messages in thread
From: Andrew Lunn @ 2012-07-03 14:22 UTC (permalink / raw)
To: linux-arm-kernel
From: Michael Walle <michael@walle.cc>
This was formerly used to store the tclk value. This is now discovered
using the clk API, rather than pass it as platform data.
Signed-off-by: Michael Walle <michael@walle.cc>
Acked-by: Jason Cooper <jason@lakedaemon.net>
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
---
drivers/spi/spi-orion.c | 5 -----
1 file changed, 5 deletions(-)
diff --git a/drivers/spi/spi-orion.c b/drivers/spi/spi-orion.c
index 547d983..8c3d625 100644
--- a/drivers/spi/spi-orion.c
+++ b/drivers/spi/spi-orion.c
@@ -39,7 +39,6 @@ struct orion_spi {
void __iomem *base;
unsigned int max_speed;
unsigned int min_speed;
- struct orion_spi_info *spi_info;
struct clk *clk;
};
@@ -378,12 +377,9 @@ static int __init orion_spi_probe(struct platform_device *pdev)
struct spi_master *master;
struct orion_spi *spi;
struct resource *r;
- struct orion_spi_info *spi_info;
unsigned long tclk_hz;
int status = 0;
- spi_info = pdev->dev.platform_data;
-
master = spi_alloc_master(&pdev->dev, sizeof *spi);
if (master == NULL) {
dev_dbg(&pdev->dev, "master allocation failed\n");
@@ -404,7 +400,6 @@ static int __init orion_spi_probe(struct platform_device *pdev)
spi = spi_master_get_devdata(master);
spi->master = master;
- spi->spi_info = spi_info;
spi->clk = clk_get(&pdev->dev, NULL);
if (IS_ERR(spi->clk)) {
--
1.7.10
^ permalink raw reply related [flat|nested] 130+ messages in thread
* [PATCH v2 04/12] spi-orion: add device tree binding
2012-07-03 14:22 ` Andrew Lunn
@ 2012-07-03 14:22 ` Andrew Lunn
-1 siblings, 0 replies; 130+ messages in thread
From: Andrew Lunn @ 2012-07-03 14:22 UTC (permalink / raw)
To: Jason Cooper
Cc: grant.likely-s3s/WqlpOiPyB63q8FvJNQ,
spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
linux-i2c-u79uwXL29TY76Z2rM5mHXA,
rob.herring-bsGFqQB8/DxBDgjK7y7TUQ,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Michael Walle,
Andrew Lunn
From: Michael Walle <michael-QKn5cuLxLXY@public.gmane.org>
Signed-off-by: Michael Walle <michael-QKn5cuLxLXY@public.gmane.org>
Signed-off-by: Andrew Lunn <andrew-g2DYL2Zd6BY@public.gmane.org>
Acked-by: Jason Cooper <jason-NLaQJdtUoK4Be96aLqz0jA@public.gmane.org>
---
Documentation/devicetree/bindings/spi/spi-orion.txt | 5 +++++
drivers/spi/spi-orion.c | 9 +++++++++
2 files changed, 14 insertions(+)
create mode 100644 Documentation/devicetree/bindings/spi/spi-orion.txt
diff --git a/Documentation/devicetree/bindings/spi/spi-orion.txt b/Documentation/devicetree/bindings/spi/spi-orion.txt
new file mode 100644
index 0000000..e68597a
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/spi-orion.txt
@@ -0,0 +1,5 @@
+Marvell Orion SPI device
+
+Required properties:
+- compatible : should be "marvell,orion-spi".
+- reg : offset and length of the register set for the device
diff --git a/drivers/spi/spi-orion.c b/drivers/spi/spi-orion.c
index 8c3d625..b16db3d 100644
--- a/drivers/spi/spi-orion.c
+++ b/drivers/spi/spi-orion.c
@@ -17,6 +17,7 @@
#include <linux/io.h>
#include <linux/spi/spi.h>
#include <linux/module.h>
+#include <linux/of.h>
#include <linux/clk.h>
#include <asm/unaligned.h>
@@ -429,6 +430,7 @@ static int __init orion_spi_probe(struct platform_device *pdev)
if (orion_spi_reset(spi) < 0)
goto out_rel_mem;
+ master->dev.of_node = pdev->dev.of_node;
status = spi_register_master(master);
if (status < 0)
goto out_rel_mem;
@@ -468,10 +470,17 @@ static int __exit orion_spi_remove(struct platform_device *pdev)
MODULE_ALIAS("platform:" DRIVER_NAME);
+static const struct of_device_id orion_spi_of_match_table[] __devinitdata = {
+ { .compatible = "marvell,orion-spi", },
+ {}
+};
+MODULE_DEVICE_TABLE(of, orion_spi_of_match_table);
+
static struct platform_driver orion_spi_driver = {
.driver = {
.name = DRIVER_NAME,
.owner = THIS_MODULE,
+ .of_match_table = of_match_ptr(orion_spi_of_match_table),
},
.remove = __exit_p(orion_spi_remove),
};
--
1.7.10
^ permalink raw reply related [flat|nested] 130+ messages in thread* [PATCH v2 04/12] spi-orion: add device tree binding
@ 2012-07-03 14:22 ` Andrew Lunn
0 siblings, 0 replies; 130+ messages in thread
From: Andrew Lunn @ 2012-07-03 14:22 UTC (permalink / raw)
To: linux-arm-kernel
From: Michael Walle <michael@walle.cc>
Signed-off-by: Michael Walle <michael@walle.cc>
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Acked-by: Jason Cooper <jason@lakedaemon.net>
---
Documentation/devicetree/bindings/spi/spi-orion.txt | 5 +++++
drivers/spi/spi-orion.c | 9 +++++++++
2 files changed, 14 insertions(+)
create mode 100644 Documentation/devicetree/bindings/spi/spi-orion.txt
diff --git a/Documentation/devicetree/bindings/spi/spi-orion.txt b/Documentation/devicetree/bindings/spi/spi-orion.txt
new file mode 100644
index 0000000..e68597a
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/spi-orion.txt
@@ -0,0 +1,5 @@
+Marvell Orion SPI device
+
+Required properties:
+- compatible : should be "marvell,orion-spi".
+- reg : offset and length of the register set for the device
diff --git a/drivers/spi/spi-orion.c b/drivers/spi/spi-orion.c
index 8c3d625..b16db3d 100644
--- a/drivers/spi/spi-orion.c
+++ b/drivers/spi/spi-orion.c
@@ -17,6 +17,7 @@
#include <linux/io.h>
#include <linux/spi/spi.h>
#include <linux/module.h>
+#include <linux/of.h>
#include <linux/clk.h>
#include <asm/unaligned.h>
@@ -429,6 +430,7 @@ static int __init orion_spi_probe(struct platform_device *pdev)
if (orion_spi_reset(spi) < 0)
goto out_rel_mem;
+ master->dev.of_node = pdev->dev.of_node;
status = spi_register_master(master);
if (status < 0)
goto out_rel_mem;
@@ -468,10 +470,17 @@ static int __exit orion_spi_remove(struct platform_device *pdev)
MODULE_ALIAS("platform:" DRIVER_NAME);
+static const struct of_device_id orion_spi_of_match_table[] __devinitdata = {
+ { .compatible = "marvell,orion-spi", },
+ {}
+};
+MODULE_DEVICE_TABLE(of, orion_spi_of_match_table);
+
static struct platform_driver orion_spi_driver = {
.driver = {
.name = DRIVER_NAME,
.owner = THIS_MODULE,
+ .of_match_table = of_match_ptr(orion_spi_of_match_table),
},
.remove = __exit_p(orion_spi_remove),
};
--
1.7.10
^ permalink raw reply related [flat|nested] 130+ messages in thread
* [PATCH v2 05/12] ARM: kirkwood: use devicetree for orion-spi
2012-07-03 14:22 ` Andrew Lunn
@ 2012-07-03 14:22 ` Andrew Lunn
-1 siblings, 0 replies; 130+ messages in thread
From: Andrew Lunn @ 2012-07-03 14:22 UTC (permalink / raw)
To: Jason Cooper
Cc: Andrew Lunn, devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
rob.herring-bsGFqQB8/DxBDgjK7y7TUQ, Michael Walle,
linux-i2c-u79uwXL29TY76Z2rM5mHXA,
spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
Michael Walle, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
From: Michael Walle <michael-QKn5cuLxLXY@public.gmane.org>
Populate the devices with auxdata to set the device names which are used by
clkdev to lookup the clocks.
Signed-off-by: Michael Walle <micheal-QKn5cuLxLXY@public.gmane.org>
Signed-off-by: Andrew Lunn <andrew-g2DYL2Zd6BY@public.gmane.org>
---
arch/arm/boot/dts/kirkwood.dtsi | 9 +++++++++
arch/arm/mach-kirkwood/board-dt.c | 8 +++++++-
2 files changed, 16 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/kirkwood.dtsi b/arch/arm/boot/dts/kirkwood.dtsi
index 66544d7..c9f36e7 100644
--- a/arch/arm/boot/dts/kirkwood.dtsi
+++ b/arch/arm/boot/dts/kirkwood.dtsi
@@ -60,6 +60,15 @@
interrupts = <53>;
};
+ spi@10600 {
+ compatible = "marvell,orion-spi";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ cell-index = <0>;
+ reg = <0x10600 0x28>;
+ status = "disabled";
+ };
+
nand@3000000 {
#address-cells = <1>;
#size-cells = <1>;
diff --git a/arch/arm/mach-kirkwood/board-dt.c b/arch/arm/mach-kirkwood/board-dt.c
index 27ac3d8..8f8da5d 100644
--- a/arch/arm/mach-kirkwood/board-dt.c
+++ b/arch/arm/mach-kirkwood/board-dt.c
@@ -26,6 +26,11 @@ static struct of_device_id kirkwood_dt_match_table[] __initdata = {
{ }
};
+struct of_dev_auxdata kirkwood_auxdata_lookup[] __initdata = {
+ OF_DEV_AUXDATA("marvell,orion-spi", 0xf1010600, "orion_spi.0", NULL),
+ {},
+};
+
static void __init kirkwood_dt_init(void)
{
pr_info("Kirkwood: %s, TCLK=%d.\n", kirkwood_id(), kirkwood_tclk);
@@ -69,7 +74,8 @@ static void __init kirkwood_dt_init(void)
if (of_machine_is_compatible("raidsonic,ib-nas62x0"))
ib62x0_init();
- of_platform_populate(NULL, kirkwood_dt_match_table, NULL, NULL);
+ of_platform_populate(NULL, kirkwood_dt_match_table,
+ kirkwood_auxdata_lookup, NULL);
}
static const char *kirkwood_dt_board_compat[] = {
--
1.7.10
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
^ permalink raw reply related [flat|nested] 130+ messages in thread* [PATCH v2 05/12] ARM: kirkwood: use devicetree for orion-spi
@ 2012-07-03 14:22 ` Andrew Lunn
0 siblings, 0 replies; 130+ messages in thread
From: Andrew Lunn @ 2012-07-03 14:22 UTC (permalink / raw)
To: linux-arm-kernel
From: Michael Walle <michael@walle.cc>
Populate the devices with auxdata to set the device names which are used by
clkdev to lookup the clocks.
Signed-off-by: Michael Walle <micheal@walle.cc>
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
---
arch/arm/boot/dts/kirkwood.dtsi | 9 +++++++++
arch/arm/mach-kirkwood/board-dt.c | 8 +++++++-
2 files changed, 16 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/kirkwood.dtsi b/arch/arm/boot/dts/kirkwood.dtsi
index 66544d7..c9f36e7 100644
--- a/arch/arm/boot/dts/kirkwood.dtsi
+++ b/arch/arm/boot/dts/kirkwood.dtsi
@@ -60,6 +60,15 @@
interrupts = <53>;
};
+ spi at 10600 {
+ compatible = "marvell,orion-spi";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ cell-index = <0>;
+ reg = <0x10600 0x28>;
+ status = "disabled";
+ };
+
nand at 3000000 {
#address-cells = <1>;
#size-cells = <1>;
diff --git a/arch/arm/mach-kirkwood/board-dt.c b/arch/arm/mach-kirkwood/board-dt.c
index 27ac3d8..8f8da5d 100644
--- a/arch/arm/mach-kirkwood/board-dt.c
+++ b/arch/arm/mach-kirkwood/board-dt.c
@@ -26,6 +26,11 @@ static struct of_device_id kirkwood_dt_match_table[] __initdata = {
{ }
};
+struct of_dev_auxdata kirkwood_auxdata_lookup[] __initdata = {
+ OF_DEV_AUXDATA("marvell,orion-spi", 0xf1010600, "orion_spi.0", NULL),
+ {},
+};
+
static void __init kirkwood_dt_init(void)
{
pr_info("Kirkwood: %s, TCLK=%d.\n", kirkwood_id(), kirkwood_tclk);
@@ -69,7 +74,8 @@ static void __init kirkwood_dt_init(void)
if (of_machine_is_compatible("raidsonic,ib-nas62x0"))
ib62x0_init();
- of_platform_populate(NULL, kirkwood_dt_match_table, NULL, NULL);
+ of_platform_populate(NULL, kirkwood_dt_match_table,
+ kirkwood_auxdata_lookup, NULL);
}
static const char *kirkwood_dt_board_compat[] = {
--
1.7.10
^ permalink raw reply related [flat|nested] 130+ messages in thread
* [PATCH v2 06/12] ARM: kirkwood: use devicetree for SPI on dreamplug
2012-07-03 14:22 ` Andrew Lunn
@ 2012-07-03 14:22 ` Andrew Lunn
-1 siblings, 0 replies; 130+ messages in thread
From: Andrew Lunn @ 2012-07-03 14:22 UTC (permalink / raw)
To: Jason Cooper
Cc: Andrew Lunn, devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
rob.herring-bsGFqQB8/DxBDgjK7y7TUQ, Michael Walle,
linux-i2c-u79uwXL29TY76Z2rM5mHXA,
spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
From: Michael Walle <michael-QKn5cuLxLXY@public.gmane.org>
Use the device tree for the SPI driver and partition layout.
Signed-off-by: Michael Walle <michael-QKn5cuLxLXY@public.gmane.org>
Signed-off-by: Andrew Lunn <andrew-g2DYL2Zd6BY@public.gmane.org>
---
arch/arm/boot/dts/kirkwood-dreamplug.dts | 29 +++++++++++++++++++++
arch/arm/mach-kirkwood/board-dreamplug.c | 41 ------------------------------
2 files changed, 29 insertions(+), 41 deletions(-)
diff --git a/arch/arm/boot/dts/kirkwood-dreamplug.dts b/arch/arm/boot/dts/kirkwood-dreamplug.dts
index a5376b8..d74d1ae 100644
--- a/arch/arm/boot/dts/kirkwood-dreamplug.dts
+++ b/arch/arm/boot/dts/kirkwood-dreamplug.dts
@@ -20,5 +20,34 @@
clock-frequency = <200000000>;
status = "ok";
};
+
+ spi@10600 {
+ status = "okay";
+
+ m25p40@0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "mx25l1606e";
+ reg = <0>;
+ spi-max-frequency = <50000000>;
+ mode = <0>;
+
+ partition@0 {
+ reg = <0x0 0x80000>;
+ label = "u-boot";
+ };
+
+ partition@100000 {
+ reg = <0x100000 0x10000>;
+ label = "u-boot env";
+ };
+
+ partition@180000 {
+ reg = <0x180000 0x10000>;
+ label = "dtb";
+ };
+ };
+ };
};
+
};
diff --git a/arch/arm/mach-kirkwood/board-dreamplug.c b/arch/arm/mach-kirkwood/board-dreamplug.c
index 55e357a..eb0e4d5 100644
--- a/arch/arm/mach-kirkwood/board-dreamplug.c
+++ b/arch/arm/mach-kirkwood/board-dreamplug.c
@@ -14,7 +14,6 @@
#include <linux/kernel.h>
#include <linux/init.h>
#include <linux/platform_device.h>
-#include <linux/mtd/partitions.h>
#include <linux/ata_platform.h>
#include <linux/mv643xx_eth.h>
#include <linux/of.h>
@@ -36,42 +35,6 @@
#include "common.h"
#include "mpp.h"
-struct mtd_partition dreamplug_partitions[] = {
- {
- .name = "u-boot",
- .size = SZ_512K,
- .offset = 0,
- },
- {
- .name = "u-boot env",
- .size = SZ_64K,
- .offset = SZ_512K + SZ_512K,
- },
- {
- .name = "dtb",
- .size = SZ_64K,
- .offset = SZ_512K + SZ_512K + SZ_512K,
- },
-};
-
-static const struct flash_platform_data dreamplug_spi_slave_data = {
- .type = "mx25l1606e",
- .name = "spi_flash",
- .parts = dreamplug_partitions,
- .nr_parts = ARRAY_SIZE(dreamplug_partitions),
-};
-
-static struct spi_board_info __initdata dreamplug_spi_slave_info[] = {
- {
- .modalias = "m25p80",
- .platform_data = &dreamplug_spi_slave_data,
- .irq = -1,
- .max_speed_hz = 50000000,
- .bus_num = 0,
- .chip_select = 0,
- },
-};
-
static struct mv643xx_eth_platform_data dreamplug_ge00_data = {
.phy_addr = MV643XX_ETH_PHY_ADDR(0),
};
@@ -137,10 +100,6 @@ void __init dreamplug_init(void)
*/
kirkwood_mpp_conf(dreamplug_mpp_config);
- spi_register_board_info(dreamplug_spi_slave_info,
- ARRAY_SIZE(dreamplug_spi_slave_info));
- kirkwood_spi_init();
-
kirkwood_ehci_init();
kirkwood_ge00_init(&dreamplug_ge00_data);
kirkwood_ge01_init(&dreamplug_ge01_data);
--
1.7.10
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
^ permalink raw reply related [flat|nested] 130+ messages in thread* [PATCH v2 06/12] ARM: kirkwood: use devicetree for SPI on dreamplug
@ 2012-07-03 14:22 ` Andrew Lunn
0 siblings, 0 replies; 130+ messages in thread
From: Andrew Lunn @ 2012-07-03 14:22 UTC (permalink / raw)
To: linux-arm-kernel
From: Michael Walle <michael@walle.cc>
Use the device tree for the SPI driver and partition layout.
Signed-off-by: Michael Walle <michael@walle.cc>
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
---
arch/arm/boot/dts/kirkwood-dreamplug.dts | 29 +++++++++++++++++++++
arch/arm/mach-kirkwood/board-dreamplug.c | 41 ------------------------------
2 files changed, 29 insertions(+), 41 deletions(-)
diff --git a/arch/arm/boot/dts/kirkwood-dreamplug.dts b/arch/arm/boot/dts/kirkwood-dreamplug.dts
index a5376b8..d74d1ae 100644
--- a/arch/arm/boot/dts/kirkwood-dreamplug.dts
+++ b/arch/arm/boot/dts/kirkwood-dreamplug.dts
@@ -20,5 +20,34 @@
clock-frequency = <200000000>;
status = "ok";
};
+
+ spi at 10600 {
+ status = "okay";
+
+ m25p40 at 0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "mx25l1606e";
+ reg = <0>;
+ spi-max-frequency = <50000000>;
+ mode = <0>;
+
+ partition at 0 {
+ reg = <0x0 0x80000>;
+ label = "u-boot";
+ };
+
+ partition at 100000 {
+ reg = <0x100000 0x10000>;
+ label = "u-boot env";
+ };
+
+ partition at 180000 {
+ reg = <0x180000 0x10000>;
+ label = "dtb";
+ };
+ };
+ };
};
+
};
diff --git a/arch/arm/mach-kirkwood/board-dreamplug.c b/arch/arm/mach-kirkwood/board-dreamplug.c
index 55e357a..eb0e4d5 100644
--- a/arch/arm/mach-kirkwood/board-dreamplug.c
+++ b/arch/arm/mach-kirkwood/board-dreamplug.c
@@ -14,7 +14,6 @@
#include <linux/kernel.h>
#include <linux/init.h>
#include <linux/platform_device.h>
-#include <linux/mtd/partitions.h>
#include <linux/ata_platform.h>
#include <linux/mv643xx_eth.h>
#include <linux/of.h>
@@ -36,42 +35,6 @@
#include "common.h"
#include "mpp.h"
-struct mtd_partition dreamplug_partitions[] = {
- {
- .name = "u-boot",
- .size = SZ_512K,
- .offset = 0,
- },
- {
- .name = "u-boot env",
- .size = SZ_64K,
- .offset = SZ_512K + SZ_512K,
- },
- {
- .name = "dtb",
- .size = SZ_64K,
- .offset = SZ_512K + SZ_512K + SZ_512K,
- },
-};
-
-static const struct flash_platform_data dreamplug_spi_slave_data = {
- .type = "mx25l1606e",
- .name = "spi_flash",
- .parts = dreamplug_partitions,
- .nr_parts = ARRAY_SIZE(dreamplug_partitions),
-};
-
-static struct spi_board_info __initdata dreamplug_spi_slave_info[] = {
- {
- .modalias = "m25p80",
- .platform_data = &dreamplug_spi_slave_data,
- .irq = -1,
- .max_speed_hz = 50000000,
- .bus_num = 0,
- .chip_select = 0,
- },
-};
-
static struct mv643xx_eth_platform_data dreamplug_ge00_data = {
.phy_addr = MV643XX_ETH_PHY_ADDR(0),
};
@@ -137,10 +100,6 @@ void __init dreamplug_init(void)
*/
kirkwood_mpp_conf(dreamplug_mpp_config);
- spi_register_board_info(dreamplug_spi_slave_info,
- ARRAY_SIZE(dreamplug_spi_slave_info));
- kirkwood_spi_init();
-
kirkwood_ehci_init();
kirkwood_ge00_init(&dreamplug_ge00_data);
kirkwood_ge01_init(&dreamplug_ge01_data);
--
1.7.10
^ permalink raw reply related [flat|nested] 130+ messages in thread
* [PATCH v2 07/12] I2C: MV64XXX: Add Device Tree support
2012-07-03 14:22 ` Andrew Lunn
@ 2012-07-03 14:22 ` Andrew Lunn
-1 siblings, 0 replies; 130+ messages in thread
From: Andrew Lunn @ 2012-07-03 14:22 UTC (permalink / raw)
To: Jason Cooper
Cc: Andrew Lunn, devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
rob.herring-bsGFqQB8/DxBDgjK7y7TUQ, Michael Walle,
linux-i2c-u79uwXL29TY76Z2rM5mHXA,
spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Extends the driver to get properties from device tree. Also extend the
kirkwood DT support to supply the needed properties.
Signed-off-by: Andrew Lunn <andrew-g2DYL2Zd6BY@public.gmane.org>
---
Documentation/devicetree/bindings/i2c/mrvl-i2c.txt | 32 ++++++++++++++++-
arch/arm/boot/dts/kirkwood.dtsi | 13 +++++++
arch/arm/mach-kirkwood/board-dt.c | 2 ++
drivers/i2c/busses/i2c-mv64xxx.c | 38 +++++++++++++++++---
4 files changed, 79 insertions(+), 6 deletions(-)
diff --git a/Documentation/devicetree/bindings/i2c/mrvl-i2c.txt b/Documentation/devicetree/bindings/i2c/mrvl-i2c.txt
index b891ee2..90d09d2 100644
--- a/Documentation/devicetree/bindings/i2c/mrvl-i2c.txt
+++ b/Documentation/devicetree/bindings/i2c/mrvl-i2c.txt
@@ -1,4 +1,4 @@
-* I2C
+* Marvell MMP I2C controller
Required properties :
@@ -32,3 +32,33 @@ Examples:
interrupts = <58>;
};
+* Marvell MV64XXX I2C controller
+
+Required properties :
+
+ - reg : Offset and length of the register set for the device
+ - compatible : should be "marvell,mv64xxx-i2c"
+ - interrupts : the interrupt number
+ - frequency-m : m factor in baud rate calculation
+ - frequency-n : n factor in baud rate calculation
+ - timeout-ms : How long to wait for a transaction to complete
+
+Baud Rate:
+
+The baud rate is calculated thus:
+
+Fscl = Ftclk
+ ------------------------------------------
+ (frequency-n + 1)
+ 10 *(frequency-m + 1) * 2
+
+Examples:
+
+ i2c@11000 {
+ compatible = "marvell,mv64xxx-i2c";
+ reg = <0x11000 0x20>;
+ interrupts = <29>;
+ frequency-m = <4>;
+ frequency-n = <4>;
+ timeout-ms = <1000>;
+ };
diff --git a/arch/arm/boot/dts/kirkwood.dtsi b/arch/arm/boot/dts/kirkwood.dtsi
index c9f36e7..c8bc122 100644
--- a/arch/arm/boot/dts/kirkwood.dtsi
+++ b/arch/arm/boot/dts/kirkwood.dtsi
@@ -81,5 +81,18 @@
/* set partition map and/or chip-delay in board dts */
status = "disabled";
};
+
+ i2c@11000 {
+ compatible = "marvell,mv64xxx-i2c";
+ reg = <0x11000 0x20>;
+ interrupt = <29>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ interrupts = <29>;
+ frequency-m = <8>;
+ frequency-n = <3>;
+ timeout-ms = <1000>;
+ status = "disable";
+ };
};
};
diff --git a/arch/arm/mach-kirkwood/board-dt.c b/arch/arm/mach-kirkwood/board-dt.c
index 8f8da5d..24c8fdd 100644
--- a/arch/arm/mach-kirkwood/board-dt.c
+++ b/arch/arm/mach-kirkwood/board-dt.c
@@ -28,6 +28,8 @@ static struct of_device_id kirkwood_dt_match_table[] __initdata = {
struct of_dev_auxdata kirkwood_auxdata_lookup[] __initdata = {
OF_DEV_AUXDATA("marvell,orion-spi", 0xf1010600, "orion_spi.0", NULL),
+ OF_DEV_AUXDATA("marvell,mv64xxx-i2c", 0xf1011000, "mv64xxx_i2c.0",
+ NULL),
{},
};
diff --git a/drivers/i2c/busses/i2c-mv64xxx.c b/drivers/i2c/busses/i2c-mv64xxx.c
index 4f44a33..2146984 100644
--- a/drivers/i2c/busses/i2c-mv64xxx.c
+++ b/drivers/i2c/busses/i2c-mv64xxx.c
@@ -18,6 +18,9 @@
#include <linux/mv643xx_i2c.h>
#include <linux/platform_device.h>
#include <linux/io.h>
+#include <linux/of.h>
+#include <linux/of_irq.h>
+#include <linux/of_i2c.h>
/* Register defines */
#define MV64XXX_I2C_REG_SLAVE_ADDR 0x00
@@ -528,7 +531,7 @@ mv64xxx_i2c_probe(struct platform_device *pd)
struct mv64xxx_i2c_pdata *pdata = pd->dev.platform_data;
int rc;
- if ((pd->id != 0) || !pdata)
+ if ((!pdata && !pd->dev.of_node) || (pdata && (pd->id != 0)))
return -ENODEV;
drv_data = kzalloc(sizeof(struct mv64xxx_i2c_data), GFP_KERNEL);
@@ -546,19 +549,35 @@ mv64xxx_i2c_probe(struct platform_device *pd)
init_waitqueue_head(&drv_data->waitq);
spin_lock_init(&drv_data->lock);
- drv_data->freq_m = pdata->freq_m;
- drv_data->freq_n = pdata->freq_n;
- drv_data->irq = platform_get_irq(pd, 0);
+ if (pd->dev.of_node) {
+ of_property_read_u32(pd->dev.of_node, "frequency-m",
+ &drv_data->freq_m);
+ of_property_read_u32(pd->dev.of_node, "frequency-n",
+ &drv_data->freq_n);
+ drv_data->irq = irq_of_parse_and_map(pd->dev.of_node, 0);
+ } else {
+ drv_data->freq_m = pdata->freq_m;
+ drv_data->freq_n = pdata->freq_n;
+ drv_data->irq = platform_get_irq(pd, 0);
+ }
+
if (drv_data->irq < 0) {
rc = -ENXIO;
goto exit_unmap_regs;
}
+
drv_data->adapter.dev.parent = &pd->dev;
drv_data->adapter.algo = &mv64xxx_i2c_algo;
drv_data->adapter.owner = THIS_MODULE;
drv_data->adapter.class = I2C_CLASS_HWMON | I2C_CLASS_SPD;
- drv_data->adapter.timeout = msecs_to_jiffies(pdata->timeout);
+ if (pd->dev.of_node)
+ drv_data->adapter.timeout = msecs_to_jiffies(
+ of_property_read_u32(pd->dev.of_node, "timeout-ms",
+ &drv_data->freq_n));
+ else
+ drv_data->adapter.timeout = msecs_to_jiffies(pdata->timeout);
drv_data->adapter.nr = pd->id;
+ drv_data->adapter.dev.of_node = pd->dev.of_node;
platform_set_drvdata(pd, drv_data);
i2c_set_adapdata(&drv_data->adapter, drv_data);
@@ -577,6 +596,8 @@ mv64xxx_i2c_probe(struct platform_device *pd)
goto exit_free_irq;
}
+ of_i2c_register_devices(&drv_data->adapter);
+
return 0;
exit_free_irq:
@@ -602,12 +623,19 @@ mv64xxx_i2c_remove(struct platform_device *dev)
return rc;
}
+static const struct of_device_id mv64xxx_i2c_of_match_table[] __devinitdata = {
+ { .compatible = "marvell,mv64xxx-i2c", },
+ {}
+};
+MODULE_DEVICE_TABLE(of, mv64xxx_i2c_of_match_table);
+
static struct platform_driver mv64xxx_i2c_driver = {
.probe = mv64xxx_i2c_probe,
.remove = __devexit_p(mv64xxx_i2c_remove),
.driver = {
.owner = THIS_MODULE,
.name = MV64XXX_I2C_CTLR_NAME,
+ .of_match_table = of_match_ptr(mv64xxx_i2c_of_match_table),
},
};
--
1.7.10
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
^ permalink raw reply related [flat|nested] 130+ messages in thread* [PATCH v2 07/12] I2C: MV64XXX: Add Device Tree support
@ 2012-07-03 14:22 ` Andrew Lunn
0 siblings, 0 replies; 130+ messages in thread
From: Andrew Lunn @ 2012-07-03 14:22 UTC (permalink / raw)
To: linux-arm-kernel
Extends the driver to get properties from device tree. Also extend the
kirkwood DT support to supply the needed properties.
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
---
Documentation/devicetree/bindings/i2c/mrvl-i2c.txt | 32 ++++++++++++++++-
arch/arm/boot/dts/kirkwood.dtsi | 13 +++++++
arch/arm/mach-kirkwood/board-dt.c | 2 ++
drivers/i2c/busses/i2c-mv64xxx.c | 38 +++++++++++++++++---
4 files changed, 79 insertions(+), 6 deletions(-)
diff --git a/Documentation/devicetree/bindings/i2c/mrvl-i2c.txt b/Documentation/devicetree/bindings/i2c/mrvl-i2c.txt
index b891ee2..90d09d2 100644
--- a/Documentation/devicetree/bindings/i2c/mrvl-i2c.txt
+++ b/Documentation/devicetree/bindings/i2c/mrvl-i2c.txt
@@ -1,4 +1,4 @@
-* I2C
+* Marvell MMP I2C controller
Required properties :
@@ -32,3 +32,33 @@ Examples:
interrupts = <58>;
};
+* Marvell MV64XXX I2C controller
+
+Required properties :
+
+ - reg : Offset and length of the register set for the device
+ - compatible : should be "marvell,mv64xxx-i2c"
+ - interrupts : the interrupt number
+ - frequency-m : m factor in baud rate calculation
+ - frequency-n : n factor in baud rate calculation
+ - timeout-ms : How long to wait for a transaction to complete
+
+Baud Rate:
+
+The baud rate is calculated thus:
+
+Fscl = Ftclk
+ ------------------------------------------
+ (frequency-n + 1)
+ 10 *(frequency-m + 1) * 2
+
+Examples:
+
+ i2c at 11000 {
+ compatible = "marvell,mv64xxx-i2c";
+ reg = <0x11000 0x20>;
+ interrupts = <29>;
+ frequency-m = <4>;
+ frequency-n = <4>;
+ timeout-ms = <1000>;
+ };
diff --git a/arch/arm/boot/dts/kirkwood.dtsi b/arch/arm/boot/dts/kirkwood.dtsi
index c9f36e7..c8bc122 100644
--- a/arch/arm/boot/dts/kirkwood.dtsi
+++ b/arch/arm/boot/dts/kirkwood.dtsi
@@ -81,5 +81,18 @@
/* set partition map and/or chip-delay in board dts */
status = "disabled";
};
+
+ i2c at 11000 {
+ compatible = "marvell,mv64xxx-i2c";
+ reg = <0x11000 0x20>;
+ interrupt = <29>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ interrupts = <29>;
+ frequency-m = <8>;
+ frequency-n = <3>;
+ timeout-ms = <1000>;
+ status = "disable";
+ };
};
};
diff --git a/arch/arm/mach-kirkwood/board-dt.c b/arch/arm/mach-kirkwood/board-dt.c
index 8f8da5d..24c8fdd 100644
--- a/arch/arm/mach-kirkwood/board-dt.c
+++ b/arch/arm/mach-kirkwood/board-dt.c
@@ -28,6 +28,8 @@ static struct of_device_id kirkwood_dt_match_table[] __initdata = {
struct of_dev_auxdata kirkwood_auxdata_lookup[] __initdata = {
OF_DEV_AUXDATA("marvell,orion-spi", 0xf1010600, "orion_spi.0", NULL),
+ OF_DEV_AUXDATA("marvell,mv64xxx-i2c", 0xf1011000, "mv64xxx_i2c.0",
+ NULL),
{},
};
diff --git a/drivers/i2c/busses/i2c-mv64xxx.c b/drivers/i2c/busses/i2c-mv64xxx.c
index 4f44a33..2146984 100644
--- a/drivers/i2c/busses/i2c-mv64xxx.c
+++ b/drivers/i2c/busses/i2c-mv64xxx.c
@@ -18,6 +18,9 @@
#include <linux/mv643xx_i2c.h>
#include <linux/platform_device.h>
#include <linux/io.h>
+#include <linux/of.h>
+#include <linux/of_irq.h>
+#include <linux/of_i2c.h>
/* Register defines */
#define MV64XXX_I2C_REG_SLAVE_ADDR 0x00
@@ -528,7 +531,7 @@ mv64xxx_i2c_probe(struct platform_device *pd)
struct mv64xxx_i2c_pdata *pdata = pd->dev.platform_data;
int rc;
- if ((pd->id != 0) || !pdata)
+ if ((!pdata && !pd->dev.of_node) || (pdata && (pd->id != 0)))
return -ENODEV;
drv_data = kzalloc(sizeof(struct mv64xxx_i2c_data), GFP_KERNEL);
@@ -546,19 +549,35 @@ mv64xxx_i2c_probe(struct platform_device *pd)
init_waitqueue_head(&drv_data->waitq);
spin_lock_init(&drv_data->lock);
- drv_data->freq_m = pdata->freq_m;
- drv_data->freq_n = pdata->freq_n;
- drv_data->irq = platform_get_irq(pd, 0);
+ if (pd->dev.of_node) {
+ of_property_read_u32(pd->dev.of_node, "frequency-m",
+ &drv_data->freq_m);
+ of_property_read_u32(pd->dev.of_node, "frequency-n",
+ &drv_data->freq_n);
+ drv_data->irq = irq_of_parse_and_map(pd->dev.of_node, 0);
+ } else {
+ drv_data->freq_m = pdata->freq_m;
+ drv_data->freq_n = pdata->freq_n;
+ drv_data->irq = platform_get_irq(pd, 0);
+ }
+
if (drv_data->irq < 0) {
rc = -ENXIO;
goto exit_unmap_regs;
}
+
drv_data->adapter.dev.parent = &pd->dev;
drv_data->adapter.algo = &mv64xxx_i2c_algo;
drv_data->adapter.owner = THIS_MODULE;
drv_data->adapter.class = I2C_CLASS_HWMON | I2C_CLASS_SPD;
- drv_data->adapter.timeout = msecs_to_jiffies(pdata->timeout);
+ if (pd->dev.of_node)
+ drv_data->adapter.timeout = msecs_to_jiffies(
+ of_property_read_u32(pd->dev.of_node, "timeout-ms",
+ &drv_data->freq_n));
+ else
+ drv_data->adapter.timeout = msecs_to_jiffies(pdata->timeout);
drv_data->adapter.nr = pd->id;
+ drv_data->adapter.dev.of_node = pd->dev.of_node;
platform_set_drvdata(pd, drv_data);
i2c_set_adapdata(&drv_data->adapter, drv_data);
@@ -577,6 +596,8 @@ mv64xxx_i2c_probe(struct platform_device *pd)
goto exit_free_irq;
}
+ of_i2c_register_devices(&drv_data->adapter);
+
return 0;
exit_free_irq:
@@ -602,12 +623,19 @@ mv64xxx_i2c_remove(struct platform_device *dev)
return rc;
}
+static const struct of_device_id mv64xxx_i2c_of_match_table[] __devinitdata = {
+ { .compatible = "marvell,mv64xxx-i2c", },
+ {}
+};
+MODULE_DEVICE_TABLE(of, mv64xxx_i2c_of_match_table);
+
static struct platform_driver mv64xxx_i2c_driver = {
.probe = mv64xxx_i2c_probe,
.remove = __devexit_p(mv64xxx_i2c_remove),
.driver = {
.owner = THIS_MODULE,
.name = MV64XXX_I2C_CTLR_NAME,
+ .of_match_table = of_match_ptr(mv64xxx_i2c_of_match_table),
},
};
--
1.7.10
^ permalink raw reply related [flat|nested] 130+ messages in thread[parent not found: <1341325365-21393-8-git-send-email-andrew-g2DYL2Zd6BY@public.gmane.org>]
* Re: [PATCH v2 07/12] I2C: MV64XXX: Add Device Tree support
2012-07-03 14:22 ` Andrew Lunn
@ 2012-07-03 15:59 ` Florian Fainelli
-1 siblings, 0 replies; 130+ messages in thread
From: Florian Fainelli @ 2012-07-03 15:59 UTC (permalink / raw)
To: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Cc: Andrew Lunn, Jason Cooper,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
rob.herring-bsGFqQB8/DxBDgjK7y7TUQ, Michael Walle,
linux-i2c-u79uwXL29TY76Z2rM5mHXA,
spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
Hello Andrew,
On Tuesday 03 July 2012 16:22:40 Andrew Lunn wrote:
> Extends the driver to get properties from device tree. Also extend the
> kirkwood DT support to supply the needed properties.
>
> Signed-off-by: Andrew Lunn <andrew-g2DYL2Zd6BY@public.gmane.org>
> ---
[snip]
> - if ((pd->id != 0) || !pdata)
> + if ((!pdata && !pd->dev.of_node) || (pdata && (pd->id != 0)))
> return -ENODEV;
This is more a reminder than a real remark, but the driver here should not be
limiting us to a single platform_device. In fact kirkwood55 (88F6282) has two
I2C controllers for instance.
>
> drv_data = kzalloc(sizeof(struct mv64xxx_i2c_data), GFP_KERNEL);
> @@ -546,19 +549,35 @@ mv64xxx_i2c_probe(struct platform_device *pd)
> init_waitqueue_head(&drv_data->waitq);
> spin_lock_init(&drv_data->lock);
>
> - drv_data->freq_m = pdata->freq_m;
> - drv_data->freq_n = pdata->freq_n;
> - drv_data->irq = platform_get_irq(pd, 0);
> + if (pd->dev.of_node) {
> + of_property_read_u32(pd->dev.of_node, "frequency-m",
> + &drv_data->freq_m);
> + of_property_read_u32(pd->dev.of_node, "frequency-n",
> + &drv_data->freq_n);
> + drv_data->irq = irq_of_parse_and_map(pd->dev.of_node, 0);
> + } else {
> + drv_data->freq_m = pdata->freq_m;
> + drv_data->freq_n = pdata->freq_n;
> + drv_data->irq = platform_get_irq(pd, 0);
> + }
> +
> if (drv_data->irq < 0) {
> rc = -ENXIO;
> goto exit_unmap_regs;
> }
> +
> drv_data->adapter.dev.parent = &pd->dev;
> drv_data->adapter.algo = &mv64xxx_i2c_algo;
> drv_data->adapter.owner = THIS_MODULE;
> drv_data->adapter.class = I2C_CLASS_HWMON | I2C_CLASS_SPD;
> - drv_data->adapter.timeout = msecs_to_jiffies(pdata->timeout);
> + if (pd->dev.of_node)
> + drv_data->adapter.timeout = msecs_to_jiffies(
> + of_property_read_u32(pd->dev.of_node, "timeout-ms",
> + &drv_data->freq_n));
> + else
> + drv_data->adapter.timeout = msecs_to_jiffies(pdata->timeout);
> drv_data->adapter.nr = pd->id;
> + drv_data->adapter.dev.of_node = pd->dev.of_node;
> platform_set_drvdata(pd, drv_data);
> i2c_set_adapdata(&drv_data->adapter, drv_data);
>
> @@ -577,6 +596,8 @@ mv64xxx_i2c_probe(struct platform_device *pd)
> goto exit_free_irq;
> }
>
> + of_i2c_register_devices(&drv_data->adapter);
> +
> return 0;
>
> exit_free_irq:
> @@ -602,12 +623,19 @@ mv64xxx_i2c_remove(struct platform_device *dev)
> return rc;
> }
>
> +static const struct of_device_id mv64xxx_i2c_of_match_table[] __devinitdata
= {
> + { .compatible = "marvell,mv64xxx-i2c", },
> + {}
> +};
> +MODULE_DEVICE_TABLE(of, mv64xxx_i2c_of_match_table);
> +
> static struct platform_driver mv64xxx_i2c_driver = {
> .probe = mv64xxx_i2c_probe,
> .remove = __devexit_p(mv64xxx_i2c_remove),
> .driver = {
> .owner = THIS_MODULE,
> .name = MV64XXX_I2C_CTLR_NAME,
> + .of_match_table = of_match_ptr(mv64xxx_i2c_of_match_table),
> },
> };
>
> --
> 1.7.10
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
^ permalink raw reply [flat|nested] 130+ messages in thread* [PATCH v2 07/12] I2C: MV64XXX: Add Device Tree support
@ 2012-07-03 15:59 ` Florian Fainelli
0 siblings, 0 replies; 130+ messages in thread
From: Florian Fainelli @ 2012-07-03 15:59 UTC (permalink / raw)
To: linux-arm-kernel
Hello Andrew,
On Tuesday 03 July 2012 16:22:40 Andrew Lunn wrote:
> Extends the driver to get properties from device tree. Also extend the
> kirkwood DT support to supply the needed properties.
>
> Signed-off-by: Andrew Lunn <andrew@lunn.ch>
> ---
[snip]
> - if ((pd->id != 0) || !pdata)
> + if ((!pdata && !pd->dev.of_node) || (pdata && (pd->id != 0)))
> return -ENODEV;
This is more a reminder than a real remark, but the driver here should not be
limiting us to a single platform_device. In fact kirkwood55 (88F6282) has two
I2C controllers for instance.
>
> drv_data = kzalloc(sizeof(struct mv64xxx_i2c_data), GFP_KERNEL);
> @@ -546,19 +549,35 @@ mv64xxx_i2c_probe(struct platform_device *pd)
> init_waitqueue_head(&drv_data->waitq);
> spin_lock_init(&drv_data->lock);
>
> - drv_data->freq_m = pdata->freq_m;
> - drv_data->freq_n = pdata->freq_n;
> - drv_data->irq = platform_get_irq(pd, 0);
> + if (pd->dev.of_node) {
> + of_property_read_u32(pd->dev.of_node, "frequency-m",
> + &drv_data->freq_m);
> + of_property_read_u32(pd->dev.of_node, "frequency-n",
> + &drv_data->freq_n);
> + drv_data->irq = irq_of_parse_and_map(pd->dev.of_node, 0);
> + } else {
> + drv_data->freq_m = pdata->freq_m;
> + drv_data->freq_n = pdata->freq_n;
> + drv_data->irq = platform_get_irq(pd, 0);
> + }
> +
> if (drv_data->irq < 0) {
> rc = -ENXIO;
> goto exit_unmap_regs;
> }
> +
> drv_data->adapter.dev.parent = &pd->dev;
> drv_data->adapter.algo = &mv64xxx_i2c_algo;
> drv_data->adapter.owner = THIS_MODULE;
> drv_data->adapter.class = I2C_CLASS_HWMON | I2C_CLASS_SPD;
> - drv_data->adapter.timeout = msecs_to_jiffies(pdata->timeout);
> + if (pd->dev.of_node)
> + drv_data->adapter.timeout = msecs_to_jiffies(
> + of_property_read_u32(pd->dev.of_node, "timeout-ms",
> + &drv_data->freq_n));
> + else
> + drv_data->adapter.timeout = msecs_to_jiffies(pdata->timeout);
> drv_data->adapter.nr = pd->id;
> + drv_data->adapter.dev.of_node = pd->dev.of_node;
> platform_set_drvdata(pd, drv_data);
> i2c_set_adapdata(&drv_data->adapter, drv_data);
>
> @@ -577,6 +596,8 @@ mv64xxx_i2c_probe(struct platform_device *pd)
> goto exit_free_irq;
> }
>
> + of_i2c_register_devices(&drv_data->adapter);
> +
> return 0;
>
> exit_free_irq:
> @@ -602,12 +623,19 @@ mv64xxx_i2c_remove(struct platform_device *dev)
> return rc;
> }
>
> +static const struct of_device_id mv64xxx_i2c_of_match_table[] __devinitdata
= {
> + { .compatible = "marvell,mv64xxx-i2c", },
> + {}
> +};
> +MODULE_DEVICE_TABLE(of, mv64xxx_i2c_of_match_table);
> +
> static struct platform_driver mv64xxx_i2c_driver = {
> .probe = mv64xxx_i2c_probe,
> .remove = __devexit_p(mv64xxx_i2c_remove),
> .driver = {
> .owner = THIS_MODULE,
> .name = MV64XXX_I2C_CTLR_NAME,
> + .of_match_table = of_match_ptr(mv64xxx_i2c_of_match_table),
> },
> };
>
> --
> 1.7.10
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 130+ messages in thread* Re: [PATCH v2 07/12] I2C: MV64XXX: Add Device Tree support
2012-07-03 15:59 ` Florian Fainelli
@ 2012-07-03 16:58 ` Andrew Lunn
-1 siblings, 0 replies; 130+ messages in thread
From: Andrew Lunn @ 2012-07-03 16:58 UTC (permalink / raw)
To: Florian Fainelli
Cc: Andrew Lunn, Jason Cooper,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
rob.herring-bsGFqQB8/DxBDgjK7y7TUQ,
linux-i2c-u79uwXL29TY76Z2rM5mHXA,
spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
On Tue, Jul 03, 2012 at 05:59:13PM +0200, Florian Fainelli wrote:
> Hello Andrew,
>
> On Tuesday 03 July 2012 16:22:40 Andrew Lunn wrote:
> > Extends the driver to get properties from device tree. Also extend the
> > kirkwood DT support to supply the needed properties.
> >
> > Signed-off-by: Andrew Lunn <andrew-g2DYL2Zd6BY@public.gmane.org>
> > ---
> [snip]
> > - if ((pd->id != 0) || !pdata)
> > + if ((!pdata && !pd->dev.of_node) || (pdata && (pd->id != 0)))
> > return -ENODEV;
>
> This is more a reminder than a real remark, but the driver here should not be
> limiting us to a single platform_device. In fact kirkwood55 (88F6282) has two
> I2C controllers for instance.
Yes, i don't understand this code. It looks impossible to use it using
platform_data with more than one controller. Any idea why its like
this? I didn't want to change the behavior because i don't understand
why its like this.
However, it should be possible to instantiate multiple I2C controllers
using DT. However, i've only tested it with one.
Andrew
^ permalink raw reply [flat|nested] 130+ messages in thread* [PATCH v2 07/12] I2C: MV64XXX: Add Device Tree support
@ 2012-07-03 16:58 ` Andrew Lunn
0 siblings, 0 replies; 130+ messages in thread
From: Andrew Lunn @ 2012-07-03 16:58 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Jul 03, 2012 at 05:59:13PM +0200, Florian Fainelli wrote:
> Hello Andrew,
>
> On Tuesday 03 July 2012 16:22:40 Andrew Lunn wrote:
> > Extends the driver to get properties from device tree. Also extend the
> > kirkwood DT support to supply the needed properties.
> >
> > Signed-off-by: Andrew Lunn <andrew@lunn.ch>
> > ---
> [snip]
> > - if ((pd->id != 0) || !pdata)
> > + if ((!pdata && !pd->dev.of_node) || (pdata && (pd->id != 0)))
> > return -ENODEV;
>
> This is more a reminder than a real remark, but the driver here should not be
> limiting us to a single platform_device. In fact kirkwood55 (88F6282) has two
> I2C controllers for instance.
Yes, i don't understand this code. It looks impossible to use it using
platform_data with more than one controller. Any idea why its like
this? I didn't want to change the behavior because i don't understand
why its like this.
However, it should be possible to instantiate multiple I2C controllers
using DT. However, i've only tested it with one.
Andrew
^ permalink raw reply [flat|nested] 130+ messages in thread[parent not found: <20120703165839.GA1519-g2DYL2Zd6BY@public.gmane.org>]
* Re: [PATCH v2 07/12] I2C: MV64XXX: Add Device Tree support
2012-07-03 16:58 ` Andrew Lunn
@ 2012-07-04 19:49 ` Florian Fainelli
-1 siblings, 0 replies; 130+ messages in thread
From: Florian Fainelli @ 2012-07-04 19:49 UTC (permalink / raw)
To: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Cc: Andrew Lunn, Jason Cooper,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
rob.herring-bsGFqQB8/DxBDgjK7y7TUQ, Michael Walle,
linux-i2c-u79uwXL29TY76Z2rM5mHXA,
spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
Hello Andrew,
On Tuesday 03 July 2012 18:58:39 Andrew Lunn wrote:
> On Tue, Jul 03, 2012 at 05:59:13PM +0200, Florian Fainelli wrote:
> > Hello Andrew,
> >
> > On Tuesday 03 July 2012 16:22:40 Andrew Lunn wrote:
> > > Extends the driver to get properties from device tree. Also extend the
> > > kirkwood DT support to supply the needed properties.
> > >
> > > Signed-off-by: Andrew Lunn <andrew-g2DYL2Zd6BY@public.gmane.org>
> > > ---
> > [snip]
> > > - if ((pd->id != 0) || !pdata)
> > > + if ((!pdata && !pd->dev.of_node) || (pdata && (pd->id != 0)))
> > > return -ENODEV;
> >
> > This is more a reminder than a real remark, but the driver here should not
be
> > limiting us to a single platform_device. In fact kirkwood55 (88F6282) has
two
> > I2C controllers for instance.
>
> Yes, i don't understand this code. It looks impossible to use it using
> platform_data with more than one controller. Any idea why its like
> this? I didn't want to change the behavior because i don't understand
> why its like this.
No idea, we just stumbled over this with a colleague the other day, and just
removing the check made our second I2C controller work, so I don't see any
reason why there is such a limitation. That said, this is for a subsequent
patch.
>
> However, it should be possible to instantiate multiple I2C controllers
> using DT. However, i've only tested it with one.
>
> Andrew
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
Florian
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
^ permalink raw reply [flat|nested] 130+ messages in thread
* [PATCH v2 07/12] I2C: MV64XXX: Add Device Tree support
@ 2012-07-04 19:49 ` Florian Fainelli
0 siblings, 0 replies; 130+ messages in thread
From: Florian Fainelli @ 2012-07-04 19:49 UTC (permalink / raw)
To: linux-arm-kernel
Hello Andrew,
On Tuesday 03 July 2012 18:58:39 Andrew Lunn wrote:
> On Tue, Jul 03, 2012 at 05:59:13PM +0200, Florian Fainelli wrote:
> > Hello Andrew,
> >
> > On Tuesday 03 July 2012 16:22:40 Andrew Lunn wrote:
> > > Extends the driver to get properties from device tree. Also extend the
> > > kirkwood DT support to supply the needed properties.
> > >
> > > Signed-off-by: Andrew Lunn <andrew@lunn.ch>
> > > ---
> > [snip]
> > > - if ((pd->id != 0) || !pdata)
> > > + if ((!pdata && !pd->dev.of_node) || (pdata && (pd->id != 0)))
> > > return -ENODEV;
> >
> > This is more a reminder than a real remark, but the driver here should not
be
> > limiting us to a single platform_device. In fact kirkwood55 (88F6282) has
two
> > I2C controllers for instance.
>
> Yes, i don't understand this code. It looks impossible to use it using
> platform_data with more than one controller. Any idea why its like
> this? I didn't want to change the behavior because i don't understand
> why its like this.
No idea, we just stumbled over this with a colleague the other day, and just
removing the check made our second I2C controller work, so I don't see any
reason why there is such a limitation. That said, this is for a subsequent
patch.
>
> However, it should be possible to instantiate multiple I2C controllers
> using DT. However, i've only tested it with one.
>
> Andrew
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
Florian
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: [PATCH v2 07/12] I2C: MV64XXX: Add Device Tree support
2012-07-04 19:49 ` Florian Fainelli
@ 2012-07-05 6:52 ` Andrew Lunn
-1 siblings, 0 replies; 130+ messages in thread
From: Andrew Lunn @ 2012-07-05 6:52 UTC (permalink / raw)
To: Florian Fainelli
Cc: Andrew Lunn, Jason Cooper,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
rob.herring-bsGFqQB8/DxBDgjK7y7TUQ,
linux-i2c-u79uwXL29TY76Z2rM5mHXA,
spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
On Wed, Jul 04, 2012 at 09:49:33PM +0200, Florian Fainelli wrote:
> Hello Andrew,
>
> On Tuesday 03 July 2012 18:58:39 Andrew Lunn wrote:
> > On Tue, Jul 03, 2012 at 05:59:13PM +0200, Florian Fainelli wrote:
> > > Hello Andrew,
> > >
> > > On Tuesday 03 July 2012 16:22:40 Andrew Lunn wrote:
> > > > Extends the driver to get properties from device tree. Also extend the
> > > > kirkwood DT support to supply the needed properties.
> > > >
> > > > Signed-off-by: Andrew Lunn <andrew-g2DYL2Zd6BY@public.gmane.org>
> > > > ---
> > > [snip]
> > > > - if ((pd->id != 0) || !pdata)
> > > > + if ((!pdata && !pd->dev.of_node) || (pdata && (pd->id != 0)))
> > > > return -ENODEV;
> > >
> > > This is more a reminder than a real remark, but the driver here should not
> be
> > > limiting us to a single platform_device. In fact kirkwood55 (88F6282) has
> two
> > > I2C controllers for instance.
> >
> > Yes, i don't understand this code. It looks impossible to use it using
> > platform_data with more than one controller. Any idea why its like
> > this? I didn't want to change the behavior because i don't understand
> > why its like this.
>
> No idea, we just stumbled over this with a colleague the other day, and just
> removing the check made our second I2C controller work, so I don't see any
> reason why there is such a limitation. That said, this is for a subsequent
> patch.
If you submit a patch, please CC: me and i will ACK it, or test it
etc, and try to sort out the merge conflicts with the DT patch.
Thanks
Andrew
^ permalink raw reply [flat|nested] 130+ messages in thread
* [PATCH v2 07/12] I2C: MV64XXX: Add Device Tree support
@ 2012-07-05 6:52 ` Andrew Lunn
0 siblings, 0 replies; 130+ messages in thread
From: Andrew Lunn @ 2012-07-05 6:52 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, Jul 04, 2012 at 09:49:33PM +0200, Florian Fainelli wrote:
> Hello Andrew,
>
> On Tuesday 03 July 2012 18:58:39 Andrew Lunn wrote:
> > On Tue, Jul 03, 2012 at 05:59:13PM +0200, Florian Fainelli wrote:
> > > Hello Andrew,
> > >
> > > On Tuesday 03 July 2012 16:22:40 Andrew Lunn wrote:
> > > > Extends the driver to get properties from device tree. Also extend the
> > > > kirkwood DT support to supply the needed properties.
> > > >
> > > > Signed-off-by: Andrew Lunn <andrew@lunn.ch>
> > > > ---
> > > [snip]
> > > > - if ((pd->id != 0) || !pdata)
> > > > + if ((!pdata && !pd->dev.of_node) || (pdata && (pd->id != 0)))
> > > > return -ENODEV;
> > >
> > > This is more a reminder than a real remark, but the driver here should not
> be
> > > limiting us to a single platform_device. In fact kirkwood55 (88F6282) has
> two
> > > I2C controllers for instance.
> >
> > Yes, i don't understand this code. It looks impossible to use it using
> > platform_data with more than one controller. Any idea why its like
> > this? I didn't want to change the behavior because i don't understand
> > why its like this.
>
> No idea, we just stumbled over this with a colleague the other day, and just
> removing the check made our second I2C controller work, so I don't see any
> reason why there is such a limitation. That said, this is for a subsequent
> patch.
If you submit a patch, please CC: me and i will ACK it, or test it
etc, and try to sort out the merge conflicts with the DT patch.
Thanks
Andrew
^ permalink raw reply [flat|nested] 130+ messages in thread
* [PATCH v2 08/12] Kirkwood: Add basic device tree support for QNAP TS219.
2012-07-03 14:22 ` Andrew Lunn
@ 2012-07-03 14:22 ` Andrew Lunn
-1 siblings, 0 replies; 130+ messages in thread
From: Andrew Lunn @ 2012-07-03 14:22 UTC (permalink / raw)
To: Jason Cooper
Cc: grant.likely-s3s/WqlpOiPyB63q8FvJNQ,
spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
linux-i2c-u79uwXL29TY76Z2rM5mHXA,
rob.herring-bsGFqQB8/DxBDgjK7y7TUQ,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Michael Walle,
Andrew Lunn
The two different variants of QNAP TS devices, varying by SoC, put the
GPIO keys on different GPIO lines. Hence we need two different DT
board descriptions, which share the same board-ts219.c file.
Signed-off-by: Andrew Lunn <andrew-g2DYL2Zd6BY@public.gmane.org>
Acked-by: Jason Cooper <jason-NLaQJdtUoK4Be96aLqz0jA@public.gmane.org>
---
arch/arm/boot/dts/kirkwood-ts219-6281.dts | 21 +++++++
arch/arm/boot/dts/kirkwood-ts219-6282.dts | 21 +++++++
arch/arm/boot/dts/kirkwood-ts219.dtsi | 73 ++++++++++++++++++++++++
arch/arm/mach-kirkwood/Kconfig | 14 +++++
arch/arm/mach-kirkwood/Makefile | 1 +
arch/arm/mach-kirkwood/Makefile.boot | 1 +
arch/arm/mach-kirkwood/board-dt.c | 4 ++
arch/arm/mach-kirkwood/board-ts219.c | 87 +++++++++++++++++++++++++++++
arch/arm/mach-kirkwood/common.h | 5 ++
9 files changed, 227 insertions(+)
create mode 100644 arch/arm/boot/dts/kirkwood-ts219-6281.dts
create mode 100644 arch/arm/boot/dts/kirkwood-ts219-6282.dts
create mode 100644 arch/arm/boot/dts/kirkwood-ts219.dtsi
create mode 100644 arch/arm/mach-kirkwood/board-ts219.c
diff --git a/arch/arm/boot/dts/kirkwood-ts219-6281.dts b/arch/arm/boot/dts/kirkwood-ts219-6281.dts
new file mode 100644
index 0000000..ccbf327
--- /dev/null
+++ b/arch/arm/boot/dts/kirkwood-ts219-6281.dts
@@ -0,0 +1,21 @@
+/dts-v1/;
+
+/include/ "kirkwood-ts219.dtsi"
+
+/ {
+ gpio_keys {
+ compatible = "gpio-keys";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ button@1 {
+ label = "USB Copy";
+ linux,code = <133>;
+ gpios = <&gpio0 15 1>;
+ };
+ button@2 {
+ label = "Reset";
+ linux,code = <0x198>;
+ gpios = <&gpio0 16 1>;
+ };
+ };
+};
\ No newline at end of file
diff --git a/arch/arm/boot/dts/kirkwood-ts219-6282.dts b/arch/arm/boot/dts/kirkwood-ts219-6282.dts
new file mode 100644
index 0000000..fbe9932
--- /dev/null
+++ b/arch/arm/boot/dts/kirkwood-ts219-6282.dts
@@ -0,0 +1,21 @@
+/dts-v1/;
+
+/include/ "kirkwood-ts219.dtsi"
+
+/ {
+ gpio_keys {
+ compatible = "gpio-keys";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ button@1 {
+ label = "USB Copy";
+ linux,code = <133>;
+ gpios = <&gpio1 11 1>;
+ };
+ button@2 {
+ label = "Reset";
+ linux,code = <0x198>;
+ gpios = <&gpio1 5 1>;
+ };
+ };
+};
\ No newline at end of file
diff --git a/arch/arm/boot/dts/kirkwood-ts219.dtsi b/arch/arm/boot/dts/kirkwood-ts219.dtsi
new file mode 100644
index 0000000..e0520c3
--- /dev/null
+++ b/arch/arm/boot/dts/kirkwood-ts219.dtsi
@@ -0,0 +1,73 @@
+/include/ "kirkwood.dtsi"
+
+/ {
+ model = "QNAP TS219 family";
+ compatible = "qnap,ts219", "mrvl,kirkwood";
+
+ memory {
+ device_type = "memory";
+ reg = <0x00000000 0x20000000>;
+ };
+
+ chosen {
+ bootargs = "console=ttyS0,115200n8";
+ };
+
+ ocp@f1000000 {
+ i2c@11000 {
+ status = "okay";
+
+ s35390a: s35390a@30 {
+ compatible = "s35390a";
+ reg = <0x30>;
+ };
+ };
+ serial@12000 {
+ clock-frequency = <200000000>;
+ status = "okay";
+ };
+ serial@12100 {
+ clock-frequency = <200000000>;
+ status = "okay";
+ };
+ spi@10600 {
+ status = "okay";
+
+ m25p128@0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "m25p128";
+ reg = <0>;
+ spi-max-frequency = <20000000>;
+ mode = <0>;
+
+ partition@0000000 {
+ reg = <0x00000000 0x00080000>;
+ label = "U-Boot";
+ };
+
+ partition@00200000 {
+ reg = <0x00200000 0x00200000>;
+ label = "Kernel";
+ };
+
+ partition@00400000 {
+ reg = <0x00400000 0x00900000>;
+ label = "RootFS1";
+ };
+ partition@00d00000 {
+ reg = <0x00d00000 0x00300000>;
+ label = "RootFS2";
+ };
+ partition@00040000 {
+ reg = <0x00080000 0x00040000>;
+ label = "U-Boot Config";
+ };
+ partition@000c0000 {
+ reg = <0x000c0000 0x00140000>;
+ label = "NAS Config";
+ };
+ };
+ };
+ };
+};
diff --git a/arch/arm/mach-kirkwood/Kconfig b/arch/arm/mach-kirkwood/Kconfig
index 199764f..089d094 100644
--- a/arch/arm/mach-kirkwood/Kconfig
+++ b/arch/arm/mach-kirkwood/Kconfig
@@ -80,6 +80,20 @@ config MACH_IB62X0_DT
RaidSonic IB-NAS6210 & IB-NAS6220 devices, using
Flattened Device Tree.
+config MACH_TS219_DT
+ bool "Device Tree for QNAP TS-110, TS-119, TS-119P+, TS-210, TS-219, TS-219P and TS-219P+ Turbo NAS"
+ select ARCH_KIRKWOOD_DT
+ select ARM_APPENDED_DTB
+ select ARM_ATAG_DTB_COMPAT
+ help
+ Say 'Y' here if you want your kernel to support the QNAP
+ TS-110, TS-119, TS-119P+, TS-210, TS-219, TS-219P and
+ TS-219P+ Turbo NAS devices using Fattened Device Tree.
+ There are two different Device Tree descriptions, depending
+ on if the device is based on an if the board uses the MV6281
+ or MV6282. If you have the wrong one, the buttons will not
+ work.
+
config MACH_TS219
bool "QNAP TS-110, TS-119, TS-119P+, TS-210, TS-219, TS-219P and TS-219P+ Turbo NAS"
help
diff --git a/arch/arm/mach-kirkwood/Makefile b/arch/arm/mach-kirkwood/Makefile
index d2b0590..0468b23 100644
--- a/arch/arm/mach-kirkwood/Makefile
+++ b/arch/arm/mach-kirkwood/Makefile
@@ -25,3 +25,4 @@ obj-$(CONFIG_MACH_DREAMPLUG_DT) += board-dreamplug.o
obj-$(CONFIG_MACH_ICONNECT_DT) += board-iconnect.o
obj-$(CONFIG_MACH_DLINK_KIRKWOOD_DT) += board-dnskw.o
obj-$(CONFIG_MACH_IB62X0_DT) += board-ib62x0.o
+obj-$(CONFIG_MACH_TS219_DT) += board-ts219.o
diff --git a/arch/arm/mach-kirkwood/Makefile.boot b/arch/arm/mach-kirkwood/Makefile.boot
index 02edbdf..4a1f66a 100644
--- a/arch/arm/mach-kirkwood/Makefile.boot
+++ b/arch/arm/mach-kirkwood/Makefile.boot
@@ -7,3 +7,4 @@ dtb-$(CONFIG_MACH_DLINK_KIRKWOOD_DT) += kirkwood-dns320.dtb
dtb-$(CONFIG_MACH_DLINK_KIRKWOOD_DT) += kirkwood-dns325.dtb
dtb-$(CONFIG_MACH_ICONNECT_DT) += kirkwood-iconnect.dtb
dtb-$(CONFIG_MACH_IB62X0_DT) += kirkwood-ib62x0.dtb
+dtb-$(CONFIG_MACH_TS219_DT) += kirkwood-qnap-ts219.dtb
diff --git a/arch/arm/mach-kirkwood/board-dt.c b/arch/arm/mach-kirkwood/board-dt.c
index 24c8fdd..b7cd6d2 100644
--- a/arch/arm/mach-kirkwood/board-dt.c
+++ b/arch/arm/mach-kirkwood/board-dt.c
@@ -76,6 +76,9 @@ static void __init kirkwood_dt_init(void)
if (of_machine_is_compatible("raidsonic,ib-nas62x0"))
ib62x0_init();
+ if (of_machine_is_compatible("qnap,ts219"))
+ qnap_dt_ts219_init();
+
of_platform_populate(NULL, kirkwood_dt_match_table,
kirkwood_auxdata_lookup, NULL);
}
@@ -86,6 +89,7 @@ static const char *kirkwood_dt_board_compat[] = {
"dlink,dns-325",
"iom,iconnect",
"raidsonic,ib-nas62x0",
+ "qnap,ts219",
NULL
};
diff --git a/arch/arm/mach-kirkwood/board-ts219.c b/arch/arm/mach-kirkwood/board-ts219.c
new file mode 100644
index 0000000..00b79ea
--- /dev/null
+++ b/arch/arm/mach-kirkwood/board-ts219.c
@@ -0,0 +1,87 @@
+/*
+ *
+ * QNAP TS-11x/TS-21x Turbo NAS Board Setup via DT
+ *
+ * Copyright (C) 2012 Andrew Lunn <andrew-g2DYL2Zd6BY@public.gmane.org>
+ *
+ * Based on the board file ts219-setup.c:
+ *
+ * Copyright (C) 2009 Martin Michlmayr <tbm-R+vWnYXSFMfQT0dZR+AlfA@public.gmane.org>
+ * Copyright (C) 2008 Byron Bradley <byron.bbradley-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ */
+
+#include <linux/kernel.h>
+#include <linux/init.h>
+#include <linux/platform_device.h>
+#include <linux/mv643xx_eth.h>
+#include <linux/ata_platform.h>
+#include <linux/gpio_keys.h>
+#include <linux/input.h>
+#include <asm/mach-types.h>
+#include <asm/mach/arch.h>
+#include <mach/kirkwood.h>
+#include "common.h"
+#include "mpp.h"
+#include "tsx1x-common.h"
+
+static struct mv643xx_eth_platform_data qnap_ts219_ge00_data = {
+ .phy_addr = MV643XX_ETH_PHY_ADDR(8),
+};
+
+static struct mv_sata_platform_data qnap_ts219_sata_data = {
+ .n_ports = 2,
+};
+
+static unsigned int qnap_ts219_mpp_config[] __initdata = {
+ MPP0_SPI_SCn,
+ MPP1_SPI_MOSI,
+ MPP2_SPI_SCK,
+ MPP3_SPI_MISO,
+ MPP4_SATA1_ACTn,
+ MPP5_SATA0_ACTn,
+ MPP8_TW0_SDA,
+ MPP9_TW0_SCK,
+ MPP10_UART0_TXD,
+ MPP11_UART0_RXD,
+ MPP13_UART1_TXD, /* PIC controller */
+ MPP14_UART1_RXD, /* PIC controller */
+ MPP15_GPIO, /* USB Copy button (on devices with 88F6281) */
+ MPP16_GPIO, /* Reset button (on devices with 88F6281) */
+ MPP36_GPIO, /* RAM: 0: 256 MB, 1: 512 MB */
+ MPP37_GPIO, /* Reset button (on devices with 88F6282) */
+ MPP43_GPIO, /* USB Copy button (on devices with 88F6282) */
+ MPP44_GPIO, /* Board ID: 0: TS-11x, 1: TS-21x */
+ 0
+};
+
+void __init qnap_dt_ts219_init(void)
+{
+ u32 dev, rev;
+
+ kirkwood_mpp_conf(qnap_ts219_mpp_config);
+
+ kirkwood_pcie_id(&dev, &rev);
+ if (dev == MV88F6282_DEV_ID)
+ qnap_ts219_ge00_data.phy_addr = MV643XX_ETH_PHY_ADDR(0);
+
+ kirkwood_ge00_init(&qnap_ts219_ge00_data);
+ kirkwood_sata_init(&qnap_ts219_sata_data);
+ kirkwood_ehci_init();
+
+ pm_power_off = qnap_tsx1x_power_off;
+}
+
+/* FIXME: Will not work with DT. Maybe use MPP40_GPIO? */
+static int __init ts219_pci_init(void)
+{
+ if (machine_is_ts219())
+ kirkwood_pcie_init(KW_PCIE0);
+
+ return 0;
+}
+subsys_initcall(ts219_pci_init);
diff --git a/arch/arm/mach-kirkwood/common.h b/arch/arm/mach-kirkwood/common.h
index 9248fa2..e0c2324 100644
--- a/arch/arm/mach-kirkwood/common.h
+++ b/arch/arm/mach-kirkwood/common.h
@@ -58,6 +58,11 @@ void dreamplug_init(void);
#else
static inline void dreamplug_init(void) {};
#endif
+#ifdef CONFIG_MACH_TS219_DT
+void qnap_dt_ts219_init(void);
+#else
+static inline void qnap_dt_ts219_init(void) {};
+#endif
#ifdef CONFIG_MACH_DLINK_KIRKWOOD_DT
void dnskw_init(void);
--
1.7.10
^ permalink raw reply related [flat|nested] 130+ messages in thread* [PATCH v2 08/12] Kirkwood: Add basic device tree support for QNAP TS219.
@ 2012-07-03 14:22 ` Andrew Lunn
0 siblings, 0 replies; 130+ messages in thread
From: Andrew Lunn @ 2012-07-03 14:22 UTC (permalink / raw)
To: linux-arm-kernel
The two different variants of QNAP TS devices, varying by SoC, put the
GPIO keys on different GPIO lines. Hence we need two different DT
board descriptions, which share the same board-ts219.c file.
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Acked-by: Jason Cooper <jason@lakedaemon.net>
---
arch/arm/boot/dts/kirkwood-ts219-6281.dts | 21 +++++++
arch/arm/boot/dts/kirkwood-ts219-6282.dts | 21 +++++++
arch/arm/boot/dts/kirkwood-ts219.dtsi | 73 ++++++++++++++++++++++++
arch/arm/mach-kirkwood/Kconfig | 14 +++++
arch/arm/mach-kirkwood/Makefile | 1 +
arch/arm/mach-kirkwood/Makefile.boot | 1 +
arch/arm/mach-kirkwood/board-dt.c | 4 ++
arch/arm/mach-kirkwood/board-ts219.c | 87 +++++++++++++++++++++++++++++
arch/arm/mach-kirkwood/common.h | 5 ++
9 files changed, 227 insertions(+)
create mode 100644 arch/arm/boot/dts/kirkwood-ts219-6281.dts
create mode 100644 arch/arm/boot/dts/kirkwood-ts219-6282.dts
create mode 100644 arch/arm/boot/dts/kirkwood-ts219.dtsi
create mode 100644 arch/arm/mach-kirkwood/board-ts219.c
diff --git a/arch/arm/boot/dts/kirkwood-ts219-6281.dts b/arch/arm/boot/dts/kirkwood-ts219-6281.dts
new file mode 100644
index 0000000..ccbf327
--- /dev/null
+++ b/arch/arm/boot/dts/kirkwood-ts219-6281.dts
@@ -0,0 +1,21 @@
+/dts-v1/;
+
+/include/ "kirkwood-ts219.dtsi"
+
+/ {
+ gpio_keys {
+ compatible = "gpio-keys";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ button at 1 {
+ label = "USB Copy";
+ linux,code = <133>;
+ gpios = <&gpio0 15 1>;
+ };
+ button at 2 {
+ label = "Reset";
+ linux,code = <0x198>;
+ gpios = <&gpio0 16 1>;
+ };
+ };
+};
\ No newline at end of file
diff --git a/arch/arm/boot/dts/kirkwood-ts219-6282.dts b/arch/arm/boot/dts/kirkwood-ts219-6282.dts
new file mode 100644
index 0000000..fbe9932
--- /dev/null
+++ b/arch/arm/boot/dts/kirkwood-ts219-6282.dts
@@ -0,0 +1,21 @@
+/dts-v1/;
+
+/include/ "kirkwood-ts219.dtsi"
+
+/ {
+ gpio_keys {
+ compatible = "gpio-keys";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ button at 1 {
+ label = "USB Copy";
+ linux,code = <133>;
+ gpios = <&gpio1 11 1>;
+ };
+ button at 2 {
+ label = "Reset";
+ linux,code = <0x198>;
+ gpios = <&gpio1 5 1>;
+ };
+ };
+};
\ No newline at end of file
diff --git a/arch/arm/boot/dts/kirkwood-ts219.dtsi b/arch/arm/boot/dts/kirkwood-ts219.dtsi
new file mode 100644
index 0000000..e0520c3
--- /dev/null
+++ b/arch/arm/boot/dts/kirkwood-ts219.dtsi
@@ -0,0 +1,73 @@
+/include/ "kirkwood.dtsi"
+
+/ {
+ model = "QNAP TS219 family";
+ compatible = "qnap,ts219", "mrvl,kirkwood";
+
+ memory {
+ device_type = "memory";
+ reg = <0x00000000 0x20000000>;
+ };
+
+ chosen {
+ bootargs = "console=ttyS0,115200n8";
+ };
+
+ ocp at f1000000 {
+ i2c at 11000 {
+ status = "okay";
+
+ s35390a: s35390a at 30 {
+ compatible = "s35390a";
+ reg = <0x30>;
+ };
+ };
+ serial at 12000 {
+ clock-frequency = <200000000>;
+ status = "okay";
+ };
+ serial at 12100 {
+ clock-frequency = <200000000>;
+ status = "okay";
+ };
+ spi at 10600 {
+ status = "okay";
+
+ m25p128 at 0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "m25p128";
+ reg = <0>;
+ spi-max-frequency = <20000000>;
+ mode = <0>;
+
+ partition at 0000000 {
+ reg = <0x00000000 0x00080000>;
+ label = "U-Boot";
+ };
+
+ partition at 00200000 {
+ reg = <0x00200000 0x00200000>;
+ label = "Kernel";
+ };
+
+ partition at 00400000 {
+ reg = <0x00400000 0x00900000>;
+ label = "RootFS1";
+ };
+ partition at 00d00000 {
+ reg = <0x00d00000 0x00300000>;
+ label = "RootFS2";
+ };
+ partition at 00040000 {
+ reg = <0x00080000 0x00040000>;
+ label = "U-Boot Config";
+ };
+ partition at 000c0000 {
+ reg = <0x000c0000 0x00140000>;
+ label = "NAS Config";
+ };
+ };
+ };
+ };
+};
diff --git a/arch/arm/mach-kirkwood/Kconfig b/arch/arm/mach-kirkwood/Kconfig
index 199764f..089d094 100644
--- a/arch/arm/mach-kirkwood/Kconfig
+++ b/arch/arm/mach-kirkwood/Kconfig
@@ -80,6 +80,20 @@ config MACH_IB62X0_DT
RaidSonic IB-NAS6210 & IB-NAS6220 devices, using
Flattened Device Tree.
+config MACH_TS219_DT
+ bool "Device Tree for QNAP TS-110, TS-119, TS-119P+, TS-210, TS-219, TS-219P and TS-219P+ Turbo NAS"
+ select ARCH_KIRKWOOD_DT
+ select ARM_APPENDED_DTB
+ select ARM_ATAG_DTB_COMPAT
+ help
+ Say 'Y' here if you want your kernel to support the QNAP
+ TS-110, TS-119, TS-119P+, TS-210, TS-219, TS-219P and
+ TS-219P+ Turbo NAS devices using Fattened Device Tree.
+ There are two different Device Tree descriptions, depending
+ on if the device is based on an if the board uses the MV6281
+ or MV6282. If you have the wrong one, the buttons will not
+ work.
+
config MACH_TS219
bool "QNAP TS-110, TS-119, TS-119P+, TS-210, TS-219, TS-219P and TS-219P+ Turbo NAS"
help
diff --git a/arch/arm/mach-kirkwood/Makefile b/arch/arm/mach-kirkwood/Makefile
index d2b0590..0468b23 100644
--- a/arch/arm/mach-kirkwood/Makefile
+++ b/arch/arm/mach-kirkwood/Makefile
@@ -25,3 +25,4 @@ obj-$(CONFIG_MACH_DREAMPLUG_DT) += board-dreamplug.o
obj-$(CONFIG_MACH_ICONNECT_DT) += board-iconnect.o
obj-$(CONFIG_MACH_DLINK_KIRKWOOD_DT) += board-dnskw.o
obj-$(CONFIG_MACH_IB62X0_DT) += board-ib62x0.o
+obj-$(CONFIG_MACH_TS219_DT) += board-ts219.o
diff --git a/arch/arm/mach-kirkwood/Makefile.boot b/arch/arm/mach-kirkwood/Makefile.boot
index 02edbdf..4a1f66a 100644
--- a/arch/arm/mach-kirkwood/Makefile.boot
+++ b/arch/arm/mach-kirkwood/Makefile.boot
@@ -7,3 +7,4 @@ dtb-$(CONFIG_MACH_DLINK_KIRKWOOD_DT) += kirkwood-dns320.dtb
dtb-$(CONFIG_MACH_DLINK_KIRKWOOD_DT) += kirkwood-dns325.dtb
dtb-$(CONFIG_MACH_ICONNECT_DT) += kirkwood-iconnect.dtb
dtb-$(CONFIG_MACH_IB62X0_DT) += kirkwood-ib62x0.dtb
+dtb-$(CONFIG_MACH_TS219_DT) += kirkwood-qnap-ts219.dtb
diff --git a/arch/arm/mach-kirkwood/board-dt.c b/arch/arm/mach-kirkwood/board-dt.c
index 24c8fdd..b7cd6d2 100644
--- a/arch/arm/mach-kirkwood/board-dt.c
+++ b/arch/arm/mach-kirkwood/board-dt.c
@@ -76,6 +76,9 @@ static void __init kirkwood_dt_init(void)
if (of_machine_is_compatible("raidsonic,ib-nas62x0"))
ib62x0_init();
+ if (of_machine_is_compatible("qnap,ts219"))
+ qnap_dt_ts219_init();
+
of_platform_populate(NULL, kirkwood_dt_match_table,
kirkwood_auxdata_lookup, NULL);
}
@@ -86,6 +89,7 @@ static const char *kirkwood_dt_board_compat[] = {
"dlink,dns-325",
"iom,iconnect",
"raidsonic,ib-nas62x0",
+ "qnap,ts219",
NULL
};
diff --git a/arch/arm/mach-kirkwood/board-ts219.c b/arch/arm/mach-kirkwood/board-ts219.c
new file mode 100644
index 0000000..00b79ea
--- /dev/null
+++ b/arch/arm/mach-kirkwood/board-ts219.c
@@ -0,0 +1,87 @@
+/*
+ *
+ * QNAP TS-11x/TS-21x Turbo NAS Board Setup via DT
+ *
+ * Copyright (C) 2012 Andrew Lunn <andrew@lunn.ch>
+ *
+ * Based on the board file ts219-setup.c:
+ *
+ * Copyright (C) 2009 Martin Michlmayr <tbm@cyrius.com>
+ * Copyright (C) 2008 Byron Bradley <byron.bbradley@gmail.com>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ */
+
+#include <linux/kernel.h>
+#include <linux/init.h>
+#include <linux/platform_device.h>
+#include <linux/mv643xx_eth.h>
+#include <linux/ata_platform.h>
+#include <linux/gpio_keys.h>
+#include <linux/input.h>
+#include <asm/mach-types.h>
+#include <asm/mach/arch.h>
+#include <mach/kirkwood.h>
+#include "common.h"
+#include "mpp.h"
+#include "tsx1x-common.h"
+
+static struct mv643xx_eth_platform_data qnap_ts219_ge00_data = {
+ .phy_addr = MV643XX_ETH_PHY_ADDR(8),
+};
+
+static struct mv_sata_platform_data qnap_ts219_sata_data = {
+ .n_ports = 2,
+};
+
+static unsigned int qnap_ts219_mpp_config[] __initdata = {
+ MPP0_SPI_SCn,
+ MPP1_SPI_MOSI,
+ MPP2_SPI_SCK,
+ MPP3_SPI_MISO,
+ MPP4_SATA1_ACTn,
+ MPP5_SATA0_ACTn,
+ MPP8_TW0_SDA,
+ MPP9_TW0_SCK,
+ MPP10_UART0_TXD,
+ MPP11_UART0_RXD,
+ MPP13_UART1_TXD, /* PIC controller */
+ MPP14_UART1_RXD, /* PIC controller */
+ MPP15_GPIO, /* USB Copy button (on devices with 88F6281) */
+ MPP16_GPIO, /* Reset button (on devices with 88F6281) */
+ MPP36_GPIO, /* RAM: 0: 256 MB, 1: 512 MB */
+ MPP37_GPIO, /* Reset button (on devices with 88F6282) */
+ MPP43_GPIO, /* USB Copy button (on devices with 88F6282) */
+ MPP44_GPIO, /* Board ID: 0: TS-11x, 1: TS-21x */
+ 0
+};
+
+void __init qnap_dt_ts219_init(void)
+{
+ u32 dev, rev;
+
+ kirkwood_mpp_conf(qnap_ts219_mpp_config);
+
+ kirkwood_pcie_id(&dev, &rev);
+ if (dev == MV88F6282_DEV_ID)
+ qnap_ts219_ge00_data.phy_addr = MV643XX_ETH_PHY_ADDR(0);
+
+ kirkwood_ge00_init(&qnap_ts219_ge00_data);
+ kirkwood_sata_init(&qnap_ts219_sata_data);
+ kirkwood_ehci_init();
+
+ pm_power_off = qnap_tsx1x_power_off;
+}
+
+/* FIXME: Will not work with DT. Maybe use MPP40_GPIO? */
+static int __init ts219_pci_init(void)
+{
+ if (machine_is_ts219())
+ kirkwood_pcie_init(KW_PCIE0);
+
+ return 0;
+}
+subsys_initcall(ts219_pci_init);
diff --git a/arch/arm/mach-kirkwood/common.h b/arch/arm/mach-kirkwood/common.h
index 9248fa2..e0c2324 100644
--- a/arch/arm/mach-kirkwood/common.h
+++ b/arch/arm/mach-kirkwood/common.h
@@ -58,6 +58,11 @@ void dreamplug_init(void);
#else
static inline void dreamplug_init(void) {};
#endif
+#ifdef CONFIG_MACH_TS219_DT
+void qnap_dt_ts219_init(void);
+#else
+static inline void qnap_dt_ts219_init(void) {};
+#endif
#ifdef CONFIG_MACH_DLINK_KIRKWOOD_DT
void dnskw_init(void);
--
1.7.10
^ permalink raw reply related [flat|nested] 130+ messages in thread[parent not found: <1341325365-21393-9-git-send-email-andrew-g2DYL2Zd6BY@public.gmane.org>]
* Re: [PATCH v2 08/12] Kirkwood: Add basic device tree support for QNAP TS219.
2012-07-03 14:22 ` Andrew Lunn
@ 2012-07-03 15:47 ` Florian Fainelli
-1 siblings, 0 replies; 130+ messages in thread
From: Florian Fainelli @ 2012-07-03 15:47 UTC (permalink / raw)
To: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Cc: Andrew Lunn, Jason Cooper,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
rob.herring-bsGFqQB8/DxBDgjK7y7TUQ,
grant.likely-s3s/WqlpOiPyB63q8FvJNQ, Michael Walle,
linux-i2c-u79uwXL29TY76Z2rM5mHXA,
spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
Hi Andrew,
On Tuesday 03 July 2012 16:22:41 Andrew Lunn wrote:
> The two different variants of QNAP TS devices, varying by SoC, put the
> GPIO keys on different GPIO lines. Hence we need two different DT
> board descriptions, which share the same board-ts219.c file.
Why don't you reorder this patch to be after patch 11/12 so that you do not
need to update this file in patch 11/12?
>
> Signed-off-by: Andrew Lunn <andrew-g2DYL2Zd6BY@public.gmane.org>
> Acked-by: Jason Cooper <jason-NLaQJdtUoK4Be96aLqz0jA@public.gmane.org>
> ---
[snip]
>
> +config MACH_TS219_DT
> + bool "Device Tree for QNAP TS-110, TS-119, TS-119P+, TS-210, TS-219,
TS-219P and TS-219P+ Turbo NAS"
This looks too long, how about just "Device Tree for QNAP TS-11x, TS-21x NAS"
for instance?
> + select ARCH_KIRKWOOD_DT
> + select ARM_APPENDED_DTB
> + select ARM_ATAG_DTB_COMPAT
> + help
> + Say 'Y' here if you want your kernel to support the QNAP
> + TS-110, TS-119, TS-119P+, TS-210, TS-219, TS-219P and
> + TS-219P+ Turbo NAS devices using Fattened Device Tree.
> + There are two different Device Tree descriptions, depending
> + on if the device is based on an if the board uses the MV6281
> + or MV6282. If you have the wrong one, the buttons will not
> + work.
> +
> config MACH_TS219
> bool "QNAP TS-110, TS-119, TS-119P+, TS-210, TS-219, TS-219P and
TS-219P+ Turbo NAS"
> help
> diff --git a/arch/arm/mach-kirkwood/Makefile b/arch/arm/mach-kirkwood/Makefile
> index d2b0590..0468b23 100644
> --- a/arch/arm/mach-kirkwood/Makefile
> +++ b/arch/arm/mach-kirkwood/Makefile
> @@ -25,3 +25,4 @@ obj-$(CONFIG_MACH_DREAMPLUG_DT) += board-dreamplug.o
> obj-$(CONFIG_MACH_ICONNECT_DT) += board-iconnect.o
> obj-$(CONFIG_MACH_DLINK_KIRKWOOD_DT) += board-dnskw.o
> obj-$(CONFIG_MACH_IB62X0_DT) += board-ib62x0.o
> +obj-$(CONFIG_MACH_TS219_DT) += board-ts219.o
> diff --git a/arch/arm/mach-kirkwood/Makefile.boot b/arch/arm/mach-
kirkwood/Makefile.boot
> index 02edbdf..4a1f66a 100644
> --- a/arch/arm/mach-kirkwood/Makefile.boot
> +++ b/arch/arm/mach-kirkwood/Makefile.boot
> @@ -7,3 +7,4 @@ dtb-$(CONFIG_MACH_DLINK_KIRKWOOD_DT) += kirkwood-dns320.dtb
> dtb-$(CONFIG_MACH_DLINK_KIRKWOOD_DT) += kirkwood-dns325.dtb
> dtb-$(CONFIG_MACH_ICONNECT_DT) += kirkwood-iconnect.dtb
> dtb-$(CONFIG_MACH_IB62X0_DT) += kirkwood-ib62x0.dtb
> +dtb-$(CONFIG_MACH_TS219_DT) += kirkwood-qnap-ts219.dtb
> diff --git a/arch/arm/mach-kirkwood/board-dt.c b/arch/arm/mach-
kirkwood/board-dt.c
> index 24c8fdd..b7cd6d2 100644
> --- a/arch/arm/mach-kirkwood/board-dt.c
> +++ b/arch/arm/mach-kirkwood/board-dt.c
> @@ -76,6 +76,9 @@ static void __init kirkwood_dt_init(void)
> if (of_machine_is_compatible("raidsonic,ib-nas62x0"))
> ib62x0_init();
>
> + if (of_machine_is_compatible("qnap,ts219"))
> + qnap_dt_ts219_init();
> +
> of_platform_populate(NULL, kirkwood_dt_match_table,
> kirkwood_auxdata_lookup, NULL);
> }
> @@ -86,6 +89,7 @@ static const char *kirkwood_dt_board_compat[] = {
> "dlink,dns-325",
> "iom,iconnect",
> "raidsonic,ib-nas62x0",
> + "qnap,ts219",
> NULL
> };
>
> diff --git a/arch/arm/mach-kirkwood/board-ts219.c b/arch/arm/mach-
kirkwood/board-ts219.c
> new file mode 100644
> index 0000000..00b79ea
> --- /dev/null
> +++ b/arch/arm/mach-kirkwood/board-ts219.c
> @@ -0,0 +1,87 @@
> +/*
> + *
> + * QNAP TS-11x/TS-21x Turbo NAS Board Setup via DT
> + *
> + * Copyright (C) 2012 Andrew Lunn <andrew-g2DYL2Zd6BY@public.gmane.org>
> + *
> + * Based on the board file ts219-setup.c:
> + *
> + * Copyright (C) 2009 Martin Michlmayr <tbm-R+vWnYXSFMfQT0dZR+AlfA@public.gmane.org>
> + * Copyright (C) 2008 Byron Bradley <byron.bbradley-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License
> + * as published by the Free Software Foundation; either version
> + * 2 of the License, or (at your option) any later version.
> + */
> +
> +#include <linux/kernel.h>
> +#include <linux/init.h>
> +#include <linux/platform_device.h>
> +#include <linux/mv643xx_eth.h>
> +#include <linux/ata_platform.h>
> +#include <linux/gpio_keys.h>
> +#include <linux/input.h>
> +#include <asm/mach-types.h>
> +#include <asm/mach/arch.h>
> +#include <mach/kirkwood.h>
> +#include "common.h"
> +#include "mpp.h"
> +#include "tsx1x-common.h"
> +
> +static struct mv643xx_eth_platform_data qnap_ts219_ge00_data = {
> + .phy_addr = MV643XX_ETH_PHY_ADDR(8),
> +};
> +
> +static struct mv_sata_platform_data qnap_ts219_sata_data = {
> + .n_ports = 2,
> +};
> +
> +static unsigned int qnap_ts219_mpp_config[] __initdata = {
> + MPP0_SPI_SCn,
> + MPP1_SPI_MOSI,
> + MPP2_SPI_SCK,
> + MPP3_SPI_MISO,
> + MPP4_SATA1_ACTn,
> + MPP5_SATA0_ACTn,
> + MPP8_TW0_SDA,
> + MPP9_TW0_SCK,
> + MPP10_UART0_TXD,
> + MPP11_UART0_RXD,
> + MPP13_UART1_TXD, /* PIC controller */
> + MPP14_UART1_RXD, /* PIC controller */
> + MPP15_GPIO, /* USB Copy button (on devices with 88F6281) */
> + MPP16_GPIO, /* Reset button (on devices with 88F6281) */
> + MPP36_GPIO, /* RAM: 0: 256 MB, 1: 512 MB */
> + MPP37_GPIO, /* Reset button (on devices with 88F6282) */
> + MPP43_GPIO, /* USB Copy button (on devices with 88F6282) */
> + MPP44_GPIO, /* Board ID: 0: TS-11x, 1: TS-21x */
> + 0
> +};
> +
> +void __init qnap_dt_ts219_init(void)
> +{
> + u32 dev, rev;
> +
> + kirkwood_mpp_conf(qnap_ts219_mpp_config);
> +
> + kirkwood_pcie_id(&dev, &rev);
> + if (dev == MV88F6282_DEV_ID)
> + qnap_ts219_ge00_data.phy_addr = MV643XX_ETH_PHY_ADDR(0);
> +
> + kirkwood_ge00_init(&qnap_ts219_ge00_data);
> + kirkwood_sata_init(&qnap_ts219_sata_data);
> + kirkwood_ehci_init();
> +
> + pm_power_off = qnap_tsx1x_power_off;
> +}
> +
> +/* FIXME: Will not work with DT. Maybe use MPP40_GPIO? */
> +static int __init ts219_pci_init(void)
> +{
> + if (machine_is_ts219())
> + kirkwood_pcie_init(KW_PCIE0);
> +
> + return 0;
> +}
> +subsys_initcall(ts219_pci_init);
> diff --git a/arch/arm/mach-kirkwood/common.h b/arch/arm/mach-
kirkwood/common.h
> index 9248fa2..e0c2324 100644
> --- a/arch/arm/mach-kirkwood/common.h
> +++ b/arch/arm/mach-kirkwood/common.h
> @@ -58,6 +58,11 @@ void dreamplug_init(void);
> #else
> static inline void dreamplug_init(void) {};
> #endif
> +#ifdef CONFIG_MACH_TS219_DT
> +void qnap_dt_ts219_init(void);
> +#else
> +static inline void qnap_dt_ts219_init(void) {};
> +#endif
>
> #ifdef CONFIG_MACH_DLINK_KIRKWOOD_DT
> void dnskw_init(void);
> --
> 1.7.10
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 130+ messages in thread* [PATCH v2 08/12] Kirkwood: Add basic device tree support for QNAP TS219.
@ 2012-07-03 15:47 ` Florian Fainelli
0 siblings, 0 replies; 130+ messages in thread
From: Florian Fainelli @ 2012-07-03 15:47 UTC (permalink / raw)
To: linux-arm-kernel
Hi Andrew,
On Tuesday 03 July 2012 16:22:41 Andrew Lunn wrote:
> The two different variants of QNAP TS devices, varying by SoC, put the
> GPIO keys on different GPIO lines. Hence we need two different DT
> board descriptions, which share the same board-ts219.c file.
Why don't you reorder this patch to be after patch 11/12 so that you do not
need to update this file in patch 11/12?
>
> Signed-off-by: Andrew Lunn <andrew@lunn.ch>
> Acked-by: Jason Cooper <jason@lakedaemon.net>
> ---
[snip]
>
> +config MACH_TS219_DT
> + bool "Device Tree for QNAP TS-110, TS-119, TS-119P+, TS-210, TS-219,
TS-219P and TS-219P+ Turbo NAS"
This looks too long, how about just "Device Tree for QNAP TS-11x, TS-21x NAS"
for instance?
> + select ARCH_KIRKWOOD_DT
> + select ARM_APPENDED_DTB
> + select ARM_ATAG_DTB_COMPAT
> + help
> + Say 'Y' here if you want your kernel to support the QNAP
> + TS-110, TS-119, TS-119P+, TS-210, TS-219, TS-219P and
> + TS-219P+ Turbo NAS devices using Fattened Device Tree.
> + There are two different Device Tree descriptions, depending
> + on if the device is based on an if the board uses the MV6281
> + or MV6282. If you have the wrong one, the buttons will not
> + work.
> +
> config MACH_TS219
> bool "QNAP TS-110, TS-119, TS-119P+, TS-210, TS-219, TS-219P and
TS-219P+ Turbo NAS"
> help
> diff --git a/arch/arm/mach-kirkwood/Makefile b/arch/arm/mach-kirkwood/Makefile
> index d2b0590..0468b23 100644
> --- a/arch/arm/mach-kirkwood/Makefile
> +++ b/arch/arm/mach-kirkwood/Makefile
> @@ -25,3 +25,4 @@ obj-$(CONFIG_MACH_DREAMPLUG_DT) += board-dreamplug.o
> obj-$(CONFIG_MACH_ICONNECT_DT) += board-iconnect.o
> obj-$(CONFIG_MACH_DLINK_KIRKWOOD_DT) += board-dnskw.o
> obj-$(CONFIG_MACH_IB62X0_DT) += board-ib62x0.o
> +obj-$(CONFIG_MACH_TS219_DT) += board-ts219.o
> diff --git a/arch/arm/mach-kirkwood/Makefile.boot b/arch/arm/mach-
kirkwood/Makefile.boot
> index 02edbdf..4a1f66a 100644
> --- a/arch/arm/mach-kirkwood/Makefile.boot
> +++ b/arch/arm/mach-kirkwood/Makefile.boot
> @@ -7,3 +7,4 @@ dtb-$(CONFIG_MACH_DLINK_KIRKWOOD_DT) += kirkwood-dns320.dtb
> dtb-$(CONFIG_MACH_DLINK_KIRKWOOD_DT) += kirkwood-dns325.dtb
> dtb-$(CONFIG_MACH_ICONNECT_DT) += kirkwood-iconnect.dtb
> dtb-$(CONFIG_MACH_IB62X0_DT) += kirkwood-ib62x0.dtb
> +dtb-$(CONFIG_MACH_TS219_DT) += kirkwood-qnap-ts219.dtb
> diff --git a/arch/arm/mach-kirkwood/board-dt.c b/arch/arm/mach-
kirkwood/board-dt.c
> index 24c8fdd..b7cd6d2 100644
> --- a/arch/arm/mach-kirkwood/board-dt.c
> +++ b/arch/arm/mach-kirkwood/board-dt.c
> @@ -76,6 +76,9 @@ static void __init kirkwood_dt_init(void)
> if (of_machine_is_compatible("raidsonic,ib-nas62x0"))
> ib62x0_init();
>
> + if (of_machine_is_compatible("qnap,ts219"))
> + qnap_dt_ts219_init();
> +
> of_platform_populate(NULL, kirkwood_dt_match_table,
> kirkwood_auxdata_lookup, NULL);
> }
> @@ -86,6 +89,7 @@ static const char *kirkwood_dt_board_compat[] = {
> "dlink,dns-325",
> "iom,iconnect",
> "raidsonic,ib-nas62x0",
> + "qnap,ts219",
> NULL
> };
>
> diff --git a/arch/arm/mach-kirkwood/board-ts219.c b/arch/arm/mach-
kirkwood/board-ts219.c
> new file mode 100644
> index 0000000..00b79ea
> --- /dev/null
> +++ b/arch/arm/mach-kirkwood/board-ts219.c
> @@ -0,0 +1,87 @@
> +/*
> + *
> + * QNAP TS-11x/TS-21x Turbo NAS Board Setup via DT
> + *
> + * Copyright (C) 2012 Andrew Lunn <andrew@lunn.ch>
> + *
> + * Based on the board file ts219-setup.c:
> + *
> + * Copyright (C) 2009 Martin Michlmayr <tbm@cyrius.com>
> + * Copyright (C) 2008 Byron Bradley <byron.bbradley@gmail.com>
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License
> + * as published by the Free Software Foundation; either version
> + * 2 of the License, or (at your option) any later version.
> + */
> +
> +#include <linux/kernel.h>
> +#include <linux/init.h>
> +#include <linux/platform_device.h>
> +#include <linux/mv643xx_eth.h>
> +#include <linux/ata_platform.h>
> +#include <linux/gpio_keys.h>
> +#include <linux/input.h>
> +#include <asm/mach-types.h>
> +#include <asm/mach/arch.h>
> +#include <mach/kirkwood.h>
> +#include "common.h"
> +#include "mpp.h"
> +#include "tsx1x-common.h"
> +
> +static struct mv643xx_eth_platform_data qnap_ts219_ge00_data = {
> + .phy_addr = MV643XX_ETH_PHY_ADDR(8),
> +};
> +
> +static struct mv_sata_platform_data qnap_ts219_sata_data = {
> + .n_ports = 2,
> +};
> +
> +static unsigned int qnap_ts219_mpp_config[] __initdata = {
> + MPP0_SPI_SCn,
> + MPP1_SPI_MOSI,
> + MPP2_SPI_SCK,
> + MPP3_SPI_MISO,
> + MPP4_SATA1_ACTn,
> + MPP5_SATA0_ACTn,
> + MPP8_TW0_SDA,
> + MPP9_TW0_SCK,
> + MPP10_UART0_TXD,
> + MPP11_UART0_RXD,
> + MPP13_UART1_TXD, /* PIC controller */
> + MPP14_UART1_RXD, /* PIC controller */
> + MPP15_GPIO, /* USB Copy button (on devices with 88F6281) */
> + MPP16_GPIO, /* Reset button (on devices with 88F6281) */
> + MPP36_GPIO, /* RAM: 0: 256 MB, 1: 512 MB */
> + MPP37_GPIO, /* Reset button (on devices with 88F6282) */
> + MPP43_GPIO, /* USB Copy button (on devices with 88F6282) */
> + MPP44_GPIO, /* Board ID: 0: TS-11x, 1: TS-21x */
> + 0
> +};
> +
> +void __init qnap_dt_ts219_init(void)
> +{
> + u32 dev, rev;
> +
> + kirkwood_mpp_conf(qnap_ts219_mpp_config);
> +
> + kirkwood_pcie_id(&dev, &rev);
> + if (dev == MV88F6282_DEV_ID)
> + qnap_ts219_ge00_data.phy_addr = MV643XX_ETH_PHY_ADDR(0);
> +
> + kirkwood_ge00_init(&qnap_ts219_ge00_data);
> + kirkwood_sata_init(&qnap_ts219_sata_data);
> + kirkwood_ehci_init();
> +
> + pm_power_off = qnap_tsx1x_power_off;
> +}
> +
> +/* FIXME: Will not work with DT. Maybe use MPP40_GPIO? */
> +static int __init ts219_pci_init(void)
> +{
> + if (machine_is_ts219())
> + kirkwood_pcie_init(KW_PCIE0);
> +
> + return 0;
> +}
> +subsys_initcall(ts219_pci_init);
> diff --git a/arch/arm/mach-kirkwood/common.h b/arch/arm/mach-
kirkwood/common.h
> index 9248fa2..e0c2324 100644
> --- a/arch/arm/mach-kirkwood/common.h
> +++ b/arch/arm/mach-kirkwood/common.h
> @@ -58,6 +58,11 @@ void dreamplug_init(void);
> #else
> static inline void dreamplug_init(void) {};
> #endif
> +#ifdef CONFIG_MACH_TS219_DT
> +void qnap_dt_ts219_init(void);
> +#else
> +static inline void qnap_dt_ts219_init(void) {};
> +#endif
>
> #ifdef CONFIG_MACH_DLINK_KIRKWOOD_DT
> void dnskw_init(void);
> --
> 1.7.10
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 130+ messages in thread* Re: [PATCH v2 08/12] Kirkwood: Add basic device tree support for QNAP TS219.
2012-07-03 15:47 ` Florian Fainelli
@ 2012-07-03 17:09 ` Andrew Lunn
-1 siblings, 0 replies; 130+ messages in thread
From: Andrew Lunn @ 2012-07-03 17:09 UTC (permalink / raw)
To: Florian Fainelli
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Andrew Lunn,
Jason Cooper, devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
rob.herring-bsGFqQB8/DxBDgjK7y7TUQ,
grant.likely-s3s/WqlpOiPyB63q8FvJNQ, Michael Walle,
linux-i2c-u79uwXL29TY76Z2rM5mHXA,
spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
On Tue, Jul 03, 2012 at 05:47:57PM +0200, Florian Fainelli wrote:
> Hi Andrew,
>
> On Tuesday 03 July 2012 16:22:41 Andrew Lunn wrote:
> > The two different variants of QNAP TS devices, varying by SoC, put the
> > GPIO keys on different GPIO lines. Hence we need two different DT
> > board descriptions, which share the same board-ts219.c file.
>
> Why don't you reorder this patch to be after patch 11/12 so that you do not
> need to update this file in patch 11/12?
It just reflects the order i did the work. I can rebase it, but what
is the advantage? It should be fully bisectable as is.
>
> >
> > Signed-off-by: Andrew Lunn <andrew-g2DYL2Zd6BY@public.gmane.org>
> > Acked-by: Jason Cooper <jason-NLaQJdtUoK4Be96aLqz0jA@public.gmane.org>
> > ---
> [snip]
> >
> > +config MACH_TS219_DT
> > + bool "Device Tree for QNAP TS-110, TS-119, TS-119P+, TS-210, TS-219,
> TS-219P and TS-219P+ Turbo NAS"
>
> This looks too long, how about just "Device Tree for QNAP TS-11x, TS-21x NAS"
> for instance?
Yes, i was not too happy with this. I copied the none DT version as a
basis, since that is what kernel builds know at the moment. Since i'm
not alone not liking it, i will change it as you suggested.
Thanks
Andrew
^ permalink raw reply [flat|nested] 130+ messages in thread* [PATCH v2 08/12] Kirkwood: Add basic device tree support for QNAP TS219.
@ 2012-07-03 17:09 ` Andrew Lunn
0 siblings, 0 replies; 130+ messages in thread
From: Andrew Lunn @ 2012-07-03 17:09 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Jul 03, 2012 at 05:47:57PM +0200, Florian Fainelli wrote:
> Hi Andrew,
>
> On Tuesday 03 July 2012 16:22:41 Andrew Lunn wrote:
> > The two different variants of QNAP TS devices, varying by SoC, put the
> > GPIO keys on different GPIO lines. Hence we need two different DT
> > board descriptions, which share the same board-ts219.c file.
>
> Why don't you reorder this patch to be after patch 11/12 so that you do not
> need to update this file in patch 11/12?
It just reflects the order i did the work. I can rebase it, but what
is the advantage? It should be fully bisectable as is.
>
> >
> > Signed-off-by: Andrew Lunn <andrew@lunn.ch>
> > Acked-by: Jason Cooper <jason@lakedaemon.net>
> > ---
> [snip]
> >
> > +config MACH_TS219_DT
> > + bool "Device Tree for QNAP TS-110, TS-119, TS-119P+, TS-210, TS-219,
> TS-219P and TS-219P+ Turbo NAS"
>
> This looks too long, how about just "Device Tree for QNAP TS-11x, TS-21x NAS"
> for instance?
Yes, i was not too happy with this. I copied the none DT version as a
basis, since that is what kernel builds know at the moment. Since i'm
not alone not liking it, i will change it as you suggested.
Thanks
Andrew
^ permalink raw reply [flat|nested] 130+ messages in thread
* [PATCH v2 09/12] ARM: Kirkwood: DTify the watchdog timer.
2012-07-03 14:22 ` Andrew Lunn
@ 2012-07-03 14:22 ` Andrew Lunn
-1 siblings, 0 replies; 130+ messages in thread
From: Andrew Lunn @ 2012-07-03 14:22 UTC (permalink / raw)
To: Jason Cooper
Cc: grant.likely-s3s/WqlpOiPyB63q8FvJNQ,
spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
linux-i2c-u79uwXL29TY76Z2rM5mHXA,
rob.herring-bsGFqQB8/DxBDgjK7y7TUQ,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Michael Walle,
Andrew Lunn
Add device tree support to the Orion watchdog timer, and enable its
use in the kirkwood devices using device tree.
Signed-off-by: Andrew Lunn <andrew-g2DYL2Zd6BY@public.gmane.org>
---
Documentation/devicetree/bindings/watchdog/marvel.txt | 14 ++++++++++++++
arch/arm/boot/dts/kirkwood.dtsi | 6 ++++++
arch/arm/mach-kirkwood/board-dt.c | 2 +-
drivers/watchdog/orion_wdt.c | 8 ++++++++
4 files changed, 29 insertions(+), 1 deletion(-)
create mode 100644 Documentation/devicetree/bindings/watchdog/marvel.txt
diff --git a/Documentation/devicetree/bindings/watchdog/marvel.txt b/Documentation/devicetree/bindings/watchdog/marvel.txt
new file mode 100644
index 0000000..0b2503a
--- /dev/null
+++ b/Documentation/devicetree/bindings/watchdog/marvel.txt
@@ -0,0 +1,14 @@
+* Marvell Orion Watchdog Time
+
+Required Properties:
+
+- Compatibility : "marvell,orion-wdt"
+- reg : Address of the timer registers
+
+Example:
+
+ wdt@20300 {
+ compatible = "marvell,orion-wdt";
+ reg = <0x20300 0x28>;
+ status = "okay";
+ };
diff --git a/arch/arm/boot/dts/kirkwood.dtsi b/arch/arm/boot/dts/kirkwood.dtsi
index c8bc122..be8e127 100644
--- a/arch/arm/boot/dts/kirkwood.dtsi
+++ b/arch/arm/boot/dts/kirkwood.dtsi
@@ -69,6 +69,12 @@
status = "disabled";
};
+ wdt@20300 {
+ compatible = "marvell,orion-wdt";
+ reg = <0x20300 0x28>;
+ status = "okay";
+ };
+
nand@3000000 {
#address-cells = <1>;
#size-cells = <1>;
diff --git a/arch/arm/mach-kirkwood/board-dt.c b/arch/arm/mach-kirkwood/board-dt.c
index b7cd6d2..73e75cf 100644
--- a/arch/arm/mach-kirkwood/board-dt.c
+++ b/arch/arm/mach-kirkwood/board-dt.c
@@ -30,6 +30,7 @@ struct of_dev_auxdata kirkwood_auxdata_lookup[] __initdata = {
OF_DEV_AUXDATA("marvell,orion-spi", 0xf1010600, "orion_spi.0", NULL),
OF_DEV_AUXDATA("marvell,mv64xxx-i2c", 0xf1011000, "mv64xxx_i2c.0",
NULL),
+ OF_DEV_AUXDATA("marvell,orion-wdt", 0xf1020300, "orion_wdt", NULL),
{},
};
@@ -55,7 +56,6 @@ static void __init kirkwood_dt_init(void)
kirkwood_clk_init();
/* internal devices that every board has */
- kirkwood_wdt_init();
kirkwood_xor0_init();
kirkwood_xor1_init();
kirkwood_crypto_init();
diff --git a/drivers/watchdog/orion_wdt.c b/drivers/watchdog/orion_wdt.c
index 0f57369..1531e02 100644
--- a/drivers/watchdog/orion_wdt.c
+++ b/drivers/watchdog/orion_wdt.c
@@ -25,6 +25,7 @@
#include <linux/io.h>
#include <linux/spinlock.h>
#include <linux/clk.h>
+#include <linux/of.h>
#include <mach/bridge-regs.h>
/*
@@ -295,6 +296,12 @@ static void orion_wdt_shutdown(struct platform_device *pdev)
orion_wdt_disable();
}
+static const struct of_device_id orion_wdt_of_match_table[] __devinitdata = {
+ { .compatible = "marvell,orion-wdt", },
+ {},
+};
+MODULE_DEVICE_TABLE(of, orion_wdt_of_match_table);
+
static struct platform_driver orion_wdt_driver = {
.probe = orion_wdt_probe,
.remove = __devexit_p(orion_wdt_remove),
@@ -302,6 +309,7 @@ static struct platform_driver orion_wdt_driver = {
.driver = {
.owner = THIS_MODULE,
.name = "orion_wdt",
+ .of_match_table = of_match_ptr(orion_wdt_of_match_table),
},
};
--
1.7.10
^ permalink raw reply related [flat|nested] 130+ messages in thread* [PATCH v2 09/12] ARM: Kirkwood: DTify the watchdog timer.
@ 2012-07-03 14:22 ` Andrew Lunn
0 siblings, 0 replies; 130+ messages in thread
From: Andrew Lunn @ 2012-07-03 14:22 UTC (permalink / raw)
To: linux-arm-kernel
Add device tree support to the Orion watchdog timer, and enable its
use in the kirkwood devices using device tree.
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
---
Documentation/devicetree/bindings/watchdog/marvel.txt | 14 ++++++++++++++
arch/arm/boot/dts/kirkwood.dtsi | 6 ++++++
arch/arm/mach-kirkwood/board-dt.c | 2 +-
drivers/watchdog/orion_wdt.c | 8 ++++++++
4 files changed, 29 insertions(+), 1 deletion(-)
create mode 100644 Documentation/devicetree/bindings/watchdog/marvel.txt
diff --git a/Documentation/devicetree/bindings/watchdog/marvel.txt b/Documentation/devicetree/bindings/watchdog/marvel.txt
new file mode 100644
index 0000000..0b2503a
--- /dev/null
+++ b/Documentation/devicetree/bindings/watchdog/marvel.txt
@@ -0,0 +1,14 @@
+* Marvell Orion Watchdog Time
+
+Required Properties:
+
+- Compatibility : "marvell,orion-wdt"
+- reg : Address of the timer registers
+
+Example:
+
+ wdt at 20300 {
+ compatible = "marvell,orion-wdt";
+ reg = <0x20300 0x28>;
+ status = "okay";
+ };
diff --git a/arch/arm/boot/dts/kirkwood.dtsi b/arch/arm/boot/dts/kirkwood.dtsi
index c8bc122..be8e127 100644
--- a/arch/arm/boot/dts/kirkwood.dtsi
+++ b/arch/arm/boot/dts/kirkwood.dtsi
@@ -69,6 +69,12 @@
status = "disabled";
};
+ wdt at 20300 {
+ compatible = "marvell,orion-wdt";
+ reg = <0x20300 0x28>;
+ status = "okay";
+ };
+
nand at 3000000 {
#address-cells = <1>;
#size-cells = <1>;
diff --git a/arch/arm/mach-kirkwood/board-dt.c b/arch/arm/mach-kirkwood/board-dt.c
index b7cd6d2..73e75cf 100644
--- a/arch/arm/mach-kirkwood/board-dt.c
+++ b/arch/arm/mach-kirkwood/board-dt.c
@@ -30,6 +30,7 @@ struct of_dev_auxdata kirkwood_auxdata_lookup[] __initdata = {
OF_DEV_AUXDATA("marvell,orion-spi", 0xf1010600, "orion_spi.0", NULL),
OF_DEV_AUXDATA("marvell,mv64xxx-i2c", 0xf1011000, "mv64xxx_i2c.0",
NULL),
+ OF_DEV_AUXDATA("marvell,orion-wdt", 0xf1020300, "orion_wdt", NULL),
{},
};
@@ -55,7 +56,6 @@ static void __init kirkwood_dt_init(void)
kirkwood_clk_init();
/* internal devices that every board has */
- kirkwood_wdt_init();
kirkwood_xor0_init();
kirkwood_xor1_init();
kirkwood_crypto_init();
diff --git a/drivers/watchdog/orion_wdt.c b/drivers/watchdog/orion_wdt.c
index 0f57369..1531e02 100644
--- a/drivers/watchdog/orion_wdt.c
+++ b/drivers/watchdog/orion_wdt.c
@@ -25,6 +25,7 @@
#include <linux/io.h>
#include <linux/spinlock.h>
#include <linux/clk.h>
+#include <linux/of.h>
#include <mach/bridge-regs.h>
/*
@@ -295,6 +296,12 @@ static void orion_wdt_shutdown(struct platform_device *pdev)
orion_wdt_disable();
}
+static const struct of_device_id orion_wdt_of_match_table[] __devinitdata = {
+ { .compatible = "marvell,orion-wdt", },
+ {},
+};
+MODULE_DEVICE_TABLE(of, orion_wdt_of_match_table);
+
static struct platform_driver orion_wdt_driver = {
.probe = orion_wdt_probe,
.remove = __devexit_p(orion_wdt_remove),
@@ -302,6 +309,7 @@ static struct platform_driver orion_wdt_driver = {
.driver = {
.owner = THIS_MODULE,
.name = "orion_wdt",
+ .of_match_table = of_match_ptr(orion_wdt_of_match_table),
},
};
--
1.7.10
^ permalink raw reply related [flat|nested] 130+ messages in thread
* [PATCH v2 10/12] ATA: sata_mv: Add device tree support
2012-07-03 14:22 ` Andrew Lunn
@ 2012-07-03 14:22 ` Andrew Lunn
-1 siblings, 0 replies; 130+ messages in thread
From: Andrew Lunn @ 2012-07-03 14:22 UTC (permalink / raw)
To: Jason Cooper
Cc: Andrew Lunn, devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
rob.herring-bsGFqQB8/DxBDgjK7y7TUQ, Michael Walle,
linux-i2c-u79uwXL29TY76Z2rM5mHXA,
spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Add support for instantiating this driver from device tree, and add
the necassary DT information to the kirkwood.dtsi file.
This is based on previous work by Michael Walle and Jason Cooper.
Signed-off-by: Andrew Lunn <andrew-g2DYL2Zd6BY@public.gmane.org>
---
Documentation/devicetree/bindings/ata/marvell.txt | 16 ++++++++
arch/arm/boot/dts/kirkwood.dtsi | 7 ++++
arch/arm/mach-kirkwood/board-dt.c | 1 +
drivers/ata/sata_mv.c | 42 ++++++++++++++-------
4 files changed, 53 insertions(+), 13 deletions(-)
create mode 100644 Documentation/devicetree/bindings/ata/marvell.txt
diff --git a/Documentation/devicetree/bindings/ata/marvell.txt b/Documentation/devicetree/bindings/ata/marvell.txt
new file mode 100644
index 0000000..b5cdd20
--- /dev/null
+++ b/Documentation/devicetree/bindings/ata/marvell.txt
@@ -0,0 +1,16 @@
+* Marvell Orion SATA
+
+Required Properties:
+- compatibility : "marvell,orion-sata"
+- reg : Address range of controller
+- interrupts : Interrupt controller is using
+- nr-ports : Number of SATA ports in use.
+
+Example:
+
+ sata@80000 {
+ compatible = "marvell,orion-sata";
+ reg = <0x80000 0x5000>;
+ interrupts = <21>;
+ nr-ports = <2>;
+ }
diff --git a/arch/arm/boot/dts/kirkwood.dtsi b/arch/arm/boot/dts/kirkwood.dtsi
index be8e127..ec31b8b 100644
--- a/arch/arm/boot/dts/kirkwood.dtsi
+++ b/arch/arm/boot/dts/kirkwood.dtsi
@@ -75,6 +75,13 @@
status = "okay";
};
+ sata@80000 {
+ compatible = "marvell,orion-sata";
+ reg = <0x80000 0x5000>;
+ interrupts = <21>;
+ status = "disabled";
+ };
+
nand@3000000 {
#address-cells = <1>;
#size-cells = <1>;
diff --git a/arch/arm/mach-kirkwood/board-dt.c b/arch/arm/mach-kirkwood/board-dt.c
index 73e75cf..d0ad250 100644
--- a/arch/arm/mach-kirkwood/board-dt.c
+++ b/arch/arm/mach-kirkwood/board-dt.c
@@ -31,6 +31,7 @@ struct of_dev_auxdata kirkwood_auxdata_lookup[] __initdata = {
OF_DEV_AUXDATA("marvell,mv64xxx-i2c", 0xf1011000, "mv64xxx_i2c.0",
NULL),
OF_DEV_AUXDATA("marvell,orion-wdt", 0xf1020300, "orion_wdt", NULL),
+ OF_DEV_AUXDATA("marvell,orion-sata", 0xf1080000, "sata_mv.0", NULL),
{},
};
diff --git a/drivers/ata/sata_mv.c b/drivers/ata/sata_mv.c
index 24712ad..8282367 100644
--- a/drivers/ata/sata_mv.c
+++ b/drivers/ata/sata_mv.c
@@ -65,6 +65,8 @@
#include <linux/mbus.h>
#include <linux/bitops.h>
#include <linux/gfp.h>
+#include <linux/of.h>
+#include <linux/of_irq.h>
#include <scsi/scsi_host.h>
#include <scsi/scsi_cmnd.h>
#include <scsi/scsi_device.h>
@@ -4026,7 +4028,7 @@ static int mv_platform_probe(struct platform_device *pdev)
struct ata_host *host;
struct mv_host_priv *hpriv;
struct resource *res;
- int n_ports = 0;
+ int n_ports = 0, irq = 0;
int rc;
#if defined(CONFIG_HAVE_CLK)
int port;
@@ -4050,8 +4052,14 @@ static int mv_platform_probe(struct platform_device *pdev)
return -EINVAL;
/* allocate host */
- mv_platform_data = pdev->dev.platform_data;
- n_ports = mv_platform_data->n_ports;
+ if (pdev->dev.of_node) {
+ of_property_read_u32(pdev->dev.of_node, "nr-ports", &n_ports);
+ irq = irq_of_parse_and_map(pdev->dev.of_node, 0);
+ } else {
+ mv_platform_data = pdev->dev.platform_data;
+ n_ports = mv_platform_data->n_ports;
+ irq = platform_get_irq(pdev, 0);
+ }
host = ata_host_alloc_pinfo(&pdev->dev, ppi, n_ports);
hpriv = devm_kzalloc(&pdev->dev, sizeof(*hpriv), GFP_KERNEL);
@@ -4109,8 +4117,7 @@ static int mv_platform_probe(struct platform_device *pdev)
dev_info(&pdev->dev, "slots %u ports %d\n",
(unsigned)MV_MAX_Q_DEPTH, host->n_ports);
- rc = ata_host_activate(host, platform_get_irq(pdev, 0), mv_interrupt,
- IRQF_SHARED, &mv6_sht);
+ rc = ata_host_activate(host, irq, mv_interrupt, IRQF_SHARED, &mv6_sht);
if (!rc)
return 0;
@@ -4205,15 +4212,24 @@ static int mv_platform_resume(struct platform_device *pdev)
#define mv_platform_resume NULL
#endif
+#ifdef CONFIG_OF
+static struct of_device_id mv_sata_dt_ids[] __devinitdata = {
+ { .compatible = "marvell,orion-sata", },
+ {},
+};
+MODULE_DEVICE_TABLE(of, mvsdio_dt_ids);
+#endif
+
static struct platform_driver mv_platform_driver = {
- .probe = mv_platform_probe,
- .remove = __devexit_p(mv_platform_remove),
- .suspend = mv_platform_suspend,
- .resume = mv_platform_resume,
- .driver = {
- .name = DRV_NAME,
- .owner = THIS_MODULE,
- },
+ .probe = mv_platform_probe,
+ .remove = __devexit_p(mv_platform_remove),
+ .suspend = mv_platform_suspend,
+ .resume = mv_platform_resume,
+ .driver = {
+ .name = DRV_NAME,
+ .owner = THIS_MODULE,
+ .of_match_table = of_match_ptr(mv_sata_dt_ids),
+ },
};
--
1.7.10
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
^ permalink raw reply related [flat|nested] 130+ messages in thread* [PATCH v2 10/12] ATA: sata_mv: Add device tree support
@ 2012-07-03 14:22 ` Andrew Lunn
0 siblings, 0 replies; 130+ messages in thread
From: Andrew Lunn @ 2012-07-03 14:22 UTC (permalink / raw)
To: linux-arm-kernel
Add support for instantiating this driver from device tree, and add
the necassary DT information to the kirkwood.dtsi file.
This is based on previous work by Michael Walle and Jason Cooper.
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
---
Documentation/devicetree/bindings/ata/marvell.txt | 16 ++++++++
arch/arm/boot/dts/kirkwood.dtsi | 7 ++++
arch/arm/mach-kirkwood/board-dt.c | 1 +
drivers/ata/sata_mv.c | 42 ++++++++++++++-------
4 files changed, 53 insertions(+), 13 deletions(-)
create mode 100644 Documentation/devicetree/bindings/ata/marvell.txt
diff --git a/Documentation/devicetree/bindings/ata/marvell.txt b/Documentation/devicetree/bindings/ata/marvell.txt
new file mode 100644
index 0000000..b5cdd20
--- /dev/null
+++ b/Documentation/devicetree/bindings/ata/marvell.txt
@@ -0,0 +1,16 @@
+* Marvell Orion SATA
+
+Required Properties:
+- compatibility : "marvell,orion-sata"
+- reg : Address range of controller
+- interrupts : Interrupt controller is using
+- nr-ports : Number of SATA ports in use.
+
+Example:
+
+ sata at 80000 {
+ compatible = "marvell,orion-sata";
+ reg = <0x80000 0x5000>;
+ interrupts = <21>;
+ nr-ports = <2>;
+ }
diff --git a/arch/arm/boot/dts/kirkwood.dtsi b/arch/arm/boot/dts/kirkwood.dtsi
index be8e127..ec31b8b 100644
--- a/arch/arm/boot/dts/kirkwood.dtsi
+++ b/arch/arm/boot/dts/kirkwood.dtsi
@@ -75,6 +75,13 @@
status = "okay";
};
+ sata at 80000 {
+ compatible = "marvell,orion-sata";
+ reg = <0x80000 0x5000>;
+ interrupts = <21>;
+ status = "disabled";
+ };
+
nand at 3000000 {
#address-cells = <1>;
#size-cells = <1>;
diff --git a/arch/arm/mach-kirkwood/board-dt.c b/arch/arm/mach-kirkwood/board-dt.c
index 73e75cf..d0ad250 100644
--- a/arch/arm/mach-kirkwood/board-dt.c
+++ b/arch/arm/mach-kirkwood/board-dt.c
@@ -31,6 +31,7 @@ struct of_dev_auxdata kirkwood_auxdata_lookup[] __initdata = {
OF_DEV_AUXDATA("marvell,mv64xxx-i2c", 0xf1011000, "mv64xxx_i2c.0",
NULL),
OF_DEV_AUXDATA("marvell,orion-wdt", 0xf1020300, "orion_wdt", NULL),
+ OF_DEV_AUXDATA("marvell,orion-sata", 0xf1080000, "sata_mv.0", NULL),
{},
};
diff --git a/drivers/ata/sata_mv.c b/drivers/ata/sata_mv.c
index 24712ad..8282367 100644
--- a/drivers/ata/sata_mv.c
+++ b/drivers/ata/sata_mv.c
@@ -65,6 +65,8 @@
#include <linux/mbus.h>
#include <linux/bitops.h>
#include <linux/gfp.h>
+#include <linux/of.h>
+#include <linux/of_irq.h>
#include <scsi/scsi_host.h>
#include <scsi/scsi_cmnd.h>
#include <scsi/scsi_device.h>
@@ -4026,7 +4028,7 @@ static int mv_platform_probe(struct platform_device *pdev)
struct ata_host *host;
struct mv_host_priv *hpriv;
struct resource *res;
- int n_ports = 0;
+ int n_ports = 0, irq = 0;
int rc;
#if defined(CONFIG_HAVE_CLK)
int port;
@@ -4050,8 +4052,14 @@ static int mv_platform_probe(struct platform_device *pdev)
return -EINVAL;
/* allocate host */
- mv_platform_data = pdev->dev.platform_data;
- n_ports = mv_platform_data->n_ports;
+ if (pdev->dev.of_node) {
+ of_property_read_u32(pdev->dev.of_node, "nr-ports", &n_ports);
+ irq = irq_of_parse_and_map(pdev->dev.of_node, 0);
+ } else {
+ mv_platform_data = pdev->dev.platform_data;
+ n_ports = mv_platform_data->n_ports;
+ irq = platform_get_irq(pdev, 0);
+ }
host = ata_host_alloc_pinfo(&pdev->dev, ppi, n_ports);
hpriv = devm_kzalloc(&pdev->dev, sizeof(*hpriv), GFP_KERNEL);
@@ -4109,8 +4117,7 @@ static int mv_platform_probe(struct platform_device *pdev)
dev_info(&pdev->dev, "slots %u ports %d\n",
(unsigned)MV_MAX_Q_DEPTH, host->n_ports);
- rc = ata_host_activate(host, platform_get_irq(pdev, 0), mv_interrupt,
- IRQF_SHARED, &mv6_sht);
+ rc = ata_host_activate(host, irq, mv_interrupt, IRQF_SHARED, &mv6_sht);
if (!rc)
return 0;
@@ -4205,15 +4212,24 @@ static int mv_platform_resume(struct platform_device *pdev)
#define mv_platform_resume NULL
#endif
+#ifdef CONFIG_OF
+static struct of_device_id mv_sata_dt_ids[] __devinitdata = {
+ { .compatible = "marvell,orion-sata", },
+ {},
+};
+MODULE_DEVICE_TABLE(of, mvsdio_dt_ids);
+#endif
+
static struct platform_driver mv_platform_driver = {
- .probe = mv_platform_probe,
- .remove = __devexit_p(mv_platform_remove),
- .suspend = mv_platform_suspend,
- .resume = mv_platform_resume,
- .driver = {
- .name = DRV_NAME,
- .owner = THIS_MODULE,
- },
+ .probe = mv_platform_probe,
+ .remove = __devexit_p(mv_platform_remove),
+ .suspend = mv_platform_suspend,
+ .resume = mv_platform_resume,
+ .driver = {
+ .name = DRV_NAME,
+ .owner = THIS_MODULE,
+ .of_match_table = of_match_ptr(mv_sata_dt_ids),
+ },
};
--
1.7.10
^ permalink raw reply related [flat|nested] 130+ messages in thread
* [PATCH v2 11/12] ARM: Kirkwood: Use DT to configure SATA device.
2012-07-03 14:22 ` Andrew Lunn
@ 2012-07-03 14:22 ` Andrew Lunn
-1 siblings, 0 replies; 130+ messages in thread
From: Andrew Lunn @ 2012-07-03 14:22 UTC (permalink / raw)
To: Jason Cooper
Cc: grant.likely-s3s/WqlpOiPyB63q8FvJNQ,
spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
linux-i2c-u79uwXL29TY76Z2rM5mHXA,
rob.herring-bsGFqQB8/DxBDgjK7y7TUQ,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Michael Walle,
Andrew Lunn
Convert boards using DT, but the old way of configuring SATA to now
use properties in there DT file.
Signed-off-by: Andrew Lunn <andrew-g2DYL2Zd6BY@public.gmane.org>
---
arch/arm/boot/dts/kirkwood-dns320.dts | 5 +++++
arch/arm/boot/dts/kirkwood-dns325.dts | 5 +++++
arch/arm/boot/dts/kirkwood-dreamplug.dts | 5 +++++
arch/arm/boot/dts/kirkwood-ib62x0.dts | 5 +++++
arch/arm/boot/dts/kirkwood-ts219.dtsi | 4 ++++
arch/arm/mach-kirkwood/board-dnskw.c | 5 -----
arch/arm/mach-kirkwood/board-dreamplug.c | 5 -----
arch/arm/mach-kirkwood/board-ib62x0.c | 5 -----
arch/arm/mach-kirkwood/board-ts219.c | 5 -----
9 files changed, 24 insertions(+), 20 deletions(-)
diff --git a/arch/arm/boot/dts/kirkwood-dns320.dts b/arch/arm/boot/dts/kirkwood-dns320.dts
index dc09a73..f2a9808 100644
--- a/arch/arm/boot/dts/kirkwood-dns320.dts
+++ b/arch/arm/boot/dts/kirkwood-dns320.dts
@@ -26,6 +26,11 @@
status = "okay";
};
+ sata@80000 {
+ status = "okay";
+ nr-ports = <2>;
+ };
+
nand@3000000 {
status = "okay";
diff --git a/arch/arm/boot/dts/kirkwood-dns325.dts b/arch/arm/boot/dts/kirkwood-dns325.dts
index c2a5562..10bc819 100644
--- a/arch/arm/boot/dts/kirkwood-dns325.dts
+++ b/arch/arm/boot/dts/kirkwood-dns325.dts
@@ -21,6 +21,11 @@
status = "okay";
};
+ sata@80000 {
+ status = "okay";
+ nr-ports = <2>;
+ };
+
nand@3000000 {
status = "okay";
diff --git a/arch/arm/boot/dts/kirkwood-dreamplug.dts b/arch/arm/boot/dts/kirkwood-dreamplug.dts
index d74d1ae..24de2b5 100644
--- a/arch/arm/boot/dts/kirkwood-dreamplug.dts
+++ b/arch/arm/boot/dts/kirkwood-dreamplug.dts
@@ -48,6 +48,11 @@
};
};
};
+
+ sata@80000 {
+ status = "okay";
+ nr-ports = <1>;
+ };
};
};
diff --git a/arch/arm/boot/dts/kirkwood-ib62x0.dts b/arch/arm/boot/dts/kirkwood-ib62x0.dts
index ada0f0c..f8e2bc6 100644
--- a/arch/arm/boot/dts/kirkwood-ib62x0.dts
+++ b/arch/arm/boot/dts/kirkwood-ib62x0.dts
@@ -21,6 +21,11 @@
status = "okay";
};
+ sata@80000 {
+ status = "okay";
+ nr-ports = <2>;
+ };
+
nand@3000000 {
status = "okay";
diff --git a/arch/arm/boot/dts/kirkwood-ts219.dtsi b/arch/arm/boot/dts/kirkwood-ts219.dtsi
index e0520c3..9b4ee7d 100644
--- a/arch/arm/boot/dts/kirkwood-ts219.dtsi
+++ b/arch/arm/boot/dts/kirkwood-ts219.dtsi
@@ -69,5 +69,9 @@
};
};
};
+ sata@80000 {
+ status = "okay";
+ nr-ports = <2>;
+ };
};
};
diff --git a/arch/arm/mach-kirkwood/board-dnskw.c b/arch/arm/mach-kirkwood/board-dnskw.c
index 58c2d68..179f4b3 100644
--- a/arch/arm/mach-kirkwood/board-dnskw.c
+++ b/arch/arm/mach-kirkwood/board-dnskw.c
@@ -35,10 +35,6 @@ static struct mv643xx_eth_platform_data dnskw_ge00_data = {
.phy_addr = MV643XX_ETH_PHY_ADDR(8),
};
-static struct mv_sata_platform_data dnskw_sata_data = {
- .n_ports = 2,
-};
-
static unsigned int dnskw_mpp_config[] __initdata = {
MPP13_UART1_TXD, /* Custom ... */
MPP14_UART1_RXD, /* ... Controller (DNS-320 only) */
@@ -245,7 +241,6 @@ void __init dnskw_init(void)
kirkwood_ehci_init();
kirkwood_ge00_init(&dnskw_ge00_data);
- kirkwood_sata_init(&dnskw_sata_data);
kirkwood_i2c_init();
platform_device_register(&dnskw_button_device);
diff --git a/arch/arm/mach-kirkwood/board-dreamplug.c b/arch/arm/mach-kirkwood/board-dreamplug.c
index eb0e4d5..e494393 100644
--- a/arch/arm/mach-kirkwood/board-dreamplug.c
+++ b/arch/arm/mach-kirkwood/board-dreamplug.c
@@ -43,10 +43,6 @@ static struct mv643xx_eth_platform_data dreamplug_ge01_data = {
.phy_addr = MV643XX_ETH_PHY_ADDR(1),
};
-static struct mv_sata_platform_data dreamplug_sata_data = {
- .n_ports = 1,
-};
-
static struct mvsdio_platform_data dreamplug_mvsdio_data = {
/* unfortunately the CD signal has not been connected */
};
@@ -103,7 +99,6 @@ void __init dreamplug_init(void)
kirkwood_ehci_init();
kirkwood_ge00_init(&dreamplug_ge00_data);
kirkwood_ge01_init(&dreamplug_ge01_data);
- kirkwood_sata_init(&dreamplug_sata_data);
kirkwood_sdio_init(&dreamplug_mvsdio_data);
platform_device_register(&dreamplug_leds);
diff --git a/arch/arm/mach-kirkwood/board-ib62x0.c b/arch/arm/mach-kirkwood/board-ib62x0.c
index eddf1df..56d198e 100644
--- a/arch/arm/mach-kirkwood/board-ib62x0.c
+++ b/arch/arm/mach-kirkwood/board-ib62x0.c
@@ -33,10 +33,6 @@ static struct mv643xx_eth_platform_data ib62x0_ge00_data = {
.phy_addr = MV643XX_ETH_PHY_ADDR(8),
};
-static struct mv_sata_platform_data ib62x0_sata_data = {
- .n_ports = 2,
-};
-
static unsigned int ib62x0_mpp_config[] __initdata = {
MPP0_NF_IO2,
MPP1_NF_IO3,
@@ -132,7 +128,6 @@ void __init ib62x0_init(void)
kirkwood_ehci_init();
kirkwood_ge00_init(&ib62x0_ge00_data);
- kirkwood_sata_init(&ib62x0_sata_data);
platform_device_register(&ib62x0_led_device);
platform_device_register(&ib62x0_button_device);
if (gpio_request(IB62X0_GPIO_POWER_OFF, "ib62x0:power:off") == 0 &&
diff --git a/arch/arm/mach-kirkwood/board-ts219.c b/arch/arm/mach-kirkwood/board-ts219.c
index 00b79ea..1750e68 100644
--- a/arch/arm/mach-kirkwood/board-ts219.c
+++ b/arch/arm/mach-kirkwood/board-ts219.c
@@ -33,10 +33,6 @@ static struct mv643xx_eth_platform_data qnap_ts219_ge00_data = {
.phy_addr = MV643XX_ETH_PHY_ADDR(8),
};
-static struct mv_sata_platform_data qnap_ts219_sata_data = {
- .n_ports = 2,
-};
-
static unsigned int qnap_ts219_mpp_config[] __initdata = {
MPP0_SPI_SCn,
MPP1_SPI_MOSI,
@@ -70,7 +66,6 @@ void __init qnap_dt_ts219_init(void)
qnap_ts219_ge00_data.phy_addr = MV643XX_ETH_PHY_ADDR(0);
kirkwood_ge00_init(&qnap_ts219_ge00_data);
- kirkwood_sata_init(&qnap_ts219_sata_data);
kirkwood_ehci_init();
pm_power_off = qnap_tsx1x_power_off;
--
1.7.10
^ permalink raw reply related [flat|nested] 130+ messages in thread* [PATCH v2 11/12] ARM: Kirkwood: Use DT to configure SATA device.
@ 2012-07-03 14:22 ` Andrew Lunn
0 siblings, 0 replies; 130+ messages in thread
From: Andrew Lunn @ 2012-07-03 14:22 UTC (permalink / raw)
To: linux-arm-kernel
Convert boards using DT, but the old way of configuring SATA to now
use properties in there DT file.
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
---
arch/arm/boot/dts/kirkwood-dns320.dts | 5 +++++
arch/arm/boot/dts/kirkwood-dns325.dts | 5 +++++
arch/arm/boot/dts/kirkwood-dreamplug.dts | 5 +++++
arch/arm/boot/dts/kirkwood-ib62x0.dts | 5 +++++
arch/arm/boot/dts/kirkwood-ts219.dtsi | 4 ++++
arch/arm/mach-kirkwood/board-dnskw.c | 5 -----
arch/arm/mach-kirkwood/board-dreamplug.c | 5 -----
arch/arm/mach-kirkwood/board-ib62x0.c | 5 -----
arch/arm/mach-kirkwood/board-ts219.c | 5 -----
9 files changed, 24 insertions(+), 20 deletions(-)
diff --git a/arch/arm/boot/dts/kirkwood-dns320.dts b/arch/arm/boot/dts/kirkwood-dns320.dts
index dc09a73..f2a9808 100644
--- a/arch/arm/boot/dts/kirkwood-dns320.dts
+++ b/arch/arm/boot/dts/kirkwood-dns320.dts
@@ -26,6 +26,11 @@
status = "okay";
};
+ sata at 80000 {
+ status = "okay";
+ nr-ports = <2>;
+ };
+
nand at 3000000 {
status = "okay";
diff --git a/arch/arm/boot/dts/kirkwood-dns325.dts b/arch/arm/boot/dts/kirkwood-dns325.dts
index c2a5562..10bc819 100644
--- a/arch/arm/boot/dts/kirkwood-dns325.dts
+++ b/arch/arm/boot/dts/kirkwood-dns325.dts
@@ -21,6 +21,11 @@
status = "okay";
};
+ sata at 80000 {
+ status = "okay";
+ nr-ports = <2>;
+ };
+
nand at 3000000 {
status = "okay";
diff --git a/arch/arm/boot/dts/kirkwood-dreamplug.dts b/arch/arm/boot/dts/kirkwood-dreamplug.dts
index d74d1ae..24de2b5 100644
--- a/arch/arm/boot/dts/kirkwood-dreamplug.dts
+++ b/arch/arm/boot/dts/kirkwood-dreamplug.dts
@@ -48,6 +48,11 @@
};
};
};
+
+ sata at 80000 {
+ status = "okay";
+ nr-ports = <1>;
+ };
};
};
diff --git a/arch/arm/boot/dts/kirkwood-ib62x0.dts b/arch/arm/boot/dts/kirkwood-ib62x0.dts
index ada0f0c..f8e2bc6 100644
--- a/arch/arm/boot/dts/kirkwood-ib62x0.dts
+++ b/arch/arm/boot/dts/kirkwood-ib62x0.dts
@@ -21,6 +21,11 @@
status = "okay";
};
+ sata at 80000 {
+ status = "okay";
+ nr-ports = <2>;
+ };
+
nand at 3000000 {
status = "okay";
diff --git a/arch/arm/boot/dts/kirkwood-ts219.dtsi b/arch/arm/boot/dts/kirkwood-ts219.dtsi
index e0520c3..9b4ee7d 100644
--- a/arch/arm/boot/dts/kirkwood-ts219.dtsi
+++ b/arch/arm/boot/dts/kirkwood-ts219.dtsi
@@ -69,5 +69,9 @@
};
};
};
+ sata at 80000 {
+ status = "okay";
+ nr-ports = <2>;
+ };
};
};
diff --git a/arch/arm/mach-kirkwood/board-dnskw.c b/arch/arm/mach-kirkwood/board-dnskw.c
index 58c2d68..179f4b3 100644
--- a/arch/arm/mach-kirkwood/board-dnskw.c
+++ b/arch/arm/mach-kirkwood/board-dnskw.c
@@ -35,10 +35,6 @@ static struct mv643xx_eth_platform_data dnskw_ge00_data = {
.phy_addr = MV643XX_ETH_PHY_ADDR(8),
};
-static struct mv_sata_platform_data dnskw_sata_data = {
- .n_ports = 2,
-};
-
static unsigned int dnskw_mpp_config[] __initdata = {
MPP13_UART1_TXD, /* Custom ... */
MPP14_UART1_RXD, /* ... Controller (DNS-320 only) */
@@ -245,7 +241,6 @@ void __init dnskw_init(void)
kirkwood_ehci_init();
kirkwood_ge00_init(&dnskw_ge00_data);
- kirkwood_sata_init(&dnskw_sata_data);
kirkwood_i2c_init();
platform_device_register(&dnskw_button_device);
diff --git a/arch/arm/mach-kirkwood/board-dreamplug.c b/arch/arm/mach-kirkwood/board-dreamplug.c
index eb0e4d5..e494393 100644
--- a/arch/arm/mach-kirkwood/board-dreamplug.c
+++ b/arch/arm/mach-kirkwood/board-dreamplug.c
@@ -43,10 +43,6 @@ static struct mv643xx_eth_platform_data dreamplug_ge01_data = {
.phy_addr = MV643XX_ETH_PHY_ADDR(1),
};
-static struct mv_sata_platform_data dreamplug_sata_data = {
- .n_ports = 1,
-};
-
static struct mvsdio_platform_data dreamplug_mvsdio_data = {
/* unfortunately the CD signal has not been connected */
};
@@ -103,7 +99,6 @@ void __init dreamplug_init(void)
kirkwood_ehci_init();
kirkwood_ge00_init(&dreamplug_ge00_data);
kirkwood_ge01_init(&dreamplug_ge01_data);
- kirkwood_sata_init(&dreamplug_sata_data);
kirkwood_sdio_init(&dreamplug_mvsdio_data);
platform_device_register(&dreamplug_leds);
diff --git a/arch/arm/mach-kirkwood/board-ib62x0.c b/arch/arm/mach-kirkwood/board-ib62x0.c
index eddf1df..56d198e 100644
--- a/arch/arm/mach-kirkwood/board-ib62x0.c
+++ b/arch/arm/mach-kirkwood/board-ib62x0.c
@@ -33,10 +33,6 @@ static struct mv643xx_eth_platform_data ib62x0_ge00_data = {
.phy_addr = MV643XX_ETH_PHY_ADDR(8),
};
-static struct mv_sata_platform_data ib62x0_sata_data = {
- .n_ports = 2,
-};
-
static unsigned int ib62x0_mpp_config[] __initdata = {
MPP0_NF_IO2,
MPP1_NF_IO3,
@@ -132,7 +128,6 @@ void __init ib62x0_init(void)
kirkwood_ehci_init();
kirkwood_ge00_init(&ib62x0_ge00_data);
- kirkwood_sata_init(&ib62x0_sata_data);
platform_device_register(&ib62x0_led_device);
platform_device_register(&ib62x0_button_device);
if (gpio_request(IB62X0_GPIO_POWER_OFF, "ib62x0:power:off") == 0 &&
diff --git a/arch/arm/mach-kirkwood/board-ts219.c b/arch/arm/mach-kirkwood/board-ts219.c
index 00b79ea..1750e68 100644
--- a/arch/arm/mach-kirkwood/board-ts219.c
+++ b/arch/arm/mach-kirkwood/board-ts219.c
@@ -33,10 +33,6 @@ static struct mv643xx_eth_platform_data qnap_ts219_ge00_data = {
.phy_addr = MV643XX_ETH_PHY_ADDR(8),
};
-static struct mv_sata_platform_data qnap_ts219_sata_data = {
- .n_ports = 2,
-};
-
static unsigned int qnap_ts219_mpp_config[] __initdata = {
MPP0_SPI_SCn,
MPP1_SPI_MOSI,
@@ -70,7 +66,6 @@ void __init qnap_dt_ts219_init(void)
qnap_ts219_ge00_data.phy_addr = MV643XX_ETH_PHY_ADDR(0);
kirkwood_ge00_init(&qnap_ts219_ge00_data);
- kirkwood_sata_init(&qnap_ts219_sata_data);
kirkwood_ehci_init();
pm_power_off = qnap_tsx1x_power_off;
--
1.7.10
^ permalink raw reply related [flat|nested] 130+ messages in thread[parent not found: <1341325365-21393-12-git-send-email-andrew-g2DYL2Zd6BY@public.gmane.org>]
* Re: [PATCH v2 11/12] ARM: Kirkwood: Use DT to configure SATA device.
2012-07-03 14:22 ` Andrew Lunn
@ 2012-07-03 14:52 ` Josh Coombs
-1 siblings, 0 replies; 130+ messages in thread
From: Josh Coombs @ 2012-07-03 14:52 UTC (permalink / raw)
To: Andrew Lunn
Cc: Jason Cooper, devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
rob.herring-bsGFqQB8/DxBDgjK7y7TUQ,
grant.likely-s3s/WqlpOiPyB63q8FvJNQ, Michael Walle,
linux-i2c-u79uwXL29TY76Z2rM5mHXA,
spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
On Tue, Jul 3, 2012 at 10:22 AM, Andrew Lunn <andrew-g2DYL2Zd6BY@public.gmane.org> wrote:
> Convert boards using DT, but the old way of configuring SATA to now
> use properties in there DT file.
Andrew, should I be updating my GoFlex patch set to work with these
new Kirkwood DT abstractions, and if so is there a specific tree you'd
prefer I work against, or should I wait to see if my existing patch
set is approved as is and update with a new patch once these updates
land in an RC?
Josh Coombs
^ permalink raw reply [flat|nested] 130+ messages in thread
* [PATCH v2 11/12] ARM: Kirkwood: Use DT to configure SATA device.
@ 2012-07-03 14:52 ` Josh Coombs
0 siblings, 0 replies; 130+ messages in thread
From: Josh Coombs @ 2012-07-03 14:52 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Jul 3, 2012 at 10:22 AM, Andrew Lunn <andrew@lunn.ch> wrote:
> Convert boards using DT, but the old way of configuring SATA to now
> use properties in there DT file.
Andrew, should I be updating my GoFlex patch set to work with these
new Kirkwood DT abstractions, and if so is there a specific tree you'd
prefer I work against, or should I wait to see if my existing patch
set is approved as is and update with a new patch once these updates
land in an RC?
Josh Coombs
^ permalink raw reply [flat|nested] 130+ messages in thread
[parent not found: <CAMW5Ufa2bsYs9VD2g9hJWKpcQNcZt+WXCA1ohYoHeLk9SambSg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>]
* Re: [PATCH v2 11/12] ARM: Kirkwood: Use DT to configure SATA device.
2012-07-03 14:52 ` Josh Coombs
@ 2012-07-03 15:32 ` Andrew Lunn
-1 siblings, 0 replies; 130+ messages in thread
From: Andrew Lunn @ 2012-07-03 15:32 UTC (permalink / raw)
To: Josh Coombs
Cc: Andrew Lunn, Jason Cooper,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
rob.herring-bsGFqQB8/DxBDgjK7y7TUQ,
linux-i2c-u79uwXL29TY76Z2rM5mHXA,
spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
On Tue, Jul 03, 2012 at 10:52:17AM -0400, Josh Coombs wrote:
> On Tue, Jul 3, 2012 at 10:22 AM, Andrew Lunn <andrew-g2DYL2Zd6BY@public.gmane.org> wrote:
> > Convert boards using DT, but the old way of configuring SATA to now
> > use properties in there DT file.
>
> Andrew, should I be updating my GoFlex patch set to work with these
> new Kirkwood DT abstractions, and if so is there a specific tree you'd
> prefer I work against, or should I wait to see if my existing patch
> set is approved as is and update with a new patch once these updates
> land in an RC?
Hi Josh
I would suggest waiting for a day or two. The IRQ and GPIO patch may
cause comments and require more work. Unfortunately, without that
patch, the rest are pretty useless, since they use IRQs in DT.
If there are no show stoppers, Jason has a for-next tree which these
patches should get pulled into, and others can use as a basis.
Andrew
^ permalink raw reply [flat|nested] 130+ messages in thread
* [PATCH v2 11/12] ARM: Kirkwood: Use DT to configure SATA device.
@ 2012-07-03 15:32 ` Andrew Lunn
0 siblings, 0 replies; 130+ messages in thread
From: Andrew Lunn @ 2012-07-03 15:32 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Jul 03, 2012 at 10:52:17AM -0400, Josh Coombs wrote:
> On Tue, Jul 3, 2012 at 10:22 AM, Andrew Lunn <andrew@lunn.ch> wrote:
> > Convert boards using DT, but the old way of configuring SATA to now
> > use properties in there DT file.
>
> Andrew, should I be updating my GoFlex patch set to work with these
> new Kirkwood DT abstractions, and if so is there a specific tree you'd
> prefer I work against, or should I wait to see if my existing patch
> set is approved as is and update with a new patch once these updates
> land in an RC?
Hi Josh
I would suggest waiting for a day or two. The IRQ and GPIO patch may
cause comments and require more work. Unfortunately, without that
patch, the rest are pretty useless, since they use IRQs in DT.
If there are no show stoppers, Jason has a for-next tree which these
patches should get pulled into, and others can use as a basis.
Andrew
^ permalink raw reply [flat|nested] 130+ messages in thread
* [PATCH v2 12/12] Crypto: CESA: Add support for DT based instantiation.
2012-07-03 14:22 ` Andrew Lunn
@ 2012-07-03 14:22 ` Andrew Lunn
-1 siblings, 0 replies; 130+ messages in thread
From: Andrew Lunn @ 2012-07-03 14:22 UTC (permalink / raw)
To: Jason Cooper
Cc: Andrew Lunn, devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
rob.herring-bsGFqQB8/DxBDgjK7y7TUQ, Michael Walle,
linux-i2c-u79uwXL29TY76Z2rM5mHXA,
spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Based on work by Michael Waller and Jason Cooper.
Added support for getting the interrupt number from DT.
Signed-off-by: Andrew Lunn <andrew-g2DYL2Zd6BY@public.gmane.org>
---
.../devicetree/bindings/crypto/mv_cesa.txt | 18 ++++++++++++
drivers/crypto/mv_cesa.c | 31 +++++++++++++++++---
2 files changed, 45 insertions(+), 4 deletions(-)
create mode 100644 Documentation/devicetree/bindings/crypto/mv_cesa.txt
diff --git a/Documentation/devicetree/bindings/crypto/mv_cesa.txt b/Documentation/devicetree/bindings/crypto/mv_cesa.txt
new file mode 100644
index 0000000..f191122
--- /dev/null
+++ b/Documentation/devicetree/bindings/crypto/mv_cesa.txt
@@ -0,0 +1,18 @@
+Marvell Cryptographic Engines And Security Accelerator
+
+Required properties:
+- compatible : should be "mrvl,orion-crypto"
+- reg : base physical address of the engine and length of memory mapped
+ region, followed by base physical address of sram and its memory
+ length
+- interrupts : interrupt number
+
+Examples:
+
+crypto@f1030000 {
+ compatible = "mrvl,orion-crypto";
+ reg = <0xf1030000 0x10000
+ 0xf5000000 0x800>; /* sram */
+ interrupts = <22>;
+};
+
diff --git a/drivers/crypto/mv_cesa.c b/drivers/crypto/mv_cesa.c
index 1cc6b3f..964c4c5 100644
--- a/drivers/crypto/mv_cesa.c
+++ b/drivers/crypto/mv_cesa.c
@@ -19,6 +19,9 @@
#include <linux/clk.h>
#include <crypto/internal/hash.h>
#include <crypto/sha.h>
+#include <linux/of.h>
+#include <linux/of_platform.h>
+#include <linux/of_irq.h>
#include "mv_cesa.h"
@@ -1005,7 +1008,11 @@ static int mv_probe(struct platform_device *pdev)
return -EEXIST;
}
- res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "regs");
+ if (pdev->dev.of_node)
+ res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
+ "regs");
+ else
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (!res)
return -ENXIO;
@@ -1021,7 +1028,11 @@ static int mv_probe(struct platform_device *pdev)
goto err;
}
- res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "sram");
+ if (pdev->dev.of_node)
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
+ else
+ res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
+ "sram");
if (!res) {
ret = -ENXIO;
goto err_unmap_reg;
@@ -1034,7 +1045,10 @@ static int mv_probe(struct platform_device *pdev)
goto err_unmap_reg;
}
- irq = platform_get_irq(pdev, 0);
+ if (pdev->dev.of_node)
+ irq = irq_of_parse_and_map(pdev->dev.of_node, 0);
+ else
+ irq = platform_get_irq(pdev, 0);
if (irq < 0 || irq == NO_IRQ) {
ret = irq;
goto err_unmap_sram;
@@ -1137,12 +1151,21 @@ static int mv_remove(struct platform_device *pdev)
return 0;
}
+#ifdef CONFIG_OF
+static const struct of_device_id mv_cesa_of_match_table[] __devinitdata = {
+ { .compatible = "marvell,orion-crypto", },
+ {},
+};
+MODULE_DEVICE_TABLE(of, mv_cesa_of_match_table);
+#endif
+
static struct platform_driver marvell_crypto = {
.probe = mv_probe,
- .remove = mv_remove,
+ .remove = __devexit_p(mv_remove),
.driver = {
.owner = THIS_MODULE,
.name = "mv_crypto",
+ .of_match_table = of_match_ptr(mv_cesa_of_match_table),
},
};
MODULE_ALIAS("platform:mv_crypto");
--
1.7.10
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
^ permalink raw reply related [flat|nested] 130+ messages in thread* [PATCH v2 12/12] Crypto: CESA: Add support for DT based instantiation.
@ 2012-07-03 14:22 ` Andrew Lunn
0 siblings, 0 replies; 130+ messages in thread
From: Andrew Lunn @ 2012-07-03 14:22 UTC (permalink / raw)
To: linux-arm-kernel
Based on work by Michael Waller and Jason Cooper.
Added support for getting the interrupt number from DT.
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
---
.../devicetree/bindings/crypto/mv_cesa.txt | 18 ++++++++++++
drivers/crypto/mv_cesa.c | 31 +++++++++++++++++---
2 files changed, 45 insertions(+), 4 deletions(-)
create mode 100644 Documentation/devicetree/bindings/crypto/mv_cesa.txt
diff --git a/Documentation/devicetree/bindings/crypto/mv_cesa.txt b/Documentation/devicetree/bindings/crypto/mv_cesa.txt
new file mode 100644
index 0000000..f191122
--- /dev/null
+++ b/Documentation/devicetree/bindings/crypto/mv_cesa.txt
@@ -0,0 +1,18 @@
+Marvell Cryptographic Engines And Security Accelerator
+
+Required properties:
+- compatible : should be "mrvl,orion-crypto"
+- reg : base physical address of the engine and length of memory mapped
+ region, followed by base physical address of sram and its memory
+ length
+- interrupts : interrupt number
+
+Examples:
+
+crypto at f1030000 {
+ compatible = "mrvl,orion-crypto";
+ reg = <0xf1030000 0x10000
+ 0xf5000000 0x800>; /* sram */
+ interrupts = <22>;
+};
+
diff --git a/drivers/crypto/mv_cesa.c b/drivers/crypto/mv_cesa.c
index 1cc6b3f..964c4c5 100644
--- a/drivers/crypto/mv_cesa.c
+++ b/drivers/crypto/mv_cesa.c
@@ -19,6 +19,9 @@
#include <linux/clk.h>
#include <crypto/internal/hash.h>
#include <crypto/sha.h>
+#include <linux/of.h>
+#include <linux/of_platform.h>
+#include <linux/of_irq.h>
#include "mv_cesa.h"
@@ -1005,7 +1008,11 @@ static int mv_probe(struct platform_device *pdev)
return -EEXIST;
}
- res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "regs");
+ if (pdev->dev.of_node)
+ res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
+ "regs");
+ else
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (!res)
return -ENXIO;
@@ -1021,7 +1028,11 @@ static int mv_probe(struct platform_device *pdev)
goto err;
}
- res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "sram");
+ if (pdev->dev.of_node)
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
+ else
+ res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
+ "sram");
if (!res) {
ret = -ENXIO;
goto err_unmap_reg;
@@ -1034,7 +1045,10 @@ static int mv_probe(struct platform_device *pdev)
goto err_unmap_reg;
}
- irq = platform_get_irq(pdev, 0);
+ if (pdev->dev.of_node)
+ irq = irq_of_parse_and_map(pdev->dev.of_node, 0);
+ else
+ irq = platform_get_irq(pdev, 0);
if (irq < 0 || irq == NO_IRQ) {
ret = irq;
goto err_unmap_sram;
@@ -1137,12 +1151,21 @@ static int mv_remove(struct platform_device *pdev)
return 0;
}
+#ifdef CONFIG_OF
+static const struct of_device_id mv_cesa_of_match_table[] __devinitdata = {
+ { .compatible = "marvell,orion-crypto", },
+ {},
+};
+MODULE_DEVICE_TABLE(of, mv_cesa_of_match_table);
+#endif
+
static struct platform_driver marvell_crypto = {
.probe = mv_probe,
- .remove = mv_remove,
+ .remove = __devexit_p(mv_remove),
.driver = {
.owner = THIS_MODULE,
.name = "mv_crypto",
+ .of_match_table = of_match_ptr(mv_cesa_of_match_table),
},
};
MODULE_ALIAS("platform:mv_crypto");
--
1.7.10
^ permalink raw reply related [flat|nested] 130+ messages in thread[parent not found: <1341325365-21393-13-git-send-email-andrew-g2DYL2Zd6BY@public.gmane.org>]
* Re: [PATCH v2 12/12] Crypto: CESA: Add support for DT based instantiation.
2012-07-03 14:22 ` Andrew Lunn
@ 2012-07-03 15:50 ` Florian Fainelli
-1 siblings, 0 replies; 130+ messages in thread
From: Florian Fainelli @ 2012-07-03 15:50 UTC (permalink / raw)
To: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Cc: Andrew Lunn, Jason Cooper,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
rob.herring-bsGFqQB8/DxBDgjK7y7TUQ,
grant.likely-s3s/WqlpOiPyB63q8FvJNQ, Michael Walle,
linux-i2c-u79uwXL29TY76Z2rM5mHXA,
spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
Hello Andrew,
On Tuesday 03 July 2012 16:22:45 Andrew Lunn wrote:
> Based on work by Michael Waller and Jason Cooper.
>
> Added support for getting the interrupt number from DT.
>
> Signed-off-by: Andrew Lunn <andrew-g2DYL2Zd6BY@public.gmane.org>
> ---
> .../devicetree/bindings/crypto/mv_cesa.txt | 18 ++++++++++++
> drivers/crypto/mv_cesa.c | 31
+++++++++++++++++---
> 2 files changed, 45 insertions(+), 4 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/crypto/mv_cesa.txt
>
> diff --git a/Documentation/devicetree/bindings/crypto/mv_cesa.txt
b/Documentation/devicetree/bindings/crypto/mv_cesa.txt
> new file mode 100644
> index 0000000..f191122
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/crypto/mv_cesa.txt
> @@ -0,0 +1,18 @@
> +Marvell Cryptographic Engines And Security Accelerator
> +
> +Required properties:
> +- compatible : should be "mrvl,orion-crypto"
You mention "mvrl" here, but the rest of your series uses "marvell", and this
is also what you use as a match table later in the driver, this looks like a
left-over from your previous submission.
> +- reg : base physical address of the engine and length of memory mapped
> + region, followed by base physical address of sram and its memory
> + length
> +- interrupts : interrupt number
> +
> +Examples:
> +
> +crypto@f1030000 {
> + compatible = "mrvl,orion-crypto";
> + reg = <0xf1030000 0x10000
> + 0xf5000000 0x800>; /* sram */
> + interrupts = <22>;
> +};
> +
> diff --git a/drivers/crypto/mv_cesa.c b/drivers/crypto/mv_cesa.c
> index 1cc6b3f..964c4c5 100644
> --- a/drivers/crypto/mv_cesa.c
> +++ b/drivers/crypto/mv_cesa.c
> @@ -19,6 +19,9 @@
> #include <linux/clk.h>
> #include <crypto/internal/hash.h>
> #include <crypto/sha.h>
> +#include <linux/of.h>
> +#include <linux/of_platform.h>
> +#include <linux/of_irq.h>
>
> #include "mv_cesa.h"
>
> @@ -1005,7 +1008,11 @@ static int mv_probe(struct platform_device *pdev)
> return -EEXIST;
> }
>
> - res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "regs");
> + if (pdev->dev.of_node)
> + res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
> + "regs");
> + else
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
If you add a reg-names property, which respects the ordering of the reg
property, you don't need this.
> if (!res)
> return -ENXIO;
>
> @@ -1021,7 +1028,11 @@ static int mv_probe(struct platform_device *pdev)
> goto err;
> }
>
> - res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "sram");
> + if (pdev->dev.of_node)
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
> + else
> + res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
> + "sram");
ditto
> if (!res) {
> ret = -ENXIO;
> goto err_unmap_reg;
> @@ -1034,7 +1045,10 @@ static int mv_probe(struct platform_device *pdev)
> goto err_unmap_reg;
> }
>
> - irq = platform_get_irq(pdev, 0);
> + if (pdev->dev.of_node)
> + irq = irq_of_parse_and_map(pdev->dev.of_node, 0);
> + else
> + irq = platform_get_irq(pdev, 0);
> if (irq < 0 || irq == NO_IRQ) {
> ret = irq;
> goto err_unmap_sram;
> @@ -1137,12 +1151,21 @@ static int mv_remove(struct platform_device *pdev)
> return 0;
> }
>
> +#ifdef CONFIG_OF
> +static const struct of_device_id mv_cesa_of_match_table[] __devinitdata = {
> + { .compatible = "marvell,orion-crypto", },
> + {},
> +};
> +MODULE_DEVICE_TABLE(of, mv_cesa_of_match_table);
> +#endif
> +
> static struct platform_driver marvell_crypto = {
> .probe = mv_probe,
> - .remove = mv_remove,
> + .remove = __devexit_p(mv_remove),
> .driver = {
> .owner = THIS_MODULE,
> .name = "mv_crypto",
> + .of_match_table = of_match_ptr(mv_cesa_of_match_table),
> },
> };
> MODULE_ALIAS("platform:mv_crypto");
> --
> 1.7.10
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 130+ messages in thread* [PATCH v2 12/12] Crypto: CESA: Add support for DT based instantiation.
@ 2012-07-03 15:50 ` Florian Fainelli
0 siblings, 0 replies; 130+ messages in thread
From: Florian Fainelli @ 2012-07-03 15:50 UTC (permalink / raw)
To: linux-arm-kernel
Hello Andrew,
On Tuesday 03 July 2012 16:22:45 Andrew Lunn wrote:
> Based on work by Michael Waller and Jason Cooper.
>
> Added support for getting the interrupt number from DT.
>
> Signed-off-by: Andrew Lunn <andrew@lunn.ch>
> ---
> .../devicetree/bindings/crypto/mv_cesa.txt | 18 ++++++++++++
> drivers/crypto/mv_cesa.c | 31
+++++++++++++++++---
> 2 files changed, 45 insertions(+), 4 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/crypto/mv_cesa.txt
>
> diff --git a/Documentation/devicetree/bindings/crypto/mv_cesa.txt
b/Documentation/devicetree/bindings/crypto/mv_cesa.txt
> new file mode 100644
> index 0000000..f191122
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/crypto/mv_cesa.txt
> @@ -0,0 +1,18 @@
> +Marvell Cryptographic Engines And Security Accelerator
> +
> +Required properties:
> +- compatible : should be "mrvl,orion-crypto"
You mention "mvrl" here, but the rest of your series uses "marvell", and this
is also what you use as a match table later in the driver, this looks like a
left-over from your previous submission.
> +- reg : base physical address of the engine and length of memory mapped
> + region, followed by base physical address of sram and its memory
> + length
> +- interrupts : interrupt number
> +
> +Examples:
> +
> +crypto at f1030000 {
> + compatible = "mrvl,orion-crypto";
> + reg = <0xf1030000 0x10000
> + 0xf5000000 0x800>; /* sram */
> + interrupts = <22>;
> +};
> +
> diff --git a/drivers/crypto/mv_cesa.c b/drivers/crypto/mv_cesa.c
> index 1cc6b3f..964c4c5 100644
> --- a/drivers/crypto/mv_cesa.c
> +++ b/drivers/crypto/mv_cesa.c
> @@ -19,6 +19,9 @@
> #include <linux/clk.h>
> #include <crypto/internal/hash.h>
> #include <crypto/sha.h>
> +#include <linux/of.h>
> +#include <linux/of_platform.h>
> +#include <linux/of_irq.h>
>
> #include "mv_cesa.h"
>
> @@ -1005,7 +1008,11 @@ static int mv_probe(struct platform_device *pdev)
> return -EEXIST;
> }
>
> - res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "regs");
> + if (pdev->dev.of_node)
> + res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
> + "regs");
> + else
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
If you add a reg-names property, which respects the ordering of the reg
property, you don't need this.
> if (!res)
> return -ENXIO;
>
> @@ -1021,7 +1028,11 @@ static int mv_probe(struct platform_device *pdev)
> goto err;
> }
>
> - res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "sram");
> + if (pdev->dev.of_node)
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
> + else
> + res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
> + "sram");
ditto
> if (!res) {
> ret = -ENXIO;
> goto err_unmap_reg;
> @@ -1034,7 +1045,10 @@ static int mv_probe(struct platform_device *pdev)
> goto err_unmap_reg;
> }
>
> - irq = platform_get_irq(pdev, 0);
> + if (pdev->dev.of_node)
> + irq = irq_of_parse_and_map(pdev->dev.of_node, 0);
> + else
> + irq = platform_get_irq(pdev, 0);
> if (irq < 0 || irq == NO_IRQ) {
> ret = irq;
> goto err_unmap_sram;
> @@ -1137,12 +1151,21 @@ static int mv_remove(struct platform_device *pdev)
> return 0;
> }
>
> +#ifdef CONFIG_OF
> +static const struct of_device_id mv_cesa_of_match_table[] __devinitdata = {
> + { .compatible = "marvell,orion-crypto", },
> + {},
> +};
> +MODULE_DEVICE_TABLE(of, mv_cesa_of_match_table);
> +#endif
> +
> static struct platform_driver marvell_crypto = {
> .probe = mv_probe,
> - .remove = mv_remove,
> + .remove = __devexit_p(mv_remove),
> .driver = {
> .owner = THIS_MODULE,
> .name = "mv_crypto",
> + .of_match_table = of_match_ptr(mv_cesa_of_match_table),
> },
> };
> MODULE_ALIAS("platform:mv_crypto");
> --
> 1.7.10
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 130+ messages in thread* Re: [PATCH v2 12/12] Crypto: CESA: Add support for DT based instantiation.
2012-07-03 15:50 ` Florian Fainelli
@ 2012-07-03 17:03 ` Andrew Lunn
-1 siblings, 0 replies; 130+ messages in thread
From: Andrew Lunn @ 2012-07-03 17:03 UTC (permalink / raw)
To: Florian Fainelli
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Andrew Lunn,
Jason Cooper, devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
rob.herring-bsGFqQB8/DxBDgjK7y7TUQ,
grant.likely-s3s/WqlpOiPyB63q8FvJNQ, Michael Walle,
linux-i2c-u79uwXL29TY76Z2rM5mHXA,
spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
On Tue, Jul 03, 2012 at 05:50:02PM +0200, Florian Fainelli wrote:
> Hello Andrew,
>
> On Tuesday 03 July 2012 16:22:45 Andrew Lunn wrote:
> > Based on work by Michael Waller and Jason Cooper.
> >
> > Added support for getting the interrupt number from DT.
> >
> > Signed-off-by: Andrew Lunn <andrew-g2DYL2Zd6BY@public.gmane.org>
> > ---
> > .../devicetree/bindings/crypto/mv_cesa.txt | 18 ++++++++++++
> > drivers/crypto/mv_cesa.c | 31
> +++++++++++++++++---
> > 2 files changed, 45 insertions(+), 4 deletions(-)
> > create mode 100644 Documentation/devicetree/bindings/crypto/mv_cesa.txt
> >
> > diff --git a/Documentation/devicetree/bindings/crypto/mv_cesa.txt
> b/Documentation/devicetree/bindings/crypto/mv_cesa.txt
> > new file mode 100644
> > index 0000000..f191122
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/crypto/mv_cesa.txt
> > @@ -0,0 +1,18 @@
> > +Marvell Cryptographic Engines And Security Accelerator
> > +
> > +Required properties:
> > +- compatible : should be "mrvl,orion-crypto"
>
> You mention "mvrl" here, but the rest of your series uses "marvell", and this
> is also what you use as a match table later in the driver, this looks like a
> left-over from your previous submission.
Correct. I will fix this.
>
> > +- reg : base physical address of the engine and length of memory mapped
> > + region, followed by base physical address of sram and its memory
> > + length
> > +- interrupts : interrupt number
> > +
> > +Examples:
> > +
> > +crypto@f1030000 {
> > + compatible = "mrvl,orion-crypto";
> > + reg = <0xf1030000 0x10000
> > + 0xf5000000 0x800>; /* sram */
> > + interrupts = <22>;
> > +};
> > +
> > diff --git a/drivers/crypto/mv_cesa.c b/drivers/crypto/mv_cesa.c
> > index 1cc6b3f..964c4c5 100644
> > --- a/drivers/crypto/mv_cesa.c
> > +++ b/drivers/crypto/mv_cesa.c
> > @@ -19,6 +19,9 @@
> > #include <linux/clk.h>
> > #include <crypto/internal/hash.h>
> > #include <crypto/sha.h>
> > +#include <linux/of.h>
> > +#include <linux/of_platform.h>
> > +#include <linux/of_irq.h>
> >
> > #include "mv_cesa.h"
> >
> > @@ -1005,7 +1008,11 @@ static int mv_probe(struct platform_device *pdev)
> > return -EEXIST;
> > }
> >
> > - res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "regs");
> > + if (pdev->dev.of_node)
> > + res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
> > + "regs");
> > + else
> > + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>
> If you add a reg-names property, which respects the ordering of the reg
> property, you don't need this.
Ah, thanks for the tip.
Andrew
^ permalink raw reply [flat|nested] 130+ messages in thread* [PATCH v2 12/12] Crypto: CESA: Add support for DT based instantiation.
@ 2012-07-03 17:03 ` Andrew Lunn
0 siblings, 0 replies; 130+ messages in thread
From: Andrew Lunn @ 2012-07-03 17:03 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Jul 03, 2012 at 05:50:02PM +0200, Florian Fainelli wrote:
> Hello Andrew,
>
> On Tuesday 03 July 2012 16:22:45 Andrew Lunn wrote:
> > Based on work by Michael Waller and Jason Cooper.
> >
> > Added support for getting the interrupt number from DT.
> >
> > Signed-off-by: Andrew Lunn <andrew@lunn.ch>
> > ---
> > .../devicetree/bindings/crypto/mv_cesa.txt | 18 ++++++++++++
> > drivers/crypto/mv_cesa.c | 31
> +++++++++++++++++---
> > 2 files changed, 45 insertions(+), 4 deletions(-)
> > create mode 100644 Documentation/devicetree/bindings/crypto/mv_cesa.txt
> >
> > diff --git a/Documentation/devicetree/bindings/crypto/mv_cesa.txt
> b/Documentation/devicetree/bindings/crypto/mv_cesa.txt
> > new file mode 100644
> > index 0000000..f191122
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/crypto/mv_cesa.txt
> > @@ -0,0 +1,18 @@
> > +Marvell Cryptographic Engines And Security Accelerator
> > +
> > +Required properties:
> > +- compatible : should be "mrvl,orion-crypto"
>
> You mention "mvrl" here, but the rest of your series uses "marvell", and this
> is also what you use as a match table later in the driver, this looks like a
> left-over from your previous submission.
Correct. I will fix this.
>
> > +- reg : base physical address of the engine and length of memory mapped
> > + region, followed by base physical address of sram and its memory
> > + length
> > +- interrupts : interrupt number
> > +
> > +Examples:
> > +
> > +crypto at f1030000 {
> > + compatible = "mrvl,orion-crypto";
> > + reg = <0xf1030000 0x10000
> > + 0xf5000000 0x800>; /* sram */
> > + interrupts = <22>;
> > +};
> > +
> > diff --git a/drivers/crypto/mv_cesa.c b/drivers/crypto/mv_cesa.c
> > index 1cc6b3f..964c4c5 100644
> > --- a/drivers/crypto/mv_cesa.c
> > +++ b/drivers/crypto/mv_cesa.c
> > @@ -19,6 +19,9 @@
> > #include <linux/clk.h>
> > #include <crypto/internal/hash.h>
> > #include <crypto/sha.h>
> > +#include <linux/of.h>
> > +#include <linux/of_platform.h>
> > +#include <linux/of_irq.h>
> >
> > #include "mv_cesa.h"
> >
> > @@ -1005,7 +1008,11 @@ static int mv_probe(struct platform_device *pdev)
> > return -EEXIST;
> > }
> >
> > - res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "regs");
> > + if (pdev->dev.of_node)
> > + res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
> > + "regs");
> > + else
> > + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>
> If you add a reg-names property, which respects the ordering of the reg
> property, you don't need this.
Ah, thanks for the tip.
Andrew
^ permalink raw reply [flat|nested] 130+ messages in thread