[PATCH v2] ARM: dts: ux500: Fix BT+WLAN on Samsung phones

[Linus Walleij]

On Wed, Mar 17, 2021 at 5:17 PM Stephan Gerhold <stephan at gerhold.net> wrote:
> On Wed, Mar 17, 2021 at 04:53:58PM +0100, Linus Walleij wrote:
> > On Wed, Mar 17, 2021 at 4:28 PM Stephan Gerhold <stephan at gerhold.net> wrote:
> >
> > > According to the schematics for samsung-golden:
> > >   - GPIO215 goes to WL_REG_ON of BCM4334
> > >   - GPIO222 goes to BT_REG_ON of BCM4334
> >
> > Yes it appears you are right...
> >
> > This is in conflict with the source code in the vendor tree:
> > board-golden-pins.c:
> >
> >         GPIO215_GPIO            | PIN_OUTPUT_LOW,       /* WLAN_RST_N */
> >         GPIO222_GPIO            | PIN_OUTPUT_LOW,       /* BT_VREG_EN */
> >
> > However the BCM4334 does not have appear to have
> > any signal named WLAN_RST_N.
> >
> > So I suspect a copy/paste error from Janice, which might
> > need this because of differences between BCM4330 and
> > BCM4334.
> >
>
> Huh, so it gets more confusing: unlike BCM4334, the BCM4330 datasheet [2]
> mentions a BT_RST_N but not a WLAN_RST_N... :O

Yeah. BT_RST_N exists on 4330 and is gone on BCM4334.

I'll think of something.

> > However another part of the patch is still needed because
> > GPIO215 is default initilized as low:
> >
> >                 wlan_en_default: wlan_en_default {
> >                         golden_cfg1 {
> >                                 pins = "GPIO215_AH13";  /* WLAN_EN */
> >                                 ste,config = <&gpio_out_lo>;
> >                         };
> >                 };
> >
> > It needs to be high, or the SDIO will not enumerate unless
> > someone powers on the Bluetooth by chance. (The driver
> > probes after the SDIO card is detected ... catch 22.)
>
> At least on samsung-golden, GPIO215 belongs to the regulator-wl-reg-on,
> which is the vmmc-supply for the SDIO card. I would expect the MMC core
> to power that up before scanning for SDIO cards.

Hm, makes sense. But this got it working for me :/
I'll investigate.

> > Also IMO GPIO 222 should be modeled as a regulator and
> > not assigned to "shutdown-gpios", which could be a separate
> > patch. The whole notion of "shutdown-gpios" seems backward
> > as the driver handles regulators just fine.
> >
>
> Yeah I suppose it might be better modelled as a regulator. But I guess
> in that case we would need support for another regulator.
> The "vbat" and "vddio" are likely supposed to point to the "BT_VDDBAT"
> and "VDDIO" input pins of the BCM4334.

We seldom model VBAT supplies since it is always on and can't
be turned off/on or done much with. The only time we do that is
when we need to know the voltage.

Yours,
Linus Walleij