Odroid-C1 regression with commit 4bc31edebde5 ("mmc: core: Set HS clock speed before sending HS CMD13")

Thorsten Leemhuis regressions at leemhuis.info
Mon Sep 11 01:48:35 PDT 2023


On 29.08.23 11:59, Linux regression tracking (Thorsten Leemhuis) wrote:
> Hi, Thorsten here, the Linux kernel's regression tracker. Top-posting
> for once, to make this easily accessible to everyone.
> 
> I still have this regression (caused by a commit from Brian, applied by
> Ulf) on my list of tracked issues. Was there any progress to finally get
> this fixed[1]? Doesn't look like it from here, but I might have easily
> missed something, that's why I'm asking.
> 
> [1] this patch from Ziyang Huang afaics was supposed to help, but it
> went nowhere afaics
> https://lore.kernel.org/linux-amlogic/TYZPR01MB5556B56D834E02F41C44D81DC95FA@TYZPR01MB5556.apcprd01.prod.exchangelabs.com/
> 
> Or does anybody stop caring?

No reply, then I assume that's the case. In that case I won't waste any
cycles tracking this:

#regzbot inconclusive: seem nobody cares anymore

Martin, if this is wrong and you want to see this fixed, please speak up.

Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
--
Everything you wanna know about Linux kernel regression tracking:
https://linux-regtracking.leemhuis.info/about/#tldr
If I did something stupid, please tell me, as explained on that page.

> On 20.06.23 11:53, Ulf Hansson wrote:
>> On Mon, 19 Jun 2023 at 21:54, Martin Blumenstingl
>> <martin.blumenstingl at googlemail.com> wrote:
>>>
>>> On Wed, Jun 14, 2023 at 5:49 PM Ulf Hansson <ulf.hansson at linaro.org> wrote:
>>> [...]
>>>>> Full register dump:
>>>>> # cat /sys/kernel/debug/regmap/c1108e00.mmc/registers
>>>>> 00: 00000900
>>>>> 04: 0000004d
>>>>> 08: e7ffe002
>>>>> 0c: 02f0003f
>>>>> 10: 0003f009
>>>>> 14: 03b81c00
>>>>> 18: 2c43bcf0
>>>>> 1c: e0000150
>>>>> 20: 00000000
>>>>> 24: 00003067
>>>>> 28: 00000000
>>>>> 2c: 00000000
>>>>> 30: 00000000
>>>>> 34: 00fe0cff
>>>>> 38: 0000100b
>>>>>
>>>>> In case you are curious, the driver is: drivers/mmc/host/meson-mx-sdhc-mmc.c
>>>>
>>>> Thanks for sharing this data!
>>>>
>>>> I assume the above registers indicate that we have sent the command
>>>> and are now waiting for an IRQ for a response/error, but we never
>>>> receive one.
>>>>
>>>> To really figure out what is going on, I think we need to do some
>>>> additional low level debugging/testing.
>>>>
>>>> I was looking at the commit message from e4bf1b0970ef ("mmc: host:
>>>> meson-mx-sdhc: new driver for the Amlogic Meson SDHC host"), which
>>>> indicates that the clock management is quite limited for this HW. For
>>>> example, the 51000000Hz isn't one of the supported frequencies. Could
>>>> that be the reason for the problem? Perhaps if we play with changing
>>>> the frequency to something that is considered supported - then can we
>>>> make this work?
>>> You seem to be more familiar with this Amlogic MMC controller than I am ;-)
>>
>> Sometimes a well written commit message actually helps. :-)
>>
>>> Today I finally had some time for testing and when I started Ziyang
>>> Huang provided a patch [0] (admittedly: I think it needs to be
>>> improved, but finally we know that it's a MMC controller driver
>>> limitation and not an MMC core bug)
>>
>> Great news!
>>
>> I will continue to monitor the thread and defer to apply anything
>> until you have given it your blessing, of course.
>>
>> Kind regards
>> Uffe



More information about the linux-amlogic mailing list