ARM: dts: Fix WLAN regression on omap5-uevm
commit6bafb3e3e48827d634624ee25395a396aa675279
authorTony Lindgren <tony@atomide.com>
Fri, 16 Oct 2015 19:32:32 +0000 (16 12:32 -0700)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Wed, 9 Dec 2015 19:03:15 +0000 (9 14:03 -0500)
tree8ab201c8b3877fdd6a214cc4e165241a9a07560d
parent3b389e9e73e0c5cc15d6e002129fc8b85aa700b6
ARM: dts: Fix WLAN regression on omap5-uevm

commit 0efc898a9bea7a2e8e583c6efab0e19dc7093078 upstream.

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 some omap5-uevm don't have WLAN populated, the
pins are not reused for other devices. And as the SDIO bus
should be probed, let's try to enable WLAN by default.

Let's fix the regression and add the WLAN configuration as
done for the other boards in 99f84cae43df ("ARM: dts: add
wl12xx/wl18xx bindings"). And let's use the new MMC pwrseq for
the 32k clock as suggested by Javier Martinez Canillas
<javier@dowhile0.org>.

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.

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

And finally, note that omap5 seems to require WAKEUP_EN for
the WLAN GPIO interrupt.

Fixes: 392adaf796b9 ("ARM: dts: omap5-evm: Add mcspi data")
Cc: Sourav Poddar <sourav.poddar@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
arch/arm/boot/dts/omap5-uevm.dts