| Message ID | 20231121122441.64385-1-tony@atomide.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | arm64: dts: ti: k3-am625-sk: Add support for WL1837 module onboard | expand |
On 14:24-20231121, Tony Lindgren wrote: > From: Vignesh Raghavendra <vigneshr@ti.com> > > WL1837 WLAN card is present on the original AM625 SK board. It > communicates with the SoC using 4 bit SDIO through the second instance of > MMCSD. > > Starting with SK-AM62B, there is a M.2 WLAN device connector instead of We support AM62B-SK. > the integrated WL1837 WLAN. The M.2 connector should be handled separately > in the k3-am62a.dtsi and k3-am62b.dtsi files as needed. Should this rather be an overlay instead of integrated dts fixup? M2 connector allows for various options including the newer 33xx family[2]. It makes sense for the regulator etc to be on the main dts file, but I am not convinced about it being integrated as part of the dts. > > Note that WLAN currently needs fw_devlink=permissive set on the command > line. Not sure what is missing here but that seems like a separate change. > > Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> > Signed-off-by: Aswath Govindraju <a-govindraju@ti.com> > [tony@atomide.com: updated for pinctrl, improved comments] > Signed-off-by: Tony Lindgren <tony@atomide.com> > --- > arch/arm64/boot/dts/ti/k3-am625-sk.dts | 79 ++++++++++++++++++++++++++ > 1 file changed, 79 insertions(+) > > diff --git a/arch/arm64/boot/dts/ti/k3-am625-sk.dts b/arch/arm64/boot/dts/ti/k3-am625-sk.dts > --- a/arch/arm64/boot/dts/ti/k3-am625-sk.dts > +++ b/arch/arm64/boot/dts/ti/k3-am625-sk.dts > @@ -103,6 +103,32 @@ vcc_1v8: regulator-5 { [...] > + }; > }; > > &main_gpio0 { > @@ -200,6 +253,32 @@ &sdhci1 { > vqmmc-supply = <&vdd_sd_dv>; > }; > > +&sdhci2 { > + status = "okay"; > + vmmc-supply = <&wlan_en>; Should we use mmc-pwrseq ? Looks like we have run into an issue in BeaglePlay with wlan_en being always on for loading firmware. so is there a need to keep the wlan on while suspended? [1] https://sukrutb.github.io/s2d_TI_am625-BeaglePlay/ (see towards the end) [2] https://www.ti.com/tool/M2-CC3301
* Nishanth Menon <nm@ti.com> [231123 07:10]: > On 14:24-20231121, Tony Lindgren wrote: > > From: Vignesh Raghavendra <vigneshr@ti.com> > > > > WL1837 WLAN card is present on the original AM625 SK board. It > > communicates with the SoC using 4 bit SDIO through the second instance of > > MMCSD. > > > > Starting with SK-AM62B, there is a M.2 WLAN device connector instead of > > We support AM62B-SK. Is that with k3-am62-lp-sk.dts though? Wondering if they should have separate dts files for the M.2. > > the integrated WL1837 WLAN. The M.2 connector should be handled separately > > in the k3-am62a.dtsi and k3-am62b.dtsi files as needed. > > Should this rather be an overlay instead of integrated dts fixup? M2 > connector allows for various options including the newer 33xx family[2]. Not sure if an overlay makes sense for an integrated device.. It sure makes sense for plug in boards though. > It makes sense for the regulator etc to be on the main dts file, but I > am not convinced about it being integrated as part of the dts. Yeah if AM62B-SK is supported with the same dts. My vote would be for separate dts files for the integrated variant to keep things simple :) > Should we use mmc-pwrseq ? Yes probably, I think there was some issue earlier with that but sounds like it's been solved already. > Looks like we have run into an issue in BeaglePlay with wlan_en > being always on for loading firmware. so is there a need to keep the > wlan on while suspended? If the wlan irq was on the first gpio bank, wake-up path would work for the wlan. But I think it's wired to a gpio bank with no wake-up capability, and the padconf wake related patches are still pending. So no need to keep the wlan enabled so far AFAIK. Regards, Tony > [1] https://sukrutb.github.io/s2d_TI_am625-BeaglePlay/ (see towards the > end) > [2] https://www.ti.com/tool/M2-CC3301
On 10:34-20231129, Tony Lindgren wrote: > * Nishanth Menon <nm@ti.com> [231123 07:10]: > > On 14:24-20231121, Tony Lindgren wrote: > > > From: Vignesh Raghavendra <vigneshr@ti.com> > > > > > > WL1837 WLAN card is present on the original AM625 SK board. It > > > communicates with the SoC using 4 bit SDIO through the second instance of > > > MMCSD. > > > > > > Starting with SK-AM62B, there is a M.2 WLAN device connector instead of > > > > We support AM62B-SK. > > Is that with k3-am62-lp-sk.dts though? Wondering if they should have separate > dts files for the M.2. It has been the same dts. Separating the wlan out of the dts sounds correct. > > > > the integrated WL1837 WLAN. The M.2 connector should be handled separately > > > in the k3-am62a.dtsi and k3-am62b.dtsi files as needed. > > > > Should this rather be an overlay instead of integrated dts fixup? M2 > > connector allows for various options including the newer 33xx family[2]. > > Not sure if an overlay makes sense for an integrated device.. It sure makes > sense for plug in boards though. overlay works for both variant of devices (please see additional comment below). > > > It makes sense for the regulator etc to be on the main dts file, but I > > am not convinced about it being integrated as part of the dts. > > Yeah if AM62B-SK is supported with the same dts. My vote would be for > separate dts files for the integrated variant to keep things simple :) we can handle it via dtb itself dts can remain common, the m2 is a dtso, we generate a dtbo and the original will be an additional dtb? I think this can work out without dts/dtsi duplication. arch/arm64/boot/dts/ti/Makefile has previous examples of the form. > > > Should we use mmc-pwrseq ? > > Yes probably, I think there was some issue earlier with that but sounds like > it's been solved already. > > > Looks like we have run into an issue in BeaglePlay with wlan_en > > being always on for loading firmware. so is there a need to keep the > > wlan on while suspended? > > If the wlan irq was on the first gpio bank, wake-up path would work for > the wlan. But I think it's wired to a gpio bank with no wake-up capability, > and the padconf wake related patches are still pending. So no need to keep > the wlan enabled so far AFAIK. I believe the issue was around the wlan firmware load itself, but i think the mmc-pwrseq will probably help resolve it.
* Nishanth Menon <nm@ti.com> [231203 14:07]: > dts can remain common, the m2 is a dtso, we generate a dtbo and the > original will be an additional dtb? I think this can work out without > dts/dtsi duplication. That sounds good to me, I'll take a look. > arch/arm64/boot/dts/ti/Makefile has previous examples of the form. OK > I believe the issue was around the wlan firmware load itself, but i > think the mmc-pwrseq will probably help resolve it. Yes mmc-pwrseq makes sense. Regards, Tony
diff --git a/arch/arm64/boot/dts/ti/k3-am625-sk.dts b/arch/arm64/boot/dts/ti/k3-am625-sk.dts --- a/arch/arm64/boot/dts/ti/k3-am625-sk.dts +++ b/arch/arm64/boot/dts/ti/k3-am625-sk.dts @@ -103,6 +103,32 @@ vcc_1v8: regulator-5 { regulator-always-on; regulator-boot-on; }; + + wlan_lten: regulator-6 { + bootph-all; + compatible = "regulator-fixed"; + regulator-name = "wlan_lten"; + regulator-min-microvolt = <3300000>; + regulator-max-microvolt = <3300000>; + regulator-always-on; + vin-supply = <&vcc_3v3_sys>; + gpios = <&exp1 11 GPIO_ACTIVE_LOW>; + }; + + wlan_en: regulator-7 { + /* OUTPUT of SN74AVC2T244DQMR */ + bootph-all; + compatible = "regulator-fixed"; + regulator-name = "wlan_en"; + regulator-min-microvolt = <1800000>; + regulator-max-microvolt = <1800000>; + enable-active-high; + regulator-always-on; + vin-supply = <&wlan_lten>; + gpios = <&main_gpio0 71 GPIO_ACTIVE_HIGH>; + pinctrl-names = "default"; + pinctrl-0 = <&wlan_en_default_pins>; + }; }; &main_pmx0 { @@ -154,6 +180,33 @@ main_gpio1_ioexp_intr_pins_default: main-gpio1-ioexp-intr-default-pins { AM62X_IOPAD(0x01d4, PIN_INPUT, 7) /* (B15) UART0_RTSn.GPIO1_23 */ >; }; + + wlan_en_default_pins: wlan-en-default-pins { + bootph-all; + pinctrl-single,pins = < + AM62X_IOPAD(0x124, PIN_OUTPUT, 7) /* (A23) MMC2_SDCD.GPIO0_71 */ + >; + }; + + main_mmc2_default_pins: main-mmc2-default-pins { + bootph-all; + pinctrl-single,pins = < + AM62X_IOPAD(0x120, PIN_INPUT, 0) /* (C24) MMC2_CMD */ + AM62X_IOPAD(0x118, PIN_INPUT, 0) /* (D25) MMC2_CLK */ + AM62X_IOPAD(0x114, PIN_INPUT, 0) /* (B24) MMC2_DAT0 */ + AM62X_IOPAD(0x110, PIN_INPUT, 0) /* (C25) MMC2_DAT1 */ + AM62X_IOPAD(0x10c, PIN_INPUT, 0) /* (E23) MMC2_DAT2 */ + AM62X_IOPAD(0x108, PIN_INPUT, 0) /* (D24) MMC2_DAT3 */ + AM62X_IOPAD(0x11c, PIN_INPUT, 0) /* (#N/A) MMC2_CLKB */ + >; + }; + + main_wlirq_default_pins: main-wlirq-default-pins { + bootph-all; + pinctrl-single,pins = < + AM62X_IOPAD(0x128, PIN_INPUT, 7) /* (B23) MMC2_SDWP.GPIO0_72 */ + >; + }; }; &main_gpio0 { @@ -200,6 +253,32 @@ &sdhci1 { vqmmc-supply = <&vdd_sd_dv>; }; +&sdhci2 { + status = "okay"; + vmmc-supply = <&wlan_en>; + pinctrl-names = "default"; + pinctrl-0 = <&main_mmc2_default_pins>; + bus-width = <4>; + non-removable; + ti,fails-without-test-cd; + cap-power-off-card; + keep-power-in-suspend; + ti,driver-strength-ohm = <50>; + assigned-clocks = <&k3_clks 157 158>; + assigned-clock-parents = <&k3_clks 157 160>; + #address-cells = <1>; + #size-cells = <0>; + + wlcore: wlcore@2 { + compatible = "ti,wl1837"; + reg = <2>; + pinctrl-names = "default"; + pinctrl-0 = <&main_wlirq_default_pins>; + interrupt-parent = <&main_gpio0>; + interrupts = <72 IRQ_TYPE_EDGE_FALLING>; + }; +}; + &cpsw3g { pinctrl-names = "default"; pinctrl-0 = <&main_rgmii1_pins_default>, <&main_rgmii2_pins_default>;