From: "Ivan T. Ivanov" <[email protected]>
Hi,
Here is fourth version of MSM USB3 drivers patches.
Changes since v3:
* Remove "_clk" suffix from clock names
* Clarify required child node for qcom,dwc3
* Fix comments in functions headers
* Use dbg instead err in drivers probe functions.
Changes since v2:
* Several improvements in devicetree bindings description
* Disable regulators in glue layer if there is error during
ioremap.
Changes since first version:
* Split devicetree bindings description file to separate patch
* Address comments for device bindings description
* Fix typo in 'gdsc' requlator name.
These patches add basic support for USB3.0 controllers found
on MSM platforms. USB3.0 core is based on Synopsys DesignWare
SuperSpeed IP.
Generated on top of Felipe 'testing' branch.
Ivan T. Ivanov (3):
usb: dwc3: msm: Add device tree binding information
usb: phy: Add Qualcomm SS-USB and HS-USB drivers for DWC3 core
usb: dwc3: Add Qualcomm DWC3 glue layer driver
.../devicetree/bindings/usb/msm-ssusb.txt | 104 ++++++
drivers/usb/dwc3/Kconfig | 8 +
drivers/usb/dwc3/Makefile | 1 +
drivers/usb/dwc3/dwc3-msm.c | 167 +++++++++
drivers/usb/phy/Kconfig | 11 +
drivers/usb/phy/Makefile | 2 +
drivers/usb/phy/phy-msm-dwc3-hs.c | 327 +++++++++++++++++
drivers/usb/phy/phy-msm-dwc3-ss.c | 374 ++++++++++++++++++++
8 files changed, 994 insertions(+)
create mode 100644 Documentation/devicetree/bindings/usb/msm-ssusb.txt
create mode 100644 drivers/usb/dwc3/dwc3-msm.c
create mode 100644 drivers/usb/phy/phy-msm-dwc3-hs.c
create mode 100644 drivers/usb/phy/phy-msm-dwc3-ss.c
--
1.7.9.5
From: "Ivan T. Ivanov" <[email protected]>
MSM USB3.0 core wrapper consist of USB3.0 IP from Synopsys
(SNPS) and HS, SS PHY's control and configuration registers.
It could operate in device mode (SS, HS, FS) and host
mode (SS, HS, FS, LS).
Signed-off-by: Ivan T. Ivanov <[email protected]>
---
.../devicetree/bindings/usb/msm-ssusb.txt | 104 ++++++++++++++++++++
1 file changed, 104 insertions(+)
create mode 100644 Documentation/devicetree/bindings/usb/msm-ssusb.txt
diff --git a/Documentation/devicetree/bindings/usb/msm-ssusb.txt b/Documentation/devicetree/bindings/usb/msm-ssusb.txt
new file mode 100644
index 0000000..cacbd3b
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/msm-ssusb.txt
@@ -0,0 +1,104 @@
+MSM SuperSpeed DWC3 USB SoC controller
+
+
+DWC3 Highspeed USB PHY
+======================
+Required properities :
+- compatible : sould be "qcom,dwc3-hsphy";
+- reg : offset and length of the register set in the memory map
+- clocks : phandles to clock instances of the device tree nodes
+- clock-names :
+ "xo" : External reference clock 19 MHz
+ "sleep_a" : Sleep clock, used when USB3 core goes into low
+ power mode (U3).
+<supply-name>-supply : phandle to the regulator device tree node
+Required "supply-name" are:
+ "v1p8" : 1.8v supply for HSPHY
+ "v3p3" : 3.3v supply for HSPHY
+ "vbus" : vbus supply for host mode
+ "vddcx" : vdd supply for HS-PHY digital circuit operation
+
+DWC3 Superspeed USB PHY
+=======================
+Required properities :
+- compatible : sould be "qcom,dwc3-ssphy";
+- reg : offset and length of the register set in the memory map
+- clocks : phandles to clock instances of the device tree nodes
+- clock-names :
+ "xo" : External reference clock 19 MHz
+ "ref" : Reference clock - used in host mode.
+<supply-name>-supply : phandle to the regulator device tree node
+Required "supply-name" are:
+ "v1p8" : 1.8v supply for SS-PHY
+ "vddcx" : vdd supply for SS-PHY digital circuit operation
+
+DWC3 controller wrapper
+=======================
+Required properties :
+- compatible : should be "qcom,dwc3"
+- reg : offset and length of the register set in the memory map
+ offset and length of the TCSR register for routing USB
+ signals to either picoPHY0 or picoPHY1.
+- clocks : phandles to clock instances of the device tree nodes
+- clock-names :
+ "core" : Master/Core clock, have to be >= 125 MHz for SS
+ operation and >= 60MHz for HS operation
+ "iface" : System bus AXI clock
+ "sleep" : Sleep clock, used when USB3 core goes into low
+ power mode (U3).
+ "utmi" : Generated by HS-PHY. Used to clock the low power
+ parts of thr HS Link layer.
+Optional properties :
+- gdsc-supply : phandle to the globally distributed switch controller
+ regulator node to the USB controller.
+Required child node:
+A child node must exist to represent the core DWC3 IP block. The name of
+the node is not important. The content of the node is defined in dwc3.txt.
+
+Example device nodes:
+
+ dwc3_hsphy: phy@f92f8800 {
+ compatible = "qcom,dwc3-hsphy";
+ reg = <0xf92f8800 0x30>;
+
+ clocks = <&cxo>, <&usb2a_phy_sleep_cxc>;
+ clock-names = "xo", "sleep_a";
+
+ vbus-supply = <&supply>;
+ vddcx-supply = <&supply>;
+ v1p8-supply = <&supply>;
+ v3p3-supply = <&supply>;
+ };
+
+ dwc3_ssphy: phy@f92f8830 {
+ compatible = "qcom,dwc3-ssphy";
+ reg = <0xf92f8830 0x30>;
+
+ clocks = <&cxo>, <&usb30_mock_utmi_cxc>;
+ clock-names = "xo", "ref";
+
+ vddcx-supply = <&supply>;
+ v1p8-supply = <&supply>;
+ };
+
+ usb@fd4ab000 {
+ compatible = "qcom,dwc3";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ reg = <0xfd4ab000 0x4>;
+
+ clocks = <&usb30_master_cxc>, <&sys_noc_usb3_axi_cxc>,
+ <&usb30_sleep_cxc>, <&usb30_mock_utmi_cxc>;
+ clock-names = "core", "iface", "sleep", "utmi";
+
+ gdsc-supply = <&supply>;
+
+ ranges;
+ dwc3@f9200000 {
+ compatible = "snps,dwc3";
+ reg = <0xf9200000 0xcd00>;
+ interrupts = <0 131 0>;
+ usb-phy = <&dwc3_hsphy>, <&dwc3_ssphy>;
+ tx-fifo-resize;
+ };
+ };
--
1.7.9.5
From: "Ivan T. Ivanov" <[email protected]>
DWC3 glue layer is hardware layer around Synopsys DesignWare
USB3 core. Its purpose is to supply Synopsys IP with required
clocks, voltages and interface it with the rest of the SoC.
Signed-off-by: Ivan T. Ivanov <[email protected]>
---
drivers/usb/dwc3/Kconfig | 8 +++
drivers/usb/dwc3/Makefile | 1 +
drivers/usb/dwc3/dwc3-msm.c | 167 +++++++++++++++++++++++++++++++++++++++++++
3 files changed, 176 insertions(+)
create mode 100644 drivers/usb/dwc3/dwc3-msm.c
diff --git a/drivers/usb/dwc3/Kconfig b/drivers/usb/dwc3/Kconfig
index f969ea2..d845966 100644
--- a/drivers/usb/dwc3/Kconfig
+++ b/drivers/usb/dwc3/Kconfig
@@ -71,6 +71,14 @@ config USB_DWC3_PCI
One such PCIe-based platform is Synopsys' PCIe HAPS model of
this IP.
+config USB_DWC3_MSM
+ tristate "Qualcomm MSM/APQ Platforms"
+ default USB_DWC3
+ select USB_MSM_DWC3_PHYS
+ help
+ Recent Qualcomm SoCs ship with one DesignWare Core USB3 IP inside,
+ say 'Y' or 'M' if you have one such device.
+
comment "Debugging features"
config USB_DWC3_DEBUG
diff --git a/drivers/usb/dwc3/Makefile b/drivers/usb/dwc3/Makefile
index dd17601..5226681 100644
--- a/drivers/usb/dwc3/Makefile
+++ b/drivers/usb/dwc3/Makefile
@@ -32,3 +32,4 @@ endif
obj-$(CONFIG_USB_DWC3_OMAP) += dwc3-omap.o
obj-$(CONFIG_USB_DWC3_EXYNOS) += dwc3-exynos.o
obj-$(CONFIG_USB_DWC3_PCI) += dwc3-pci.o
+obj-$(CONFIG_USB_DWC3_MSM) += dwc3-msm.o
diff --git a/drivers/usb/dwc3/dwc3-msm.c b/drivers/usb/dwc3/dwc3-msm.c
new file mode 100644
index 0000000..361076c
--- /dev/null
+++ b/drivers/usb/dwc3/dwc3-msm.c
@@ -0,0 +1,167 @@
+/* Copyright (c) 2013, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include <linux/clk.h>
+#include <linux/err.h>
+#include <linux/io.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_platform.h>
+#include <linux/platform_device.h>
+#include <linux/regulator/consumer.h>
+#include <linux/usb/phy.h>
+
+struct dwc3_msm {
+ struct device *dev;
+
+ struct clk *core_clk;
+ struct clk *iface_clk;
+ struct clk *sleep_clk;
+ struct clk *utmi_clk;
+
+ struct regulator *gdsc;
+};
+
+static int dwc3_msm_probe(struct platform_device *pdev)
+{
+ struct device_node *node = pdev->dev.of_node;
+ struct dwc3_msm *mdwc;
+ struct resource *res;
+ void __iomem *tcsr;
+ int ret = 0;
+
+ mdwc = devm_kzalloc(&pdev->dev, sizeof(*mdwc), GFP_KERNEL);
+ if (!mdwc)
+ return -ENOMEM;
+
+ platform_set_drvdata(pdev, mdwc);
+ mdwc->dev = &pdev->dev;
+
+ mdwc->gdsc = devm_regulator_get(mdwc->dev, "gdsc");
+
+ mdwc->core_clk = devm_clk_get(&pdev->dev, "core");
+ if (IS_ERR(mdwc->core_clk)) {
+ dev_dbg(&pdev->dev, "failed to get core clock\n");
+ return PTR_ERR(mdwc->core_clk);
+ }
+
+ mdwc->iface_clk = devm_clk_get(&pdev->dev, "iface");
+ if (IS_ERR(mdwc->iface_clk)) {
+ dev_dbg(&pdev->dev, "failed to get iface clock\n");
+ return PTR_ERR(mdwc->iface_clk);
+ }
+
+ mdwc->sleep_clk = devm_clk_get(&pdev->dev, "sleep ");
+ if (IS_ERR(mdwc->sleep_clk)) {
+ dev_dbg(&pdev->dev, "failed to get sleep clock\n");
+ return PTR_ERR(mdwc->sleep_clk);
+ }
+
+ mdwc->utmi_clk = devm_clk_get(&pdev->dev, "utmi");
+ if (IS_ERR(mdwc->utmi_clk)) {
+ dev_dbg(&pdev->dev, "failed to get utmi clock\n");
+ return PTR_ERR(mdwc->utmi_clk);
+ }
+
+ if (!IS_ERR(mdwc->gdsc)) {
+ ret = regulator_enable(mdwc->gdsc);
+ if (ret)
+ dev_err(mdwc->dev, "cannot enable usb3 gdsc\n");
+ }
+
+ /*
+ * DWC3 Core requires its CORE CLK (aka master / bus clk) to
+ * run at 125Mhz in SSUSB mode and >60MHZ for HSUSB mode.
+ */
+ clk_set_rate(mdwc->core_clk, 125000000);
+ clk_prepare_enable(mdwc->core_clk);
+ clk_prepare_enable(mdwc->iface_clk);
+ clk_prepare_enable(mdwc->sleep_clk);
+ clk_prepare_enable(mdwc->utmi_clk);
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ tcsr = devm_ioremap_resource(&pdev->dev, res);
+ if (!tcsr) {
+ ret = PTR_ERR(tcsr);
+ goto dis_clks;
+ }
+
+ /*
+ * Primary USB port is shared between USB2 and USB3 controllers.
+ * By default this port is routed to USB2. Select primary port for
+ * USB3, this will automatically move USB2 to secondary port.
+ */
+ writel(0x1, tcsr);
+
+ ret = of_platform_populate(node, NULL, NULL, &pdev->dev);
+ if (ret) {
+ dev_dbg(&pdev->dev, "failed to add create dwc3 core\n");
+ writel(0x0, tcsr);
+ goto dis_clks;
+ }
+
+ return 0;
+
+dis_clks:
+ clk_disable_unprepare(mdwc->utmi_clk);
+ clk_disable_unprepare(mdwc->sleep_clk);
+ clk_disable_unprepare(mdwc->iface_clk);
+ clk_disable_unprepare(mdwc->core_clk);
+ if (!IS_ERR(mdwc->gdsc)) {
+ ret = regulator_disable(mdwc->gdsc);
+ if (ret)
+ dev_dbg(mdwc->dev, "cannot disable usb3 gdsc\n");
+ }
+
+ return ret;
+}
+
+static int dwc3_msm_remove(struct platform_device *pdev)
+{
+ struct dwc3_msm *mdwc = platform_get_drvdata(pdev);
+ int ret;
+
+ clk_disable_unprepare(mdwc->utmi_clk);
+ clk_disable_unprepare(mdwc->sleep_clk);
+ clk_disable_unprepare(mdwc->iface_clk);
+ clk_disable_unprepare(mdwc->core_clk);
+
+ if (!IS_ERR(mdwc->gdsc)) {
+ ret = regulator_disable(mdwc->gdsc);
+ if (ret)
+ dev_dbg(mdwc->dev, "cannot disable usb3 gdsc\n");
+ }
+
+ return 0;
+}
+
+static const struct of_device_id of_dwc3_match[] = {
+ { .compatible = "qcom,dwc3" },
+ { /* Sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, of_dwc3_match);
+
+static struct platform_driver dwc3_msm_driver = {
+ .probe = dwc3_msm_probe,
+ .remove = dwc3_msm_remove,
+ .driver = {
+ .name = "msm-dwc3",
+ .owner = THIS_MODULE,
+ .of_match_table = of_dwc3_match,
+ },
+};
+
+module_platform_driver(dwc3_msm_driver);
+
+MODULE_ALIAS("platform:msm_dwc3");
+MODULE_LICENSE("GPL v2");
+MODULE_DESCRIPTION("DesignWare USB3 MSM Glue Layer");
--
1.7.9.5
From: "Ivan T. Ivanov" <[email protected]>
These drivers handles control and configuration of the HS
and SS USB PHY transceivers. They are part of the driver
which manage Synopsys DesignWare USB3 controller stack
inside Qualcomm SoC's.
Signed-off-by: Ivan T. Ivanov <[email protected]>
---
drivers/usb/phy/Kconfig | 11 ++
drivers/usb/phy/Makefile | 2 +
drivers/usb/phy/phy-msm-dwc3-hs.c | 327 ++++++++++++++++++++++++++++++++
drivers/usb/phy/phy-msm-dwc3-ss.c | 374 +++++++++++++++++++++++++++++++++++++
4 files changed, 714 insertions(+)
create mode 100644 drivers/usb/phy/phy-msm-dwc3-hs.c
create mode 100644 drivers/usb/phy/phy-msm-dwc3-ss.c
diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig
index d5589f9..c525835 100644
--- a/drivers/usb/phy/Kconfig
+++ b/drivers/usb/phy/Kconfig
@@ -214,6 +214,17 @@ config USB_RCAR_PHY
To compile this driver as a module, choose M here: the
module will be called phy-rcar-usb.
+config USB_MSM_DWC3_PHYS
+ tristate "Qualcomm DWC3 USB controller PHY's support"
+ depends on (USB || USB_GADGET) && ARCH_MSM
+ select USB_PHY
+ help
+ Enable this to support the USB PHY transceivers on MSM chips with
+ DWC3 USB core. It handles PHY initialization, clock management
+ required after resetting the hardware and power management.
+ This driver is required even for peripheral only or host only
+ mode configurations.
+
config USB_ULPI
bool "Generic ULPI Transceiver Driver"
depends on ARM
diff --git a/drivers/usb/phy/Makefile b/drivers/usb/phy/Makefile
index 2135e85..8f2dd94 100644
--- a/drivers/usb/phy/Makefile
+++ b/drivers/usb/phy/Makefile
@@ -26,6 +26,8 @@ obj-$(CONFIG_USB_EHCI_TEGRA) += phy-tegra-usb.o
obj-$(CONFIG_USB_GPIO_VBUS) += phy-gpio-vbus-usb.o
obj-$(CONFIG_USB_ISP1301) += phy-isp1301.o
obj-$(CONFIG_USB_MSM_OTG) += phy-msm-usb.o
+obj-$(CONFIG_USB_MSM_DWC3_PHYS) += phy-msm-dwc3-hs.o
+obj-$(CONFIG_USB_MSM_DWC3_PHYS) += phy-msm-dwc3-ss.o
obj-$(CONFIG_USB_MV_OTG) += phy-mv-usb.o
obj-$(CONFIG_USB_MXS_PHY) += phy-mxs-usb.o
obj-$(CONFIG_USB_RCAR_PHY) += phy-rcar-usb.o
diff --git a/drivers/usb/phy/phy-msm-dwc3-hs.c b/drivers/usb/phy/phy-msm-dwc3-hs.c
new file mode 100644
index 0000000..840e766
--- /dev/null
+++ b/drivers/usb/phy/phy-msm-dwc3-hs.c
@@ -0,0 +1,327 @@
+/* Copyright (c) 2013, Code Aurora Forum. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include <linux/clk.h>
+#include <linux/err.h>
+#include <linux/io.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <linux/regulator/consumer.h>
+#include <linux/usb/phy.h>
+
+/**
+ * USB QSCRATCH Hardware registers
+ */
+#define QSCRATCH_CTRL_REG (0x04)
+#define QSCRATCH_GENERAL_CFG (0x08)
+#define PHY_CTRL_REG (0x10)
+#define PARAMETER_OVERRIDE_X_REG (0x14)
+#define CHARGING_DET_CTRL_REG (0x18)
+#define CHARGING_DET_OUTPUT_REG (0x1c)
+#define ALT_INTERRUPT_EN_REG (0x20)
+#define PHY_IRQ_STAT_REG (0x24)
+#define CGCTL_REG (0x28)
+
+#define PHY_3P3_VOL_MIN 3050000 /* uV */
+#define PHY_3P3_VOL_MAX 3300000 /* uV */
+#define PHY_3P3_HPM_LOAD 16000 /* uA */
+
+#define PHY_1P8_VOL_MIN 1800000 /* uV */
+#define PHY_1P8_VOL_MAX 1800000 /* uV */
+#define PHY_1P8_HPM_LOAD 19000 /* uA */
+
+/* TODO: these are suspicious */
+#define USB_VDDCX_NO 1 /* uV */
+#define USB_VDDCX_MIN 5 /* uV */
+#define USB_VDDCX_MAX 7 /* uV */
+
+struct msm_dwc3_hs_phy {
+ struct usb_phy phy;
+ void __iomem *base;
+ struct device *dev;
+
+ struct clk *xo_clk;
+ struct clk *sleep_a_clk;
+
+ struct regulator *v3p3;
+ struct regulator *v1p8;
+ struct regulator *vddcx;
+ struct regulator *vbus;
+};
+
+#define phy_to_dwc3_phy(x) container_of((x), struct msm_dwc3_hs_phy, phy)
+
+
+/**
+ * Write register.
+ *
+ * @base - MSM DWC3 PHY base virtual address.
+ * @offset - register offset.
+ * @val - value to write.
+ */
+static inline void msm_dwc3_hs_write(void __iomem *base, u32 offset, u32 val)
+{
+ iowrite32(val, base + offset);
+}
+
+/**
+ * Write register and read back masked value to confirm it is written
+ *
+ * @base - MSM DWC3 PHY base virtual address.
+ * @offset - register offset.
+ * @mask - register bitmask specifying what should be updated
+ * @val - value to write.
+ */
+static inline void msm_dwc3_hs_write_readback(void __iomem *base, u32 offset,
+ const u32 mask, u32 val)
+{
+ u32 write_val, tmp = ioread32(base + offset);
+
+ tmp &= ~mask; /* retain other bits */
+ write_val = tmp | val;
+
+ iowrite32(write_val, base + offset);
+
+ /* Read back to see if val was written */
+ tmp = ioread32(base + offset);
+ tmp &= mask; /* clear other bits */
+
+ if (tmp != val)
+ pr_err("write: %x to QSCRATCH: %x FAILED\n", val, offset);
+}
+
+static void msm_dwc3_hs_phy_shutdown(struct usb_phy *x)
+{
+ struct msm_dwc3_hs_phy *phy = phy_to_dwc3_phy(x);
+ int ret;
+
+ ret = regulator_set_voltage(phy->v3p3, 0, PHY_3P3_VOL_MAX);
+ if (ret)
+ dev_err(phy->dev, "cannot set voltage for v3p3\n");
+
+ ret = regulator_set_voltage(phy->v1p8, 0, PHY_1P8_VOL_MAX);
+ if (ret)
+ dev_err(phy->dev, "cannot set voltage for v1p8\n");
+
+ ret = regulator_disable(phy->v1p8);
+ if (ret)
+ dev_err(phy->dev, "cannot disable v1p8\n");
+
+ ret = regulator_disable(phy->v3p3);
+ if (ret)
+ dev_err(phy->dev, "cannot disable v3p3\n");
+
+ ret = regulator_set_voltage(phy->vddcx, USB_VDDCX_NO, USB_VDDCX_MAX);
+ if (ret)
+ dev_err(phy->dev, "cannot set voltage for vddcx\n");
+
+ ret = regulator_disable(phy->vddcx);
+ if (ret)
+ dev_err(phy->dev, "cannot enable vddcx\n");
+
+ clk_disable_unprepare(phy->sleep_a_clk);
+}
+
+static int msm_dwc3_hs_phy_init(struct usb_phy *x)
+{
+ struct msm_dwc3_hs_phy *phy = phy_to_dwc3_phy(x);
+ int ret;
+
+ clk_prepare_enable(phy->sleep_a_clk);
+
+ ret = regulator_set_voltage(phy->vddcx, USB_VDDCX_MIN, USB_VDDCX_MAX);
+ if (ret) {
+ dev_err(phy->dev, "cannot set voltage for vddcx\n");
+ return ret;
+ }
+
+ ret = regulator_enable(phy->vddcx);
+ if (ret) {
+ dev_err(phy->dev, "cannot enable vddcx\n");
+ return ret;
+ }
+
+ ret = regulator_set_voltage(phy->v3p3, PHY_3P3_VOL_MIN,
+ PHY_3P3_VOL_MAX);
+ if (ret) {
+ dev_err(phy->dev, "cannot set voltage for v3p3\n");
+ return ret;
+ }
+
+ ret = regulator_set_voltage(phy->v1p8, PHY_1P8_VOL_MIN,
+ PHY_1P8_VOL_MAX);
+ if (ret) {
+ dev_err(phy->dev, "cannot set voltage for v1p8\n");
+ return ret;
+ }
+
+ ret = regulator_set_optimum_mode(phy->v1p8, PHY_1P8_HPM_LOAD);
+ if (ret < 0) {
+ dev_err(phy->dev, "cannot set HPM of regulator v1p8\n");
+ return ret;
+ }
+
+ ret = regulator_enable(phy->v1p8);
+ if (ret) {
+ dev_err(phy->dev, "cannot enable v1p8\n");
+ return ret;
+ }
+
+ ret = regulator_set_optimum_mode(phy->v3p3, PHY_3P3_HPM_LOAD);
+ if (ret < 0) {
+ dev_err(phy->dev, "cannot set HPM of regulator v3p3\n");
+ return ret;
+ }
+
+ ret = regulator_enable(phy->v3p3);
+ if (ret) {
+ dev_err(phy->dev, "cannot enable v3p3\n");
+ return ret;
+ }
+
+ /*
+ * HSPHY Initialization: Enable UTMI clock and clamp enable HVINTs,
+ * and disable RETENTION (power-on default is ENABLED)
+ */
+ msm_dwc3_hs_write(phy->base, PHY_CTRL_REG, 0x5220bb2);
+ usleep_range(2000, 2200);
+
+ /*
+ * write HSPHY init value to QSCRATCH reg to set HSPHY parameters like
+ * VBUS valid threshold, disconnect valid threshold, DC voltage level,
+ * preempasis and rise/fall time.
+ */
+ msm_dwc3_hs_write_readback(phy->base, PARAMETER_OVERRIDE_X_REG,
+ 0x03ffffff, 0x00d191a4);
+
+ /* Disable (bypass) VBUS and ID filters */
+ msm_dwc3_hs_write(phy->base, QSCRATCH_GENERAL_CFG, 0x78);
+
+ return 0;
+}
+
+static int msm_dwc3_hs_phy_set_vbus(struct usb_phy *x, int on)
+{
+ struct msm_dwc3_hs_phy *phy = phy_to_dwc3_phy(x);
+ int ret;
+
+ if (on)
+ ret = regulator_enable(phy->vbus);
+ else
+ ret = regulator_disable(phy->vbus);
+
+ if (ret)
+ dev_err(x->dev, "Cannot %s Vbus\n", on ? "set" : "off");
+ return ret;
+}
+
+static int msm_dwc3_hs_probe(struct platform_device *pdev)
+{
+ struct msm_dwc3_hs_phy *phy;
+ struct resource *res;
+ void __iomem *base;
+
+ phy = devm_kzalloc(&pdev->dev, sizeof(*phy), GFP_KERNEL);
+ if (!phy)
+ return -ENOMEM;
+
+ platform_set_drvdata(pdev, phy);
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ base = devm_ioremap_resource(&pdev->dev, res);
+ if (IS_ERR(base))
+ return PTR_ERR(base);
+
+ phy->vddcx = devm_regulator_get(&pdev->dev, "vddcx");
+ if (IS_ERR(phy->vddcx)) {
+ dev_dbg(&pdev->dev, "cannot get vddcx\n");
+ return PTR_ERR(phy->vddcx);
+ }
+
+ phy->v3p3 = devm_regulator_get(phy->dev, "v3p3");
+ if (IS_ERR(phy->v3p3)) {
+ dev_dbg(phy->dev, "cannot get v3p3\n");
+ return PTR_ERR(phy->v3p3);
+ }
+
+ phy->v1p8 = devm_regulator_get(phy->dev, "v1p8");
+ if (IS_ERR(phy->v1p8)) {
+ dev_dbg(phy->dev, "cannot get v1p8\n");
+ return PTR_ERR(phy->v1p8);
+ }
+
+ phy->vbus = devm_regulator_get(&pdev->dev, "vbus");
+ if (IS_ERR(phy->vbus)) {
+ dev_dbg(phy->dev, "Failed to get vbus\n");
+ return PTR_ERR(phy->vbus);
+ }
+
+ phy->xo_clk = devm_clk_get(&pdev->dev, "xo");
+ if (IS_ERR(phy->xo_clk)) {
+ dev_dbg(&pdev->dev, "cannot get TCXO buffer handle\n");
+ return PTR_ERR(phy->xo_clk);
+ }
+
+ phy->sleep_a_clk = devm_clk_get(&pdev->dev, "sleep_a");
+ if (IS_ERR(phy->sleep_a_clk)) {
+ dev_dbg(&pdev->dev, "failed to get sleep_a clock\n");
+ return PTR_ERR(phy->sleep_a_clk);
+ }
+
+ clk_prepare_enable(phy->xo_clk);
+
+ phy->dev = &pdev->dev;
+ phy->base = base;
+ phy->phy.dev = phy->dev;
+ phy->phy.label = "msm-dwc3-hsphy";
+ phy->phy.init = msm_dwc3_hs_phy_init;
+ phy->phy.shutdown = msm_dwc3_hs_phy_shutdown;
+ phy->phy.set_vbus = msm_dwc3_hs_phy_set_vbus;
+ phy->phy.type = USB_PHY_TYPE_USB2;
+ phy->phy.state = OTG_STATE_UNDEFINED;
+
+ usb_add_phy_dev(&phy->phy);
+
+ return 0;
+}
+
+static int msm_dwc3_hs_remove(struct platform_device *pdev)
+{
+ struct msm_dwc3_hs_phy *phy = platform_get_drvdata(pdev);
+
+ clk_disable_unprepare(phy->xo_clk);
+ usb_remove_phy(&phy->phy);
+ return 0;
+}
+
+static const struct of_device_id msm_dwc3_hs_id_table[] = {
+ { .compatible = "qcom,dwc3-hsphy" },
+ { /* Sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, msm_dwc3_hs_id_table);
+
+static struct platform_driver msm_dwc3_hs_driver = {
+ .probe = msm_dwc3_hs_probe,
+ .remove = msm_dwc3_hs_remove,
+ .driver = {
+ .name = "msm-dwc3-hsphy",
+ .owner = THIS_MODULE,
+ .of_match_table = msm_dwc3_hs_id_table,
+ },
+};
+
+module_platform_driver(msm_dwc3_hs_driver);
+
+MODULE_ALIAS("platform:msm_dwc3_hsphy");
+MODULE_LICENSE("GPL v2");
+MODULE_DESCRIPTION("DesignWare USB3 MSM HS-PHY driver");
diff --git a/drivers/usb/phy/phy-msm-dwc3-ss.c b/drivers/usb/phy/phy-msm-dwc3-ss.c
new file mode 100644
index 0000000..9ac46bf
--- /dev/null
+++ b/drivers/usb/phy/phy-msm-dwc3-ss.c
@@ -0,0 +1,374 @@
+/* Copyright (c) 2013, Code Aurora Forum. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include <linux/clk.h>
+#include <linux/err.h>
+#include <linux/io.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <linux/regulator/consumer.h>
+#include <linux/usb/phy.h>
+
+/**
+ * USB QSCRATCH Hardware registers
+ */
+#define PHY_CTRL_REG (0x00)
+#define PHY_PARAM_CTRL_1 (0x04)
+#define PHY_PARAM_CTRL_2 (0x08)
+#define CR_PROTOCOL_DATA_IN_REG (0x0c)
+#define CR_PROTOCOL_DATA_OUT_REG (0x10)
+#define CR_PROTOCOL_CAP_ADDR_REG (0x14)
+#define CR_PROTOCOL_CAP_DATA_REG (0x18)
+#define CR_PROTOCOL_READ_REG (0x1c)
+#define CR_PROTOCOL_WRITE_REG (0x20)
+
+#define PHY_1P8_VOL_MIN 1800000 /* uV */
+#define PHY_1P8_VOL_MAX 1800000 /* uV */
+#define PHY_1P8_HPM_LOAD 23000 /* uA */
+
+/* TODO: these are suspicious */
+#define USB_VDDCX_NO 1 /* uV */
+#define USB_VDDCX_MIN 5 /* uV */
+#define USB_VDDCX_MAX 7 /* uV */
+
+struct msm_dwc3_ss_phy {
+ struct usb_phy phy;
+ void __iomem *base;
+ struct device *dev;
+
+ struct regulator *v1p8;
+ struct regulator *vddcx;
+
+ struct clk *xo_clk;
+ struct clk *ref_clk;
+};
+
+#define phy_to_dwc3_phy(x) container_of((x), struct msm_dwc3_ss_phy, phy)
+
+
+/**
+ * Write register
+ *
+ * @base - MSM DWC3 PHY base virtual address.
+ * @offset - register offset.
+ * @val - value to write.
+ */
+static inline void msm_dwc3_ss_write(void __iomem *base, u32 offset, u32 val)
+{
+ iowrite32(val, base + offset);
+}
+
+/**
+ * Write register and read back masked value to confirm it is written
+ *
+ * @base - MSM DWC3 PHY base virtual address.
+ * @offset - register offset.
+ * @mask - register bitmask specifying what should be updated
+ * @val - value to write.
+ */
+static inline void msm_dwc3_ss_write_readback(void __iomem *base, u32 offset,
+ const u32 mask, u32 val)
+{
+ u32 write_val, tmp = ioread32(base + offset);
+
+ tmp &= ~mask; /* retain other bits */
+ write_val = tmp | val;
+
+ iowrite32(write_val, base + offset);
+
+ /* Read back to see if val was written */
+ tmp = ioread32(base + offset);
+ tmp &= mask; /* clear other bits */
+
+ if (tmp != val)
+ pr_err("write: %x to QSCRATCH: %x FAILED\n", val, offset);
+}
+
+/**
+ * Write SSPHY register
+ *
+ * @base - MSM DWC3 PHY base virtual address.
+ * @addr - SSPHY address to write.
+ * @val - value to write.
+ */
+static void msm_dwc3_ss_write_phycreg(void __iomem *base, u32 addr, u32 val)
+{
+ iowrite32(addr, base + CR_PROTOCOL_DATA_IN_REG);
+ iowrite32(0x1, base + CR_PROTOCOL_CAP_ADDR_REG);
+ while (ioread32(base + CR_PROTOCOL_CAP_ADDR_REG))
+ cpu_relax();
+
+ iowrite32(val, base + CR_PROTOCOL_DATA_IN_REG);
+ iowrite32(0x1, base + CR_PROTOCOL_CAP_DATA_REG);
+ while (ioread32(base + CR_PROTOCOL_CAP_DATA_REG))
+ cpu_relax();
+
+ iowrite32(0x1, base + CR_PROTOCOL_WRITE_REG);
+ while (ioread32(base + CR_PROTOCOL_WRITE_REG))
+ cpu_relax();
+}
+
+/**
+ * Read SSPHY register.
+ *
+ * @base - MSM DWC3 PHY base virtual address.
+ * @addr - SSPHY address to read.
+ */
+static u32 msm_dwc3_ss_read_phycreg(void __iomem *base, u32 addr)
+{
+ bool first_read = true;
+
+ iowrite32(addr, base + CR_PROTOCOL_DATA_IN_REG);
+ iowrite32(0x1, base + CR_PROTOCOL_CAP_ADDR_REG);
+ while (ioread32(base + CR_PROTOCOL_CAP_ADDR_REG))
+ cpu_relax();
+
+ /*
+ * Due to hardware bug, first read of SSPHY register might be
+ * incorrect. Hence as workaround, SW should perform SSPHY register
+ * read twice, but use only second read and ignore first read.
+ */
+retry:
+ iowrite32(0x1, base + CR_PROTOCOL_READ_REG);
+ while (ioread32(base + CR_PROTOCOL_READ_REG))
+ cpu_relax();
+
+ if (first_read) {
+ ioread32(base + CR_PROTOCOL_DATA_OUT_REG);
+ first_read = false;
+ goto retry;
+ }
+
+ return ioread32(base + CR_PROTOCOL_DATA_OUT_REG);
+}
+
+static void msm_dwc3_ss_phy_shutdown(struct usb_phy *x)
+{
+ struct msm_dwc3_ss_phy *phy = phy_to_dwc3_phy(x);
+ int ret;
+
+ /* Sequence to put SSPHY in low power state:
+ * 1. Clear REF_PHY_EN in PHY_CTRL_REG
+ * 2. Clear REF_USE_PAD in PHY_CTRL_REG
+ * 3. Set TEST_POWERED_DOWN in PHY_CTRL_REG to enable PHY retention
+ * 4. Disable SSPHY ref clk
+ */
+ msm_dwc3_ss_write_readback(phy->base, PHY_CTRL_REG, (1 << 8), 0x0);
+ msm_dwc3_ss_write_readback(phy->base, PHY_CTRL_REG, (1 << 28), 0x0);
+ msm_dwc3_ss_write_readback(phy->base, PHY_CTRL_REG,
+ (1 << 26), (1 << 26));
+
+ usleep_range(1000, 1200);
+ clk_disable_unprepare(phy->ref_clk);
+
+ ret = regulator_set_voltage(phy->vddcx, USB_VDDCX_NO, USB_VDDCX_MAX);
+ if (ret)
+ dev_err(phy->dev, "cannot set voltage for vddcx\n");
+
+ regulator_disable(phy->vddcx);
+
+ ret = regulator_set_voltage(phy->v1p8, 0, PHY_1P8_VOL_MAX);
+ if (ret)
+ dev_err(phy->dev, "cannot set v1p8\n");
+
+ regulator_disable(phy->v1p8);
+}
+
+static int msm_dwc3_ss_phy_init(struct usb_phy *x)
+{
+ struct msm_dwc3_ss_phy *phy = phy_to_dwc3_phy(x);
+ u32 data = 0;
+ int ret;
+
+ ret = regulator_set_voltage(phy->vddcx, USB_VDDCX_MIN, USB_VDDCX_MAX);
+ if (ret) {
+ dev_err(phy->dev, "cannot set voltage for vddcx\n");
+ return ret;
+ }
+
+ ret = regulator_enable(phy->vddcx);
+ if (ret) {
+ dev_err(phy->dev, "cannot enable vddcx\n");
+ return ret;
+ }
+
+ ret = regulator_set_voltage(phy->v1p8, PHY_1P8_VOL_MIN,
+ PHY_1P8_VOL_MAX);
+ if (ret) {
+ regulator_disable(phy->vddcx);
+ dev_err(phy->dev, "cannot set v1p8\n");
+ return ret;
+ }
+
+ ret = regulator_enable(phy->v1p8);
+ if (ret) {
+ regulator_disable(phy->vddcx);
+ dev_err(phy->dev, "cannot enable v1p8\n");
+ return ret;
+ }
+
+ clk_prepare_enable(phy->ref_clk);
+ usleep_range(1000, 1200);
+
+ /* SSPHY Initialization: Use ref_clk from pads and set its parameters */
+ msm_dwc3_ss_write(phy->base, PHY_CTRL_REG, 0x10210002);
+ msleep(30);
+ /* Assert SSPHY reset */
+ msm_dwc3_ss_write(phy->base, PHY_CTRL_REG, 0x10210082);
+ usleep_range(2000, 2200);
+ /* De-assert SSPHY reset - power and ref_clock must be ON */
+ msm_dwc3_ss_write(phy->base, PHY_CTRL_REG, 0x10210002);
+ usleep_range(2000, 2200);
+ /* Ref clock must be stable now, enable ref clock for HS mode */
+ msm_dwc3_ss_write(phy->base, PHY_CTRL_REG, 0x10210102);
+ usleep_range(2000, 2200);
+
+ /*
+ * WORKAROUND: There is SSPHY suspend bug due to which USB enumerates
+ * in HS mode instead of SS mode. Workaround it by asserting
+ * LANE0.TX_ALT_BLOCK.EN_ALT_BUS to enable TX to use alt bus mode
+ */
+ data = msm_dwc3_ss_read_phycreg(phy->base, 0x102d);
+ data |= (1 << 7);
+ msm_dwc3_ss_write_phycreg(phy->base, 0x102D, data);
+
+ data = msm_dwc3_ss_read_phycreg(phy->base, 0x1010);
+ data &= ~0xff0;
+ data |= 0x20;
+ msm_dwc3_ss_write_phycreg(phy->base, 0x1010, data);
+
+ /*
+ * Fix RX Equalization setting as follows
+ * LANE0.RX_OVRD_IN_HI. RX_EQ_EN set to 0
+ * LANE0.RX_OVRD_IN_HI.RX_EQ_EN_OVRD set to 1
+ * LANE0.RX_OVRD_IN_HI.RX_EQ set to 3
+ * LANE0.RX_OVRD_IN_HI.RX_EQ_OVRD set to 1
+ */
+ data = msm_dwc3_ss_read_phycreg(phy->base, 0x1006);
+ data &= ~(1 << 6);
+ data |= (1 << 7);
+ data &= ~(0x7 << 8);
+ data |= (0x3 << 8);
+ data |= (0x1 << 11);
+ msm_dwc3_ss_write_phycreg(phy->base, 0x1006, data);
+
+ /*
+ * Set EQ and TX launch amplitudes as follows
+ * LANE0.TX_OVRD_DRV_LO.PREEMPH set to 22
+ * LANE0.TX_OVRD_DRV_LO.AMPLITUDE set to 127
+ * LANE0.TX_OVRD_DRV_LO.EN set to 1.
+ */
+ data = msm_dwc3_ss_read_phycreg(phy->base, 0x1002);
+ data &= ~0x3f80;
+ data |= (0x16 << 7);
+ data &= ~0x7f;
+ data |= (0x7f | (1 << 14));
+ msm_dwc3_ss_write_phycreg(phy->base, 0x1002, data);
+
+ /*
+ * Set the QSCRATCH PHY_PARAM_CTRL1 parameters as follows
+ * TX_FULL_SWING [26:20] amplitude to 127
+ * TX_DEEMPH_3_5DB [13:8] to 22
+ * LOS_BIAS [2:0] to 0x5
+ */
+ msm_dwc3_ss_write_readback(phy->base, PHY_PARAM_CTRL_1,
+ 0x07f03f07, 0x07f01605);
+ return 0;
+}
+
+static int msm_dwc3_ss_probe(struct platform_device *pdev)
+{
+ struct msm_dwc3_ss_phy *phy;
+ struct resource *res;
+ void __iomem *base;
+
+ phy = devm_kzalloc(&pdev->dev, sizeof(*phy), GFP_KERNEL);
+ if (!phy)
+ return -ENOMEM;
+
+ platform_set_drvdata(pdev, phy);
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ base = devm_ioremap_resource(&pdev->dev, res);
+ if (IS_ERR(base))
+ return PTR_ERR(base);
+
+ phy->vddcx = devm_regulator_get(phy->dev, "vddcx");
+ if (IS_ERR(phy->vddcx)) {
+ dev_dbg(&pdev->dev, "cannot get vddcx\n");
+ return PTR_ERR(phy->vddcx);
+ }
+
+ phy->v1p8 = devm_regulator_get(phy->dev, "v1p8");
+ if (IS_ERR(phy->v1p8)) {
+ dev_dbg(&pdev->dev, "cannot get v1p8\n");
+ return PTR_ERR(phy->v1p8);
+ }
+
+ phy->xo_clk = devm_clk_get(&pdev->dev, "xo");
+ if (IS_ERR(phy->xo_clk)) {
+ dev_dbg(&pdev->dev, "cannot get TCXO buffer handle\n");
+ return PTR_ERR(phy->xo_clk);
+ }
+
+ phy->ref_clk = devm_clk_get(&pdev->dev, "ref");
+ if (IS_ERR(phy->ref_clk)) {
+ dev_dbg(&pdev->dev, "cannot get ref clock handle\n");
+ return PTR_ERR(phy->ref_clk);
+ }
+
+ clk_prepare_enable(phy->xo_clk);
+
+ phy->dev = &pdev->dev;
+ phy->base = base;
+ phy->phy.dev = phy->dev;
+ phy->phy.label = "msm-dwc3-ssphy";
+ phy->phy.init = msm_dwc3_ss_phy_init;
+ phy->phy.shutdown = msm_dwc3_ss_phy_shutdown;
+ phy->phy.type = USB_PHY_TYPE_USB3;
+
+ usb_add_phy_dev(&phy->phy);
+
+ return 0;
+}
+
+static int msm_dwc3_ss_remove(struct platform_device *pdev)
+{
+ struct msm_dwc3_ss_phy *phy = platform_get_drvdata(pdev);
+
+ clk_disable_unprepare(phy->xo_clk);
+ usb_remove_phy(&phy->phy);
+ return 0;
+}
+
+static const struct of_device_id msm_dwc3_ss_id_table[] = {
+ { .compatible = "qcom,dwc3-ssphy" },
+ { /* Sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, msm_dwc3_ss_id_table);
+
+static struct platform_driver msm_dwc3_ss_driver = {
+ .probe = msm_dwc3_ss_probe,
+ .remove = msm_dwc3_ss_remove,
+ .driver = {
+ .name = "msm-dwc3-ssphy",
+ .owner = THIS_MODULE,
+ .of_match_table = msm_dwc3_ss_id_table,
+ },
+};
+
+module_platform_driver(msm_dwc3_ss_driver);
+
+MODULE_ALIAS("platform:msm_dwc3_ssphy");
+MODULE_LICENSE("GPL v2");
+MODULE_DESCRIPTION("DesignWare USB3 MSM SS-PHY driver");
--
1.7.9.5
Hi,
On Tue, Aug 20, 2013 at 12:56:04PM +0300, Ivan T. Ivanov wrote:
> From: "Ivan T. Ivanov" <[email protected]>
>
> These drivers handles control and configuration of the HS
> and SS USB PHY transceivers. They are part of the driver
> which manage Synopsys DesignWare USB3 controller stack
> inside Qualcomm SoC's.
>
> Signed-off-by: Ivan T. Ivanov <[email protected]>
> ---
> drivers/usb/phy/Kconfig | 11 ++
> drivers/usb/phy/Makefile | 2 +
> drivers/usb/phy/phy-msm-dwc3-hs.c | 327 ++++++++++++++++++++++++++++++++
> drivers/usb/phy/phy-msm-dwc3-ss.c | 374 +++++++++++++++++++++++++++++++++++++
please rename these PHY drivers, they have nothing to do with DWC3. PHYs
don't care about the USB controller.
--
balbi
Hi,
On Tue, 2013-08-20 at 07:29 -0500, Felipe Balbi wrote:
> Hi,
>
> On Tue, Aug 20, 2013 at 12:56:04PM +0300, Ivan T. Ivanov wrote:
> > From: "Ivan T. Ivanov" <[email protected]>
> >
> > These drivers handles control and configuration of the HS
> > and SS USB PHY transceivers. They are part of the driver
> > which manage Synopsys DesignWare USB3 controller stack
> > inside Qualcomm SoC's.
> >
> > Signed-off-by: Ivan T. Ivanov <[email protected]>
> > ---
> > drivers/usb/phy/Kconfig | 11 ++
> > drivers/usb/phy/Makefile | 2 +
> > drivers/usb/phy/phy-msm-dwc3-hs.c | 327 ++++++++++++++++++++++++++++++++
> > drivers/usb/phy/phy-msm-dwc3-ss.c | 374 +++++++++++++++++++++++++++++++++++++
>
> please rename these PHY drivers, they have nothing to do with DWC3. PHYs
> don't care about the USB controller.
I think they are SNPS DesignWare PHY's, additionally
wrapped with Qualcomm logic. I could substitute "dwc3"
with just "dw", which will be more correct.
Regards,
Ivan
Hi,
On Tue, Aug 20, 2013 at 04:32:23PM +0300, Ivan T. Ivanov wrote:
> > On Tue, Aug 20, 2013 at 12:56:04PM +0300, Ivan T. Ivanov wrote:
> > > From: "Ivan T. Ivanov" <[email protected]>
> > >
> > > These drivers handles control and configuration of the HS
> > > and SS USB PHY transceivers. They are part of the driver
> > > which manage Synopsys DesignWare USB3 controller stack
> > > inside Qualcomm SoC's.
> > >
> > > Signed-off-by: Ivan T. Ivanov <[email protected]>
> > > ---
> > > drivers/usb/phy/Kconfig | 11 ++
> > > drivers/usb/phy/Makefile | 2 +
> > > drivers/usb/phy/phy-msm-dwc3-hs.c | 327 ++++++++++++++++++++++++++++++++
> > > drivers/usb/phy/phy-msm-dwc3-ss.c | 374 +++++++++++++++++++++++++++++++++++++
> >
> > please rename these PHY drivers, they have nothing to do with DWC3. PHYs
> > don't care about the USB controller.
>
> I think they are SNPS DesignWare PHY's, additionally
> wrapped with Qualcomm logic. I could substitute "dwc3"
> with just "dw", which will be more correct.
alright, thank you. Let's add Paul to the loop since he might have very
good insight in the synopsys PHYs.
mental note: if any other platform shows up with Synopsys PHY, ask them
to use this driver instead :-)
--
balbi
Hi,
On Tue, 2013-08-20 at 08:37 -0500, Felipe Balbi wrote:
> Hi,
>
> On Tue, Aug 20, 2013 at 04:32:23PM +0300, Ivan T. Ivanov wrote:
> > > On Tue, Aug 20, 2013 at 12:56:04PM +0300, Ivan T. Ivanov wrote:
> > > > From: "Ivan T. Ivanov" <[email protected]>
> > > >
> > > > These drivers handles control and configuration of the HS
> > > > and SS USB PHY transceivers. They are part of the driver
> > > > which manage Synopsys DesignWare USB3 controller stack
> > > > inside Qualcomm SoC's.
> > > >
> > > > Signed-off-by: Ivan T. Ivanov <[email protected]>
> > > > ---
> > > > drivers/usb/phy/Kconfig | 11 ++
> > > > drivers/usb/phy/Makefile | 2 +
> > > > drivers/usb/phy/phy-msm-dwc3-hs.c | 327 ++++++++++++++++++++++++++++++++
> > > > drivers/usb/phy/phy-msm-dwc3-ss.c | 374 +++++++++++++++++++++++++++++++++++++
> > >
> > > please rename these PHY drivers, they have nothing to do with DWC3. PHYs
> > > don't care about the USB controller.
> >
> > I think they are SNPS DesignWare PHY's, additionally
> > wrapped with Qualcomm logic. I could substitute "dwc3"
> > with just "dw", which will be more correct.
>
> alright, thank you. Let's add Paul to the loop since he might have very
> good insight in the synopsys PHYs.
>
> mental note: if any other platform shows up with Synopsys PHY, ask them
> to use this driver instead :-)
I really doubt that this will bi possible. Control of the PHY's is
not directly trough ULPI, UTMI or PIPE3 interfaces, but trough
QSCRATCH registers, which of course is highly Qualcomm specific.
Regards,
Ivan
On Tue, Aug 20, 2013 at 05:09:11PM +0300, Ivan T. Ivanov wrote:
> Hi,
>
> On Tue, 2013-08-20 at 08:37 -0500, Felipe Balbi wrote:
> > Hi,
> >
> > On Tue, Aug 20, 2013 at 04:32:23PM +0300, Ivan T. Ivanov wrote:
> > > > On Tue, Aug 20, 2013 at 12:56:04PM +0300, Ivan T. Ivanov wrote:
> > > > > From: "Ivan T. Ivanov" <[email protected]>
> > > > >
> > > > > These drivers handles control and configuration of the HS
> > > > > and SS USB PHY transceivers. They are part of the driver
> > > > > which manage Synopsys DesignWare USB3 controller stack
> > > > > inside Qualcomm SoC's.
> > > > >
> > > > > Signed-off-by: Ivan T. Ivanov <[email protected]>
> > > > > ---
> > > > > drivers/usb/phy/Kconfig | 11 ++
> > > > > drivers/usb/phy/Makefile | 2 +
> > > > > drivers/usb/phy/phy-msm-dwc3-hs.c | 327 ++++++++++++++++++++++++++++++++
> > > > > drivers/usb/phy/phy-msm-dwc3-ss.c | 374 +++++++++++++++++++++++++++++++++++++
> > > >
> > > > please rename these PHY drivers, they have nothing to do with DWC3. PHYs
> > > > don't care about the USB controller.
> > >
> > > I think they are SNPS DesignWare PHY's, additionally
> > > wrapped with Qualcomm logic. I could substitute "dwc3"
> > > with just "dw", which will be more correct.
> >
> > alright, thank you. Let's add Paul to the loop since he might have very
> > good insight in the synopsys PHYs.
> >
> > mental note: if any other platform shows up with Synopsys PHY, ask them
> > to use this driver instead :-)
>
> I really doubt that this will bi possible. Control of the PHY's is
> not directly trough ULPI, UTMI or PIPE3 interfaces, but trough
> QSCRATCH registers, which of course is highly Qualcomm specific.
isn't it a memory mapped IP ? doesn't synopsys provide their own set of
registers ?
--
balbi
Hi,
On Tue, 2013-08-20 at 09:33 -0500, Felipe Balbi wrote:
> On Tue, Aug 20, 2013 at 05:09:11PM +0300, Ivan T. Ivanov wrote:
> > Hi,
> >
> > On Tue, 2013-08-20 at 08:37 -0500, Felipe Balbi wrote:
> > > Hi,
> > >
> > > On Tue, Aug 20, 2013 at 04:32:23PM +0300, Ivan T. Ivanov wrote:
> > > > > On Tue, Aug 20, 2013 at 12:56:04PM +0300, Ivan T. Ivanov wrote:
> > > > > > From: "Ivan T. Ivanov" <[email protected]>
> > > > > >
> > > > > > These drivers handles control and configuration of the HS
> > > > > > and SS USB PHY transceivers. They are part of the driver
> > > > > > which manage Synopsys DesignWare USB3 controller stack
> > > > > > inside Qualcomm SoC's.
> > > > > >
> > > > > > Signed-off-by: Ivan T. Ivanov <[email protected]>
> > > > > > ---
> > > > > > drivers/usb/phy/Kconfig | 11 ++
> > > > > > drivers/usb/phy/Makefile | 2 +
> > > > > > drivers/usb/phy/phy-msm-dwc3-hs.c | 327 ++++++++++++++++++++++++++++++++
> > > > > > drivers/usb/phy/phy-msm-dwc3-ss.c | 374 +++++++++++++++++++++++++++++++++++++
> > > > >
> > > > > please rename these PHY drivers, they have nothing to do with DWC3. PHYs
> > > > > don't care about the USB controller.
> > > >
> > > > I think they are SNPS DesignWare PHY's, additionally
> > > > wrapped with Qualcomm logic. I could substitute "dwc3"
> > > > with just "dw", which will be more correct.
> > >
> > > alright, thank you. Let's add Paul to the loop since he might have very
> > > good insight in the synopsys PHYs.
> > >
> > > mental note: if any other platform shows up with Synopsys PHY, ask them
> > > to use this driver instead :-)
> >
> > I really doubt that this will bi possible. Control of the PHY's is
> > not directly trough ULPI, UTMI or PIPE3 interfaces, but trough
> > QSCRATCH registers, which of course is highly Qualcomm specific.
>
> isn't it a memory mapped IP ? doesn't synopsys provide their own set of
> registers ?
>From what I see it is not directly mapped. How QSCRATCH write and
reads transactions are translated to DW IP is unclear to me.
Ivan
On Aug 20, 2013, at 9:54 AM, Ivan T. Ivanov wrote:
>
> Hi,
>
> On Tue, 2013-08-20 at 09:33 -0500, Felipe Balbi wrote:
>> On Tue, Aug 20, 2013 at 05:09:11PM +0300, Ivan T. Ivanov wrote:
>>> Hi,
>>>
>>> On Tue, 2013-08-20 at 08:37 -0500, Felipe Balbi wrote:
>>>> Hi,
>>>>
>>>> On Tue, Aug 20, 2013 at 04:32:23PM +0300, Ivan T. Ivanov wrote:
>>>>>> On Tue, Aug 20, 2013 at 12:56:04PM +0300, Ivan T. Ivanov wrote:
>>>>>>> From: "Ivan T. Ivanov" <[email protected]>
>>>>>>>
>>>>>>> These drivers handles control and configuration of the HS
>>>>>>> and SS USB PHY transceivers. They are part of the driver
>>>>>>> which manage Synopsys DesignWare USB3 controller stack
>>>>>>> inside Qualcomm SoC's.
>>>>>>>
>>>>>>> Signed-off-by: Ivan T. Ivanov <[email protected]>
>>>>>>> ---
>>>>>>> drivers/usb/phy/Kconfig | 11 ++
>>>>>>> drivers/usb/phy/Makefile | 2 +
>>>>>>> drivers/usb/phy/phy-msm-dwc3-hs.c | 327 ++++++++++++++++++++++++++++++++
>>>>>>> drivers/usb/phy/phy-msm-dwc3-ss.c | 374 +++++++++++++++++++++++++++++++++++++
>>>>>>
>>>>>> please rename these PHY drivers, they have nothing to do with DWC3. PHYs
>>>>>> don't care about the USB controller.
>>>>>
>>>>> I think they are SNPS DesignWare PHY's, additionally
>>>>> wrapped with Qualcomm logic. I could substitute "dwc3"
>>>>> with just "dw", which will be more correct.
>>>>
>>>> alright, thank you. Let's add Paul to the loop since he might have very
>>>> good insight in the synopsys PHYs.
>>>>
>>>> mental note: if any other platform shows up with Synopsys PHY, ask them
>>>> to use this driver instead :-)
>>>
>>> I really doubt that this will bi possible. Control of the PHY's is
>>> not directly trough ULPI, UTMI or PIPE3 interfaces, but trough
>>> QSCRATCH registers, which of course is highly Qualcomm specific.
>>
>> isn't it a memory mapped IP ? doesn't synopsys provide their own set of
>> registers ?
>
> From what I see it is not directly mapped. How QSCRATCH write and
> reads transactions are translated to DW IP is unclear to me.
I think the question is how does SW access them?
- k
--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
On Tue, 2013-08-20 at 16:01 +0100, Kumar Gala wrote:
> On Aug 20, 2013, at 9:54 AM, Ivan T. Ivanov wrote:
>
> >
> > Hi,
> >
> > On Tue, 2013-08-20 at 09:33 -0500, Felipe Balbi wrote:
> >> On Tue, Aug 20, 2013 at 05:09:11PM +0300, Ivan T. Ivanov wrote:
> >>> Hi,
> >>>
> >>> On Tue, 2013-08-20 at 08:37 -0500, Felipe Balbi wrote:
> >>>> Hi,
> >>>>
> >>>> On Tue, Aug 20, 2013 at 04:32:23PM +0300, Ivan T. Ivanov wrote:
> >>>>>> On Tue, Aug 20, 2013 at 12:56:04PM +0300, Ivan T. Ivanov wrote:
> >>>>>>> From: "Ivan T. Ivanov" <[email protected]>
> >>>>>>>
> >>>>>>> These drivers handles control and configuration of the HS
> >>>>>>> and SS USB PHY transceivers. They are part of the driver
> >>>>>>> which manage Synopsys DesignWare USB3 controller stack
> >>>>>>> inside Qualcomm SoC's.
> >>>>>>>
> >>>>>>> Signed-off-by: Ivan T. Ivanov <[email protected]>
> >>>>>>> ---
> >>>>>>> drivers/usb/phy/Kconfig | 11 ++
> >>>>>>> drivers/usb/phy/Makefile | 2 +
> >>>>>>> drivers/usb/phy/phy-msm-dwc3-hs.c | 327 ++++++++++++++++++++++++++++++++
> >>>>>>> drivers/usb/phy/phy-msm-dwc3-ss.c | 374 +++++++++++++++++++++++++++++++++++++
> >>>>>>
> >>>>>> please rename these PHY drivers, they have nothing to do with DWC3. PHYs
> >>>>>> don't care about the USB controller.
> >>>>>
> >>>>> I think they are SNPS DesignWare PHY's, additionally
> >>>>> wrapped with Qualcomm logic. I could substitute "dwc3"
> >>>>> with just "dw", which will be more correct.
> >>>>
> >>>> alright, thank you. Let's add Paul to the loop since he might have very
> >>>> good insight in the synopsys PHYs.
> >>>>
> >>>> mental note: if any other platform shows up with Synopsys PHY, ask them
> >>>> to use this driver instead :-)
> >>>
> >>> I really doubt that this will bi possible. Control of the PHY's is
> >>> not directly trough ULPI, UTMI or PIPE3 interfaces, but trough
> >>> QSCRATCH registers, which of course is highly Qualcomm specific.
> >>
> >> isn't it a memory mapped IP ? doesn't synopsys provide their own set of
> >> registers ?
> >
> > From what I see it is not directly mapped. How QSCRATCH write and
> > reads transactions are translated to DW IP is unclear to me.
>
>
> I think the question is how does SW access them?
I afraid the answer may be: "it depends on the SOC". In my past I had to
initialize a (SATA) PHY by implementing a software JTAG state machine,
as the PHY's registers were not memory mapped *at all*. And the IP
itself came from Synopsys, Cadence or yet another EDA company...
Paweł
On Tue, 2013-08-20 at 10:01 -0500, Kumar Gala wrote:
> On Aug 20, 2013, at 9:54 AM, Ivan T. Ivanov wrote:
>
> >
> > Hi,
> >
> > On Tue, 2013-08-20 at 09:33 -0500, Felipe Balbi wrote:
> >> On Tue, Aug 20, 2013 at 05:09:11PM +0300, Ivan T. Ivanov wrote:
> >>> Hi,
> >>>
> >>> On Tue, 2013-08-20 at 08:37 -0500, Felipe Balbi wrote:
> >>>> Hi,
> >>>>
> >>>> On Tue, Aug 20, 2013 at 04:32:23PM +0300, Ivan T. Ivanov wrote:
> >>>>>> On Tue, Aug 20, 2013 at 12:56:04PM +0300, Ivan T. Ivanov wrote:
> >>>>>>> From: "Ivan T. Ivanov" <[email protected]>
> >>>>>>>
> >>>>>>> These drivers handles control and configuration of the HS
> >>>>>>> and SS USB PHY transceivers. They are part of the driver
> >>>>>>> which manage Synopsys DesignWare USB3 controller stack
> >>>>>>> inside Qualcomm SoC's.
> >>>>>>>
> >>>>>>> Signed-off-by: Ivan T. Ivanov <[email protected]>
> >>>>>>> ---
> >>>>>>> drivers/usb/phy/Kconfig | 11 ++
> >>>>>>> drivers/usb/phy/Makefile | 2 +
> >>>>>>> drivers/usb/phy/phy-msm-dwc3-hs.c | 327 ++++++++++++++++++++++++++++++++
> >>>>>>> drivers/usb/phy/phy-msm-dwc3-ss.c | 374 +++++++++++++++++++++++++++++++++++++
> >>>>>>
> >>>>>> please rename these PHY drivers, they have nothing to do with DWC3. PHYs
> >>>>>> don't care about the USB controller.
> >>>>>
> >>>>> I think they are SNPS DesignWare PHY's, additionally
> >>>>> wrapped with Qualcomm logic. I could substitute "dwc3"
> >>>>> with just "dw", which will be more correct.
> >>>>
> >>>> alright, thank you. Let's add Paul to the loop since he might have very
> >>>> good insight in the synopsys PHYs.
> >>>>
> >>>> mental note: if any other platform shows up with Synopsys PHY, ask them
> >>>> to use this driver instead :-)
> >>>
> >>> I really doubt that this will bi possible. Control of the PHY's is
> >>> not directly trough ULPI, UTMI or PIPE3 interfaces, but trough
> >>> QSCRATCH registers, which of course is highly Qualcomm specific.
> >>
> >> isn't it a memory mapped IP ? doesn't synopsys provide their own set of
> >> registers ?
> >
> > From what I see it is not directly mapped. How QSCRATCH write and
> > reads transactions are translated to DW IP is unclear to me.
>
>
> I think the question is how does SW access them?
"USB QSCRATCH Hardware registers" don't ask me what is this :-)
or like Pawel says: "it depends on the SOC" .
Ivan
>
> - k
>
On Tue, 2013-08-20 at 16:06 +0100, Pawel Moll wrote:
> On Tue, 2013-08-20 at 16:01 +0100, Kumar Gala wrote:
> > On Aug 20, 2013, at 9:54 AM, Ivan T. Ivanov wrote:
> >
> > >
> > > Hi,
> > >
> > > On Tue, 2013-08-20 at 09:33 -0500, Felipe Balbi wrote:
> > >> On Tue, Aug 20, 2013 at 05:09:11PM +0300, Ivan T. Ivanov wrote:
> > >>> Hi,
> > >>>
> > >>> On Tue, 2013-08-20 at 08:37 -0500, Felipe Balbi wrote:
> > >>>> Hi,
> > >>>>
> > >>>> On Tue, Aug 20, 2013 at 04:32:23PM +0300, Ivan T. Ivanov wrote:
> > >>>>>> On Tue, Aug 20, 2013 at 12:56:04PM +0300, Ivan T. Ivanov wrote:
> > >>>>>>> From: "Ivan T. Ivanov" <[email protected]>
> > >>>>>>>
> > >>>>>>> These drivers handles control and configuration of the HS
> > >>>>>>> and SS USB PHY transceivers. They are part of the driver
> > >>>>>>> which manage Synopsys DesignWare USB3 controller stack
> > >>>>>>> inside Qualcomm SoC's.
> > >>>>>>>
> > >>>>>>> Signed-off-by: Ivan T. Ivanov <[email protected]>
> > >>>>>>> ---
> > >>>>>>> drivers/usb/phy/Kconfig | 11 ++
> > >>>>>>> drivers/usb/phy/Makefile | 2 +
> > >>>>>>> drivers/usb/phy/phy-msm-dwc3-hs.c | 327 ++++++++++++++++++++++++++++++++
> > >>>>>>> drivers/usb/phy/phy-msm-dwc3-ss.c | 374 +++++++++++++++++++++++++++++++++++++
> > >>>>>>
> > >>>>>> please rename these PHY drivers, they have nothing to do with DWC3. PHYs
> > >>>>>> don't care about the USB controller.
> > >>>>>
> > >>>>> I think they are SNPS DesignWare PHY's, additionally
> > >>>>> wrapped with Qualcomm logic. I could substitute "dwc3"
> > >>>>> with just "dw", which will be more correct.
> > >>>>
> > >>>> alright, thank you. Let's add Paul to the loop since he might have very
> > >>>> good insight in the synopsys PHYs.
> > >>>>
> > >>>> mental note: if any other platform shows up with Synopsys PHY, ask them
> > >>>> to use this driver instead :-)
> > >>>
> > >>> I really doubt that this will bi possible. Control of the PHY's is
> > >>> not directly trough ULPI, UTMI or PIPE3 interfaces, but trough
> > >>> QSCRATCH registers, which of course is highly Qualcomm specific.
> > >>
> > >> isn't it a memory mapped IP ? doesn't synopsys provide their own set of
> > >> registers ?
> > >
> > > From what I see it is not directly mapped. How QSCRATCH write and
> > > reads transactions are translated to DW IP is unclear to me.
> >
> >
> > I think the question is how does SW access them?
>
> I afraid the answer may be: "it depends on the SOC". In my past I had to
> initialize a (SATA) PHY by implementing a software JTAG state machine,
> as the PHY's registers were not memory mapped *at all*. And the IP
> itself came from Synopsys, Cadence or yet another EDA company...
Having said all that... If the PHY's spec at least defined layout of the
registers in question and driver was using regmap API to talk to the
device (initially regmap-mmio), it has some chances to become universal.
The SOCs designed like "my" one would have to provide a custom regmap
implementation.
Paweł
On Tue, 2013-08-20 at 18:01 +0100, Pawel Moll wrote:
> On Tue, 2013-08-20 at 16:06 +0100, Pawel Moll wrote:
> > On Tue, 2013-08-20 at 16:01 +0100, Kumar Gala wrote:
> > > On Aug 20, 2013, at 9:54 AM, Ivan T. Ivanov wrote:
> > >
> > > >
> > > > Hi,
> > > >
> > > > On Tue, 2013-08-20 at 09:33 -0500, Felipe Balbi wrote:
> > > >> On Tue, Aug 20, 2013 at 05:09:11PM +0300, Ivan T. Ivanov wrote:
> > > >>> Hi,
> > > >>>
> > > >>> On Tue, 2013-08-20 at 08:37 -0500, Felipe Balbi wrote:
> > > >>>> Hi,
> > > >>>>
> > > >>>> On Tue, Aug 20, 2013 at 04:32:23PM +0300, Ivan T. Ivanov wrote:
> > > >>>>>> On Tue, Aug 20, 2013 at 12:56:04PM +0300, Ivan T. Ivanov wrote:
> > > >>>>>>> From: "Ivan T. Ivanov" <[email protected]>
> > > >>>>>>>
> > > >>>>>>> These drivers handles control and configuration of the HS
> > > >>>>>>> and SS USB PHY transceivers. They are part of the driver
> > > >>>>>>> which manage Synopsys DesignWare USB3 controller stack
> > > >>>>>>> inside Qualcomm SoC's.
> > > >>>>>>>
> > > >>>>>>> Signed-off-by: Ivan T. Ivanov <[email protected]>
> > > >>>>>>> ---
> > > >>>>>>> drivers/usb/phy/Kconfig | 11 ++
> > > >>>>>>> drivers/usb/phy/Makefile | 2 +
> > > >>>>>>> drivers/usb/phy/phy-msm-dwc3-hs.c | 327 ++++++++++++++++++++++++++++++++
> > > >>>>>>> drivers/usb/phy/phy-msm-dwc3-ss.c | 374 +++++++++++++++++++++++++++++++++++++
> > > >>>>>>
> > > >>>>>> please rename these PHY drivers, they have nothing to do with DWC3. PHYs
> > > >>>>>> don't care about the USB controller.
> > > >>>>>
> > > >>>>> I think they are SNPS DesignWare PHY's, additionally
> > > >>>>> wrapped with Qualcomm logic. I could substitute "dwc3"
> > > >>>>> with just "dw", which will be more correct.
> > > >>>>
> > > >>>> alright, thank you. Let's add Paul to the loop since he might have very
> > > >>>> good insight in the synopsys PHYs.
> > > >>>>
> > > >>>> mental note: if any other platform shows up with Synopsys PHY, ask them
> > > >>>> to use this driver instead :-)
> > > >>>
> > > >>> I really doubt that this will bi possible. Control of the PHY's is
> > > >>> not directly trough ULPI, UTMI or PIPE3 interfaces, but trough
> > > >>> QSCRATCH registers, which of course is highly Qualcomm specific.
> > > >>
> > > >> isn't it a memory mapped IP ? doesn't synopsys provide their own set of
> > > >> registers ?
> > > >
> > > > From what I see it is not directly mapped. How QSCRATCH write and
> > > > reads transactions are translated to DW IP is unclear to me.
> > >
> > >
> > > I think the question is how does SW access them?
> >
> > I afraid the answer may be: "it depends on the SOC". In my past I had to
> > initialize a (SATA) PHY by implementing a software JTAG state machine,
> > as the PHY's registers were not memory mapped *at all*. And the IP
> > itself came from Synopsys, Cadence or yet another EDA company...
>
> Having said all that... If the PHY's spec at least defined layout of the
> registers in question and driver was using regmap API to talk to the
> device (initially regmap-mmio), it has some chances to become universal.
> The SOCs designed like "my" one would have to provide a custom regmap
> implementation.
Sound reasonable. Unfortunately I don't have PHY's IP spec.
Regards,
Ivan
>
> Paweł
>
On Wed, Aug 21, 2013 at 10:13:28AM -0500, Kumar Gala wrote:
>
> On Aug 21, 2013, at 8:06 AM, Ivan T. Ivanov wrote:
>
> > On Tue, 2013-08-20 at 18:01 +0100, Pawel Moll wrote:
> >> On Tue, 2013-08-20 at 16:06 +0100, Pawel Moll wrote:
> >>> On Tue, 2013-08-20 at 16:01 +0100, Kumar Gala wrote:
> >>>> On Aug 20, 2013, at 9:54 AM, Ivan T. Ivanov wrote:
> >>>>
> >>>>>
> >>>>> Hi,
> >>>>>
> >>>>> On Tue, 2013-08-20 at 09:33 -0500, Felipe Balbi wrote:
> >>>>>> On Tue, Aug 20, 2013 at 05:09:11PM +0300, Ivan T. Ivanov wrote:
> >>>>>>> Hi,
> >>>>>>>
> >>>>>>> On Tue, 2013-08-20 at 08:37 -0500, Felipe Balbi wrote:
> >>>>>>>> Hi,
> >>>>>>>>
> >>>>>>>> On Tue, Aug 20, 2013 at 04:32:23PM +0300, Ivan T. Ivanov wrote:
> >>>>>>>>>> On Tue, Aug 20, 2013 at 12:56:04PM +0300, Ivan T. Ivanov wrote:
> >>>>>>>>>>> From: "Ivan T. Ivanov" <[email protected]>
> >>>>>>>>>>>
> >>>>>>>>>>> These drivers handles control and configuration of the HS
> >>>>>>>>>>> and SS USB PHY transceivers. They are part of the driver
> >>>>>>>>>>> which manage Synopsys DesignWare USB3 controller stack
> >>>>>>>>>>> inside Qualcomm SoC's.
> >>>>>>>>>>>
> >>>>>>>>>>> Signed-off-by: Ivan T. Ivanov <[email protected]>
> >>>>>>>>>>> ---
> >>>>>>>>>>> drivers/usb/phy/Kconfig | 11 ++
> >>>>>>>>>>> drivers/usb/phy/Makefile | 2 +
> >>>>>>>>>>> drivers/usb/phy/phy-msm-dwc3-hs.c | 327 ++++++++++++++++++++++++++++++++
> >>>>>>>>>>> drivers/usb/phy/phy-msm-dwc3-ss.c | 374 +++++++++++++++++++++++++++++++++++++
> >>>>>>>>>>
> >>>>>>>>>> please rename these PHY drivers, they have nothing to do with DWC3. PHYs
> >>>>>>>>>> don't care about the USB controller.
> >>>>>>>>>
> >>>>>>>>> I think they are SNPS DesignWare PHY's, additionally
> >>>>>>>>> wrapped with Qualcomm logic. I could substitute "dwc3"
> >>>>>>>>> with just "dw", which will be more correct.
> >>>>>>>>
> >>>>>>>> alright, thank you. Let's add Paul to the loop since he might have very
> >>>>>>>> good insight in the synopsys PHYs.
> >>>>>>>>
> >>>>>>>> mental note: if any other platform shows up with Synopsys PHY, ask them
> >>>>>>>> to use this driver instead :-)
> >>>>>>>
> >>>>>>> I really doubt that this will bi possible. Control of the PHY's is
> >>>>>>> not directly trough ULPI, UTMI or PIPE3 interfaces, but trough
> >>>>>>> QSCRATCH registers, which of course is highly Qualcomm specific.
> >>>>>>
> >>>>>> isn't it a memory mapped IP ? doesn't synopsys provide their own set of
> >>>>>> registers ?
> >>>>>
> >>>>> From what I see it is not directly mapped. How QSCRATCH write and
> >>>>> reads transactions are translated to DW IP is unclear to me.
> >>>>
> >>>>
> >>>> I think the question is how does SW access them?
> >>>
> >>> I afraid the answer may be: "it depends on the SOC". In my past I had to
> >>> initialize a (SATA) PHY by implementing a software JTAG state machine,
> >>> as the PHY's registers were not memory mapped *at all*. And the IP
> >>> itself came from Synopsys, Cadence or yet another EDA company...
> >>
> >> Having said all that... If the PHY's spec at least defined layout of the
> >> registers in question and driver was using regmap API to talk to the
> >> device (initially regmap-mmio), it has some chances to become universal.
> >> The SOCs designed like "my" one would have to provide a custom regmap
> >> implementation.
> >
> > Sound reasonable. Unfortunately I don't have PHY's IP spec.
>
> Looking into this it appears that the register wrapper around the IP
> is most likely highly specific to qualcomm as I'm not seeing a
> register interface around the DWC HS PHY.
Then it's set, we'll go with this driver :-)
--
balbi
> From: Ivan T. Ivanov [mailto:[email protected]]
> Sent: Tuesday, August 20, 2013 8:26 AM
>
> On Tue, 2013-08-20 at 10:01 -0500, Kumar Gala wrote:
> > On Aug 20, 2013, at 9:54 AM, Ivan T. Ivanov wrote:
> >
> > >
> > > Hi,
> > >
> > > On Tue, 2013-08-20 at 09:33 -0500, Felipe Balbi wrote:
> > >> On Tue, Aug 20, 2013 at 05:09:11PM +0300, Ivan T. Ivanov wrote:
> > >>>
> > >>> On Tue, 2013-08-20 at 08:37 -0500, Felipe Balbi wrote:
> > >>>>
> > >>>> On Tue, Aug 20, 2013 at 04:32:23PM +0300, Ivan T. Ivanov wrote:
> > >>>>>
> > >>>>> I think they are SNPS DesignWare PHY's, additionally
> > >>>>> wrapped with Qualcomm logic. I could substitute "dwc3"
> > >>>>> with just "dw", which will be more correct.
> > >>>>
> > >>>> alright, thank you. Let's add Paul to the loop since he might have very
> > >>>> good insight in the synopsys PHYs.
> > >>>>
> > >>>> mental note: if any other platform shows up with Synopsys PHY, ask them
> > >>>> to use this driver instead :-)
> > >>>
> > >>> I really doubt that this will bi possible. Control of the PHY's is
> > >>> not directly trough ULPI, UTMI or PIPE3 interfaces, but trough
> > >>> QSCRATCH registers, which of course is highly Qualcomm specific.
> > >>
> > >> isn't it a memory mapped IP ? doesn't synopsys provide their own set of
> > >> registers ?
> > >
> > > From what I see it is not directly mapped. How QSCRATCH write and
> > > reads transactions are translated to DW IP is unclear to me.
> >
> >
> > I think the question is how does SW access them?
>
> "USB QSCRATCH Hardware registers" don't ask me what is this :-)
> or like Pawel says: "it depends on the SOC" .
To answer the question "doesn't synopsys provide their own set of
registers", we provide registers in our USB cores to access the PHYs
through I2C, ULPI/UTMI, or PIPE3 interfaces. But if someone wants to use
our PHY with some other controller that doesn't provide that, then they
may need to implement their own register set, as Qualcomm has apparently
done.
--
Paul
????{.n?+???????+%?????ݶ??w??{.n?+????{??G?????{ay? ʇڙ?,j??f???h?????????z_??(?階?ݢj"???m??????G????????????&???~???iO???z??v?^?m???? ????????I?
Hi,
On Thu, Aug 22, 2013 at 09:24:49PM +0000, Paul Zimmerman wrote:
> > From: Ivan T. Ivanov [mailto:[email protected]]
> > Sent: Tuesday, August 20, 2013 8:26 AM
> >
> > On Tue, 2013-08-20 at 10:01 -0500, Kumar Gala wrote:
> > > On Aug 20, 2013, at 9:54 AM, Ivan T. Ivanov wrote:
> > >
> > > >
> > > > Hi,
> > > >
> > > > On Tue, 2013-08-20 at 09:33 -0500, Felipe Balbi wrote:
> > > >> On Tue, Aug 20, 2013 at 05:09:11PM +0300, Ivan T. Ivanov wrote:
> > > >>>
> > > >>> On Tue, 2013-08-20 at 08:37 -0500, Felipe Balbi wrote:
> > > >>>>
> > > >>>> On Tue, Aug 20, 2013 at 04:32:23PM +0300, Ivan T. Ivanov wrote:
> > > >>>>>
> > > >>>>> I think they are SNPS DesignWare PHY's, additionally
> > > >>>>> wrapped with Qualcomm logic. I could substitute "dwc3"
> > > >>>>> with just "dw", which will be more correct.
> > > >>>>
> > > >>>> alright, thank you. Let's add Paul to the loop since he might have very
> > > >>>> good insight in the synopsys PHYs.
> > > >>>>
> > > >>>> mental note: if any other platform shows up with Synopsys PHY, ask them
> > > >>>> to use this driver instead :-)
> > > >>>
> > > >>> I really doubt that this will bi possible. Control of the PHY's is
> > > >>> not directly trough ULPI, UTMI or PIPE3 interfaces, but trough
> > > >>> QSCRATCH registers, which of course is highly Qualcomm specific.
> > > >>
> > > >> isn't it a memory mapped IP ? doesn't synopsys provide their own set of
> > > >> registers ?
> > > >
> > > > From what I see it is not directly mapped. How QSCRATCH write and
> > > > reads transactions are translated to DW IP is unclear to me.
> > >
> > >
> > > I think the question is how does SW access them?
> >
> > "USB QSCRATCH Hardware registers" don't ask me what is this :-)
> > or like Pawel says: "it depends on the SOC" .
>
> To answer the question "doesn't synopsys provide their own set of
> registers", we provide registers in our USB cores to access the PHYs
> through I2C, ULPI/UTMI, or PIPE3 interfaces. But if someone wants to use
> our PHY with some other controller that doesn't provide that, then they
> may need to implement their own register set, as Qualcomm has apparently
> done.
thanks for clarifying. that pretty much hinders writing any sort of
generic drivers for Synopsys' PHYs though :-s
But I guess that's alright.
--
balbi
On Thu, 2013-08-22 at 15:41 -0500, Felipe Balbi wrote:
> On Wed, Aug 21, 2013 at 10:13:28AM -0500, Kumar Gala wrote:
> >
> > On Aug 21, 2013, at 8:06 AM, Ivan T. Ivanov wrote:
> >
> > > On Tue, 2013-08-20 at 18:01 +0100, Pawel Moll wrote:
> > >> On Tue, 2013-08-20 at 16:06 +0100, Pawel Moll wrote:
> > >>> On Tue, 2013-08-20 at 16:01 +0100, Kumar Gala wrote:
> > >>>> On Aug 20, 2013, at 9:54 AM, Ivan T. Ivanov wrote:
> > >>>>
> > >>>>>
> > >>>>> Hi,
> > >>>>>
> > >>>>> On Tue, 2013-08-20 at 09:33 -0500, Felipe Balbi wrote:
> > >>>>>> On Tue, Aug 20, 2013 at 05:09:11PM +0300, Ivan T. Ivanov wrote:
> > >>>>>>> Hi,
> > >>>>>>>
> > >>>>>>> On Tue, 2013-08-20 at 08:37 -0500, Felipe Balbi wrote:
> > >>>>>>>> Hi,
> > >>>>>>>>
> > >>>>>>>> On Tue, Aug 20, 2013 at 04:32:23PM +0300, Ivan T. Ivanov wrote:
> > >>>>>>>>>> On Tue, Aug 20, 2013 at 12:56:04PM +0300, Ivan T. Ivanov wrote:
> > >>>>>>>>>>> From: "Ivan T. Ivanov" <[email protected]>
> > >>>>>>>>>>>
> > >>>>>>>>>>> These drivers handles control and configuration of the HS
> > >>>>>>>>>>> and SS USB PHY transceivers. They are part of the driver
> > >>>>>>>>>>> which manage Synopsys DesignWare USB3 controller stack
> > >>>>>>>>>>> inside Qualcomm SoC's.
> > >>>>>>>>>>>
> > >>>>>>>>>>> Signed-off-by: Ivan T. Ivanov <[email protected]>
> > >>>>>>>>>>> ---
> > >>>>>>>>>>> drivers/usb/phy/Kconfig | 11 ++
> > >>>>>>>>>>> drivers/usb/phy/Makefile | 2 +
> > >>>>>>>>>>> drivers/usb/phy/phy-msm-dwc3-hs.c | 327 ++++++++++++++++++++++++++++++++
> > >>>>>>>>>>> drivers/usb/phy/phy-msm-dwc3-ss.c | 374 +++++++++++++++++++++++++++++++++++++
> > >>>>>>>>>>
> > >>>>>>>>>> please rename these PHY drivers, they have nothing to do with DWC3. PHYs
> > >>>>>>>>>> don't care about the USB controller.
> > >>>>>>>>>
> > >>>>>>>>> I think they are SNPS DesignWare PHY's, additionally
> > >>>>>>>>> wrapped with Qualcomm logic. I could substitute "dwc3"
> > >>>>>>>>> with just "dw", which will be more correct.
> > >>>>>>>>
> > >>>>>>>> alright, thank you. Let's add Paul to the loop since he might have very
> > >>>>>>>> good insight in the synopsys PHYs.
> > >>>>>>>>
> > >>>>>>>> mental note: if any other platform shows up with Synopsys PHY, ask them
> > >>>>>>>> to use this driver instead :-)
> > >>>>>>>
> > >>>>>>> I really doubt that this will bi possible. Control of the PHY's is
> > >>>>>>> not directly trough ULPI, UTMI or PIPE3 interfaces, but trough
> > >>>>>>> QSCRATCH registers, which of course is highly Qualcomm specific.
> > >>>>>>
> > >>>>>> isn't it a memory mapped IP ? doesn't synopsys provide their own set of
> > >>>>>> registers ?
> > >>>>>
> > >>>>> From what I see it is not directly mapped. How QSCRATCH write and
> > >>>>> reads transactions are translated to DW IP is unclear to me.
> > >>>>
> > >>>>
> > >>>> I think the question is how does SW access them?
> > >>>
> > >>> I afraid the answer may be: "it depends on the SOC". In my past I had to
> > >>> initialize a (SATA) PHY by implementing a software JTAG state machine,
> > >>> as the PHY's registers were not memory mapped *at all*. And the IP
> > >>> itself came from Synopsys, Cadence or yet another EDA company...
> > >>
> > >> Having said all that... If the PHY's spec at least defined layout of the
> > >> registers in question and driver was using regmap API to talk to the
> > >> device (initially regmap-mmio), it has some chances to become universal.
> > >> The SOCs designed like "my" one would have to provide a custom regmap
> > >> implementation.
> > >
> > > Sound reasonable. Unfortunately I don't have PHY's IP spec.
> >
> > Looking into this it appears that the register wrapper around the IP
> > is most likely highly specific to qualcomm as I'm not seeing a
> > register interface around the DWC HS PHY.
>
> Then it's set, we'll go with this driver :-)
>
Does this mean that driver could be merged?
Regards,
Ivan
Hi,
On Tue, Aug 20, 2013 at 12:56:03PM +0300, Ivan T. Ivanov wrote:
> From: "Ivan T. Ivanov" <[email protected]>
>
> MSM USB3.0 core wrapper consist of USB3.0 IP from Synopsys
> (SNPS) and HS, SS PHY's control and configuration registers.
>
> It could operate in device mode (SS, HS, FS) and host
> mode (SS, HS, FS, LS).
>
> Signed-off-by: Ivan T. Ivanov <[email protected]>
Any acks for the DT part ? This patch has been pending forever.
> ---
> .../devicetree/bindings/usb/msm-ssusb.txt | 104 ++++++++++++++++++++
> 1 file changed, 104 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/usb/msm-ssusb.txt
>
> diff --git a/Documentation/devicetree/bindings/usb/msm-ssusb.txt b/Documentation/devicetree/bindings/usb/msm-ssusb.txt
> new file mode 100644
> index 0000000..cacbd3b
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/usb/msm-ssusb.txt
> @@ -0,0 +1,104 @@
> +MSM SuperSpeed DWC3 USB SoC controller
> +
> +
> +DWC3 Highspeed USB PHY
> +======================
> +Required properities :
> +- compatible : sould be "qcom,dwc3-hsphy";
> +- reg : offset and length of the register set in the memory map
> +- clocks : phandles to clock instances of the device tree nodes
> +- clock-names :
> + "xo" : External reference clock 19 MHz
> + "sleep_a" : Sleep clock, used when USB3 core goes into low
> + power mode (U3).
> +<supply-name>-supply : phandle to the regulator device tree node
> +Required "supply-name" are:
> + "v1p8" : 1.8v supply for HSPHY
> + "v3p3" : 3.3v supply for HSPHY
> + "vbus" : vbus supply for host mode
> + "vddcx" : vdd supply for HS-PHY digital circuit operation
> +
> +DWC3 Superspeed USB PHY
> +=======================
> +Required properities :
> +- compatible : sould be "qcom,dwc3-ssphy";
> +- reg : offset and length of the register set in the memory map
> +- clocks : phandles to clock instances of the device tree nodes
> +- clock-names :
> + "xo" : External reference clock 19 MHz
> + "ref" : Reference clock - used in host mode.
> +<supply-name>-supply : phandle to the regulator device tree node
> +Required "supply-name" are:
> + "v1p8" : 1.8v supply for SS-PHY
> + "vddcx" : vdd supply for SS-PHY digital circuit operation
> +
> +DWC3 controller wrapper
> +=======================
> +Required properties :
> +- compatible : should be "qcom,dwc3"
> +- reg : offset and length of the register set in the memory map
> + offset and length of the TCSR register for routing USB
> + signals to either picoPHY0 or picoPHY1.
> +- clocks : phandles to clock instances of the device tree nodes
> +- clock-names :
> + "core" : Master/Core clock, have to be >= 125 MHz for SS
> + operation and >= 60MHz for HS operation
> + "iface" : System bus AXI clock
> + "sleep" : Sleep clock, used when USB3 core goes into low
> + power mode (U3).
> + "utmi" : Generated by HS-PHY. Used to clock the low power
> + parts of thr HS Link layer.
> +Optional properties :
> +- gdsc-supply : phandle to the globally distributed switch controller
> + regulator node to the USB controller.
> +Required child node:
> +A child node must exist to represent the core DWC3 IP block. The name of
> +the node is not important. The content of the node is defined in dwc3.txt.
> +
> +Example device nodes:
> +
> + dwc3_hsphy: phy@f92f8800 {
> + compatible = "qcom,dwc3-hsphy";
> + reg = <0xf92f8800 0x30>;
> +
> + clocks = <&cxo>, <&usb2a_phy_sleep_cxc>;
> + clock-names = "xo", "sleep_a";
> +
> + vbus-supply = <&supply>;
> + vddcx-supply = <&supply>;
> + v1p8-supply = <&supply>;
> + v3p3-supply = <&supply>;
> + };
> +
> + dwc3_ssphy: phy@f92f8830 {
> + compatible = "qcom,dwc3-ssphy";
> + reg = <0xf92f8830 0x30>;
> +
> + clocks = <&cxo>, <&usb30_mock_utmi_cxc>;
> + clock-names = "xo", "ref";
> +
> + vddcx-supply = <&supply>;
> + v1p8-supply = <&supply>;
> + };
> +
> + usb@fd4ab000 {
> + compatible = "qcom,dwc3";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + reg = <0xfd4ab000 0x4>;
> +
> + clocks = <&usb30_master_cxc>, <&sys_noc_usb3_axi_cxc>,
> + <&usb30_sleep_cxc>, <&usb30_mock_utmi_cxc>;
> + clock-names = "core", "iface", "sleep", "utmi";
> +
> + gdsc-supply = <&supply>;
> +
> + ranges;
> + dwc3@f9200000 {
> + compatible = "snps,dwc3";
> + reg = <0xf9200000 0xcd00>;
> + interrupts = <0 131 0>;
> + usb-phy = <&dwc3_hsphy>, <&dwc3_ssphy>;
> + tx-fifo-resize;
> + };
> + };
> --
> 1.7.9.5
>
--
balbi
On Mon, Sep 23, 2013 at 08:31:48PM +0100, Felipe Balbi wrote:
> Hi,
>
> On Tue, Aug 20, 2013 at 12:56:03PM +0300, Ivan T. Ivanov wrote:
> > From: "Ivan T. Ivanov" <[email protected]>
> >
> > MSM USB3.0 core wrapper consist of USB3.0 IP from Synopsys
> > (SNPS) and HS, SS PHY's control and configuration registers.
> >
> > It could operate in device mode (SS, HS, FS) and host
> > mode (SS, HS, FS, LS).
> >
> > Signed-off-by: Ivan T. Ivanov <[email protected]>
>
> Any acks for the DT part ? This patch has been pending forever.
Apologies for the delay. I have a couple of comments that would be nice
to fix up now.
>
> > ---
> > .../devicetree/bindings/usb/msm-ssusb.txt | 104 ++++++++++++++++++++
> > 1 file changed, 104 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/usb/msm-ssusb.txt
> >
> > diff --git a/Documentation/devicetree/bindings/usb/msm-ssusb.txt b/Documentation/devicetree/bindings/usb/msm-ssusb.txt
> > new file mode 100644
> > index 0000000..cacbd3b
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/usb/msm-ssusb.txt
> > @@ -0,0 +1,104 @@
> > +MSM SuperSpeed DWC3 USB SoC controller
> > +
> > +
> > +DWC3 Highspeed USB PHY
> > +======================
> > +Required properities :
> > +- compatible : sould be "qcom,dwc3-hsphy";
s/sould/should/
In general, compatible properties are "should contain" rather than
"should be", as we might have backwards compatible hardware in future.
> > +- reg : offset and length of the register set in the memory map
> > +- clocks : phandles to clock instances of the device tree nodes
Clocks are referred to be phandle + clock-specifier pairs rather than
phandles, it would be nice to fix the terminology here
> > +- clock-names :
> > + "xo" : External reference clock 19 MHz
> > + "sleep_a" : Sleep clock, used when USB3 core goes into low
> > + power mode (U3).
I think it would be nicer to say:
- clocks : A list of phandle + clock-specifier pairs for the clocks
listed in clock-names
- clock-names: Should contain the following:
"xo" - External reference clock (19MHz)
"sleep_a" - Sleep clock used when USB3 core goes into low
power mode (U3).
I'm not sure we need to describe the frequency of the xo clock -- either
it's a requriement of the IP and thus doesn't need to be a part of the
binding, or it's configurable by the driver and thus doesn't need to be
documented.
> > +<supply-name>-supply : phandle to the regulator device tree node
> > +Required "supply-name" are:
> > + "v1p8" : 1.8v supply for HSPHY
> > + "v3p3" : 3.3v supply for HSPHY
> > + "vbus" : vbus supply for host mode
> > + "vddcx" : vdd supply for HS-PHY digital circuit operation
Any reason for the HSPHY/HS-PHY difference?
I'd list these separately with their full names:
- v1p8-supply: phandle to the regulator for the 1.8v supply to HSPHY.
- v3p3-supply: phandle to the regulator for the 3.3v supply to HSPHY.
- vbus-supply: phandle to the regulator for the vbus supply for host
mode.
- vddcx-supply: phandle to the regulator for the vdd supply for HSPHY
digital circuit operation.
> > +
> > +DWC3 Superspeed USB PHY
> > +=======================
> > +Required properities :
> > +- compatible : sould be "qcom,dwc3-ssphy";
> > +- reg : offset and length of the register set in the memory map
> > +- clocks : phandles to clock instances of the device tree nodes
> > +- clock-names :
> > + "xo" : External reference clock 19 MHz
> > + "ref" : Reference clock - used in host mode.
> > +<supply-name>-supply : phandle to the regulator device tree node
> > +Required "supply-name" are:
> > + "v1p8" : 1.8v supply for SS-PHY
> > + "vddcx" : vdd supply for SS-PHY digital circuit operation
The commments on compatible, clocks, clock-names and the regulators
apply here.
> > +
> > +DWC3 controller wrapper
> > +=======================
> > +Required properties :
> > +- compatible : should be "qcom,dwc3"
> > +- reg : offset and length of the register set in the memory map
> > + offset and length of the TCSR register for routing USB
> > + signals to either picoPHY0 or picoPHY1.
> > +- clocks : phandles to clock instances of the device tree nodes
> > +- clock-names :
> > + "core" : Master/Core clock, have to be >= 125 MHz for SS
> > + operation and >= 60MHz for HS operation
> > + "iface" : System bus AXI clock
> > + "sleep" : Sleep clock, used when USB3 core goes into low
> > + power mode (U3).
> > + "utmi" : Generated by HS-PHY. Used to clock the low power
> > + parts of thr HS Link layer.
> > +Optional properties :
> > +- gdsc-supply : phandle to the globally distributed switch controller
> > + regulator node to the USB controller.
The commments on compatible, clocks, and clock-names apply here too. I
see the regulator is defined individually :)
I'm fine with the binding itself, I'd just like the documentation fixed
up.
Cheers,
Mark.
> > +Required child node:
> > +A child node must exist to represent the core DWC3 IP block. The name of
> > +the node is not important. The content of the node is defined in dwc3.txt.
> > +
> > +Example device nodes:
> > +
> > + dwc3_hsphy: phy@f92f8800 {
> > + compatible = "qcom,dwc3-hsphy";
> > + reg = <0xf92f8800 0x30>;
> > +
> > + clocks = <&cxo>, <&usb2a_phy_sleep_cxc>;
> > + clock-names = "xo", "sleep_a";
> > +
> > + vbus-supply = <&supply>;
> > + vddcx-supply = <&supply>;
> > + v1p8-supply = <&supply>;
> > + v3p3-supply = <&supply>;
> > + };
> > +
> > + dwc3_ssphy: phy@f92f8830 {
> > + compatible = "qcom,dwc3-ssphy";
> > + reg = <0xf92f8830 0x30>;
> > +
> > + clocks = <&cxo>, <&usb30_mock_utmi_cxc>;
> > + clock-names = "xo", "ref";
> > +
> > + vddcx-supply = <&supply>;
> > + v1p8-supply = <&supply>;
> > + };
> > +
> > + usb@fd4ab000 {
> > + compatible = "qcom,dwc3";
> > + #address-cells = <1>;
> > + #size-cells = <1>;
> > + reg = <0xfd4ab000 0x4>;
> > +
> > + clocks = <&usb30_master_cxc>, <&sys_noc_usb3_axi_cxc>,
> > + <&usb30_sleep_cxc>, <&usb30_mock_utmi_cxc>;
> > + clock-names = "core", "iface", "sleep", "utmi";
> > +
> > + gdsc-supply = <&supply>;
> > +
> > + ranges;
> > + dwc3@f9200000 {
> > + compatible = "snps,dwc3";
> > + reg = <0xf9200000 0xcd00>;
> > + interrupts = <0 131 0>;
> > + usb-phy = <&dwc3_hsphy>, <&dwc3_ssphy>;
> > + tx-fifo-resize;
> > + };
> > + };
> > --
> > 1.7.9.5
> >
>
> --
> balbi
Hi, I am sorry for delay answer.
On Thu, 2013-09-26 at 10:46 +0100, Mark Rutland wrote:
> On Mon, Sep 23, 2013 at 08:31:48PM +0100, Felipe Balbi wrote:
> > Hi,
> >
> > On Tue, Aug 20, 2013 at 12:56:03PM +0300, Ivan T. Ivanov wrote:
> > > From: "Ivan T. Ivanov" <[email protected]>
> > >
> > > MSM USB3.0 core wrapper consist of USB3.0 IP from Synopsys
> > > (SNPS) and HS, SS PHY's control and configuration registers.
> > >
> > > It could operate in device mode (SS, HS, FS) and host
> > > mode (SS, HS, FS, LS).
> > >
> > > Signed-off-by: Ivan T. Ivanov <[email protected]>
> >
> > Any acks for the DT part ? This patch has been pending forever.
>
> Apologies for the delay. I have a couple of comments that would be nice
> to fix up now.
>
> >
> > > ---
> > > .../devicetree/bindings/usb/msm-ssusb.txt | 104 ++++++++++++++++++++
> > > 1 file changed, 104 insertions(+)
> > > create mode 100644 Documentation/devicetree/bindings/usb/msm-ssusb.txt
> > >
> > > diff --git a/Documentation/devicetree/bindings/usb/msm-ssusb.txt b/Documentation/devicetree/bindings/usb/msm-ssusb.txt
> > > new file mode 100644
> > > index 0000000..cacbd3b
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/usb/msm-ssusb.txt
> > > @@ -0,0 +1,104 @@
> > > +MSM SuperSpeed DWC3 USB SoC controller
> > > +
> > > +
> > > +DWC3 Highspeed USB PHY
> > > +======================
> > > +Required properities :
> > > +- compatible : sould be "qcom,dwc3-hsphy";
>
> s/sould/should/
>
> In general, compatible properties are "should contain" rather than
> "should be", as we might have backwards compatible hardware in future.
Ok.
>
> > > +- reg : offset and length of the register set in the memory map
> > > +- clocks : phandles to clock instances of the device tree nodes
>
> Clocks are referred to be phandle + clock-specifier pairs rather than
> phandles, it would be nice to fix the terminology here
Ok.
>
> > > +- clock-names :
> > > + "xo" : External reference clock 19 MHz
> > > + "sleep_a" : Sleep clock, used when USB3 core goes into low
> > > + power mode (U3).
>
> I think it would be nicer to say:
> - clocks : A list of phandle + clock-specifier pairs for the clocks
> listed in clock-names
> - clock-names: Should contain the following:
> "xo" - External reference clock (19MHz)
> "sleep_a" - Sleep clock used when USB3 core goes into low
> power mode (U3).
>
> I'm not sure we need to describe the frequency of the xo clock -- either
> it's a requriement of the IP and thus doesn't need to be a part of the
> binding, or it's configurable by the driver and thus doesn't need to be
> documented.
Ok. will remove explicit numbers here.
>
> > > +<supply-name>-supply : phandle to the regulator device tree node
> > > +Required "supply-name" are:
> > > + "v1p8" : 1.8v supply for HSPHY
> > > + "v3p3" : 3.3v supply for HSPHY
> > > + "vbus" : vbus supply for host mode
> > > + "vddcx" : vdd supply for HS-PHY digital circuit operation
>
> Any reason for the HSPHY/HS-PHY difference?
No, just lack of attention from my side.
>
> I'd list these separately with their full names:
>
> - v1p8-supply: phandle to the regulator for the 1.8v supply to HSPHY.
> - v3p3-supply: phandle to the regulator for the 3.3v supply to HSPHY.
> - vbus-supply: phandle to the regulator for the vbus supply for host
> mode.
> - vddcx-supply: phandle to the regulator for the vdd supply for HSPHY
> digital circuit operation.
>
ok.
> > > +
> > > +DWC3 Superspeed USB PHY
> > > +=======================
> > > +Required properities :
> > > +- compatible : sould be "qcom,dwc3-ssphy";
> > > +- reg : offset and length of the register set in the memory map
> > > +- clocks : phandles to clock instances of the device tree nodes
> > > +- clock-names :
> > > + "xo" : External reference clock 19 MHz
> > > + "ref" : Reference clock - used in host mode.
> > > +<supply-name>-supply : phandle to the regulator device tree node
> > > +Required "supply-name" are:
> > > + "v1p8" : 1.8v supply for SS-PHY
> > > + "vddcx" : vdd supply for SS-PHY digital circuit operation
>
> The commments on compatible, clocks, clock-names and the regulators
> apply here.
ok
>
> > > +
> > > +DWC3 controller wrapper
> > > +=======================
> > > +Required properties :
> > > +- compatible : should be "qcom,dwc3"
> > > +- reg : offset and length of the register set in the memory map
> > > + offset and length of the TCSR register for routing USB
> > > + signals to either picoPHY0 or picoPHY1.
> > > +- clocks : phandles to clock instances of the device tree nodes
> > > +- clock-names :
> > > + "core" : Master/Core clock, have to be >= 125 MHz for SS
> > > + operation and >= 60MHz for HS operation
> > > + "iface" : System bus AXI clock
> > > + "sleep" : Sleep clock, used when USB3 core goes into low
> > > + power mode (U3).
> > > + "utmi" : Generated by HS-PHY. Used to clock the low power
> > > + parts of thr HS Link layer.
> > > +Optional properties :
> > > +- gdsc-supply : phandle to the globally distributed switch controller
> > > + regulator node to the USB controller.
>
> The commments on compatible, clocks, and clock-names apply here too. I
> see the regulator is defined individually :)
>
> I'm fine with the binding itself, I'd just like the documentation fixed
> up.
>
Thanks,
Ivan
> Cheers,
> Mark.
>
> > > +Required child node:
> > > +A child node must exist to represent the core DWC3 IP block. The name of
> > > +the node is not important. The content of the node is defined in dwc3.txt.
> > > +
> > > +Example device nodes:
> > > +
> > > + dwc3_hsphy: phy@f92f8800 {
> > > + compatible = "qcom,dwc3-hsphy";
> > > + reg = <0xf92f8800 0x30>;
> > > +
> > > + clocks = <&cxo>, <&usb2a_phy_sleep_cxc>;
> > > + clock-names = "xo", "sleep_a";
> > > +
> > > + vbus-supply = <&supply>;
> > > + vddcx-supply = <&supply>;
> > > + v1p8-supply = <&supply>;
> > > + v3p3-supply = <&supply>;
> > > + };
> > > +
> > > + dwc3_ssphy: phy@f92f8830 {
> > > + compatible = "qcom,dwc3-ssphy";
> > > + reg = <0xf92f8830 0x30>;
> > > +
> > > + clocks = <&cxo>, <&usb30_mock_utmi_cxc>;
> > > + clock-names = "xo", "ref";
> > > +
> > > + vddcx-supply = <&supply>;
> > > + v1p8-supply = <&supply>;
> > > + };
> > > +
> > > + usb@fd4ab000 {
> > > + compatible = "qcom,dwc3";
> > > + #address-cells = <1>;
> > > + #size-cells = <1>;
> > > + reg = <0xfd4ab000 0x4>;
> > > +
> > > + clocks = <&usb30_master_cxc>, <&sys_noc_usb3_axi_cxc>,
> > > + <&usb30_sleep_cxc>, <&usb30_mock_utmi_cxc>;
> > > + clock-names = "core", "iface", "sleep", "utmi";
> > > +
> > > + gdsc-supply = <&supply>;
> > > +
> > > + ranges;
> > > + dwc3@f9200000 {
> > > + compatible = "snps,dwc3";
> > > + reg = <0xf9200000 0xcd00>;
> > > + interrupts = <0 131 0>;
> > > + usb-phy = <&dwc3_hsphy>, <&dwc3_ssphy>;
> > > + tx-fifo-resize;
> > > + };
> > > + };
> > > --
> > > 1.7.9.5
> > >
> >
> > --
> > balbi
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi,
On Mon, 2013-09-23 at 14:31 -0500, Felipe Balbi wrote:
> Hi,
>
> On Tue, Aug 20, 2013 at 12:56:03PM +0300, Ivan T. Ivanov wrote:
> > From: "Ivan T. Ivanov" <[email protected]>
> >
> > MSM USB3.0 core wrapper consist of USB3.0 IP from Synopsys
> > (SNPS) and HS, SS PHY's control and configuration registers.
> >
> > It could operate in device mode (SS, HS, FS) and host
> > mode (SS, HS, FS, LS).
> >
> > Signed-off-by: Ivan T. Ivanov <[email protected]>
>
> Any acks for the DT part ? This patch has been pending forever.
Thanks you for you patience Felipe. There are also several small
fixups in the driver code that I will like to address. Will send
updated version with all pending comments shortly.
Regards,
Ivan