On Tuesday 17 October 2006 2:21 pm, Dmitry Torokhov wrote: > > One approach would be to add a function callback pointer to the input > > device structure for autosuspend requests. The transport layer would then > > be responsible for handling these callbacks and carrying out the suspend. > > But input does not care about power management.
I'm missing part of this discussion, but isn't that exactly the problem? It has knowledge that's very relevant to power management, but hasn't been sharing it because it "doesn't care". Which means it's part of the problem; while it needs to be part of the solution, instead. > It's like saying that > we need to move power management for disks into partition handling or > filesystem code or (taking to extreme) userspace. Bad analogies. Better would be input drivers needing input from the input framework, like disk drivers needing input from the block framework. A disk that's not been written to for ten minutes is a *much* better candidate for entering a low power state than one that's been written to every ten seconds for the past day. And there can be other knowledge available to higher level drivers too ... that's the whole point of APIs that are generic rather than driver-specific. Including hinting like madvise(), whereby userspace applications tell lower levels of the driver stack information needed to improve performance. (And power usage/efficiency is certainly a key measure of system performance.) It's completely reasonable IMO to expect higher level drivers to provide inputs to power management decisions ... especially when without them, lower level drivers could only make bad guesses. Some factors in power management are "domain-specific", e.g. "input" or "block", rather than being purely device-specific. > Input will tells > device whether it is used or not (open/closed) and expects device to > be available if it is open. Sure, but that's orthogonal to whether the open device is very active or not ... and "is it very active" is highly relevant for power management. > It is lower level driver's task to implement autosuspend if needed Certainly. > but it has to be transparent for the upper layer. Nope. To do it _well_ additional inputs may be needed, which are not available except within upper layer drivers. That's not "transparent" in most senses of the word. If you just mean that the upper layers must not need to know if the lower level _has_ autosuspended, that's a different discussion, and one I'd be inclined to start by agreeing with you. :) - Dave ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
