From: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
To: Rob Herring <robh+dt@kernel.org>
Cc: "Bartosz Golaszewski" <brgl@bgdev.pl>,
"Kalle Valo" <kvalo@kernel.org>,
"David S . Miller" <davem@davemloft.net>,
"Eric Dumazet" <edumazet@google.com>,
"Jakub Kicinski" <kuba@kernel.org>,
"Paolo Abeni" <pabeni@redhat.com>,
"Krzysztof Kozlowski" <krzysztof.kozlowski+dt@linaro.org>,
"Conor Dooley" <conor+dt@kernel.org>,
"Bjorn Andersson" <andersson@kernel.org>,
"Konrad Dybcio" <konrad.dybcio@linaro.org>,
"Catalin Marinas" <catalin.marinas@arm.com>,
"Will Deacon" <will@kernel.org>,
"Bjorn Helgaas" <bhelgaas@google.com>,
"Heiko Stuebner" <heiko@sntech.de>,
"Jernej Skrabec" <jernej.skrabec@gmail.com>,
"Chris Morgan" <macromorgan@hotmail.com>,
"Linus Walleij" <linus.walleij@linaro.org>,
"Geert Uytterhoeven" <geert+renesas@glider.be>,
"Arnd Bergmann" <arnd@arndb.de>,
"Neil Armstrong" <neil.armstrong@linaro.org>,
"Nícolas F . R . A . Prado" <nfraprado@collabora.com>,
"Marek Szyprowski" <m.szyprowski@samsung.com>,
"Peng Fan" <peng.fan@nxp.com>,
"Robert Richter" <rrichter@amd.com>,
"Dan Williams" <dan.j.williams@intel.com>,
"Jonathan Cameron" <Jonathan.Cameron@huawei.com>,
"Terry Bowman" <terry.bowman@amd.com>,
"Lukas Wunner" <lukas@wunner.de>,
"Huacai Chen" <chenhuacai@kernel.org>,
"Alex Elder" <elder@linaro.org>,
"Srini Kandagatla" <srinivas.kandagatla@linaro.org>,
"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
"Abel Vesa" <abel.vesa@linaro.org>,
linux-wireless@vger.kernel.org, netdev@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-msm@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, linux-pci@vger.kernel.org,
"Bartosz Golaszewski" <bartosz.golaszewski@linaro.org>
Subject: Re: [PATCH 0/9] PCI: introduce the concept of power sequencing of PCIe devices
Date: Thu, 18 Jan 2024 22:17:55 +0530 [thread overview]
Message-ID: <20240118164755.GA3253@thinkpad> (raw)
In-Reply-To: <CAL_Jsq+0xb-otvjkbLqB8gNKadVqnigwGB_k+VGrj740Y6wxjg@mail.gmail.com>
On Thu, Jan 18, 2024 at 08:29:01AM -0600, Rob Herring wrote:
> On Wed, Jan 17, 2024 at 10:08 AM Bartosz Golaszewski <brgl@bgdev.pl> wrote:
> >
> > From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
> >
> > The responses to the RFC were rather positive so here's a proper series.
>
> Thanks for tackling this.
>
> > During last year's Linux Plumbers we had several discussions centered
> > around the need to power-on PCI devices before they can be detected on
> > the bus.
> >
> > The consensus during the conference was that we need to introduce a
> > class of "PCI slot drivers" that would handle the power-sequencing.
> >
> > After some additional brain-storming with Manivannan and the realization
> > that DT maintainers won't like adding any "fake" nodes not representing
> > actual devices, we decided to reuse existing PCI infrastructure.
>
> Thank you. :)
>
> > The general idea is to instantiate platform devices for child nodes of
> > the PCIe port DT node. For those nodes for which a power-sequencing
> > driver exists, we bind it and let it probe. The driver then triggers a
> > rescan of the PCI bus with the aim of detecting the now powered-on
> > device. The device will consume the same DT node as the platform,
> > power-sequencing device. We use device links to make the latter become
> > the parent of the former.
> >
> > The main advantage of this approach is not modifying the existing DT in
> > any way and especially not adding any "fake" platform devices.
>
> Suspend/resume has been brought up already, but I disagree we can
> worry about that later unless there is and always will be no power
> sequencing during suspend/resume for all devices ever. Given the
> supplies aren't standard, it wouldn't surprise me if standard PCI
> power management isn't either. The primary issue I see with this
> design is we will end up with 2 drivers doing the same power
> sequencing: the platform driver for initial power on and the device's
> PCI driver for suspend/resume.
>
There are actually 3 drivers need to do their own power management operations:
1. PCIe device driver - Handle the PM of the device itself (shutdown, low power)
2. PCIe pwrseq driver (this one) - Control resources of the PCIe devices
3. PCIe controller driver - Control resources of PCIe controller and Link
And all of them has different responsibilities, so I do not see an issue with
that. But what is really important is that all 3 has to work in sync and that's
quite involved. That's why I thought of dealing with that later.
Moreover, even if driver (2) doesn't do any PM operations now, it won't break
anything on the currently supported platforms (Qcom). It will be a problem once
people start adding pwrseq drivers for platforms whose controller drivers are
already handling the job which is now offloaded by this driver.
- Mani
> Rob
>
--
மணிவண்ணன் சதாசிவம்
WARNING: multiple messages have this Message-ID (diff)
From: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
To: Rob Herring <robh+dt@kernel.org>
Cc: "Bartosz Golaszewski" <brgl@bgdev.pl>,
"Kalle Valo" <kvalo@kernel.org>,
"David S . Miller" <davem@davemloft.net>,
"Eric Dumazet" <edumazet@google.com>,
"Jakub Kicinski" <kuba@kernel.org>,
"Paolo Abeni" <pabeni@redhat.com>,
"Krzysztof Kozlowski" <krzysztof.kozlowski+dt@linaro.org>,
"Conor Dooley" <conor+dt@kernel.org>,
"Bjorn Andersson" <andersson@kernel.org>,
"Konrad Dybcio" <konrad.dybcio@linaro.org>,
"Catalin Marinas" <catalin.marinas@arm.com>,
"Will Deacon" <will@kernel.org>,
"Bjorn Helgaas" <bhelgaas@google.com>,
"Heiko Stuebner" <heiko@sntech.de>,
"Jernej Skrabec" <jernej.skrabec@gmail.com>,
"Chris Morgan" <macromorgan@hotmail.com>,
"Linus Walleij" <linus.walleij@linaro.org>,
"Geert Uytterhoeven" <geert+renesas@glider.be>,
"Arnd Bergmann" <arnd@arndb.de>,
"Neil Armstrong" <neil.armstrong@linaro.org>,
"Nícolas F . R . A . Prado" <nfraprado@collabora.com>,
"Marek Szyprowski" <m.szyprowski@samsung.com>,
"Peng Fan" <peng.fan@nxp.com>,
"Robert Richter" <rrichter@amd.com>,
"Dan Williams" <dan.j.williams@intel.com>,
"Jonathan Cameron" <Jonathan.Cameron@huawei.com>,
"Terry Bowman" <terry.bowman@amd.com>,
"Lukas Wunner" <lukas@wunner.de>,
"Huacai Chen" <chenhuacai@kernel.org>,
"Alex Elder" <elder@linaro.org>,
"Srini Kandagatla" <srinivas.kandagatla@linaro.org>,
"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
"Abel Vesa" <abel.vesa@linaro.org>,
linux-wireless@vger.kernel.org, netdev@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-msm@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, linux-pci@vger.kernel.org,
"Bartosz Golaszewski" <bartosz.golaszewski@linaro.org>
Subject: Re: [PATCH 0/9] PCI: introduce the concept of power sequencing of PCIe devices
Date: Thu, 18 Jan 2024 22:17:55 +0530 [thread overview]
Message-ID: <20240118164755.GA3253@thinkpad> (raw)
In-Reply-To: <CAL_Jsq+0xb-otvjkbLqB8gNKadVqnigwGB_k+VGrj740Y6wxjg@mail.gmail.com>
On Thu, Jan 18, 2024 at 08:29:01AM -0600, Rob Herring wrote:
> On Wed, Jan 17, 2024 at 10:08 AM Bartosz Golaszewski <brgl@bgdev.pl> wrote:
> >
> > From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
> >
> > The responses to the RFC were rather positive so here's a proper series.
>
> Thanks for tackling this.
>
> > During last year's Linux Plumbers we had several discussions centered
> > around the need to power-on PCI devices before they can be detected on
> > the bus.
> >
> > The consensus during the conference was that we need to introduce a
> > class of "PCI slot drivers" that would handle the power-sequencing.
> >
> > After some additional brain-storming with Manivannan and the realization
> > that DT maintainers won't like adding any "fake" nodes not representing
> > actual devices, we decided to reuse existing PCI infrastructure.
>
> Thank you. :)
>
> > The general idea is to instantiate platform devices for child nodes of
> > the PCIe port DT node. For those nodes for which a power-sequencing
> > driver exists, we bind it and let it probe. The driver then triggers a
> > rescan of the PCI bus with the aim of detecting the now powered-on
> > device. The device will consume the same DT node as the platform,
> > power-sequencing device. We use device links to make the latter become
> > the parent of the former.
> >
> > The main advantage of this approach is not modifying the existing DT in
> > any way and especially not adding any "fake" platform devices.
>
> Suspend/resume has been brought up already, but I disagree we can
> worry about that later unless there is and always will be no power
> sequencing during suspend/resume for all devices ever. Given the
> supplies aren't standard, it wouldn't surprise me if standard PCI
> power management isn't either. The primary issue I see with this
> design is we will end up with 2 drivers doing the same power
> sequencing: the platform driver for initial power on and the device's
> PCI driver for suspend/resume.
>
There are actually 3 drivers need to do their own power management operations:
1. PCIe device driver - Handle the PM of the device itself (shutdown, low power)
2. PCIe pwrseq driver (this one) - Control resources of the PCIe devices
3. PCIe controller driver - Control resources of PCIe controller and Link
And all of them has different responsibilities, so I do not see an issue with
that. But what is really important is that all 3 has to work in sync and that's
quite involved. That's why I thought of dealing with that later.
Moreover, even if driver (2) doesn't do any PM operations now, it won't break
anything on the currently supported platforms (Qcom). It will be a problem once
people start adding pwrseq drivers for platforms whose controller drivers are
already handling the job which is now offloaded by this driver.
- Mani
> Rob
>
--
மணிவண்ணன் சதாசிவம்
_______________________________________________
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:[~2024-01-18 16:48 UTC|newest]
Thread overview: 79+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-17 16:07 [PATCH 0/9] PCI: introduce the concept of power sequencing of PCIe devices Bartosz Golaszewski
2024-01-17 16:07 ` Bartosz Golaszewski
2024-01-17 16:07 ` [PATCH 1/9] arm64: dts: qcom: qrb5165-rb5: describe the WLAN module of QCA6390 Bartosz Golaszewski
2024-01-17 16:07 ` Bartosz Golaszewski
2024-01-17 16:07 ` [PATCH 2/9] arm64: dts: qcom: sm8550-qrd: add Wifi nodes Bartosz Golaszewski
2024-01-17 16:07 ` Bartosz Golaszewski
2024-01-17 16:07 ` [PATCH 3/9] arm64: dts: qcom: sm8650-qrd: " Bartosz Golaszewski
2024-01-17 16:07 ` Bartosz Golaszewski
2024-01-17 16:07 ` [PATCH 4/9] PCI: create platform devices for child OF nodes of the port node Bartosz Golaszewski
2024-01-17 16:07 ` Bartosz Golaszewski
2024-01-17 16:22 ` Dan Williams
2024-01-17 16:22 ` Dan Williams
2024-01-18 13:11 ` Bartosz Golaszewski
2024-01-18 13:11 ` Bartosz Golaszewski
2024-01-17 16:45 ` Greg Kroah-Hartman
2024-01-17 16:45 ` Greg Kroah-Hartman
2024-01-18 10:58 ` Bartosz Golaszewski
2024-01-18 10:58 ` Bartosz Golaszewski
2024-01-18 11:15 ` Greg Kroah-Hartman
2024-01-18 11:15 ` Greg Kroah-Hartman
2024-01-30 21:54 ` Bjorn Andersson
2024-01-30 21:54 ` Bjorn Andersson
2024-01-31 11:04 ` Bartosz Golaszewski
2024-01-31 11:04 ` Bartosz Golaszewski
2024-02-02 0:03 ` Bjorn Andersson
2024-02-02 0:03 ` Bjorn Andersson
2024-02-02 4:50 ` Jeff Johnson
2024-02-02 4:50 ` Jeff Johnson
2024-02-02 10:02 ` Re: " Bartosz Golaszewski
2024-02-02 10:02 ` Bartosz Golaszewski
2024-02-07 16:32 ` Bartosz Golaszewski
2024-02-07 16:32 ` Bartosz Golaszewski
2024-02-14 15:34 ` Greg Kroah-Hartman
2024-02-14 15:34 ` Greg Kroah-Hartman
2024-01-17 16:07 ` [PATCH 5/9] PCI: hold the rescan mutex when scanning for the first time Bartosz Golaszewski
2024-01-17 16:07 ` Bartosz Golaszewski
2024-01-17 16:07 ` [PATCH 6/9] PCI/pwrseq: add pwrseq core code Bartosz Golaszewski
2024-01-17 16:07 ` Bartosz Golaszewski
2024-01-17 16:07 ` [PATCH 7/9] dt-bindings: wireless: ath11k: describe QCA6390 Bartosz Golaszewski
2024-01-17 16:07 ` Bartosz Golaszewski
2024-01-17 16:07 ` [PATCH 8/9] dt-bindings: wireless: ath11k: describe WCN7850 Bartosz Golaszewski
2024-01-17 16:07 ` Bartosz Golaszewski
2024-01-17 18:07 ` Kalle Valo
2024-01-17 18:07 ` Kalle Valo
2024-01-17 20:01 ` Bartosz Golaszewski
2024-01-17 20:01 ` Bartosz Golaszewski
2024-01-17 16:07 ` [PATCH 9/9] PCI/pwrseq: add a pwrseq driver for QCA6390 Bartosz Golaszewski
2024-01-17 16:07 ` Bartosz Golaszewski
2024-01-18 5:49 ` Kalle Valo
2024-01-18 5:49 ` Kalle Valo
2024-01-18 17:50 ` Konrad Dybcio
2024-01-18 17:50 ` Konrad Dybcio
2024-01-17 17:53 ` [PATCH 0/9] PCI: introduce the concept of power sequencing of PCIe devices Neil Armstrong
2024-01-17 17:53 ` Neil Armstrong
2024-01-17 18:16 ` Dmitry Baryshkov
2024-01-17 18:16 ` Dmitry Baryshkov
2024-01-18 18:53 ` Dmitry Baryshkov
2024-01-18 18:53 ` Dmitry Baryshkov
2024-01-19 11:52 ` Bartosz Golaszewski
2024-01-19 11:52 ` Bartosz Golaszewski
2024-01-19 12:31 ` Dmitry Baryshkov
2024-01-19 12:31 ` Dmitry Baryshkov
2024-01-19 13:35 ` brgl
2024-01-19 13:35 ` brgl
2024-01-19 14:07 ` Dmitry Baryshkov
2024-01-19 14:07 ` Dmitry Baryshkov
2024-01-19 14:11 ` Bartosz Golaszewski
2024-01-19 14:11 ` Bartosz Golaszewski
2024-01-19 14:48 ` Bartosz Golaszewski
2024-01-19 14:48 ` Bartosz Golaszewski
2024-01-19 16:34 ` Lukas Wunner
2024-01-19 16:45 ` Rob Herring
2024-01-19 16:45 ` Rob Herring
2024-01-18 14:29 ` Rob Herring
2024-01-18 14:29 ` Rob Herring
2024-01-18 16:38 ` Bartosz Golaszewski
2024-01-18 16:38 ` Bartosz Golaszewski
2024-01-18 16:47 ` Manivannan Sadhasivam [this message]
2024-01-18 16:47 ` Manivannan Sadhasivam
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=20240118164755.GA3253@thinkpad \
--to=manivannan.sadhasivam@linaro.org \
--cc=Jonathan.Cameron@huawei.com \
--cc=abel.vesa@linaro.org \
--cc=andersson@kernel.org \
--cc=arnd@arndb.de \
--cc=bartosz.golaszewski@linaro.org \
--cc=bhelgaas@google.com \
--cc=brgl@bgdev.pl \
--cc=catalin.marinas@arm.com \
--cc=chenhuacai@kernel.org \
--cc=conor+dt@kernel.org \
--cc=dan.j.williams@intel.com \
--cc=davem@davemloft.net \
--cc=devicetree@vger.kernel.org \
--cc=edumazet@google.com \
--cc=elder@linaro.org \
--cc=geert+renesas@glider.be \
--cc=gregkh@linuxfoundation.org \
--cc=heiko@sntech.de \
--cc=jernej.skrabec@gmail.com \
--cc=konrad.dybcio@linaro.org \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=kuba@kernel.org \
--cc=kvalo@kernel.org \
--cc=linus.walleij@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=lukas@wunner.de \
--cc=m.szyprowski@samsung.com \
--cc=macromorgan@hotmail.com \
--cc=neil.armstrong@linaro.org \
--cc=netdev@vger.kernel.org \
--cc=nfraprado@collabora.com \
--cc=pabeni@redhat.com \
--cc=peng.fan@nxp.com \
--cc=robh+dt@kernel.org \
--cc=rrichter@amd.com \
--cc=srinivas.kandagatla@linaro.org \
--cc=terry.bowman@amd.com \
--cc=will@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.