Re: sdhci_msm issues with cold-plugged SD cards

From: Veerabhadrarao Badiganti <vbadigan@codeaurora.org>
To: Ulf Hansson <ulf.hansson@linaro.org>,
	Iskren Chernev <iskren.chernev@gmail.com>
Cc: kernelnewbies@kernelnewbies.org,
	"linux-mmc@vger.kernel.org" <linux-mmc@vger.kernel.org>,
	Bjorn Andersson <bjorn.andersson@linaro.org>,
	Sarthak Garg <sartgarg@codeaurora.org>
Subject: Re: sdhci_msm issues with cold-plugged SD cards
Date: Tue, 26 May 2020 18:31:56 +0530	[thread overview]
Message-ID: <d268a70b-a938-ab37-cca1-9a1322ad3cae@codeaurora.org> (raw)
In-Reply-To: <CAPDyKFqAWVPU=mJ=RzMyJsBiMTfSQqFTXw1oLqb=cZCM4e9ebw@mail.gmail.com>

On 5/25/2020 2:44 PM, Ulf Hansson wrote:
> + Bjorn, Sarthak, Veerabhadrarao
>
> On Fri, 22 May 2020 at 17:51, Iskren Chernev <iskren.chernev@gmail.com> wrote:
>>
>> Hello,
>>
>> I'm trying to add SD Card support to a smartphone (Samsung Galaxy S5). After
>> configuring the sdhci-msm driver through DT, it all seems to work fine except
>> the case when the phone boots with the SD card inserted. If the card is
>> re-inserted, or the driver is polling, or the probe code is forcefully executed
>> a second time the card is properly detected.
>>
>> I logged the SD interrupts, commands and responses, and it looks like the
>> hardware is returning Command Index Error and/or Command End Bit Error via the
>> Error Interrupt Status Register, which gets converted to -EILSEQ error. On
>> a second attempt (due to re-insertion, polling or re-execution) these errors
>> are missing, and the card behaves correctly.
>>
>> On the downstream kernel, these errors resulting in EILSEQ do not appear, so it
>> might be related to setup. Also I see that sdhci-msm driver has hardcoded
>> a SDHCI_QUIRK_BROKEN_CARD_DETECTION quirk, which might imply that polling
>> should be used (instead Card Detection GPIO), in which case this issue won't
>> manifest itself. But polling wastes power, and the Card Detect pin works well,
>> at least for this device, so I feel it can be made better.
>>
>> Any suggestions on how to track this down are appreciated!
> I think the device is intended to be used with GPIO card detection.
> Polling mode shouldn't be needed if there is GPIO.
>
> Anyway, to me it sounds like the HW/controller isn't properly
> initialized during ->probe(), but I can't help you much more than
> that. I have looped in some of the recent active sdhci-msm developers
> to see if they have some ideas that we can try.
>
> Kind regards
> Uffe
Strange issue. We never encountered this issue internally.
Please define "post-power-on-delay-ms" dt property with some larger 
delay value (25ms?)
and see if that helps you...

If this doesn't work, let me know the Qcom SoC (name/number) present on 
that phone.
And the kernel that you are using.

Thanks
Veera