On Thu, Jan 18, 2024 at 08:29:01AM -0600, Rob Herring wrote:

On Wed, Jan 17, 2024 at 10:08 AM Bartosz Golaszewski [off-list ref] wrote:

quoted

From: Bartosz Golaszewski <redacted>

The responses to the RFC were rather positive so here's a proper series.

Thanks for tackling this.

quoted

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. :)

quoted

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

-- 
மணிவண்ணன் சதாசிவம்