Hi, On Wed, Aug 30, 2023 at 12:35 AM Sven van Ashbrook svenva@chromium.org wrote:
- Rafael for advice on runtime_pm corner cases.
On Mon, Aug 28, 2023 at 10:48 PM Ben Chuang benchuanggli@gmail.com wrote:
My concern is that when runtime_pm is false, gl9763e is disabled LPM negotiation, gl9763e can't enter L1.x and s0ix may fail. It seems that runtime_pm will always exist and that's ok.
Thank you. I believe we can address your concern.
- XXX_suspend/XXX_resume (i.e. classic suspend/resume) depends on CONFIG_PM_SLEEP. This always selects CONFIG_PM. This always includes the runtime_pm framework. So, if XXX_suspend/XXX_resume gets called, the runtime_pm framework is always present, but may not be actively managing the device.
This is ok.
"when runtime_pm is false" AFAIK the only way to disable runtime_pm when CONFIG_PM is set, is to write "on" to /sys/devices/.../power/control. See https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-devices-power In that case, the runtime_pm framework will activate the device, calling XXX_runtime_resume() if necessary. Are there other ways of disabling it?
if /sys/devices/.../power/control is "on", then: gl9763e_runtime_resume() always called -> LPM always disabled gl9763e_suspend() -> LPM enabled -> gl9763e_resume() -> LPM disabled In between "classic" XXX_suspend and XXX_resume, LPM will be enabled, so the device can enter L1.x and S0ix.
In this cas, after gl9763e_resume(), it is LPM disabled. Is there no chance for gl9763e to enter L1.x again when the system is idle?
And the LPM negotiation flags look correct. Does that address your concerns?
Best regards, Ben Chuang