[PATCH 0/6] SolidRun Hummingboard/Cubox-i DT updates

[PATCH 0/6] SolidRun Hummingboard/Cubox-i DT updates

[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".

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.

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

[Russell King]

From: Rabeeh Khoury <rabeeh@solid-run.com>
To: Shawn Guo <shawn.guo@freescale.com>

MDIO pad must be set open drain.

Signed-off-by: Rabeeh Khoury <rabeeh@solid-run.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
 arch/arm/boot/dts/imx6qdl-microsom-ar8035.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/imx6qdl-microsom-ar8035.dtsi b/arch/arm/boot/dts/imx6qdl-microsom-ar8035.dtsi
index d16066608e21..db9f45b2c573 100644
--- a/arch/arm/boot/dts/imx6qdl-microsom-ar8035.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-microsom-ar8035.dtsi
@@ -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
-- 
1.8.3.1

[PATCH 1/6] ARM: dts: microsom-ar8035: MDIO pad must be set open drain

[Iain Paton]

On 23/08/14 10:11, Russell King wrote:
> From: Rabeeh Khoury <rabeeh@solid-run.com>
> To: Shawn Guo <shawn.guo@freescale.com>
> 
> MDIO pad must be set open drain.
> 
> Signed-off-by: Rabeeh Khoury <rabeeh@solid-run.com>
> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
> ---
>  arch/arm/boot/dts/imx6qdl-microsom-ar8035.dtsi | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm/boot/dts/imx6qdl-microsom-ar8035.dtsi b/arch/arm/boot/dts/imx6qdl-microsom-ar8035.dtsi
> index d16066608e21..db9f45b2c573 100644
> --- a/arch/arm/boot/dts/imx6qdl-microsom-ar8035.dtsi
> +++ b/arch/arm/boot/dts/imx6qdl-microsom-ar8035.dtsi
> @@ -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

[Russell King - ARM Linux]

On Sun, Aug 24, 2014 at 10:44:54AM +0100, Iain Paton wrote:
> On 23/08/14 10:11, Russell King wrote:
> > From: Rabeeh Khoury <rabeeh@solid-run.com>
> > To: Shawn Guo <shawn.guo@freescale.com>
> > 
> > MDIO pad must be set open drain.
> > 
> > Signed-off-by: Rabeeh Khoury <rabeeh@solid-run.com>
> > Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
> > ---
> >  arch/arm/boot/dts/imx6qdl-microsom-ar8035.dtsi | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/arch/arm/boot/dts/imx6qdl-microsom-ar8035.dtsi b/arch/arm/boot/dts/imx6qdl-microsom-ar8035.dtsi
> > index d16066608e21..db9f45b2c573 100644
> > --- a/arch/arm/boot/dts/imx6qdl-microsom-ar8035.dtsi
> > +++ b/arch/arm/boot/dts/imx6qdl-microsom-ar8035.dtsi
> > @@ -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.

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

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

[Eric Bénard]

Hi Russell,

Le Sun, 24 Aug 2014 10:58:55 +0100,
Russell King - ARM Linux <linux@arm.linux.org.uk> a ?crit :
> 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

[Iain Paton]

On 24/08/14 10:58, Russell King - ARM Linux wrote:
> On Sun, Aug 24, 2014 at 10:44:54AM +0100, Iain Paton wrote:
>> On 23/08/14 10:11, Russell King wrote:
>>> From: Rabeeh Khoury <rabeeh@solid-run.com>
>>> To: Shawn Guo <shawn.guo@freescale.com>
>>>
>>> MDIO pad must be set open drain.
>>>
>>> Signed-off-by: Rabeeh Khoury <rabeeh@solid-run.com>
>>> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
>>> ---
>>>  arch/arm/boot/dts/imx6qdl-microsom-ar8035.dtsi | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/arch/arm/boot/dts/imx6qdl-microsom-ar8035.dtsi b/arch/arm/boot/dts/imx6qdl-microsom-ar8035.dtsi
>>> index d16066608e21..db9f45b2c573 100644
>>> --- a/arch/arm/boot/dts/imx6qdl-microsom-ar8035.dtsi
>>> +++ b/arch/arm/boot/dts/imx6qdl-microsom-ar8035.dtsi
>>> @@ -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.
> 
> 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

[Shawn Guo]

On Sun, Aug 24, 2014 at 10:44:54AM +0100, Iain Paton wrote:
> On 23/08/14 10:11, Russell King wrote:
> > From: Rabeeh Khoury <rabeeh@solid-run.com>
> > To: Shawn Guo <shawn.guo@freescale.com>
> > 
> > MDIO pad must be set open drain.
> > 
> > Signed-off-by: Rabeeh Khoury <rabeeh@solid-run.com>
> > Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
> > ---
> >  arch/arm/boot/dts/imx6qdl-microsom-ar8035.dtsi | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/arch/arm/boot/dts/imx6qdl-microsom-ar8035.dtsi b/arch/arm/boot/dts/imx6qdl-microsom-ar8035.dtsi
> > index d16066608e21..db9f45b2c573 100644
> > --- a/arch/arm/boot/dts/imx6qdl-microsom-ar8035.dtsi
> > +++ b/arch/arm/boot/dts/imx6qdl-microsom-ar8035.dtsi
> > @@ -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 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."

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

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

[Iain Paton]

On 26/08/14 11:15, Shawn Guo wrote:
> On Sun, Aug 24, 2014 at 10:44:54AM +0100, Iain Paton wrote:
>> On 23/08/14 10:11, Russell King wrote:
>>> From: Rabeeh Khoury <rabeeh@solid-run.com>
>>> To: Shawn Guo <shawn.guo@freescale.com>
>>>
>>> MDIO pad must be set open drain.
>>>
>>> Signed-off-by: Rabeeh Khoury <rabeeh@solid-run.com>
>>> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
>>> ---
>>>  arch/arm/boot/dts/imx6qdl-microsom-ar8035.dtsi | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/arch/arm/boot/dts/imx6qdl-microsom-ar8035.dtsi b/arch/arm/boot/dts/imx6qdl-microsom-ar8035.dtsi
>>> index d16066608e21..db9f45b2c573 100644
>>> --- a/arch/arm/boot/dts/imx6qdl-microsom-ar8035.dtsi
>>> +++ b/arch/arm/boot/dts/imx6qdl-microsom-ar8035.dtsi
>>> @@ -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 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."
> 
>>
>> 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

[Russell King]

Hummingboard has no over current hardware, so disable the over current
detection for both ports.

Cubox-i has over current hardware, so appropriately configure this.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
 arch/arm/boot/dts/imx6dl-hummingboard.dts |  2 ++
 arch/arm/boot/dts/imx6qdl-cubox-i.dtsi    | 17 +++++++++++++----
 2 files changed, 15 insertions(+), 4 deletions(-)

diff --git a/arch/arm/boot/dts/imx6dl-hummingboard.dts b/arch/arm/boot/dts/imx6dl-hummingboard.dts
index c8e51dd41b8f..d1c892e28296 100644
--- a/arch/arm/boot/dts/imx6dl-hummingboard.dts
+++ b/arch/arm/boot/dts/imx6dl-hummingboard.dts
@@ -181,11 +181,13 @@
 };
 
 &usbh1 {
+	disable-over-current;
 	vbus-supply = <&reg_usbh1_vbus>;
 	status = "okay";
 };
 
 &usbotg {
+	disable-over-current;
 	pinctrl-names = "default";
 	pinctrl-0 = <&pinctrl_hummingboard_usbotg_id>;
 	vbus-supply = <&reg_usbotg_vbus>;
diff --git a/arch/arm/boot/dts/imx6qdl-cubox-i.dtsi b/arch/arm/boot/dts/imx6qdl-cubox-i.dtsi
index e8e781656b3f..298d0fdf8ebe 100644
--- a/arch/arm/boot/dts/imx6qdl-cubox-i.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-cubox-i.dtsi
@@ -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 = <&reg_usbh1_vbus>;
 	status = "okay";
 };
 
 &usbotg {
 	pinctrl-names = "default";
-	pinctrl-0 = <&pinctrl_cubox_i_usbotg_id>;
+	pinctrl-0 = <&pinctrl_cubox_i_usbotg>;
 	vbus-supply = <&reg_usbotg_vbus>;
 	status = "okay";
 };
-- 
1.8.3.1

[PATCH 3/6] ARM: dts: hummingboard/cubox-i: change SPDIF output to be more descriptive

[Russell King]

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
 arch/arm/boot/dts/imx6dl-hummingboard.dts | 2 +-
 arch/arm/boot/dts/imx6qdl-cubox-i.dtsi    | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/imx6dl-hummingboard.dts b/arch/arm/boot/dts/imx6dl-hummingboard.dts
index d1c892e28296..71598546087f 100644
--- a/arch/arm/boot/dts/imx6dl-hummingboard.dts
+++ b/arch/arm/boot/dts/imx6dl-hummingboard.dts
@@ -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;
diff --git a/arch/arm/boot/dts/imx6qdl-cubox-i.dtsi b/arch/arm/boot/dts/imx6qdl-cubox-i.dtsi
index 298d0fdf8ebe..6a524ca011e7 100644
--- a/arch/arm/boot/dts/imx6qdl-cubox-i.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-cubox-i.dtsi
@@ -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;
-- 
1.8.3.1

[PATCH 4/6] ARM: dts: hummingboard: Split HummingBoard DT to support s/dl and d/q

[Russell King]

From: Rabeeh Khoury <rabeeh@solid-run.com>
To: Shawn Guo <shawn.guo@freescale.com>

Signed-off-by: Rabeeh Khoury <rabeeh@solid-run.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
 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

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index b8c5cd3ddeb9..bef8619536ae 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -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 \
diff --git a/arch/arm/boot/dts/imx6dl-hummingboard.dts b/arch/arm/boot/dts/imx6dl-hummingboard.dts
index 71598546087f..44a0e6736bb1 100644
--- a/arch/arm/boot/dts/imx6dl-hummingboard.dts
+++ b/arch/arm/boot/dts/imx6dl-hummingboard.dts
@@ -1,206 +1,13 @@
 /*
- * Copyright (C) 2013,2014 Russell King
+ * Copyright (C) 2014 Rabeeh Khoury (rabeeh at solid-run.com)
+ * Based on dt work by Russell King
  */
 /dts-v1/;
 
 #include "imx6dl.dtsi"
-#include "imx6qdl-microsom.dtsi"
-#include "imx6qdl-microsom-ar8035.dtsi"
+#include "imx6qdl-hummingboard.dtsi"
 
 / {
-	model = "SolidRun HummingBoard DL/Solo";
-	compatible = "solidrun,hummingboard", "fsl,imx6dl";
-
-	chosen {
-		stdout-path = &uart1;
-	};
-
-	ir_recv: ir-receiver {
-		compatible = "gpio-ir-receiver";
-		gpios = <&gpio1 2 1>;
-		pinctrl-names = "default";
-		pinctrl-0 = <&pinctrl_hummingboard_gpio1_2>;
-	};
-
-	regulators {
-		compatible = "simple-bus";
-
-		reg_3p3v: 3p3v {
-			compatible = "regulator-fixed";
-			regulator-name = "3P3V";
-			regulator-min-microvolt = <3300000>;
-			regulator-max-microvolt = <3300000>;
-			regulator-always-on;
-		};
-
-		reg_usbh1_vbus: usb-h1-vbus {
-			compatible = "regulator-fixed";
-			enable-active-high;
-			gpio = <&gpio1 0 0>;
-			pinctrl-names = "default";
-			pinctrl-0 = <&pinctrl_hummingboard_usbh1_vbus>;
-			regulator-name = "usb_h1_vbus";
-			regulator-min-microvolt = <5000000>;
-			regulator-max-microvolt = <5000000>;
-		};
-
-		reg_usbotg_vbus: usb-otg-vbus {
-			compatible = "regulator-fixed";
-			enable-active-high;
-			gpio = <&gpio3 22 0>;
-			pinctrl-names = "default";
-			pinctrl-0 = <&pinctrl_hummingboard_usbotg_vbus>;
-			regulator-name = "usb_otg_vbus";
-			regulator-min-microvolt = <5000000>;
-			regulator-max-microvolt = <5000000>;
-		};
-	};
-
-	sound-spdif {
-		compatible = "fsl,imx-audio-spdif";
-		model = "On-board SPDIF";
-		/* IMX6 doesn't implement this yet */
-		spdif-controller = <&spdif>;
-		spdif-out;
-	};
-};
-
-&can1 {
-	pinctrl-names = "default";
-	pinctrl-0 = <&pinctrl_hummingboard_flexcan1>;
-	status = "okay";
-};
-
-&hdmi {
-	pinctrl-names = "default";
-	pinctrl-0 = <&pinctrl_hummingboard_hdmi>;
-	ddc-i2c-bus = <&i2c2>;
-	status = "okay";
-};
-
-&i2c1 {
-	pinctrl-names = "default";
-	pinctrl-0 = <&pinctrl_hummingboard_i2c1>;
-
-	/*
-	 * Not fitted on Carrier-1 board... yet
-	status = "okay";
-
-	rtc: pcf8523 at 68 {
-		compatible = "nxp,pcf8523";
-		reg = <0x68>;
-	};
-	 */
-};
-
-&i2c2 {
-	clock-frequency = <100000>;
-	pinctrl-names = "default";
-	pinctrl-0 = <&pinctrl_hummingboard_i2c2>;
-	status = "okay";
-};
-
-&iomuxc {
-	hummingboard {
-		pinctrl_hummingboard_flexcan1: hummingboard-flexcan1 {
-			fsl,pins = <
-				MX6QDL_PAD_SD3_CLK__FLEXCAN1_RX 0x80000000
-				MX6QDL_PAD_SD3_CMD__FLEXCAN1_TX 0x80000000
-			>;
-		};
-
-		pinctrl_hummingboard_gpio1_2: hummingboard-gpio1_2 {
-			fsl,pins = <
-				MX6QDL_PAD_GPIO_2__GPIO1_IO02 0x80000000
-			>;
-		};
-
-		pinctrl_hummingboard_hdmi: hummingboard-hdmi {
-			fsl,pins = <
-				MX6QDL_PAD_KEY_ROW2__HDMI_TX_CEC_LINE 0x1f8b0
-			>;
-		};
-
-		pinctrl_hummingboard_i2c1: hummingboard-i2c1 {
-			fsl,pins = <
-				MX6QDL_PAD_EIM_D21__I2C1_SCL 0x4001b8b1
-				MX6QDL_PAD_EIM_D28__I2C1_SDA 0x4001b8b1
-			>;
-		};
-
-		pinctrl_hummingboard_i2c2: hummingboard-i2c2 {
-			fsl,pins = <
-				MX6QDL_PAD_KEY_COL3__I2C2_SCL 0x4001b8b1
-				MX6QDL_PAD_KEY_ROW3__I2C2_SDA 0x4001b8b1
-			>;
-		};
-
-		pinctrl_hummingboard_spdif: hummingboard-spdif {
-			fsl,pins = <MX6QDL_PAD_GPIO_17__SPDIF_OUT 0x13091>;
-		};
-
-		pinctrl_hummingboard_usbh1_vbus: hummingboard-usbh1-vbus {
-			fsl,pins = <MX6QDL_PAD_GPIO_0__GPIO1_IO00 0x1b0b0>;
-		};
-
-		pinctrl_hummingboard_usbotg_id: hummingboard-usbotg-id {
-			/*
-			 * Similar to pinctrl_usbotg_2, but we want it
-			 * pulled down for a fixed host connection.
-			 */
-			fsl,pins = <MX6QDL_PAD_GPIO_1__USB_OTG_ID 0x13059>;
-		};
-
-		pinctrl_hummingboard_usbotg_vbus: hummingboard-usbotg-vbus {
-			fsl,pins = <MX6QDL_PAD_EIM_D22__GPIO3_IO22 0x1b0b0>;
-		};
-
-		pinctrl_hummingboard_usdhc2_aux: hummingboard-usdhc2-aux {
-			fsl,pins = <
-				MX6QDL_PAD_GPIO_4__GPIO1_IO04    0x1f071
-			>;
-		};
-
-		pinctrl_hummingboard_usdhc2: hummingboard-usdhc2 {
-			fsl,pins = <
-				MX6QDL_PAD_SD2_CMD__SD2_CMD    0x17059
-				MX6QDL_PAD_SD2_CLK__SD2_CLK    0x10059
-				MX6QDL_PAD_SD2_DAT0__SD2_DATA0 0x17059
-				MX6QDL_PAD_SD2_DAT1__SD2_DATA1 0x17059
-				MX6QDL_PAD_SD2_DAT2__SD2_DATA2 0x17059
-				MX6QDL_PAD_SD2_DAT3__SD2_DATA3 0x13059
-			>;
-		};
-	};
-};
-
-&spdif {
-	pinctrl-names = "default";
-	pinctrl-0 = <&pinctrl_hummingboard_spdif>;
-	status = "okay";
-};
-
-&usbh1 {
-	disable-over-current;
-	vbus-supply = <&reg_usbh1_vbus>;
-	status = "okay";
-};
-
-&usbotg {
-	disable-over-current;
-	pinctrl-names = "default";
-	pinctrl-0 = <&pinctrl_hummingboard_usbotg_id>;
-	vbus-supply = <&reg_usbotg_vbus>;
-	status = "okay";
-};
-
-&usdhc2 {
-	pinctrl-names = "default";
-	pinctrl-0 = <
-		&pinctrl_hummingboard_usdhc2_aux
-		&pinctrl_hummingboard_usdhc2
-	>;
-	vmmc-supply = <&reg_3p3v>;
-	cd-gpios = <&gpio1 4 0>;
-	status = "okay";
+	model = "SolidRun HummingBoard Solo/DualLite";
+	compatible = "solidrun,hummingboard/dl", "fsl,imx6dl";
 };
diff --git a/arch/arm/boot/dts/imx6q-hummingboard.dts b/arch/arm/boot/dts/imx6q-hummingboard.dts
new file mode 100644
index 000000000000..0a3574105165
--- /dev/null
+++ b/arch/arm/boot/dts/imx6q-hummingboard.dts
@@ -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";
+};
diff --git a/arch/arm/boot/dts/imx6qdl-hummingboard.dtsi b/arch/arm/boot/dts/imx6qdl-hummingboard.dtsi
new file mode 100644
index 000000000000..bf38072a2779
--- /dev/null
+++ b/arch/arm/boot/dts/imx6qdl-hummingboard.dtsi
@@ -0,0 +1,200 @@
+/*
+ * Copyright (C) 2013,2014 Russell King
+ */
+#include "imx6qdl-microsom.dtsi"
+#include "imx6qdl-microsom-ar8035.dtsi"
+
+/ {
+	chosen {
+		stdout-path = &uart1;
+	};
+
+	ir_recv: ir-receiver {
+		compatible = "gpio-ir-receiver";
+		gpios = <&gpio1 2 1>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&pinctrl_hummingboard_gpio1_2>;
+	};
+
+	regulators {
+		compatible = "simple-bus";
+
+		reg_3p3v: 3p3v {
+			compatible = "regulator-fixed";
+			regulator-name = "3P3V";
+			regulator-min-microvolt = <3300000>;
+			regulator-max-microvolt = <3300000>;
+			regulator-always-on;
+		};
+
+		reg_usbh1_vbus: usb-h1-vbus {
+			compatible = "regulator-fixed";
+			enable-active-high;
+			gpio = <&gpio1 0 0>;
+			pinctrl-names = "default";
+			pinctrl-0 = <&pinctrl_hummingboard_usbh1_vbus>;
+			regulator-name = "usb_h1_vbus";
+			regulator-min-microvolt = <5000000>;
+			regulator-max-microvolt = <5000000>;
+		};
+
+		reg_usbotg_vbus: usb-otg-vbus {
+			compatible = "regulator-fixed";
+			enable-active-high;
+			gpio = <&gpio3 22 0>;
+			pinctrl-names = "default";
+			pinctrl-0 = <&pinctrl_hummingboard_usbotg_vbus>;
+			regulator-name = "usb_otg_vbus";
+			regulator-min-microvolt = <5000000>;
+			regulator-max-microvolt = <5000000>;
+		};
+	};
+
+	sound-spdif {
+		compatible = "fsl,imx-audio-spdif";
+		model = "On-board SPDIF";
+		/* IMX6 doesn't implement this yet */
+		spdif-controller = <&spdif>;
+		spdif-out;
+	};
+};
+
+&can1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_hummingboard_flexcan1>;
+	status = "okay";
+};
+
+&hdmi {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_hummingboard_hdmi>;
+	ddc-i2c-bus = <&i2c2>;
+	status = "okay";
+};
+
+&i2c1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_hummingboard_i2c1>;
+
+	/*
+	 * Not fitted on Carrier-1 board... yet
+	status = "okay";
+
+	rtc: pcf8523 at 68 {
+		compatible = "nxp,pcf8523";
+		reg = <0x68>;
+	};
+	 */
+};
+
+&i2c2 {
+	clock-frequency = <100000>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_hummingboard_i2c2>;
+	status = "okay";
+};
+
+&iomuxc {
+	hummingboard {
+		pinctrl_hummingboard_flexcan1: hummingboard-flexcan1 {
+			fsl,pins = <
+				MX6QDL_PAD_SD3_CLK__FLEXCAN1_RX 0x80000000
+				MX6QDL_PAD_SD3_CMD__FLEXCAN1_TX 0x80000000
+			>;
+		};
+
+		pinctrl_hummingboard_gpio1_2: hummingboard-gpio1_2 {
+			fsl,pins = <
+				MX6QDL_PAD_GPIO_2__GPIO1_IO02 0x80000000
+			>;
+		};
+
+		pinctrl_hummingboard_hdmi: hummingboard-hdmi {
+			fsl,pins = <
+				MX6QDL_PAD_KEY_ROW2__HDMI_TX_CEC_LINE 0x1f8b0
+			>;
+		};
+
+		pinctrl_hummingboard_i2c1: hummingboard-i2c1 {
+			fsl,pins = <
+				MX6QDL_PAD_EIM_D21__I2C1_SCL 0x4001b8b1
+				MX6QDL_PAD_EIM_D28__I2C1_SDA 0x4001b8b1
+			>;
+		};
+
+		pinctrl_hummingboard_i2c2: hummingboard-i2c2 {
+			fsl,pins = <
+				MX6QDL_PAD_KEY_COL3__I2C2_SCL 0x4001b8b1
+				MX6QDL_PAD_KEY_ROW3__I2C2_SDA 0x4001b8b1
+			>;
+		};
+
+		pinctrl_hummingboard_spdif: hummingboard-spdif {
+			fsl,pins = <MX6QDL_PAD_GPIO_17__SPDIF_OUT 0x13091>;
+		};
+
+		pinctrl_hummingboard_usbh1_vbus: hummingboard-usbh1-vbus {
+			fsl,pins = <MX6QDL_PAD_GPIO_0__GPIO1_IO00 0x1b0b0>;
+		};
+
+		pinctrl_hummingboard_usbotg_id: hummingboard-usbotg-id {
+			/*
+			 * Similar to pinctrl_usbotg_2, but we want it
+			 * pulled down for a fixed host connection.
+			 */
+			fsl,pins = <MX6QDL_PAD_GPIO_1__USB_OTG_ID 0x13059>;
+		};
+
+		pinctrl_hummingboard_usbotg_vbus: hummingboard-usbotg-vbus {
+			fsl,pins = <MX6QDL_PAD_EIM_D22__GPIO3_IO22 0x1b0b0>;
+		};
+
+		pinctrl_hummingboard_usdhc2_aux: hummingboard-usdhc2-aux {
+			fsl,pins = <
+				MX6QDL_PAD_GPIO_4__GPIO1_IO04    0x1f071
+			>;
+		};
+
+		pinctrl_hummingboard_usdhc2: hummingboard-usdhc2 {
+			fsl,pins = <
+				MX6QDL_PAD_SD2_CMD__SD2_CMD    0x17059
+				MX6QDL_PAD_SD2_CLK__SD2_CLK    0x10059
+				MX6QDL_PAD_SD2_DAT0__SD2_DATA0 0x17059
+				MX6QDL_PAD_SD2_DAT1__SD2_DATA1 0x17059
+				MX6QDL_PAD_SD2_DAT2__SD2_DATA2 0x17059
+				MX6QDL_PAD_SD2_DAT3__SD2_DATA3 0x13059
+			>;
+		};
+	};
+};
+
+&spdif {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_hummingboard_spdif>;
+	status = "okay";
+};
+
+&usbh1 {
+	disable-over-current;
+	vbus-supply = <&reg_usbh1_vbus>;
+	status = "okay";
+};
+
+&usbotg {
+	disable-over-current;
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_hummingboard_usbotg_id>;
+	vbus-supply = <&reg_usbotg_vbus>;
+	status = "okay";
+};
+
+&usdhc2 {
+	pinctrl-names = "default";
+	pinctrl-0 = <
+		&pinctrl_hummingboard_usdhc2_aux
+		&pinctrl_hummingboard_usdhc2
+	>;
+	vmmc-supply = <&reg_3p3v>;
+	cd-gpios = <&gpio1 4 0>;
+	status = "okay";
+};
-- 
1.8.3.1

[PATCH 5/6] ARM: dts: hummingboard: add mSATA support for iMX6 quad/dual HummingBoard

[Russell King]

From: Rabeeh Khoury <rabeeh@solid-run.com>
To: Shawn Guo <shawn.guo@freescale.com>

Initial patch from Rabeeh, but with the electrical properties added.

Signed-off-by: Rabeeh Khoury <rabeeh@solid-run.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
 arch/arm/boot/dts/imx6q-hummingboard.dts | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/arch/arm/boot/dts/imx6q-hummingboard.dts b/arch/arm/boot/dts/imx6q-hummingboard.dts
index 0a3574105165..c2bf8476ce45 100644
--- a/arch/arm/boot/dts/imx6q-hummingboard.dts
+++ b/arch/arm/boot/dts/imx6q-hummingboard.dts
@@ -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>;
+};
-- 
1.8.3.1

[PATCH 6/6] ARM: dts: hummingboard: gpio-ir on gpio 3,5

[Russell King]

From: Rabeeh Khoury <rabeeh@solid-run.com>
To: Shawn Guo <shawn.guo@freescale.com>

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.

Signed-off-by: Rabeeh Khoury <rabeeh@solid-run.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
 arch/arm/boot/dts/imx6qdl-hummingboard.dtsi | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm/boot/dts/imx6qdl-hummingboard.dtsi b/arch/arm/boot/dts/imx6qdl-hummingboard.dtsi
index bf38072a2779..1f355804c2cb 100644
--- a/arch/arm/boot/dts/imx6qdl-hummingboard.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-hummingboard.dtsi
@@ -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
 			>;
 		};
 
-- 
1.8.3.1

[PATCH 6/6] ARM: dts: hummingboard: gpio-ir on gpio 3,5

[Fabio Estevam]

On Sat, Aug 23, 2014 at 6:11 AM, Russell King
<rmk+kernel@arm.linux.org.uk> wrote:

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

[Russell King - ARM Linux]

On Sat, Aug 23, 2014 at 10:32:23AM -0300, Fabio Estevam wrote:
> On Sat, Aug 23, 2014 at 6:11 AM, Russell King
> <rmk+kernel@arm.linux.org.uk> wrote:
> 
> > -                               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.

I'd just end up choosing something which appears to work - I've no idea
at present what an appropriate value should be here.

-- 
FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
according to speedtest.net.

[PATCH 6/6] ARM: dts: hummingboard: gpio-ir on gpio 3,5

[Fabio Estevam]

On Sat, Aug 23, 2014 at 10:36 AM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Sat, Aug 23, 2014 at 10:32:23AM -0300, Fabio Estevam wrote:
>> On Sat, Aug 23, 2014 at 6:11 AM, Russell King
>> <rmk+kernel@arm.linux.org.uk> wrote:
>>
>> > -                               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.
>
> 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

[Russell King - ARM Linux]

On Sat, Aug 23, 2014 at 10:56:37AM -0300, Fabio Estevam wrote:
> On Sat, Aug 23, 2014 at 10:36 AM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> > On Sat, Aug 23, 2014 at 10:32:23AM -0300, Fabio Estevam wrote:
> >> On Sat, Aug 23, 2014 at 6:11 AM, Russell King
> >> <rmk+kernel@arm.linux.org.uk> wrote:
> >>
> >> > -                               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.
> >
> > 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.

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.

-- 
FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
according to speedtest.net.

[PATCH 6/6] ARM: dts: hummingboard: gpio-ir on gpio 3,5

[Fabio Estevam]

On Sat, Aug 23, 2014 at 11:33 AM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:

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

Sounds good, thanks.

[PATCH 6/6] ARM: dts: hummingboard: gpio-ir on gpio 3,5

[Russell King - ARM Linux]

On Sat, Aug 23, 2014 at 12:02:05PM -0300, Fabio Estevam wrote:
> On Sat, Aug 23, 2014 at 11:33 AM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> 
> > 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.
> 
> Sounds good, thanks.

Right, here's the patch to make that change.  Shawn, can you pick this
one up as well please?

Thanks.

8<===
>From 5cebff8f6232fbafde7af564eca61447f951040e Mon Sep 17 00:00:00 2001
From: Russell King <rmk+kernel@arm.linux.org.uk>
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.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
 arch/arm/boot/dts/imx6qdl-hummingboard.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/imx6qdl-hummingboard.dtsi b/arch/arm/boot/dts/imx6qdl-hummingboard.dtsi
index 4aa0ae357b00..7fe29de89e9d 100644
--- a/arch/arm/boot/dts/imx6qdl-hummingboard.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-hummingboard.dtsi
@@ -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
 			>;
 		};
 
-- 
1.8.3.1



-- 
FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
according to speedtest.net.

[PATCH 6/6] ARM: dts: hummingboard: gpio-ir on gpio 3,5

[Shawn Guo]

On Wed, Aug 27, 2014 at 07:43:54PM +0100, Russell King - ARM Linux wrote:
> On Sat, Aug 23, 2014 at 12:02:05PM -0300, Fabio Estevam wrote:
> > On Sat, Aug 23, 2014 at 11:33 AM, Russell King - ARM Linux
> > <linux@arm.linux.org.uk> wrote:
> > 
> > > 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.
> > 
> > Sounds good, thanks.
> 
> Right, here's the patch to make that change.  Shawn, can you pick this
> one up as well please?
> 
> Thanks.
> 
> 8<===
> From 5cebff8f6232fbafde7af564eca61447f951040e Mon Sep 17 00:00:00 2001
> From: Russell King <rmk+kernel@arm.linux.org.uk>
> 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.
> 
> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

Applied, thanks.

Shawn

> ---
>  arch/arm/boot/dts/imx6qdl-hummingboard.dtsi | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm/boot/dts/imx6qdl-hummingboard.dtsi b/arch/arm/boot/dts/imx6qdl-hummingboard.dtsi
> index 4aa0ae357b00..7fe29de89e9d 100644
> --- a/arch/arm/boot/dts/imx6qdl-hummingboard.dtsi
> +++ b/arch/arm/boot/dts/imx6qdl-hummingboard.dtsi
> @@ -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
>  			>;
>  		};
>  
> -- 
> 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

[PATCH 0/6] SolidRun Hummingboard/Cubox-i DT updates

[Shawn Guo]

On Sat, Aug 23, 2014 at 10:10:58AM +0100, Russell King - ARM Linux wrote:
> 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.

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

Though it's mostly just a DTS split, the diff stat looks too scary to
be a material of -rc.

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

Patches 4 ~ 6 are not fixes in any way, so I prefer to queue them for
the next merge window.

Shawn

[PATCH 0/6] SolidRun Hummingboard/Cubox-i DT updates

[Russell King - ARM Linux]

On Mon, Aug 25, 2014 at 02:29:32PM +0800, Shawn Guo wrote:
> On Sat, Aug 23, 2014 at 10:10:58AM +0100, Russell King - ARM Linux wrote:
> > 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.

I still have no answer for that, so I suggest dropping it until Rabeeh
can write a better commit log.

-- 
FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
according to speedtest.net.

[PATCH 0/6] SolidRun Hummingboard/Cubox-i DT updates

[Shawn Guo]

On Mon, Aug 25, 2014 at 10:51:07AM +0100, Russell King - ARM Linux wrote:
> On Mon, Aug 25, 2014 at 02:29:32PM +0800, Shawn Guo wrote:
> > On Sat, Aug 23, 2014 at 10:10:58AM +0100, Russell King - ARM Linux wrote:
> > > 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.
> 
> 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