From: Mark Brown <broonie@kernel.org> To: Florian Fainelli <f.fainelli@gmail.com> Cc: Jim Quinlan <jim2101024@gmail.com>, linux-pci <linux-pci@vger.kernel.org>, Nicolas Saenz Julienne <nsaenzjulienne@suse.de>, Rob Herring <robh@kernel.org>, bcm-kernel-feedback-list <bcm-kernel-feedback-list@broadcom.com>, Jim Quinlan <james.quinlan@broadcom.com>, Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>, Bjorn Helgaas <bhelgaas@google.com>, "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 v3 2/6] PCI: brcmstb: Add control of EP voltage regulators Date: Mon, 29 Mar 2021 22:31:25 +0100 [thread overview] Message-ID: <20210329213125.GK5166@sirena.org.uk> (raw) In-Reply-To: <e364818a-daa3-7313-3ad2-41dbe6e5be62@gmail.com> [-- Attachment #1: Type: text/plain, Size: 1850 bytes --] On Mon, Mar 29, 2021 at 02:09:58PM -0700, Florian Fainelli wrote: > On 3/29/21 1:45 PM, Mark Brown wrote: > > management in the driver anyway? Just mark the regualtors as always on > > and set up an appropriate suspend mode configuration and everything > > should work without the drivers doing anything. Unless your PMIC isn't > > able to provide separate suspend mode configuration for the regulators? > We have typically GPIO-controlled and PMIC (via SCMI) controlled > regulators. During PCIe enumeration we need these regulators turned on > to be successful in training the PCIe link and discover the end-point > attached, so there an always on regulator would work. > When we enter a system suspend state however there are really two cases: > - the end-point supports Wake-on (typically wake-on-WLAN) and we need > its power supplied kept on to support that > - the end-point does not support or participate in any wake-up, there we > want to turn its supplies off to save power > How would we go about supporting such an use case with an always on > regulator? With a PMIC most PMICs have a system suspend mode with separate regulator configuration for that and there's seprate regulator API control for those, including DT bindings. If that needs runtime configuration for something hidden by SCMI I'd hope the SCMI regulator stuff has facilities for that, if not then I guess a spec extension is needed. If you want to dynamically select if something is on during suspend there's not really a way around regulator API support. For a GPIO regulator you probably need something that does a disable on the way down, assuming that the GPIO/pin controller doesn't end up having it's own suspend mode control that ends up powering things off anyway. With GPIOs pinctrl on the pins rather than exposing as a regulator might be enough. [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 488 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: Mark Brown <broonie@kernel.org> To: Florian Fainelli <f.fainelli@gmail.com> Cc: Jim Quinlan <jim2101024@gmail.com>, linux-pci <linux-pci@vger.kernel.org>, Nicolas Saenz Julienne <nsaenzjulienne@suse.de>, Rob Herring <robh@kernel.org>, bcm-kernel-feedback-list <bcm-kernel-feedback-list@broadcom.com>, Jim Quinlan <james.quinlan@broadcom.com>, Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>, Bjorn Helgaas <bhelgaas@google.com>, "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 v3 2/6] PCI: brcmstb: Add control of EP voltage regulators Date: Mon, 29 Mar 2021 22:31:25 +0100 [thread overview] Message-ID: <20210329213125.GK5166@sirena.org.uk> (raw) In-Reply-To: <e364818a-daa3-7313-3ad2-41dbe6e5be62@gmail.com> [-- Attachment #1.1: Type: text/plain, Size: 1850 bytes --] On Mon, Mar 29, 2021 at 02:09:58PM -0700, Florian Fainelli wrote: > On 3/29/21 1:45 PM, Mark Brown wrote: > > management in the driver anyway? Just mark the regualtors as always on > > and set up an appropriate suspend mode configuration and everything > > should work without the drivers doing anything. Unless your PMIC isn't > > able to provide separate suspend mode configuration for the regulators? > We have typically GPIO-controlled and PMIC (via SCMI) controlled > regulators. During PCIe enumeration we need these regulators turned on > to be successful in training the PCIe link and discover the end-point > attached, so there an always on regulator would work. > When we enter a system suspend state however there are really two cases: > - the end-point supports Wake-on (typically wake-on-WLAN) and we need > its power supplied kept on to support that > - the end-point does not support or participate in any wake-up, there we > want to turn its supplies off to save power > How would we go about supporting such an use case with an always on > regulator? With a PMIC most PMICs have a system suspend mode with separate regulator configuration for that and there's seprate regulator API control for those, including DT bindings. If that needs runtime configuration for something hidden by SCMI I'd hope the SCMI regulator stuff has facilities for that, if not then I guess a spec extension is needed. If you want to dynamically select if something is on during suspend there's not really a way around regulator API support. For a GPIO regulator you probably need something that does a disable on the way down, assuming that the GPIO/pin controller doesn't end up having it's own suspend mode control that ends up powering things off anyway. With GPIOs pinctrl on the pins rather than exposing as a regulator might be enough. [-- Attachment #1.2: signature.asc --] [-- Type: application/pgp-signature, Size: 488 bytes --] [-- Attachment #2: Type: text/plain, Size: 176 bytes --] _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2021-03-29 21:32 UTC|newest] Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-03-26 19:18 [PATCH v3 0/6] PCI: brcmstb: add EP regulators and panic handler Jim Quinlan 2021-03-26 19:18 ` Jim Quinlan 2021-03-26 19:18 ` [PATCH v3 1/6] dt-bindings: PCI: Add bindings for Brcmstb EP voltage regulators Jim Quinlan 2021-03-26 19:18 ` Jim Quinlan 2021-03-27 15:58 ` Rob Herring 2021-03-27 15:58 ` Rob Herring 2021-03-30 15:08 ` Rob Herring 2021-03-30 15:08 ` Rob Herring 2021-03-30 15:30 ` Mark Brown 2021-03-30 15:30 ` Mark Brown 2021-03-30 16:23 ` Jim Quinlan 2021-03-30 16:23 ` Jim Quinlan 2021-03-31 11:46 ` Mark Brown 2021-03-31 11:46 ` Mark Brown 2021-03-26 19:19 ` [PATCH v3 2/6] PCI: brcmstb: Add control of " Jim Quinlan 2021-03-26 19:19 ` Jim Quinlan 2021-03-26 20:11 ` Bjorn Helgaas 2021-03-26 20:11 ` Bjorn Helgaas 2021-03-27 22:20 ` Jim Quinlan 2021-03-27 22:20 ` Jim Quinlan 2021-03-29 16:19 ` Mark Brown 2021-03-29 16:19 ` Mark Brown 2021-03-29 16:25 ` Mark Brown 2021-03-29 16:25 ` Mark Brown 2021-03-29 16:39 ` Jim Quinlan 2021-03-29 16:39 ` Jim Quinlan 2021-03-29 17:16 ` Mark Brown 2021-03-29 17:16 ` Mark Brown 2021-03-29 19:48 ` Jim Quinlan 2021-03-29 19:48 ` Jim Quinlan 2021-03-29 20:45 ` Mark Brown 2021-03-29 20:45 ` Mark Brown 2021-03-29 21:09 ` Florian Fainelli 2021-03-29 21:09 ` Florian Fainelli 2021-03-29 21:31 ` Mark Brown [this message] 2021-03-29 21:31 ` Mark Brown 2021-03-26 19:19 ` [PATCH v3 3/6] PCI: brcmstb: Do not turn off regulators if EP can wake up Jim Quinlan 2021-03-26 19:19 ` Jim Quinlan 2021-03-26 20:17 ` Bjorn Helgaas 2021-03-26 20:17 ` Bjorn Helgaas 2021-03-26 19:19 ` [PATCH v3 4/6] PCI: brcmstb: Give 7216 SOCs their own config type Jim Quinlan 2021-03-26 19:19 ` Jim Quinlan 2021-03-26 19:19 ` [PATCH v3 5/6] PCI: brcmstb: Add panic/die handler to RC driver Jim Quinlan 2021-03-26 19:19 ` Jim Quinlan 2021-03-26 19:19 ` [PATCH v3 6/6] PCI: brcmstb: Check return value of clk_prepare_enable() Jim Quinlan 2021-03-26 19:19 ` Jim Quinlan 2021-03-26 20:31 ` Bjorn Helgaas 2021-03-26 20:31 ` Bjorn Helgaas
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=20210329213125.GK5166@sirena.org.uk \ --to=broonie@kernel.org \ --cc=bcm-kernel-feedback-list@broadcom.com \ --cc=bhelgaas@google.com \ --cc=f.fainelli@gmail.com \ --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=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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.