On Wednesday, March 07, 2012, Kevin Hilman wrote: > "Rafael J. Wysocki" <r...@sisk.pl> 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.
That would be fine, but it doesn't _conflict_ with a more direct (so to speak) knob in sysfs, does it? Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
