ARM RealView DeviceTree support v4

This makes it possible to create a set of LEDs from a syscon MFD instance, which is lean mean and clean on the ARM reference designs and can replace the Versatile LEDs driver in the long run, as well as other custom syscon LEDs drivers.

Cc Bryan Wu <[email protected]>

Cc Richard Purdie <[email protected]>

Signed-off-by Linus Walleij <[email protected]>

This adds the device tree bindings used by syscon-based LEDs.

Cc devicetree at vger.kernel.org

Cc Bryan Wu <[email protected]>

Cc Richard Purdie <[email protected]>

Signed-off-by Linus Walleij <[email protected]>

---
 .../devicetree/bindings/leds/leds-syscon.txt       | 83 ++++++++++++++++++++++
 1 file changed, 83 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/leds/leds-syscon.txt

Documentation/devicetree/bindings/leds/leds-syscon.txt new file +0 -0

new file mode 100644
index 000000000000..460b9c3d1bd3

Documentation/devicetree/bindings/leds/leds-syscon.txt new file +8 -0

+  see Documentation/devicetree/bindings/leds/common.txt
+- linux,default-trigger : (optional)
+  see Documentation/devicetree/bindings/leds/common.txt
+- default-state: (optional) The initial state of the LED. Valid
+  values are "on", "off", and "keep". If the LED is already on or off
+  and the default-state property is set the to same value, then no
+  glitch should be produced where the LED momentarily turns off (or
+  on). The "keep" setting will keep the LED at whatever its current

Documentation/devicetree/bindings/leds/leds-syscon.txt new file +6 -0

+               offset = <0x08>;
+               mask = <0x01>;
+               label = "versatile:0";
+               linux,default-trigger = "heartbeat";
+               default-state = "on";
+       };

Quoted 1 line · Linus Walleij

This adds the device tree bindings used by syscon-based LEDs.

Documentation/devicetree/bindings/leds/leds-syscon.txt line 4

Quoted 4 lines

Documentation/devicetree/bindings/leds/leds-syscon.txt new file +4 -0

+Device Tree Bindings for Syscon LEDs
+
+Required properties:
+- compatible : must be "syscon-leds".

Not really happy with the name... More below.

I think the compatible should be something like "register-bit-led" (perhaps someone has a better name) as syscon is somewhat linux specific term and you could use this binding for any LEDs that have a single register bit control.

Documentation/devicetree/bindings/leds/leds-syscon.txt line 13

Quoted 4 lines

Documentation/devicetree/bindings/leds/leds-syscon.txt new file +4 -0

+LED sub-node properties:
+- offset : register offset to the register controlling this LED
+- mask : bit mask for the bit controlling this LED in the register
+  typically 0x01, 0x02, 0x04 ...

This would be a single bit, right? What about inverted bits (i.e. 0 is on or 1 is on)?

Quoted 1 line

+- label : (optional)

Please group all required and optional properties under those headings.

Documentation/devicetree/bindings/leds/leds-syscon.txt line 32

Quoted 7 lines

Documentation/devicetree/bindings/leds/leds-syscon.txt new file +7 -0

+Example:
+
+leds: leds at 08 {
+       compatible = "syscon-leds";
+       regmap = <&syscon>;
+
+       led at bit0 {

Perhaps we can define a way to express unit address as offset+bit like <offset>_<bit> or <offset>.<bit>.

I think we should get rid of the leds node and put this within the syscon device node and each node here should have a compatible property.

cd /sysbus/soc/devices/soc0
ls

cat family

cat fpga

cat board

cat build

This implements basic device tree boot support for the RealView platforms, with a basic device tree for ARM PB1176 as an example.

The implementation is done with a new DT-specific board file using only pre-existing bindings for the basic IRQ, timer and serial port drivers. A new compatible type is added to the GIC for the ARM1176.

This implementation uses the MFD syscon handle from day one to access the system controller registers, and register the devices using the SoC bus.

Cc Arnd Bergmann <[email protected]>

Cc Rob Herring <[email protected]>

Acked-by Jason Cooper <[email protected]>

Signed-off-by Linus Walleij <[email protected]>

---
ChangeLog v3->v4:
- Switch the LEDs to usa a new syscon-LEDs driver so we can use the syscon as a hub for all these registers
- Split out the SoC driver to its own file in drivers/soc ChangeLog v2->v3:
- Rename uart at 0x12345678 to serial at 0x12345678 in DTS file
- Drop static remapping for the LEDs, using my new invention syscon-leds instead
- Drop the hunk selecting ARM_DMA_MEM_BUFFERABLE for the DT version of the RealView platform. We think this is a local optimization we can live without.
- Split off the reset driver to a separate syscon-based reset driver in drivers/power/reset, add separate device tree bindings for this driver.
- To make sure the reset driver is always available for this system a few extra select statements are needed in Kconfig
- Split off the SoC bus driver to an easily identifiable chunk inside the mach-realview/realview-dt.c file. This *can* be spun off as a separate driver under drivers/soc for example but we need some separate discussion on this subject.
- Augment the SoC driver to display some system info so it's clear why this driver is there.
- Drop surplus string "with device tree" from machine description in the DTS file.
- Move the new GIC compatible string in alphabetic order. ChangeLog v1->v2:
- Adjust timer clock names to be the same as the example in the device tree binding.
- Remove all memory fixup code - this should be handled by the device tree specification of memory areas or by special MM hacks for the RealView PBX.
- Fix the documentation around syscon to specify that it can be in any node, need not be the root node.
- Switch device tree license to the BSD license, taken from arch/powerpc/boot/dts/p1024rdb_32b.dts
- Add a hunk for the new compatible string to Documentation/devicetree/bindings/arm/gic.txt
- Move the clocks out of the SoC node, certainly the xtal is not sitting on the SoC...
- Sort the selects in Kconfig alphabetically
- Use IS_ENABLED() for the l2x0 code snippet
- Instead of checking the board variant in the reset routine to figure out how to tweak the reset controller, have a compatible string for each syscon variant, map it to an enum that provides a unique type ID and that way figure out how to handle it in a maybe more elegant way.
- Open issue: what do to with the l2x0 stuff?

---
 Documentation/devicetree/bindings/arm/arm-boards |  66 +++++++
 Documentation/devicetree/bindings/arm/gic.txt    |   1 +
 arch/arm/boot/dts/Makefile                       |   1 +
 arch/arm/boot/dts/arm-realview-pb1176.dts        | 240 +++++++++++++++++++++++
 arch/arm/mach-realview/Kconfig                   |  13 ++
 arch/arm/mach-realview/Makefile                  |   1 +
 arch/arm/mach-realview/realview-dt.c             |  72 +++++++
 drivers/irqchip/irq-gic.c                        |   1 +
 8 files changed, 395 insertions(+)
 create mode 100644 arch/arm/boot/dts/arm-realview-pb1176.dts
 create mode 100644 arch/arm/mach-realview/realview-dt.c

Documentation/devicetree/bindings/arm/arm-boards +19 -0

index 3509707f9320..d2399e6f1378 100644
@@ -86,3 +86,69 @@ Interrupt controllers:
        compatible = "arm,versatile-sic";
        interrupt-controller;
        #interrupt-cells = <1>;
+
+
+ARM RealView Boards
+-------------------
+The RealView boards cover tailored evaluation boards that are used to explore
+the ARM11 and Cortex A-8 and Cortex A-9 processors.
+
+Required properties (in root node):
+       /* RealView Emulation Baseboard */
+       compatible = "arm,realview-eb";
+        /* RealView Platform Baseboard for ARM1176JZF-S */
+       compatible = "arm,realview-pb1176";
+       /* RealView Platform Baseboard for ARM11 MPCore */
+       compatible = "arm,realview-pb11mp";
+       /* RealView Platform Baseboard for Cortex A-8 */
+       compatible = "arm,realview-pba8";
+       /* RealView Platform Baseboard Explore for Cortex A-9 */
+       compatible = "arm,realview-pbx";
+

Documentation/devicetree/bindings/arm/arm-boards +6 -0

+       soc {
+               #address-cells = <1>;
+               #size-cells = <1>;
+               compatible = "simple-bus", "arm,realview-pb1176-soc";
+               regmap = <&syscon>;
+               ranges;

Documentation/devicetree/bindings/arm/arm-boards +8 -0

+                       #interrupt-cells = <3>;
+                       #address-cells = <1>;
+                       interrupt-controller;
+                       reg = <0x10041000 0x1000>,
+                             <0x10040000 0x100>;
+                       interrupt-parent = <&intc_dc1176>;
+                       interrupts = <0 31 IRQ_TYPE_LEVEL_HIGH>;
+               };

Documentation/devicetree/bindings/arm/arm-boards +22 -0

+static void __init realview_dt_init_machine(void)
+{
+       int ret;
+
+#if IS_ENABLED(CONFIG_CACHE_L2X0)
+       if (of_machine_is_compatible("arm,realview-eb"))
+               /*
+                * 1MB (128KB/way), 8-way associativity,
+                * evmon/parity/share enabled
+                * Bits:  .... ...0 0111 1001 0000 .... .... ....
+                */
+               l2x0_of_init(0x00790000, 0xfe000fff);
+       else if (of_machine_is_compatible("arm,realview-pb1176"))
+               /*
+                * 128Kb (16Kb/way) 8-way associativity.
+                * evmon/parity/share enabled.
+                */
+               l2x0_of_init(0x00730000, 0xfe000fff);
+       else if (of_machine_is_compatible("arm,realview-pb11mp"))
+               /*
+                * 1MB (128KB/way), 8-way associativity,
+                * evmon/parity/share enabled

+DT_MACHINE_START(REALVIEW_DT, "ARM RealView Machine (Device Tree Support)")

Hi Linus,

Quoted 22 lines · Linus Walleij

arch/arm/mach-realview/realview-dt.c new file +22 -0

+static void __init realview_dt_init_machine(void)
+{
+       int ret;
+
+#if IS_ENABLED(CONFIG_CACHE_L2X0)
+       if (of_machine_is_compatible("arm,realview-eb"))
+               /*
+                * 1MB (128KB/way), 8-way associativity,
+                * evmon/parity/share enabled
+                * Bits:  .... ...0 0111 1001 0000 .... .... ....
+                */
+               l2x0_of_init(0x00790000, 0xfe000fff);
+       else if (of_machine_is_compatible("arm,realview-pb1176"))
+               /*
+                * 128Kb (16Kb/way) 8-way associativity.
+                * evmon/parity/share enabled.
+                */
+               l2x0_of_init(0x00730000, 0xfe000fff);
+       else if (of_machine_is_compatible("arm,realview-pb11mp"))
+               /*
+                * 1MB (128KB/way), 8-way associativity,
+                * evmon/parity/share enabled

arch/arm/mach-realview/realview-dt.c line 47

Quoted 10 lines

arch/arm/mach-realview/realview-dt.c new file +10 -0

+                * Bits:  .... ...0 0111 1001 0000 .... .... ....
+                */
+               l2x0_of_init(0x00730000, 0xfe000fff);
+       else if (of_machine_is_compatible("arm,realview-pbx"))
+               /*
+                * 16KB way size, 8-way associativity, parity disabled
+                * Bits:  .. 0 0 0 0 1 00 1 0 1 001 0 000 0 .... .... ....
+                */
+               l2x0_of_init(0x02520000, 0xc0000fff);
+#endif

Are these just copied form what we already have for non-DT?

Do we know that these are all necessary?

I toyed with the idea of adding the standard cache size specifications to the L2C code, it sounds like there's a reason to do that now.

Let's not mess around with adding stuff like the above to work around the L2 code not parsing the appropriate specs from DT, let's do the right thing and add bindings to allow DT to provide the cache geometry.

Quoted 7 lines · On Friday 25 July 2014 16:50:10 Russell King - ARM Linux wrote:

I toyed with the idea of adding the standard cache size specifications to the L2C code, it sounds like there's a reason to do that now.

Let's not mess around with adding stuff like the above to work around the L2 code not parsing the appropriate specs from DT, let's do the right thing and add bindings to allow DT to provide the cache geometry.

Yes, please!

That would actually reduce the realview to just the dma_zone_size definition, and I think someone also posted a patch to get that from DT recently. Having realview booting with an empty board file would be ideal.

Quoted 9 lines · Arnd Bergmann

Quoted 7 lines · On Friday 25 July 2014 16:50:10 Russell King - ARM Linux wrote:

I toyed with the idea of adding the standard cache size specifications to the L2C code, it sounds like there's a reason to do that now.

Let's not mess around with adding stuff like the above to work around the L2 code not parsing the appropriate specs from DT, let's do the right thing and add bindings to allow DT to provide the cache geometry.

Quoted 6 lines

Yes, please!

That would actually reduce the realview to just the dma_zone_size definition, and I think someone also posted a patch to get that from DT recently. Having realview booting with an empty board file would be ideal.

I did have a patch in my L2C cleanup series to provide these properties, but it got discarded - even though we have existing platforms which provide these values.

The reason for that was because requiring new properties causes a DT breakage - previous versions of the DT suddenly stop working because the values necessary to setup the L2C have been removed from the kernel, and the older DT files do not contain the neccessary values either.

arch/arm/boot/dts/arm-realview-pb1176.dts line 150

Quoted 3 lines · Linus Walleij

arch/arm/boot/dts/arm-realview-pb1176.dts new file +3 -0

+               /* Primary DevChip GIC synthesized with the CPU */
+               intc_dc1176: interrupt-controller at 10120000 {
+                       compatible = "arm,arm1176jzf-gic";

As far as I am aware, the JZF flags haven nothing to do with the GIC implementation. I think they can be dropped from this string (following the example of "arm,arm1176-pmu").

arch/arm/boot/dts/arm-realview-pb1176.dts line 160

Quoted 3 lines

arch/arm/boot/dts/arm-realview-pb1176.dts new file +3 -0

+               /* This GIC on the board is cascaded off the DevChip GIC */
+               intc_pb1176: interrupt-controller at 10040000 {
+                       compatible = "arm,arm1176jzf-gic";

And this isn't part of the CPU, so that string doesn't look right. I'd at least like to see an additional string earlier in the list

Some ARM1176JZF confusion in as separate thread...

Quoted 6 lines · Mark Rutland

Quoted 3 lines · Linus Walleij

arch/arm/boot/dts/arm-realview-pb1176.dts new file +3 -0

+               /* Primary DevChip GIC synthesized with the CPU */
+               intc_dc1176: interrupt-controller at 10120000 {
+                       compatible = "arm,arm1176jzf-gic";

Quoted 3 lines

As far as I am aware, the JZF flags haven nothing to do with the GIC implementation. I think they can be dropped from this string (following the example of "arm,arm1176-pmu").

FWIW I changed the string to "arm,arm1176-gic"

But this isn't about the CPU actually. It is the ARM1176JZF development chip. See:
http://infocenter.arm.com/help/topic/com.arm.doc.ddi0375a/DDI0375A_arm1176jzf_dev_chip_r0p0_trm.pdf

I know it is confusingly named as a name of a SoC that has this CPU inside it but what can I do ... some guys named ARM came up with this.

Should use the string "arm,arm1176jzf-devchip-gic"?

Quoted 7 lines

arch/arm/boot/dts/arm-realview-pb1176.dts line 160

Quoted 4 lines

arch/arm/boot/dts/arm-realview-pb1176.dts new file +3 -0

+               /* This GIC on the board is cascaded off the DevChip GIC */
+               intc_pb1176: interrupt-controller at 10040000 {
+                       compatible = "arm,arm1176jzf-gic";

And this isn't part of the CPU, so that string doesn't look right. I'd at least like to see an additional string earlier in the list

This seems to be a follow-on to the above confusion.

Quoted 1 line · Linus Walleij

Should use the string "arm,arm1176jzf-devchip-gic"?

That sounds fine to me.

The document you've linked to says the GIC is derived from the MPCore GIC, so I'd place "arm,arm11mp-gic" as a fallback entry in the compatible list. Until we need to distinguish the two the driver shouldn't need to be updated.

Quoted 6 lines · Mark Rutland

Quoted 1 line · Linus Walleij

Should use the string "arm,arm1176jzf-devchip-gic"?

That sounds fine to me.

Quoted 4 lines

The document you've linked to says the GIC is derived from the MPCore GIC, so I'd place "arm,arm11mp-gic" as a fallback entry in the compatible list. Until we need to distinguish the two the driver shouldn't need to be updated.

Well the driver doesn't have a IRQCHIP_DECLARE() for arm11mp-gic either so I'll have to add that instead.