From: David Gibson <david@gibson.dropbear.id.au>
To: David Daney <ddaney@caviumnetworks.com>
Cc: linux-mips@linux-mips.org, ralf@linux-mips.org,
devicetree-discuss@lists.ozlabs.org, grant.likely@secretlab.ca,
linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH 02/10] MIPS: Octeon: Add device tree source files.
Date: Wed, 23 Feb 2011 11:07:59 +1100 [thread overview]
Message-ID: <20110223000759.GA26300@yookeroo> (raw)
In-Reply-To: <1298408274-20856-3-git-send-email-ddaney@caviumnetworks.com>
On Tue, Feb 22, 2011 at 12:57:46PM -0800, David Daney wrote:
> Signed-off-by: David Daney <ddaney@caviumnetworks.com>
> ---
> arch/mips/cavium-octeon/.gitignore | 2 +
> arch/mips/cavium-octeon/Makefile | 13 ++
> arch/mips/cavium-octeon/octeon_3xxx.dts | 314 +++++++++++++++++++++++++++++++
> arch/mips/cavium-octeon/octeon_68xx.dts | 99 ++++++++++
> 4 files changed, 428 insertions(+), 0 deletions(-)
> create mode 100644 arch/mips/cavium-octeon/.gitignore
> create mode 100644 arch/mips/cavium-octeon/octeon_3xxx.dts
> create mode 100644 arch/mips/cavium-octeon/octeon_68xx.dts
>
> diff --git a/arch/mips/cavium-octeon/.gitignore b/arch/mips/cavium-octeon/.gitignore
> new file mode 100644
> index 0000000..39c9686
> --- /dev/null
> +++ b/arch/mips/cavium-octeon/.gitignore
> @@ -0,0 +1,2 @@
> +*.dtb.S
.dtb.S?
[snip]
> +/dts-v1/;
> +/* OCTEON 3XXX, 5XXX, 63XX device tree skeleton. */
> +/ {
> + model = "OCTEON";
1 tab indents are the usual convention for device trees.
> + compatible = "octeon,octeon";
There's no model number at all for this board?
> + #address-cells = <2>;
> + #size-cells = <2>;
> +
> + soc@0 {
> + device_type = "soc";
Drop this device_type.
> + compatible = "simple-bus";
> + #address-cells = <2>;
> + #size-cells = <2>;
> + ranges; /* Direct mapping */
> +
> + ciu: ciu-3xxx@1070000000000 {
> + compatible = "octeon,ciu-3xxx";
So, names or compatible values with "wildcards" like 3xxx should be
avoided. Instead, use the specific model number of this device, then
future devices can claim compatibility with the earlier one.
But, in addition the generic names convention means that the node name
should be "interrupt-controller" rather than something model specific.
> + interrupt-controller;
> + #address-cells = <0>;
> + #interrupt-cells = <2>;
> + reg = <0x10700 0x00000000 0x0 0x7000>;
> + };
> +
> + /* SMI0 */
> + mdio0: mdio@1180000001800 {
If SMI0 is the name generally used in the documentation, using that in
the label instead of mdio0 might be more useful.
> + compatible = "octeon,mdio";
No model or revision number?
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0x11800 0x00001800 0x0 0x40>;
> + device_type = "mdio";
Drop this device_type.
> +
> + phy0: ethernet-phy@0 {
> + reg = <0>;
> + };
> +
> + phy1: ethernet-phy@1 {
> + reg = <1>;
> + };
> +
> + phy2: ethernet-phy@2 {
> + reg = <2>;
> + marvell,reg-init = <3 0x10 0 0x5777>,
> + <3 0x11 0 0x00aa>,
> + <3 0x12 0 0x4105>,
> + <3 0x13 0 0x0a60>;
> + };
> + phy3: ethernet-phy@3 {
> + reg = <3>;
> + marvell,reg-init = <3 0x10 0 0x5777>,
> + <3 0x11 0 0x00aa>,
> + <3 0x12 0 0x4105>,
> + <3 0x13 0 0x0a60>;
> + };
> + phy4: ethernet-phy@4 {
> + reg = <4>;
> + marvell,reg-init = <3 0x10 0 0x5777>,
> + <3 0x11 0 0x00aa>,
> + <3 0x12 0 0x4105>,
> + <3 0x13 0 0x0a60>;
> + };
> + phy5: ethernet-phy@5 {
> + reg = <5>;
> + marvell,reg-init = <3 0x10 0 0x5777>,
> + <3 0x11 0 0x00aa>,
> + <3 0x12 0 0x4105>,
> + <3 0x13 0 0x0a60>;
> + };
> +
> + phy6: ethernet-phy@6 {
> + reg = <6>;
> + marvell,reg-init = <3 0x10 0 0x5777>,
> + <3 0x11 0 0x00aa>,
> + <3 0x12 0 0x4105>,
> + <3 0x13 0 0x0a60>;
> + };
> + phy7: ethernet-phy@7 {
> + reg = <7>;
> + marvell,reg-init = <3 0x10 0 0x5777>,
> + <3 0x11 0 0x00aa>,
> + <3 0x12 0 0x4105>,
> + <3 0x13 0 0x0a60>;
> + };
> + phy8: ethernet-phy@8 {
> + reg = <8>;
> + marvell,reg-init = <3 0x10 0 0x5777>,
> + <3 0x11 0 0x00aa>,
> + <3 0x12 0 0x4105>,
> + <3 0x13 0 0x0a60>;
> + };
> + phy9: ethernet-phy@9 {
> + reg = <9>;
> + marvell,reg-init = <3 0x10 0 0x5777>,
> + <3 0x11 0 0x00aa>,
> + <3 0x12 0 0x4105>,
> + <3 0x13 0 0x0a60>;
> + };
> + };
> +
> + /* SMI1 */
> + mdio1: mdio@1180000001900 {
> + compatible = "octeon,mdio";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0x11800 0x00001900 0x0 0x40>;
> + device_type = "mdio";
> + };
> +
> + mgmt0: ethernet@1070000100000 {
> + compatible = "octeon,mgmt";
> + device_type = "network";
> + model = "mgmt";
> + reg = <0x10700 0x00100000 0x0 0x100>, /* MIX */
> + <0x11800 0xE0000000 0x0 0x300>, /* AGL */
> + <0x11800 0xE0000400 0x0 0x400>, /* AGL_SHARED */
> + <0x11800 0xE0002000 0x0 0x8>; /* AGL_PRT_CTL */
> + unit-number = <0>;
What is this 'unit-number' property for?
> + interrupt-parent = <&ciu>;
> + interrupts = <0 62>, <1 46>;
> + local-mac-address = [ 00 00 00 00 00 00 ];
That's not a valid MAC address of course. If this has to be patched
in by the bootloader / later processing, you should add a comment to
that effect.
> + phy-handle = <&phy0>;
> + };
> +
> + mgmt1: ethernet@1070000100800 {
> + compatible = "octeon,mgmt";
> + device_type = "network";
> + model = "mgmt";
> + reg = <0x10700 0x00100800 0x0 0x100>, /* MIX */
> + <0x11800 0xE0000800 0x0 0x300>, /* AGL */
> + <0x11800 0xE0000400 0x0 0x400>, /* AGL_SHARED */
> + <0x11800 0xE0002008 0x0 0x8>; /* AGL_PRT_CTL */
> + unit-number = <1>;
> + interrupt-parent = <&ciu>;
> + interrupts = <1 18>, < 1 46>;
> + local-mac-address = [ 00 00 00 00 00 00 ];
> + phy-handle = <&phy1>;
> + };
> +
> + pip: pip@11800a0000000 {
> + compatible = "octeon,pip";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0x11800 0xa0000000 0x0 0x2000>;
> +
> + interface@0 {
These subnodes and subsubnodes should have compatible values too, even
if it's just "octeon,pip-interface" and "octeon,pip-ethernet".
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0>; /* interface */
> +
> + ethernet@0 {
> + device_type = "network";
> + model = "pip";
This model property doesn't look very useful.
[snip]
> + /* TWSI 0 */
> + i2c0: i2c@1180000001000 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + compatible = "octeon,twsi";
> + reg = <0x11800 0x00001000 0x0 0x200>;
> + interrupt-parent = <&ciu>;
> + interrupts = <0 45>;
> + clock-rate = <100000>;
> +
> + rtc@68 {
> + compatible = "dallas,ds1337";
> + reg = <0x68>;
> + };
> + };
> +
> + /* TWSI 1 */
> + i2c1: i2c@1180000001200 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + compatible = "octeon,twsi";
> + reg = <0x11800 0x00001200 0x0 0x200>;
> + interrupt-parent = <&ciu>;
> + interrupts = <0 59>;
> + clock-rate = <100000>;
> + };
> + };
Uh.. where are the CPUs?
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
next prev parent reply other threads:[~2011-02-23 0:36 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-02-22 20:57 [RFC PATCH 00/10] MIPS: Octeon: Use Device Tree David Daney
2011-02-22 20:57 ` [RFC PATCH 01/10] MIPS: Octeon: Move some Ethernet support files out of staging David Daney
2011-02-23 14:48 ` Grant Likely
2011-02-23 17:36 ` David Daney
2011-02-22 20:57 ` [RFC PATCH 02/10] MIPS: Octeon: Add device tree source files David Daney
2011-02-23 0:07 ` David Gibson [this message]
2011-02-23 14:30 ` Ralf Baechle
2011-02-23 16:59 ` David Daney
2011-02-24 23:19 ` David Gibson
2011-02-25 15:22 ` Grant Likely
2011-02-25 21:46 ` Benjamin Herrenschmidt
2011-02-23 19:06 ` David Daney
2011-02-23 23:49 ` David Gibson
2011-02-24 1:57 ` David Daney
2011-02-24 2:14 ` David Gibson
2011-02-24 2:22 ` David Daney
2011-02-22 20:57 ` [RFC PATCH 03/10] MIPS: Prune some target specific code out of prom.c David Daney
2011-02-22 20:57 ` [RFC PATCH 04/10] MIPS: Octeon: Add a irq_create_of_mapping() implementation David Daney
2011-02-22 20:57 ` [RFC PATCH 05/10] MIPS: Octeon: Rearrance CVMX files in preperation for device tree David Daney
2011-02-22 20:57 ` [RFC PATCH 06/10] MIPS: Octeon: Initialize and fixup " David Daney
2011-02-23 0:16 ` David Gibson
2011-02-23 17:41 ` Grant Likely
2011-02-23 18:40 ` David Daney
2011-02-23 18:51 ` Grant Likely
2011-02-23 19:20 ` David Daney
2011-02-22 20:57 ` [RFC PATCH 07/10] i2c: Convert i2c-octeon.c to use " David Daney
2011-02-23 16:25 ` Grant Likely
2011-02-22 20:57 ` [RFC PATCH 08/10] netdev: mdio-octeon.c: Convert " David Daney
2011-02-22 20:57 ` [RFC PATCH 09/10] netdev: octeon_mgmt: " David Daney
2011-02-23 16:32 ` Grant Likely
2011-02-23 20:33 ` David Miller
2011-02-22 20:57 ` [RFC PATCH 10/10] staging: octeon_ethernet: " David Daney
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=20110223000759.GA26300@yookeroo \
--to=david@gibson.dropbear.id.au \
--cc=ddaney@caviumnetworks.com \
--cc=devicetree-discuss@lists.ozlabs.org \
--cc=grant.likely@secretlab.ca \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mips@linux-mips.org \
--cc=ralf@linux-mips.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