From: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>
To: Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Cc: "linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org"
<linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>,
"devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>,
Pawel Moll <Pawel.Moll-5wv7dgnIgG8@public.gmane.org>,
Marc Zyngier <Marc.Zyngier-5wv7dgnIgG8@public.gmane.org>,
Will Deacon <Will.Deacon-5wv7dgnIgG8@public.gmane.org>,
Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Subject: Re: [PATCH 6/6 v4] ARM: realview: basic device tree implementation
Date: Fri, 25 Jul 2014 16:24:02 +0100 [thread overview]
Message-ID: <20140725152401.GA21830@leverpostej> (raw)
In-Reply-To: <1406294628-16079-7-git-send-email-linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Hi Linus,
On Fri, Jul 25, 2014 at 02:23:48PM +0100, Linus Walleij wrote:
> 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 <arnd-r2nGTMty4D4@public.gmane.org>
> Cc: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> Acked-by: Jason Cooper <jason-NLaQJdtUoK4Be96aLqz0jA@public.gmane.org>
> Signed-off-by: Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> ---
> 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@0x12345678 to serial@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
>
> diff --git a/Documentation/devicetree/bindings/arm/arm-boards b/Documentation/devicetree/bindings/arm/arm-boards
> index 3509707f9320..d2399e6f1378 100644
> --- a/Documentation/devicetree/bindings/arm/arm-boards
> +++ b/Documentation/devicetree/bindings/arm/arm-boards
> @@ -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";
> +
> +Required nodes:
> +
> +- soc: some node of the RealView platforms must be the SoC
> + node that contain the SoC-specific devices, withe the compatible
> + string set to one of these tuples:
> + "simple-bus", "arm,realview-eb-soc"
> + "simple-bus", "arm,realview-pb1176-soc"
> + "simple-bus", "arm,realview-pb11mp-soc"
> + "simple-bus", "arm,realview-pba8-soc"
> + "simple-bus", "arm,realview-pbx-soc"
If you have simple-bus in a compatible list, it should come last. The
list is meant to go from most specific to least specific.
That'll need to be swapped in the example and dts too.
[...]
> + soc {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + compatible = "simple-bus", "arm,realview-pb1176-soc";
> + regmap = <&syscon>;
> + ranges;
> +
> + syscon: syscon@10000000 {
> + compatible = "arm,realview-pb1176-syscon", "syscon";
> + reg = <0x10000000 0x1000>;
> + };
> +
> + reboot: reboot@0x40 {
> + compatible = "arm,realview-pb1176-reboot";
> + regmap = <&syscon>;
> + };
What's the @0x40 for?
Why don't we just have a property on the arm,realview-pb1176-syscon node
to say it can do reset (or just assume that it can)?
This looks like a leak of Linux internals, this isn't really a device.
[...]
> + /* Primary DevChip GIC synthesized with the CPU */
> + intc_dc1176: interrupt-controller@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").
> + #interrupt-cells = <3>;
> + #address-cells = <1>;
> + interrupt-controller;
> + reg = <0x10121000 0x1000>,
> + <0x10120000 0x100>;
> + };
> +
> + /* This GIC on the board is cascaded off the DevChip GIC */
> + intc_pb1176: interrupt-controller@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
> + #interrupt-cells = <3>;
> + #address-cells = <1>;
> + interrupt-controller;
> + reg = <0x10041000 0x1000>,
> + <0x10040000 0x100>;
> + interrupt-parent = <&intc_dc1176>;
> + interrupts = <0 31 IRQ_TYPE_LEVEL_HIGH>;
> + };
[...]
> +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
> + * 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?
> +DT_MACHINE_START(REALVIEW_DT, "ARM RealView Machine (Device Tree Support)")
As a general point, we seem to have so many different ways of formatting
this, and we should standardise.
Thanks,
Mark.
--
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
next prev parent reply other threads:[~2014-07-25 15:24 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-25 13:23 [PATCH 0/6] ARM RealView DeviceTree support v4 Linus Walleij
[not found] ` <1406294628-16079-1-git-send-email-linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2014-07-25 13:23 ` [PATCH 1/6] leds: add a driver for syscon-based LEDs Linus Walleij
[not found] ` <1406294628-16079-2-git-send-email-linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2014-08-13 9:14 ` Linus Walleij
2014-07-25 13:23 ` [PATCH 2/6] leds: add device tree bindings for syscon LEDs Linus Walleij
[not found] ` <1406294628-16079-3-git-send-email-linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2014-07-25 14:07 ` Rob Herring
[not found] ` <CAL_Jsq+-G68wjBLDbELHRDFcGYRa65-Hx9WoD6HypXNjJKVDvA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-08-13 9:31 ` Linus Walleij
2014-07-25 13:23 ` [PATCH 3/6] power: reset: driver for the Versatile syscon reboot Linus Walleij
2014-07-25 13:23 ` [PATCH 4/6] power: reset: DT bindings for the Versatile reset driver Linus Walleij
2014-07-25 13:23 ` [PATCH 5/6] soc: add driver for the ARM RealView Linus Walleij
2014-07-25 13:23 ` [PATCH 6/6 v4] ARM: realview: basic device tree implementation Linus Walleij
[not found] ` <1406294628-16079-7-git-send-email-linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2014-07-25 15:24 ` Mark Rutland [this message]
2014-07-25 15:50 ` Russell King - ARM Linux
[not found] ` <20140725155010.GP21766-l+eeeJia6m9vn6HldHNs0ANdhmdF6hFW@public.gmane.org>
2014-07-25 15:58 ` Arnd Bergmann
2014-09-01 12:03 ` Russell King - ARM Linux
[not found] ` <20140901120313.GI30401-l+eeeJia6m9vn6HldHNs0ANdhmdF6hFW@public.gmane.org>
2014-09-01 12:11 ` Arnd Bergmann
2014-09-01 11:52 ` Linus Walleij
[not found] ` <CACRpkdaugAmVt5CF194xd+eVyz=Yfir6Jz0k9h4VSvSWLkKPRQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-09-01 12:17 ` Mark Rutland
2014-09-01 12:27 ` Linus Walleij
[not found] ` <CACRpkdYoqhiLqVMqrrUxZEq-c63NuDT--FVWs3j_5b1BC24FeA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-09-01 12:44 ` Mark Rutland
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140725152401.GA21830@leverpostej \
--to=mark.rutland-5wv7dgnigg8@public.gmane.org \
--cc=Marc.Zyngier-5wv7dgnIgG8@public.gmane.org \
--cc=Pawel.Moll-5wv7dgnIgG8@public.gmane.org \
--cc=Will.Deacon-5wv7dgnIgG8@public.gmane.org \
--cc=arnd-r2nGTMty4D4@public.gmane.org \
--cc=devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \
--cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
--cc=robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).