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 X-Spam-Level: X-Spam-Status: No, score=-2.2 required=3.0 tests=BAYES_00,DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED,DKIM_VALID,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id B7DE4C48BD1 for ; Fri, 11 Jun 2021 16:57:39 +0000 (UTC) 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 mail.kernel.org (Postfix) with ESMTPS id 7C6F5613C3 for ; Fri, 11 Jun 2021 16:57:39 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7C6F5613C3 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date: Message-ID:From:References:Cc:To:Subject:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Owner; bh=u2boXAxzqKw6qpwi9UL/iALYpoXgyxtR3lHnOE28bVw=; b=tBdu8bFTV8l05aDvkrOrGVDGjY wQ9r6L35sXUQEqjvwQwC79qMsN/bydLhbeW99Hej7zc62ZZrMsSv1TL8Y7L3/yYjDsONt3eyNNF0T NRot0iSdwDUwThsSkSr72Yr6xz9yrlGrY4iHSmX5Ylh92/hDVGJpsU4+vot/ZNsIaolOurYTr9zCQ T4P/yPV+3pxbU8eR+WTFLZrqivwT49RIiu0XyO4PbHa4KlKmgiP2WSE8U1nK+gIQHNaqFrRitPC0V KF/NvImIPz/2b0EoarDxCnTmY7BwsGg0baMpjnmmhqQXfg3ey4QmQFmi0U02WPzpLaTbBaDag095X sQDehU7A==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1lrkRn-006Aa0-El; Fri, 11 Jun 2021 16:55:55 +0000 Received: from mail-pg1-f177.google.com ([209.85.215.177]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1lrkRj-006AZB-Kj for linux-arm-kernel@lists.infradead.org; Fri, 11 Jun 2021 16:55:53 +0000 Received: by mail-pg1-f177.google.com with SMTP id t9so2947621pgn.4 for ; Fri, 11 Jun 2021 09:55:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=eOlkoTfGj5WVDhRnQCIRockeDZbW6gvXOn1hNr+Rd2g=; b=j+W9JDxX+UOqQOy1Rik3ezLT5/EwreVn5+ywE686P15vhF/BffKXoXFbwZiDEmcDJi sOY61C+BiW2e1xKMbHa4JcY2ItvGJ01q6u379JhYfarZuKrvCzZURJrG6Zkq9o30uy4i waP2xGRgt7ClLlo1ejFAsX/DEC+rIV8FZ8OKAcAk3VO4yk9iWotdOQ0nYcR67rLB1hkX zBZ5qY14X2G24UKU9gM8pksq7LqnaJPZIihJ/tltwqdNmXg2xEZB0V4fqP2EzW/2Wu4S TGABmAuxyGxc9TNkDuoXvaH6izjk0IXq65+QWFX708h0FHpLouv4us6O7NL/wwkWiqZi irsA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=eOlkoTfGj5WVDhRnQCIRockeDZbW6gvXOn1hNr+Rd2g=; b=bnqaRtk824uCHcqocfe8vhWkthVRnxQUzbMliygj3FUhbBb3Qgz4LzW3XFCvQCUruS Y/nl6hYF05ZImTEg9OGfcPAymrS29JpAlQe/SMvY2SMpK2/OAX4NnQXfIefcc9MH/yBt uIzsIA0xxnoUYzaL5fEqIEfu/TAsNBF9aU6EHqV1pcWN1b+f7O42DmdP+KSMcerN7SM5 cu+/K2FVkgQ+F/RCB+S+/t8QyhAva3eDQ1RogNW1N9siUHegNUAu551KRa71nOC5Oequ 6R4nbUt1MsCTMn7D99sMsom9Id5q87gzcx/sAK0kjoCXFuq76qBkJ6X7/SGQIA25xQFc ZIDg== X-Gm-Message-State: AOAM533xrYc8D6NMx70EPdiPoBv1uJq09XpaWvd5oBcoZ3Tg25Zhk3UR TWCAMRG+IFWn8Qa5HBnuPjU= X-Google-Smtp-Source: ABdhPJz9kNGw9WY8PUrVoC4RNkOSJInnurD+RcgOjd2YX86UFEggs6C6s2CjLfa6jif3g9podQ29eA== X-Received: by 2002:a63:5522:: with SMTP id j34mr4537401pgb.148.1623430489795; Fri, 11 Jun 2021 09:54:49 -0700 (PDT) Received: from [192.168.1.67] (99-44-17-11.lightspeed.irvnca.sbcglobal.net. [99.44.17.11]) by smtp.gmail.com with ESMTPSA id h12sm5829720pfq.72.2021.06.11.09.54.47 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 11 Jun 2021 09:54:49 -0700 (PDT) Subject: Re: [PATCH 2/2] mmc: sdhci-iproc: Add support for the legacy sdhci controller on the BCM7211 To: Ulf Hansson , Florian Fainelli Cc: "Rafael J. Wysocki" , Linux PM , Al Cooper , Linux Kernel Mailing List , Adrian Hunter , BCM Kernel Feedback , DTML , Linux ARM , linux-mmc , Nicolas Saenz Julienne , Ray Jui , Rob Herring , Scott Branden References: <20210602192758.38735-1-alcooperx@gmail.com> <20210602192758.38735-2-alcooperx@gmail.com> <6acd480a-8928-89bb-0f40-d278294973a1@gmail.com> From: Florian Fainelli Message-ID: Date: Fri, 11 Jun 2021 09:54:46 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Firefox/78.0 Thunderbird/78.10.2 MIME-Version: 1.0 In-Reply-To: Content-Language: en-US X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210611_095551_727311_52C97C15 X-CRM114-Status: GOOD ( 38.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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 6/11/2021 3:23 AM, Ulf Hansson wrote: > On Thu, 10 Jun 2021 at 17:59, Florian Fainelli wrote: >> >> >> >> On 6/10/2021 1:49 AM, Ulf Hansson wrote: >>> On Thu, 10 Jun 2021 at 01:59, Florian Fainelli wrote: >>>> >>>> >>>> >>>> On 6/9/2021 2:22 AM, Ulf Hansson wrote: >>>>> On Wed, 9 Jun 2021 at 05:07, Florian Fainelli wrote: >>>>>> >>>>>> >>>>>> >>>>>> On 6/8/2021 5:40 AM, Ulf Hansson wrote: >>>>>>> On Wed, 2 Jun 2021 at 21:28, Al Cooper wrote: >>>>>>>> >>>>>>>> Add support for the legacy Arasan sdhci controller on the BCM7211 and >>>>>>>> related SoC's. This includes adding a .shutdown callback to increase >>>>>>>> the power savings during S5. >>>>>>> >>>>>>> Please split this into two separate changes. >>>>>>> >>>>>>> May I also ask about the ->shutdown() callback and in relation to S5. >>>>>>> What makes the ->shutdown callback only being invoked for S5? >>>>>> >>>>>> It is not only called for S5 (entered via poweroff on a prompt) but also >>>>>> during kexec or reboot. The poweroff path is via: >>>>>> >>>>>> kernel_power_off() -> kernel_shutdown_prepare() -> device_shutdown() -> >>>>>> .shutdown() >>>>>> >>>>>> For kexec or reboot we do not really care about power savings since we >>>>>> are about to load a new image anyway, however for S5/poweroff we do care >>>>>> about quiescing the eMMC controller in a way that its clocks and the >>>>>> eMMC device can be put into low power mode since we will stay in that >>>>>> mode for seconds/hours/days until someone presses a button on their >>>>>> remote (or other wake-up sources). >>>>> >>>>> Hmm, I am not sure I understand correctly. At shutdown we don't care >>>>> about wake-up sources from the kernel point of view, instead we treat >>>>> everything as if it will be powered off. >>>> >>>> The same .shutdown() path is used whether you kexec, reboot or poweroff, >>>> but for poweroff we do care about allowing specific wake-up sources >>>> configured as such to wake-up the system at a later time, like GPIOs, >>>> RTC, etc. >>> >>> That's true, but using the ->shutdown() callbacks in this way would >>> certainly be a new use case. >>> >>> Most subsystems/drivers don't care about power management in those >>> callbacks, but rather just about managing a graceful shutdown. >>> >>> It sounds to me like you should have a look at the hibernation >>> path/callbacks instead - or perhaps even the system suspend >>> path/callback. Normally, that's where we care about power management. >> >> The platforms we use do not support hibernation, keep in mind that these >> are embedded SoCs that support the S2 (standby), S3 (mem) and poweroff >> suspend states, hibernation is not something that we can support. >> >>> >>> I have looped in Rafael, to allow him to share his opinion on this. >>> >>>> >>>>> >>>>> We put devices into low power state at system suspend and potentially >>>>> also during some of the hibernation phases. >>>>> >>>>> Graceful shutdown of the eMMC is also managed by the mmc core. >>>> >>>> AFAICT that calls mmc_blk_shutdown() but that is pretty much it, the >>>> SDHCI platform_driver still needs to do something in order to conserve >>>> power including disabling host->clk, otherwise we would not have done >>>> that for sdhci-brcmstb.c. >>> >>> That's not entirely correct. When mmc_bus_shutdown() is called for the >>> struct device* that belongs to an eMMC card, two actions are taken. >>> >>> *) We call mmc_blk_shutdown(), to suspend the block device queue from >>> receiving new I/O requests. >>> **) We call host->bus_ops->shutdown(), which is an eMMC specific >>> callback set to mmc_shutdown(). In this step, we do a graceful >>> shutdown/power-off of the eMMC card. >>> >>> When it comes to controller specific resources, like clocks and PM >>> domains, for example, those may very well stay turned on. Do deal with >>> these, then yes, you would need to implement the ->shutdown() >>> callback. But as I said above, I am not sure it's the right thing to >>> do. >> >> As explained before, we can enter S5 for an indefinite amount of time >> until a wake-up source wakes us up so we must conserve power, even if we >> happen to wake up the next second, we don't know that ahead of time. The >> point of calling sdhci_pltfm_suspend() here is to ensure that host->clk >> is turned off which cuts the eMMC controller digital clock, I forgot how >> much power we save by doing so, but every 10s of mW counts for us. > > I fully understand that you want to avoid draining energy, every > single uA certainly counts in cases like these. > > What puzzles me, is that your platform seems to keep some resources > powered on (like device clocks) when entering the system wide low > power state, S5. More on that below. > > In principle, I am wondering if it would be possible to use S5 as the > system-wide low power state for the system suspend path, rather than > S3, for example? In this way, we would be able to re-use already > implemented ->suspend|resume callbacks from most subsystems/drivers, I > believe. Or is there a problem with that? The specific platform this driver is used on (BCM7211) is only capable of supporting S2 and S5. There is no S3 because we have no provision on the board to maintain the DRAM supplies on and preserve the DRAM contents. This is a design choice that is different from the other Broadcom STB platforms where we offer S2, S3 and S5 and we have an On/off domain which is shutdown by hardware upon S3 or S5 entry and a small always on domain which remains on to service wake-up sources (infrared, timer, gpio, UART, etc.). S2 on this platform is implemented entirely in software/firmware and does make use of the regular suspend/resume calls. S5 is implemented in part in software/firmware and with the help of the hardware that will turn off external board components. We do need the help of the various software drivers (PCIe, Ethernet, GPIO, USB, UART, RTC, eMMC, SPI, etc.) to do their job and conserve power when we enter S5, hence the reason why all of our drivers implement ->shutdown() (in addition to needing that for kexec and ensure no DMA is left running). > > I think we need an opinion from Rafel to move forward. There is already an identical change done for sdhci-brcmstb.c, and the exact same rationale applied there since both sdhci-iproc.c and sdhci-brcmstb.c are used on this BCM7211 platform. In all honesty, I am a bit surprised that the Linux device driver model does not try to default the absence of a ->shutdown() to a ->suspend() call since in most cases they are functionally equivalent, or should be, in that they need to save power and quiesce the hardware, or leave enough running to support a wake-up event. Cheers -- Florian _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel