[PATCH 0/2] Fix omap5-uevm WLAN regressions

[PATCH 0/2] Fix omap5-uevm WLAN regressions

[Tony Lindgren]

Hi all,

Here are two fixes for omap5-uevm WLAN.

Regards,

Tony

Tony Lindgren (2):
  mfd: twl6040: Fix deferred probe handling for clk32k
  ARM: dts: Fix WLAN regression on omap5-uevm

 arch/arm/boot/dts/omap5-uevm.dts | 51 +++++++++++++++++++++++++++++++---------
 drivers/mfd/twl6040.c            |  2 ++
 2 files changed, 42 insertions(+), 11 deletions(-)

-- 
2.1.4

[PATCH 0/2] Fix omap5-uevm WLAN regressions

[Tony Lindgren]

Hi all,

Here are two fixes for omap5-uevm WLAN.

Regards,

Tony

Tony Lindgren (2):
  mfd: twl6040: Fix deferred probe handling for clk32k
  ARM: dts: Fix WLAN regression on omap5-uevm

 arch/arm/boot/dts/omap5-uevm.dts | 51 +++++++++++++++++++++++++++++++---------
 drivers/mfd/twl6040.c            |  2 ++
 2 files changed, 42 insertions(+), 11 deletions(-)

-- 
2.1.4

[PATCH 1/2] mfd: twl6040: Fix deferred probe handling for clk32k

[Tony Lindgren]

Commit 68bab8662f49 ("mfd: twl6040: Optional clk32k clock handling")
added clock handling for the 32k clock from palmas-clk. However, that
patch did not consider a typical situation where twl6040 is built-in,
and palmas-clk is a loadable module like we have in omap2plus_defconfig.

If palmas-clk is not loaded before twl6040 probes, we will get a
"clk32k is not handled" warning during booting. This means that any
drivers relying on this clock will mysteriously fail, including
omap5-uevm WLAN and audio.

Note that for WLAN, we probably should also eventually get
the clk32kgaudio for MMC3 directly as that's shared between
audio and WLAN SDIO at least for omap5-uevm. It seems the
WLAN chip cannot get it as otherwise MMC3 won't get properly
probed.

Fixes: 68bab8662f49 ("mfd: twl6040: Optional clk32k clock handling")
Cc: Benoit Cousson <bcousson@baylibre.com>
Cc: Dr. H. Nikolaus Schaller <hns@goldelico.com>
Cc: Grazvydas Ignotas <notasas@gmail.com>
Cc: Lee Jones <lee.jones@linaro.org>
Cc: Peter Ujfalusi <peter.ujfalusi@ti.com>
Cc: Samuel Ortiz <sameo@linux.intel.com>
Cc: Sourav Poddar <sourav.poddar@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
---
 drivers/mfd/twl6040.c | 2 ++
 1 file changed, 2 insertions(+)

--- a/drivers/mfd/twl6040.c
+++ b/drivers/mfd/twl6040.c
@@ -647,6 +647,8 @@ static int twl6040_probe(struct i2c_client *client,
 
 	twl6040->clk32k = devm_clk_get(&client->dev, "clk32k");
 	if (IS_ERR(twl6040->clk32k)) {
+		if (PTR_ERR(twl6040->clk32k) == -EPROBE_DEFER)
+			return -EPROBE_DEFER;
 		dev_info(&client->dev, "clk32k is not handled\n");
 		twl6040->clk32k = NULL;
 	}
-- 
2.1.4

[PATCH 1/2] mfd: twl6040: Fix deferred probe handling for clk32k

[Tony Lindgren]

Commit 68bab8662f49 ("mfd: twl6040: Optional clk32k clock handling")
added clock handling for the 32k clock from palmas-clk. However, that
patch did not consider a typical situation where twl6040 is built-in,
and palmas-clk is a loadable module like we have in omap2plus_defconfig.

If palmas-clk is not loaded before twl6040 probes, we will get a
"clk32k is not handled" warning during booting. This means that any
drivers relying on this clock will mysteriously fail, including
omap5-uevm WLAN and audio.

Note that for WLAN, we probably should also eventually get
the clk32kgaudio for MMC3 directly as that's shared between
audio and WLAN SDIO at least for omap5-uevm. It seems the
WLAN chip cannot get it as otherwise MMC3 won't get properly
probed.

Fixes: 68bab8662f49 ("mfd: twl6040: Optional clk32k clock handling")
Cc: Benoit Cousson <bcousson@baylibre.com>
Cc: Dr. H. Nikolaus Schaller <hns@goldelico.com>
Cc: Grazvydas Ignotas <notasas@gmail.com>
Cc: Lee Jones <lee.jones@linaro.org>
Cc: Peter Ujfalusi <peter.ujfalusi@ti.com>
Cc: Samuel Ortiz <sameo@linux.intel.com>
Cc: Sourav Poddar <sourav.poddar@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
---
 drivers/mfd/twl6040.c | 2 ++
 1 file changed, 2 insertions(+)

--- a/drivers/mfd/twl6040.c
+++ b/drivers/mfd/twl6040.c
@@ -647,6 +647,8 @@ static int twl6040_probe(struct i2c_client *client,
 
 	twl6040->clk32k = devm_clk_get(&client->dev, "clk32k");
 	if (IS_ERR(twl6040->clk32k)) {
+		if (PTR_ERR(twl6040->clk32k) == -EPROBE_DEFER)
+			return -EPROBE_DEFER;
 		dev_info(&client->dev, "clk32k is not handled\n");
 		twl6040->clk32k = NULL;
 	}
-- 
2.1.4

[PATCH 2/2] ARM: dts: Fix WLAN regression on omap5-uevm

[Tony Lindgren]

Commit 99f84cae43df ("ARM: dts: add wl12xx/wl18xx bindings") added
device tree bindings for the TI WLAN SDIO on many omap variants.

I recall wondering how come omap5-uevm did not have the WLAN
added and this issue has been bugging me for a while now, and
I finally tracked it down to a bad pinmux regression, and a missing
deferred probe handling for the 32k clock from palmas that's
requested by twl6040.

Basically 392adaf796b9 ("ARM: dts: omap5-evm: Add mcspi data")
added pin muxing for mcspi4 that conflicts with the onboard
WLAN. While the omap5-uevm docs say the WLAN is not populated,
this was probably only the case for initial prototypes. Both
omap5-uevm boards I have have WLAN populated.

Let's fix the regression and add the WLAN configuration as
done for the other boards in 99f84cae43df ("ARM: dts: add
wl12xx/wl18xx bindings").

Note that without a related deferred probe fix for twl6040,
the 32k clock is not initialized if palmas-clk is a module
and twl6040 is built-in. And we should probably also request
the 32k clock from palmas directly for MMC3 eventually, but
that's another patch not related to this regression.

Let's also use the generic "non-removable" instead of the
legacy "ti,non-removable" property while at it.

Fixes: 392adaf796b9 ("ARM: dts: omap5-evm: Add mcspi data")
Cc: Benoit Cousson <bcousson@baylibre.com>
Cc: Dr. H. Nikolaus Schaller <hns@goldelico.com>
Cc: Grazvydas Ignotas <notasas@gmail.com>
Cc: Peter Ujfalusi <peter.ujfalusi@ti.com>
Cc: Sourav Poddar <sourav.poddar@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
---
 arch/arm/boot/dts/omap5-uevm.dts | 51 +++++++++++++++++++++++++++++++---------
 1 file changed, 40 insertions(+), 11 deletions(-)

--- a/arch/arm/boot/dts/omap5-uevm.dts
+++ b/arch/arm/boot/dts/omap5-uevm.dts
@@ -31,6 +31,18 @@
 		regulator-max-microvolt = <3000000>;
 	};
 
+	vmmcsdio_fixed: fixedregulator-mmcsdio {
+		compatible = "regulator-fixed";
+		regulator-name = "vmmcsdio_fixed";
+		regulator-min-microvolt = <1800000>;
+		regulator-max-microvolt = <1800000>;
+		gpio = <&gpio5 12 GPIO_ACTIVE_HIGH>;	/* gpio140 WLAN_EN */
+		enable-active-high;
+		startup-delay-us = <70000>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&wlan_pins>;
+	};
+
 	/* HS USB Host PHY on PORT 2 */
 	hsusb2_phy: hsusb2_phy {
 		compatible = "usb-nop-xceiv";
@@ -197,12 +209,20 @@
 		>;
 	};
 
-	mcspi4_pins: pinmux_mcspi4_pins {
+	mmc3_pins: pinmux_mmc3_pins {
 		pinctrl-single,pins = <
-			0x164 (PIN_INPUT | MUX_MODE1)		/*  mcspi4_clk */
-			0x168 (PIN_INPUT | MUX_MODE1)		/*  mcspi4_simo */
-			0x16a (PIN_INPUT | MUX_MODE1)		/*  mcspi4_somi */
-			0x16c (PIN_INPUT | MUX_MODE1)		/*  mcspi4_cs0 */
+			OMAP5_IOPAD(0x01a4, PIN_INPUT_PULLUP | MUX_MODE0) /* wlsdio_clk */
+			OMAP5_IOPAD(0x01a6, PIN_INPUT_PULLUP | MUX_MODE0) /* wlsdio_cmd */
+			OMAP5_IOPAD(0x01a8, PIN_INPUT_PULLUP | MUX_MODE0) /* wlsdio_data0 */
+			OMAP5_IOPAD(0x01aa, PIN_INPUT_PULLUP | MUX_MODE0) /* wlsdio_data1 */
+			OMAP5_IOPAD(0x01ac, PIN_INPUT_PULLUP | MUX_MODE0) /* wlsdio_data2 */
+			OMAP5_IOPAD(0x01ae, PIN_INPUT_PULLUP | MUX_MODE0) /* wlsdio_data3 */
+		>;
+	};
+
+	wlan_pins: pinmux_wlan_pins {
+		pinctrl-single,pins = <
+			OMAP5_IOPAD(0x1bc, PIN_OUTPUT | MUX_MODE6) /* mcspi1_clk.gpio5_140 */
 		>;
 	};
 
@@ -290,8 +310,22 @@
 };
 
 &mmc3 {
+	vmmc-supply = <&vmmcsdio_fixed>;
 	bus-width = <4>;
-	ti,non-removable;
+	non-removable;
+	cap-power-off-card;
+	pinctrl-names = "default";
+	pinctrl-0 = <&mmc3_pins>;
+
+	#address-cells = <1>;
+	#size-cells = <0>;
+	wlcore: wlcore@2 {
+		compatible = "ti,wl1271";
+		reg = <2>;
+		interrupt-parent = <&gpio1>;
+		interrupts = <14 IRQ_TYPE_LEVEL_HIGH>;	/* gpio 14 */
+		ref-clock-frequency = <26000000>;
+	};
 };
 
 &mmc4 {
@@ -598,11 +632,6 @@
 	pinctrl-0 = <&mcspi3_pins>;
 };
 
-&mcspi4 {
-	pinctrl-names = "default";
-	pinctrl-0 = <&mcspi4_pins>;
-};
-
 &uart1 {
 	pinctrl-names = "default";
 	pinctrl-0 = <&uart1_pins>;
-- 
2.1.4

[PATCH 2/2] ARM: dts: Fix WLAN regression on omap5-uevm

[Tony Lindgren]

Commit 99f84cae43df ("ARM: dts: add wl12xx/wl18xx bindings") added
device tree bindings for the TI WLAN SDIO on many omap variants.

I recall wondering how come omap5-uevm did not have the WLAN
added and this issue has been bugging me for a while now, and
I finally tracked it down to a bad pinmux regression, and a missing
deferred probe handling for the 32k clock from palmas that's
requested by twl6040.

Basically 392adaf796b9 ("ARM: dts: omap5-evm: Add mcspi data")
added pin muxing for mcspi4 that conflicts with the onboard
WLAN. While the omap5-uevm docs say the WLAN is not populated,
this was probably only the case for initial prototypes. Both
omap5-uevm boards I have have WLAN populated.

Let's fix the regression and add the WLAN configuration as
done for the other boards in 99f84cae43df ("ARM: dts: add
wl12xx/wl18xx bindings").

Note that without a related deferred probe fix for twl6040,
the 32k clock is not initialized if palmas-clk is a module
and twl6040 is built-in. And we should probably also request
the 32k clock from palmas directly for MMC3 eventually, but
that's another patch not related to this regression.

Let's also use the generic "non-removable" instead of the
legacy "ti,non-removable" property while at it.

Fixes: 392adaf796b9 ("ARM: dts: omap5-evm: Add mcspi data")
Cc: Benoit Cousson <bcousson@baylibre.com>
Cc: Dr. H. Nikolaus Schaller <hns@goldelico.com>
Cc: Grazvydas Ignotas <notasas@gmail.com>
Cc: Peter Ujfalusi <peter.ujfalusi@ti.com>
Cc: Sourav Poddar <sourav.poddar@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
---
 arch/arm/boot/dts/omap5-uevm.dts | 51 +++++++++++++++++++++++++++++++---------
 1 file changed, 40 insertions(+), 11 deletions(-)

--- a/arch/arm/boot/dts/omap5-uevm.dts
+++ b/arch/arm/boot/dts/omap5-uevm.dts
@@ -31,6 +31,18 @@
 		regulator-max-microvolt = <3000000>;
 	};
 
+	vmmcsdio_fixed: fixedregulator-mmcsdio {
+		compatible = "regulator-fixed";
+		regulator-name = "vmmcsdio_fixed";
+		regulator-min-microvolt = <1800000>;
+		regulator-max-microvolt = <1800000>;
+		gpio = <&gpio5 12 GPIO_ACTIVE_HIGH>;	/* gpio140 WLAN_EN */
+		enable-active-high;
+		startup-delay-us = <70000>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&wlan_pins>;
+	};
+
 	/* HS USB Host PHY on PORT 2 */
 	hsusb2_phy: hsusb2_phy {
 		compatible = "usb-nop-xceiv";
@@ -197,12 +209,20 @@
 		>;
 	};
 
-	mcspi4_pins: pinmux_mcspi4_pins {
+	mmc3_pins: pinmux_mmc3_pins {
 		pinctrl-single,pins = <
-			0x164 (PIN_INPUT | MUX_MODE1)		/*  mcspi4_clk */
-			0x168 (PIN_INPUT | MUX_MODE1)		/*  mcspi4_simo */
-			0x16a (PIN_INPUT | MUX_MODE1)		/*  mcspi4_somi */
-			0x16c (PIN_INPUT | MUX_MODE1)		/*  mcspi4_cs0 */
+			OMAP5_IOPAD(0x01a4, PIN_INPUT_PULLUP | MUX_MODE0) /* wlsdio_clk */
+			OMAP5_IOPAD(0x01a6, PIN_INPUT_PULLUP | MUX_MODE0) /* wlsdio_cmd */
+			OMAP5_IOPAD(0x01a8, PIN_INPUT_PULLUP | MUX_MODE0) /* wlsdio_data0 */
+			OMAP5_IOPAD(0x01aa, PIN_INPUT_PULLUP | MUX_MODE0) /* wlsdio_data1 */
+			OMAP5_IOPAD(0x01ac, PIN_INPUT_PULLUP | MUX_MODE0) /* wlsdio_data2 */
+			OMAP5_IOPAD(0x01ae, PIN_INPUT_PULLUP | MUX_MODE0) /* wlsdio_data3 */
+		>;
+	};
+
+	wlan_pins: pinmux_wlan_pins {
+		pinctrl-single,pins = <
+			OMAP5_IOPAD(0x1bc, PIN_OUTPUT | MUX_MODE6) /* mcspi1_clk.gpio5_140 */
 		>;
 	};
 
@@ -290,8 +310,22 @@
 };
 
 &mmc3 {
+	vmmc-supply = <&vmmcsdio_fixed>;
 	bus-width = <4>;
-	ti,non-removable;
+	non-removable;
+	cap-power-off-card;
+	pinctrl-names = "default";
+	pinctrl-0 = <&mmc3_pins>;
+
+	#address-cells = <1>;
+	#size-cells = <0>;
+	wlcore: wlcore at 2 {
+		compatible = "ti,wl1271";
+		reg = <2>;
+		interrupt-parent = <&gpio1>;
+		interrupts = <14 IRQ_TYPE_LEVEL_HIGH>;	/* gpio 14 */
+		ref-clock-frequency = <26000000>;
+	};
 };
 
 &mmc4 {
@@ -598,11 +632,6 @@
 	pinctrl-0 = <&mcspi3_pins>;
 };
 
-&mcspi4 {
-	pinctrl-names = "default";
-	pinctrl-0 = <&mcspi4_pins>;
-};
-
 &uart1 {
 	pinctrl-names = "default";
 	pinctrl-0 = <&uart1_pins>;
-- 
2.1.4

Re: [PATCH 1/2] mfd: twl6040: Fix deferred probe handling for clk32k

[Felipe Balbi]

[-- Attachment #1.1: Type: text/plain, Size: 2088 bytes --]

On Fri, Sep 18, 2015 at 09:29:04AM -0700, Tony Lindgren wrote:
> Commit 68bab8662f49 ("mfd: twl6040: Optional clk32k clock handling")
> added clock handling for the 32k clock from palmas-clk. However, that
> patch did not consider a typical situation where twl6040 is built-in,
> and palmas-clk is a loadable module like we have in omap2plus_defconfig.
> 
> If palmas-clk is not loaded before twl6040 probes, we will get a
> "clk32k is not handled" warning during booting. This means that any
> drivers relying on this clock will mysteriously fail, including
> omap5-uevm WLAN and audio.
> 
> Note that for WLAN, we probably should also eventually get
> the clk32kgaudio for MMC3 directly as that's shared between
> audio and WLAN SDIO at least for omap5-uevm. It seems the
> WLAN chip cannot get it as otherwise MMC3 won't get properly
> probed.
> 
> Fixes: 68bab8662f49 ("mfd: twl6040: Optional clk32k clock handling")
> Cc: Benoit Cousson <bcousson@baylibre.com>
> Cc: Dr. H. Nikolaus Schaller <hns@goldelico.com>
> Cc: Grazvydas Ignotas <notasas@gmail.com>
> Cc: Lee Jones <lee.jones@linaro.org>
> Cc: Peter Ujfalusi <peter.ujfalusi@ti.com>
> Cc: Samuel Ortiz <sameo@linux.intel.com>
> Cc: Sourav Poddar <sourav.poddar@ti.com>
> Signed-off-by: Tony Lindgren <tony@atomide.com>

Reviewed-by: Felipe Balbi <balbi@ti.com>

> ---
>  drivers/mfd/twl6040.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> --- a/drivers/mfd/twl6040.c
> +++ b/drivers/mfd/twl6040.c
> @@ -647,6 +647,8 @@ static int twl6040_probe(struct i2c_client *client,
>  
>  	twl6040->clk32k = devm_clk_get(&client->dev, "clk32k");
>  	if (IS_ERR(twl6040->clk32k)) {
> +		if (PTR_ERR(twl6040->clk32k) == -EPROBE_DEFER)
> +			return -EPROBE_DEFER;
>  		dev_info(&client->dev, "clk32k is not handled\n");
>  		twl6040->clk32k = NULL;
>  	}
> -- 
> 2.1.4
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
balbi

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH 1/2] mfd: twl6040: Fix deferred probe handling for clk32k

[Felipe Balbi]

On Fri, Sep 18, 2015 at 09:29:04AM -0700, Tony Lindgren wrote:
> Commit 68bab8662f49 ("mfd: twl6040: Optional clk32k clock handling")
> added clock handling for the 32k clock from palmas-clk. However, that
> patch did not consider a typical situation where twl6040 is built-in,
> and palmas-clk is a loadable module like we have in omap2plus_defconfig.
> 
> If palmas-clk is not loaded before twl6040 probes, we will get a
> "clk32k is not handled" warning during booting. This means that any
> drivers relying on this clock will mysteriously fail, including
> omap5-uevm WLAN and audio.
> 
> Note that for WLAN, we probably should also eventually get
> the clk32kgaudio for MMC3 directly as that's shared between
> audio and WLAN SDIO at least for omap5-uevm. It seems the
> WLAN chip cannot get it as otherwise MMC3 won't get properly
> probed.
> 
> Fixes: 68bab8662f49 ("mfd: twl6040: Optional clk32k clock handling")
> Cc: Benoit Cousson <bcousson@baylibre.com>
> Cc: Dr. H. Nikolaus Schaller <hns@goldelico.com>
> Cc: Grazvydas Ignotas <notasas@gmail.com>
> Cc: Lee Jones <lee.jones@linaro.org>
> Cc: Peter Ujfalusi <peter.ujfalusi@ti.com>
> Cc: Samuel Ortiz <sameo@linux.intel.com>
> Cc: Sourav Poddar <sourav.poddar@ti.com>
> Signed-off-by: Tony Lindgren <tony@atomide.com>

Reviewed-by: Felipe Balbi <balbi@ti.com>

> ---
>  drivers/mfd/twl6040.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> --- a/drivers/mfd/twl6040.c
> +++ b/drivers/mfd/twl6040.c
> @@ -647,6 +647,8 @@ static int twl6040_probe(struct i2c_client *client,
>  
>  	twl6040->clk32k = devm_clk_get(&client->dev, "clk32k");
>  	if (IS_ERR(twl6040->clk32k)) {
> +		if (PTR_ERR(twl6040->clk32k) == -EPROBE_DEFER)
> +			return -EPROBE_DEFER;
>  		dev_info(&client->dev, "clk32k is not handled\n");
>  		twl6040->clk32k = NULL;
>  	}
> -- 
> 2.1.4
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150918/f0cc02d5/attachment.sig>

Re: [PATCH 2/2] ARM: dts: Fix WLAN regression on omap5-uevm

[Robert Nelson]

On Fri, Sep 18, 2015 at 11:29 AM, Tony Lindgren <tony@atomide.com> wrote:
> Commit 99f84cae43df ("ARM: dts: add wl12xx/wl18xx bindings") added
> device tree bindings for the TI WLAN SDIO on many omap variants.
>
> I recall wondering how come omap5-uevm did not have the WLAN
> added and this issue has been bugging me for a while now, and
> I finally tracked it down to a bad pinmux regression, and a missing
> deferred probe handling for the 32k clock from palmas that's
> requested by twl6040.
>
> Basically 392adaf796b9 ("ARM: dts: omap5-evm: Add mcspi data")
> added pin muxing for mcspi4 that conflicts with the onboard
> WLAN. While the omap5-uevm docs say the WLAN is not populated,
> this was probably only the case for initial prototypes. Both
> omap5-uevm boards I have have WLAN populated.

Production boards from svtronics don't populate the wlan..

http://www.svtronics.com/EVM/OMAP5432/5432

quote: "WiFi not available on this model"

They have an option to order a version with a "COM8Q" connector to add wlan...

http://www.svtronics.com/EVM/OMAP5432/5432C

http://www.svtronics.com/EVM/OMAP5432/COM8Q

I'm not sure who to bug from that era, but the wlan populated devices
might have been prototype only.

Regards,

-- 
Robert Nelson
https://rcn-ee.com/

[PATCH 2/2] ARM: dts: Fix WLAN regression on omap5-uevm

[Robert Nelson]

On Fri, Sep 18, 2015 at 11:29 AM, Tony Lindgren <tony@atomide.com> wrote:
> Commit 99f84cae43df ("ARM: dts: add wl12xx/wl18xx bindings") added
> device tree bindings for the TI WLAN SDIO on many omap variants.
>
> I recall wondering how come omap5-uevm did not have the WLAN
> added and this issue has been bugging me for a while now, and
> I finally tracked it down to a bad pinmux regression, and a missing
> deferred probe handling for the 32k clock from palmas that's
> requested by twl6040.
>
> Basically 392adaf796b9 ("ARM: dts: omap5-evm: Add mcspi data")
> added pin muxing for mcspi4 that conflicts with the onboard
> WLAN. While the omap5-uevm docs say the WLAN is not populated,
> this was probably only the case for initial prototypes. Both
> omap5-uevm boards I have have WLAN populated.

Production boards from svtronics don't populate the wlan..

http://www.svtronics.com/EVM/OMAP5432/5432

quote: "WiFi not available on this model"

They have an option to order a version with a "COM8Q" connector to add wlan...

http://www.svtronics.com/EVM/OMAP5432/5432C

http://www.svtronics.com/EVM/OMAP5432/COM8Q

I'm not sure who to bug from that era, but the wlan populated devices
might have been prototype only.

Regards,

-- 
Robert Nelson
https://rcn-ee.com/

Re: [PATCH 2/2] ARM: dts: Fix WLAN regression on omap5-uevm

[Tony Lindgren]

* Robert Nelson <robertcnelson@gmail.com> [150918 09:45]:
> On Fri, Sep 18, 2015 at 11:29 AM, Tony Lindgren <tony@atomide.com> wrote:
> > Commit 99f84cae43df ("ARM: dts: add wl12xx/wl18xx bindings") added
> > device tree bindings for the TI WLAN SDIO on many omap variants.
> >
> > I recall wondering how come omap5-uevm did not have the WLAN
> > added and this issue has been bugging me for a while now, and
> > I finally tracked it down to a bad pinmux regression, and a missing
> > deferred probe handling for the 32k clock from palmas that's
> > requested by twl6040.
> >
> > Basically 392adaf796b9 ("ARM: dts: omap5-evm: Add mcspi data")
> > added pin muxing for mcspi4 that conflicts with the onboard
> > WLAN. While the omap5-uevm docs say the WLAN is not populated,
> > this was probably only the case for initial prototypes. Both
> > omap5-uevm boards I have have WLAN populated.
> 
> Production boards from svtronics don't populate the wlan..
> 
> http://www.svtronics.com/EVM/OMAP5432/5432
> 
> quote: "WiFi not available on this model"
> 
> They have an option to order a version with a "COM8Q" connector to add wlan...

Oh OK interesting.

> http://www.svtronics.com/EVM/OMAP5432/5432C
> 
> http://www.svtronics.com/EVM/OMAP5432/COM8Q
> 
> I'm not sure who to bug from that era, but the wlan populated devices
> might have been prototype only.

Hmm OK. Well as it's a SDIO card, it seems safe to add for now.
We may want to have a minimal separate dts file if the wiring is
different with the COM8Q card.

Regards,

Tony

[PATCH 2/2] ARM: dts: Fix WLAN regression on omap5-uevm

[Tony Lindgren]

* Robert Nelson <robertcnelson@gmail.com> [150918 09:45]:
> On Fri, Sep 18, 2015 at 11:29 AM, Tony Lindgren <tony@atomide.com> wrote:
> > Commit 99f84cae43df ("ARM: dts: add wl12xx/wl18xx bindings") added
> > device tree bindings for the TI WLAN SDIO on many omap variants.
> >
> > I recall wondering how come omap5-uevm did not have the WLAN
> > added and this issue has been bugging me for a while now, and
> > I finally tracked it down to a bad pinmux regression, and a missing
> > deferred probe handling for the 32k clock from palmas that's
> > requested by twl6040.
> >
> > Basically 392adaf796b9 ("ARM: dts: omap5-evm: Add mcspi data")
> > added pin muxing for mcspi4 that conflicts with the onboard
> > WLAN. While the omap5-uevm docs say the WLAN is not populated,
> > this was probably only the case for initial prototypes. Both
> > omap5-uevm boards I have have WLAN populated.
> 
> Production boards from svtronics don't populate the wlan..
> 
> http://www.svtronics.com/EVM/OMAP5432/5432
> 
> quote: "WiFi not available on this model"
> 
> They have an option to order a version with a "COM8Q" connector to add wlan...

Oh OK interesting.

> http://www.svtronics.com/EVM/OMAP5432/5432C
> 
> http://www.svtronics.com/EVM/OMAP5432/COM8Q
> 
> I'm not sure who to bug from that era, but the wlan populated devices
> might have been prototype only.

Hmm OK. Well as it's a SDIO card, it seems safe to add for now.
We may want to have a minimal separate dts file if the wiring is
different with the COM8Q card.

Regards,

Tony

Re: [PATCH 2/2] ARM: dts: Fix WLAN regression on omap5-uevm

[Tony Lindgren]

* Tony Lindgren <tony@atomide.com> [150918 09:55]:
> * Robert Nelson <robertcnelson@gmail.com> [150918 09:45]:
> > On Fri, Sep 18, 2015 at 11:29 AM, Tony Lindgren <tony@atomide.com> wrote:
> > > Commit 99f84cae43df ("ARM: dts: add wl12xx/wl18xx bindings") added
> > > device tree bindings for the TI WLAN SDIO on many omap variants.
> > >
> > > I recall wondering how come omap5-uevm did not have the WLAN
> > > added and this issue has been bugging me for a while now, and
> > > I finally tracked it down to a bad pinmux regression, and a missing
> > > deferred probe handling for the 32k clock from palmas that's
> > > requested by twl6040.
> > >
> > > Basically 392adaf796b9 ("ARM: dts: omap5-evm: Add mcspi data")
> > > added pin muxing for mcspi4 that conflicts with the onboard
> > > WLAN. While the omap5-uevm docs say the WLAN is not populated,
> > > this was probably only the case for initial prototypes. Both
> > > omap5-uevm boards I have have WLAN populated.
> > 
> > Production boards from svtronics don't populate the wlan..
> > 
> > http://www.svtronics.com/EVM/OMAP5432/5432
> > 
> > quote: "WiFi not available on this model"
> > 
> > They have an option to order a version with a "COM8Q" connector to add wlan...
> 
> Oh OK interesting.
> 
> > http://www.svtronics.com/EVM/OMAP5432/5432C
> > 
> > http://www.svtronics.com/EVM/OMAP5432/COM8Q
> > 
> > I'm not sure who to bug from that era, but the wlan populated devices
> > might have been prototype only.
> 
> Hmm OK. Well as it's a SDIO card, it seems safe to add for now.
> We may want to have a minimal separate dts file if the wiring is
> different with the COM8Q card.

Also I just noticed that WLAN will work with these only if omap_hsmmc
is a loadable module. That's probably because we're not yet claiming
the 32k clock for MMC3 directly yet. But that's a separate patch.

Regards,

Tony

[PATCH 2/2] ARM: dts: Fix WLAN regression on omap5-uevm

[Tony Lindgren]

* Tony Lindgren <tony@atomide.com> [150918 09:55]:
> * Robert Nelson <robertcnelson@gmail.com> [150918 09:45]:
> > On Fri, Sep 18, 2015 at 11:29 AM, Tony Lindgren <tony@atomide.com> wrote:
> > > Commit 99f84cae43df ("ARM: dts: add wl12xx/wl18xx bindings") added
> > > device tree bindings for the TI WLAN SDIO on many omap variants.
> > >
> > > I recall wondering how come omap5-uevm did not have the WLAN
> > > added and this issue has been bugging me for a while now, and
> > > I finally tracked it down to a bad pinmux regression, and a missing
> > > deferred probe handling for the 32k clock from palmas that's
> > > requested by twl6040.
> > >
> > > Basically 392adaf796b9 ("ARM: dts: omap5-evm: Add mcspi data")
> > > added pin muxing for mcspi4 that conflicts with the onboard
> > > WLAN. While the omap5-uevm docs say the WLAN is not populated,
> > > this was probably only the case for initial prototypes. Both
> > > omap5-uevm boards I have have WLAN populated.
> > 
> > Production boards from svtronics don't populate the wlan..
> > 
> > http://www.svtronics.com/EVM/OMAP5432/5432
> > 
> > quote: "WiFi not available on this model"
> > 
> > They have an option to order a version with a "COM8Q" connector to add wlan...
> 
> Oh OK interesting.
> 
> > http://www.svtronics.com/EVM/OMAP5432/5432C
> > 
> > http://www.svtronics.com/EVM/OMAP5432/COM8Q
> > 
> > I'm not sure who to bug from that era, but the wlan populated devices
> > might have been prototype only.
> 
> Hmm OK. Well as it's a SDIO card, it seems safe to add for now.
> We may want to have a minimal separate dts file if the wiring is
> different with the COM8Q card.

Also I just noticed that WLAN will work with these only if omap_hsmmc
is a loadable module. That's probably because we're not yet claiming
the 32k clock for MMC3 directly yet. But that's a separate patch.

Regards,

Tony

Re: [PATCH 2/2] ARM: dts: Fix WLAN regression on omap5-uevm

[Javier Martinez Canillas]

Hello Tony,

[snip]

>
> +       vmmcsdio_fixed: fixedregulator-mmcsdio {
> +               compatible = "regulator-fixed";
> +               regulator-name = "vmmcsdio_fixed";
> +               regulator-min-microvolt = <1800000>;
> +               regulator-max-microvolt = <1800000>;
> +               gpio = <&gpio5 12 GPIO_ACTIVE_HIGH>;    /* gpio140 WLAN_EN */

I know that other OMAP boards use a fake fixed regulator to toggle the
WiFi enable pin but now the MMC subsystem has proper support for power
sequence providers so that should be used instead. For simple uses
like this, Documentation/devicetree/bindings/mmc/mmc-pwrseq-simple.txt
should be enough.

Best regards,
Javier

[PATCH 2/2] ARM: dts: Fix WLAN regression on omap5-uevm

[Javier Martinez Canillas]

Hello Tony,

[snip]

>
> +       vmmcsdio_fixed: fixedregulator-mmcsdio {
> +               compatible = "regulator-fixed";
> +               regulator-name = "vmmcsdio_fixed";
> +               regulator-min-microvolt = <1800000>;
> +               regulator-max-microvolt = <1800000>;
> +               gpio = <&gpio5 12 GPIO_ACTIVE_HIGH>;    /* gpio140 WLAN_EN */

I know that other OMAP boards use a fake fixed regulator to toggle the
WiFi enable pin but now the MMC subsystem has proper support for power
sequence providers so that should be used instead. For simple uses
like this, Documentation/devicetree/bindings/mmc/mmc-pwrseq-simple.txt
should be enough.

Best regards,
Javier

Re: [PATCH 2/2] ARM: dts: Fix WLAN regression on omap5-uevm

[Tony Lindgren]

* Javier Martinez Canillas <javier@dowhile0.org> [150918 10:39]:
> Hello Tony,
> 
> [snip]
> 
> >
> > +       vmmcsdio_fixed: fixedregulator-mmcsdio {
> > +               compatible = "regulator-fixed";
> > +               regulator-name = "vmmcsdio_fixed";
> > +               regulator-min-microvolt = <1800000>;
> > +               regulator-max-microvolt = <1800000>;
> > +               gpio = <&gpio5 12 GPIO_ACTIVE_HIGH>;    /* gpio140 WLAN_EN */
> 
> I know that other OMAP boards use a fake fixed regulator to toggle the
> WiFi enable pin but now the MMC subsystem has proper support for power
> sequence providers so that should be used instead. For simple uses
> like this, Documentation/devicetree/bindings/mmc/mmc-pwrseq-simple.txt
> should be enough.

Hmm OK great, I'll take a look. Looks like that might also provide a
nice solution for handling the 32k clock from palmas to the wl12xx.

In the wl12xx case it's a real regulator on wl12xx though, not a fake.
It gets the power directly from VBAT and generates it's own clocks..
Of course nobody knows what the chip is actually doing with the GPIO
pin, it's probably just a hint to some wl12xx internal state machine.

Regards,

Tony

[PATCH 2/2] ARM: dts: Fix WLAN regression on omap5-uevm

[Tony Lindgren]

* Javier Martinez Canillas <javier@dowhile0.org> [150918 10:39]:
> Hello Tony,
> 
> [snip]
> 
> >
> > +       vmmcsdio_fixed: fixedregulator-mmcsdio {
> > +               compatible = "regulator-fixed";
> > +               regulator-name = "vmmcsdio_fixed";
> > +               regulator-min-microvolt = <1800000>;
> > +               regulator-max-microvolt = <1800000>;
> > +               gpio = <&gpio5 12 GPIO_ACTIVE_HIGH>;    /* gpio140 WLAN_EN */
> 
> I know that other OMAP boards use a fake fixed regulator to toggle the
> WiFi enable pin but now the MMC subsystem has proper support for power
> sequence providers so that should be used instead. For simple uses
> like this, Documentation/devicetree/bindings/mmc/mmc-pwrseq-simple.txt
> should be enough.

Hmm OK great, I'll take a look. Looks like that might also provide a
nice solution for handling the 32k clock from palmas to the wl12xx.

In the wl12xx case it's a real regulator on wl12xx though, not a fake.
It gets the power directly from VBAT and generates it's own clocks..
Of course nobody knows what the chip is actually doing with the GPIO
pin, it's probably just a hint to some wl12xx internal state machine.

Regards,

Tony

Re: [PATCH 2/2] ARM: dts: Fix WLAN regression on omap5-uevm

[Robert Nelson]

On Fri, Sep 18, 2015 at 11:51 AM, Tony Lindgren <tony@atomide.com> wrote:
> * Robert Nelson <robertcnelson@gmail.com> [150918 09:45]:
>> On Fri, Sep 18, 2015 at 11:29 AM, Tony Lindgren <tony@atomide.com> wrote:
>> > Commit 99f84cae43df ("ARM: dts: add wl12xx/wl18xx bindings") added
>> > device tree bindings for the TI WLAN SDIO on many omap variants.
>> >
>> > I recall wondering how come omap5-uevm did not have the WLAN
>> > added and this issue has been bugging me for a while now, and
>> > I finally tracked it down to a bad pinmux regression, and a missing
>> > deferred probe handling for the 32k clock from palmas that's
>> > requested by twl6040.
>> >
>> > Basically 392adaf796b9 ("ARM: dts: omap5-evm: Add mcspi data")
>> > added pin muxing for mcspi4 that conflicts with the onboard
>> > WLAN. While the omap5-uevm docs say the WLAN is not populated,
>> > this was probably only the case for initial prototypes. Both
>> > omap5-uevm boards I have have WLAN populated.
>>
>> Production boards from svtronics don't populate the wlan..
>>
>> http://www.svtronics.com/EVM/OMAP5432/5432
>>
>> quote: "WiFi not available on this model"

Okay, got an email back from svtronics, there was a special omap5_uevm
+ wlan order option for production units.

>>
>> They have an option to order a version with a "COM8Q" connector to add wlan...
>
> Oh OK interesting.
>
>> http://www.svtronics.com/EVM/OMAP5432/5432C
>>
>> http://www.svtronics.com/EVM/OMAP5432/COM8Q
>>
>> I'm not sure who to bug from that era, but the wlan populated devices
>> might have been prototype only.
>
> Hmm OK. Well as it's a SDIO card, it seems safe to add for now.
> We may want to have a minimal separate dts file if the wiring is
> different with the COM8Q card.

Well we can take care of that as an device tree overlay. ;)

Regards,

-- 
Robert Nelson
https://rcn-ee.com/

[PATCH 2/2] ARM: dts: Fix WLAN regression on omap5-uevm

[Robert Nelson]

On Fri, Sep 18, 2015 at 11:51 AM, Tony Lindgren <tony@atomide.com> wrote:
> * Robert Nelson <robertcnelson@gmail.com> [150918 09:45]:
>> On Fri, Sep 18, 2015 at 11:29 AM, Tony Lindgren <tony@atomide.com> wrote:
>> > Commit 99f84cae43df ("ARM: dts: add wl12xx/wl18xx bindings") added
>> > device tree bindings for the TI WLAN SDIO on many omap variants.
>> >
>> > I recall wondering how come omap5-uevm did not have the WLAN
>> > added and this issue has been bugging me for a while now, and
>> > I finally tracked it down to a bad pinmux regression, and a missing
>> > deferred probe handling for the 32k clock from palmas that's
>> > requested by twl6040.
>> >
>> > Basically 392adaf796b9 ("ARM: dts: omap5-evm: Add mcspi data")
>> > added pin muxing for mcspi4 that conflicts with the onboard
>> > WLAN. While the omap5-uevm docs say the WLAN is not populated,
>> > this was probably only the case for initial prototypes. Both
>> > omap5-uevm boards I have have WLAN populated.
>>
>> Production boards from svtronics don't populate the wlan..
>>
>> http://www.svtronics.com/EVM/OMAP5432/5432
>>
>> quote: "WiFi not available on this model"

Okay, got an email back from svtronics, there was a special omap5_uevm
+ wlan order option for production units.

>>
>> They have an option to order a version with a "COM8Q" connector to add wlan...
>
> Oh OK interesting.
>
>> http://www.svtronics.com/EVM/OMAP5432/5432C
>>
>> http://www.svtronics.com/EVM/OMAP5432/COM8Q
>>
>> I'm not sure who to bug from that era, but the wlan populated devices
>> might have been prototype only.
>
> Hmm OK. Well as it's a SDIO card, it seems safe to add for now.
> We may want to have a minimal separate dts file if the wiring is
> different with the COM8Q card.

Well we can take care of that as an device tree overlay. ;)

Regards,

-- 
Robert Nelson
https://rcn-ee.com/

Re: [PATCH 2/2] ARM: dts: Fix WLAN regression on omap5-uevm

[Tony Lindgren]

* Tony Lindgren <tony@atomide.com> [150918 10:54]:
> * Javier Martinez Canillas <javier@dowhile0.org> [150918 10:39]:
> > Hello Tony,
> > 
> > [snip]
> > 
> > >
> > > +       vmmcsdio_fixed: fixedregulator-mmcsdio {
> > > +               compatible = "regulator-fixed";
> > > +               regulator-name = "vmmcsdio_fixed";
> > > +               regulator-min-microvolt = <1800000>;
> > > +               regulator-max-microvolt = <1800000>;
> > > +               gpio = <&gpio5 12 GPIO_ACTIVE_HIGH>;    /* gpio140 WLAN_EN */
> > 
> > I know that other OMAP boards use a fake fixed regulator to toggle the
> > WiFi enable pin but now the MMC subsystem has proper support for power
> > sequence providers so that should be used instead. For simple uses
> > like this, Documentation/devicetree/bindings/mmc/mmc-pwrseq-simple.txt
> > should be enough.
> 
> Hmm OK great, I'll take a look. Looks like that might also provide a
> nice solution for handling the 32k clock from palmas to the wl12xx.

It seems it's not quite working yet.. It seems pwrseq_simple.c can't
deal with delay on a power pin. It might be best to treat those using
the regulator framework because of the refcounting and start-up delay.
I don't think also having regulator handling in pwrseq_simple.c
conflicts with the MMC regulators as they can be separate?

Also not related to wl12xx, the power pin on mwifiex_sdio 8787 wlan
must be asserted low while reset is asserted and must stay low for
300ms after power pin has deasserted. Again using a regulator there
for the power pin might make more sense.

Then getting the 32k clock from palmas is not working either, it
seems some better deferred probe handling is needed there if
omap_hsmmc is built-in and palmas-clk is a loadable module.

I think for the fix I'll stick with regulator fixed, let's update
it later on unless you have better suggestions.

And also.. It seems wl18xx somehow keeps looing for a wrong

Cheers,

Tony

[PATCH 2/2] ARM: dts: Fix WLAN regression on omap5-uevm

[Tony Lindgren]

* Tony Lindgren <tony@atomide.com> [150918 10:54]:
> * Javier Martinez Canillas <javier@dowhile0.org> [150918 10:39]:
> > Hello Tony,
> > 
> > [snip]
> > 
> > >
> > > +       vmmcsdio_fixed: fixedregulator-mmcsdio {
> > > +               compatible = "regulator-fixed";
> > > +               regulator-name = "vmmcsdio_fixed";
> > > +               regulator-min-microvolt = <1800000>;
> > > +               regulator-max-microvolt = <1800000>;
> > > +               gpio = <&gpio5 12 GPIO_ACTIVE_HIGH>;    /* gpio140 WLAN_EN */
> > 
> > I know that other OMAP boards use a fake fixed regulator to toggle the
> > WiFi enable pin but now the MMC subsystem has proper support for power
> > sequence providers so that should be used instead. For simple uses
> > like this, Documentation/devicetree/bindings/mmc/mmc-pwrseq-simple.txt
> > should be enough.
> 
> Hmm OK great, I'll take a look. Looks like that might also provide a
> nice solution for handling the 32k clock from palmas to the wl12xx.

It seems it's not quite working yet.. It seems pwrseq_simple.c can't
deal with delay on a power pin. It might be best to treat those using
the regulator framework because of the refcounting and start-up delay.
I don't think also having regulator handling in pwrseq_simple.c
conflicts with the MMC regulators as they can be separate?

Also not related to wl12xx, the power pin on mwifiex_sdio 8787 wlan
must be asserted low while reset is asserted and must stay low for
300ms after power pin has deasserted. Again using a regulator there
for the power pin might make more sense.

Then getting the 32k clock from palmas is not working either, it
seems some better deferred probe handling is needed there if
omap_hsmmc is built-in and palmas-clk is a loadable module.

I think for the fix I'll stick with regulator fixed, let's update
it later on unless you have better suggestions.

And also.. It seems wl18xx somehow keeps looing for a wrong

Cheers,

Tony

Re: [PATCH 2/2] ARM: dts: Fix WLAN regression on omap5-uevm

[Tony Lindgren]

* Tony Lindgren <tony@atomide.com> [150918 13:27]:

> And also.. It seems wl18xx somehow keeps looing for a wrong

Sorry sent the email before finishing it :) Note related to
these patches, but the wl18xx keeps looking for wrong firmware
and produces the following:

# modprobe wlcore_sdio
...
wlcore: ERROR configuration binary file size is wrong, expected 1229 got 1221
wlcore: WARNING falling back to default config
wlcore: wl18xx HW: 183x or 180x, PG 2.0 (ROM 0x9)
wlcore: loaded

So that's yet another bug to fix somewhere.

Regards,

Tony

[PATCH 2/2] ARM: dts: Fix WLAN regression on omap5-uevm

[Tony Lindgren]

* Tony Lindgren <tony@atomide.com> [150918 13:27]:

> And also.. It seems wl18xx somehow keeps looing for a wrong

Sorry sent the email before finishing it :) Note related to
these patches, but the wl18xx keeps looking for wrong firmware
and produces the following:

# modprobe wlcore_sdio
...
wlcore: ERROR configuration binary file size is wrong, expected 1229 got 1221
wlcore: WARNING falling back to default config
wlcore: wl18xx HW: 183x or 180x, PG 2.0 (ROM 0x9)
wlcore: loaded

So that's yet another bug to fix somewhere.

Regards,

Tony

Re: [PATCH 1/2] mfd: twl6040: Fix deferred probe handling for clk32k

[Lee Jones]

On Fri, 18 Sep 2015, Tony Lindgren wrote:

> Commit 68bab8662f49 ("mfd: twl6040: Optional clk32k clock handling")
> added clock handling for the 32k clock from palmas-clk. However, that
> patch did not consider a typical situation where twl6040 is built-in,
> and palmas-clk is a loadable module like we have in omap2plus_defconfig.
> 
> If palmas-clk is not loaded before twl6040 probes, we will get a
> "clk32k is not handled" warning during booting. This means that any
> drivers relying on this clock will mysteriously fail, including
> omap5-uevm WLAN and audio.
> 
> Note that for WLAN, we probably should also eventually get
> the clk32kgaudio for MMC3 directly as that's shared between
> audio and WLAN SDIO at least for omap5-uevm. It seems the
> WLAN chip cannot get it as otherwise MMC3 won't get properly
> probed.
> 
> Fixes: 68bab8662f49 ("mfd: twl6040: Optional clk32k clock handling")
> Cc: Benoit Cousson <bcousson@baylibre.com>
> Cc: Dr. H. Nikolaus Schaller <hns@goldelico.com>
> Cc: Grazvydas Ignotas <notasas@gmail.com>
> Cc: Lee Jones <lee.jones@linaro.org>
> Cc: Peter Ujfalusi <peter.ujfalusi@ti.com>
> Cc: Samuel Ortiz <sameo@linux.intel.com>
> Cc: Sourav Poddar <sourav.poddar@ti.com>
> Signed-off-by: Tony Lindgren <tony@atomide.com>
> ---
>  drivers/mfd/twl6040.c | 2 ++
>  1 file changed, 2 insertions(+)

Applied, thanks.

> --- a/drivers/mfd/twl6040.c
> +++ b/drivers/mfd/twl6040.c
> @@ -647,6 +647,8 @@ static int twl6040_probe(struct i2c_client *client,
>  
>  	twl6040->clk32k = devm_clk_get(&client->dev, "clk32k");
>  	if (IS_ERR(twl6040->clk32k)) {
> +		if (PTR_ERR(twl6040->clk32k) == -EPROBE_DEFER)
> +			return -EPROBE_DEFER;
>  		dev_info(&client->dev, "clk32k is not handled\n");
>  		twl6040->clk32k = NULL;
>  	}

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH 1/2] mfd: twl6040: Fix deferred probe handling for clk32k

[Lee Jones]

On Fri, 18 Sep 2015, Tony Lindgren wrote:

> Commit 68bab8662f49 ("mfd: twl6040: Optional clk32k clock handling")
> added clock handling for the 32k clock from palmas-clk. However, that
> patch did not consider a typical situation where twl6040 is built-in,
> and palmas-clk is a loadable module like we have in omap2plus_defconfig.
> 
> If palmas-clk is not loaded before twl6040 probes, we will get a
> "clk32k is not handled" warning during booting. This means that any
> drivers relying on this clock will mysteriously fail, including
> omap5-uevm WLAN and audio.
> 
> Note that for WLAN, we probably should also eventually get
> the clk32kgaudio for MMC3 directly as that's shared between
> audio and WLAN SDIO at least for omap5-uevm. It seems the
> WLAN chip cannot get it as otherwise MMC3 won't get properly
> probed.
> 
> Fixes: 68bab8662f49 ("mfd: twl6040: Optional clk32k clock handling")
> Cc: Benoit Cousson <bcousson@baylibre.com>
> Cc: Dr. H. Nikolaus Schaller <hns@goldelico.com>
> Cc: Grazvydas Ignotas <notasas@gmail.com>
> Cc: Lee Jones <lee.jones@linaro.org>
> Cc: Peter Ujfalusi <peter.ujfalusi@ti.com>
> Cc: Samuel Ortiz <sameo@linux.intel.com>
> Cc: Sourav Poddar <sourav.poddar@ti.com>
> Signed-off-by: Tony Lindgren <tony@atomide.com>
> ---
>  drivers/mfd/twl6040.c | 2 ++
>  1 file changed, 2 insertions(+)

Applied, thanks.

> --- a/drivers/mfd/twl6040.c
> +++ b/drivers/mfd/twl6040.c
> @@ -647,6 +647,8 @@ static int twl6040_probe(struct i2c_client *client,
>  
>  	twl6040->clk32k = devm_clk_get(&client->dev, "clk32k");
>  	if (IS_ERR(twl6040->clk32k)) {
> +		if (PTR_ERR(twl6040->clk32k) == -EPROBE_DEFER)
> +			return -EPROBE_DEFER;
>  		dev_info(&client->dev, "clk32k is not handled\n");
>  		twl6040->clk32k = NULL;
>  	}

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH 2/2] ARM: dts: Fix WLAN regression on omap5-uevm

[Grazvydas Ignotas]

On Fri, Sep 18, 2015 at 9:39 PM, Robert Nelson <robertcnelson@gmail.com> wrote:
> On Fri, Sep 18, 2015 at 11:51 AM, Tony Lindgren <tony@atomide.com> wrote:
>> * Robert Nelson <robertcnelson@gmail.com> [150918 09:45]:
>>> On Fri, Sep 18, 2015 at 11:29 AM, Tony Lindgren <tony@atomide.com> wrote:
>>> > Commit 99f84cae43df ("ARM: dts: add wl12xx/wl18xx bindings") added
>>> > device tree bindings for the TI WLAN SDIO on many omap variants.
>>> >
>>> > I recall wondering how come omap5-uevm did not have the WLAN
>>> > added and this issue has been bugging me for a while now, and
>>> > I finally tracked it down to a bad pinmux regression, and a missing
>>> > deferred probe handling for the 32k clock from palmas that's
>>> > requested by twl6040.
>>> >
>>> > Basically 392adaf796b9 ("ARM: dts: omap5-evm: Add mcspi data")
>>> > added pin muxing for mcspi4 that conflicts with the onboard
>>> > WLAN. While the omap5-uevm docs say the WLAN is not populated,
>>> > this was probably only the case for initial prototypes. Both
>>> > omap5-uevm boards I have have WLAN populated.
>>>
>>> Production boards from svtronics don't populate the wlan..
>>>
>>> http://www.svtronics.com/EVM/OMAP5432/5432
>>>
>>> quote: "WiFi not available on this model"
>
> Okay, got an email back from svtronics, there was a special omap5_uevm
> + wlan order option for production units.

The boards we bought came without wlan, so that seems to be the
"default" configuration.

I vote for using separate DT overlay for the wlan version to avoid
unnecessary probing. OTOH the pins are not exposed on expansion
connectors and should not conflict with custom peripherals, so no
strong opinion here.

Gražvydas

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH 2/2] ARM: dts: Fix WLAN regression on omap5-uevm

[Grazvydas Ignotas]

On Fri, Sep 18, 2015 at 9:39 PM, Robert Nelson <robertcnelson@gmail.com> wrote:
> On Fri, Sep 18, 2015 at 11:51 AM, Tony Lindgren <tony@atomide.com> wrote:
>> * Robert Nelson <robertcnelson@gmail.com> [150918 09:45]:
>>> On Fri, Sep 18, 2015 at 11:29 AM, Tony Lindgren <tony@atomide.com> wrote:
>>> > Commit 99f84cae43df ("ARM: dts: add wl12xx/wl18xx bindings") added
>>> > device tree bindings for the TI WLAN SDIO on many omap variants.
>>> >
>>> > I recall wondering how come omap5-uevm did not have the WLAN
>>> > added and this issue has been bugging me for a while now, and
>>> > I finally tracked it down to a bad pinmux regression, and a missing
>>> > deferred probe handling for the 32k clock from palmas that's
>>> > requested by twl6040.
>>> >
>>> > Basically 392adaf796b9 ("ARM: dts: omap5-evm: Add mcspi data")
>>> > added pin muxing for mcspi4 that conflicts with the onboard
>>> > WLAN. While the omap5-uevm docs say the WLAN is not populated,
>>> > this was probably only the case for initial prototypes. Both
>>> > omap5-uevm boards I have have WLAN populated.
>>>
>>> Production boards from svtronics don't populate the wlan..
>>>
>>> http://www.svtronics.com/EVM/OMAP5432/5432
>>>
>>> quote: "WiFi not available on this model"
>
> Okay, got an email back from svtronics, there was a special omap5_uevm
> + wlan order option for production units.

The boards we bought came without wlan, so that seems to be the
"default" configuration.

I vote for using separate DT overlay for the wlan version to avoid
unnecessary probing. OTOH the pins are not exposed on expansion
connectors and should not conflict with custom peripherals, so no
strong opinion here.

Gra?vydas

Re: [PATCH 2/2] ARM: dts: Fix WLAN regression on omap5-uevm

[Tony Lindgren]

* Grazvydas Ignotas <notasas@gmail.com> [150919 14:16]:
> On Fri, Sep 18, 2015 at 9:39 PM, Robert Nelson <robertcnelson@gmail.com> wrote:
> > On Fri, Sep 18, 2015 at 11:51 AM, Tony Lindgren <tony@atomide.com> wrote:
> >> * Robert Nelson <robertcnelson@gmail.com> [150918 09:45]:
> >>> On Fri, Sep 18, 2015 at 11:29 AM, Tony Lindgren <tony@atomide.com> wrote:
> >>> > Commit 99f84cae43df ("ARM: dts: add wl12xx/wl18xx bindings") added
> >>> > device tree bindings for the TI WLAN SDIO on many omap variants.
> >>> >
> >>> > I recall wondering how come omap5-uevm did not have the WLAN
> >>> > added and this issue has been bugging me for a while now, and
> >>> > I finally tracked it down to a bad pinmux regression, and a missing
> >>> > deferred probe handling for the 32k clock from palmas that's
> >>> > requested by twl6040.
> >>> >
> >>> > Basically 392adaf796b9 ("ARM: dts: omap5-evm: Add mcspi data")
> >>> > added pin muxing for mcspi4 that conflicts with the onboard
> >>> > WLAN. While the omap5-uevm docs say the WLAN is not populated,
> >>> > this was probably only the case for initial prototypes. Both
> >>> > omap5-uevm boards I have have WLAN populated.
> >>>
> >>> Production boards from svtronics don't populate the wlan..
> >>>
> >>> http://www.svtronics.com/EVM/OMAP5432/5432
> >>>
> >>> quote: "WiFi not available on this model"
> >
> > Okay, got an email back from svtronics, there was a special omap5_uevm
> > + wlan order option for production units.
> 
> The boards we bought came without wlan, so that seems to be the
> "default" configuration.
> 
> I vote for using separate DT overlay for the wlan version to avoid
> unnecessary probing. OTOH the pins are not exposed on expansion
> connectors and should not conflict with custom peripherals, so no
> strong opinion here.

Good to hear those pins are not rerouted. But considering we
already have mmc3 defined in omap5-uevm.. And the SDIO bus
is meant to be probed.. And the boards have WLAN connectors but
unpopulated.. I'd say it's safe to have it mapped in the dts :)

BTW, I have a few patches coming for omap5-board-common.dtsi
and basic igepv5 support pending some more testing. That makes
it easy to add omap5-uevm related variants easily.

Regards,

Tony

[PATCH 2/2] ARM: dts: Fix WLAN regression on omap5-uevm

[Tony Lindgren]

* Grazvydas Ignotas <notasas@gmail.com> [150919 14:16]:
> On Fri, Sep 18, 2015 at 9:39 PM, Robert Nelson <robertcnelson@gmail.com> wrote:
> > On Fri, Sep 18, 2015 at 11:51 AM, Tony Lindgren <tony@atomide.com> wrote:
> >> * Robert Nelson <robertcnelson@gmail.com> [150918 09:45]:
> >>> On Fri, Sep 18, 2015 at 11:29 AM, Tony Lindgren <tony@atomide.com> wrote:
> >>> > Commit 99f84cae43df ("ARM: dts: add wl12xx/wl18xx bindings") added
> >>> > device tree bindings for the TI WLAN SDIO on many omap variants.
> >>> >
> >>> > I recall wondering how come omap5-uevm did not have the WLAN
> >>> > added and this issue has been bugging me for a while now, and
> >>> > I finally tracked it down to a bad pinmux regression, and a missing
> >>> > deferred probe handling for the 32k clock from palmas that's
> >>> > requested by twl6040.
> >>> >
> >>> > Basically 392adaf796b9 ("ARM: dts: omap5-evm: Add mcspi data")
> >>> > added pin muxing for mcspi4 that conflicts with the onboard
> >>> > WLAN. While the omap5-uevm docs say the WLAN is not populated,
> >>> > this was probably only the case for initial prototypes. Both
> >>> > omap5-uevm boards I have have WLAN populated.
> >>>
> >>> Production boards from svtronics don't populate the wlan..
> >>>
> >>> http://www.svtronics.com/EVM/OMAP5432/5432
> >>>
> >>> quote: "WiFi not available on this model"
> >
> > Okay, got an email back from svtronics, there was a special omap5_uevm
> > + wlan order option for production units.
> 
> The boards we bought came without wlan, so that seems to be the
> "default" configuration.
> 
> I vote for using separate DT overlay for the wlan version to avoid
> unnecessary probing. OTOH the pins are not exposed on expansion
> connectors and should not conflict with custom peripherals, so no
> strong opinion here.

Good to hear those pins are not rerouted. But considering we
already have mmc3 defined in omap5-uevm.. And the SDIO bus
is meant to be probed.. And the boards have WLAN connectors but
unpopulated.. I'd say it's safe to have it mapped in the dts :)

BTW, I have a few patches coming for omap5-board-common.dtsi
and basic igepv5 support pending some more testing. That makes
it easy to add omap5-uevm related variants easily.

Regards,

Tony

Re: [PATCH 2/2] ARM: dts: Fix WLAN regression on omap5-uevm

[Javier Martinez Canillas]

[adding Ulf and Tomeu to cc list]

On Fri, Sep 18, 2015 at 10:27 PM, Tony Lindgren <tony@atomide.com> wrote:
> * Tony Lindgren <tony@atomide.com> [150918 10:54]:
>> * Javier Martinez Canillas <javier@dowhile0.org> [150918 10:39]:
>> > Hello Tony,
>> >
>> > [snip]
>> >
>> > >
>> > > +       vmmcsdio_fixed: fixedregulator-mmcsdio {
>> > > +               compatible = "regulator-fixed";
>> > > +               regulator-name = "vmmcsdio_fixed";
>> > > +               regulator-min-microvolt = <1800000>;
>> > > +               regulator-max-microvolt = <1800000>;
>> > > +               gpio = <&gpio5 12 GPIO_ACTIVE_HIGH>;    /* gpio140 WLAN_EN */
>> >
>> > I know that other OMAP boards use a fake fixed regulator to toggle the
>> > WiFi enable pin but now the MMC subsystem has proper support for power
>> > sequence providers so that should be used instead. For simple uses
>> > like this, Documentation/devicetree/bindings/mmc/mmc-pwrseq-simple.txt
>> > should be enough.
>>
>> Hmm OK great, I'll take a look. Looks like that might also provide a
>> nice solution for handling the 32k clock from palmas to the wl12xx.
>
> It seems it's not quite working yet.. It seems pwrseq_simple.c can't
> deal with delay on a power pin. It might be best to treat those using
> the regulator framework because of the refcounting and start-up delay.

Yes, pwrseq_simple does not support delaying a power pin. IIRC Tomeu
wanted to add a delay for power / reset pins at some point but then
the SDIO device he wanted to power up didn't need it so he dropped
that change at the end. I may be missremembering though.

> I don't think also having regulator handling in pwrseq_simple.c
> conflicts with the MMC regulators as they can be separate?
>

The original "mmc: add support for power-on sequencing through DT" [0]
patch from Olof that added just properties to the MMC controller slot
dev node had a "card-external-vcc-supply" for SDIO devices that needed
an external supply separate to vqmmc and vmmc supplies. The
pwrseq_simple does not support having an input supply regulator right
now but one can be added if that is needed.

> Also not related to wl12xx, the power pin on mwifiex_sdio 8787 wlan
> must be asserted low while reset is asserted and must stay low for
> 300ms after power pin has deasserted. Again using a regulator there
> for the power pin might make more sense.
>

Interesting, I've a patch queued on my tree to convert pwrseq_simple
to use the GPIO descriptors array API since all the code do now is to
set GPIO levels high or low for all the pins at the same time. But for
such a fine grained timing control as you said, I wonder if we should
just keep the code as it is now. Even when is open coding what
gpiod_{get,set,put}_array already do, it may make sense if we add
assert and deassert delay time for each pin.

Or maybe such a HW should have its own power sequence provider instead
of making pwrseq_simple more and more complex?

> Then getting the 32k clock from palmas is not working either, it
> seems some better deferred probe handling is needed there if
> omap_hsmmc is built-in and palmas-clk is a loadable module.
>

IIUC from another email, you already solved this.

> I think for the fix I'll stick with regulator fixed, let's update
> it later on unless you have better suggestions.
>

Yes, I didn't want to block your fixed regulator approach. I was just
pointing out that the MMC infrastructure already has support for power
sequence providers but if what is there doesn't fit your use case, I
agree that we can go with the regulator fixed for now and then change
it later.

>
> Cheers,
>
> Tony

[0]: http://patchwork.ozlabs.org/patch/312444/

Best regards,
Javier

[PATCH 2/2] ARM: dts: Fix WLAN regression on omap5-uevm

[Javier Martinez Canillas]

[adding Ulf and Tomeu to cc list]

On Fri, Sep 18, 2015 at 10:27 PM, Tony Lindgren <tony@atomide.com> wrote:
> * Tony Lindgren <tony@atomide.com> [150918 10:54]:
>> * Javier Martinez Canillas <javier@dowhile0.org> [150918 10:39]:
>> > Hello Tony,
>> >
>> > [snip]
>> >
>> > >
>> > > +       vmmcsdio_fixed: fixedregulator-mmcsdio {
>> > > +               compatible = "regulator-fixed";
>> > > +               regulator-name = "vmmcsdio_fixed";
>> > > +               regulator-min-microvolt = <1800000>;
>> > > +               regulator-max-microvolt = <1800000>;
>> > > +               gpio = <&gpio5 12 GPIO_ACTIVE_HIGH>;    /* gpio140 WLAN_EN */
>> >
>> > I know that other OMAP boards use a fake fixed regulator to toggle the
>> > WiFi enable pin but now the MMC subsystem has proper support for power
>> > sequence providers so that should be used instead. For simple uses
>> > like this, Documentation/devicetree/bindings/mmc/mmc-pwrseq-simple.txt
>> > should be enough.
>>
>> Hmm OK great, I'll take a look. Looks like that might also provide a
>> nice solution for handling the 32k clock from palmas to the wl12xx.
>
> It seems it's not quite working yet.. It seems pwrseq_simple.c can't
> deal with delay on a power pin. It might be best to treat those using
> the regulator framework because of the refcounting and start-up delay.

Yes, pwrseq_simple does not support delaying a power pin. IIRC Tomeu
wanted to add a delay for power / reset pins at some point but then
the SDIO device he wanted to power up didn't need it so he dropped
that change at the end. I may be missremembering though.

> I don't think also having regulator handling in pwrseq_simple.c
> conflicts with the MMC regulators as they can be separate?
>

The original "mmc: add support for power-on sequencing through DT" [0]
patch from Olof that added just properties to the MMC controller slot
dev node had a "card-external-vcc-supply" for SDIO devices that needed
an external supply separate to vqmmc and vmmc supplies. The
pwrseq_simple does not support having an input supply regulator right
now but one can be added if that is needed.

> Also not related to wl12xx, the power pin on mwifiex_sdio 8787 wlan
> must be asserted low while reset is asserted and must stay low for
> 300ms after power pin has deasserted. Again using a regulator there
> for the power pin might make more sense.
>

Interesting, I've a patch queued on my tree to convert pwrseq_simple
to use the GPIO descriptors array API since all the code do now is to
set GPIO levels high or low for all the pins at the same time. But for
such a fine grained timing control as you said, I wonder if we should
just keep the code as it is now. Even when is open coding what
gpiod_{get,set,put}_array already do, it may make sense if we add
assert and deassert delay time for each pin.

Or maybe such a HW should have its own power sequence provider instead
of making pwrseq_simple more and more complex?

> Then getting the 32k clock from palmas is not working either, it
> seems some better deferred probe handling is needed there if
> omap_hsmmc is built-in and palmas-clk is a loadable module.
>

IIUC from another email, you already solved this.

> I think for the fix I'll stick with regulator fixed, let's update
> it later on unless you have better suggestions.
>

Yes, I didn't want to block your fixed regulator approach. I was just
pointing out that the MMC infrastructure already has support for power
sequence providers but if what is there doesn't fit your use case, I
agree that we can go with the regulator fixed for now and then change
it later.

>
> Cheers,
>
> Tony

[0]: http://patchwork.ozlabs.org/patch/312444/

Best regards,
Javier

Re: [PATCH 1/2] mfd: twl6040: Fix deferred probe handling for clk32k

[Peter Ujfalusi]

On 09/18/2015 07:29 PM, Tony Lindgren wrote:
> Commit 68bab8662f49 ("mfd: twl6040: Optional clk32k clock handling")
> added clock handling for the 32k clock from palmas-clk. However, that
> patch did not consider a typical situation where twl6040 is built-in,
> and palmas-clk is a loadable module like we have in omap2plus_defconfig.
> 
> If palmas-clk is not loaded before twl6040 probes, we will get a
> "clk32k is not handled" warning during booting. This means that any
> drivers relying on this clock will mysteriously fail, including
> omap5-uevm WLAN and audio.
> 
> Note that for WLAN, we probably should also eventually get
> the clk32kgaudio for MMC3 directly as that's shared between
> audio and WLAN SDIO at least for omap5-uevm. It seems the
> WLAN chip cannot get it as otherwise MMC3 won't get properly
> probed.

While this is going to 'fix' the WLAN because currently the twl6040 is powered
on all the time (32k clock is enabled). My plan is to finally implement the
power state handling for the twl6040, which means that w/o audio activity the
twl6040 will be turned off. This will imply that any clock which is only used
by twl6040 will be off as well.
The proper solution would be to add clock handling to the WLAN driver stack.

Otherwise:
Acked-by: Peter Ujfalusi <peter.ujfalusi@ti.com>

> Fixes: 68bab8662f49 ("mfd: twl6040: Optional clk32k clock handling")
> Cc: Benoit Cousson <bcousson@baylibre.com>
> Cc: Dr. H. Nikolaus Schaller <hns@goldelico.com>
> Cc: Grazvydas Ignotas <notasas@gmail.com>
> Cc: Lee Jones <lee.jones@linaro.org>
> Cc: Peter Ujfalusi <peter.ujfalusi@ti.com>
> Cc: Samuel Ortiz <sameo@linux.intel.com>
> Cc: Sourav Poddar <sourav.poddar@ti.com>
> Signed-off-by: Tony Lindgren <tony@atomide.com>
> ---
>  drivers/mfd/twl6040.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> --- a/drivers/mfd/twl6040.c
> +++ b/drivers/mfd/twl6040.c
> @@ -647,6 +647,8 @@ static int twl6040_probe(struct i2c_client *client,
>  
>  	twl6040->clk32k = devm_clk_get(&client->dev, "clk32k");
>  	if (IS_ERR(twl6040->clk32k)) {
> +		if (PTR_ERR(twl6040->clk32k) == -EPROBE_DEFER)
> +			return -EPROBE_DEFER;
>  		dev_info(&client->dev, "clk32k is not handled\n");
>  		twl6040->clk32k = NULL;
>  	}
> 


-- 
Péter

[PATCH 1/2] mfd: twl6040: Fix deferred probe handling for clk32k

[Peter Ujfalusi]

On 09/18/2015 07:29 PM, Tony Lindgren wrote:
> Commit 68bab8662f49 ("mfd: twl6040: Optional clk32k clock handling")
> added clock handling for the 32k clock from palmas-clk. However, that
> patch did not consider a typical situation where twl6040 is built-in,
> and palmas-clk is a loadable module like we have in omap2plus_defconfig.
> 
> If palmas-clk is not loaded before twl6040 probes, we will get a
> "clk32k is not handled" warning during booting. This means that any
> drivers relying on this clock will mysteriously fail, including
> omap5-uevm WLAN and audio.
> 
> Note that for WLAN, we probably should also eventually get
> the clk32kgaudio for MMC3 directly as that's shared between
> audio and WLAN SDIO at least for omap5-uevm. It seems the
> WLAN chip cannot get it as otherwise MMC3 won't get properly
> probed.

While this is going to 'fix' the WLAN because currently the twl6040 is powered
on all the time (32k clock is enabled). My plan is to finally implement the
power state handling for the twl6040, which means that w/o audio activity the
twl6040 will be turned off. This will imply that any clock which is only used
by twl6040 will be off as well.
The proper solution would be to add clock handling to the WLAN driver stack.

Otherwise:
Acked-by: Peter Ujfalusi <peter.ujfalusi@ti.com>

> Fixes: 68bab8662f49 ("mfd: twl6040: Optional clk32k clock handling")
> Cc: Benoit Cousson <bcousson@baylibre.com>
> Cc: Dr. H. Nikolaus Schaller <hns@goldelico.com>
> Cc: Grazvydas Ignotas <notasas@gmail.com>
> Cc: Lee Jones <lee.jones@linaro.org>
> Cc: Peter Ujfalusi <peter.ujfalusi@ti.com>
> Cc: Samuel Ortiz <sameo@linux.intel.com>
> Cc: Sourav Poddar <sourav.poddar@ti.com>
> Signed-off-by: Tony Lindgren <tony@atomide.com>
> ---
>  drivers/mfd/twl6040.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> --- a/drivers/mfd/twl6040.c
> +++ b/drivers/mfd/twl6040.c
> @@ -647,6 +647,8 @@ static int twl6040_probe(struct i2c_client *client,
>  
>  	twl6040->clk32k = devm_clk_get(&client->dev, "clk32k");
>  	if (IS_ERR(twl6040->clk32k)) {
> +		if (PTR_ERR(twl6040->clk32k) == -EPROBE_DEFER)
> +			return -EPROBE_DEFER;
>  		dev_info(&client->dev, "clk32k is not handled\n");
>  		twl6040->clk32k = NULL;
>  	}
> 


-- 
P?ter

Re: [PATCH 1/2] mfd: twl6040: Fix deferred probe handling for clk32k

[Tony Lindgren]

* Peter Ujfalusi <peter.ujfalusi@ti.com> [150921 02:59]:
> On 09/18/2015 07:29 PM, Tony Lindgren wrote:
> > Commit 68bab8662f49 ("mfd: twl6040: Optional clk32k clock handling")
> > added clock handling for the 32k clock from palmas-clk. However, that
> > patch did not consider a typical situation where twl6040 is built-in,
> > and palmas-clk is a loadable module like we have in omap2plus_defconfig.
> > 
> > If palmas-clk is not loaded before twl6040 probes, we will get a
> > "clk32k is not handled" warning during booting. This means that any
> > drivers relying on this clock will mysteriously fail, including
> > omap5-uevm WLAN and audio.
> > 
> > Note that for WLAN, we probably should also eventually get
> > the clk32kgaudio for MMC3 directly as that's shared between
> > audio and WLAN SDIO at least for omap5-uevm. It seems the
> > WLAN chip cannot get it as otherwise MMC3 won't get properly
> > probed.
> 
> While this is going to 'fix' the WLAN because currently the twl6040 is powered
> on all the time (32k clock is enabled). My plan is to finally implement the
> power state handling for the twl6040, which means that w/o audio activity the
> twl6040 will be turned off. This will imply that any clock which is only used
> by twl6040 will be off as well.
> The proper solution would be to add clock handling to the WLAN driver stack.

Yes the place to request this clock is using pwrseq_simple.c for MMC3.
It seems there are some issues with deferred probe handling there too
though.

Regards,

Tony

[PATCH 1/2] mfd: twl6040: Fix deferred probe handling for clk32k

[Tony Lindgren]

* Peter Ujfalusi <peter.ujfalusi@ti.com> [150921 02:59]:
> On 09/18/2015 07:29 PM, Tony Lindgren wrote:
> > Commit 68bab8662f49 ("mfd: twl6040: Optional clk32k clock handling")
> > added clock handling for the 32k clock from palmas-clk. However, that
> > patch did not consider a typical situation where twl6040 is built-in,
> > and palmas-clk is a loadable module like we have in omap2plus_defconfig.
> > 
> > If palmas-clk is not loaded before twl6040 probes, we will get a
> > "clk32k is not handled" warning during booting. This means that any
> > drivers relying on this clock will mysteriously fail, including
> > omap5-uevm WLAN and audio.
> > 
> > Note that for WLAN, we probably should also eventually get
> > the clk32kgaudio for MMC3 directly as that's shared between
> > audio and WLAN SDIO at least for omap5-uevm. It seems the
> > WLAN chip cannot get it as otherwise MMC3 won't get properly
> > probed.
> 
> While this is going to 'fix' the WLAN because currently the twl6040 is powered
> on all the time (32k clock is enabled). My plan is to finally implement the
> power state handling for the twl6040, which means that w/o audio activity the
> twl6040 will be turned off. This will imply that any clock which is only used
> by twl6040 will be off as well.
> The proper solution would be to add clock handling to the WLAN driver stack.

Yes the place to request this clock is using pwrseq_simple.c for MMC3.
It seems there are some issues with deferred probe handling there too
though.

Regards,

Tony

Re: [PATCH 2/2] ARM: dts: Fix WLAN regression on omap5-uevm

[Tony Lindgren]

* Javier Martinez Canillas <javier@dowhile0.org> [150921 02:17]:
> [adding Ulf and Tomeu to cc list]
> 
> On Fri, Sep 18, 2015 at 10:27 PM, Tony Lindgren <tony@atomide.com> wrote:
> > * Tony Lindgren <tony@atomide.com> [150918 10:54]:
> >> * Javier Martinez Canillas <javier@dowhile0.org> [150918 10:39]:
> >> > Hello Tony,
> >> >
> >> > [snip]
> >> >
> >> > >
> >> > > +       vmmcsdio_fixed: fixedregulator-mmcsdio {
> >> > > +               compatible = "regulator-fixed";
> >> > > +               regulator-name = "vmmcsdio_fixed";
> >> > > +               regulator-min-microvolt = <1800000>;
> >> > > +               regulator-max-microvolt = <1800000>;
> >> > > +               gpio = <&gpio5 12 GPIO_ACTIVE_HIGH>;    /* gpio140 WLAN_EN */
> >> >
> >> > I know that other OMAP boards use a fake fixed regulator to toggle the
> >> > WiFi enable pin but now the MMC subsystem has proper support for power
> >> > sequence providers so that should be used instead. For simple uses
> >> > like this, Documentation/devicetree/bindings/mmc/mmc-pwrseq-simple.txt
> >> > should be enough.
> >>
> >> Hmm OK great, I'll take a look. Looks like that might also provide a
> >> nice solution for handling the 32k clock from palmas to the wl12xx.
> >
> > It seems it's not quite working yet.. It seems pwrseq_simple.c can't
> > deal with delay on a power pin. It might be best to treat those using
> > the regulator framework because of the refcounting and start-up delay.
> 
> Yes, pwrseq_simple does not support delaying a power pin. IIRC Tomeu
> wanted to add a delay for power / reset pins at some point but then
> the SDIO device he wanted to power up didn't need it so he dropped
> that change at the end. I may be missremembering though.
>
> > I don't think also having regulator handling in pwrseq_simple.c
> > conflicts with the MMC regulators as they can be separate?
> >
> 
> The original "mmc: add support for power-on sequencing through DT" [0]
> patch from Olof that added just properties to the MMC controller slot
> dev node had a "card-external-vcc-supply" for SDIO devices that needed
> an external supply separate to vqmmc and vmmc supplies. The
> pwrseq_simple does not support having an input supply regulator right
> now but one can be added if that is needed.

Yes I think adding support for regulators to pwerseq_simple would
solve the issues for power line for start-up latency and usecount for
shared resources.

> > Also not related to wl12xx, the power pin on mwifiex_sdio 8787 wlan
> > must be asserted low while reset is asserted and must stay low for
> > 300ms after power pin has deasserted. Again using a regulator there
> > for the power pin might make more sense.
> >
> 
> Interesting, I've a patch queued on my tree to convert pwrseq_simple
> to use the GPIO descriptors array API since all the code do now is to
> set GPIO levels high or low for all the pins at the same time. But for
> such a fine grained timing control as you said, I wonder if we should
> just keep the code as it is now. Even when is open coding what
> gpiod_{get,set,put}_array already do, it may make sense if we add
> assert and deassert delay time for each pin.

Well the power pin typically has a latency because of a regulator
somewhere.. And it needs to disabled for PM when not used.. And
it may be shared.. So rather than reinvent the roundish thingy
again, I suggest we just let a regulator handle that.

A reset pin just needs to be toggled, but may have a dependency
to the power pin like in the 8787 case.

> Or maybe such a HW should have its own power sequence provider instead
> of making pwrseq_simple more and more complex?
> 
> > Then getting the 32k clock from palmas is not working either, it
> > seems some better deferred probe handling is needed there if
> > omap_hsmmc is built-in and palmas-clk is a loadable module.
> >
> 
> IIUC from another email, you already solved this.

That deferred probe fix did not solve this one, need to debug further.

> > I think for the fix I'll stick with regulator fixed, let's update
> > it later on unless you have better suggestions.
> 
> Yes, I didn't want to block your fixed regulator approach. I was just
> pointing out that the MMC infrastructure already has support for power
> sequence providers but if what is there doesn't fit your use case, I
> agree that we can go with the regulator fixed for now and then change
> it later.

OK yeah let's fix the issues in the pwrseq so we can finally have
resets working for 8787 too :)

Regards,

Tony

> [0]: http://patchwork.ozlabs.org/patch/312444/

[PATCH 2/2] ARM: dts: Fix WLAN regression on omap5-uevm

[Tony Lindgren]

* Javier Martinez Canillas <javier@dowhile0.org> [150921 02:17]:
> [adding Ulf and Tomeu to cc list]
> 
> On Fri, Sep 18, 2015 at 10:27 PM, Tony Lindgren <tony@atomide.com> wrote:
> > * Tony Lindgren <tony@atomide.com> [150918 10:54]:
> >> * Javier Martinez Canillas <javier@dowhile0.org> [150918 10:39]:
> >> > Hello Tony,
> >> >
> >> > [snip]
> >> >
> >> > >
> >> > > +       vmmcsdio_fixed: fixedregulator-mmcsdio {
> >> > > +               compatible = "regulator-fixed";
> >> > > +               regulator-name = "vmmcsdio_fixed";
> >> > > +               regulator-min-microvolt = <1800000>;
> >> > > +               regulator-max-microvolt = <1800000>;
> >> > > +               gpio = <&gpio5 12 GPIO_ACTIVE_HIGH>;    /* gpio140 WLAN_EN */
> >> >
> >> > I know that other OMAP boards use a fake fixed regulator to toggle the
> >> > WiFi enable pin but now the MMC subsystem has proper support for power
> >> > sequence providers so that should be used instead. For simple uses
> >> > like this, Documentation/devicetree/bindings/mmc/mmc-pwrseq-simple.txt
> >> > should be enough.
> >>
> >> Hmm OK great, I'll take a look. Looks like that might also provide a
> >> nice solution for handling the 32k clock from palmas to the wl12xx.
> >
> > It seems it's not quite working yet.. It seems pwrseq_simple.c can't
> > deal with delay on a power pin. It might be best to treat those using
> > the regulator framework because of the refcounting and start-up delay.
> 
> Yes, pwrseq_simple does not support delaying a power pin. IIRC Tomeu
> wanted to add a delay for power / reset pins at some point but then
> the SDIO device he wanted to power up didn't need it so he dropped
> that change at the end. I may be missremembering though.
>
> > I don't think also having regulator handling in pwrseq_simple.c
> > conflicts with the MMC regulators as they can be separate?
> >
> 
> The original "mmc: add support for power-on sequencing through DT" [0]
> patch from Olof that added just properties to the MMC controller slot
> dev node had a "card-external-vcc-supply" for SDIO devices that needed
> an external supply separate to vqmmc and vmmc supplies. The
> pwrseq_simple does not support having an input supply regulator right
> now but one can be added if that is needed.

Yes I think adding support for regulators to pwerseq_simple would
solve the issues for power line for start-up latency and usecount for
shared resources.

> > Also not related to wl12xx, the power pin on mwifiex_sdio 8787 wlan
> > must be asserted low while reset is asserted and must stay low for
> > 300ms after power pin has deasserted. Again using a regulator there
> > for the power pin might make more sense.
> >
> 
> Interesting, I've a patch queued on my tree to convert pwrseq_simple
> to use the GPIO descriptors array API since all the code do now is to
> set GPIO levels high or low for all the pins at the same time. But for
> such a fine grained timing control as you said, I wonder if we should
> just keep the code as it is now. Even when is open coding what
> gpiod_{get,set,put}_array already do, it may make sense if we add
> assert and deassert delay time for each pin.

Well the power pin typically has a latency because of a regulator
somewhere.. And it needs to disabled for PM when not used.. And
it may be shared.. So rather than reinvent the roundish thingy
again, I suggest we just let a regulator handle that.

A reset pin just needs to be toggled, but may have a dependency
to the power pin like in the 8787 case.

> Or maybe such a HW should have its own power sequence provider instead
> of making pwrseq_simple more and more complex?
> 
> > Then getting the 32k clock from palmas is not working either, it
> > seems some better deferred probe handling is needed there if
> > omap_hsmmc is built-in and palmas-clk is a loadable module.
> >
> 
> IIUC from another email, you already solved this.

That deferred probe fix did not solve this one, need to debug further.

> > I think for the fix I'll stick with regulator fixed, let's update
> > it later on unless you have better suggestions.
> 
> Yes, I didn't want to block your fixed regulator approach. I was just
> pointing out that the MMC infrastructure already has support for power
> sequence providers but if what is there doesn't fit your use case, I
> agree that we can go with the regulator fixed for now and then change
> it later.

OK yeah let's fix the issues in the pwrseq so we can finally have
resets working for 8787 too :)

Regards,

Tony

> [0]: http://patchwork.ozlabs.org/patch/312444/

Re: [PATCH 2/2] ARM: dts: Fix WLAN regression on omap5-uevm

[Tony Lindgren]

* Tony Lindgren <tony@atomide.com> [150921 07:16]:
> * Javier Martinez Canillas <javier@dowhile0.org> [150921 02:17]:
> > > Then getting the 32k clock from palmas is not working either, it
> > > seems some better deferred probe handling is needed there if
> > > omap_hsmmc is built-in and palmas-clk is a loadable module.
> > >
> > 
> > IIUC from another email, you already solved this.
> 
> That deferred probe fix did not solve this one, need to debug further.

FYI, found the MMC pwrseq clock issue, I had a typo in my dts
file with "ext_clk" instead of "ext_clock" :)

Will send v2 of $subject patch after some more testing using
both a GPIO regulator-fixed and mmc pwrseq for the clock.

Regards,

Tony

[PATCH 2/2] ARM: dts: Fix WLAN regression on omap5-uevm

[Tony Lindgren]

* Tony Lindgren <tony@atomide.com> [150921 07:16]:
> * Javier Martinez Canillas <javier@dowhile0.org> [150921 02:17]:
> > > Then getting the 32k clock from palmas is not working either, it
> > > seems some better deferred probe handling is needed there if
> > > omap_hsmmc is built-in and palmas-clk is a loadable module.
> > >
> > 
> > IIUC from another email, you already solved this.
> 
> That deferred probe fix did not solve this one, need to debug further.

FYI, found the MMC pwrseq clock issue, I had a typo in my dts
file with "ext_clk" instead of "ext_clock" :)

Will send v2 of $subject patch after some more testing using
both a GPIO regulator-fixed and mmc pwrseq for the clock.

Regards,

Tony