From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 747F8CF885B for ; Fri, 4 Oct 2024 20:43:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Type: Content-Transfer-Encoding:MIME-Version:References:In-Reply-To:Message-ID:Date :Subject:Cc:To:From:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=/3WqLUyp55MFWyio5AkOs6mN8Dn13D5CQnQY7Az5rxg=; b=wnP5KZIHag1ONNUq1gzkvbZg2V 5PHVDUKewXiE2CFUhbDdGNjU8HBed+MPF2qtMxy7wDwbzpmoMm8uPEPM2JnvwokuMoT5Oaaw2/48j 1Y4uytWfWiim6EQfjnzAmz8NcdrDf7toVBjIch6+lbYxg0S6PFfI7c+qnKXhtUYAi1KmHLxRmi2A9 OVLnWOX4KGf5A0WA1pByG5uDeSttjaWCeGS74jwEQP0dm51rEJCsImQHb8NHeq/CEzeM08aR9ivJg us7EM0IijquuRWeauKBqPnP3S9zj7ujaIoBBd1HHeneAb75qGxh0CptmFH0CedkMrvsi8aD2twF23 MFMf8mMw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98 #2 (Red Hat Linux)) id 1swp9K-0000000EBco-2zoz; Fri, 04 Oct 2024 20:43:42 +0000 Received: from gloria.sntech.de ([185.11.138.130]) by bombadil.infradead.org with esmtps (Exim 4.98 #2 (Red Hat Linux)) id 1swp7z-0000000EBHQ-0i7L; Fri, 04 Oct 2024 20:42:20 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sntech.de; s=gloria202408; h=Content-Type:Content-Transfer-Encoding:MIME-Version: References:In-Reply-To:Message-ID:Date:Subject:Cc:To: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=/3WqLUyp55MFWyio5AkOs6mN8Dn13D5CQnQY7Az5rxg=; b=BII+msqzNxCU2zL5wLSSVvPT/E BKsCjmFV6ImfzbP530vw0hwcDEdsguXF5ibc0HcBe+K2tlfD8LnGq7QsYn5pVhiLXWe/1mZ/+pXDv pbSqATlBSNRPtMmLpXAZ0O83raw1aeprHObqombUi+R/EmUaYYUCPpyrAHtg8cxi9GqStiAwx1tJY UZI+la1C1hrtY4QeqsHfdwlBvG0UOHujGoW1UIkxusd8A1dtDPbeSPO1TNBc9Ba0T1/n40SyeI2SR DR1oZl5npe/Zf+Rh/2iqXeYK+YtjwyorVGkzqAYjnO420WZLIZlGTJ14G9TPW/olWaKfgCxCfu83t bMY8hc6w==; Received: from i5e8616d7.versanet.de ([94.134.22.215] helo=diego.localnet) by gloria.sntech.de with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1swp7o-0003kO-KH; Fri, 04 Oct 2024 22:42:08 +0200 From: Heiko =?ISO-8859-1?Q?St=FCbner?= To: Ulf Hansson , Kever Yang , Robin Murphy Cc: linux-rockchip@lists.infradead.org, Jaehoon Chung , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-mmc@vger.kernel.org Subject: Re: [PATCH] mmc: dw_mmc: rockchip: Keep controller working for card detect Date: Fri, 04 Oct 2024 22:42:07 +0200 Message-ID: <1846973.TLkxdtWsSY@diego> In-Reply-To: <69d06c04-cc8c-4435-a622-33d5dcd1fa24@arm.com> References: <20240912152538.1.I858c2a0bf83606c8b59ba1ab6944978a398d2ac5@changeid> <69d06c04-cc8c-4435-a622-33d5dcd1fa24@arm.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20241004_134219_254993_F82D6EE0 X-CRM114-Status: GOOD ( 23.89 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Am Freitag, 4. Oktober 2024, 19:34:33 CEST schrieb Robin Murphy: > On 02/10/2024 10:55 pm, Ulf Hansson wrote: > > On Sat, 14 Sept 2024 at 13:52, Heiko St=FCbner wrote: > >> > >> Am Donnerstag, 12. September 2024, 09:26:14 CEST schrieb Kever Yang: > >>> In order to make the SD card hotplug working we need the card detect > >>> function logic inside the controller always working. The runtime PM w= ill > >>> gate the clock and the power domain, which stops controller working w= hen > >>> no data transfer happen. > >>> > >>> So lets skip enable runtime PM when the card needs to detected by the > >>> controller and the card is removable. > >>> > >>> Signed-off-by: Kever Yang > >> > >> So for the change itself this looks good, i.e. it fixes an issue for b= aords relying > >> on the on-chip-card-detect. > >> > >> > >> But for boards doing that, the controller will be running _all the tim= e_ > >> even if there is never any card inserted. > >> > >> So relying on the on-soc card-detect will effectively increase the pow= er- > >> consumption of the board - even it it'll never use any sd-card? > >=20 > > Good point! A better option is to use a polling based mechanism - and > > we have MMC_CAP_NEEDS_POLL for exactly that. > >=20 > > Moreover, on DT based platforms one can even use the "broken-cd" > > property to indicate this. >=20 > Except that goes further than is needed here, since it would fall back=20 > entirely to software-based polling for card presence. In this case the=20 > CD function is not broken in terms of actually detecting a card, it just= =20 > doesn't work to wake the controller up from suspend because it can't=20 > fire its own interrupt while powered off. In principle all we should=20 > require here is to periodically resume/suspend the device, to provide a=20 > window for the interrupt to work and normal operation to take over if=20 > appropriate. >=20 > Of course the really clever way would be for suspend to switch the pin=20 > into GPIO mode, and set the GPIO interrupt as a wakeup to trigger resume= =20 > and switch it back again, but perhaps that's a bit tricky without=20 > explicit pinctrl states in the DT :/ and then the question really becomes, why move away from cd-gpios at all.