Re: SD card reader only works after a suspend/resume

From: Jakob Alvermark <jakob_at_alvermark.net>
Date: Fri, 14 Sep 2018 22:25:56 +0200
On 9/13/18 6:11 PM, Jakob Alvermark wrote:
> On 9/13/18 12:13 AM, Marius Strobl wrote:
>> On Fri, Sep 07, 2018 at 04:52:12PM +0200, Jakob Alvermark wrote:
>>> On 9/7/18 12:41 AM, Marius Strobl wrote:
>>>> On Thu, Sep 06, 2018 at 12:33:39PM +0200, Jakob Alvermark wrote:
>>>>> Hi,
>>>>>
>>>>>
>>>>> I discovered this by chance.
>>>>>
>>>>> The SD card reader in my laptop has never worked, but now I 
>>>>> noticed it
>>>>> does after suspending and resuming.
>>>>>
>>>>> The controller is probed and attached on boot:
>>>>>
>>>>> sdhci_acpi1: <Intel Bay Trail/Braswell SDXC Controller> iomem
>>>>> 0x90a00000-0x90a00fff irq 47 on acpi0
>>>>>
>>>>> But nothing happens if I put a card in. Unless I suspend and resume:
>>>>>
>>>>> mmc1: <MMC/SD bus> on sdhci_acpi1
>>>>> mmcsd0: 32GB <SDHC SL32G 8.0 SN 19CD02C0 MFG 11/2014 by 3 SD> at mmc1
>>>>> 50.0MHz/4bit/65535-block
>>>>>
>>>>> Then I can remove and replug cards and it seems to work just fine.
>>>> I believe that making SD card insertion/removal with the integrated
>>>> SDHCI controlers of newer Intel SoCs work out-of-the-box requires
>>>> support for ACPI GPE interrupts and ACPI GPIO events respectively to
>>>> be added to FreeBSD. Otherwise insertion/removal interrutps/events
>>>> aren't reported and polling the card present state doesn't generally
>>>> work as a workaround with these controllers either, unfortunately.
>>>> I'm not aware of anyone working on the former, though.
>>>>
>>>> Polling the card present state happens to work one time after SDHCI
>>>> initialization with these controllers which is why a card will be
>>>> attached when inserted as part of a suspend/resume cycle (resume of
>>>> mmc(4) had some bugs until some months ago, which probably explains
>>>> why that procedure hasn't worked as a workaround for you in the past).
>>>> Inserting the card before boot, unloading/loading sdhci_acpi.ko or
>>>> triggering detach/attach of sdhci_acpi(4) via devctl(8) should allow
>>>> to attach a card, too.
>>> If a card is inserted before booting it is not detected.
>>>
>>> Removing and inserting card after boot is not detected unless I suspend
>>> and resume.
>>>
>>> After I have suspended and resumed once, cards are detected. Removals
>>> and insertions are detected as they happen.
>> Okay, then you are seeing somewhat different behavior than I do. What
>> SoC model is this?
>
>
> CPU: Intel(R) Pentium(R) CPU  N3540  _at_ 2.16GHz (2166.73-MHz K8-class CPU)
>
>
>>   Are you loading a GPIO controller driver such as
>> bytgpio(4) or chvgpio(4)? Doing so might be sufficient to kick ACPI
>> GPIO events into working but would be missing dependency information
>> between drivers (which might explain what you are experiencing if
>> sdhci_acpi1 attaches first) and some other bits to do it properly.
>
>
> I have bytgpio_load="YES" in /boot/loader.conf
>
> But I tried removing it, doesn't change the behavior.
>
> With or without the bytgpio driver, inserting or removing cards is 
> only detected after a suspend/resume cycle of the computer.
>
>
>> Also, could you please try whether doing a suspend/resume cycle of
>> sdhci_acpi1 via devctl(8) only kicks the card detection into working?
>> That test should indicate whether the firmware plays a role in making
>> the latter work.
>
>
> Tried that.
>
> devctl suspend sdhci_acpi1
>
> devctl resume sdhci_acpi1
>
> Doesn't make any difference.
>
> Also tried devctl disable/enable. No change.


Additional research:

After boot, before any suspend/resume:

 From acpidump -d

         Device (SDHC)
         {
             Name (_ADR, Zero)  // _ADR: Address
             Name (_HID, "80860F16")  // _HID: Hardware ID
             Name (_CID, "PNP0D40" /* SDA Standard Compliant SD Host 
Controller */)  // _CID: Compatible ID
             Name (_DDN, "Intel(R) SD Card Controller - 80860F16") // 
_DDN: DOS Device Name
             Name (_UID, 0x03)  // _UID: Unique ID
             Name (RBUF, ResourceTemplate ()
             {
                 Memory32Fixed (ReadWrite,
                     0x00000000,         // Address Base
                     0x00001000,         // Address Length
                     _Y04)
                 Interrupt (ResourceConsumer, Level, ActiveLow, 
Exclusive, ,, )
                 {
                     0x0000002F,
                 }
                 GpioInt (Edge, ActiveBoth, SharedAndWake, PullNone, 0x2710,
                     "\\_SB.GPO0", 0x00, ResourceConsumer, ,
                     )
                     {   // Pin list
                         0x0026
                     }
                 GpioIo (Shared, PullDefault, 0x0000, 0x0000, 
IoRestrictionInputOnly,
                     "\\_SB.GPO0", 0x00, ResourceConsumer, ,
                     )
                     {   // Pin list
                         0x0026
                     }
             })


And indeed card detection is GPIO pin 38 (0x26):

No card:

gpioctl -l | grep "pin 38"

pin 38:    1    GPIO_S0_SC38<IN>

Card inserted:

gpioctl -l | grep "pin 38"

pin 38:    0    GPIO_S0_SC38<IN>


After suspend/resume card detection works:

mmc1: <MMC/SD bus> on sdhci_acpi1
mmcsd0: 32GB <SDHC SL32G 8.0 SN 19CD02C0 MFG 11/2014 by 3 SD> at mmc1 
50.0MHz/4bit/65535-block

But pin 38 is always 1, regardless if a card is inserted or not:

gpioctl -l | grep "pin 38"
pin 38:    1    GPIO_S0_SC38<IN>

And 'acpidump -d' fails:

acpidump: RSDT entry 12 is corrupt

Any clue on what's going on here?


Jakob
Received on Fri Sep 14 2018 - 18:25:59 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:18 UTC