On Mon, Jan 13, 2014 at 1:48 PM, Sarah Sharp <sarah.a.sharp@xxxxxxxxxxxxxxx> wrote: > A couple comments below. > > On Tue, Jan 07, 2014 at 12:30:21PM -0800, Dan Williams wrote: >> From: Lan Tianyu <tianyu.lan@xxxxxxxxx> >> >> describe the mechanisms for controlling port power policy and >> discovering the port power state. >> >> Cc: Oliver Neukum <oneukum@xxxxxxx> >> Signed-off-by: Lan Tianyu <tianyu.lan@xxxxxxxxx> >> Signed-off-by: Sarah Sharp <sarah.a.sharp@xxxxxxxxxxxxxxx> > > I think this version of the patch was changed since the last time I > internally signed off on it. I'll have to be more careful about sending > draft patches out with my Signed-off-by line. In this case I left it in because you authored part of the patch, but yeah makes it awkward if you are going to also be in the submission chain... > >> Signed-off-by: Dan Williams <dan.j.williams@xxxxxxxxx> >> --- >> Documentation/usb/power-management.txt | 210 ++++++++++++++++++++++++++++++++ >> 1 files changed, 210 insertions(+), 0 deletions(-) >> >> diff --git a/Documentation/usb/power-management.txt b/Documentation/usb/power-management.txt >> index 1392b61d6ebe..e5e77a67abb7 100644 >> --- a/Documentation/usb/power-management.txt >> +++ b/Documentation/usb/power-management.txt [..] >> +In addition to these files some ports may have a 'peer' link to a port on >> +another hub. The expectation is that all superspeed ports have a >> +hi-speed peer. >> + >> +/sys/bus/usb/devices/usb2/2-0:1.0/port1/peer -> ../../../usb3/3-0:1.0/port1 >> +/sys/bus/usb/devices/usb3/3-0:1.0/port1/peer -> ../../../usb2/2-0:1.0/port1 >> + >> +Physically, a superspeed port is ganged with a hi-speed port to form a >> +connector. Distinct from 'companion ports', peer ports share the same >> +ancestor XHCI device. Whereas, with a companion port, an EHCI or XHCI >> +device optionally drive the same pins. While a superspeed port is > > I think you mean "with a companion port, an EHCI or OHCI/UHCI device > optionally drive the same pins". Or are you talking about the Intel > EHCI to xHCI port switchover? We don't call those companion ports in > that case. My mistake, yes, ehci/xhci is another kind of relationship. I'll reduce that to: "Distinct from 'companion ports', or 'ehci/xhci switchover ports' peer ports are simply the hi-speed and superspeed interface pins that are combined into a single usb3 connector. Peer ports share the same ancestor XHCI device." I probably picked this up from usb_enable_intel_xhci_ports() which uses 'companion' to reference the ehci device. >> +powered off a device may downgrade its connection and attempt to connect >> +to the hi-speed pins. The implementation takes steps to prevent this >> +and sequences port power to guarantee that hi-speed ports are >> +powered-off before superspeed are allowed to suspend, and that >> +superspeed ports are recovered/repowered before hi-speed. >> + >> + power/pm_qos_no_power_off: >> + This writable flag controls the state of an idle port. >> + Once all children and descendants have suspended the >> + port may suspend/poweroff provided that >> + pm_qos_no_power_off is '0'. If pm_qos_no_power_off is >> + '1' the port will remain active/powered regardless of >> + the stats of descendants. > > You probably want to mention the default policy of '1' here. Ok, noted. [..] >> +A more aggressive userspace policy is to enable USB port power off >> +for all ports (set portX/power/pm_qos_no_power_off to '0' and set >> +portX/connect_type to 'hardwired') when some external factor indicates >> +the user has stopped interacting with the system. For example, a distro >> +may want to enable power off all USB ports when the screen blanks, and >> +re-power them when the screen becomes active. Smart phones and tablets >> +may want to power off USB ports when the user pushes the power button. > > This paragraph is out-of-date. You mention that connect_type is > read-only above, and this paragraph assumes it's read-write. > > It also assumes that the reason why userspace needs to write into > connect_type is because we won't power off a port unless it's set to > hardwired. I think that assumption is false with the current code base, > and we'll power off a port with any connect_type value, as long as > userspace says it's OK. Is that correct? Oops missed that one. Yes, ports will poweroff as soon as pm_qos_no_poweroff and pm_runtime_usage/autosuspend allows. -- 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
