* [PATCH v6 8/9] riscv: dts: spacemit: k1-bananapi-f3: add SD card support with UHS modes
From: Iker Pedrosa @ 2026-04-07 8:25 UTC (permalink / raw)
To: Ulf Hansson, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Adrian Hunter, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Alexandre Ghiti, Yixun Lan, Yixun Lan
Cc: Troy Mitchell, Michael Opdenacker, Javier Martinez Canillas,
linux-mmc, devicetree, linux-riscv, spacemit, linux-kernel,
Iker Pedrosa, Anand Moon
In-Reply-To: <20260407-orangepi-sd-card-uhs-v6-0-b5b8a1b2bfc8@gmail.com>
Add complete SD card controller support with UHS high-speed modes.
- Enable sdhci0 controller with 4-bit bus width
- Configure card detect GPIO with inversion
- Connect vmmc-supply to buck4 for 3.3V card power
- Connect vqmmc-supply to aldo1 for 1.8V/3.3V I/O switching
- Add dual pinctrl states for voltage-dependent pin configuration
- Support UHS-I SDR25, SDR50, and SDR104 modes
This enables full SD card functionality including high-speed UHS modes
for improved performance.
Suggested-by: Anand Moon <linux.amoon@gmail.com>
Tested-by: Anand Moon <linux.amoon@gmail.com>
Signed-off-by: Iker Pedrosa <ikerpedrosam@gmail.com>
---
arch/riscv/boot/dts/spacemit/k1-bananapi-f3.dts | 24 ++++++++++++++++++++++--
1 file changed, 22 insertions(+), 2 deletions(-)
diff --git a/arch/riscv/boot/dts/spacemit/k1-bananapi-f3.dts b/arch/riscv/boot/dts/spacemit/k1-bananapi-f3.dts
index 5790d927b93db350c8f53aa0f314183b3173fd76..a7d88564630f3332270ba5fe47b078bb14f564e5 100644
--- a/arch/riscv/boot/dts/spacemit/k1-bananapi-f3.dts
+++ b/arch/riscv/boot/dts/spacemit/k1-bananapi-f3.dts
@@ -220,7 +220,7 @@ buck3_1v8: buck3 {
regulator-always-on;
};
- buck4 {
+ buck4: buck4 {
regulator-min-microvolt = <500000>;
regulator-max-microvolt = <3300000>;
regulator-ramp-delay = <5000>;
@@ -241,7 +241,7 @@ buck6 {
regulator-always-on;
};
- aldo1 {
+ aldo1: aldo1 {
regulator-min-microvolt = <500000>;
regulator-max-microvolt = <3400000>;
regulator-boot-on;
@@ -367,3 +367,23 @@ hub_3_0: hub@2 {
reset-gpios = <&gpio K1_GPIO(124) GPIO_ACTIVE_LOW>;
};
};
+
+&sdhci0 {
+ pinctrl-names = "default", "uhs";
+ pinctrl-0 = <&mmc1_cfg>;
+ pinctrl-1 = <&mmc1_uhs_cfg>;
+ bus-width = <4>;
+ cd-gpios = <&gpio K1_GPIO(80) GPIO_ACTIVE_HIGH>;
+ cd-inverted;
+ broken-cd;
+ no-mmc;
+ no-sdio;
+ disable-wp;
+ cap-sd-highspeed;
+ vmmc-supply = <&buck4>;
+ vqmmc-supply = <&aldo1>;
+ sd-uhs-sdr25;
+ sd-uhs-sdr50;
+ sd-uhs-sdr104;
+ status = "okay";
+};
--
2.53.0
^ permalink raw reply related
* [PATCH v6 7/9] riscv: dts: spacemit: k1-orangepi-rv2: add SD card support with UHS modes
From: Iker Pedrosa @ 2026-04-07 8:25 UTC (permalink / raw)
To: Ulf Hansson, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Adrian Hunter, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Alexandre Ghiti, Yixun Lan, Yixun Lan
Cc: Troy Mitchell, Michael Opdenacker, Javier Martinez Canillas,
linux-mmc, devicetree, linux-riscv, spacemit, linux-kernel,
Iker Pedrosa, Anand Moon, Trevor Gamblin
In-Reply-To: <20260407-orangepi-sd-card-uhs-v6-0-b5b8a1b2bfc8@gmail.com>
Add complete SD card controller support with UHS high-speed modes.
- Enable sdhci0 controller with 4-bit bus width
- Configure card detect GPIO with inversion
- Connect vmmc-supply to buck4 for 3.3V card power
- Connect vqmmc-supply to aldo1 for 1.8V/3.3V I/O switching
- Add dual pinctrl states for voltage-dependent pin configuration
- Support UHS-I SDR25, SDR50, and SDR104 modes
This enables full SD card functionality including high-speed UHS modes
for improved performance.
Tested-by: Anand Moon <linux.amoon@gmail.com>
Tested-by: Trevor Gamblin <tgamblin@baylibre.com>
Tested-by: Michael Opdenacker <michael.opdenacker@rootcommit.com>
Signed-off-by: Iker Pedrosa <ikerpedrosam@gmail.com>
---
arch/riscv/boot/dts/spacemit/k1-orangepi-rv2.dts | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)
diff --git a/arch/riscv/boot/dts/spacemit/k1-orangepi-rv2.dts b/arch/riscv/boot/dts/spacemit/k1-orangepi-rv2.dts
index 9c417a483f6bad6e60617cf8d5400ca079588726..95cfb4681ced8f539693717e718a3633c35989d5 100644
--- a/arch/riscv/boot/dts/spacemit/k1-orangepi-rv2.dts
+++ b/arch/riscv/boot/dts/spacemit/k1-orangepi-rv2.dts
@@ -140,3 +140,22 @@ aldo1: aldo1 {
};
};
};
+
+&sdhci0 {
+ pinctrl-names = "default", "uhs";
+ pinctrl-0 = <&mmc1_cfg>;
+ pinctrl-1 = <&mmc1_uhs_cfg>;
+ bus-width = <4>;
+ cd-gpios = <&gpio K1_GPIO(80) GPIO_ACTIVE_HIGH>;
+ cd-inverted;
+ no-mmc;
+ no-sdio;
+ disable-wp;
+ cap-sd-highspeed;
+ vmmc-supply = <&buck4>;
+ vqmmc-supply = <&aldo1>;
+ sd-uhs-sdr25;
+ sd-uhs-sdr50;
+ sd-uhs-sdr104;
+ status = "okay";
+};
--
2.53.0
^ permalink raw reply related
* [PATCH v6 6/9] riscv: dts: spacemit: k1-orangepi-rv2: add PMIC and power infrastructure
From: Iker Pedrosa @ 2026-04-07 8:25 UTC (permalink / raw)
To: Ulf Hansson, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Adrian Hunter, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Alexandre Ghiti, Yixun Lan, Yixun Lan
Cc: Troy Mitchell, Michael Opdenacker, Javier Martinez Canillas,
linux-mmc, devicetree, linux-riscv, spacemit, linux-kernel,
Iker Pedrosa, Anand Moon, Trevor Gamblin
In-Reply-To: <20260407-orangepi-sd-card-uhs-v6-0-b5b8a1b2bfc8@gmail.com>
Add Spacemit P1 PMIC configuration and board power infrastructure for
voltage regulation support.
- Add board power regulators (5V input, 4V rail)
- Enable I2C8 for PMIC communication
- Configure PMIC with buck4 (vmmc) and aldo1 (vqmmc) regulators
- Set up regulator constraints for SD card operation
Tested-by: Anand Moon <linux.amoon@gmail.com>
Tested-by: Trevor Gamblin <tgamblin@baylibre.com>
Signed-off-by: Iker Pedrosa <ikerpedrosam@gmail.com>
---
arch/riscv/boot/dts/spacemit/k1-orangepi-rv2.dts | 48 ++++++++++++++++++++++++
1 file changed, 48 insertions(+)
diff --git a/arch/riscv/boot/dts/spacemit/k1-orangepi-rv2.dts b/arch/riscv/boot/dts/spacemit/k1-orangepi-rv2.dts
index 7b7331cb3c726f11d597f81917f3a3f5fc21e1b9..9c417a483f6bad6e60617cf8d5400ca079588726 100644
--- a/arch/riscv/boot/dts/spacemit/k1-orangepi-rv2.dts
+++ b/arch/riscv/boot/dts/spacemit/k1-orangepi-rv2.dts
@@ -19,6 +19,25 @@ aliases {
ethernet1 = ð1;
};
+ reg_dc_in: dc-in-5v {
+ compatible = "regulator-fixed";
+ regulator-name = "dc_in_5v";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ 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 = <®_dc_in>;
+ };
+
chosen {
stdout-path = "serial0";
};
@@ -92,3 +111,32 @@ &uart0 {
pinctrl-0 = <&uart0_2_cfg>;
status = "okay";
};
+
+&i2c8 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c8_cfg>;
+ status = "okay";
+
+ pmic@41 {
+ compatible = "spacemit,p1";
+ reg = <0x41>;
+ interrupts = <64>;
+ vin-supply = <®_vcc_4v>;
+
+ regulators {
+ buck4: buck4 {
+ regulator-min-microvolt = <500000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-ramp-delay = <5000>;
+ regulator-always-on;
+ };
+
+ aldo1: aldo1 {
+ regulator-min-microvolt = <500000>;
+ regulator-max-microvolt = <3400000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+ };
+ };
+};
--
2.53.0
^ permalink raw reply related
* [PATCH v6 5/9] riscv: dts: spacemit: k1: add SD card controller and pinctrl support
From: Iker Pedrosa @ 2026-04-07 8:25 UTC (permalink / raw)
To: Ulf Hansson, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Adrian Hunter, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Alexandre Ghiti, Yixun Lan, Yixun Lan
Cc: Troy Mitchell, Michael Opdenacker, Javier Martinez Canillas,
linux-mmc, devicetree, linux-riscv, spacemit, linux-kernel,
Iker Pedrosa, Anand Moon, Trevor Gamblin
In-Reply-To: <20260407-orangepi-sd-card-uhs-v6-0-b5b8a1b2bfc8@gmail.com>
Add SD card controller infrastructure for SpacemiT K1 SoC with complete
pinctrl support for both standard and UHS modes.
- Add sdhci0 controller definition with clocks, resets and interrupts
- Add mmc1_cfg pinctrl for 3.3V standard SD operation
- Add mmc1_uhs_cfg pinctrl for 1.8V UHS high-speed operation
- Configure appropriate drive strength and power-source properties
This provides complete SD card infrastructure that K1-based boards can
enable.
Tested-by: Anand Moon <linux.amoon@gmail.com>
Tested-by: Trevor Gamblin <tgamblin@baylibre.com>
Signed-off-by: Iker Pedrosa <ikerpedrosam@gmail.com>
---
arch/riscv/boot/dts/spacemit/k1-pinctrl.dtsi | 40 ++++++++++++++++++++++++++++
arch/riscv/boot/dts/spacemit/k1.dtsi | 13 +++++++++
2 files changed, 53 insertions(+)
diff --git a/arch/riscv/boot/dts/spacemit/k1-pinctrl.dtsi b/arch/riscv/boot/dts/spacemit/k1-pinctrl.dtsi
index b13dcb10f4d66022d27307de73a6ea3287e97441..b3c472a0783b99091662d2d3516aa7fec4b3c3a3 100644
--- a/arch/riscv/boot/dts/spacemit/k1-pinctrl.dtsi
+++ b/arch/riscv/boot/dts/spacemit/k1-pinctrl.dtsi
@@ -570,4 +570,44 @@ pwm14-1-pins {
drive-strength = <32>;
};
};
+
+ mmc1_cfg: mmc1-cfg {
+ mmc1-data-cmd-pins {
+ pinmux = <K1_PADCONF(104, 0)>, /* mmc1_d3 */
+ <K1_PADCONF(105, 0)>, /* mmc1_d2 */
+ <K1_PADCONF(106, 0)>, /* mmc1_d1 */
+ <K1_PADCONF(107, 0)>, /* mmc1_d0 */
+ <K1_PADCONF(108, 0)>; /* mmc1_cmd */
+ bias-pull-up = <1>;
+ drive-strength = <19>;
+ power-source = <3300>;
+ };
+
+ mmc1-clk-pins {
+ pinmux = <K1_PADCONF(109, 0)>; /* mmc1_clk */
+ bias-pull-down = <1>;
+ drive-strength = <19>;
+ power-source = <3300>;
+ };
+ };
+
+ mmc1_uhs_cfg: mmc1-uhs-cfg {
+ mmc1-data-cmd-pins {
+ pinmux = <K1_PADCONF(104, 0)>, /* mmc1_d3 */
+ <K1_PADCONF(105, 0)>, /* mmc1_d2 */
+ <K1_PADCONF(106, 0)>, /* mmc1_d1 */
+ <K1_PADCONF(107, 0)>, /* mmc1_d0 */
+ <K1_PADCONF(108, 0)>; /* mmc1_cmd */
+ bias-pull-up = <1>;
+ drive-strength = <42>;
+ power-source = <1800>;
+ };
+
+ mmc1-clk-pins {
+ pinmux = <K1_PADCONF(109, 0)>; /* mmc1_clk */
+ bias-pull-down = <1>;
+ drive-strength = <42>;
+ power-source = <1800>;
+ };
+ };
};
diff --git a/arch/riscv/boot/dts/spacemit/k1.dtsi b/arch/riscv/boot/dts/spacemit/k1.dtsi
index f0bad6855c970a609253d4b0ca2a4fcbf06bb8e3..28949f804610c60b7fa89d957507be32e3b49f34 100644
--- a/arch/riscv/boot/dts/spacemit/k1.dtsi
+++ b/arch/riscv/boot/dts/spacemit/k1.dtsi
@@ -1211,6 +1211,19 @@ 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";
+ resets = <&syscon_apmu RESET_SDH_AXI>,
+ <&syscon_apmu RESET_SDH0>;
+ reset-names = "axi", "sdh";
+ interrupts = <99>;
+ status = "disabled";
+ };
};
};
};
--
2.53.0
^ permalink raw reply related
* [PATCH v6 4/9] mmc: sdhci-of-k1: add comprehensive SDR tuning support
From: Iker Pedrosa @ 2026-04-07 8:25 UTC (permalink / raw)
To: Ulf Hansson, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Adrian Hunter, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Alexandre Ghiti, Yixun Lan, Yixun Lan
Cc: Troy Mitchell, Michael Opdenacker, Javier Martinez Canillas,
linux-mmc, devicetree, linux-riscv, spacemit, linux-kernel,
Iker Pedrosa, Anand Moon, Trevor Gamblin
In-Reply-To: <20260407-orangepi-sd-card-uhs-v6-0-b5b8a1b2bfc8@gmail.com>
Implement software tuning algorithm to enable UHS-I SDR modes for SD
card operation and HS200 mode for eMMC. This adds both TX and RX delay
line tuning based on the SpacemiT K1 controller capabilities.
Algorithm features:
- Add tuning register definitions (RX_CFG, DLINE_CTRL, DLINE_CFG)
- Conditional tuning: only for high-speed modes (≥100MHz)
- TX tuning: configure transmit delay line with optimal values
(dline_reg=0, delaycode=127) to ensure optimal signal output timing
- RX tuning: single-pass window detection algorithm testing full
delay range (0-255) to find optimal receive timing window
- Retry mechanism: multiple fallback delays within optimal window
for improved reliability
Tested-by: Anand Moon <linux.amoon@gmail.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Tested-by: Trevor Gamblin <tgamblin@baylibre.com>
Signed-off-by: Iker Pedrosa <ikerpedrosam@gmail.com>
---
drivers/mmc/host/sdhci-of-k1.c | 172 +++++++++++++++++++++++++++++++++++++++++
1 file changed, 172 insertions(+)
diff --git a/drivers/mmc/host/sdhci-of-k1.c b/drivers/mmc/host/sdhci-of-k1.c
index d9144537032a51a12d7480885f247f4c66583e59..37b0911e7cf2023ad440fbdbf504821457f061f6 100644
--- a/drivers/mmc/host/sdhci-of-k1.c
+++ b/drivers/mmc/host/sdhci-of-k1.c
@@ -69,6 +69,28 @@
#define SDHC_PHY_DRIVE_SEL GENMASK(2, 0)
#define SDHC_RX_BIAS_CTRL BIT(5)
+#define SPACEMIT_SDHC_RX_CFG_REG 0x118
+#define SDHC_RX_SDCLK_SEL0_MASK GENMASK(1, 0)
+#define SDHC_RX_SDCLK_SEL1_MASK GENMASK(3, 2)
+#define SDHC_RX_SDCLK_SEL1 FIELD_PREP(SDHC_RX_SDCLK_SEL1_MASK, 1)
+
+#define SPACEMIT_SDHC_DLINE_CTRL_REG 0x130
+#define SDHC_DLINE_PU BIT(0)
+#define SDHC_RX_DLINE_CODE_MASK GENMASK(23, 16)
+#define SDHC_TX_DLINE_CODE_MASK GENMASK(31, 24)
+
+#define SPACEMIT_SDHC_DLINE_CFG_REG 0x134
+#define SDHC_RX_DLINE_REG_MASK GENMASK(7, 0)
+#define SDHC_RX_DLINE_GAIN BIT(8)
+#define SDHC_TX_DLINE_REG_MASK GENMASK(23, 16)
+
+#define SPACEMIT_RX_DLINE_REG 9
+#define SPACEMIT_RX_TUNE_DELAY_MIN 0x0
+#define SPACEMIT_RX_TUNE_DELAY_MAX 0xFF
+
+#define SPACEMIT_TX_TUNING_DLINE_REG 0x00
+#define SPACEMIT_TX_TUNING_DELAYCODE 127
+
struct spacemit_sdhci_host {
struct clk *clk_core;
struct clk *clk_io;
@@ -96,6 +118,50 @@ static inline void spacemit_sdhci_clrsetbits(struct sdhci_host *host, u32 clr, u
sdhci_writel(host, val, reg);
}
+static void spacemit_sdhci_set_rx_delay(struct sdhci_host *host, u8 delay)
+{
+ spacemit_sdhci_clrsetbits(host, SDHC_RX_DLINE_CODE_MASK,
+ FIELD_PREP(SDHC_RX_DLINE_CODE_MASK, delay),
+ SPACEMIT_SDHC_DLINE_CTRL_REG);
+}
+
+static void spacemit_sdhci_set_tx_delay(struct sdhci_host *host, u8 delay)
+{
+ spacemit_sdhci_clrsetbits(host, SDHC_TX_DLINE_CODE_MASK,
+ FIELD_PREP(SDHC_TX_DLINE_CODE_MASK, delay),
+ SPACEMIT_SDHC_DLINE_CTRL_REG);
+}
+
+static void spacemit_sdhci_set_tx_dline_reg(struct sdhci_host *host, u8 dline_reg)
+{
+ spacemit_sdhci_clrsetbits(host, SDHC_TX_DLINE_REG_MASK,
+ FIELD_PREP(SDHC_TX_DLINE_REG_MASK, dline_reg),
+ SPACEMIT_SDHC_DLINE_CFG_REG);
+}
+
+static void spacemit_sdhci_tx_tuning_prepare(struct sdhci_host *host)
+{
+ spacemit_sdhci_setbits(host, SDHC_TX_MUX_SEL, SPACEMIT_SDHC_TX_CFG_REG);
+ spacemit_sdhci_setbits(host, SDHC_DLINE_PU, SPACEMIT_SDHC_DLINE_CTRL_REG);
+ udelay(5);
+}
+
+static void spacemit_sdhci_prepare_tuning(struct sdhci_host *host)
+{
+ spacemit_sdhci_clrsetbits(host, SDHC_RX_DLINE_REG_MASK,
+ FIELD_PREP(SDHC_RX_DLINE_REG_MASK, SPACEMIT_RX_DLINE_REG),
+ SPACEMIT_SDHC_DLINE_CFG_REG);
+
+ spacemit_sdhci_setbits(host, SDHC_DLINE_PU, SPACEMIT_SDHC_DLINE_CTRL_REG);
+ udelay(5);
+
+ spacemit_sdhci_clrsetbits(host, SDHC_RX_SDCLK_SEL1_MASK, SDHC_RX_SDCLK_SEL1,
+ SPACEMIT_SDHC_RX_CFG_REG);
+
+ if (host->mmc->ios.timing == MMC_TIMING_MMC_HS200)
+ spacemit_sdhci_setbits(host, SDHC_HS200_USE_RFIFO, SPACEMIT_SDHC_PHY_FUNC_REG);
+}
+
static void spacemit_sdhci_reset(struct sdhci_host *host, u8 mask)
{
sdhci_reset(host, mask);
@@ -191,6 +257,111 @@ static unsigned int spacemit_sdhci_clk_get_max_clock(struct sdhci_host *host)
return clk_get_rate(pltfm_host->clk);
}
+static int spacemit_sdhci_execute_tuning(struct sdhci_host *host, u32 opcode)
+{
+ int current_len = 0, current_start = 0;
+ int max_pass_len = 0, max_pass_start = 0;
+ struct mmc_host *mmc = host->mmc;
+ struct mmc_ios ios = mmc->ios;
+ u8 final_delay;
+ int ret = 0;
+ int i;
+
+ /*
+ * Tuning is required for SDR50/SDR104, HS200/HS400 cards and
+ * if clock frequency is greater than 100MHz in these modes.
+ */
+ if (host->clock < 100 * 1000 * 1000 ||
+ !(ios.timing == MMC_TIMING_MMC_HS200 ||
+ ios.timing == MMC_TIMING_UHS_SDR50 ||
+ ios.timing == MMC_TIMING_UHS_SDR104))
+ return 0;
+
+ if (mmc->caps2 & MMC_CAP2_NO_MMC) {
+ spacemit_sdhci_set_tx_dline_reg(host, SPACEMIT_TX_TUNING_DLINE_REG);
+ spacemit_sdhci_set_tx_delay(host, SPACEMIT_TX_TUNING_DELAYCODE);
+ spacemit_sdhci_tx_tuning_prepare(host);
+
+ dev_dbg(mmc_dev(host->mmc), "TX tuning: dline_reg=%d, delaycode=%d\n",
+ SPACEMIT_TX_TUNING_DLINE_REG, SPACEMIT_TX_TUNING_DELAYCODE);
+ }
+
+ spacemit_sdhci_prepare_tuning(host);
+
+ for (i = SPACEMIT_RX_TUNE_DELAY_MIN; i <= SPACEMIT_RX_TUNE_DELAY_MAX; i++) {
+ spacemit_sdhci_set_rx_delay(host, i);
+ ret = mmc_send_tuning(host->mmc, opcode, NULL);
+
+ dev_dbg(mmc_dev(host->mmc), "RX delay %d: %s\n",
+ i, ret == 0 ? "pass" : "fail");
+
+ if (ret == 0) {
+ /* Test passed - extend current window */
+ if (current_len == 0)
+ current_start = i;
+ current_len++;
+ } else {
+ /* Test failed - check if current window is best so far */
+ if (current_len > max_pass_len) {
+ max_pass_len = current_len;
+ max_pass_start = current_start;
+ }
+ current_len = 0;
+ }
+ }
+
+ if (current_len > max_pass_len) {
+ max_pass_len = current_len;
+ max_pass_start = current_start;
+ }
+
+ if (max_pass_len < 3) {
+ dev_err(mmc_dev(host->mmc), "Tuning failed: no stable window found\n");
+ return -EIO;
+ }
+
+ final_delay = max_pass_start + max_pass_len / 2;
+ spacemit_sdhci_set_rx_delay(host, final_delay);
+ ret = mmc_send_tuning(host->mmc, opcode, NULL);
+ if (ret) {
+ u8 retry_delays[] = {
+ max_pass_start + max_pass_len / 4,
+ max_pass_start + (3 * max_pass_len) / 4,
+ max_pass_start,
+ max_pass_start + max_pass_len - 1
+ };
+ int retry_count = ARRAY_SIZE(retry_delays);
+
+ dev_warn(mmc_dev(mmc), "Primary delay %d failed, trying alternatives\n",
+ final_delay);
+
+ for (i = 0; i < retry_count; i++) {
+ if (retry_delays[i] >= SPACEMIT_RX_TUNE_DELAY_MIN &&
+ retry_delays[i] <= SPACEMIT_RX_TUNE_DELAY_MAX) {
+ spacemit_sdhci_set_rx_delay(host, retry_delays[i]);
+ ret = mmc_send_tuning(host->mmc, opcode, NULL);
+ if (!ret) {
+ final_delay = retry_delays[i];
+ dev_info(mmc_dev(mmc), "Retry successful with delay %d\n",
+ final_delay);
+ break;
+ }
+ }
+ }
+
+ if (ret) {
+ dev_err(mmc_dev(mmc), "All retry attempts failed\n");
+ return -EIO;
+ }
+ }
+
+ dev_dbg(mmc_dev(host->mmc),
+ "Tuning successful: window %d-%d, using delay %d\n",
+ max_pass_start, max_pass_start + max_pass_len - 1, final_delay);
+
+ return 0;
+}
+
static int spacemit_sdhci_pre_select_hs400(struct mmc_host *mmc)
{
struct sdhci_host *host = mmc_priv(mmc);
@@ -326,6 +497,7 @@ static const struct sdhci_ops spacemit_sdhci_ops = {
.set_bus_width = sdhci_set_bus_width,
.set_clock = spacemit_sdhci_set_clock,
.set_uhs_signaling = spacemit_sdhci_set_uhs_signaling,
+ .platform_execute_tuning = spacemit_sdhci_execute_tuning,
};
static const struct sdhci_pltfm_data spacemit_sdhci_k1_pdata = {
--
2.53.0
^ permalink raw reply related
* [PATCH v6 3/9] mmc: sdhci-of-k1: add regulator and pinctrl voltage switching support
From: Iker Pedrosa @ 2026-04-07 8:25 UTC (permalink / raw)
To: Ulf Hansson, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Adrian Hunter, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Alexandre Ghiti, Yixun Lan, Yixun Lan
Cc: Troy Mitchell, Michael Opdenacker, Javier Martinez Canillas,
linux-mmc, devicetree, linux-riscv, spacemit, linux-kernel,
Iker Pedrosa, Anand Moon, Trevor Gamblin
In-Reply-To: <20260407-orangepi-sd-card-uhs-v6-0-b5b8a1b2bfc8@gmail.com>
Add voltage switching infrastructure for UHS-I modes by integrating both
regulator framework (for supply voltage control) and pinctrl state
switching (for pin drive strength optimization).
- Add regulator supply parsing and voltage switching callback
- Add optional pinctrl state switching between "default" (3.3V) and
"state_uhs" (1.8V) configurations
- Enable coordinated voltage and pin configuration changes for UHS modes
This provides complete voltage switching support while maintaining
backward compatibility when pinctrl states are not defined.
Tested-by: Anand Moon <linux.amoon@gmail.com>
Tested-by: Trevor Gamblin <tgamblin@baylibre.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Reviewed-by: Troy Mitchell <troy.mitchell@linux.dev>
Signed-off-by: Iker Pedrosa <ikerpedrosam@gmail.com>
---
drivers/mmc/host/sdhci-of-k1.c | 72 ++++++++++++++++++++++++++++++++++++++++++
1 file changed, 72 insertions(+)
diff --git a/drivers/mmc/host/sdhci-of-k1.c b/drivers/mmc/host/sdhci-of-k1.c
index 0dd06fc19b8574ae1b00f7e5d09b7d4c87d06770..d9144537032a51a12d7480885f247f4c66583e59 100644
--- a/drivers/mmc/host/sdhci-of-k1.c
+++ b/drivers/mmc/host/sdhci-of-k1.c
@@ -16,6 +16,7 @@
#include <linux/of.h>
#include <linux/of_device.h>
#include <linux/reset.h>
+#include <linux/pinctrl/consumer.h>
#include <linux/platform_device.h>
#include "sdhci.h"
@@ -71,6 +72,9 @@
struct spacemit_sdhci_host {
struct clk *clk_core;
struct clk *clk_io;
+ struct pinctrl *pinctrl;
+ struct pinctrl_state *pinctrl_default;
+ struct pinctrl_state *pinctrl_uhs;
};
/* All helper functions will update clr/set while preserve rest bits */
@@ -219,6 +223,46 @@ static void spacemit_sdhci_pre_hs400_to_hs200(struct mmc_host *mmc)
SPACEMIT_SDHC_PHY_CTRL_REG);
}
+static int spacemit_sdhci_start_signal_voltage_switch(struct mmc_host *mmc,
+ struct mmc_ios *ios)
+{
+ struct sdhci_host *host = mmc_priv(mmc);
+ struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
+ struct spacemit_sdhci_host *sdhst = sdhci_pltfm_priv(pltfm_host);
+ struct pinctrl_state *state;
+ int ret;
+
+ ret = sdhci_start_signal_voltage_switch(mmc, ios);
+ if (ret)
+ return ret;
+
+ if (!sdhst->pinctrl)
+ return 0;
+
+ /* Select appropriate pinctrl state based on signal voltage */
+ switch (ios->signal_voltage) {
+ case MMC_SIGNAL_VOLTAGE_330:
+ state = sdhst->pinctrl_default;
+ break;
+ case MMC_SIGNAL_VOLTAGE_180:
+ state = sdhst->pinctrl_uhs;
+ break;
+ default:
+ dev_warn(mmc_dev(mmc), "unsupported voltage %d\n", ios->signal_voltage);
+ return 0;
+ }
+
+ ret = pinctrl_select_state(sdhst->pinctrl, state);
+ if (ret) {
+ dev_warn(mmc_dev(mmc), "failed to select pinctrl state: %d\n", ret);
+ return 0;
+ }
+ dev_dbg(mmc_dev(mmc), "switched to %s pinctrl state\n",
+ ios->signal_voltage == MMC_SIGNAL_VOLTAGE_180 ? "UHS" : "default");
+
+ return 0;
+}
+
static inline int spacemit_sdhci_get_clocks(struct device *dev,
struct sdhci_pltfm_host *pltfm_host)
{
@@ -252,6 +296,30 @@ static inline int spacemit_sdhci_get_resets(struct device *dev)
return 0;
}
+static inline void spacemit_sdhci_get_pins(struct device *dev,
+ struct sdhci_pltfm_host *pltfm_host)
+{
+ struct spacemit_sdhci_host *sdhst = sdhci_pltfm_priv(pltfm_host);
+
+ sdhst->pinctrl = devm_pinctrl_get(dev);
+ if (IS_ERR(sdhst->pinctrl)) {
+ sdhst->pinctrl = NULL;
+ dev_dbg(dev, "pinctrl not available, voltage switching will work without it\n");
+ return;
+ }
+
+ sdhst->pinctrl_default = pinctrl_lookup_state(sdhst->pinctrl, "default");
+ if (IS_ERR(sdhst->pinctrl_default))
+ sdhst->pinctrl_default = NULL;
+
+ sdhst->pinctrl_uhs = pinctrl_lookup_state(sdhst->pinctrl, "uhs");
+ if (IS_ERR(sdhst->pinctrl_uhs))
+ sdhst->pinctrl_uhs = NULL;
+
+ dev_dbg(dev, "pinctrl setup: default=%p, uhs=%p\n",
+ sdhst->pinctrl_default, sdhst->pinctrl_uhs);
+}
+
static const struct sdhci_ops spacemit_sdhci_ops = {
.get_max_clock = spacemit_sdhci_clk_get_max_clock,
.reset = spacemit_sdhci_reset,
@@ -324,6 +392,10 @@ static int spacemit_sdhci_probe(struct platform_device *pdev)
host->mmc->caps |= MMC_CAP_NEED_RSP_BUSY;
+ spacemit_sdhci_get_pins(dev, pltfm_host);
+
+ host->mmc_host_ops.start_signal_voltage_switch = spacemit_sdhci_start_signal_voltage_switch;
+
ret = spacemit_sdhci_get_clocks(dev, pltfm_host);
if (ret)
goto err_pltfm;
--
2.53.0
^ permalink raw reply related
* Re: [PATCH 1/3] dt-bindings: pwm: Add Raspberry Pi RP1 PWM controller
From: Andrea della Porta @ 2026-04-07 8:29 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Andrea della Porta, Uwe Kleine-König, linux-pwm, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Florian Fainelli,
Broadcom internal kernel review list, devicetree,
linux-rpi-kernel, linux-arm-kernel, linux-kernel, Naushir Patuck,
Stanimir Varbanov
In-Reply-To: <20260405-enormous-glittering-avocet-285f82@quoll>
Hi Krzysztof,
On 09:52 Sun 05 Apr , Krzysztof Kozlowski wrote:
> On Fri, Apr 03, 2026 at 04:31:54PM +0200, Andrea della Porta wrote:
> > +required:
> > + - compatible
> > + - reg
> > + - clocks
> > +
>
> Missing ref to pwm.yaml.
The reference to pwm.yaml is at line 13, as follows:
allOf:
- $ref: pwm.yaml#
currently right after the maintainers: block. Are you
suggesting to move it after the required: block?
>
> > +additionalProperties: false
>
> and this should be unevaluatedProperties. See other files.
Ack.
Many thanks,
Andrea
>
> Best regards,
> Krzysztof
>
^ permalink raw reply
* [PATCH v6 2/9] mmc: sdhci-of-k1: enable essential clock infrastructure for SD operation
From: Iker Pedrosa @ 2026-04-07 8:25 UTC (permalink / raw)
To: Ulf Hansson, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Adrian Hunter, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Alexandre Ghiti, Yixun Lan, Yixun Lan
Cc: Troy Mitchell, Michael Opdenacker, Javier Martinez Canillas,
linux-mmc, devicetree, linux-riscv, spacemit, linux-kernel,
Iker Pedrosa, Anand Moon, Trevor Gamblin
In-Reply-To: <20260407-orangepi-sd-card-uhs-v6-0-b5b8a1b2bfc8@gmail.com>
Ensure SD card pins receive clock signals by enabling pad clock
generation and overriding automatic clock gating. Required for all SD
operation modes.
The SDHC_GEN_PAD_CLK_ON setting in LEGACY_CTRL_REG is safe for both SD
and eMMC operation as both protocols use the same physical MMC interface
pins and require proper clock signal generation at the hardware level
for signal integrity and timing.
Additional SD-specific clock overrides (SDHC_OVRRD_CLK_OEN and
SDHC_FORCE_CLK_ON) are conditionally applied only for SD-only
controllers to handle removable card scenarios.
Tested-by: Anand Moon <linux.amoon@gmail.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Tested-by: Trevor Gamblin <tgamblin@baylibre.com>
Reviewed-by: Troy Mitchell <troy.mitchell@linux.dev>
Signed-off-by: Iker Pedrosa <ikerpedrosam@gmail.com>
---
drivers/mmc/host/sdhci-of-k1.c | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/drivers/mmc/host/sdhci-of-k1.c b/drivers/mmc/host/sdhci-of-k1.c
index 455656f9842df90c7a94a290aeec22157b378fc1..0dd06fc19b8574ae1b00f7e5d09b7d4c87d06770 100644
--- a/drivers/mmc/host/sdhci-of-k1.c
+++ b/drivers/mmc/host/sdhci-of-k1.c
@@ -21,6 +21,13 @@
#include "sdhci.h"
#include "sdhci-pltfm.h"
+#define SPACEMIT_SDHC_OP_EXT_REG 0x108
+#define SDHC_OVRRD_CLK_OEN BIT(11)
+#define SDHC_FORCE_CLK_ON BIT(12)
+
+#define SPACEMIT_SDHC_LEGACY_CTRL_REG 0x10C
+#define SDHC_GEN_PAD_CLK_ON BIT(6)
+
#define SPACEMIT_SDHC_MMC_CTRL_REG 0x114
#define SDHC_MISC_INT_EN BIT(1)
#define SDHC_MISC_INT BIT(2)
@@ -101,6 +108,12 @@ static void spacemit_sdhci_reset(struct sdhci_host *host, u8 mask)
if (!(host->mmc->caps2 & MMC_CAP2_NO_MMC))
spacemit_sdhci_setbits(host, SDHC_MMC_CARD_MODE, SPACEMIT_SDHC_MMC_CTRL_REG);
+
+ spacemit_sdhci_setbits(host, SDHC_GEN_PAD_CLK_ON, SPACEMIT_SDHC_LEGACY_CTRL_REG);
+
+ if (host->mmc->caps2 & MMC_CAP2_NO_MMC)
+ spacemit_sdhci_setbits(host, SDHC_OVRRD_CLK_OEN | SDHC_FORCE_CLK_ON,
+ SPACEMIT_SDHC_OP_EXT_REG);
}
static void spacemit_sdhci_set_uhs_signaling(struct sdhci_host *host, unsigned int timing)
--
2.53.0
^ permalink raw reply related
* [PATCH v6 1/9] dt-bindings: mmc: spacemit,sdhci: add pinctrl support for voltage switching
From: Iker Pedrosa @ 2026-04-07 8:25 UTC (permalink / raw)
To: Ulf Hansson, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Adrian Hunter, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Alexandre Ghiti, Yixun Lan, Yixun Lan
Cc: Troy Mitchell, Michael Opdenacker, Javier Martinez Canillas,
linux-mmc, devicetree, linux-riscv, spacemit, linux-kernel,
Iker Pedrosa
In-Reply-To: <20260407-orangepi-sd-card-uhs-v6-0-b5b8a1b2bfc8@gmail.com>
Document pinctrl properties to support voltage-dependent pin
configuration switching for UHS-I SD card modes.
Add optional pinctrl-names property with two states:
- "default": For 3.3V operation with standard drive strength
- "state_uhs": For 1.8V operation with optimized drive strength
These pinctrl states allow the SDHCI driver to coordinate voltage
switching with pin configuration changes, ensuring proper signal
integrity during UHS-I mode transitions.
Signed-off-by: Iker Pedrosa <ikerpedrosam@gmail.com>
---
.../devicetree/bindings/mmc/spacemit,sdhci.yaml | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/Documentation/devicetree/bindings/mmc/spacemit,sdhci.yaml b/Documentation/devicetree/bindings/mmc/spacemit,sdhci.yaml
index 9a055d963a7f0cdba4741c1e3e7269688dcd5f45..932fccc609bf8dbaf3ecfe09d9e610852ac7afa0 100644
--- a/Documentation/devicetree/bindings/mmc/spacemit,sdhci.yaml
+++ b/Documentation/devicetree/bindings/mmc/spacemit,sdhci.yaml
@@ -11,6 +11,7 @@ maintainers:
allOf:
- $ref: mmc-controller.yaml#
+ - $ref: sdhci-common.yaml#
properties:
compatible:
@@ -44,6 +45,18 @@ properties:
- const: axi
- const: sdh
+ pinctrl-names:
+ minItems: 1
+ items:
+ - const: default
+ - const: uhs
+
+ pinctrl-0:
+ description: Default pinctrl state for 3.3V operation
+
+ pinctrl-1:
+ description: Optional pinctrl state for 1.8V UHS operation with "uhs" name
+
required:
- compatible
- reg
@@ -62,4 +75,7 @@ examples:
interrupt-parent = <&plic>;
clocks = <&clk_apmu 10>, <&clk_apmu 13>;
clock-names = "core", "io";
+ pinctrl-names = "default", "uhs";
+ pinctrl-0 = <&sdhci_default_cfg>;
+ pinctrl-1 = <&sdhci_uhs_cfg>;
};
--
2.53.0
^ permalink raw reply related
* [PATCH v6 0/9] riscv: spacemit: enable SD card support with UHS modes for OrangePi RV2
From: Iker Pedrosa @ 2026-04-07 8:25 UTC (permalink / raw)
To: Ulf Hansson, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Adrian Hunter, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Alexandre Ghiti, Yixun Lan, Yixun Lan
Cc: Troy Mitchell, Michael Opdenacker, Javier Martinez Canillas,
linux-mmc, devicetree, linux-riscv, spacemit, linux-kernel,
Iker Pedrosa, Anand Moon, Trevor Gamblin
This series enables complete SD card support for the Spacemit K1-based
OrangePi RV2 board, including UHS (Ultra High Speed) modes for
high-performance SD card operation.
Background
The Spacemit K1 SoC includes an SDHCI controller capable of supporting
SD cards up to UHS-I speeds (SDR104 at 208MHz). However, mainline
currently lacks basic SD controller configuration, SDHCI driver
enhancements for voltage switching and tuning, and power management
infrastructure.
Implementation
The series enables SD card support through coordinated layers:
- Hardware infrastructure (patches 1-2): Device tree bindings for voltage
switching hardware and essential clock infrastructure.
- SDHCI driver enhancements (patches 3-7): Regulator framework
integration, pinctrl state switching for voltage domains, AIB register
programming, and comprehensive SDR tuning support for reliable UHS
operation.
- SoC and board integration (patches 8-10): Complete K1 SoC controller
definitions, PMIC power infrastructure, and OrangePi RV2 board enablement
with full UHS support.
This transforms the OrangePi RV2 from having no SD card support to full
UHS-I capability, enabling high-performance storage up to 208MHz.
Tested-by: Michael Opdenacker <michael.opdenacker@rootcommit.com>
Signed-off-by: Iker Pedrosa <ikerpedrosam@gmail.com>
---
Changes in v6:
- Add pinctrl support for voltage switching. Document optional
pinctrl-names property supporting "default" and "uhs" pinctrl states
for coordinating pin configuration changes during UHS-I voltage
switching.
- Update pinctrl state naming from "state_uhs" to "uhs" to match DT
binding naming convention.
- Fix MMC drive strength values based on vendor kernel investigation.
Correct 3.3V operation from 7mA to 19mA and 1.8V UHS operation from
13mA to 42mA to match proven vendor implementation.
- Link to v5: https://lore.kernel.org/r/20260330-orangepi-sd-card-uhs-v5-0-bd853604322d@gmail.com
Changes in v5:
- Document optional pinctrl-names property supporting "default" and
"state_uhs" pinctrl states for coordinating pin configuration changes
during UHS-I voltage switching.
- Link to v4: https://lore.kernel.org/r/20260323-orangepi-sd-card-uhs-v4-0-567c9775fd0e@gmail.com
Changes in v4:
- Revert to start_signal_voltage_switch() approach for bidirectional
voltage switching: replace voltage_switch() callback with
start_signal_voltage_switch() to properly handle both 3.3V and 1.8V
signal voltage directions.
- Fix DC input voltage specification: corrected the main power supply
from 12V to 5V to match the OrangePi RV2 board specifications. The
board uses a 5V USB-C input connector, not a 12V rail as previously
specified in the device tree.
- k1-bananapi-f3.dts: add `broken-cd` property to work around card
detection. Using `broken-cd` disables hotplug detection but keeps SD
card functionality working without additional dependencies.
- Add SD card support for Muse Pi Pro board (contributed by Trevor
Gamblin): enable SD card support with UHS-I capabilities following the
same pattern as OrangePi RV2, including dual pinctrl states, PMIC
power supplies, and card detection.
- Link to v3: https://lore.kernel.org/r/20260316-orangepi-sd-card-uhs-v3-0-aefd3b7832df@gmail.com
Changes in v3:
- Rebase on mmc.git/next to resolve conflicts with "mmc: sdhci-of-k1:
add reset support" patch.
- Squash tuning infrastructure and implementation patches (3 and 4)
together to form complete functionality and avoid unused function
warnings.
- Reduce code nesting: implemented an early return sanity check in
spacemit_sdhci_voltage_switch() to reduce indentation and improve
logic flow.
- Refactor pinctrl initialization: moved pinctrl resource acquisition
and state lookup into a dedicated helper function,
spacemit_sdhci_get_pins().
- Use generic regulator node names (buck4, aldo1) instead of
device-specific aliases (sd_vmmc, sd_vqmmc) to better reflect that
these PMIC outputs serve multiple devices.
- Remove dead code handling 3.3V voltage switching from
spacemit_sdhci_voltage_switch().
- Optimize tuning algorithm to use single-pass window detection instead
of storing results in array, reducing memory usage and complexity.
- Remove unnecessary card detect check in execute_tuning() - rely on MMC
core.
- Clarify commit message to mention both SD (UHS-I) and eMMC (HS200)
tuning support.
- Add SD card support for Banana Pi BPI-F3 board with UHS-I capabilities
following the same pattern as OrangePi RV2.
- Link to v2: https://lore.kernel.org/r/20260309-orangepi-sd-card-uhs-v2-0-5bb2b574df5d@gmail.com
Changes in v2:
- Removed custom AIB voltage switching code per maintainer feedback. The
existing pinctrl driver already handles AIB voltage switching
automatically via power-source property changes during UHS mode
transitions. This eliminates code duplication.
- Squashed regulator and pinctrl commits into single voltage switching
implementation.
- Moved voltage switching callback from dynamic probe assignment to
static sdhci_ops declaration. Removed redundant SDHCI core call since
the framework handles standard voltage switching automatically.
- Made clock override (SDHC_OVRRD_CLK_OEN | SDHC_FORCE_CLK_ON)
conditional for SD/SDIO cards only. This follows vendor driver pattern
of differentiating SD and eMMC card handling.
- Include no-mmc property for SD card.
- Link to v1: https://lore.kernel.org/r/20260302-orangepi-sd-card-uhs-v1-0-89c219973c0c@gmail.com
---
Iker Pedrosa (8):
dt-bindings: mmc: spacemit,sdhci: add pinctrl support for voltage switching
mmc: sdhci-of-k1: enable essential clock infrastructure for SD operation
mmc: sdhci-of-k1: add regulator and pinctrl voltage switching support
mmc: sdhci-of-k1: add comprehensive SDR tuning support
riscv: dts: spacemit: k1: add SD card controller and pinctrl support
riscv: dts: spacemit: k1-orangepi-rv2: add PMIC and power infrastructure
riscv: dts: spacemit: k1-orangepi-rv2: add SD card support with UHS modes
riscv: dts: spacemit: k1-bananapi-f3: add SD card support with UHS modes
Trevor Gamblin (1):
riscv: dts: spacemit: k1-musepi-pro: add SD card support with UHS modes
.../devicetree/bindings/mmc/spacemit,sdhci.yaml | 16 ++
arch/riscv/boot/dts/spacemit/k1-bananapi-f3.dts | 24 +-
arch/riscv/boot/dts/spacemit/k1-musepi-pro.dts | 66 ++++++
arch/riscv/boot/dts/spacemit/k1-orangepi-rv2.dts | 67 ++++++
arch/riscv/boot/dts/spacemit/k1-pinctrl.dtsi | 40 ++++
arch/riscv/boot/dts/spacemit/k1.dtsi | 13 ++
drivers/mmc/host/sdhci-of-k1.c | 257 +++++++++++++++++++++
7 files changed, 481 insertions(+), 2 deletions(-)
---
base-commit: 4c3b07bf68391122266dfb01126484daf352cf70
change-id: 20260226-orangepi-sd-card-uhs-0ecb05839b0c
Best regards,
--
Iker Pedrosa <ikerpedrosam@gmail.com>
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: sram: qcom,imem: Add the Milos compatible
From: Luca Weiss @ 2026-04-07 8:21 UTC (permalink / raw)
To: Krzysztof Kozlowski, Luca Weiss
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Konrad Dybcio, ~postmarketos/upstreaming, phone-devel,
linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <20260405-rampant-green-harrier-eaf680@quoll>
On Sun Apr 5, 2026 at 9:54 AM CEST, Krzysztof Kozlowski wrote:
> On Fri, Apr 03, 2026 at 05:00:23PM +0200, Luca Weiss wrote:
>> Add compatible for Milos SoC IMEM.
>>
>> Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
>> ---
>> Documentation/devicetree/bindings/sram/qcom,imem.yaml | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/Documentation/devicetree/bindings/sram/qcom,imem.yaml b/Documentation/devicetree/bindings/sram/qcom,imem.yaml
>> index c63026904061..38488e28a6b4 100644
>> --- a/Documentation/devicetree/bindings/sram/qcom,imem.yaml
>> +++ b/Documentation/devicetree/bindings/sram/qcom,imem.yaml
>> @@ -19,6 +19,7 @@ properties:
>> - enum:
>> - qcom,apq8064-imem
>> - qcom,ipq5424-imem
>> + - qcom,milos-imem
>
> Wasn't this imem binding supposed to stop growing and switch to a
> different style?
Then I missed the memo. Is this written anywhere (apart from LKML)?
Regards
Luca
^ permalink raw reply
* Re: [PATCH v6 3/3] fpga-mgr: Add Efinix SPI programming driver
From: Ian Dannapel @ 2026-04-07 8:20 UTC (permalink / raw)
To: Xu Yilun
Cc: linux-fpga, devicetree, linux-kernel, mdf, yilun.xu, trix, robh,
krzk+dt, conor+dt, neil.armstrong, heiko, marex,
prabhakar.mahadev-lad.rj, dev
In-Reply-To: <adSgQJa/8ZPlzPbO@yilunxu-OptiPlex-7050>
Hi,
thanks for the quick review.
On Tue, Apr 7, 2026 at 8:33 AM Xu Yilun <yilun.xu@linux.intel.com> wrote:
>
> > diff --git a/drivers/fpga/Makefile b/drivers/fpga/Makefile
> > index aeb89bb13517..21eb0ef1fc2e 100644
> > --- a/drivers/fpga/Makefile
> > +++ b/drivers/fpga/Makefile
> > @@ -24,6 +24,7 @@ obj-$(CONFIG_FPGA_MGR_VERSAL_FPGA) += versal-fpga.o
> > obj-$(CONFIG_FPGA_MGR_MICROCHIP_SPI) += microchip-spi.o
> > obj-$(CONFIG_FPGA_MGR_LATTICE_SYSCONFIG) += lattice-sysconfig.o
> > obj-$(CONFIG_FPGA_MGR_LATTICE_SYSCONFIG_SPI) += lattice-sysconfig-spi.o
> > +obj-$(CONFIG_FPGA_MGR_EFINIX_SPI) += efinix-spi.o
> > obj-$(CONFIG_ALTERA_PR_IP_CORE) += altera-pr-ip-core.o
> > obj-$(CONFIG_ALTERA_PR_IP_CORE_PLAT) += altera-pr-ip-core-plat.o
>
> This is the tail of "FPGA Manager Drivers", move it here.
All right
>
> ...
>
> > +static int efinix_spi_write_init(struct fpga_manager *mgr,
> > + struct fpga_image_info *info,
> > + const char *buf, size_t count)
> > +{
> > + struct device *dev = &mgr->dev;
>
> Why do you make this change? This is just one-time usage, and in some
> other functions you don't make the same change. Please delete it.
Will revert it
>
> > + struct efinix_spi_conf *conf = mgr->priv;
> > + struct spi_transfer assert_cs = {
> > + .cs_change = 1,
> > + };
> > + struct spi_message message;
> > + int ret;
> > +
> > + if (info->flags & FPGA_MGR_PARTIAL_RECONFIG) {
> > + dev_err(dev, "Partial reconfiguration not supported\n");
> > + return -EOPNOTSUPP;
> > + }
> > +
> > + /*
> > + * Efinix passive SPI configuration requires chip select to stay
> > + * asserted from reset until the bitstream is fully clocked in.
> > + * Lock the SPI bus so no other device can toggle CS between the
> > + * reset pulse and the write/complete transfers.
> > + */
> > + spi_bus_lock(conf->spi->controller);
> > + spi_message_init_with_transfers(&message, &assert_cs, 1);
> > + ret = spi_sync_locked(conf->spi, &message);
> > + if (ret) {
> > + spi_bus_unlock(conf->spi->controller);
> > + return ret;
> > + }
> > +
> > + /* Reset with CS asserted */
> > + efinix_spi_reset(conf);
> > +
> > + return 0;
> > +}
> > +
> > +static int efinix_spi_write(struct fpga_manager *mgr, const char *buf,
> > + size_t count)
> > +{
> > + struct device *dev = &mgr->dev;
>
> ditto.
>
> > + struct spi_transfer write_xfer = {
> > + .tx_buf = buf,
> > + .len = count,
> > + .cs_change = 1, /* Keep CS asserted */
>
> Move this comment to its first appearance.
>
> ...
>
> > +static const struct of_device_id efinix_spi_of_match[] = {
> > + { .compatible = "efinix,trion-config", },
> > + {}
> > +};
> > +MODULE_DEVICE_TABLE(of, efinix_spi_of_match);
> > +
> > +static const struct spi_device_id efinix_ids[] = {
> > + { "trion-config", 0 },
> > + { "titanium-config", 0 },
> > + { "topaz-config", 0 },
>
> Since you've trimmed of_match_table, any reason to keep 3
> spi_device_ids? IIUC you could keep them in sync.
I don't see any reason to have other IDs, will drop them.
I would also rename the file from efinix-spi.c to efinix-config.c to
match the dt bindings
^ permalink raw reply
* [PATCH v13 2/2] arm: dts: aspeed: ventura: add Meta Ventura BMC
From: P.K. Lee @ 2026-04-07 8:17 UTC (permalink / raw)
To: robh+dt, krzysztof.kozlowski+dt, conor+dt, joel, andrew,
devicetree, linux-arm-kernel, linux-aspeed, linux-kernel
Cc: Jason-Hsu, p.k.lee
In-Reply-To: <20260407081700.2658011-1-pkleequanta@gmail.com>
Add Linux device tree related to Meta (Facebook) Ventura specific
devices connected to the BMC (AST2600) SoC. The purpose of Ventura is to
detect liquid leakage from all compute trays, switch trays and rack
sensors within the rack, log the events, and take necessary actions
accordingly.
Signed-off-by: P.K. Lee <pkleequanta@gmail.com>
---
arch/arm/boot/dts/aspeed/Makefile | 1 +
.../aspeed/aspeed-bmc-facebook-ventura.dts | 1636 +++++++++++++++++
2 files changed, 1637 insertions(+)
create mode 100644 arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-ventura.dts
diff --git a/arch/arm/boot/dts/aspeed/Makefile b/arch/arm/boot/dts/aspeed/Makefile
index 0f0b5b707654..f5ac72d5933c 100644
--- a/arch/arm/boot/dts/aspeed/Makefile
+++ b/arch/arm/boot/dts/aspeed/Makefile
@@ -32,6 +32,7 @@ dtb-$(CONFIG_ARCH_ASPEED) += \
aspeed-bmc-facebook-minipack.dtb \
aspeed-bmc-facebook-santabarbara.dtb \
aspeed-bmc-facebook-tiogapass.dtb \
+ aspeed-bmc-facebook-ventura.dtb \
aspeed-bmc-facebook-wedge40.dtb \
aspeed-bmc-facebook-wedge100.dtb \
aspeed-bmc-facebook-wedge400-data64.dtb \
diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-ventura.dts b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-ventura.dts
new file mode 100644
index 000000000000..6ce6201f7755
--- /dev/null
+++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-ventura.dts
@@ -0,0 +1,1636 @@
+// SPDX-License-Identifier: GPL-2.0+
+// Copyright (c) 2023 Facebook Inc.
+/dts-v1/;
+
+#include "aspeed-g6.dtsi"
+#include <dt-bindings/i2c/i2c.h>
+#include <dt-bindings/gpio/aspeed-gpio.h>
+
+/ {
+ model = "Facebook ventura RMC";
+ compatible = "facebook,ventura-rmc", "aspeed,ast2600";
+
+ aliases {
+ serial4 = &uart5;
+ i2c16 = &i2c3mux0ch3;
+ i2c17 = &i2c3mux0ch4;
+ i2c18 = &i2c3mux0ch5;
+ i2c19 = &i2c3mux0ch6;
+ i2c20 = &i2c3mux0ch0;
+ i2c21 = &i2c3mux0ch1;
+ i2c22 = &i2c3mux0ch2;
+ i2c23 = &i2c3mux0ch7;
+ i2c24 = &i2c0mux0ch0;
+ i2c25 = &i2c0mux0ch1;
+ i2c26 = &i2c0mux0ch2;
+ i2c27 = &i2c0mux0ch3;
+ i2c28 = &i2c0mux0ch4;
+ i2c29 = &i2c0mux0ch5;
+ i2c30 = &i2c0mux0ch6;
+ i2c31 = &i2c0mux0ch7;
+ i2c32 = &i2c1mux0ch0;
+ i2c33 = &i2c1mux0ch1;
+ i2c34 = &i2c1mux0ch2;
+ i2c35 = &i2c1mux0ch3;
+ i2c36 = &i2c1mux0ch4;
+ i2c37 = &i2c1mux0ch5;
+ i2c38 = &i2c1mux0ch6;
+ i2c39 = &i2c1mux0ch7;
+ i2c40 = &i2c2mux0ch0;
+ i2c41 = &i2c2mux0ch1;
+ i2c42 = &i2c2mux0ch2;
+ i2c43 = &i2c2mux0ch3;
+ i2c44 = &i2c2mux0ch4;
+ i2c45 = &i2c2mux0ch5;
+ i2c46 = &i2c2mux0ch6;
+ i2c47 = &i2c2mux0ch7;
+ };
+
+ chosen {
+ stdout-path = "serial4:57600n8";
+ };
+
+ iio-hwmon {
+ compatible = "iio-hwmon";
+ io-channels = <&adc0 0>, <&adc0 1>, <&adc0 2>, <&adc0 3>,
+ <&adc0 4>, <&adc0 5>, <&adc0 6>, <&adc0 7>,
+ <&adc1 2>;
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ led-0 {
+ label = "bmc_heartbeat_amber";
+ gpios = <&gpio0 ASPEED_GPIO(P, 7) GPIO_ACTIVE_LOW>;
+ linux,default-trigger = "heartbeat";
+ };
+
+ led-1 {
+ label = "fp_id_amber";
+ default-state = "off";
+ gpios = <&gpio0 ASPEED_GPIO(B, 5) GPIO_ACTIVE_HIGH>;
+ };
+
+ led-2 {
+ label = "bmc_ready_noled";
+ default-state = "on";
+ gpios = <&gpio0 ASPEED_GPIO(B, 3) (GPIO_ACTIVE_HIGH|GPIO_TRANSITORY)>;
+ };
+
+ led-3 {
+ label = "power_blue";
+ default-state = "off";
+ gpios = <&gpio0 ASPEED_GPIO(P, 4) GPIO_ACTIVE_HIGH>;
+ };
+
+ led-4 {
+ label = "compute1_led_switch";
+ default-state = "off";
+ gpios = <&tray_leds_g5_gpio 0 GPIO_ACTIVE_LOW>;
+ };
+
+ led-5 {
+ label = "compute1_led_blue";
+ default-state = "off";
+ gpios = <&tray_leds_g2_gpio 15 GPIO_ACTIVE_LOW>;
+ };
+
+ led-6 {
+ label = "compute1_led_amber";
+ default-state = "off";
+ gpios = <&tray_leds_g2_gpio 14 GPIO_ACTIVE_LOW>;
+ };
+
+ led-7 {
+ label = "compute2_led_switch";
+ default-state = "off";
+ gpios = <&tray_leds_g1_gpio 11 GPIO_ACTIVE_LOW>;
+ };
+
+ led-8 {
+ label = "compute2_led_blue";
+ default-state = "off";
+ gpios = <&tray_leds_g1_gpio 10 GPIO_ACTIVE_LOW>;
+ };
+
+ led-9 {
+ label = "compute2_led_amber";
+ default-state = "off";
+ gpios = <&tray_leds_g1_gpio 9 GPIO_ACTIVE_LOW>;
+ };
+
+ led-10 {
+ label = "compute3_led_switch";
+ default-state = "off";
+ gpios = <&tray_leds_g1_gpio 8 GPIO_ACTIVE_LOW>;
+ };
+
+ led-11 {
+ label = "compute3_led_blue";
+ default-state = "off";
+ gpios = <&tray_leds_g1_gpio 7 GPIO_ACTIVE_LOW>;
+ };
+
+ led-12 {
+ label = "compute3_led_amber";
+ default-state = "off";
+ gpios = <&tray_leds_g1_gpio 6 GPIO_ACTIVE_LOW>;
+ };
+
+ led-13 {
+ label = "compute4_led_switch";
+ default-state = "off";
+ gpios = <&tray_leds_g4_gpio 1 GPIO_ACTIVE_LOW>;
+ };
+
+ led-14 {
+ label = "compute4_led_blue";
+ default-state = "off";
+ gpios = <&tray_leds_g4_gpio 0 GPIO_ACTIVE_LOW>;
+ };
+
+ led-15 {
+ label = "compute4_led_amber";
+ default-state = "off";
+ gpios = <&tray_leds_g1_gpio 15 GPIO_ACTIVE_LOW>;
+ };
+
+ led-16 {
+ label = "compute5_led_switch";
+ default-state = "off";
+ gpios = <&tray_leds_g1_gpio 14 GPIO_ACTIVE_LOW>;
+ };
+
+ led-17 {
+ label = "compute5_led_blue";
+ default-state = "off";
+ gpios = <&tray_leds_g1_gpio 13 GPIO_ACTIVE_LOW>;
+ };
+
+ led-18 {
+ label = "compute5_led_amber";
+ default-state = "off";
+ gpios = <&tray_leds_g1_gpio 12 GPIO_ACTIVE_LOW>;
+ };
+
+ led-19 {
+ label = "compute6_led_switch";
+ default-state = "off";
+ gpios = <&tray_leds_g4_gpio 7 GPIO_ACTIVE_LOW>;
+ };
+
+ led-20 {
+ label = "compute6_led_blue";
+ default-state = "off";
+ gpios = <&tray_leds_g4_gpio 6 GPIO_ACTIVE_LOW>;
+ };
+
+ led-21 {
+ label = "compute6_led_amber";
+ default-state = "off";
+ gpios = <&tray_leds_g4_gpio 5 GPIO_ACTIVE_LOW>;
+ };
+
+ led-22 {
+ label = "compute7_led_switch";
+ default-state = "off";
+ gpios = <&tray_leds_g4_gpio 4 GPIO_ACTIVE_LOW>;
+ };
+
+ led-23 {
+ label = "compute7_led_blue";
+ default-state = "off";
+ gpios = <&tray_leds_g4_gpio 3 GPIO_ACTIVE_LOW>;
+ };
+
+ led-24 {
+ label = "compute7_led_amber";
+ default-state = "off";
+ gpios = <&tray_leds_g4_gpio 2 GPIO_ACTIVE_LOW>;
+ };
+
+ led-25 {
+ label = "compute8_led_switch";
+ default-state = "off";
+ gpios = <&tray_leds_g4_gpio 13 GPIO_ACTIVE_LOW>;
+ };
+
+ led-26 {
+ label = "compute8_led_blue";
+ default-state = "off";
+ gpios = <&tray_leds_g4_gpio 12 GPIO_ACTIVE_LOW>;
+ };
+
+ led-27 {
+ label = "compute8_led_amber";
+ default-state = "off";
+ gpios = <&tray_leds_g4_gpio 11 GPIO_ACTIVE_LOW>;
+ };
+
+ led-28 {
+ label = "nvs1_led_switch";
+ default-state = "off";
+ gpios = <&tray_leds_g4_gpio 10 GPIO_ACTIVE_LOW>;
+ };
+
+ led-29 {
+ label = "nvs1_led_blue";
+ default-state = "off";
+ gpios = <&tray_leds_g4_gpio 9 GPIO_ACTIVE_LOW>;
+ };
+
+ led-30 {
+ label = "nvs1_led_amber";
+ default-state = "off";
+ gpios = <&tray_leds_g4_gpio 8 GPIO_ACTIVE_LOW>;
+ };
+
+ led-31 {
+ label = "nvs2_led_switch";
+ default-state = "off";
+ gpios = <&tray_leds_g3_gpio 3 GPIO_ACTIVE_LOW>;
+ };
+
+ led-32 {
+ label = "nvs2_led_blue";
+ default-state = "off";
+ gpios = <&tray_leds_g3_gpio 2 GPIO_ACTIVE_LOW>;
+ };
+
+ led-33 {
+ label = "nvs2_led_amber";
+ default-state = "off";
+ gpios = <&tray_leds_g3_gpio 1 GPIO_ACTIVE_LOW>;
+ };
+
+ led-34 {
+ label = "nvs3_led_switch";
+ default-state = "off";
+ gpios = <&tray_leds_g3_gpio 0 GPIO_ACTIVE_LOW>;
+ };
+
+ led-35 {
+ label = "nvs3_led_blue";
+ default-state = "off";
+ gpios = <&tray_leds_g4_gpio 15 GPIO_ACTIVE_LOW>;
+ };
+
+ led-36 {
+ label = "nvs3_led_amber";
+ default-state = "off";
+ gpios = <&tray_leds_g4_gpio 14 GPIO_ACTIVE_LOW>;
+ };
+
+ led-37 {
+ label = "nvs4_led_switch";
+ default-state = "off";
+ gpios = <&tray_leds_g3_gpio 9 GPIO_ACTIVE_LOW>;
+ };
+
+ led-38 {
+ label = "nvs4_led_blue";
+ default-state = "off";
+ gpios = <&tray_leds_g3_gpio 8 GPIO_ACTIVE_LOW>;
+ };
+
+ led-39 {
+ label = "nvs4_led_amber";
+ default-state = "off";
+ gpios = <&tray_leds_g3_gpio 7 GPIO_ACTIVE_LOW>;
+ };
+
+ led-40 {
+ label = "nvs5_led_switch";
+ default-state = "off";
+ gpios = <&tray_leds_g3_gpio 6 GPIO_ACTIVE_LOW>;
+ };
+
+ led-41 {
+ label = "nvs5_led_blue";
+ default-state = "off";
+ gpios = <&tray_leds_g3_gpio 5 GPIO_ACTIVE_LOW>;
+ };
+
+ led-42 {
+ label = "nvs5_led_amber";
+ default-state = "off";
+ gpios = <&tray_leds_g3_gpio 4 GPIO_ACTIVE_LOW>;
+ };
+
+ led-43 {
+ label = "nvs6_led_switch";
+ default-state = "off";
+ gpios = <&tray_leds_g3_gpio 15 GPIO_ACTIVE_LOW>;
+ };
+
+ led-44 {
+ label = "nvs6_led_blue";
+ default-state = "off";
+ gpios = <&tray_leds_g3_gpio 14 GPIO_ACTIVE_LOW>;
+ };
+
+ led-45 {
+ label = "nvs6_led_amber";
+ default-state = "off";
+ gpios = <&tray_leds_g3_gpio 13 GPIO_ACTIVE_LOW>;
+ };
+
+ led-46 {
+ label = "nvs7_led_switch";
+ default-state = "off";
+ gpios = <&tray_leds_g3_gpio 12 GPIO_ACTIVE_LOW>;
+ };
+
+ led-47 {
+ label = "nvs7_led_blue";
+ default-state = "off";
+ gpios = <&tray_leds_g3_gpio 11 GPIO_ACTIVE_LOW>;
+ };
+
+ led-48 {
+ label = "nvs7_led_amber";
+ default-state = "off";
+ gpios = <&tray_leds_g3_gpio 10 GPIO_ACTIVE_LOW>;
+ };
+
+ led-49 {
+ label = "nvs8_led_switch";
+ default-state = "off";
+ gpios = <&tray_leds_g6_gpio 5 GPIO_ACTIVE_LOW>;
+ };
+
+ led-50 {
+ label = "nvs8_led_blue";
+ default-state = "off";
+ gpios = <&tray_leds_g6_gpio 4 GPIO_ACTIVE_LOW>;
+ };
+
+ led-51 {
+ label = "nvs8_led_amber";
+ default-state = "off";
+ gpios = <&tray_leds_g6_gpio 3 GPIO_ACTIVE_LOW>;
+ };
+
+ led-52 {
+ label = "nvs9_led_switch";
+ default-state = "off";
+ gpios = <&tray_leds_g6_gpio 2 GPIO_ACTIVE_LOW>;
+ };
+
+ led-53 {
+ label = "nvs9_led_blue";
+ default-state = "off";
+ gpios = <&tray_leds_g6_gpio 1 GPIO_ACTIVE_LOW>;
+ };
+
+ led-54 {
+ label = "nvs9_led_amber";
+ default-state = "off";
+ gpios = <&tray_leds_g6_gpio 0 GPIO_ACTIVE_LOW>;
+ };
+
+ led-55 {
+ label = "compute9_led_switch";
+ default-state = "off";
+ gpios = <&tray_leds_g6_gpio 11 GPIO_ACTIVE_LOW>;
+ };
+
+ led-56 {
+ label = "compute9_led_blue";
+ default-state = "off";
+ gpios = <&tray_leds_g6_gpio 10 GPIO_ACTIVE_LOW>;
+ };
+
+ led-57 {
+ label = "compute9_led_amber";
+ default-state = "off";
+ gpios = <&tray_leds_g6_gpio 9 GPIO_ACTIVE_LOW>;
+ };
+
+ led-58 {
+ label = "compute10_led_switch";
+ default-state = "off";
+ gpios = <&tray_leds_g6_gpio 8 GPIO_ACTIVE_LOW>;
+ };
+
+ led-59 {
+ label = "compute10_led_blue";
+ default-state = "off";
+ gpios = <&tray_leds_g6_gpio 7 GPIO_ACTIVE_LOW>;
+ };
+
+ led-60 {
+ label = "compute10_led_amber";
+ default-state = "off";
+ gpios = <&tray_leds_g6_gpio 6 GPIO_ACTIVE_LOW>;
+ };
+
+ led-61 {
+ label = "compute11_led_switch";
+ default-state = "off";
+ gpios = <&tray_leds_g2_gpio 1 GPIO_ACTIVE_LOW>;
+ };
+
+ led-62 {
+ label = "compute11_led_blue";
+ default-state = "off";
+ gpios = <&tray_leds_g2_gpio 0 GPIO_ACTIVE_LOW>;
+ };
+
+ led-63 {
+ label = "compute11_led_amber";
+ default-state = "off";
+ gpios = <&tray_leds_g6_gpio 15 GPIO_ACTIVE_LOW>;
+ };
+
+ led-64 {
+ label = "compute12_led_switch";
+ default-state = "off";
+ gpios = <&tray_leds_g6_gpio 14 GPIO_ACTIVE_LOW>;
+ };
+
+ led-65 {
+ label = "compute12_led_blue";
+ default-state = "off";
+ gpios = <&tray_leds_g6_gpio 13 GPIO_ACTIVE_LOW>;
+ };
+
+ led-66 {
+ label = "compute12_led_amber";
+ default-state = "off";
+ gpios = <&tray_leds_g6_gpio 12 GPIO_ACTIVE_LOW>;
+ };
+
+ led-67 {
+ label = "compute13_led_switch";
+ default-state = "off";
+ gpios = <&tray_leds_g2_gpio 7 GPIO_ACTIVE_LOW>;
+ };
+
+ led-68 {
+ label = "compute13_led_blue";
+ default-state = "off";
+ gpios = <&tray_leds_g2_gpio 6 GPIO_ACTIVE_LOW>;
+ };
+
+ led-69 {
+ label = "compute13_led_amber";
+ default-state = "off";
+ gpios = <&tray_leds_g2_gpio 5 GPIO_ACTIVE_LOW>;
+ };
+
+ led-70 {
+ label = "compute14_led_switch";
+ default-state = "off";
+ gpios = <&tray_leds_g2_gpio 4 GPIO_ACTIVE_LOW>;
+ };
+
+ led-71 {
+ label = "compute14_led_blue";
+ default-state = "off";
+ gpios = <&tray_leds_g2_gpio 3 GPIO_ACTIVE_LOW>;
+ };
+
+ led-72 {
+ label = "compute14_led_amber";
+ default-state = "off";
+ gpios = <&tray_leds_g2_gpio 2 GPIO_ACTIVE_LOW>;
+ };
+
+ led-73 {
+ label = "compute15_led_switch";
+ default-state = "off";
+ gpios = <&tray_leds_g2_gpio 13 GPIO_ACTIVE_LOW>;
+ };
+
+ led-74 {
+ label = "compute15_led_blue";
+ default-state = "off";
+ gpios = <&tray_leds_g2_gpio 12 GPIO_ACTIVE_LOW>;
+ };
+
+ led-75 {
+ label = "compute15_led_amber";
+ default-state = "off";
+ gpios = <&tray_leds_g2_gpio 11 GPIO_ACTIVE_LOW>;
+ };
+
+ led-76 {
+ label = "compute16_led_switch";
+ default-state = "off";
+ gpios = <&tray_leds_g2_gpio 10 GPIO_ACTIVE_LOW>;
+ };
+
+ led-77 {
+ label = "compute16_led_blue";
+ default-state = "off";
+ gpios = <&tray_leds_g2_gpio 9 GPIO_ACTIVE_LOW>;
+ };
+
+ led-78 {
+ label = "compute16_led_amber";
+ default-state = "off";
+ gpios = <&tray_leds_g2_gpio 8 GPIO_ACTIVE_LOW>;
+ };
+
+ led-79 {
+ label = "compute17_led_switch";
+ default-state = "off";
+ gpios = <&tray_leds_g1_gpio 5 GPIO_ACTIVE_LOW>;
+ };
+
+ led-80 {
+ label = "compute17_led_blue";
+ default-state = "off";
+ gpios = <&tray_leds_g1_gpio 4 GPIO_ACTIVE_LOW>;
+ };
+
+ led-81 {
+ label = "compute17_led_amber";
+ default-state = "off";
+ gpios = <&tray_leds_g1_gpio 3 GPIO_ACTIVE_LOW>;
+ };
+
+ led-82 {
+ label = "compute18_led_switch";
+ default-state = "off";
+ gpios = <&tray_leds_g1_gpio 2 GPIO_ACTIVE_LOW>;
+ };
+
+ led-83 {
+ label = "compute18_led_blue";
+ default-state = "off";
+ gpios = <&tray_leds_g1_gpio 1 GPIO_ACTIVE_LOW>;
+ };
+
+ led-84 {
+ label = "compute18_led_amber";
+ default-state = "off";
+ gpios = <&tray_leds_g1_gpio 0 GPIO_ACTIVE_LOW>;
+ };
+
+ led-85 {
+ label = "fan0_ledd1_blue";
+ default-state = "off";
+ gpios = <&fan_leds_g1_gpio 0 GPIO_ACTIVE_LOW>;
+ };
+
+ led-86 {
+ label = "fan0_ledd2_blue";
+ default-state = "off";
+ gpios = <&fan_leds_g1_gpio 1 GPIO_ACTIVE_LOW>;
+ };
+
+ led-87 {
+ label = "fan0_ledd1_amber";
+ default-state = "off";
+ gpios = <&fan_leds_g1_gpio 4 GPIO_ACTIVE_LOW>;
+ };
+
+ led-88 {
+ label = "fan0_ledd2_amber";
+ default-state = "off";
+ gpios = <&fan_leds_g1_gpio 5 GPIO_ACTIVE_LOW>;
+ };
+
+ led-89 {
+ label = "fan1_ledd1_blue";
+ default-state = "off";
+ gpios = <&fan_leds_g2_gpio 0 GPIO_ACTIVE_LOW>;
+ };
+
+ led-90 {
+ label = "fan1_ledd2_blue";
+ default-state = "off";
+ gpios = <&fan_leds_g2_gpio 1 GPIO_ACTIVE_LOW>;
+ };
+
+ led-91 {
+ label = "fan1_ledd1_amber";
+ default-state = "off";
+ gpios = <&fan_leds_g2_gpio 4 GPIO_ACTIVE_LOW>;
+ };
+
+ led-92 {
+ label = "fan1_ledd2_amber";
+ default-state = "off";
+ gpios = <&fan_leds_g2_gpio 5 GPIO_ACTIVE_LOW>;
+ };
+ };
+
+ memory@80000000 {
+ device_type = "memory";
+ reg = <0x80000000 0x80000000>;
+ };
+
+ p1v8_bmc_aux: regulator-p1v8-bmc-aux {
+ compatible = "regulator-fixed";
+ regulator-name = "p1v8_bmc_aux";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-always-on;
+ };
+
+ p2v5_bmc_aux: regulator-p2v5-bmc-aux {
+ compatible = "regulator-fixed";
+ regulator-name = "p2v5_bmc_aux";
+ regulator-min-microvolt = <2500000>;
+ regulator-max-microvolt = <2500000>;
+ regulator-always-on;
+ };
+
+ spi1_gpio: spi {
+ compatible = "spi-gpio";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ sck-gpios = <&gpio0 ASPEED_GPIO(Z, 3) GPIO_ACTIVE_HIGH>;
+ mosi-gpios = <&gpio0 ASPEED_GPIO(Z, 4) GPIO_ACTIVE_HIGH>;
+ miso-gpios = <&gpio0 ASPEED_GPIO(Z, 5) GPIO_ACTIVE_HIGH>;
+ cs-gpios = <&gpio0 ASPEED_GPIO(Z, 0) GPIO_ACTIVE_LOW>;
+ num-chipselects = <1>;
+
+ tpm@0 {
+ compatible = "infineon,slb9670", "tcg,tpm_tis-spi";
+ spi-max-frequency = <33000000>;
+ reg = <0>;
+ };
+ };
+};
+
+&adc0 {
+ vref-supply = <&p1v8_bmc_aux>;
+ status = "okay";
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_adc0_default &pinctrl_adc1_default
+ &pinctrl_adc2_default &pinctrl_adc3_default
+ &pinctrl_adc4_default &pinctrl_adc5_default
+ &pinctrl_adc6_default &pinctrl_adc7_default>;
+};
+
+&adc1 {
+ vref-supply = <&p2v5_bmc_aux>;
+ status = "okay";
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_adc10_default>;
+};
+
+&ehci0 {
+ status = "okay";
+};
+
+&ehci1 {
+ status = "okay";
+};
+
+&fmc {
+ status = "okay";
+ flash@0 {
+ status = "okay";
+ m25p,fast-read;
+ label = "bmc";
+ spi-max-frequency = <50000000>;
+#include "openbmc-flash-layout-128.dtsi"
+ };
+ flash@1 {
+ status = "okay";
+ m25p,fast-read;
+ label = "alt-bmc";
+ spi-max-frequency = <50000000>;
+ };
+};
+
+&gpio0 {
+ gpio-line-names =
+ /*A0-A7*/ "","","","","","","","",
+ /*B0-B7*/ "BATTERY_DETECT","","","BMC_READY","","","","",
+ /*C0-C7*/ "","","","","","","","",
+ /*D0-D7*/ "","","","","","","","",
+ /*E0-E7*/ "","","","","","","","",
+ /*F0-F7*/ "","","","","","","","",
+ /*G0-G7*/ "","","","","","","","",
+ /*H0-H7*/ "","","","","","","","",
+ /*I0-I7*/ "","","","","","","","",
+ /*J0-J7*/ "","","","","","","","",
+ /*K0-K7*/ "","","","","","","","",
+ /*L0-L7*/ "","","","","","","","",
+ /*M0-M7*/ "","","","","","","","",
+ /*N0-N7*/ "","","","","","","","",
+ /*O0-O7*/ "","","","","","","","USBDBG_IPMI_EN_L",
+ /*P0-P7*/ "","","","","","","","",
+ /*Q0-Q7*/ "","","","","","FM_MDIO_SW_SEL","","",
+ /*R0-R7*/ "","","","","","","","",
+ /*S0-S7*/ "","","","","","","","",
+ /*T0-T7*/ "","","","","","","","",
+ /*U0-U7*/ "","","","","","","","",
+ /*V0-V7*/ "","","","","","","","",
+ /*W0-W7*/ "","","","","","","","",
+ /*X0-X7*/ "","","","","","","","",
+ /*Y0-Y7*/ "","","","","","","","",
+ /*Z0-Z7*/ "","","","","","","","";
+};
+
+&i2c0 {
+ status = "okay";
+
+ i2c-mux@77 {
+ compatible = "nxp,pca9548";
+ reg = <0x77>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ i2c0mux0ch0: i2c@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+ status = "okay";
+ };
+
+ i2c0mux0ch1: i2c@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+ status = "okay";
+ };
+
+ i2c0mux0ch2: i2c@2 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <2>;
+ status = "okay";
+ };
+
+ i2c0mux0ch3: i2c@3 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <3>;
+ status = "okay";
+ };
+
+ i2c0mux0ch4: i2c@4 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <4>;
+ status = "okay";
+ };
+
+ i2c0mux0ch5: i2c@5 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <5>;
+ status = "okay";
+ };
+
+ i2c0mux0ch6: i2c@6 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <6>;
+ status = "okay";
+ };
+
+ i2c0mux0ch7: i2c@7 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <7>;
+ status = "okay";
+ };
+ };
+};
+
+&i2c1 {
+ status = "okay";
+
+ i2c-mux@77 {
+ compatible = "nxp,pca9548";
+ reg = <0x77>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ i2c1mux0ch0: i2c@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+ status = "okay";
+ };
+
+ i2c1mux0ch1: i2c@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+ status = "okay";
+ };
+
+ i2c1mux0ch2: i2c@2 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <2>;
+ status = "okay";
+ };
+
+ i2c1mux0ch3: i2c@3 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <3>;
+ status = "okay";
+ };
+
+ i2c1mux0ch4: i2c@4 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <4>;
+ status = "okay";
+ };
+
+ i2c1mux0ch5: i2c@5 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <5>;
+ status = "okay";
+ };
+
+ i2c1mux0ch6: i2c@6 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <6>;
+ status = "okay";
+ };
+
+ i2c1mux0ch7: i2c@7 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <7>;
+ status = "okay";
+ };
+ };
+};
+
+&i2c2 {
+ status = "okay";
+
+ i2c-mux@77 {
+ compatible = "nxp,pca9548";
+ reg = <0x77>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ i2c2mux0ch0: i2c@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+ status = "okay";
+ };
+
+ i2c2mux0ch1: i2c@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+ status = "okay";
+ };
+
+ i2c2mux0ch2: i2c@2 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <2>;
+ status = "okay";
+ };
+
+ i2c2mux0ch3: i2c@3 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <3>;
+ status = "okay";
+ };
+
+ i2c2mux0ch4: i2c@4 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <4>;
+ status = "okay";
+ };
+
+ i2c2mux0ch5: i2c@5 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <5>;
+ status = "okay";
+ };
+
+ i2c2mux0ch6: i2c@6 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <6>;
+ status = "okay";
+ };
+
+ i2c2mux0ch7: i2c@7 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <7>;
+ status = "okay";
+ };
+ };
+};
+
+&i2c3 {
+ status = "okay";
+
+ i2c-mux@77 {
+ compatible = "nxp,pca9548";
+ reg = <0x77>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ i2c3mux0ch0: i2c@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+ status = "okay";
+ };
+
+ i2c3mux0ch1: i2c@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+ status = "okay";
+ };
+
+ i2c3mux0ch2: i2c@2 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <2>;
+ status = "okay";
+ };
+
+ i2c3mux0ch3: i2c@3 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <3>;
+
+ adc@1f {
+ compatible = "ti,adc128d818";
+ reg = <0x1f>;
+ ti,mode = /bits/ 8 <1>;
+ };
+
+ fan_leds_g1_gpio: gpio@21 {
+ compatible = "nxp,pca9555";
+ reg = <0x21>;
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ gpio-line-names =
+ "", "",
+ "", "",
+ "", "",
+ "", "",
+ "FAN0_PRSNT", "FAN1_PRSNT",
+ "", "",
+ "", "",
+ "", "";
+ };
+
+ adc@35 {
+ compatible = "maxim,max11617";
+ reg = <0x35>;
+ };
+
+ // Fan Board 0 FRU
+ eeprom@56 {
+ compatible = "atmel,24c128";
+ reg = <0x56>;
+ };
+ };
+
+ i2c3mux0ch4: i2c@4 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <4>;
+
+ adc@1f {
+ compatible = "ti,adc128d818";
+ reg = <0x1f>;
+ ti,mode = /bits/ 8 <1>;
+ };
+
+ fan_leds_g2_gpio: gpio@21 {
+ compatible = "nxp,pca9555";
+ reg = <0x21>;
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ gpio-line-names =
+ "", "",
+ "", "",
+ "", "",
+ "", "",
+ "FAN2_PRSNT", "FAN3_PRSNT",
+ "", "",
+ "", "",
+ "", "";
+ };
+
+ adc@35 {
+ compatible = "maxim,max11617";
+ reg = <0x35>;
+ };
+
+ // Fan Board 1 FRU
+ eeprom@56 {
+ compatible = "atmel,24c128";
+ reg = <0x56>;
+ };
+ };
+
+ i2c3mux0ch5: i2c@5 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <5>;
+
+ pwm@20 {
+ compatible = "maxim,max31790";
+ reg = <0x20>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ channel@2 {
+ reg = <2>;
+ sensor-type = "TACH";
+ };
+ channel@5 {
+ reg = <5>;
+ sensor-type = "TACH";
+ };
+ };
+
+ hwmon: hwmon@23 {
+ compatible = "nuvoton,nct7363";
+ reg = <0x23>;
+ #pwm-cells = <2>;
+
+ //fan 0 IL
+ fan-0 {
+ pwms = <&hwmon 0 20000>;
+ tach-ch = /bits/ 8 <0x09>;
+ };
+
+ //fan 0 OL
+ fan-1 {
+ pwms = <&hwmon 0 20000>;
+ tach-ch = /bits/ 8 <0x0B>;
+ };
+
+ //fan 1 IL
+ fan-2 {
+ pwms = <&hwmon 4 20000>;
+ tach-ch = /bits/ 8 <0x0A>;
+ };
+
+ //fan 1 OL
+ fan-3 {
+ pwms = <&hwmon 4 20000>;
+ tach-ch = /bits/ 8 <0x0D>;
+ };
+
+ //fan 2 IL
+ fan-4 {
+ pwms = <&hwmon 6 20000>;
+ tach-ch = /bits/ 8 <0x0F>;
+ };
+
+ //fan 2 OL
+ fan-5 {
+ pwms = <&hwmon 6 20000>;
+ tach-ch = /bits/ 8 <0x01>;
+ };
+
+ //fan 3 IL
+ fan-6 {
+ pwms = <&hwmon 10 20000>;
+ tach-ch = /bits/ 8 <0x00>;
+ };
+
+ //fan 3 OL
+ fan-7 {
+ pwms = <&hwmon 10 20000>;
+ tach-ch = /bits/ 8 <0x03>;
+ };
+ };
+ };
+
+ i2c3mux0ch6: i2c@6 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <6>;
+
+ // REAR-IO Board FRU
+ eeprom@56 {
+ compatible = "atmel,24c128";
+ reg = <0x56>;
+ };
+ };
+
+ i2c3mux0ch7: i2c@7 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <7>;
+ status = "okay";
+ };
+ };
+};
+
+&i2c4 {
+ status = "okay";
+};
+
+&i2c5 {
+ status = "okay";
+
+ // VR TEMP U399
+ temperature-sensor@4c {
+ compatible = "ti,tmp75";
+ reg = <0x4c>;
+ };
+
+ // VR TEMP U397
+ temperature-sensor@4d {
+ compatible = "ti,tmp75";
+ reg = <0x4d>;
+ };
+
+ // BRICK TEMP U398
+ temperature-sensor@4e {
+ compatible = "ti,tmp75";
+ reg = <0x4e>;
+ };
+
+ temperature-sensor@4f {
+ compatible = "ti,tmp75";
+ reg = <0x4f>;
+ };
+
+ // RMC FRU
+ eeprom@54 {
+ compatible = "atmel,24c128";
+ reg = <0x54>;
+ };
+};
+
+&i2c6 {
+ status = "okay";
+
+ gpio@20 {
+ compatible = "nxp,pca9555";
+ reg = <0x20>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+
+ gpio@21 {
+ compatible = "nxp,pca9555";
+ reg = <0x21>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+
+ gpio@22 {
+ compatible = "nxp,pca9555";
+ reg = <0x22>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+
+ rtc@51 {
+ compatible = "nxp,pcf8563";
+ reg = <0x51>;
+ };
+};
+
+&i2c7 {
+ status = "okay";
+ bus-frequency = <100000>;
+ multi-master;
+ i2c-scl-clk-low-timeout-us = <31744>;
+
+ //USB Debug Connector
+ ipmb@10 {
+ compatible = "ipmb-dev";
+ reg = <(0x10 | I2C_OWN_SLAVE_ADDRESS)>;
+ i2c-protocol;
+ };
+};
+
+&i2c9 {
+ status = "okay";
+
+ // SCM TEMP SENSOR
+ temperature-sensor@4b {
+ compatible = "ti,tmp75";
+ reg = <0x4b>;
+ };
+
+ // SCM FRU EEPROM
+ eeprom@50 {
+ compatible = "atmel,24c128";
+ reg = <0x50>;
+ };
+
+ // BSM FRU EEPROM
+ eeprom@56 {
+ compatible = "atmel,24c64";
+ reg = <0x56>;
+ };
+};
+
+&i2c10 {
+ status = "okay";
+
+ gpio@10 {
+ compatible = "nxp,pca9555";
+ reg = <0x10>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-parent = <&sgpiom0>;
+ interrupts = <16 IRQ_TYPE_LEVEL_LOW>;
+
+ gpio-line-names =
+ "IT_STOP_PUMP_SPARE_2", "IT_STOP_PUMP_2",
+ "IT_STOP_PUMP_SPARE", "IT_STOP_PUMP",
+ "", "RPU_2_READY_PLD_R",
+ "RPU_READY_SPARE_PLD_R", "",
+ "wPWRGD_P12V_SCM_R", "wPWRGD_P12V_AUX_R",
+ "wPWRGD_P24V_AUX_R", "wPWRGD_P52V_HSC_PWROK_R",
+ "wSMB_TMC75_TEMP_ALERT_N_R", "wP48V_HSC_ALERT_N",
+ "wP24V_AUX_INA230_ALERT_N_R", "wP24V_SM_INA230_ALERT_N_R";
+ };
+
+ gpio@11 {
+ compatible = "nxp,pca9555";
+ reg = <0x11>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-parent = <&sgpiom0>;
+ interrupts = <2 IRQ_TYPE_LEVEL_LOW>;
+
+ gpio-line-names =
+ "", "",
+ "", "wPWRGD_P24V_SMPWROK",
+ "wPWRGD_P1V05_AUX_R", "wPWRGD_P1V5_AUX_R",
+ "wPWRGD_P3V3_AUX_R", "wPWRGD_P5V_AUX_R",
+ "", "",
+ "", "",
+ "", "",
+ "", "";
+ };
+
+ power-monitor@14 {
+ compatible = "infineon,xdp710";
+ reg = <0x14>;
+ };
+
+ gpio@16 {
+ compatible = "nxp,pca9555";
+ reg = <0x16>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-parent = <&sgpiom0>;
+ interrupts = <28 IRQ_TYPE_LEVEL_LOW>;
+
+ gpio-line-names =
+ "PWREN_COMPUTE_BLADE2_EN_R", "PWREN_COMPUTE_BLADE1_EN_R",
+ "", "",
+ "", "",
+ "", "",
+ "PWREN_NVS_BLADE2_EN_L_R", "PWREN_NVS_BLADE1_EN_L_R",
+ "PWREN_COMPUTE_BLADE8_EN_R", "PWREN_COMPUTE_BLADE7_EN_R",
+ "PWREN_COMPUTE_BLADE6_EN_R", "PWREN_COMPUTE_BLADE5_EN_R",
+ "PWREN_COMPUTE_BLADE4_EN_R", "PWREN_COMPUTE_BLADE3_EN_R";
+ };
+
+ gpio@17 {
+ compatible = "nxp,pca9555";
+ reg = <0x17>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-parent = <&sgpiom0>;
+ interrupts = <26 IRQ_TYPE_LEVEL_LOW>;
+
+ gpio-line-names =
+ "PWREN_COMPUTE_BLADE18_EN_R", "PWREN_COMPUTE_BLADE17_EN_R",
+ "PWREN_COMPUTE_BLADE16_EN_R", "PWREN_COMPUTE_BLADE15_EN_R",
+ "PWREN_COMPUTE_BLADE14_EN_R", "PWREN_COMPUTE_BLADE13_EN_R",
+ "PWREN_COMPUTE_BLADE12_EN_R", "PWREN_COMPUTE_BLADE11_EN_R",
+ "PWREN_COMPUTE_BLADE9_EN_R", "PWREN_NVS_BLADE9_EN_L_R",
+ "PWREN_NVS_BLADE8_EN_L_R", "PWREN_NVS_BLADE7_EN_L_R",
+ "PWREN_NVS_BLADE6_EN_L_R", "PWREN_NVS_BLADE5_EN_L_R",
+ "PWREN_NVS_BLADE4_EN_L_R", "PWREN_NVS_BLADE3_EN_L_R";
+ };
+
+ gpio@19 {
+ compatible = "nxp,pca9555";
+ reg = <0x19>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-parent = <&sgpiom0>;
+ interrupts = <22 IRQ_TYPE_LEVEL_LOW>;
+
+ gpio-line-names =
+ "", "",
+ "", "",
+ "", "",
+ "", "",
+ "wIT_GEAR_RPU_2_LINK_PRSNT_SPARE_N_R", "wIT_GEAR_RPU_2_LINK_PRSNT_N_R",
+ "wIT_GEAR_RPU_LINK_PRSNT_SPARE_N_R", "wIT_GEAR_RPU_LINK_PRSNT_N_R",
+ "", "",
+ "", "";
+ };
+
+ gpio@1a {
+ compatible = "nxp,pca9555";
+ reg = <0x1a>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-parent = <&sgpiom0>;
+ interrupts = <20 IRQ_TYPE_LEVEL_LOW>;
+
+ gpio-line-names =
+ "wPRSNT_LEAK1_SENSOR_R_PLD_N", "wPRSNT_LEAK0_SENSOR_R_PLD_N",
+ "", "",
+ "", "",
+ "", "",
+ "", "",
+ "", "",
+ "", "",
+ "", "wPRSNT_LEAK2_SENSOR_R_PLD_N";
+ };
+
+ gpio@1b {
+ compatible = "nxp,pca9555";
+ reg = <0x1b>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-parent = <&sgpiom0>;
+ interrupts = <18 IRQ_TYPE_LEVEL_LOW>;
+
+ gpio-line-names =
+ "", "",
+ "", "",
+ "", "wPRSNT_LEAK4_SENSOR_R_PLD_N",
+ "wPRSNT_LEAK3_SENSOR_R_PLD_N", "",
+ "", "",
+ "", "",
+ "", "",
+ "", "PWREN_COMPUTE_BLADE10_EN_R";
+ };
+
+ power-monitor@44 {
+ compatible = "lltc,ltc4286";
+ reg = <0x44>;
+ };
+};
+
+&i2c14 {
+ status = "okay";
+};
+
+&i2c15 {
+ status = "okay";
+
+ tray_leds_g1_gpio: gpio@20 {
+ compatible = "nxp,pca9555";
+ reg = <0x20>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+
+ tray_leds_g2_gpio: gpio@21 {
+ compatible = "nxp,pca9555";
+ reg = <0x21>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+
+ tray_leds_g3_gpio: gpio@22 {
+ compatible = "nxp,pca9555";
+ reg = <0x22>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+
+ tray_leds_g4_gpio: gpio@24 {
+ compatible = "nxp,pca9555";
+ reg = <0x24>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+
+ tray_leds_g5_gpio: gpio@25 {
+ compatible = "nxp,pca9555";
+ reg = <0x25>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+
+ tray_leds_g6_gpio: gpio@26 {
+ compatible = "nxp,pca9555";
+ reg = <0x26>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+
+ // LED Board FRU
+ eeprom@56 {
+ compatible = "atmel,24c128";
+ reg = <0x56>;
+ };
+};
+
+&mac3 {
+ status = "okay";
+ phy-mode = "rmii";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_rmii4_default>;
+
+ /* Connected to Marvell 88E6393X CPU port in unmanaged mode */
+ fixed-link {
+ speed = <100>;
+ full-duplex;
+ };
+};
+
+&mdio0 {
+ status = "okay";
+ /* * Intentionally left empty.
+ * Enabled to allow user-space tools (e.g., mdio)
+ * to access the unmanaged Marvell switch registers.
+ */
+};
+
+&sgpiom0 {
+ status = "okay";
+ ngpios = <128>;
+ bus-frequency = <2000000>;
+
+ gpio-line-names =
+ /*"input pin","output pin"*/
+ /*A0 - A7*/
+ "power-chassis-good","power-chassis-control",
+ "IOEXP1_INT_N","WATER_VALVE_CLOSED_N",
+ "wPRSNT_RETURN_PLD_R_N","FM_MDIO_SW_SEL_PLD",
+ "wPRSNT_SUPPLY_PLD_R_N","FM_88E6393X_BIN_UPDATE_EN_N",
+ "LEAK3_DETECT","",
+ "LEAK4_DETECT","",
+ "RETURN_CNTL_FB_D_R","",
+ "SUPPLY_CNTL_FB_D_R","",
+ /*B0 - B7*/
+ "IOEXP0_INT_N","",
+ "IOEXP11_INT_N","",
+ "IOEXP10_INT_N","",
+ "IOEXP9_INT_N","",
+ "RPU_2_READY_SPARE_PLD_R","",
+ "IOEXP7_INT_N","",
+ "IOEXP6_INT_N","",
+ "RPU_READY_PLD_R","",
+ /*C0 - C7*/
+ "wAALC_RPU_READY","",
+ "LEAK0_DETECT","",
+ "LEAK1_DETECT","",
+ "LEAK2_DETECT","",
+ "PRSNT_COMPUTE_TRAY1_N","",
+ "PRSNT_COMPUTE_TRAY2_N","",
+ "PRSNT_COMPUTE_TRAY3_N","",
+ "PRSNT_COMPUTE_TRAY4_N","",
+ /*D0 - D7*/
+ "PRSNT_COMPUTE_TRAY5_N","",
+ "PRSNT_COMPUTE_TRAY6_N","",
+ "PRSNT_COMPUTE_TRAY7_N","",
+ "PRSNT_COMPUTE_TRAY8_N","",
+ "PRSNT_NVS_TRAY1_N","",
+ "PRSNT_NVS_TRAY2_N","",
+ "PRSNT_COMPUTE_TRAY11_N","",
+ "PRSNT_COMPUTE_TRAY12_N","",
+ /*E0 - E7*/
+ "PRSNT_COMPUTE_TRAY13_N","",
+ "PRSNT_COMPUTE_TRAY14_N","",
+ "PRSNT_COMPUTE_TRAY15_N","",
+ "PRSNT_COMPUTE_TRAY16_N","",
+ "PRSNT_COMPUTE_TRAY17_N","",
+ "PRSNT_COMPUTE_TRAY18_N","",
+ "PRSNT_NVS_TRAY3_N","",
+ "PRSNT_NVS_TRAY4_N","",
+ /*F0 - F7*/
+ "PRSNT_NVS_TRAY5_N","",
+ "PRSNT_NVS_TRAY6_N","",
+ "PRSNT_NVS_TRAY7_N","",
+ "PRSNT_NVS_TRAY8_N","",
+ "PRSNT_NVS_TRAY9_N","",
+ "PRSNT_COMPUTE_TRAY9_N","",
+ "PRSNT_COMPUTE_TRAY10_N","",
+ "SMALL_LEAK_COMPUTE_TRAY1_N","",
+ /*G0 - G7*/
+ "SMALL_LEAK_COMPUTE_TRAY2_N","",
+ "SMALL_LEAK_COMPUTE_TRAY3_N","",
+ "SMALL_LEAK_COMPUTE_TRAY4_N","",
+ "SMALL_LEAK_COMPUTE_TRAY5_N","",
+ "SMALL_LEAK_COMPUTE_TRAY6_N","",
+ "SMALL_LEAK_COMPUTE_TRAY7_N","",
+ "SMALL_LEAK_COMPUTE_TRAY8_N","",
+ "SMALL_LEAK_NVS_TRAY1_N","",
+ /*H0 - H7*/
+ "SMALL_LEAK_NVS_TRAY2_N","",
+ "SMALL_LEAK_COMPUTE_TRAY11_N","",
+ "SMALL_LEAK_COMPUTE_TRAY12_N","",
+ "SMALL_LEAK_COMPUTE_TRAY13_N","",
+ "SMALL_LEAK_COMPUTE_TRAY14_N","",
+ "SMALL_LEAK_COMPUTE_TRAY15_N","",
+ "SMALL_LEAK_COMPUTE_TRAY16_N","",
+ "SMALL_LEAK_COMPUTE_TRAY17_N","",
+ /*I0 - I7*/
+ "SMALL_LEAK_COMPUTE_TRAY18_N","",
+ "SMALL_LEAK_NVS_TRAY3_N","",
+ "SMALL_LEAK_NVS_TRAY4_N","",
+ "SMALL_LEAK_NVS_TRAY5_N","",
+ "SMALL_LEAK_NVS_TRAY6_N","",
+ "SMALL_LEAK_NVS_TRAY7_N","",
+ "SMALL_LEAK_NVS_TRAY8_N","",
+ "SMALL_LEAK_NVS_TRAY9_N","",
+ /*J0 - J7*/
+ "SMALL_LEAK_COMPUTE_TRAY9_N","",
+ "SMALL_LEAK_COMPUTE_TRAY10_N","",
+ "PWRGD_COMPUTE_TRAY1_N","",
+ "PWRGD_COMPUTE_TRAY2_N","",
+ "PWRGD_COMPUTE_TRAY3_N","",
+ "PWRGD_COMPUTE_TRAY4_N","",
+ "PWRGD_COMPUTE_TRAY5_N","",
+ "PWRGD_COMPUTE_TRAY6_N","",
+ /*K0 - K7*/
+ "PWRGD_COMPUTE_TRAY7_N","",
+ "PWRGD_COMPUTE_TRAY8_N","",
+ "PWRGD_NVS_TRAY1_PWROK_N","",
+ "PWRGD_NVS_TRAY2_PWROK_N","",
+ "PWRGD_COMPUTE_TRAY11_N","",
+ "PWRGD_COMPUTE_TRAY12_N","",
+ "PWRGD_COMPUTE_TRAY13_N","",
+ "PWRGD_COMPUTE_TRAY14_N","",
+ /*L0 - L7*/
+ "PWRGD_COMPUTE_TRAY15_N","",
+ "PWRGD_COMPUTE_TRAY16_N","",
+ "PWRGD_COMPUTE_TRAY17_N","",
+ "PWRGD_COMPUTE_TRAY18_N","",
+ "PWRGD_NVS_TRAY3_PWROK_N","",
+ "PWRGD_NVS_TRAY4_PWROK_N","",
+ "PWRGD_NVS_TRAY5_PWROK_N","",
+ "PWRGD_NVS_TRAY6_PWROK_N","",
+ /*M0 - M7*/
+ "PWRGD_NVS_TRAY7_PWROK_N","",
+ "PWRGD_NVS_TRAY8_PWROK_N","",
+ "PWRGD_NVS_TRAY9_PWROK_N","",
+ "PWRGD_COMPUTE_TRAY9_N","",
+ "PWRGD_COMPUTE_TRAY10_N","",
+ "LEAK_DETECT_COMPUTE_TRAY1_N","",
+ "LEAK_DETECT_COMPUTE_TRAY2_N","",
+ "LEAK_DETECT_COMPUTE_TRAY3_N","",
+ /*N0 - N7*/
+ "LEAK_DETECT_COMPUTE_TRAY4_N","",
+ "LEAK_DETECT_COMPUTE_TRAY5_N","",
+ "LEAK_DETECT_COMPUTE_TRAY6_N","",
+ "LEAK_DETECT_COMPUTE_TRAY7_N","",
+ "LEAK_DETECT_COMPUTE_TRAY8_N","",
+ "LEAK_DETECT_NVS_TRAY1_N","",
+ "LEAK_DETECT_NVS_TRAY2_N","",
+ "LEAK_DETECT_COMPUTE_TRAY11_N","",
+ /*O0 - O7*/
+ "LEAK_DETECT_COMPUTE_TRAY12_N","",
+ "LEAK_DETECT_COMPUTE_TRAY13_N","",
+ "LEAK_DETECT_COMPUTE_TRAY14_N","",
+ "LEAK_DETECT_COMPUTE_TRAY15_N","",
+ "LEAK_DETECT_COMPUTE_TRAY16_N","",
+ "LEAK_DETECT_COMPUTE_TRAY17_N","",
+ "LEAK_DETECT_COMPUTE_TRAY18_N","",
+ "LEAK_DETECT_NVS_TRAY3_N","",
+ /*P0 - P7*/
+ "LEAK_DETECT_NVS_TRAY4_N","",
+ "LEAK_DETECT_NVS_TRAY5_N","",
+ "LEAK_DETECT_NVS_TRAY6_N","",
+ "LEAK_DETECT_NVS_TRAY7_N","",
+ "LEAK_DETECT_NVS_TRAY8_N","",
+ "LEAK_DETECT_NVS_TRAY9_N","",
+ "LEAK_DETECT_COMPUTE_TRAY9_N","",
+ "LEAK_DETECT_COMPUTE_TRAY10_N","";
+};
+
+&uhci {
+ status = "okay";
+};
+
+&wdt1 {
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_wdtrst1_default>;
+ aspeed,reset-type = "soc";
+ aspeed,external-signal;
+ aspeed,ext-push-pull;
+ aspeed,ext-active-high;
+ aspeed,ext-pulse-duration = <256>;
+};
--
2.43.0
^ permalink raw reply related
* [PATCH v13 1/2] dt-bindings: arm: aspeed: add Meta Ventura board
From: P.K. Lee @ 2026-04-07 8:16 UTC (permalink / raw)
To: robh+dt, krzysztof.kozlowski+dt, conor+dt, joel, andrew,
devicetree, linux-arm-kernel, linux-aspeed, linux-kernel
Cc: Jason-Hsu, p.k.lee
In-Reply-To: <20260407081700.2658011-1-pkleequanta@gmail.com>
Document the new compatibles used on Meta Ventura.
Signed-off-by: P.K. Lee <pkleequanta@gmail.com>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
---
Documentation/devicetree/bindings/arm/aspeed/aspeed.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/arm/aspeed/aspeed.yaml b/Documentation/devicetree/bindings/arm/aspeed/aspeed.yaml
index aedefca7cf4a..afabfe22c8f3 100644
--- a/Documentation/devicetree/bindings/arm/aspeed/aspeed.yaml
+++ b/Documentation/devicetree/bindings/arm/aspeed/aspeed.yaml
@@ -92,6 +92,7 @@ properties:
- facebook,harma-bmc
- facebook,minerva-cmc
- facebook,santabarbara-bmc
+ - facebook,ventura-rmc
- facebook,yosemite4-bmc
- ibm,blueridge-bmc
- ibm,everest-bmc
--
2.43.0
^ permalink raw reply related
* [PATCH v13 0/2] Add Meta (Facebook) Ventura BMC (AST2600)
From: P.K. Lee @ 2026-04-07 8:16 UTC (permalink / raw)
To: robh+dt, krzysztof.kozlowski+dt, conor+dt, joel, andrew,
devicetree, linux-arm-kernel, linux-aspeed, linux-kernel
Cc: Jason-Hsu, p.k.lee
Add Linux device tree entry related to Meta (Facebook) Ventura specific
devices connected to the BMC (AST2600) SoC. The purpose of Ventura is to
detect liquid leakage from all compute trays, switch trays and rack
sensors within the rack, log the events, and take necessary actions
accordingly.
---
v1:
1. Create ventura dts file.
2. Add commit msg.
3. Use format-patch to generate patch.
4. Add subject prefixes matching the subsystem.
---
v2:
1. Modify email content.
---
v3:
1. Add mail list.
---
v4:
1. Apply git send-email --thread option.
2. Sort nodes in the dts alphanumerically.
---
v5:
1. Run scripts/checkpatch.pl and fix reported warnings.
2. Remove unnecessary 88E6393X CONFIG FRU.
---
v6:
1. Add a new stage for the DTS change.
2. Run scripts/checkpatch.pl and fix reported error.
3. Fix the issue in a separate patch.
---
v7:
1. Fix broken indentation in the device tree file.
2. Sort nodes alphabetically, then by address if equal.
3. Rename fan sensor nodes from 'hwmon' to 'fan-controller'.
---
v8:
1. This patch series has significant changes compared to
previous versions, and quite some time has passed since the last
submission.Therefore, previously received Acked-by/Reviewed-by/Tested-by
tags are not included in this version.
If needed, tags can be added again after review of thisnew version.
---
v9:
1. Reordered the node sequence under i2c5.
2. Added a description of the platform's intended use to the commit
messages.
3. Added 3 GPIO expanders to i2c10 and defined the necessary GPIO
line names.
---
v10:
1. Added IRQ support in GPIO expanders under i2c10 to handle edge-triggered
events.
2. Reordered the nodes.
---
v11:
1. Modified the position for i2c3mux0ch6 and i2c3mux0ch7.
---
v12:
1. Added a GPIO expander at address 0x11 on i2c10, and assign an SGPIO pin
as the IRQ for it.
2. Fixed the "failed to match any schema with compatible" issues.
3. Reorder the nodes in alphabetically.
---
v13:
1. Add two GPIO expanders (0x16 and 0x17) to i2c10 and assign two SGPIO
pins as IRQs.
2. Move the RPU_READY_SPARE_PLD_R and RPU_2_READY_PLD_R pins from
SGPIO to the GPIO expander (0x10).
3. Add all tray PWREN pins to the GPIO expanders (0x16, 0x17 and 0x1b).
4. Add explanatory comments for "unmanaged mode" under &mac3 and
"intentionally left empty" under &mdio.
P.K. Lee (2):
dt-bindings: arm: aspeed: add Meta Ventura board
arm: dts: aspeed: ventura: add Meta Ventura BMC
.../bindings/arm/aspeed/aspeed.yaml | 1 +
arch/arm/boot/dts/aspeed/Makefile | 1 +
.../aspeed/aspeed-bmc-facebook-ventura.dts | 1636 +++++++++++++++++
3 files changed, 1638 insertions(+)
create mode 100644 arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-ventura.dts
base-commit: e11fa6b1ff6c27c808d17e479bd7d5582e772062
branch: dev-6.6
--
2.43.0
^ permalink raw reply
* Re: [PATCH 1/2] Revert "arm64: tegra: Disable ISO SMMU for Tegra194"
From: Thierry Reding @ 2026-04-07 8:16 UTC (permalink / raw)
To: Mikko Perttunen
Cc: Aaron Kling, Thierry Reding, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Jonathan Hunter, devicetree, linux-tegra,
linux-kernel
In-Reply-To: <oPjOdaRsQES6O8jgrehMZw@nvidia.com>
[-- Attachment #1: Type: text/plain, Size: 9789 bytes --]
On Tue, Apr 07, 2026 at 01:09:10PM +0900, Mikko Perttunen wrote:
> On Monday, April 6, 2026 4:49 PM Aaron Kling wrote:
> > On Tue, Feb 17, 2026 at 4:13 AM Thierry Reding
> > <thierry.reding@kernel.org> wrote:
> > >
> > > On Tue, Feb 17, 2026 at 12:53:54PM +0900, Mikko Perttunen wrote:
> > > > On Thursday, January 22, 2026 7:22 PM Mikko Perttunen wrote:
> > > > > On Tuesday, December 9, 2025 1:21 PM Aaron Kling wrote:
> > > > > > On Mon, Nov 3, 2025 at 12:05 PM Aaron Kling <webgeek1234@gmail.com> wrote:
> > > > > > >
> > > > > > > On Mon, Nov 3, 2025 at 5:07 AM Thierry Reding <thierry.reding@gmail.com> wrote:
> > > > > > > >
> > > > > > > > On Sat, Nov 01, 2025 at 06:13:26PM -0500, Aaron Kling wrote:
> > > > > > > > > On Sat, Nov 1, 2025 at 6:01 PM Aaron Kling via B4 Relay
> > > > > > > > > <devnull+webgeek1234.gmail.com@kernel.org> wrote:
> > > > > > > > > >
> > > > > > > > > > From: Aaron Kling <webgeek1234@gmail.com>
> > > > > > > > > >
> > > > > > > > > > This reverts commit ebea268ea583ba4970df425dfef8c8e21d0a4e12.
> > > > > > > > > >
> > > > > > > > > > Mmu is now being enabled for the display controllers.
> > > > > > > > > >
> > > > > > > > > > Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
> > > > > > > > > > ---
> > > > > > > > > > arch/arm64/boot/dts/nvidia/tegra194.dtsi | 2 +-
> > > > > > > > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > > > > > > > >
> > > > > > > > > > diff --git a/arch/arm64/boot/dts/nvidia/tegra194.dtsi b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
> > > > > > > > > > index 1399342f23e1c4f73b278adc66dfb948fc30d326..854ed6d46aa1d8eedcdfbae1fdde1374adf40337 100644
> > > > > > > > > > --- a/arch/arm64/boot/dts/nvidia/tegra194.dtsi
> > > > > > > > > > +++ b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
> > > > > > > > > > @@ -1807,7 +1807,7 @@ iommu@10000000 {
> > > > > > > > > > #iommu-cells = <1>;
> > > > > > > > > >
> > > > > > > > > > nvidia,memory-controller = <&mc>;
> > > > > > > > > > - status = "disabled";
> > > > > > > > > > + status = "okay";
> > > > > > > > > > };
> > > > > > > > > >
> > > > > > > > > > smmu: iommu@12000000 {
> > > > > > > > > >
> > > > > > > > > > --
> > > > > > > > > > 2.51.0
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > Question for Jon as the author of the commit being reverted. The
> > > > > > > > > commit message states "we do not have a way to pass frame-buffer
> > > > > > > > > memory from the bootloader to the kernel". If I understand this
> > > > > > > > > correctly, this is talking about seamless handoff. What does this have
> > > > > > > > > to do with enabling mmu on the display controllers? Seamless does not
> > > > > > > > > work on any tegra arch as far as I'm aware, but Tegra194 is the only
> > > > > > > > > one that doesn't have mmu enabled for the dc's. But enabling mmu
> > > > > > > > > allows for better and faster memory allocation. My initial attempts to
> > > > > > > > > enable this didn't work because I tried to attach them to the main mmu
> > > > > > > > > unit, see the related freedesktop issue [0]. After noticing in the
> > > > > > > > > downstream dt that the dc's are on a separate unit, I made it work.
> > > > > > > > > And so far, it seems to work just as well as Tegra186. Then when I was
> > > > > > > > > packaging up the change to submit, I found that this had been
> > > > > > > > > explicitly disabled. But I'm not seeing why. Am I missing some
> > > > > > > > > additional factors?
> > > > > > > >
> > > > > > > > This isn't seamless handoff to the Tegra DRM driver for display, but
> > > > > > > > rather to simple-framebuffer. While this does technically work, it also
> > > > > > > > causes a spew of SMMU faults during early boot because the firmware does
> > > > > > > > not properly pass the SMMU mapping information to the kernel.
> > > > > > > >
> > > > > > > > In a nutshell what happens is that the firmware sets up the display
> > > > > > > > controller to scan out from a reserved memory region, but it does so
> > > > > > > > without involving the SMMU, so it uses physical addresses directly. When
> > > > > > > > the kernel boots and the SMMU is enabled the continued accesses from
> > > > > > > > display hardware cause SMMU faults (because there is no mapping for the
> > > > > > > > framebuffer addresses).
> > > > > > > >
> > > > > > > > That said, we did solve these issues and this may not be happening
> > > > > > > > anymore with the most recent L4T releases, so it may be okay to revert
> > > > > > > > this now. We should find out exactly which release includes all the
> > > > > > > > needed changes so that it can be referenced in the commit message. I
> > > > > > > > want to avoid people running new kernels with an old L4T release and
> > > > > > > > then seeing these errors without any reference as to why that might
> > > > > > > > suddenly happen.
> > > > > > >
> > > > > > > For reference, I have rolled back my Android usecase to use the L4T
> > > > > > > r32.7.6 bootloaders on T194 for a variety of reasons. So I am using
> > > > > > > cboot as the final bootloader and not edk2 as in L4T r34/r35. I have a
> > > > > > > pending cboot patch to support simple-framebuffer handoff, but haven't
> > > > > > > fully verified it as tegra-drm is currently unable to takeover from
> > > > > > > simplefb like openrm does for t234. But all that to say that since I
> > > > > > > no longer use r35 for t194 I don't have the setup to easily verify
> > > > > > > which point release works here and what doesn't.
> > > > > >
> > > > > > Any further thoughts on this patch?
> > > > > >
> > > > > > Aaron
> > > > >
> > > > > FWIW,
> > > > >
> > > > > looks like the edk2 patch to update iommu-addresses --
> > > > >
> > > > > commit 6071946461389221d2314cbbae0377610b5b1f6a
> > > > > Author: Jan Bobek <jbobek@nvidia.com>
> > > > > Date: Tue Mar 21 00:15:27 2023 +0000
> > > > >
> > > > > feat(NvDisplayControllerDxe): update FDT with framebuffer info
> > > > >
> > > > > On ready-to-boot and whenever FDT is installed, update FDT with
> > > > > framebuffer mode information, base address and size.
> > > > >
> > > > > Signed-off-by: Jan Bobek <jbobek@nvidia.com>
> > > > > Reviewed-by: Ashish Singhal <ashishsingha@nvidia.com>
> > > > >
> > > > > is in since r36.2
> > > > >
> > > > > $ git tag --contains 6071946461389221d2314cbbae0377610b5b1f6a | grep "^r"
> > > > > r36.2
> > > > > r36.3.0
> > > > > r36.4.0
> > > > > r36.4.3
> > > > > r36.4.4
> > > > > r36.4.5
> > > > > r38.2
> > > > > r38.4
> > > > >
> > > > > Not so good for T194 since r36 only supports Orin.
> > > > >
> > > > > I'll look into getting this cherry-picked to r35.
> > > > >
> > > > > Mikko
> > > > >
> > > > >
> > > >
> > > > I looked into this and it appears a version of this is in r35, but it
> > > > only supports T234. However, I also found that at one point, L4T
> > > > bootloader configuration has been modified to place the display
> > > > controllers into SMMU bypass until otherwise configured by the kernel
> > > > -- which the kernel does in tegra_mc_probe_device.
> > > >
> > > > I think that means there is still potential for an issue where the
> > > > display continues to be on between tegra_mc_probe_device and tegradrm
> > > > reconfiguring it. However, I cannot reproduce that happening -- most
> > > > likely the display is being turned off before that because of a clock
> > > > or power domain being turned off.
> > > >
> > > > In any case, this means that we no longer need to pass the
> > > > framebuffer's information to the kernel. I think it would be good to
> > > > have some clarity to ensure the issue described above cannot happen,
> > > > but otherwise we should be able to enable IOMMU.
> > >
> > > The problem would happen if you enable some sort of early framebuffer
> > > support, such as simple-drm or simple-framebuffer. Maybe even efifb. I
> > > think it'd still be worth getting the iommu-addresses code into r35 if
> > > for nothing else but to have a bit more of a safety buffer for the
> > > future.
> > >
> > > If we don't and for some reason decide that we want early framebuffer
> > > support, it might be too late to get UEFI updated for Tegra194. I recall
> > > that the UEFI code for Tegra194 is different from the one for Tegra234,
> > > so it is probably not as trivial as a simple cherry-pick, but I'll try
> > > to do some digging and find the code that does this for Xavier.
> >
> > Any updates on this?
>
> FWIW, in my testing with L4T versions with UEFI firmware, I'm not seeing
> any issues even if efifb is enabled. My inclination would be to merge,
> and we can work on issues related to early framebuffer separately.
>
> Outside adding support to r35, one option is to make it so TegraDRM has
> to explicitly call tegra_mc_probe_device (not necessarily directly) when
> it has quiesced the hardware during probe. This would not allow seamless
> early framebuffer transition, but otherwise it should work. Implementing
> this for tegra-smmu would also allow us to get rid of the IOMMU API
> paths in TegraDRM and Host1x, which would be a great boon.
I did most of this work a long time ago and L4T just wasn't ready yet to
make use of all this cleanup potential. We can probably go find most of
the code and it might still be largely applicable.
It's a bit disappointing that this didn't go anywhere for the longest
time and all of a sudden most of it just seems to be irrelevant.
Thierry
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v3 3/4] soc: rockchip: rk3588: add SYS_GRF SOC_CON6 register offset
From: Nicolas Frattaroli @ 2026-04-07 8:10 UTC (permalink / raw)
To: Michael Turquette, Stephen Boyd, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Heiko Stuebner, Daniele Briguglio
Cc: linux-clk, devicetree, linux-arm-kernel, linux-rockchip,
linux-kernel, Daniele Briguglio
In-Reply-To: <20260320-rk3588-mclk-gate-grf-v3-3-980338eacd2c@superkali.me>
On Friday, 20 March 2026 11:34:15 Central European Summer Time Daniele Briguglio wrote:
> Add the RK3588_SYSGRF_SOC_CON6 register offset to the RK3588 GRF
> header. This register contains the I2S MCLK output to IO gate bits,
> needed by the clock driver.
>
> Signed-off-by: Daniele Briguglio <hello@superkali.me>
> ---
> include/soc/rockchip/rk3588_grf.h | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/include/soc/rockchip/rk3588_grf.h b/include/soc/rockchip/rk3588_grf.h
> index 02a7b2432d99..db0092fc66ad 100644
> --- a/include/soc/rockchip/rk3588_grf.h
> +++ b/include/soc/rockchip/rk3588_grf.h
> @@ -19,4 +19,6 @@
> /* Whether the LPDDR5 is in 2:1 (= 0) or 4:1 (= 1) CKR a.k.a. DQS mode */
> #define RK3588_PMUGRF_OS_REG6_LP5_CKR BIT(0)
>
> +#define RK3588_SYSGRF_SOC_CON6 0x0318
> +
> #endif /* __SOC_RK3588_GRF_H */
>
>
Reviewed-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Verified the definition by comparing it to hardware documentation,
it checks out.
^ permalink raw reply
* Re: [PATCH v4 6/6] clk: fsl-sai: Add MCLK generation support
From: Michael Walle @ 2026-04-07 8:02 UTC (permalink / raw)
To: Marek Vasut, linux-clk
Cc: Michael Walle, Brian Masney, Conor Dooley, Krzysztof Kozlowski,
Michael Turquette, Rob Herring, Stephen Boyd, devicetree,
linux-kernel
In-Reply-To: <20260406215150.176599-6-marex@nabladev.com>
[-- Attachment #1: Type: text/plain, Size: 2833 bytes --]
On Mon Apr 6, 2026 at 11:49 PM CEST, Marek Vasut wrote:
> The driver currently supports generating BCLK. There are systems which
> require generation of MCLK instead. Register new MCLK clock and handle
> clock-cells = <1> to differentiate between BCLK and MCLK. In case of a
> legacy system with clock-cells = <0>, the driver behaves as before, i.e.
> always returns BCLK.
>
> Note that it is not possible re-use the current SAI audio driver to
> generate MCLK and correctly enable and disable the MCLK.
>
> If SAI (audio driver) is used to control the MCLK enablement, then MCLK
> clock is not always enabled, and it is not necessarily enabled when the
> codec may need the clock to be enabled. There is also no way for the
> codec node to specify phandle to clock provider in DT, because the SAI
> (audio driver) is not clock provider.
>
> If SAI (clock driver) is used to control the MCLK enablement, then MCLK
> clock is enabled when the codec needs the clock enabled, because the
> codec is the clock consumer and the SAI (clock driver) is the clock
> provider, and the codec driver can request the clock to be enabled when
> needed. There is also the usual phandle to clock provider in DT, because
> the SAI (clock driver) is clock provider.
>
> Acked-by: Michael Walle <mwalle@kernel.org>
> Signed-off-by: Marek Vasut <marex@nabladev.com>
> ---
> Cc: Brian Masney <bmasney@redhat.com>
> Cc: Conor Dooley <conor+dt@kernel.org>
> Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
> Cc: Michael Turquette <mturquette@baylibre.com>
> Cc: Michael Walle <michael@walle.cc>
> Cc: Rob Herring <robh@kernel.org>
> Cc: Stephen Boyd <sboyd@kernel.org>
> Cc: devicetree@vger.kernel.org
> Cc: linux-clk@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> ---
> V2: No change
> V3: - Rebase on current next, update mail address
> - Update commit message according to clarify the difference between
> SAI audio and SAI clock driver
> - Pick ancient AB from Michael, although this may be outdated
> https://patchwork.kernel.org/project/alsa-devel/patch/20241226162234.40141-4-marex@denx.de/
I'm fine with this, but I want to point out, that this is still a
hack as the correct way would be to make the original SAI (audio
driver) a clock provider. Keep in mind that both driver variants are
mutually exclusive. So if a SoC has 6 SAIs for example, you can only
use 5, because the one will have to be MCLK the clock provider
driver.
In the original LS1028A case (which doesn't have a MCLK), you
actually have to use the hardware peripheral block to generate the
BCLK, thus you'll loose one SAI anyway. In this case - at least from
what I understands - this is just a software construct, because the
original SAI driver is missing a clock provider (phandle).
-michael
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 297 bytes --]
^ permalink raw reply
* Re: [PATCH 3/3] arm64: dts: qcom: milos: Add Iris VPU v2.0
From: Krzysztof Kozlowski @ 2026-04-07 8:05 UTC (permalink / raw)
To: Alexander Koskovich
Cc: Vikash Garodia, Dikshita Agarwal, Abhinav Kumar,
Bryan O'Donoghue, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson, Konrad Dybcio,
Luca Weiss, linux-media, linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <20260406-milos-iris-v1-3-17ed0167ba6f@pm.me>
On Mon, Apr 06, 2026 at 10:19:50AM +0000, Alexander Koskovich wrote:
> Add devicetree nodes for the Iris codec (VPU 2.0) found on the Milos
> platform.
>
> Signed-off-by: Alexander Koskovich <akoskovich@pm.me>
> ---
> arch/arm64/boot/dts/qcom/milos.dtsi | 85 +++++++++++++++++++++++++++++++++++++
> 1 file changed, 85 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/milos.dtsi b/arch/arm64/boot/dts/qcom/milos.dtsi
> index e1a51d43943f..07aa398c9695 100644
> --- a/arch/arm64/boot/dts/qcom/milos.dtsi
> +++ b/arch/arm64/boot/dts/qcom/milos.dtsi
> @@ -7,6 +7,7 @@
> #include <dt-bindings/clock/qcom,milos-dispcc.h>
> #include <dt-bindings/clock/qcom,milos-gcc.h>
> #include <dt-bindings/clock/qcom,milos-gpucc.h>
> +#include <dt-bindings/clock/qcom,milos-videocc.h>
> #include <dt-bindings/clock/qcom,rpmh.h>
> #include <dt-bindings/clock/qcom,sm8650-tcsr.h>
> #include <dt-bindings/dma/qcom-gpi.h>
> @@ -1517,6 +1518,90 @@ usb_1_dwc3_hs: endpoint {
> };
> };
>
> + iris: video-codec@aa00000 {
> + compatible = "qcom,milos-iris";
> + reg = <0 0x0aa00000 0 0xf0000>;
Hex, please.
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 1/3] dt-bindings: media: qcom,milos-iris: Add Milos video codec
From: Krzysztof Kozlowski @ 2026-04-07 8:04 UTC (permalink / raw)
To: Alexander Koskovich
Cc: Vikash Garodia, Dikshita Agarwal, Abhinav Kumar,
Bryan O'Donoghue, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson, Konrad Dybcio,
Luca Weiss, linux-media, linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <20260406-milos-iris-v1-1-17ed0167ba6f@pm.me>
On Mon, Apr 06, 2026 at 10:19:34AM +0000, Alexander Koskovich wrote:
> Add binding for Qualcomm Milos Iris video codec.
>
> Signed-off-by: Alexander Koskovich <akoskovich@pm.me>
> ---
> .../devicetree/bindings/media/qcom,milos-iris.yaml | 166 +++++++++++++++++++++
> 1 file changed, 166 insertions(+)
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH] dt-bindings: display: bridge: lt9211: Require data-lanes on DSI input ports
From: Krzysztof Kozlowski @ 2026-04-07 8:00 UTC (permalink / raw)
To: Marek Vasut
Cc: devicetree, Andrzej Hajda, Conor Dooley, David Airlie,
Jernej Skrabec, Jonas Karlman, Krzysztof Kozlowski,
Laurent Pinchart, Maarten Lankhorst, Maxime Ripard,
Neil Armstrong, Rob Herring, Robert Foss, Simona Vetter,
Thomas Zimmermann, dri-devel, linux-kernel
In-Reply-To: <20260404034123.340818-1-marex@nabladev.com>
On Sat, Apr 04, 2026 at 05:40:18AM +0200, Marek Vasut wrote:
> The Lontium LT9211 is capable of 1..4 DSI lanes per input DSI port,
> describe the lane count for each input port in the schema.
Ah, and subject does not really match what you did in the patch. It will
match when you fix the patch, though...
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH] dt-bindings: display: bridge: lt9211: Require data-lanes on DSI input ports
From: Krzysztof Kozlowski @ 2026-04-07 8:00 UTC (permalink / raw)
To: Marek Vasut
Cc: devicetree, Andrzej Hajda, Conor Dooley, David Airlie,
Jernej Skrabec, Jonas Karlman, Krzysztof Kozlowski,
Laurent Pinchart, Maarten Lankhorst, Maxime Ripard,
Neil Armstrong, Rob Herring, Robert Foss, Simona Vetter,
Thomas Zimmermann, dri-devel, linux-kernel
In-Reply-To: <20260404034123.340818-1-marex@nabladev.com>
On Sat, Apr 04, 2026 at 05:40:18AM +0200, Marek Vasut wrote:
> The Lontium LT9211 is capable of 1..4 DSI lanes per input DSI port,
> describe the lane count for each input port in the schema.
>
> Signed-off-by: Marek Vasut <marex@nabladev.com>
> ---
> Cc: Andrzej Hajda <andrzej.hajda@intel.com>
> Cc: Conor Dooley <conor+dt@kernel.org>
> Cc: David Airlie <airlied@gmail.com>
> Cc: Jernej Skrabec <jernej.skrabec@gmail.com>
> Cc: Jonas Karlman <jonas@kwiboo.se>
> Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
> Cc: Laurent Pinchart <Laurent.pinchart@ideasonboard.com>
> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> Cc: Maxime Ripard <mripard@kernel.org>
> Cc: Neil Armstrong <neil.armstrong@linaro.org>
> Cc: Rob Herring <robh@kernel.org>
> Cc: Robert Foss <rfoss@kernel.org>
> Cc: Simona Vetter <simona@ffwll.ch>
> Cc: Thomas Zimmermann <tzimmermann@suse.de>
> Cc: devicetree@vger.kernel.org
> Cc: dri-devel@lists.freedesktop.org
> Cc: linux-kernel@vger.kernel.org
> ---
> NOTE: For example Linux kernel driver does already use that information
> and fails to probe if it is missing. There are currently no intree
The first sentence must be part of the commit msg. That is important
reason why you are doing this... but I don't see how you achieve any of
this. Look:
> users for this binding, so no new warnings will be generated once
> this is applied, but a new user is about to be added.
What warnings? How?
> ---
> .../display/bridge/lontium,lt9211.yaml | 37 ++++++++++++++++++-
> 1 file changed, 35 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/display/bridge/lontium,lt9211.yaml b/Documentation/devicetree/bindings/display/bridge/lontium,lt9211.yaml
> index 9a6e9b25d14a9..5264fb2b68b78 100644
> --- a/Documentation/devicetree/bindings/display/bridge/lontium,lt9211.yaml
> +++ b/Documentation/devicetree/bindings/display/bridge/lontium,lt9211.yaml
> @@ -36,18 +36,50 @@ properties:
>
> properties:
> port@0:
> - $ref: /schemas/graph.yaml#/properties/port
> + $ref: /schemas/graph.yaml#/$defs/port-base
OK, that's correct.
> + unevaluatedProperties: false
> description:
> Primary MIPI DSI port-1 for MIPI input or
> LVDS port-1 for LVDS input or DPI input.
>
> + properties:
> + endpoint:
> + $ref: /schemas/media/video-interfaces.yaml#
> + unevaluatedProperties: false
That's correct.
> +
> + properties:
> + data-lanes:
> + description: array of physical DSI data lane indexes.
> + minItems: 1
> + items:
> + - const: 1
> + - const: 2
> + - const: 3
> + - const: 4
That's almost redundant in this context - it was already there - and the
point is that it solves noting in the problem you had. Binding still
does not validate the ABI and does not match it, still.
Since commit foo bar, driver needs data-lanes, so what you need to do is
allow them and to require them. You can also specify their constraints
if device can be configured multiple ways, up to 4 lanes.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 3/4] dt-bindings: PCI: Add UltraRISC DP1000 PCIe controller
From: Krzysztof Kozlowski @ 2026-04-07 7:50 UTC (permalink / raw)
To: Jia Wang
Cc: Paul Walmsley, Palmer Dabbelt, Albert Ou, Alexandre Ghiti,
Lorenzo Pieralisi, Krzysztof Wilczyński,
Manivannan Sadhasivam, Rob Herring, Bjorn Helgaas, Jingoo Han,
Xincheng Zhang, Krzysztof Kozlowski, Conor Dooley, linux-riscv,
linux-kernel, linux-pci, devicetree
In-Reply-To: <20260407-ultrarisc-pcie-v2-3-2aa2a19a7fb3@ultrarisc.com>
On Tue, Apr 07, 2026 at 10:40:54AM +0800, Jia Wang wrote:
> Add UltraRISC DP1000 SoC PCIe controller devicetree bindings.
>
> Signed-off-by: Jia Wang <wangjia@ultrarisc.com>
> ---
> .../bindings/pci/ultrarisc,dp1000-pcie.yaml | 103 +++++++++++++++++++++
> 1 file changed, 103 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/pci/ultrarisc,dp1000-pcie.yaml b/Documentation/devicetree/bindings/pci/ultrarisc,dp1000-pcie.yaml
> new file mode 100644
> index 000000000000..d0517130e127
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/pci/ultrarisc,dp1000-pcie.yaml
> @@ -0,0 +1,103 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/pci/ultrarisc,dp1000-pcie.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: UltraRISC DP1000 PCIe Host Controller
> +
> +description: |
Do not need '|' unless you need to preserve formatting.
> + UltraRISC DP1000 SoC PCIe host controller is based on the DesignWare PCIe IP.
> + This binding describes the UltraRISC specific extensions to the base
> + DesignWare PCIe binding.
Drop sentence. Do not describe in description what the binding
describes. It's circular / repetitive. Just describe that.
> +
> +maintainers:
> + - Xincheng Zhang <zhangxincheng@ultrarisc.com>
> + - Jia Wang <wangjia@ultrarisc.com>
> +
> +allOf:
> + - $ref: /schemas/pci/snps,dw-pcie.yaml#
> +
> +properties:
> + compatible:
> + const: ultrarisc,dp1000-pcie
> +
> + reg:
> + items:
> + - description: Data Bus Interface (DBI) registers.
> + - description: PCIe configuration space region.
> +
> + reg-names:
> + items:
> + - const: dbi
> + - const: config
> +
> + num-lanes:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + enum: [4, 16]
> + description: Number of lanes to use.
> +
> + max-link-speed:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + const: 4
If const then deducible from the compatible. Drop the property.
> + description: Maximum PCIe link speed supported.
> +
> + interrupts:
> + description: List of interrupt specifiers used by the controller
Drop description. Obvious.
> + items:
> + - description: MSI interrupt
> + - description: Legacy INTA interrupt
> + - description: Legacy INTB interrupt
> + - description: Legacy INTC interrupt
> + - description: Legacy INTD interrupt
> +
> + interrupt-names:
> + items:
> + - const: msi
> + - const: inta
> + - const: intb
> + - const: intc
> + - const: intd
> +
> +required:
> + - compatible
> + - reg
> + - reg-names
> + - interrupts
> + - interrupt-names
> +
> +unevaluatedProperties: false
> +
> +examples:
> + - |
> + soc {
> + #address-cells = <2>;
> + #size-cells = <2>;
> +
> + pcie_x16: pcie@21000000 {
Drop unused label
> + compatible = "ultrarisc,dp1000-pcie";
reg, names and ranges go here. Please follow DTS coding style.
> + #address-cells = <3>;
> + #size-cells = <2>;
> + #interrupt-cells = <1>;
> + reg = <0x0 0x21000000 0x0 0x01000000>,
> + <0x0 0x4fff0000 0x0 0x00010000>;
> + reg-names = "dbi", "config";
> + device_type = "pci";
> + dma-coherent;
> + bus-range = <0x0 0xff>;
> + num-lanes = <16>;
> + ranges = <0x81000000 0x0 0x4fbf0000 0x0 0x4fbf0000 0x0 0x00400000>,
> + <0x82000000 0x0 0x40000000 0x0 0x40000000 0x0 0x0fbf0000>,
> + <0xc3000000 0x40 0x00000000 0x40 0x00000000 0xd 0x00000000>;
> +
> + max-link-speed = <4>;
Drop, compatible defines this.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 2/4] MAINTAINERS: Add entry for the UltraRISC DP1000 PCIe controller driver and its DT binding
From: Krzysztof Kozlowski @ 2026-04-07 7:44 UTC (permalink / raw)
To: Jia Wang
Cc: Paul Walmsley, Palmer Dabbelt, Albert Ou, Alexandre Ghiti,
Lorenzo Pieralisi, Krzysztof Wilczyński,
Manivannan Sadhasivam, Rob Herring, Bjorn Helgaas, Jingoo Han,
Xincheng Zhang, Krzysztof Kozlowski, Conor Dooley, linux-riscv,
linux-kernel, linux-pci, devicetree
In-Reply-To: <20260407-ultrarisc-pcie-v2-2-2aa2a19a7fb3@ultrarisc.com>
On Tue, Apr 07, 2026 at 10:40:53AM +0800, Jia Wang wrote:
> Add a MAINTAINERS entry for the UltraRISC DP1000 PCIe host driver and its
> DT binding.
>
> Signed-off-by: Jia Wang <wangjia@ultrarisc.com>
> ---
> MAINTAINERS | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index c3fe46d7c4bc..c8159670a14d 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -20582,6 +20582,14 @@ S: Maintained
> F: Documentation/devicetree/bindings/pci/starfive,jh7110-pcie.yaml
> F: drivers/pci/controller/plda/pcie-starfive.c
>
> +PCIE DRIVER FOR ULTRARISC DP1000
> +M: Xincheng Zhang <zhangxincheng@ultrarisc.com>
> +M: Jia Wang <wangjia@ultrarisc.com>
> +L: linux-pci@vger.kernel.org
> +S: Maintained
> +F: Documentation/devicetree/bindings/pci/ultrarisc,dp1000-pcie.yaml
There is no such file.
This is not supposed to be a separate commit.
> +F: drivers/pci/controller/dwc/pcie-ultrarisc.c
No such file.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 1/2] dt-bindings: interconnect: document the RPMh Network-On-Chip interconnect in Hawi SoC
From: Krzysztof Kozlowski @ 2026-04-07 7:42 UTC (permalink / raw)
To: Vivek Aknurwar
Cc: Georgi Djakov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
linux-arm-msm, linux-pm, devicetree, linux-kernel, Mike Tipton
In-Reply-To: <20260406-icc-hawi-v2-1-6cfee87a1d25@oss.qualcomm.com>
On Mon, Apr 06, 2026 at 04:04:41PM -0700, Vivek Aknurwar wrote:
> Document the RPMh Network-On-Chip Interconnect of the Hawi platform.
>
> Signed-off-by: Vivek Aknurwar <vivek.aknurwar@oss.qualcomm.com>
Same fixes needed I wrote to Hawi upstreaming lead in private. That's
why I gave that feedback (privately) very fast, to avoid repeating the
mistake. So since private feedback was ignored, you have now review on
the lists.
All Qualcomm previous patches are poor:
document the RPMh Network-On-Chip interconnect in Mahua SoC
document the RPMh Network-On-Chip interconnect in Eliza SoC
document the RPMh Network-On-Chip interconnect in Kaanapali SoC
document the RPMh Network-On-Chip interconnect in Glymur SoC
Made by the same people.
Why can't you look how Neil did it for SM8650? Or Luca recently for
Milos? Or if you cannot look at non-qcom commits then Rajendra for X1E?
Best regards,
Krzysztof
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox