[PATCH v1 1/9] dt-bindings: reset: altr: add COMBOPHY_RESET for Agilex5

[PATCH v1 1/9] dt-bindings: reset: altr: add COMBOPHY_RESET for Agilex5

[Tanmay Kathpalia]

Add COMBOPHY_RESET definition at index 38 for the combo PHY reset
control on Altera Agilex5 SoCs. This reset is used by peripherals
such as the SD/eMMC controller that share the combo PHY.

Signed-off-by: Tanmay Kathpalia <tanmay.kathpalia@altera.com>
---
 include/dt-bindings/reset/altr,rst-mgr-s10.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/dt-bindings/reset/altr,rst-mgr-s10.h b/include/dt-bindings/reset/altr,rst-mgr-s10.h
index 04c4d0c6fd34..c2505b9eb63e 100644
--- a/include/dt-bindings/reset/altr,rst-mgr-s10.h
+++ b/include/dt-bindings/reset/altr,rst-mgr-s10.h
@@ -22,7 +22,7 @@
 #define USB0_RESET		35
 #define USB1_RESET		36
 #define NAND_RESET		37
-/* 38 is empty */
+#define COMBOPHY_RESET		38
 #define SDMMC_RESET		39
 #define EMAC0_OCP_RESET		40
 #define EMAC1_OCP_RESET		41
-- 
2.43.7

Re: [PATCH v1 1/9] dt-bindings: reset: altr: add COMBOPHY_RESET for Agilex5

[Conor Dooley]

[-- Attachment #1: Type: text/plain, Size: 413 bytes --]

On Mon, May 11, 2026 at 01:21:23PM -0700, Tanmay Kathpalia wrote:
> Add COMBOPHY_RESET definition at index 38 for the combo PHY reset
> control on Altera Agilex5 SoCs. This reset is used by peripherals
> such as the SD/eMMC controller that share the combo PHY.
> 
> Signed-off-by: Tanmay Kathpalia <tanmay.kathpalia@altera.com>

Acked-by: Conor Dooley <conor.dooley@microchip.com>
pw-bot: not-applicable

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

[PATCH v1 2/9] dt-bindings: mmc: cdns,sdhci: add SD6HC support and PHY properties

[Tanmay Kathpalia]

Extend the Cadence SDHCI binding to support the sixth-generation
SD6HC controller. Add the cdns,sd6hc and altr,agilex5-sd6hc
compatible strings, clock-names, reset-names, iommus and three
SD6HC-specific PHY timing properties.

Add per-variant conditional blocks so SD6HC and SD4HC each enforce
their own clock, reset, and PHY property constraints independently.

Signed-off-by: Tanmay Kathpalia <tanmay.kathpalia@altera.com>
---
 .../devicetree/bindings/mmc/cdns,sdhci.yaml   | 107 ++++++++++++++++--
 1 file changed, 97 insertions(+), 10 deletions(-)

diff --git a/Documentation/devicetree/bindings/mmc/cdns,sdhci.yaml b/Documentation/devicetree/bindings/mmc/cdns,sdhci.yaml
index 6c7317d13aa6..e483ff83cbc2 100644
--- a/Documentation/devicetree/bindings/mmc/cdns,sdhci.yaml
+++ b/Documentation/devicetree/bindings/mmc/cdns,sdhci.yaml
@@ -4,21 +4,29 @@
 $id: http://devicetree.org/schemas/mmc/cdns,sdhci.yaml#
 $schema: http://devicetree.org/meta-schemas/core.yaml#
 
-title: Cadence SD/SDIO/eMMC Host Controller (SD4HC)
+title: Cadence SD/SDIO/eMMC Host Controller (SD4HC and SD6HC)
 
 maintainers:
   - Masahiro Yamada <yamada.masahiro@socionext.com>
+  - Tanmay Kathpalia <tanmay.kathpalia@altera.com>
 
 properties:
   compatible:
-    items:
-      - enum:
-          - amd,pensando-elba-sd4hc
-          - microchip,mpfs-sd4hc
-          - microchip,pic64gx-sd4hc
-          - mobileye,eyeq-sd4hc
-          - socionext,uniphier-sd4hc
-      - const: cdns,sd4hc
+    oneOf:
+      - description: Cadence SD4HC controller
+        items:
+          - enum:
+              - amd,pensando-elba-sd4hc
+              - microchip,mpfs-sd4hc
+              - microchip,pic64gx-sd4hc
+              - mobileye,eyeq-sd4hc
+              - socionext,uniphier-sd4hc
+          - const: cdns,sd4hc
+      - description: Cadence SD6HC controller
+        items:
+          - enum:
+              - altr,agilex5-sd6hc
+          - const: cdns,sd6hc
 
   reg:
     minItems: 1
@@ -28,9 +36,14 @@ properties:
     maxItems: 1
 
   clocks:
-    maxItems: 1
+    minItems: 1
+    maxItems: 2
 
   resets:
+    minItems: 1
+    maxItems: 3
+
+  iommus:
     maxItems: 1
 
   # PHY DLL input delays:
@@ -115,6 +128,25 @@ properties:
     minimum: 0
     maximum: 0x7f
 
+  # SD6HC PHY timing properties:
+  cdns,iocell-input-delay:
+    description: Input delay across IO cells in picoseconds
+    $ref: /schemas/types.yaml#/definitions/uint32
+    minimum: 0
+    maximum: 20000   # 20 ns
+
+  cdns,iocell-output-delay:
+    description: Output delay across IO cells in picoseconds
+    $ref: /schemas/types.yaml#/definitions/uint32
+    minimum: 0
+    maximum: 20000   # 20 ns
+
+  cdns,delay-element:
+    description: Delay element size in picoseconds
+    $ref: /schemas/types.yaml#/definitions/uint32
+    minimum: 1
+    maximum: 1000    # 1 ns
+
 required:
   - compatible
   - reg
@@ -139,6 +171,61 @@ allOf:
         reg:
           maxItems: 1
 
+  - if:
+      properties:
+        compatible:
+          contains:
+            const: cdns,sd6hc
+    then:
+      description: SD6HC variant - use IO-cell and delay element properties
+      properties:
+        clocks:
+          minItems: 2
+          maxItems: 2
+        clock-names:
+          items:
+            - const: ciu
+            - const: biu
+        resets:
+          minItems: 3
+          maxItems: 3
+        reset-names:
+          items:
+            - const: sdhc-reset
+            - const: combophy
+            - const: sdmmc-ocp
+        cdns,phy-input-delay-sd-highspeed: false
+        cdns,phy-input-delay-legacy: false
+        cdns,phy-input-delay-sd-uhs-sdr12: false
+        cdns,phy-input-delay-sd-uhs-sdr25: false
+        cdns,phy-input-delay-sd-uhs-sdr50: false
+        cdns,phy-input-delay-sd-uhs-ddr50: false
+        cdns,phy-input-delay-mmc-highspeed: false
+        cdns,phy-input-delay-mmc-ddr: false
+        cdns,phy-dll-delay-sdclk: false
+        cdns,phy-dll-delay-sdclk-hsmmc: false
+        cdns,phy-dll-delay-strobe: false
+      required:
+        - resets
+        - clock-names
+        - reset-names
+
+  - if:
+      properties:
+        compatible:
+          contains:
+            const: cdns,sd4hc
+    then:
+      description: SD4HC variant - use legacy DLL delay properties
+      properties:
+        clocks:
+          maxItems: 1
+        resets:
+          maxItems: 1
+        cdns,iocell-input-delay: false
+        cdns,iocell-output-delay: false
+        cdns,delay-element: false
+
 unevaluatedProperties: false
 
 examples:
-- 
2.43.7

Re: [PATCH v1 2/9] dt-bindings: mmc: cdns,sdhci: add SD6HC support and PHY properties

[Conor Dooley]

[-- Attachment #1: Type: text/plain, Size: 598 bytes --]

On Mon, May 11, 2026 at 01:21:24PM -0700, Tanmay Kathpalia wrote:
> Extend the Cadence SDHCI binding to support the sixth-generation
> SD6HC controller. Add the cdns,sd6hc and altr,agilex5-sd6hc
> compatible strings, clock-names, reset-names, iommus and three
> SD6HC-specific PHY timing properties.
> 
> Add per-variant conditional blocks so SD6HC and SD4HC each enforce
> their own clock, reset, and PHY property constraints independently.
> 
> Signed-off-by: Tanmay Kathpalia <tanmay.kathpalia@altera.com>

Acked-by: Conor Dooley <conor.dooley@microchip.com>
pw-bot: not-applicable

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH v1 2/9] dt-bindings: mmc: cdns,sdhci: add SD6HC support and PHY properties

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] clock-names and reset-names are defined exclusively inside the if:then: conditional block instead of the top-level properties block.
--

commit f399abc006829d70cb476a2bacc2fc4f092408b9
Author: Tanmay Kathpalia <tanmay.kathpalia@altera.com>

dt-bindings: mmc: cdns,sdhci: add SD6HC support and PHY properties

Extend the Cadence SDHCI binding to support the sixth-generation SD6HC
controller. Add new compatible strings, properties, and per-variant
conditional blocks to enforce hardware constraints.

> diff --git a/Documentation/devicetree/bindings/mmc/cdns,sdhci.yaml b/Documentation/devicetree/bindings/mmc/cdns,sdhci.yaml
> --- a/Documentation/devicetree/bindings/mmc/cdns,sdhci.yaml
> +++ b/Documentation/devicetree/bindings/mmc/cdns,sdhci.yaml

[ ... ]

> @@ -141,6 +173,61 @@ allOf:
> +  - if:
> +      properties:
> +        compatible:
> +          contains:
> +            const: cdns,sd6hc
> +    then:
> +      description: SD6HC variant - use IO-cell and delay element properties
> +      properties:
> +        clocks:
> +          minItems: 2
> +          maxItems: 2
> +        clock-names:
> +          items:
> +            - const: ciu
> +            - const: biu
> +        resets:
> +          minItems: 3
> +          maxItems: 3
> +        reset-names:
> +          items:
> +            - const: sdhc-reset
> +            - const: combophy
> +            - const: sdmmc-ocp

This isn't a functional bug, but does defining these properties directly
inside the conditional block violate the device tree writing schema
guidelines?

The documentation in writing-schema.rst typically requires properties to be
declared with their broadest constraints in the top-level properties block,
rather than exclusively inside an if:then: block.

Should clock-names and reset-names be added to the top-level properties
dictionary before narrowing their constraints here?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260511202132.5597-1-tanmay.kathpalia@altera.com?part=2

[PATCH v1 3/9] arm64: dts: agilex5: add Cadence SD6HC controller and SOCDK enablement

[Tanmay Kathpalia]

The Agilex5 SoC device tree gains an SD/MMC controller node backed by
the Cadence SD6HC, with IOMMU integration via the system SMMU. Card
power is supplied by a fixed 3.3V regulator and I/O voltage switching
between 1.8V and 3.3V is handled by a GPIO-controlled regulator.

The SOCDK board enables the controller for SD-only operation in 4-bit
bus width with high-speed and SDR104 UHS-I modes at 200 MHz maximum
clock. SDHCI capability overrides clear the SDR50 tuning flag and
override the clock base mask to report 200 MHz.

Signed-off-by: Tanmay Kathpalia <tanmay.kathpalia@altera.com>
---
 .../arm64/boot/dts/intel/socfpga_agilex5.dtsi | 38 +++++++++++++++++++
 .../boot/dts/intel/socfpga_agilex5_socdk.dts  | 26 +++++++++++++
 2 files changed, 64 insertions(+)

diff --git a/arch/arm64/boot/dts/intel/socfpga_agilex5.dtsi b/arch/arm64/boot/dts/intel/socfpga_agilex5.dtsi
index 352c96d144a8..7e080f13166f 100644
--- a/arch/arm64/boot/dts/intel/socfpga_agilex5.dtsi
+++ b/arch/arm64/boot/dts/intel/socfpga_agilex5.dtsi
@@ -300,6 +300,44 @@ portb: gpio-controller@0 {
 			};
 		};
 
+		sd_emmc_power: regulator-fixed-3p3v {
+			compatible = "regulator-fixed";
+			regulator-name = "card-power";
+			regulator-min-microvolt = <3300000>;
+			regulator-max-microvolt = <3300000>;
+			regulator-always-on;
+		};
+
+		sd_io_1v8_reg: regulator-1p8v {
+			compatible = "regulator-gpio";
+			regulator-name = "sd-bus-io-power";
+			regulator-min-microvolt = <1800000>;
+			regulator-max-microvolt = <3300000>;
+			states =	<1800000 0x1>,
+					<3300000 0x0>;
+		};
+
+		emmc: mmc@10808000 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			compatible = "altr,agilex5-sd6hc", "cdns,sd6hc";
+			reg = <0x10808000 0x1000>;
+			interrupts = <GIC_SPI 96 IRQ_TYPE_LEVEL_HIGH>;
+			fifo-depth = <0x800>;
+			resets = <&rst SDMMC_RESET>, <&rst COMBOPHY_RESET>, <&rst SDMMC_OCP_RESET>;
+			reset-names = "sdhc-reset", "combophy", "sdmmc-ocp";
+			/*
+			 * "ciu" (SDMCLK) is listed first so it is selected as the
+			 * primary clock by the SDHCI platform layer; the SD6HC PHY
+			 * timing calculations are derived from this clock rate.
+			 */
+			clocks = <&clkmgr AGILEX5_SDMCLK>, <&clkmgr AGILEX5_L4_MP_CLK>;
+			clock-names = "ciu", "biu";
+			iommus = <&smmu 5>;
+			dma-coherent;
+			status = "disabled";
+		};
+
 		nand: nand-controller@10b80000 {
 			compatible = "cdns,hp-nfc";
 			reg = <0x10b80000 0x10000>,
diff --git a/arch/arm64/boot/dts/intel/socfpga_agilex5_socdk.dts b/arch/arm64/boot/dts/intel/socfpga_agilex5_socdk.dts
index 262bb3e8e5c7..a9de824e292a 100644
--- a/arch/arm64/boot/dts/intel/socfpga_agilex5_socdk.dts
+++ b/arch/arm64/boot/dts/intel/socfpga_agilex5_socdk.dts
@@ -98,6 +98,32 @@ root: partition@4200000 {
 	};
 };
 
+&sd_io_1v8_reg {
+	gpios = <&portb 3 GPIO_ACTIVE_HIGH>;
+};
+
+&emmc {
+	status = "okay";
+
+	no-mmc;
+	disable-wp;
+	bus-width = <4>;
+	cap-sd-highspeed;
+	sd-uhs-sdr104;
+	vmmc-supply = <&sd_emmc_power>;
+	vqmmc-supply = <&sd_io_1v8_reg>;
+	max-frequency = <200000000>;
+	/*
+	 * SDHCI capability overrides:
+	 *  - caps_mask[0] 0x0000ff00 / caps[0] 0x0000c800:
+	 *      Override SDHCI_CLOCK_BASE_MASK to 0xc8 (200 MHz).
+	 *  - caps_mask[1] 0x00002000 / caps[1] 0:
+	 *      Clear SDHCI_USE_SDR50_TUNING; SDR50 tuning is unsupported.
+	 */
+	sdhci-caps = <0x00000000 0x0000c800>;
+	sdhci-caps-mask = <0x00002000 0x0000ff00>;
+};
+
 &uart0 {
 	status = "okay";
 };
-- 
2.43.7

Re: [PATCH v1 3/9] arm64: dts: agilex5: add Cadence SD6HC controller and SOCDK enablement

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] Board-specific regulators are incorrectly defined in the generic SoC .dtsi file and placed inside a simple-bus.
- [Low] The Cadence SD6HC node includes an undocumented and unsupported `fifo-depth` property.
--

commit cd8114ca6cbb7c0bc2b1d26651ea445b3eef24ec
Author: Tanmay Kathpalia <tanmay.kathpalia@altera.com>

arm64: dts: agilex5: add Cadence SD6HC controller and SOCDK enablement

This commit adds an SD/MMC controller node backed by the Cadence SD6HC
to the Agilex5 SoC device tree. It also enables the controller on the
SOCDK board with high-speed and UHS-I modes.

> diff --git a/arch/arm64/boot/dts/intel/socfpga_agilex5.dtsi b/arch/arm64/boot/dts/intel/socfpga_agilex5.dtsi
> --- a/arch/arm64/boot/dts/intel/socfpga_agilex5.dtsi
> +++ b/arch/arm64/boot/dts/intel/socfpga_agilex5.dtsi
[ ... ]
> @@ -300,6 +300,44 @@ portb: gpio-controller@0 {
>  			};
>  		};
>  
> +		sd_emmc_power: regulator-fixed-3p3v {
> +			compatible = "regulator-fixed";
> +			regulator-name = "card-power";
> +			regulator-min-microvolt = <3300000>;
> +			regulator-max-microvolt = <3300000>;
> +			regulator-always-on;
> +		};
> +
> +		sd_io_1v8_reg: regulator-1p8v {
> +			compatible = "regulator-gpio";
> +			regulator-name = "sd-bus-io-power";
> +			regulator-min-microvolt = <1800000>;
> +			regulator-max-microvolt = <3300000>;
> +			states =	<1800000 0x1>,
> +					<3300000 0x0>;
> +		};

Should these board-specific regulators be defined in the generic SoC
dtsi file instead of the board dts file?

Placing them here forces these external board-level circuitry
definitions onto all future boards using this SoC.

Additionally, because they are placed inside a simple-bus without a reg
property, it looks like they will trigger simple_bus_reg compiler
warnings. The sd_io_1v8_reg node is also missing the mandatory gpios
property in the dtsi, which might cause dtbs_check schema validation
failures for any board that does not explicitly provide one.

> +
> +		emmc: mmc@10808000 {
> +			#address-cells = <1>;
> +			#size-cells = <0>;
> +			compatible = "altr,agilex5-sd6hc", "cdns,sd6hc";
> +			reg = <0x10808000 0x1000>;
> +			interrupts = <GIC_SPI 96 IRQ_TYPE_LEVEL_HIGH>;
> +			fifo-depth = <0x800>;

Is the fifo-depth property supported by the Cadence SDHC binding?

The Cadence SDHC binding specifies unevaluatedProperties: false and
does not appear to define or support fifo-depth, which seems to be a
leftover from Synopsys DesignWare MMC bindings.

While the driver will ignore it, its presence might cause a dtbs_check
schema validation failure.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260511202132.5597-1-tanmay.kathpalia@altera.com?part=3

Re: [PATCH v1 3/9] arm64: dts: agilex5: add Cadence SD6HC controller and SOCDK enablement

[Kathpalia, Tanmay]

On 5/13/2026 6:13 AM, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
> - [Medium] Board-specific regulators are incorrectly defined in the generic SoC .dtsi file and placed inside a simple-bus.
> - [Low] The Cadence SD6HC node includes an undocumented and unsupported `fifo-depth` property.
> --
>
> commit cd8114ca6cbb7c0bc2b1d26651ea445b3eef24ec
> Author: Tanmay Kathpalia <tanmay.kathpalia@altera.com>
>
> arm64: dts: agilex5: add Cadence SD6HC controller and SOCDK enablement
>
> This commit adds an SD/MMC controller node backed by the Cadence SD6HC
> to the Agilex5 SoC device tree. It also enables the controller on the
> SOCDK board with high-speed and UHS-I modes.
>
>> diff --git a/arch/arm64/boot/dts/intel/socfpga_agilex5.dtsi b/arch/arm64/boot/dts/intel/socfpga_agilex5.dtsi
>> --- a/arch/arm64/boot/dts/intel/socfpga_agilex5.dtsi
>> +++ b/arch/arm64/boot/dts/intel/socfpga_agilex5.dtsi
> [ ... ]
>> @@ -300,6 +300,44 @@ portb: gpio-controller@0 {
>>   			};
>>   		};
>>   
>> +		sd_emmc_power: regulator-fixed-3p3v {
>> +			compatible = "regulator-fixed";
>> +			regulator-name = "card-power";
>> +			regulator-min-microvolt = <3300000>;
>> +			regulator-max-microvolt = <3300000>;
>> +			regulator-always-on;
>> +		};
>> +
>> +		sd_io_1v8_reg: regulator-1p8v {
>> +			compatible = "regulator-gpio";
>> +			regulator-name = "sd-bus-io-power";
>> +			regulator-min-microvolt = <1800000>;
>> +			regulator-max-microvolt = <3300000>;
>> +			states =	<1800000 0x1>,
>> +					<3300000 0x0>;
>> +		};
> Should these board-specific regulators be defined in the generic SoC
> dtsi file instead of the board dts file?
>
> Placing them here forces these external board-level circuitry
> definitions onto all future boards using this SoC.
>
> Additionally, because they are placed inside a simple-bus without a reg
> property, it looks like they will trigger simple_bus_reg compiler
> warnings. The sd_io_1v8_reg node is also missing the mandatory gpios
> property in the dtsi, which might cause dtbs_check schema validation
> failures for any board that does not explicitly provide one.

The sd_emmc_power and sd_io_1v8_reg regulators are
board-specific and will be moved to the board DTS file in v2. I
will also run dtbs_check schema validation to catch any
remaining issues before sending v2.
>
>> +
>> +		emmc: mmc@10808000 {
>> +			#address-cells = <1>;
>> +			#size-cells = <0>;
>> +			compatible = "altr,agilex5-sd6hc", "cdns,sd6hc";
>> +			reg = <0x10808000 0x1000>;
>> +			interrupts = <GIC_SPI 96 IRQ_TYPE_LEVEL_HIGH>;
>> +			fifo-depth = <0x800>;
> Is the fifo-depth property supported by the Cadence SDHC binding?
>
> The Cadence SDHC binding specifies unevaluatedProperties: false and
> does not appear to define or support fifo-depth, which seems to be a
> leftover from Synopsys DesignWare MMC bindings.
>
> While the driver will ignore it, its presence might cause a dtbs_check
> schema validation failure.

fifo-depth is not supported by the Cadence SD6HC binding. It will
be removed in v2. I will verify with dtbs_check schema
validation before sending.

[PATCH v1 4/9] dt-bindings: arm: intel: add Agilex5 SOCDK eMMC board variant

[Tanmay Kathpalia]

Add "intel,socfpga-agilex5-socdk-emmc" compatible string for the
Agilex5 SOCDK board variant configured with eMMC storage.

Signed-off-by: Tanmay Kathpalia <tanmay.kathpalia@altera.com>
---
 Documentation/devicetree/bindings/arm/altera.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/arm/altera.yaml b/Documentation/devicetree/bindings/arm/altera.yaml
index 13a3a9696821..198692878e99 100644
--- a/Documentation/devicetree/bindings/arm/altera.yaml
+++ b/Documentation/devicetree/bindings/arm/altera.yaml
@@ -106,6 +106,7 @@ properties:
               - intel,socfpga-agilex5-socdk
               - intel,socfpga-agilex5-socdk-013b
               - intel,socfpga-agilex5-socdk-nand
+              - intel,socfpga-agilex5-socdk-emmc
           - const: intel,socfpga-agilex5
 
       - description: SoCFPGA VT
-- 
2.43.7

[PATCH v1 5/9] arm64: dts: agilex5: add SOCDK eMMC daughter board support

[Tanmay Kathpalia]

Add device tree support for the Agilex5 SOCDK board variant with
eMMC daughter card.

Update the SoC dtsi with a fixed 1.8V regulator for eMMC I/O voltage.

Add socfpga_agilex5_socdk_emmc.dts with eMMC controller configured for:
- 8-bit bus width
- Non-removable eMMC device
- High-speed, HS200, and HS400 modes at 1.8V
- 200MHz maximum frequency with SDHCI clock base capability override

Signed-off-by: Tanmay Kathpalia <tanmay.kathpalia@altera.com>
---
 arch/arm64/boot/dts/intel/Makefile            |   1 +
 .../arm64/boot/dts/intel/socfpga_agilex5.dtsi |   8 ++
 .../dts/intel/socfpga_agilex5_socdk_emmc.dts  | 111 ++++++++++++++++++
 3 files changed, 120 insertions(+)
 create mode 100644 arch/arm64/boot/dts/intel/socfpga_agilex5_socdk_emmc.dts

diff --git a/arch/arm64/boot/dts/intel/Makefile b/arch/arm64/boot/dts/intel/Makefile
index 33fcc55d0cb9..5bbbcfda1f48 100644
--- a/arch/arm64/boot/dts/intel/Makefile
+++ b/arch/arm64/boot/dts/intel/Makefile
@@ -8,5 +8,6 @@ dtb-$(CONFIG_ARCH_INTEL_SOCFPGA) += socfpga_agilex_n6000.dtb \
 				socfpga_agilex5_socdk_013b.dtb \
 				socfpga_agilex5_socdk_modular.dtb \
 				socfpga_agilex5_socdk_nand.dtb \
+				socfpga_agilex5_socdk_emmc.dtb \
 				socfpga_n5x_socdk.dtb
 dtb-$(CONFIG_ARCH_KEEMBAY) += keembay-evm.dtb
diff --git a/arch/arm64/boot/dts/intel/socfpga_agilex5.dtsi b/arch/arm64/boot/dts/intel/socfpga_agilex5.dtsi
index 7e080f13166f..feb4ccb317a7 100644
--- a/arch/arm64/boot/dts/intel/socfpga_agilex5.dtsi
+++ b/arch/arm64/boot/dts/intel/socfpga_agilex5.dtsi
@@ -317,6 +317,14 @@ sd_io_1v8_reg: regulator-1p8v {
 					<3300000 0x0>;
 		};
 
+		emmc_io_1v8_reg: regulator-fixed-1p8v {
+			compatible = "regulator-fixed";
+			regulator-name = "emmc-io-power";
+			regulator-min-microvolt = <1800000>;
+			regulator-max-microvolt = <1800000>;
+			regulator-always-on;
+		};
+
 		emmc: mmc@10808000 {
 			#address-cells = <1>;
 			#size-cells = <0>;
diff --git a/arch/arm64/boot/dts/intel/socfpga_agilex5_socdk_emmc.dts b/arch/arm64/boot/dts/intel/socfpga_agilex5_socdk_emmc.dts
new file mode 100644
index 000000000000..87bde9fa69c6
--- /dev/null
+++ b/arch/arm64/boot/dts/intel/socfpga_agilex5_socdk_emmc.dts
@@ -0,0 +1,111 @@
+// SPDX-License-Identifier:     GPL-2.0
+/*
+ * Copyright (C) 2026, Altera Corporation
+ */
+#include "socfpga_agilex5.dtsi"
+
+/ {
+	model = "SoCFPGA Agilex5 SoCDK eMMC daughter board";
+	compatible = "intel,socfpga-agilex5-socdk-emmc", "intel,socfpga-agilex5";
+
+	aliases {
+		serial0 = &uart0;
+		ethernet0 = &gmac0;
+	};
+
+	chosen {
+		stdout-path = "serial0:115200n8";
+	};
+
+	leds {
+		compatible = "gpio-leds";
+		led0 {
+			label = "hps_led0";
+			gpios = <&porta 6 GPIO_ACTIVE_HIGH>;
+		};
+
+		led1 {
+			label = "hps_led1";
+			gpios = <&porta 7 GPIO_ACTIVE_HIGH>;
+		};
+	};
+
+	memory@80000000 {
+		device_type = "memory";
+		/* We expect the bootloader to fill in the reg */
+		reg = <0x0 0x80000000 0x0 0x0>;
+	};
+};
+
+&gmac0 {
+	status = "okay";
+	phy-mode = "rgmii-id";
+	phy-handle = <&emac0_phy0>;
+	max-frame-size = <9000>;
+
+	mdio0 {
+		#address-cells = <1>;
+		#size-cells = <0>;
+		compatible = "snps,dwmac-mdio";
+
+		emac0_phy0: ethernet-phy@0 {
+			reg = <0>;
+		};
+	};
+};
+
+&gpio0 {
+	status = "okay";
+};
+
+&gpio1 {
+	status = "okay";
+};
+
+&i2c0 {
+	status = "okay";
+};
+
+&i3c0 {
+	status = "okay";
+};
+
+&i3c1 {
+	status = "okay";
+};
+
+&emmc {
+	status = "okay";
+
+	no-sd;
+	no-sdio;
+	no-1-8-v;
+	disable-wp;
+	non-removable;
+	cap-mmc-highspeed;
+	mmc-hs400-1_8v;
+	mmc-hs200-1_8v;
+	bus-width = <8>;
+	vmmc-supply = <&sd_emmc_power>;
+	vqmmc-supply = <&emmc_io_1v8_reg>;
+	max-frequency = <200000000>;
+	/*
+	 * SDHCI capability overrides:
+	 *  - caps_mask[0] 0x0000ff00 / caps[0] 0x0000c800:
+	 *      Override SDHCI_CLOCK_BASE_MASK to 0xc8 (200 MHz).
+	 */
+	sdhci-caps = <0x00000000 0x0000c800>;
+	sdhci-caps-mask = <0x00000000 0x0000ff00>;
+};
+
+&osc1 {
+	clock-frequency = <25000000>;
+};
+
+&uart0 {
+	status = "okay";
+};
+
+&watchdog0 {
+	status = "okay";
+};
-- 
2.43.7

Re: [PATCH v1 5/9] arm64: dts: agilex5: add SOCDK eMMC daughter board support

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] The `no-1-8-v` property in the `&emmc` node explicitly disables the 1.8V HS200 and HS400 modes, contradicting the commit intent.
- [Medium] A board-specific fixed regulator (`emmc_io_1v8_reg`) is improperly defined in the shared SoC-level `.dtsi` file and placed under a memory-mapped bus.
--

commit 832d2f01748902348b5ee8ddc2a87d8dfab30896
Author: Tanmay Kathpalia <tanmay.kathpalia@altera.com>

arm64: dts: agilex5: add SOCDK eMMC daughter board support

This commit adds device tree support for the Agilex5 SOCDK eMMC daughter
board. It introduces the new board dts file and adds a fixed 1.8V regulator
for the eMMC I/O voltage to the common SoC dtsi.

> diff --git a/arch/arm64/boot/dts/intel/socfpga_agilex5.dtsi b/arch/arm64/boot/dts/intel/socfpga_agilex5.dtsi
> index 7e080f13166f2..feb4ccb317a71 100644
> --- a/arch/arm64/boot/dts/intel/socfpga_agilex5.dtsi
> +++ b/arch/arm64/boot/dts/intel/socfpga_agilex5.dtsi
[ ... ]
> @@ -317,6 +317,14 @@ sd_io_1v8_reg: regulator-1p8v {
>  					<3300000 0x0>;
>  		};
>  
> +		emmc_io_1v8_reg: regulator-fixed-1p8v {
> +			compatible = "regulator-fixed";
> +			regulator-name = "emmc-io-power";
> +			regulator-min-microvolt = <1800000>;
> +			regulator-max-microvolt = <1800000>;
> +			regulator-always-on;
> +		};
> +

Will this cause every Agilex 5 board to inadvertently instantiate and enable
this regulator, even if they do not have the eMMC daughter card attached?
Since this appears to be a board-specific regulator, would it be better
placed at the root level of the board-specific socfpga_agilex5_socdk_emmc.dts
file?

Additionally, does placing this node inside a memory-mapped bus without a reg
property trigger device tree compiler warnings?

> diff --git a/arch/arm64/boot/dts/intel/socfpga_agilex5_socdk_emmc.dts b/arch/arm64/boot/dts/intel/socfpga_agilex5_socdk_emmc.dts
> new file mode 100644
> index 0000000000000..87bde9fa69c6c
> --- /dev/null
> +++ b/arch/arm64/boot/dts/intel/socfpga_agilex5_socdk_emmc.dts
[ ... ]
> +&emmc {
> +	status = "okay";
> +
> +	no-sd;
> +	no-sdio;
> +	no-1-8-v;

The commit message states the eMMC controller is configured for HS200 and
HS400 modes at 1.8V. Does the no-1-8-v property prevent these high-speed
modes from functioning?

In the SDHCI core, parsing no-1-8-v sets the SDHCI_QUIRK2_NO_1_8_V flag,
which strips out the MMC_CAP2_HSX00_1_8V and MMC_CAP2_HS400_ES capabilities
during host setup. Since the eMMC IO is explicitly supplied by a 1.8V
regulator, shouldn't this property be removed to allow HS200 and HS400
negotiation?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260511202132.5597-1-tanmay.kathpalia@altera.com?part=5

Re: [PATCH v1 5/9] arm64: dts: agilex5: add SOCDK eMMC daughter board support

[Kathpalia, Tanmay]

On 5/13/2026 6:52 AM, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
> - [High] The `no-1-8-v` property in the `&emmc` node explicitly disables the 1.8V HS200 and HS400 modes, contradicting the commit intent.
> - [Medium] A board-specific fixed regulator (`emmc_io_1v8_reg`) is improperly defined in the shared SoC-level `.dtsi` file and placed under a memory-mapped bus.
> --
>
> commit 832d2f01748902348b5ee8ddc2a87d8dfab30896
> Author: Tanmay Kathpalia <tanmay.kathpalia@altera.com>
>
> arm64: dts: agilex5: add SOCDK eMMC daughter board support
>
> This commit adds device tree support for the Agilex5 SOCDK eMMC daughter
> board. It introduces the new board dts file and adds a fixed 1.8V regulator
> for the eMMC I/O voltage to the common SoC dtsi.
>
>> diff --git a/arch/arm64/boot/dts/intel/socfpga_agilex5.dtsi b/arch/arm64/boot/dts/intel/socfpga_agilex5.dtsi
>> index 7e080f13166f2..feb4ccb317a71 100644
>> --- a/arch/arm64/boot/dts/intel/socfpga_agilex5.dtsi
>> +++ b/arch/arm64/boot/dts/intel/socfpga_agilex5.dtsi
> [ ... ]
>> @@ -317,6 +317,14 @@ sd_io_1v8_reg: regulator-1p8v {
>>   					<3300000 0x0>;
>>   		};
>>   
>> +		emmc_io_1v8_reg: regulator-fixed-1p8v {
>> +			compatible = "regulator-fixed";
>> +			regulator-name = "emmc-io-power";
>> +			regulator-min-microvolt = <1800000>;
>> +			regulator-max-microvolt = <1800000>;
>> +			regulator-always-on;
>> +		};
>> +
> Will this cause every Agilex 5 board to inadvertently instantiate and enable
> this regulator, even if they do not have the eMMC daughter card attached?
> Since this appears to be a board-specific regulator, would it be better
> placed at the root level of the board-specific socfpga_agilex5_socdk_emmc.dts
> file?
>
> Additionally, does placing this node inside a memory-mapped bus without a reg
> property trigger device tree compiler warnings?

Agreed, this is board-specific and should not be in the shared SoC dtsi.
Will be moved to socfpga_agilex5_socdk_emmc.dts in v2.
>
>> diff --git a/arch/arm64/boot/dts/intel/socfpga_agilex5_socdk_emmc.dts b/arch/arm64/boot/dts/intel/socfpga_agilex5_socdk_emmc.dts
>> new file mode 100644
>> index 0000000000000..87bde9fa69c6c
>> --- /dev/null
>> +++ b/arch/arm64/boot/dts/intel/socfpga_agilex5_socdk_emmc.dts
> [ ... ]
>> +&emmc {
>> +	status = "okay";
>> +
>> +	no-sd;
>> +	no-sdio;
>> +	no-1-8-v;
> The commit message states the eMMC controller is configured for HS200 and
> HS400 modes at 1.8V. Does the no-1-8-v property prevent these high-speed
> modes from functioning?
>
> In the SDHCI core, parsing no-1-8-v sets the SDHCI_QUIRK2_NO_1_8_V flag,
> which strips out the MMC_CAP2_HSX00_1_8V and MMC_CAP2_HS400_ES capabilities
> during host setup. Since the eMMC IO is explicitly supplied by a 1.8V
> regulator, shouldn't this property be removed to allow HS200 and HS400
> negotiation?


no-1-8-v sets SDHCI_QUIRK2_NO_1_8_V which prevents HS200/HS400
negotiation — contradicting the intent. Will be removed in v2.