sdhci_msm issues with cold-plugged SD cards

sdhci_msm issues with cold-plugged SD cards

[Iskren Chernev]

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!

Regards,
Iskren Chernev

Re: sdhci_msm issues with cold-plugged SD cards

[Ulf Hansson]

+ 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

Re: sdhci_msm issues with cold-plugged SD cards

[Veerabhadrarao Badiganti]

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

Re: sdhci_msm issues with cold-plugged SD cards

[Iskren Chernev]

On 5/26/20 4:01 PM, Veerabhadrarao Badiganti wrote:
> 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...

I put 25ms, and 100ms, it doesn't seem to make any difference.

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

The device uses a Qcom msm8974-pro. There is SoC dtsi and device dts
(samsung-klte). I used a 5.6-rc6 kernel when I reported this, but now tried on
next-20200526 and the results are the same.

> Thanks
> Veera
>
>