Am 24.03.21 um 16:34 schrieb Nicolas Saenz Julienne:

Hi Stefan,

On Wed, 2021-03-24 at 16:16 +0100, Stefan Wahren wrote:

quoted

Hi Nicolas,

Am 22.03.21 um 19:58 schrieb Nicolas Saenz Julienne:

quoted

From: Nicolas Saenz Julienne <redacted>

Force emmc2's frequency to 150MHz as the default 100MHz (set by FW)
seems to interfere with the VPU clock when setup at frequencies bigger
than 500MHz (a pretty common case). This ends up causing unwarranted
SDHCI CMD hangs  when no SD card is present.

Signed-off-by: Nicolas Saenz Julienne <nsaenz@kernel.org>
---
 arch/arm/boot/dts/bcm2711-rpi-4-b.dts | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/boot/dts/bcm2711-rpi-4-b.dts b/arch/arm/boot/dts/bcm2711-rpi-4-b.dts
index 3b4ab947492a..9aa8408d9960 100644
--- a/arch/arm/boot/dts/bcm2711-rpi-4-b.dts
+++ b/arch/arm/boot/dts/bcm2711-rpi-4-b.dts

@@ -257,6 +257,12 @@ &emmc2 {

 	vqmmc-supply = <&sd_io_1v8_reg>;
 	vmmc-supply = <&sd_vcc_reg>;
 	broken-cd;
+	/*
+	 * Force the frequency to 150MHz as the default 100MHz seems to
+	 * interfere with the VPU clock when setup at frequencies bigger than
+	 * 500MHz, causing unwarranted CMD hangs.
+	 */
+	clock-frequency = <150000000>;

i don't want to bike-shed here, but is there any chance to solve this in
clk-bcm2835 in a less hacky way?

What do you have in mind?

Sorry, nothing specific.

All I can think of is adding some kind of heuristic to the clock's prepare()
callback. That said, I don't feel it would be a better solution than this.

Based on my limited knowledge and an old SD card specification, all
possibly connected devices could have different frequencies. So my
concern here is, that in case we limit the frequency to a specific value
we could break things just to suppress a warning.

More background information about this issue would be helpful.

Best regards