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=-3.9 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 6C118C47094 for ; Thu, 10 Jun 2021 09:27:03 +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 35C3E61182 for ; Thu, 10 Jun 2021 09:27:03 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 35C3E61182 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linaro.org 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:Cc:To:Subject:Message-ID:Date:From: In-Reply-To:References:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=bKm2q2e9gTCcwYZS6+CAEWUistm9Oj4hY5qWKsmcLIY=; b=BKqHldYPcRe3k7 1k4XNv2bp7k5rng1bk+elh0jIhtXvhJiRSBPev93aFGKipyGCBfVQ7829kgN5rNQ+L5YOgUqwG3nF i0SNUtBHvSTExtsrRiX8PxkM3qTSdwM7fy8S9FkRpYOsvbWWOANvbPQY2puX3ibOMIYNG1fFyGH1p ykZpper4cX+e+xosuT1ooPUheLTwY1LyB1xRQXy0WonC4y9hLemAe7/1emH9KDofiNvLKxwHYk0/U JoU0J93ron3Uc9ZWsAOITDwfrb0TFnnBPyCm9/sxN3pOl+6Qel/IaTxBeLiFjULPFtAjzBlZnhiWD +s5zr4bOb05oJnWz0jhg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1lrGv5-000An5-NP; Thu, 10 Jun 2021 09:24:13 +0000 Received: from mail-vs1-xe35.google.com ([2607:f8b0:4864:20::e35]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1lrGOW-0000ML-RN for linux-arm-kernel@lists.infradead.org; Thu, 10 Jun 2021 08:50:34 +0000 Received: by mail-vs1-xe35.google.com with SMTP id f21so1457120vsl.4 for ; Thu, 10 Jun 2021 01:50:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0n9dDqvP+lODnMQ5qHqWheaeGBbbZs8YgGz8kfCeEwE=; b=JkDxdgQpwfa+eXaZCKAJkqqIgDJlXievjNrXMtpoIJp6+zIC1G25BQDrEvuVDpGRm0 plRQJtPmIF08MTR5knKoO2iTXQX9rfFxoUYK1L+9CoJGzLBgyyBwx9A2KiEzcstXgM1O jdozPW1VC/HCG1J4vEN2akMEAhUCrSxjOBZKfqP+rAojYe3Z9JLddsVNkYmJ2gh1CnWH H2iBlL5JptW+Ca+jEt9McBKUWVHQ4zVe6tUMJOlycNhGzY+g7kxeNsy/9gds+usgQgKI 3ZGc7l9fLcMiQgxSYGqeVPDXXHBBD17aSUmo81BIx5vk4U1jhPWmyNdlowhYaUs0ZTQz iiQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=0n9dDqvP+lODnMQ5qHqWheaeGBbbZs8YgGz8kfCeEwE=; b=r8J7VtcENUD4sMRws1mNL/UGMZptStsh3ZOwWxdtii5kEGgfO+WdIiJyOCot/6xsPM hf1gHYUPxpANZIEZ1l73Z/C63naUg04AqKd6W07rABSGCZoLt4eqScydjmWVdRCAPJ+H 3seqpqYT5ux9Vovi7hoE8JJGrHSZdHFHnjD2wR6RUbuPNPLH3ssA9qljLsGRm/QOoGR6 SFrs7TC5le4KWAbC5/no6LvlgK7P+xKUbIRGg72Kj06kg//pjv/WovsuxtshXKUEXwS9 PYGIQj1ZNKJ9U2A4OZceetHc5tEydlJG5alRieXtwwbbiFQvx6spThbWleZvT5IPWCuG QLBQ== X-Gm-Message-State: AOAM532BJ8IiUZq1rZQfUcJeyGlvQGEONP9bKVMhWWVpZ2e3yR8b9oqi tCzOCO1CAz7ehDC4mkH6CWEomYwB5qJp1iLAi8kz5Q== X-Google-Smtp-Source: ABdhPJzstZsJ7BuqoMSAVvMFwNv9YXy7kEZbmqM17vT0c7zJLt83fqECmPBoDLcuzViZxiKRyf+OKJntCcPl3ZSYZx0= X-Received: by 2002:a67:19c2:: with SMTP id 185mr521314vsz.34.1623315031276; Thu, 10 Jun 2021 01:50:31 -0700 (PDT) MIME-Version: 1.0 References: <20210602192758.38735-1-alcooperx@gmail.com> <20210602192758.38735-2-alcooperx@gmail.com> <6acd480a-8928-89bb-0f40-d278294973a1@gmail.com> In-Reply-To: <6acd480a-8928-89bb-0f40-d278294973a1@gmail.com> From: Ulf Hansson Date: Thu, 10 Jun 2021 10:49:55 +0200 Message-ID: Subject: Re: [PATCH 2/2] mmc: sdhci-iproc: Add support for the legacy sdhci controller on the BCM7211 To: Florian Fainelli , "Rafael J. Wysocki" , Linux PM Cc: 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 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210610_015032_939580_68DD3CC9 X-CRM114-Status: GOOD ( 33.22 ) 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 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. 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. Kind regards Uffe _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel