Hi Sven van Ashbrook, On Thu, Aug 31, 2023 at 4:14 AM Sven van Ashbrook <svenva@xxxxxxxxxxxx> wrote: > > On Tue, Aug 29, 2023 at 10:27 PM Ben Chuang <benchuanggli@xxxxxxxxx> wrote: > > > > > > > > - if /sys/devices/.../power/control is "on", then: > > > <snip> > > > > > 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? > > > > AFAIK the only way to disable runtime_pm is to write: > $ echo on > /sys/devices/.../power/control > where > $ echo auto > /sys/devices/.../power/control > means: runtime_pm is actively managing the device, device can be "active" > or "suspended". > $ echo on > /sys/devices/.../power/control > means: runtime_pm is not managing the device, device is "active" only. > > In the "auto" case, we know what should happen: LPM negotiation is enabled when > idle, disabled when active. > > What should be the LPM negotiation state in the "on" case? We have to > make a choice: > a) LPM negotiation disabled: normal performance, high power consumption, OR > b) LPM negotiation enabled: low performance, low power consumption > > If userspace disables our device's runtime_pm by writing "on", it expects the > device to be always-on. It should then expect a higher power consumption. > It should then also expect a performance that is not-worse than the "auto" case. > > So my suggestion would be to use (a), which is what this patch does. Understood, I accept your suggestion. > > Appreciate your thoughts. Best regards, Ben Chuang
