On Wed, Nov 8, 2023 at 11:56 PM Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > > 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.] > Apologies, I should use "wakeup source" here. > > 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 Hi Rafael, We'd like to implement a feature to allow system suspend with several devices still active. Do you have any consideration on this? Thanks, Guan-Yu
