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

[Iker Pedrosa]

Hi Michael,

Based on the discussion and Javier's feedback, to make the SD card
work properly, we need to patch the driver to implement the following:

Define a separate compatible string: the eMMC slot has a PHY, while
SD/SDIO slots do not. We need to differentiate them to apply the
correct reset logic (skipping PHY init for SD).
Extend the pinctrl driver: support is needed for switching the SD
voltage pins from 3.3V to 1.8V.
Add tuning logic: this is required at least for SDR modes.

If you don't mind, I'll start working on point #1. Feel free to choose
any other task.

I'll post a patch once I have it working.


El mar, 16 dic 2025 a las 22:30, Michael Opdenacker
(<michael.opdenacker at rootcommit.com>) escribió:
>
> Hi Yao
>
> Thanks a lot for your help and tips, much appreciated!
>
> On 12/16/25 06:37, Yao Zi wrote:
> > 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.
>
> Good to know!
> Surprisingly, when I add this to the "sdhci0" node:
>
> vmmc-supply = <&buck4_3v3>;
>
> (after creating the label, of course), the device and its partition no
> longer show up in /proc/partitions!
>
> I was hopeful because read-only mode already seems to work, but maybe
> indeed things are more complicated.
> >
> >>> 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.
>
> Wow, that's surprising.
> https://developer.spacemit.com/documentation?token=WZNvwFDkYinYx0k9jzPcMK5WnIe#12.5-sd%2Femmc
> doesn't seem to mention this (though I didn't check very carefully yet).
> >
> > 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.
>
> Right, I'm already using it :)
>
> I'll be patient and try to progress step by step. My time is quite
> limited these days, so everyone is welcome to try and make this work.
> Thanks again for everything
> Cheers
> Michael.
>
> --
> Michael Opdenacker
> Root Commit
> Yocto Project and OpenEmbedded Training course - Learn by doing:
> https://rootcommit.com/training/yocto/
>
>