Ticket #6935 (closed defect: fixed)

Opened 6 years ago

Last modified 5 years ago

Turn off USB?

Reported by: cjb Owned by: rsmith
Priority: normal Milestone:
Component: kernel Version:
Keywords: power Cc: dilinger, dwmw2
Action Needed: never set Verified: no
Deployments affected: Blocked By:
Blocking:

Description

I'm working on a manually-selected UI mode that does best possible efforts to preserve power. It can be thought of as the "reading under the covers" mode that tries to prolong your battery while you're alone. Namely, it would:

  • turn on automatic idle suspends
  • turn off networking
  • possibly use the camera to detect external lighting, and modify the backlight brightness according to how bright the environment is (turning it off altogether if you're outside).

The "turn off networking" part won't gain us much at the moment, because even unloading the wireless module doesn't stop the power draw of the 8388 -- we can't disable power to its rail altogether, because it's the main 3.3V rail. We should instead put it into reset for the duration of the low-power mode.

Richard, please point us at the documentation for doing this (via the EC?). Andres or Dave, please think about how userspace (with root) could ask for USB to be turned off completely until it wants to turn it back on again. The rationale for dropping USB completely is that it lets us show how good our suspend/resume times will be once we have USB resume put in its place. (Hey, it might also save power.)

Change History

  Changed 6 years ago by cjb

Andres or Dave, please think about how userspace (with root) could ask for USB to be turned off completely until it wants to turn it back on again.

Of course, unloading the controller modules is probably the right answer, but I think we compile the wireless module and USB controllers into the kernel image rather than as modules. I guess I'm asking to investigate if there's a good reason we need to do that, and to go modular with them if there isn't.

  Changed 6 years ago by dwmw2

I think we started building it into the kernel very early, when we were using USB disk for a lot of things, and probably even USB keyboards.

It could probably be made modular now, as long as we make sure stuff like the magic activation USB keys are still working.

It's also possible to unbind a driver from a device and rebind it later through sysfs, I believe.

in reply to: ↑ description   Changed 6 years ago by rsmith

Replying to cjb:

altogether, because it's the main 3.3V rail. We should instead put it into reset for the duration of the low-power mode.

Richard, please point us at the documentation for doing this (via the EC?).

http://dev.laptop.org/ticket/3355 http://wiki.laptop.org/go/Ec_specification#EC_Port_6c_Command_List

Cmd 0x35 (off) and 0x25 (on)

  Changed 6 years ago by cjb

Building a modular USB kernel worked fine, and I was able to rmmod the USB modules and get resume down to the ~370ms range.

dilinger points out that doing this in our main kernel would break booting from USB, so we're at a quandary.

I tried unbinding the device from the driver/controller, but couldn't get the device to unbind from the controller. Even if I could, I don't think it would do the same thing (cause us not to spend time reinitializing USB at resume time).

  Changed 6 years ago by dwmw2

You can make USB modular in the main kernel and still boot from USB, as long as you have the module in the initrd. Obviously you can't unload it before suspend when your rootfs is on USB, but that's a different issue.

  Changed 6 years ago by dilinger

Except we don't have a per-kernel initrd.. Long term, scott has wanted to build initrds with each kernel, but currently we cannot.

  Changed 6 years ago by cjb

Maybe I (or we) should work on fixing that, then? What would it entail?

  Changed 6 years ago by cjb

I think we decided on IRC today that we're going to switch to per-kernel initrds using the standard Fedora mkinitrd mechanism. Dave, Scott and Michael all expressed willingness to work on this if no-one beats them to it.

  Changed 6 years ago by cjb

While we work on mkinitrd, would anyone like to implement the EC commands Richard linked to above in the driver?

  Changed 6 years ago by cjb

Dave, which interface do you prefer for the device power on/off switch? sysfs under usb8xxx seems most reasonable to me, since we're asking the EC to kill power to the device.

  Changed 6 years ago by dwmw2

I don't think we can put it there. When we turn off the power, the device will go away... taking with it the sysfs directories...

follow-up: ↓ 13   Changed 6 years ago by cjb

Oh, good point. iwconfig/ethtool are ruled out for the same reason. What's left? :)

in reply to: ↑ 12   Changed 6 years ago by rsmith

Replying to cjb:

Oh, good point. iwconfig/ethtool are ruled out for the same reason. What's left? :)

I'll interject that the moment we add a path for userspace to send commands to the EC we might as well make it generic since the path crosses the security barrier.

I've wanted a generic userspace EC command path for a while but until now there's never been a non-debugging need. I suggest we make the EC a platform specific device for olpc and give it the ability to issue commands. Just like we do for dcon.

  Changed 6 years ago by cjb

Mmm, yak shaving. Andres/Dave, any objection to an EC platform device?

follow-up: ↓ 16   Changed 6 years ago by cjb

Andres says he had objections to EC commands being exposed to userspace in the past. We just noticed that I can have the libertas module loaded without ehci_hcd or usb8xxx loaded -- one option (and it seems to be the only one that obeys driver boundaries) is to have a sysfs toggle inside libertas for the EC reset commands. I'm happy to write this today.

in reply to: ↑ 15   Changed 6 years ago by dsaxena

Replying to cjb:

Andres says he had objections to EC commands being exposed to userspace in the past. We just noticed that I can have the libertas module loaded without ehci_hcd or usb8xxx loaded -- one option (and it seems to be the only one that obeys driver boundaries) is to have a sysfs toggle inside libertas for the EC reset commands. I'm happy to write this today.

Did the sysfs toggle for libertas get written? Since this is very OLPC specific, I think it should not be in the that driver but either just go under /sys/power/wlan_power or under some new EC-specific interface.

  Changed 6 years ago by cjb

I've written the reset functions (untested) and not hooked it up to sysfs yet, so it's a good time to think more about the interface. I don't see any problems with /sys/power; I'll put it there, and we can do whatever we like with it afterwards. Thanks.

  Changed 6 years ago by gregorio

  • milestone deleted

Milestone Never Assigned deleted

  Changed 5 years ago by rsmith

  • status changed from new to closed
  • next_action set to never set
  • resolution set to fixed
Note: See TracTickets for help on using tickets.