[PATCH 1/2] riscv: dts: spacemit: Add i2c buses on OrangePi RV2
Michael Opdenacker
michael.opdenacker at rootcommit.com
Tue Dec 16 13:05:37 PST 2025
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/
More information about the linux-riscv
mailing list