On Wed, Nov 08, 2023 at 04:45:43PM +0800, Guan-Yu Lin wrote: > Thanks for the questions. Let me first introduce my motivation for > proposing this feature. We can discuss the implementation details later. > > Motivation: > Currently, system PM operations always override runtime PM operations. > As runtime PM reflects the power status of devices, there is a > possibility that runtime PM states that a device is in use, but system > PM decides to suspend it. Up to now, we have assumed that a device can't > function without resources from the system, so the device should acquire > a wakelock to prevent this from happening. However, what if the device [From the fact that you mention wakelocks, I assume that you're trying to implement something for Android systems rather than Linux systems in general.] > does not need the system's support to function? Or only needs limited > resources (e.g., only limited power source or clock) to function? In this > situation, we would like to keep the device on but allow the system to > suspend. This is an example where we would like devices to follow runtime > PM rather than system PM. To put it more simply, you want a way to leave some devices in an active state while the rest of the system is suspended. It's not clear why you have dragged runtime PM into the discussion (apart from the obvious fact that you won't want to keep a device active if it isn't active already). This sounds like a major change, not something to be done with a simple override. You should discuss it with Rafael Wysocki and the linux-pm mailing list before trying to implement anything. > Feature Supported: > 1. Devices could control the priority of system PM and runtime PM during > runtime. This seems like a totally unnecessary side issue. Forget about runtime PM for the time being and concentrate instead on which devices you want to keep active. > 2. The control should be at the device level, meaning that different > devices should control their own priorities. > > Goal of This Patch: > 1. Design a framework to support features above. > 2. Apply it into usb for demonstration. You may find that it is easier (and less work in the long run) to design the general framework and get it working than to concentrate on one particular subsystem. Alan Stern
