SolidRun Hummingboard/Cubox-i DT updates
Subsystems (3)
cover SolidRun Hummingboard/Cubox-i DT updates
Here's a set of patches updating the Cubox-i/Hummingboard DT files.
The first two are fairly important fixes, so should at least go in for -rc kernels.
The SPDIF patch is something which could go in -rc as well as it's a cosmetic patch, changing the name displayed in (eg) pulseaudio for the SPDIF output from the developer-centric "imx-spdif" to "Integrated SPDIF".
Patch 4 updates the Hummingboard support as SolidRun now have a Dual version of this platform, which needs imx6q.dtsi instead of imx6dl.dtsi, and also has mSATA support.
Patch 5 adds the mSATA support for the Dual version of the Hummingboard.
Patch 6 is the first patch which breaks something on the initial version of the Hummingboard, aka Carrier1, specifically the IrDA receiver. In hindsight, we should not have used the name "Hummingboard" for the Carrier1. The Carrier1 is obsolete, and people are being encouraged to dispose of the C1 hardware.
Out of these, I think it would be worth getting the first five patches in for 3.17 (even though we're in -rc), but patch 6 should certainly wait for the next merge window.
Signature · 2 lines
FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up according to speedtest.net.
PATCH 1/6 ARM: dts: microsom-ar8035: MDIO pad must be set open drain
From: Rabeeh Khoury <[email protected]>
To: Shawn Guo <[email protected]>
MDIO pad must be set open drain.
--- arch/arm/boot/dts/imx6qdl-microsom-ar8035.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/arm/boot/dts/imx6qdl-microsom-ar8035.dtsi +1 -1
@@ -17,7 +17,7 @@ enet { pinctrl_microsom_enet_ar8035: microsom-enet-ar8035 { fsl,pins = < - MX6QDL_PAD_ENET_MDIO__ENET_MDIO 0x1b0b0 + MX6QDL_PAD_ENET_MDIO__ENET_MDIO 0x1b8b0 MX6QDL_PAD_ENET_MDC__ENET_MDC 0x1b0b0 /* AR8035 reset */ MX6QDL_PAD_KEY_ROW4__GPIO4_IO15 0x130b0
Signature · 1 line
1.8.3.1
PATCH 1/6 ARM: dts: microsom-ar8035: MDIO pad must be set open drain
Quoted 17 lines · Russell King
From: Rabeeh Khoury <[email protected]>
To: Shawn Guo <[email protected]>MDIO pad must be set open drain.
Signed-off-by Rabeeh Khoury <[email protected]>Signed-off-by Russell King <[email protected]>--- arch/arm/boot/dts/imx6qdl-microsom-ar8035.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)arch/arm/boot/dts/imx6qdl-microsom-ar8035.dtsi +0
-0
arch/arm/boot/dts/imx6qdl-microsom-ar8035.dtsi line 23
Quoted 8 lines
arch/arm/boot/dts/imx6qdl-microsom-ar8035.dtsi +1
-1@@ -17,7 +17,7 @@ enet { pinctrl_microsom_enet_ar8035: microsom-enet-ar8035 { fsl,pins = < - MX6QDL_PAD_ENET_MDIO__ENET_MDIO 0x1b0b0 + MX6QDL_PAD_ENET_MDIO__ENET_MDIO 0x1b8b0 MX6QDL_PAD_ENET_MDC__ENET_MDC 0x1b0b0 /* AR8035 reset */ MX6QDL_PAD_KEY_ROW4__GPIO4_IO15 0x130b0
Can you elaborate some more on the reasons for this?
I'd like to understand if it's something specific to the hardware on that board, or if other i.MX6 boards using the ar8035 are doing it wrong as well.
The datasheet strongly suggests this is the correct thing to do as MDIO should electrically be open drain. However that suggests many more instances of this incorrect configuration exist which also need changed, and not just for ar8035.
While I'm reluctant to attribute something like this to the fec/interrupt problems some people are seeing, I'd also like to be able to rule it out.
PATCH 1/6 ARM: dts: microsom-ar8035: MDIO pad must be set open drain
Quoted 32 lines · Iain Paton
Quoted 17 lines · Russell King
From: Rabeeh Khoury <[email protected]>
To: Shawn Guo <[email protected]>MDIO pad must be set open drain.
Signed-off-by Rabeeh Khoury <[email protected]>Signed-off-by Russell King <[email protected]>--- arch/arm/boot/dts/imx6qdl-microsom-ar8035.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)arch/arm/boot/dts/imx6qdl-microsom-ar8035.dtsi +0
-0arch/arm/boot/dts/imx6qdl-microsom-ar8035.dtsi line 23
Quoted 8 lines
arch/arm/boot/dts/imx6qdl-microsom-ar8035.dtsi +1
-1@@ -17,7 +17,7 @@ enet { pinctrl_microsom_enet_ar8035: microsom-enet-ar8035 { fsl,pins = < - MX6QDL_PAD_ENET_MDIO__ENET_MDIO 0x1b0b0 + MX6QDL_PAD_ENET_MDIO__ENET_MDIO 0x1b8b0 MX6QDL_PAD_ENET_MDC__ENET_MDC 0x1b0b0 /* AR8035 reset */ MX6QDL_PAD_KEY_ROW4__GPIO4_IO15 0x130b0Can you elaborate some more on the reasons for this?
I'd like to understand if it's something specific to the hardware on that board, or if other i.MX6 boards using the ar8035 are doing it wrong as well.
Quoted 7 lines
The datasheet strongly suggests this is the correct thing to do as MDIO should electrically be open drain. However that suggests many more instances of this incorrect configuration exist which also need changed, and not just for ar8035.
While I'm reluctant to attribute something like this to the fec/interrupt problems some people are seeing, I'd also like to be able to rule it out.
I'm merely passing the patch along; I've forwarded your question to Rabeeh via IRC, and may have an answer soon.
FYI, I've run for a long time (close to a year now) on various iMX6 SolidRun platforms without the above patch and haven't seen a problem. I've now also running with it on Solo and Quad and haven't seen any ill effects there, despite the machines running root-NFS, doing regular compiles and git activity.
For me, the problem device right now is that placing the Vivante 2D GPU under stress (using gtkperf) causes the pixel engines to lock up. The Solo is extremely unstable, locking up in less than a second on the first or second test, whereas the Quad is much better, normally taking two runs before locking up in the circle drawing. The Solo also locks up the 2D pixel engines if it needs ot resize the display (due to HDMI being connected.)
Signature · 2 lines
FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up according to speedtest.net.
PATCH 1/6 ARM: dts: microsom-ar8035: MDIO pad must be set open drain
Hi Russell,
Le Sun, 24 Aug 2014 10:58:55 +0100,
Russell King - ARM Linux <[email protected]> a ?crit :
Quoted 8 lines
For me, the problem device right now is that placing the Vivante 2D GPU under stress (using gtkperf) causes the pixel engines to lock up. The Solo is extremely unstable, locking up in less than a second on the first or second test, whereas the Quad is much better, normally taking two runs before locking up in the circle drawing. The Solo also locks up the 2D pixel engines if it needs ot resize the display (due to HDMI being connected.)
Maybe the lock you get is related to what this patch is supposed to fix in Freescale's kernel ?
http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/commit/?h=imx_3.10.17_1.0.1_ga&id=ba5139e1daa3f5834b061a099bcec8e85575a2c0
Best regards,
Eric
PATCH 1/6 ARM: dts: microsom-ar8035: MDIO pad must be set open drain
In reply to Russell King - ARM LinuxQuoted 41 lines · Russell King - ARM Linux
Quoted 32 lines · Iain Paton
Quoted 17 lines · Russell King
From: Rabeeh Khoury <[email protected]>
To: Shawn Guo <[email protected]>MDIO pad must be set open drain.
Signed-off-by Rabeeh Khoury <[email protected]>Signed-off-by Russell King <[email protected]>--- arch/arm/boot/dts/imx6qdl-microsom-ar8035.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)arch/arm/boot/dts/imx6qdl-microsom-ar8035.dtsi +0
-0arch/arm/boot/dts/imx6qdl-microsom-ar8035.dtsi line 23
Quoted 8 lines
arch/arm/boot/dts/imx6qdl-microsom-ar8035.dtsi +1
-1@@ -17,7 +17,7 @@ enet { pinctrl_microsom_enet_ar8035: microsom-enet-ar8035 { fsl,pins = < - MX6QDL_PAD_ENET_MDIO__ENET_MDIO 0x1b0b0 + MX6QDL_PAD_ENET_MDIO__ENET_MDIO 0x1b8b0 MX6QDL_PAD_ENET_MDC__ENET_MDC 0x1b0b0 /* AR8035 reset */ MX6QDL_PAD_KEY_ROW4__GPIO4_IO15 0x130b0Can you elaborate some more on the reasons for this?
I'd like to understand if it's something specific to the hardware on that board, or if other i.MX6 boards using the ar8035 are doing it wrong as well.
Quoted 7 lines
The datasheet strongly suggests this is the correct thing to do as MDIO should electrically be open drain. However that suggests many more instances of this incorrect configuration exist which also need changed, and not just for ar8035.
While I'm reluctant to attribute something like this to the fec/interrupt problems some people are seeing, I'd also like to be able to rule it out.
Quoted 8 lines
I'm merely passing the patch along; I've forwarded your question to Rabeeh via IRC, and may have an answer soon.
FYI, I've run for a long time (close to a year now) on various iMX6 SolidRun platforms without the above patch and haven't seen a problem. I've now also running with it on Solo and Quad and haven't seen any ill effects there, despite the machines running root-NFS, doing regular compiles and git activity.
I've not seen any problems either. Digging through IEEE 802.3 clause 22 only provides references to MDIO being implemented using a tri-state driver. Then in Clause 45 (10gig) there's a one liner saying it 'may' be implemented using open drain.
The i.MX6 manual specifically states support for Clause 22.
However, as 802.3 requires the pull-up be present, it seems unlikely there will be any practical difference between an implementation using open drain and tri-state signalling. Indeed, open drain would seem to be the logical way to implement it electrically.
The AR8035 datasheet specifically marks MDIO and INT as being open drain, however the KSZ9021 (as used on sabre-lite) datasheet doesn't, instead it marks them as Ipu/O (for Input with internal pull-up/Output).
I'd suggest that this is a question of correctness more than a practical problem and I have no objection to the patch being applied.
PATCH 1/6 ARM: dts: microsom-ar8035: MDIO pad must be set open drain
In reply to Iain PatonQuoted 12 lines · Iain Paton
Quoted 11 lines · Russell King
From: Rabeeh Khoury <[email protected]>
To: Shawn Guo <[email protected]>MDIO pad must be set open drain.
Signed-off-by Rabeeh Khoury <[email protected]>Signed-off-by Russell King <[email protected]>--- arch/arm/boot/dts/imx6qdl-microsom-ar8035.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
Quoted 16 lines
Quoted 6 lines
arch/arm/boot/dts/imx6qdl-microsom-ar8035.dtsi +0
-0arch/arm/boot/dts/imx6qdl-microsom-ar8035.dtsi line 23
Quoted 8 lines
arch/arm/boot/dts/imx6qdl-microsom-ar8035.dtsi +1
-1@@ -17,7 +17,7 @@ enet { pinctrl_microsom_enet_ar8035: microsom-enet-ar8035 { fsl,pins = < - MX6QDL_PAD_ENET_MDIO__ENET_MDIO 0x1b0b0 + MX6QDL_PAD_ENET_MDIO__ENET_MDIO 0x1b8b0 MX6QDL_PAD_ENET_MDC__ENET_MDC 0x1b0b0 /* AR8035 reset */ MX6QDL_PAD_KEY_ROW4__GPIO4_IO15 0x130b0Can you elaborate some more on the reasons for this?
I just got the following text from Rabeeh explaining the change.
"This patch is important for the MicroSOM implementation due to the following details -
1. VIH of the Atheros phy is 1.7V.
2. NVCC_ENET which is the power domain of the MDIO pad is driven by the PHY's LDO (i.e. either 1.8v or 2.5v).
3. The MicroSOM implements an onbouard 1.6kohm pull up to 3.3v (R3000).
In the case the PHY's LDO was 1.8v then there would be only a 100mV margin for the signal to be acknowledged as high (1.8v-1.7v). Due to that setting the pad as an open drain will let the 1.6kohm pull that signal high to 3.3 that assures enough margins to the PHY to be acked as '1' logic.
Notice that this change is not required to the SabreSD boards since that hardware drives the NVCC_EIM power island from a 3.3v power rail."
Quoted 3 lines
I'd like to understand if it's something specific to the hardware on that board, or if other i.MX6 boards using the ar8035 are doing it wrong as well.
So from text above, it's a MicroSOM board specific change, I think.
Shawn
Quoted 10 lines
The datasheet strongly suggests this is the correct thing to do as MDIO should electrically be open drain. However that suggests many more instances of this incorrect configuration exist which also need changed, and not just for ar8035.
While I'm reluctant to attribute something like this to the fec/interrupt problems some people are seeing, I'd also like to be able to rule it out.
PATCH 1/6 ARM: dts: microsom-ar8035: MDIO pad must be set open drain
Quoted 46 lines · Shawn Guo
Quoted 12 lines · Iain Paton
Quoted 11 lines · Russell King
From: Rabeeh Khoury <[email protected]>
To: Shawn Guo <[email protected]>MDIO pad must be set open drain.
Signed-off-by Rabeeh Khoury <[email protected]>Signed-off-by Russell King <[email protected]>--- arch/arm/boot/dts/imx6qdl-microsom-ar8035.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)Quoted 16 lines
Quoted 6 lines
arch/arm/boot/dts/imx6qdl-microsom-ar8035.dtsi +0
-0arch/arm/boot/dts/imx6qdl-microsom-ar8035.dtsi line 23
Quoted 8 lines
arch/arm/boot/dts/imx6qdl-microsom-ar8035.dtsi +1
-1@@ -17,7 +17,7 @@ enet { pinctrl_microsom_enet_ar8035: microsom-enet-ar8035 { fsl,pins = < - MX6QDL_PAD_ENET_MDIO__ENET_MDIO 0x1b0b0 + MX6QDL_PAD_ENET_MDIO__ENET_MDIO 0x1b8b0 MX6QDL_PAD_ENET_MDC__ENET_MDC 0x1b0b0 /* AR8035 reset */ MX6QDL_PAD_KEY_ROW4__GPIO4_IO15 0x130b0Can you elaborate some more on the reasons for this?
I just got the following text from Rabeeh explaining the change.
"This patch is important for the MicroSOM implementation due to the following details -
1. VIH of the Atheros phy is 1.7V.
2.NVCC_ENETwhich is the power domain of the MDIO pad is driven by the PHY's LDO (i.e. either 1.8v or 2.5v).
3. The MicroSOM implements an onbouard 1.6kohm pull up to 3.3v (R3000).In the case the PHY's LDO was 1.8v then there would be only a 100mV margin for the signal to be acknowledged as high (1.8v-1.7v). Due to that setting the pad as an open drain will let the 1.6kohm pull that signal high to 3.3 that assures enough margins to the PHY to be acked as '1' logic.
Quoted 8 lines
Notice that this change is not required to the SabreSD boards since that hardware drives the
NVCC_EIMpower island from a 3.3v power rail."Quoted 3 lines
I'd like to understand if it's something specific to the hardware on that board, or if other i.MX6 boards using the ar8035 are doing it wrong as well.
So from text above, it's a MicroSOM board specific change, I think.
Ok, that makes a lot of sense. Practical implementation reasons wins any argument.
No objections from me to this, I think we understand the reasons now.
Iain
PATCH 2/6 ARM: dts: hummingboard/cubox-i: add USB OC pinctrl configuration
In reply to Russell King - ARM LinuxHummingboard has no over current hardware, so disable the over current detection for both ports.
Cubox-i has over current hardware, so appropriately configure this.
--- arch/arm/boot/dts/imx6dl-hummingboard.dts | 2 ++ arch/arm/boot/dts/imx6qdl-cubox-i.dtsi | 17 +++++++++++++---- 2 files changed, 15 insertions(+), 4 deletions(-)
arch/arm/boot/dts/imx6dl-hummingboard.dts +2 -0
@@ -181,11 +181,13 @@ }; &usbh1 { + disable-over-current; vbus-supply = <®_usbh1_vbus>; status = "okay"; }; &usbotg { + disable-over-current; pinctrl-names = "default"; pinctrl-0 = <&pinctrl_hummingboard_usbotg_id>; vbus-supply = <®_usbotg_vbus>;
arch/arm/boot/dts/imx6qdl-cubox-i.dtsi +13 -4
@@ -130,16 +130,23 @@ fsl,pins = <MX6QDL_PAD_GPIO_17__SPDIF_OUT 0x13091>; }; + pinctrl_cubox_i_usbh1: cubox-i-usbh1 { + fsl,pins = <MX6QDL_PAD_GPIO_3__USB_H1_OC 0x1b0b0>; + }; + pinctrl_cubox_i_usbh1_vbus: cubox-i-usbh1-vbus { fsl,pins = <MX6QDL_PAD_GPIO_0__GPIO1_IO00 0x4001b0b0>; }; - pinctrl_cubox_i_usbotg_id: cubox-i-usbotg-id { + pinctrl_cubox_i_usbotg: cubox-i-usbotg { /* - * The Cubox-i pulls this low, but as it's pointless + * The Cubox-i pulls ID low, but as it's pointless * leaving it as a pull-up, even if it is just 10uA. */ - fsl,pins = <MX6QDL_PAD_GPIO_1__USB_OTG_ID 0x13059>; + fsl,pins = < + MX6QDL_PAD_GPIO_1__USB_OTG_ID 0x13059 + MX6QDL_PAD_KEY_COL4__USB_OTG_OC 0x1b0b0 + >; }; pinctrl_cubox_i_usbotg_vbus: cubox-i-usbotg-vbus {
@@ -173,13 +180,15 @@ }; &usbh1 { + pinctrl-names = "default"; + pinctrl-0 = <&pinctrl_cubox_i_usbh1>; vbus-supply = <®_usbh1_vbus>; status = "okay"; }; &usbotg { pinctrl-names = "default"; - pinctrl-0 = <&pinctrl_cubox_i_usbotg_id>; + pinctrl-0 = <&pinctrl_cubox_i_usbotg>; vbus-supply = <®_usbotg_vbus>; status = "okay"; };
Signature · 1 line
1.8.3.1
PATCH 3/6 ARM: dts: hummingboard/cubox-i: change SPDIF output to be more descriptive
In reply to Russell King - ARM Linux--- arch/arm/boot/dts/imx6dl-hummingboard.dts | 2 +- arch/arm/boot/dts/imx6qdl-cubox-i.dtsi | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-)
arch/arm/boot/dts/imx6dl-hummingboard.dts +1 -1
@@ -58,7 +58,7 @@ sound-spdif { compatible = "fsl,imx-audio-spdif"; - model = "imx-spdif"; + model = "On-board SPDIF"; /* IMX6 doesn't implement this yet */ spdif-controller = <&spdif>; spdif-out;
arch/arm/boot/dts/imx6qdl-cubox-i.dtsi +1 -1
@@ -61,7 +61,7 @@ sound-spdif { compatible = "fsl,imx-audio-spdif"; - model = "imx-spdif"; + model = "Integrated SPDIF"; /* IMX6 doesn't implement this yet */ spdif-controller = <&spdif>; spdif-out;
Signature · 1 line
1.8.3.1
PATCH 4/6 ARM: dts: hummingboard: Split HummingBoard DT to support s/dl and d/q
In reply to Russell King - ARM LinuxFrom: Rabeeh Khoury <[email protected]>
To: Shawn Guo <[email protected]>
--- arch/arm/boot/dts/Makefile | 1 + arch/arm/boot/dts/imx6dl-hummingboard.dts | 203 +--------------------------- arch/arm/boot/dts/imx6q-hummingboard.dts | 13 ++ arch/arm/boot/dts/imx6qdl-hummingboard.dtsi | 200 +++++++++++++++++++++++++++ 4 files changed, 219 insertions(+), 198 deletions(-) create mode 100644 arch/arm/boot/dts/imx6q-hummingboard.dts create mode 100644 arch/arm/boot/dts/imx6qdl-hummingboard.dtsi
arch/arm/boot/dts/Makefile +1 -0
@@ -223,6 +223,7 @@ dtb-$(CONFIG_ARCH_MXC) += \ imx6q-gw53xx.dtb \ imx6q-gw5400-a.dtb \ imx6q-gw54xx.dtb \ + imx6q-hummingboard.dtb \ imx6q-nitrogen6x.dtb \ imx6q-phytec-pbab01.dtb \ imx6q-rex-pro.dtb \
arch/arm/boot/dts/imx6dl-hummingboard.dts +5 -198
211 lines not on this page · raw message
arch/arm/boot/dts/imx6q-hummingboard.dts new file +13 -0
@@ -0,0 +1,13 @@ +/* + * Copyright (C) 2014 Rabeeh Khoury (rabeeh at solid-run.com) + * Based on dt work by Russell King + */ +/dts-v1/; + +#include "imx6q.dtsi" +#include "imx6qdl-hummingboard.dtsi" + +/ { + model = "SolidRun HummingBoard Dual/Quad"; + compatible = "solidrun,hummingboard/q", "fsl,imx6q"; +};
arch/arm/boot/dts/imx6qdl-hummingboard.dtsi new file +200 -0
200 lines not on this page · raw message
Signature · 1 line
1.8.3.1
PATCH 5/6 ARM: dts: hummingboard: add mSATA support for iMX6 quad/dual HummingBoard
In reply to Russell King - ARM LinuxFrom: Rabeeh Khoury <[email protected]>
To: Shawn Guo <[email protected]>
Initial patch from Rabeeh, but with the electrical properties added.
--- arch/arm/boot/dts/imx6q-hummingboard.dts | 8 ++++++++ 1 file changed, 8 insertions(+)
arch/arm/boot/dts/imx6q-hummingboard.dts +8 -0
@@ -11,3 +11,11 @@ model = "SolidRun HummingBoard Dual/Quad"; compatible = "solidrun,hummingboard/q", "fsl,imx6q"; }; + +&sata { + status = "okay"; + fsl,transmit-level-mV = <1025>; + fsl,transmit-boost-mdB = <3330>; + fsl,transmit-atten-16ths = <9>; + fsl,receive-eq-mdB = <3000>; +};
Signature · 1 line
1.8.3.1
PATCH 6/6 ARM: dts: hummingboard: gpio-ir on gpio 3,5
In reply to Russell King - ARM LinuxFrom: Rabeeh Khoury <[email protected]>
To: Shawn Guo <[email protected]>
HummingBoard after rev 2.0 and the production one starting rev 3.0 uses gpio 3,5 (EIM_DA5 pad) as the gpio infra red receiver input.
Since the original Carrier1 board is obsolete and we are retiring it, update the DT file for this. This will mean IR reception will not work on Carrier1 with this DT file.
--- arch/arm/boot/dts/imx6qdl-hummingboard.dtsi | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)
arch/arm/boot/dts/imx6qdl-hummingboard.dtsi +4 -4
@@ -11,9 +11,9 @@ ir_recv: ir-receiver { compatible = "gpio-ir-receiver"; - gpios = <&gpio1 2 1>; + gpios = <&gpio3 5 1>; pinctrl-names = "default"; - pinctrl-0 = <&pinctrl_hummingboard_gpio1_2>; + pinctrl-0 = <&pinctrl_hummingboard_gpio3_5>; }; regulators {
@@ -103,9 +103,9 @@ >; }; - pinctrl_hummingboard_gpio1_2: hummingboard-gpio1_2 { + pinctrl_hummingboard_gpio3_5: hummingboard-gpio3_5 { fsl,pins = < - MX6QDL_PAD_GPIO_2__GPIO1_IO02 0x80000000 + MX6QDL_PAD_EIM_DA5__GPIO3_IO05 0x80000000 >; };
Signature · 1 line
1.8.3.1
Fabio Estevam
reviewerPATCH 6/6 ARM: dts: hummingboard: gpio-ir on gpio 3,5
arch/arm/boot/dts/imx6qdl-hummingboard.dtsi line 108
Quoted 2 lines · Russell King
arch/arm/boot/dts/imx6qdl-hummingboard.dtsi +1
-1- MX6QDL_PAD_GPIO_2__GPIO1_IO02 0x80000000 + MX6QDL_PAD_EIM_DA5__GPIO3_IO05 0x80000000
It would be better to replace the '0x80000000' with the real iomux value (like 0x1b0b0 for example), so that we do not need to rely on the bootloader doing the correct configuration for us.
PATCH 6/6 ARM: dts: hummingboard: gpio-ir on gpio 3,5
Quoted 9 lines · Fabio Estevam
arch/arm/boot/dts/imx6qdl-hummingboard.dtsi line 108
Quoted 2 lines · Russell King
arch/arm/boot/dts/imx6qdl-hummingboard.dtsi +1
-1- MX6QDL_PAD_GPIO_2__GPIO1_IO02 0x80000000 + MX6QDL_PAD_EIM_DA5__GPIO3_IO05 0x80000000It would be better to replace the '
0x80000000' with the real iomux value (like0x1b0b0for example), so that we do not need to rely on the bootloader doing the correct configuration for us.
I'd just end up choosing something which appears to work - I've no idea at present what an appropriate value should be here.
Signature · 2 lines
FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up according to speedtest.net.
Fabio Estevam
reviewerPATCH 6/6 ARM: dts: hummingboard: gpio-ir on gpio 3,5
Quoted 7 lines · Russell King - ARM Linux
Quoted 6 lines · Fabio Estevam
Quoted 2 lines · Russell King
arch/arm/boot/dts/imx6qdl-hummingboard.dtsi +1
-1- MX6QDL_PAD_GPIO_2__GPIO1_IO02 0x80000000 + MX6QDL_PAD_EIM_DA5__GPIO3_IO05 0x80000000
Quoted 6 lines
Quoted 3 lines
It would be better to replace the '
0x80000000' with the real iomux value (like0x1b0b0for example), so that we do not need to rely on the bootloader doing the correct configuration for us.I'd just end up choosing something which appears to work - I've no idea at present what an appropriate value should be here.
In the working system, you could read the register:
IOMUXC_SW_PAD_CTL_PAD_EIM_AD05 (address: 0x20E043C)
Most likely it will return the default value of 0xb0b1 if the bootloader has not re-configured it.
,and then put this read value into the device tree. This way we guarantee that the kernel will have this pin correctly configured, without depending on the bootloader.
PATCH 6/6 ARM: dts: hummingboard: gpio-ir on gpio 3,5
Quoted 16 lines · Fabio Estevam
Quoted 7 lines · Russell King - ARM Linux
Quoted 6 lines · Fabio Estevam
Quoted 2 lines · Russell King
arch/arm/boot/dts/imx6qdl-hummingboard.dtsi +1
-1- MX6QDL_PAD_GPIO_2__GPIO1_IO02 0x80000000 + MX6QDL_PAD_EIM_DA5__GPIO3_IO05 0x80000000Quoted 6 lines
Quoted 3 lines
It would be better to replace the '
0x80000000' with the real iomux value (like0x1b0b0for example), so that we do not need to rely on the bootloader doing the correct configuration for us.I'd just end up choosing something which appears to work - I've no idea at present what an appropriate value should be here.
Quoted 6 lines
In the working system, you could read the register:
IOMUXC_SW_PAD_CTL_PAD_EIM_AD05(address:0x20E043C)Most likely it will return the default value of
0xb0b1if the bootloader has not re-configured it.
Most of the pins not associated with booting the kernel are left unconfigured by the boot loader - that's because uboot SPL has very little space for such things.
Rabeeh has just told me that 0x1b0b1 would be a better value for it. I'll add an additional patch to the series for that, rather than modifying Rabeeh's original patch.
Signature · 2 lines
FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up according to speedtest.net.
Fabio Estevam
reviewerPATCH 6/6 ARM: dts: hummingboard: gpio-ir on gpio 3,5
Quoted 7 lines · Russell King - ARM Linux
Most of the pins not associated with booting the kernel are left unconfigured by the boot loader - that's because uboot SPL has very little space for such things.
Rabeeh has just told me that
0x1b0b1would be a better value for it. I'll add an additional patch to the series for that, rather than modifying Rabeeh's original patch.
Sounds good, thanks.
PATCH 6/6 ARM: dts: hummingboard: gpio-ir on gpio 3,5
Quoted 7 lines · Fabio Estevam
Quoted 4 lines · Russell King - ARM Linux
Most of the pins not associated with booting the kernel are left unconfigured by the boot loader - that's because uboot SPL has very little space for such things.
Quoted 5 lines
Quoted 3 lines
Rabeeh has just told me that
0x1b0b1would be a better value for it. I'll add an additional patch to the series for that, rather than modifying Rabeeh's original patch.Sounds good, thanks.
Right, here's the patch to make that change. Shawn, can you pick this one up as well please?
Thanks.
8<===
Quoted 1 line
From
5cebff8f6232fbafde7af564eca61447f951040eMon Sep 17 00:00:00 2001
From: Russell King <[email protected]>
Date: Sat, 23 Aug 2014 15:34:07 +0100
Subject: [PATCH] ARM: dts: hummingboard: fix configuration of IR input
Add the IOMUX setting for the IR input, rather than relying on the boot loader.
--- arch/arm/boot/dts/imx6qdl-hummingboard.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/arm/boot/dts/imx6qdl-hummingboard.dtsi +1 -1
@@ -130,7 +130,7 @@ pinctrl_hummingboard_gpio3_5: hummingboard-gpio3_5 { fsl,pins = < - MX6QDL_PAD_EIM_DA5__GPIO3_IO05 0x80000000 + MX6QDL_PAD_EIM_DA5__GPIO3_IO05 0x1b0b1 >; };
Signature · 7 lines
1.8.3.1 -- FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up according to speedtest.net.
Shawn Guo
AppliedPATCH 6/6 ARM: dts: hummingboard: gpio-ir on gpio 3,5
Quoted 25 lines · Russell King - ARM Linux
Quoted 7 lines · Fabio Estevam
Quoted 4 lines · Russell King - ARM Linux
Most of the pins not associated with booting the kernel are left unconfigured by the boot loader - that's because uboot SPL has very little space for such things.
Quoted 5 lines
Quoted 3 lines
Rabeeh has just told me that
0x1b0b1would be a better value for it. I'll add an additional patch to the series for that, rather than modifying Rabeeh's original patch.Sounds good, thanks.
Right, here's the patch to make that change. Shawn, can you pick this one up as well please?
Thanks.
8<===
From5cebff8f6232fbafde7af564eca61447f951040eMon Sep 17 00:00:00 2001
From: Russell King <[email protected]>
Date: Sat, 23 Aug 2014 15:34:07 +0100
Subject: [PATCH] ARM: dts: hummingboard: fix configuration of IR input
Quoted 4 lines
Add the IOMUX setting for the IR input, rather than relying on the boot loader.
Signed-off-by Russell King <[email protected]>
Applied, thanks.
Shawn
Quoted 29 lines
--- arch/arm/boot/dts/imx6qdl-hummingboard.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)arch/arm/boot/dts/imx6qdl-hummingboard.dtsi +1
-1@@ -130,7 +130,7 @@ pinctrl_hummingboard_gpio3_5: hummingboard-gpio3_5 { fsl,pins = < - MX6QDL_PAD_EIM_DA5__GPIO3_IO05 0x80000000 + MX6QDL_PAD_EIM_DA5__GPIO3_IO05 0x1b0b1 >; };Signature · 11 lines
1.8.3.1 -- FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up according to speedtest.net. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo at vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
cover SolidRun Hummingboard/Cubox-i DT updates
In reply to Russell King - ARM LinuxQuoted 8 lines · Russell King - ARM Linux
Here's a set of patches updating the Cubox-i/Hummingboard DT files.
The first two are fairly important fixes, so should at least go in for -rc kernels.
The SPDIF patch is something which could go in -rc as well as it's a cosmetic patch, changing the name displayed in (eg) pulseaudio for the SPDIF output from the developer-centric "imx-spdif" to "Integrated SPDIF".
I will sent the first 3 for -rc. But I second Iain's comment that the first patch should have a better commit log to explain why it's an important fix.
Quoted 4 lines
Patch 4 updates the Hummingboard support as SolidRun now have a Dual version of this platform, which needs
imx6q.dtsiinstead ofimx6dl.dtsi, and also has mSATA support.
Though it's mostly just a DTS split, the diff stat looks too scary to be a material of -rc.
Quoted 9 lines
Patch 5 adds the mSATA support for the Dual version of the Hummingboard.
Patch 6 is the first patch which breaks something on the initial version of the Hummingboard, aka Carrier1, specifically the IrDA receiver. In hindsight, we should not have used the name "Hummingboard" for the Carrier1. The Carrier1 is obsolete, and people are being encouraged to dispose of the C1 hardware.
Quoted 3 lines
Out of these, I think it would be worth getting the first five patches in for 3.17 (even though we're in -rc), but patch 6 should certainly wait for the next merge window.
Patches 4 ~ 6 are not fixes in any way, so I prefer to queue them for the next merge window.
Shawn
cover SolidRun Hummingboard/Cubox-i DT updates
Quoted 6 lines · Shawn Guo
Quoted 5 lines · Russell King - ARM Linux
Here's a set of patches updating the Cubox-i/Hummingboard DT files.
The first two are fairly important fixes, so should at least go in for -rc kernels.
Quoted 7 lines
Quoted 3 lines
The SPDIF patch is something which could go in -rc as well as it's a cosmetic patch, changing the name displayed in (eg) pulseaudio for the SPDIF output from the developer-centric "imx-spdif" to "Integrated SPDIF".
I will sent the first 3 for -rc. But I second Iain's comment that the first patch should have a better commit log to explain why it's an important fix.
I still have no answer for that, so I suggest dropping it until Rabeeh can write a better commit log.
Signature · 2 lines
FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up according to speedtest.net.
cover SolidRun Hummingboard/Cubox-i DT updates
Quoted 11 lines · Russell King - ARM Linux
Quoted 10 lines · Shawn Guo
Quoted 8 lines · Russell King - ARM Linux
Here's a set of patches updating the Cubox-i/Hummingboard DT files.
The first two are fairly important fixes, so should at least go in for -rc kernels.
The SPDIF patch is something which could go in -rc as well as it's a cosmetic patch, changing the name displayed in (eg) pulseaudio for the SPDIF output from the developer-centric "imx-spdif" to "Integrated SPDIF".
Quoted 6 lines
Quoted 3 lines
I will sent the first 3 for -rc. But I second Iain's comment that the first patch should have a better commit log to explain why it's an important fix.
I still have no answer for that, so I suggest dropping it until Rabeeh can write a better commit log.
Okay. #2 and #3 applied on imx/fixes, and #4~6 applied on imx/dt.
Shawn