[PATCH 00/12] ARM: vf610m4: Add Vybrid Cortex-M4 support

[PATCH 00/12] ARM: vf610m4: Add Vybrid Cortex-M4 support

[Stefan Agner]

This is the second version (first was RFC) of this patchset. It
contains feedback from RFC and mainly grew by the support for the
interrupt router which is part of the MSCM IP contained in Vybrid.
MSCM provides a simple router for the pheriperal interrupts which
allows to select which CPU should receive a certain interrupt.
Hence it is crucrial for Linux. Right now, the boot loader enables
all interrupts for the Cortex-A5. To make Linux on Cortex-M4
working, the interrupts of the peripherals have been manually
remapped. A proper driver would automate this, along with a "poor
mans resource controller" (WARN_ON when the interrupt is routed).
This IP appears only to be part of Vybrid, the somewhat similar
SoC i.MX6SoloX does not contain this IP, hence I made it rather
Vybrid specific.

I think some patches are already merge ready (unified addruart),
while some need likely more discussion (NVIC irq router support,
MSCM stuff).

Especially I did not solved the multiplatform problem. Arnd, I
read your patches and started to think about it, but I'm not sure
I'm the right person doing that since my view of the ARM world
is still rather limited... But for Vybrid, it would be very useful
and simplify Kconfig (would avoid the additional arch ARCH_MXCM4).

With the m4boot utility (https://github.com/falstaff84/m4boot), a
XIP kernel image with its dtb and a initramfs, the Cortex-M4 can
be booted on a mainline kernel using:

./m4boot xipImage initramfs.cpio.lzo vf610m4-colibri.dtb

(some U-Boot fiddling needed, ask for details if you really want
to test that)

Changes since RFC:
- Unified addruart calls for MMU/!MMU
- Add MSCM support along with routable IRQ support in NVIC
- Rebased on Shawns for-next tree which made some changes
  obsolete (mainly the Vybrid SoC device tree files in for-next
  are already prepared for Cortex-M4 support)
- Removed SRC_GPR3 hack, this is now part of a mini boot-loader:
  https://github.com/falstaff84/vf610m4bootldr

Stefan Agner (12):
  ARM: dts: vf610: add routable-irqs property for gic node
  ARM: dts: vf610: add Miscellaneous System Control Module (MSCM)
  irqchip: gic: define register_routable_domain_ops conditional
  irqchip: nvic: support routable irq domain ops
  irqchip: nvic: increase number of external interrupts to 112
  ARM: imx: add support for MSCM interrupt router
  Documentation: dt: imx: add MSCM documentation
  clocksource: add dependencies for Vybrid pit clocksource
  ARM: unify MMU/!MMU addruart calls
  ARM: vf610m4: add new machine and SoC for Vybrid on Cortex-M4
  ARM: dts: add support for Vybrid running on Cortex-M4
  ARM: vf610m4: add defconfig for Linux on Vybrids Cortex-M4

 .../bindings/arm/freescale/fsl,vf610-mscm.txt      |  14 ++
 arch/arm/Kconfig                                   |  12 ++
 arch/arm/Kconfig.debug                             |   4 +-
 arch/arm/Makefile                                  |   1 +
 arch/arm/boot/dts/Makefile                         |   1 +
 arch/arm/boot/dts/vf500.dtsi                       |   1 +
 arch/arm/boot/dts/vf610m4-colibri.dts              |  52 ++++++++
 arch/arm/boot/dts/vf610m4.dtsi                     |  33 +++++
 arch/arm/boot/dts/vfxxx.dtsi                       |   5 +
 arch/arm/configs/vf610m4_defconfig                 |  49 +++++++
 arch/arm/include/debug/efm32.S                     |   2 +-
 arch/arm/kernel/debug.S                            |   2 +-
 arch/arm/kernel/entry-v7m.S                        |   6 +-
 arch/arm/mach-imx/Kconfig                          |  27 ++++
 arch/arm/mach-imx/Makefile                         |   2 +
 arch/arm/mach-imx/Makefile.boot                    |   0
 arch/arm/mach-imx/common.h                         |   1 +
 arch/arm/mach-imx/mach-vf610.c                     |   7 +
 arch/arm/mach-imx/mach-vf610m4.c                   |  31 +++++
 arch/arm/mach-imx/mscm-vf610.c                     | 141 +++++++++++++++++++++
 drivers/clocksource/Kconfig                        |   2 +
 drivers/irqchip/irq-nvic.c                         |  72 ++++++++++-
 drivers/mmc/host/Kconfig                           |   2 +-
 drivers/pinctrl/freescale/Kconfig                  |   2 +-
 include/linux/irqchip/arm-gic.h                    |   3 +
 include/linux/irqchip/arm-nvic.h                   |  25 ++++
 26 files changed, 487 insertions(+), 10 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/arm/freescale/fsl,vf610-mscm.txt
 create mode 100644 arch/arm/boot/dts/vf610m4-colibri.dts
 create mode 100644 arch/arm/boot/dts/vf610m4.dtsi
 create mode 100644 arch/arm/configs/vf610m4_defconfig
 create mode 100644 arch/arm/mach-imx/Makefile.boot
 create mode 100644 arch/arm/mach-imx/mach-vf610m4.c
 create mode 100644 arch/arm/mach-imx/mscm-vf610.c
 create mode 100644 include/linux/irqchip/arm-nvic.h

-- 
2.1.3

[PATCH 00/12] ARM: vf610m4: Add Vybrid Cortex-M4 support

[Stefan Agner]

This is the second version (first was RFC) of this patchset. It
contains feedback from RFC and mainly grew by the support for the
interrupt router which is part of the MSCM IP contained in Vybrid.
MSCM provides a simple router for the pheriperal interrupts which
allows to select which CPU should receive a certain interrupt.
Hence it is crucrial for Linux. Right now, the boot loader enables
all interrupts for the Cortex-A5. To make Linux on Cortex-M4
working, the interrupts of the peripherals have been manually
remapped. A proper driver would automate this, along with a "poor
mans resource controller" (WARN_ON when the interrupt is routed).
This IP appears only to be part of Vybrid, the somewhat similar
SoC i.MX6SoloX does not contain this IP, hence I made it rather
Vybrid specific.

I think some patches are already merge ready (unified addruart),
while some need likely more discussion (NVIC irq router support,
MSCM stuff).

Especially I did not solved the multiplatform problem. Arnd, I
read your patches and started to think about it, but I'm not sure
I'm the right person doing that since my view of the ARM world
is still rather limited... But for Vybrid, it would be very useful
and simplify Kconfig (would avoid the additional arch ARCH_MXCM4).

With the m4boot utility (https://github.com/falstaff84/m4boot), a
XIP kernel image with its dtb and a initramfs, the Cortex-M4 can
be booted on a mainline kernel using:

./m4boot xipImage initramfs.cpio.lzo vf610m4-colibri.dtb

(some U-Boot fiddling needed, ask for details if you really want
to test that)

Changes since RFC:
- Unified addruart calls for MMU/!MMU
- Add MSCM support along with routable IRQ support in NVIC
- Rebased on Shawns for-next tree which made some changes
  obsolete (mainly the Vybrid SoC device tree files in for-next
  are already prepared for Cortex-M4 support)
- Removed SRC_GPR3 hack, this is now part of a mini boot-loader:
  https://github.com/falstaff84/vf610m4bootldr

Stefan Agner (12):
  ARM: dts: vf610: add routable-irqs property for gic node
  ARM: dts: vf610: add Miscellaneous System Control Module (MSCM)
  irqchip: gic: define register_routable_domain_ops conditional
  irqchip: nvic: support routable irq domain ops
  irqchip: nvic: increase number of external interrupts to 112
  ARM: imx: add support for MSCM interrupt router
  Documentation: dt: imx: add MSCM documentation
  clocksource: add dependencies for Vybrid pit clocksource
  ARM: unify MMU/!MMU addruart calls
  ARM: vf610m4: add new machine and SoC for Vybrid on Cortex-M4
  ARM: dts: add support for Vybrid running on Cortex-M4
  ARM: vf610m4: add defconfig for Linux on Vybrids Cortex-M4

 .../bindings/arm/freescale/fsl,vf610-mscm.txt      |  14 ++
 arch/arm/Kconfig                                   |  12 ++
 arch/arm/Kconfig.debug                             |   4 +-
 arch/arm/Makefile                                  |   1 +
 arch/arm/boot/dts/Makefile                         |   1 +
 arch/arm/boot/dts/vf500.dtsi                       |   1 +
 arch/arm/boot/dts/vf610m4-colibri.dts              |  52 ++++++++
 arch/arm/boot/dts/vf610m4.dtsi                     |  33 +++++
 arch/arm/boot/dts/vfxxx.dtsi                       |   5 +
 arch/arm/configs/vf610m4_defconfig                 |  49 +++++++
 arch/arm/include/debug/efm32.S                     |   2 +-
 arch/arm/kernel/debug.S                            |   2 +-
 arch/arm/kernel/entry-v7m.S                        |   6 +-
 arch/arm/mach-imx/Kconfig                          |  27 ++++
 arch/arm/mach-imx/Makefile                         |   2 +
 arch/arm/mach-imx/Makefile.boot                    |   0
 arch/arm/mach-imx/common.h                         |   1 +
 arch/arm/mach-imx/mach-vf610.c                     |   7 +
 arch/arm/mach-imx/mach-vf610m4.c                   |  31 +++++
 arch/arm/mach-imx/mscm-vf610.c                     | 141 +++++++++++++++++++++
 drivers/clocksource/Kconfig                        |   2 +
 drivers/irqchip/irq-nvic.c                         |  72 ++++++++++-
 drivers/mmc/host/Kconfig                           |   2 +-
 drivers/pinctrl/freescale/Kconfig                  |   2 +-
 include/linux/irqchip/arm-gic.h                    |   3 +
 include/linux/irqchip/arm-nvic.h                   |  25 ++++
 26 files changed, 487 insertions(+), 10 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/arm/freescale/fsl,vf610-mscm.txt
 create mode 100644 arch/arm/boot/dts/vf610m4-colibri.dts
 create mode 100644 arch/arm/boot/dts/vf610m4.dtsi
 create mode 100644 arch/arm/configs/vf610m4_defconfig
 create mode 100644 arch/arm/mach-imx/Makefile.boot
 create mode 100644 arch/arm/mach-imx/mach-vf610m4.c
 create mode 100644 arch/arm/mach-imx/mscm-vf610.c
 create mode 100644 include/linux/irqchip/arm-nvic.h

-- 
2.1.3

[PATCH 01/12] ARM: dts: vf610: add routable-irqs property for gic node

[Stefan Agner]

From: Stefan Agner <stefan.agner@toradex.com>

To enable proper routable interrupt controller support for
the GIC driver, the routable-irqs need to be specified.
Hence add the routable-irqs property with the amount of
IRQs supported by the GIC controller on the Vybrid SoC.

Signed-off-by: Stefan Agner <stefan@agner.ch>
---
 arch/arm/boot/dts/vf500.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/vf500.dtsi b/arch/arm/boot/dts/vf500.dtsi
index de67005..2b0d84d 100644
--- a/arch/arm/boot/dts/vf500.dtsi
+++ b/arch/arm/boot/dts/vf500.dtsi
@@ -30,6 +30,7 @@
 
 			intc: interrupt-controller@40002000 {
 				compatible = "arm,cortex-a9-gic";
+				arm,routable-irqs = <144>;
 				#interrupt-cells = <3>;
 				interrupt-controller;
 				reg = <0x40003000 0x1000>,
-- 
2.1.3

[PATCH 01/12] ARM: dts: vf610: add routable-irqs property for gic node

[Stefan Agner]

From: Stefan Agner <stefan.agner@toradex.com>

To enable proper routable interrupt controller support for
the GIC driver, the routable-irqs need to be specified.
Hence add the routable-irqs property with the amount of
IRQs supported by the GIC controller on the Vybrid SoC.

Signed-off-by: Stefan Agner <stefan@agner.ch>
---
 arch/arm/boot/dts/vf500.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/vf500.dtsi b/arch/arm/boot/dts/vf500.dtsi
index de67005..2b0d84d 100644
--- a/arch/arm/boot/dts/vf500.dtsi
+++ b/arch/arm/boot/dts/vf500.dtsi
@@ -30,6 +30,7 @@
 
 			intc: interrupt-controller at 40002000 {
 				compatible = "arm,cortex-a9-gic";
+				arm,routable-irqs = <144>;
 				#interrupt-cells = <3>;
 				interrupt-controller;
 				reg = <0x40003000 0x1000>,
-- 
2.1.3

[PATCH 02/12] ARM: dts: vf610: add Miscellaneous System Control Module (MSCM)

[Stefan Agner]

Add the Miscellaneous System Control Module (MSCM) to the base
device tree for Vybrid SoCs. This module contains the peripheral
interrupt router, which is handling the routing of the interrupts
between the two cores.

Signed-off-by: Stefan Agner <stefan@agner.ch>
---
 arch/arm/boot/dts/vfxxx.dtsi | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/boot/dts/vfxxx.dtsi b/arch/arm/boot/dts/vfxxx.dtsi
index 505969a..85fb697 100644
--- a/arch/arm/boot/dts/vfxxx.dtsi
+++ b/arch/arm/boot/dts/vfxxx.dtsi
@@ -55,6 +55,11 @@
 			#size-cells = <1>;
 			ranges;
 
+			mscm: mscm@40001000 {
+				compatible = "fsl,vf610-mscm";
+				reg = <0x40001000 0x1000>;
+			};
+
 			edma0: dma-controller@40018000 {
 				#dma-cells = <2>;
 				compatible = "fsl,vf610-edma";
-- 
2.1.3

[PATCH 02/12] ARM: dts: vf610: add Miscellaneous System Control Module (MSCM)

[Stefan Agner]

Add the Miscellaneous System Control Module (MSCM) to the base
device tree for Vybrid SoCs. This module contains the peripheral
interrupt router, which is handling the routing of the interrupts
between the two cores.

Signed-off-by: Stefan Agner <stefan-XLVq0VzYD2Y@public.gmane.org>
---
 arch/arm/boot/dts/vfxxx.dtsi | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/boot/dts/vfxxx.dtsi b/arch/arm/boot/dts/vfxxx.dtsi
index 505969a..85fb697 100644
--- a/arch/arm/boot/dts/vfxxx.dtsi
+++ b/arch/arm/boot/dts/vfxxx.dtsi
@@ -55,6 +55,11 @@
 			#size-cells = <1>;
 			ranges;
 
+			mscm: mscm@40001000 {
+				compatible = "fsl,vf610-mscm";
+				reg = <0x40001000 0x1000>;
+			};
+
 			edma0: dma-controller@40018000 {
 				#dma-cells = <2>;
 				compatible = "fsl,vf610-edma";
-- 
2.1.3

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 02/12] ARM: dts: vf610: add Miscellaneous System Control Module (MSCM)

[Stefan Agner]

Add the Miscellaneous System Control Module (MSCM) to the base
device tree for Vybrid SoCs. This module contains the peripheral
interrupt router, which is handling the routing of the interrupts
between the two cores.

Signed-off-by: Stefan Agner <stefan@agner.ch>
---
 arch/arm/boot/dts/vfxxx.dtsi | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/boot/dts/vfxxx.dtsi b/arch/arm/boot/dts/vfxxx.dtsi
index 505969a..85fb697 100644
--- a/arch/arm/boot/dts/vfxxx.dtsi
+++ b/arch/arm/boot/dts/vfxxx.dtsi
@@ -55,6 +55,11 @@
 			#size-cells = <1>;
 			ranges;
 
+			mscm: mscm at 40001000 {
+				compatible = "fsl,vf610-mscm";
+				reg = <0x40001000 0x1000>;
+			};
+
 			edma0: dma-controller at 40018000 {
 				#dma-cells = <2>;
 				compatible = "fsl,vf610-edma";
-- 
2.1.3

[PATCH 03/12] irqchip: gic: define register_routable_domain_ops conditional

[Stefan Agner]

The inline function register_routable_domain_ops is only usable if
CONFIG_ARM_GIC is set. Make it depend on this configuration. This
also allows other SoC interrupt controller to provide such a
function.

Signed-off-by: Stefan Agner <stefan@agner.ch>
---
 include/linux/irqchip/arm-gic.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/include/linux/irqchip/arm-gic.h b/include/linux/irqchip/arm-gic.h
index 13eed92..3b1baf1 100644
--- a/include/linux/irqchip/arm-gic.h
+++ b/include/linux/irqchip/arm-gic.h
@@ -111,11 +111,14 @@ int gic_get_cpu_id(unsigned int cpu);
 void gic_migrate_target(unsigned int new_cpu_id);
 unsigned long gic_get_sgir_physaddr(void);
 
+#ifdef CONFIG_ARM_GIC
 extern const struct irq_domain_ops *gic_routable_irq_domain_ops;
 static inline void __init register_routable_domain_ops
 					(const struct irq_domain_ops *ops)
 {
 	gic_routable_irq_domain_ops = ops;
 }
+#endif /* CONFIG_ARM_GIC */
+
 #endif /* __ASSEMBLY */
 #endif
-- 
2.1.3

[PATCH 03/12] irqchip: gic: define register_routable_domain_ops conditional

[Stefan Agner]

The inline function register_routable_domain_ops is only usable if
CONFIG_ARM_GIC is set. Make it depend on this configuration. This
also allows other SoC interrupt controller to provide such a
function.

Signed-off-by: Stefan Agner <stefan@agner.ch>
---
 include/linux/irqchip/arm-gic.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/include/linux/irqchip/arm-gic.h b/include/linux/irqchip/arm-gic.h
index 13eed92..3b1baf1 100644
--- a/include/linux/irqchip/arm-gic.h
+++ b/include/linux/irqchip/arm-gic.h
@@ -111,11 +111,14 @@ int gic_get_cpu_id(unsigned int cpu);
 void gic_migrate_target(unsigned int new_cpu_id);
 unsigned long gic_get_sgir_physaddr(void);
 
+#ifdef CONFIG_ARM_GIC
 extern const struct irq_domain_ops *gic_routable_irq_domain_ops;
 static inline void __init register_routable_domain_ops
 					(const struct irq_domain_ops *ops)
 {
 	gic_routable_irq_domain_ops = ops;
 }
+#endif /* CONFIG_ARM_GIC */
+
 #endif /* __ASSEMBLY */
 #endif
-- 
2.1.3

[PATCH 04/12] irqchip: nvic: support routable irq domain ops

[Stefan Agner]

Add support for routable irq domain ops like the GIC interrupt
controller provides. This is useful for asymmetrical multi-
processor SoCs, such as Freescale Vybrid (VF6xx) which have
a Cortex-M4 alongside a Cortex-A5 and a interrupt router to
route the peripheral interrupts between them.

Signed-off-by: Stefan Agner <stefan@agner.ch>
---
 drivers/irqchip/irq-nvic.c       | 70 +++++++++++++++++++++++++++++++++++++++-
 include/linux/irqchip/arm-nvic.h | 25 ++++++++++++++
 2 files changed, 94 insertions(+), 1 deletion(-)
 create mode 100644 include/linux/irqchip/arm-nvic.h

diff --git a/drivers/irqchip/irq-nvic.c b/drivers/irqchip/irq-nvic.c
index 4ff0805..dbfb5be 100644
--- a/drivers/irqchip/irq-nvic.c
+++ b/drivers/irqchip/irq-nvic.c
@@ -40,6 +40,7 @@
 #define NVIC_MAX_IRQ		((NVIC_MAX_BANKS - 1) * 32 + 16)
 
 static struct irq_domain *nvic_irq_domain;
+const struct irq_domain_ops *nvic_routable_irq_domain_ops;
 
 asmlinkage void __exception_irq_entry
 nvic_handle_irq(irq_hw_number_t hwirq, struct pt_regs *regs)
@@ -49,6 +50,73 @@ nvic_handle_irq(irq_hw_number_t hwirq, struct pt_regs *regs)
 	handle_IRQ(irq, regs);
 }
 
+static int nvic_irq_domain_map(struct irq_domain *d, unsigned int irq,
+				irq_hw_number_t hw)
+{
+	int ret;
+
+	ret = irq_map_generic_chip(d, irq, hw);
+
+	if (IS_ERR_VALUE(ret))
+		return ret;
+
+	return nvic_routable_irq_domain_ops->map(d, irq, hw);
+}
+
+static void nvic_irq_domain_unmap(struct irq_domain *d, unsigned int irq)
+{
+	nvic_routable_irq_domain_ops->unmap(d, irq);
+}
+
+static int nvic_irq_domain_xlate(struct irq_domain *d,
+				 struct device_node *controller,
+				 const u32 *intspec, unsigned int intsize,
+				 unsigned long *out_hwirq,
+				 unsigned int *out_type)
+{
+	*out_hwirq = intspec[0];
+	*out_type = IRQ_TYPE_NONE;
+
+	return nvic_routable_irq_domain_ops->xlate(d, controller, intspec,
+						  intsize, out_hwirq, out_type);
+}
+
+struct irq_domain_ops nvic_irq_domain_ops = {
+	.map	= nvic_irq_domain_map,
+	.unmap	= nvic_irq_domain_unmap,
+	.xlate	= nvic_irq_domain_xlate,
+};
+
+/* Default functions for routable irq domain */
+static int nvic_routable_irq_domain_map(struct irq_domain *d, unsigned int irq,
+			      irq_hw_number_t hw)
+{
+	return 0;
+}
+
+static void nvic_routable_irq_domain_unmap(struct irq_domain *d,
+					  unsigned int irq)
+{
+}
+
+static int nvic_routable_irq_domain_xlate(struct irq_domain *d,
+				struct device_node *controller,
+				const u32 *intspec, unsigned int intsize,
+				unsigned long *out_hwirq,
+				unsigned int *out_type)
+{
+	return 0;
+}
+
+static const struct irq_domain_ops nvic_default_routable_irq_domain_ops = {
+	.map = nvic_routable_irq_domain_map,
+	.unmap = nvic_routable_irq_domain_unmap,
+	.xlate = nvic_routable_irq_domain_xlate,
+};
+
+const struct irq_domain_ops *nvic_routable_irq_domain_ops =
+					&nvic_default_routable_irq_domain_ops;
+
 static int __init nvic_of_init(struct device_node *node,
 			       struct device_node *parent)
 {
@@ -70,7 +138,7 @@ static int __init nvic_of_init(struct device_node *node,
 		irqs = NVIC_MAX_IRQ;
 
 	nvic_irq_domain =
-		irq_domain_add_linear(node, irqs, &irq_generic_chip_ops, NULL);
+		irq_domain_add_linear(node, irqs, &nvic_irq_domain_ops, NULL);
 	if (!nvic_irq_domain) {
 		pr_warn("Failed to allocate irq domain\n");
 		return -ENOMEM;
diff --git a/include/linux/irqchip/arm-nvic.h b/include/linux/irqchip/arm-nvic.h
new file mode 100644
index 0000000..0e92a14
--- /dev/null
+++ b/include/linux/irqchip/arm-nvic.h
@@ -0,0 +1,25 @@
+/*
+ *  include/linux/irqchip/arm-nvic.h
+ *
+ *  Copyright (C) 2014 Stefan Agner
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#ifndef __LINUX_IRQCHIP_ARM_NVIC_H
+#define __LINUX_IRQCHIP_ARM_NVIC_H
+
+#ifndef __ASSEMBLY__
+
+#ifdef CONFIG_ARM_NVIC
+extern const struct irq_domain_ops *nvic_routable_irq_domain_ops;
+static inline void __init register_routable_domain_ops
+					(const struct irq_domain_ops *ops)
+{
+		nvic_routable_irq_domain_ops = ops;
+}
+#endif /* CONFIG_ARM_NVIC */
+
+#endif /* __ASSEMBLY__ */
+#endif /* __LINUX_IRQCHIP_ARM_NVIC_H */
-- 
2.1.3

[PATCH 04/12] irqchip: nvic: support routable irq domain ops

[Stefan Agner]

Add support for routable irq domain ops like the GIC interrupt
controller provides. This is useful for asymmetrical multi-
processor SoCs, such as Freescale Vybrid (VF6xx) which have
a Cortex-M4 alongside a Cortex-A5 and a interrupt router to
route the peripheral interrupts between them.

Signed-off-by: Stefan Agner <stefan@agner.ch>
---
 drivers/irqchip/irq-nvic.c       | 70 +++++++++++++++++++++++++++++++++++++++-
 include/linux/irqchip/arm-nvic.h | 25 ++++++++++++++
 2 files changed, 94 insertions(+), 1 deletion(-)
 create mode 100644 include/linux/irqchip/arm-nvic.h

diff --git a/drivers/irqchip/irq-nvic.c b/drivers/irqchip/irq-nvic.c
index 4ff0805..dbfb5be 100644
--- a/drivers/irqchip/irq-nvic.c
+++ b/drivers/irqchip/irq-nvic.c
@@ -40,6 +40,7 @@
 #define NVIC_MAX_IRQ		((NVIC_MAX_BANKS - 1) * 32 + 16)
 
 static struct irq_domain *nvic_irq_domain;
+const struct irq_domain_ops *nvic_routable_irq_domain_ops;
 
 asmlinkage void __exception_irq_entry
 nvic_handle_irq(irq_hw_number_t hwirq, struct pt_regs *regs)
@@ -49,6 +50,73 @@ nvic_handle_irq(irq_hw_number_t hwirq, struct pt_regs *regs)
 	handle_IRQ(irq, regs);
 }
 
+static int nvic_irq_domain_map(struct irq_domain *d, unsigned int irq,
+				irq_hw_number_t hw)
+{
+	int ret;
+
+	ret = irq_map_generic_chip(d, irq, hw);
+
+	if (IS_ERR_VALUE(ret))
+		return ret;
+
+	return nvic_routable_irq_domain_ops->map(d, irq, hw);
+}
+
+static void nvic_irq_domain_unmap(struct irq_domain *d, unsigned int irq)
+{
+	nvic_routable_irq_domain_ops->unmap(d, irq);
+}
+
+static int nvic_irq_domain_xlate(struct irq_domain *d,
+				 struct device_node *controller,
+				 const u32 *intspec, unsigned int intsize,
+				 unsigned long *out_hwirq,
+				 unsigned int *out_type)
+{
+	*out_hwirq = intspec[0];
+	*out_type = IRQ_TYPE_NONE;
+
+	return nvic_routable_irq_domain_ops->xlate(d, controller, intspec,
+						  intsize, out_hwirq, out_type);
+}
+
+struct irq_domain_ops nvic_irq_domain_ops = {
+	.map	= nvic_irq_domain_map,
+	.unmap	= nvic_irq_domain_unmap,
+	.xlate	= nvic_irq_domain_xlate,
+};
+
+/* Default functions for routable irq domain */
+static int nvic_routable_irq_domain_map(struct irq_domain *d, unsigned int irq,
+			      irq_hw_number_t hw)
+{
+	return 0;
+}
+
+static void nvic_routable_irq_domain_unmap(struct irq_domain *d,
+					  unsigned int irq)
+{
+}
+
+static int nvic_routable_irq_domain_xlate(struct irq_domain *d,
+				struct device_node *controller,
+				const u32 *intspec, unsigned int intsize,
+				unsigned long *out_hwirq,
+				unsigned int *out_type)
+{
+	return 0;
+}
+
+static const struct irq_domain_ops nvic_default_routable_irq_domain_ops = {
+	.map = nvic_routable_irq_domain_map,
+	.unmap = nvic_routable_irq_domain_unmap,
+	.xlate = nvic_routable_irq_domain_xlate,
+};
+
+const struct irq_domain_ops *nvic_routable_irq_domain_ops =
+					&nvic_default_routable_irq_domain_ops;
+
 static int __init nvic_of_init(struct device_node *node,
 			       struct device_node *parent)
 {
@@ -70,7 +138,7 @@ static int __init nvic_of_init(struct device_node *node,
 		irqs = NVIC_MAX_IRQ;
 
 	nvic_irq_domain =
-		irq_domain_add_linear(node, irqs, &irq_generic_chip_ops, NULL);
+		irq_domain_add_linear(node, irqs, &nvic_irq_domain_ops, NULL);
 	if (!nvic_irq_domain) {
 		pr_warn("Failed to allocate irq domain\n");
 		return -ENOMEM;
diff --git a/include/linux/irqchip/arm-nvic.h b/include/linux/irqchip/arm-nvic.h
new file mode 100644
index 0000000..0e92a14
--- /dev/null
+++ b/include/linux/irqchip/arm-nvic.h
@@ -0,0 +1,25 @@
+/*
+ *  include/linux/irqchip/arm-nvic.h
+ *
+ *  Copyright (C) 2014 Stefan Agner
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#ifndef __LINUX_IRQCHIP_ARM_NVIC_H
+#define __LINUX_IRQCHIP_ARM_NVIC_H
+
+#ifndef __ASSEMBLY__
+
+#ifdef CONFIG_ARM_NVIC
+extern const struct irq_domain_ops *nvic_routable_irq_domain_ops;
+static inline void __init register_routable_domain_ops
+					(const struct irq_domain_ops *ops)
+{
+		nvic_routable_irq_domain_ops = ops;
+}
+#endif /* CONFIG_ARM_NVIC */
+
+#endif /* __ASSEMBLY__ */
+#endif /* __LINUX_IRQCHIP_ARM_NVIC_H */
-- 
2.1.3

[PATCH 05/12] irqchip: nvic: increase number of external interrupts to 112

[Stefan Agner]

So far only vectors for up to 48 external interrupts have been
registred in the vector table. Increase the amount of registred
external vectors to 112. Also, add a warning in case NVIC reports
support for more interrupts than 128.

Note: the vector table must align to the number of entires in the
vector table, hence increase the alignment to 0x200.

Signed-off-by: Stefan Agner <stefan@agner.ch>
---
 arch/arm/kernel/entry-v7m.S | 6 +++---
 drivers/irqchip/irq-nvic.c  | 2 ++
 2 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/arch/arm/kernel/entry-v7m.S b/arch/arm/kernel/entry-v7m.S
index 2260f18..754a1fa 100644
--- a/arch/arm/kernel/entry-v7m.S
+++ b/arch/arm/kernel/entry-v7m.S
@@ -115,7 +115,7 @@ ENTRY(__switch_to)
 ENDPROC(__switch_to)
 
 	.data
-	.align	8
+	.align	9
 /*
  * Vector table (64 words => 256 bytes natural alignment)
  */
@@ -136,6 +136,6 @@ ENTRY(vector_table)
 	.long	__invalid_entry		@ 13 - Reserved
 	.long	__pendsv_entry		@ 14 - PendSV
 	.long	__invalid_entry		@ 15 - SysTick
-	.rept	64 - 16
-	.long	__irq_entry		@ 16..64 - External Interrupts
+	.rept	128 - 16
+	.long	__irq_entry		@ 16..128 - External Interrupts
 	.endr
diff --git a/drivers/irqchip/irq-nvic.c b/drivers/irqchip/irq-nvic.c
index dbfb5be..40f62a9 100644
--- a/drivers/irqchip/irq-nvic.c
+++ b/drivers/irqchip/irq-nvic.c
@@ -137,6 +137,8 @@ static int __init nvic_of_init(struct device_node *node,
 	if (irqs > NVIC_MAX_IRQ)
 		irqs = NVIC_MAX_IRQ;
 
+	WARN(irqs > 128, "vector table in entry-v7m.S configured for 128 irqs");
+
 	nvic_irq_domain =
 		irq_domain_add_linear(node, irqs, &nvic_irq_domain_ops, NULL);
 	if (!nvic_irq_domain) {
-- 
2.1.3

[PATCH 05/12] irqchip: nvic: increase number of external interrupts to 112

[Stefan Agner]

So far only vectors for up to 48 external interrupts have been
registred in the vector table. Increase the amount of registred
external vectors to 112. Also, add a warning in case NVIC reports
support for more interrupts than 128.

Note: the vector table must align to the number of entires in the
vector table, hence increase the alignment to 0x200.

Signed-off-by: Stefan Agner <stefan@agner.ch>
---
 arch/arm/kernel/entry-v7m.S | 6 +++---
 drivers/irqchip/irq-nvic.c  | 2 ++
 2 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/arch/arm/kernel/entry-v7m.S b/arch/arm/kernel/entry-v7m.S
index 2260f18..754a1fa 100644
--- a/arch/arm/kernel/entry-v7m.S
+++ b/arch/arm/kernel/entry-v7m.S
@@ -115,7 +115,7 @@ ENTRY(__switch_to)
 ENDPROC(__switch_to)
 
 	.data
-	.align	8
+	.align	9
 /*
  * Vector table (64 words => 256 bytes natural alignment)
  */
@@ -136,6 +136,6 @@ ENTRY(vector_table)
 	.long	__invalid_entry		@ 13 - Reserved
 	.long	__pendsv_entry		@ 14 - PendSV
 	.long	__invalid_entry		@ 15 - SysTick
-	.rept	64 - 16
-	.long	__irq_entry		@ 16..64 - External Interrupts
+	.rept	128 - 16
+	.long	__irq_entry		@ 16..128 - External Interrupts
 	.endr
diff --git a/drivers/irqchip/irq-nvic.c b/drivers/irqchip/irq-nvic.c
index dbfb5be..40f62a9 100644
--- a/drivers/irqchip/irq-nvic.c
+++ b/drivers/irqchip/irq-nvic.c
@@ -137,6 +137,8 @@ static int __init nvic_of_init(struct device_node *node,
 	if (irqs > NVIC_MAX_IRQ)
 		irqs = NVIC_MAX_IRQ;
 
+	WARN(irqs > 128, "vector table in entry-v7m.S configured for 128 irqs");
+
 	nvic_irq_domain =
 		irq_domain_add_linear(node, irqs, &nvic_irq_domain_ops, NULL);
 	if (!nvic_irq_domain) {
-- 
2.1.3

[PATCH 05/12] irqchip: nvic: increase number of external interrupts to 112

[Stefan Agner]

So far only vectors for up to 48 external interrupts have been
registred in the vector table. Increase the amount of registred
external vectors to 112. Also, add a warning in case NVIC reports
support for more interrupts than 128.

Note: the vector table must align to the number of entires in the
vector table, hence increase the alignment to 0x200.

Signed-off-by: Stefan Agner <stefan@agner.ch>
---
 arch/arm/kernel/entry-v7m.S | 6 +++---
 drivers/irqchip/irq-nvic.c  | 2 ++
 2 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/arch/arm/kernel/entry-v7m.S b/arch/arm/kernel/entry-v7m.S
index 2260f18..754a1fa 100644
--- a/arch/arm/kernel/entry-v7m.S
+++ b/arch/arm/kernel/entry-v7m.S
@@ -115,7 +115,7 @@ ENTRY(__switch_to)
 ENDPROC(__switch_to)
 
 	.data
-	.align	8
+	.align	9
 /*
  * Vector table (64 words => 256 bytes natural alignment)
  */
@@ -136,6 +136,6 @@ ENTRY(vector_table)
 	.long	__invalid_entry		@ 13 - Reserved
 	.long	__pendsv_entry		@ 14 - PendSV
 	.long	__invalid_entry		@ 15 - SysTick
-	.rept	64 - 16
-	.long	__irq_entry		@ 16..64 - External Interrupts
+	.rept	128 - 16
+	.long	__irq_entry		@ 16..128 - External Interrupts
 	.endr
diff --git a/drivers/irqchip/irq-nvic.c b/drivers/irqchip/irq-nvic.c
index dbfb5be..40f62a9 100644
--- a/drivers/irqchip/irq-nvic.c
+++ b/drivers/irqchip/irq-nvic.c
@@ -137,6 +137,8 @@ static int __init nvic_of_init(struct device_node *node,
 	if (irqs > NVIC_MAX_IRQ)
 		irqs = NVIC_MAX_IRQ;
 
+	WARN(irqs > 128, "vector table in entry-v7m.S configured for 128 irqs");
+
 	nvic_irq_domain =
 		irq_domain_add_linear(node, irqs, &nvic_irq_domain_ops, NULL);
 	if (!nvic_irq_domain) {
-- 
2.1.3

[PATCH 06/12] ARM: imx: add support for MSCM interrupt router

[Stefan Agner]

This adds support for Vybrids interrupt router for the shared
peripherals. The router is part of the MSCM (Miscellaneous System
Control Module).

Signed-off-by: Stefan Agner <stefan@agner.ch>
---
 arch/arm/mach-imx/Kconfig      |   4 ++
 arch/arm/mach-imx/Makefile     |   1 +
 arch/arm/mach-imx/common.h     |   1 +
 arch/arm/mach-imx/mach-vf610.c |   7 ++
 arch/arm/mach-imx/mscm-vf610.c | 141 +++++++++++++++++++++++++++++++++++++++++
 5 files changed, 154 insertions(+)
 create mode 100644 arch/arm/mach-imx/mscm-vf610.c

diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
index e8627e0..2935972 100644
--- a/arch/arm/mach-imx/Kconfig
+++ b/arch/arm/mach-imx/Kconfig
@@ -58,6 +58,9 @@ config HAVE_IMX_SRC
 	def_bool y if SMP
 	select ARCH_HAS_RESET_CONTROLLER
 
+config HAVE_VF610_MSCM
+	bool
+
 config IMX_HAVE_IOMUX_V1
 	bool
 
@@ -631,6 +634,7 @@ config SOC_IMX6SX
 
 config SOC_VF610
 	bool "Vybrid Family VF610 support"
+	select HAVE_VF610_MSCM
 	select ARM_GIC
 	select PINCTRL_VF610
 	select PL310_ERRATA_769419 if CACHE_L2X0
diff --git a/arch/arm/mach-imx/Makefile b/arch/arm/mach-imx/Makefile
index f5ac685..82b1159 100644
--- a/arch/arm/mach-imx/Makefile
+++ b/arch/arm/mach-imx/Makefile
@@ -108,6 +108,7 @@ obj-$(CONFIG_SOC_IMX50) += mach-imx50.o
 obj-$(CONFIG_SOC_IMX51) += mach-imx51.o
 obj-$(CONFIG_SOC_IMX53) += mach-imx53.o
 
+obj-$(CONFIG_HAVE_VF610_MSCM) += mscm-vf610.o
 obj-$(CONFIG_SOC_VF610) += clk-vf610.o mach-vf610.o
 
 obj-$(CONFIG_SOC_LS1021A) += mach-ls1021a.o
diff --git a/arch/arm/mach-imx/common.h b/arch/arm/mach-imx/common.h
index 59ce8f3..6b5cad9 100644
--- a/arch/arm/mach-imx/common.h
+++ b/arch/arm/mach-imx/common.h
@@ -103,6 +103,7 @@ static inline void imx_smp_prepare(void) {}
 #endif
 void imx_src_init(void);
 void imx_gpc_init(void);
+void vf610_mscm_init(void);
 void imx_gpc_pre_suspend(bool arm_power_off);
 void imx_gpc_post_resume(void);
 void imx_gpc_mask_all(void);
diff --git a/arch/arm/mach-imx/mach-vf610.c b/arch/arm/mach-imx/mach-vf610.c
index c11ab6a..d1d200d 100644
--- a/arch/arm/mach-imx/mach-vf610.c
+++ b/arch/arm/mach-imx/mach-vf610.c
@@ -12,6 +12,12 @@
 #include <asm/mach/arch.h>
 #include <asm/hardware/cache-l2x0.h>
 
+static void __init vf610_init_irq(void)
+{
+	vf610_mscm_init();
+	irqchip_init();
+}
+
 static const char * const vf610_dt_compat[] __initconst = {
 	"fsl,vf610",
 	NULL,
@@ -20,5 +26,6 @@ static const char * const vf610_dt_compat[] __initconst = {
 DT_MACHINE_START(VYBRID_VF610, "Freescale Vybrid VF610 (Device Tree)")
 	.l2c_aux_val	= 0,
 	.l2c_aux_mask	= ~0,
+	.init_irq	= vf610_init_irq,
 	.dt_compat	= vf610_dt_compat,
 MACHINE_END
diff --git a/arch/arm/mach-imx/mscm-vf610.c b/arch/arm/mach-imx/mscm-vf610.c
new file mode 100644
index 0000000..211ea10
--- /dev/null
+++ b/arch/arm/mach-imx/mscm-vf610.c
@@ -0,0 +1,141 @@
+/*
+ * Copyright 2014 Stefan Agner
+ *
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ */
+
+#include <linux/cpu_pm.h>
+#include <linux/io.h>
+#include <linux/irq.h>
+#include <linux/irqdomain.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/irqchip/arm-gic.h>
+#include <linux/irqchip/arm-nvic.h>
+#include "common.h"
+
+#define MSCM_CPxNUM		0x4
+#define MSCM_IRSPRC(n)		(0x880 + 2 * (n))
+#define MSCM_IRSPRC_CPEN_MASK	0x3
+
+#define MSCM_IRSPRC_NUM		112
+
+#ifdef CONFIG_ARM_GIC
+#define MSCM_IRQ_OFFSET		32
+#elif CONFIG_ARM_NVIC
+#define MSCM_IRQ_OFFSET		0
+#endif
+
+static void __iomem *mscm_base;
+static u16 mscm_saved_irsprc[MSCM_IRSPRC_NUM];
+static u16 cpu_id;
+
+static int vf610_mscm_notifier(struct notifier_block *self, unsigned long cmd,
+			       void *v)
+{
+	int i;
+
+	/* Only the primary (boot CPU) should do suspend/resume */
+	if (cpu_id > 0)
+		return NOTIFY_OK;
+
+	switch (cmd) {
+	case CPU_CLUSTER_PM_ENTER:
+		for (i = 0; i < MSCM_IRSPRC_NUM; i++)
+			mscm_saved_irsprc[i] =
+				readw_relaxed(mscm_base + MSCM_IRSPRC(i));
+		break;
+	case CPU_CLUSTER_PM_ENTER_FAILED:
+	case CPU_CLUSTER_PM_EXIT:
+		for (i = 0; i < MSCM_IRSPRC_NUM; i++)
+			writew_relaxed(mscm_saved_irsprc[i],
+				       mscm_base + MSCM_IRSPRC(i));
+		break;
+	}
+
+	return NOTIFY_OK;
+}
+
+static struct notifier_block mscm_notifier_block = {
+	.notifier_call = vf610_mscm_notifier,
+};
+
+static int vf610_mscm_domain_map(struct irq_domain *d, unsigned int irq,
+			       irq_hw_number_t hw)
+{
+	u16 irsprc;
+
+	/* Do not handle non interrupt router IRQs */
+	if (hw < MSCM_IRQ_OFFSET)
+		return 0;
+
+	hw -= MSCM_IRQ_OFFSET;
+	irsprc = readw_relaxed(mscm_base + MSCM_IRSPRC(hw));
+	irsprc &= MSCM_IRSPRC_CPEN_MASK;
+
+	WARN_ON(irsprc);
+
+	writew_relaxed(0x1 << cpu_id, mscm_base + MSCM_IRSPRC(hw));
+
+	return 0;
+}
+
+static void vf610_mscm_domain_unmap(struct irq_domain *d, unsigned int irq)
+{
+	irq_hw_number_t hw = irq_get_irq_data(irq)->hwirq;
+	u16 irsprc;
+
+	/* Do not handle non interrupt router IRQs */
+	if (hw < MSCM_IRQ_OFFSET)
+		return;
+
+	hw -= MSCM_IRQ_OFFSET;
+	irsprc = readw_relaxed(mscm_base + MSCM_IRSPRC(hw));
+	irsprc &= MSCM_IRSPRC_CPEN_MASK;
+
+	WARN_ON(irsprc & ~(0x1 << cpu_id));
+
+	writew_relaxed(0x1 << cpu_id, mscm_base + MSCM_IRSPRC(hw));
+}
+
+static int vf610_mscm_domain_xlate(struct irq_domain *d,
+				struct device_node *controller,
+				const u32 *intspec, unsigned int intsize,
+				unsigned long *out_hwirq,
+				unsigned int *out_type)
+{
+#ifdef CONFIG_ARM_GIC
+	*out_hwirq += 16;
+#endif
+	return 0;
+}
+static const struct irq_domain_ops routable_irq_domain_ops = {
+	.map = vf610_mscm_domain_map,
+	.unmap = vf610_mscm_domain_unmap,
+	.xlate = vf610_mscm_domain_xlate,
+};
+
+void __init vf610_mscm_init(void)
+{
+	struct device_node *np;
+
+	np = of_find_compatible_node(NULL, NULL, "fsl,vf610-mscm");
+	mscm_base = of_iomap(np, 0);
+
+	if (!mscm_base) {
+		WARN_ON(1);
+		return;
+	}
+
+	cpu_id = readl_relaxed(mscm_base + MSCM_CPxNUM);
+
+	/* Register MSCM as interrupt router */
+	register_routable_domain_ops(&routable_irq_domain_ops);
+
+	cpu_pm_register_notifier(&mscm_notifier_block);
+}
-- 
2.1.3

[PATCH 06/12] ARM: imx: add support for MSCM interrupt router

[Stefan Agner]

This adds support for Vybrids interrupt router for the shared
peripherals. The router is part of the MSCM (Miscellaneous System
Control Module).

Signed-off-by: Stefan Agner <stefan-XLVq0VzYD2Y@public.gmane.org>
---
 arch/arm/mach-imx/Kconfig      |   4 ++
 arch/arm/mach-imx/Makefile     |   1 +
 arch/arm/mach-imx/common.h     |   1 +
 arch/arm/mach-imx/mach-vf610.c |   7 ++
 arch/arm/mach-imx/mscm-vf610.c | 141 +++++++++++++++++++++++++++++++++++++++++
 5 files changed, 154 insertions(+)
 create mode 100644 arch/arm/mach-imx/mscm-vf610.c

diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
index e8627e0..2935972 100644
--- a/arch/arm/mach-imx/Kconfig
+++ b/arch/arm/mach-imx/Kconfig
@@ -58,6 +58,9 @@ config HAVE_IMX_SRC
 	def_bool y if SMP
 	select ARCH_HAS_RESET_CONTROLLER
 
+config HAVE_VF610_MSCM
+	bool
+
 config IMX_HAVE_IOMUX_V1
 	bool
 
@@ -631,6 +634,7 @@ config SOC_IMX6SX
 
 config SOC_VF610
 	bool "Vybrid Family VF610 support"
+	select HAVE_VF610_MSCM
 	select ARM_GIC
 	select PINCTRL_VF610
 	select PL310_ERRATA_769419 if CACHE_L2X0
diff --git a/arch/arm/mach-imx/Makefile b/arch/arm/mach-imx/Makefile
index f5ac685..82b1159 100644
--- a/arch/arm/mach-imx/Makefile
+++ b/arch/arm/mach-imx/Makefile
@@ -108,6 +108,7 @@ obj-$(CONFIG_SOC_IMX50) += mach-imx50.o
 obj-$(CONFIG_SOC_IMX51) += mach-imx51.o
 obj-$(CONFIG_SOC_IMX53) += mach-imx53.o
 
+obj-$(CONFIG_HAVE_VF610_MSCM) += mscm-vf610.o
 obj-$(CONFIG_SOC_VF610) += clk-vf610.o mach-vf610.o
 
 obj-$(CONFIG_SOC_LS1021A) += mach-ls1021a.o
diff --git a/arch/arm/mach-imx/common.h b/arch/arm/mach-imx/common.h
index 59ce8f3..6b5cad9 100644
--- a/arch/arm/mach-imx/common.h
+++ b/arch/arm/mach-imx/common.h
@@ -103,6 +103,7 @@ static inline void imx_smp_prepare(void) {}
 #endif
 void imx_src_init(void);
 void imx_gpc_init(void);
+void vf610_mscm_init(void);
 void imx_gpc_pre_suspend(bool arm_power_off);
 void imx_gpc_post_resume(void);
 void imx_gpc_mask_all(void);
diff --git a/arch/arm/mach-imx/mach-vf610.c b/arch/arm/mach-imx/mach-vf610.c
index c11ab6a..d1d200d 100644
--- a/arch/arm/mach-imx/mach-vf610.c
+++ b/arch/arm/mach-imx/mach-vf610.c
@@ -12,6 +12,12 @@
 #include <asm/mach/arch.h>
 #include <asm/hardware/cache-l2x0.h>
 
+static void __init vf610_init_irq(void)
+{
+	vf610_mscm_init();
+	irqchip_init();
+}
+
 static const char * const vf610_dt_compat[] __initconst = {
 	"fsl,vf610",
 	NULL,
@@ -20,5 +26,6 @@ static const char * const vf610_dt_compat[] __initconst = {
 DT_MACHINE_START(VYBRID_VF610, "Freescale Vybrid VF610 (Device Tree)")
 	.l2c_aux_val	= 0,
 	.l2c_aux_mask	= ~0,
+	.init_irq	= vf610_init_irq,
 	.dt_compat	= vf610_dt_compat,
 MACHINE_END
diff --git a/arch/arm/mach-imx/mscm-vf610.c b/arch/arm/mach-imx/mscm-vf610.c
new file mode 100644
index 0000000..211ea10
--- /dev/null
+++ b/arch/arm/mach-imx/mscm-vf610.c
@@ -0,0 +1,141 @@
+/*
+ * Copyright 2014 Stefan Agner
+ *
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ */
+
+#include <linux/cpu_pm.h>
+#include <linux/io.h>
+#include <linux/irq.h>
+#include <linux/irqdomain.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/irqchip/arm-gic.h>
+#include <linux/irqchip/arm-nvic.h>
+#include "common.h"
+
+#define MSCM_CPxNUM		0x4
+#define MSCM_IRSPRC(n)		(0x880 + 2 * (n))
+#define MSCM_IRSPRC_CPEN_MASK	0x3
+
+#define MSCM_IRSPRC_NUM		112
+
+#ifdef CONFIG_ARM_GIC
+#define MSCM_IRQ_OFFSET		32
+#elif CONFIG_ARM_NVIC
+#define MSCM_IRQ_OFFSET		0
+#endif
+
+static void __iomem *mscm_base;
+static u16 mscm_saved_irsprc[MSCM_IRSPRC_NUM];
+static u16 cpu_id;
+
+static int vf610_mscm_notifier(struct notifier_block *self, unsigned long cmd,
+			       void *v)
+{
+	int i;
+
+	/* Only the primary (boot CPU) should do suspend/resume */
+	if (cpu_id > 0)
+		return NOTIFY_OK;
+
+	switch (cmd) {
+	case CPU_CLUSTER_PM_ENTER:
+		for (i = 0; i < MSCM_IRSPRC_NUM; i++)
+			mscm_saved_irsprc[i] =
+				readw_relaxed(mscm_base + MSCM_IRSPRC(i));
+		break;
+	case CPU_CLUSTER_PM_ENTER_FAILED:
+	case CPU_CLUSTER_PM_EXIT:
+		for (i = 0; i < MSCM_IRSPRC_NUM; i++)
+			writew_relaxed(mscm_saved_irsprc[i],
+				       mscm_base + MSCM_IRSPRC(i));
+		break;
+	}
+
+	return NOTIFY_OK;
+}
+
+static struct notifier_block mscm_notifier_block = {
+	.notifier_call = vf610_mscm_notifier,
+};
+
+static int vf610_mscm_domain_map(struct irq_domain *d, unsigned int irq,
+			       irq_hw_number_t hw)
+{
+	u16 irsprc;
+
+	/* Do not handle non interrupt router IRQs */
+	if (hw < MSCM_IRQ_OFFSET)
+		return 0;
+
+	hw -= MSCM_IRQ_OFFSET;
+	irsprc = readw_relaxed(mscm_base + MSCM_IRSPRC(hw));
+	irsprc &= MSCM_IRSPRC_CPEN_MASK;
+
+	WARN_ON(irsprc);
+
+	writew_relaxed(0x1 << cpu_id, mscm_base + MSCM_IRSPRC(hw));
+
+	return 0;
+}
+
+static void vf610_mscm_domain_unmap(struct irq_domain *d, unsigned int irq)
+{
+	irq_hw_number_t hw = irq_get_irq_data(irq)->hwirq;
+	u16 irsprc;
+
+	/* Do not handle non interrupt router IRQs */
+	if (hw < MSCM_IRQ_OFFSET)
+		return;
+
+	hw -= MSCM_IRQ_OFFSET;
+	irsprc = readw_relaxed(mscm_base + MSCM_IRSPRC(hw));
+	irsprc &= MSCM_IRSPRC_CPEN_MASK;
+
+	WARN_ON(irsprc & ~(0x1 << cpu_id));
+
+	writew_relaxed(0x1 << cpu_id, mscm_base + MSCM_IRSPRC(hw));
+}
+
+static int vf610_mscm_domain_xlate(struct irq_domain *d,
+				struct device_node *controller,
+				const u32 *intspec, unsigned int intsize,
+				unsigned long *out_hwirq,
+				unsigned int *out_type)
+{
+#ifdef CONFIG_ARM_GIC
+	*out_hwirq += 16;
+#endif
+	return 0;
+}
+static const struct irq_domain_ops routable_irq_domain_ops = {
+	.map = vf610_mscm_domain_map,
+	.unmap = vf610_mscm_domain_unmap,
+	.xlate = vf610_mscm_domain_xlate,
+};
+
+void __init vf610_mscm_init(void)
+{
+	struct device_node *np;
+
+	np = of_find_compatible_node(NULL, NULL, "fsl,vf610-mscm");
+	mscm_base = of_iomap(np, 0);
+
+	if (!mscm_base) {
+		WARN_ON(1);
+		return;
+	}
+
+	cpu_id = readl_relaxed(mscm_base + MSCM_CPxNUM);
+
+	/* Register MSCM as interrupt router */
+	register_routable_domain_ops(&routable_irq_domain_ops);
+
+	cpu_pm_register_notifier(&mscm_notifier_block);
+}
-- 
2.1.3

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 06/12] ARM: imx: add support for MSCM interrupt router

[Stefan Agner]

This adds support for Vybrids interrupt router for the shared
peripherals. The router is part of the MSCM (Miscellaneous System
Control Module).

Signed-off-by: Stefan Agner <stefan@agner.ch>
---
 arch/arm/mach-imx/Kconfig      |   4 ++
 arch/arm/mach-imx/Makefile     |   1 +
 arch/arm/mach-imx/common.h     |   1 +
 arch/arm/mach-imx/mach-vf610.c |   7 ++
 arch/arm/mach-imx/mscm-vf610.c | 141 +++++++++++++++++++++++++++++++++++++++++
 5 files changed, 154 insertions(+)
 create mode 100644 arch/arm/mach-imx/mscm-vf610.c

diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
index e8627e0..2935972 100644
--- a/arch/arm/mach-imx/Kconfig
+++ b/arch/arm/mach-imx/Kconfig
@@ -58,6 +58,9 @@ config HAVE_IMX_SRC
 	def_bool y if SMP
 	select ARCH_HAS_RESET_CONTROLLER
 
+config HAVE_VF610_MSCM
+	bool
+
 config IMX_HAVE_IOMUX_V1
 	bool
 
@@ -631,6 +634,7 @@ config SOC_IMX6SX
 
 config SOC_VF610
 	bool "Vybrid Family VF610 support"
+	select HAVE_VF610_MSCM
 	select ARM_GIC
 	select PINCTRL_VF610
 	select PL310_ERRATA_769419 if CACHE_L2X0
diff --git a/arch/arm/mach-imx/Makefile b/arch/arm/mach-imx/Makefile
index f5ac685..82b1159 100644
--- a/arch/arm/mach-imx/Makefile
+++ b/arch/arm/mach-imx/Makefile
@@ -108,6 +108,7 @@ obj-$(CONFIG_SOC_IMX50) += mach-imx50.o
 obj-$(CONFIG_SOC_IMX51) += mach-imx51.o
 obj-$(CONFIG_SOC_IMX53) += mach-imx53.o
 
+obj-$(CONFIG_HAVE_VF610_MSCM) += mscm-vf610.o
 obj-$(CONFIG_SOC_VF610) += clk-vf610.o mach-vf610.o
 
 obj-$(CONFIG_SOC_LS1021A) += mach-ls1021a.o
diff --git a/arch/arm/mach-imx/common.h b/arch/arm/mach-imx/common.h
index 59ce8f3..6b5cad9 100644
--- a/arch/arm/mach-imx/common.h
+++ b/arch/arm/mach-imx/common.h
@@ -103,6 +103,7 @@ static inline void imx_smp_prepare(void) {}
 #endif
 void imx_src_init(void);
 void imx_gpc_init(void);
+void vf610_mscm_init(void);
 void imx_gpc_pre_suspend(bool arm_power_off);
 void imx_gpc_post_resume(void);
 void imx_gpc_mask_all(void);
diff --git a/arch/arm/mach-imx/mach-vf610.c b/arch/arm/mach-imx/mach-vf610.c
index c11ab6a..d1d200d 100644
--- a/arch/arm/mach-imx/mach-vf610.c
+++ b/arch/arm/mach-imx/mach-vf610.c
@@ -12,6 +12,12 @@
 #include <asm/mach/arch.h>
 #include <asm/hardware/cache-l2x0.h>
 
+static void __init vf610_init_irq(void)
+{
+	vf610_mscm_init();
+	irqchip_init();
+}
+
 static const char * const vf610_dt_compat[] __initconst = {
 	"fsl,vf610",
 	NULL,
@@ -20,5 +26,6 @@ static const char * const vf610_dt_compat[] __initconst = {
 DT_MACHINE_START(VYBRID_VF610, "Freescale Vybrid VF610 (Device Tree)")
 	.l2c_aux_val	= 0,
 	.l2c_aux_mask	= ~0,
+	.init_irq	= vf610_init_irq,
 	.dt_compat	= vf610_dt_compat,
 MACHINE_END
diff --git a/arch/arm/mach-imx/mscm-vf610.c b/arch/arm/mach-imx/mscm-vf610.c
new file mode 100644
index 0000000..211ea10
--- /dev/null
+++ b/arch/arm/mach-imx/mscm-vf610.c
@@ -0,0 +1,141 @@
+/*
+ * Copyright 2014 Stefan Agner
+ *
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ */
+
+#include <linux/cpu_pm.h>
+#include <linux/io.h>
+#include <linux/irq.h>
+#include <linux/irqdomain.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/irqchip/arm-gic.h>
+#include <linux/irqchip/arm-nvic.h>
+#include "common.h"
+
+#define MSCM_CPxNUM		0x4
+#define MSCM_IRSPRC(n)		(0x880 + 2 * (n))
+#define MSCM_IRSPRC_CPEN_MASK	0x3
+
+#define MSCM_IRSPRC_NUM		112
+
+#ifdef CONFIG_ARM_GIC
+#define MSCM_IRQ_OFFSET		32
+#elif CONFIG_ARM_NVIC
+#define MSCM_IRQ_OFFSET		0
+#endif
+
+static void __iomem *mscm_base;
+static u16 mscm_saved_irsprc[MSCM_IRSPRC_NUM];
+static u16 cpu_id;
+
+static int vf610_mscm_notifier(struct notifier_block *self, unsigned long cmd,
+			       void *v)
+{
+	int i;
+
+	/* Only the primary (boot CPU) should do suspend/resume */
+	if (cpu_id > 0)
+		return NOTIFY_OK;
+
+	switch (cmd) {
+	case CPU_CLUSTER_PM_ENTER:
+		for (i = 0; i < MSCM_IRSPRC_NUM; i++)
+			mscm_saved_irsprc[i] =
+				readw_relaxed(mscm_base + MSCM_IRSPRC(i));
+		break;
+	case CPU_CLUSTER_PM_ENTER_FAILED:
+	case CPU_CLUSTER_PM_EXIT:
+		for (i = 0; i < MSCM_IRSPRC_NUM; i++)
+			writew_relaxed(mscm_saved_irsprc[i],
+				       mscm_base + MSCM_IRSPRC(i));
+		break;
+	}
+
+	return NOTIFY_OK;
+}
+
+static struct notifier_block mscm_notifier_block = {
+	.notifier_call = vf610_mscm_notifier,
+};
+
+static int vf610_mscm_domain_map(struct irq_domain *d, unsigned int irq,
+			       irq_hw_number_t hw)
+{
+	u16 irsprc;
+
+	/* Do not handle non interrupt router IRQs */
+	if (hw < MSCM_IRQ_OFFSET)
+		return 0;
+
+	hw -= MSCM_IRQ_OFFSET;
+	irsprc = readw_relaxed(mscm_base + MSCM_IRSPRC(hw));
+	irsprc &= MSCM_IRSPRC_CPEN_MASK;
+
+	WARN_ON(irsprc);
+
+	writew_relaxed(0x1 << cpu_id, mscm_base + MSCM_IRSPRC(hw));
+
+	return 0;
+}
+
+static void vf610_mscm_domain_unmap(struct irq_domain *d, unsigned int irq)
+{
+	irq_hw_number_t hw = irq_get_irq_data(irq)->hwirq;
+	u16 irsprc;
+
+	/* Do not handle non interrupt router IRQs */
+	if (hw < MSCM_IRQ_OFFSET)
+		return;
+
+	hw -= MSCM_IRQ_OFFSET;
+	irsprc = readw_relaxed(mscm_base + MSCM_IRSPRC(hw));
+	irsprc &= MSCM_IRSPRC_CPEN_MASK;
+
+	WARN_ON(irsprc & ~(0x1 << cpu_id));
+
+	writew_relaxed(0x1 << cpu_id, mscm_base + MSCM_IRSPRC(hw));
+}
+
+static int vf610_mscm_domain_xlate(struct irq_domain *d,
+				struct device_node *controller,
+				const u32 *intspec, unsigned int intsize,
+				unsigned long *out_hwirq,
+				unsigned int *out_type)
+{
+#ifdef CONFIG_ARM_GIC
+	*out_hwirq += 16;
+#endif
+	return 0;
+}
+static const struct irq_domain_ops routable_irq_domain_ops = {
+	.map = vf610_mscm_domain_map,
+	.unmap = vf610_mscm_domain_unmap,
+	.xlate = vf610_mscm_domain_xlate,
+};
+
+void __init vf610_mscm_init(void)
+{
+	struct device_node *np;
+
+	np = of_find_compatible_node(NULL, NULL, "fsl,vf610-mscm");
+	mscm_base = of_iomap(np, 0);
+
+	if (!mscm_base) {
+		WARN_ON(1);
+		return;
+	}
+
+	cpu_id = readl_relaxed(mscm_base + MSCM_CPxNUM);
+
+	/* Register MSCM as interrupt router */
+	register_routable_domain_ops(&routable_irq_domain_ops);
+
+	cpu_pm_register_notifier(&mscm_notifier_block);
+}
-- 
2.1.3

[PATCH 07/12] Documentation: dt: imx: add MSCM documentation

[Stefan Agner]

Add documentation for Miscellaneous System Control Module found in
Freescale Vybrid SoCs.

Signed-off-by: Stefan Agner <stefan@agner.ch>
---
 .../devicetree/bindings/arm/freescale/fsl,vf610-mscm.txt   | 14 ++++++++++++++
 1 file changed, 14 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/freescale/fsl,vf610-mscm.txt

diff --git a/Documentation/devicetree/bindings/arm/freescale/fsl,vf610-mscm.txt b/Documentation/devicetree/bindings/arm/freescale/fsl,vf610-mscm.txt
new file mode 100644
index 0000000..31c58cc
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/freescale/fsl,vf610-mscm.txt
@@ -0,0 +1,14 @@
+Freescale Vybrid Miscellaneous System Control Module
+
+The MSCM IP contains Access Control and TrustZone Security hardware,
+CPU Configuration registers and Interrupt Router control.
+
+Required properties:
+- compatible : "fsl,vf610-mscm"
+- reg : the register range of the MSCM module
+
+Example:
+	mscm: mscm@40001000 {                 
+		compatible = "fsl,vf610-mscm";
+		reg = <0x40001000 0x1000>;    
+	};                                    
-- 
2.1.3

[PATCH 07/12] Documentation: dt: imx: add MSCM documentation

[Stefan Agner]

Add documentation for Miscellaneous System Control Module found in
Freescale Vybrid SoCs.

Signed-off-by: Stefan Agner <stefan@agner.ch>
---
 .../devicetree/bindings/arm/freescale/fsl,vf610-mscm.txt   | 14 ++++++++++++++
 1 file changed, 14 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/freescale/fsl,vf610-mscm.txt

diff --git a/Documentation/devicetree/bindings/arm/freescale/fsl,vf610-mscm.txt b/Documentation/devicetree/bindings/arm/freescale/fsl,vf610-mscm.txt
new file mode 100644
index 0000000..31c58cc
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/freescale/fsl,vf610-mscm.txt
@@ -0,0 +1,14 @@
+Freescale Vybrid Miscellaneous System Control Module
+
+The MSCM IP contains Access Control and TrustZone Security hardware,
+CPU Configuration registers and Interrupt Router control.
+
+Required properties:
+- compatible : "fsl,vf610-mscm"
+- reg : the register range of the MSCM module
+
+Example:
+	mscm: mscm@40001000 {                 
+		compatible = "fsl,vf610-mscm";
+		reg = <0x40001000 0x1000>;    
+	};                                    
-- 
2.1.3

[PATCH 07/12] Documentation: dt: imx: add MSCM documentation

[Stefan Agner]

Add documentation for Miscellaneous System Control Module found in
Freescale Vybrid SoCs.

Signed-off-by: Stefan Agner <stefan@agner.ch>
---
 .../devicetree/bindings/arm/freescale/fsl,vf610-mscm.txt   | 14 ++++++++++++++
 1 file changed, 14 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/freescale/fsl,vf610-mscm.txt

diff --git a/Documentation/devicetree/bindings/arm/freescale/fsl,vf610-mscm.txt b/Documentation/devicetree/bindings/arm/freescale/fsl,vf610-mscm.txt
new file mode 100644
index 0000000..31c58cc
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/freescale/fsl,vf610-mscm.txt
@@ -0,0 +1,14 @@
+Freescale Vybrid Miscellaneous System Control Module
+
+The MSCM IP contains Access Control and TrustZone Security hardware,
+CPU Configuration registers and Interrupt Router control.
+
+Required properties:
+- compatible : "fsl,vf610-mscm"
+- reg : the register range of the MSCM module
+
+Example:
+	mscm: mscm at 40001000 {                 
+		compatible = "fsl,vf610-mscm";
+		reg = <0x40001000 0x1000>;    
+	};                                    
-- 
2.1.3

[PATCH 08/12] clocksource: add dependencies for Vybrid pit clocksource

[Stefan Agner]

Add the minimal dependencies required to use the Vybrid PIT
clocksource driver. Those are not part of the SoC dependencies.

Signed-off-by: Stefan Agner <stefan@agner.ch>
---
 drivers/clocksource/Kconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
index 9042060..7d757b7 100644
--- a/drivers/clocksource/Kconfig
+++ b/drivers/clocksource/Kconfig
@@ -153,6 +153,8 @@ config FSL_FTM_TIMER
 
 config VF_PIT_TIMER
 	bool
+	select CLKSRC_MMIO
+	select CLKSRC_OF
 	help
 	  Support for Period Interrupt Timer on Freescale Vybrid Family SoCs.
 
-- 
2.1.3

[PATCH 08/12] clocksource: add dependencies for Vybrid pit clocksource

[Stefan Agner]

Add the minimal dependencies required to use the Vybrid PIT
clocksource driver. Those are not part of the SoC dependencies.

Signed-off-by: Stefan Agner <stefan@agner.ch>
---
 drivers/clocksource/Kconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
index 9042060..7d757b7 100644
--- a/drivers/clocksource/Kconfig
+++ b/drivers/clocksource/Kconfig
@@ -153,6 +153,8 @@ config FSL_FTM_TIMER
 
 config VF_PIT_TIMER
 	bool
+	select CLKSRC_MMIO
+	select CLKSRC_OF
 	help
 	  Support for Period Interrupt Timer on Freescale Vybrid Family SoCs.
 
-- 
2.1.3

[PATCH 08/12] clocksource: add dependencies for Vybrid pit clocksource

[Stefan Agner]

Add the minimal dependencies required to use the Vybrid PIT
clocksource driver. Those are not part of the SoC dependencies.

Signed-off-by: Stefan Agner <stefan@agner.ch>
---
 drivers/clocksource/Kconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
index 9042060..7d757b7 100644
--- a/drivers/clocksource/Kconfig
+++ b/drivers/clocksource/Kconfig
@@ -153,6 +153,8 @@ config FSL_FTM_TIMER
 
 config VF_PIT_TIMER
 	bool
+	select CLKSRC_MMIO
+	select CLKSRC_OF
 	help
 	  Support for Period Interrupt Timer on Freescale Vybrid Family SoCs.
 
-- 
2.1.3

[PATCH 09/12] ARM: unify MMU/!MMU addruart calls

[Stefan Agner]

Remove the needless differences between MMU/!MMU addruart calls.
This allows to use the same addruart macro on SoC level. Useful
for SoC consisting of multiple CPUs with and without MMU such as
Freescale Vybrid.

Signed-off-by: Stefan Agner <stefan@agner.ch>
---
 arch/arm/include/debug/efm32.S | 2 +-
 arch/arm/kernel/debug.S        | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/include/debug/efm32.S b/arch/arm/include/debug/efm32.S
index 2265a19..660fa1e 100644
--- a/arch/arm/include/debug/efm32.S
+++ b/arch/arm/include/debug/efm32.S
@@ -16,7 +16,7 @@
 
 #define	UARTn_TXDATA		0x0034
 
-		.macro	addruart, rx, tmp
+		.macro	addruart, rx, tmp, tmp2
 		ldr	\rx, =(CONFIG_DEBUG_UART_PHYS)
 
 		/*
diff --git a/arch/arm/kernel/debug.S b/arch/arm/kernel/debug.S
index 78c91b5..ea9646c 100644
--- a/arch/arm/kernel/debug.S
+++ b/arch/arm/kernel/debug.S
@@ -35,7 +35,7 @@
 
 #else /* !CONFIG_MMU */
 		.macro	addruart_current, rx, tmp1, tmp2
-		addruart	\rx, \tmp1
+		addruart	\rx, \tmp1, \tmp2
 		.endm
 
 #endif /* CONFIG_MMU */
-- 
2.1.3

[PATCH 09/12] ARM: unify MMU/!MMU addruart calls

[Stefan Agner]

Remove the needless differences between MMU/!MMU addruart calls.
This allows to use the same addruart macro on SoC level. Useful
for SoC consisting of multiple CPUs with and without MMU such as
Freescale Vybrid.

Signed-off-by: Stefan Agner <stefan@agner.ch>
---
 arch/arm/include/debug/efm32.S | 2 +-
 arch/arm/kernel/debug.S        | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/include/debug/efm32.S b/arch/arm/include/debug/efm32.S
index 2265a19..660fa1e 100644
--- a/arch/arm/include/debug/efm32.S
+++ b/arch/arm/include/debug/efm32.S
@@ -16,7 +16,7 @@
 
 #define	UARTn_TXDATA		0x0034
 
-		.macro	addruart, rx, tmp
+		.macro	addruart, rx, tmp, tmp2
 		ldr	\rx, =(CONFIG_DEBUG_UART_PHYS)
 
 		/*
diff --git a/arch/arm/kernel/debug.S b/arch/arm/kernel/debug.S
index 78c91b5..ea9646c 100644
--- a/arch/arm/kernel/debug.S
+++ b/arch/arm/kernel/debug.S
@@ -35,7 +35,7 @@
 
 #else /* !CONFIG_MMU */
 		.macro	addruart_current, rx, tmp1, tmp2
-		addruart	\rx, \tmp1
+		addruart	\rx, \tmp1, \tmp2
 		.endm
 
 #endif /* CONFIG_MMU */
-- 
2.1.3

[PATCH 09/12] ARM: unify MMU/!MMU addruart calls

[Stefan Agner]

Remove the needless differences between MMU/!MMU addruart calls.
This allows to use the same addruart macro on SoC level. Useful
for SoC consisting of multiple CPUs with and without MMU such as
Freescale Vybrid.

Signed-off-by: Stefan Agner <stefan@agner.ch>
---
 arch/arm/include/debug/efm32.S | 2 +-
 arch/arm/kernel/debug.S        | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/include/debug/efm32.S b/arch/arm/include/debug/efm32.S
index 2265a19..660fa1e 100644
--- a/arch/arm/include/debug/efm32.S
+++ b/arch/arm/include/debug/efm32.S
@@ -16,7 +16,7 @@
 
 #define	UARTn_TXDATA		0x0034
 
-		.macro	addruart, rx, tmp
+		.macro	addruart, rx, tmp, tmp2
 		ldr	\rx, =(CONFIG_DEBUG_UART_PHYS)
 
 		/*
diff --git a/arch/arm/kernel/debug.S b/arch/arm/kernel/debug.S
index 78c91b5..ea9646c 100644
--- a/arch/arm/kernel/debug.S
+++ b/arch/arm/kernel/debug.S
@@ -35,7 +35,7 @@
 
 #else /* !CONFIG_MMU */
 		.macro	addruart_current, rx, tmp1, tmp2
-		addruart	\rx, \tmp1
+		addruart	\rx, \tmp1, \tmp2
 		.endm
 
 #endif /* CONFIG_MMU */
-- 
2.1.3

[PATCH 10/12] ARM: vf610m4: add new machine and SoC for Vybrid on Cortex-M4

[Stefan Agner]

This patch adds a new machine MACH_MXCM4 which requires !MMU and
!MULTIARCH and is meant as machine for the hetregenous multi-core
Vybrid/i.MX SoC's to run Linux on the Cortex-M4.

The first SoC supported is Vybrid on Cortex-M4 (SOC_VF610M4).

Signed-off-by: Stefan Agner <stefan@agner.ch>
---
 arch/arm/Kconfig                  | 12 ++++++++++++
 arch/arm/Kconfig.debug            |  4 ++--
 arch/arm/Makefile                 |  1 +
 arch/arm/mach-imx/Kconfig         | 29 ++++++++++++++++++++++++++---
 arch/arm/mach-imx/Makefile        |  1 +
 arch/arm/mach-imx/Makefile.boot   |  0
 arch/arm/mach-imx/mach-vf610m4.c  | 31 +++++++++++++++++++++++++++++++
 drivers/mmc/host/Kconfig          |  2 +-
 drivers/pinctrl/freescale/Kconfig |  2 +-
 9 files changed, 75 insertions(+), 7 deletions(-)
 create mode 100644 arch/arm/mach-imx/Makefile.boot
 create mode 100644 arch/arm/mach-imx/mach-vf610m4.c

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 89c4b5c..fdebe18 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -459,6 +459,18 @@ config ARCH_FOOTBRIDGE
 	  Support for systems based on the DC21285 companion chip
 	  ("FootBridge"), such as the Simtec CATS and the Rebel NetWinder.
 
+menuconfig ARCH_MXCM4
+	bool "Freescale Vybrid/i.MX family on Cortex-M4" if !MMU
+	select ARCH_REQUIRE_GPIOLIB
+	select ARM_CPU_SUSPEND if PM
+	select CLKSRC_MMIO
+	select GENERIC_IRQ_CHIP
+	select PINCTRL
+	select PM_OPP if PM
+	select SOC_BUS
+	help
+	  Support for Freescale Vybrid/iMX-based family of processors on Cortex-M4
+
 config ARCH_NETX
 	bool "Hilscher NetX based"
 	select ARM_VIC
diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index 03dc4c1..f479727 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -459,7 +459,7 @@ choice
 
 	config DEBUG_VF_UART
 		bool "Vybrid UART"
-		depends on SOC_VF610
+		depends on SOC_VF610 || SOC_VF610M4
 		help
 		  Say Y here if you want kernel low-level debugging support
 		  on Vybrid based platforms.
@@ -1026,7 +1026,7 @@ config DEBUG_VF_UART_PORT
 	int "Vybrid Debug UART Port Selection" if DEBUG_VF_UART
 	default 1
 	range 0 3
-	depends on SOC_VF610
+	depends on SOC_VF610 || SOC_VF610M4
 	help
 	  Choose UART port on which kernel low-level debug messages
 	  should be output.
diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index 034a949..0b84168 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -174,6 +174,7 @@ machine-$(CONFIG_ARCH_MSM)		+= msm
 machine-$(CONFIG_ARCH_MV78XX0)		+= mv78xx0
 machine-$(CONFIG_ARCH_MVEBU)		+= mvebu
 machine-$(CONFIG_ARCH_MXC)		+= imx
+machine-$(CONFIG_ARCH_MXCM4)		+= imx
 machine-$(CONFIG_ARCH_MEDIATEK)		+= mediatek
 machine-$(CONFIG_ARCH_MXS)		+= mxs
 machine-$(CONFIG_ARCH_NETX)		+= netx
diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
index 2935972..56635d5 100644
--- a/arch/arm/mach-imx/Kconfig
+++ b/arch/arm/mach-imx/Kconfig
@@ -1,3 +1,6 @@
+config HAVE_VF610_MSCM
+	bool
+
 menuconfig ARCH_MXC
 	bool "Freescale i.MX family" if ARCH_MULTI_V4_V5 || ARCH_MULTI_V6_V7
 	select ARCH_REQUIRE_GPIOLIB
@@ -58,9 +61,6 @@ config HAVE_IMX_SRC
 	def_bool y if SMP
 	select ARCH_HAS_RESET_CONTROLLER
 
-config HAVE_VF610_MSCM
-	bool
-
 config IMX_HAVE_IOMUX_V1
 	bool
 
@@ -677,3 +677,26 @@ endif
 source "arch/arm/mach-imx/devices/Kconfig"
 
 endif
+
+if !MMU && ARCH_MXCM4
+
+config SOC_VF610M4
+	bool "Vybrid Family VF610 support for Cortex-M4"
+	select HAVE_VF610_MSCM
+	select ARCH_REQUIRE_GPIOLIB
+	select PINCTRL_VF610
+	select PINCTRL_IMX
+	select ARM_NVIC
+	select AUTO_ZRELADDR
+	select CPU_V7M
+	select COMMON_CLK
+	select GENERIC_CLOCKEVENTS
+	select NO_DMA
+	select NO_IOPORT_MAP
+	select SPARSE_IRQ
+	select USE_OF
+	select VF_PIT_TIMER
+	help
+	  Support for Vybrid Familiy VF610's Cortex-M4
+
+endif
diff --git a/arch/arm/mach-imx/Makefile b/arch/arm/mach-imx/Makefile
index 82b1159..21fb423 100644
--- a/arch/arm/mach-imx/Makefile
+++ b/arch/arm/mach-imx/Makefile
@@ -110,6 +110,7 @@ obj-$(CONFIG_SOC_IMX53) += mach-imx53.o
 
 obj-$(CONFIG_HAVE_VF610_MSCM) += mscm-vf610.o
 obj-$(CONFIG_SOC_VF610) += clk-vf610.o mach-vf610.o
+obj-$(CONFIG_SOC_VF610M4) += clk-vf610.o mach-vf610m4.o
 
 obj-$(CONFIG_SOC_LS1021A) += mach-ls1021a.o
 
diff --git a/arch/arm/mach-imx/Makefile.boot b/arch/arm/mach-imx/Makefile.boot
new file mode 100644
index 0000000..e69de29
diff --git a/arch/arm/mach-imx/mach-vf610m4.c b/arch/arm/mach-imx/mach-vf610m4.c
new file mode 100644
index 0000000..245788f
--- /dev/null
+++ b/arch/arm/mach-imx/mach-vf610m4.c
@@ -0,0 +1,31 @@
+/*
+ * Copyright 2014 Stefan Agner
+ *
+ * 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/irqchip.h>
+#include <linux/kernel.h>
+#include <asm/v7m.h>
+#include <asm/mach/arch.h>
+#include "common.h"
+
+static void __init vf610m4_init_irq(void)
+{
+	vf610_mscm_init();
+	irqchip_init();
+}
+
+static const char *const vf610m4_compat[] __initconst = {
+	"fsl,vf610m4",
+	NULL
+};
+
+DT_MACHINE_START(VF610M4DT, "VF610 on Cortex-M4 (Device Tree Support)")
+	.dt_compat = vf610m4_compat,
+	.init_irq = vf610m4_init_irq,
+	.restart = armv7m_restart,
+MACHINE_END
diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
index 1386065..bfbec2d 100644
--- a/drivers/mmc/host/Kconfig
+++ b/drivers/mmc/host/Kconfig
@@ -166,7 +166,7 @@ config MMC_SDHCI_CNS3XXX
 
 config MMC_SDHCI_ESDHC_IMX
 	tristate "SDHCI support for the Freescale eSDHC/uSDHC i.MX controller"
-	depends on ARCH_MXC
+	depends on ARCH_MXC || ARCH_MXCM4
 	depends on MMC_SDHCI_PLTFM
 	select MMC_SDHCI_IO_ACCESSORS
 	help
diff --git a/drivers/pinctrl/freescale/Kconfig b/drivers/pinctrl/freescale/Kconfig
index 16aac38..5271ca2 100644
--- a/drivers/pinctrl/freescale/Kconfig
+++ b/drivers/pinctrl/freescale/Kconfig
@@ -89,7 +89,7 @@ config PINCTRL_IMX6SX
 
 config PINCTRL_VF610
 	bool "Freescale Vybrid VF610 pinctrl driver"
-	depends on SOC_VF610
+	depends on SOC_VF610 || SOC_VF610M4
 	select PINCTRL_IMX
 	help
 	  Say Y here to enable the Freescale Vybrid VF610 pinctrl driver
-- 
2.1.3

[PATCH 10/12] ARM: vf610m4: add new machine and SoC for Vybrid on Cortex-M4

[Stefan Agner]

This patch adds a new machine MACH_MXCM4 which requires !MMU and
!MULTIARCH and is meant as machine for the hetregenous multi-core
Vybrid/i.MX SoC's to run Linux on the Cortex-M4.

The first SoC supported is Vybrid on Cortex-M4 (SOC_VF610M4).

Signed-off-by: Stefan Agner <stefan@agner.ch>
---
 arch/arm/Kconfig                  | 12 ++++++++++++
 arch/arm/Kconfig.debug            |  4 ++--
 arch/arm/Makefile                 |  1 +
 arch/arm/mach-imx/Kconfig         | 29 ++++++++++++++++++++++++++---
 arch/arm/mach-imx/Makefile        |  1 +
 arch/arm/mach-imx/Makefile.boot   |  0
 arch/arm/mach-imx/mach-vf610m4.c  | 31 +++++++++++++++++++++++++++++++
 drivers/mmc/host/Kconfig          |  2 +-
 drivers/pinctrl/freescale/Kconfig |  2 +-
 9 files changed, 75 insertions(+), 7 deletions(-)
 create mode 100644 arch/arm/mach-imx/Makefile.boot
 create mode 100644 arch/arm/mach-imx/mach-vf610m4.c

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 89c4b5c..fdebe18 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -459,6 +459,18 @@ config ARCH_FOOTBRIDGE
 	  Support for systems based on the DC21285 companion chip
 	  ("FootBridge"), such as the Simtec CATS and the Rebel NetWinder.
 
+menuconfig ARCH_MXCM4
+	bool "Freescale Vybrid/i.MX family on Cortex-M4" if !MMU
+	select ARCH_REQUIRE_GPIOLIB
+	select ARM_CPU_SUSPEND if PM
+	select CLKSRC_MMIO
+	select GENERIC_IRQ_CHIP
+	select PINCTRL
+	select PM_OPP if PM
+	select SOC_BUS
+	help
+	  Support for Freescale Vybrid/iMX-based family of processors on Cortex-M4
+
 config ARCH_NETX
 	bool "Hilscher NetX based"
 	select ARM_VIC
diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index 03dc4c1..f479727 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -459,7 +459,7 @@ choice
 
 	config DEBUG_VF_UART
 		bool "Vybrid UART"
-		depends on SOC_VF610
+		depends on SOC_VF610 || SOC_VF610M4
 		help
 		  Say Y here if you want kernel low-level debugging support
 		  on Vybrid based platforms.
@@ -1026,7 +1026,7 @@ config DEBUG_VF_UART_PORT
 	int "Vybrid Debug UART Port Selection" if DEBUG_VF_UART
 	default 1
 	range 0 3
-	depends on SOC_VF610
+	depends on SOC_VF610 || SOC_VF610M4
 	help
 	  Choose UART port on which kernel low-level debug messages
 	  should be output.
diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index 034a949..0b84168 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -174,6 +174,7 @@ machine-$(CONFIG_ARCH_MSM)		+= msm
 machine-$(CONFIG_ARCH_MV78XX0)		+= mv78xx0
 machine-$(CONFIG_ARCH_MVEBU)		+= mvebu
 machine-$(CONFIG_ARCH_MXC)		+= imx
+machine-$(CONFIG_ARCH_MXCM4)		+= imx
 machine-$(CONFIG_ARCH_MEDIATEK)		+= mediatek
 machine-$(CONFIG_ARCH_MXS)		+= mxs
 machine-$(CONFIG_ARCH_NETX)		+= netx
diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
index 2935972..56635d5 100644
--- a/arch/arm/mach-imx/Kconfig
+++ b/arch/arm/mach-imx/Kconfig
@@ -1,3 +1,6 @@
+config HAVE_VF610_MSCM
+	bool
+
 menuconfig ARCH_MXC
 	bool "Freescale i.MX family" if ARCH_MULTI_V4_V5 || ARCH_MULTI_V6_V7
 	select ARCH_REQUIRE_GPIOLIB
@@ -58,9 +61,6 @@ config HAVE_IMX_SRC
 	def_bool y if SMP
 	select ARCH_HAS_RESET_CONTROLLER
 
-config HAVE_VF610_MSCM
-	bool
-
 config IMX_HAVE_IOMUX_V1
 	bool
 
@@ -677,3 +677,26 @@ endif
 source "arch/arm/mach-imx/devices/Kconfig"
 
 endif
+
+if !MMU && ARCH_MXCM4
+
+config SOC_VF610M4
+	bool "Vybrid Family VF610 support for Cortex-M4"
+	select HAVE_VF610_MSCM
+	select ARCH_REQUIRE_GPIOLIB
+	select PINCTRL_VF610
+	select PINCTRL_IMX
+	select ARM_NVIC
+	select AUTO_ZRELADDR
+	select CPU_V7M
+	select COMMON_CLK
+	select GENERIC_CLOCKEVENTS
+	select NO_DMA
+	select NO_IOPORT_MAP
+	select SPARSE_IRQ
+	select USE_OF
+	select VF_PIT_TIMER
+	help
+	  Support for Vybrid Familiy VF610's Cortex-M4
+
+endif
diff --git a/arch/arm/mach-imx/Makefile b/arch/arm/mach-imx/Makefile
index 82b1159..21fb423 100644
--- a/arch/arm/mach-imx/Makefile
+++ b/arch/arm/mach-imx/Makefile
@@ -110,6 +110,7 @@ obj-$(CONFIG_SOC_IMX53) += mach-imx53.o
 
 obj-$(CONFIG_HAVE_VF610_MSCM) += mscm-vf610.o
 obj-$(CONFIG_SOC_VF610) += clk-vf610.o mach-vf610.o
+obj-$(CONFIG_SOC_VF610M4) += clk-vf610.o mach-vf610m4.o
 
 obj-$(CONFIG_SOC_LS1021A) += mach-ls1021a.o
 
diff --git a/arch/arm/mach-imx/Makefile.boot b/arch/arm/mach-imx/Makefile.boot
new file mode 100644
index 0000000..e69de29
diff --git a/arch/arm/mach-imx/mach-vf610m4.c b/arch/arm/mach-imx/mach-vf610m4.c
new file mode 100644
index 0000000..245788f
--- /dev/null
+++ b/arch/arm/mach-imx/mach-vf610m4.c
@@ -0,0 +1,31 @@
+/*
+ * Copyright 2014 Stefan Agner
+ *
+ * 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/irqchip.h>
+#include <linux/kernel.h>
+#include <asm/v7m.h>
+#include <asm/mach/arch.h>
+#include "common.h"
+
+static void __init vf610m4_init_irq(void)
+{
+	vf610_mscm_init();
+	irqchip_init();
+}
+
+static const char *const vf610m4_compat[] __initconst = {
+	"fsl,vf610m4",
+	NULL
+};
+
+DT_MACHINE_START(VF610M4DT, "VF610 on Cortex-M4 (Device Tree Support)")
+	.dt_compat = vf610m4_compat,
+	.init_irq = vf610m4_init_irq,
+	.restart = armv7m_restart,
+MACHINE_END
diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
index 1386065..bfbec2d 100644
--- a/drivers/mmc/host/Kconfig
+++ b/drivers/mmc/host/Kconfig
@@ -166,7 +166,7 @@ config MMC_SDHCI_CNS3XXX
 
 config MMC_SDHCI_ESDHC_IMX
 	tristate "SDHCI support for the Freescale eSDHC/uSDHC i.MX controller"
-	depends on ARCH_MXC
+	depends on ARCH_MXC || ARCH_MXCM4
 	depends on MMC_SDHCI_PLTFM
 	select MMC_SDHCI_IO_ACCESSORS
 	help
diff --git a/drivers/pinctrl/freescale/Kconfig b/drivers/pinctrl/freescale/Kconfig
index 16aac38..5271ca2 100644
--- a/drivers/pinctrl/freescale/Kconfig
+++ b/drivers/pinctrl/freescale/Kconfig
@@ -89,7 +89,7 @@ config PINCTRL_IMX6SX
 
 config PINCTRL_VF610
 	bool "Freescale Vybrid VF610 pinctrl driver"
-	depends on SOC_VF610
+	depends on SOC_VF610 || SOC_VF610M4
 	select PINCTRL_IMX
 	help
 	  Say Y here to enable the Freescale Vybrid VF610 pinctrl driver
-- 
2.1.3

[PATCH 11/12] ARM: dts: add support for Vybrid running on Cortex-M4

[Stefan Agner]

This adds an initial device tree to run Linux on the Cortex-M4 on
the Vybrid based Colibri VF61.

Signed-off-by: Stefan Agner <stefan@agner.ch>
---
 arch/arm/boot/dts/Makefile            |  1 +
 arch/arm/boot/dts/vf610m4-colibri.dts | 52 +++++++++++++++++++++++++++++++++++
 arch/arm/boot/dts/vf610m4.dtsi        | 33 ++++++++++++++++++++++
 3 files changed, 86 insertions(+)
 create mode 100644 arch/arm/boot/dts/vf610m4-colibri.dts
 create mode 100644 arch/arm/boot/dts/vf610m4.dtsi

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 4600499..a2f3a9e 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -67,6 +67,7 @@ dtb-$(CONFIG_ARCH_BRCMSTB) += \
 dtb-$(CONFIG_ARCH_DAVINCI) += da850-enbw-cmc.dtb \
 	da850-evm.dtb
 dtb-$(CONFIG_ARCH_EFM32) += efm32gg-dk3750.dtb
+dtb-$(CONFIG_SOC_VF610M4) += vf610m4-colibri.dtb
 dtb-$(CONFIG_ARCH_EXYNOS) += exynos4210-origen.dtb \
 	exynos4210-smdkv310.dtb \
 	exynos4210-trats.dtb \
diff --git a/arch/arm/boot/dts/vf610m4-colibri.dts b/arch/arm/boot/dts/vf610m4-colibri.dts
new file mode 100644
index 0000000..051ee0f
--- /dev/null
+++ b/arch/arm/boot/dts/vf610m4-colibri.dts
@@ -0,0 +1,52 @@
+/*
+ * Device tree for Colibri VF61 Cortex-M4 support
+ *
+ * Copyright 2014 Stefan Agner
+ *
+ * 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.
+ */
+
+/dts-v1/;
+#include "vf610m4.dtsi"
+
+/ {
+	model = "VF610 Cortex-M4";
+	compatible = "fsl,vf610m4";
+
+	chosen {
+		bootargs = "console=ttyLP2,115200 ihash_entries=64 dhash_entries=64 earlyprintk clk_ignore_unused init=/linuxrc rw";
+	};
+
+	memory {
+		reg = <0x8c000000 0x3000000>;
+	};
+};
+
+&esdhc1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_esdhc1>;
+	status = "okay";
+};
+
+&uart2 {
+	status = "okay";
+};
+
+&iomuxc {
+	vf610-colibri {
+		pinctrl_esdhc1: esdhc1grp {
+			fsl,pins = <
+				VF610_PAD_PTA24__ESDHC1_CLK	0x31ef
+				VF610_PAD_PTA25__ESDHC1_CMD	0x31ef
+				VF610_PAD_PTA26__ESDHC1_DAT0	0x31ef
+				VF610_PAD_PTA27__ESDHC1_DAT1	0x31ef
+				VF610_PAD_PTA28__ESDHC1_DATA2	0x31ef
+				VF610_PAD_PTA29__ESDHC1_DAT3	0x31ef
+				VF610_PAD_PTB20__GPIO_42	0x219d
+			>;
+		};
+	};
+};
diff --git a/arch/arm/boot/dts/vf610m4.dtsi b/arch/arm/boot/dts/vf610m4.dtsi
new file mode 100644
index 0000000..6ee6b0c
--- /dev/null
+++ b/arch/arm/boot/dts/vf610m4.dtsi
@@ -0,0 +1,33 @@
+/*
+ * Device tree for VF6xx Cortex-M4 support
+ */
+
+#include "armv7-m.dtsi"
+#include "vfxxx.dtsi"
+
+/ {
+
+	soc {
+		interrupt-parent = <&nvic>;
+	};
+};
+
+&esdhc1 {
+	interrupts = <28>;
+};
+
+&pit {
+	interrupts = <39>;
+};
+
+&uart0 {
+	interrupts = <61>;
+};
+
+&uart1 {
+	interrupts = <62>;
+};
+
+&uart2 {
+	interrupts = <63>;
+};
-- 
2.1.3

[PATCH 11/12] ARM: dts: add support for Vybrid running on Cortex-M4

[Stefan Agner]

This adds an initial device tree to run Linux on the Cortex-M4 on
the Vybrid based Colibri VF61.

Signed-off-by: Stefan Agner <stefan@agner.ch>
---
 arch/arm/boot/dts/Makefile            |  1 +
 arch/arm/boot/dts/vf610m4-colibri.dts | 52 +++++++++++++++++++++++++++++++++++
 arch/arm/boot/dts/vf610m4.dtsi        | 33 ++++++++++++++++++++++
 3 files changed, 86 insertions(+)
 create mode 100644 arch/arm/boot/dts/vf610m4-colibri.dts
 create mode 100644 arch/arm/boot/dts/vf610m4.dtsi

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 4600499..a2f3a9e 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -67,6 +67,7 @@ dtb-$(CONFIG_ARCH_BRCMSTB) += \
 dtb-$(CONFIG_ARCH_DAVINCI) += da850-enbw-cmc.dtb \
 	da850-evm.dtb
 dtb-$(CONFIG_ARCH_EFM32) += efm32gg-dk3750.dtb
+dtb-$(CONFIG_SOC_VF610M4) += vf610m4-colibri.dtb
 dtb-$(CONFIG_ARCH_EXYNOS) += exynos4210-origen.dtb \
 	exynos4210-smdkv310.dtb \
 	exynos4210-trats.dtb \
diff --git a/arch/arm/boot/dts/vf610m4-colibri.dts b/arch/arm/boot/dts/vf610m4-colibri.dts
new file mode 100644
index 0000000..051ee0f
--- /dev/null
+++ b/arch/arm/boot/dts/vf610m4-colibri.dts
@@ -0,0 +1,52 @@
+/*
+ * Device tree for Colibri VF61 Cortex-M4 support
+ *
+ * Copyright 2014 Stefan Agner
+ *
+ * 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.
+ */
+
+/dts-v1/;
+#include "vf610m4.dtsi"
+
+/ {
+	model = "VF610 Cortex-M4";
+	compatible = "fsl,vf610m4";
+
+	chosen {
+		bootargs = "console=ttyLP2,115200 ihash_entries=64 dhash_entries=64 earlyprintk clk_ignore_unused init=/linuxrc rw";
+	};
+
+	memory {
+		reg = <0x8c000000 0x3000000>;
+	};
+};
+
+&esdhc1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_esdhc1>;
+	status = "okay";
+};
+
+&uart2 {
+	status = "okay";
+};
+
+&iomuxc {
+	vf610-colibri {
+		pinctrl_esdhc1: esdhc1grp {
+			fsl,pins = <
+				VF610_PAD_PTA24__ESDHC1_CLK	0x31ef
+				VF610_PAD_PTA25__ESDHC1_CMD	0x31ef
+				VF610_PAD_PTA26__ESDHC1_DAT0	0x31ef
+				VF610_PAD_PTA27__ESDHC1_DAT1	0x31ef
+				VF610_PAD_PTA28__ESDHC1_DATA2	0x31ef
+				VF610_PAD_PTA29__ESDHC1_DAT3	0x31ef
+				VF610_PAD_PTB20__GPIO_42	0x219d
+			>;
+		};
+	};
+};
diff --git a/arch/arm/boot/dts/vf610m4.dtsi b/arch/arm/boot/dts/vf610m4.dtsi
new file mode 100644
index 0000000..6ee6b0c
--- /dev/null
+++ b/arch/arm/boot/dts/vf610m4.dtsi
@@ -0,0 +1,33 @@
+/*
+ * Device tree for VF6xx Cortex-M4 support
+ */
+
+#include "armv7-m.dtsi"
+#include "vfxxx.dtsi"
+
+/ {
+
+	soc {
+		interrupt-parent = <&nvic>;
+	};
+};
+
+&esdhc1 {
+	interrupts = <28>;
+};
+
+&pit {
+	interrupts = <39>;
+};
+
+&uart0 {
+	interrupts = <61>;
+};
+
+&uart1 {
+	interrupts = <62>;
+};
+
+&uart2 {
+	interrupts = <63>;
+};
-- 
2.1.3

[PATCH 12/12] ARM: vf610m4: add defconfig for Linux on Vybrids Cortex-M4

[Stefan Agner]

Add defconfig for Linux on Vybrid (vf610) on the secondary Cortex-
M4 CPU. The use of a XIP image has been tested which needs to be
loaded (e.g. using the custom m4boot loader) to the end of the
available RAM at address 0x8f000000. The Cortex-M4 has a code-alias
which makes sure that the instructions get fetched through the code
bus (alias starts at 0x00800000 => 0x80800000 in system address).
Hence, to get optimal performance, use 0x0f000000 as XIP_PHYS_ADDR.
This address is additionally shifted by the length of the minimal
loader which is inserted by m4boot. Currently, this offset is 0x80.

The standard DRAM base address is configured to 0x8C000000, which
gives the Cortex-M4 48MiB of RAM.

Signed-off-by: Stefan Agner <stefan@agner.ch>
---
 arch/arm/configs/vf610m4_defconfig | 49 ++++++++++++++++++++++++++++++++++++++
 1 file changed, 49 insertions(+)
 create mode 100644 arch/arm/configs/vf610m4_defconfig

diff --git a/arch/arm/configs/vf610m4_defconfig b/arch/arm/configs/vf610m4_defconfig
new file mode 100644
index 0000000..121908b
--- /dev/null
+++ b/arch/arm/configs/vf610m4_defconfig
@@ -0,0 +1,49 @@
+CONFIG_NAMESPACES=y
+CONFIG_BLK_DEV_INITRD=y
+CONFIG_RD_LZO=y
+# CONFIG_KALLSYMS is not set
+CONFIG_EMBEDDED=y
+# CONFIG_MMU is not set
+CONFIG_ARCH_MXCM4=y
+CONFIG_SOC_VF610M4=y
+# CONFIG_KUSER_HELPERS is not set
+CONFIG_SET_MEM_PARAM=y
+CONFIG_DRAM_BASE=0x8c000000
+CONFIG_FLASH_MEM_BASE=0x8f000000
+CONFIG_FLASH_SIZE=0x01000000
+CONFIG_CMDLINE="console=/dev/ttyLP0 earlyprintk"
+CONFIG_XIP_KERNEL=y
+CONFIG_XIP_PHYS_ADDR=0x0f000080
+CONFIG_BINFMT_FLAT=y
+CONFIG_BINFMT_ZFLAT=y
+CONFIG_BINFMT_SHARED_FLAT=y
+# CONFIG_SUSPEND is not set
+# CONFIG_UEVENT_HELPER is not set
+# CONFIG_STANDALONE is not set
+# CONFIG_PREVENT_FIRMWARE_BUILD is not set
+# CONFIG_FIRMWARE_IN_KERNEL is not set
+CONFIG_BLK_DEV_RAM=y
+CONFIG_BLK_DEV_RAM_COUNT=4
+CONFIG_BLK_DEV_XIP=y
+CONFIG_SRAM=y
+# CONFIG_INPUT_MOUSEDEV is not set
+# CONFIG_KEYBOARD_ATKBD is not set
+CONFIG_KEYBOARD_GPIO=y
+CONFIG_KEYBOARD_GPIO_POLLED=y
+# CONFIG_INPUT_MOUSE is not set
+# CONFIG_SERIO is not set
+CONFIG_SERIAL_FSL_LPUART=y
+CONFIG_SERIAL_FSL_LPUART_CONSOLE=y
+# CONFIG_HW_RANDOM is not set
+# CONFIG_HID is not set
+# CONFIG_USB_SUPPORT is not set
+CONFIG_MMC=y
+CONFIG_MMC_SDHCI=y
+CONFIG_MMC_SDHCI_PLTFM=y
+CONFIG_MMC_SDHCI_ESDHC_IMX=y
+# CONFIG_IOMMU_SUPPORT is not set
+CONFIG_EXT4_FS=y
+# CONFIG_MISC_FILESYSTEMS is not set
+CONFIG_DEBUG_MEMORY_INIT=y
+# CONFIG_FTRACE is not set
+# CONFIG_CRYPTO_HW is not set
-- 
2.1.3

[PATCH 12/12] ARM: vf610m4: add defconfig for Linux on Vybrids Cortex-M4

[Stefan Agner]

Add defconfig for Linux on Vybrid (vf610) on the secondary Cortex-
M4 CPU. The use of a XIP image has been tested which needs to be
loaded (e.g. using the custom m4boot loader) to the end of the
available RAM at address 0x8f000000. The Cortex-M4 has a code-alias
which makes sure that the instructions get fetched through the code
bus (alias starts at 0x00800000 => 0x80800000 in system address).
Hence, to get optimal performance, use 0x0f000000 as XIP_PHYS_ADDR.
This address is additionally shifted by the length of the minimal
loader which is inserted by m4boot. Currently, this offset is 0x80.

The standard DRAM base address is configured to 0x8C000000, which
gives the Cortex-M4 48MiB of RAM.

Signed-off-by: Stefan Agner <stefan-XLVq0VzYD2Y@public.gmane.org>
---
 arch/arm/configs/vf610m4_defconfig | 49 ++++++++++++++++++++++++++++++++++++++
 1 file changed, 49 insertions(+)
 create mode 100644 arch/arm/configs/vf610m4_defconfig

diff --git a/arch/arm/configs/vf610m4_defconfig b/arch/arm/configs/vf610m4_defconfig
new file mode 100644
index 0000000..121908b
--- /dev/null
+++ b/arch/arm/configs/vf610m4_defconfig
@@ -0,0 +1,49 @@
+CONFIG_NAMESPACES=y
+CONFIG_BLK_DEV_INITRD=y
+CONFIG_RD_LZO=y
+# CONFIG_KALLSYMS is not set
+CONFIG_EMBEDDED=y
+# CONFIG_MMU is not set
+CONFIG_ARCH_MXCM4=y
+CONFIG_SOC_VF610M4=y
+# CONFIG_KUSER_HELPERS is not set
+CONFIG_SET_MEM_PARAM=y
+CONFIG_DRAM_BASE=0x8c000000
+CONFIG_FLASH_MEM_BASE=0x8f000000
+CONFIG_FLASH_SIZE=0x01000000
+CONFIG_CMDLINE="console=/dev/ttyLP0 earlyprintk"
+CONFIG_XIP_KERNEL=y
+CONFIG_XIP_PHYS_ADDR=0x0f000080
+CONFIG_BINFMT_FLAT=y
+CONFIG_BINFMT_ZFLAT=y
+CONFIG_BINFMT_SHARED_FLAT=y
+# CONFIG_SUSPEND is not set
+# CONFIG_UEVENT_HELPER is not set
+# CONFIG_STANDALONE is not set
+# CONFIG_PREVENT_FIRMWARE_BUILD is not set
+# CONFIG_FIRMWARE_IN_KERNEL is not set
+CONFIG_BLK_DEV_RAM=y
+CONFIG_BLK_DEV_RAM_COUNT=4
+CONFIG_BLK_DEV_XIP=y
+CONFIG_SRAM=y
+# CONFIG_INPUT_MOUSEDEV is not set
+# CONFIG_KEYBOARD_ATKBD is not set
+CONFIG_KEYBOARD_GPIO=y
+CONFIG_KEYBOARD_GPIO_POLLED=y
+# CONFIG_INPUT_MOUSE is not set
+# CONFIG_SERIO is not set
+CONFIG_SERIAL_FSL_LPUART=y
+CONFIG_SERIAL_FSL_LPUART_CONSOLE=y
+# CONFIG_HW_RANDOM is not set
+# CONFIG_HID is not set
+# CONFIG_USB_SUPPORT is not set
+CONFIG_MMC=y
+CONFIG_MMC_SDHCI=y
+CONFIG_MMC_SDHCI_PLTFM=y
+CONFIG_MMC_SDHCI_ESDHC_IMX=y
+# CONFIG_IOMMU_SUPPORT is not set
+CONFIG_EXT4_FS=y
+# CONFIG_MISC_FILESYSTEMS is not set
+CONFIG_DEBUG_MEMORY_INIT=y
+# CONFIG_FTRACE is not set
+# CONFIG_CRYPTO_HW is not set
-- 
2.1.3

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 12/12] ARM: vf610m4: add defconfig for Linux on Vybrids Cortex-M4

[Stefan Agner]

Add defconfig for Linux on Vybrid (vf610) on the secondary Cortex-
M4 CPU. The use of a XIP image has been tested which needs to be
loaded (e.g. using the custom m4boot loader) to the end of the
available RAM at address 0x8f000000. The Cortex-M4 has a code-alias
which makes sure that the instructions get fetched through the code
bus (alias starts at 0x00800000 => 0x80800000 in system address).
Hence, to get optimal performance, use 0x0f000000 as XIP_PHYS_ADDR.
This address is additionally shifted by the length of the minimal
loader which is inserted by m4boot. Currently, this offset is 0x80.

The standard DRAM base address is configured to 0x8C000000, which
gives the Cortex-M4 48MiB of RAM.

Signed-off-by: Stefan Agner <stefan@agner.ch>
---
 arch/arm/configs/vf610m4_defconfig | 49 ++++++++++++++++++++++++++++++++++++++
 1 file changed, 49 insertions(+)
 create mode 100644 arch/arm/configs/vf610m4_defconfig

diff --git a/arch/arm/configs/vf610m4_defconfig b/arch/arm/configs/vf610m4_defconfig
new file mode 100644
index 0000000..121908b
--- /dev/null
+++ b/arch/arm/configs/vf610m4_defconfig
@@ -0,0 +1,49 @@
+CONFIG_NAMESPACES=y
+CONFIG_BLK_DEV_INITRD=y
+CONFIG_RD_LZO=y
+# CONFIG_KALLSYMS is not set
+CONFIG_EMBEDDED=y
+# CONFIG_MMU is not set
+CONFIG_ARCH_MXCM4=y
+CONFIG_SOC_VF610M4=y
+# CONFIG_KUSER_HELPERS is not set
+CONFIG_SET_MEM_PARAM=y
+CONFIG_DRAM_BASE=0x8c000000
+CONFIG_FLASH_MEM_BASE=0x8f000000
+CONFIG_FLASH_SIZE=0x01000000
+CONFIG_CMDLINE="console=/dev/ttyLP0 earlyprintk"
+CONFIG_XIP_KERNEL=y
+CONFIG_XIP_PHYS_ADDR=0x0f000080
+CONFIG_BINFMT_FLAT=y
+CONFIG_BINFMT_ZFLAT=y
+CONFIG_BINFMT_SHARED_FLAT=y
+# CONFIG_SUSPEND is not set
+# CONFIG_UEVENT_HELPER is not set
+# CONFIG_STANDALONE is not set
+# CONFIG_PREVENT_FIRMWARE_BUILD is not set
+# CONFIG_FIRMWARE_IN_KERNEL is not set
+CONFIG_BLK_DEV_RAM=y
+CONFIG_BLK_DEV_RAM_COUNT=4
+CONFIG_BLK_DEV_XIP=y
+CONFIG_SRAM=y
+# CONFIG_INPUT_MOUSEDEV is not set
+# CONFIG_KEYBOARD_ATKBD is not set
+CONFIG_KEYBOARD_GPIO=y
+CONFIG_KEYBOARD_GPIO_POLLED=y
+# CONFIG_INPUT_MOUSE is not set
+# CONFIG_SERIO is not set
+CONFIG_SERIAL_FSL_LPUART=y
+CONFIG_SERIAL_FSL_LPUART_CONSOLE=y
+# CONFIG_HW_RANDOM is not set
+# CONFIG_HID is not set
+# CONFIG_USB_SUPPORT is not set
+CONFIG_MMC=y
+CONFIG_MMC_SDHCI=y
+CONFIG_MMC_SDHCI_PLTFM=y
+CONFIG_MMC_SDHCI_ESDHC_IMX=y
+# CONFIG_IOMMU_SUPPORT is not set
+CONFIG_EXT4_FS=y
+# CONFIG_MISC_FILESYSTEMS is not set
+CONFIG_DEBUG_MEMORY_INIT=y
+# CONFIG_FTRACE is not set
+# CONFIG_CRYPTO_HW is not set
-- 
2.1.3

Re: [PATCH 05/12] irqchip: nvic: increase number of external interrupts to 112

[Uwe Kleine-König]

Hallo Stefan,

On Wed, Dec 03, 2014 at 01:12:04AM +0100, Stefan Agner wrote:
> So far only vectors for up to 48 external interrupts have been
> registred in the vector table. Increase the amount of registred
s/registred/registered/

> external vectors to 112. Also, add a warning in case NVIC reports
> support for more interrupts than 128.
s/interrupts than 128/than 128 interrupts/ (not sure about this one)

> Note: the vector table must align to the number of entires in the
s/entires/entries/

Maybe point out that "X external interrupts" corresponds to "X + 16
vectors".

> vector table, hence increase the alignment to 0x200.
> 
> Signed-off-by: Stefan Agner <stefan@agner.ch>
> ---
>  arch/arm/kernel/entry-v7m.S | 6 +++---
>  drivers/irqchip/irq-nvic.c  | 2 ++
>  2 files changed, 5 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/arm/kernel/entry-v7m.S b/arch/arm/kernel/entry-v7m.S
> index 2260f18..754a1fa 100644
> --- a/arch/arm/kernel/entry-v7m.S
> +++ b/arch/arm/kernel/entry-v7m.S
> @@ -115,7 +115,7 @@ ENTRY(__switch_to)
>  ENDPROC(__switch_to)
>  
>  	.data
> -	.align	8
> +	.align	9
>  /*
>   * Vector table (64 words => 256 bytes natural alignment)
This comment needs fixing

>   */
> @@ -136,6 +136,6 @@ ENTRY(vector_table)
>  	.long	__invalid_entry		@ 13 - Reserved
>  	.long	__pendsv_entry		@ 14 - PendSV
>  	.long	__invalid_entry		@ 15 - SysTick
> -	.rept	64 - 16
> -	.long	__irq_entry		@ 16..64 - External Interrupts
> +	.rept	128 - 16
> +	.long	__irq_entry		@ 16..128 - External Interrupts
>  	.endr
> diff --git a/drivers/irqchip/irq-nvic.c b/drivers/irqchip/irq-nvic.c
> index dbfb5be..40f62a9 100644
> --- a/drivers/irqchip/irq-nvic.c
> +++ b/drivers/irqchip/irq-nvic.c
> @@ -137,6 +137,8 @@ static int __init nvic_of_init(struct device_node *node,
>  	if (irqs > NVIC_MAX_IRQ)
>  		irqs = NVIC_MAX_IRQ;
>  
> +	WARN(irqs > 128, "vector table in entry-v7m.S configured for 128 irqs");
> +
That's pointless. Better do:

	if (WARN(irqs > 128, "vector table in entry-v7m.S configured for 128 irqs"))
		irqs = 128;

Hmm, I wonder if that is correct. The first 16 exceptions are the system
exception that will not be registered be drivers and so exception 16
(i.e. the first regular irq) is reported as hwirq 0. So I think we can
(in a separate patch) pass irqs - 16 to irq_domain_add_linear. Didn't
test that though.

>  	nvic_irq_domain =
>  		irq_domain_add_linear(node, irqs, &nvic_irq_domain_ops, NULL);
>  	if (!nvic_irq_domain) {

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

Re: [PATCH 05/12] irqchip: nvic: increase number of external interrupts to 112

[Uwe Kleine-König]

Hallo Stefan,

On Wed, Dec 03, 2014 at 01:12:04AM +0100, Stefan Agner wrote:
> So far only vectors for up to 48 external interrupts have been
> registred in the vector table. Increase the amount of registred
s/registred/registered/

> external vectors to 112. Also, add a warning in case NVIC reports
> support for more interrupts than 128.
s/interrupts than 128/than 128 interrupts/ (not sure about this one)

> Note: the vector table must align to the number of entires in the
s/entires/entries/

Maybe point out that "X external interrupts" corresponds to "X + 16
vectors".

> vector table, hence increase the alignment to 0x200.
> 
> Signed-off-by: Stefan Agner <stefan-XLVq0VzYD2Y@public.gmane.org>
> ---
>  arch/arm/kernel/entry-v7m.S | 6 +++---
>  drivers/irqchip/irq-nvic.c  | 2 ++
>  2 files changed, 5 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/arm/kernel/entry-v7m.S b/arch/arm/kernel/entry-v7m.S
> index 2260f18..754a1fa 100644
> --- a/arch/arm/kernel/entry-v7m.S
> +++ b/arch/arm/kernel/entry-v7m.S
> @@ -115,7 +115,7 @@ ENTRY(__switch_to)
>  ENDPROC(__switch_to)
>  
>  	.data
> -	.align	8
> +	.align	9
>  /*
>   * Vector table (64 words => 256 bytes natural alignment)
This comment needs fixing

>   */
> @@ -136,6 +136,6 @@ ENTRY(vector_table)
>  	.long	__invalid_entry		@ 13 - Reserved
>  	.long	__pendsv_entry		@ 14 - PendSV
>  	.long	__invalid_entry		@ 15 - SysTick
> -	.rept	64 - 16
> -	.long	__irq_entry		@ 16..64 - External Interrupts
> +	.rept	128 - 16
> +	.long	__irq_entry		@ 16..128 - External Interrupts
>  	.endr
> diff --git a/drivers/irqchip/irq-nvic.c b/drivers/irqchip/irq-nvic.c
> index dbfb5be..40f62a9 100644
> --- a/drivers/irqchip/irq-nvic.c
> +++ b/drivers/irqchip/irq-nvic.c
> @@ -137,6 +137,8 @@ static int __init nvic_of_init(struct device_node *node,
>  	if (irqs > NVIC_MAX_IRQ)
>  		irqs = NVIC_MAX_IRQ;
>  
> +	WARN(irqs > 128, "vector table in entry-v7m.S configured for 128 irqs");
> +
That's pointless. Better do:

	if (WARN(irqs > 128, "vector table in entry-v7m.S configured for 128 irqs"))
		irqs = 128;

Hmm, I wonder if that is correct. The first 16 exceptions are the system
exception that will not be registered be drivers and so exception 16
(i.e. the first regular irq) is reported as hwirq 0. So I think we can
(in a separate patch) pass irqs - 16 to irq_domain_add_linear. Didn't
test that though.

>  	nvic_irq_domain =
>  		irq_domain_add_linear(node, irqs, &nvic_irq_domain_ops, NULL);
>  	if (!nvic_irq_domain) {

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 05/12] irqchip: nvic: increase number of external interrupts to 112

[Uwe Kleine-König]

Hallo Stefan,

On Wed, Dec 03, 2014 at 01:12:04AM +0100, Stefan Agner wrote:
> So far only vectors for up to 48 external interrupts have been
> registred in the vector table. Increase the amount of registred
s/registred/registered/

> external vectors to 112. Also, add a warning in case NVIC reports
> support for more interrupts than 128.
s/interrupts than 128/than 128 interrupts/ (not sure about this one)

> Note: the vector table must align to the number of entires in the
s/entires/entries/

Maybe point out that "X external interrupts" corresponds to "X + 16
vectors".

> vector table, hence increase the alignment to 0x200.
> 
> Signed-off-by: Stefan Agner <stefan@agner.ch>
> ---
>  arch/arm/kernel/entry-v7m.S | 6 +++---
>  drivers/irqchip/irq-nvic.c  | 2 ++
>  2 files changed, 5 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/arm/kernel/entry-v7m.S b/arch/arm/kernel/entry-v7m.S
> index 2260f18..754a1fa 100644
> --- a/arch/arm/kernel/entry-v7m.S
> +++ b/arch/arm/kernel/entry-v7m.S
> @@ -115,7 +115,7 @@ ENTRY(__switch_to)
>  ENDPROC(__switch_to)
>  
>  	.data
> -	.align	8
> +	.align	9
>  /*
>   * Vector table (64 words => 256 bytes natural alignment)
This comment needs fixing

>   */
> @@ -136,6 +136,6 @@ ENTRY(vector_table)
>  	.long	__invalid_entry		@ 13 - Reserved
>  	.long	__pendsv_entry		@ 14 - PendSV
>  	.long	__invalid_entry		@ 15 - SysTick
> -	.rept	64 - 16
> -	.long	__irq_entry		@ 16..64 - External Interrupts
> +	.rept	128 - 16
> +	.long	__irq_entry		@ 16..128 - External Interrupts
>  	.endr
> diff --git a/drivers/irqchip/irq-nvic.c b/drivers/irqchip/irq-nvic.c
> index dbfb5be..40f62a9 100644
> --- a/drivers/irqchip/irq-nvic.c
> +++ b/drivers/irqchip/irq-nvic.c
> @@ -137,6 +137,8 @@ static int __init nvic_of_init(struct device_node *node,
>  	if (irqs > NVIC_MAX_IRQ)
>  		irqs = NVIC_MAX_IRQ;
>  
> +	WARN(irqs > 128, "vector table in entry-v7m.S configured for 128 irqs");
> +
That's pointless. Better do:

	if (WARN(irqs > 128, "vector table in entry-v7m.S configured for 128 irqs"))
		irqs = 128;

Hmm, I wonder if that is correct. The first 16 exceptions are the system
exception that will not be registered be drivers and so exception 16
(i.e. the first regular irq) is reported as hwirq 0. So I think we can
(in a separate patch) pass irqs - 16 to irq_domain_add_linear. Didn't
test that though.

>  	nvic_irq_domain =
>  		irq_domain_add_linear(node, irqs, &nvic_irq_domain_ops, NULL);
>  	if (!nvic_irq_domain) {

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

Re: [PATCH 04/12] irqchip: nvic: support routable irq domain ops

[Uwe Kleine-König]

Hello Stefan,

On Wed, Dec 03, 2014 at 01:12:03AM +0100, Stefan Agner wrote:
> Add support for routable irq domain ops like the GIC interrupt
> controller provides. This is useful for asymmetrical multi-
> processor SoCs, such as Freescale Vybrid (VF6xx) which have
> a Cortex-M4 alongside a Cortex-A5 and a interrupt router to
> route the peripheral interrupts between them.
> 
> Signed-off-by: Stefan Agner <stefan@agner.ch>
> ---
>  drivers/irqchip/irq-nvic.c       | 70 +++++++++++++++++++++++++++++++++++++++-
>  include/linux/irqchip/arm-nvic.h | 25 ++++++++++++++
>  2 files changed, 94 insertions(+), 1 deletion(-)
>  create mode 100644 include/linux/irqchip/arm-nvic.h
> 
> diff --git a/drivers/irqchip/irq-nvic.c b/drivers/irqchip/irq-nvic.c
> index 4ff0805..dbfb5be 100644
> --- a/drivers/irqchip/irq-nvic.c
> +++ b/drivers/irqchip/irq-nvic.c
> @@ -40,6 +40,7 @@
>  #define NVIC_MAX_IRQ		((NVIC_MAX_BANKS - 1) * 32 + 16)
>  
>  static struct irq_domain *nvic_irq_domain;
> +const struct irq_domain_ops *nvic_routable_irq_domain_ops;
Can you reshuffle the order of functions to make this forward
declaration unnecessary?
  
>  asmlinkage void __exception_irq_entry
>  nvic_handle_irq(irq_hw_number_t hwirq, struct pt_regs *regs)
> @@ -49,6 +50,73 @@ nvic_handle_irq(irq_hw_number_t hwirq, struct pt_regs *regs)
>  	handle_IRQ(irq, regs);
>  }
>  
> +static int nvic_irq_domain_map(struct irq_domain *d, unsigned int irq,
> +				irq_hw_number_t hw)
> +{
> +	int ret;
> +
> +	ret = irq_map_generic_chip(d, irq, hw);
> +
> +	if (IS_ERR_VALUE(ret))
if (ret < 0)

> +		return ret;
> +
> +	return nvic_routable_irq_domain_ops->map(d, irq, hw);
You could save the default implementations if you do:

	if (nvic_routable_irq_domain_ops)
		return nvic_routable_irq_domain_ops->map(d, irq, hw);

(maybe also check for map?)

> +}
> +
> +static void nvic_irq_domain_unmap(struct irq_domain *d, unsigned int irq)
> +{
> +	nvic_routable_irq_domain_ops->unmap(d, irq);
> +}
> +
> +static int nvic_irq_domain_xlate(struct irq_domain *d,
> +				 struct device_node *controller,
> +				 const u32 *intspec, unsigned int intsize,
> +				 unsigned long *out_hwirq,
> +				 unsigned int *out_type)
> +{
> +	*out_hwirq = intspec[0];
> +	*out_type = IRQ_TYPE_NONE;
If you demand from the callback to set this, you can just do

	nvic_irq_domain_ops.xlate = new_callback;

not sure this is sensible though. Up to you.

> +	return nvic_routable_irq_domain_ops->xlate(d, controller, intspec,
> +						  intsize, out_hwirq, out_type);
> +}
> +
> +struct irq_domain_ops nvic_irq_domain_ops = {
> +	.map	= nvic_irq_domain_map,
> +	.unmap	= nvic_irq_domain_unmap,
> +	.xlate	= nvic_irq_domain_xlate,
> +};
> +
> +/* Default functions for routable irq domain */
> +static int nvic_routable_irq_domain_map(struct irq_domain *d, unsigned int irq,
> +			      irq_hw_number_t hw)
> +{
> +	return 0;
> +}
> +
> +static void nvic_routable_irq_domain_unmap(struct irq_domain *d,
> +					  unsigned int irq)
> +{
> +}
> +
> +static int nvic_routable_irq_domain_xlate(struct irq_domain *d,
> +				struct device_node *controller,
> +				const u32 *intspec, unsigned int intsize,
> +				unsigned long *out_hwirq,
> +				unsigned int *out_type)
> +{
> +	return 0;
> +}
> +
> +static const struct irq_domain_ops nvic_default_routable_irq_domain_ops = {
> +	.map = nvic_routable_irq_domain_map,
> +	.unmap = nvic_routable_irq_domain_unmap,
> +	.xlate = nvic_routable_irq_domain_xlate,
> +};
> +
> +const struct irq_domain_ops *nvic_routable_irq_domain_ops =
> +					&nvic_default_routable_irq_domain_ops;
> +
>  static int __init nvic_of_init(struct device_node *node,
>  			       struct device_node *parent)
>  {
> @@ -70,7 +138,7 @@ static int __init nvic_of_init(struct device_node *node,
>  		irqs = NVIC_MAX_IRQ;
>  
>  	nvic_irq_domain =
> -		irq_domain_add_linear(node, irqs, &irq_generic_chip_ops, NULL);
> +		irq_domain_add_linear(node, irqs, &nvic_irq_domain_ops, NULL);
>  	if (!nvic_irq_domain) {
>  		pr_warn("Failed to allocate irq domain\n");
>  		return -ENOMEM;
> diff --git a/include/linux/irqchip/arm-nvic.h b/include/linux/irqchip/arm-nvic.h
> new file mode 100644
> index 0000000..0e92a14
> --- /dev/null
> +++ b/include/linux/irqchip/arm-nvic.h
> @@ -0,0 +1,25 @@
> +/*
> + *  include/linux/irqchip/arm-nvic.h
Don't add the filename to a comment. There are more reliable means to
find it out than looking for that comment.

> + *
> + *  Copyright (C) 2014 Stefan Agner
Is this indented differently to the paragraph below on purpose?

> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +#ifndef __LINUX_IRQCHIP_ARM_NVIC_H
> +#define __LINUX_IRQCHIP_ARM_NVIC_H
> +
> +#ifndef __ASSEMBLY__
> +
> +#ifdef CONFIG_ARM_NVIC
> +extern const struct irq_domain_ops *nvic_routable_irq_domain_ops;
> +static inline void __init register_routable_domain_ops
> +					(const struct irq_domain_ops *ops)
> +{
> +		nvic_routable_irq_domain_ops = ops;
> +}
> +#endif /* CONFIG_ARM_NVIC */
> +
> +#endif /* __ASSEMBLY__ */
> +#endif /* __LINUX_IRQCHIP_ARM_NVIC_H */

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

Re: [PATCH 04/12] irqchip: nvic: support routable irq domain ops

[Uwe Kleine-König]

Hello Stefan,

On Wed, Dec 03, 2014 at 01:12:03AM +0100, Stefan Agner wrote:
> Add support for routable irq domain ops like the GIC interrupt
> controller provides. This is useful for asymmetrical multi-
> processor SoCs, such as Freescale Vybrid (VF6xx) which have
> a Cortex-M4 alongside a Cortex-A5 and a interrupt router to
> route the peripheral interrupts between them.
> 
> Signed-off-by: Stefan Agner <stefan-XLVq0VzYD2Y@public.gmane.org>
> ---
>  drivers/irqchip/irq-nvic.c       | 70 +++++++++++++++++++++++++++++++++++++++-
>  include/linux/irqchip/arm-nvic.h | 25 ++++++++++++++
>  2 files changed, 94 insertions(+), 1 deletion(-)
>  create mode 100644 include/linux/irqchip/arm-nvic.h
> 
> diff --git a/drivers/irqchip/irq-nvic.c b/drivers/irqchip/irq-nvic.c
> index 4ff0805..dbfb5be 100644
> --- a/drivers/irqchip/irq-nvic.c
> +++ b/drivers/irqchip/irq-nvic.c
> @@ -40,6 +40,7 @@
>  #define NVIC_MAX_IRQ		((NVIC_MAX_BANKS - 1) * 32 + 16)
>  
>  static struct irq_domain *nvic_irq_domain;
> +const struct irq_domain_ops *nvic_routable_irq_domain_ops;
Can you reshuffle the order of functions to make this forward
declaration unnecessary?
  
>  asmlinkage void __exception_irq_entry
>  nvic_handle_irq(irq_hw_number_t hwirq, struct pt_regs *regs)
> @@ -49,6 +50,73 @@ nvic_handle_irq(irq_hw_number_t hwirq, struct pt_regs *regs)
>  	handle_IRQ(irq, regs);
>  }
>  
> +static int nvic_irq_domain_map(struct irq_domain *d, unsigned int irq,
> +				irq_hw_number_t hw)
> +{
> +	int ret;
> +
> +	ret = irq_map_generic_chip(d, irq, hw);
> +
> +	if (IS_ERR_VALUE(ret))
if (ret < 0)

> +		return ret;
> +
> +	return nvic_routable_irq_domain_ops->map(d, irq, hw);
You could save the default implementations if you do:

	if (nvic_routable_irq_domain_ops)
		return nvic_routable_irq_domain_ops->map(d, irq, hw);

(maybe also check for map?)

> +}
> +
> +static void nvic_irq_domain_unmap(struct irq_domain *d, unsigned int irq)
> +{
> +	nvic_routable_irq_domain_ops->unmap(d, irq);
> +}
> +
> +static int nvic_irq_domain_xlate(struct irq_domain *d,
> +				 struct device_node *controller,
> +				 const u32 *intspec, unsigned int intsize,
> +				 unsigned long *out_hwirq,
> +				 unsigned int *out_type)
> +{
> +	*out_hwirq = intspec[0];
> +	*out_type = IRQ_TYPE_NONE;
If you demand from the callback to set this, you can just do

	nvic_irq_domain_ops.xlate = new_callback;

not sure this is sensible though. Up to you.

> +	return nvic_routable_irq_domain_ops->xlate(d, controller, intspec,
> +						  intsize, out_hwirq, out_type);
> +}
> +
> +struct irq_domain_ops nvic_irq_domain_ops = {
> +	.map	= nvic_irq_domain_map,
> +	.unmap	= nvic_irq_domain_unmap,
> +	.xlate	= nvic_irq_domain_xlate,
> +};
> +
> +/* Default functions for routable irq domain */
> +static int nvic_routable_irq_domain_map(struct irq_domain *d, unsigned int irq,
> +			      irq_hw_number_t hw)
> +{
> +	return 0;
> +}
> +
> +static void nvic_routable_irq_domain_unmap(struct irq_domain *d,
> +					  unsigned int irq)
> +{
> +}
> +
> +static int nvic_routable_irq_domain_xlate(struct irq_domain *d,
> +				struct device_node *controller,
> +				const u32 *intspec, unsigned int intsize,
> +				unsigned long *out_hwirq,
> +				unsigned int *out_type)
> +{
> +	return 0;
> +}
> +
> +static const struct irq_domain_ops nvic_default_routable_irq_domain_ops = {
> +	.map = nvic_routable_irq_domain_map,
> +	.unmap = nvic_routable_irq_domain_unmap,
> +	.xlate = nvic_routable_irq_domain_xlate,
> +};
> +
> +const struct irq_domain_ops *nvic_routable_irq_domain_ops =
> +					&nvic_default_routable_irq_domain_ops;
> +
>  static int __init nvic_of_init(struct device_node *node,
>  			       struct device_node *parent)
>  {
> @@ -70,7 +138,7 @@ static int __init nvic_of_init(struct device_node *node,
>  		irqs = NVIC_MAX_IRQ;
>  
>  	nvic_irq_domain =
> -		irq_domain_add_linear(node, irqs, &irq_generic_chip_ops, NULL);
> +		irq_domain_add_linear(node, irqs, &nvic_irq_domain_ops, NULL);
>  	if (!nvic_irq_domain) {
>  		pr_warn("Failed to allocate irq domain\n");
>  		return -ENOMEM;
> diff --git a/include/linux/irqchip/arm-nvic.h b/include/linux/irqchip/arm-nvic.h
> new file mode 100644
> index 0000000..0e92a14
> --- /dev/null
> +++ b/include/linux/irqchip/arm-nvic.h
> @@ -0,0 +1,25 @@
> +/*
> + *  include/linux/irqchip/arm-nvic.h
Don't add the filename to a comment. There are more reliable means to
find it out than looking for that comment.

> + *
> + *  Copyright (C) 2014 Stefan Agner
Is this indented differently to the paragraph below on purpose?

> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +#ifndef __LINUX_IRQCHIP_ARM_NVIC_H
> +#define __LINUX_IRQCHIP_ARM_NVIC_H
> +
> +#ifndef __ASSEMBLY__
> +
> +#ifdef CONFIG_ARM_NVIC
> +extern const struct irq_domain_ops *nvic_routable_irq_domain_ops;
> +static inline void __init register_routable_domain_ops
> +					(const struct irq_domain_ops *ops)
> +{
> +		nvic_routable_irq_domain_ops = ops;
> +}
> +#endif /* CONFIG_ARM_NVIC */
> +
> +#endif /* __ASSEMBLY__ */
> +#endif /* __LINUX_IRQCHIP_ARM_NVIC_H */

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 04/12] irqchip: nvic: support routable irq domain ops

[Uwe Kleine-König]

Hello Stefan,

On Wed, Dec 03, 2014 at 01:12:03AM +0100, Stefan Agner wrote:
> Add support for routable irq domain ops like the GIC interrupt
> controller provides. This is useful for asymmetrical multi-
> processor SoCs, such as Freescale Vybrid (VF6xx) which have
> a Cortex-M4 alongside a Cortex-A5 and a interrupt router to
> route the peripheral interrupts between them.
> 
> Signed-off-by: Stefan Agner <stefan@agner.ch>
> ---
>  drivers/irqchip/irq-nvic.c       | 70 +++++++++++++++++++++++++++++++++++++++-
>  include/linux/irqchip/arm-nvic.h | 25 ++++++++++++++
>  2 files changed, 94 insertions(+), 1 deletion(-)
>  create mode 100644 include/linux/irqchip/arm-nvic.h
> 
> diff --git a/drivers/irqchip/irq-nvic.c b/drivers/irqchip/irq-nvic.c
> index 4ff0805..dbfb5be 100644
> --- a/drivers/irqchip/irq-nvic.c
> +++ b/drivers/irqchip/irq-nvic.c
> @@ -40,6 +40,7 @@
>  #define NVIC_MAX_IRQ		((NVIC_MAX_BANKS - 1) * 32 + 16)
>  
>  static struct irq_domain *nvic_irq_domain;
> +const struct irq_domain_ops *nvic_routable_irq_domain_ops;
Can you reshuffle the order of functions to make this forward
declaration unnecessary?
  
>  asmlinkage void __exception_irq_entry
>  nvic_handle_irq(irq_hw_number_t hwirq, struct pt_regs *regs)
> @@ -49,6 +50,73 @@ nvic_handle_irq(irq_hw_number_t hwirq, struct pt_regs *regs)
>  	handle_IRQ(irq, regs);
>  }
>  
> +static int nvic_irq_domain_map(struct irq_domain *d, unsigned int irq,
> +				irq_hw_number_t hw)
> +{
> +	int ret;
> +
> +	ret = irq_map_generic_chip(d, irq, hw);
> +
> +	if (IS_ERR_VALUE(ret))
if (ret < 0)

> +		return ret;
> +
> +	return nvic_routable_irq_domain_ops->map(d, irq, hw);
You could save the default implementations if you do:

	if (nvic_routable_irq_domain_ops)
		return nvic_routable_irq_domain_ops->map(d, irq, hw);

(maybe also check for map?)

> +}
> +
> +static void nvic_irq_domain_unmap(struct irq_domain *d, unsigned int irq)
> +{
> +	nvic_routable_irq_domain_ops->unmap(d, irq);
> +}
> +
> +static int nvic_irq_domain_xlate(struct irq_domain *d,
> +				 struct device_node *controller,
> +				 const u32 *intspec, unsigned int intsize,
> +				 unsigned long *out_hwirq,
> +				 unsigned int *out_type)
> +{
> +	*out_hwirq = intspec[0];
> +	*out_type = IRQ_TYPE_NONE;
If you demand from the callback to set this, you can just do

	nvic_irq_domain_ops.xlate = new_callback;

not sure this is sensible though. Up to you.

> +	return nvic_routable_irq_domain_ops->xlate(d, controller, intspec,
> +						  intsize, out_hwirq, out_type);
> +}
> +
> +struct irq_domain_ops nvic_irq_domain_ops = {
> +	.map	= nvic_irq_domain_map,
> +	.unmap	= nvic_irq_domain_unmap,
> +	.xlate	= nvic_irq_domain_xlate,
> +};
> +
> +/* Default functions for routable irq domain */
> +static int nvic_routable_irq_domain_map(struct irq_domain *d, unsigned int irq,
> +			      irq_hw_number_t hw)
> +{
> +	return 0;
> +}
> +
> +static void nvic_routable_irq_domain_unmap(struct irq_domain *d,
> +					  unsigned int irq)
> +{
> +}
> +
> +static int nvic_routable_irq_domain_xlate(struct irq_domain *d,
> +				struct device_node *controller,
> +				const u32 *intspec, unsigned int intsize,
> +				unsigned long *out_hwirq,
> +				unsigned int *out_type)
> +{
> +	return 0;
> +}
> +
> +static const struct irq_domain_ops nvic_default_routable_irq_domain_ops = {
> +	.map = nvic_routable_irq_domain_map,
> +	.unmap = nvic_routable_irq_domain_unmap,
> +	.xlate = nvic_routable_irq_domain_xlate,
> +};
> +
> +const struct irq_domain_ops *nvic_routable_irq_domain_ops =
> +					&nvic_default_routable_irq_domain_ops;
> +
>  static int __init nvic_of_init(struct device_node *node,
>  			       struct device_node *parent)
>  {
> @@ -70,7 +138,7 @@ static int __init nvic_of_init(struct device_node *node,
>  		irqs = NVIC_MAX_IRQ;
>  
>  	nvic_irq_domain =
> -		irq_domain_add_linear(node, irqs, &irq_generic_chip_ops, NULL);
> +		irq_domain_add_linear(node, irqs, &nvic_irq_domain_ops, NULL);
>  	if (!nvic_irq_domain) {
>  		pr_warn("Failed to allocate irq domain\n");
>  		return -ENOMEM;
> diff --git a/include/linux/irqchip/arm-nvic.h b/include/linux/irqchip/arm-nvic.h
> new file mode 100644
> index 0000000..0e92a14
> --- /dev/null
> +++ b/include/linux/irqchip/arm-nvic.h
> @@ -0,0 +1,25 @@
> +/*
> + *  include/linux/irqchip/arm-nvic.h
Don't add the filename to a comment. There are more reliable means to
find it out than looking for that comment.

> + *
> + *  Copyright (C) 2014 Stefan Agner
Is this indented differently to the paragraph below on purpose?

> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +#ifndef __LINUX_IRQCHIP_ARM_NVIC_H
> +#define __LINUX_IRQCHIP_ARM_NVIC_H
> +
> +#ifndef __ASSEMBLY__
> +
> +#ifdef CONFIG_ARM_NVIC
> +extern const struct irq_domain_ops *nvic_routable_irq_domain_ops;
> +static inline void __init register_routable_domain_ops
> +					(const struct irq_domain_ops *ops)
> +{
> +		nvic_routable_irq_domain_ops = ops;
> +}
> +#endif /* CONFIG_ARM_NVIC */
> +
> +#endif /* __ASSEMBLY__ */
> +#endif /* __LINUX_IRQCHIP_ARM_NVIC_H */

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

Re: [PATCH 03/12] irqchip: gic: define register_routable_domain_ops conditional

[Arnd Bergmann]

On Wednesday 03 December 2014 01:12:02 Stefan Agner wrote:
> The inline function register_routable_domain_ops is only usable if
> CONFIG_ARM_GIC is set. Make it depend on this configuration. This
> also allows other SoC interrupt controller to provide such a
> function.
> 
> Signed-off-by: Stefan Agner <stefan@agner.ch>

I don't think this is a good idea: either the interface is meant
to be generic and should work with any interrupt controller, or
it is specific to one irqchip and another irqchip should provide
a different interface that has a nonconflicting name.

I suppose you want the latter here, given that the declaration
is part of the gic specific header file.

	Arnd

Re: [PATCH 03/12] irqchip: gic: define register_routable_domain_ops conditional

[Arnd Bergmann]

On Wednesday 03 December 2014 01:12:02 Stefan Agner wrote:
> The inline function register_routable_domain_ops is only usable if
> CONFIG_ARM_GIC is set. Make it depend on this configuration. This
> also allows other SoC interrupt controller to provide such a
> function.
> 
> Signed-off-by: Stefan Agner <stefan-XLVq0VzYD2Y@public.gmane.org>

I don't think this is a good idea: either the interface is meant
to be generic and should work with any interrupt controller, or
it is specific to one irqchip and another irqchip should provide
a different interface that has a nonconflicting name.

I suppose you want the latter here, given that the declaration
is part of the gic specific header file.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 03/12] irqchip: gic: define register_routable_domain_ops conditional

[Arnd Bergmann]

On Wednesday 03 December 2014 01:12:02 Stefan Agner wrote:
> The inline function register_routable_domain_ops is only usable if
> CONFIG_ARM_GIC is set. Make it depend on this configuration. This
> also allows other SoC interrupt controller to provide such a
> function.
> 
> Signed-off-by: Stefan Agner <stefan@agner.ch>

I don't think this is a good idea: either the interface is meant
to be generic and should work with any interrupt controller, or
it is specific to one irqchip and another irqchip should provide
a different interface that has a nonconflicting name.

I suppose you want the latter here, given that the declaration
is part of the gic specific header file.

	Arnd

Re: [PATCH 04/12] irqchip: nvic: support routable irq domain ops

[Arnd Bergmann]

On Wednesday 03 December 2014 01:12:03 Stefan Agner wrote:
> +#ifdef CONFIG_ARM_NVIC
> +extern const struct irq_domain_ops *nvic_routable_irq_domain_ops;
> +static inline void __init register_routable_domain_ops
> +                                       (const struct irq_domain_ops *ops)
> +{
> +               nvic_routable_irq_domain_ops = ops;
> +}
> +#endif /* CONFIG_ARM_NVIC */
> 

As you mentioned, this conflicts with the gic specific declaration.
Why not remove the #ifdef here and rename the function to
nvic_register_routable_domain_ops() ?

If that doesn't work, I guess we need something more generic
and move the routable_irq_domain_ops to some common location.

	Arnd

Re: [PATCH 04/12] irqchip: nvic: support routable irq domain ops

[Arnd Bergmann]

On Wednesday 03 December 2014 01:12:03 Stefan Agner wrote:
> +#ifdef CONFIG_ARM_NVIC
> +extern const struct irq_domain_ops *nvic_routable_irq_domain_ops;
> +static inline void __init register_routable_domain_ops
> +                                       (const struct irq_domain_ops *ops)
> +{
> +               nvic_routable_irq_domain_ops = ops;
> +}
> +#endif /* CONFIG_ARM_NVIC */
> 

As you mentioned, this conflicts with the gic specific declaration.
Why not remove the #ifdef here and rename the function to
nvic_register_routable_domain_ops() ?

If that doesn't work, I guess we need something more generic
and move the routable_irq_domain_ops to some common location.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 04/12] irqchip: nvic: support routable irq domain ops

[Arnd Bergmann]

On Wednesday 03 December 2014 01:12:03 Stefan Agner wrote:
> +#ifdef CONFIG_ARM_NVIC
> +extern const struct irq_domain_ops *nvic_routable_irq_domain_ops;
> +static inline void __init register_routable_domain_ops
> +                                       (const struct irq_domain_ops *ops)
> +{
> +               nvic_routable_irq_domain_ops = ops;
> +}
> +#endif /* CONFIG_ARM_NVIC */
> 

As you mentioned, this conflicts with the gic specific declaration.
Why not remove the #ifdef here and rename the function to
nvic_register_routable_domain_ops() ?

If that doesn't work, I guess we need something more generic
and move the routable_irq_domain_ops to some common location.

	Arnd

Re: [PATCH 06/12] ARM: imx: add support for MSCM interrupt router

[Arnd Bergmann]

On Wednesday 03 December 2014 01:12:05 Stefan Agner wrote:
> +
> +static int vf610_mscm_domain_xlate(struct irq_domain *d,
> +				struct device_node *controller,
> +				const u32 *intspec, unsigned int intsize,
> +				unsigned long *out_hwirq,
> +				unsigned int *out_type)
> +{
> +#ifdef CONFIG_ARM_GIC
> +	*out_hwirq += 16;
> +#endif
> +	return 0;
> +}

I don't see how the hwirq should in any way depend on whether the
kernel also supports an ARM_GIC. This number should only be meaningful
inside of your irqchip driver.

	Arnd

[PATCH 06/12] ARM: imx: add support for MSCM interrupt router

[Arnd Bergmann]

On Wednesday 03 December 2014 01:12:05 Stefan Agner wrote:
> +
> +static int vf610_mscm_domain_xlate(struct irq_domain *d,
> +				struct device_node *controller,
> +				const u32 *intspec, unsigned int intsize,
> +				unsigned long *out_hwirq,
> +				unsigned int *out_type)
> +{
> +#ifdef CONFIG_ARM_GIC
> +	*out_hwirq += 16;
> +#endif
> +	return 0;
> +}

I don't see how the hwirq should in any way depend on whether the
kernel also supports an ARM_GIC. This number should only be meaningful
inside of your irqchip driver.

	Arnd

Re: [PATCH 07/12] Documentation: dt: imx: add MSCM documentation

[Arnd Bergmann]

On Wednesday 03 December 2014 01:12:06 Stefan Agner wrote:
> +Freescale Vybrid Miscellaneous System Control Module
> +
> +The MSCM IP contains Access Control and TrustZone Security hardware,
> +CPU Configuration registers and Interrupt Router control.
> +
> +Required properties:
> +- compatible : "fsl,vf610-mscm"
> +- reg : the register range of the MSCM module
> +
> +Example:
> +       mscm: mscm@40001000 {                 
> +               compatible = "fsl,vf610-mscm";
> +               reg = <0x40001000 0x1000>;    
> +       };                                    

This sounds like one of those generic system controller devices.
Should this be marked as syscon an accessed through
syscon_regmap_lookup_by_phandle()?

If you only eve have one driver touching these registers, that
won't be necessary of course.

	arnd

Re: [PATCH 07/12] Documentation: dt: imx: add MSCM documentation

[Arnd Bergmann]

On Wednesday 03 December 2014 01:12:06 Stefan Agner wrote:
> +Freescale Vybrid Miscellaneous System Control Module
> +
> +The MSCM IP contains Access Control and TrustZone Security hardware,
> +CPU Configuration registers and Interrupt Router control.
> +
> +Required properties:
> +- compatible : "fsl,vf610-mscm"
> +- reg : the register range of the MSCM module
> +
> +Example:
> +       mscm: mscm@40001000 {                 
> +               compatible = "fsl,vf610-mscm";
> +               reg = <0x40001000 0x1000>;    
> +       };                                    

This sounds like one of those generic system controller devices.
Should this be marked as syscon an accessed through
syscon_regmap_lookup_by_phandle()?

If you only eve have one driver touching these registers, that
won't be necessary of course.

	arnd
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 07/12] Documentation: dt: imx: add MSCM documentation

[Arnd Bergmann]

On Wednesday 03 December 2014 01:12:06 Stefan Agner wrote:
> +Freescale Vybrid Miscellaneous System Control Module
> +
> +The MSCM IP contains Access Control and TrustZone Security hardware,
> +CPU Configuration registers and Interrupt Router control.
> +
> +Required properties:
> +- compatible : "fsl,vf610-mscm"
> +- reg : the register range of the MSCM module
> +
> +Example:
> +       mscm: mscm at 40001000 {                 
> +               compatible = "fsl,vf610-mscm";
> +               reg = <0x40001000 0x1000>;    
> +       };                                    

This sounds like one of those generic system controller devices.
Should this be marked as syscon an accessed through
syscon_regmap_lookup_by_phandle()?

If you only eve have one driver touching these registers, that
won't be necessary of course.

	arnd

Re: [PATCH 09/12] ARM: unify MMU/!MMU addruart calls

[Arnd Bergmann]

On Wednesday 03 December 2014 01:12:08 Stefan Agner wrote:
> Remove the needless differences between MMU/!MMU addruart calls.
> This allows to use the same addruart macro on SoC level. Useful
> for SoC consisting of multiple CPUs with and without MMU such as
> Freescale Vybrid.
> 
> Signed-off-by: Stefan Agner <stefan@agner.ch>
> 

I think I had the same patch somewhere hidden in my collection
of stuff I need to submit one day. Looks good.

	Arnd

Re: [PATCH 09/12] ARM: unify MMU/!MMU addruart calls

[Arnd Bergmann]

On Wednesday 03 December 2014 01:12:08 Stefan Agner wrote:
> Remove the needless differences between MMU/!MMU addruart calls.
> This allows to use the same addruart macro on SoC level. Useful
> for SoC consisting of multiple CPUs with and without MMU such as
> Freescale Vybrid.
> 
> Signed-off-by: Stefan Agner <stefan-XLVq0VzYD2Y@public.gmane.org>
> 

I think I had the same patch somewhere hidden in my collection
of stuff I need to submit one day. Looks good.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 09/12] ARM: unify MMU/!MMU addruart calls

[Arnd Bergmann]

On Wednesday 03 December 2014 01:12:08 Stefan Agner wrote:
> Remove the needless differences between MMU/!MMU addruart calls.
> This allows to use the same addruart macro on SoC level. Useful
> for SoC consisting of multiple CPUs with and without MMU such as
> Freescale Vybrid.
> 
> Signed-off-by: Stefan Agner <stefan@agner.ch>
> 

I think I had the same patch somewhere hidden in my collection
of stuff I need to submit one day. Looks good.

	Arnd

Re: [PATCH 10/12] ARM: vf610m4: add new machine and SoC for Vybrid on Cortex-M4

[Arnd Bergmann]

On Wednesday 03 December 2014 01:12:09 Stefan Agner wrote:
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 89c4b5c..fdebe18 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -459,6 +459,18 @@ config ARCH_FOOTBRIDGE
>  	  Support for systems based on the DC21285 companion chip
>  	  ("FootBridge"), such as the Simtec CATS and the Rebel NetWinder.
>  
> +menuconfig ARCH_MXCM4
> +	bool "Freescale Vybrid/i.MX family on Cortex-M4" if !MMU
> +	select ARCH_REQUIRE_GPIOLIB
> +	select ARM_CPU_SUSPEND if PM
> +	select CLKSRC_MMIO
> +	select GENERIC_IRQ_CHIP
> +	select PINCTRL
> +	select PM_OPP if PM
> +	select SOC_BUS
> +	help
> +	  Support for Freescale Vybrid/iMX-based family of processors on Cortex-M4
> +
>  config ARCH_NETX
>  	bool "Hilscher NetX based"
>  	select ARM_VIC

I would really prefer not to see any more standalone machine types,
but rather have ARMv7-M as one of the options for the
multiplatform configuration. In particular, that would let us
do *build* testing on a combined mxcm4/efm32/vexpress kernel,
although that kernel would clearly not be usable anywhere
because of the restrictions of nommu machines.

> +static void __init vf610m4_init_irq(void)
> +{
> +	vf610_mscm_init();
> +	irqchip_init();
> +}

Can you make vf610_mscm_init get called from irqchip and remove this
function?

	Arnd

Re: [PATCH 10/12] ARM: vf610m4: add new machine and SoC for Vybrid on Cortex-M4

[Arnd Bergmann]

On Wednesday 03 December 2014 01:12:09 Stefan Agner wrote:
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 89c4b5c..fdebe18 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -459,6 +459,18 @@ config ARCH_FOOTBRIDGE
>  	  Support for systems based on the DC21285 companion chip
>  	  ("FootBridge"), such as the Simtec CATS and the Rebel NetWinder.
>  
> +menuconfig ARCH_MXCM4
> +	bool "Freescale Vybrid/i.MX family on Cortex-M4" if !MMU
> +	select ARCH_REQUIRE_GPIOLIB
> +	select ARM_CPU_SUSPEND if PM
> +	select CLKSRC_MMIO
> +	select GENERIC_IRQ_CHIP
> +	select PINCTRL
> +	select PM_OPP if PM
> +	select SOC_BUS
> +	help
> +	  Support for Freescale Vybrid/iMX-based family of processors on Cortex-M4
> +
>  config ARCH_NETX
>  	bool "Hilscher NetX based"
>  	select ARM_VIC

I would really prefer not to see any more standalone machine types,
but rather have ARMv7-M as one of the options for the
multiplatform configuration. In particular, that would let us
do *build* testing on a combined mxcm4/efm32/vexpress kernel,
although that kernel would clearly not be usable anywhere
because of the restrictions of nommu machines.

> +static void __init vf610m4_init_irq(void)
> +{
> +	vf610_mscm_init();
> +	irqchip_init();
> +}

Can you make vf610_mscm_init get called from irqchip and remove this
function?

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 10/12] ARM: vf610m4: add new machine and SoC for Vybrid on Cortex-M4

[Arnd Bergmann]

On Wednesday 03 December 2014 01:12:09 Stefan Agner wrote:
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 89c4b5c..fdebe18 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -459,6 +459,18 @@ config ARCH_FOOTBRIDGE
>  	  Support for systems based on the DC21285 companion chip
>  	  ("FootBridge"), such as the Simtec CATS and the Rebel NetWinder.
>  
> +menuconfig ARCH_MXCM4
> +	bool "Freescale Vybrid/i.MX family on Cortex-M4" if !MMU
> +	select ARCH_REQUIRE_GPIOLIB
> +	select ARM_CPU_SUSPEND if PM
> +	select CLKSRC_MMIO
> +	select GENERIC_IRQ_CHIP
> +	select PINCTRL
> +	select PM_OPP if PM
> +	select SOC_BUS
> +	help
> +	  Support for Freescale Vybrid/iMX-based family of processors on Cortex-M4
> +
>  config ARCH_NETX
>  	bool "Hilscher NetX based"
>  	select ARM_VIC

I would really prefer not to see any more standalone machine types,
but rather have ARMv7-M as one of the options for the
multiplatform configuration. In particular, that would let us
do *build* testing on a combined mxcm4/efm32/vexpress kernel,
although that kernel would clearly not be usable anywhere
because of the restrictions of nommu machines.

> +static void __init vf610m4_init_irq(void)
> +{
> +	vf610_mscm_init();
> +	irqchip_init();
> +}

Can you make vf610_mscm_init get called from irqchip and remove this
function?

	Arnd

Re: [PATCH 11/12] ARM: dts: add support for Vybrid running on Cortex-M4

[Arnd Bergmann]

On Wednesday 03 December 2014 01:12:10 Stefan Agner wrote:
> diff --git a/arch/arm/boot/dts/vf610m4-colibri.dts b/arch/arm/boot/dts/vf610m4-colibri.dts
> new file mode 100644
> index 0000000..051ee0f
> --- /dev/null
> +++ b/arch/arm/boot/dts/vf610m4-colibri.dts
> @@ -0,0 +1,52 @@
> +/*
> + * Device tree for Colibri VF61 Cortex-M4 support
> + *
> + * Copyright 2014 Stefan Agner
> + *
> + * 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.
> + */
> +
> +/dts-v1/;
> +#include "vf610m4.dtsi"
> +
> +/ {
> +       model = "VF610 Cortex-M4";
> +       compatible = "fsl,vf610m4";
> +
> +       chosen {
> +               bootargs = "console=ttyLP2,115200 ihash_entries=64 dhash_entries=64 earlyprintk clk_ignore_unused init=/linuxrc rw";
> +       };
> +

Starting with v3.19, you should be able to use the earlycon framework on
arm32, so it would be better to replace earlyprintk with earlycon here
and add a stdout-path property in chosen that points to the console
uart.

64 hash table entries sounds extremely small, doesn't that impact
performance? If you have 50MB of actual RAM available, I don't think
you need that.

	Arnd

[PATCH 11/12] ARM: dts: add support for Vybrid running on Cortex-M4

[Arnd Bergmann]

On Wednesday 03 December 2014 01:12:10 Stefan Agner wrote:
> diff --git a/arch/arm/boot/dts/vf610m4-colibri.dts b/arch/arm/boot/dts/vf610m4-colibri.dts
> new file mode 100644
> index 0000000..051ee0f
> --- /dev/null
> +++ b/arch/arm/boot/dts/vf610m4-colibri.dts
> @@ -0,0 +1,52 @@
> +/*
> + * Device tree for Colibri VF61 Cortex-M4 support
> + *
> + * Copyright 2014 Stefan Agner
> + *
> + * 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.
> + */
> +
> +/dts-v1/;
> +#include "vf610m4.dtsi"
> +
> +/ {
> +       model = "VF610 Cortex-M4";
> +       compatible = "fsl,vf610m4";
> +
> +       chosen {
> +               bootargs = "console=ttyLP2,115200 ihash_entries=64 dhash_entries=64 earlyprintk clk_ignore_unused init=/linuxrc rw";
> +       };
> +

Starting with v3.19, you should be able to use the earlycon framework on
arm32, so it would be better to replace earlyprintk with earlycon here
and add a stdout-path property in chosen that points to the console
uart.

64 hash table entries sounds extremely small, doesn't that impact
performance? If you have 50MB of actual RAM available, I don't think
you need that.

	Arnd

Re: [PATCH 03/12] irqchip: gic: define register_routable_domain_ops conditional

[Thomas Gleixner]

On Wed, 3 Dec 2014, Arnd Bergmann wrote:

> On Wednesday 03 December 2014 01:12:02 Stefan Agner wrote:
> > The inline function register_routable_domain_ops is only usable if
> > CONFIG_ARM_GIC is set. Make it depend on this configuration. This
> > also allows other SoC interrupt controller to provide such a
> > function.
> > 
> > Signed-off-by: Stefan Agner <stefan@agner.ch>
> 
> I don't think this is a good idea: either the interface is meant
> to be generic and should work with any interrupt controller, or
> it is specific to one irqchip and another irqchip should provide
> a different interface that has a nonconflicting name.
> 
> I suppose you want the latter here, given that the declaration
> is part of the gic specific header file.

That routable_domain stuff should have never been invented. In
hindsight we should have done the stacked irq domains back then
already, but in hindsight ...

If you look at the crossbar scheme what we have now:

   GIC domain
|--------------|
|              |---------- private
| non routable |---------- peripheral
|              |---------- peripheral
|              |
|--------------|
|              |---------- peripheral
|   routable   |---------- peripheral
|    |         |---------- peripheral
|--------------|
     |               |----------------|
     |-------------->| crossbar magic |
                     |----------------|

which is not how the hardware looks. The hardware actually looks like
this:

   GIC domain
|--------------|
|              |---------- private
| non routable |---------- peripheral
|              |---------- peripheral
|              |
|--------------|           |--------------|
|              |           |              |---------- peripheral
|   routable   |-----------| crossbar     |---------- peripheral
|              |           | domain       |---------- peripheral
|--------------|           |--------------|

So it is completely obvious that the peripheral interrupts which need
to be routed through the crossbar belong to a different domain. We
really should convert crossbar to that scheme and get rid of the
routable domain stuff completely.

With vybrid thats not different according to the diagram in the
reference manual.

  GIC domain
|--------------|
|              |---------- private
| non routable |---------- peripheral
|              |---------- peripheral
|              |
|--------------|           |--------------|
|              |           |              |
|   routable   |-----------|  IRQ router  |
|              |           |  domain      |
|              |           |              |
|--------------|           |--------------|
                           | Shared state |---------- CPU to CPU 
  NVIC domain              | and hardware |---------- peripheral
|--------------|           |              |---------- peripheral
|              |           |--------------|
|              |           |              |
|   routable   |-----------|  IRQ router  |
|              |           |  domain      |
|              |           |              |
|--------------|           |--------------|
|              |
|              |---------- private
| non routable |---------- peripheral
|              |---------- peripheral
|--------------|

The routable domain stuff is just an adhoc redirector which must be
tied to a particular base irq chip implementation (i.e. GIC). With
stacked irq domains there is no dependency on the underlying irq
chip. No ifdeffery, nothing. So you can use the same router domain
implementation for both the A5 and the M4 side.

On the A5 side the router domain has the gic domain as parent and on
the M4 side the nvic domain.

The shared interrupts are allocated through the router domain which
decides whether the interrupt can be assigned to a particular core or
not. If it can be assigned it allocates the corresponding interrupt in
the parent domain, sets up the routing and everything just works.

See: http://git.kernel.org/cgit/linux/kernel/git/tip/tip.git/log/?h=irq/irqdomain-arm

Thanks,

	tglx

Re: [PATCH 03/12] irqchip: gic: define register_routable_domain_ops conditional

[Thomas Gleixner]

On Wed, 3 Dec 2014, Arnd Bergmann wrote:

> On Wednesday 03 December 2014 01:12:02 Stefan Agner wrote:
> > The inline function register_routable_domain_ops is only usable if
> > CONFIG_ARM_GIC is set. Make it depend on this configuration. This
> > also allows other SoC interrupt controller to provide such a
> > function.
> > 
> > Signed-off-by: Stefan Agner <stefan-XLVq0VzYD2Y@public.gmane.org>
> 
> I don't think this is a good idea: either the interface is meant
> to be generic and should work with any interrupt controller, or
> it is specific to one irqchip and another irqchip should provide
> a different interface that has a nonconflicting name.
> 
> I suppose you want the latter here, given that the declaration
> is part of the gic specific header file.

That routable_domain stuff should have never been invented. In
hindsight we should have done the stacked irq domains back then
already, but in hindsight ...

If you look at the crossbar scheme what we have now:

   GIC domain
|--------------|
|              |---------- private
| non routable |---------- peripheral
|              |---------- peripheral
|              |
|--------------|
|              |---------- peripheral
|   routable   |---------- peripheral
|    |         |---------- peripheral
|--------------|
     |               |----------------|
     |-------------->| crossbar magic |
                     |----------------|

which is not how the hardware looks. The hardware actually looks like
this:

   GIC domain
|--------------|
|              |---------- private
| non routable |---------- peripheral
|              |---------- peripheral
|              |
|--------------|           |--------------|
|              |           |              |---------- peripheral
|   routable   |-----------| crossbar     |---------- peripheral
|              |           | domain       |---------- peripheral
|--------------|           |--------------|

So it is completely obvious that the peripheral interrupts which need
to be routed through the crossbar belong to a different domain. We
really should convert crossbar to that scheme and get rid of the
routable domain stuff completely.

With vybrid thats not different according to the diagram in the
reference manual.

  GIC domain
|--------------|
|              |---------- private
| non routable |---------- peripheral
|              |---------- peripheral
|              |
|--------------|           |--------------|
|              |           |              |
|   routable   |-----------|  IRQ router  |
|              |           |  domain      |
|              |           |              |
|--------------|           |--------------|
                           | Shared state |---------- CPU to CPU 
  NVIC domain              | and hardware |---------- peripheral
|--------------|           |              |---------- peripheral
|              |           |--------------|
|              |           |              |
|   routable   |-----------|  IRQ router  |
|              |           |  domain      |
|              |           |              |
|--------------|           |--------------|
|              |
|              |---------- private
| non routable |---------- peripheral
|              |---------- peripheral
|--------------|

The routable domain stuff is just an adhoc redirector which must be
tied to a particular base irq chip implementation (i.e. GIC). With
stacked irq domains there is no dependency on the underlying irq
chip. No ifdeffery, nothing. So you can use the same router domain
implementation for both the A5 and the M4 side.

On the A5 side the router domain has the gic domain as parent and on
the M4 side the nvic domain.

The shared interrupts are allocated through the router domain which
decides whether the interrupt can be assigned to a particular core or
not. If it can be assigned it allocates the corresponding interrupt in
the parent domain, sets up the routing and everything just works.

See: http://git.kernel.org/cgit/linux/kernel/git/tip/tip.git/log/?h=irq/irqdomain-arm

Thanks,

	tglx
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 03/12] irqchip: gic: define register_routable_domain_ops conditional

[Thomas Gleixner]

On Wed, 3 Dec 2014, Arnd Bergmann wrote:

> On Wednesday 03 December 2014 01:12:02 Stefan Agner wrote:
> > The inline function register_routable_domain_ops is only usable if
> > CONFIG_ARM_GIC is set. Make it depend on this configuration. This
> > also allows other SoC interrupt controller to provide such a
> > function.
> > 
> > Signed-off-by: Stefan Agner <stefan@agner.ch>
> 
> I don't think this is a good idea: either the interface is meant
> to be generic and should work with any interrupt controller, or
> it is specific to one irqchip and another irqchip should provide
> a different interface that has a nonconflicting name.
> 
> I suppose you want the latter here, given that the declaration
> is part of the gic specific header file.

That routable_domain stuff should have never been invented. In
hindsight we should have done the stacked irq domains back then
already, but in hindsight ...

If you look at the crossbar scheme what we have now:

   GIC domain
|--------------|
|              |---------- private
| non routable |---------- peripheral
|              |---------- peripheral
|              |
|--------------|
|              |---------- peripheral
|   routable   |---------- peripheral
|    |         |---------- peripheral
|--------------|
     |               |----------------|
     |-------------->| crossbar magic |
                     |----------------|

which is not how the hardware looks. The hardware actually looks like
this:

   GIC domain
|--------------|
|              |---------- private
| non routable |---------- peripheral
|              |---------- peripheral
|              |
|--------------|           |--------------|
|              |           |              |---------- peripheral
|   routable   |-----------| crossbar     |---------- peripheral
|              |           | domain       |---------- peripheral
|--------------|           |--------------|

So it is completely obvious that the peripheral interrupts which need
to be routed through the crossbar belong to a different domain. We
really should convert crossbar to that scheme and get rid of the
routable domain stuff completely.

With vybrid thats not different according to the diagram in the
reference manual.

  GIC domain
|--------------|
|              |---------- private
| non routable |---------- peripheral
|              |---------- peripheral
|              |
|--------------|           |--------------|
|              |           |              |
|   routable   |-----------|  IRQ router  |
|              |           |  domain      |
|              |           |              |
|--------------|           |--------------|
                           | Shared state |---------- CPU to CPU 
  NVIC domain              | and hardware |---------- peripheral
|--------------|           |              |---------- peripheral
|              |           |--------------|
|              |           |              |
|   routable   |-----------|  IRQ router  |
|              |           |  domain      |
|              |           |              |
|--------------|           |--------------|
|              |
|              |---------- private
| non routable |---------- peripheral
|              |---------- peripheral
|--------------|

The routable domain stuff is just an adhoc redirector which must be
tied to a particular base irq chip implementation (i.e. GIC). With
stacked irq domains there is no dependency on the underlying irq
chip. No ifdeffery, nothing. So you can use the same router domain
implementation for both the A5 and the M4 side.

On the A5 side the router domain has the gic domain as parent and on
the M4 side the nvic domain.

The shared interrupts are allocated through the router domain which
decides whether the interrupt can be assigned to a particular core or
not. If it can be assigned it allocates the corresponding interrupt in
the parent domain, sets up the routing and everything just works.

See: http://git.kernel.org/cgit/linux/kernel/git/tip/tip.git/log/?h=irq/irqdomain-arm

Thanks,

	tglx

Re: [PATCH 03/12] irqchip: gic: define register_routable_domain_ops conditional

[Stefan Agner]

On 2014-12-03 14:04, Thomas Gleixner wrote:
> On Wed, 3 Dec 2014, Arnd Bergmann wrote:
> 
>> On Wednesday 03 December 2014 01:12:02 Stefan Agner wrote:
>> > The inline function register_routable_domain_ops is only usable if
>> > CONFIG_ARM_GIC is set. Make it depend on this configuration. This
>> > also allows other SoC interrupt controller to provide such a
>> > function.
>> >
>> > Signed-off-by: Stefan Agner <stefan@agner.ch>
>>
>> I don't think this is a good idea: either the interface is meant
>> to be generic and should work with any interrupt controller, or
>> it is specific to one irqchip and another irqchip should provide
>> a different interface that has a nonconflicting name.
>>
>> I suppose you want the latter here, given that the declaration
>> is part of the gic specific header file.
> 
> That routable_domain stuff should have never been invented. In
> hindsight we should have done the stacked irq domains back then
> already, but in hindsight ...

I must admit that my first implementation even used arch_extn (through
the mask/unmask stuff). Then I saw the routable domain stuff, which
looked more like a fit. But when I realized that only GIC has support
for that, I soon realized that this might either need a proper
framework... my hackish NVIC extension probably won't be acceptable...

Stack-able IRQ domain sounds like exactly what I was looking for...

> 
> If you look at the crossbar scheme what we have now:
> 
>    GIC domain
> |--------------|
> |              |---------- private
> | non routable |---------- peripheral
> |              |---------- peripheral
> |              |
> |--------------|
> |              |---------- peripheral
> |   routable   |---------- peripheral
> |    |         |---------- peripheral
> |--------------|
>      |               |----------------|
>      |-------------->| crossbar magic |
>                      |----------------|
> 
> which is not how the hardware looks. The hardware actually looks like
> this:
> 
>    GIC domain
> |--------------|
> |              |---------- private
> | non routable |---------- peripheral
> |              |---------- peripheral
> |              |
> |--------------|           |--------------|
> |              |           |              |---------- peripheral
> |   routable   |-----------| crossbar     |---------- peripheral
> |              |           | domain       |---------- peripheral
> |--------------|           |--------------|
> 
> So it is completely obvious that the peripheral interrupts which need
> to be routed through the crossbar belong to a different domain. We
> really should convert crossbar to that scheme and get rid of the
> routable domain stuff completely.
> 
> With vybrid thats not different according to the diagram in the
> reference manual.
> 
>   GIC domain
> |--------------|
> |              |---------- private
> | non routable |---------- peripheral
> |              |---------- peripheral
> |              |
> |--------------|           |--------------|
> |              |           |              |
> |   routable   |-----------|  IRQ router  |
> |              |           |  domain      |
> |              |           |              |
> |--------------|           |--------------|
>                            | Shared state |---------- CPU to CPU 
>   NVIC domain              | and hardware |---------- peripheral
> |--------------|           |              |---------- peripheral
> |              |           |--------------|
> |              |           |              |
> |   routable   |-----------|  IRQ router  |
> |              |           |  domain      |
> |              |           |              |
> |--------------|           |--------------|
> |              |
> |              |---------- private
> | non routable |---------- peripheral
> |              |---------- peripheral
> |--------------|
> 
> The routable domain stuff is just an adhoc redirector which must be
> tied to a particular base irq chip implementation (i.e. GIC). With
> stacked irq domains there is no dependency on the underlying irq
> chip. No ifdeffery, nothing. So you can use the same router domain
> implementation for both the A5 and the M4 side.
> 
> On the A5 side the router domain has the gic domain as parent and on
> the M4 side the nvic domain.
> 
> The shared interrupts are allocated through the router domain which
> decides whether the interrupt can be assigned to a particular core or
> not. If it can be assigned it allocates the corresponding interrupt in
> the parent domain, sets up the routing and everything just works.

What do you mean by the shared state in the drawing above? Currently, I
check whether a interrupt is already used by the other core by reading
the register (do this configuration register reflect the "shared state"
in your drawing?).


> 
> See:
> http://git.kernel.org/cgit/linux/kernel/git/tip/tip.git/log/?h=irq/irqdomain-arm
> 

Thanks for the link. So my work would involve to support domain
hierarchy for NVIC (proper irq_domain_ops, introduce arm,routable-irqs
property, anything else?) and then make use of the hierarchy code in my
MSCM driver like for instance the mtk-sysirq driver...?

What is the state of the IRQ domain hierarchy, when will it go upstream?

--
Stefan

[PATCH 03/12] irqchip: gic: define register_routable_domain_ops conditional

[Stefan Agner]

On 2014-12-03 14:04, Thomas Gleixner wrote:
> On Wed, 3 Dec 2014, Arnd Bergmann wrote:
> 
>> On Wednesday 03 December 2014 01:12:02 Stefan Agner wrote:
>> > The inline function register_routable_domain_ops is only usable if
>> > CONFIG_ARM_GIC is set. Make it depend on this configuration. This
>> > also allows other SoC interrupt controller to provide such a
>> > function.
>> >
>> > Signed-off-by: Stefan Agner <stefan@agner.ch>
>>
>> I don't think this is a good idea: either the interface is meant
>> to be generic and should work with any interrupt controller, or
>> it is specific to one irqchip and another irqchip should provide
>> a different interface that has a nonconflicting name.
>>
>> I suppose you want the latter here, given that the declaration
>> is part of the gic specific header file.
> 
> That routable_domain stuff should have never been invented. In
> hindsight we should have done the stacked irq domains back then
> already, but in hindsight ...

I must admit that my first implementation even used arch_extn (through
the mask/unmask stuff). Then I saw the routable domain stuff, which
looked more like a fit. But when I realized that only GIC has support
for that, I soon realized that this might either need a proper
framework... my hackish NVIC extension probably won't be acceptable...

Stack-able IRQ domain sounds like exactly what I was looking for...

> 
> If you look at the crossbar scheme what we have now:
> 
>    GIC domain
> |--------------|
> |              |---------- private
> | non routable |---------- peripheral
> |              |---------- peripheral
> |              |
> |--------------|
> |              |---------- peripheral
> |   routable   |---------- peripheral
> |    |         |---------- peripheral
> |--------------|
>      |               |----------------|
>      |-------------->| crossbar magic |
>                      |----------------|
> 
> which is not how the hardware looks. The hardware actually looks like
> this:
> 
>    GIC domain
> |--------------|
> |              |---------- private
> | non routable |---------- peripheral
> |              |---------- peripheral
> |              |
> |--------------|           |--------------|
> |              |           |              |---------- peripheral
> |   routable   |-----------| crossbar     |---------- peripheral
> |              |           | domain       |---------- peripheral
> |--------------|           |--------------|
> 
> So it is completely obvious that the peripheral interrupts which need
> to be routed through the crossbar belong to a different domain. We
> really should convert crossbar to that scheme and get rid of the
> routable domain stuff completely.
> 
> With vybrid thats not different according to the diagram in the
> reference manual.
> 
>   GIC domain
> |--------------|
> |              |---------- private
> | non routable |---------- peripheral
> |              |---------- peripheral
> |              |
> |--------------|           |--------------|
> |              |           |              |
> |   routable   |-----------|  IRQ router  |
> |              |           |  domain      |
> |              |           |              |
> |--------------|           |--------------|
>                            | Shared state |---------- CPU to CPU 
>   NVIC domain              | and hardware |---------- peripheral
> |--------------|           |              |---------- peripheral
> |              |           |--------------|
> |              |           |              |
> |   routable   |-----------|  IRQ router  |
> |              |           |  domain      |
> |              |           |              |
> |--------------|           |--------------|
> |              |
> |              |---------- private
> | non routable |---------- peripheral
> |              |---------- peripheral
> |--------------|
> 
> The routable domain stuff is just an adhoc redirector which must be
> tied to a particular base irq chip implementation (i.e. GIC). With
> stacked irq domains there is no dependency on the underlying irq
> chip. No ifdeffery, nothing. So you can use the same router domain
> implementation for both the A5 and the M4 side.
> 
> On the A5 side the router domain has the gic domain as parent and on
> the M4 side the nvic domain.
> 
> The shared interrupts are allocated through the router domain which
> decides whether the interrupt can be assigned to a particular core or
> not. If it can be assigned it allocates the corresponding interrupt in
> the parent domain, sets up the routing and everything just works.

What do you mean by the shared state in the drawing above? Currently, I
check whether a interrupt is already used by the other core by reading
the register (do this configuration register reflect the "shared state"
in your drawing?).


> 
> See:
> http://git.kernel.org/cgit/linux/kernel/git/tip/tip.git/log/?h=irq/irqdomain-arm
> 

Thanks for the link. So my work would involve to support domain
hierarchy for NVIC (proper irq_domain_ops, introduce arm,routable-irqs
property, anything else?) and then make use of the hierarchy code in my
MSCM driver like for instance the mtk-sysirq driver...?

What is the state of the IRQ domain hierarchy, when will it go upstream?

--
Stefan

Re: [PATCH 04/12] irqchip: nvic: support routable irq domain ops

[Stefan Agner]

On 2014-12-03 11:49, Arnd Bergmann wrote:
> On Wednesday 03 December 2014 01:12:03 Stefan Agner wrote:
>> +#ifdef CONFIG_ARM_NVIC
>> +extern const struct irq_domain_ops *nvic_routable_irq_domain_ops;
>> +static inline void __init register_routable_domain_ops
>> +                                       (const struct irq_domain_ops *ops)
>> +{
>> +               nvic_routable_irq_domain_ops = ops;
>> +}
>> +#endif /* CONFIG_ARM_NVIC */
>>
> 
> As you mentioned, this conflicts with the gic specific declaration.
> Why not remove the #ifdef here and rename the function to
> nvic_register_routable_domain_ops() ?
> 
> If that doesn't work, I guess we need something more generic
> and move the routable_irq_domain_ops to some common location.
> 

This would move the ifdef to the MSCM driver code. I thought of having a
generic function to call, no matter what base IRQ chip is used.

Anyway, as tglx suggested in patch 3/12, I will try to use the IRQ
domain hierarchy stuff...

--
Stefan

Re: [PATCH 04/12] irqchip: nvic: support routable irq domain ops

[Stefan Agner]

On 2014-12-03 11:49, Arnd Bergmann wrote:
> On Wednesday 03 December 2014 01:12:03 Stefan Agner wrote:
>> +#ifdef CONFIG_ARM_NVIC
>> +extern const struct irq_domain_ops *nvic_routable_irq_domain_ops;
>> +static inline void __init register_routable_domain_ops
>> +                                       (const struct irq_domain_ops *ops)
>> +{
>> +               nvic_routable_irq_domain_ops = ops;
>> +}
>> +#endif /* CONFIG_ARM_NVIC */
>>
> 
> As you mentioned, this conflicts with the gic specific declaration.
> Why not remove the #ifdef here and rename the function to
> nvic_register_routable_domain_ops() ?
> 
> If that doesn't work, I guess we need something more generic
> and move the routable_irq_domain_ops to some common location.
> 

This would move the ifdef to the MSCM driver code. I thought of having a
generic function to call, no matter what base IRQ chip is used.

Anyway, as tglx suggested in patch 3/12, I will try to use the IRQ
domain hierarchy stuff...

--
Stefan


--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 04/12] irqchip: nvic: support routable irq domain ops

[Stefan Agner]

On 2014-12-03 11:49, Arnd Bergmann wrote:
> On Wednesday 03 December 2014 01:12:03 Stefan Agner wrote:
>> +#ifdef CONFIG_ARM_NVIC
>> +extern const struct irq_domain_ops *nvic_routable_irq_domain_ops;
>> +static inline void __init register_routable_domain_ops
>> +                                       (const struct irq_domain_ops *ops)
>> +{
>> +               nvic_routable_irq_domain_ops = ops;
>> +}
>> +#endif /* CONFIG_ARM_NVIC */
>>
> 
> As you mentioned, this conflicts with the gic specific declaration.
> Why not remove the #ifdef here and rename the function to
> nvic_register_routable_domain_ops() ?
> 
> If that doesn't work, I guess we need something more generic
> and move the routable_irq_domain_ops to some common location.
> 

This would move the ifdef to the MSCM driver code. I thought of having a
generic function to call, no matter what base IRQ chip is used.

Anyway, as tglx suggested in patch 3/12, I will try to use the IRQ
domain hierarchy stuff...

--
Stefan

Re: [PATCH 05/12] irqchip: nvic: increase number of external interrupts to 112

[Stefan Agner]

On 2014-12-03 09:12, Uwe Kleine-König wrote:
> Hallo Stefan,
> 
> On Wed, Dec 03, 2014 at 01:12:04AM +0100, Stefan Agner wrote:
>> So far only vectors for up to 48 external interrupts have been
>> registred in the vector table. Increase the amount of registred
> s/registred/registered/
> 
>> external vectors to 112. Also, add a warning in case NVIC reports
>> support for more interrupts than 128.
> s/interrupts than 128/than 128 interrupts/ (not sure about this one)
> 
>> Note: the vector table must align to the number of entires in the
> s/entires/entries/
> 
> Maybe point out that "X external interrupts" corresponds to "X + 16
> vectors".
> 
>> vector table, hence increase the alignment to 0x200.
>>
>> Signed-off-by: Stefan Agner <stefan@agner.ch>
>> ---
>>  arch/arm/kernel/entry-v7m.S | 6 +++---
>>  drivers/irqchip/irq-nvic.c  | 2 ++
>>  2 files changed, 5 insertions(+), 3 deletions(-)
>>
>> diff --git a/arch/arm/kernel/entry-v7m.S b/arch/arm/kernel/entry-v7m.S
>> index 2260f18..754a1fa 100644
>> --- a/arch/arm/kernel/entry-v7m.S
>> +++ b/arch/arm/kernel/entry-v7m.S
>> @@ -115,7 +115,7 @@ ENTRY(__switch_to)
>>  ENDPROC(__switch_to)
>>
>>  	.data
>> -	.align	8
>> +	.align	9
>>  /*
>>   * Vector table (64 words => 256 bytes natural alignment)
> This comment needs fixing
> 
>>   */
>> @@ -136,6 +136,6 @@ ENTRY(vector_table)
>>  	.long	__invalid_entry		@ 13 - Reserved
>>  	.long	__pendsv_entry		@ 14 - PendSV
>>  	.long	__invalid_entry		@ 15 - SysTick
>> -	.rept	64 - 16
>> -	.long	__irq_entry		@ 16..64 - External Interrupts
>> +	.rept	128 - 16
>> +	.long	__irq_entry		@ 16..128 - External Interrupts
>>  	.endr
>> diff --git a/drivers/irqchip/irq-nvic.c b/drivers/irqchip/irq-nvic.c
>> index dbfb5be..40f62a9 100644
>> --- a/drivers/irqchip/irq-nvic.c
>> +++ b/drivers/irqchip/irq-nvic.c
>> @@ -137,6 +137,8 @@ static int __init nvic_of_init(struct device_node *node,
>>  	if (irqs > NVIC_MAX_IRQ)
>>  		irqs = NVIC_MAX_IRQ;
>>
>> +	WARN(irqs > 128, "vector table in entry-v7m.S configured for 128 irqs");
>> +
> That's pointless. Better do:
> 
> 	if (WARN(irqs > 128, "vector table in entry-v7m.S configured for 128 irqs"))
> 		irqs = 128;
> 
> Hmm, I wonder if that is correct. The first 16 exceptions are the system
> exception that will not be registered be drivers and so exception 16
> (i.e. the first regular irq) is reported as hwirq 0. So I think we can
> (in a separate patch) pass irqs - 16 to irq_domain_add_linear. Didn't
> test that though.

Hm, I think you are correct yes. NVIC interrupt ID's are shifted by 16
compared to the Cortex-M4 vector table. Also the irq check above would
need to take care of that.

I anyway need to have a look into that, since I need to make sure that I
work with the right interrupt ID's for both cores M4 (NVIC) and A5
(GIC)... The assignment is quite nicely listed in chapter 3.2.4
(Interrupt Assignments) in the Vybrid RM. The table also supports your
statement above.

Agreed on all the rest.

--
Stefan

> 
>>  	nvic_irq_domain =
>>  		irq_domain_add_linear(node, irqs, &nvic_irq_domain_ops, NULL);
>>  	if (!nvic_irq_domain) {

Re: [PATCH 05/12] irqchip: nvic: increase number of external interrupts to 112

[Stefan Agner]

On 2014-12-03 09:12, Uwe Kleine-König wrote:
> Hallo Stefan,
> 
> On Wed, Dec 03, 2014 at 01:12:04AM +0100, Stefan Agner wrote:
>> So far only vectors for up to 48 external interrupts have been
>> registred in the vector table. Increase the amount of registred
> s/registred/registered/
> 
>> external vectors to 112. Also, add a warning in case NVIC reports
>> support for more interrupts than 128.
> s/interrupts than 128/than 128 interrupts/ (not sure about this one)
> 
>> Note: the vector table must align to the number of entires in the
> s/entires/entries/
> 
> Maybe point out that "X external interrupts" corresponds to "X + 16
> vectors".
> 
>> vector table, hence increase the alignment to 0x200.
>>
>> Signed-off-by: Stefan Agner <stefan-XLVq0VzYD2Y@public.gmane.org>
>> ---
>>  arch/arm/kernel/entry-v7m.S | 6 +++---
>>  drivers/irqchip/irq-nvic.c  | 2 ++
>>  2 files changed, 5 insertions(+), 3 deletions(-)
>>
>> diff --git a/arch/arm/kernel/entry-v7m.S b/arch/arm/kernel/entry-v7m.S
>> index 2260f18..754a1fa 100644
>> --- a/arch/arm/kernel/entry-v7m.S
>> +++ b/arch/arm/kernel/entry-v7m.S
>> @@ -115,7 +115,7 @@ ENTRY(__switch_to)
>>  ENDPROC(__switch_to)
>>
>>  	.data
>> -	.align	8
>> +	.align	9
>>  /*
>>   * Vector table (64 words => 256 bytes natural alignment)
> This comment needs fixing
> 
>>   */
>> @@ -136,6 +136,6 @@ ENTRY(vector_table)
>>  	.long	__invalid_entry		@ 13 - Reserved
>>  	.long	__pendsv_entry		@ 14 - PendSV
>>  	.long	__invalid_entry		@ 15 - SysTick
>> -	.rept	64 - 16
>> -	.long	__irq_entry		@ 16..64 - External Interrupts
>> +	.rept	128 - 16
>> +	.long	__irq_entry		@ 16..128 - External Interrupts
>>  	.endr
>> diff --git a/drivers/irqchip/irq-nvic.c b/drivers/irqchip/irq-nvic.c
>> index dbfb5be..40f62a9 100644
>> --- a/drivers/irqchip/irq-nvic.c
>> +++ b/drivers/irqchip/irq-nvic.c
>> @@ -137,6 +137,8 @@ static int __init nvic_of_init(struct device_node *node,
>>  	if (irqs > NVIC_MAX_IRQ)
>>  		irqs = NVIC_MAX_IRQ;
>>
>> +	WARN(irqs > 128, "vector table in entry-v7m.S configured for 128 irqs");
>> +
> That's pointless. Better do:
> 
> 	if (WARN(irqs > 128, "vector table in entry-v7m.S configured for 128 irqs"))
> 		irqs = 128;
> 
> Hmm, I wonder if that is correct. The first 16 exceptions are the system
> exception that will not be registered be drivers and so exception 16
> (i.e. the first regular irq) is reported as hwirq 0. So I think we can
> (in a separate patch) pass irqs - 16 to irq_domain_add_linear. Didn't
> test that though.

Hm, I think you are correct yes. NVIC interrupt ID's are shifted by 16
compared to the Cortex-M4 vector table. Also the irq check above would
need to take care of that.

I anyway need to have a look into that, since I need to make sure that I
work with the right interrupt ID's for both cores M4 (NVIC) and A5
(GIC)... The assignment is quite nicely listed in chapter 3.2.4
(Interrupt Assignments) in the Vybrid RM. The table also supports your
statement above.

Agreed on all the rest.

--
Stefan

> 
>>  	nvic_irq_domain =
>>  		irq_domain_add_linear(node, irqs, &nvic_irq_domain_ops, NULL);
>>  	if (!nvic_irq_domain) {

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 05/12] irqchip: nvic: increase number of external interrupts to 112

[Stefan Agner]

On 2014-12-03 09:12, Uwe Kleine-K?nig wrote:
> Hallo Stefan,
> 
> On Wed, Dec 03, 2014 at 01:12:04AM +0100, Stefan Agner wrote:
>> So far only vectors for up to 48 external interrupts have been
>> registred in the vector table. Increase the amount of registred
> s/registred/registered/
> 
>> external vectors to 112. Also, add a warning in case NVIC reports
>> support for more interrupts than 128.
> s/interrupts than 128/than 128 interrupts/ (not sure about this one)
> 
>> Note: the vector table must align to the number of entires in the
> s/entires/entries/
> 
> Maybe point out that "X external interrupts" corresponds to "X + 16
> vectors".
> 
>> vector table, hence increase the alignment to 0x200.
>>
>> Signed-off-by: Stefan Agner <stefan@agner.ch>
>> ---
>>  arch/arm/kernel/entry-v7m.S | 6 +++---
>>  drivers/irqchip/irq-nvic.c  | 2 ++
>>  2 files changed, 5 insertions(+), 3 deletions(-)
>>
>> diff --git a/arch/arm/kernel/entry-v7m.S b/arch/arm/kernel/entry-v7m.S
>> index 2260f18..754a1fa 100644
>> --- a/arch/arm/kernel/entry-v7m.S
>> +++ b/arch/arm/kernel/entry-v7m.S
>> @@ -115,7 +115,7 @@ ENTRY(__switch_to)
>>  ENDPROC(__switch_to)
>>
>>  	.data
>> -	.align	8
>> +	.align	9
>>  /*
>>   * Vector table (64 words => 256 bytes natural alignment)
> This comment needs fixing
> 
>>   */
>> @@ -136,6 +136,6 @@ ENTRY(vector_table)
>>  	.long	__invalid_entry		@ 13 - Reserved
>>  	.long	__pendsv_entry		@ 14 - PendSV
>>  	.long	__invalid_entry		@ 15 - SysTick
>> -	.rept	64 - 16
>> -	.long	__irq_entry		@ 16..64 - External Interrupts
>> +	.rept	128 - 16
>> +	.long	__irq_entry		@ 16..128 - External Interrupts
>>  	.endr
>> diff --git a/drivers/irqchip/irq-nvic.c b/drivers/irqchip/irq-nvic.c
>> index dbfb5be..40f62a9 100644
>> --- a/drivers/irqchip/irq-nvic.c
>> +++ b/drivers/irqchip/irq-nvic.c
>> @@ -137,6 +137,8 @@ static int __init nvic_of_init(struct device_node *node,
>>  	if (irqs > NVIC_MAX_IRQ)
>>  		irqs = NVIC_MAX_IRQ;
>>
>> +	WARN(irqs > 128, "vector table in entry-v7m.S configured for 128 irqs");
>> +
> That's pointless. Better do:
> 
> 	if (WARN(irqs > 128, "vector table in entry-v7m.S configured for 128 irqs"))
> 		irqs = 128;
> 
> Hmm, I wonder if that is correct. The first 16 exceptions are the system
> exception that will not be registered be drivers and so exception 16
> (i.e. the first regular irq) is reported as hwirq 0. So I think we can
> (in a separate patch) pass irqs - 16 to irq_domain_add_linear. Didn't
> test that though.

Hm, I think you are correct yes. NVIC interrupt ID's are shifted by 16
compared to the Cortex-M4 vector table. Also the irq check above would
need to take care of that.

I anyway need to have a look into that, since I need to make sure that I
work with the right interrupt ID's for both cores M4 (NVIC) and A5
(GIC)... The assignment is quite nicely listed in chapter 3.2.4
(Interrupt Assignments) in the Vybrid RM. The table also supports your
statement above.

Agreed on all the rest.

--
Stefan

> 
>>  	nvic_irq_domain =
>>  		irq_domain_add_linear(node, irqs, &nvic_irq_domain_ops, NULL);
>>  	if (!nvic_irq_domain) {

Re: [PATCH 07/12] Documentation: dt: imx: add MSCM documentation

[Stefan Agner]

On 2014-12-03 11:52, Arnd Bergmann wrote:
> On Wednesday 03 December 2014 01:12:06 Stefan Agner wrote:
>> +Freescale Vybrid Miscellaneous System Control Module
>> +
>> +The MSCM IP contains Access Control and TrustZone Security hardware,
>> +CPU Configuration registers and Interrupt Router control.
>> +
>> +Required properties:
>> +- compatible : "fsl,vf610-mscm"
>> +- reg : the register range of the MSCM module
>> +
>> +Example:
>> +       mscm: mscm@40001000 {
>> +               compatible = "fsl,vf610-mscm";
>> +               reg = <0x40001000 0x1000>;
>> +       };
> 
> This sounds like one of those generic system controller devices.
> Should this be marked as syscon an accessed through
> syscon_regmap_lookup_by_phandle()?
> 
> If you only eve have one driver touching these registers, that
> won't be necessary of course.
> 

So far, in upstream code the module is not used at all (other than in
U-Boot setting up the interrupt router in a static manner). I think it
is not that "miscellaneous" as it sounds, it mainly controls and
provides information regarding the dual-core stuff, for instance provide
interrupt flags for the CPU-to-CPU interrupts or exports CPU information
(beside the interrupt routing thing). I don't know (yet) if and how we
want export support for that interrupt. We would certainly need it to
support some message based framework (Freescale used it for their
out-of-tree MCC (multi-core communication) stuff, probably we would need
it to implement rpmsg support...).

--
Stefan

Re: [PATCH 07/12] Documentation: dt: imx: add MSCM documentation

[Stefan Agner]

On 2014-12-03 11:52, Arnd Bergmann wrote:
> On Wednesday 03 December 2014 01:12:06 Stefan Agner wrote:
>> +Freescale Vybrid Miscellaneous System Control Module
>> +
>> +The MSCM IP contains Access Control and TrustZone Security hardware,
>> +CPU Configuration registers and Interrupt Router control.
>> +
>> +Required properties:
>> +- compatible : "fsl,vf610-mscm"
>> +- reg : the register range of the MSCM module
>> +
>> +Example:
>> +       mscm: mscm@40001000 {
>> +               compatible = "fsl,vf610-mscm";
>> +               reg = <0x40001000 0x1000>;
>> +       };
> 
> This sounds like one of those generic system controller devices.
> Should this be marked as syscon an accessed through
> syscon_regmap_lookup_by_phandle()?
> 
> If you only eve have one driver touching these registers, that
> won't be necessary of course.
> 

So far, in upstream code the module is not used at all (other than in
U-Boot setting up the interrupt router in a static manner). I think it
is not that "miscellaneous" as it sounds, it mainly controls and
provides information regarding the dual-core stuff, for instance provide
interrupt flags for the CPU-to-CPU interrupts or exports CPU information
(beside the interrupt routing thing). I don't know (yet) if and how we
want export support for that interrupt. We would certainly need it to
support some message based framework (Freescale used it for their
out-of-tree MCC (multi-core communication) stuff, probably we would need
it to implement rpmsg support...).

--
Stefan

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 07/12] Documentation: dt: imx: add MSCM documentation

[Stefan Agner]

On 2014-12-03 11:52, Arnd Bergmann wrote:
> On Wednesday 03 December 2014 01:12:06 Stefan Agner wrote:
>> +Freescale Vybrid Miscellaneous System Control Module
>> +
>> +The MSCM IP contains Access Control and TrustZone Security hardware,
>> +CPU Configuration registers and Interrupt Router control.
>> +
>> +Required properties:
>> +- compatible : "fsl,vf610-mscm"
>> +- reg : the register range of the MSCM module
>> +
>> +Example:
>> +       mscm: mscm at 40001000 {
>> +               compatible = "fsl,vf610-mscm";
>> +               reg = <0x40001000 0x1000>;
>> +       };
> 
> This sounds like one of those generic system controller devices.
> Should this be marked as syscon an accessed through
> syscon_regmap_lookup_by_phandle()?
> 
> If you only eve have one driver touching these registers, that
> won't be necessary of course.
> 

So far, in upstream code the module is not used at all (other than in
U-Boot setting up the interrupt router in a static manner). I think it
is not that "miscellaneous" as it sounds, it mainly controls and
provides information regarding the dual-core stuff, for instance provide
interrupt flags for the CPU-to-CPU interrupts or exports CPU information
(beside the interrupt routing thing). I don't know (yet) if and how we
want export support for that interrupt. We would certainly need it to
support some message based framework (Freescale used it for their
out-of-tree MCC (multi-core communication) stuff, probably we would need
it to implement rpmsg support...).

--
Stefan

Re: [PATCH 10/12] ARM: vf610m4: add new machine and SoC for Vybrid on Cortex-M4

[Stefan Agner]

On 2014-12-03 11:56, Arnd Bergmann wrote:
> On Wednesday 03 December 2014 01:12:09 Stefan Agner wrote:
>> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
>> index 89c4b5c..fdebe18 100644
>> --- a/arch/arm/Kconfig
>> +++ b/arch/arm/Kconfig
>> @@ -459,6 +459,18 @@ config ARCH_FOOTBRIDGE
>>  	  Support for systems based on the DC21285 companion chip
>>  	  ("FootBridge"), such as the Simtec CATS and the Rebel NetWinder.
>>
>> +menuconfig ARCH_MXCM4
>> +	bool "Freescale Vybrid/i.MX family on Cortex-M4" if !MMU
>> +	select ARCH_REQUIRE_GPIOLIB
>> +	select ARM_CPU_SUSPEND if PM
>> +	select CLKSRC_MMIO
>> +	select GENERIC_IRQ_CHIP
>> +	select PINCTRL
>> +	select PM_OPP if PM
>> +	select SOC_BUS
>> +	help
>> +	  Support for Freescale Vybrid/iMX-based family of processors on Cortex-M4
>> +
>>  config ARCH_NETX
>>  	bool "Hilscher NetX based"
>>  	select ARM_VIC
> 
> I would really prefer not to see any more standalone machine types,
> but rather have ARMv7-M as one of the options for the
> multiplatform configuration. In particular, that would let us
> do *build* testing on a combined mxcm4/efm32/vexpress kernel,
> although that kernel would clearly not be usable anywhere
> because of the restrictions of nommu machines.

Yes me too, but as I pointed out in the cover letter, I'm not sure I'm
up to that task.... I'm not at all in a hurry with the Vybrid M4 Linux
stuff, so I can wait until that is resolved or maybe try to resolve that
myself (again)...

Beside that the multi-platform would help do build tests, Vybrid is also
a nice platform to do smoke tests on a !MMU platform. Uwe would be happy
about that, as he discovered that !MMU was broken for several releases
lately :-)

> 
>> +static void __init vf610m4_init_irq(void)
>> +{
>> +	vf610_mscm_init();
>> +	irqchip_init();
>> +}
> 
> Can you make vf610_mscm_init get called from irqchip and remove this
> function?
> 

I guess you mean by IRQCHIP_DECLARE? I hesitated to do this since I only
found drivers in drivers/irqchip using that. However, MSCM is currently
part of mach-imx. First I used arch_extn to implement the functionality,
so I thought it really fits more into arch. But I guess when it is a
normal irqchip driver, I will have to move it anyway, despite the fact
that it is only available on Vybrid....?

--
Stefan

Re: [PATCH 10/12] ARM: vf610m4: add new machine and SoC for Vybrid on Cortex-M4

[Stefan Agner]

On 2014-12-03 11:56, Arnd Bergmann wrote:
> On Wednesday 03 December 2014 01:12:09 Stefan Agner wrote:
>> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
>> index 89c4b5c..fdebe18 100644
>> --- a/arch/arm/Kconfig
>> +++ b/arch/arm/Kconfig
>> @@ -459,6 +459,18 @@ config ARCH_FOOTBRIDGE
>>  	  Support for systems based on the DC21285 companion chip
>>  	  ("FootBridge"), such as the Simtec CATS and the Rebel NetWinder.
>>
>> +menuconfig ARCH_MXCM4
>> +	bool "Freescale Vybrid/i.MX family on Cortex-M4" if !MMU
>> +	select ARCH_REQUIRE_GPIOLIB
>> +	select ARM_CPU_SUSPEND if PM
>> +	select CLKSRC_MMIO
>> +	select GENERIC_IRQ_CHIP
>> +	select PINCTRL
>> +	select PM_OPP if PM
>> +	select SOC_BUS
>> +	help
>> +	  Support for Freescale Vybrid/iMX-based family of processors on Cortex-M4
>> +
>>  config ARCH_NETX
>>  	bool "Hilscher NetX based"
>>  	select ARM_VIC
> 
> I would really prefer not to see any more standalone machine types,
> but rather have ARMv7-M as one of the options for the
> multiplatform configuration. In particular, that would let us
> do *build* testing on a combined mxcm4/efm32/vexpress kernel,
> although that kernel would clearly not be usable anywhere
> because of the restrictions of nommu machines.

Yes me too, but as I pointed out in the cover letter, I'm not sure I'm
up to that task.... I'm not at all in a hurry with the Vybrid M4 Linux
stuff, so I can wait until that is resolved or maybe try to resolve that
myself (again)...

Beside that the multi-platform would help do build tests, Vybrid is also
a nice platform to do smoke tests on a !MMU platform. Uwe would be happy
about that, as he discovered that !MMU was broken for several releases
lately :-)

> 
>> +static void __init vf610m4_init_irq(void)
>> +{
>> +	vf610_mscm_init();
>> +	irqchip_init();
>> +}
> 
> Can you make vf610_mscm_init get called from irqchip and remove this
> function?
> 

I guess you mean by IRQCHIP_DECLARE? I hesitated to do this since I only
found drivers in drivers/irqchip using that. However, MSCM is currently
part of mach-imx. First I used arch_extn to implement the functionality,
so I thought it really fits more into arch. But I guess when it is a
normal irqchip driver, I will have to move it anyway, despite the fact
that it is only available on Vybrid....?

--
Stefan


--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 10/12] ARM: vf610m4: add new machine and SoC for Vybrid on Cortex-M4

[Stefan Agner]

On 2014-12-03 11:56, Arnd Bergmann wrote:
> On Wednesday 03 December 2014 01:12:09 Stefan Agner wrote:
>> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
>> index 89c4b5c..fdebe18 100644
>> --- a/arch/arm/Kconfig
>> +++ b/arch/arm/Kconfig
>> @@ -459,6 +459,18 @@ config ARCH_FOOTBRIDGE
>>  	  Support for systems based on the DC21285 companion chip
>>  	  ("FootBridge"), such as the Simtec CATS and the Rebel NetWinder.
>>
>> +menuconfig ARCH_MXCM4
>> +	bool "Freescale Vybrid/i.MX family on Cortex-M4" if !MMU
>> +	select ARCH_REQUIRE_GPIOLIB
>> +	select ARM_CPU_SUSPEND if PM
>> +	select CLKSRC_MMIO
>> +	select GENERIC_IRQ_CHIP
>> +	select PINCTRL
>> +	select PM_OPP if PM
>> +	select SOC_BUS
>> +	help
>> +	  Support for Freescale Vybrid/iMX-based family of processors on Cortex-M4
>> +
>>  config ARCH_NETX
>>  	bool "Hilscher NetX based"
>>  	select ARM_VIC
> 
> I would really prefer not to see any more standalone machine types,
> but rather have ARMv7-M as one of the options for the
> multiplatform configuration. In particular, that would let us
> do *build* testing on a combined mxcm4/efm32/vexpress kernel,
> although that kernel would clearly not be usable anywhere
> because of the restrictions of nommu machines.

Yes me too, but as I pointed out in the cover letter, I'm not sure I'm
up to that task.... I'm not at all in a hurry with the Vybrid M4 Linux
stuff, so I can wait until that is resolved or maybe try to resolve that
myself (again)...

Beside that the multi-platform would help do build tests, Vybrid is also
a nice platform to do smoke tests on a !MMU platform. Uwe would be happy
about that, as he discovered that !MMU was broken for several releases
lately :-)

> 
>> +static void __init vf610m4_init_irq(void)
>> +{
>> +	vf610_mscm_init();
>> +	irqchip_init();
>> +}
> 
> Can you make vf610_mscm_init get called from irqchip and remove this
> function?
> 

I guess you mean by IRQCHIP_DECLARE? I hesitated to do this since I only
found drivers in drivers/irqchip using that. However, MSCM is currently
part of mach-imx. First I used arch_extn to implement the functionality,
so I thought it really fits more into arch. But I guess when it is a
normal irqchip driver, I will have to move it anyway, despite the fact
that it is only available on Vybrid....?

--
Stefan

Re: [PATCH 03/12] irqchip: gic: define register_routable_domain_ops conditional

[Marc Zyngier]

Hi Stefan,

On 03/12/14 17:28, Stefan Agner wrote:
> On 2014-12-03 14:04, Thomas Gleixner wrote:
>> On Wed, 3 Dec 2014, Arnd Bergmann wrote:
>>
>>> On Wednesday 03 December 2014 01:12:02 Stefan Agner wrote:
>>>> The inline function register_routable_domain_ops is only usable if
>>>> CONFIG_ARM_GIC is set. Make it depend on this configuration. This
>>>> also allows other SoC interrupt controller to provide such a
>>>> function.
>>>>
>>>> Signed-off-by: Stefan Agner <stefan@agner.ch>
>>>
>>> I don't think this is a good idea: either the interface is meant
>>> to be generic and should work with any interrupt controller, or
>>> it is specific to one irqchip and another irqchip should provide
>>> a different interface that has a nonconflicting name.
>>>
>>> I suppose you want the latter here, given that the declaration
>>> is part of the gic specific header file.
>>
>> That routable_domain stuff should have never been invented. In
>> hindsight we should have done the stacked irq domains back then
>> already, but in hindsight ...
> 
> I must admit that my first implementation even used arch_extn (through

I'm glad I didn't see that! ;-)

> the mask/unmask stuff). Then I saw the routable domain stuff, which
> looked more like a fit. But when I realized that only GIC has support
> for that, I soon realized that this might either need a proper
> framework... my hackish NVIC extension probably won't be acceptable...
> 
> Stack-able IRQ domain sounds like exactly what I was looking for...

Like Thomas said, we should have had that ages ago. It solves so many
problems in one go it's mind-boggling. On the down side, we end-up
refactoring *a lot* of the existing code...

>>
>> If you look at the crossbar scheme what we have now:
>>
>>    GIC domain
>> |--------------|
>> |              |---------- private
>> | non routable |---------- peripheral
>> |              |---------- peripheral
>> |              |
>> |--------------|
>> |              |---------- peripheral
>> |   routable   |---------- peripheral
>> |    |         |---------- peripheral
>> |--------------|
>>      |               |----------------|
>>      |-------------->| crossbar magic |
>>                      |----------------|
>>
>> which is not how the hardware looks. The hardware actually looks like
>> this:
>>
>>    GIC domain
>> |--------------|
>> |              |---------- private
>> | non routable |---------- peripheral
>> |              |---------- peripheral
>> |              |
>> |--------------|           |--------------|
>> |              |           |              |---------- peripheral
>> |   routable   |-----------| crossbar     |---------- peripheral
>> |              |           | domain       |---------- peripheral
>> |--------------|           |--------------|
>>
>> So it is completely obvious that the peripheral interrupts which need
>> to be routed through the crossbar belong to a different domain. We
>> really should convert crossbar to that scheme and get rid of the
>> routable domain stuff completely.
>>
>> With vybrid thats not different according to the diagram in the
>> reference manual.
>>
>>   GIC domain
>> |--------------|
>> |              |---------- private
>> | non routable |---------- peripheral
>> |              |---------- peripheral
>> |              |
>> |--------------|           |--------------|
>> |              |           |              |
>> |   routable   |-----------|  IRQ router  |
>> |              |           |  domain      |
>> |              |           |              |
>> |--------------|           |--------------|
>>                            | Shared state |---------- CPU to CPU 
>>   NVIC domain              | and hardware |---------- peripheral
>> |--------------|           |              |---------- peripheral
>> |              |           |--------------|
>> |              |           |              |
>> |   routable   |-----------|  IRQ router  |
>> |              |           |  domain      |
>> |              |           |              |
>> |--------------|           |--------------|
>> |              |
>> |              |---------- private
>> | non routable |---------- peripheral
>> |              |---------- peripheral
>> |--------------|
>>
>> The routable domain stuff is just an adhoc redirector which must be
>> tied to a particular base irq chip implementation (i.e. GIC). With
>> stacked irq domains there is no dependency on the underlying irq
>> chip. No ifdeffery, nothing. So you can use the same router domain
>> implementation for both the A5 and the M4 side.
>>
>> On the A5 side the router domain has the gic domain as parent and on
>> the M4 side the nvic domain.
>>
>> The shared interrupts are allocated through the router domain which
>> decides whether the interrupt can be assigned to a particular core or
>> not. If it can be assigned it allocates the corresponding interrupt in
>> the parent domain, sets up the routing and everything just works.
> 
> What do you mean by the shared state in the drawing above? Currently, I
> check whether a interrupt is already used by the other core by reading
> the register (do this configuration register reflect the "shared state"
> in your drawing?).

I think that is basically it. It should only be the register that
decides on the actual routing. BTW, how do you arbitrate between
concurrent accesses to this register? Or is only the A5 allowed to
change it?

> 
>>
>> See:
>> http://git.kernel.org/cgit/linux/kernel/git/tip/tip.git/log/?h=irq/irqdomain-arm
>>
> 
> Thanks for the link. So my work would involve to support domain
> hierarchy for NVIC (proper irq_domain_ops, introduce arm,routable-irqs
> property, anything else?) and then make use of the hierarchy code in my
> MSCM driver like for instance the mtk-sysirq driver...?

I don't think we need the arm,routable-irq property at all, and I'm
looking at refactoring the crossbar thingy to remove most of its
entanglement with the GIC.

All you need to know is the range of interrupts you're allowed to
request through the "routable" domain. The inner-most irqchip shouldn't
even know about it (after all, they are just wires coming in). It should
be the duty of the outer-most irqchip (the "router") to generate the
correct request to the GIC/NVIC. So all the knowledge should be at the
router level.

The mtk-sysrq code is indeed a good example of what you can do.

> What is the state of the IRQ domain hierarchy, when will it go upstream?

Scheduled for 3.19, if everything goes according to plan. Don't think we
can go back anyway... ;-)

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...

Re: [PATCH 03/12] irqchip: gic: define register_routable_domain_ops conditional

[Marc Zyngier]

Hi Stefan,

On 03/12/14 17:28, Stefan Agner wrote:
> On 2014-12-03 14:04, Thomas Gleixner wrote:
>> On Wed, 3 Dec 2014, Arnd Bergmann wrote:
>>
>>> On Wednesday 03 December 2014 01:12:02 Stefan Agner wrote:
>>>> The inline function register_routable_domain_ops is only usable if
>>>> CONFIG_ARM_GIC is set. Make it depend on this configuration. This
>>>> also allows other SoC interrupt controller to provide such a
>>>> function.
>>>>
>>>> Signed-off-by: Stefan Agner <stefan-XLVq0VzYD2Y@public.gmane.org>
>>>
>>> I don't think this is a good idea: either the interface is meant
>>> to be generic and should work with any interrupt controller, or
>>> it is specific to one irqchip and another irqchip should provide
>>> a different interface that has a nonconflicting name.
>>>
>>> I suppose you want the latter here, given that the declaration
>>> is part of the gic specific header file.
>>
>> That routable_domain stuff should have never been invented. In
>> hindsight we should have done the stacked irq domains back then
>> already, but in hindsight ...
> 
> I must admit that my first implementation even used arch_extn (through

I'm glad I didn't see that! ;-)

> the mask/unmask stuff). Then I saw the routable domain stuff, which
> looked more like a fit. But when I realized that only GIC has support
> for that, I soon realized that this might either need a proper
> framework... my hackish NVIC extension probably won't be acceptable...
> 
> Stack-able IRQ domain sounds like exactly what I was looking for...

Like Thomas said, we should have had that ages ago. It solves so many
problems in one go it's mind-boggling. On the down side, we end-up
refactoring *a lot* of the existing code...

>>
>> If you look at the crossbar scheme what we have now:
>>
>>    GIC domain
>> |--------------|
>> |              |---------- private
>> | non routable |---------- peripheral
>> |              |---------- peripheral
>> |              |
>> |--------------|
>> |              |---------- peripheral
>> |   routable   |---------- peripheral
>> |    |         |---------- peripheral
>> |--------------|
>>      |               |----------------|
>>      |-------------->| crossbar magic |
>>                      |----------------|
>>
>> which is not how the hardware looks. The hardware actually looks like
>> this:
>>
>>    GIC domain
>> |--------------|
>> |              |---------- private
>> | non routable |---------- peripheral
>> |              |---------- peripheral
>> |              |
>> |--------------|           |--------------|
>> |              |           |              |---------- peripheral
>> |   routable   |-----------| crossbar     |---------- peripheral
>> |              |           | domain       |---------- peripheral
>> |--------------|           |--------------|
>>
>> So it is completely obvious that the peripheral interrupts which need
>> to be routed through the crossbar belong to a different domain. We
>> really should convert crossbar to that scheme and get rid of the
>> routable domain stuff completely.
>>
>> With vybrid thats not different according to the diagram in the
>> reference manual.
>>
>>   GIC domain
>> |--------------|
>> |              |---------- private
>> | non routable |---------- peripheral
>> |              |---------- peripheral
>> |              |
>> |--------------|           |--------------|
>> |              |           |              |
>> |   routable   |-----------|  IRQ router  |
>> |              |           |  domain      |
>> |              |           |              |
>> |--------------|           |--------------|
>>                            | Shared state |---------- CPU to CPU 
>>   NVIC domain              | and hardware |---------- peripheral
>> |--------------|           |              |---------- peripheral
>> |              |           |--------------|
>> |              |           |              |
>> |   routable   |-----------|  IRQ router  |
>> |              |           |  domain      |
>> |              |           |              |
>> |--------------|           |--------------|
>> |              |
>> |              |---------- private
>> | non routable |---------- peripheral
>> |              |---------- peripheral
>> |--------------|
>>
>> The routable domain stuff is just an adhoc redirector which must be
>> tied to a particular base irq chip implementation (i.e. GIC). With
>> stacked irq domains there is no dependency on the underlying irq
>> chip. No ifdeffery, nothing. So you can use the same router domain
>> implementation for both the A5 and the M4 side.
>>
>> On the A5 side the router domain has the gic domain as parent and on
>> the M4 side the nvic domain.
>>
>> The shared interrupts are allocated through the router domain which
>> decides whether the interrupt can be assigned to a particular core or
>> not. If it can be assigned it allocates the corresponding interrupt in
>> the parent domain, sets up the routing and everything just works.
> 
> What do you mean by the shared state in the drawing above? Currently, I
> check whether a interrupt is already used by the other core by reading
> the register (do this configuration register reflect the "shared state"
> in your drawing?).

I think that is basically it. It should only be the register that
decides on the actual routing. BTW, how do you arbitrate between
concurrent accesses to this register? Or is only the A5 allowed to
change it?

> 
>>
>> See:
>> http://git.kernel.org/cgit/linux/kernel/git/tip/tip.git/log/?h=irq/irqdomain-arm
>>
> 
> Thanks for the link. So my work would involve to support domain
> hierarchy for NVIC (proper irq_domain_ops, introduce arm,routable-irqs
> property, anything else?) and then make use of the hierarchy code in my
> MSCM driver like for instance the mtk-sysirq driver...?

I don't think we need the arm,routable-irq property at all, and I'm
looking at refactoring the crossbar thingy to remove most of its
entanglement with the GIC.

All you need to know is the range of interrupts you're allowed to
request through the "routable" domain. The inner-most irqchip shouldn't
even know about it (after all, they are just wires coming in). It should
be the duty of the outer-most irqchip (the "router") to generate the
correct request to the GIC/NVIC. So all the knowledge should be at the
router level.

The mtk-sysrq code is indeed a good example of what you can do.

> What is the state of the IRQ domain hierarchy, when will it go upstream?

Scheduled for 3.19, if everything goes according to plan. Don't think we
can go back anyway... ;-)

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 03/12] irqchip: gic: define register_routable_domain_ops conditional

[Marc Zyngier]

Hi Stefan,

On 03/12/14 17:28, Stefan Agner wrote:
> On 2014-12-03 14:04, Thomas Gleixner wrote:
>> On Wed, 3 Dec 2014, Arnd Bergmann wrote:
>>
>>> On Wednesday 03 December 2014 01:12:02 Stefan Agner wrote:
>>>> The inline function register_routable_domain_ops is only usable if
>>>> CONFIG_ARM_GIC is set. Make it depend on this configuration. This
>>>> also allows other SoC interrupt controller to provide such a
>>>> function.
>>>>
>>>> Signed-off-by: Stefan Agner <stefan@agner.ch>
>>>
>>> I don't think this is a good idea: either the interface is meant
>>> to be generic and should work with any interrupt controller, or
>>> it is specific to one irqchip and another irqchip should provide
>>> a different interface that has a nonconflicting name.
>>>
>>> I suppose you want the latter here, given that the declaration
>>> is part of the gic specific header file.
>>
>> That routable_domain stuff should have never been invented. In
>> hindsight we should have done the stacked irq domains back then
>> already, but in hindsight ...
> 
> I must admit that my first implementation even used arch_extn (through

I'm glad I didn't see that! ;-)

> the mask/unmask stuff). Then I saw the routable domain stuff, which
> looked more like a fit. But when I realized that only GIC has support
> for that, I soon realized that this might either need a proper
> framework... my hackish NVIC extension probably won't be acceptable...
> 
> Stack-able IRQ domain sounds like exactly what I was looking for...

Like Thomas said, we should have had that ages ago. It solves so many
problems in one go it's mind-boggling. On the down side, we end-up
refactoring *a lot* of the existing code...

>>
>> If you look at the crossbar scheme what we have now:
>>
>>    GIC domain
>> |--------------|
>> |              |---------- private
>> | non routable |---------- peripheral
>> |              |---------- peripheral
>> |              |
>> |--------------|
>> |              |---------- peripheral
>> |   routable   |---------- peripheral
>> |    |         |---------- peripheral
>> |--------------|
>>      |               |----------------|
>>      |-------------->| crossbar magic |
>>                      |----------------|
>>
>> which is not how the hardware looks. The hardware actually looks like
>> this:
>>
>>    GIC domain
>> |--------------|
>> |              |---------- private
>> | non routable |---------- peripheral
>> |              |---------- peripheral
>> |              |
>> |--------------|           |--------------|
>> |              |           |              |---------- peripheral
>> |   routable   |-----------| crossbar     |---------- peripheral
>> |              |           | domain       |---------- peripheral
>> |--------------|           |--------------|
>>
>> So it is completely obvious that the peripheral interrupts which need
>> to be routed through the crossbar belong to a different domain. We
>> really should convert crossbar to that scheme and get rid of the
>> routable domain stuff completely.
>>
>> With vybrid thats not different according to the diagram in the
>> reference manual.
>>
>>   GIC domain
>> |--------------|
>> |              |---------- private
>> | non routable |---------- peripheral
>> |              |---------- peripheral
>> |              |
>> |--------------|           |--------------|
>> |              |           |              |
>> |   routable   |-----------|  IRQ router  |
>> |              |           |  domain      |
>> |              |           |              |
>> |--------------|           |--------------|
>>                            | Shared state |---------- CPU to CPU 
>>   NVIC domain              | and hardware |---------- peripheral
>> |--------------|           |              |---------- peripheral
>> |              |           |--------------|
>> |              |           |              |
>> |   routable   |-----------|  IRQ router  |
>> |              |           |  domain      |
>> |              |           |              |
>> |--------------|           |--------------|
>> |              |
>> |              |---------- private
>> | non routable |---------- peripheral
>> |              |---------- peripheral
>> |--------------|
>>
>> The routable domain stuff is just an adhoc redirector which must be
>> tied to a particular base irq chip implementation (i.e. GIC). With
>> stacked irq domains there is no dependency on the underlying irq
>> chip. No ifdeffery, nothing. So you can use the same router domain
>> implementation for both the A5 and the M4 side.
>>
>> On the A5 side the router domain has the gic domain as parent and on
>> the M4 side the nvic domain.
>>
>> The shared interrupts are allocated through the router domain which
>> decides whether the interrupt can be assigned to a particular core or
>> not. If it can be assigned it allocates the corresponding interrupt in
>> the parent domain, sets up the routing and everything just works.
> 
> What do you mean by the shared state in the drawing above? Currently, I
> check whether a interrupt is already used by the other core by reading
> the register (do this configuration register reflect the "shared state"
> in your drawing?).

I think that is basically it. It should only be the register that
decides on the actual routing. BTW, how do you arbitrate between
concurrent accesses to this register? Or is only the A5 allowed to
change it?

> 
>>
>> See:
>> http://git.kernel.org/cgit/linux/kernel/git/tip/tip.git/log/?h=irq/irqdomain-arm
>>
> 
> Thanks for the link. So my work would involve to support domain
> hierarchy for NVIC (proper irq_domain_ops, introduce arm,routable-irqs
> property, anything else?) and then make use of the hierarchy code in my
> MSCM driver like for instance the mtk-sysirq driver...?

I don't think we need the arm,routable-irq property at all, and I'm
looking at refactoring the crossbar thingy to remove most of its
entanglement with the GIC.

All you need to know is the range of interrupts you're allowed to
request through the "routable" domain. The inner-most irqchip shouldn't
even know about it (after all, they are just wires coming in). It should
be the duty of the outer-most irqchip (the "router") to generate the
correct request to the GIC/NVIC. So all the knowledge should be at the
router level.

The mtk-sysrq code is indeed a good example of what you can do.

> What is the state of the IRQ domain hierarchy, when will it go upstream?

Scheduled for 3.19, if everything goes according to plan. Don't think we
can go back anyway... ;-)

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...

Re: [PATCH 03/12] irqchip: gic: define register_routable_domain_ops conditional

[Thomas Gleixner]

On Wed, 3 Dec 2014, Marc Zyngier wrote:
> On 03/12/14 17:28, Stefan Agner wrote:
> > On 2014-12-03 14:04, Thomas Gleixner wrote:
> >> The shared interrupts are allocated through the router domain which
> >> decides whether the interrupt can be assigned to a particular core or
> >> not. If it can be assigned it allocates the corresponding interrupt in
> >> the parent domain, sets up the routing and everything just works.
> > 
> > What do you mean by the shared state in the drawing above? Currently, I
> > check whether a interrupt is already used by the other core by reading
> > the register (do this configuration register reflect the "shared state"
> > in your drawing?).
> 
> I think that is basically it. It should only be the register that
> decides on the actual routing. BTW, how do you arbitrate between
> concurrent accesses to this register? Or is only the A5 allowed to
> change it?

What I meant with 'shared state' is basically the configuration
register space. Plus depending on the mechanism you want to use for
correlating the routing between the A5 and the M4 some shared memory
state, locking, IPC or whatever you need for this.
 
> >> http://git.kernel.org/cgit/linux/kernel/git/tip/tip.git/log/?h=irq/irqdomain-arm
> >>
> > 
> > Thanks for the link. So my work would involve to support domain
> > hierarchy for NVIC (proper irq_domain_ops, introduce arm,routable-irqs
> > property, anything else?) and then make use of the hierarchy code in my
> > MSCM driver like for instance the mtk-sysirq driver...?
> 
> I don't think we need the arm,routable-irq property at all, and I'm
> looking at refactoring the crossbar thingy to remove most of its
> entanglement with the GIC.
> 
> All you need to know is the range of interrupts you're allowed to
> request through the "routable" domain. The inner-most irqchip shouldn't
> even know about it (after all, they are just wires coming in). It should
> be the duty of the outer-most irqchip (the "router") to generate the
> correct request to the GIC/NVIC. So all the knowledge should be at the
> router level.
> 
> The mtk-sysrq code is indeed a good example of what you can do.

The gic-v2m MSI stuff is probably helpful as well.
 
> > What is the state of the IRQ domain hierarchy, when will it go upstream?
> 
> Scheduled for 3.19, if everything goes according to plan. Don't think we
> can go back anyway... ;-)

Indeed. That would be a major headache...

Thanks,

	tglx

Re: [PATCH 03/12] irqchip: gic: define register_routable_domain_ops conditional

[Thomas Gleixner]

On Wed, 3 Dec 2014, Marc Zyngier wrote:
> On 03/12/14 17:28, Stefan Agner wrote:
> > On 2014-12-03 14:04, Thomas Gleixner wrote:
> >> The shared interrupts are allocated through the router domain which
> >> decides whether the interrupt can be assigned to a particular core or
> >> not. If it can be assigned it allocates the corresponding interrupt in
> >> the parent domain, sets up the routing and everything just works.
> > 
> > What do you mean by the shared state in the drawing above? Currently, I
> > check whether a interrupt is already used by the other core by reading
> > the register (do this configuration register reflect the "shared state"
> > in your drawing?).
> 
> I think that is basically it. It should only be the register that
> decides on the actual routing. BTW, how do you arbitrate between
> concurrent accesses to this register? Or is only the A5 allowed to
> change it?

What I meant with 'shared state' is basically the configuration
register space. Plus depending on the mechanism you want to use for
correlating the routing between the A5 and the M4 some shared memory
state, locking, IPC or whatever you need for this.
 
> >> http://git.kernel.org/cgit/linux/kernel/git/tip/tip.git/log/?h=irq/irqdomain-arm
> >>
> > 
> > Thanks for the link. So my work would involve to support domain
> > hierarchy for NVIC (proper irq_domain_ops, introduce arm,routable-irqs
> > property, anything else?) and then make use of the hierarchy code in my
> > MSCM driver like for instance the mtk-sysirq driver...?
> 
> I don't think we need the arm,routable-irq property at all, and I'm
> looking at refactoring the crossbar thingy to remove most of its
> entanglement with the GIC.
> 
> All you need to know is the range of interrupts you're allowed to
> request through the "routable" domain. The inner-most irqchip shouldn't
> even know about it (after all, they are just wires coming in). It should
> be the duty of the outer-most irqchip (the "router") to generate the
> correct request to the GIC/NVIC. So all the knowledge should be at the
> router level.
> 
> The mtk-sysrq code is indeed a good example of what you can do.

The gic-v2m MSI stuff is probably helpful as well.
 
> > What is the state of the IRQ domain hierarchy, when will it go upstream?
> 
> Scheduled for 3.19, if everything goes according to plan. Don't think we
> can go back anyway... ;-)

Indeed. That would be a major headache...

Thanks,

	tglx

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 03/12] irqchip: gic: define register_routable_domain_ops conditional

[Thomas Gleixner]

On Wed, 3 Dec 2014, Marc Zyngier wrote:
> On 03/12/14 17:28, Stefan Agner wrote:
> > On 2014-12-03 14:04, Thomas Gleixner wrote:
> >> The shared interrupts are allocated through the router domain which
> >> decides whether the interrupt can be assigned to a particular core or
> >> not. If it can be assigned it allocates the corresponding interrupt in
> >> the parent domain, sets up the routing and everything just works.
> > 
> > What do you mean by the shared state in the drawing above? Currently, I
> > check whether a interrupt is already used by the other core by reading
> > the register (do this configuration register reflect the "shared state"
> > in your drawing?).
> 
> I think that is basically it. It should only be the register that
> decides on the actual routing. BTW, how do you arbitrate between
> concurrent accesses to this register? Or is only the A5 allowed to
> change it?

What I meant with 'shared state' is basically the configuration
register space. Plus depending on the mechanism you want to use for
correlating the routing between the A5 and the M4 some shared memory
state, locking, IPC or whatever you need for this.
 
> >> http://git.kernel.org/cgit/linux/kernel/git/tip/tip.git/log/?h=irq/irqdomain-arm
> >>
> > 
> > Thanks for the link. So my work would involve to support domain
> > hierarchy for NVIC (proper irq_domain_ops, introduce arm,routable-irqs
> > property, anything else?) and then make use of the hierarchy code in my
> > MSCM driver like for instance the mtk-sysirq driver...?
> 
> I don't think we need the arm,routable-irq property at all, and I'm
> looking at refactoring the crossbar thingy to remove most of its
> entanglement with the GIC.
> 
> All you need to know is the range of interrupts you're allowed to
> request through the "routable" domain. The inner-most irqchip shouldn't
> even know about it (after all, they are just wires coming in). It should
> be the duty of the outer-most irqchip (the "router") to generate the
> correct request to the GIC/NVIC. So all the knowledge should be at the
> router level.
> 
> The mtk-sysrq code is indeed a good example of what you can do.

The gic-v2m MSI stuff is probably helpful as well.
 
> > What is the state of the IRQ domain hierarchy, when will it go upstream?
> 
> Scheduled for 3.19, if everything goes according to plan. Don't think we
> can go back anyway... ;-)

Indeed. That would be a major headache...

Thanks,

	tglx

Re: [PATCH 03/12] irqchip: gic: define register_routable_domain_ops conditional

[Stefan Agner]

On 2014-12-03 20:04, Marc Zyngier wrote:
<snip>
>> What do you mean by the shared state in the drawing above? Currently, I
>> check whether a interrupt is already used by the other core by reading
>> the register (do this configuration register reflect the "shared state"
>> in your drawing?).
> 
> I think that is basically it. It should only be the register that
> decides on the actual routing. BTW, how do you arbitrate between
> concurrent accesses to this register? Or is only the A5 allowed to
> change it?
 
No arbitration so far... The whole Vybrid on M4 stuff is quite a hack
right now. For instance also the concurrent access to the clock
registers is not handled. Currently, I start the M4 from a booted A5
Linux. To avoid half of the clocks get turned of by the M4 clock driver,
I need to specify clk_ignore_unused. Beside that, peripherals have to be
enabled/disabled in a non conflicting manor in the device trees...

For the interrupt router in MSCM, it would be nice if the access could
be done an atomic way, which would avoid the use of a lock mechanism.
But I guess this is not possible, since peripherals only support
standard ldr/str...?

There is the SEMA4 module which provides hardware semaphores. I'm aware
of the hardware spinlock drivers (drivers/hwspinlock/), I started to
implement such a driver for Vybrid. But so far a grep through the kernel
does not show one usage of that framework... I guess we could add dt
support for that, so we can assign the locks to individual drivers.

I also plan to have a deeper look into remoteproc/rpmsg, not sure if
locking of shared peripherals is part (or planned to be part) of that
framework.

For the clock stuff, the problem is more complex: I guess the would need
some kind of master/slave definition, where we disallow the change of
the shared clocks for the slave.

If you are aware of patches/solutions, I'm happy to hear it...

--
Stefan


<snip>

Re: [PATCH 03/12] irqchip: gic: define register_routable_domain_ops conditional

[Stefan Agner]

On 2014-12-03 20:04, Marc Zyngier wrote:
<snip>
>> What do you mean by the shared state in the drawing above? Currently, I
>> check whether a interrupt is already used by the other core by reading
>> the register (do this configuration register reflect the "shared state"
>> in your drawing?).
> 
> I think that is basically it. It should only be the register that
> decides on the actual routing. BTW, how do you arbitrate between
> concurrent accesses to this register? Or is only the A5 allowed to
> change it?
 
No arbitration so far... The whole Vybrid on M4 stuff is quite a hack
right now. For instance also the concurrent access to the clock
registers is not handled. Currently, I start the M4 from a booted A5
Linux. To avoid half of the clocks get turned of by the M4 clock driver,
I need to specify clk_ignore_unused. Beside that, peripherals have to be
enabled/disabled in a non conflicting manor in the device trees...

For the interrupt router in MSCM, it would be nice if the access could
be done an atomic way, which would avoid the use of a lock mechanism.
But I guess this is not possible, since peripherals only support
standard ldr/str...?

There is the SEMA4 module which provides hardware semaphores. I'm aware
of the hardware spinlock drivers (drivers/hwspinlock/), I started to
implement such a driver for Vybrid. But so far a grep through the kernel
does not show one usage of that framework... I guess we could add dt
support for that, so we can assign the locks to individual drivers.

I also plan to have a deeper look into remoteproc/rpmsg, not sure if
locking of shared peripherals is part (or planned to be part) of that
framework.

For the clock stuff, the problem is more complex: I guess the would need
some kind of master/slave definition, where we disallow the change of
the shared clocks for the slave.

If you are aware of patches/solutions, I'm happy to hear it...

--
Stefan


<snip>

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 03/12] irqchip: gic: define register_routable_domain_ops conditional

[Stefan Agner]

On 2014-12-03 20:04, Marc Zyngier wrote:
<snip>
>> What do you mean by the shared state in the drawing above? Currently, I
>> check whether a interrupt is already used by the other core by reading
>> the register (do this configuration register reflect the "shared state"
>> in your drawing?).
> 
> I think that is basically it. It should only be the register that
> decides on the actual routing. BTW, how do you arbitrate between
> concurrent accesses to this register? Or is only the A5 allowed to
> change it?
 
No arbitration so far... The whole Vybrid on M4 stuff is quite a hack
right now. For instance also the concurrent access to the clock
registers is not handled. Currently, I start the M4 from a booted A5
Linux. To avoid half of the clocks get turned of by the M4 clock driver,
I need to specify clk_ignore_unused. Beside that, peripherals have to be
enabled/disabled in a non conflicting manor in the device trees...

For the interrupt router in MSCM, it would be nice if the access could
be done an atomic way, which would avoid the use of a lock mechanism.
But I guess this is not possible, since peripherals only support
standard ldr/str...?

There is the SEMA4 module which provides hardware semaphores. I'm aware
of the hardware spinlock drivers (drivers/hwspinlock/), I started to
implement such a driver for Vybrid. But so far a grep through the kernel
does not show one usage of that framework... I guess we could add dt
support for that, so we can assign the locks to individual drivers.

I also plan to have a deeper look into remoteproc/rpmsg, not sure if
locking of shared peripherals is part (or planned to be part) of that
framework.

For the clock stuff, the problem is more complex: I guess the would need
some kind of master/slave definition, where we disallow the change of
the shared clocks for the slave.

If you are aware of patches/solutions, I'm happy to hear it...

--
Stefan


<snip>

Re: [PATCH 03/12] irqchip: gic: define register_routable_domain_ops conditional

[Marc Zyngier]

On 04/12/14 13:35, Stefan Agner wrote:
> On 2014-12-03 20:04, Marc Zyngier wrote:
> <snip>
>>> What do you mean by the shared state in the drawing above? Currently, I
>>> check whether a interrupt is already used by the other core by reading
>>> the register (do this configuration register reflect the "shared state"
>>> in your drawing?).
>>
>> I think that is basically it. It should only be the register that
>> decides on the actual routing. BTW, how do you arbitrate between
>> concurrent accesses to this register? Or is only the A5 allowed to
>> change it?
>  
> No arbitration so far... The whole Vybrid on M4 stuff is quite a hack
> right now. For instance also the concurrent access to the clock
> registers is not handled. Currently, I start the M4 from a booted A5
> Linux. To avoid half of the clocks get turned of by the M4 clock driver,
> I need to specify clk_ignore_unused. Beside that, peripherals have to be
> enabled/disabled in a non conflicting manor in the device trees...
> 
> For the interrupt router in MSCM, it would be nice if the access could
> be done an atomic way, which would avoid the use of a lock mechanism.
> But I guess this is not possible, since peripherals only support
> standard ldr/str...?
> 
> There is the SEMA4 module which provides hardware semaphores. I'm aware
> of the hardware spinlock drivers (drivers/hwspinlock/), I started to
> implement such a driver for Vybrid. But so far a grep through the kernel
> does not show one usage of that framework... I guess we could add dt
> support for that, so we can assign the locks to individual drivers.
> 
> I also plan to have a deeper look into remoteproc/rpmsg, not sure if
> locking of shared peripherals is part (or planned to be part) of that
> framework.
> 
> For the clock stuff, the problem is more complex: I guess the would need
> some kind of master/slave definition, where we disallow the change of
> the shared clocks for the slave.
> 
> If you are aware of patches/solutions, I'm happy to hear it...

I don't have a real solution for this, but I'd be tempted to generate
the M4 DT based on the HW the A5 is not using, and only describe that.

Clearly not ideal, but it gives you the control you need (don't describe
the HW you don't want to see touched)...

	M.
-- 
Jazz is not dead. It just smells funny...

Re: [PATCH 03/12] irqchip: gic: define register_routable_domain_ops conditional

[Marc Zyngier]

On 04/12/14 13:35, Stefan Agner wrote:
> On 2014-12-03 20:04, Marc Zyngier wrote:
> <snip>
>>> What do you mean by the shared state in the drawing above? Currently, I
>>> check whether a interrupt is already used by the other core by reading
>>> the register (do this configuration register reflect the "shared state"
>>> in your drawing?).
>>
>> I think that is basically it. It should only be the register that
>> decides on the actual routing. BTW, how do you arbitrate between
>> concurrent accesses to this register? Or is only the A5 allowed to
>> change it?
>  
> No arbitration so far... The whole Vybrid on M4 stuff is quite a hack
> right now. For instance also the concurrent access to the clock
> registers is not handled. Currently, I start the M4 from a booted A5
> Linux. To avoid half of the clocks get turned of by the M4 clock driver,
> I need to specify clk_ignore_unused. Beside that, peripherals have to be
> enabled/disabled in a non conflicting manor in the device trees...
> 
> For the interrupt router in MSCM, it would be nice if the access could
> be done an atomic way, which would avoid the use of a lock mechanism.
> But I guess this is not possible, since peripherals only support
> standard ldr/str...?
> 
> There is the SEMA4 module which provides hardware semaphores. I'm aware
> of the hardware spinlock drivers (drivers/hwspinlock/), I started to
> implement such a driver for Vybrid. But so far a grep through the kernel
> does not show one usage of that framework... I guess we could add dt
> support for that, so we can assign the locks to individual drivers.
> 
> I also plan to have a deeper look into remoteproc/rpmsg, not sure if
> locking of shared peripherals is part (or planned to be part) of that
> framework.
> 
> For the clock stuff, the problem is more complex: I guess the would need
> some kind of master/slave definition, where we disallow the change of
> the shared clocks for the slave.
> 
> If you are aware of patches/solutions, I'm happy to hear it...

I don't have a real solution for this, but I'd be tempted to generate
the M4 DT based on the HW the A5 is not using, and only describe that.

Clearly not ideal, but it gives you the control you need (don't describe
the HW you don't want to see touched)...

	M.
-- 
Jazz is not dead. It just smells funny...
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 03/12] irqchip: gic: define register_routable_domain_ops conditional

[Marc Zyngier]

On 04/12/14 13:35, Stefan Agner wrote:
> On 2014-12-03 20:04, Marc Zyngier wrote:
> <snip>
>>> What do you mean by the shared state in the drawing above? Currently, I
>>> check whether a interrupt is already used by the other core by reading
>>> the register (do this configuration register reflect the "shared state"
>>> in your drawing?).
>>
>> I think that is basically it. It should only be the register that
>> decides on the actual routing. BTW, how do you arbitrate between
>> concurrent accesses to this register? Or is only the A5 allowed to
>> change it?
>  
> No arbitration so far... The whole Vybrid on M4 stuff is quite a hack
> right now. For instance also the concurrent access to the clock
> registers is not handled. Currently, I start the M4 from a booted A5
> Linux. To avoid half of the clocks get turned of by the M4 clock driver,
> I need to specify clk_ignore_unused. Beside that, peripherals have to be
> enabled/disabled in a non conflicting manor in the device trees...
> 
> For the interrupt router in MSCM, it would be nice if the access could
> be done an atomic way, which would avoid the use of a lock mechanism.
> But I guess this is not possible, since peripherals only support
> standard ldr/str...?
> 
> There is the SEMA4 module which provides hardware semaphores. I'm aware
> of the hardware spinlock drivers (drivers/hwspinlock/), I started to
> implement such a driver for Vybrid. But so far a grep through the kernel
> does not show one usage of that framework... I guess we could add dt
> support for that, so we can assign the locks to individual drivers.
> 
> I also plan to have a deeper look into remoteproc/rpmsg, not sure if
> locking of shared peripherals is part (or planned to be part) of that
> framework.
> 
> For the clock stuff, the problem is more complex: I guess the would need
> some kind of master/slave definition, where we disallow the change of
> the shared clocks for the slave.
> 
> If you are aware of patches/solutions, I'm happy to hear it...

I don't have a real solution for this, but I'd be tempted to generate
the M4 DT based on the HW the A5 is not using, and only describe that.

Clearly not ideal, but it gives you the control you need (don't describe
the HW you don't want to see touched)...

	M.
-- 
Jazz is not dead. It just smells funny...

Re: [PATCH 03/12] irqchip: gic: define register_routable_domain_ops conditional

[Stefan Agner]

On 2014-12-04 14:42, Marc Zyngier wrote:
> On 04/12/14 13:35, Stefan Agner wrote:
>> On 2014-12-03 20:04, Marc Zyngier wrote:
>> <snip>
>>>> What do you mean by the shared state in the drawing above? Currently, I
>>>> check whether a interrupt is already used by the other core by reading
>>>> the register (do this configuration register reflect the "shared state"
>>>> in your drawing?).
>>>
>>> I think that is basically it. It should only be the register that
>>> decides on the actual routing. BTW, how do you arbitrate between
>>> concurrent accesses to this register? Or is only the A5 allowed to
>>> change it?
>>
>> No arbitration so far... The whole Vybrid on M4 stuff is quite a hack
>> right now. For instance also the concurrent access to the clock
>> registers is not handled. Currently, I start the M4 from a booted A5
>> Linux. To avoid half of the clocks get turned of by the M4 clock driver,
>> I need to specify clk_ignore_unused. Beside that, peripherals have to be
>> enabled/disabled in a non conflicting manor in the device trees...
>>
>> For the interrupt router in MSCM, it would be nice if the access could
>> be done an atomic way, which would avoid the use of a lock mechanism.
>> But I guess this is not possible, since peripherals only support
>> standard ldr/str...?
>>
>> There is the SEMA4 module which provides hardware semaphores. I'm aware
>> of the hardware spinlock drivers (drivers/hwspinlock/), I started to
>> implement such a driver for Vybrid. But so far a grep through the kernel
>> does not show one usage of that framework... I guess we could add dt
>> support for that, so we can assign the locks to individual drivers.
>>
>> I also plan to have a deeper look into remoteproc/rpmsg, not sure if
>> locking of shared peripherals is part (or planned to be part) of that
>> framework.
>>
>> For the clock stuff, the problem is more complex: I guess the would need
>> some kind of master/slave definition, where we disallow the change of
>> the shared clocks for the slave.
>>
>> If you are aware of patches/solutions, I'm happy to hear it...
> 
> I don't have a real solution for this, but I'd be tempted to generate
> the M4 DT based on the HW the A5 is not using, and only describe that.
> 
> Clearly not ideal, but it gives you the control you need (don't describe
> the HW you don't want to see touched)...
> 

Yeah, that avoids the need for any synchronization for those
peripherals.

However, for some hardware (e.g. clocks and that interrupt controller)
both sides need access... I guess to do it properly, I need to take care
of it...

--
Stefan

Re: [PATCH 03/12] irqchip: gic: define register_routable_domain_ops conditional

[Stefan Agner]

On 2014-12-04 14:42, Marc Zyngier wrote:
> On 04/12/14 13:35, Stefan Agner wrote:
>> On 2014-12-03 20:04, Marc Zyngier wrote:
>> <snip>
>>>> What do you mean by the shared state in the drawing above? Currently, I
>>>> check whether a interrupt is already used by the other core by reading
>>>> the register (do this configuration register reflect the "shared state"
>>>> in your drawing?).
>>>
>>> I think that is basically it. It should only be the register that
>>> decides on the actual routing. BTW, how do you arbitrate between
>>> concurrent accesses to this register? Or is only the A5 allowed to
>>> change it?
>>
>> No arbitration so far... The whole Vybrid on M4 stuff is quite a hack
>> right now. For instance also the concurrent access to the clock
>> registers is not handled. Currently, I start the M4 from a booted A5
>> Linux. To avoid half of the clocks get turned of by the M4 clock driver,
>> I need to specify clk_ignore_unused. Beside that, peripherals have to be
>> enabled/disabled in a non conflicting manor in the device trees...
>>
>> For the interrupt router in MSCM, it would be nice if the access could
>> be done an atomic way, which would avoid the use of a lock mechanism.
>> But I guess this is not possible, since peripherals only support
>> standard ldr/str...?
>>
>> There is the SEMA4 module which provides hardware semaphores. I'm aware
>> of the hardware spinlock drivers (drivers/hwspinlock/), I started to
>> implement such a driver for Vybrid. But so far a grep through the kernel
>> does not show one usage of that framework... I guess we could add dt
>> support for that, so we can assign the locks to individual drivers.
>>
>> I also plan to have a deeper look into remoteproc/rpmsg, not sure if
>> locking of shared peripherals is part (or planned to be part) of that
>> framework.
>>
>> For the clock stuff, the problem is more complex: I guess the would need
>> some kind of master/slave definition, where we disallow the change of
>> the shared clocks for the slave.
>>
>> If you are aware of patches/solutions, I'm happy to hear it...
> 
> I don't have a real solution for this, but I'd be tempted to generate
> the M4 DT based on the HW the A5 is not using, and only describe that.
> 
> Clearly not ideal, but it gives you the control you need (don't describe
> the HW you don't want to see touched)...
> 

Yeah, that avoids the need for any synchronization for those
peripherals.

However, for some hardware (e.g. clocks and that interrupt controller)
both sides need access... I guess to do it properly, I need to take care
of it...

--
Stefan

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 03/12] irqchip: gic: define register_routable_domain_ops conditional

[Stefan Agner]

On 2014-12-04 14:42, Marc Zyngier wrote:
> On 04/12/14 13:35, Stefan Agner wrote:
>> On 2014-12-03 20:04, Marc Zyngier wrote:
>> <snip>
>>>> What do you mean by the shared state in the drawing above? Currently, I
>>>> check whether a interrupt is already used by the other core by reading
>>>> the register (do this configuration register reflect the "shared state"
>>>> in your drawing?).
>>>
>>> I think that is basically it. It should only be the register that
>>> decides on the actual routing. BTW, how do you arbitrate between
>>> concurrent accesses to this register? Or is only the A5 allowed to
>>> change it?
>>
>> No arbitration so far... The whole Vybrid on M4 stuff is quite a hack
>> right now. For instance also the concurrent access to the clock
>> registers is not handled. Currently, I start the M4 from a booted A5
>> Linux. To avoid half of the clocks get turned of by the M4 clock driver,
>> I need to specify clk_ignore_unused. Beside that, peripherals have to be
>> enabled/disabled in a non conflicting manor in the device trees...
>>
>> For the interrupt router in MSCM, it would be nice if the access could
>> be done an atomic way, which would avoid the use of a lock mechanism.
>> But I guess this is not possible, since peripherals only support
>> standard ldr/str...?
>>
>> There is the SEMA4 module which provides hardware semaphores. I'm aware
>> of the hardware spinlock drivers (drivers/hwspinlock/), I started to
>> implement such a driver for Vybrid. But so far a grep through the kernel
>> does not show one usage of that framework... I guess we could add dt
>> support for that, so we can assign the locks to individual drivers.
>>
>> I also plan to have a deeper look into remoteproc/rpmsg, not sure if
>> locking of shared peripherals is part (or planned to be part) of that
>> framework.
>>
>> For the clock stuff, the problem is more complex: I guess the would need
>> some kind of master/slave definition, where we disallow the change of
>> the shared clocks for the slave.
>>
>> If you are aware of patches/solutions, I'm happy to hear it...
> 
> I don't have a real solution for this, but I'd be tempted to generate
> the M4 DT based on the HW the A5 is not using, and only describe that.
> 
> Clearly not ideal, but it gives you the control you need (don't describe
> the HW you don't want to see touched)...
> 

Yeah, that avoids the need for any synchronization for those
peripherals.

However, for some hardware (e.g. clocks and that interrupt controller)
both sides need access... I guess to do it properly, I need to take care
of it...

--
Stefan

Re: [PATCH 11/12] ARM: dts: add support for Vybrid running on Cortex-M4

[Stefan Agner]

On 2014-12-03 12:03, Arnd Bergmann wrote:
> On Wednesday 03 December 2014 01:12:10 Stefan Agner wrote:
>> diff --git a/arch/arm/boot/dts/vf610m4-colibri.dts b/arch/arm/boot/dts/vf610m4-colibri.dts
>> new file mode 100644
>> index 0000000..051ee0f
>> --- /dev/null
>> +++ b/arch/arm/boot/dts/vf610m4-colibri.dts
>> @@ -0,0 +1,52 @@
>> +/*
>> + * Device tree for Colibri VF61 Cortex-M4 support
>> + *
>> + * Copyright 2014 Stefan Agner
>> + *
>> + * 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.
>> + */
>> +
>> +/dts-v1/;
>> +#include "vf610m4.dtsi"
>> +
>> +/ {
>> +       model = "VF610 Cortex-M4";
>> +       compatible = "fsl,vf610m4";
>> +
>> +       chosen {
>> +               bootargs = "console=ttyLP2,115200 ihash_entries=64 dhash_entries=64 earlyprintk clk_ignore_unused init=/linuxrc rw";
>> +       };
>> +
> 
> Starting with v3.19, you should be able to use the earlycon framework on
> arm32, so it would be better to replace earlyprintk with earlycon here
> and add a stdout-path property in chosen that points to the console
> uart.

Hi Arnd,

Just started looking in that a bit deeper and some question arose:
Afaik, earlycon need to be supported by the uart driver. The fsl_lpuart,
which is used for Vybrid's uart, does not support earlycon yet. However,
earlyprink already works (see ./arch/arm/include/debug/vf.S). I
understand that earlycon has the advantage of being able to be used on
multiplatform. But earlyprintk is working really early (e.g. before
locating the FDT), and it proved helpful for me when I started working
on that Cortex-M4 stuff. Should earlycon replace earlyprintk completely?

Maybe, on Vybrid, since it would be a good platform for automated !MMU
testing, it would be nice to have earlycon which can be enabled in any
case and would provide output even something blows up quite early... But
I guess I would add earlycon support as part of a new patchset and just
drop earlyprintk here for now.

> 64 hash table entries sounds extremely small, doesn't that impact
> performance? If you have 50MB of actual RAM available, I don't think
> you need that.

Agreed. I copied that from EFM32 which is under much more memory
pressure...

--
Stefan

Re: [PATCH 11/12] ARM: dts: add support for Vybrid running on Cortex-M4

[Stefan Agner]

On 2014-12-03 12:03, Arnd Bergmann wrote:
> On Wednesday 03 December 2014 01:12:10 Stefan Agner wrote:
>> diff --git a/arch/arm/boot/dts/vf610m4-colibri.dts b/arch/arm/boot/dts/vf610m4-colibri.dts
>> new file mode 100644
>> index 0000000..051ee0f
>> --- /dev/null
>> +++ b/arch/arm/boot/dts/vf610m4-colibri.dts
>> @@ -0,0 +1,52 @@
>> +/*
>> + * Device tree for Colibri VF61 Cortex-M4 support
>> + *
>> + * Copyright 2014 Stefan Agner
>> + *
>> + * 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.
>> + */
>> +
>> +/dts-v1/;
>> +#include "vf610m4.dtsi"
>> +
>> +/ {
>> +       model = "VF610 Cortex-M4";
>> +       compatible = "fsl,vf610m4";
>> +
>> +       chosen {
>> +               bootargs = "console=ttyLP2,115200 ihash_entries=64 dhash_entries=64 earlyprintk clk_ignore_unused init=/linuxrc rw";
>> +       };
>> +
> 
> Starting with v3.19, you should be able to use the earlycon framework on
> arm32, so it would be better to replace earlyprintk with earlycon here
> and add a stdout-path property in chosen that points to the console
> uart.

Hi Arnd,

Just started looking in that a bit deeper and some question arose:
Afaik, earlycon need to be supported by the uart driver. The fsl_lpuart,
which is used for Vybrid's uart, does not support earlycon yet. However,
earlyprink already works (see ./arch/arm/include/debug/vf.S). I
understand that earlycon has the advantage of being able to be used on
multiplatform. But earlyprintk is working really early (e.g. before
locating the FDT), and it proved helpful for me when I started working
on that Cortex-M4 stuff. Should earlycon replace earlyprintk completely?

Maybe, on Vybrid, since it would be a good platform for automated !MMU
testing, it would be nice to have earlycon which can be enabled in any
case and would provide output even something blows up quite early... But
I guess I would add earlycon support as part of a new patchset and just
drop earlyprintk here for now.

> 64 hash table entries sounds extremely small, doesn't that impact
> performance? If you have 50MB of actual RAM available, I don't think
> you need that.

Agreed. I copied that from EFM32 which is under much more memory
pressure...

--
Stefan

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 11/12] ARM: dts: add support for Vybrid running on Cortex-M4

[Stefan Agner]

On 2014-12-03 12:03, Arnd Bergmann wrote:
> On Wednesday 03 December 2014 01:12:10 Stefan Agner wrote:
>> diff --git a/arch/arm/boot/dts/vf610m4-colibri.dts b/arch/arm/boot/dts/vf610m4-colibri.dts
>> new file mode 100644
>> index 0000000..051ee0f
>> --- /dev/null
>> +++ b/arch/arm/boot/dts/vf610m4-colibri.dts
>> @@ -0,0 +1,52 @@
>> +/*
>> + * Device tree for Colibri VF61 Cortex-M4 support
>> + *
>> + * Copyright 2014 Stefan Agner
>> + *
>> + * 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.
>> + */
>> +
>> +/dts-v1/;
>> +#include "vf610m4.dtsi"
>> +
>> +/ {
>> +       model = "VF610 Cortex-M4";
>> +       compatible = "fsl,vf610m4";
>> +
>> +       chosen {
>> +               bootargs = "console=ttyLP2,115200 ihash_entries=64 dhash_entries=64 earlyprintk clk_ignore_unused init=/linuxrc rw";
>> +       };
>> +
> 
> Starting with v3.19, you should be able to use the earlycon framework on
> arm32, so it would be better to replace earlyprintk with earlycon here
> and add a stdout-path property in chosen that points to the console
> uart.

Hi Arnd,

Just started looking in that a bit deeper and some question arose:
Afaik, earlycon need to be supported by the uart driver. The fsl_lpuart,
which is used for Vybrid's uart, does not support earlycon yet. However,
earlyprink already works (see ./arch/arm/include/debug/vf.S). I
understand that earlycon has the advantage of being able to be used on
multiplatform. But earlyprintk is working really early (e.g. before
locating the FDT), and it proved helpful for me when I started working
on that Cortex-M4 stuff. Should earlycon replace earlyprintk completely?

Maybe, on Vybrid, since it would be a good platform for automated !MMU
testing, it would be nice to have earlycon which can be enabled in any
case and would provide output even something blows up quite early... But
I guess I would add earlycon support as part of a new patchset and just
drop earlyprintk here for now.

> 64 hash table entries sounds extremely small, doesn't that impact
> performance? If you have 50MB of actual RAM available, I don't think
> you need that.

Agreed. I copied that from EFM32 which is under much more memory
pressure...

--
Stefan

Re: [PATCH 11/12] ARM: dts: add support for Vybrid running on Cortex-M4

[Stefan Agner]

On 2014-12-03 12:03, Arnd Bergmann wrote:
> On Wednesday 03 December 2014 01:12:10 Stefan Agner wrote:
>> diff --git a/arch/arm/boot/dts/vf610m4-colibri.dts b/arch/arm/boot/dts/vf610m4-colibri.dts
>> new file mode 100644
>> index 0000000..051ee0f
>> --- /dev/null
>> +++ b/arch/arm/boot/dts/vf610m4-colibri.dts
>> @@ -0,0 +1,52 @@
>> +/*
>> + * Device tree for Colibri VF61 Cortex-M4 support
>> + *
>> + * Copyright 2014 Stefan Agner
>> + *
>> + * 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.
>> + */
>> +
>> +/dts-v1/;
>> +#include "vf610m4.dtsi"
>> +
>> +/ {
>> +       model = "VF610 Cortex-M4";
>> +       compatible = "fsl,vf610m4";
>> +
>> +       chosen {
>> +               bootargs = "console=ttyLP2,115200 ihash_entries=64 dhash_entries=64 earlyprintk clk_ignore_unused init=/linuxrc rw";
>> +       };
>> +
> 
> Starting with v3.19, you should be able to use the earlycon framework on
> arm32, so it would be better to replace earlyprintk with earlycon here
> and add a stdout-path property in chosen that points to the console
> uart.

I started to implement earlycon support, but something currently fails
when earlycon tries to map the UART registers:
[    0.000000] earlycon_map: Couldn't map 0x40027000

I traced the issue a bit further down and found that get_vm_area_caller
returns NULL (in __arm_ioremap_pfn_caller). This happend on Linus master
as of today (2dbfca5a181973558277b28b1f4c36362291f5e0). Do I miss
something here?

> 
> 64 hash table entries sounds extremely small, doesn't that impact
> performance? If you have 50MB of actual RAM available, I don't think
> you need that.
> 
> 	Arnd

[PATCH 11/12] ARM: dts: add support for Vybrid running on Cortex-M4

[Stefan Agner]

On 2014-12-03 12:03, Arnd Bergmann wrote:
> On Wednesday 03 December 2014 01:12:10 Stefan Agner wrote:
>> diff --git a/arch/arm/boot/dts/vf610m4-colibri.dts b/arch/arm/boot/dts/vf610m4-colibri.dts
>> new file mode 100644
>> index 0000000..051ee0f
>> --- /dev/null
>> +++ b/arch/arm/boot/dts/vf610m4-colibri.dts
>> @@ -0,0 +1,52 @@
>> +/*
>> + * Device tree for Colibri VF61 Cortex-M4 support
>> + *
>> + * Copyright 2014 Stefan Agner
>> + *
>> + * 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.
>> + */
>> +
>> +/dts-v1/;
>> +#include "vf610m4.dtsi"
>> +
>> +/ {
>> +       model = "VF610 Cortex-M4";
>> +       compatible = "fsl,vf610m4";
>> +
>> +       chosen {
>> +               bootargs = "console=ttyLP2,115200 ihash_entries=64 dhash_entries=64 earlyprintk clk_ignore_unused init=/linuxrc rw";
>> +       };
>> +
> 
> Starting with v3.19, you should be able to use the earlycon framework on
> arm32, so it would be better to replace earlyprintk with earlycon here
> and add a stdout-path property in chosen that points to the console
> uart.

I started to implement earlycon support, but something currently fails
when earlycon tries to map the UART registers:
[    0.000000] earlycon_map: Couldn't map 0x40027000

I traced the issue a bit further down and found that get_vm_area_caller
returns NULL (in __arm_ioremap_pfn_caller). This happend on Linus master
as of today (2dbfca5a181973558277b28b1f4c36362291f5e0). Do I miss
something here?

> 
> 64 hash table entries sounds extremely small, doesn't that impact
> performance? If you have 50MB of actual RAM available, I don't think
> you need that.
> 
> 	Arnd

Re: [PATCH 11/12] ARM: dts: add support for Vybrid running on Cortex-M4

[Arnd Bergmann]

On Tuesday 16 December 2014 23:19:08 Stefan Agner wrote:
> On 2014-12-03 12:03, Arnd Bergmann wrote:
> > On Wednesday 03 December 2014 01:12:10 Stefan Agner wrote:

> Just started looking in that a bit deeper and some question arose:
> Afaik, earlycon need to be supported by the uart driver. The fsl_lpuart,
> which is used for Vybrid's uart, does not support earlycon yet. However,
> earlyprink already works (see ./arch/arm/include/debug/vf.S). I
> understand that earlycon has the advantage of being able to be used on
> multiplatform. But earlyprintk is working really early (e.g. before
> locating the FDT), and it proved helpful for me when I started working
> on that Cortex-M4 stuff. Should earlycon replace earlyprintk completely?

earlyprintk will stay around for debugging early boot problems, but
with working earlycon support, there should no longer be a reason to
enable it by default.

> Maybe, on Vybrid, since it would be a good platform for automated !MMU
> testing, it would be nice to have earlycon which can be enabled in any
> case and would provide output even something blows up quite early... But
> I guess I would add earlycon support as part of a new patchset and just
> drop earlyprintk here for now.

Yes, I think that would be good.

> > 64 hash table entries sounds extremely small, doesn't that impact
> > performance? If you have 50MB of actual RAM available, I don't think
> > you need that.
> 
> Agreed. I copied that from EFM32 which is under much more memory
> pressure...

Ok.
	
	Arnd

Re: [PATCH 11/12] ARM: dts: add support for Vybrid running on Cortex-M4

[Arnd Bergmann]

On Tuesday 16 December 2014 23:19:08 Stefan Agner wrote:
> On 2014-12-03 12:03, Arnd Bergmann wrote:
> > On Wednesday 03 December 2014 01:12:10 Stefan Agner wrote:

> Just started looking in that a bit deeper and some question arose:
> Afaik, earlycon need to be supported by the uart driver. The fsl_lpuart,
> which is used for Vybrid's uart, does not support earlycon yet. However,
> earlyprink already works (see ./arch/arm/include/debug/vf.S). I
> understand that earlycon has the advantage of being able to be used on
> multiplatform. But earlyprintk is working really early (e.g. before
> locating the FDT), and it proved helpful for me when I started working
> on that Cortex-M4 stuff. Should earlycon replace earlyprintk completely?

earlyprintk will stay around for debugging early boot problems, but
with working earlycon support, there should no longer be a reason to
enable it by default.

> Maybe, on Vybrid, since it would be a good platform for automated !MMU
> testing, it would be nice to have earlycon which can be enabled in any
> case and would provide output even something blows up quite early... But
> I guess I would add earlycon support as part of a new patchset and just
> drop earlyprintk here for now.

Yes, I think that would be good.

> > 64 hash table entries sounds extremely small, doesn't that impact
> > performance? If you have 50MB of actual RAM available, I don't think
> > you need that.
> 
> Agreed. I copied that from EFM32 which is under much more memory
> pressure...

Ok.
	
	Arnd

[PATCH 11/12] ARM: dts: add support for Vybrid running on Cortex-M4

[Arnd Bergmann]

On Tuesday 16 December 2014 23:19:08 Stefan Agner wrote:
> On 2014-12-03 12:03, Arnd Bergmann wrote:
> > On Wednesday 03 December 2014 01:12:10 Stefan Agner wrote:

> Just started looking in that a bit deeper and some question arose:
> Afaik, earlycon need to be supported by the uart driver. The fsl_lpuart,
> which is used for Vybrid's uart, does not support earlycon yet. However,
> earlyprink already works (see ./arch/arm/include/debug/vf.S). I
> understand that earlycon has the advantage of being able to be used on
> multiplatform. But earlyprintk is working really early (e.g. before
> locating the FDT), and it proved helpful for me when I started working
> on that Cortex-M4 stuff. Should earlycon replace earlyprintk completely?

earlyprintk will stay around for debugging early boot problems, but
with working earlycon support, there should no longer be a reason to
enable it by default.

> Maybe, on Vybrid, since it would be a good platform for automated !MMU
> testing, it would be nice to have earlycon which can be enabled in any
> case and would provide output even something blows up quite early... But
> I guess I would add earlycon support as part of a new patchset and just
> drop earlyprintk here for now.

Yes, I think that would be good.

> > 64 hash table entries sounds extremely small, doesn't that impact
> > performance? If you have 50MB of actual RAM available, I don't think
> > you need that.
> 
> Agreed. I copied that from EFM32 which is under much more memory
> pressure...

Ok.
	
	Arnd

Re: [PATCH 11/12] ARM: dts: add support for Vybrid running on Cortex-M4

[Arnd Bergmann]

On Wednesday 17 December 2014 00:41:33 Stefan Agner wrote:
> On 2014-12-03 12:03, Arnd Bergmann wrote:
> > On Wednesday 03 December 2014 01:12:10 Stefan Agner wrote:
> >> diff --git a/arch/arm/boot/dts/vf610m4-colibri.dts b/arch/arm/boot/dts/vf610m4-colibri.dts
> >> new file mode 100644
> >> index 0000000..051ee0f
> >> --- /dev/null
> >> +++ b/arch/arm/boot/dts/vf610m4-colibri.dts
> >> @@ -0,0 +1,52 @@
> >> +/*
> >> + * Device tree for Colibri VF61 Cortex-M4 support
> >> + *
> >> + * Copyright 2014 Stefan Agner
> >> + *
> >> + * 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.
> >> + */
> >> +
> >> +/dts-v1/;
> >> +#include "vf610m4.dtsi"
> >> +
> >> +/ {
> >> +       model = "VF610 Cortex-M4";
> >> +       compatible = "fsl,vf610m4";
> >> +
> >> +       chosen {
> >> +               bootargs = "console=ttyLP2,115200 ihash_entries=64 dhash_entries=64 earlyprintk clk_ignore_unused init=/linuxrc rw";
> >> +       };
> >> +
> > 
> > Starting with v3.19, you should be able to use the earlycon framework on
> > arm32, so it would be better to replace earlyprintk with earlycon here
> > and add a stdout-path property in chosen that points to the console
> > uart.
> 
> I started to implement earlycon support, but something currently fails
> when earlycon tries to map the UART registers:
> [    0.000000] earlycon_map: Couldn't map 0x40027000
> 
> I traced the issue a bit further down and found that get_vm_area_caller
> returns NULL (in __arm_ioremap_pfn_caller). This happend on Linus master
> as of today (2dbfca5a181973558277b28b1f4c36362291f5e0). Do I miss
> something here?

Hmm, I fear the arm32 FIX_EARLYCON_MEM support ended up not making it
into 3.19 after all. :(

Rob, is this something you are still working on?

	Arnd

[PATCH 11/12] ARM: dts: add support for Vybrid running on Cortex-M4

[Arnd Bergmann]

On Wednesday 17 December 2014 00:41:33 Stefan Agner wrote:
> On 2014-12-03 12:03, Arnd Bergmann wrote:
> > On Wednesday 03 December 2014 01:12:10 Stefan Agner wrote:
> >> diff --git a/arch/arm/boot/dts/vf610m4-colibri.dts b/arch/arm/boot/dts/vf610m4-colibri.dts
> >> new file mode 100644
> >> index 0000000..051ee0f
> >> --- /dev/null
> >> +++ b/arch/arm/boot/dts/vf610m4-colibri.dts
> >> @@ -0,0 +1,52 @@
> >> +/*
> >> + * Device tree for Colibri VF61 Cortex-M4 support
> >> + *
> >> + * Copyright 2014 Stefan Agner
> >> + *
> >> + * 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.
> >> + */
> >> +
> >> +/dts-v1/;
> >> +#include "vf610m4.dtsi"
> >> +
> >> +/ {
> >> +       model = "VF610 Cortex-M4";
> >> +       compatible = "fsl,vf610m4";
> >> +
> >> +       chosen {
> >> +               bootargs = "console=ttyLP2,115200 ihash_entries=64 dhash_entries=64 earlyprintk clk_ignore_unused init=/linuxrc rw";
> >> +       };
> >> +
> > 
> > Starting with v3.19, you should be able to use the earlycon framework on
> > arm32, so it would be better to replace earlyprintk with earlycon here
> > and add a stdout-path property in chosen that points to the console
> > uart.
> 
> I started to implement earlycon support, but something currently fails
> when earlycon tries to map the UART registers:
> [    0.000000] earlycon_map: Couldn't map 0x40027000
> 
> I traced the issue a bit further down and found that get_vm_area_caller
> returns NULL (in __arm_ioremap_pfn_caller). This happend on Linus master
> as of today (2dbfca5a181973558277b28b1f4c36362291f5e0). Do I miss
> something here?

Hmm, I fear the arm32 FIX_EARLYCON_MEM support ended up not making it
into 3.19 after all. :(

Rob, is this something you are still working on?

	Arnd

Re: [PATCH 11/12] ARM: dts: add support for Vybrid running on Cortex-M4

[Stefan Agner]

On 2014-12-17 13:31, Arnd Bergmann wrote:
> On Wednesday 17 December 2014 00:41:33 Stefan Agner wrote:
>> On 2014-12-03 12:03, Arnd Bergmann wrote:
>> > On Wednesday 03 December 2014 01:12:10 Stefan Agner wrote:
>> >> diff --git a/arch/arm/boot/dts/vf610m4-colibri.dts b/arch/arm/boot/dts/vf610m4-colibri.dts
>> >> new file mode 100644
>> >> index 0000000..051ee0f
>> >> --- /dev/null
>> >> +++ b/arch/arm/boot/dts/vf610m4-colibri.dts
>> >> @@ -0,0 +1,52 @@
>> >> +/*
>> >> + * Device tree for Colibri VF61 Cortex-M4 support
>> >> + *
>> >> + * Copyright 2014 Stefan Agner
>> >> + *
>> >> + * 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.
>> >> + */
>> >> +
>> >> +/dts-v1/;
>> >> +#include "vf610m4.dtsi"
>> >> +
>> >> +/ {
>> >> +       model = "VF610 Cortex-M4";
>> >> +       compatible = "fsl,vf610m4";
>> >> +
>> >> +       chosen {
>> >> +               bootargs = "console=ttyLP2,115200 ihash_entries=64 dhash_entries=64 earlyprintk clk_ignore_unused init=/linuxrc rw";
>> >> +       };
>> >> +
>> >
>> > Starting with v3.19, you should be able to use the earlycon framework on
>> > arm32, so it would be better to replace earlyprintk with earlycon here
>> > and add a stdout-path property in chosen that points to the console
>> > uart.
>>
>> I started to implement earlycon support, but something currently fails
>> when earlycon tries to map the UART registers:
>> [    0.000000] earlycon_map: Couldn't map 0x40027000
>>
>> I traced the issue a bit further down and found that get_vm_area_caller
>> returns NULL (in __arm_ioremap_pfn_caller). This happend on Linus master
>> as of today (2dbfca5a181973558277b28b1f4c36362291f5e0). Do I miss
>> something here?
> 
> Hmm, I fear the arm32 FIX_EARLYCON_MEM support ended up not making it
> into 3.19 after all. :(

Is it because early_ioremap and fixmap still missing for arm32?
According to Rob's patchset from spring fixmap is required, there is
something in this tree:
https://git.kernel.org/cgit/linux/kernel/git/robh/linux.git/log/?h=arm-fixmap

--
Stefan

Re: [PATCH 11/12] ARM: dts: add support for Vybrid running on Cortex-M4

[Stefan Agner]

On 2014-12-17 13:31, Arnd Bergmann wrote:
> On Wednesday 17 December 2014 00:41:33 Stefan Agner wrote:
>> On 2014-12-03 12:03, Arnd Bergmann wrote:
>> > On Wednesday 03 December 2014 01:12:10 Stefan Agner wrote:
>> >> diff --git a/arch/arm/boot/dts/vf610m4-colibri.dts b/arch/arm/boot/dts/vf610m4-colibri.dts
>> >> new file mode 100644
>> >> index 0000000..051ee0f
>> >> --- /dev/null
>> >> +++ b/arch/arm/boot/dts/vf610m4-colibri.dts
>> >> @@ -0,0 +1,52 @@
>> >> +/*
>> >> + * Device tree for Colibri VF61 Cortex-M4 support
>> >> + *
>> >> + * Copyright 2014 Stefan Agner
>> >> + *
>> >> + * 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.
>> >> + */
>> >> +
>> >> +/dts-v1/;
>> >> +#include "vf610m4.dtsi"
>> >> +
>> >> +/ {
>> >> +       model = "VF610 Cortex-M4";
>> >> +       compatible = "fsl,vf610m4";
>> >> +
>> >> +       chosen {
>> >> +               bootargs = "console=ttyLP2,115200 ihash_entries=64 dhash_entries=64 earlyprintk clk_ignore_unused init=/linuxrc rw";
>> >> +       };
>> >> +
>> >
>> > Starting with v3.19, you should be able to use the earlycon framework on
>> > arm32, so it would be better to replace earlyprintk with earlycon here
>> > and add a stdout-path property in chosen that points to the console
>> > uart.
>>
>> I started to implement earlycon support, but something currently fails
>> when earlycon tries to map the UART registers:
>> [    0.000000] earlycon_map: Couldn't map 0x40027000
>>
>> I traced the issue a bit further down and found that get_vm_area_caller
>> returns NULL (in __arm_ioremap_pfn_caller). This happend on Linus master
>> as of today (2dbfca5a181973558277b28b1f4c36362291f5e0). Do I miss
>> something here?
> 
> Hmm, I fear the arm32 FIX_EARLYCON_MEM support ended up not making it
> into 3.19 after all. :(

Is it because early_ioremap and fixmap still missing for arm32?
According to Rob's patchset from spring fixmap is required, there is
something in this tree:
https://git.kernel.org/cgit/linux/kernel/git/robh/linux.git/log/?h=arm-fixmap

--
Stefan

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 11/12] ARM: dts: add support for Vybrid running on Cortex-M4

[Stefan Agner]

On 2014-12-17 13:31, Arnd Bergmann wrote:
> On Wednesday 17 December 2014 00:41:33 Stefan Agner wrote:
>> On 2014-12-03 12:03, Arnd Bergmann wrote:
>> > On Wednesday 03 December 2014 01:12:10 Stefan Agner wrote:
>> >> diff --git a/arch/arm/boot/dts/vf610m4-colibri.dts b/arch/arm/boot/dts/vf610m4-colibri.dts
>> >> new file mode 100644
>> >> index 0000000..051ee0f
>> >> --- /dev/null
>> >> +++ b/arch/arm/boot/dts/vf610m4-colibri.dts
>> >> @@ -0,0 +1,52 @@
>> >> +/*
>> >> + * Device tree for Colibri VF61 Cortex-M4 support
>> >> + *
>> >> + * Copyright 2014 Stefan Agner
>> >> + *
>> >> + * 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.
>> >> + */
>> >> +
>> >> +/dts-v1/;
>> >> +#include "vf610m4.dtsi"
>> >> +
>> >> +/ {
>> >> +       model = "VF610 Cortex-M4";
>> >> +       compatible = "fsl,vf610m4";
>> >> +
>> >> +       chosen {
>> >> +               bootargs = "console=ttyLP2,115200 ihash_entries=64 dhash_entries=64 earlyprintk clk_ignore_unused init=/linuxrc rw";
>> >> +       };
>> >> +
>> >
>> > Starting with v3.19, you should be able to use the earlycon framework on
>> > arm32, so it would be better to replace earlyprintk with earlycon here
>> > and add a stdout-path property in chosen that points to the console
>> > uart.
>>
>> I started to implement earlycon support, but something currently fails
>> when earlycon tries to map the UART registers:
>> [    0.000000] earlycon_map: Couldn't map 0x40027000
>>
>> I traced the issue a bit further down and found that get_vm_area_caller
>> returns NULL (in __arm_ioremap_pfn_caller). This happend on Linus master
>> as of today (2dbfca5a181973558277b28b1f4c36362291f5e0). Do I miss
>> something here?
> 
> Hmm, I fear the arm32 FIX_EARLYCON_MEM support ended up not making it
> into 3.19 after all. :(

Is it because early_ioremap and fixmap still missing for arm32?
According to Rob's patchset from spring fixmap is required, there is
something in this tree:
https://git.kernel.org/cgit/linux/kernel/git/robh/linux.git/log/?h=arm-fixmap

--
Stefan

Re: [PATCH 11/12] ARM: dts: add support for Vybrid running on Cortex-M4

[Arnd Bergmann]

On Thursday 18 December 2014 21:36:31 Stefan Agner wrote:
> On 2014-12-17 13:31, Arnd Bergmann wrote:
> > On Wednesday 17 December 2014 00:41:33 Stefan Agner wrote:
> >> On 2014-12-03 12:03, Arnd Bergmann wrote:
> >> > Starting with v3.19, you should be able to use the earlycon framework on
> >> > arm32, so it would be better to replace earlyprintk with earlycon here
> >> > and add a stdout-path property in chosen that points to the console
> >> > uart.
> >>
> >> I started to implement earlycon support, but something currently fails
> >> when earlycon tries to map the UART registers:
> >> [    0.000000] earlycon_map: Couldn't map 0x40027000
> >>
> >> I traced the issue a bit further down and found that get_vm_area_caller
> >> returns NULL (in __arm_ioremap_pfn_caller). This happend on Linus master
> >> as of today (2dbfca5a181973558277b28b1f4c36362291f5e0). Do I miss
> >> something here?
> > 
> > Hmm, I fear the arm32 FIX_EARLYCON_MEM support ended up not making it
> > into 3.19 after all. 
> 
> Is it because early_ioremap and fixmap still missing for arm32?
> According to Rob's patchset from spring fixmap is required, there is
> something in this tree:
> https://git.kernel.org/cgit/linux/kernel/git/robh/linux.git/log/?h=arm-fixmap

Right, that's the one, thanks for finding that again. There are five
patches on that branch. The first three got merged, and the one we
need is just the last one (ARM: fixmap early permanent mapping support),
but the implementation depends on the previous patch (arm: add
early_ioremap support).

I was hoping we'd see both of them in 3.19, but apparently Rob didn't
submit the latest version. If you don't mind, could you try forward-porting
them to the latest kernel and then submit them for inclusion? You could
also try adapting the last patch to work without the early_ioremap
support that we don't really need that urgently on arm32.

	Arnd

Re: [PATCH 11/12] ARM: dts: add support for Vybrid running on Cortex-M4

[Arnd Bergmann]

On Thursday 18 December 2014 21:36:31 Stefan Agner wrote:
> On 2014-12-17 13:31, Arnd Bergmann wrote:
> > On Wednesday 17 December 2014 00:41:33 Stefan Agner wrote:
> >> On 2014-12-03 12:03, Arnd Bergmann wrote:
> >> > Starting with v3.19, you should be able to use the earlycon framework on
> >> > arm32, so it would be better to replace earlyprintk with earlycon here
> >> > and add a stdout-path property in chosen that points to the console
> >> > uart.
> >>
> >> I started to implement earlycon support, but something currently fails
> >> when earlycon tries to map the UART registers:
> >> [    0.000000] earlycon_map: Couldn't map 0x40027000
> >>
> >> I traced the issue a bit further down and found that get_vm_area_caller
> >> returns NULL (in __arm_ioremap_pfn_caller). This happend on Linus master
> >> as of today (2dbfca5a181973558277b28b1f4c36362291f5e0). Do I miss
> >> something here?
> > 
> > Hmm, I fear the arm32 FIX_EARLYCON_MEM support ended up not making it
> > into 3.19 after all. 
> 
> Is it because early_ioremap and fixmap still missing for arm32?
> According to Rob's patchset from spring fixmap is required, there is
> something in this tree:
> https://git.kernel.org/cgit/linux/kernel/git/robh/linux.git/log/?h=arm-fixmap

Right, that's the one, thanks for finding that again. There are five
patches on that branch. The first three got merged, and the one we
need is just the last one (ARM: fixmap early permanent mapping support),
but the implementation depends on the previous patch (arm: add
early_ioremap support).

I was hoping we'd see both of them in 3.19, but apparently Rob didn't
submit the latest version. If you don't mind, could you try forward-porting
them to the latest kernel and then submit them for inclusion? You could
also try adapting the last patch to work without the early_ioremap
support that we don't really need that urgently on arm32.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 11/12] ARM: dts: add support for Vybrid running on Cortex-M4

[Arnd Bergmann]

On Thursday 18 December 2014 21:36:31 Stefan Agner wrote:
> On 2014-12-17 13:31, Arnd Bergmann wrote:
> > On Wednesday 17 December 2014 00:41:33 Stefan Agner wrote:
> >> On 2014-12-03 12:03, Arnd Bergmann wrote:
> >> > Starting with v3.19, you should be able to use the earlycon framework on
> >> > arm32, so it would be better to replace earlyprintk with earlycon here
> >> > and add a stdout-path property in chosen that points to the console
> >> > uart.
> >>
> >> I started to implement earlycon support, but something currently fails
> >> when earlycon tries to map the UART registers:
> >> [    0.000000] earlycon_map: Couldn't map 0x40027000
> >>
> >> I traced the issue a bit further down and found that get_vm_area_caller
> >> returns NULL (in __arm_ioremap_pfn_caller). This happend on Linus master
> >> as of today (2dbfca5a181973558277b28b1f4c36362291f5e0). Do I miss
> >> something here?
> > 
> > Hmm, I fear the arm32 FIX_EARLYCON_MEM support ended up not making it
> > into 3.19 after all. 
> 
> Is it because early_ioremap and fixmap still missing for arm32?
> According to Rob's patchset from spring fixmap is required, there is
> something in this tree:
> https://git.kernel.org/cgit/linux/kernel/git/robh/linux.git/log/?h=arm-fixmap

Right, that's the one, thanks for finding that again. There are five
patches on that branch. The first three got merged, and the one we
need is just the last one (ARM: fixmap early permanent mapping support),
but the implementation depends on the previous patch (arm: add
early_ioremap support).

I was hoping we'd see both of them in 3.19, but apparently Rob didn't
submit the latest version. If you don't mind, could you try forward-porting
them to the latest kernel and then submit them for inclusion? You could
also try adapting the last patch to work without the early_ioremap
support that we don't really need that urgently on arm32.

	Arnd

Re: [PATCH 11/12] ARM: dts: add support for Vybrid running on Cortex-M4

[Stefan Agner]

On 2014-12-18 23:44, Arnd Bergmann wrote:
> On Thursday 18 December 2014 21:36:31 Stefan Agner wrote:
>> On 2014-12-17 13:31, Arnd Bergmann wrote:
>> > On Wednesday 17 December 2014 00:41:33 Stefan Agner wrote:
>> >> On 2014-12-03 12:03, Arnd Bergmann wrote:
>> >> > Starting with v3.19, you should be able to use the earlycon framework on
>> >> > arm32, so it would be better to replace earlyprintk with earlycon here
>> >> > and add a stdout-path property in chosen that points to the console
>> >> > uart.
>> >>
>> >> I started to implement earlycon support, but something currently fails
>> >> when earlycon tries to map the UART registers:
>> >> [    0.000000] earlycon_map: Couldn't map 0x40027000
>> >>
>> >> I traced the issue a bit further down and found that get_vm_area_caller
>> >> returns NULL (in __arm_ioremap_pfn_caller). This happend on Linus master
>> >> as of today (2dbfca5a181973558277b28b1f4c36362291f5e0). Do I miss
>> >> something here?
>> >
>> > Hmm, I fear the arm32 FIX_EARLYCON_MEM support ended up not making it
>> > into 3.19 after all.
>>
>> Is it because early_ioremap and fixmap still missing for arm32?
>> According to Rob's patchset from spring fixmap is required, there is
>> something in this tree:
>> https://git.kernel.org/cgit/linux/kernel/git/robh/linux.git/log/?h=arm-fixmap
> 
> Right, that's the one, thanks for finding that again. There are five
> patches on that branch. The first three got merged, and the one we
> need is just the last one (ARM: fixmap early permanent mapping support),
> but the implementation depends on the previous patch (arm: add
> early_ioremap support).
> 
> I was hoping we'd see both of them in 3.19, but apparently Rob didn't
> submit the latest version. If you don't mind, could you try forward-porting
> them to the latest kernel and then submit them for inclusion? You could
> also try adapting the last patch to work without the early_ioremap
> support that we don't really need that urgently on arm32.

Looked into that a bit more in depth. I tried creating a patch which
adds just what is necessary to support FIX_EARLYCON_MEM. Fixmap seems to
be in place, just for earlycon it would need a fixmap entry with
FIX_EARLYCON_MEM_BASE. And I guess later during boot, it would need a
call to create_mapping to create a permanent mapping of it.

Currently I'm stuck in the __set_fixmap call, on set_pte_ext call the
kernel freezes. The arguments look fine as far as I can tell (vaddr
ffeff000, phys 40027000, pgprot is FIXMAP_PAGE_IO, defined as in Rob's
patchset). 

Afaik, initialization for early fixmap is missing, I guess we could do
something which looks similar to what ARM64 has now:

https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/?id=af86e5974d3069bd26ebcf7c046c6e59726acaaa

I'm wondering what the value is of __set_fixmap without that, as is
right now? I still need to understand the whole MM stuff a bit more. I
will be away the next couple of days, but will have a look into it
towards the end of the year. But if anyone else can help make that
happen (who might be better in the picture of fixmap than I am), I'm
happy too :-)

--
Stefan

[PATCH 11/12] ARM: dts: add support for Vybrid running on Cortex-M4

[Stefan Agner]

On 2014-12-18 23:44, Arnd Bergmann wrote:
> On Thursday 18 December 2014 21:36:31 Stefan Agner wrote:
>> On 2014-12-17 13:31, Arnd Bergmann wrote:
>> > On Wednesday 17 December 2014 00:41:33 Stefan Agner wrote:
>> >> On 2014-12-03 12:03, Arnd Bergmann wrote:
>> >> > Starting with v3.19, you should be able to use the earlycon framework on
>> >> > arm32, so it would be better to replace earlyprintk with earlycon here
>> >> > and add a stdout-path property in chosen that points to the console
>> >> > uart.
>> >>
>> >> I started to implement earlycon support, but something currently fails
>> >> when earlycon tries to map the UART registers:
>> >> [    0.000000] earlycon_map: Couldn't map 0x40027000
>> >>
>> >> I traced the issue a bit further down and found that get_vm_area_caller
>> >> returns NULL (in __arm_ioremap_pfn_caller). This happend on Linus master
>> >> as of today (2dbfca5a181973558277b28b1f4c36362291f5e0). Do I miss
>> >> something here?
>> >
>> > Hmm, I fear the arm32 FIX_EARLYCON_MEM support ended up not making it
>> > into 3.19 after all.
>>
>> Is it because early_ioremap and fixmap still missing for arm32?
>> According to Rob's patchset from spring fixmap is required, there is
>> something in this tree:
>> https://git.kernel.org/cgit/linux/kernel/git/robh/linux.git/log/?h=arm-fixmap
> 
> Right, that's the one, thanks for finding that again. There are five
> patches on that branch. The first three got merged, and the one we
> need is just the last one (ARM: fixmap early permanent mapping support),
> but the implementation depends on the previous patch (arm: add
> early_ioremap support).
> 
> I was hoping we'd see both of them in 3.19, but apparently Rob didn't
> submit the latest version. If you don't mind, could you try forward-porting
> them to the latest kernel and then submit them for inclusion? You could
> also try adapting the last patch to work without the early_ioremap
> support that we don't really need that urgently on arm32.

Looked into that a bit more in depth. I tried creating a patch which
adds just what is necessary to support FIX_EARLYCON_MEM. Fixmap seems to
be in place, just for earlycon it would need a fixmap entry with
FIX_EARLYCON_MEM_BASE. And I guess later during boot, it would need a
call to create_mapping to create a permanent mapping of it.

Currently I'm stuck in the __set_fixmap call, on set_pte_ext call the
kernel freezes. The arguments look fine as far as I can tell (vaddr
ffeff000, phys 40027000, pgprot is FIXMAP_PAGE_IO, defined as in Rob's
patchset). 

Afaik, initialization for early fixmap is missing, I guess we could do
something which looks similar to what ARM64 has now:

https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/?id=af86e5974d3069bd26ebcf7c046c6e59726acaaa

I'm wondering what the value is of __set_fixmap without that, as is
right now? I still need to understand the whole MM stuff a bit more. I
will be away the next couple of days, but will have a look into it
towards the end of the year. But if anyone else can help make that
happen (who might be better in the picture of fixmap than I am), I'm
happy too :-)

--
Stefan