From: Honghui Zhang <honghui.zhang@mediatek.com>
To: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>,
Marc Zyngier <marc.zyngier@arm.com>,
Bjorn Helgaas <bhelgaas@google.com>,
Matthias Brugger <matthias.bgg@gmail.com>,
linux-arm Mailing List <linux-arm-kernel@lists.infradead.org>,
"moderated list:ARM/Mediatek SoC support"
<linux-mediatek@lists.infradead.org>,
linux-pci@vger.kernel.org,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
devicetree <devicetree@vger.kernel.org>,
yingjoe.chen@mediatek.com, Eddie Huang <eddie.huang@mediatek.com>,
ryder.lee@mediatek.com, hongkun.cao@mediatek.com,
youlin.pei@mediatek.com, yong.wu@mediatek.com,
YT Shen <yt.shen@mediatek.com>,
sean.wang@mediatek.com
Subject: Re: [PATCH 3/4] PCI: mediatek: Add system pm support for MT2712 and MT7622
Date: Thu, 28 Jun 2018 09:44:25 +0800 [thread overview]
Message-ID: <1530150265.28284.25.camel@mhfsdcap03> (raw)
In-Reply-To: <CAHp75VcHgJrujzqstSc4RWpUbjip1vtJu87HN3uTosoLdOiT3A@mail.gmail.com>
On Wed, 2018-06-27 at 19:45 +0300, Andy Shevchenko wrote:
> On Wed, Jun 27, 2018 at 12:21 PM, <honghui.zhang@mediatek.com> wrote:
> > From: Honghui Zhang <honghui.zhang@mediatek.com>
> >
> > The MTCMOS of PCIe Host for MT2712 and MT7622 will be off when system
> > suspend, and all the internal control register will be reset after system
> > resume. The PCIe link should be re-established and the related control
> > register values should be re-set after system resume.
>
> > struct mtk_pcie_soc {
> > bool need_fix_class_id;
>
> > + bool pm_support;
>
> Hmm... Do you really need this flag? Can't runtime PM API tell you this?
This host driver is both for MT2712, MT7622 and MT7623, but MT7623 do
not this this patch.
I only add this flag to identify whether we need to do the PM operation
for this SoC since I do not want to touch anything for MT7623.
>
> > struct pci_ops *ops;
> > int (*startup)(struct mtk_pcie_port *port);
> > int (*setup_irq)(struct mtk_pcie_port *port, struct device_node *node);
> > @@ -1195,12 +1197,76 @@ static int mtk_pcie_probe(struct platform_device *pdev)
> > return err;
> > }
> >
> > +#ifdef CONFIG_PM_SLEEP
> > +static int mtk_pcie_suspend_noirq(struct device *dev)
>
> Perhaps __maybe_unused?
Ok, I'm a bit confused about this, if there's some discussion about
this, do you have the link of those discussion and kindly point put it
in this thread? Or I guess I can change this back to __maybe_unused if
there's no other comments about this.
>
> > +{
> > + struct mtk_pcie *pcie = dev_get_drvdata(dev);
> > + const struct mtk_pcie_soc *soc = pcie->soc;
> > + struct mtk_pcie_port *port;
> > +
> > + if (!soc->pm_support)
> > + return 0;
> > +
>
> > + if (list_empty(&pcie->ports))
> > + return 0;
>
> So, if the list is empty you are not suspending for the host?
>
if the list was empty then it indicate that all the PCIe slot was not
connected with any EP device, and all the resource have been release in
probe time. So the host driver does not need to save or restore
anything.
>
> > +
> > + list_for_each_entry(port, &pcie->ports, list) {
> > + clk_disable_unprepare(port->pipe_ck);
> > + clk_disable_unprepare(port->obff_ck);
> > + clk_disable_unprepare(port->axi_ck);
> > + clk_disable_unprepare(port->aux_ck);
> > + clk_disable_unprepare(port->ahb_ck);
> > + clk_disable_unprepare(port->sys_ck);
> > + phy_power_off(port->phy);
> > + phy_exit(port->phy);
> > + }
> > +
> > + mtk_pcie_subsys_powerdown(pcie);
> > +
> > + return 0;
> > +}
> > +
> > +static int mtk_pcie_resume_noirq(struct device *dev)
> > +{
> > + struct mtk_pcie *pcie = dev_get_drvdata(dev);
> > + const struct mtk_pcie_soc *soc = pcie->soc;
> > + struct mtk_pcie_port *port;
> > +
> > + if (!soc->pm_support)
> > + return 0;
> > +
>
> > + if (list_empty(&pcie->ports))
> > + return 0;
>
> No runtime PM for this case?
> (It seems now I understand why in previous patch you have a similar check)
>
I guess host driver does not need to resume anything if there's no EP
device was connected.
> > +
> > + if (dev->pm_domain) {
> > + pm_runtime_enable(dev);
> > + pm_runtime_get_sync(dev);
> > + }
> > +
> > + clk_prepare_enable(pcie->free_ck);
> > +
> > + list_for_each_entry(port, &pcie->ports, list)
> > + mtk_pcie_enable_port(port);
> > +
>
> > + if (list_empty(&pcie->ports))
>
> Hmm... How it would be true if you already bailed out above on the
> same condition?
Assuming that there's EP device connected before suspend, and the EP was
removed from the link while system suspend. It means that when enter
this function the list is not empty, but after the function of
mtk_pcie_enable_port was called, host driver found there's no EP device
was connected anymore, it will free this list and some other resources
in mtk_pcie_enable_port,(after mtk_pcie_enable_port was called, the list
is empty in this scenario) but leave the subsys power along, I guess we
need to take care of this scenario.
>
> > + mtk_pcie_subsys_powerdown(pcie);
> > +
> > + return 0;
> > +}
> > +#endif
> > +
> > +static const struct dev_pm_ops mtk_pcie_pm_ops = {
> > + SET_NOIRQ_SYSTEM_SLEEP_PM_OPS(mtk_pcie_suspend_noirq,
> > + mtk_pcie_resume_noirq)
> > +};
> > +
> > static const struct mtk_pcie_soc mtk_pcie_soc_v1 = {
> > .ops = &mtk_pcie_ops,
> > .startup = mtk_pcie_startup_port,
> > };
> >
> > static const struct mtk_pcie_soc mtk_pcie_soc_mt2712 = {
> > + .pm_support = true,
> > .ops = &mtk_pcie_ops_v2,
> > .startup = mtk_pcie_startup_port_v2,
> > .setup_irq = mtk_pcie_setup_irq,
>
> No update for .pm ?
I'm not get your point, I update the .pm callbacks in the
platform_driver struct, this SoC data just store the different
information for SoCs. Did I missed something?
>
> > @@ -1208,6 +1274,7 @@ static const struct mtk_pcie_soc mtk_pcie_soc_mt2712 = {
> >
> > static const struct mtk_pcie_soc mtk_pcie_soc_mt7622 = {
> > .need_fix_class_id = true,
> > + .pm_support = true,
> > .ops = &mtk_pcie_ops_v2,
> > .startup = mtk_pcie_startup_port_v2,
> > .setup_irq = mtk_pcie_setup_irq,
> > @@ -1227,6 +1294,7 @@ static struct platform_driver mtk_pcie_driver = {
> > .name = "mtk-pcie",
> > .of_match_table = mtk_pcie_ids,
> > .suppress_bind_attrs = true,
> > + .pm = &mtk_pcie_pm_ops,
> > },
> > };
> > builtin_platform_driver(mtk_pcie_driver);
> > --
> > 2.6.4
> >
>
>
>
next prev parent reply other threads:[~2018-06-28 1:44 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-27 9:21 [PATCH 0/4] PCI: mediatek: fixup find_port, enable_msi and add pm, module support honghui.zhang
2018-06-27 9:21 ` [PATCH 1/4] PCI: mediatek: fixup mtk_pcie_find_port logical honghui.zhang
2018-06-27 16:35 ` Andy Shevchenko
2018-06-28 1:12 ` Honghui Zhang
2018-06-28 13:07 ` Bjorn Helgaas
2018-06-29 7:51 ` Honghui Zhang
2018-06-27 9:21 ` [PATCH 2/4] PCI: mediatek: enable msi after clock enabled honghui.zhang
2018-06-27 9:21 ` [PATCH 3/4] PCI: mediatek: Add system pm support for MT2712 and MT7622 honghui.zhang
2018-06-27 16:45 ` Andy Shevchenko
2018-06-28 1:44 ` Honghui Zhang [this message]
2018-06-27 9:21 ` [PATCH 4/4] PCI: mediatek: Add loadable kernel module support honghui.zhang
2018-06-27 16:39 ` Andy Shevchenko
2018-06-28 1:17 ` Honghui Zhang
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=1530150265.28284.25.camel@mhfsdcap03 \
--to=honghui.zhang@mediatek.com \
--cc=andy.shevchenko@gmail.com \
--cc=bhelgaas@google.com \
--cc=devicetree@vger.kernel.org \
--cc=eddie.huang@mediatek.com \
--cc=hongkun.cao@mediatek.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=linux-pci@vger.kernel.org \
--cc=lorenzo.pieralisi@arm.com \
--cc=marc.zyngier@arm.com \
--cc=matthias.bgg@gmail.com \
--cc=ryder.lee@mediatek.com \
--cc=sean.wang@mediatek.com \
--cc=yingjoe.chen@mediatek.com \
--cc=yong.wu@mediatek.com \
--cc=youlin.pei@mediatek.com \
--cc=yt.shen@mediatek.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).