SD card reader only works after a suspend/resume
Jakob Alvermark
jakob at alvermark.net
Fri Sep 14 20:25:59 UTC 2018
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 @ 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
More information about the freebsd-current
mailing list