FS#8588 - Re-disable USB devices on disconnect to save power

Attached to Project: Rockbox
Opened by Barry Wardell (barrywardell) - Monday, 11 February 2008, 09:34 GMT
Last edited by Barry Wardell (barrywardell) - Tuesday, 19 February 2008, 15:27 GMT
Task Type Patches
Category Drivers
Status Closed
Assigned To No-one
Operating System PortalPlayer-based
Severity Low
Priority Normal
Reported Version Daily build (which?)
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No


The commit of  FS#8379  disables the USB devices and only re-enables them when USB is connected in order to save power. However, when USB is disconnected again, the USB devices are not disabled again so are probably still on and draining power. I have not actually measured this, but it seems this way from looking at the code.

The attached patch should disable the USB devices again when a disconnection is detected. Tested on a Sansa e280 to the extent that it doesn't seem to cause any new problems.
This task depends upon

Closed by  Barry Wardell (barrywardell)
Tuesday, 19 February 2008, 15:27 GMT
Reason for closing:  Accepted
Comment by Thomas Martitz (kugel.) - Monday, 11 February 2008, 11:45 GMT
Take a look at  FS#8582 . This seems to be a duplicate.
Comment by Andree Buschmann (Buschel) - Monday, 11 February 2008, 18:01 GMT
Yes, the spirit is identical to #8582.

Interesting thing is: Even when applying the patch the battery consumption is higher when charging via USB while rockbox is running, disconnecting it and directly run a battery bench. My standard usecase is to charge my iPod in "disk mode", then disconnect to load rockbox and start the battery bench after a clean startup. The consumption (calculated from the runtime) is ~3 mA higher when using the first use case.

Can anyone reproduce this and has anyone an idea? I did not find any obvious registers that were enabled during usb_core_init().
Comment by Barry Wardell (barrywardell) - Monday, 11 February 2008, 18:32 GMT
Yes, sorry I didn't notice the patch submitted yesterday by Andree. There is a small difference between the two patches in that this one only en/dis-ables the USB device when the connection status is changed, ie. it is plugged in or out.  FS#8582  does a reset and en/dis-able every time usb_pin_detect() is called which I think could be quite frequently.
Comment by Barry Wardell (barrywardell) - Tuesday, 12 February 2008, 10:24 GMT
Andree, which patch are you getting the higher battery consumption? This one or  FS#8582 ?
Comment by Andree Buschmann (Buschel) - Tuesday, 12 February 2008, 11:12 GMT
This was using  FS#8582  (and after detaching USB I've checked that the devices were disabled via debug menu).
Comment by Barry Wardell (barrywardell) - Tuesday, 12 February 2008, 14:09 GMT
Should I just commit this? I think I'd prefer to have current measurements done to be sure it's actually working right.
Comment by Andree Buschmann (Buschel) - Tuesday, 12 February 2008, 14:13 GMT
I would like to give it a short test, too. Feedback in a few hours (I am still @work).
Comment by Barry Wardell (barrywardell) - Tuesday, 12 February 2008, 15:59 GMT
OK, no rush. I won't commit it before I hear back about your test.
Comment by Andree Buschmann (Buschel) - Tuesday, 12 February 2008, 18:26 GMT
Hi, could test it now. Works like charm for me. I will re-do a battery bench within the next days to check the possible high power consumption after one-time USB-attachment.
Comment by Andree Buschmann (Buschel) - Wednesday, 13 February 2008, 06:40 GMT
Ok, did a battery bench now comparing the two charging use cases again:

1) charging via OF disk mode, restart, benching -> consumption ~28.3mA
2) charging via USB mode under rockbox, USB disconnect, benching -> consumption ~30.0mA

The former 3mA difference were a misinterpretation, nevertheless there is a significant difference of about 1.7mA between both uses cases.

Some other facts:
- DEV_EN/DEV_INIT-registers are properly set with your patch -> this does not seem to be the reason.
- Boost ratio of playback compared before and after USB-connection is nearly the same (20% -> 21%). So there is no significant higher CPU-load.

Any other ideas?
Comment by Andree Buschmann (Buschel) - Sunday, 17 February 2008, 13:22 GMT
I think this patch should be submitted.