Bug 11948

Well, it seems the problem it's because the usb hardware is not being suspended.  If I issue the following command then it gets suspended and the driver stops waking up the CPU without removing it:
echo suspend > /sys/bus/usb/devices/1-5/power/level

This immediately stops the waking up and reduces about 4 watts of power consumption according to my Kill A Watt P3 device.

I tried with "auto" instead of "suspend" but it doesn't work even if autosuspend is set to 2 seconds.  What can I do to autosuspend the device automatically and save power?

If I'm not mistaken your camera has a microphone, and the usbaudio driver doesn't support autosuspend yes. Unloading the snd_usb_audio module should help (you will still have to 'echo auto > /sys/bus/usb/devices/1-5/power/level to enable autosuspend).

Hi Laurent,

I've been doing extra testing and I think you are right.  For example, removing the uvcvideo driver stops the waking up of the CPU and reduces the power consumption because doing that powers down the webcam I suppose, but then I discovered that issuing "echo suspend > /sys/bus/usb/devices/1-5/power/level" reduced the power consumption a bit further because it suspends the USB audio thing.  I realized that because during shutdown the computer would block completely on the saving mixer settings process.  The only option there is a hard power down.

Now I wonder, is this a driver problem or a hardware problem? can we improve the usbaudio driver so that it can support autosuspend? against what component should I file a bug report?

Power saving on Linux is great but there are many hardware specific details that spoil the picture.  In this case the ideal thing would be that drivers auto suspend the webcam and the microphone while not being used (saving power) but immediately wake it up when ever I want to use the hardware.  I really hope this can be achieved sometime.

Thanks a lot for your help, it's really appreciated.

Oliver Neukum wrote a patch to implement autosuspend in the usbaudio driver. See http://www.mail-archive.com/linux-usb%40vger.kernel.org/msg00982.html for more information.

Cool! thanks a lot.

I notice that posting is a bit old, what is the state of this? is it mergeable or is it still in early stages? may be 2.6.29 material??

Cheers.

Hi Laurent,

I understand that the microphone that comes in the webcam is keeping the device from being suspended, but how come removing the uvc driver shutdowns the device (but still the mic is on)? isn't this achievable by the uvc driver itself without the need of removing the driver?  I mean, I believe the webcam and the mic should be "suspendable" in an independent way.  Am I right?

Hi William,

stop asking clever questions, will you ? :-)

I've installed powertop and played with the uvcvideo driver myself. It turns on that what keeps the USB controller busy and thus consumes power is the video status endpoint.

Most UVC camera include an interrupt endpoint to report control value changes, video streaming errors and camera button events. The USB controller continuously polls the interrupt endpoint to retrieve such events.

I can disable polling in the driver when the camera is idle, but I'm not sure how to define "idle" in this case.

Reporting video streaming errors don't make sense when the V4L2 device is closed. Control value changes are probably useless as well if nobody listens to the events, although caching will probably have to be completely disabled then. No polling would thus be required when /dev/videoX is not opened.

Camera button events are also useless if nobody listens on the corresponding /dev/input/eventX device, but hald-addon-input opens the device as soon as the camera is plugged in. I could ignore button events when the V4L2 device is closed, but we would then miss the ability to detect button events if no application is using the camera.

Jajajaja... I will, thanks for your detailed explanation.  It seems the only viable solution is to wait for the usbaudio driver to support autosuspend.  Do you know something about the status of this development?

Thanks again.

I think the button events only really make sense when the camera device is in use - the length of time taken to start an application and open the camera is long enough that it wouldn't be useful to take an immediate shot. So I suspect the easiest thing to do is just to stop the status polling when the device is closed and restart it on open.

Created attachment 20771 [details]
Start status polling on device open

Something like this? I'd guess there's a more elegant way to do it, but I know nothing about v4l.

Created attachment 21248 [details]
Start status polling on device open

Please try this slightly modified patch. If you don't notice any issue I'll apply it.

Patch 21248 sent upstream

Hello, is there any news about the patch? did it got merged upstream?

Yes, it will be available in 2.6.31

I'm using Fedora 12 and this bug seems to be fixed.  I can leave the uvcvideo driver loaded and the power consumption seems to be fine.

The only problem is that the microphone incorporated in this webcam is still active and consuming power.  I have to suspend it to save about 1 watt of power using this command:

    echo suspend > /sys/bus/usb/devices/1-5/power/level

I guess pulseaudio is keeping the device open for no good reason.  It should autosuspend until an application tries to use it.

Maybe I should file a different bug report and close this one?

(In reply to comment #15)
> Maybe I should file a different bug report and close this one?

Please do. The problem is now unrelated to the uvcvideo driver.

Ok, closing, thanks for working on this.

Any hint about what product and component should I use to file the new bug report?

Laurent, do you have any idea about which kernel component or may be user space tool should I file a bug report for the microphone not being (auto)suspended? This one saves a little bit more of power so it would be great to fix this.

In kernelspace that would be usbaudio. If I remember well, the driver supports auto-suspend.

In userspace I'm not sure, it probably depends on your desktop environment.

You could try to raise the issue on the linux-usb mailing list first to make sure the kernel driver supports auto-suspend. Search the archives first, it might turn out useful information.