diff options
Diffstat (limited to 'Documentation')
| -rw-r--r-- | Documentation/devicetree/bindings/phy/phy-bindings.txt | 66 | ||||
| -rw-r--r-- | Documentation/devicetree/bindings/phy/samsung-phy.txt | 22 | ||||
| -rw-r--r-- | Documentation/devicetree/bindings/usb/msm-hsusb.txt | 17 | ||||
| -rw-r--r-- | Documentation/devicetree/bindings/usb/omap-usb.txt | 39 | ||||
| -rw-r--r-- | Documentation/devicetree/bindings/usb/usb-phy.txt | 6 | ||||
| -rw-r--r-- | Documentation/devicetree/bindings/video/exynos_dp.txt | 17 | ||||
| -rw-r--r-- | Documentation/phy.txt | 166 | ||||
| -rw-r--r-- | Documentation/pps/pps.txt | 15 |
8 files changed, 321 insertions, 27 deletions
diff --git a/Documentation/devicetree/bindings/phy/phy-bindings.txt b/Documentation/devicetree/bindings/phy/phy-bindings.txt new file mode 100644 index 000000000000..8ae844fc0c60 --- /dev/null +++ b/Documentation/devicetree/bindings/phy/phy-bindings.txt @@ -0,0 +1,66 @@ +This document explains only the device tree data binding. For general +information about PHY subsystem refer to Documentation/phy.txt + +PHY device node +=============== + +Required Properties: +#phy-cells: Number of cells in a PHY specifier; The meaning of all those + cells is defined by the binding for the phy node. The PHY + provider can use the values in cells to find the appropriate + PHY. + +For example: + +phys: phy { + compatible = "xxx"; + reg = <...>; + . + . + #phy-cells = <1>; + . + . +}; + +That node describes an IP block (PHY provider) that implements 2 different PHYs. +In order to differentiate between these 2 PHYs, an additonal specifier should be +given while trying to get a reference to it. + +PHY user node +============= + +Required Properties: +phys : the phandle for the PHY device (used by the PHY subsystem) +phy-names : the names of the PHY corresponding to the PHYs present in the + *phys* phandle + +Example 1: +usb1: usb_otg_ss@xxx { + compatible = "xxx"; + reg = <xxx>; + . + . + phys = <&usb2_phy>, <&usb3_phy>; + phy-names = "usb2phy", "usb3phy"; + . + . +}; + +This node represents a controller that uses two PHYs, one for usb2 and one for +usb3. + +Example 2: +usb2: usb_otg_ss@xxx { + compatible = "xxx"; + reg = <xxx>; + . + . + phys = <&phys 1>; + phy-names = "usbphy"; + . + . +}; + +This node represents a controller that uses one of the PHYs of the PHY provider +device defined previously. Note that the phy handle has an additional specifier +"1" to differentiate between the two PHYs. diff --git a/Documentation/devicetree/bindings/phy/samsung-phy.txt b/Documentation/devicetree/bindings/phy/samsung-phy.txt new file mode 100644 index 000000000000..c0fccaa1671e --- /dev/null +++ b/Documentation/devicetree/bindings/phy/samsung-phy.txt @@ -0,0 +1,22 @@ +Samsung S5P/EXYNOS SoC series MIPI CSIS/DSIM DPHY +------------------------------------------------- + +Required properties: +- compatible : should be "samsung,s5pv210-mipi-video-phy"; +- reg : offset and length of the MIPI DPHY register set; +- #phy-cells : from the generic phy bindings, must be 1; + +For "samsung,s5pv210-mipi-video-phy" compatible PHYs the second cell in +the PHY specifier identifies the PHY and its meaning is as follows: + 0 - MIPI CSIS 0, + 1 - MIPI DSIM 0, + 2 - MIPI CSIS 1, + 3 - MIPI DSIM 1. + +Samsung EXYNOS SoC series Display Port PHY +------------------------------------------------- + +Required properties: +- compatible : should be "samsung,exynos5250-dp-video-phy"; +- reg : offset and length of the Display Port PHY register set; +- #phy-cells : from the generic PHY bindings, must be 0; diff --git a/Documentation/devicetree/bindings/usb/msm-hsusb.txt b/Documentation/devicetree/bindings/usb/msm-hsusb.txt new file mode 100644 index 000000000000..5ea26c631e3a --- /dev/null +++ b/Documentation/devicetree/bindings/usb/msm-hsusb.txt @@ -0,0 +1,17 @@ +MSM SoC HSUSB controllers + +EHCI + +Required properties: +- compatible: Should contain "qcom,ehci-host" +- regs: offset and length of the register set in the memory map +- usb-phy: phandle for the PHY device + +Example EHCI controller device node: + + ehci: ehci@f9a55000 { + compatible = "qcom,ehci-host"; + reg = <0xf9a55000 0x400>; + usb-phy = <&usb_otg>; + }; + diff --git a/Documentation/devicetree/bindings/usb/omap-usb.txt b/Documentation/devicetree/bindings/usb/omap-usb.txt index 9088ab09e200..090e5e22bd2b 100644 --- a/Documentation/devicetree/bindings/usb/omap-usb.txt +++ b/Documentation/devicetree/bindings/usb/omap-usb.txt @@ -3,9 +3,6 @@ OMAP GLUE AND OTHER OMAP SPECIFIC COMPONENTS OMAP MUSB GLUE - compatible : Should be "ti,omap4-musb" or "ti,omap3-musb" - ti,hwmods : must be "usb_otg_hs" - - ti,has-mailbox : to specify that omap uses an external mailbox - (in control module) to communicate with the musb core during device connect - and disconnect. - multipoint : Should be "1" indicating the musb controller supports multipoint. This is a MUSB configuration-specific setting. - num-eps : Specifies the number of endpoints. This is also a @@ -19,6 +16,9 @@ OMAP MUSB GLUE - power : Should be "50". This signifies the controller can supply up to 100mA when operating in host mode. - usb-phy : the phandle for the PHY device + - phys : the phandle for the PHY device (used by generic PHY framework) + - phy-names : the names of the PHY corresponding to the PHYs present in the + *phy* phandle. Optional properties: - ctrl-module : phandle of the control module this glue uses to write to @@ -28,11 +28,12 @@ SOC specific device node entry usb_otg_hs: usb_otg_hs@4a0ab000 { compatible = "ti,omap4-musb"; ti,hwmods = "usb_otg_hs"; - ti,has-mailbox; multipoint = <1>; num-eps = <16>; ram-bits = <12>; ctrl-module = <&omap_control_usb>; + phys = <&usb2_phy>; + phy-names = "usb2-phy"; }; Board specific device node entry @@ -78,22 +79,22 @@ omap_dwc3 { OMAP CONTROL USB Required properties: - - compatible: Should be "ti,omap-control-usb" + - compatible: Should be one of + "ti,control-phy-otghs" - if it has otghs_control mailbox register as on OMAP4. + "ti,control-phy-usb2" - if it has Power down bit in control_dev_conf register + 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-dra7usb2" - if it has power down register like USB2 PHY on + DRA7 platform. - reg : Address and length of the register set for the device. It contains - the address of "control_dev_conf" and "otghs_control" or "phy_power_usb" - depending upon omap4 or omap5. - - reg-names: The names of the register addresses corresponding to the registers - filled in "reg". - - ti,type: This is used to differentiate whether the control module has - usb mailbox or usb3 phy power. omap4 has usb mailbox in control module to - notify events to the musb core and omap5 has usb3 phy power register to - power on usb3 phy. Should be "1" if it has mailbox and "2" if it has usb3 - phy power. + 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. omap_control_usb: omap-control-usb@4a002300 { - compatible = "ti,omap-control-usb"; - reg = <0x4a002300 0x4>, - <0x4a00233c 0x4>; - reg-names = "control_dev_conf", "otghs_control"; - ti,type = <1>; + compatible = "ti,control-phy-otghs"; + reg = <0x4a00233c 0x4>; + reg-names = "otghs_control"; }; diff --git a/Documentation/devicetree/bindings/usb/usb-phy.txt b/Documentation/devicetree/bindings/usb/usb-phy.txt index 61496f5cb095..c0245c888982 100644 --- a/Documentation/devicetree/bindings/usb/usb-phy.txt +++ b/Documentation/devicetree/bindings/usb/usb-phy.txt @@ -5,6 +5,8 @@ OMAP USB2 PHY Required properties: - compatible: Should be "ti,omap-usb2" - reg : Address and length of the register set for the device. + - #phy-cells: determine the number of cells that should be given in the + phandle while referencing this phy. Optional properties: - ctrl-module : phandle of the control module used by PHY driver to power on @@ -16,6 +18,7 @@ usb2phy@4a0ad080 { compatible = "ti,omap-usb2"; reg = <0x4a0ad080 0x58>; ctrl-module = <&omap_control_usb>; + #phy-cells = <0>; }; OMAP USB3 PHY @@ -25,6 +28,8 @@ Required properties: - 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". + - #phy-cells: determine the number of cells that should be given in the + phandle while referencing this phy. Optional properties: - ctrl-module : phandle of the control module used by PHY driver to power on @@ -39,4 +44,5 @@ usb3phy@4a084400 { <0x4a084c00 0x40>; reg-names = "phy_rx", "phy_tx", "pll_ctrl"; ctrl-module = <&omap_control_usb>; + #phy-cells = <0>; }; diff --git a/Documentation/devicetree/bindings/video/exynos_dp.txt b/Documentation/devicetree/bindings/video/exynos_dp.txt index 84f10c16cb38..3289d76a21d0 100644 --- a/Documentation/devicetree/bindings/video/exynos_dp.txt +++ b/Documentation/devicetree/bindings/video/exynos_dp.txt @@ -6,10 +6,10 @@ We use two nodes: -dptx-phy node(defined inside dp-controller node) For the DP-PHY initialization, we use the dptx-phy node. -Required properties for dptx-phy: - -reg: +Required properties for dptx-phy: deprecated, use phys and phy-names + -reg: deprecated Base address of DP PHY register. - -samsung,enable-mask: + -samsung,enable-mask: deprecated The bit-mask used to enable/disable DP PHY. For the Panel initialization, we read data from dp-controller node. @@ -27,6 +27,10 @@ Required properties for dp-controller: from common clock binding: Shall be "dp". -interrupt-parent: phandle to Interrupt combiner node. + -phys: + from general PHY binding: the phandle for the PHY device. + -phy-names: + from general PHY binding: Should be "dp". -samsung,color-space: input video data format. COLOR_RGB = 0, COLOR_YCBCR422 = 1, COLOR_YCBCR444 = 2 @@ -68,11 +72,8 @@ SOC specific portion: clocks = <&clock 342>; clock-names = "dp"; - dptx-phy { - reg = <0x10040720>; - samsung,enable-mask = <1>; - }; - + phys = <&dp_phy>; + phy-names = "dp"; }; Board Specific portion: diff --git a/Documentation/phy.txt b/Documentation/phy.txt new file mode 100644 index 000000000000..0103e4b15b0e --- /dev/null +++ b/Documentation/phy.txt @@ -0,0 +1,166 @@ + PHY SUBSYSTEM + Kishon Vijay Abraham I <kishon@ti.com> + +This document explains the Generic PHY Framework along with the APIs provided, +and how-to-use. + +1. Introduction + +*PHY* is the abbreviation for physical layer. It is used to connect a device +to the physical medium e.g., the USB controller has a PHY to provide functions +such as serialization, de-serialization, encoding, decoding and is responsible +for obtaining the required data transmission rate. Note that some USB +controllers have PHY functionality embedded into it and others use an external +PHY. Other peripherals that use PHY include Wireless LAN, Ethernet, +SATA etc. + +The intention of creating this framework is to bring the PHY drivers spread +all over the Linux kernel to drivers/phy to increase code re-use and for +better code maintainability. + +This framework will be of use only to devices that use external PHY (PHY +functionality is not embedded within the controller). + +2. Registering/Unregistering the PHY provider + +PHY provider refers to an entity that implements one or more PHY instances. +For the simple case where the PHY provider implements only a single instance of +the PHY, the framework provides its own implementation of of_xlate in +of_phy_simple_xlate. If the PHY provider implements multiple instances, it +should provide its own implementation of of_xlate. of_xlate is used only for +dt boot case. + +#define of_phy_provider_register(dev, xlate) \ + __of_phy_provider_register((dev), THIS_MODULE, (xlate)) + +#define devm_of_phy_provider_register(dev, xlate) \ + __devm_of_phy_provider_register((dev), THIS_MODULE, (xlate)) + +of_phy_provider_register and devm_of_phy_provider_register macros can be used to +register the phy_provider and it takes device and of_xlate as +arguments. For the dt boot case, all PHY providers should use one of the above +2 macros to register the PHY provider. + +void devm_of_phy_provider_unregister(struct device *dev, + struct phy_provider *phy_provider); +void of_phy_provider_unregister(struct phy_provider *phy_provider); + +devm_of_phy_provider_unregister and of_phy_provider_unregister can be used to +unregister the PHY. + +3. Creating 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); + +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. +phy_ops is a set of function pointers for performing PHY operations such as +init, exit, power_on and power_off. *init_data* is mandatory to get a reference +to the PHY in the case of non-dt boot. See section *Board File Initialization* +on how init_data should be used. + +Inorder to dereference the private data (in phy_ops), the phy provider driver +can use phy_set_drvdata() after creating the PHY and use phy_get_drvdata() in +phy_ops to get back the private data. + +4. Getting a reference to the PHY + +Before the controller can make use of the PHY, it has to get a reference to +it. This framework provides the following APIs to get a reference to the PHY. + +struct phy *phy_get(struct device *dev, const char *string); +struct phy *devm_phy_get(struct device *dev, const char *string); + +phy_get and devm_phy_get can be used to get the PHY. In the case of dt boot, +the string arguments should contain the phy name as given in the dt data and +in the case of non-dt boot, it should contain the label of the PHY. +The only difference between the two APIs is that devm_phy_get associates the +device with the PHY using devres on successful PHY get. On driver detach, +release function is invoked on the the devres data and devres data is freed. + +5. Releasing a reference to the PHY + +When the controller no longer needs the PHY, it has to release the reference +to the PHY it has obtained using the APIs mentioned in the above section. The +PHY framework provides 2 APIs to release a reference to the PHY. + +void phy_put(struct phy *phy); +void devm_phy_put(struct device *dev, struct phy *phy); + +Both these APIs are used to release a reference to the PHY and devm_phy_put +destroys the devres associated with this PHY. + +6. Destroying the PHY + +When the driver that created the PHY is unloaded, it should destroy the PHY it +created using one of the following 2 APIs. + +void phy_destroy(struct phy *phy); +void devm_phy_destroy(struct device *dev, struct phy *phy); + +Both these APIs destroy the PHY and devm_phy_destroy destroys the devres +associated with this PHY. + +7. PM Runtime + +This subsystem is pm runtime enabled. So while creating the PHY, +pm_runtime_enable of the phy device created by this subsystem is called and +while destroying the PHY, pm_runtime_disable is called. Note that the phy +device created by this subsystem will be a child of the device that calls +phy_create (PHY provider device). + +So pm_runtime_get_sync of the phy_device created by this subsystem will invoke +pm_runtime_get_sync of PHY provider device because of parent-child relationship. +It should also be noted that phy_power_on and phy_power_off performs +phy_pm_runtime_get_sync and phy_pm_runtime_put respectively. +There are exported APIs like phy_pm_runtime_get, phy_pm_runtime_get_sync, +phy_pm_runtime_put, phy_pm_runtime_put_sync, phy_pm_runtime_allow and +phy_pm_runtime_forbid for performing PM operations. + +8. Board File Initialization + +Certain board file initialization is necessary in order to get a reference +to the PHY in the case of non-dt boot. +Say we have a single device that implements 3 PHYs that of USB, SATA and PCIe, +then in the board file the following initialization should be done. + +struct phy_consumer consumers[] = { + PHY_CONSUMER("dwc3.0", "usb"), + PHY_CONSUMER("pcie.0", "pcie"), + PHY_CONSUMER("sata.0", "sata"), +}; +PHY_CONSUMER takes 2 parameters, first is the device name of the controller +(PHY consumer) and second is the port name. + +struct phy_init_data init_data = { + .consumers = consumers, + .num_consumers = ARRAY_SIZE(consumers), +}; + +static const struct platform_device pipe3_phy_dev = { + .name = "pipe3-phy", + .id = -1, + .dev = { + .platform_data = { + .init_data = &init_data, + }, + }, +}; + +then, while doing phy_create, the PHY driver should pass this init_data + phy_create(dev, ops, pdata->init_data); + +and the controller driver (phy consumer) should pass the port name along with +the device to get a reference to the PHY + phy_get(dev, "pcie"); + +9. DeviceTree Binding + +The documentation for PHY dt binding can be found @ +Documentation/devicetree/bindings/phy/phy-bindings.txt diff --git a/Documentation/pps/pps.txt b/Documentation/pps/pps.txt index d35dcdd82ff6..c03b1be5eb15 100644 --- a/Documentation/pps/pps.txt +++ b/Documentation/pps/pps.txt @@ -66,6 +66,21 @@ In LinuxPPS the PPS sources are simply char devices usually mapped into files /dev/pps0, /dev/pps1, etc.. +PPS with USB to serial devices +------------------------------ + +It is possible to grab the PPS from an USB to serial device. However, +you should take into account the latencies and jitter introduced by +the USB stack. Users has reported clock instability around +-1ms when +synchronized with PPS through USB. This isn't suited for time server +synchronization. + +If your device doesn't report PPS, you can check that the feature is +supported by its driver. Most of the time, you only need to add a call +to usb_serial_handle_dcd_change after checking the DCD status (see +ch341 and pl2303 examples). + + Coding example -------------- |