lkml.org 
[lkml]   [2004]   [May]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] Hotplug for device power state changes
Patrick Mochel wrote:
>>A patch to call a hotplug device-power agent when the power state of a
>>device is modified at runtime (that is, individually via sysfs or by a
>>driver call, not as part of a system suspend/resume). Allows a power
>>management application to be informed of changes in device power needs.
>>This can be useful on platforms with dependencies between system
>>clock/voltage settings and operation of certain devices (such as
>>PXA27x), or, for example, on a cell phone where voiceband or network
>>devices going inactive signals an opportunity to lower platform power
>>levels to conserve battery life.
>
>
> Why? If the device is powered down at runtime via sysfs, then the app that
> did that already exists in userspace, like the ones you're trying to
> notify via /sbin/hotplug. It would be much simpler for the first app to
> generate e.g. a d-bus message to notify other apps, rather than creating
> this conduit through the kernel.

The ability to do this was originally requested in the context of a
driver managing the power state of its devices (according to some
unspecified logic); agreed that state changes requested via sysfs are a
less compelling usage scenario. Small battery-powered gadgets often
implement drivers that are more actively involved in managing power
state than the desktop/notebook/server norm, invoking LDM suspend
routines when an opportunity to power down arises. But it is also
common in wall-plug-wired systems to have a few power state transitions
that result from things under kernel control, such as blanking a display
device after a timer expires.

In many cases, the opportunity to move to a lower-power state may be
triggered by userspace activity and would make a good candidate for a
purely userspace notification method. However, a kernel-to-userspace
notification method is suggested for this to cover potential cases where
a device power state change might not be directly caused by, or may be a
non-obvious side effect of, an application action. Display blanking is
an example; other devices that can enter a low-power state due to
inactivity or due to changes in power state of other upstream or
downstream devices could also use this. If anyone reading this has
concrete examples that they would like to have considered then please do
speak up.

It may be the case that most useful scenarios for userspace actions in
response to device power state changes could be handled through a
suitable implementation of D-BUS messages between applications, and I'd
certainly support use of that model wherever possible. Returning errors
through the system call interface for an operation on a device file
descriptor, as I believe you've suggested, may also help cover most
useful cases. I will continue to encourage the developers who have
asked me for driver power state notifiers to chime in here with more
details on their needs.

> Besides, if one process has a device open, then the driver should refuse
> any requests to power it down.

I'd suggest some latitude in driver handling of low-power device states
wrt open file descriptors, such as for display blanking. But yes, this
is usually true (at least in the non-system-suspend case).


--
Todd Poynor
MontaVista Software

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:02    [W:2.147 / U:0.048 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site