On Fri, May 11, 2012 at 01:44:26PM -0400, Alan Stern wrote: > On Sat, 12 May 2012, Lan Tianyu wrote: > > > The power saving depends on devices. I test a usb3.0 ssd. The power saving of > > power off is about 2.2w more than just selective suspend. In theory, power > > off can help to save remaining power after selective suspend. > > That's a lot of power! Suspended USB devices aren't supposed to > consume more than 2.5 mA of bus current, which at 5 V amounts to <= > 0.0125 W. Does the port really use that much? Or does the SSD have a > separate power supply that it disables when port power is removed? I actually suspect that the host controller is powering off several PLLs if all the ports are powered off. After all, if it doesn't have to pay attention to connects, disconnects, or remote wakeup, it can power off a lot more circuitry, and possibly even enter D3cold instead of D3hot when the PCI device is suspended (depending on what board Tianyu is testing on). But I agree that it would be interesting to see if the SSD has a separate power supply that it's turning off. > > > The patch did not address the case of powering down ports that have no > > > devices attached. That might be a better place to start, because it's > > > simpler, even though it might not yield as much power savings. > > > > Do you mean internal ports? > > Internal or external. > > > From my opinion, ACPI will tell us whether the port is connectable or not. > > ACPI will tell you about some ports, not others (for example, ACPI > knows nothing about the ports on hubs that the user plugs in). On > other systems, a Device Tree database might provide the same > information. > > > When the internal port is not connectable, this means the port is not used > > and this patch will power down the port. > > ... > > > For external ports, this should be associated with sys file control. The users > > need to determine when they should be power off. > > You don't mean "external", you mean "not described as unconnectable by > ACPI". > > > So I should work on the external ports without devices firstly and > > add the sys file for user to control? > > Yes, I think so. It will be less controversial and probably simpler. > When that mechanism is ready, you should be able to use it > automatically for unconnectable ports. > > One tricky thing: In theory, there should be a separate sysfs file for > each port. That seems like a lot of overhead though; is there any way > to present the information in a single file that won't offend sysfs > purists? Tianyu proposed having one file per hub, with a bit field that controlled each port power. However, I was concerned about different userspace applications racing with each other to turn or off ports. For example, one app could read the bit field, attempt to power off just port 1, but before it can write to the sysfs file, a second app powers on port2, and the first app then writes to the sysfs file, leaving port 1 powered off, and port 2 powered off, which is not what the second app wanted. But if you can think of a better way to coalesce the port power off mechanisms into one file, we're all ears. :) Sarah Sharp -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
