Re: [PATCH v2] Revert "mmc: sdhci_am654: Add sdhci_am654_start_signal_voltage_switch"
From: Sverdlin, Alexander
Date: Wed Mar 19 2025 - 06:23:18 EST
Hi Judith, Ulf,
On Wed, 2025-02-05 at 13:39 -0600, Judith Mendez wrote:
> Hi all,
>
> On 1/27/25 2:12 PM, Josua Mayer wrote:
> > This reverts commit 941a7abd4666912b84ab209396fdb54b0dae685d.
> >
> > This commit uses presence of device-tree properties vmmc-supply and
> > vqmmc-supply for deciding whether to enable a quirk affecting timing of
> > clock and data.
> > The intention was to address issues observed with eMMC and SD on AM62
> > platforms.
> >
> > This new quirk is however also enabled for AM64 breaking microSD access
> > on the SolidRun HimmingBoard-T which is supported in-tree since v6.11,
> > causing a regression. During boot microSD initialization now fails with
> > the error below:
> >
> > [ 2.008520] mmc1: SDHCI controller on fa00000.mmc [fa00000.mmc] using ADMA 64-bit
> > [ 2.115348] mmc1: error -110 whilst initialising SD card
> >
> > The heuristics for enabling the quirk are clearly not correct as they
> > break at least one but potentially many existing boards.
> >
> > Revert the change and restore original behaviour until a more
> > appropriate method of selecting the quirk is derived.
>
>
> Somehow I missed these emails, apologies.
>
> Thanks for reporting this issue Josua.
>
> We do need this patch for am62x devices since it fixes timing issues
> with a variety of SD cards on those boards, but if there is a
> regression, too bad, patch had to be reverted.
>
> I will look again into how to implement this quirk, I think using the
> voltage regulator nodes to discover if we need this quirk might not have
> been a good idea, based on your explanation. I believe I did test the
> patch on am64x SK and am64x EVM boards and saw no boot issue there,
> so the issue seems related to the voltage regulator nodes existing in DT
> (the heuristics for enabling the quirk) as you call it.
>
> Again, thanks for reporting, will look into fixing this issue for am62x
> again soon.
does it mean, that 14afef2333af
("arm64: dts: ti: k3-am62-main: Update otap/itap values") has to be reverted
as well, for the time being?
--
Alexander Sverdlin
Siemens AG
www.siemens.com