[PATCH 1/2] riscv: dts: spacemit: Add i2c buses on OrangePi RV2

[Yao Zi]

On Mon, Dec 15, 2025 at 03:00:52PM +0000, Michael Opdenacker wrote:
> Hi Yao
> 
> Thanks for your helpful questions!
> 
> On 12/15/25 13:58, Yao Zi wrote:
> > On Mon, Dec 15, 2025 at 10:10:14AM +0000, Michael Opdenacker wrote:
> > > The OrangePi RV2 board exposes i2c2 and i2c8 buses
> > > from the Spacemit K1 SoC.
> > > 
> > > This declares devices present on such buses, in particular
> > > the at24 eeprom to store MAC addresses and the regulators
> > > attached to the PMIC on i2c8.
> > This series is named as "Attempt to enable MMC on SpacemiT K1 boards",
> > what's the relationship between MMC and PMIC/I2C bus? You didn't make
> > use of any regulators in the second patch, either (which seems wrong to
> > me).
> 
> I expected that declaring the regulators under the PMIC on i2c8 was enough
> to enable them, but I'm happy to be corrected.

Declaring them doesn't mean enable them. Regulator subsystem maintains a
enable reference count, and when it downcounts to zero, the regulator
gets disabled.

If no driver acquires one regulator, it gets disabled after 30s since
the regulator subsystem is initialized, see regulator_init_complete()
and regulator_init_complete_work_function.

On BPI F3, SD is supplied by buck4 of the PMIC. It's marked as
regulator-always-on, so wouldn't be disabled and then cause issues for
the SD card, but this doesn't mean it's okay to omit the correct
regulator supplier of SD.

> > 
> > vmmc-supply specifies the card's power supply. And if you want to enable
> > SDR modes which mandate 1.8v IO level, vqmmc-supply is also necessary
> > for switching between 1.8v and 3.3v.
> 
> 
> I was thinking to get started without the SDR modes first, to make sure
> basic operation works first. Would that work?

Yes.

FYI, for SDR104 mode, you may need to implement some tuning logic[1] as
indicated by vendor driver,

	/*
	 * Tuning is required for SDR50/SDR104, HS200/HS400 cards and
	 * if clock frequency is greater than 100MHz in these modes.
	 */

Though in mainline the eMMC on BPI-F3 already makes use of HS400 mode
without tuning. No idea what happened here, or it just happens to work
well.

Also, the pin controller on K1 SoC seems to have some undocumented
registers to select the IO voltage of SD pins, which should be adjusted
when switching IO voltage[2].

I think these pins should be implemented in the pinctrl driver, then you
could create two pinctrl states, one for 1.8v operation, one for 3.3v,
and switch between them through pinctrl_lookup_state() when changing IO
voltage.

The last thing to mention is that the three MMC controllers on K1 aren't
same, The one used for eMMC is the only one that has a phy (both SD and
SDIO controllers are marked as SDHCI_QUIRK2_BROKEN_PHY_MODULE[3]), thus
have different reset and tuning logics.

You probably need to create new compatibles for the SD and SDIO
controllers instead of re-using spacemit,k1-sdhci, and write correct
sdhci_spacemit_reset() for controllers without phy. This is probably
necessary even if you don't implement SDR modes.

> Would you have board examples to recommend, with an MMC controller operating
> in a way similar to the one on SpacemiT K1?

All sd/emmc controllers work similarly... you may want to take a look at
mmc-controller-common.yaml for common properties.

> Thanks again
> Michael.

That's it! I've struggled for hours with the MMC driver, and these are
all strange points which I've figured out. Hope it's helpful, and feel
free to ask me if I am not clear.

Regards,
Yao Zi

[1]: https://gitee.com/spacemit-buildroot/linux-6.6/blob/k1-bl-v2.2.y/drivers/mmc/host/sdhci-of-k1x.c#L1203
[2]: https://gitee.com/spacemit-buildroot/linux-6.6/blob/k1-bl-v2.2.y/drivers/mmc/host/sdhci-of-k1x.c#L923
[3]: https://gitee.com/spacemit-buildroot/linux-6.6/blob/k1-bl-v2.2.y/arch/riscv/boot/dts/spacemit/k1-x_deb1.dts#L670