[PATCH v2 0/3] rockchip: rk35xx: Fix writing to eMMC
Testing has shown that writing to eMMC using DDR52 mode does not seem to work on RK356x and RK3588 boards.
This series fixes this issue by changing RK356x and RK3588 boards to prefer use of the more reliably HS200 mode.
Changes in v2: - Update commit messages - Imply MMC_HS200_SUPPORT and SPL_MMC_HS200_SUPPORT in arch Kconfig instead of adding to each boards defconfig - Combine changes for rk356x and rk3588 in one patch - New patch to fix HS400 mode write on RK3568
Link to v1: https://patchwork.ozlabs.org/cover/1891692/
This series depend on the series "rockchip: rk35xx: Sync device tree with linux v6.8-rc1" [1].
[1] https://patchwork.ozlabs.org/cover/1891669/
Jonas Karlman (3): rockchip: rk35xx: Remove use of eMMC DDR52 mode rockchip: rk35xx: Enable eMMC HS200 mode by default rockchip: sdhci: Fix eMMC HS400 modes for RK3568
arch/arm/dts/rk3566-quartz64-a-u-boot.dtsi | 1 - arch/arm/dts/rk3566-quartz64-b-u-boot.dtsi | 1 - arch/arm/dts/rk3566-radxa-cm3-io-u-boot.dtsi | 1 - arch/arm/dts/rk3566-soquartz-u-boot.dtsi | 1 - arch/arm/dts/rk3568-lubancat-2-u-boot.dtsi | 1 - arch/arm/dts/rk3568-nanopi-r5s-u-boot.dtsi | 1 - arch/arm/dts/rk3568-odroid-m1-u-boot.dtsi | 1 - arch/arm/dts/rk3568-radxa-e25-u-boot.dtsi | 1 - arch/arm/dts/rk3568-rock-3a-u-boot.dtsi | 1 - arch/arm/dts/rk3588-rock-5b-u-boot.dtsi | 1 - arch/arm/dts/rk3588-turing-rk1-u-boot.dtsi | 1 - arch/arm/dts/rk3588s-rock-5a-u-boot.dtsi | 1 - arch/arm/mach-rockchip/Kconfig | 4 ++++ configs/nanopi-r5c-rk3568_defconfig | 2 -- configs/nanopi-r5s-rk3568_defconfig | 2 -- configs/radxa-e25-rk3568_defconfig | 2 -- drivers/mmc/rockchip_sdhci.c | 9 +++++---- 17 files changed, 9 insertions(+), 22 deletions(-)
Testing has shown that writing to eMMC using DDR52 mode does not seem to work on RK356x and RK3588 boards.
A simple test of writing a single block to e.g. sector 0x4000 fails:
# Rescan using DDR52 mode => mmc rescan 4
# Write a single block to sector 0x4000 fails with ERROR => mmc write 20000000 4000 1
With the MMC_SPEED_MODE_SET Kconfig option enabled.
Fix this by removing the mmc-ddr-1_8v prop from sdhci nodes in affected board u-boot.dtsi files.
Signed-off-by: Jonas Karlman jonas@kwiboo.se --- Changes in v2: - Update commit message
Link to v1: https://patchwork.ozlabs.org/patch/1891695/ --- arch/arm/dts/rk3566-quartz64-a-u-boot.dtsi | 1 - arch/arm/dts/rk3566-quartz64-b-u-boot.dtsi | 1 - arch/arm/dts/rk3566-radxa-cm3-io-u-boot.dtsi | 1 - arch/arm/dts/rk3566-soquartz-u-boot.dtsi | 1 - arch/arm/dts/rk3568-lubancat-2-u-boot.dtsi | 1 - arch/arm/dts/rk3568-nanopi-r5s-u-boot.dtsi | 1 - arch/arm/dts/rk3568-odroid-m1-u-boot.dtsi | 1 - arch/arm/dts/rk3568-radxa-e25-u-boot.dtsi | 1 - arch/arm/dts/rk3568-rock-3a-u-boot.dtsi | 1 - arch/arm/dts/rk3588-rock-5b-u-boot.dtsi | 1 - arch/arm/dts/rk3588-turing-rk1-u-boot.dtsi | 1 - arch/arm/dts/rk3588s-rock-5a-u-boot.dtsi | 1 - 12 files changed, 12 deletions(-)
diff --git a/arch/arm/dts/rk3566-quartz64-a-u-boot.dtsi b/arch/arm/dts/rk3566-quartz64-a-u-boot.dtsi index 11976fd3a6e0..930d660868bb 100644 --- a/arch/arm/dts/rk3566-quartz64-a-u-boot.dtsi +++ b/arch/arm/dts/rk3566-quartz64-a-u-boot.dtsi @@ -8,7 +8,6 @@
&sdhci { cap-mmc-highspeed; - mmc-ddr-1_8v; pinctrl-names = "default"; pinctrl-0 = <&emmc_bus8 &emmc_clk &emmc_cmd &emmc_datastrobe>; }; diff --git a/arch/arm/dts/rk3566-quartz64-b-u-boot.dtsi b/arch/arm/dts/rk3566-quartz64-b-u-boot.dtsi index 8de9d1535efb..c235b4357f7d 100644 --- a/arch/arm/dts/rk3566-quartz64-b-u-boot.dtsi +++ b/arch/arm/dts/rk3566-quartz64-b-u-boot.dtsi @@ -4,7 +4,6 @@
&sdhci { cap-mmc-highspeed; - mmc-ddr-1_8v; pinctrl-names = "default"; pinctrl-0 = <&emmc_bus8 &emmc_clk &emmc_cmd &emmc_datastrobe>; }; diff --git a/arch/arm/dts/rk3566-radxa-cm3-io-u-boot.dtsi b/arch/arm/dts/rk3566-radxa-cm3-io-u-boot.dtsi index 158f652cb3b1..e0e501deccfe 100644 --- a/arch/arm/dts/rk3566-radxa-cm3-io-u-boot.dtsi +++ b/arch/arm/dts/rk3566-radxa-cm3-io-u-boot.dtsi @@ -7,5 +7,4 @@
&sdhci { cap-mmc-highspeed; - mmc-ddr-1_8v; }; diff --git a/arch/arm/dts/rk3566-soquartz-u-boot.dtsi b/arch/arm/dts/rk3566-soquartz-u-boot.dtsi index f65f4067f3e9..5e46a2422d60 100644 --- a/arch/arm/dts/rk3566-soquartz-u-boot.dtsi +++ b/arch/arm/dts/rk3566-soquartz-u-boot.dtsi @@ -4,7 +4,6 @@
&sdhci { cap-mmc-highspeed; - mmc-ddr-1_8v; pinctrl-names = "default"; pinctrl-0 = <&emmc_bus8 &emmc_clk &emmc_cmd &emmc_datastrobe>; }; diff --git a/arch/arm/dts/rk3568-lubancat-2-u-boot.dtsi b/arch/arm/dts/rk3568-lubancat-2-u-boot.dtsi index a44ac35bdacd..1597473017ed 100644 --- a/arch/arm/dts/rk3568-lubancat-2-u-boot.dtsi +++ b/arch/arm/dts/rk3568-lubancat-2-u-boot.dtsi @@ -8,7 +8,6 @@
&sdhci { cap-mmc-highspeed; - mmc-ddr-1_8v; mmc-hs400-1_8v; mmc-hs400-enhanced-strobe; pinctrl-0 = <&emmc_bus8 &emmc_clk &emmc_cmd &emmc_datastrobe>; diff --git a/arch/arm/dts/rk3568-nanopi-r5s-u-boot.dtsi b/arch/arm/dts/rk3568-nanopi-r5s-u-boot.dtsi index 62f572c4cf9f..64c43374c042 100644 --- a/arch/arm/dts/rk3568-nanopi-r5s-u-boot.dtsi +++ b/arch/arm/dts/rk3568-nanopi-r5s-u-boot.dtsi @@ -14,7 +14,6 @@
&sdhci { cap-mmc-highspeed; - mmc-ddr-1_8v; mmc-hs200-1_8v; mmc-hs400-1_8v; mmc-hs400-enhanced-strobe; diff --git a/arch/arm/dts/rk3568-odroid-m1-u-boot.dtsi b/arch/arm/dts/rk3568-odroid-m1-u-boot.dtsi index ecba91aa30f5..1fc71faa9e07 100644 --- a/arch/arm/dts/rk3568-odroid-m1-u-boot.dtsi +++ b/arch/arm/dts/rk3568-odroid-m1-u-boot.dtsi @@ -8,7 +8,6 @@
&sdhci { cap-mmc-highspeed; - mmc-ddr-1_8v; mmc-hs200-1_8v; mmc-hs400-1_8v; mmc-hs400-enhanced-strobe; diff --git a/arch/arm/dts/rk3568-radxa-e25-u-boot.dtsi b/arch/arm/dts/rk3568-radxa-e25-u-boot.dtsi index caf524443079..74755a44eaee 100644 --- a/arch/arm/dts/rk3568-radxa-e25-u-boot.dtsi +++ b/arch/arm/dts/rk3568-radxa-e25-u-boot.dtsi @@ -16,7 +16,6 @@
&sdhci { cap-mmc-highspeed; - mmc-ddr-1_8v; mmc-hs200-1_8v; mmc-hs400-1_8v; mmc-hs400-enhanced-strobe; diff --git a/arch/arm/dts/rk3568-rock-3a-u-boot.dtsi b/arch/arm/dts/rk3568-rock-3a-u-boot.dtsi index 46ebb77283f1..5b823fcca5fb 100644 --- a/arch/arm/dts/rk3568-rock-3a-u-boot.dtsi +++ b/arch/arm/dts/rk3568-rock-3a-u-boot.dtsi @@ -20,7 +20,6 @@
&sdhci { cap-mmc-highspeed; - mmc-ddr-1_8v; mmc-hs200-1_8v; mmc-hs400-1_8v; mmc-hs400-enhanced-strobe; diff --git a/arch/arm/dts/rk3588-rock-5b-u-boot.dtsi b/arch/arm/dts/rk3588-rock-5b-u-boot.dtsi index e99e60185ebe..9ee9dd051e32 100644 --- a/arch/arm/dts/rk3588-rock-5b-u-boot.dtsi +++ b/arch/arm/dts/rk3588-rock-5b-u-boot.dtsi @@ -31,7 +31,6 @@
&sdhci { cap-mmc-highspeed; - mmc-ddr-1_8v; mmc-hs200-1_8v; };
diff --git a/arch/arm/dts/rk3588-turing-rk1-u-boot.dtsi b/arch/arm/dts/rk3588-turing-rk1-u-boot.dtsi index 471508a9ed74..ca2a684f3541 100644 --- a/arch/arm/dts/rk3588-turing-rk1-u-boot.dtsi +++ b/arch/arm/dts/rk3588-turing-rk1-u-boot.dtsi @@ -8,7 +8,6 @@
&sdhci { cap-mmc-highspeed; - mmc-ddr-1_8v; mmc-hs200-1_8v; };
diff --git a/arch/arm/dts/rk3588s-rock-5a-u-boot.dtsi b/arch/arm/dts/rk3588s-rock-5a-u-boot.dtsi index 9a6a353088df..efba0c359ba5 100644 --- a/arch/arm/dts/rk3588s-rock-5a-u-boot.dtsi +++ b/arch/arm/dts/rk3588s-rock-5a-u-boot.dtsi @@ -7,6 +7,5 @@
&sdhci { cap-mmc-highspeed; - mmc-ddr-1_8v; mmc-hs200-1_8v; };
On 2024/2/5 04:53, Jonas Karlman wrote:
Testing has shown that writing to eMMC using DDR52 mode does not seem to work on RK356x and RK3588 boards.
A simple test of writing a single block to e.g. sector 0x4000 fails:
# Rescan using DDR52 mode => mmc rescan 4
# Write a single block to sector 0x4000 fails with ERROR => mmc write 20000000 4000 1
With the MMC_SPEED_MODE_SET Kconfig option enabled.
Fix this by removing the mmc-ddr-1_8v prop from sdhci nodes in affected board u-boot.dtsi files.
Signed-off-by: Jonas Karlman jonas@kwiboo.se
Reviewed-by: Kever Yang kever.yang@rock-chips.com
Thanks, - Kever
Changes in v2:
- Update commit message
Link to v1: https://patchwork.ozlabs.org/patch/1891695/
arch/arm/dts/rk3566-quartz64-a-u-boot.dtsi | 1 - arch/arm/dts/rk3566-quartz64-b-u-boot.dtsi | 1 - arch/arm/dts/rk3566-radxa-cm3-io-u-boot.dtsi | 1 - arch/arm/dts/rk3566-soquartz-u-boot.dtsi | 1 - arch/arm/dts/rk3568-lubancat-2-u-boot.dtsi | 1 - arch/arm/dts/rk3568-nanopi-r5s-u-boot.dtsi | 1 - arch/arm/dts/rk3568-odroid-m1-u-boot.dtsi | 1 - arch/arm/dts/rk3568-radxa-e25-u-boot.dtsi | 1 - arch/arm/dts/rk3568-rock-3a-u-boot.dtsi | 1 - arch/arm/dts/rk3588-rock-5b-u-boot.dtsi | 1 - arch/arm/dts/rk3588-turing-rk1-u-boot.dtsi | 1 - arch/arm/dts/rk3588s-rock-5a-u-boot.dtsi | 1 - 12 files changed, 12 deletions(-)
diff --git a/arch/arm/dts/rk3566-quartz64-a-u-boot.dtsi b/arch/arm/dts/rk3566-quartz64-a-u-boot.dtsi index 11976fd3a6e0..930d660868bb 100644 --- a/arch/arm/dts/rk3566-quartz64-a-u-boot.dtsi +++ b/arch/arm/dts/rk3566-quartz64-a-u-boot.dtsi @@ -8,7 +8,6 @@
&sdhci { cap-mmc-highspeed;
- mmc-ddr-1_8v; pinctrl-names = "default"; pinctrl-0 = <&emmc_bus8 &emmc_clk &emmc_cmd &emmc_datastrobe>; };
diff --git a/arch/arm/dts/rk3566-quartz64-b-u-boot.dtsi b/arch/arm/dts/rk3566-quartz64-b-u-boot.dtsi index 8de9d1535efb..c235b4357f7d 100644 --- a/arch/arm/dts/rk3566-quartz64-b-u-boot.dtsi +++ b/arch/arm/dts/rk3566-quartz64-b-u-boot.dtsi @@ -4,7 +4,6 @@
&sdhci { cap-mmc-highspeed;
- mmc-ddr-1_8v; pinctrl-names = "default"; pinctrl-0 = <&emmc_bus8 &emmc_clk &emmc_cmd &emmc_datastrobe>; };
diff --git a/arch/arm/dts/rk3566-radxa-cm3-io-u-boot.dtsi b/arch/arm/dts/rk3566-radxa-cm3-io-u-boot.dtsi index 158f652cb3b1..e0e501deccfe 100644 --- a/arch/arm/dts/rk3566-radxa-cm3-io-u-boot.dtsi +++ b/arch/arm/dts/rk3566-radxa-cm3-io-u-boot.dtsi @@ -7,5 +7,4 @@
&sdhci { cap-mmc-highspeed;
- mmc-ddr-1_8v; };
diff --git a/arch/arm/dts/rk3566-soquartz-u-boot.dtsi b/arch/arm/dts/rk3566-soquartz-u-boot.dtsi index f65f4067f3e9..5e46a2422d60 100644 --- a/arch/arm/dts/rk3566-soquartz-u-boot.dtsi +++ b/arch/arm/dts/rk3566-soquartz-u-boot.dtsi @@ -4,7 +4,6 @@
&sdhci { cap-mmc-highspeed;
- mmc-ddr-1_8v; pinctrl-names = "default"; pinctrl-0 = <&emmc_bus8 &emmc_clk &emmc_cmd &emmc_datastrobe>; };
diff --git a/arch/arm/dts/rk3568-lubancat-2-u-boot.dtsi b/arch/arm/dts/rk3568-lubancat-2-u-boot.dtsi index a44ac35bdacd..1597473017ed 100644 --- a/arch/arm/dts/rk3568-lubancat-2-u-boot.dtsi +++ b/arch/arm/dts/rk3568-lubancat-2-u-boot.dtsi @@ -8,7 +8,6 @@
&sdhci { cap-mmc-highspeed;
- mmc-ddr-1_8v; mmc-hs400-1_8v; mmc-hs400-enhanced-strobe; pinctrl-0 = <&emmc_bus8 &emmc_clk &emmc_cmd &emmc_datastrobe>;
diff --git a/arch/arm/dts/rk3568-nanopi-r5s-u-boot.dtsi b/arch/arm/dts/rk3568-nanopi-r5s-u-boot.dtsi index 62f572c4cf9f..64c43374c042 100644 --- a/arch/arm/dts/rk3568-nanopi-r5s-u-boot.dtsi +++ b/arch/arm/dts/rk3568-nanopi-r5s-u-boot.dtsi @@ -14,7 +14,6 @@
&sdhci { cap-mmc-highspeed;
- mmc-ddr-1_8v; mmc-hs200-1_8v; mmc-hs400-1_8v; mmc-hs400-enhanced-strobe;
diff --git a/arch/arm/dts/rk3568-odroid-m1-u-boot.dtsi b/arch/arm/dts/rk3568-odroid-m1-u-boot.dtsi index ecba91aa30f5..1fc71faa9e07 100644 --- a/arch/arm/dts/rk3568-odroid-m1-u-boot.dtsi +++ b/arch/arm/dts/rk3568-odroid-m1-u-boot.dtsi @@ -8,7 +8,6 @@
&sdhci { cap-mmc-highspeed;
- mmc-ddr-1_8v; mmc-hs200-1_8v; mmc-hs400-1_8v; mmc-hs400-enhanced-strobe;
diff --git a/arch/arm/dts/rk3568-radxa-e25-u-boot.dtsi b/arch/arm/dts/rk3568-radxa-e25-u-boot.dtsi index caf524443079..74755a44eaee 100644 --- a/arch/arm/dts/rk3568-radxa-e25-u-boot.dtsi +++ b/arch/arm/dts/rk3568-radxa-e25-u-boot.dtsi @@ -16,7 +16,6 @@
&sdhci { cap-mmc-highspeed;
- mmc-ddr-1_8v; mmc-hs200-1_8v; mmc-hs400-1_8v; mmc-hs400-enhanced-strobe;
diff --git a/arch/arm/dts/rk3568-rock-3a-u-boot.dtsi b/arch/arm/dts/rk3568-rock-3a-u-boot.dtsi index 46ebb77283f1..5b823fcca5fb 100644 --- a/arch/arm/dts/rk3568-rock-3a-u-boot.dtsi +++ b/arch/arm/dts/rk3568-rock-3a-u-boot.dtsi @@ -20,7 +20,6 @@
&sdhci { cap-mmc-highspeed;
- mmc-ddr-1_8v; mmc-hs200-1_8v; mmc-hs400-1_8v; mmc-hs400-enhanced-strobe;
diff --git a/arch/arm/dts/rk3588-rock-5b-u-boot.dtsi b/arch/arm/dts/rk3588-rock-5b-u-boot.dtsi index e99e60185ebe..9ee9dd051e32 100644 --- a/arch/arm/dts/rk3588-rock-5b-u-boot.dtsi +++ b/arch/arm/dts/rk3588-rock-5b-u-boot.dtsi @@ -31,7 +31,6 @@
&sdhci { cap-mmc-highspeed;
- mmc-ddr-1_8v; mmc-hs200-1_8v; };
diff --git a/arch/arm/dts/rk3588-turing-rk1-u-boot.dtsi b/arch/arm/dts/rk3588-turing-rk1-u-boot.dtsi index 471508a9ed74..ca2a684f3541 100644 --- a/arch/arm/dts/rk3588-turing-rk1-u-boot.dtsi +++ b/arch/arm/dts/rk3588-turing-rk1-u-boot.dtsi @@ -8,7 +8,6 @@
&sdhci { cap-mmc-highspeed;
- mmc-ddr-1_8v; mmc-hs200-1_8v; };
diff --git a/arch/arm/dts/rk3588s-rock-5a-u-boot.dtsi b/arch/arm/dts/rk3588s-rock-5a-u-boot.dtsi index 9a6a353088df..efba0c359ba5 100644 --- a/arch/arm/dts/rk3588s-rock-5a-u-boot.dtsi +++ b/arch/arm/dts/rk3588s-rock-5a-u-boot.dtsi @@ -7,6 +7,5 @@
&sdhci { cap-mmc-highspeed;
- mmc-ddr-1_8v; mmc-hs200-1_8v; };
On Mon, Feb 5, 2024 at 4:53 AM Jonas Karlman jonas@kwiboo.se wrote:
Testing has shown that writing to eMMC using DDR52 mode does not seem to work on RK356x and RK3588 boards.
A simple test of writing a single block to e.g. sector 0x4000 fails:
# Rescan using DDR52 mode => mmc rescan 4
# Write a single block to sector 0x4000 fails with ERROR => mmc write 20000000 4000 1
With the MMC_SPEED_MODE_SET Kconfig option enabled.
Fix this by removing the mmc-ddr-1_8v prop from sdhci nodes in affected board u-boot.dtsi files.
Signed-off-by: Jonas Karlman jonas@kwiboo.se
Reviewed-by: Weizhao Ouyang o451686892@gmail.com
BR, Weizhao
Changes in v2:
- Update commit message
Link to v1: https://patchwork.ozlabs.org/patch/1891695/
arch/arm/dts/rk3566-quartz64-a-u-boot.dtsi | 1 - arch/arm/dts/rk3566-quartz64-b-u-boot.dtsi | 1 - arch/arm/dts/rk3566-radxa-cm3-io-u-boot.dtsi | 1 - arch/arm/dts/rk3566-soquartz-u-boot.dtsi | 1 - arch/arm/dts/rk3568-lubancat-2-u-boot.dtsi | 1 - arch/arm/dts/rk3568-nanopi-r5s-u-boot.dtsi | 1 - arch/arm/dts/rk3568-odroid-m1-u-boot.dtsi | 1 - arch/arm/dts/rk3568-radxa-e25-u-boot.dtsi | 1 - arch/arm/dts/rk3568-rock-3a-u-boot.dtsi | 1 - arch/arm/dts/rk3588-rock-5b-u-boot.dtsi | 1 - arch/arm/dts/rk3588-turing-rk1-u-boot.dtsi | 1 - arch/arm/dts/rk3588s-rock-5a-u-boot.dtsi | 1 - 12 files changed, 12 deletions(-)
diff --git a/arch/arm/dts/rk3566-quartz64-a-u-boot.dtsi b/arch/arm/dts/rk3566-quartz64-a-u-boot.dtsi index 11976fd3a6e0..930d660868bb 100644 --- a/arch/arm/dts/rk3566-quartz64-a-u-boot.dtsi +++ b/arch/arm/dts/rk3566-quartz64-a-u-boot.dtsi @@ -8,7 +8,6 @@
&sdhci { cap-mmc-highspeed;
mmc-ddr-1_8v; pinctrl-names = "default"; pinctrl-0 = <&emmc_bus8 &emmc_clk &emmc_cmd &emmc_datastrobe>;}; diff --git a/arch/arm/dts/rk3566-quartz64-b-u-boot.dtsi b/arch/arm/dts/rk3566-quartz64-b-u-boot.dtsi index 8de9d1535efb..c235b4357f7d 100644 --- a/arch/arm/dts/rk3566-quartz64-b-u-boot.dtsi +++ b/arch/arm/dts/rk3566-quartz64-b-u-boot.dtsi @@ -4,7 +4,6 @@
&sdhci { cap-mmc-highspeed;
mmc-ddr-1_8v; pinctrl-names = "default"; pinctrl-0 = <&emmc_bus8 &emmc_clk &emmc_cmd &emmc_datastrobe>;}; diff --git a/arch/arm/dts/rk3566-radxa-cm3-io-u-boot.dtsi b/arch/arm/dts/rk3566-radxa-cm3-io-u-boot.dtsi index 158f652cb3b1..e0e501deccfe 100644 --- a/arch/arm/dts/rk3566-radxa-cm3-io-u-boot.dtsi +++ b/arch/arm/dts/rk3566-radxa-cm3-io-u-boot.dtsi @@ -7,5 +7,4 @@
&sdhci { cap-mmc-highspeed;
mmc-ddr-1_8v;}; diff --git a/arch/arm/dts/rk3566-soquartz-u-boot.dtsi b/arch/arm/dts/rk3566-soquartz-u-boot.dtsi index f65f4067f3e9..5e46a2422d60 100644 --- a/arch/arm/dts/rk3566-soquartz-u-boot.dtsi +++ b/arch/arm/dts/rk3566-soquartz-u-boot.dtsi @@ -4,7 +4,6 @@
&sdhci { cap-mmc-highspeed;
mmc-ddr-1_8v; pinctrl-names = "default"; pinctrl-0 = <&emmc_bus8 &emmc_clk &emmc_cmd &emmc_datastrobe>;}; diff --git a/arch/arm/dts/rk3568-lubancat-2-u-boot.dtsi b/arch/arm/dts/rk3568-lubancat-2-u-boot.dtsi index a44ac35bdacd..1597473017ed 100644 --- a/arch/arm/dts/rk3568-lubancat-2-u-boot.dtsi +++ b/arch/arm/dts/rk3568-lubancat-2-u-boot.dtsi @@ -8,7 +8,6 @@
&sdhci { cap-mmc-highspeed;
mmc-ddr-1_8v; mmc-hs400-1_8v; mmc-hs400-enhanced-strobe; pinctrl-0 = <&emmc_bus8 &emmc_clk &emmc_cmd &emmc_datastrobe>;diff --git a/arch/arm/dts/rk3568-nanopi-r5s-u-boot.dtsi b/arch/arm/dts/rk3568-nanopi-r5s-u-boot.dtsi index 62f572c4cf9f..64c43374c042 100644 --- a/arch/arm/dts/rk3568-nanopi-r5s-u-boot.dtsi +++ b/arch/arm/dts/rk3568-nanopi-r5s-u-boot.dtsi @@ -14,7 +14,6 @@
&sdhci { cap-mmc-highspeed;
mmc-ddr-1_8v; mmc-hs200-1_8v; mmc-hs400-1_8v; mmc-hs400-enhanced-strobe;diff --git a/arch/arm/dts/rk3568-odroid-m1-u-boot.dtsi b/arch/arm/dts/rk3568-odroid-m1-u-boot.dtsi index ecba91aa30f5..1fc71faa9e07 100644 --- a/arch/arm/dts/rk3568-odroid-m1-u-boot.dtsi +++ b/arch/arm/dts/rk3568-odroid-m1-u-boot.dtsi @@ -8,7 +8,6 @@
&sdhci { cap-mmc-highspeed;
mmc-ddr-1_8v; mmc-hs200-1_8v; mmc-hs400-1_8v; mmc-hs400-enhanced-strobe;diff --git a/arch/arm/dts/rk3568-radxa-e25-u-boot.dtsi b/arch/arm/dts/rk3568-radxa-e25-u-boot.dtsi index caf524443079..74755a44eaee 100644 --- a/arch/arm/dts/rk3568-radxa-e25-u-boot.dtsi +++ b/arch/arm/dts/rk3568-radxa-e25-u-boot.dtsi @@ -16,7 +16,6 @@
&sdhci { cap-mmc-highspeed;
mmc-ddr-1_8v; mmc-hs200-1_8v; mmc-hs400-1_8v; mmc-hs400-enhanced-strobe;diff --git a/arch/arm/dts/rk3568-rock-3a-u-boot.dtsi b/arch/arm/dts/rk3568-rock-3a-u-boot.dtsi index 46ebb77283f1..5b823fcca5fb 100644 --- a/arch/arm/dts/rk3568-rock-3a-u-boot.dtsi +++ b/arch/arm/dts/rk3568-rock-3a-u-boot.dtsi @@ -20,7 +20,6 @@
&sdhci { cap-mmc-highspeed;
mmc-ddr-1_8v; mmc-hs200-1_8v; mmc-hs400-1_8v; mmc-hs400-enhanced-strobe;diff --git a/arch/arm/dts/rk3588-rock-5b-u-boot.dtsi b/arch/arm/dts/rk3588-rock-5b-u-boot.dtsi index e99e60185ebe..9ee9dd051e32 100644 --- a/arch/arm/dts/rk3588-rock-5b-u-boot.dtsi +++ b/arch/arm/dts/rk3588-rock-5b-u-boot.dtsi @@ -31,7 +31,6 @@
&sdhci { cap-mmc-highspeed;
mmc-ddr-1_8v; mmc-hs200-1_8v;};
diff --git a/arch/arm/dts/rk3588-turing-rk1-u-boot.dtsi b/arch/arm/dts/rk3588-turing-rk1-u-boot.dtsi index 471508a9ed74..ca2a684f3541 100644 --- a/arch/arm/dts/rk3588-turing-rk1-u-boot.dtsi +++ b/arch/arm/dts/rk3588-turing-rk1-u-boot.dtsi @@ -8,7 +8,6 @@
&sdhci { cap-mmc-highspeed;
mmc-ddr-1_8v; mmc-hs200-1_8v;};
diff --git a/arch/arm/dts/rk3588s-rock-5a-u-boot.dtsi b/arch/arm/dts/rk3588s-rock-5a-u-boot.dtsi index 9a6a353088df..efba0c359ba5 100644 --- a/arch/arm/dts/rk3588s-rock-5a-u-boot.dtsi +++ b/arch/arm/dts/rk3588s-rock-5a-u-boot.dtsi @@ -7,6 +7,5 @@
&sdhci { cap-mmc-highspeed;
mmc-ddr-1_8v; mmc-hs200-1_8v;};
2.43.0
Hi Jonas,
On 2/4/24 21:53, Jonas Karlman wrote:
Testing has shown that writing to eMMC using DDR52 mode does not seem to work on RK356x and RK3588 boards.
A simple test of writing a single block to e.g. sector 0x4000 fails:
# Rescan using DDR52 mode => mmc rescan 4
# Write a single block to sector 0x4000 fails with ERROR => mmc write 20000000 4000 1
With the MMC_SPEED_MODE_SET Kconfig option enabled.
Fix this by removing the mmc-ddr-1_8v prop from sdhci nodes in affected board u-boot.dtsi files.
Signed-off-by: Jonas Karlman jonas@kwiboo.se
Changes in v2:
- Update commit message
Link to v1: https://patchwork.ozlabs.org/patch/1891695/
arch/arm/dts/rk3566-quartz64-a-u-boot.dtsi | 1 - arch/arm/dts/rk3566-quartz64-b-u-boot.dtsi | 1 - arch/arm/dts/rk3566-radxa-cm3-io-u-boot.dtsi | 1 - arch/arm/dts/rk3566-soquartz-u-boot.dtsi | 1 - arch/arm/dts/rk3568-lubancat-2-u-boot.dtsi | 1 - arch/arm/dts/rk3568-nanopi-r5s-u-boot.dtsi | 1 - arch/arm/dts/rk3568-odroid-m1-u-boot.dtsi | 1 - arch/arm/dts/rk3568-radxa-e25-u-boot.dtsi | 1 - arch/arm/dts/rk3568-rock-3a-u-boot.dtsi | 1 - arch/arm/dts/rk3588-rock-5b-u-boot.dtsi | 1 - arch/arm/dts/rk3588-turing-rk1-u-boot.dtsi | 1 - arch/arm/dts/rk3588s-rock-5a-u-boot.dtsi | 1 - 12 files changed, 12 deletions(-)
diff --git a/arch/arm/dts/rk3566-quartz64-a-u-boot.dtsi b/arch/arm/dts/rk3566-quartz64-a-u-boot.dtsi index 11976fd3a6e0..930d660868bb 100644 --- a/arch/arm/dts/rk3566-quartz64-a-u-boot.dtsi +++ b/arch/arm/dts/rk3566-quartz64-a-u-boot.dtsi @@ -8,7 +8,6 @@
&sdhci { cap-mmc-highspeed;
Shouldn't we also remove cap-mmc-highspeed?
I assume this is for MMC_HS? Which we discovered doesn't work reliably?
Since it could be in a different patch if you wanted to, for the changes in this patch:
Reviewed-by: Quentin Schulz quentin.schulz@theobroma-systems.com
Thanks, Quentin
Hi Quentin,
On 2024-02-05 10:40, Quentin Schulz wrote:
Hi Jonas,
On 2/4/24 21:53, Jonas Karlman wrote:
Testing has shown that writing to eMMC using DDR52 mode does not seem to work on RK356x and RK3588 boards.
A simple test of writing a single block to e.g. sector 0x4000 fails:
# Rescan using DDR52 mode => mmc rescan 4
# Write a single block to sector 0x4000 fails with ERROR => mmc write 20000000 4000 1
With the MMC_SPEED_MODE_SET Kconfig option enabled.
Fix this by removing the mmc-ddr-1_8v prop from sdhci nodes in affected board u-boot.dtsi files.
Signed-off-by: Jonas Karlman jonas@kwiboo.se
Changes in v2:
- Update commit message
Link to v1: https://patchwork.ozlabs.org/patch/1891695/
arch/arm/dts/rk3566-quartz64-a-u-boot.dtsi | 1 - arch/arm/dts/rk3566-quartz64-b-u-boot.dtsi | 1 - arch/arm/dts/rk3566-radxa-cm3-io-u-boot.dtsi | 1 - arch/arm/dts/rk3566-soquartz-u-boot.dtsi | 1 - arch/arm/dts/rk3568-lubancat-2-u-boot.dtsi | 1 - arch/arm/dts/rk3568-nanopi-r5s-u-boot.dtsi | 1 - arch/arm/dts/rk3568-odroid-m1-u-boot.dtsi | 1 - arch/arm/dts/rk3568-radxa-e25-u-boot.dtsi | 1 - arch/arm/dts/rk3568-rock-3a-u-boot.dtsi | 1 - arch/arm/dts/rk3588-rock-5b-u-boot.dtsi | 1 - arch/arm/dts/rk3588-turing-rk1-u-boot.dtsi | 1 - arch/arm/dts/rk3588s-rock-5a-u-boot.dtsi | 1 - 12 files changed, 12 deletions(-)
diff --git a/arch/arm/dts/rk3566-quartz64-a-u-boot.dtsi b/arch/arm/dts/rk3566-quartz64-a-u-boot.dtsi index 11976fd3a6e0..930d660868bb 100644 --- a/arch/arm/dts/rk3566-quartz64-a-u-boot.dtsi +++ b/arch/arm/dts/rk3566-quartz64-a-u-boot.dtsi @@ -8,7 +8,6 @@
&sdhci { cap-mmc-highspeed;
Shouldn't we also remove cap-mmc-highspeed?
I assume this is for MMC_HS? Which we discovered doesn't work reliably?
Writing in lower speeds on RK356x does work better then on RK3588, however HS200 still seem to be more reliable overall and give more speed.
For RK3588 they could possible be removed, but since reading does work and similar issue also existed in the fallback MMC legacy mode, I did not see that cleanup as important, or maybe more correctly it did not cross my mind to also remove these props :-), the fully broken ddr52 felt more important.
Since it could be in a different patch if you wanted to, for the changes in this patch:
Agree, a possible cleanup of cap-mmc-highspeed props could be done in a separate patch.
Alternatively any missing and appropriate modes currently in u-boot.dtsi should be added to linux DT and they can then be synced back to U-Boot and any override/addition dropped from u-boot.dtsi files.
Regards, Jonas
Reviewed-by: Quentin Schulz quentin.schulz@theobroma-systems.com
Thanks, Quentin
On 2024-02-05 14:24, Jonas Karlman wrote:
On 2024-02-05 10:40, Quentin Schulz wrote:
On 2/4/24 21:53, Jonas Karlman wrote:
Testing has shown that writing to eMMC using DDR52 mode does not seem to work on RK356x and RK3588 boards.
A simple test of writing a single block to e.g. sector 0x4000 fails:
# Rescan using DDR52 mode => mmc rescan 4
# Write a single block to sector 0x4000 fails with ERROR => mmc write 20000000 4000 1
With the MMC_SPEED_MODE_SET Kconfig option enabled.
Fix this by removing the mmc-ddr-1_8v prop from sdhci nodes in affected board u-boot.dtsi files.
Signed-off-by: Jonas Karlman jonas@kwiboo.se
Changes in v2:
- Update commit message
Link to v1: https://patchwork.ozlabs.org/patch/1891695/
arch/arm/dts/rk3566-quartz64-a-u-boot.dtsi | 1 - arch/arm/dts/rk3566-quartz64-b-u-boot.dtsi | 1 - arch/arm/dts/rk3566-radxa-cm3-io-u-boot.dtsi | 1 - arch/arm/dts/rk3566-soquartz-u-boot.dtsi | 1 - arch/arm/dts/rk3568-lubancat-2-u-boot.dtsi | 1 - arch/arm/dts/rk3568-nanopi-r5s-u-boot.dtsi | 1 - arch/arm/dts/rk3568-odroid-m1-u-boot.dtsi | 1 - arch/arm/dts/rk3568-radxa-e25-u-boot.dtsi | 1 - arch/arm/dts/rk3568-rock-3a-u-boot.dtsi | 1 - arch/arm/dts/rk3588-rock-5b-u-boot.dtsi | 1 - arch/arm/dts/rk3588-turing-rk1-u-boot.dtsi | 1 - arch/arm/dts/rk3588s-rock-5a-u-boot.dtsi | 1 - 12 files changed, 12 deletions(-)
diff --git a/arch/arm/dts/rk3566-quartz64-a-u-boot.dtsi b/arch/arm/dts/rk3566-quartz64-a-u-boot.dtsi index 11976fd3a6e0..930d660868bb 100644 --- a/arch/arm/dts/rk3566-quartz64-a-u-boot.dtsi +++ b/arch/arm/dts/rk3566-quartz64-a-u-boot.dtsi @@ -8,7 +8,6 @@
&sdhci { cap-mmc-highspeed;
Shouldn't we also remove cap-mmc-highspeed?
I assume this is for MMC_HS? Which we discovered doesn't work reliably?
Writing in lower speeds on RK356x does work better then on RK3588, however HS200 still seem to be more reliable overall and give more speed.
For RK3588 they could possible be removed, but since reading does work and similar issue also existed in the fallback MMC legacy mode, I did not see that cleanup as important, or maybe more correctly it did not cross my mind to also remove these props :-), the fully broken ddr52 felt more important.
Since it could be in a different patch if you wanted to, for the changes in this patch:
Agree, a possible cleanup of cap-mmc-highspeed props could be done in a separate patch.
Alternatively any missing and appropriate modes currently in u-boot.dtsi should be added to linux DT and they can then be synced back to U-Boot and any override/addition dropped from u-boot.dtsi files.
How about waiting until I fix the mode selection in the Linux kernel drivers? As I noted already, that's already on my TODO list, and perhaps it would be good to test a bit again under Linux with those fixes applied, before actually removing the buggy modes from the kernel's RK356x and RK3588(s) SoC dtsi files.
I expect to continue my work on those kernel bugfixes in the next few weeks. I did some work already, but left it there, and now I'll pick it up again.
Hi Dragan,
On 2/5/24 14:40, Dragan Simic wrote:
[You don't often get email from dsimic@manjaro.org. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
On 2024-02-05 14:24, Jonas Karlman wrote:
On 2024-02-05 10:40, Quentin Schulz wrote:
On 2/4/24 21:53, Jonas Karlman wrote:
Testing has shown that writing to eMMC using DDR52 mode does not seem to work on RK356x and RK3588 boards.
A simple test of writing a single block to e.g. sector 0x4000 fails:
# Rescan using DDR52 mode => mmc rescan 4
# Write a single block to sector 0x4000 fails with ERROR => mmc write 20000000 4000 1
With the MMC_SPEED_MODE_SET Kconfig option enabled.
Fix this by removing the mmc-ddr-1_8v prop from sdhci nodes in affected board u-boot.dtsi files.
Signed-off-by: Jonas Karlman jonas@kwiboo.se
Changes in v2:
- Update commit message
Link to v1: https://patchwork.ozlabs.org/patch/1891695/
arch/arm/dts/rk3566-quartz64-a-u-boot.dtsi | 1 - arch/arm/dts/rk3566-quartz64-b-u-boot.dtsi | 1 - arch/arm/dts/rk3566-radxa-cm3-io-u-boot.dtsi | 1 - arch/arm/dts/rk3566-soquartz-u-boot.dtsi | 1 - arch/arm/dts/rk3568-lubancat-2-u-boot.dtsi | 1 - arch/arm/dts/rk3568-nanopi-r5s-u-boot.dtsi | 1 - arch/arm/dts/rk3568-odroid-m1-u-boot.dtsi | 1 - arch/arm/dts/rk3568-radxa-e25-u-boot.dtsi | 1 - arch/arm/dts/rk3568-rock-3a-u-boot.dtsi | 1 - arch/arm/dts/rk3588-rock-5b-u-boot.dtsi | 1 - arch/arm/dts/rk3588-turing-rk1-u-boot.dtsi | 1 - arch/arm/dts/rk3588s-rock-5a-u-boot.dtsi | 1 - 12 files changed, 12 deletions(-)
diff --git a/arch/arm/dts/rk3566-quartz64-a-u-boot.dtsi b/arch/arm/dts/rk3566-quartz64-a-u-boot.dtsi index 11976fd3a6e0..930d660868bb 100644 --- a/arch/arm/dts/rk3566-quartz64-a-u-boot.dtsi +++ b/arch/arm/dts/rk3566-quartz64-a-u-boot.dtsi @@ -8,7 +8,6 @@
&sdhci { cap-mmc-highspeed;
Shouldn't we also remove cap-mmc-highspeed?
I assume this is for MMC_HS? Which we discovered doesn't work reliably?
Writing in lower speeds on RK356x does work better then on RK3588, however HS200 still seem to be more reliable overall and give more speed.
For RK3588 they could possible be removed, but since reading does work and similar issue also existed in the fallback MMC legacy mode, I did not see that cleanup as important, or maybe more correctly it did not cross my mind to also remove these props :-), the fully broken ddr52 felt more important.
Since it could be in a different patch if you wanted to, for the changes in this patch:
Agree, a possible cleanup of cap-mmc-highspeed props could be done in a separate patch.
Alternatively any missing and appropriate modes currently in u-boot.dtsi should be added to linux DT and they can then be synced back to U-Boot and any override/addition dropped from u-boot.dtsi files.
How about waiting until I fix the mode selection in the Linux kernel drivers? As I noted already, that's already on my TODO list, and perhaps it would be good to test a bit again under Linux with those fixes applied, before actually removing the buggy modes from the kernel's RK356x and RK3588(s) SoC dtsi files.
While I appreciate there's some work that can be done in the Linux kernel for those low-speed modes, the properties in question are removed only from U-Boot's DTS and your future patches for the kernel wouldn't impact the bootloader anyway.
The issue right now is that U-Boot is currently broken because of those properties, which are only in U-Boot's DTS.
Not sure exactly why we should waiting on Linux kernel patches for merging work-arounds for U-Boot? What exactly are you suggesting we wait for? What can improve the situation?
Cheers, Quentin
On 2024-02-05 14:45, Quentin Schulz wrote:
On 2/5/24 14:40, Dragan Simic wrote:
On 2024-02-05 14:24, Jonas Karlman wrote:
On 2024-02-05 10:40, Quentin Schulz wrote:
Shouldn't we also remove cap-mmc-highspeed?
I assume this is for MMC_HS? Which we discovered doesn't work reliably?
Writing in lower speeds on RK356x does work better then on RK3588, however HS200 still seem to be more reliable overall and give more speed.
For RK3588 they could possible be removed, but since reading does work and similar issue also existed in the fallback MMC legacy mode, I did not see that cleanup as important, or maybe more correctly it did not cross my mind to also remove these props :-), the fully broken ddr52 felt more important.
Since it could be in a different patch if you wanted to, for the changes in this patch:
Agree, a possible cleanup of cap-mmc-highspeed props could be done in a separate patch.
Alternatively any missing and appropriate modes currently in u-boot.dtsi should be added to linux DT and they can then be synced back to U-Boot and any override/addition dropped from u-boot.dtsi files.
How about waiting until I fix the mode selection in the Linux kernel drivers? As I noted already, that's already on my TODO list, and perhaps it would be good to test a bit again under Linux with those fixes applied, before actually removing the buggy modes from the kernel's RK356x and RK3588(s) SoC dtsi files.
While I appreciate there's some work that can be done in the Linux kernel for those low-speed modes, the properties in question are removed only from U-Boot's DTS and your future patches for the kernel wouldn't impact the bootloader anyway.
The issue right now is that U-Boot is currently broken because of those properties, which are only in U-Boot's DTS.
Not sure exactly why we should waiting on Linux kernel patches for merging work-arounds for U-Boot? What exactly are you suggesting we wait for? What can improve the situation?
Ah, sorry for the confusion, let me clarify a bit...
I just replied to the Jonas's remark about the need to eventually have the same fixes and mode removals in the Linux kernel's SoC dtsi files. In other words, all I wrote was about those changes, not about the changes on the U-Boot side.
Of course, there are no reasons for delaying these U-Boot fixes.
On 2024-02-05 14:51, Dragan Simic wrote:
On 2024-02-05 14:45, Quentin Schulz wrote:
On 2/5/24 14:40, Dragan Simic wrote:
On 2024-02-05 14:24, Jonas Karlman wrote:
On 2024-02-05 10:40, Quentin Schulz wrote:
Shouldn't we also remove cap-mmc-highspeed?
I assume this is for MMC_HS? Which we discovered doesn't work reliably?
Writing in lower speeds on RK356x does work better then on RK3588, however HS200 still seem to be more reliable overall and give more speed.
For RK3588 they could possible be removed, but since reading does work and similar issue also existed in the fallback MMC legacy mode, I did not see that cleanup as important, or maybe more correctly it did not cross my mind to also remove these props :-), the fully broken ddr52 felt more important.
Since it could be in a different patch if you wanted to, for the changes in this patch:
Agree, a possible cleanup of cap-mmc-highspeed props could be done in a separate patch.
Alternatively any missing and appropriate modes currently in u-boot.dtsi should be added to linux DT and they can then be synced back to U-Boot and any override/addition dropped from u-boot.dtsi files.
How about waiting until I fix the mode selection in the Linux kernel drivers? As I noted already, that's already on my TODO list, and perhaps it would be good to test a bit again under Linux with those fixes applied, before actually removing the buggy modes from the kernel's RK356x and RK3588(s) SoC dtsi files.
While I appreciate there's some work that can be done in the Linux kernel for those low-speed modes, the properties in question are removed only from U-Boot's DTS and your future patches for the kernel wouldn't impact the bootloader anyway.
The issue right now is that U-Boot is currently broken because of those properties, which are only in U-Boot's DTS.
Not sure exactly why we should waiting on Linux kernel patches for merging work-arounds for U-Boot? What exactly are you suggesting we wait for? What can improve the situation?
Ah, sorry for the confusion, let me clarify a bit...
I just replied to the Jonas's remark about the need to eventually have the same fixes and mode removals in the Linux kernel's SoC dtsi files. In other words, all I wrote was about those changes, not about the changes on the U-Boot side.
Of course, there are no reasons for delaying these U-Boot fixes.
Short history about the added eMMC modes in u-boot.dtsi on RK35xx boards:
U-Boot defaults to not support HS200+ modes unless explicitly enabled in Kconfig options and on top of that the driver require DT to have a corresponding mode prop to make use of any mode faster than MMC legacy.
When I worked on eMMC fixes for RK3568 and support for RK3588 [1] I only tested reading data using all modes.
Because reading data in all modes seem to work on the boards I tested on, I eventually added the "missing" props to board u-boot.dtsi-files, so that U-Boot could make use of faster modes. However, I opted to only enable the HS200 Kconfig option on boards with embedded eMMC.
This has resulted in that most RK35xx boards now default to using the fastest none HS200+ mode, i.e. DDR52 mode. They would also try to use a faster mode as long as a HS200+ Kconfig option is enabled.
With the removal of mmc-ddr-1_8v prop in this series, at least the most broken mode is avoided for all RK35xx boards. And with the HS200 Kconfig option enabled by default, the required tuning in HS200+ mode should automatically happen as long as eMMC module support HS200 mode. After that writing in any supported lower speed seem to work OK.
In the case where HS200 is supported any read/write in lower speed seem to work, so the modes provided by cap-mmc-highspeed prop is OK.
However, if HS200+ is not supported it does not really matter, first write will fail in any remaining mode, the slowest legacy or the modes provided by cap-mmc-highspeed prop.
Keeping the cap-mmc-highspeed prop at least make reading data faster possible, and writing data is still semi-broken in any remaining mode.
In conclusion I suggest:
- We keep the cap-mmc-highspeed props in board u-boot.dtsi for now.
- The mmc mode props that has been added in board u-boot.dtsi and have been validated working with both U-Boot and linux should be added to board DT. e.g HS200+ props is missing in some board DT.
- When an updated board DT has been synced from linux, any override in board u-boot.dtsi should be dropped.
I am also fine with completely dropping cap-mmc-highspeed props now if they cause issues not solved by the HS200 Kconfig option being enabled.
[1] https://patchwork.ozlabs.org/cover/1764606/
Regards, Jonas
Hello Jonas,
On 2024-02-05 18:01, Jonas Karlman wrote:
On 2024-02-05 14:51, Dragan Simic wrote:
On 2024-02-05 14:45, Quentin Schulz wrote:
On 2/5/24 14:40, Dragan Simic wrote:
How about waiting until I fix the mode selection in the Linux kernel drivers? As I noted already, that's already on my TODO list, and perhaps it would be good to test a bit again under Linux with those fixes applied, before actually removing the buggy modes from the kernel's RK356x and RK3588(s) SoC dtsi files.
While I appreciate there's some work that can be done in the Linux kernel for those low-speed modes, the properties in question are removed only from U-Boot's DTS and your future patches for the kernel wouldn't impact the bootloader anyway.
The issue right now is that U-Boot is currently broken because of those properties, which are only in U-Boot's DTS.
Not sure exactly why we should waiting on Linux kernel patches for merging work-arounds for U-Boot? What exactly are you suggesting we wait for? What can improve the situation?
Ah, sorry for the confusion, let me clarify a bit...
I just replied to the Jonas's remark about the need to eventually have the same fixes and mode removals in the Linux kernel's SoC dtsi files. In other words, all I wrote was about those changes, not about the changes on the U-Boot side.
Of course, there are no reasons for delaying these U-Boot fixes.
Short history about the added eMMC modes in u-boot.dtsi on RK35xx boards:
U-Boot defaults to not support HS200+ modes unless explicitly enabled in Kconfig options and on top of that the driver require DT to have a corresponding mode prop to make use of any mode faster than MMC legacy.
When I worked on eMMC fixes for RK3568 and support for RK3588 [1] I only tested reading data using all modes.
Because reading data in all modes seem to work on the boards I tested on, I eventually added the "missing" props to board u-boot.dtsi-files, so that U-Boot could make use of faster modes. However, I opted to only enable the HS200 Kconfig option on boards with embedded eMMC.
This has resulted in that most RK35xx boards now default to using the fastest none HS200+ mode, i.e. DDR52 mode. They would also try to use a faster mode as long as a HS200+ Kconfig option is enabled.
With the removal of mmc-ddr-1_8v prop in this series, at least the most broken mode is avoided for all RK35xx boards. And with the HS200 Kconfig option enabled by default, the required tuning in HS200+ mode should automatically happen as long as eMMC module support HS200 mode. After that writing in any supported lower speed seem to work OK.
In the case where HS200 is supported any read/write in lower speed seem to work, so the modes provided by cap-mmc-highspeed prop is OK.
However, if HS200+ is not supported it does not really matter, first write will fail in any remaining mode, the slowest legacy or the modes provided by cap-mmc-highspeed prop.
Keeping the cap-mmc-highspeed prop at least make reading data faster possible, and writing data is still semi-broken in any remaining mode.
In conclusion I suggest:
We keep the cap-mmc-highspeed props in board u-boot.dtsi for now.
The mmc mode props that has been added in board u-boot.dtsi and have been validated working with both U-Boot and linux should be added to board DT. e.g HS200+ props is missing in some board DT.
When an updated board DT has been synced from linux, any override in board u-boot.dtsi should be dropped.
I am also fine with completely dropping cap-mmc-highspeed props now if they cause issues not solved by the HS200 Kconfig option being enabled.
Thank you for taking the time to write this detailed summary!
It's somewhat unexpected that the writes to eMMC fail to work while the reads work fine. As we know, the writes don't introduce the delay between the host-generated clock and the data to be written. It would be expected for the reads to be more error-prone.
Testing has shown that writing to eMMC using a slower mode then HS200 typically generate an ERROR on first attempt on RK3588.
# Rescan using MMC legacy mode => mmc rescan 0
# Write a single block to sector 0x4000 fails with ERROR => mmc write 20000000 4000 1
# Write a single block to sector 0x4000 now works => mmc write 20000000 4000 1
With the MMC_SPEED_MODE_SET Kconfig option enabled.
Writing to eMMC using HS200 mode work more reliably than slower modes on RK35xx boards. Enable MMC_HS200_SUPPORT Kconfig option by default to prefer use of HS200 mode on RK356x and RK3588.
Signed-off-by: Jonas Karlman jonas@kwiboo.se --- Changes in v2: - Imply MMC_HS200_SUPPORT and SPL_MMC_HS200_SUPPORT in arch Kconfig instead of adding to each boards defconfig - R-b tags not collected because of above change - Combine changes for rk356x and rk3588 in one patch - Update commit message
Link to v1: https://patchwork.ozlabs.org/patch/1891693/ --- arch/arm/mach-rockchip/Kconfig | 4 ++++ configs/nanopi-r5c-rk3568_defconfig | 2 -- configs/nanopi-r5s-rk3568_defconfig | 2 -- configs/radxa-e25-rk3568_defconfig | 2 -- 4 files changed, 4 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-rockchip/Kconfig b/arch/arm/mach-rockchip/Kconfig index 6ff0aa6911e2..946ef5d7023d 100644 --- a/arch/arm/mach-rockchip/Kconfig +++ b/arch/arm/mach-rockchip/Kconfig @@ -292,6 +292,8 @@ config ROCKCHIP_RK3568 imply OF_LIBFDT_OVERLAY imply ROCKCHIP_OTP imply MISC_INIT_R + imply MMC_HS200_SUPPORT if MMC_SDHCI_ROCKCHIP + imply SPL_MMC_HS200_SUPPORT if SPL_MMC && MMC_HS200_SUPPORT help The Rockchip RK3568 is a ARM-based SoC with quad-core Cortex-A55, including NEON and GPU, 512K L3 cache, Mali-G52 based graphics, @@ -317,6 +319,8 @@ config ROCKCHIP_RK3588 imply OF_LIBFDT_OVERLAY imply ROCKCHIP_OTP imply MISC_INIT_R + imply MMC_HS200_SUPPORT if MMC_SDHCI_ROCKCHIP + imply SPL_MMC_HS200_SUPPORT if SPL_MMC && MMC_HS200_SUPPORT imply CLK_SCMI imply SCMI_FIRMWARE help diff --git a/configs/nanopi-r5c-rk3568_defconfig b/configs/nanopi-r5c-rk3568_defconfig index 833cff0e457d..f5a472d03d78 100644 --- a/configs/nanopi-r5c-rk3568_defconfig +++ b/configs/nanopi-r5c-rk3568_defconfig @@ -58,8 +58,6 @@ CONFIG_ROCKCHIP_GPIO=y CONFIG_SYS_I2C_ROCKCHIP=y CONFIG_MISC=y CONFIG_SUPPORT_EMMC_RPMB=y -CONFIG_MMC_HS200_SUPPORT=y -CONFIG_SPL_MMC_HS200_SUPPORT=y CONFIG_MMC_DW=y CONFIG_MMC_DW_ROCKCHIP=y CONFIG_MMC_SDHCI=y diff --git a/configs/nanopi-r5s-rk3568_defconfig b/configs/nanopi-r5s-rk3568_defconfig index 2736d382a352..99692d341f44 100644 --- a/configs/nanopi-r5s-rk3568_defconfig +++ b/configs/nanopi-r5s-rk3568_defconfig @@ -58,8 +58,6 @@ CONFIG_ROCKCHIP_GPIO=y CONFIG_SYS_I2C_ROCKCHIP=y CONFIG_MISC=y CONFIG_SUPPORT_EMMC_RPMB=y -CONFIG_MMC_HS200_SUPPORT=y -CONFIG_SPL_MMC_HS200_SUPPORT=y CONFIG_MMC_DW=y CONFIG_MMC_DW_ROCKCHIP=y CONFIG_MMC_SDHCI=y diff --git a/configs/radxa-e25-rk3568_defconfig b/configs/radxa-e25-rk3568_defconfig index 5a613abe0d2d..fedb137877ab 100644 --- a/configs/radxa-e25-rk3568_defconfig +++ b/configs/radxa-e25-rk3568_defconfig @@ -60,8 +60,6 @@ CONFIG_ROCKCHIP_GPIO=y CONFIG_SYS_I2C_ROCKCHIP=y CONFIG_MISC=y CONFIG_SUPPORT_EMMC_RPMB=y -CONFIG_MMC_HS200_SUPPORT=y -CONFIG_SPL_MMC_HS200_SUPPORT=y CONFIG_MMC_DW=y CONFIG_MMC_DW_ROCKCHIP=y CONFIG_MMC_SDHCI=y
On 2024/2/5 04:53, Jonas Karlman wrote:
Testing has shown that writing to eMMC using a slower mode then HS200 typically generate an ERROR on first attempt on RK3588.
# Rescan using MMC legacy mode => mmc rescan 0
# Write a single block to sector 0x4000 fails with ERROR => mmc write 20000000 4000 1
# Write a single block to sector 0x4000 now works => mmc write 20000000 4000 1
With the MMC_SPEED_MODE_SET Kconfig option enabled.
Writing to eMMC using HS200 mode work more reliably than slower modes on RK35xx boards. Enable MMC_HS200_SUPPORT Kconfig option by default to prefer use of HS200 mode on RK356x and RK3588.
Signed-off-by: Jonas Karlman jonas@kwiboo.se
Reviewed-by: Kever Yang kever.yang@rock-chips.com
Thanks, - Kever
Changes in v2:
- Imply MMC_HS200_SUPPORT and SPL_MMC_HS200_SUPPORT in arch Kconfig instead of adding to each boards defconfig
- R-b tags not collected because of above change
- Combine changes for rk356x and rk3588 in one patch
- Update commit message
Link to v1: https://patchwork.ozlabs.org/patch/1891693/
arch/arm/mach-rockchip/Kconfig | 4 ++++ configs/nanopi-r5c-rk3568_defconfig | 2 -- configs/nanopi-r5s-rk3568_defconfig | 2 -- configs/radxa-e25-rk3568_defconfig | 2 -- 4 files changed, 4 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-rockchip/Kconfig b/arch/arm/mach-rockchip/Kconfig index 6ff0aa6911e2..946ef5d7023d 100644 --- a/arch/arm/mach-rockchip/Kconfig +++ b/arch/arm/mach-rockchip/Kconfig @@ -292,6 +292,8 @@ config ROCKCHIP_RK3568 imply OF_LIBFDT_OVERLAY imply ROCKCHIP_OTP imply MISC_INIT_R
- imply MMC_HS200_SUPPORT if MMC_SDHCI_ROCKCHIP
- imply SPL_MMC_HS200_SUPPORT if SPL_MMC && MMC_HS200_SUPPORT help The Rockchip RK3568 is a ARM-based SoC with quad-core Cortex-A55, including NEON and GPU, 512K L3 cache, Mali-G52 based graphics,
@@ -317,6 +319,8 @@ config ROCKCHIP_RK3588 imply OF_LIBFDT_OVERLAY imply ROCKCHIP_OTP imply MISC_INIT_R
- imply MMC_HS200_SUPPORT if MMC_SDHCI_ROCKCHIP
- imply SPL_MMC_HS200_SUPPORT if SPL_MMC && MMC_HS200_SUPPORT imply CLK_SCMI imply SCMI_FIRMWARE help
diff --git a/configs/nanopi-r5c-rk3568_defconfig b/configs/nanopi-r5c-rk3568_defconfig index 833cff0e457d..f5a472d03d78 100644 --- a/configs/nanopi-r5c-rk3568_defconfig +++ b/configs/nanopi-r5c-rk3568_defconfig @@ -58,8 +58,6 @@ CONFIG_ROCKCHIP_GPIO=y CONFIG_SYS_I2C_ROCKCHIP=y CONFIG_MISC=y CONFIG_SUPPORT_EMMC_RPMB=y -CONFIG_MMC_HS200_SUPPORT=y -CONFIG_SPL_MMC_HS200_SUPPORT=y CONFIG_MMC_DW=y CONFIG_MMC_DW_ROCKCHIP=y CONFIG_MMC_SDHCI=y diff --git a/configs/nanopi-r5s-rk3568_defconfig b/configs/nanopi-r5s-rk3568_defconfig index 2736d382a352..99692d341f44 100644 --- a/configs/nanopi-r5s-rk3568_defconfig +++ b/configs/nanopi-r5s-rk3568_defconfig @@ -58,8 +58,6 @@ CONFIG_ROCKCHIP_GPIO=y CONFIG_SYS_I2C_ROCKCHIP=y CONFIG_MISC=y CONFIG_SUPPORT_EMMC_RPMB=y -CONFIG_MMC_HS200_SUPPORT=y -CONFIG_SPL_MMC_HS200_SUPPORT=y CONFIG_MMC_DW=y CONFIG_MMC_DW_ROCKCHIP=y CONFIG_MMC_SDHCI=y diff --git a/configs/radxa-e25-rk3568_defconfig b/configs/radxa-e25-rk3568_defconfig index 5a613abe0d2d..fedb137877ab 100644 --- a/configs/radxa-e25-rk3568_defconfig +++ b/configs/radxa-e25-rk3568_defconfig @@ -60,8 +60,6 @@ CONFIG_ROCKCHIP_GPIO=y CONFIG_SYS_I2C_ROCKCHIP=y CONFIG_MISC=y CONFIG_SUPPORT_EMMC_RPMB=y -CONFIG_MMC_HS200_SUPPORT=y -CONFIG_SPL_MMC_HS200_SUPPORT=y CONFIG_MMC_DW=y CONFIG_MMC_DW_ROCKCHIP=y CONFIG_MMC_SDHCI=y
On Mon, Feb 5, 2024 at 4:53 AM Jonas Karlman jonas@kwiboo.se wrote:
Testing has shown that writing to eMMC using a slower mode then HS200 typically generate an ERROR on first attempt on RK3588.
# Rescan using MMC legacy mode => mmc rescan 0
# Write a single block to sector 0x4000 fails with ERROR => mmc write 20000000 4000 1
# Write a single block to sector 0x4000 now works => mmc write 20000000 4000 1
With the MMC_SPEED_MODE_SET Kconfig option enabled.
Writing to eMMC using HS200 mode work more reliably than slower modes on RK35xx boards. Enable MMC_HS200_SUPPORT Kconfig option by default to prefer use of HS200 mode on RK356x and RK3588.
Signed-off-by: Jonas Karlman jonas@kwiboo.se
Reviewed-by: Weizhao Ouyang o451686892@gmail.com
BR, Weizhao
Changes in v2:
- Imply MMC_HS200_SUPPORT and SPL_MMC_HS200_SUPPORT in arch Kconfig instead of adding to each boards defconfig
- R-b tags not collected because of above change
- Combine changes for rk356x and rk3588 in one patch
- Update commit message
Link to v1: https://patchwork.ozlabs.org/patch/1891693/
arch/arm/mach-rockchip/Kconfig | 4 ++++ configs/nanopi-r5c-rk3568_defconfig | 2 -- configs/nanopi-r5s-rk3568_defconfig | 2 -- configs/radxa-e25-rk3568_defconfig | 2 -- 4 files changed, 4 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-rockchip/Kconfig b/arch/arm/mach-rockchip/Kconfig index 6ff0aa6911e2..946ef5d7023d 100644 --- a/arch/arm/mach-rockchip/Kconfig +++ b/arch/arm/mach-rockchip/Kconfig @@ -292,6 +292,8 @@ config ROCKCHIP_RK3568 imply OF_LIBFDT_OVERLAY imply ROCKCHIP_OTP imply MISC_INIT_R
imply MMC_HS200_SUPPORT if MMC_SDHCI_ROCKCHIPimply SPL_MMC_HS200_SUPPORT if SPL_MMC && MMC_HS200_SUPPORT help The Rockchip RK3568 is a ARM-based SoC with quad-core Cortex-A55, including NEON and GPU, 512K L3 cache, Mali-G52 based graphics,@@ -317,6 +319,8 @@ config ROCKCHIP_RK3588 imply OF_LIBFDT_OVERLAY imply ROCKCHIP_OTP imply MISC_INIT_R
imply MMC_HS200_SUPPORT if MMC_SDHCI_ROCKCHIPimply SPL_MMC_HS200_SUPPORT if SPL_MMC && MMC_HS200_SUPPORT imply CLK_SCMI imply SCMI_FIRMWARE helpdiff --git a/configs/nanopi-r5c-rk3568_defconfig b/configs/nanopi-r5c-rk3568_defconfig index 833cff0e457d..f5a472d03d78 100644 --- a/configs/nanopi-r5c-rk3568_defconfig +++ b/configs/nanopi-r5c-rk3568_defconfig @@ -58,8 +58,6 @@ CONFIG_ROCKCHIP_GPIO=y CONFIG_SYS_I2C_ROCKCHIP=y CONFIG_MISC=y CONFIG_SUPPORT_EMMC_RPMB=y -CONFIG_MMC_HS200_SUPPORT=y -CONFIG_SPL_MMC_HS200_SUPPORT=y CONFIG_MMC_DW=y CONFIG_MMC_DW_ROCKCHIP=y CONFIG_MMC_SDHCI=y diff --git a/configs/nanopi-r5s-rk3568_defconfig b/configs/nanopi-r5s-rk3568_defconfig index 2736d382a352..99692d341f44 100644 --- a/configs/nanopi-r5s-rk3568_defconfig +++ b/configs/nanopi-r5s-rk3568_defconfig @@ -58,8 +58,6 @@ CONFIG_ROCKCHIP_GPIO=y CONFIG_SYS_I2C_ROCKCHIP=y CONFIG_MISC=y CONFIG_SUPPORT_EMMC_RPMB=y -CONFIG_MMC_HS200_SUPPORT=y -CONFIG_SPL_MMC_HS200_SUPPORT=y CONFIG_MMC_DW=y CONFIG_MMC_DW_ROCKCHIP=y CONFIG_MMC_SDHCI=y diff --git a/configs/radxa-e25-rk3568_defconfig b/configs/radxa-e25-rk3568_defconfig index 5a613abe0d2d..fedb137877ab 100644 --- a/configs/radxa-e25-rk3568_defconfig +++ b/configs/radxa-e25-rk3568_defconfig @@ -60,8 +60,6 @@ CONFIG_ROCKCHIP_GPIO=y CONFIG_SYS_I2C_ROCKCHIP=y CONFIG_MISC=y CONFIG_SUPPORT_EMMC_RPMB=y -CONFIG_MMC_HS200_SUPPORT=y -CONFIG_SPL_MMC_HS200_SUPPORT=y CONFIG_MMC_DW=y CONFIG_MMC_DW_ROCKCHIP=y CONFIG_MMC_SDHCI=y -- 2.43.0
Hi Jonas,
On 2/4/24 21:53, Jonas Karlman wrote:
Testing has shown that writing to eMMC using a slower mode then HS200 typically generate an ERROR on first attempt on RK3588.
# Rescan using MMC legacy mode => mmc rescan 0
# Write a single block to sector 0x4000 fails with ERROR => mmc write 20000000 4000 1
# Write a single block to sector 0x4000 now works => mmc write 20000000 4000 1
With the MMC_SPEED_MODE_SET Kconfig option enabled.
Writing to eMMC using HS200 mode work more reliably than slower modes on RK35xx boards. Enable MMC_HS200_SUPPORT Kconfig option by default to prefer use of HS200 mode on RK356x and RK3588.
Signed-off-by: Jonas Karlman jonas@kwiboo.se
Changes in v2:
- Imply MMC_HS200_SUPPORT and SPL_MMC_HS200_SUPPORT in arch Kconfig instead of adding to each boards defconfig
- R-b tags not collected because of above change
- Combine changes for rk356x and rk3588 in one patch
- Update commit message
Link to v1: https://patchwork.ozlabs.org/patch/1891693/
arch/arm/mach-rockchip/Kconfig | 4 ++++ configs/nanopi-r5c-rk3568_defconfig | 2 -- configs/nanopi-r5s-rk3568_defconfig | 2 -- configs/radxa-e25-rk3568_defconfig | 2 -- 4 files changed, 4 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-rockchip/Kconfig b/arch/arm/mach-rockchip/Kconfig index 6ff0aa6911e2..946ef5d7023d 100644 --- a/arch/arm/mach-rockchip/Kconfig +++ b/arch/arm/mach-rockchip/Kconfig @@ -292,6 +292,8 @@ config ROCKCHIP_RK3568 imply OF_LIBFDT_OVERLAY imply ROCKCHIP_OTP imply MISC_INIT_R
- imply MMC_HS200_SUPPORT if MMC_SDHCI_ROCKCHIP
MMC_SDHCI_ROCKCHIP is also required for eMMC on RK3399, which would change the current default, at the very least for Puma RK3399.
Doing a:
rg -lU --multiline-dotall 'RK3399.*MMC_HS.*' configs/
Only returns: configs/evb-rk3399_defconfig configs/pinebook-pro-rk3399_defconfig
and there are 29 defconfigs for RK3399-based boards right now, so maybe that's a bit too big of a change?
Cheers, Quentin
Hi Quentin,
On 2024-02-05 10:47, Quentin Schulz wrote:
Hi Jonas,
On 2/4/24 21:53, Jonas Karlman wrote:
Testing has shown that writing to eMMC using a slower mode then HS200 typically generate an ERROR on first attempt on RK3588.
# Rescan using MMC legacy mode => mmc rescan 0
# Write a single block to sector 0x4000 fails with ERROR => mmc write 20000000 4000 1
# Write a single block to sector 0x4000 now works => mmc write 20000000 4000 1
With the MMC_SPEED_MODE_SET Kconfig option enabled.
Writing to eMMC using HS200 mode work more reliably than slower modes on RK35xx boards. Enable MMC_HS200_SUPPORT Kconfig option by default to prefer use of HS200 mode on RK356x and RK3588.
Signed-off-by: Jonas Karlman jonas@kwiboo.se
Changes in v2:
- Imply MMC_HS200_SUPPORT and SPL_MMC_HS200_SUPPORT in arch Kconfig instead of adding to each boards defconfig
- R-b tags not collected because of above change
- Combine changes for rk356x and rk3588 in one patch
- Update commit message
Link to v1: https://patchwork.ozlabs.org/patch/1891693/
arch/arm/mach-rockchip/Kconfig | 4 ++++ configs/nanopi-r5c-rk3568_defconfig | 2 -- configs/nanopi-r5s-rk3568_defconfig | 2 -- configs/radxa-e25-rk3568_defconfig | 2 -- 4 files changed, 4 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-rockchip/Kconfig b/arch/arm/mach-rockchip/Kconfig index 6ff0aa6911e2..946ef5d7023d 100644 --- a/arch/arm/mach-rockchip/Kconfig +++ b/arch/arm/mach-rockchip/Kconfig @@ -292,6 +292,8 @@ config ROCKCHIP_RK3568 imply OF_LIBFDT_OVERLAY imply ROCKCHIP_OTP imply MISC_INIT_R
- imply MMC_HS200_SUPPORT if MMC_SDHCI_ROCKCHIP
MMC_SDHCI_ROCKCHIP is also required for eMMC on RK3399, which would change the current default, at the very least for Puma RK3399.
Doing a:
rg -lU --multiline-dotall 'RK3399.*MMC_HS.*' configs/
Only returns: configs/evb-rk3399_defconfig configs/pinebook-pro-rk3399_defconfig
and there are 29 defconfigs for RK3399-based boards right now, so maybe that's a bit too big of a change?
The imply statements added in this patch should only affect ROCKCHIP_RK3568 and ROCKCHIP_RK3588, nothing should change for RK3399, at least not intentionally.
Regards, Jonas
Cheers, Quentin
Hi Jonas,
On 2/5/24 14:05, Jonas Karlman wrote:
Hi Quentin,
On 2024-02-05 10:47, Quentin Schulz wrote:
Hi Jonas,
On 2/4/24 21:53, Jonas Karlman wrote:
Testing has shown that writing to eMMC using a slower mode then HS200 typically generate an ERROR on first attempt on RK3588.
# Rescan using MMC legacy mode => mmc rescan 0 # Write a single block to sector 0x4000 fails with ERROR => mmc write 20000000 4000 1 # Write a single block to sector 0x4000 now works => mmc write 20000000 4000 1With the MMC_SPEED_MODE_SET Kconfig option enabled.
Writing to eMMC using HS200 mode work more reliably than slower modes on RK35xx boards. Enable MMC_HS200_SUPPORT Kconfig option by default to prefer use of HS200 mode on RK356x and RK3588.
Signed-off-by: Jonas Karlman jonas@kwiboo.se
Changes in v2:
- Imply MMC_HS200_SUPPORT and SPL_MMC_HS200_SUPPORT in arch Kconfig instead of adding to each boards defconfig
- R-b tags not collected because of above change
- Combine changes for rk356x and rk3588 in one patch
- Update commit message
Link to v1: https://patchwork.ozlabs.org/patch/1891693/
arch/arm/mach-rockchip/Kconfig | 4 ++++ configs/nanopi-r5c-rk3568_defconfig | 2 -- configs/nanopi-r5s-rk3568_defconfig | 2 -- configs/radxa-e25-rk3568_defconfig | 2 -- 4 files changed, 4 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-rockchip/Kconfig b/arch/arm/mach-rockchip/Kconfig index 6ff0aa6911e2..946ef5d7023d 100644 --- a/arch/arm/mach-rockchip/Kconfig +++ b/arch/arm/mach-rockchip/Kconfig @@ -292,6 +292,8 @@ config ROCKCHIP_RK3568 imply OF_LIBFDT_OVERLAY imply ROCKCHIP_OTP imply MISC_INIT_R
- imply MMC_HS200_SUPPORT if MMC_SDHCI_ROCKCHIP
MMC_SDHCI_ROCKCHIP is also required for eMMC on RK3399, which would change the current default, at the very least for Puma RK3399.
Doing a:
rg -lU --multiline-dotall 'RK3399.*MMC_HS.*' configs/
Only returns: configs/evb-rk3399_defconfig configs/pinebook-pro-rk3399_defconfig
and there are 29 defconfigs for RK3399-based boards right now, so maybe that's a bit too big of a change?
The imply statements added in this patch should only affect ROCKCHIP_RK3568 and ROCKCHIP_RK3588, nothing should change for RK3399, at least not intentionally.
Clearly misread the patch, sorry for the noise.
Reviewed-by: Quentin Schulz quentin.schulz@theobroma-systems.com
Cheers, Quentin
Testing has shown that writing to eMMC using HS400 modes on RK3568 result in an ERROR.
Change the tap number for transmit clock to fix this.
Also stop DLL when config_dll() is called to disable DLL.
Signed-off-by: Jonas Karlman jonas@kwiboo.se --- Changes in v2: - New patch to fix HS400 mode write on RK3568 --- drivers/mmc/rockchip_sdhci.c | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/mmc/rockchip_sdhci.c b/drivers/mmc/rockchip_sdhci.c index 285332d9f4fd..706fb1235796 100644 --- a/drivers/mmc/rockchip_sdhci.c +++ b/drivers/mmc/rockchip_sdhci.c @@ -71,7 +71,6 @@ #define DLL_RXCLK_NO_INVERTER BIT(29) #define DLL_RXCLK_ORI_GATE BIT(31) #define DLL_TXCLK_TAPNUM_DEFAULT 0x10 -#define DLL_TXCLK_TAPNUM_90_DEGREES 0x9 #define DLL_TXCLK_TAPNUM_FROM_SW BIT(24) #define DLL_TXCLK_NO_INVERTER BIT(29) #define DLL_STRBIN_TAPNUM_DEFAULT 0x4 @@ -314,8 +313,10 @@ static int rk3568_sdhci_config_dll(struct sdhci_host *host, u32 clock, bool enab int val, ret; u32 extra, txclk_tapnum;
- if (!enable) + if (!enable) { + sdhci_writel(host, 0, DWCMSHC_EMMC_DLL_CTRL); return 0; + }
if (clock >= 100 * MHz) { /* reset DLL */ @@ -648,7 +649,7 @@ static const struct sdhci_data rk3568_data = { .config_dll = rk3568_sdhci_config_dll, .flags = FLAG_INVERTER_FLAG_IN_RXCLK, .hs200_txclk_tapnum = DLL_TXCLK_TAPNUM_DEFAULT, - .hs400_txclk_tapnum = DLL_TXCLK_TAPNUM_DEFAULT, + .hs400_txclk_tapnum = 0x8, };
static const struct sdhci_data rk3588_data = { @@ -656,7 +657,7 @@ static const struct sdhci_data rk3588_data = { .set_clock = rk3568_sdhci_set_clock, .config_dll = rk3568_sdhci_config_dll, .hs200_txclk_tapnum = DLL_TXCLK_TAPNUM_DEFAULT, - .hs400_txclk_tapnum = DLL_TXCLK_TAPNUM_90_DEGREES, + .hs400_txclk_tapnum = 0x9, };
static const struct udevice_id sdhci_ids[] = {
On 2024/2/5 04:53, Jonas Karlman wrote:
Testing has shown that writing to eMMC using HS400 modes on RK3568 result in an ERROR.
Change the tap number for transmit clock to fix this.
Also stop DLL when config_dll() is called to disable DLL.
Signed-off-by: Jonas Karlman jonas@kwiboo.se
Reviewed-by: Kever Yang kever.yang@rock-chips.com
Thanks, - Kever
Changes in v2:
- New patch to fix HS400 mode write on RK3568
drivers/mmc/rockchip_sdhci.c | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/mmc/rockchip_sdhci.c b/drivers/mmc/rockchip_sdhci.c index 285332d9f4fd..706fb1235796 100644 --- a/drivers/mmc/rockchip_sdhci.c +++ b/drivers/mmc/rockchip_sdhci.c @@ -71,7 +71,6 @@ #define DLL_RXCLK_NO_INVERTER BIT(29) #define DLL_RXCLK_ORI_GATE BIT(31) #define DLL_TXCLK_TAPNUM_DEFAULT 0x10 -#define DLL_TXCLK_TAPNUM_90_DEGREES 0x9 #define DLL_TXCLK_TAPNUM_FROM_SW BIT(24) #define DLL_TXCLK_NO_INVERTER BIT(29) #define DLL_STRBIN_TAPNUM_DEFAULT 0x4 @@ -314,8 +313,10 @@ static int rk3568_sdhci_config_dll(struct sdhci_host *host, u32 clock, bool enab int val, ret; u32 extra, txclk_tapnum;
- if (!enable)
if (!enable) {
sdhci_writel(host, 0, DWCMSHC_EMMC_DLL_CTRL);return 0;
}
if (clock >= 100 * MHz) { /* reset DLL */
@@ -648,7 +649,7 @@ static const struct sdhci_data rk3568_data = { .config_dll = rk3568_sdhci_config_dll, .flags = FLAG_INVERTER_FLAG_IN_RXCLK, .hs200_txclk_tapnum = DLL_TXCLK_TAPNUM_DEFAULT,
- .hs400_txclk_tapnum = DLL_TXCLK_TAPNUM_DEFAULT,
.hs400_txclk_tapnum = 0x8, };
static const struct sdhci_data rk3588_data = {
@@ -656,7 +657,7 @@ static const struct sdhci_data rk3588_data = { .set_clock = rk3568_sdhci_set_clock, .config_dll = rk3568_sdhci_config_dll, .hs200_txclk_tapnum = DLL_TXCLK_TAPNUM_DEFAULT,
- .hs400_txclk_tapnum = DLL_TXCLK_TAPNUM_90_DEGREES,
.hs400_txclk_tapnum = 0x9, };
static const struct udevice_id sdhci_ids[] = {
participants (5)
-
Dragan Simic -
Jonas Karlman -
Kever Yang -
Quentin Schulz -
Weizhao Ouyang