linux-pci.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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 --]

  reply	other threads:[~2021-03-29 21:32 UTC|newest]

Thread overview: 24+ 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 ` [PATCH v3 1/6] dt-bindings: PCI: Add bindings for Brcmstb EP voltage regulators Jim Quinlan
2021-03-27 15:58   ` Rob Herring
2021-03-30 15:08   ` Rob Herring
2021-03-30 15:30     ` Mark Brown
2021-03-30 16:23       ` Jim Quinlan
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 20:11   ` Bjorn Helgaas
2021-03-27 22:20     ` Jim Quinlan
2021-03-29 16:19   ` Mark Brown
2021-03-29 16:25   ` Mark Brown
2021-03-29 16:39     ` Jim Quinlan
2021-03-29 17:16       ` Mark Brown
2021-03-29 19:48         ` Jim Quinlan
2021-03-29 20:45           ` Mark Brown
2021-03-29 21:09             ` Florian Fainelli
2021-03-29 21:31               ` Mark Brown [this message]
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 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 ` [PATCH v3 5/6] PCI: brcmstb: Add panic/die handler to RC driver 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 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: 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).