[PATCH 0/2] Attempt to enable MMC on SpacemiT K1 boards

[PATCH 0/2] Attempt to enable MMC on SpacemiT K1 boards

[Michael Opdenacker]

The following commits are trying to enable MMC support on the OrangePi RV2
and BananaPi F3 boards.

This is partially supported. On both boards, partitions are
recognized and a filesystem can be read until a certain point.

However, after attempting to read a partition via dd to /dev/null,
this error is shown:

[ 503.868650] Disabling IRQ #21

IRQ #21 was indeed the IRQ for mmc (from /proc/interrupts):

     CPU0 CPU1 CPU2 CPU3 CPU4 CPU5 CPU6 CPU7
 21: 390 0 0 0 0 0 0 0 SiFive PLIC 99 Edge mmc1

This "Disabling IRQ" message comes from kernel/irq/spurious.c,
meaning that the IRQ was spurious, i.e. not handled by the driver.

This is confirmed by the number of interrupts:

     CPU0 CPU1 CPU2 CPU3 CPU4 CPU5 CPU6 CPU7
 21: 100391 0 0 0 0 0 0 0 SiFive PLIC 99 Edge mmc1

What could be wrong? Are the pin configurations correct?
My understanding of MMC/SD and of the K1 SoC is very limited.

Signed-off-by: Michael Opdenacker <michael.opdenacker@rootcommit.com>
---
Michael Opdenacker (2):
      riscv: dts: spacemit: Add i2c buses on OrangePi RV2
      riscv: dts: spacemit: Add MMC support on BPI-F3 and OrangePi RV2

 arch/riscv/boot/dts/spacemit/k1-bananapi-f3.dts  |  12 ++
 arch/riscv/boot/dts/spacemit/k1-orangepi-rv2.dts | 176 +++++++++++++++++++++++
 arch/riscv/boot/dts/spacemit/k1-pinctrl.dtsi     |  13 ++
 arch/riscv/boot/dts/spacemit/k1.dtsi             |  10 ++
 4 files changed, 211 insertions(+)
---
base-commit: 8f0b4cce4481fb22653697cced8d0d04027cb1e8
change-id: 20251215-k1-boards-add-mmc-843c7d9e5822

Best regards,
-- 
Michael Opdenacker <michael.opdenacker@rootcommit.com>


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

[PATCH 2/2] riscv: dts: spacemit: Add MMC support on BPI-F3 and OrangePi RV2

[Michael Opdenacker]

This introduces a new sdhci0 node and enables it
for the BananaPI F3 and OrangePi RV2 boards.

Note that card detect is marked as broken in the driver
(SDHCI_QUIRK_BROKEN_CARD_DETECTION quirk), therefore removing the card
while the system is running won't have any effect.

Signed-off-by: Michael Opdenacker <michael.opdenacker@rootcommit.com>
---
 arch/riscv/boot/dts/spacemit/k1-bananapi-f3.dts  | 12 ++++++++++++
 arch/riscv/boot/dts/spacemit/k1-orangepi-rv2.dts | 10 ++++++++++
 arch/riscv/boot/dts/spacemit/k1-pinctrl.dtsi     | 13 +++++++++++++
 arch/riscv/boot/dts/spacemit/k1.dtsi             | 10 ++++++++++
 4 files changed, 45 insertions(+)

diff --git a/arch/riscv/boot/dts/spacemit/k1-bananapi-f3.dts b/arch/riscv/boot/dts/spacemit/k1-bananapi-f3.dts
index 02f218a16318..1ff758115496 100644
--- a/arch/riscv/boot/dts/spacemit/k1-bananapi-f3.dts
+++ b/arch/riscv/boot/dts/spacemit/k1-bananapi-f3.dts
@@ -16,6 +16,8 @@ aliases {
 		serial0 = &uart0;
 		i2c2 = &i2c2;
 		i2c8 = &i2c8;
+		mmc0 = &emmc;
+		mmc1 = &sdhci0;
 	};
 
 	chosen {
@@ -264,6 +266,16 @@ dldo7 {
 	};
 };
 
+&sdhci0 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&mmc1_cfg>;
+	bus-width = <4>;
+	cd-gpios = <&gpio K1_GPIO(80) GPIO_ACTIVE_HIGH>;
+	cd-inverted;
+	no-sdio;
+	status = "okay";
+};
+
 &uart0 {
 	pinctrl-names = "default";
 	pinctrl-0 = <&uart0_2_cfg>;
diff --git a/arch/riscv/boot/dts/spacemit/k1-orangepi-rv2.dts b/arch/riscv/boot/dts/spacemit/k1-orangepi-rv2.dts
index b9b760d7c398..7204f419c856 100644
--- a/arch/riscv/boot/dts/spacemit/k1-orangepi-rv2.dts
+++ b/arch/riscv/boot/dts/spacemit/k1-orangepi-rv2.dts
@@ -247,6 +247,16 @@ dldo7 {
 	};
 };
 
+&sdhci0 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&mmc1_cfg>;
+	bus-width = <4>;
+	cd-gpios = <&gpio K1_GPIO(80) GPIO_ACTIVE_HIGH>;
+	cd-inverted;
+	no-sdio;
+	status = "okay";
+};
+
 &pdma {
 	status = "okay";
 };
diff --git a/arch/riscv/boot/dts/spacemit/k1-pinctrl.dtsi b/arch/riscv/boot/dts/spacemit/k1-pinctrl.dtsi
index e922e05ff856..87e84a880fbc 100644
--- a/arch/riscv/boot/dts/spacemit/k1-pinctrl.dtsi
+++ b/arch/riscv/boot/dts/spacemit/k1-pinctrl.dtsi
@@ -537,4 +537,17 @@ pwm14-1-pins {
 			drive-strength = <32>;
 		};
 	};
+
+	mmc1_cfg: mmc1-cfg {
+		mmc1-pins {
+			pinmux = <K1_PADCONF(92, 0)>,   /* mmc1_d3 */
+				 <K1_PADCONF(91, 0)>,   /* mmc1_d2 */
+				 <K1_PADCONF(90, 0)>,   /* mmc1_d1 */
+				 <K1_PADCONF(89, 0)>,   /* mmc1_d0 */
+				 <K1_PADCONF(113, 0)>,  /* mmc1_cmd */
+				 <K1_PADCONF(114, 0)>;  /* mmc1_clk */
+			bias-pull-up = <1>;
+			drive-strength = <21>;
+		};
+	};
 };
diff --git a/arch/riscv/boot/dts/spacemit/k1.dtsi b/arch/riscv/boot/dts/spacemit/k1.dtsi
index 7818ca4979b6..a5b7d7c8c066 100644
--- a/arch/riscv/boot/dts/spacemit/k1.dtsi
+++ b/arch/riscv/boot/dts/spacemit/k1.dtsi
@@ -987,6 +987,16 @@ emmc: mmc@d4281000 {
 				interrupts = <101>;
 				status = "disabled";
 			};
+
+			sdhci0: mmc@d4280000 {
+				compatible = "spacemit,k1-sdhci";
+				reg = <0x0 0xd4280000 0x0 0x200>;
+				clocks = <&syscon_apmu CLK_SDH_AXI>,
+					 <&syscon_apmu CLK_SDH0>;
+				clock-names = "core", "io";
+				interrupts = <99>;
+				status = "disabled";
+			};
 		};
 	};
 };

-- 
2.43.0


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

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

[Michael Opdenacker]

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.

Signed-off-by: Michael Opdenacker <michael.opdenacker@rootcommit.com>
---
 arch/riscv/boot/dts/spacemit/k1-orangepi-rv2.dts | 166 +++++++++++++++++++++++
 1 file changed, 166 insertions(+)

diff --git a/arch/riscv/boot/dts/spacemit/k1-orangepi-rv2.dts b/arch/riscv/boot/dts/spacemit/k1-orangepi-rv2.dts
index 41dc8e35e6eb..b9b760d7c398 100644
--- a/arch/riscv/boot/dts/spacemit/k1-orangepi-rv2.dts
+++ b/arch/riscv/boot/dts/spacemit/k1-orangepi-rv2.dts
@@ -17,6 +17,8 @@ aliases {
 		serial0 = &uart0;
 		ethernet0 = &eth0;
 		ethernet1 = &eth1;
+		i2c2 = &i2c2;
+		i2c8 = &i2c8;
 	};
 
 	chosen {
@@ -33,6 +35,25 @@ led1 {
 			default-state = "on";
 		};
 	};
+
+	reg_dc_in: dc-in-12v {
+		compatible = "regulator-fixed";
+		regulator-name = "dc_in_12v";
+		regulator-min-microvolt = <12000000>;
+		regulator-max-microvolt = <12000000>;
+		regulator-boot-on;
+		regulator-always-on;
+	};
+
+	reg_vcc_4v: vcc-4v {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc_4v";
+		regulator-min-microvolt = <4000000>;
+		regulator-max-microvolt = <4000000>;
+		regulator-boot-on;
+		regulator-always-on;
+		vin-supply = <&reg_dc_in>;
+	};
 };
 
 &eth0 {
@@ -81,6 +102,151 @@ rgmii1: phy@1 {
 	};
 };
 
+&i2c2 {
+	pinctrl-0 = <&i2c2_0_cfg>;
+	pinctrl-names = "default";
+	status = "okay";
+
+	eeprom@50 {
+		compatible = "atmel,24c02";
+		reg = <0x50>;
+		vcc-supply = <&buck3_1v8>; /* EEPROM_VCC1V8 */
+		pagesize = <16>;
+		read-only;
+		size = <256>;
+
+		nvmem-layout {
+			compatible = "onie,tlv-layout";
+
+			mac-address {
+				#nvmem-cell-cells = <1>;
+			};
+
+			num-macs {
+			};
+
+			serial-number {
+			};
+		};
+	};
+};
+
+&i2c8 {
+	pinctrl-0 = <&i2c8_cfg>;
+	pinctrl-names = "default";
+	status = "okay";
+
+	pmic@41 {
+		compatible = "spacemit,p1";
+		reg = <0x41>;
+		interrupts = <64>;
+		vin-supply = <&reg_vcc_4v>;
+
+		regulators {
+			buck1 {
+				regulator-min-microvolt = <500000>;
+				regulator-max-microvolt = <3450000>;
+				regulator-ramp-delay = <5000>;
+				regulator-always-on;
+			};
+
+			buck2 {
+				regulator-min-microvolt = <500000>;
+				regulator-max-microvolt = <3450000>;
+				regulator-ramp-delay = <5000>;
+				regulator-always-on;
+			};
+
+			buck3_1v8: buck3 {
+				regulator-min-microvolt = <500000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-ramp-delay = <5000>;
+				regulator-always-on;
+			};
+
+			buck4 {
+				regulator-min-microvolt = <500000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-ramp-delay = <5000>;
+				regulator-always-on;
+			};
+
+			buck5 {
+				regulator-min-microvolt = <500000>;
+				regulator-max-microvolt = <3450000>;
+				regulator-ramp-delay = <5000>;
+				regulator-always-on;
+			};
+
+			buck6 {
+				regulator-min-microvolt = <500000>;
+				regulator-max-microvolt = <3450000>;
+				regulator-ramp-delay = <5000>;
+				regulator-always-on;
+			};
+
+			aldo1 {
+				regulator-min-microvolt = <500000>;
+				regulator-max-microvolt = <3400000>;
+				regulator-boot-on;
+			};
+
+			aldo2 {
+				regulator-min-microvolt = <500000>;
+				regulator-max-microvolt = <3400000>;
+			};
+
+			aldo3 {
+				regulator-min-microvolt = <500000>;
+				regulator-max-microvolt = <3400000>;
+			};
+
+			aldo4 {
+				regulator-min-microvolt = <500000>;
+				regulator-max-microvolt = <3400000>;
+			};
+
+			dldo1 {
+				regulator-min-microvolt = <500000>;
+				regulator-max-microvolt = <3400000>;
+				regulator-boot-on;
+			};
+
+			dldo2 {
+				regulator-min-microvolt = <500000>;
+				regulator-max-microvolt = <3400000>;
+			};
+
+			dldo3 {
+				regulator-min-microvolt = <500000>;
+				regulator-max-microvolt = <3400000>;
+			};
+
+			dldo4 {
+				regulator-min-microvolt = <500000>;
+				regulator-max-microvolt = <3400000>;
+				regulator-always-on;
+			};
+
+			dldo5 {
+				regulator-min-microvolt = <500000>;
+				regulator-max-microvolt = <3400000>;
+			};
+
+			dldo6 {
+				regulator-min-microvolt = <500000>;
+				regulator-max-microvolt = <3400000>;
+				regulator-always-on;
+			};
+
+			dldo7 {
+				regulator-min-microvolt = <500000>;
+				regulator-max-microvolt = <3400000>;
+			};
+		};
+	};
+};
+
 &pdma {
 	status = "okay";
 };

-- 
2.43.0


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [PATCH 2/2] riscv: dts: spacemit: Add MMC support on BPI-F3 and OrangePi RV2

[Yao Zi]

On Mon, Dec 15, 2025 at 10:10:14AM +0000, Michael Opdenacker wrote:
> This introduces a new sdhci0 node and enables it
> for the BananaPI F3 and OrangePi RV2 boards.
> 
> Note that card detect is marked as broken in the driver
> (SDHCI_QUIRK_BROKEN_CARD_DETECTION quirk), therefore removing the card
> while the system is running won't have any effect.

This description looks suspicious: SDHCI_QUIRK_BROKEN_CARD_DETECTION
doesn't break hotplug. It only informs sdhci core to actively poll for
card status, instead of relying on interrupts for status change.

...

> diff --git a/arch/riscv/boot/dts/spacemit/k1.dtsi b/arch/riscv/boot/dts/spacemit/k1.dtsi
> index 7818ca4979b6..a5b7d7c8c066 100644
> --- a/arch/riscv/boot/dts/spacemit/k1.dtsi
> +++ b/arch/riscv/boot/dts/spacemit/k1.dtsi
> @@ -987,6 +987,16 @@ emmc: mmc@d4281000 {
>  				interrupts = <101>;
>  				status = "disabled";
>  			};
> +
> +			sdhci0: mmc@d4280000 {
> +				compatible = "spacemit,k1-sdhci";
> +				reg = <0x0 0xd4280000 0x0 0x200>;
> +				clocks = <&syscon_apmu CLK_SDH_AXI>,
> +					 <&syscon_apmu CLK_SDH0>;
> +				clock-names = "core", "io";
> +				interrupts = <99>;
> +				status = "disabled";
> +			};

This node should be probably put before the emmc node, since it comes
with lower address.

Regards,
Yao Zi

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

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

[Yao Zi]

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).

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.

Regards,
Yao Zi

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [PATCH 2/2] riscv: dts: spacemit: Add MMC support on BPI-F3 and OrangePi RV2

[Michael Opdenacker]

Hi Yao

Thanks a lot for the review!

On 12/15/25 13:46, Yao Zi wrote:
> On Mon, Dec 15, 2025 at 10:10:14AM +0000, Michael Opdenacker wrote:
>> This introduces a new sdhci0 node and enables it
>> for the BananaPI F3 and OrangePi RV2 boards.
>>
>> Note that card detect is marked as broken in the driver
>> (SDHCI_QUIRK_BROKEN_CARD_DETECTION quirk), therefore removing the card
>> while the system is running won't have any effect.
> This description looks suspicious: SDHCI_QUIRK_BROKEN_CARD_DETECTION
> doesn't break hotplug. It only informs sdhci core to actively poll for
> card status, instead of relying on interrupts for status change.

I must have misinterpreted the code.  I modified the description to just 
mention
that card detection currently doesn't work with these changes.

>
> ...
>
>> diff --git a/arch/riscv/boot/dts/spacemit/k1.dtsi b/arch/riscv/boot/dts/spacemit/k1.dtsi
>> index 7818ca4979b6..a5b7d7c8c066 100644
>> --- a/arch/riscv/boot/dts/spacemit/k1.dtsi
>> +++ b/arch/riscv/boot/dts/spacemit/k1.dtsi
>> @@ -987,6 +987,16 @@ emmc: mmc@d4281000 {
>>   				interrupts = <101>;
>>   				status = "disabled";
>>   			};
>> +
>> +			sdhci0: mmc@d4280000 {
>> +				compatible = "spacemit,k1-sdhci";
>> +				reg = <0x0 0xd4280000 0x0 0x200>;
>> +				clocks = <&syscon_apmu CLK_SDH_AXI>,
>> +					 <&syscon_apmu CLK_SDH0>;
>> +				clock-names = "core", "io";
>> +				interrupts = <99>;
>> +				status = "disabled";
>> +			};
> This node should be probably put before the emmc node, since it comes
> with lower address.

Oops, correct in my branch. Thanks!
Cheers
Michael.

-- 
Michael Opdenacker
Root Commit
Yocto Project and OpenEmbedded Training course - Learn by doing:
https://rootcommit.com/training/yocto/


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

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

[Michael Opdenacker]

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.

>
> 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?

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

-- 
Michael Opdenacker
Root Commit
Yocto Project and OpenEmbedded Training course - Learn by doing:
https://rootcommit.com/training/yocto/


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [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

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

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

[Javier Martinez Canillas]

Michael Opdenacker <michael.opdenacker@rootcommit.com> writes:

Hello Michael,

> 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.
>

As Yao explained, there is still work needed to make the MMC work on K1
based boards. I also tried the same on my Milk-V Jupiter and found issues.

I believe though that this patch has merits on its own and could land
regardless of the MMC support. That's why I also posted a similar change
for the Milk-V Jupiter board:

https://lore.kernel.org/lkml/20251206134532.1741648-1-javierm@redhat.com/

My changes are identical to the Banana Pi BPI-F3 and I see yours too, so
it seems all these boards are based on a K1 SoC reference design.

> Signed-off-by: Michael Opdenacker <michael.opdenacker@rootcommit.com>
> ---
>  arch/riscv/boot/dts/spacemit/k1-orangepi-rv2.dts | 166 +++++++++++++++++++++++
>  1 file changed, 166 insertions(+)
>

Personally, I would split the changes in separate patches as I did on my
series. But I guess it is also OK to have it as a single patch as you did:

Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>

-- 
Best regards,

Javier Martinez Canillas
Core Platforms
Red Hat


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

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

[Michael Opdenacker]

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/


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [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@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/
>
>

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

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

[Michael Opdenacker]

Hi Iker

On 12/17/25 16:26, Iker Pedrosa wrote:
> 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.

Wow, that would be awesome indeed, all the more as my time is quite 
limited. Please do!
I'll have a look at other aspects if I can, like USB and PCI Express.

Note that I have an eMMC module if you have code to test, and I have the 
BananaPI F3 too which also has eMMC.
Happy to work together :)
Cheers
Michael.

-- 
Michael Opdenacker
Root Commit
Yocto Project and OpenEmbedded Training course - Learn by doing:
https://rootcommit.com/training/yocto/


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

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

[Javier Martinez Canillas]

Iker Pedrosa <ikerpedrosam@gmail.com> writes:

Hello Iker,

> 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:
>

Just one correction: it was Yao who gave that feedback, not me.

> 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.
>

I think you are correct with all of these.

> 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.
>

As Micheal said, that would be great. Please let me know if I can help in
any way since I also have a board to test (Milk-V Jupiter with a MMC slot).

-- 
Best regards,

Javier Martinez Canillas
Core Platforms
Red Hat


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

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

[Johannes Erdfelt]

On Wed, Dec 17, 2025, Michael Opdenacker <michael.opdenacker@rootcommit.com> wrote:
> Wow, that would be awesome indeed, all the more as my time is quite limited.
> Please do!
> I'll have a look at other aspects if I can, like USB and PCI Express.

If it helps, I have PCIe working on my RV2 board. I based it on the BPI
F3 patches but RV2 also requires enabling 3.3v for the M.2 slot.

I haven't ever submitted a DT patch before, but I'd be willing to clean
up my patch.

JE


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

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

[Michael Opdenacker]

Hi Johannes

On 12/17/25 23:10, Johannes Erdfelt wrote:
> On Wed, Dec 17, 2025, Michael Opdenacker <michael.opdenacker@rootcommit.com> wrote:
>> Wow, that would be awesome indeed, all the more as my time is quite limited.
>> Please do!
>> I'll have a look at other aspects if I can, like USB and PCI Express.
> If it helps, I have PCIe working on my RV2 board. I based it on the BPI
> F3 patches but RV2 also requires enabling 3.3v for the M.2 slot.
>
Great, please share... I needed this too on Orange Pi R2S to enable the 
two 2.5 Gb Ethernet links :)
>
> I haven't ever submitted a DT patch before, but I'd be willing to clean
> up my patch.


Sharing is always a great opportunity to learn. Here are my raw notes 
about the topic:

  * Most importantly, run scripts/checkpatch.pl on your patches before
    sending them
  * Very important too, run "make dtbs" and then "make dtbs_check" to
    validate your changes
    See https://static.sched.com/hosted_files/ossjapan2025/59/Status of
    DTS Validation in Linux Kernel - Krzysztof Kozlowski%2C Qualcomm -
    OSSJ 2025.pdf
    <https://static.sched.com/hosted_files/ossjapan2025/59/Status%20of%20DTS%20Validation%20in%20Linux%20Kernel%20-%20Krzysztof%20Kozlowski%2C%20Qualcomm%20-%20OSSJ%202025.pdf>
    for reasons why.
  * You won't be embarrassed if you already passed these first two checks ;)
  *

    Follow the DTS coding style:
    https://docs.kernel.org/devicetree/bindings/dts-coding-style.html
    - Nodes on any bus should be in ascending address order
    - If no address, order alphanumerically by node name
    - "status" right before child nodes
    - properties of the same type (like aliases) in "natural" order (1,
    3, 12...)

  *

    Don't enable features as static (default y) in Kconfig, unless you
    have a very strong reason. Otherwise, it makes the kernel bigger for
    everyone else.

  *

    When you submit first DTS support for one board, submit the DTS in
    one commit.
    https://lore.kernel.org/all/20251010-confider-raven-0ad7a810e5de@spud/

  * If someone replies "2 < v" to you, it means "Please send v2"
  *

    In commit messages, don't comment on where the DT is coming from
    (device tree is similar to...)

  *

    References should be like this, followed by a blank line before
    "Signed-off-by"

    [1] https://tinker-board.asus.com/series/tinker-board-3.html
    [2] https://tinker-board.asus.com/series/tinker-board-3s.html

  *

    Keep track of Reviewed-by and Tested-by tags (using b4 to manage
    your branch and submissions will help tremendously)
    https://b4.docs.kernel.org/en/latest/

  *

    Explain WHY you're doing something in a commit message (Krzysztof
    Kozlowski)

  * If anything is wrong or can be improved, we (the Linux kernel
    community) will be delighted to guide you, so that we end up with
    some code that's easy for others to maintain and expand.
  * Special gratitude to Krzysztof Kozlowski for always being there to
    help  on DT patches :)

I'm also available to test your patches, as I have Banana Pi F3, Orange 
Pi RV2 and R2S.

I hope you can do this in the next days, because there's a great window 
in the next days for contribution, when work slows down during the 
holidays :)
Thanks in advance
Cheers
Michael.

-- 
Michael Opdenacker
Root Commit
Yocto Project and OpenEmbedded Training course - Learn by doing:
https://rootcommit.com/training/yocto/


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

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

[Michael Opdenacker]

On 12/18/25 06:19, Michael Opdenacker wrote:
>
>  * You won't be embarrassed if you already passed these first two 
> checks ;)
>  *

I'm the one getting embarrassed 😅. Copying and pasting from Joplin 
notes into Thunderbird really made my reply ugly...

This made me forget a quite important rule: send the patches to yourself 
first:
b4 send --reflect

Michael.

-- 
Michael Opdenacker
Root Commit
Yocto Project and OpenEmbedded Training course - Learn by doing:
https://rootcommit.com/training/yocto/


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

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

[Iker Pedrosa]

Hi Michael, Yao, Javier, Johannes,

Thanks everyone for the great discussion and the guidance.

First of all, I’d like to clarify a point regarding my previous email
to avoid any confusion: the detailed technical breakdown and pointers
were provided by Yao here in the thread. My mention of Javier was
regarding a separate offline conversation we had earlier. Both
contributions have been essential to understanding why the SD card is
currently failing.

Given that we are all a bit tight on time, I think it would be best to
split the work into separate tasks so we can make progress in
parallel. Based on the feedback, here is the roadmap:

1. 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).
2. Extend the pinctrl driver: support is needed for switching the SD
voltage pins from 3.3V to 1.8V.
3. Add tuning logic: this is required at least for SDR modes.

Since I’ll be focusing on the driver/reset logic (1), is there anyone
else willing to pick up the pinctrl (2) or the tuning (3)?

Looking forward to working together on this.


El jue, 18 dic 2025 a las 6:25, Michael Opdenacker
(<michael.opdenacker@rootcommit.com>) escribió:
>
>
> On 12/18/25 06:19, Michael Opdenacker wrote:
> >
> >  * You won't be embarrassed if you already passed these first two
> > checks ;)
> >  *
>
> I'm the one getting embarrassed 😅. Copying and pasting from Joplin
> notes into Thunderbird really made my reply ugly...
>
> This made me forget a quite important rule: send the patches to yourself
> first:
> b4 send --reflect
>
> Michael.
>
> --
> Michael Opdenacker
> Root Commit
> Yocto Project and OpenEmbedded Training course - Learn by doing:
> https://rootcommit.com/training/yocto/
>

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

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

[Yixun Lan]

Hi Iker,

thanks for pushing this, I have few comments

On 10:49 Thu 18 Dec     , Iker Pedrosa wrote:
> Hi Michael, Yao, Javier, Johannes,
> 
> Thanks everyone for the great discussion and the guidance.
> 
> First of all, I’d like to clarify a point regarding my previous email
> to avoid any confusion: the detailed technical breakdown and pointers
> were provided by Yao here in the thread. My mention of Javier was
> regarding a separate offline conversation we had earlier. Both
> contributions have been essential to understanding why the SD card is
> currently failing.
> 
> Given that we are all a bit tight on time, I think it would be best to
> split the work into separate tasks so we can make progress in
> parallel. Based on the feedback, here is the roadmap:
> 
> 1. 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).
I agree, separate compatibles sounds more feasibile, vendor reuse macro
of MMC_CAP2_NO_{SD,SDIO,MMC} to differentiate the controller which is
kind of unmaintainable

> 2. Extend the pinctrl driver: support is needed for switching the SD
> voltage pins from 3.3V to 1.8V.
we probably could leave pinctrl for now or take a look at it later when
really necessary,  the default pin settings should work for most cases,
besides, vendor is also starting to drop two pinctrl state implementation
(the normal vs fast ..)

for 3.3v to 1.8v switch, there is one MMC1_IO_REG to control it, and
we do need to implement a _voltage_switch() function
and it's in another aib io space..

> 3. Add tuning logic: this is required at least for SDR modes.
> 
right, especially for high speed clock

> Since I’ll be focusing on the driver/reset logic (1), is there anyone
the reset logic is also needed for K3 SoC, so I'd like to get it added
early, I could get a patch for it during the weekend if you don't mind,
or can leave it to you if you will do it shortly..

> else willing to pick up the pinctrl (2) or the tuning (3)?
> 
I do want to work on SD/SDIO support, but for now I need to push
clock/pinctrl for K3 SoC first, then will have time to take a look

> Looking forward to working together on this.
> 
great!

-- 
Yixun Lan (dlan)

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

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

[Yao Zi]

On Fri, Dec 19, 2025 at 07:29:24PM +0800, Yixun Lan wrote:
> Hi Iker,
> 
> thanks for pushing this, I have few comments
> 
> On 10:49 Thu 18 Dec     , Iker Pedrosa wrote:
> > Hi Michael, Yao, Javier, Johannes,
> > 
> > Thanks everyone for the great discussion and the guidance.

...

> > 2. Extend the pinctrl driver: support is needed for switching the SD
> > voltage pins from 3.3V to 1.8V.
> we probably could leave pinctrl for now or take a look at it later when
> really necessary,  the default pin settings should work for most cases,
> besides, vendor is also starting to drop two pinctrl state implementation
> (the normal vs fast ..)
> 
> for 3.3v to 1.8v switch, there is one MMC1_IO_REG to control it, and
> we do need to implement a _voltage_switch() function
> and it's in another aib io space..

Note the MMC1_IO_REG (0xd401_e81c) stays right in the Pad Configuration
region (0xd401_e000, length 0xc00) as stated in the address mapping of
TRM.

So it's not another io space, it's right the pin controller. This makes
me believe it's an undocumented pinctrl register, in which case it's
pretty natural to implement the switch logic through pinctrl interface.

Seems I forgot to mention one thing: there are mysterious "asfar" and
"assar" registers in APBC region which are written 0xbaba and 0xeb10
during voltage switch process.

I've looked through the TRM and found they aren't documented, either.
But handling of them should be easy, since the whole APBC region is
registered as a syscon, though it will still be helpful to know their
effects...

Regards,
Yao Zi

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

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

[Chukun Pan]

Hi,

> +	reg_dc_in: dc-in-12v {
> +		compatible = "regulator-fixed";
> +		regulator-name = "dc_in_12v";
> +		regulator-min-microvolt = <12000000>;
> +		regulator-max-microvolt = <12000000>;
> +		regulator-boot-on;
> +		regulator-always-on;
> +	};

This does not match the schematic. (vcc_5v0 instead of dc-in-12v)
https://drive.google.com/drive/folders/1pcI_U0C3VJKTCg8A1zj08CwNbohnONSR

> +
> +	reg_vcc_4v: vcc-4v {
> +		compatible = "regulator-fixed";
> +		regulator-name = "vcc_4v";
> +		regulator-min-microvolt = <4000000>;
> +		regulator-max-microvolt = <4000000>;
> +		regulator-boot-on;
> +		regulator-always-on;
> +		vin-supply = <&reg_dc_in>;
> +	};

It is also missing the regulator prefix.
So it should look like this:

```
	vcc_5v0: regulator-vcc-5v0 {
		compatible = "regulator-fixed";
		regulator-name = "vcc_5v0";
		regulator-always-on;
		regulator-boot-on;
		regulator-min-microvolt = <5000000>;
		regulator-max-microvolt = <5000000>;
	};

	vcc4v0: regulator-vcc4v0 {
		compatible = "regulator-fixed";
		regulator-name = "vcc4v0";
		regulator-always-on;
		regulator-boot-on;
		regulator-min-microvolt = <4000000>;
		regulator-max-microvolt = <4000000>;
		vin-supply = <&vcc_5v0>;
	};
```

> +&i2c2 {
> +	pinctrl-0 = <&i2c2_0_cfg>;
> +	pinctrl-names = "default";
> +	status = "okay";
> +
> +	eeprom@50 {
> +		compatible = "atmel,24c02";
> +		reg = <0x50>;
> +		vcc-supply = <&buck3_1v8>; /* EEPROM_VCC1V8 */

vcc-supply should be placed after size.

> +		pagesize = <16>;
> +		read-only;
> +		size = <256>;
> +
> +		nvmem-layout {
> +			compatible = "onie,tlv-layout";
> +
> +			mac-address {
> +				#nvmem-cell-cells = <1>;
> +			};
> +
> +			num-macs {
> +			};
> +
> +			serial-number {
> +			};

From vendor uboot:

=> tlv_eeprom 
TLV: 0
[   6.991] TlvInfo Header:
[   6.992]    Id String:    TlvInfo
[   6.995]    Version:      1
[   6.997]    Total Length: 38
[   7.000] TLV Name             Code Len Value
[   7.004] -------------------- ---- --- -----
[   7.009] Base MAC Address     0x24   6 xxxxx
[   7.014] MAC Addresses        0x2A   2 2
[   7.018] Unknown              0x41   1  0x01
[   7.022] Product Name         0x21  15 x1_orangepi-rv2
[   7.027] CRC-32               0xFE   4 0x...
[   7.031] Checksum is valid.

There is no serial-number (0x23) in the EEPROM.
Does "product-name" need to be described here?

> +		};
> +	};

Thanks,
Chukun

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [PATCH 2/2] riscv: dts: spacemit: Add MMC support on BPI-F3 and OrangePi RV2

[Chukun Pan]

Hi,

> +&sdhci0 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&mmc1_cfg>;

It would be better to arrange them in alphabetical order.
(Place pinctrl below no-sdio)

> +	bus-width = <4>;
> +	cd-gpios = <&gpio K1_GPIO(80) GPIO_ACTIVE_HIGH>;

It seems that "cap-sd-highspeed" is missing?

> +	cd-inverted;
> +	no-sdio;
> +	status = "okay";
> +};

> +			sdhci0: mmc@d4280000 {

An immature idea. Would naming nodes this way be better?

sdmmc: mmc@d4280000
 sdio: mmc@d4280800
 emmc: mmc@d4281000

This seems to fit the description here better:
https://bianbu-linux.spacemit.com/en/device/peripheral_driver/SDHC/#dts-configuration

Thanks,
Chukun

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [PATCH 2/2] riscv: dts: spacemit: Add MMC support on BPI-F3 and OrangePi RV2

[Javier Martinez Canillas]

Chukun Pan <amadeus@jmu.edu.cn> writes:

> Hi,
>
>> +&sdhci0 {
>> +	pinctrl-names = "default";
>> +	pinctrl-0 = <&mmc1_cfg>;
>
> It would be better to arrange them in alphabetical order.
> (Place pinctrl below no-sdio)
>
>> +	bus-width = <4>;
>> +	cd-gpios = <&gpio K1_GPIO(80) GPIO_ACTIVE_HIGH>;
>
> It seems that "cap-sd-highspeed" is missing?
>
>> +	cd-inverted;
>> +	no-sdio;
>> +	status = "okay";
>> +};
>
>> +			sdhci0: mmc@d4280000 {
>
> An immature idea. Would naming nodes this way be better?
>
> sdmmc: mmc@d4280000
>  sdio: mmc@d4280800
>  emmc: mmc@d4281000
>
> This seems to fit the description here better:
> https://bianbu-linux.spacemit.com/en/device/peripheral_driver/SDHC/#dts-configuration
>

I initially thought something similar but it's not accurate. Because as
explained in the doc that you referred:

* slot1 supports SD/SDIO (1/4 bit)
* slot2 supports SDIO/eMMC (1/4 bit)
* slot3 supports only eMMC (1/4/8 bit)

Which means that only slot3 is limited to eMMC.

So even when a typical configuration is what you mentioned (and what I saw
in most of the existing designs), slots 1 and 2 won't always be SD and SDIO.

-- 
Best regards,

Javier Martinez Canillas
Core Platforms
Red Hat


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv