ARM: Kirkwood: Add DT description of QNAP 419
PATCH 1/1 ARM: Kirkwood: Add DT description of QNAP 419
Re-implement the Marvell Kirkwood ts41x-setup.c in DT.
As with the QNAP 119, there are two variants, depending on which SoC has been used. They differ on Ethernet PHY addresses and number of PCIe busses.
--- arch/arm/boot/dts/Makefile | 4 +- arch/arm/boot/dts/kirkwood-ts419-6281.dts | 20 ++++++++ arch/arm/boot/dts/kirkwood-ts419-6282.dts | 32 ++++++++++++ arch/arm/boot/dts/kirkwood-ts419.dtsi | 75 +++++++++++++++++++++++++++++ 4 files changed, 130 insertions(+), 1 deletion(-) create mode 100644 arch/arm/boot/dts/kirkwood-ts419-6281.dts create mode 100644 arch/arm/boot/dts/kirkwood-ts419-6282.dts create mode 100644 arch/arm/boot/dts/kirkwood-ts419.dtsi
arch/arm/boot/dts/Makefile +3 -1
@@ -104,7 +104,9 @@ dtb-$(CONFIG_ARCH_KIRKWOOD) += kirkwood-b3.dtb \ kirkwood-sheevaplug-esata.dtb \ kirkwood-topkick.dtb \ kirkwood-ts219-6281.dtb \ - kirkwood-ts219-6282.dtb + kirkwood-ts219-6282.dtb \ + kirkwood-ts419-6281.dtb \ + kirkwood-ts419-6282.dtb dtb-$(CONFIG_ARCH_MARCO) += marco-evb.dtb dtb-$(CONFIG_ARCH_MSM) += qcom-msm8660-surf.dtb \ qcom-msm8960-cdp.dtb
arch/arm/boot/dts/kirkwood-ts419-6281.dts new file +20 -0
@@ -0,0 +1,20 @@ +/* + * Device Tree file for QNAP TS41X with 6281 SoC + * + * Copyright (C) 2013, Andrew Lunn <[email protected]> + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * as published by the Free Software Foundation; either version + * 2 of the License, or (at your option) any later version. + */ + +/dts-v1/; + +#include "kirkwood.dtsi" +#include "kirkwood-6281.dtsi" +#include "kirkwood-ts219.dtsi" +#include "kirkwood-ts419.dtsi" + +ðphy0 { reg = <8>; }; +ðphy1 { reg = <0>; };
arch/arm/boot/dts/kirkwood-ts419-6282.dts new file +32 -0
@@ -0,0 +1,32 @@ +/* + * Device Tree file for QNAP TS41X with 6282 SoC + * + * Copyright (C) 2013, Andrew Lunn <[email protected]> + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * as published by the Free Software Foundation; either version + * 2 of the License, or (at your option) any later version. + */ + +/dts-v1/; + +#include "kirkwood.dtsi" +#include "kirkwood-6282.dtsi" +#include "kirkwood-ts219.dtsi" +#include "kirkwood-ts419.dtsi" + +/ { + mbus { + pcie-controller { + status = "okay"; + + pcie at 2,0 { + status = "okay"; + }; + }; + }; +}; + +ðphy0 { reg = <0>; }; +ðphy1 { reg = <1>; };
arch/arm/boot/dts/kirkwood-ts419.dtsi new file +75 -0
75 lines not on this page · raw message
Signature · 1 line
1.7.10.4
PATCH 1/1 ARM: Kirkwood: Add DT description of QNAP 419
Quoted 7 lines · Andrew Lunn
Re-implement the Marvell Kirkwood
ts41x-setup.cin DT.As with the QNAP 119, there are two variants, depending on which SoC has been used. They differ on Ethernet PHY addresses and number of PCIe busses.
Signed-off-by Andrew Lunn <[email protected]>
On the assumption that this is basically the same as the think you asked me to test last week:
What is the plan for the board files for the ts* platforms? Are they going to go away? This seems to have happened for the Sheevaplug case, which is causing some transition pain for distros (e.g.
http://bugs.debian.org/731345).
The big issue for the ts devices is that each board file seems to be splitting into two DTB files so in order to handle upgrades we need to be able to detect which of the two variants we need, both when running the previous board-file kernel and when running the DT version. Any advice? You previously pointed me to a string in the dmesg but this might not be reliable if the early boot messages have gone from the circular buffer and in any case I'm not sure how wise it is to rely on parsing those.
It looks like the board files determine things based on kirkwood_pcie_id() -- is the result of that available in userspace anywhere? I suppose counting the number of PCI buses would work, not a brilliant solution but given the need to work with board file kernels too maybe that's the best option.
The other issue I spotted is
that /dev/input/by-path/platform-gpio-keys-event has
become /dev/input/by-path/platform-gpio_keys.3-event. Is it considered valid for a by-path name to change? In particular the 3 here is apparently the node depth in the DTB, which doesn't make much logical sense as a "path" in this context I don't think (I expect it to be some sort of path through the hardware buses, perhaps my expectation is wrong?).
I may make the userspace tools (e.g. qcontrol) switch to listening on all input devices anyway (which realistically is mostly going to only be that one). Or is there some other stable input device naming scheme which should be implemented (perhaps on the udev side)?
Thanks,
Ian.
Quoted 170 lines
--- arch/arm/boot/dts/Makefile | 4 +- arch/arm/boot/dts/kirkwood-ts419-6281.dts | 20 ++++++++ arch/arm/boot/dts/kirkwood-ts419-6282.dts | 32 ++++++++++++ arch/arm/boot/dts/kirkwood-ts419.dtsi | 75 +++++++++++++++++++++++++++++ 4 files changed, 130 insertions(+), 1 deletion(-) create mode 100644 arch/arm/boot/dts/kirkwood-ts419-6281.dts create mode 100644 arch/arm/boot/dts/kirkwood-ts419-6282.dts create mode 100644 arch/arm/boot/dts/kirkwood-ts419.dtsiarch/arm/boot/dts/Makefile +3
-1@@ -104,7 +104,9 @@ dtb-$(CONFIG_ARCH_KIRKWOOD) += kirkwood-b3.dtb \ kirkwood-sheevaplug-esata.dtb \ kirkwood-topkick.dtb \ kirkwood-ts219-6281.dtb \ - kirkwood-ts219-6282.dtb + kirkwood-ts219-6282.dtb \ + kirkwood-ts419-6281.dtb \ + kirkwood-ts419-6282.dtb dtb-$(CONFIG_ARCH_MARCO) += marco-evb.dtb dtb-$(CONFIG_ARCH_MSM) += qcom-msm8660-surf.dtb \ qcom-msm8960-cdp.dtbarch/arm/boot/dts/kirkwood-ts419-6281.dts new file +20
-0@@ -0,0 +1,20 @@ +/* + * Device Tree file for QNAP TS41X with 6281 SoC + * + * Copyright (C) 2013, Andrew Lunn <[email protected]> + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * as published by the Free Software Foundation; either version + * 2 of the License, or (at your option) any later version. + */ + +/dts-v1/; + +#include "kirkwood.dtsi" +#include "kirkwood-6281.dtsi" +#include "kirkwood-ts219.dtsi" +#include "kirkwood-ts419.dtsi" + +ðphy0 { reg = <8>; }; +ðphy1 { reg = <0>; };arch/arm/boot/dts/kirkwood-ts419-6282.dts new file +32
-0@@ -0,0 +1,32 @@ +/* + * Device Tree file for QNAP TS41X with 6282 SoC + * + * Copyright (C) 2013, Andrew Lunn <[email protected]> + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * as published by the Free Software Foundation; either version + * 2 of the License, or (at your option) any later version. + */ + +/dts-v1/; + +#include "kirkwood.dtsi" +#include "kirkwood-6282.dtsi" +#include "kirkwood-ts219.dtsi" +#include "kirkwood-ts419.dtsi" + +/ { + mbus { + pcie-controller { + status = "okay"; + + pcie at 2,0 { + status = "okay"; + }; + }; + }; +}; + +ðphy0 { reg = <0>; }; +ðphy1 { reg = <1>; };arch/arm/boot/dts/kirkwood-ts419.dtsi new file +75
-0@@ -0,0 +1,75 @@ +/* + * Device Tree include file for QNAP TS41X + * + * Copyright (C) 2013, Andrew Lunn <[email protected]> + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * as published by the Free Software Foundation; either version + * 2 of the License, or (at your option) any later version. + */ + +/ { + model = "QNAP TS419 family"; + compatible = "qnap,ts419", "marvell,kirkwood"; + + ocp at f1000000 { + pinctrl: pinctrl at 10000 { + pinctrl-names = "default"; + + pmx_USB_copy_button: pmx-USB-copy-button { + marvell,pins = "mpp43"; + marvell,function = "gpio"; + }; + pmx_reset_button: pmx-reset-button { + marvell,pins = "mpp37"; + marvell,function = "gpio"; + }; + /* + * JP1 indicates if an LCD module is installed + * on the serial port (0), or if the port is used + * as a console (1). + */ + pmx_jumper_jp1: pmx-jumper_jp1 { + marvell,pins = "mpp45"; + marvell,function = "gpio"; + }; + + }; + }; + + gpio_keys { + compatible = "gpio-keys"; + #address-cells = <1>; + #size-cells = <0>; + pinctrl-0 = <&pmx_reset_button &pmx_USB_copy_button>; + pinctrl-names = "default"; + + button at 1 { + label = "USB Copy"; + linux,code = <KEY_COPY>; + gpios = <&gpio1 11 GPIO_ACTIVE_LOW>; + }; + button at 2 { + label = "Reset"; + linux,code = <KEY_RESTART>; + gpios = <&gpio1 5 GPIO_ACTIVE_LOW>; + }; + }; +}; + +&mdio { + status = "okay"; + + ethphy1: ethernet-phy at 1 { + device_type = "ethernet-phy"; + /* overwrite reg property in board file */ + }; +}; + +ð1 { + status = "okay"; + ethernet1-port at 0 { + phy-handle = <ðphy1>; + }; +};
PATCH 1/1 ARM: Kirkwood: Add DT description of QNAP 419
Quoted 7 lines · Ian Campbell
Quoted 6 lines · Andrew Lunn
Re-implement the Marvell Kirkwood
ts41x-setup.cin DT.As with the QNAP 119, there are two variants, depending on which SoC has been used. They differ on Ethernet PHY addresses and number of PCIe busses.
Quoted 5 lines
Quoted 1 line
Signed-off-by Andrew Lunn <[email protected]>On the assumption that this is basically the same as the think you asked me to test last week:
It is the same. Thanks for testing.
Quoted 4 lines
What is the plan for the board files for the ts* platforms? Are they going to go away? This seems to have happened for the Sheevaplug case, which is causing some transition pain for distros (e.g.
http://bugs.debian.org/731345).
We plan to make them go away. We are not quite there yet, there are still a couple of boards which don't have DT files. But we are working on those.
Quoted 9 lines
The big issue for the ts devices is that each board file seems to be splitting into two DTB files so in order to handle upgrades we need to be able to detect which of the two variants we need, both when running the previous board-file kernel and when running the DT version. Any advice? You previously pointed me to a string in the dmesg but this might not be reliable if the early boot messages have gone from the circular buffer and in any case I'm not sure how wise it is to rely on parsing those.
Quoted 5 lines
It looks like the board files determine things based on
kirkwood_pcie_id()-- is the result of that available in userspace anywhere? I suppose counting the number of PCI buses would work, not a brilliant solution but given the need to work with board file kernels too maybe that's the best option.
This is an issue, which has been discussed a bit recently while fixing an i2c issues on Marvell XP SoCs. As far as i know, there is no reliable export of the version field. It might be available from lspci, but so far i've not seen it. I will look into this in the next few days.
Quoted 8 lines
The other issue I spotted is
that/dev/input/by-path/platform-gpio-keys-eventhas
become/dev/input/by-path/platform-gpio_keys.3-event. Is it considered valid for a by-path name to change? In particular the 3 here is apparently the node depth in the DTB, which doesn't make much logical sense as a "path" in this context I don't think (I expect it to be some sort of path through the hardware buses, perhaps my expectation is wrong?).
To be honest, i've no idea about this. I hope somebody else will answer. If not, we might need to ask on the input mailing list.
Andrew
PATCH 1/1 ARM: Kirkwood: Add DT description of QNAP 419
In reply to Ian CampbellQuoted 1 line · Ian Campbell
On Mon, 2014-01-06 at 23:49 +0100, Andrew Lunn wrote:
Hi Ian
I added in the devicetree list and the input list and added my thoughts below.
Quoted 8 lines
The other issue I spotted is
that/dev/input/by-path/platform-gpio-keys-eventhas
become/dev/input/by-path/platform-gpio_keys.3-event. Is it considered valid for a by-path name to change? In particular the 3 here is apparently the node depth in the DTB, which doesn't make much logical sense as a "path" in this context I don't think (I expect it to be some sort of path through the hardware buses, perhaps my expectation is wrong?).
The ts41x-setup.c board file creates the gpio keys platform device using the following structure:
static struct platform_device qnap_ts41x_button_device = {
.name = "gpio-keys",
.id = -1,
.num_resources = 0,
.dev = { .platform_data = &qnap_ts41x_button_data,
}
};
The id of -1 causes platform_device_add() to set the device name to plain "gpio-keys".
When using DT, the device name is created by the function of_device_make_bus_id(). It has the following comment:
* This routine will first try using either the dcr-reg or the reg property
* value to derive a unique name. As a last resort it will use the node
* name followed by a unique number.
Since the gpio_keys node does not have a reg properties, it gets a unique number appended to it. We end up with the device name "gpio_keys.3"
So as it stands, it does not appear i can make the DT system use the same device name as a board system.
But i'm also a little bit concerned by the "unique number" and this ending up in /dev/input/by-path/platform-gpio_keys.3-event. Is this path supposed to be stable? This unique number is not stable. An unwitting change to the DT could cause its value to change. Do we need to make it stable?
Andrew
Arnd Bergmann
maintainerPATCH 1/1 ARM: Kirkwood: Add DT description of QNAP 419
Quoted 14 lines · Andrew Lunn
The id of -1 causes
platform_device_add()to set the device name to plain "gpio-keys".When using DT, the device name is created by the function
of_device_make_bus_id(). It has the following comment:* This routine will first try using either the dcr-reg or the reg property
* value to derive a unique name. As a last resort it will use the node
* name followed by a unique number.Since the
gpio_keysnode does not have a reg properties, it gets a unique number appended to it. We end up with the device name "gpio_keys.3"
Quoted 9 lines
So as it stands, it does not appear i can make the DT system use the same device name as a board system.
But i'm also a little bit concerned by the "unique number" and this ending up in
/dev/input/by-path/platform-gpio_keys.3-event. Is this path supposed to be stable? This unique number is not stable. An unwitting change to the DT could cause its value to change. Do we need to make it stable?
One possibility would be to create an artificial bus in DT for all gpio-keys devices, use #address-cells=<1> and #size-cells=<0> for it, and give each device a unique reg property. Not sure if that would be considered an elegant solution though.
Arnd
PATCH 1/1 ARM: Kirkwood: Add DT description of QNAP 419
Quoted 11 lines
Quoted 6 lines
But i'm also a little bit concerned by the "unique number" and this ending up in
/dev/input/by-path/platform-gpio_keys.3-event. Is this path supposed to be stable? This unique number is not stable. An unwitting change to the DT could cause its value to change. Do we need to make it stable?One possibility would be to create an artificial bus in DT for all gpio-keys devices, use #address-cells=<1> and #size-cells=<0> for it, and give each device a unique reg property. Not sure if that would be considered an elegant solution though.
Hi Arnd
Can i imply from your answer that you think
/dev/input/by-path/platform-gpio_keys.3-event
should be stable?
A quick look at udev rules seems to suggestion this is an issue for input/gpio-keys and maybe audio and video if there is a top level DT property collecting the different sub devices together for ASOC and V4L.
Thanks
Andrew
Arnd Bergmann
maintainerPATCH 1/1 ARM: Kirkwood: Add DT description of QNAP 419
Quoted 12 lines · On Wednesday 15 January 2014 18:45:19 Andrew Lunn wrote:
Quoted 11 lines
Quoted 6 lines
But i'm also a little bit concerned by the "unique number" and this ending up in
/dev/input/by-path/platform-gpio_keys.3-event. Is this path supposed to be stable? This unique number is not stable. An unwitting change to the DT could cause its value to change. Do we need to make it stable?One possibility would be to create an artificial bus in DT for all gpio-keys devices, use #address-cells=<1> and #size-cells=<0> for it, and give each device a unique reg property. Not sure if that would be considered an elegant solution though.
Quoted 7 lines
Hi Arnd
Can i imply from your answer that you think
/dev/input/by-path/platform-gpio_keys.3-eventshould be stable?
No, I have no idea whether it should be or not. I was just trying to come up with a way to make it stable if that's desired.
Quoted 4 lines
A quick look at udev rules seems to suggestion this is an issue for input/gpio-keys and maybe audio and video if there is a top level DT property collecting the different sub devices together for ASOC and V4L.
For some other subsystems, we have entries in /aliases/ to sort them. Maybe that would work here to get a stable path independent of the location in DT.
Arnd
PATCH 1/1 ARM: Kirkwood: Add DT description of QNAP 419
In reply to Ian CampbellIan,
Quoted 4 lines · Ian Campbell
What is the plan for the board files for the ts* platforms? Are they going to go away? This seems to have happened for the Sheevaplug case, which is causing some transition pain for distros (e.g.
http://bugs.debian.org/731345).
Sorry, I'm rather swamped at the moment. From my cursory reading of the thread, is it correct to say that this problem can be solved by enabling the CONFIG_MACH_SHEEVAPLUG_DT config option?
thx,
Jason.
PATCH 1/1 ARM: Kirkwood: Add DT description of QNAP 419
Quoted 11 lines · Jason Cooper
Ian,
Quoted 4 lines · Ian Campbell
What is the plan for the board files for the ts* platforms? Are they going to go away? This seems to have happened for the Sheevaplug case, which is causing some transition pain for distros (e.g.
http://bugs.debian.org/731345).Sorry, I'm rather swamped at the moment. From my cursory reading of the thread, is it correct to say that this problem can be solved by enabling the
CONFIG_MACH_SHEEVAPLUG_DTconfig option?
That would have allows 3.11 to boot with DT, but for 3.11 we are OK with the board file support from a Debian PoV
The real issue is the transition of the userspace components which configure the bootloader (called "flash-kernel" in Debian) which needs to know whether or not a DTB should be appended. I think we've now mostly solved that by teaching flash-kernel what the minimum kernel version which requires a DTB is (see [0] and [1]), I've set this to 3.12 for Sheevaplug and Guruplug, I'll set it to whatever is appropriate on the ts* platforms when the time comes.
Ian.
[0] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=731345http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=731345
[1] http://anonscm.debian.org/gitweb/?p=d-i/flash-kernel.git;a=commit;h=f656a00daa4d1ada46203e6e1831ae574eb005f8
PATCH 1/1 ARM: Kirkwood: Add DT description of QNAP 419
In reply to Andrew LunnQuoted 7 lines · Andrew Lunn
Re-implement the Marvell Kirkwood
ts41x-setup.cin DT.As with the QNAP 119, there are two variants, depending on which SoC has been used. They differ on Ethernet PHY addresses and number of PCIe busses.
Signed-off-by Andrew Lunn <[email protected]>
Quoted 9 lines
--- arch/arm/boot/dts/Makefile | 4 +- arch/arm/boot/dts/kirkwood-ts419-6281.dts | 20 ++++++++ arch/arm/boot/dts/kirkwood-ts419-6282.dts | 32 ++++++++++++ arch/arm/boot/dts/kirkwood-ts419.dtsi | 75 +++++++++++++++++++++++++++++ 4 files changed, 130 insertions(+), 1 deletion(-) create mode 100644 arch/arm/boot/dts/kirkwood-ts419-6281.dts create mode 100644 arch/arm/boot/dts/kirkwood-ts419-6282.dts create mode 100644 arch/arm/boot/dts/kirkwood-ts419.dtsi
Applied to mvebu/dt with Ian's Tested-by
thx,
Jason.
PATCH 1/1 ARM: Kirkwood: Add DT description of QNAP 419
Quoted 18 lines · Jason Cooper
Quoted 7 lines · Andrew Lunn
Re-implement the Marvell Kirkwood
ts41x-setup.cin DT.As with the QNAP 119, there are two variants, depending on which SoC has been used. They differ on Ethernet PHY addresses and number of PCIe busses.
Signed-off-by Andrew Lunn <[email protected]>Quoted 9 lines
--- arch/arm/boot/dts/Makefile | 4 +- arch/arm/boot/dts/kirkwood-ts419-6281.dts | 20 ++++++++ arch/arm/boot/dts/kirkwood-ts419-6282.dts | 32 ++++++++++++ arch/arm/boot/dts/kirkwood-ts419.dtsi | 75 +++++++++++++++++++++++++++++ 4 files changed, 130 insertions(+), 1 deletion(-) create mode 100644 arch/arm/boot/dts/kirkwood-ts419-6281.dts create mode 100644 arch/arm/boot/dts/kirkwood-ts419-6282.dts create mode 100644 arch/arm/boot/dts/kirkwood-ts419.dtsi
Quoted 1 line
Applied to mvebu/dt with Ian's Tested-by
Hi Jason
Thanks, but please could you hold onto it for a while. I would like to see how the discussion about unstable /dev/input/by-path discussion plays out. That is if anybody actually replies to my question...
Thanks
Andrew
PATCH 1/1 ARM: Kirkwood: Add DT description of QNAP 419
Quoted 19 lines · Andrew Lunn
Quoted 18 lines · Jason Cooper
Quoted 16 lines · Andrew Lunn
Re-implement the Marvell Kirkwood
ts41x-setup.cin DT.As with the QNAP 119, there are two variants, depending on which SoC has been used. They differ on Ethernet PHY addresses and number of PCIe busses.
Signed-off-by Andrew Lunn <[email protected]>--- arch/arm/boot/dts/Makefile | 4 +- arch/arm/boot/dts/kirkwood-ts419-6281.dts | 20 ++++++++ arch/arm/boot/dts/kirkwood-ts419-6282.dts | 32 ++++++++++++ arch/arm/boot/dts/kirkwood-ts419.dtsi | 75 +++++++++++++++++++++++++++++ 4 files changed, 130 insertions(+), 1 deletion(-) create mode 100644 arch/arm/boot/dts/kirkwood-ts419-6281.dts create mode 100644 arch/arm/boot/dts/kirkwood-ts419-6282.dts create mode 100644 arch/arm/boot/dts/kirkwood-ts419.dtsi
Quoted 7 lines
Quoted 1 line
Applied to mvebu/dt with Ian's Tested-by
Hi Jason
Thanks, but please could you hold onto it for a while. I would like to see how the discussion about unstable
/dev/input/by-pathdiscussion plays out. That is if anybody actually replies to my question...
Ok, this and the Bubba board are probably for next cycle at this point anyhow. I'll send pulls for the fixes sometime today.
thx,
Jason.