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@xxxxxxxx> wrote: > > > > From: Bartosz Golaszewski <bartosz.golaszewski@xxxxxxxxxx> > > > > 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 > -- மணிவண்ணன் சதாசிவம்
