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:
>> Hi Nicolas,
>>
>> Am 22.03.21 um 19:58 schrieb Nicolas Saenz Julienne:
>>> From: Nicolas Saenz Julienne <nsaenzjulienne@xxxxxxx>
>>>
>>> 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@xxxxxxxxxx>
>>> ---
>>> 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
