Re: [PATCH 2/3] arm64: dts: rockchip: Enable sdmmc2 on rock-3b and set it up for SDIO devices

[Dragan Simic]

Hello Jonas and Tamas,

On 2024-11-11 20:06, Jonas Karlman wrote:
> On 2024-11-11 19:17, Tamás Szűcs wrote:
> > Enable SDIO on Radxa ROCK 3 Model B M.2 Key E. Add all supported UHS-I 
> > rates and
> > enable 200 MHz maximum clock. Also, allow host wakeup via SDIO IRQ.
> >
> > Signed-off-by: Tamás Szűcs <tszucs@xxxxxxxxx>
> > ---
> >  arch/arm64/boot/dts/rockchip/rk3568-rock-3b.dts | 8 +++++++-
> >  1 file changed, 7 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/arm64/boot/dts/rockchip/rk3568-rock-3b.dts 
> > b/arch/arm64/boot/dts/rockchip/rk3568-rock-3b.dts
> > index 242af5337cdf..b7527ba418f7 100644
> > --- a/arch/arm64/boot/dts/rockchip/rk3568-rock-3b.dts
> > +++ b/arch/arm64/boot/dts/rockchip/rk3568-rock-3b.dts
> > @@ -688,14 +688,20 @@ &sdmmc2 {
> >  	cap-sd-highspeed;
> >  	cap-sdio-irq;
> >  	keep-power-in-suspend;
> > +	max-frequency = <200000000>;
> >  	mmc-pwrseq = <&sdio_pwrseq>;
> >  	non-removable;
> >  	pinctrl-names = "default";
> >  	pinctrl-0 = <&sdmmc2m0_bus4 &sdmmc2m0_clk &sdmmc2m0_cmd>;
> > +	sd-uhs-sdr12;
> > +	sd-uhs-sdr25;
> > +	sd-uhs-sdr50;
>
> I thought that lower speeds was implied by uhs-sdr104?

Last time I went through the MMC drivers, they were implied.  IIRC,
such backward mode compatibility is actually a requirement made by
the MMC specification.

> >  	sd-uhs-sdr104;
> > +	sd-uhs-ddr50;
> >  	vmmc-supply = <&vcc3v3_sys2>;
> >  	vqmmc-supply = <&vcc_1v8>;
> > -	status = "disabled";
> > +	wakeup-source;
> > +	status = "okay";
>
> This should probably be enabled using an dt-overlay, there is no
> SDIO device embedded on the board and the reason I left it disabled
> in original board DT submission.

Just went through the ROCK 3B schematic, version 1.51, and I think
there should be no need for a separate overlay, because sdmmc2 goes
to the M.2 slot on the board, which any user can plug an M.2 module
into, and the SDIO interface is kind-of self-discoverable.

Of course, all that unless there are some horribly looking :) error
messages emitted to the kernel log when nothing is actually found,
in which case the SDIO/MMC driers should be fixed first.  Also, I'm
not sure what do we do with the possible SDIO-related power timing
requirements?