On Tue, Nov 14, 2023 at 10:08 AM Guan-Yu Lin <guanyulin@xxxxxxxxxx> wrote: > > 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? I will have more time to think about this when I'm back from the conference I'm participating in now. In the meantime, I would recommend you to address Alan's comments.
