From: arnd@arndb.de (Arnd Bergmann)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 2/4] arm64, thunder: Add initial dts for Cavium Thunder SoC
Date: Fri, 05 Sep 2014 13:21:48 +0200 [thread overview]
Message-ID: <5017180.kZRPNE71Sv@wuerfel> (raw)
In-Reply-To: <1409903205-2762-3-git-send-email-rric@kernel.org>
On Friday 05 September 2014 09:46:43 Robert Richter wrote:
> diff --git a/arch/arm64/boot/dts/thunder-88xx.dts b/arch/arm64/boot/dts/thunder-88xx.dts
> new file mode 100644
> index 000000000000..4cc1d059d2d9
> --- /dev/null
> +++ b/arch/arm64/boot/dts/thunder-88xx.dts
Most people end up having a soc.dtsi file and a board.dsi file including
the former and adding the machine-specific properties.
It is likely that you will end up needing the same, so you might want to
start that way.
> +/ {
> + model = "Cavium ThunderX CN88XX Family";
> + compatible = "cavium,thunder-88xx";
As mentioned by Mark already, you should not include 'xx' in the
compatible string, but instead use the real soc ID.
Normally, each SoC has some slight differences anyway, so you would
override these in the specialized dtsi file.
The "model" property should go into the board specific file.
> + interrupt-parent = <&gic0>;
> + #address-cells = <2>;
> + #size-cells = <2>;
> +
> + aliases {
> + serial0 = &uaa0;
> + serial1 = &uaa1;
> + };
> +
> + psci {
> + compatible = "arm,psci-0.2";
> + method = "smc";
> + };
The aliases node should go into the board file as well, since it's
possible that e.g. the first uart is not connected and you need
something like
aliases {
serial0 = &uaa1;
};
The psci node (according to a discussion we just had for the freescale
dts files) should ideally get filled out by the boot loader that
implements the psci code, to ensure the version matches.
> +
> + memory at 00000000 {
> + device_type = "memory";
> + reg = <0x0 0x00000000 0x0 0x80000000>;
> + };
memory should also go into the board specific file, or get filled by
the boot loader if it is detected at boot time and user serviceable.
I assume that your machines have NUMA properties, in that case it
makes sense to split up the memory device nodes by topology. I think
there are some standard properties to describe the topology further,
but I don't remember how it's done at the moment.
> + soc {
> + compatible = "simple-bus";
> + #address-cells = <2>;
> + #size-cells = <2>;
> + ranges;
> +
> + refclk50mhz: refclk50mhz {
> + compatible = "fixed-clock";
> + #clock-cells = <0>;
> + clock-frequency = <50000000>;
> + clock-output-names = "refclk50mhz";
> + };
If the reference clock is generated outside of the SoC, I would put the device
node for it on the top level.
Arnd
next prev parent reply other threads:[~2014-09-05 11:21 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-05 7:46 [PATCH v2 0/4] arm64, thunder: Enable Cavium Thunder SoC Family Robert Richter
2014-09-05 7:46 ` [PATCH v2 1/4] arm64, thunder: Add Kconfig option for " Robert Richter
2014-09-05 8:39 ` Will Deacon
2014-09-05 9:21 ` Robert Richter
2014-09-05 9:25 ` Will Deacon
2014-09-05 9:36 ` Mark Rutland
2014-09-05 10:51 ` Robert Richter
2014-09-05 9:32 ` Russell King - ARM Linux
2014-09-05 10:45 ` Robert Richter
2014-09-05 11:05 ` Russell King - ARM Linux
2014-09-05 12:51 ` Mark Rutland
2014-09-05 14:04 ` Arnd Bergmann
2014-09-05 14:22 ` Mark Rutland
2014-09-05 16:25 ` Arnd Bergmann
2014-09-08 11:01 ` Robert Richter
2014-09-08 12:29 ` Arnd Bergmann
2014-09-08 18:25 ` Rob Herring
2014-09-05 7:46 ` [PATCH v2 2/4] arm64, thunder: Add initial dts for Cavium Thunder SoC Robert Richter
2014-09-05 11:21 ` Arnd Bergmann [this message]
2014-09-11 14:51 ` Robert Richter
2014-09-05 7:46 ` [PATCH v2 3/4] arm64, thunder: Document devicetree bindings " Robert Richter
2014-09-05 8:42 ` Will Deacon
2014-09-05 9:32 ` Robert Richter
2014-09-05 9:39 ` Mark Rutland
2014-09-08 7:54 ` Robert Richter
2014-09-05 7:46 ` [PATCH v2 4/4] arm64, defconfig: Enable Cavium Thunder SoC in defconfig Robert Richter
2014-09-05 8:42 ` [PATCH v2 0/4] arm64, thunder: Enable Cavium Thunder SoC Family Will Deacon
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=5017180.kZRPNE71Sv@wuerfel \
--to=arnd@arndb.de \
--cc=linux-arm-kernel@lists.infradead.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).