proposal on runtime power management in hid

proposal on runtime power management in hid

[Oliver Neukum]

Hi,

I am looking at runtime power management for usb hid devices.
There's a problem with hidraw. As we have no idea, what goes
on between a device and users of hidraw, it seems to me that
such a device should not be subject to runtime power management
without the user's explicit agreement.
But that would be only a kludge. Therefore this is my first draft of
an API to cleanly allow this.

It is based on telling drivers what capabilties a device must provide
to the system, allowing the driver to use the most aggressive runtime
power management compatible with the requirement.
Comments?

	Regards
		Oliver

diff --git a/include/linux/hid.h b/include/linux/hid.h
index ea80380..9b886c5 100644
--- a/include/linux/hid.h
+++ b/include/linux/hid.h
@@ -602,6 +602,12 @@ struct hid_driver {
  * @parse: this method is called only once to parse the device data,
  *	   shouldn't allocate anything to not leak memory
  */
+
+#define HID_POWER_LEVEL_NONE		0
+#define HID_POWER_LEVEL_WAKEUP		1
+#define HID_POWER_LEVEL_OPERATING	2
+#define HID_POWER_LEVEL_ON		3
+
 struct hid_ll_driver {
 	int (*start)(struct hid_device *hdev);
 	void (*stop)(struct hid_device *hdev);
@@ -613,6 +619,7 @@ struct hid_ll_driver {
 			unsigned int code, int value);
 
 	int (*parse)(struct hid_device *hdev);
+	int (*pctrl)(struct hid_device *hdev, int level);
 };
 
 /* Applications from HID Usage Tables 4/8/99 Version 1.1 */

Re: proposal on runtime power management in hid

[Alan Stern]

On Thu, 30 Oct 2008, Oliver Neukum wrote:

> Hi,
> 
> I am looking at runtime power management for usb hid devices.
> There's a problem with hidraw. As we have no idea, what goes
> on between a device and users of hidraw, it seems to me that
> such a device should not be subject to runtime power management
> without the user's explicit agreement.
> But that would be only a kludge. Therefore this is my first draft of
> an API to cleanly allow this.
> 
> It is based on telling drivers what capabilties a device must provide
> to the system, allowing the driver to use the most aggressive runtime
> power management compatible with the requirement.
> Comments?

Would it make more sense never to autosuspend a device that has an open
hidraw interface?  Then if you want to, you could add an API allowing
the user to tell the kernel to suspend or to resume (if the existing
sysfs interface isn't sufficient).

Alan Stern

Re: proposal on runtime power management in hid

[Jiri Kosina]

On Thu, 30 Oct 2008, Oliver Neukum wrote:

> I am looking at runtime power management for usb hid devices. There's a 
> problem with hidraw. As we have no idea, what goes on between a device 
> and users of hidraw, it seems to me that such a device should not be 
> subject to runtime power management without the user's explicit 
> agreement. But that would be only a kludge. Therefore this is my first 
> draft of an API to cleanly allow this.

Hi Oliver,

isn't this just a little bit way too complex?

I think the simple and working solution would be never suspedning devices 
that have interface open through hidraw, unless user explicitly allows 
this through respective power/autosuspend setting in sysfs (which will by 
default be set to 'off' for HID devices anyway, right?).

Thanks for looking into this.

-- 
Jiri Kosina
SUSE Labs

Re: proposal on runtime power management in hid

[Oliver Neukum]

Am Freitag, 31. Oktober 2008 00:17:38 schrieb Jiri Kosina:
> On Thu, 30 Oct 2008, Oliver Neukum wrote:
> 
> > I am looking at runtime power management for usb hid devices. There's a 
> > problem with hidraw. As we have no idea, what goes on between a device 
> > and users of hidraw, it seems to me that such a device should not be 
> > subject to runtime power management without the user's explicit 
> > agreement. But that would be only a kludge. Therefore this is my first 
> > draft of an API to cleanly allow this.
> 
> Hi Oliver,
> 
> isn't this just a little bit way too complex?

That depends on the eventual goal. If hidraw were the only problem,
I could find a simpler solution.

> I think the simple and working solution would be never suspedning devices 
> that have interface open through hidraw, unless user explicitly allows 
> this through respective power/autosuspend setting in sysfs (which will by 
> default be set to 'off' for HID devices anyway, right?).

That we already have. That's the simple copout. Do not enable autosuspend
if you allow hidraw for a device. However, if normal users shall be able to use
the hidraw device that means that autosuspend can never be enabled for the
device, as we don't know when someone will use the device.

For hiddev we can do better, the device is not autosuspended while it is
open. This allows allowing ordinary users to use the device. Doing so for
hidraw would require to extended the low level hid API. But not as extensively
as I suggested.

But I consider this to be a lost opportunity.
Currently the ll driver must assume that the device is required to be fully
operational when it is open. This means different things for ordinary input
devices and "raw" devices. Raw devices must not be autosuspended when
open at all. Ordinary devices must be able to process input.

But that is often overkill. In many situations, for example when a the screen
saver is running, you only care that a key has been pressed, not which key.
Drivers can save more power if they know this.

Quote Alan Stern:
> Would it make more sense never to autosuspend a device that has an open
> hidraw interface?  Then if you want to, you could add an API allowing

That is the sane default.

> the user to tell the kernel to suspend or to resume (if the existing
> sysfs interface isn't sufficient).

The existing sysfs interface is clearly not designed for this. It's designed
for system administration work. We are talking about ordinary user tasks
accessing a generic interface. This leads to the following deficiencies:

- the sysfs interface is specific to USB, hidraw is for all HID devices
- the sysfs interface operates on physical devices, hidraw on logical devices
- the sysfs interface is not designed to be shared among tasks
- user space tasks know a device node, not the sysfs directory

	Regards
		Oliver

Re: proposal on runtime power management in hid

[Oliver Neukum]

Am Freitag, 31. Oktober 2008 23:53:59 schrieb Ben Klein:
> 2008/10/31 Oliver Neukum <oliver@neukum.org>
> 
> > Am Freitag, 31. Oktober 2008 00:17:38 schrieb Jiri Kosina:

> > That we already have. That's the simple copout. Do not enable autosuspend
> > if you allow hidraw for a device. However, if normal users shall be able to
> > use
> > the hidraw device that means that autosuspend can never be enabled for the
> > device, as we don't know when someone will use the device.
> >
> So you're saying if a device *can be* opened, autosuspend is not enabled?

No. With the current version of the hid autosuspend patch a system that
allows autosuspend for a device to be used with hidraw is misconfigured.
 
> > For hiddev we can do better, the device is not autosuspended while it is
> > open. This allows allowing ordinary users to use the device. Doing so for
> > hidraw would require to extended the low level hid API. But not as
> > extensively
> > as I suggested.
> >
> > But I consider this to be a lost opportunity.
> > Currently the ll driver must assume that the device is required to be fully
> > operational when it is open. This means different things for ordinary input
> > devices and "raw" devices. Raw devices must not be autosuspended when
> > open at all. Ordinary devices must be able to process input.
> >
>  And now you're saying that hidraw devices should not be autosuspended when
> the device is open ... which is what the other guys are saying too.

True, but it is not all I am saying.

> But that is often overkill. In many situations, for example when a the
> > screen
> > saver is running, you only care that a key has been pressed, not which key.
> > Drivers can save more power if they know this.
> 
> Maybe they can, but this is not the point of hidraw. The point of hidraw is

The question here is how the problem is to be fixed. Should only hidraw
be fixed or a broader fix be made that can be used for input devices?

> that the driver doesn't know/care what type of device it's connected to, and
> that the device is processed by some userspace program/library. That
> userspace system can identify the device and process it correctly, even
> possibly adjust its suspension via sysfs interfaces.

Thereby making a generic interface moot. If you have to find out whether
it is USB you can just use hiddev.
 
> Quote Alan Stern:
> > > Would it make more sense never to autosuspend a device that has an open
> > > hidraw interface?  Then if you want to, you could add an API allowing
> >
> > That is the sane default.
> >
> > > the user to tell the kernel to suspend or to resume (if the existing
> > > sysfs interface isn't sufficient).
> >
> > The existing sysfs interface is clearly not designed for this. It's
> > designed
> > for system administration work. We are talking about ordinary user tasks
> > accessing a generic interface. This leads to the following deficiencies:
> >
> > - the sysfs interface is specific to USB, hidraw is for all HID devices
> > - the sysfs interface operates on physical devices, hidraw on logical
> > devices
> > - the sysfs interface is not designed to be shared among tasks
> > - user space tasks know a device node, not the sysfs directory
> >
> Let me get this straight ... you're complaining that Linux kernel internals
> are not user-friendly? This is why people write userspace libraries that

No, I am saying that they are not useable for certain purposes.

> wrap around kernel interfaces - libjsw for joysticks, libasound for ALSA,
> and if still don't like those there's SDL, or you can write your own.

That means you can no longer operate with only a file descriptor.
No inheritance by fork, exec or passing fds over sockets.
 
> As for the USB-device/HID-device argument, can you autosuspend HID devices
> that aren't USB, such as PS/2 or serial/parallel port keyboards and mice? If
> so, then a generic HID interface for sysfs may be appropriate.

Bluetooth. We are discussing HID, not input devices in a generic sense.

> Note that user space tasks don't have to know just a device node; after all,
> there is HAL.

That won't do. Simply telling a programm to work on a device by name has to
work. Even only a fd should work.

	Regards
		Oliver

Re: proposal on runtime power management in hid

[Pavel Machek]

Hi!

> > I think the simple and working solution would be never suspedning devices 
> > that have interface open through hidraw, unless user explicitly allows 
> > this through respective power/autosuspend setting in sysfs (which will by 
> > default be set to 'off' for HID devices anyway, right?).
> 
> That we already have. That's the simple copout. Do not enable autosuspend
> if you allow hidraw for a device. However, if normal users shall be able to use
> the hidraw device that means that autosuspend can never be enabled for the
> device, as we don't know when someone will use the device.
> 
> For hiddev we can do better, the device is not autosuspended while it is
> open. This allows allowing ordinary users to use the device. Doing so for
> hidraw would require to extended the low level hid API. But not as extensively
> as I suggested.
> 
> But I consider this to be a lost opportunity.
> Currently the ll driver must assume that the device is required to be fully
> operational when it is open. This means different things for ordinary input
> devices and "raw" devices. Raw devices must not be autosuspended when
> open at all. Ordinary devices must be able to process input.
> 
> But that is often overkill. In many situations, for example when a the screen
> saver is running, you only care that a key has been pressed, not which key.
> Drivers can save more power if they know this.


...way more power in some cases. Yes, I'd love to see interface like
that.

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html