Powering up “discoverable bus-attached” devices on DT-based platforms
summary
Proposes creating a virtual PCI slot device bound as a platform child of the PCI host controller so DT node compatibles drive a slot/hotplug driver that powers devices before bus discovery, using existing regulator and GPIO frameworks. For the x3s board the Bluetooth and Wi‑Fi use separate GPIOs and regulators (Wi‑Fi ≈ four regulators, Bluetooth one plus one shared regulator with millisecond timing constraints) so the slot driver approach avoids a kernel-wide power‑sequencing subsystem and is slated for testing but not yet proven in mainline. PCI slot device as platform child of PCI host controller use DT compatible strings to pick slot driver no kernel-wide power-sequencing subsystem
AI-written summary · about
chapters (8)
- 0:00Introduction and context
- 1:25PCI slot driver proposal
- 10:02Power sequencing challenges
- 21:22Resource handling and subsystem needs
- 27:39PCI hot plug driver integration
- 33:26Device tree binding details
- 36:17Broader power management issues
- 40:58Summary and next steps
related talks
26mBridging Worlds: Using Device Tree Overlays To Support Complex PCI Devices in Linux
14mPCI Pwrctrl woes
50mHotplug of Non-discoverable Hardware: Status and Future Directions
19mPower Sequencing for Enumerable Busses - What's Still Missing From the Device Tree...
21mSetting up the PCIe hotplug in Kernel for Flexible Setups
46mEarly Platform Drivers in Linux Kernel
50mHow Not to Write X86 Platform Drivers
41mThe Case for an SoC Power Management Driver