Date: Thu, 13 Sep 2018 18:11:27 +0200 From: Jakob Alvermark <jakob@alvermark.net> To: Marius Strobl <marius@freebsd.org> Cc: FreeBSD Current <freebsd-current@FreeBSD.org> Subject: Re: SD card reader only works after a suspend/resume Message-ID: <d07fe9bc-900d-19df-5555-42ec1ac2fd4b@alvermark.net> In-Reply-To: <20180912221319.GL21523@alchemy.franken.de> References: <34659383-981f-e627-dfaa-d486685a11f5@alvermark.net> <20180906224108.GA65506@alchemy.franken.de> <3a219e6e-0e27-00d7-50ff-e6671f717bc6@alvermark.net> <20180912221319.GL21523@alchemy.franken.de>
next in thread | previous in thread | raw e-mail | index | archive | help
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. Jakob
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?d07fe9bc-900d-19df-5555-42ec1ac2fd4b>