devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

  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).