ARM: dts: Fix WLAN regression on omap5-uevm
authorTony Lindgren <tony@atomide.com>
Fri, 16 Oct 2015 19:32:32 +0000 (12:32 -0700)
committerTony Lindgren <tony@atomide.com>
Fri, 16 Oct 2015 19:32:32 +0000 (12:32 -0700)
commit0efc898a9bea7a2e8e583c6efab0e19dc7093078
tree2b59dc1f85bcccd9486c7c98f038203049ef759c
parentbe146412501bc2ed49183637605da97f47125696
ARM: dts: Fix WLAN regression on omap5-uevm

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>
arch/arm/boot/dts/omap5-uevm.dts