From owner-freebsd-current@freebsd.org Thu Sep 13 16:11:30 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 A0BA9109234D for ; Thu, 13 Sep 2018 16:11:30 +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 3EB6277843; Thu, 13 Sep 2018 16:11:29 +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 1g0UDH-0005fd-KL; Thu, 13 Sep 2018 18:11:27 +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:Subject:From: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=QqI9kef6zXoD04Rc7uulP/uNSQhxbMXhVohW1UlG9nk=; b=FBvhUbYegiDfRVMv/0aYzS/6Tk d91halCH8nkwy/ozlM8GrXwlDLYp0nGBozau+gN+8xpjkCLh9HXAGLNrrxE4/BzO8nlWXSmifay8q 0k1iYWQzxER7hrF8/V5rX9UJd8gtJay+4m30PMu0tM9Mj4p7pVDRWSGzF9bhOfIKhmw0+Q1H0iXil TOHlJpXEsYTmni2Zhs7fn9ju0OR35VdSGvSjFCIdGEoN5HgrYYW5fVkyKAUiYcgRmYyCS301bky2L gbONs/LUE8sD2tgVWtLVygq3jd1sUlL0t2IDY31U+xhhiQYt+wAiptktTwQqkeT82is0Ex/HVTVLM 5W4rD4zA==; 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 1g0UDH-000MY3-3i; Thu, 13 Sep 2018 18:11:27 +0200 From: Jakob Alvermark Subject: Re: SD card reader only works after a suspend/resume 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: Thu, 13 Sep 2018 18:11:27 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: <20180912221319.GL21523@alchemy.franken.de> 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: Thu, 13 Sep 2018 16:11:30 -0000 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. Jakob