ARM: shmobile: Use "arm,pl390" for GIC where appropriate

Hi Simon, Magnus, Greg,

On several Renesas ARM SoCs, the GIC is described in DT as being a Cortex A9 GIC, while it's actually a PL390. This is not only stated in the documentation, but has been verified by reading the GICD_IIDR register.

This series
1. Corrects the DT compatible value to match reality,
2. Updates the board staging drivers to match the above.

As both parts impact each other, I think it's best that all patches go in through Simon's ARM/SHMOBILE tree.

Greg: can you please provide your ack for the last two patches?

Thanks!

Geert Uytterhoeven (6):
ARM: shmobile: r7s72100 dtsi: Use "arm,pl390" for GIC
ARM: shmobile: r8a7740 dtsi: Use "arm,pl390" for GIC
ARM: shmobile: emev2 dtsi: Use "arm,pl390" for GIC
ARM: shmobile: r8a7778 dtsi: Use "arm,pl390" for GIC
staging: board: kzm9d: Use "arm,pl390"
staging: board: armadillo800eva: Use "arm,pl390"

 arch/arm/boot/dts/emev2.dtsi            | 2 +-
 arch/arm/boot/dts/r7s72100.dtsi         | 2 +-
 arch/arm/boot/dts/r8a7740.dtsi          | 2 +-
 arch/arm/boot/dts/r8a7778.dtsi          | 2 +-
 drivers/staging/board/armadillo800eva.c | 2 +-
 drivers/staging/board/kzm9d.c           | 2 +-
 6 files changed, 6 insertions(+), 6 deletions(-)

1.9.1

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

Replace the "arm,cortex-a9-gic" compatible value for the GIC by "arm,pl390", as the documentation states it is a PL390. This has been confirmed (thanks Chris, Wolfram!) by reading the GICD_IIDR register, which reports 0x0000043b (PL390 = 0x00, ARM = 0x43b).

This has no effect on runtime behavior, as currently the GIC driver treats both compatible values the same.

---
You can read the GICD_IIDR register from U-Boot using

    md 0xe8201008 1
---
 arch/arm/boot/dts/r7s72100.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

index 5f22d6dcdd141f9c..0c3b9e341ce7fd8e 100644
@@ -329,7 +329,7 @@
 	};
 
 	gic: interrupt-controller at e8201000 {
-		compatible = "arm,cortex-a9-gic";
+		compatible = "arm,pl390";
 		#interrupt-cells = <3>;
 		#address-cells = <0>;
 		interrupt-controller;

1.9.1

Replace the "arm,cortex-a9-gic" compatible value for the GIC by "arm,pl390", as the documentation states it is a PL390.
This has been confirmed by reading the GICD_IIDR register, which reports 0x0000043b (PL390 = 0x00, ARM = 0x43b).

This has no effect on runtime behavior, as currently the GIC driver treats both compatible values the same.

---
You can read the GICD_IIDR register from Hermit using

    frob
    peek 0xc2800008
---
 arch/arm/boot/dts/r8a7740.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

index 4d58cdc3a026b2a4..08846c72cf1a64a3 100644
@@ -39,7 +39,7 @@
 	};
 
 	gic: interrupt-controller at c2800000 {
-		compatible = "arm,cortex-a9-gic";
+		compatible = "arm,pl390";
 		#interrupt-cells = <3>;
 		interrupt-controller;
 		reg = <0xc2800000 0x1000>,

1.9.1

Replace the "arm,cortex-a9-gic" compatible value for the GIC by "arm,pl390", as the documentation states it is a PL390. This has been confirmed (thanks Simon!) by reading the GICD_IIDR register, which reports 0x0000043b (PL390 = 0x00, ARM = 0x43b).

This has no effect on runtime behavior, as currently the GIC driver treats both compatible values the same.

---
You can read the GICD_IIDR register from U-Boot using

    md 0xe0028008 1
---
 arch/arm/boot/dts/emev2.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

index edad0c4eea3505b7..57795da616cb4085 100644
@@ -44,7 +44,7 @@
 	};
 
 	gic: interrupt-controller at e0020000 {
-		compatible = "arm,cortex-a9-gic";
+		compatible = "arm,pl390";
 		interrupt-controller;
 		#interrupt-cells = <3>;
 		reg = <0xe0028000 0x1000>,

1.9.1

Replace the "arm,cortex-a9-gic" compatible value for the GIC by "arm,pl390", as the documentation states it is a PL390.
This has been confirmed by reading the GICD_IIDR register, which reports 0x0000043b (PL390 = 0x00, ARM = 0x43b).

This has no effect on runtime behavior, as currently the GIC driver treats both compatible values the same.

---
You can read the GICD_IIDR register from U-Boot using

    md 0xfe438008 1
---
 arch/arm/boot/dts/r8a7778.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

index da76f5d95875ce11..fd10197c7dba6d7d 100644
@@ -61,7 +61,7 @@
 	};
 
 	gic: interrupt-controller at fe438000 {
-		compatible = "arm,cortex-a9-gic";
+		compatible = "arm,pl390";
 		#interrupt-cells = <3>;
 		interrupt-controller;
 		reg = <0xfe438000 0x1000>,

1.9.1

---
Must be applied together with "ARM: shmobile: emev2 dtsi: Use "arm,pl390" for GIC"!

Greg: Can you please provide your ack? Thanks!

---
 drivers/staging/board/kzm9d.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

index 8d1eb09bc66ef413..05a6d434d307fe0f 100644
@@ -11,7 +11,7 @@ static struct resource usbs1_res[] __initdata = {
 
 static void __init kzm9d_init(void)
 {
-	board_staging_gic_setup_xlate("arm,cortex-a9-gic", 32);
+	board_staging_gic_setup_xlate("arm,pl390", 32);
 
 	if (!board_staging_dt_node_available(usbs1_res,
 					     ARRAY_SIZE(usbs1_res))) {

1.9.1

---
Must be applied together with "ARM: shmobile: r8a7740 dtsi: Use "arm,pl390" for GIC"!

Greg: Can you please provide your ack? Thanks!

---
 drivers/staging/board/armadillo800eva.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

index 9c41652ee908b5e8..912c96b0536def7c 100644
@@ -97,7 +97,7 @@ static const struct board_staging_dev armadillo800eva_devices[] __initconst = {
 
 static void __init armadillo800eva_init(void)
 {
-	board_staging_gic_setup_xlate("arm,cortex-a9-gic", 32);
+	board_staging_gic_setup_xlate("arm,pl390", 32);
 	board_staging_register_devices(armadillo800eva_devices,
 				       ARRAY_SIZE(armadillo800eva_devices));
 }

1.9.1

Thanks Greg,

I have taken the liberty of assuming that ack also applies to patch 5/6 of this series, the other staging/board patch in this series.

I have queued up this series accordingly.

Oops, yes, good call, thanks for doing this.

greg k-h

No problem.

For the record I have queued up these patches for v4.6 as I believe that the ARM SoC maintainers prefer not to have driver changes depending on DT changes and the first four patches of this series are DT changes.