From: Andy Shevchenko <andy.shevchenko@gmail.com>
To: Bjorn Helgaas <helgaas@kernel.org>
Cc: Krishna chaitanya chundru <quic_krichai@quicinc.com>,
Bjorn Helgaas <bhelgaas@google.com>,
manivannan.sadhasivam@linaro.org, Markus.Elfring@web.de,
quic_mrana@quicinc.com, rafael@kernel.org,
linux-pm@vger.kernel.org, linux-pci@vger.kernel.org,
linux-kernel@vger.kernel.org, quic_vbadigan@quicinc.com,
quic_ramkri@quicinc.com
Subject: Re: [PATCH v5] PCI: Enable runtime pm of the host bridge
Date: Wed, 9 Oct 2024 01:25:05 +0300 [thread overview]
Message-ID: <ZwWxQQgPSlVa3QH_@surfacebook.localdomain> (raw)
In-Reply-To: <20241003221033.GA327855@bhelgaas>
Thu, Oct 03, 2024 at 05:10:33PM -0500, Bjorn Helgaas kirjoitti:
> On Thu, Oct 03, 2024 at 11:32:32AM +0530, Krishna chaitanya chundru wrote:
> > The Controller driver is the parent device of the PCIe host bridge,
> > PCI-PCI bridge and PCIe endpoint as shown below.
> >
> > PCIe controller(Top level parent & parent of host bridge)
> > |
> > v
> > PCIe Host bridge(Parent of PCI-PCI bridge)
> > |
> > v
> > PCI-PCI bridge(Parent of endpoint driver)
> > |
> > v
> > PCIe endpoint driver
> >
> > Now, when the controller device goes to runtime suspend, PM framework
> > will check the runtime PM state of the child device (host bridge) and
> > will find it to be disabled. So it will allow the parent (controller
> > device) to go to runtime suspend. Only if the child device's state was
> > 'active' it will prevent the parent to get suspended.
> >
> > It is a property of the runtime PM framework that it can only
> > follow continuous dependency chains. That is, if there is a device
> > with runtime PM disabled in a dependency chain, runtime PM cannot be
> > enabled for devices below it and above it in that chain both at the
> > same time.
> >
> > Since runtime PM is disabled for host bridge, the state of the child
> > devices under the host bridge is not taken into account by PM framework
> > for the top level parent, PCIe controller. So PM framework, allows
> > the controller driver to enter runtime PM irrespective of the state
> > of the devices under the host bridge. And this causes the topology
> > breakage and also possible PM issues like controller driver goes to
> > runtime suspend while endpoint driver is doing some transfers.
> >
> > Because of the above, in order to enable runtime PM for a PCIe
> > controller device, one needs to ensure that runtime PM is enabled for
> > all devices in every dependency chain between it and any PCIe endpoint
> > (as runtime PM is enabled for PCIe endpoints).
> >
> > This means that runtime PM needs to be enabled for the host bridge
> > device, which is present in all of these dependency chains.
> >
> > After this change, the host bridge device will be runtime-suspended
> > by the runtime PM framework automatically after suspending its last
> > child and it will be runtime-resumed automatically before resuming its
> > first child which will allow the runtime PM framework to track
> > dependencies between the host bridge device and all of its
> > descendants.
>
> Applied to pci/pm for v6.13, thanks for your patience is working
> through this!
...
> > + pm_runtime_set_active(&bridge->dev);
> > + pm_runtime_no_callbacks(&bridge->dev);
> > + devm_pm_runtime_enable(&bridge->dev);
So, potentially this might lead to a case where PM runtime is enabled and won't
be disabled on the bridge device removal. Is this a problem?
TL;DR:
I have found no explanations why error code from devm_*() call is being ignored.
> > return 0;
--
With Best Regards,
Andy Shevchenko
next prev parent reply other threads:[~2024-10-08 22:26 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20241009181035eucas1p1410785aa81c9ec764c44d3f6eea940ed@eucas1p1.samsung.com>
2024-10-03 6:02 ` [PATCH v5] PCI: Enable runtime pm of the host bridge Krishna chaitanya chundru
2024-10-03 22:10 ` Bjorn Helgaas
2024-10-08 22:25 ` Andy Shevchenko [this message]
2024-10-09 18:10 ` Marek Szyprowski
2024-10-09 22:20 ` Mayank Rana
2024-10-10 6:08 ` Manivannan Sadhasivam
2024-10-10 6:42 ` Marek Szyprowski
2024-10-10 19:25 ` Bjorn Helgaas
2024-10-10 20:39 ` Mayank Rana
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=ZwWxQQgPSlVa3QH_@surfacebook.localdomain \
--to=andy.shevchenko@gmail.com \
--cc=Markus.Elfring@web.de \
--cc=bhelgaas@google.com \
--cc=helgaas@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=manivannan.sadhasivam@linaro.org \
--cc=quic_krichai@quicinc.com \
--cc=quic_mrana@quicinc.com \
--cc=quic_ramkri@quicinc.com \
--cc=quic_vbadigan@quicinc.com \
--cc=rafael@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