public inbox for linux-arm-kernel@lists.infradead.org
 help / color / mirror / Atom feed
From: Bjorn Helgaas <helgaas@kernel.org>
To: Jim Quinlan <jim2101024@gmail.com>
Cc: linux-pci@vger.kernel.org,
	Nicolas Saenz Julienne <nsaenzjulienne@suse.de>,
	Rob Herring <robh@kernel.org>, Mark Brown <broonie@kernel.org>,
	bcm-kernel-feedback-list@broadcom.com,
	james.quinlan@broadcom.com,
	Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>,
	Bjorn Helgaas <bhelgaas@google.com>,
	Florian Fainelli <f.fainelli@gmail.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: Fri, 26 Mar 2021 15:11:43 -0500	[thread overview]
Message-ID: <20210326201143.GA903800@bjorn-Precision-5520> (raw)
In-Reply-To: <20210326191906.43567-3-jim2101024@gmail.com>

On Fri, Mar 26, 2021 at 03:19:00PM -0400, Jim Quinlan wrote:
> Control of EP regulators by the RC is needed because of the chicken-and-egg

Can you expand "EP"?  Not sure if this refers to "endpoint" or
something else.

If this refers to a device in a slot, I guess it isn't necessarily a
PCIe *endpoint*; it could also be a switch upstream port.

> situation: although the regulator is "owned" by the EP and would be best
> handled on its driver, the EP cannot be discovered and probed unless its
> regulator is already turned on.
> 
> Signed-off-by: Jim Quinlan <jim2101024@gmail.com>
> ---
>  drivers/pci/controller/pcie-brcmstb.c | 90 ++++++++++++++++++++++++++-
>  1 file changed, 87 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/pci/controller/pcie-brcmstb.c b/drivers/pci/controller/pcie-brcmstb.c
> index e330e6811f0b..b76ec7d9af32 100644
> --- a/drivers/pci/controller/pcie-brcmstb.c
> +++ b/drivers/pci/controller/pcie-brcmstb.c
> @@ -24,6 +24,7 @@
>  #include <linux/pci.h>
>  #include <linux/pci-ecam.h>
>  #include <linux/printk.h>
> +#include <linux/regulator/consumer.h>
>  #include <linux/reset.h>
>  #include <linux/sizes.h>
>  #include <linux/slab.h>
> @@ -169,6 +170,7 @@
>  #define SSC_STATUS_SSC_MASK		0x400
>  #define SSC_STATUS_PLL_LOCK_MASK	0x800
>  #define PCIE_BRCM_MAX_MEMC		3
> +#define PCIE_BRCM_MAX_EP_REGULATORS	4
>  
>  #define IDX_ADDR(pcie)			(pcie->reg_offsets[EXT_CFG_INDEX])
>  #define DATA_ADDR(pcie)			(pcie->reg_offsets[EXT_CFG_DATA])
> @@ -295,8 +297,27 @@ struct brcm_pcie {
>  	u32			hw_rev;
>  	void			(*perst_set)(struct brcm_pcie *pcie, u32 val);
>  	void			(*bridge_sw_init_set)(struct brcm_pcie *pcie, u32 val);
> +	struct regulator_bulk_data supplies[PCIE_BRCM_MAX_EP_REGULATORS];
> +	unsigned int		num_supplies;
>  };
>  
> +static int brcm_set_regulators(struct brcm_pcie *pcie, bool on)
> +{
> +	struct device *dev = pcie->dev;
> +	int ret;
> +
> +	if (!pcie->num_supplies)
> +		return 0;
> +	if (on)
> +		ret = regulator_bulk_enable(pcie->num_supplies, pcie->supplies);
> +	else
> +		ret = regulator_bulk_disable(pcie->num_supplies, pcie->supplies);
> +	if (ret)
> +		dev_err(dev, "failed to %s EP regulators\n",
> +			on ? "enable" : "disable");
> +	return ret;
> +}
> +
>  /*
>   * This is to convert the size of the inbound "BAR" region to the
>   * non-linear values of PCIE_X_MISC_RC_BAR[123]_CONFIG_LO.SIZE
> @@ -1141,16 +1162,63 @@ static void brcm_pcie_turn_off(struct brcm_pcie *pcie)
>  	pcie->bridge_sw_init_set(pcie, 1);
>  }
>  
> +static int brcm_pcie_get_regulators(struct brcm_pcie *pcie)
> +{
> +	struct device_node *child, *parent = pcie->np;
> +	const unsigned int max_name_len = 64 + 4;
> +	struct property *pp;
> +
> +	/* Look for regulator supply property in the EP device subnodes */
> +	for_each_available_child_of_node(parent, child) {
> +		/*
> +		 * Do a santiy test to ensure that this is an EP node

s/santiy/sanity/

> +		 * (e.g. node name: "pci-ep@0,0").  The slot number
> +		 * should always be 0 as our controller only has a single
> +		 * port.
> +		 */
> +		const char *p = strstr(child->full_name, "@0");
> +
> +		if (!p || (p[2] && p[2] != ','))
> +			continue;
> +
> +		/* Now look for regulator supply properties */
> +		for_each_property_of_node(child, pp) {
> +			int i, n = strnlen(pp->name, max_name_len);
> +
> +			if (n <= 7 || strncmp("-supply", &pp->name[n - 7], 7))
> +				continue;
> +
> +			/* Make sure this is not a duplicate */
> +			for (i = 0; i < pcie->num_supplies; i++)
> +				if (strncmp(pcie->supplies[i].supply,
> +					    pp->name, max_name_len) == 0)
> +					continue;
> +
> +			if (pcie->num_supplies < PCIE_BRCM_MAX_EP_REGULATORS)
> +				pcie->supplies[pcie->num_supplies++].supply = pp->name;
> +			else
> +				dev_warn(pcie->dev, "No room for EP supply %s\n",
> +					 pp->name);
> +		}
> +	}
> +	/*
> +	 * Get the regulators that the EP devices require.  We cannot use
> +	 * pcie->dev as the device argument in regulator_bulk_get() since
> +	 * it will not find the regulators.  Instead, use NULL and the
> +	 * regulators are looked up by their name.

The comment doesn't explain the interesting part of why you need NULL
instead of "pcie->dev".  I assume it has something to do with the
platform topology and its DT description.

This appears to be the only instance in the whole kernel of a use of
regulator_bulk_get() or devm_regulator_bulk_get() with NULL.  That
definitely warrants a comment, so I'm glad you've got something here.

The regulator_bulk_get() function comment doesn't mention the
possibility of "dev == NULL", although regulator_dev_lookup(),
create_regulator(), device_link_add() do check for it being NULL, so I
guess it's not a surprise.  We may call dev_err(NULL), which I think
will *work* without crashing even though it will look like a mistake
on the output.

> +	 */
> +	return regulator_bulk_get(NULL, pcie->num_supplies, pcie->supplies);

devm_regulator_bulk_get()?

> +}
> +
>  static int brcm_pcie_suspend(struct device *dev)
>  {
>  	struct brcm_pcie *pcie = dev_get_drvdata(dev);
> -	int ret;
>  
>  	brcm_pcie_turn_off(pcie);
> -	ret = brcm_phy_stop(pcie);
> +	brcm_phy_stop(pcie);

If we no longer care whether brcm_phy_stop() returns an error, nobody
looks at the return value and it could be void.

>  	clk_disable_unprepare(pcie->clk);
>  
> -	return ret;
> +	return brcm_set_regulators(pcie, false);
>  }
>  
>  static int brcm_pcie_resume(struct device *dev)
> @@ -1163,6 +1231,10 @@ static int brcm_pcie_resume(struct device *dev)
>  	base = pcie->base;
>  	clk_prepare_enable(pcie->clk);
>  
> +	ret = brcm_set_regulators(pcie, true);
> +	if (ret)
> +		return ret;
> +
>  	ret = brcm_phy_start(pcie);
>  	if (ret)
>  		goto err;
> @@ -1199,6 +1271,8 @@ static void __brcm_pcie_remove(struct brcm_pcie *pcie)
>  	brcm_phy_stop(pcie);
>  	reset_control_assert(pcie->rescal);
>  	clk_disable_unprepare(pcie->clk);
> +	brcm_set_regulators(pcie, false);
> +	regulator_bulk_free(pcie->num_supplies, pcie->supplies);
>  }
>  
>  static int brcm_pcie_remove(struct platform_device *pdev)
> @@ -1289,6 +1363,16 @@ static int brcm_pcie_probe(struct platform_device *pdev)
>  		return ret;
>  	}
>  
> +	ret = brcm_pcie_get_regulators(pcie);
> +	if (ret) {
> +		dev_err(pcie->dev, "failed to get regulators (err=%d)\n", ret);
> +		goto fail;
> +	}
> +
> +	ret = brcm_set_regulators(pcie, true);
> +	if (ret)
> +		goto fail;
> +
>  	ret = brcm_pcie_setup(pcie);
>  	if (ret)
>  		goto fail;
> -- 
> 2.17.1
> 

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2021-03-26 20:13 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 [this message]
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
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=20210326201143.GA903800@bjorn-Precision-5520 \
    --to=helgaas@kernel.org \
    --cc=bcm-kernel-feedback-list@broadcom.com \
    --cc=bhelgaas@google.com \
    --cc=broonie@kernel.org \
    --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