[PATCH v2 00/12] IRQ, GPIO SPI, I2C, etc DTC support

[PATCH v2 00/12] IRQ, GPIO SPI, I2C, etc DTC support

[Andrew Lunn]

This patch set adds Device Tree support for IRQ, GPIOm, SPI, I2C, ATA,
and crypto on Orion based drivers, and makes use of these for kirkwood
devices.  It also adds the ability to boot QNAP TS219 based systems
using device tree.

The SPI DT patches are from Michael Walle, and have been previously
posted. I've addressed the issues raised during the review.

The SPI refactor to use the SPI framework was submitted for merge into
3.5, but due to dependency issues, which are now resolved, the patch
was not accepted. This patch has been modified to remove two NOP
functions, which the SPI framework no longer needs.

v1 -> v2
--------

Changes since the last version are the reworking of the IRQ and GPIO
handling. It has been generalized and should now be applicable to all
Orion platforms. The irqdomain is still layered on top of IRQ generic
chip, since generic chip has not yet gained irqdomain support. The
GPIO interrupts are also handled using an IRQ generic chip, thus a
similar layering is made. This applies to both DT and none DT IRQ and
GPIO controllers.

White space problem as pointed out by Michael Walle have been
corrected.

Andrew Lunn (8):
  ARM: Orion: DT support for IRQ and GPIO Controllers
  SPI: Refactor spi-orion to use SPI framework queue.
  I2C: MV64XXX: Add Device Tree support
  Kirkwood: Add basic device tree support for QNAP TS219.
  ARM: Kirkwood: DTify the watchdog timer.
  ATA: sata_mv: Add device tree support
  ARM: Kirkwood: Use DT to configure SATA device.
  Crypto: CESA: Add support for DT based instantiation.

Michael Walle (4):
  spi-orion: remove uneeded spi_info
  spi-orion: add device tree binding
  ARM: kirkwood: use devicetree for orion-spi
  ARM: kirkwood: use devicetree for SPI on dreamplug

 .../devicetree/bindings/arm/mrvl/intc.txt          |   19 ++
 Documentation/devicetree/bindings/ata/marvell.txt  |   16 ++
 .../devicetree/bindings/crypto/mv_cesa.txt         |   18 ++
 .../devicetree/bindings/gpio/mrvl-gpio.txt         |   23 ++
 Documentation/devicetree/bindings/i2c/mrvl-i2c.txt |   32 ++-
 .../devicetree/bindings/spi/spi-orion.txt          |    5 +
 .../devicetree/bindings/watchdog/marvel.txt        |   14 ++
 arch/arm/Kconfig                                   |    1 +
 arch/arm/boot/dts/kirkwood-dns320.dts              |    5 +
 arch/arm/boot/dts/kirkwood-dns325.dts              |    5 +
 arch/arm/boot/dts/kirkwood-dreamplug.dts           |   34 +++
 arch/arm/boot/dts/kirkwood-ib62x0.dts              |    5 +
 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              |   77 +++++++
 arch/arm/boot/dts/kirkwood.dtsi                    |   62 ++++++
 arch/arm/mach-dove/irq.c                           |   58 ++---
 arch/arm/mach-kirkwood/Kconfig                     |   14 ++
 arch/arm/mach-kirkwood/Makefile                    |    1 +
 arch/arm/mach-kirkwood/Makefile.boot               |    1 +
 arch/arm/mach-kirkwood/board-dnskw.c               |    5 -
 arch/arm/mach-kirkwood/board-dreamplug.c           |   46 ----
 arch/arm/mach-kirkwood/board-dt.c                  |   20 +-
 arch/arm/mach-kirkwood/board-ib62x0.c              |    5 -
 arch/arm/mach-kirkwood/board-ts219.c               |   82 +++++++
 arch/arm/mach-kirkwood/common.h                    |    5 +
 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 ++++
 drivers/ata/sata_mv.c                              |   42 ++--
 drivers/crypto/mv_cesa.c                           |   31 ++-
 drivers/i2c/busses/i2c-mv64xxx.c                   |   38 +++-
 drivers/spi/spi-orion.c                            |  223 ++++++--------------
 drivers/watchdog/orion_wdt.c                       |    8 +
 38 files changed, 878 insertions(+), 366 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/ata/marvell.txt
 create mode 100644 Documentation/devicetree/bindings/crypto/mv_cesa.txt
 create mode 100644 Documentation/devicetree/bindings/spi/spi-orion.txt
 create mode 100644 Documentation/devicetree/bindings/watchdog/marvel.txt
 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

-- 
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/

[PATCH v2 01/12] ARM: Orion: DT support for IRQ and GPIO Controllers

[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

Re: [PATCH v2 01/12] ARM: Orion: DT support for IRQ and GPIO Controllers

[Thomas Petazzoni]

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

Re: [PATCH v2 01/12] ARM: Orion: DT support for IRQ and GPIO Controllers

[Andrew Lunn]

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

Re: [PATCH v2 01/12] ARM: Orion: DT support for IRQ and GPIO Controllers

[Arnaud Patard]

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

Re: [PATCH v2 01/12] ARM: Orion: DT support for IRQ and GPIO Controllers

[Thomas Petazzoni]

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

Re: [PATCH v2 01/12] ARM: Orion: DT support for IRQ and GPIO Controllers

[Arnaud Patard]

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

Re: [PATCH v2 01/12] ARM: Orion: DT support for IRQ and GPIO Controllers

[Thomas Petazzoni]

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

Re: [PATCH v2 01/12] ARM: Orion: DT support for IRQ and GPIO Controllers

[Andrew Lunn]

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

Re: [PATCH v2 01/12] ARM: Orion: DT support for IRQ and GPIO Controllers

[Sebastian Hesselbarth]

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

Re: [PATCH v2 01/12] ARM: Orion: DT support for IRQ and GPIO Controllers

[Thomas Petazzoni]

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

Re: [PATCH v2 01/12] ARM: Orion: DT support for IRQ and GPIO Controllers

[Andrew Lunn]

> 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

Re: [PATCH v2 01/12] ARM: Orion: DT support for IRQ and GPIO Controllers

[Thomas Petazzoni]

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

Re: [PATCH v2 01/12] ARM: Orion: DT support for IRQ and GPIO Controllers

[Andrew Lunn]

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

Re: [PATCH v2 01/12] ARM: Orion: DT support for IRQ and GPIO Controllers

[Thomas Petazzoni]

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

Re: [PATCH v2 01/12] ARM: Orion: DT support for IRQ and GPIO Controllers

[Arnd Bergmann]

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

Re: [PATCH v2 01/12] ARM: Orion: DT support for IRQ and GPIO Controllers

[Andrew Lunn]

> > +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

Re: [PATCH v2 01/12] ARM: Orion: DT support for IRQ and GPIO Controllers

[Arnd Bergmann]

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/

Re: [PATCH v2 01/12] ARM: Orion: DT support for IRQ and GPIO Controllers

[Sebastian Hesselbarth]

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

Re: [PATCH v2 01/12] ARM: Orion: DT support for IRQ and GPIO Controllers

[Andrew Lunn]

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

Re: [PATCH v2 01/12] ARM: Orion: DT support for IRQ and GPIO Controllers

[Arnd Bergmann]

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

Re: [PATCH v2 01/12] ARM: Orion: DT support for IRQ and GPIO Controllers

[Sebastian Hesselbarth]

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

Re: [PATCH v2 01/12] ARM: Orion: DT support for IRQ and GPIO Controllers

[Arnaud Patard]

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

Re: [PATCH v2 01/12] ARM: Orion: DT support for IRQ and GPIO Controllers

[Andrew Lunn]

> 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

Re: [PATCH v2 01/12] ARM: Orion: DT support for IRQ and GPIO Controllers

[Arnd Bergmann]

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

Re: [PATCH v2 01/12] ARM: Orion: DT support for IRQ and GPIO Controllers

[Andrew Lunn]

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

Re: [PATCH v2 01/12] ARM: Orion: DT support for IRQ and GPIO Controllers

[Mitch Bradley]

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
>

[PATCH v2 02/12] SPI: Refactor spi-orion to use SPI framework queue.

[Andrew Lunn]

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/

[PATCH v2 03/12] spi-orion: remove uneeded spi_info

[Andrew Lunn]

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/

[PATCH v2 04/12] spi-orion: add device tree binding

[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

[PATCH v2 05/12] ARM: kirkwood: use devicetree for orion-spi

[Andrew Lunn]

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/

[PATCH v2 06/12] ARM: kirkwood: use devicetree for SPI on dreamplug

[Andrew Lunn]

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/

[PATCH v2 07/12] I2C: MV64XXX: Add Device Tree support

[Andrew Lunn]

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/

Re: [PATCH v2 07/12] I2C: MV64XXX: Add Device Tree support

[Florian Fainelli]

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/

Re: [PATCH v2 07/12] I2C: MV64XXX: Add Device Tree support

[Andrew Lunn]

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

Re: [PATCH v2 07/12] I2C: MV64XXX: Add Device Tree support

[Florian Fainelli]

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/

Re: [PATCH v2 07/12] I2C: MV64XXX: Add Device Tree support

[Andrew Lunn]

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

[PATCH v2 08/12] Kirkwood: Add basic device tree support for QNAP TS219.

[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

Re: [PATCH v2 08/12] Kirkwood: Add basic device tree support for QNAP TS219.

[Florian Fainelli]

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

Re: [PATCH v2 08/12] Kirkwood: Add basic device tree support for QNAP TS219.

[Andrew Lunn]

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

[PATCH v2 09/12] ARM: Kirkwood: DTify the watchdog timer.

[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

[PATCH v2 10/12] ATA: sata_mv: Add device tree support

[Andrew Lunn]

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/

[PATCH v2 11/12] ARM: Kirkwood: Use DT to configure SATA device.

[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

Re: [PATCH v2 11/12] ARM: Kirkwood: Use DT to configure SATA device.

[Josh Coombs]

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

Re: [PATCH v2 11/12] ARM: Kirkwood: Use DT to configure SATA device.

[Andrew Lunn]

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

[PATCH v2 12/12] Crypto: CESA: Add support for DT based instantiation.

[Andrew Lunn]

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/

Re: [PATCH v2 12/12] Crypto: CESA: Add support for DT based instantiation.

[Florian Fainelli]

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

Re: [PATCH v2 12/12] Crypto: CESA: Add support for DT based instantiation.

[Andrew Lunn]

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