Messages in this thread | | | From | Guan-Yu Lin <> | Date | Sat, 9 Mar 2024 02:04:00 +0800 | Subject | Re: [PATCH v3] PM / core: conditionally skip system pm in device/driver model |
| |
On Fri, Mar 1, 2024 at 4:34 AM Greg KH <gregkh@linuxfoundation.org> wrote: > > On Thu, Feb 29, 2024 at 05:08:00PM +0800, Guan-Yu Lin wrote: > > We want to introduce a mechanism that allows the Linux kernel to make > > power transitions for the peripheral based on whether the other > > operating system kernel is actively using it. To achieve this, we > > propose this patch that adds a sysfs attribute, providing the Linux > > kernel with the necessary information. > > Don't create random user/kernel apis in sysfs for no good reason just > because it is "easy" :( >
We initially considered using sysfs because it could provide a universal interface regardless of which operating system kernel shares the device with the Linux kernel. This would allow users to modify the feature through simple sysfs interactions. However, the current method of using information in sysfs doesn't seem to integrate well with the existing system power management framework. Could we refine how sysfs is used in system power management to enable cross-kernel communication? Alternatively, should we avoid exposing the information of whether a device is used by multiple operating systems to user space?
> If the "other operating system is actively using it" isn't able to be > detected by Linux, then Linux shouldn't be able to change the PM state, > so this sounds like you need to fix your Linux driver to properly know > this information, just like any other device type (think about a sound > device that needs to know if it is being used or not, nothing different > here.) >
I think the variable `usage_count` in struct `dev_pm_info` records whether the device is being used. Could we leverage this information in the design? We could modify the device tree to record which devices are shared across operating system kernels. Then, we could conditionally skip system power management steps for those devices if they're actively in use. We'll need to carefully consider potential corner cases and assess any impact on runtime power management. If this proposal seems worthwhile, I can prepare a more detailed v4 for discussion.
> So please post your Linux driver and we can see what needs to be done > there to get this to work properly, odds are you are just missing > something. Have a pointer to the code anywhere? > > Also, as you know, we can NOT add interfaces to the kernel without any > real user, so without a driver for your hardware, none of this is able > to go anywhere at all, sorry. >
The Linux device driver we're using here is the upstream xhci driver. We configure only partial interrupts for the controller in the device tree. This prevents the Linux kernel from accessing other interrupts handled by another operating system kernel. Consequently, the controller can function normally even with two operating system kernels accessing it, as long as we completely disable system power management functionality.
> thanks, > > greg k-h
| |