[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <1929240.tdWV9SEqCh@diego>
Date: Sun, 27 Apr 2025 13:14:58 +0200
From: Heiko StĂĽbner <heiko@...ech.de>
To: linux-rockchip@...ts.infradead.org, Hao Zhang <hao.zhang@...lkit.cn>
Cc: devicetree@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
conor+dt@...nel.org, krzysztof.kozlowski+dt@...aro.org, robh+dt@...nel.org,
linux-kernel@...r.kernel.org, "hao.zhang" <hao.zhang@...lkit.cn>
Subject:
Re: [PATCH 1/1] ARM: dts: rockchip: Wifi improvements for Sonoff iHost
Hi,
Am Sonntag, 27. April 2025, 08:50:13 Mitteleuropäische Sommerzeit schrieb Hao Zhang:
> From: "hao.zhang" <hao.zhang@...lkit.cn>
>
> After some Sonoff-iHosts have been running for a long time,
> the WiFi module will run abnormally.
>
> Adjust the pmu_io_domains and sdio properties
> to solve the WiFi module operation abnormality.
"adjust the ... properties", really sounds like hacking around some issue.
> diff --git a/arch/arm/boot/dts/rockchip/rv1126-sonoff-ihost.dtsi b/arch/arm/boot/dts/rockchip/rv1126-sonoff-ihost.dtsi
> index 9a87dc0d5f66..3c0371103015 100644
> --- a/arch/arm/boot/dts/rockchip/rv1126-sonoff-ihost.dtsi
> +++ b/arch/arm/boot/dts/rockchip/rv1126-sonoff-ihost.dtsi
> @@ -323,15 +323,15 @@ wifi_enable_h: wifi-enable-h {
> };
>
> &pmu_io_domains {
> - pmuio0-supply = <&vcc1v8_pmu>;
> + pmuio0-supply = <&vcc3v3_sys>;
> pmuio1-supply = <&vcc3v3_sys>;
> vccio1-supply = <&vcc_1v8>;
> vccio2-supply = <&vccio_sd>;
> - vccio3-supply = <&vcc3v3_sd>;
> - vccio4-supply = <&vcc_dovdd>;
> - vccio5-supply = <&vcc_1v8>;
> - vccio6-supply = <&vcc_1v8>;
> - vccio7-supply = <&vcc_dovdd>;
> + vccio3-supply = <&vcc_3v3>;
> + vccio4-supply = <&vcc_3v3>;
> + vccio5-supply = <&vcc_3v3>;
> + vccio6-supply = <&vcc_3v3>;
> + vccio7-supply = <&vcc_1v8>;
> status = "okay";
> };
First of all, this would be two patches. If the io-domains do not follow
the schematics, fixing this is one patch, but for such a big change
I do expect actual references to the devices' schematics for that.
This is even more important, as you're switching some supplies
between sources of different voltages
> @@ -342,18 +342,15 @@ &saradc {
>
> &sdio {
> bus-width = <4>;
> - cap-sd-highspeed;
> cap-sdio-irq;
> keep-power-in-suspend;
> - max-frequency = <50000000>;
> + max-frequency = <25000000>;
> mmc-pwrseq = <&sdio_pwrseq>;
> + supports-sdio;
> non-removable;
> pinctrl-names = "default";
> pinctrl-0 = <&sdmmc1_clk &sdmmc1_cmd &sdmmc1_bus4>;
> rockchip,default-sample-phase = <90>;
> - sd-uhs-sdr50;
> - vmmc-supply = <&vcc3v3_sd>;
> - vqmmc-supply = <&vcc_1v8>;
> status = "okay";
> };
and here it looks like you're more or less randomly adding and removing
properties until it worked "for you".
Especially removing the supply-regulators does not really make sense.
If you see instabilities, the main contenders would be max-frequency and
sd-uhs-sdr50 as culprits.
Similarly, supports-sdio is not even a valid property, so neither the
devicetree spec does allow it, nor does the kernel handle it at all.
Heiko
Powered by blists - more mailing lists