[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 at gmail.com> wrote:
> On Fri, Sep 18, 2015 at 11:51 AM, Tony Lindgren <tony at atomide.com> wrote:
>> * Robert Nelson <robertcnelson at gmail.com> [150918 09:45]:
>>> On Fri, Sep 18, 2015 at 11:29 AM, Tony Lindgren <tony at 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