Re: [PATCH] arm64: dts: ulcb-kf: Add support for TI WL1837

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Geert,

We appreciate your review comments.

On Tue, May 28, 2019 at 11:19:04AM +0200, Geert Uytterhoeven wrote:
[..]
> > +       wlan_en: regulator-wlan_en {
> > +               compatible = "regulator-fixed";
> > +               regulator-name = "wlan-en-regulator";
> > +
> > +               regulator-min-microvolt = <3300000>;
> > +               regulator-max-microvolt = <3300000>;
> 
> So this is a 3.3V regulator...
> 
> > +
> > +               gpio = <&gpio_exp_74 4 GPIO_ACTIVE_HIGH>;
> > +               startup-delay-us = <70000>;
> > +               enable-active-high;
> > +       };
> >  };
> >
> >  &can0 {
> 
> > @@ -273,6 +298,30 @@
> >         status = "okay";
> >  };
> >
> > +&sdhi3 {
> > +       pinctrl-0 = <&sdhi3_pins>;
> > +       pinctrl-names = "default";
> > +
> > +       vmmc-supply = <&wlan_en>;
> > +       vqmmc-supply = <&wlan_en>;
> 
> ... used for both card and I/O line power...
> 
> > +       bus-width = <4>;
> > +       no-1-8-v;
> 
> ... hence no 1.8V I/O.
> 
> However, VIO of WL1837 is provided by W1.8V of regulator U55,
> which is 1.8V?

Looking at the KF-M06 schematics, it seems like the SDIO-relevant lines
of WL1837 (U52) are interfaced with the SoC via TXS0108EPWR (U57) which
is there to level-translate from 3.3v (SoC) to 1.8v (WL1837). So,
from SoC perspective, it looks like the lines are 3.3v-powered.

FTR, the test results are independent on the 'no-1-8-v' property.

> > +       non-removable;
> > +       cap-power-off-card;
> > +       keep-power-in-suspend;
> > +       max-frequency = <26000000>;
> > +       status = "okay";
> > +
> > +       #address-cells = <1>;
> > +       #size-cells = <0>;
> > +       wlcore: wlcore@2 {
> > +               compatible = "ti,wl1837";
> > +               reg = <2>;
> > +               interrupt-parent = <&gpio1>;
> > +               interrupts = <25 IRQ_TYPE_EDGE_FALLING>;
> 
> I'm also a bit puzzled by the interrupt type.
> On Cat 874, it's IRQ_TYPE_LEVEL_HIGH, cfr.
> https://lore.kernel.org/linux-renesas-soc/1557997166-63351-2-git-send-email-biju.das@xxxxxxxxxxxxxx/
> 
> On Kingfisher, the IRQ signal is inverted by U104, so I'd expect
> IRQ_TYPE_LEVEL_LOW instead of IRQ_TYPE_EDGE_FALLING?

That's an insightful comment, if it simply arose from code review.
I guess we mistakenly relied on [1] during our testing on linux/master.
So, we definitely have to re-spin the patch to make it independent
on [1]. The problem is that by dropping [1] and switching from
IRQ_TYPE_EDGE_FALLING to IRQ_TYPE_LEVEL_LOW, the wifi testing
(particularly 'iwlist wlan0 scan') doesn't pass. We have to give
another thought how to best tackle it.

[1] https://github.com/CogentEmbedded/meta-rcar/blob/289fbd4f8354/meta-rcar-gen3-adas/recipes-kernel/linux/linux-renesas/0024-wl18xx-do-not-invert-IRQ-on-WLxxxx-side.patch

Thank you.

> 
> Apart from the above two comments:
> Reviewed-by: Geert Uytterhoeven <geert+renesas@xxxxxxxxx>
> 
> Gr{oetje,eeting}s,
> 
>                         Geert
> 
> -- 
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx
> 
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
>                                 -- Linus Torvalds

-- 
Best Regards,
Eugeniu.



[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux