From: Florian Fainelli <f.fainelli@gmail.com>
To: Bjorn Helgaas <helgaas@kernel.org>
Cc: Jim Quinlan <jim2101024@gmail.com>,
linux-pci@vger.kernel.org, Bjorn Helgaas <bhelgaas@google.com>,
Nicolas Saenz Julienne <nsaenzjulienne@suse.de>,
bcm-kernel-feedback-list@broadcom.com,
james.quinlan@broadcom.com,
Nicolas Saenz Julienne <nsaenz@kernel.org>,
Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>,
Rob Herring <robh@kernel.org>,
"moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE"
<linux-rpi-kernel@lists.infradead.org>,
"moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE"
<linux-arm-kernel@lists.infradead.org>,
open list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v1 4/4] PCI: brcmstb: add shutdown call to driver
Date: Thu, 3 Jun 2021 10:30:37 -0700 [thread overview]
Message-ID: <dbd96bb2-4873-a37c-567d-ffd731beb927@gmail.com> (raw)
In-Reply-To: <20210603172313.GA2123252@bjorn-Precision-5520>
On 6/3/21 10:23 AM, Bjorn Helgaas wrote:
> On Wed, May 26, 2021 at 10:03:47AM -0700, Florian Fainelli wrote:
>> On 5/25/21 2:18 PM, Bjorn Helgaas wrote:
>>> On Tue, Apr 27, 2021 at 01:51:39PM -0400, Jim Quinlan wrote:
>>>> The shutdown() call is similar to the remove() call except the former does
>>>> not need to invoke pci_{stop,remove}_root_bus(), and besides, errors occur
>>>> if it does.
>>>
>>> This doesn't explain why shutdown() is necessary. "errors occur"
>>> might be a hint, except that AFAICT, many similar drivers do invoke
>>> pci_stop_root_bus() and pci_remove_root_bus() (several of them while
>>> holding pci_lock_rescan_remove()), without implementing .shutdown().
>>
>> We have to implement .shutdown() in order to meet a certain power budget
>> while the chip is being put into S5 (soft off) state and still support
>> Wake-on-WLAN, for our latest chips this translates into roughly 200mW of
>> power savings at the wall. We could probably add a word or two in a v2
>> that indicates this is done for power savings.
>
> "Saving power" is a great reason to do this. But we still need to
> connect this to the driver model and the system-level behavior
> somehow.
>
> The pci_driver comment says @shutdown is to "stop idling DMA
> operations" and it hooks into reboot_notifier_list in kernel/sys.c.
> That's incorrect or at least incomplete because reboot_notifier_list
> isn't mentioned at all in kernel/sys.c, and I don't see the connection
> between @shutdown and reboot_notifier_list.
>
> AFAICT, @shutdown is currently used in this path:
>
> kernel_restart_prepare or kernel_shutdown_prepare
> device_shutdown
> dev->bus->shutdown
> pci_device_shutdown # pci_bus_type.shutdown
> drv->shutdown
>
> so we're going to either reboot or halt/power-off the entire system,
> and we're not going to use this device again until we're in a
> brand-new kernel and we re-enumerate the device and re-register the
> driver.
>
> I'm not quite sure how either of those fits into the power-saving
> reason. I guess going to S5 is probably via the kernel_power_off()
> path and that by itself doesn't turn off as much power to the PCIe
> controller as it could? And this new .shutdown() method will get
> called in that path and will turn off more power, but will still leave
> enough for wake-on-LAN to work? And when we *do* wake from S5,
> obviously that means a complete boot with a new kernel.
Correct, the S5 shutdown is via kernel_power_off() and will turn off all
that we can in the PCIe root complex and its PHY, drop the PCIe link to
the end-point which signals that the end-point can enter its own suspend
logic, too. And yes, when we do wake-up from S5 it means booting a
completely new kernel. S5 is typically implemented in our chips by
keeping just a little bit of logic active to service wake-up events
(infrared remotes, GPIOs, RTC, etc.).
--
Florian
next prev parent reply other threads:[~2021-06-03 17:30 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-27 17:51 [PATCH v1 0/4] PCI: brcmstb: Add panic handler and shutdown func Jim Quinlan
2021-04-27 17:51 ` [PATCH v1 1/4] PCI: brcmstb: Check return value of clk_prepare_enable() Jim Quinlan
2021-04-27 17:51 ` [PATCH v1 2/4] PCI: brcmstb: Give 7216 SOCs their own config type Jim Quinlan
2021-04-27 17:51 ` [PATCH v1 3/4] PCI: brcmstb: Add panic/die handler to RC driver Jim Quinlan
2021-05-25 20:40 ` Bjorn Helgaas
2021-05-25 21:05 ` Jim Quinlan
2021-05-25 21:17 ` Bjorn Helgaas
2021-04-27 17:51 ` [PATCH v1 4/4] PCI: brcmstb: add shutdown call to driver Jim Quinlan
2021-04-27 19:35 ` Florian Fainelli
2021-05-25 21:18 ` Bjorn Helgaas
2021-05-25 21:40 ` Jim Quinlan
2021-05-26 16:11 ` Rob Herring
2021-05-26 17:03 ` Florian Fainelli
2021-06-03 17:23 ` Bjorn Helgaas
2021-06-03 17:30 ` Florian Fainelli [this message]
2021-06-03 20:58 ` Bjorn Helgaas
2021-06-03 21:01 ` Florian Fainelli
2021-05-25 18:01 ` [PATCH v1 0/4] PCI: brcmstb: Add panic handler and shutdown func Florian Fainelli
2021-06-03 16:32 ` Lorenzo Pieralisi
2021-06-03 17:31 ` Jim Quinlan
2021-06-04 9:22 ` Lorenzo Pieralisi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=dbd96bb2-4873-a37c-567d-ffd731beb927@gmail.com \
--to=f.fainelli@gmail.com \
--cc=bcm-kernel-feedback-list@broadcom.com \
--cc=bhelgaas@google.com \
--cc=helgaas@kernel.org \
--cc=james.quinlan@broadcom.com \
--cc=jim2101024@gmail.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=linux-rpi-kernel@lists.infradead.org \
--cc=lorenzo.pieralisi@arm.com \
--cc=nsaenz@kernel.org \
--cc=nsaenzjulienne@suse.de \
--cc=robh@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).