Re: [PATCH v5 5/9] riscv: dts: spacemit: k1: add SD card controller and pinctrl support

Iker Pedrosa
2026-04-01T08:53:28Z

El lun, 30 mar 2026 a las 11:08, Troy Mitchell
(<troy.mitchell@linux.dev>) escribió:
>
> On Mon, Mar 30, 2026 at 16:38:06 CST, Iker Pedrosa wrote:
> > Add SD card controller infrastructure for SpacemiT K1 SoC with complete
> > pinctrl support for both standard and UHS modes.
> >
> > - Add sdhci0 controller definition with clocks, resets and interrupts
> > - Add mmc1_cfg pinctrl for 3.3V standard SD operation
> > - Add mmc1_uhs_cfg pinctrl for 1.8V UHS high-speed operation
> > - Configure appropriate drive strength and power-source properties
> >
> > This provides complete SD card infrastructure that K1-based boards can
> > enable.
> >
> > Tested-by: Anand Moon <linux.amoon@gmail.com>
> > Tested-by: Trevor Gamblin <tgamblin@baylibre.com>
> > Signed-off-by: Iker Pedrosa <ikerpedrosam@gmail.com>
> > ---
> > arch/riscv/boot/dts/spacemit/k1-pinctrl.dtsi | 40 ++++++++++++++++++++++++++++
> > arch/riscv/boot/dts/spacemit/k1.dtsi | 13 +++++++++
> > 2 files changed, 53 insertions(+)
> >
> > diff --git a/arch/riscv/boot/dts/spacemit/k1-pinctrl.dtsi b/arch/riscv/boot/dts/spacemit/k1-pinctrl.dtsi
> > index b13dcb10f4d66022d27307de73a6ea3287e97441..8d82011f1af666fb78c282a2abcc0cb88f962053 100644
> > --- a/arch/riscv/boot/dts/spacemit/k1-pinctrl.dtsi
> > +++ b/arch/riscv/boot/dts/spacemit/k1-pinctrl.dtsi
> > @@ -570,4 +570,44 @@ pwm14-1-pins {
> > drive-strength = <32>;
> > };
> > };
> > +
> > + mmc1_cfg: mmc1-cfg {
> > + mmc1-data-cmd-pins {
> > + pinmux = <K1_PADCONF(104, 0)>, /* mmc1_d3 */
> > + <K1_PADCONF(105, 0)>, /* mmc1_d2 */
> > + <K1_PADCONF(106, 0)>, /* mmc1_d1 */
> > + <K1_PADCONF(107, 0)>, /* mmc1_d0 */
> > + <K1_PADCONF(108, 0)>; /* mmc1_cmd */
> > + bias-pull-up = <1>;
> > + drive-strength = <7>;
> I'm a bit concerned about this value. Looking at the downstream 6.6 code, 3.3V uses DS4,
> which equals 13mA. Since 7mA maps to DS0, what's the reasoning for using it here?
> Do we have any documentation or measurement to back this up?

Thank you for catching this! You're absolutely right to question these
drive strength values.

Looking back at my development process, I remember hitting signal
integrity issues in the early stages of this driver development. As a
quick solution, I lowered the drive strength values, which seemed to
resolve the immediate problems, and I moved on without revisiting the
electrical characteristics.

After your feedback, I investigated this properly by comparing with
the vendor kernel. It uses:
- 3.3V mode: PAD_3V_DS4 (19mA)
- 1.8V UHS mode: PAD_1V8_DS3 (42mA)

My original values were indeed backwards from both electrical theory
and proven vendor implementation. Testing with the corrected values
(19mA/42mA) confirms SD card is working.

I'll send v6 with the corrected drive strength values: drive-strength
= <19> for 3.3V and drive-strength = <42> for 1.8V UHS modes.

> > + power-source = <3300>;
> > + };
> > +
> > + mmc1-clk-pins {
> > + pinmux = <K1_PADCONF(109, 0)>; /* mmc1_clk */
> > + bias-pull-down = <1>;
> > + drive-strength = <7>;
> > + power-source = <3300>;
> > + };
> > + };
> > +
> > + mmc1_uhs_cfg: mmc1-uhs-cfg {
> > + mmc1-data-cmd-pins {
> > + pinmux = <K1_PADCONF(104, 0)>, /* mmc1_d3 */
> > + <K1_PADCONF(105, 0)>, /* mmc1_d2 */
> > + <K1_PADCONF(106, 0)>, /* mmc1_d1 */
> > + <K1_PADCONF(107, 0)>, /* mmc1_d0 */
> > + <K1_PADCONF(108, 0)>; /* mmc1_cmd */
> > + bias-pull-up = <1>;
> > + drive-strength = <13>;
> See above.
>
> - Troy