"Rafael J. Wysocki" <rjw@xxxxxxx> writes: >> Maybe this needs to be re-thought. Userspace needs a simple, consistent and >> understandable set of pm controls across the entire kernel, not piecemeal >> across different subsystems. > > Well, that's my opinion too, but other people don't seem to agree with it. I don't agree because when it comes to PM, subsystems can be quite different in what they want to expose to userspace. IMO, it's the subsystems/drivers that should decide what to expose to userspace for PM, just like they decide what gets exposed to userspace for the rest of their functionality. In other words, in my view, keeping PM knobs/controls outside the management of the subsystem is creating a strange boundary for userspace. Applications have to do all their "normal" interactions with the subsystem/driver, but for PM, they have to find the right sysfs magic and twiddle that. I would much rather see the subsystems/drivers grow their own PM functionality and expose it to userspace as they see fit. One of the examples used to discuss this in the past has been the touchscreen sample rate. Touchscreens can save power by having a lower sample rate at the expense of less precision. For finger/thumb type interface, a lower sample rate might be fine, but for handwriting recognition with a stylus, a higher sample rate could be required. Using a subsystem-generic (presumably sysfs-based) interface, the application would be required to find the right sysfs magic in addition to its interactions with tslib. (is there really a generic "sampling rate" knob that would make sense for all subsystems?) To me it seems more logical for the touchscreen/input subystem to expose this "sampling rate" knob in a subsystem-specific way to userspace, which could then be handled by tslib. Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
