On 10/11/23 18:58, Sven van Ashbrook wrote: > There's something happening in this driver that doesn't > make much sense to me. > > According to the pm runtime docs [1] the initial runtime pm > status of all devices is 'suspended'. Which I presume, means: > if the driver doesn't use any of the pm_runtime_*() functions > to tell the core "actually, I am active after probe", then the > device remains suspended until explicitly going active, at which > point the runtime_resume() callback is invoked. > > That's the theory. In practice, what do I see on a device > containing this bridge? > Intel SoC <-> PCIe bus <-> gl9763e bridge <-> eMMC bus <-> eMMC drive > > at probe() (does not exist in this driver so I stubbed it): > [ 0.601542] runtime pm is enabled = 1 (disable_depth == 0) > [ 0.601552] runtime pm is active = 2 (usage_count) > > at probe_slot(): > [ 0.602024] runtime pm is enabled = 1 > [ 0.602027] runtime pm is active = 2 > > At add_host(): > [ 0.602804] runtime pm is enabled = 1 > [ 0.602809] runtime pm is active = 3 > > It looks like: > - nowhere does the gl9763e driver inform runtime pm it's active PCI subsystem does it in pci_pm_init() > - the device is active in probe(), probe_slot() and add_host() > - the runtime_resume() callback did not get called before > probe(), probe_slot(), or add_host(). > > Why is the runtime_resume() callback not invoked? Most drivers expect the device to be active at probe(). How it gets that way is up to the bus. Note, the driver may call pm_runtime_set_active() but that doesn't call runtime_resume(). > Does the driver have a runtime_pm misconfiguration issue here? No > > Perhaps Rafael could clarify? > > [1] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/Documentation/power/runtime_pm.rst?h=v6.6.1#n563
