[PATCH RESEND v3 0/3] Add ti,suppress-v1p8-ena

[Judith Mendez]

Hi Nishanth,

On 4/23/25 1:08 PM, Nishanth Menon wrote:
> On 17:05-20250422, Judith Mendez wrote:
>> Resend patch series to fix cc list
>>
>> There are MMC boot failures seen with V1P8_SIGNAL_ENA on Kingston eMMC
>> and Microcenter/Patriot SD cards on Sitara K3 boards due to the HS200
>> initialization sequence involving V1P8_SIGNAL_ENA. Since V1P8_SIGNAL_ENA
>> is optional for eMMC, do not set V1P8_SIGNAL_ENA by default for eMMC.
>> For SD cards we shall parse DT for ti,suppress-v1p8-ena property to
>> determine whether to suppress V1P8_SIGNAL_ENA. Add new ti,suppress-v1p8-ena
>> to am62x, am62ax, and am62px SoC dtsi files since there is no internal LDO
>> tied to sdhci1 interface so V1P8_SIGNAL_ENA only affects timing.
>>
>> This fix was previously merged in the kernel, but was reverted due
>> to the "heuristics for enabling the quirk"[0]. This issue is adressed
>> in this patch series by adding optional ti,suppress-v1p8-ena DT property
>> which determines whether to apply the quirk for SD.
> [...]
>>
>> [0] https://lore.kernel.org/linux-mmc/20250127-am654-mmc-regression-v2-1-9bb39fb12810@solid-run.com/
> 
> Why cant we use compatible to enable the quirk instead of blindly
> enabling for all IPs including ones that have onchip LDOs? That was the
> reason it failed in the first place for am64x.

We made an assumption that did not work out.

> 
> This is very much like a quirk that seems to go hand-in-hand with the
> compatible for am62-sdhci ?
> 
> Is it worth exploring that option in the driver thread? from where I
> stand, this sounds very much like an issue that AM62x IP has, and should
> be handled by the driver instead of punting to dts to select where to
> use and not to use the quirk.
> 

Sure, I can test this out and respin the series. It does seem like a
more clean solution, thanks for reviewing.

~ Judith