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.
