From 20f6fdd01c2c0de9cc1109083222edded24c5350 Mon Sep 17 00:00:00 2001 From: Pratyush Anand Date: Fri, 4 Jul 2014 17:01:25 +0300 Subject: xhci: Platform: Set xhci lpm support quirk based on platform data If an xhci platform supports USB3 LPM capability then enable XHCI_LPM_SUPPORT quirk flag. Signed-off-by: Pratyush Anand Signed-off-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman --- Documentation/devicetree/bindings/usb/usb-xhci.txt | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/usb/usb-xhci.txt b/Documentation/devicetree/bindings/usb/usb-xhci.txt index 5a79377c6a96..86f67f0886bc 100644 --- a/Documentation/devicetree/bindings/usb/usb-xhci.txt +++ b/Documentation/devicetree/bindings/usb/usb-xhci.txt @@ -9,8 +9,9 @@ Required properties: register set for the device. - interrupts: one XHCI interrupt should be described here. -Optional property: +Optional properties: - clocks: reference to a clock + - usb3-lpm-capable: determines if platform is USB3 LPM capable Example: usb@f0931000 { -- cgit v1.2.3 From f64c51975dd635eba2a65f258013a95859b3d04a Mon Sep 17 00:00:00 2001 From: Lan Tianyu Date: Thu, 29 May 2014 12:58:52 -0700 Subject: usb: documentation for usb port power off mechanisms describe the mechanisms for controlling port power policy and discovering the port power state. [oliver]: fixes, clarification of wakeup vs port-power-control [sarah]: wordsmithing [djbw]: updates for peer port changes [alan]: review and fixes Cc: Oliver Neukum Signed-off-by: Lan Tianyu Signed-off-by: Dan Williams Acked-by: Alan Stern Signed-off-by: Greg Kroah-Hartman --- Documentation/usb/power-management.txt | 245 ++++++++++++++++++++++++++++++++- 1 file changed, 243 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/usb/power-management.txt b/Documentation/usb/power-management.txt index 1392b61d6ebe..7b90fe034c4b 100644 --- a/Documentation/usb/power-management.txt +++ b/Documentation/usb/power-management.txt @@ -2,8 +2,27 @@ Alan Stern - October 28, 2010 - + Last-updated: February 2014 + + + Contents: + --------- + * What is Power Management? + * What is Remote Wakeup? + * When is a USB device idle? + * Forms of dynamic PM + * The user interface for dynamic PM + * Changing the default idle-delay time + * Warnings + * The driver interface for Power Management + * The driver interface for autosuspend and autoresume + * Other parts of the driver interface + * Mutual exclusion + * Interaction between dynamic PM and system PM + * xHCI hardware link PM + * USB Port Power Control + * User Interface for Port Power Control + * Suggested Userspace Port Power Policy What is Power Management? @@ -516,3 +535,225 @@ relevant attribute files is usb2_hardware_lpm. driver will enable hardware LPM for the device. You can write y/Y/1 or n/N/0 to the file to enable/disable USB2 hardware LPM manually. This is for test purpose mainly. + + + USB Port Power Control + ---------------------- + +In addition to suspending endpoint devices and enabling hardware +controlled link power management, the USB subsystem also has the +capability to disable power to ports under some conditions. Power is +controlled through Set/ClearPortFeature(PORT_POWER) requests to a hub. +In the case of a root or platform-internal hub the host controller +driver translates PORT_POWER requests into platform firmware (ACPI) +method calls to set the port power state. For more background see the +Linux Plumbers Conference 2012 slides [1] and video [2]: + +Upon receiving a ClearPortFeature(PORT_POWER) request a USB port is +logically off, and may trigger the actual loss of VBUS to the port [3]. +VBUS may be maintained in the case where a hub gangs multiple ports into +a shared power well causing power to remain until all ports in the gang +are turned off. VBUS may also be maintained by hub ports configured for +a charging application. In any event a logically off port will lose +connection with its device, not respond to hotplug events, and not +respond to remote wakeup events*. + +WARNING: turning off a port may result in the inability to hot add a device. +Please see "User Interface for Port Power Control" for details. + +As far as the effect on the device itself it is similar to what a device +goes through during system suspend, i.e. the power session is lost. Any +USB device or driver that misbehaves with system suspend will be +similarly affected by a port power cycle event. For this reason the +implementation shares the same device recovery path (and honors the same +quirks) as the system resume path for the hub. + +[1]: http://dl.dropbox.com/u/96820575/sarah-sharp-lpt-port-power-off2-mini.pdf +[2]: http://linuxplumbers.ubicast.tv/videos/usb-port-power-off-kerneluserspace-api/ +[3]: USB 3.1 Section 10.12 +* wakeup note: if a device is configured to send wakeup events the port + power control implementation will block poweroff attempts on that + port. + + + User Interface for Port Power Control + ------------------------------------- + +The port power control mechanism uses the PM runtime system. Poweroff is +requested by clearing the power/pm_qos_no_power_off flag of the port device +(defaults to 1). If the port is disconnected it will immediately receive a +ClearPortFeature(PORT_POWER) request. Otherwise, it will honor the pm runtime +rules and require the attached child device and all descendants to be suspended. +This mechanism is dependent on the hub advertising port power switching in its +hub descriptor (wHubCharacteristics logical power switching mode field). + +Note, some interface devices/drivers do not support autosuspend. Userspace may +need to unbind the interface drivers before the usb_device will suspend. An +unbound interface device is suspended by default. When unbinding, be careful +to unbind interface drivers, not the driver of the parent usb device. Also, +leave hub interface drivers bound. If the driver for the usb device (not +interface) is unbound the kernel is no longer able to resume the device. If a +hub interface driver is unbound, control of its child ports is lost and all +attached child-devices will disconnect. A good rule of thumb is that if the +'driver/module' link for a device points to /sys/module/usbcore then unbinding +it will interfere with port power control. + +Example of the relevant files for port power control. Note, in this example +these files are relative to a usb hub device (prefix). + + prefix=/sys/devices/pci0000:00/0000:00:14.0/usb3/3-1 + + attached child device + + hub port device + | + hub interface device + | | + v v v + $prefix/3-1:1.0/3-1-port1/device + + $prefix/3-1:1.0/3-1-port1/power/pm_qos_no_power_off + $prefix/3-1:1.0/3-1-port1/device/power/control + $prefix/3-1:1.0/3-1-port1/device/3-1.1:/driver/unbind + $prefix/3-1:1.0/3-1-port1/device/3-1.1:/driver/unbind + ... + $prefix/3-1:1.0/3-1-port1/device/3-1.1:/driver/unbind + +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. + +$prefix/3-1:1.0/3-1-port1/peer -> ../../../../usb2/2-1/2-1:1.0/2-1-port1 +../../../../usb2/2-1/2-1:1.0/2-1-port1/peer -> ../../../../usb3/3-1/3-1:1.0/3-1-port1 + +Distinct from 'companion ports', or 'ehci/xhci shared 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. + +While a superspeed port is powered off a device may downgrade its +connection and attempt to connect to the hi-speed pins. The +implementation takes steps to prevent this: + +1/ Port suspend is sequenced to guarantee that hi-speed ports are powered-off + before their superspeed peer is permitted to power-off. The implication is + that the setting pm_qos_no_power_off to zero on a superspeed port may not cause + the port to power-off until its highspeed peer has gone to its runtime suspend + state. Userspace must take care to order the suspensions if it wants to + guarantee that a superspeed port will power-off. + +2/ Port resume is sequenced to force a superspeed port to power-on prior to its + highspeed peer. + +3/ Port resume always triggers an attached child device to resume. After a + power session is lost the device may have been removed, or need reset. + Resuming the child device when the parent port regains power resolves those + states and clamps the maximum port power cycle frequency at the rate the child + device can suspend (autosuspend-delay) and resume (reset-resume latency). + +Sysfs files relevant for port power control: + /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. Defaults to 1. + + /power/runtime_status: + This file reflects whether the port is 'active' (power is on) + or 'suspended' (logically off). There is no indication to + userspace whether VBUS is still supplied. + + /connect_type: + An advisory read-only flag to userspace indicating the + location and connection type of the port. It returns + one of four values 'hotplug', 'hardwired', 'not used', + and 'unknown'. All values, besides unknown, are set by + platform firmware. + + "hotplug" indicates an externally connectable/visible + port on the platform. Typically userspace would choose + to keep such a port powered to handle new device + connection events. + + "hardwired" refers to a port that is not visible but + connectable. Examples are internal ports for USB + bluetooth that can be disconnected via an external + switch or a port with a hardwired USB camera. It is + expected to be safe to allow these ports to suspend + provided pm_qos_no_power_off is coordinated with any + switch that gates connections. Userspace must arrange + for the device to be connected prior to the port + powering off, or to activate the port prior to enabling + connection via a switch. + + "not used" refers to an internal port that is expected + to never have a device connected to it. These may be + empty internal ports, or ports that are not physically + exposed on a platform. Considered safe to be + powered-off at all times. + + "unknown" means platform firmware does not provide + information for this port. Most commonly refers to + external hub ports which should be considered 'hotplug' + for policy decisions. + + NOTE1: since we are relying on the BIOS to get this ACPI + information correct, the USB port descriptions may be + missing or wrong. + + NOTE2: Take care in clearing pm_qos_no_power_off. Once + power is off this port will + not respond to new connect events. + + Once a child device is attached additional constraints are + applied before the port is allowed to poweroff. + + /power/control: + Must be 'auto', and the port will not + power down until /power/runtime_status + reflects the 'suspended' state. Default + value is controlled by child device driver. + + /power/persist: + This defaults to '1' for most devices and indicates if + kernel can persist the device's configuration across a + power session loss (suspend / port-power event). When + this value is '0' (quirky devices), port poweroff is + disabled. + + /driver/unbind: + Wakeup capable devices will block port poweroff. At + this time the only mechanism to clear the usb-internal + wakeup-capability for an interface device is to unbind + its driver. + +Summary of poweroff pre-requisite settings relative to a port device: + + echo 0 > power/pm_qos_no_power_off + echo 0 > peer/power/pm_qos_no_power_off # if it exists + echo auto > power/control # this is the default value + echo auto > /power/control + echo 1 > /power/persist # this is the default value + + Suggested Userspace Port Power Policy + ------------------------------------- + +As noted above userspace needs to be careful and deliberate about what +ports are enabled for poweroff. + +The default configuration is that all ports start with +power/pm_qos_no_power_off set to '1' causing ports to always remain +active. + +Given confidence in the platform firmware's description of the ports +(ACPI _PLD record for a port populates 'connect_type') userspace can +clear pm_qos_no_power_off for all 'not used' ports. The same can be +done for 'hardwired' ports provided poweroff is coordinated with any +connection switch for the port. + +A more aggressive userspace policy is to enable USB port power off for +all ports (set /power/pm_qos_no_power_off to '0') 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. -- cgit v1.2.3 From 31e01f0aca3e9b77fea0b1c1b569b02fa2812eb6 Mon Sep 17 00:00:00 2001 From: Jeremiah Mahler Date: Fri, 6 Jun 2014 12:29:17 -0700 Subject: usb: doc: hotplug.txt code typos Fixed several typos in the code examples given in Documentation/usb/hotplug.txt. - missing [] with array of struct usb_device_id - checkpatch.pl warning: space between function name and parenthesis - missing terminating ';' Signed-off-by: Jeremiah Mahler Signed-off-by: Greg Kroah-Hartman --- Documentation/usb/hotplug.txt | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) (limited to 'Documentation') diff --git a/Documentation/usb/hotplug.txt b/Documentation/usb/hotplug.txt index 6424b130485c..a80b0e9a7a0b 100644 --- a/Documentation/usb/hotplug.txt +++ b/Documentation/usb/hotplug.txt @@ -105,13 +105,13 @@ macros such as these, and use driver_info to store more information. A short example, for a driver that supports several specific USB devices and their quirks, might have a MODULE_DEVICE_TABLE like this: - static const struct usb_device_id mydriver_id_table = { + static const struct usb_device_id mydriver_id_table[] = { { USB_DEVICE (0x9999, 0xaaaa), driver_info: QUIRK_X }, { USB_DEVICE (0xbbbb, 0x8888), driver_info: QUIRK_Y|QUIRK_Z }, ... { } /* end with an all-zeroes entry */ - } - MODULE_DEVICE_TABLE (usb, mydriver_id_table); + }; + MODULE_DEVICE_TABLE(usb, mydriver_id_table); Most USB device drivers should pass these tables to the USB subsystem as well as to the module management subsystem. Not all, though: some driver @@ -134,7 +134,7 @@ something like this: if exposing any operations through usbdevfs: .ioctl = my_ioctl, */ - } + }; When the USB subsystem knows about a driver's device ID table, it's used when choosing drivers to probe(). The thread doing new device processing checks -- cgit v1.2.3 From cc583db3d708886ef89bce9d686419c58400182c Mon Sep 17 00:00:00 2001 From: Paul Bolle Date: Wed, 2 Jul 2014 12:10:45 +0200 Subject: Documentation: sysfs-bus-usb: update power/persist description There's no power/persist file for hubs. And CONFIG_USB_PERSIST was removed in v2.6.26. Update the description of power/persist accordingly. Also remove the line on its default value. It is not entirely correct, as CONFIG_USB_DEFAULT_PERSIST and the USB_QUIRK_RESET flag influence the default. It is not needed to understand this file anyhow. Signed-off-by: Paul Bolle Acked-by: Alan Stern Signed-off-by: Greg Kroah-Hartman --- Documentation/ABI/stable/sysfs-bus-usb | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) (limited to 'Documentation') diff --git a/Documentation/ABI/stable/sysfs-bus-usb b/Documentation/ABI/stable/sysfs-bus-usb index a6b685724740..e2bc700a6f9c 100644 --- a/Documentation/ABI/stable/sysfs-bus-usb +++ b/Documentation/ABI/stable/sysfs-bus-usb @@ -3,13 +3,13 @@ Date: May 2007 KernelVersion: 2.6.23 Contact: Alan Stern Description: - If CONFIG_USB_PERSIST is set, then each USB device directory - will contain a file named power/persist. The file holds a - boolean value (0 or 1) indicating whether or not the - "USB-Persist" facility is enabled for the device. Since the - facility is inherently dangerous, it is disabled by default - for all devices except hubs. For more information, see - Documentation/usb/persist.txt. + USB device directories can contain a file named power/persist. + The file holds a boolean value (0 or 1) indicating whether or + not the "USB-Persist" facility is enabled for the device. For + hubs this facility is always enabled and their device + directories will not contain this file. + + For more information, see Documentation/usb/persist.txt. What: /sys/bus/usb/devices/.../power/autosuspend Date: March 2007 -- cgit v1.2.3 From 883df42abff97b4791c7bc466226b878a828ecc5 Mon Sep 17 00:00:00 2001 From: Tuomas Tynkkynen Date: Fri, 4 Jul 2014 04:09:36 +0300 Subject: USB: tegra: Add resets & has-utmi-pad-registers flag to the PHY binding When Tegra was converted to use the standard reset bindings, the PHY was forgotten, probably because all the resetting of the USB blocks were done in the EHCI driver. What also went unnoticed is that resetting the 1st on-chip USB module also wipes some of the UTMI pad configuration registers that are also used by the other USB blocks. So this fact needs to be described in the device tree, and the driver modified not to reset the 1st module at inappropriate times. In order to stay compatible with old device trees, the USB drivers will still function without these properties but with the old, potentially buggy behaviour. Signed-off-by: Tuomas Tynkkynen Acked-by: Mark Rutland Signed-off-by: Greg Kroah-Hartman --- Documentation/devicetree/bindings/usb/nvidia,tegra20-usb-phy.txt | 8 ++++++++ 1 file changed, 8 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/usb/nvidia,tegra20-usb-phy.txt b/Documentation/devicetree/bindings/usb/nvidia,tegra20-usb-phy.txt index ba797d3e6326..c9205fbf26e2 100644 --- a/Documentation/devicetree/bindings/usb/nvidia,tegra20-usb-phy.txt +++ b/Documentation/devicetree/bindings/usb/nvidia,tegra20-usb-phy.txt @@ -20,6 +20,12 @@ Required properties : Present if phy_type == utmi. - ulpi-link: The clock Tegra provides to the ULPI PHY (cdev2). Present if phy_type == ulpi, and ULPI link mode is in use. + - resets : Must contain an entry for each entry in reset-names. + See ../reset/reset.txt for details. + - reset-names : Must include the following entries: + - usb: The PHY's own reset signal. + - utmi-pads: The reset of the PHY containing the chip-wide UTMI pad control + registers. Required even if phy_type == ulpi. Required properties for phy_type == ulpi: - nvidia,phy-reset-gpio : The GPIO used to reset the PHY. @@ -56,6 +62,8 @@ Optional properties: host means this is a host controller peripheral means it is device controller otg means it can operate as either ("on the go") + - nvidia,has-utmi-pad-registers : boolean indicates whether this controller + contains the UTMI pad control registers common to all USB controllers. VBUS control (required for dr_mode == otg, optional for dr_mode == host): - vbus-supply: regulator for VBUS -- cgit v1.2.3 From 8346b33fad01cfe93f0fd0e64cd32ff40bd4ba41 Mon Sep 17 00:00:00 2001 From: Andrzej Pietrasiewicz Date: Thu, 17 Jul 2014 16:41:29 +0200 Subject: Documentation: DocBook: elieminate doc build break Gadget function files have been moved to a "function" subdirectory. Signed-off-by: Andrzej Pietrasiewicz Signed-off-by: Felipe Balbi --- Documentation/DocBook/gadget.tmpl | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) (limited to 'Documentation') diff --git a/Documentation/DocBook/gadget.tmpl b/Documentation/DocBook/gadget.tmpl index 4017f147ba2f..1197165b8f28 100644 --- a/Documentation/DocBook/gadget.tmpl +++ b/Documentation/DocBook/gadget.tmpl @@ -556,11 +556,11 @@ been converted to this framework. Near-term plans include converting all of them, except for "gadgetfs". -!Edrivers/usb/gadget/f_acm.c -!Edrivers/usb/gadget/f_ecm.c -!Edrivers/usb/gadget/f_subset.c -!Edrivers/usb/gadget/f_obex.c -!Edrivers/usb/gadget/f_serial.c +!Edrivers/usb/gadget/function/f_acm.c +!Edrivers/usb/gadget/function/f_ecm.c +!Edrivers/usb/gadget/function/f_subset.c +!Edrivers/usb/gadget/function/f_obex.c +!Edrivers/usb/gadget/function/f_serial.c -- cgit v1.2.3 From ce21bfe603b3401c258c415456c915634998e133 Mon Sep 17 00:00:00 2001 From: Pratyush Anand Date: Mon, 14 Jul 2014 19:27:49 +0530 Subject: USB: Add LVS Test device driver OTG3 and EH Compliance Plan 1.0 talks about Super Speed OTG Verification system (SS-OVS) which consists of an excersizer and analyzer. USB Compliance Suite from Lecroy or Ellisys can act as such SS-OVS for Link Layer Validation (LVS). Some modifications are needed for an embedded Linux USB host to pass all these tests. Most of these tests require just Link to be in U0. They do not work with default Linux USB stack since, default stack does port reset and then starts sending setup packet, which is not expected by Link Layer Validation (LVS) device of Lecroy Compliance Suit. Then, There are many Link Layer Tests which need host to generate specific traffic. This patch supports specific traffic generation cases. As of now all the host Lecroy Link Layer-USBIF tests (except TD7.26) passes with this patch for single run using Lecroy USB Compliance Suite Version 1.98 Build 239 and Lecroy USB Protocol Analyzer version 4.80 Build 1603. Therefore patch seems to be a good candidate for inclusion. Further modification can be done on top of it. lvstest driver will not bind to any device by default. It can bind manually to a super speed USB host controller root hub. Therefore, regular hub driver must be unbound before this driver is bound. For example, if 2-0:1.0 is the xhci root hub, then execute following to unbind hub driver. echo 2-0:1.0 > /sys/bus/usb/drivers/hub/unbind Then write Linux Foundation's vendor ID which is used by root hubs and SS root hub's device ID into new_id file. Writing IDs into new_id file will also bind the lvs driver with any available SS root hub interfaces. echo "1D6B 3" > /sys/bus/usb/drivers/lvs/new_id Now connect LVS device with root hub port. Test case specific traffic can be generated as follows whenever needed: 1. To issue "Get Device descriptor" command for TD.7.06: echo > /sys/bus/usb/devices/2-0\:1.0/get_dev_desc 2. To set U1 timeout to 127 for TD.7.18 echo 127 > /sys/bus/usb/devices/2-0\:1.0/u1_timeout 3. To set U2 timeout to 0 for TD.7.18 echo 0 > /sys/bus/usb/devices/2-0\:1.0/u2_timeout 4. To issue "Hot Reset" for TD.7.29 echo > /sys/bus/usb/devices/2-0\:1.0/hot_reset 5. To issue "U3 Entry" for TD.7.35 echo > /sys/bus/usb/devices/2-0\:1.0/u3_entry 6. To issue "U3 Exit" for TD.7.36 echo > /sys/bus/usb/devices/2-0\:1.0/u3_exit Signed-off-by: Pratyush Anand Acked-by: Alan Stern Signed-off-by: Greg Kroah-Hartman --- Documentation/ABI/testing/sysfs-bus-usb-lvstest | 47 +++++++++++++++++++++++++ 1 file changed, 47 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-bus-usb-lvstest (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-bus-usb-lvstest b/Documentation/ABI/testing/sysfs-bus-usb-lvstest new file mode 100644 index 000000000000..aae68fc2d842 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-bus-usb-lvstest @@ -0,0 +1,47 @@ +Link Layer Validation Device is a standard device for testing of Super +Speed Link Layer tests. These nodes are available in sysfs only when lvs +driver is bound with root hub device. + +What: /sys/bus/usb/devices/.../get_dev_desc +Date: March 2014 +Contact: Pratyush Anand +Description: + Write to this node to issue "Get Device Descriptor" + for Link Layer Validation device. It is needed for TD.7.06. + +What: /sys/bus/usb/devices/.../u1_timeout +Date: March 2014 +Contact: Pratyush Anand +Description: + Set "U1 timeout" for the downstream port where Link Layer + Validation device is connected. Timeout value must be between 0 + and 127. It is needed for TD.7.18, TD.7.19, TD.7.20 and TD.7.21. + +What: /sys/bus/usb/devices/.../u2_timeout +Date: March 2014 +Contact: Pratyush Anand +Description: + Set "U2 timeout" for the downstream port where Link Layer + Validation device is connected. Timeout value must be between 0 + and 127. It is needed for TD.7.18, TD.7.19, TD.7.20 and TD.7.21. + +What: /sys/bus/usb/devices/.../hot_reset +Date: March 2014 +Contact: Pratyush Anand +Description: + Write to this node to issue "Reset" for Link Layer Validation + device. It is needed for TD.7.29, TD.7.31, TD.7.34 and TD.7.35. + +What: /sys/bus/usb/devices/.../u3_entry +Date: March 2014 +Contact: Pratyush Anand +Description: + Write to this node to issue "U3 entry" for Link Layer + Validation device. It is needed for TD.7.35 and TD.7.36. + +What: /sys/bus/usb/devices/.../u3_exit +Date: March 2014 +Contact: Pratyush Anand +Description: + Write to this node to issue "U3 exit" for Link Layer + Validation device. It is needed for TD.7.36. -- cgit v1.2.3 From 99bbd48c2065552fd2d224c9f065dcac9b7e25ce Mon Sep 17 00:00:00 2001 From: Kishon Vijay Abraham I Date: Wed, 25 Jun 2014 23:22:56 +0530 Subject: phy: phy-omap-pipe3: Add support for PCIe PHY PCIe PHY uses an external pll instead of the internal pll used by SATA and USB3. So added support in pipe3 PHY to use external pll. Signed-off-by: Kishon Vijay Abraham I Reviewed-by: Roger Quadros --- Documentation/devicetree/bindings/phy/ti-phy.txt | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/phy/ti-phy.txt b/Documentation/devicetree/bindings/phy/ti-phy.txt index 9ce458f32945..b50e1c10a05d 100644 --- a/Documentation/devicetree/bindings/phy/ti-phy.txt +++ b/Documentation/devicetree/bindings/phy/ti-phy.txt @@ -56,8 +56,8 @@ usb2phy@4a0ad080 { TI PIPE3 PHY Required properties: - - compatible: Should be "ti,phy-usb3" or "ti,phy-pipe3-sata". - "ti,omap-usb3" is deprecated. + - compatible: Should be "ti,phy-usb3", "ti,phy-pipe3-sata" or + "ti,phy-pipe3-pcie. "ti,omap-usb3" is deprecated. - reg : Address and length of the register set for the device. - reg-names: The names of the register addresses corresponding to the registers filled in "reg". @@ -69,10 +69,17 @@ Required properties: * "wkupclk" - wakeup clock. * "sysclk" - system clock. * "refclk" - reference clock. + * "dpll_ref" - external dpll ref clk + * "dpll_ref_m2" - external dpll ref clk + * "phy-div" - divider for apll + * "div-clk" - apll clock Optional properties: - ctrl-module : phandle of the control module used by PHY driver to power on the PHY. + - id: If there are multiple instance of the same type, in order to + differentiate between each instance "id" can be used (e.g., multi-lane PCIe + PHY). If "id" is not provided, it is set to default value of '1'. This is usually a subnode of ocp2scp to which it is connected. -- cgit v1.2.3 From f0e2cf7b912522c9c7146d9d6e99d1b0ea5c97c6 Mon Sep 17 00:00:00 2001 From: Kishon Vijay Abraham I Date: Wed, 25 Jun 2014 23:22:57 +0530 Subject: phy: pipe3: insert delay to enumerate in GEN2 mode 8-bit delay value (0xF1) is required for GEN2 devices to be enumerated consistently. Added an API to be called from PHY drivers to set this delay value and called it from PIPE3 driver to set the delay value. Signed-off-by: Kishon Vijay Abraham I Reviewed-by: Roger Quadros --- Documentation/devicetree/bindings/phy/ti-phy.txt | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/phy/ti-phy.txt b/Documentation/devicetree/bindings/phy/ti-phy.txt index b50e1c10a05d..305e3df3d9b1 100644 --- a/Documentation/devicetree/bindings/phy/ti-phy.txt +++ b/Documentation/devicetree/bindings/phy/ti-phy.txt @@ -9,15 +9,17 @@ Required properties: e.g. USB2_PHY on OMAP5. "ti,control-phy-pipe3" - if it has DPLL and individual Rx & Tx power control e.g. USB3 PHY and SATA PHY on OMAP5. + "ti,control-phy-pcie" - for pcie to support external clock for pcie and to + set PCS delay value. + e.g. PCIE PHY in DRA7x "ti,control-phy-usb2-dra7" - if it has power down register like USB2 PHY on DRA7 platform. "ti,control-phy-usb2-am437" - if it has power down register like USB2 PHY on AM437 platform. - - reg : Address and length of the register set for the device. It contains - the address of "otghs_control" for control-phy-otghs or "power" register - for other types. - - reg-names: should be "otghs_control" control-phy-otghs and "power" for - other types. + - reg : register ranges as listed in the reg-names property + - reg-names: "otghs_control" for control-phy-otghs + "power", "pcie_pcs" and "control_sma" for control-phy-pcie + "power" for all other types omap_control_usb: omap-control-usb@4a002300 { compatible = "ti,control-phy-otghs"; -- cgit v1.2.3 From f1876accff7ffb3f3cb91ab86aaa866a5eec3f0a Mon Sep 17 00:00:00 2001 From: Jiancheng Xue Date: Thu, 3 Jul 2014 22:28:37 +0800 Subject: Documentation: Document Hisilicon hix5hd2 sata PHY Add necessary binding documentation SATA PHY on Hisilicon hix5hd2 soc. Signed-off-by: Jiancheng Xue Signed-off-by: Zhangfei Gao Signed-off-by: Kishon Vijay Abraham I --- .../devicetree/bindings/phy/hix5hd2-phy.txt | 22 ++++++++++++++++++++++ 1 file changed, 22 insertions(+) create mode 100644 Documentation/devicetree/bindings/phy/hix5hd2-phy.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/phy/hix5hd2-phy.txt b/Documentation/devicetree/bindings/phy/hix5hd2-phy.txt new file mode 100644 index 000000000000..296168b74d24 --- /dev/null +++ b/Documentation/devicetree/bindings/phy/hix5hd2-phy.txt @@ -0,0 +1,22 @@ +Hisilicon hix5hd2 SATA PHY +----------------------- + +Required properties: +- compatible: should be "hisilicon,hix5hd2-sata-phy" +- reg: offset and length of the PHY registers +- #phy-cells: must be 0 +Refer to phy/phy-bindings.txt for the generic PHY binding properties + +Optional Properties: +- hisilicon,peripheral-syscon: phandle of syscon used to control peripheral. +- hisilicon,power-reg: offset and bit number within peripheral-syscon, + register of controlling sata power supply. + +Example: + sata_phy: phy@f9900000 { + compatible = "hisilicon,hix5hd2-sata-phy"; + reg = <0xf9900000 0x10000>; + #phy-cells = <0>; + hisilicon,peripheral-syscon = <&peripheral_ctrl>; + hisilicon,power-reg = <0x8 10>; + }; -- cgit v1.2.3 From 016e0d3cb72c1433810fd85a7a7c0946e710d3d6 Mon Sep 17 00:00:00 2001 From: Marek Szyprowski Date: Mon, 7 Jul 2014 11:39:26 +0200 Subject: drivers: phy: exynos-usb2: add support for Exynos 3250 This patch adds support for Exynos3250 SoC to Exynos2USB PHY driver. Although Exynos3250 has only one device phy interface, the register layout and all operations that are required to get it enabled are almost same as on Exynos4x12. The only different is one more register (REFCLKSEL) which need to be set and lack of MODE SWITCH register. Signed-off-by: Marek Szyprowski Reviewed-by: Tomasz Figa Signed-off-by: Kishon Vijay Abraham I --- Documentation/devicetree/bindings/phy/samsung-phy.txt | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/phy/samsung-phy.txt b/Documentation/devicetree/bindings/phy/samsung-phy.txt index 2049261d8c31..6099a5c94283 100644 --- a/Documentation/devicetree/bindings/phy/samsung-phy.txt +++ b/Documentation/devicetree/bindings/phy/samsung-phy.txt @@ -26,6 +26,7 @@ Samsung S5P/EXYNOS SoC series USB PHY Required properties: - compatible : should be one of the listed compatibles: + - "samsung,exynos3250-usb2-phy" - "samsung,exynos4210-usb2-phy" - "samsung,exynos4x12-usb2-phy" - "samsung,exynos5250-usb2-phy" @@ -46,6 +47,7 @@ and Exynos 4212) it is as follows: 1 - USB host ("host"), 2 - HSIC0 ("hsic0"), 3 - HSIC1 ("hsic1"), +Exynos3250 has only USB device phy available as phy 0. Exynos 4210 and Exynos 4212 use mode switching and require that mode switch register is supplied. -- cgit v1.2.3 From e9e8cf49f9ebbdc8ffafc9627bfade76c5384845 Mon Sep 17 00:00:00 2001 From: Roger Quadros Date: Fri, 4 Jul 2014 12:55:46 +0300 Subject: phy: core: Add phy-supply to DT binding documentation phy-supply is a phandle to the regulator that provides power to the PHY. This regulator is managed during the PHY power on/off sequence by the phy core driver. Signed-off-by: Roger Quadros Signed-off-by: Kishon Vijay Abraham I --- Documentation/devicetree/bindings/phy/phy-bindings.txt | 4 ++++ 1 file changed, 4 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/phy/phy-bindings.txt b/Documentation/devicetree/bindings/phy/phy-bindings.txt index 8ae844fc0c60..2aa1840200ed 100644 --- a/Documentation/devicetree/bindings/phy/phy-bindings.txt +++ b/Documentation/devicetree/bindings/phy/phy-bindings.txt @@ -10,6 +10,10 @@ Required Properties: provider can use the values in cells to find the appropriate PHY. +Optional Properties: +phy-supply: Phandle to a regulator that provides power to the PHY. This + regulator will be managed during the PHY power on/off sequence. + For example: phys: phy { -- cgit v1.2.3 From e299f59a2ea1d1f6ce43ebfc56c75ea266a056de Mon Sep 17 00:00:00 2001 From: Srinivas Kandagatla Date: Mon, 14 Jul 2014 12:18:08 +0100 Subject: phy: qcom: Add APQ8064 SATA PHY device tree bindings This patch adds binding spec for Qualcomm AP8064 SATA PHY. Signed-off-by: Srinivas Kandagatla Tested-by: Kiran Padwal Signed-off-by: Kishon Vijay Abraham I --- .../bindings/phy/qcom-apq8064-sata-phy.txt | 24 ++++++++++++++++++++++ 1 file changed, 24 insertions(+) create mode 100644 Documentation/devicetree/bindings/phy/qcom-apq8064-sata-phy.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/phy/qcom-apq8064-sata-phy.txt b/Documentation/devicetree/bindings/phy/qcom-apq8064-sata-phy.txt new file mode 100644 index 000000000000..952f6c96bab9 --- /dev/null +++ b/Documentation/devicetree/bindings/phy/qcom-apq8064-sata-phy.txt @@ -0,0 +1,24 @@ +Qualcomm APQ8064 SATA PHY Controller +------------------------------------ + +SATA PHY nodes are defined to describe on-chip SATA Physical layer controllers. +Each SATA PHY controller should have its own node. + +Required properties: +- compatible: compatible list, contains "qcom,apq8064-sata-phy". +- reg: offset and length of the SATA PHY register set; +- #phy-cells: must be zero +- clocks: a list of phandles and clock-specifier pairs, one for each entry in + clock-names. +- clock-names: must be "cfg" for phy config clock. + +Example: + sata_phy: sata-phy@1b400000 { + compatible = "qcom,apq8064-sata-phy"; + reg = <0x1b400000 0x200>; + + clocks = <&gcc SATA_PHY_CFG_CLK>; + clock-names = "cfg"; + + #phy-cells = <0>; + }; -- cgit v1.2.3 From 6e58240fae556c23150bb0c7cb9fdba17e6c14cf Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Antoine=20T=C3=A9nart?= Date: Mon, 7 Jul 2014 12:16:08 +0200 Subject: Documentation: bindings: add the Berlin SATA PHY MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The Berlin SATA PHY drives the PHY related to the SATA interface. Add the corresponding documentation. Signed-off-by: Antoine Ténart Signed-off-by: Kishon Vijay Abraham I --- .../devicetree/bindings/phy/berlin-sata-phy.txt | 34 ++++++++++++++++++++++ 1 file changed, 34 insertions(+) create mode 100644 Documentation/devicetree/bindings/phy/berlin-sata-phy.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/phy/berlin-sata-phy.txt b/Documentation/devicetree/bindings/phy/berlin-sata-phy.txt new file mode 100644 index 000000000000..88f8c23384c0 --- /dev/null +++ b/Documentation/devicetree/bindings/phy/berlin-sata-phy.txt @@ -0,0 +1,34 @@ +Berlin SATA PHY +--------------- + +Required properties: +- compatible: should be "marvell,berlin2q-sata-phy" +- address-cells: should be 1 +- size-cells: should be 0 +- phy-cells: from the generic PHY bindings, must be 1 +- reg: address and length of the register +- clocks: reference to the clock entry + +Sub-nodes: +Each PHY should be represented as a sub-node. + +Sub-nodes required properties: +- reg: the PHY number + +Example: + sata_phy: phy@f7e900a0 { + compatible = "marvell,berlin2q-sata-phy"; + reg = <0xf7e900a0 0x200>; + clocks = <&chip CLKID_SATA>; + #address-cells = <1>; + #size-cells = <0>; + #phy-cells = <1>; + + sata-phy@0 { + reg = <0>; + }; + + sata-phy@1 { + reg = <1>; + }; + }; -- cgit v1.2.3 From f0ed817638b59aa927f1f7e9564dd8796b18dc4f Mon Sep 17 00:00:00 2001 From: Kishon Vijay Abraham I Date: Mon, 14 Jul 2014 15:55:02 +0530 Subject: phy: core: Let node ptr of PHY point to PHY and not of PHY provider In case of multi-phy PHY providers, each PHY should be modeled as a sub node of the PHY provider. Then each PHY will have a different node pointer (node pointer of sub node) than that of PHY provider. Added this provision in the PHY core. Also fixed all drivers to use the updated API. Signed-off-by: Kishon Vijay Abraham I Acked-by: Lee Jones --- Documentation/phy.txt | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) (limited to 'Documentation') diff --git a/Documentation/phy.txt b/Documentation/phy.txt index ebff6ee52441..c6594af94d25 100644 --- a/Documentation/phy.txt +++ b/Documentation/phy.txt @@ -53,10 +53,12 @@ unregister the PHY. The PHY driver should create the PHY in order for other peripheral controllers to make use of it. The PHY framework provides 2 APIs to create the PHY. -struct phy *phy_create(struct device *dev, const struct phy_ops *ops, - struct phy_init_data *init_data); -struct phy *devm_phy_create(struct device *dev, const struct phy_ops *ops, - struct phy_init_data *init_data); +struct phy *phy_create(struct device *dev, struct device_node *node, + const struct phy_ops *ops, + struct phy_init_data *init_data); +struct phy *devm_phy_create(struct device *dev, struct device_node *node, + const struct phy_ops *ops, + struct phy_init_data *init_data); The PHY drivers can use one of the above 2 APIs to create the PHY by passing the device pointer, phy ops and init_data. -- cgit v1.2.3 From c4aee1aacb4798d23f514ab4eb59acef752d2397 Mon Sep 17 00:00:00 2001 From: Kumar Gala Date: Wed, 16 Jul 2014 11:10:09 -0500 Subject: phy: qcom: Add device tree bindings for IPQ806x SATA PHY Add binding spec for Qualcomm SoC PHYs, starting with the SATA PHY on the IPQ806x family of SoCs. Signed-off-by: Kumar Gala Signed-off-by: Kishon Vijay Abraham I --- .../bindings/phy/qcom-ipq806x-sata-phy.txt | 23 ++++++++++++++++++++++ 1 file changed, 23 insertions(+) create mode 100644 Documentation/devicetree/bindings/phy/qcom-ipq806x-sata-phy.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/phy/qcom-ipq806x-sata-phy.txt b/Documentation/devicetree/bindings/phy/qcom-ipq806x-sata-phy.txt new file mode 100644 index 000000000000..76bfbd056202 --- /dev/null +++ b/Documentation/devicetree/bindings/phy/qcom-ipq806x-sata-phy.txt @@ -0,0 +1,23 @@ +Qualcomm IPQ806x SATA PHY Controller +------------------------------------ + +SATA PHY nodes are defined to describe on-chip SATA Physical layer controllers. +Each SATA PHY controller should have its own node. + +Required properties: +- compatible: compatible list, contains "qcom,ipq806x-sata-phy" +- reg: offset and length of the SATA PHY register set; +- #phy-cells: must be zero +- clocks: must be exactly one entry +- clock-names: must be "cfg" + +Example: + sata_phy: sata-phy@1b400000 { + compatible = "qcom,ipq806x-sata-phy"; + reg = <0x1b400000 0x200>; + + clocks = <&gcc SATA_PHY_CFG_CLK>; + clock-names = "cfg"; + + #phy-cells = <0>; + }; -- cgit v1.2.3 From f5c9f3be608017577731ebe8be37e55f800586d3 Mon Sep 17 00:00:00 2001 From: Lee Jones Date: Thu, 10 Jul 2014 10:09:31 +0100 Subject: phy: miphy365x: Add Device Tree bindings for the MiPHY365x The MiPHY365x is a Generic PHY which can serve various SATA or PCIe devices. It has 2 ports which it can use for either; both SATA, both PCIe or one of each in any configuration. Acked-by: Mark Rutland Acked-by: Alexandre Torgue Signed-off-by: Lee Jones Signed-off-by: Kishon Vijay Abraham I --- .../devicetree/bindings/phy/phy-miphy365x.txt | 76 ++++++++++++++++++++++ 1 file changed, 76 insertions(+) create mode 100644 Documentation/devicetree/bindings/phy/phy-miphy365x.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/phy/phy-miphy365x.txt b/Documentation/devicetree/bindings/phy/phy-miphy365x.txt new file mode 100644 index 000000000000..42c880886cf7 --- /dev/null +++ b/Documentation/devicetree/bindings/phy/phy-miphy365x.txt @@ -0,0 +1,76 @@ +STMicroelectronics STi MIPHY365x PHY binding +============================================ + +This binding describes a miphy device that is used to control PHY hardware +for SATA and PCIe. + +Required properties (controller (parent) node): +- compatible : Should be "st,miphy365x-phy" +- st,syscfg : Should be a phandle of the system configuration register group + which contain the SATA, PCIe mode setting bits + +Required nodes : A sub-node is required for each channel the controller + provides. Address range information including the usual + 'reg' and 'reg-names' properties are used inside these + nodes to describe the controller's topology. These nodes + are translated by the driver's .xlate() function. + +Required properties (port (child) node): +- #phy-cells : Should be 1 (See second example) + Cell after port phandle is device type from: + - MIPHY_TYPE_SATA + - MIPHY_TYPE_PCI +- reg : Address and length of register sets for each device in + "reg-names" +- reg-names : The names of the register addresses corresponding to the + registers filled in "reg": + - sata: For SATA devices + - pcie: For PCIe devices + - syscfg: To specify the syscfg based config register + +Optional properties (port (child) node): +- st,sata-gen : Generation of locally attached SATA IP. Expected values + are {1,2,3). If not supplied generation 1 hardware will + be expected +- st,pcie-tx-pol-inv : Bool property to invert the polarity PCIe Tx (Txn/Txp) +- st,sata-tx-pol-inv : Bool property to invert the polarity SATA Tx (Txn/Txp) + +Example: + + miphy365x_phy: miphy365x@fe382000 { + compatible = "st,miphy365x-phy"; + st,syscfg = <&syscfg_rear>; + #address-cells = <1>; + #size-cells = <1>; + ranges; + + phy_port0: port@fe382000 { + reg = <0xfe382000 0x100>, <0xfe394000 0x100>, <0x824 0x4>; + reg-names = "sata", "pcie", "syscfg"; + #phy-cells = <1>; + st,sata-gen = <3>; + }; + + phy_port1: port@fe38a000 { + reg = <0xfe38a000 0x100>, <0xfe804000 0x100>, <0x828 0x4>;; + reg-names = "sata", "pcie", "syscfg"; + #phy-cells = <1>; + st,pcie-tx-pol-inv; + }; + }; + +Specifying phy control of devices +================================= + +Device nodes should specify the configuration required in their "phys" +property, containing a phandle to the phy port node and a device type. + +Example: + +#include + + sata0: sata@fe380000 { + ... + phys = <&phy_port0 MIPHY_TYPE_SATA>; + ... + }; -- cgit v1.2.3 From 000cb478f3227d34d126004acc5389fb562d0b53 Mon Sep 17 00:00:00 2001 From: Markus Pargmann Date: Tue, 22 Jul 2014 10:09:44 +0800 Subject: usb: ci_hdrc_imx doc: fsl,usbphy is required fsl,usbphy is no optional property. This patch moves it to the list of required properties. Signed-off-by: Markus Pargmann Signed-off-by: Peter Chen Signed-off-by: Greg Kroah-Hartman --- Documentation/devicetree/bindings/usb/ci-hdrc-imx.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/usb/ci-hdrc-imx.txt b/Documentation/devicetree/bindings/usb/ci-hdrc-imx.txt index a6a32cb7f777..1bae71e9ad47 100644 --- a/Documentation/devicetree/bindings/usb/ci-hdrc-imx.txt +++ b/Documentation/devicetree/bindings/usb/ci-hdrc-imx.txt @@ -4,6 +4,7 @@ Required properties: - compatible: Should be "fsl,imx27-usb" - reg: Should contain registers location and length - interrupts: Should contain controller interrupt +- fsl,usbphy: phandle of usb phy that connects to the port Recommended properies: - phy_type: the type of the phy connected to the core. Should be one @@ -12,7 +13,6 @@ Recommended properies: - dr_mode: One of "host", "peripheral" or "otg". Defaults to "otg" Optional properties: -- fsl,usbphy: phandler of usb phy that connects to the only one port - fsl,usbmisc: phandler of non-core register device, with one argument that indicate usb controller index - vbus-supply: regulator for vbus -- cgit v1.2.3