From owner-freebsd-current@freebsd.org Fri Sep 14 20:25:59 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2FA791092BD0 for ; Fri, 14 Sep 2018 20:25:59 +0000 (UTC) (envelope-from jakob@alvermark.net) Received: from out.alvermark.net (out.alvermark.net [185.34.136.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B3DCD703FC; Fri, 14 Sep 2018 20:25:58 +0000 (UTC) (envelope-from jakob@alvermark.net) Received: from c-42bc70d5.06-431-73746f70.bbcust.telenor.se ([213.112.188.66] helo=mail.alvermark.net) by out.alvermark.net with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91 (FreeBSD)) (envelope-from ) id 1g0uf7-0006nA-17; Fri, 14 Sep 2018 22:25:57 +0200 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=alvermark.net; s=x; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:References:Cc:To:From:Subject:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=OTGjyIzZCvZiXvfP4dg6JGrehyVeJX9BptQotdeG6pE=; b=fzYqcIZ8GthNf4oQ8Trv/A1OQW iMgXuzYPzagiiGyrTyF/ajKkwaLOycSZd2duQylvQ3l9Ubg6wGouDlahTRZ5nqU1gozSKSwCzHNYE HnDnst66JY4S72fH1xlf5KEx6S3n2fyMF1ZcIghcDLNRZeUcm8v1y3hx7NFeLWQ5GHN2+9CGR6nS6 pS74uS6LKZ3itYxXm2UoE+p5INQHtAgMGyOVKtmfJwi7j6k6IeM5DP586+C+03/IoEdYxXiEajw+V qsR/dGVYYvvWlhQAceSWpEbCB4BkVyrpRpBVLZfIZ+4k0G6ZMwkHsaZFIhsiqq8mSqT1jLyNcoVgT tHntEcCA==; Received: from [192.168.67.33] by mail.alvermark.net with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91 (FreeBSD)) (envelope-from ) id 1g0uf6-000ABo-H6; Fri, 14 Sep 2018 22:25:56 +0200 Subject: Re: SD card reader only works after a suspend/resume From: Jakob Alvermark To: Marius Strobl Cc: FreeBSD Current 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> Message-ID: Date: Fri, 14 Sep 2018 22:25:56 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2018 20:25:59 -0000 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: iomem >>>>> 0x90a00000-0x90a00fff irq 47 on acpi0 >>>>> >>>>> But nothing happens if I put a card in. Unless I suspend and resume: >>>>> >>>>> mmc1: on sdhci_acpi1 >>>>> mmcsd0: 32GB 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 Card inserted: gpioctl -l | grep "pin 38" pin 38:    0    GPIO_S0_SC38 After suspend/resume card detection works: mmc1: on sdhci_acpi1 mmcsd0: 32GB 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 And 'acpidump -d' fails: acpidump: RSDT entry 12 is corrupt Any clue on what's going on here? Jakob