From: Florian Fainelli <f.fainelli@gmail.com>
To: Rob Herring <robh@kernel.org>, Jim Quinlan <james.quinlan@broadcom.com>
Cc: "moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE"
<linux-arm-kernel@lists.infradead.org>,
Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>,
linux-pci@vger.kernel.org,
open list <linux-kernel@vger.kernel.org>,
bcm-kernel-feedback-list@broadcom.com,
"moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE"
<linux-rpi-kernel@lists.infradead.org>,
Bjorn Helgaas <bhelgaas@google.com>,
Robin Murphy <robin.murphy@arm.com>,
Christoph Hellwig <hch@lst.de>,
Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
Subject: Re: [PATCH v11 04/11] PCI: brcmstb: Add suspend and resume pm_ops
Date: Thu, 10 Sep 2020 11:47:03 -0700 [thread overview]
Message-ID: <4ae713d2-14d3-8ef8-e589-fdc55f5b1731@gmail.com> (raw)
In-Reply-To: <20200910155637.GA423872@bogus>
On 9/10/2020 8:56 AM, Rob Herring wrote:
> On Mon, Aug 24, 2020 at 03:30:17PM -0400, Jim Quinlan wrote:
>> From: Jim Quinlan <jquinlan@broadcom.com>
>>
>> Broadcom Set-top (BrcmSTB) boards typically support S2, S3, and S5 suspend
>> and resume. Now the PCIe driver may do so as well.
>>
>> Signed-off-by: Jim Quinlan <jquinlan@broadcom.com>
>> Acked-by: Florian Fainelli <f.fainelli@gmail.com>
>> ---
>> drivers/pci/controller/pcie-brcmstb.c | 47 +++++++++++++++++++++++++++
>> 1 file changed, 47 insertions(+)
>>
>> diff --git a/drivers/pci/controller/pcie-brcmstb.c b/drivers/pci/controller/pcie-brcmstb.c
>> index c2b3d2946a36..3d588ab7a6dd 100644
>> --- a/drivers/pci/controller/pcie-brcmstb.c
>> +++ b/drivers/pci/controller/pcie-brcmstb.c
>> @@ -978,6 +978,47 @@ static void brcm_pcie_turn_off(struct brcm_pcie *pcie)
>> brcm_pcie_bridge_sw_init_set(pcie, 1);
>> }
>>
>> +static int brcm_pcie_suspend(struct device *dev)
>> +{
>> + struct brcm_pcie *pcie = dev_get_drvdata(dev);
>> +
>> + brcm_pcie_turn_off(pcie);
>> + clk_disable_unprepare(pcie->clk);
>> +
>> + return 0;
>> +}
>> +
>> +static int brcm_pcie_resume(struct device *dev)
>> +{
>> + struct brcm_pcie *pcie = dev_get_drvdata(dev);
>> + void __iomem *base;
>> + u32 tmp;
>> + int ret;
>> +
>> + base = pcie->base;
>> + clk_prepare_enable(pcie->clk);
>> +
>> + /* Take bridge out of reset so we can access the SERDES reg */
>> + brcm_pcie_bridge_sw_init_set(pcie, 0);
>> +
>> + /* SERDES_IDDQ = 0 */
>> + tmp = readl(base + PCIE_MISC_HARD_PCIE_HARD_DEBUG);
>> + u32p_replace_bits(&tmp, 0, PCIE_MISC_HARD_PCIE_HARD_DEBUG_SERDES_IDDQ_MASK);
>> + writel(tmp, base + PCIE_MISC_HARD_PCIE_HARD_DEBUG);
>> +
>> + /* wait for serdes to be stable */
>> + udelay(100);
>
> Really needs to be a spinloop?
>
>> +
>> + ret = brcm_pcie_setup(pcie);
>> + if (ret)
>> + return ret;
>> +
>> + if (pcie->msi)
>> + brcm_msi_set_regs(pcie->msi);
>> +
>> + return 0;
>> +}
>> +
>> static void __brcm_pcie_remove(struct brcm_pcie *pcie)
>> {
>> brcm_msi_remove(pcie);
>> @@ -1087,12 +1128,18 @@ static int brcm_pcie_probe(struct platform_device *pdev)
>>
>> MODULE_DEVICE_TABLE(of, brcm_pcie_match);
>>
>> +static const struct dev_pm_ops brcm_pcie_pm_ops = {
>> + .suspend_noirq = brcm_pcie_suspend,
>> + .resume_noirq = brcm_pcie_resume,
>
> Why do you need interrupts disabled? There's 39 cases of .suspend_noirq
> and 1352 of .suspend in the tree.
>
> Is doing a clk unprepare even safe in .suspend_noirq? IIRC,
> prepare/unprepare can sleep.
Yes, it is safe, provided that your clock provider (clk-scmi.c in our
case) supports it, too. In our case the underlying mailbox driver has
its interrupts flagged with IRQF_NOSUSPEND such that they can still be
processed at _noirq time.
I think the rationale was to ensure that this would be done much later
after other subsystem have been made quiescent, but given the Linux
device driver model, the PCI bridge should be suspended after all
pci_device child device, so it should be safe not to use _noirq.
--
Florian
_______________________________________________
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:[~2020-09-10 18:48 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-24 19:30 [PATCH v11 00/11] PCI: brcmstb: enable PCIe for STB chips Jim Quinlan
2020-08-24 19:30 ` [PATCH v11 02/11] dt-bindings: PCI: Add bindings for more Brcmstb chips Jim Quinlan
2020-08-24 19:30 ` [PATCH v11 03/11] PCI: brcmstb: Add bcm7278 register info Jim Quinlan
2020-09-10 15:44 ` Rob Herring
2020-08-24 19:30 ` [PATCH v11 04/11] PCI: brcmstb: Add suspend and resume pm_ops Jim Quinlan
2020-09-10 15:56 ` Rob Herring
2020-09-10 16:42 ` Jim Quinlan
2020-09-10 18:50 ` Rob Herring
2020-09-10 18:54 ` Florian Fainelli
2020-09-10 19:05 ` Jim Quinlan
2020-09-10 19:07 ` Florian Fainelli
2020-09-10 19:09 ` Jim Quinlan
2020-09-10 18:47 ` Florian Fainelli [this message]
2020-08-24 19:30 ` [PATCH v11 05/11] PCI: brcmstb: Add bcm7278 PERST# support Jim Quinlan
2020-09-10 16:04 ` Rob Herring
2020-08-24 19:30 ` [PATCH v11 06/11] PCI: brcmstb: Add control of rescal reset Jim Quinlan
2020-09-08 13:32 ` Lorenzo Pieralisi
2020-09-10 16:09 ` Rob Herring
2020-08-24 19:30 ` [PATCH v11 08/11] PCI: brcmstb: Set additional internal memory DMA viewport sizes Jim Quinlan
2020-09-10 16:17 ` Rob Herring
2020-09-11 15:28 ` Jim Quinlan
2020-09-11 16:13 ` Rob Herring
2020-08-24 19:30 ` [PATCH v11 09/11] PCI: brcmstb: Accommodate MSI for older chips Jim Quinlan
2020-09-10 16:20 ` Rob Herring
2020-08-24 19:30 ` [PATCH v11 10/11] PCI: brcmstb: Set bus max burst size by chip type Jim Quinlan
2020-09-10 16:22 ` Rob Herring
2020-08-24 19:30 ` [PATCH v11 11/11] PCI: brcmstb: Add bcm7211, bcm7216, bcm7445, bcm7278 to match list Jim Quinlan
2020-09-10 16:23 ` Rob Herring
2020-08-25 17:40 ` [PATCH v11 00/11] PCI: brcmstb: enable PCIe for STB chips Florian Fainelli
2020-08-27 6:35 ` Christoph Hellwig
2020-08-27 13:29 ` Jim Quinlan
2020-09-07 9:16 ` Lorenzo Pieralisi
2020-09-07 17:43 ` Jim Quinlan
2020-09-07 18:29 ` Florian Fainelli
2020-09-08 10:42 ` Lorenzo Pieralisi
2020-09-08 12:20 ` Christoph Hellwig
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=4ae713d2-14d3-8ef8-e589-fdc55f5b1731@gmail.com \
--to=f.fainelli@gmail.com \
--cc=bcm-kernel-feedback-list@broadcom.com \
--cc=bhelgaas@google.com \
--cc=hch@lst.de \
--cc=james.quinlan@broadcom.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 \
--cc=robin.murphy@arm.com \
/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).