ARM: keystone: Few non-critical fixes, cleanups for 3.12

Here are few non-critical fixes, cleanups for the Keystone SOCs targeted for 3.12 merge window.

Brief summary of changes:
- Drop unused HAVE_SCHED_CLOCK config option
- Remove now redundant keystone_cpu_smc() call
- Update the smc code to remove dsb and r12 usage
- Convert device tree to use #include and GIC bindings
- Update the MAINTAINER file.

Boot tested on Kesytone 2 EVM.

Paul Bolle (1):
ARM: keystone: drop useless HAVE_SCHED_CLOCK

Santosh Shilimkar (5):
ARM: Keystone: No need to preserve r12 across smc call
ARM: keystone: Drop the un-necessary dsb from keystone_cpu_smc()
ARM: keystone: use #include to include skeleton.dtsi
ARM: Keystone: Convert device tree file to use IRQ defines
MAINTAINERS: add TI Keystone ARM platform

Sudeep KarkadaNagesha (1):
ARM: keystone: remove redundant smp_init_cpus definition

 MAINTAINERS                      |    6 ++++++
 arch/arm/boot/dts/keystone.dts   |   29 ++++++++++++++++++-----------
 arch/arm/mach-keystone/Kconfig   |    1 -
 arch/arm/mach-keystone/platsmp.c |    1 -
 arch/arm/mach-keystone/smc.S     |    5 ++---
 5 files changed, 26 insertions(+), 16 deletions(-)

Regards,
Santosh

1.7.9.5

From: Paul Bolle <[email protected]>

The Kconfig symbol HAVE_SCHED_CLOCK got removed in v3.4, with commit 6905a65879b5 ("ARM: Make the sched_clock framework mandatory"). But a select statement for it popped up again through commit 828989ad87af ("ARM: keystone: Add minimal TI Keystone platform support"). Drop that statement, as it is useless.

---
 arch/arm/mach-keystone/Kconfig |    1 -
 1 file changed, 1 deletion(-)

index 51a50e9..366d1a3 100644
@@ -7,7 +7,6 @@ config ARCH_KEYSTONE
 	select HAVE_SMP
 	select CLKSRC_MMIO
 	select GENERIC_CLOCKEVENTS
-	select HAVE_SCHED_CLOCK
 	select ARCH_WANT_OPTIONAL_GPIOLIB
 	select ARM_ERRATA_798181 if SMP
 	help

1.7.9.5

From: Sudeep KarkadaNagesha <[email protected]>

arm_dt_init_cpu_maps is called before smp_init_cpus. It makes the platform/SoC definition of smp_init_cpus unnecessary.

---
 arch/arm/mach-keystone/platsmp.c |    1 -
 1 file changed, 1 deletion(-)

index 14378e3..c122961 100644
@@ -38,6 +38,5 @@ static int keystone_smp_boot_secondary(unsigned int cpu,
 }
 
 struct smp_operations keystone_smp_ops __initdata = {
-	.smp_init_cpus		= arm_dt_init_cpu_maps,
 	.smp_boot_secondary	= keystone_smp_boot_secondary,
 };

1.7.9.5

Register r12 is caller-save, so no need preserve it keystone_cpu_smc().

---
 arch/arm/mach-keystone/smc.S |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

index 9b9e4f7..5bb5176 100644
@@ -22,8 +22,8 @@
  * Return: Non zero value on failure
  */
 ENTRY(keystone_cpu_smc)
-	stmfd   sp!, {r4-r12, lr}
+	stmfd   sp!, {r4-r11, lr}
 	smc	#0
 	dsb
-	ldmfd   sp!, {r4-r12, pc}
+	ldmfd   sp!, {r4-r11, pc}
 ENDPROC(keystone_cpu_smc)

1.7.9.5

This was added because of some legacy reasons from OMAP SOCs but after testing and verifying with the keystone hardware folks, the dsb in keystone_cpu_smc() is not necessary.

So drop it.

---
 arch/arm/mach-keystone/smc.S |    1 -
 1 file changed, 1 deletion(-)

index 5bb5176..d15de81 100644
@@ -24,6 +24,5 @@
 ENTRY(keystone_cpu_smc)
 	stmfd   sp!, {r4-r11, lr}
 	smc	#0
-	dsb
 	ldmfd   sp!, {r4-r11, pc}
 ENDPROC(keystone_cpu_smc)

1.7.9.5

Replace /include/ (dtc) with #include (C pre-processor) to include skeleton.dtsi

---
 arch/arm/boot/dts/keystone.dts |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

index 1334b42..612ba8c 100644
@@ -7,7 +7,7 @@
  */
 
 /dts-v1/;
-/include/ "skeleton.dtsi"
+#include "skeleton.dtsi"
 
 / {
 	model = "Texas Instruments Keystone 2 SoC";

1.7.9.5

Use the GIC and standard IRQ binding defines in all IRQ specifiers.

---
 arch/arm/boot/dts/keystone.dts |   27 +++++++++++++++++----------
 1 file changed, 17 insertions(+), 10 deletions(-)

index 612ba8c..a68e34b 100644
@@ -7,6 +7,8 @@
  */
 
 /dts-v1/;
+#include <dt-bindings/interrupt-controller/arm-gic.h>
+
 #include "skeleton.dtsi"
 
 / {

@@ -67,18 +69,23 @@
 
 	timer {
 		compatible = "arm,armv7-timer";
-		interrupts = <1 13 0xf08>,
-			     <1 14 0xf08>,
-			     <1 11 0xf08>,
-			     <1 10 0x308>;
+		interrupts =
+			<GIC_PPI 13
+				(GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
+			<GIC_PPI 14
+				(GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
+			<GIC_PPI 11
+				(GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
+			<GIC_PPI 10
+				(GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>;
 	};
 
 	pmu {
 		compatible = "arm,cortex-a15-pmu";
-		interrupts = <0 20 0xf01>,
-			     <0 21 0xf01>,
-			     <0 22 0xf01>,
-			     <0 23 0xf01>;
+		interrupts = <GIC_SPI 20 IRQ_TYPE_EDGE_RISING>,
+			     <GIC_SPI 21 IRQ_TYPE_EDGE_RISING>,
+			     <GIC_SPI 22 IRQ_TYPE_EDGE_RISING>,
+			     <GIC_SPI 23 IRQ_TYPE_EDGE_RISING>;
 	};
 
 	soc {

@@ -100,7 +107,7 @@
 			reg-io-width = <4>;
 			reg = <0x02530c00 0x100>;
 			clock-frequency = <133120000>;
-			interrupts = <0 277 0xf01>;
+			interrupts = <GIC_SPI 277 IRQ_TYPE_EDGE_RISING>;
 		};
 
 		uart1:	serial at 02531000 {

@@ -110,7 +117,7 @@
 			reg-io-width = <4>;
 			reg = <0x02531000 0x100>;
 			clock-frequency = <133120000>;
-			interrupts = <0 280 0xf01>;
+			interrupts = <GIC_SPI 280 IRQ_TYPE_EDGE_RISING>;
 		};
 
 	};

1.7.9.5

Adding maintainer for arch/arm/mach-keystone/

---
 MAINTAINERS |    6 ++++++
 1 file changed, 6 insertions(+)

index bf61e04..b24a96e 100644
@@ -965,6 +965,12 @@ M:	Lennert Buytenhek <[email protected]>
 L:	linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
 S:	Maintained
 
+ARM/TEXAS INSTRUMENT KEYSTONE ARCHITECTURE
+M:	Santosh Shilimkar <[email protected]>
+L:	linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
+S:	Maintained
+F:	arch/arm/mach-keystone/
+
 ARM/LOGICPD PXA270 MACHINE SUPPORT
 M:	Lennert Buytenhek <[email protected]>
 L:	linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)

1.7.9.5

Since I'm colleting some MAINTAINERS changes, I applied this one to arm-soc/fixes.

The rest of the series looks good to me. Are you still waiting for any more feedback? If not, are you planning to send a pull request? or I could just apply 1-6 for fixes-non-critical.

Kevin

Thanks

I will send a pull request dropping the last patch which you already applied.

Regards,
Santosh