2018-11-27 10:08:57

by Shawn Guo

[permalink] [raw]
Subject: [PATCH v5 0/2] Add Synopsys High-Speed USB PHY driver for Qualcomm SoCs

It's based on a downstream driver from Sriharsha Allenki <[email protected]>
that uses USB phy framework, and gets rewrote to adpot generic phy
framework together with quite some cleanups.

Changes for v5:
- Drop mb() call from function qcom_snps_hsphy_init_sequence() and
qcom_snps_hsphy_por_reset().

Changes for v4:
- Kill device tree property 'qcom,init-seq' by moving the settings
into phy driver as device match data.

Changes for v3:
- Use SoC specific compatible "qcom,qcs404-usb-hsphy".
- Use OF graph instead of extcon bindings to model the link to USB
connector.

Changes for v2:
- Add a pointer to phy/phy-bindings.txt for property #phy-cells.
- Roll back voltage settings in case function
qcom_snps_hsphy_config_regulators() fails in the middle.
- Add a comment for init-seq tuple which consists of 3 numbers.
- Sort include headers alphabetically.
- Sort register definitions in order of offset.

Shawn Guo (1):
phy: qualcomm: Add Synopsys High-Speed USB PHY driver

Sriharsha Allenki (1):
dt-bindings: phy: Add Qualcomm Synopsys High-Speed USB PHY binding

.../phy/qcom,snps-28nm-usb-hs-phy.txt | 87 +++
drivers/phy/qualcomm/Kconfig | 10 +
drivers/phy/qualcomm/Makefile | 1 +
.../phy/qualcomm/phy-qcom-usb-hs-snsp-28nm.c | 529 ++++++++++++++++++
4 files changed, 627 insertions(+)
create mode 100644 Documentation/devicetree/bindings/phy/qcom,snps-28nm-usb-hs-phy.txt
create mode 100644 drivers/phy/qualcomm/phy-qcom-usb-hs-snsp-28nm.c

--
2.18.0



2018-11-27 10:09:02

by Shawn Guo

[permalink] [raw]
Subject: [PATCH v5 1/2] dt-bindings: phy: Add Qualcomm Synopsys High-Speed USB PHY binding

From: Sriharsha Allenki <[email protected]>

It adds bindings for Synopsys 28nm femto phy controller that supports
LS/FS/HS usb connectivity on Qualcomm chipsets.

Signed-off-by: Sriharsha Allenki <[email protected]>
Signed-off-by: Anu Ramanathan <[email protected]>
Signed-off-by: Bjorn Andersson <[email protected]>
Reviewed-by: Rob Herring <[email protected]>
Signed-off-by: Shawn Guo <[email protected]>
---
.../phy/qcom,snps-28nm-usb-hs-phy.txt | 87 +++++++++++++++++++
1 file changed, 87 insertions(+)
create mode 100644 Documentation/devicetree/bindings/phy/qcom,snps-28nm-usb-hs-phy.txt

diff --git a/Documentation/devicetree/bindings/phy/qcom,snps-28nm-usb-hs-phy.txt b/Documentation/devicetree/bindings/phy/qcom,snps-28nm-usb-hs-phy.txt
new file mode 100644
index 000000000000..301987e716fd
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/qcom,snps-28nm-usb-hs-phy.txt
@@ -0,0 +1,87 @@
+Qualcomm Synopsys 28nm Femto phy controller
+===========================================
+
+Synopsys 28nm femto phy controller supports LS/FS/HS usb connectivity on
+Qualcomm chipsets.
+
+Required properties:
+
+- compatible:
+ Value type: <string>
+ Definition: Should contain "qcom,qcs404-usb-hsphy".
+
+- reg:
+ Value type: <prop-encoded-array>
+ Definition: USB PHY base address and length of the register map.
+
+- #phy-cells:
+ Value type: <u32>
+ Definition: Should be 0. See phy/phy-bindings.txt for details.
+
+- clocks:
+ Value type: <prop-encoded-array>
+ Definition: See clock-bindings.txt section "consumers". List of
+ three clock specifiers for reference, phy core and
+ sleep clocks.
+
+- clock-names:
+ Value type: <string>
+ Definition: Names of the clocks in 1-1 correspondence with the "clocks"
+ property. Must contain "ref", "phy" and "sleep".
+
+- resets:
+ Value type: <prop-encoded-array>
+ Definition: See reset.txt section "consumers". PHY reset specifiers
+ for phy core and POR resets.
+
+- reset-names:
+ Value type: <string>
+ Definition: Names of the resets in 1-1 correspondence with the "resets"
+ property. Must contain "phy" and "por".
+
+- vdd-supply:
+ Value type: <phandle>
+ Definition: phandle to the regulator VDD supply node.
+
+- vdda1p8-supply:
+ Value type: <phandle>
+ Definition: phandle to the regulator 1.8V supply node.
+
+- vdda3p3-supply:
+ Value type: <phandle>
+ Definition: phandle to the regulator 3.3V supply node.
+
+- qcom,vdd-voltage-level:
+ Value type: <prop-array>
+ Definition: This is a list of three integer values <no min max> where
+ each value corresponding to voltage corner in uV.
+
+Optional child nodes:
+
+- The link to the USB connector should be modeled using the OF graph bindings
+ specified in bindings/graph.txt.
+
+Example:
+
+ phy@7a000 {
+ compatible = "qcom,qcs404-usb-hsphy";
+ reg = <0x7a000 0x200>;
+ #phy-cells = <0>;
+ clocks = <&rpmcc RPM_SMD_LN_BB_CLK>,
+ <&gcc GCC_USB_HS_PHY_CFG_AHB_CLK>,
+ <&gcc GCC_USB2A_PHY_SLEEP_CLK>;
+ clock-names = "ref", "phy", "sleep";
+ resets = <&gcc GCC_USB_HS_PHY_CFG_AHB_BCR>,
+ <&gcc GCC_USB2A_PHY_BCR>;
+ reset-names = "phy", "por";
+ vdd-supply = <&vreg_l4_1p2>;
+ vdda1p8-supply = <&vreg_l5_1p8>;
+ vdda3p3-supply = <&vreg_l12_3p3>;
+ qcom,vdd-voltage-level = <0 1144000 1200000>;
+
+ port {
+ ep_usb_phy: endpoint {
+ remote-endpoint = <&ep_usb_con>;
+ };
+ };
+ };
--
2.18.0


2018-11-27 10:10:24

by Shawn Guo

[permalink] [raw]
Subject: [PATCH v5 2/2] phy: qualcomm: Add Synopsys High-Speed USB PHY driver

It adds Synopsys 28nm Femto High-Speed USB PHY driver support, which
is usually paired with Synopsys DWC3 USB controllers on Qualcomm SoCs.

Signed-off-by: Shawn Guo <[email protected]>
---
drivers/phy/qualcomm/Kconfig | 10 +
drivers/phy/qualcomm/Makefile | 1 +
.../phy/qualcomm/phy-qcom-usb-hs-snsp-28nm.c | 529 ++++++++++++++++++
3 files changed, 540 insertions(+)
create mode 100644 drivers/phy/qualcomm/phy-qcom-usb-hs-snsp-28nm.c

diff --git a/drivers/phy/qualcomm/Kconfig b/drivers/phy/qualcomm/Kconfig
index 32f7d34eb784..c7b5ee82895d 100644
--- a/drivers/phy/qualcomm/Kconfig
+++ b/drivers/phy/qualcomm/Kconfig
@@ -82,3 +82,13 @@ config PHY_QCOM_USB_HSIC
select GENERIC_PHY
help
Support for the USB HSIC ULPI compliant PHY on QCOM chipsets.
+
+config PHY_QCOM_USB_HS_SNPS_28NM
+ tristate "Qualcomm Synopsys 28nm USB HS PHY driver"
+ depends on ARCH_QCOM || COMPILE_TEST
+ depends on EXTCON || !EXTCON # if EXTCON=m, this cannot be built-in
+ select GENERIC_PHY
+ help
+ Enable this to support the Synopsys 28nm Femto USB PHY on Qualcomm
+ chips. This driver supports the high-speed PHY which is usually
+ paired with either the ChipIdea or Synopsys DWC3 USB IPs on MSM SOCs.
diff --git a/drivers/phy/qualcomm/Makefile b/drivers/phy/qualcomm/Makefile
index c56efd3af205..dc238d95b18c 100644
--- a/drivers/phy/qualcomm/Makefile
+++ b/drivers/phy/qualcomm/Makefile
@@ -9,3 +9,4 @@ obj-$(CONFIG_PHY_QCOM_UFS_14NM) += phy-qcom-ufs-qmp-14nm.o
obj-$(CONFIG_PHY_QCOM_UFS_20NM) += phy-qcom-ufs-qmp-20nm.o
obj-$(CONFIG_PHY_QCOM_USB_HS) += phy-qcom-usb-hs.o
obj-$(CONFIG_PHY_QCOM_USB_HSIC) += phy-qcom-usb-hsic.o
+obj-$(CONFIG_PHY_QCOM_USB_HS_SNPS_28NM) += phy-qcom-usb-hs-snsp-28nm.o
diff --git a/drivers/phy/qualcomm/phy-qcom-usb-hs-snsp-28nm.c b/drivers/phy/qualcomm/phy-qcom-usb-hs-snsp-28nm.c
new file mode 100644
index 000000000000..1fa364417237
--- /dev/null
+++ b/drivers/phy/qualcomm/phy-qcom-usb-hs-snsp-28nm.c
@@ -0,0 +1,529 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2009-2018, Linux Foundation. All rights reserved.
+ * Copyright (c) 2018, Linaro Limited
+ */
+
+#include <linux/clk.h>
+#include <linux/delay.h>
+#include <linux/extcon.h>
+#include <linux/io.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/notifier.h>
+#include <linux/of.h>
+#include <linux/of_graph.h>
+#include <linux/phy/phy.h>
+#include <linux/platform_device.h>
+#include <linux/regulator/consumer.h>
+#include <linux/reset.h>
+#include <linux/slab.h>
+
+/* PHY register and bit definitions */
+#define PHY_CTRL_COMMON0 0x078
+#define SIDDQ BIT(2)
+#define PHY_IRQ_CMD 0x0d0
+#define PHY_INTR_MASK0 0x0d4
+#define PHY_INTR_CLEAR0 0x0dc
+#define DPDM_MASK 0x1e
+#define DP_1_0 BIT(4)
+#define DP_0_1 BIT(3)
+#define DM_1_0 BIT(2)
+#define DM_0_1 BIT(1)
+
+enum hsphy_voltage {
+ VOL_NONE,
+ VOL_MIN,
+ VOL_MAX,
+ VOL_NUM,
+};
+
+enum hsphy_vreg {
+ VDD,
+ VDDA_1P8,
+ VDDA_3P3,
+ VREG_NUM,
+};
+
+struct hsphy_init_seq {
+ int offset;
+ int val;
+ int delay;
+};
+
+struct hsphy_data {
+ const struct hsphy_init_seq *init_seq;
+ unsigned int init_seq_num;
+};
+
+struct hsphy_priv {
+ void __iomem *base;
+ struct clk_bulk_data *clks;
+ int num_clks;
+ struct reset_control *phy_reset;
+ struct reset_control *por_reset;
+ struct regulator_bulk_data vregs[VREG_NUM];
+ unsigned int voltages[VREG_NUM][VOL_NUM];
+ const struct hsphy_data *data;
+ bool cable_connected;
+ struct extcon_dev *vbus_edev;
+ struct notifier_block vbus_notify;
+ enum phy_mode mode;
+};
+
+static int qcom_snps_hsphy_config_regulators(struct hsphy_priv *priv, int high)
+{
+ int old_uV[VREG_NUM];
+ int min, ret, i;
+
+ min = high ? 1 : 0; /* low or none? */
+
+ for (i = 0; i < VREG_NUM; i++) {
+ old_uV[i] = regulator_get_voltage(priv->vregs[i].consumer);
+ ret = regulator_set_voltage(priv->vregs[i].consumer,
+ priv->voltages[i][min],
+ priv->voltages[i][VOL_MAX]);
+ if (ret)
+ goto roll_back;
+ }
+
+ return 0;
+
+roll_back:
+ for (; i >= 0; i--)
+ regulator_set_voltage(priv->vregs[i].consumer,
+ old_uV[i], old_uV[i]);
+ return ret;
+}
+
+static int qcom_snps_hsphy_enable_regulators(struct hsphy_priv *priv)
+{
+ int ret;
+
+ ret = qcom_snps_hsphy_config_regulators(priv, 1);
+ if (ret)
+ return ret;
+
+ ret = regulator_set_load(priv->vregs[VDDA_1P8].consumer, 19000);
+ if (ret < 0)
+ goto unconfig_regulators;
+
+ ret = regulator_set_load(priv->vregs[VDDA_3P3].consumer, 16000);
+ if (ret < 0)
+ goto unset_1p8_load;
+
+ ret = regulator_bulk_enable(VREG_NUM, priv->vregs);
+ if (ret)
+ goto unset_3p3_load;
+
+ return 0;
+
+unset_3p3_load:
+ regulator_set_load(priv->vregs[VDDA_3P3].consumer, 0);
+unset_1p8_load:
+ regulator_set_load(priv->vregs[VDDA_1P8].consumer, 0);
+unconfig_regulators:
+ qcom_snps_hsphy_config_regulators(priv, 0);
+ return ret;
+}
+
+static void qcom_snps_hsphy_disable_regulators(struct hsphy_priv *priv)
+{
+ regulator_bulk_disable(VREG_NUM, priv->vregs);
+ regulator_set_load(priv->vregs[VDDA_1P8].consumer, 0);
+ regulator_set_load(priv->vregs[VDDA_3P3].consumer, 0);
+ qcom_snps_hsphy_config_regulators(priv, 0);
+}
+
+static int qcom_snps_hsphy_set_mode(struct phy *phy, enum phy_mode mode)
+{
+ struct hsphy_priv *priv = phy_get_drvdata(phy);
+
+ priv->mode = mode;
+
+ return 0;
+}
+
+static void qcom_snps_hsphy_enable_hv_interrupts(struct hsphy_priv *priv)
+{
+ u32 val;
+
+ /* Clear any existing interrupts before enabling the interrupts */
+ val = readb(priv->base + PHY_INTR_CLEAR0);
+ val |= DPDM_MASK;
+ writeb(val, priv->base + PHY_INTR_CLEAR0);
+
+ writeb(0x0, priv->base + PHY_IRQ_CMD);
+ usleep_range(200, 220);
+ writeb(0x1, priv->base + PHY_IRQ_CMD);
+
+ /* Make sure the interrupts are cleared */
+ usleep_range(200, 220);
+
+ val = readb(priv->base + PHY_INTR_MASK0);
+ switch (priv->mode) {
+ case PHY_MODE_USB_HOST_HS:
+ case PHY_MODE_USB_HOST_FS:
+ case PHY_MODE_USB_DEVICE_HS:
+ case PHY_MODE_USB_DEVICE_FS:
+ val |= DP_1_0 | DM_0_1;
+ break;
+ case PHY_MODE_USB_HOST_LS:
+ case PHY_MODE_USB_DEVICE_LS:
+ val |= DP_0_1 | DM_1_0;
+ break;
+ default:
+ /* No device connected */
+ val |= DP_0_1 | DM_0_1;
+ break;
+ }
+ writeb(val, priv->base + PHY_INTR_MASK0);
+}
+
+static void qcom_snps_hsphy_disable_hv_interrupts(struct hsphy_priv *priv)
+{
+ u32 val;
+
+ val = readb(priv->base + PHY_INTR_MASK0);
+ val &= ~DPDM_MASK;
+ writeb(val, priv->base + PHY_INTR_MASK0);
+
+ /* Clear any pending interrupts */
+ val = readb(priv->base + PHY_INTR_CLEAR0);
+ val |= DPDM_MASK;
+ writeb(val, priv->base + PHY_INTR_CLEAR0);
+
+ writeb(0x0, priv->base + PHY_IRQ_CMD);
+ usleep_range(200, 220);
+
+ writeb(0x1, priv->base + PHY_IRQ_CMD);
+ usleep_range(200, 220);
+}
+
+static void qcom_snps_hsphy_enter_retention(struct hsphy_priv *priv)
+{
+ u32 val;
+
+ val = readb(priv->base + PHY_CTRL_COMMON0);
+ val |= SIDDQ;
+ writeb(val, priv->base + PHY_CTRL_COMMON0);
+}
+
+static void qcom_snps_hsphy_exit_retention(struct hsphy_priv *priv)
+{
+ u32 val;
+
+ val = readb(priv->base + PHY_CTRL_COMMON0);
+ val &= ~SIDDQ;
+ writeb(val, priv->base + PHY_CTRL_COMMON0);
+}
+
+static int qcom_snps_hsphy_vbus_notifier(struct notifier_block *nb,
+ unsigned long event, void *ptr)
+{
+ struct hsphy_priv *priv = container_of(nb, struct hsphy_priv,
+ vbus_notify);
+ priv->cable_connected = !!event;
+ return 0;
+}
+
+static int qcom_snps_hsphy_power_on(struct phy *phy)
+{
+ struct hsphy_priv *priv = phy_get_drvdata(phy);
+ int ret;
+
+ if (priv->cable_connected) {
+ ret = clk_bulk_prepare_enable(priv->num_clks, priv->clks);
+ if (ret)
+ return ret;
+ qcom_snps_hsphy_disable_hv_interrupts(priv);
+ } else {
+ ret = qcom_snps_hsphy_enable_regulators(priv);
+ if (ret)
+ return ret;
+ ret = clk_bulk_prepare_enable(priv->num_clks, priv->clks);
+ if (ret)
+ return ret;
+ qcom_snps_hsphy_exit_retention(priv);
+ }
+
+ return 0;
+}
+
+static int qcom_snps_hsphy_power_off(struct phy *phy)
+{
+ struct hsphy_priv *priv = phy_get_drvdata(phy);
+
+ if (priv->cable_connected) {
+ qcom_snps_hsphy_enable_hv_interrupts(priv);
+ clk_bulk_disable_unprepare(priv->num_clks, priv->clks);
+ } else {
+ qcom_snps_hsphy_enter_retention(priv);
+ clk_bulk_disable_unprepare(priv->num_clks, priv->clks);
+ qcom_snps_hsphy_disable_regulators(priv);
+ }
+
+ return 0;
+}
+
+static int qcom_snps_hsphy_reset(struct hsphy_priv *priv)
+{
+ int ret;
+
+ ret = reset_control_assert(priv->phy_reset);
+ if (ret)
+ return ret;
+
+ usleep_range(10, 15);
+
+ ret = reset_control_deassert(priv->phy_reset);
+ if (ret)
+ return ret;
+
+ usleep_range(80, 100);
+
+ return 0;
+}
+
+static void qcom_snps_hsphy_init_sequence(struct hsphy_priv *priv)
+{
+ const struct hsphy_data *data = priv->data;
+ const struct hsphy_init_seq *seq;
+ int i;
+
+ /* Device match data is optional. */
+ if (!data)
+ return;
+
+ seq = data->init_seq;
+
+ for (i = 0; i < data->init_seq_num; i++, seq++) {
+ writeb(seq->val, priv->base + seq->offset);
+ if (seq->delay)
+ usleep_range(seq->delay, seq->delay + 10);
+ }
+}
+
+static int qcom_snps_hsphy_por_reset(struct hsphy_priv *priv)
+{
+ int ret;
+
+ ret = reset_control_assert(priv->por_reset);
+ if (ret)
+ return ret;
+
+ /*
+ * The Femto PHY is POR reset in the following scenarios.
+ *
+ * 1. After overriding the parameter registers.
+ * 2. Low power mode exit from PHY retention.
+ *
+ * Ensure that SIDDQ is cleared before bringing the PHY
+ * out of reset.
+ */
+ qcom_snps_hsphy_exit_retention(priv);
+
+ /*
+ * As per databook, 10 usec delay is required between
+ * PHY POR assert and de-assert.
+ */
+ usleep_range(10, 20);
+ ret = reset_control_deassert(priv->por_reset);
+ if (ret)
+ return ret;
+
+ /*
+ * As per databook, it takes 75 usec for PHY to stabilize
+ * after the reset.
+ */
+ usleep_range(80, 100);
+
+ return 0;
+}
+
+static int qcom_snps_hsphy_init(struct phy *phy)
+{
+ struct hsphy_priv *priv = phy_get_drvdata(phy);
+ int state;
+ int ret;
+
+ ret = qcom_snps_hsphy_reset(priv);
+ if (ret)
+ return ret;
+
+ qcom_snps_hsphy_init_sequence(priv);
+
+ ret = qcom_snps_hsphy_por_reset(priv);
+ if (ret)
+ return ret;
+
+ /* Setup initial state */
+ if (priv->vbus_edev) {
+ state = extcon_get_state(priv->vbus_edev, EXTCON_USB);
+ ret = qcom_snps_hsphy_vbus_notifier(&priv->vbus_notify, state,
+ priv->vbus_edev);
+ if (ret)
+ return ret;
+ }
+
+ return 0;
+}
+
+static const struct phy_ops qcom_snps_hsphy_ops = {
+ .init = qcom_snps_hsphy_init,
+ .power_on = qcom_snps_hsphy_power_on,
+ .power_off = qcom_snps_hsphy_power_off,
+ .set_mode = qcom_snps_hsphy_set_mode,
+ .owner = THIS_MODULE,
+};
+
+static const char * const qcom_snps_hsphy_clks[] = {
+ "ref",
+ "phy",
+ "sleep",
+};
+
+static int qcom_snps_hsphy_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct device_node *extcon_node;
+ struct phy_provider *provider;
+ struct hsphy_priv *priv;
+ struct resource *res;
+ struct phy *phy;
+ int ret;
+ int i;
+
+ priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
+ if (!priv)
+ return -ENOMEM;
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ priv->base = devm_ioremap_resource(dev, res);
+ if (IS_ERR(priv->base))
+ return PTR_ERR(priv->base);
+
+ priv->num_clks = ARRAY_SIZE(qcom_snps_hsphy_clks);
+ priv->clks = devm_kcalloc(dev, priv->num_clks, sizeof(*priv->clks),
+ GFP_KERNEL);
+ if (!priv->clks)
+ return -ENOMEM;
+
+ for (i = 0; i < priv->num_clks; i++)
+ priv->clks[i].id = qcom_snps_hsphy_clks[i];
+
+ ret = devm_clk_bulk_get(dev, priv->num_clks, priv->clks);
+ if (ret)
+ return ret;
+
+ priv->phy_reset = devm_reset_control_get(dev, "phy");
+ if (IS_ERR(priv->phy_reset))
+ return PTR_ERR(priv->phy_reset);
+
+ priv->por_reset = devm_reset_control_get(dev, "por");
+ if (IS_ERR(priv->por_reset))
+ return PTR_ERR(priv->por_reset);
+
+ priv->vregs[VDD].supply = "vdd";
+ priv->vregs[VDDA_1P8].supply = "vdda1p8";
+ priv->vregs[VDDA_3P3].supply = "vdda3p3";
+
+ ret = devm_regulator_bulk_get(dev, VREG_NUM, priv->vregs);
+ if (ret)
+ return ret;
+
+ priv->voltages[VDDA_1P8][VOL_NONE] = 0;
+ priv->voltages[VDDA_1P8][VOL_MIN] = 1800000;
+ priv->voltages[VDDA_1P8][VOL_MAX] = 1800000;
+
+ priv->voltages[VDDA_3P3][VOL_NONE] = 0;
+ priv->voltages[VDDA_3P3][VOL_MIN] = 3050000;
+ priv->voltages[VDDA_3P3][VOL_MAX] = 3300000;
+
+ ret = of_property_read_u32_array(dev->of_node, "qcom,vdd-voltage-level",
+ priv->voltages[VDD], VOL_NUM);
+ if (ret) {
+ dev_err(dev, "failed to read qcom,vdd-voltage-level\n");
+ return ret;
+ }
+
+ extcon_node = of_graph_get_remote_node(dev->of_node, -1, -1);
+ if (extcon_node) {
+ priv->vbus_edev = extcon_find_edev_by_node(extcon_node);
+ if (IS_ERR(priv->vbus_edev)) {
+ if (PTR_ERR(priv->vbus_edev) != -ENODEV) {
+ of_node_put(extcon_node);
+ return PTR_ERR(priv->vbus_edev);
+ }
+ priv->vbus_edev = NULL;
+ }
+ }
+ of_node_put(extcon_node);
+
+ if (priv->vbus_edev) {
+ priv->vbus_notify.notifier_call = qcom_snps_hsphy_vbus_notifier;
+ ret = devm_extcon_register_notifier(dev, priv->vbus_edev,
+ EXTCON_USB,
+ &priv->vbus_notify);
+ if (ret)
+ return ret;
+ }
+
+ /* Get device match data */
+ priv->data = device_get_match_data(dev);
+
+ phy = devm_phy_create(dev, dev->of_node, &qcom_snps_hsphy_ops);
+ if (IS_ERR(phy))
+ return PTR_ERR(phy);
+
+ phy_set_drvdata(phy, priv);
+
+ provider = devm_of_phy_provider_register(dev, of_phy_simple_xlate);
+ return PTR_ERR_OR_ZERO(provider);
+}
+
+/*
+ * The macro is used to define an initialization sequence. Each tuple
+ * is meant to program 'value' into phy register at 'offset' with 'delay'
+ * in us followed.
+ */
+#define HSPHY_INIT_CFG(o, v, d) { .offset = o, .val = v, .delay = d, }
+
+static const struct hsphy_init_seq init_seq_qcs404[] = {
+ HSPHY_INIT_CFG(0xc0, 0x01, 0),
+ HSPHY_INIT_CFG(0xe8, 0x0d, 0),
+ HSPHY_INIT_CFG(0x74, 0x12, 0),
+ HSPHY_INIT_CFG(0x98, 0x63, 0),
+ HSPHY_INIT_CFG(0x9c, 0x03, 0),
+ HSPHY_INIT_CFG(0xa0, 0x1d, 0),
+ HSPHY_INIT_CFG(0xa4, 0x03, 0),
+ HSPHY_INIT_CFG(0x8c, 0x23, 0),
+ HSPHY_INIT_CFG(0x78, 0x08, 0),
+ HSPHY_INIT_CFG(0x7c, 0xdc, 0),
+ HSPHY_INIT_CFG(0x90, 0xe0, 20),
+ HSPHY_INIT_CFG(0x74, 0x10, 0),
+ HSPHY_INIT_CFG(0x90, 0x60, 0),
+};
+
+static const struct hsphy_data hsphy_data_qcs404 = {
+ .init_seq = init_seq_qcs404,
+ .init_seq_num = ARRAY_SIZE(init_seq_qcs404),
+};
+
+static const struct of_device_id qcom_snps_hsphy_match[] = {
+ { .compatible = "qcom,qcs404-usb-hsphy", .data = &hsphy_data_qcs404, },
+ { },
+};
+MODULE_DEVICE_TABLE(of, qcom_snps_hsphy_match);
+
+static struct platform_driver qcom_snps_hsphy_driver = {
+ .probe = qcom_snps_hsphy_probe,
+ .driver = {
+ .name = "qcom-usb-snps-hsphy",
+ .of_match_table = qcom_snps_hsphy_match,
+ },
+};
+module_platform_driver(qcom_snps_hsphy_driver);
+
+MODULE_DESCRIPTION("Qualcomm Synopsys 28nm USB High-Speed PHY driver");
+MODULE_LICENSE("GPL v2");
--
2.18.0


2018-12-04 05:10:08

by Kishon Vijay Abraham I

[permalink] [raw]
Subject: Re: [PATCH v5 2/2] phy: qualcomm: Add Synopsys High-Speed USB PHY driver

Hi,

On 27/11/18 3:37 PM, Shawn Guo wrote:
> It adds Synopsys 28nm Femto High-Speed USB PHY driver support, which
> is usually paired with Synopsys DWC3 USB controllers on Qualcomm SoCs.

Is this Synopsys PHY specific to Qualcomm or could it be used by other vendors
(with just changing tuning parameters)? If it could be used by other vendors
then it would make sense to add this PHY driver in synopsys directory.

Thanks
Kishon
>
> Signed-off-by: Shawn Guo <[email protected]>
> ---
> drivers/phy/qualcomm/Kconfig | 10 +
> drivers/phy/qualcomm/Makefile | 1 +
> .../phy/qualcomm/phy-qcom-usb-hs-snsp-28nm.c | 529 ++++++++++++++++++
> 3 files changed, 540 insertions(+)
> create mode 100644 drivers/phy/qualcomm/phy-qcom-usb-hs-snsp-28nm.c
>
> diff --git a/drivers/phy/qualcomm/Kconfig b/drivers/phy/qualcomm/Kconfig
> index 32f7d34eb784..c7b5ee82895d 100644
> --- a/drivers/phy/qualcomm/Kconfig
> +++ b/drivers/phy/qualcomm/Kconfig
> @@ -82,3 +82,13 @@ config PHY_QCOM_USB_HSIC
> select GENERIC_PHY
> help
> Support for the USB HSIC ULPI compliant PHY on QCOM chipsets.
> +
> +config PHY_QCOM_USB_HS_SNPS_28NM
> + tristate "Qualcomm Synopsys 28nm USB HS PHY driver"
> + depends on ARCH_QCOM || COMPILE_TEST
> + depends on EXTCON || !EXTCON # if EXTCON=m, this cannot be built-in
> + select GENERIC_PHY
> + help
> + Enable this to support the Synopsys 28nm Femto USB PHY on Qualcomm
> + chips. This driver supports the high-speed PHY which is usually
> + paired with either the ChipIdea or Synopsys DWC3 USB IPs on MSM SOCs.
> diff --git a/drivers/phy/qualcomm/Makefile b/drivers/phy/qualcomm/Makefile
> index c56efd3af205..dc238d95b18c 100644
> --- a/drivers/phy/qualcomm/Makefile
> +++ b/drivers/phy/qualcomm/Makefile
> @@ -9,3 +9,4 @@ obj-$(CONFIG_PHY_QCOM_UFS_14NM) += phy-qcom-ufs-qmp-14nm.o
> obj-$(CONFIG_PHY_QCOM_UFS_20NM) += phy-qcom-ufs-qmp-20nm.o
> obj-$(CONFIG_PHY_QCOM_USB_HS) += phy-qcom-usb-hs.o
> obj-$(CONFIG_PHY_QCOM_USB_HSIC) += phy-qcom-usb-hsic.o
> +obj-$(CONFIG_PHY_QCOM_USB_HS_SNPS_28NM) += phy-qcom-usb-hs-snsp-28nm.o
> diff --git a/drivers/phy/qualcomm/phy-qcom-usb-hs-snsp-28nm.c b/drivers/phy/qualcomm/phy-qcom-usb-hs-snsp-28nm.c
> new file mode 100644
> index 000000000000..1fa364417237
> --- /dev/null
> +++ b/drivers/phy/qualcomm/phy-qcom-usb-hs-snsp-28nm.c
> @@ -0,0 +1,529 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (c) 2009-2018, Linux Foundation. All rights reserved.
> + * Copyright (c) 2018, Linaro Limited
> + */
> +
> +#include <linux/clk.h>
> +#include <linux/delay.h>
> +#include <linux/extcon.h>
> +#include <linux/io.h>
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/notifier.h>
> +#include <linux/of.h>
> +#include <linux/of_graph.h>
> +#include <linux/phy/phy.h>
> +#include <linux/platform_device.h>
> +#include <linux/regulator/consumer.h>
> +#include <linux/reset.h>
> +#include <linux/slab.h>
> +
> +/* PHY register and bit definitions */
> +#define PHY_CTRL_COMMON0 0x078
> +#define SIDDQ BIT(2)
> +#define PHY_IRQ_CMD 0x0d0
> +#define PHY_INTR_MASK0 0x0d4
> +#define PHY_INTR_CLEAR0 0x0dc
> +#define DPDM_MASK 0x1e
> +#define DP_1_0 BIT(4)
> +#define DP_0_1 BIT(3)
> +#define DM_1_0 BIT(2)
> +#define DM_0_1 BIT(1)
> +
> +enum hsphy_voltage {
> + VOL_NONE,
> + VOL_MIN,
> + VOL_MAX,
> + VOL_NUM,
> +};
> +
> +enum hsphy_vreg {
> + VDD,
> + VDDA_1P8,
> + VDDA_3P3,
> + VREG_NUM,
> +};
> +
> +struct hsphy_init_seq {
> + int offset;
> + int val;
> + int delay;
> +};
> +
> +struct hsphy_data {
> + const struct hsphy_init_seq *init_seq;
> + unsigned int init_seq_num;
> +};
> +
> +struct hsphy_priv {
> + void __iomem *base;
> + struct clk_bulk_data *clks;
> + int num_clks;
> + struct reset_control *phy_reset;
> + struct reset_control *por_reset;
> + struct regulator_bulk_data vregs[VREG_NUM];
> + unsigned int voltages[VREG_NUM][VOL_NUM];
> + const struct hsphy_data *data;
> + bool cable_connected;
> + struct extcon_dev *vbus_edev;
> + struct notifier_block vbus_notify;
> + enum phy_mode mode;
> +};
> +
> +static int qcom_snps_hsphy_config_regulators(struct hsphy_priv *priv, int high)
> +{
> + int old_uV[VREG_NUM];
> + int min, ret, i;
> +
> + min = high ? 1 : 0; /* low or none? */
> +
> + for (i = 0; i < VREG_NUM; i++) {
> + old_uV[i] = regulator_get_voltage(priv->vregs[i].consumer);
> + ret = regulator_set_voltage(priv->vregs[i].consumer,
> + priv->voltages[i][min],
> + priv->voltages[i][VOL_MAX]);
> + if (ret)
> + goto roll_back;
> + }
> +
> + return 0;
> +
> +roll_back:
> + for (; i >= 0; i--)
> + regulator_set_voltage(priv->vregs[i].consumer,
> + old_uV[i], old_uV[i]);
> + return ret;
> +}
> +
> +static int qcom_snps_hsphy_enable_regulators(struct hsphy_priv *priv)
> +{
> + int ret;
> +
> + ret = qcom_snps_hsphy_config_regulators(priv, 1);
> + if (ret)
> + return ret;
> +
> + ret = regulator_set_load(priv->vregs[VDDA_1P8].consumer, 19000);
> + if (ret < 0)
> + goto unconfig_regulators;
> +
> + ret = regulator_set_load(priv->vregs[VDDA_3P3].consumer, 16000);
> + if (ret < 0)
> + goto unset_1p8_load;
> +
> + ret = regulator_bulk_enable(VREG_NUM, priv->vregs);
> + if (ret)
> + goto unset_3p3_load;
> +
> + return 0;
> +
> +unset_3p3_load:
> + regulator_set_load(priv->vregs[VDDA_3P3].consumer, 0);
> +unset_1p8_load:
> + regulator_set_load(priv->vregs[VDDA_1P8].consumer, 0);
> +unconfig_regulators:
> + qcom_snps_hsphy_config_regulators(priv, 0);
> + return ret;
> +}
> +
> +static void qcom_snps_hsphy_disable_regulators(struct hsphy_priv *priv)
> +{
> + regulator_bulk_disable(VREG_NUM, priv->vregs);
> + regulator_set_load(priv->vregs[VDDA_1P8].consumer, 0);
> + regulator_set_load(priv->vregs[VDDA_3P3].consumer, 0);
> + qcom_snps_hsphy_config_regulators(priv, 0);
> +}
> +
> +static int qcom_snps_hsphy_set_mode(struct phy *phy, enum phy_mode mode)
> +{
> + struct hsphy_priv *priv = phy_get_drvdata(phy);
> +
> + priv->mode = mode;
> +
> + return 0;
> +}
> +
> +static void qcom_snps_hsphy_enable_hv_interrupts(struct hsphy_priv *priv)
> +{
> + u32 val;
> +
> + /* Clear any existing interrupts before enabling the interrupts */
> + val = readb(priv->base + PHY_INTR_CLEAR0);
> + val |= DPDM_MASK;
> + writeb(val, priv->base + PHY_INTR_CLEAR0);
> +
> + writeb(0x0, priv->base + PHY_IRQ_CMD);
> + usleep_range(200, 220);
> + writeb(0x1, priv->base + PHY_IRQ_CMD);
> +
> + /* Make sure the interrupts are cleared */
> + usleep_range(200, 220);
> +
> + val = readb(priv->base + PHY_INTR_MASK0);
> + switch (priv->mode) {
> + case PHY_MODE_USB_HOST_HS:
> + case PHY_MODE_USB_HOST_FS:
> + case PHY_MODE_USB_DEVICE_HS:
> + case PHY_MODE_USB_DEVICE_FS:
> + val |= DP_1_0 | DM_0_1;
> + break;
> + case PHY_MODE_USB_HOST_LS:
> + case PHY_MODE_USB_DEVICE_LS:
> + val |= DP_0_1 | DM_1_0;
> + break;
> + default:
> + /* No device connected */
> + val |= DP_0_1 | DM_0_1;
> + break;
> + }
> + writeb(val, priv->base + PHY_INTR_MASK0);
> +}
> +
> +static void qcom_snps_hsphy_disable_hv_interrupts(struct hsphy_priv *priv)
> +{
> + u32 val;
> +
> + val = readb(priv->base + PHY_INTR_MASK0);
> + val &= ~DPDM_MASK;
> + writeb(val, priv->base + PHY_INTR_MASK0);
> +
> + /* Clear any pending interrupts */
> + val = readb(priv->base + PHY_INTR_CLEAR0);
> + val |= DPDM_MASK;
> + writeb(val, priv->base + PHY_INTR_CLEAR0);
> +
> + writeb(0x0, priv->base + PHY_IRQ_CMD);
> + usleep_range(200, 220);
> +
> + writeb(0x1, priv->base + PHY_IRQ_CMD);
> + usleep_range(200, 220);
> +}
> +
> +static void qcom_snps_hsphy_enter_retention(struct hsphy_priv *priv)
> +{
> + u32 val;
> +
> + val = readb(priv->base + PHY_CTRL_COMMON0);
> + val |= SIDDQ;
> + writeb(val, priv->base + PHY_CTRL_COMMON0);
> +}
> +
> +static void qcom_snps_hsphy_exit_retention(struct hsphy_priv *priv)
> +{
> + u32 val;
> +
> + val = readb(priv->base + PHY_CTRL_COMMON0);
> + val &= ~SIDDQ;
> + writeb(val, priv->base + PHY_CTRL_COMMON0);
> +}
> +
> +static int qcom_snps_hsphy_vbus_notifier(struct notifier_block *nb,
> + unsigned long event, void *ptr)
> +{
> + struct hsphy_priv *priv = container_of(nb, struct hsphy_priv,
> + vbus_notify);
> + priv->cable_connected = !!event;
> + return 0;
> +}
> +
> +static int qcom_snps_hsphy_power_on(struct phy *phy)
> +{
> + struct hsphy_priv *priv = phy_get_drvdata(phy);
> + int ret;
> +
> + if (priv->cable_connected) {
> + ret = clk_bulk_prepare_enable(priv->num_clks, priv->clks);
> + if (ret)
> + return ret;
> + qcom_snps_hsphy_disable_hv_interrupts(priv);
> + } else {
> + ret = qcom_snps_hsphy_enable_regulators(priv);
> + if (ret)
> + return ret;
> + ret = clk_bulk_prepare_enable(priv->num_clks, priv->clks);
> + if (ret)
> + return ret;
> + qcom_snps_hsphy_exit_retention(priv);
> + }
> +
> + return 0;
> +}
> +
> +static int qcom_snps_hsphy_power_off(struct phy *phy)
> +{
> + struct hsphy_priv *priv = phy_get_drvdata(phy);
> +
> + if (priv->cable_connected) {
> + qcom_snps_hsphy_enable_hv_interrupts(priv);
> + clk_bulk_disable_unprepare(priv->num_clks, priv->clks);
> + } else {
> + qcom_snps_hsphy_enter_retention(priv);
> + clk_bulk_disable_unprepare(priv->num_clks, priv->clks);
> + qcom_snps_hsphy_disable_regulators(priv);
> + }
> +
> + return 0;
> +}
> +
> +static int qcom_snps_hsphy_reset(struct hsphy_priv *priv)
> +{
> + int ret;
> +
> + ret = reset_control_assert(priv->phy_reset);
> + if (ret)
> + return ret;
> +
> + usleep_range(10, 15);
> +
> + ret = reset_control_deassert(priv->phy_reset);
> + if (ret)
> + return ret;
> +
> + usleep_range(80, 100);
> +
> + return 0;
> +}
> +
> +static void qcom_snps_hsphy_init_sequence(struct hsphy_priv *priv)
> +{
> + const struct hsphy_data *data = priv->data;
> + const struct hsphy_init_seq *seq;
> + int i;
> +
> + /* Device match data is optional. */
> + if (!data)
> + return;
> +
> + seq = data->init_seq;
> +
> + for (i = 0; i < data->init_seq_num; i++, seq++) {
> + writeb(seq->val, priv->base + seq->offset);
> + if (seq->delay)
> + usleep_range(seq->delay, seq->delay + 10);
> + }
> +}
> +
> +static int qcom_snps_hsphy_por_reset(struct hsphy_priv *priv)
> +{
> + int ret;
> +
> + ret = reset_control_assert(priv->por_reset);
> + if (ret)
> + return ret;
> +
> + /*
> + * The Femto PHY is POR reset in the following scenarios.
> + *
> + * 1. After overriding the parameter registers.
> + * 2. Low power mode exit from PHY retention.
> + *
> + * Ensure that SIDDQ is cleared before bringing the PHY
> + * out of reset.
> + */
> + qcom_snps_hsphy_exit_retention(priv);
> +
> + /*
> + * As per databook, 10 usec delay is required between
> + * PHY POR assert and de-assert.
> + */
> + usleep_range(10, 20);
> + ret = reset_control_deassert(priv->por_reset);
> + if (ret)
> + return ret;
> +
> + /*
> + * As per databook, it takes 75 usec for PHY to stabilize
> + * after the reset.
> + */
> + usleep_range(80, 100);
> +
> + return 0;
> +}
> +
> +static int qcom_snps_hsphy_init(struct phy *phy)
> +{
> + struct hsphy_priv *priv = phy_get_drvdata(phy);
> + int state;
> + int ret;
> +
> + ret = qcom_snps_hsphy_reset(priv);
> + if (ret)
> + return ret;
> +
> + qcom_snps_hsphy_init_sequence(priv);
> +
> + ret = qcom_snps_hsphy_por_reset(priv);
> + if (ret)
> + return ret;
> +
> + /* Setup initial state */
> + if (priv->vbus_edev) {
> + state = extcon_get_state(priv->vbus_edev, EXTCON_USB);
> + ret = qcom_snps_hsphy_vbus_notifier(&priv->vbus_notify, state,
> + priv->vbus_edev);
> + if (ret)
> + return ret;
> + }
> +
> + return 0;
> +}
> +
> +static const struct phy_ops qcom_snps_hsphy_ops = {
> + .init = qcom_snps_hsphy_init,
> + .power_on = qcom_snps_hsphy_power_on,
> + .power_off = qcom_snps_hsphy_power_off,
> + .set_mode = qcom_snps_hsphy_set_mode,
> + .owner = THIS_MODULE,
> +};
> +
> +static const char * const qcom_snps_hsphy_clks[] = {
> + "ref",
> + "phy",
> + "sleep",
> +};
> +
> +static int qcom_snps_hsphy_probe(struct platform_device *pdev)
> +{
> + struct device *dev = &pdev->dev;
> + struct device_node *extcon_node;
> + struct phy_provider *provider;
> + struct hsphy_priv *priv;
> + struct resource *res;
> + struct phy *phy;
> + int ret;
> + int i;
> +
> + priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
> + if (!priv)
> + return -ENOMEM;
> +
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + priv->base = devm_ioremap_resource(dev, res);
> + if (IS_ERR(priv->base))
> + return PTR_ERR(priv->base);
> +
> + priv->num_clks = ARRAY_SIZE(qcom_snps_hsphy_clks);
> + priv->clks = devm_kcalloc(dev, priv->num_clks, sizeof(*priv->clks),
> + GFP_KERNEL);
> + if (!priv->clks)
> + return -ENOMEM;
> +
> + for (i = 0; i < priv->num_clks; i++)
> + priv->clks[i].id = qcom_snps_hsphy_clks[i];
> +
> + ret = devm_clk_bulk_get(dev, priv->num_clks, priv->clks);
> + if (ret)
> + return ret;
> +
> + priv->phy_reset = devm_reset_control_get(dev, "phy");
> + if (IS_ERR(priv->phy_reset))
> + return PTR_ERR(priv->phy_reset);
> +
> + priv->por_reset = devm_reset_control_get(dev, "por");
> + if (IS_ERR(priv->por_reset))
> + return PTR_ERR(priv->por_reset);
> +
> + priv->vregs[VDD].supply = "vdd";
> + priv->vregs[VDDA_1P8].supply = "vdda1p8";
> + priv->vregs[VDDA_3P3].supply = "vdda3p3";
> +
> + ret = devm_regulator_bulk_get(dev, VREG_NUM, priv->vregs);
> + if (ret)
> + return ret;
> +
> + priv->voltages[VDDA_1P8][VOL_NONE] = 0;
> + priv->voltages[VDDA_1P8][VOL_MIN] = 1800000;
> + priv->voltages[VDDA_1P8][VOL_MAX] = 1800000;
> +
> + priv->voltages[VDDA_3P3][VOL_NONE] = 0;
> + priv->voltages[VDDA_3P3][VOL_MIN] = 3050000;
> + priv->voltages[VDDA_3P3][VOL_MAX] = 3300000;
> +
> + ret = of_property_read_u32_array(dev->of_node, "qcom,vdd-voltage-level",
> + priv->voltages[VDD], VOL_NUM);
> + if (ret) {
> + dev_err(dev, "failed to read qcom,vdd-voltage-level\n");
> + return ret;
> + }
> +
> + extcon_node = of_graph_get_remote_node(dev->of_node, -1, -1);
> + if (extcon_node) {
> + priv->vbus_edev = extcon_find_edev_by_node(extcon_node);
> + if (IS_ERR(priv->vbus_edev)) {
> + if (PTR_ERR(priv->vbus_edev) != -ENODEV) {
> + of_node_put(extcon_node);
> + return PTR_ERR(priv->vbus_edev);
> + }
> + priv->vbus_edev = NULL;
> + }
> + }
> + of_node_put(extcon_node);
> +
> + if (priv->vbus_edev) {
> + priv->vbus_notify.notifier_call = qcom_snps_hsphy_vbus_notifier;
> + ret = devm_extcon_register_notifier(dev, priv->vbus_edev,
> + EXTCON_USB,
> + &priv->vbus_notify);
> + if (ret)
> + return ret;
> + }
> +
> + /* Get device match data */
> + priv->data = device_get_match_data(dev);
> +
> + phy = devm_phy_create(dev, dev->of_node, &qcom_snps_hsphy_ops);
> + if (IS_ERR(phy))
> + return PTR_ERR(phy);
> +
> + phy_set_drvdata(phy, priv);
> +
> + provider = devm_of_phy_provider_register(dev, of_phy_simple_xlate);
> + return PTR_ERR_OR_ZERO(provider);
> +}
> +
> +/*
> + * The macro is used to define an initialization sequence. Each tuple
> + * is meant to program 'value' into phy register at 'offset' with 'delay'
> + * in us followed.
> + */
> +#define HSPHY_INIT_CFG(o, v, d) { .offset = o, .val = v, .delay = d, }
> +
> +static const struct hsphy_init_seq init_seq_qcs404[] = {
> + HSPHY_INIT_CFG(0xc0, 0x01, 0),
> + HSPHY_INIT_CFG(0xe8, 0x0d, 0),
> + HSPHY_INIT_CFG(0x74, 0x12, 0),
> + HSPHY_INIT_CFG(0x98, 0x63, 0),
> + HSPHY_INIT_CFG(0x9c, 0x03, 0),
> + HSPHY_INIT_CFG(0xa0, 0x1d, 0),
> + HSPHY_INIT_CFG(0xa4, 0x03, 0),
> + HSPHY_INIT_CFG(0x8c, 0x23, 0),
> + HSPHY_INIT_CFG(0x78, 0x08, 0),
> + HSPHY_INIT_CFG(0x7c, 0xdc, 0),
> + HSPHY_INIT_CFG(0x90, 0xe0, 20),
> + HSPHY_INIT_CFG(0x74, 0x10, 0),
> + HSPHY_INIT_CFG(0x90, 0x60, 0),
> +};
> +
> +static const struct hsphy_data hsphy_data_qcs404 = {
> + .init_seq = init_seq_qcs404,
> + .init_seq_num = ARRAY_SIZE(init_seq_qcs404),
> +};
> +
> +static const struct of_device_id qcom_snps_hsphy_match[] = {
> + { .compatible = "qcom,qcs404-usb-hsphy", .data = &hsphy_data_qcs404, },
> + { },
> +};
> +MODULE_DEVICE_TABLE(of, qcom_snps_hsphy_match);
> +
> +static struct platform_driver qcom_snps_hsphy_driver = {
> + .probe = qcom_snps_hsphy_probe,
> + .driver = {
> + .name = "qcom-usb-snps-hsphy",
> + .of_match_table = qcom_snps_hsphy_match,
> + },
> +};
> +module_platform_driver(qcom_snps_hsphy_driver);
> +
> +MODULE_DESCRIPTION("Qualcomm Synopsys 28nm USB High-Speed PHY driver");
> +MODULE_LICENSE("GPL v2");
>

2018-12-04 06:03:06

by Shawn Guo

[permalink] [raw]
Subject: Re: [PATCH v5 2/2] phy: qualcomm: Add Synopsys High-Speed USB PHY driver

Hi Kishon,

On Tue, Dec 04, 2018 at 10:38:19AM +0530, Kishon Vijay Abraham I wrote:
> Hi,
>
> On 27/11/18 3:37 PM, Shawn Guo wrote:
> > It adds Synopsys 28nm Femto High-Speed USB PHY driver support, which
> > is usually paired with Synopsys DWC3 USB controllers on Qualcomm SoCs.
>
> Is this Synopsys PHY specific to Qualcomm or could it be used by other vendors
> (with just changing tuning parameters)? If it could be used by other vendors
> then it would make sense to add this PHY driver in synopsys directory.

My knowledge is that this Synopsys PHY is specific to Qualcomm SoCs.
@Sriharsha, correct me if I'm wrong.

Shawn

2018-12-17 01:11:12

by Shawn Guo

[permalink] [raw]
Subject: Re: [PATCH v5 2/2] phy: qualcomm: Add Synopsys High-Speed USB PHY driver

On Tue, Dec 04, 2018 at 02:01:07PM +0800, Shawn Guo wrote:
> Hi Kishon,
>
> On Tue, Dec 04, 2018 at 10:38:19AM +0530, Kishon Vijay Abraham I wrote:
> > Hi,
> >
> > On 27/11/18 3:37 PM, Shawn Guo wrote:
> > > It adds Synopsys 28nm Femto High-Speed USB PHY driver support, which
> > > is usually paired with Synopsys DWC3 USB controllers on Qualcomm SoCs.
> >
> > Is this Synopsys PHY specific to Qualcomm or could it be used by other vendors
> > (with just changing tuning parameters)? If it could be used by other vendors
> > then it would make sense to add this PHY driver in synopsys directory.
>
> My knowledge is that this Synopsys PHY is specific to Qualcomm SoCs.
> @Sriharsha, correct me if I'm wrong.

Kishon,

Do you have any further comments on the patches? We are close the 4.21
merge window, and I really hope they can hit mainline with 4.21 release.
Thanks.

Shawn

2018-12-18 14:19:18

by Kishon Vijay Abraham I

[permalink] [raw]
Subject: Re: [PATCH v5 2/2] phy: qualcomm: Add Synopsys High-Speed USB PHY driver



On 17/12/18 6:04 AM, Shawn Guo wrote:
> On Tue, Dec 04, 2018 at 02:01:07PM +0800, Shawn Guo wrote:
>> Hi Kishon,
>>
>> On Tue, Dec 04, 2018 at 10:38:19AM +0530, Kishon Vijay Abraham I wrote:
>>> Hi,
>>>
>>> On 27/11/18 3:37 PM, Shawn Guo wrote:
>>>> It adds Synopsys 28nm Femto High-Speed USB PHY driver support, which
>>>> is usually paired with Synopsys DWC3 USB controllers on Qualcomm SoCs.
>>>
>>> Is this Synopsys PHY specific to Qualcomm or could it be used by other vendors
>>> (with just changing tuning parameters)? If it could be used by other vendors
>>> then it would make sense to add this PHY driver in synopsys directory.
>>
>> My knowledge is that this Synopsys PHY is specific to Qualcomm SoCs.
>> @Sriharsha, correct me if I'm wrong.
>
> Kishon,
>
> Do you have any further comments on the patches? We are close the 4.21
> merge window, and I really hope they can hit mainline with 4.21 release.
> Thanks.

Aren't we waiting for feedback from Sriharsha?

-Kishon

2018-12-19 02:40:36

by Shawn Guo

[permalink] [raw]
Subject: Re: [PATCH v5 2/2] phy: qualcomm: Add Synopsys High-Speed USB PHY driver

On Tue, Dec 18, 2018 at 07:46:13PM +0530, Kishon Vijay Abraham I wrote:
>
>
> On 17/12/18 6:04 AM, Shawn Guo wrote:
> > On Tue, Dec 04, 2018 at 02:01:07PM +0800, Shawn Guo wrote:
> >> Hi Kishon,
> >>
> >> On Tue, Dec 04, 2018 at 10:38:19AM +0530, Kishon Vijay Abraham I wrote:
> >>> Hi,
> >>>
> >>> On 27/11/18 3:37 PM, Shawn Guo wrote:
> >>>> It adds Synopsys 28nm Femto High-Speed USB PHY driver support, which
> >>>> is usually paired with Synopsys DWC3 USB controllers on Qualcomm SoCs.
> >>>
> >>> Is this Synopsys PHY specific to Qualcomm or could it be used by other vendors
> >>> (with just changing tuning parameters)? If it could be used by other vendors
> >>> then it would make sense to add this PHY driver in synopsys directory.
> >>
> >> My knowledge is that this Synopsys PHY is specific to Qualcomm SoCs.
> >> @Sriharsha, correct me if I'm wrong.
> >
> > Kishon,
> >
> > Do you have any further comments on the patches? We are close the 4.21
> > merge window, and I really hope they can hit mainline with 4.21 release.
> > Thanks.
>
> Aren't we waiting for feedback from Sriharsha?

I think no correction means that I'm right :)

Shawn

2018-12-19 19:20:51

by Jack Pham

[permalink] [raw]
Subject: Re: [PATCH v5 2/2] phy: qualcomm: Add Synopsys High-Speed USB PHY driver

Hi Shawn, Kishon,

On Wed, Dec 19, 2018 at 09:07:36AM +0800, Shawn Guo wrote:
> On Tue, Dec 18, 2018 at 07:46:13PM +0530, Kishon Vijay Abraham I wrote:
> >
> >
> > On 17/12/18 6:04 AM, Shawn Guo wrote:
> > > On Tue, Dec 04, 2018 at 02:01:07PM +0800, Shawn Guo wrote:
> > >> Hi Kishon,
> > >>
> > >> On Tue, Dec 04, 2018 at 10:38:19AM +0530, Kishon Vijay Abraham I wrote:
> > >>> Hi,
> > >>>
> > >>> On 27/11/18 3:37 PM, Shawn Guo wrote:
> > >>>> It adds Synopsys 28nm Femto High-Speed USB PHY driver support, which
> > >>>> is usually paired with Synopsys DWC3 USB controllers on Qualcomm SoCs.
> > >>>
> > >>> Is this Synopsys PHY specific to Qualcomm or could it be used by other vendors
> > >>> (with just changing tuning parameters)? If it could be used by other vendors
> > >>> then it would make sense to add this PHY driver in synopsys directory.
> > >>
> > >> My knowledge is that this Synopsys PHY is specific to Qualcomm SoCs.
> > >> @Sriharsha, correct me if I'm wrong.
> > >
> > > Kishon,
> > >
> > > Do you have any further comments on the patches? We are close the 4.21
> > > merge window, and I really hope they can hit mainline with 4.21 release.
> > > Thanks.
> >
> > Aren't we waiting for feedback from Sriharsha?
>
> I think no correction means that I'm right :)

I'm sorry Sriharsha has not yet responded but I can confirm that this
PHY driver would only be specific to Qualcomm SoCs simply because of our
custom register mapping used to control and initialize it. These are
only defined as as HW signals by the Synopsys IP, which have been
synthesized to map to our own IO register space. So really it can be
treated as just a "Qualcomm USB PHY" with acknowledgement that the core
design is licensed from SNPS.

Thanks,
Jack
--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

2018-12-19 21:51:56

by Jack Pham

[permalink] [raw]
Subject: Re: [PATCH v5 2/2] phy: qualcomm: Add Synopsys High-Speed USB PHY driver

Hi Shawn,

On Tue, Nov 27, 2018 at 06:07:22PM +0800, Shawn Guo wrote:
> It adds Synopsys 28nm Femto High-Speed USB PHY driver support, which
> is usually paired with Synopsys DWC3 USB controllers on Qualcomm SoCs.
>
> Signed-off-by: Shawn Guo <[email protected]>
> ---
> drivers/phy/qualcomm/Kconfig | 10 +
> drivers/phy/qualcomm/Makefile | 1 +
> .../phy/qualcomm/phy-qcom-usb-hs-snsp-28nm.c | 529 ++++++++++++++++++

Just caught this...
s/snsp/snps/ in the file name? The bindings doc in Patch 1 is named
correctly.

Thanks,
Jack
--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

2018-12-20 02:11:59

by Shawn Guo

[permalink] [raw]
Subject: Re: [PATCH v5 2/2] phy: qualcomm: Add Synopsys High-Speed USB PHY driver

On Wed, Dec 19, 2018 at 10:49:38AM -0800, Jack Pham wrote:
> Hi Shawn, Kishon,
>
> On Wed, Dec 19, 2018 at 09:07:36AM +0800, Shawn Guo wrote:
> > On Tue, Dec 18, 2018 at 07:46:13PM +0530, Kishon Vijay Abraham I wrote:
> > >
> > >
> > > On 17/12/18 6:04 AM, Shawn Guo wrote:
> > > > On Tue, Dec 04, 2018 at 02:01:07PM +0800, Shawn Guo wrote:
> > > >> Hi Kishon,
> > > >>
> > > >> On Tue, Dec 04, 2018 at 10:38:19AM +0530, Kishon Vijay Abraham I wrote:
> > > >>> Hi,
> > > >>>
> > > >>> On 27/11/18 3:37 PM, Shawn Guo wrote:
> > > >>>> It adds Synopsys 28nm Femto High-Speed USB PHY driver support, which
> > > >>>> is usually paired with Synopsys DWC3 USB controllers on Qualcomm SoCs.
> > > >>>
> > > >>> Is this Synopsys PHY specific to Qualcomm or could it be used by other vendors
> > > >>> (with just changing tuning parameters)? If it could be used by other vendors
> > > >>> then it would make sense to add this PHY driver in synopsys directory.
> > > >>
> > > >> My knowledge is that this Synopsys PHY is specific to Qualcomm SoCs.
> > > >> @Sriharsha, correct me if I'm wrong.
> > > >
> > > > Kishon,
> > > >
> > > > Do you have any further comments on the patches? We are close the 4.21
> > > > merge window, and I really hope they can hit mainline with 4.21 release.
> > > > Thanks.
> > >
> > > Aren't we waiting for feedback from Sriharsha?
> >
> > I think no correction means that I'm right :)
>
> I'm sorry Sriharsha has not yet responded but I can confirm that this
> PHY driver would only be specific to Qualcomm SoCs simply because of our
> custom register mapping used to control and initialize it. These are
> only defined as as HW signals by the Synopsys IP, which have been
> synthesized to map to our own IO register space. So really it can be
> treated as just a "Qualcomm USB PHY" with acknowledgement that the core
> design is licensed from SNPS.

Thanks much for confirming, Jack.

Shawn

2018-12-20 03:26:58

by Shawn Guo

[permalink] [raw]
Subject: Re: [PATCH v5 2/2] phy: qualcomm: Add Synopsys High-Speed USB PHY driver

On Wed, Dec 19, 2018 at 12:01:07PM -0800, Jack Pham wrote:
> Hi Shawn,
>
> On Tue, Nov 27, 2018 at 06:07:22PM +0800, Shawn Guo wrote:
> > It adds Synopsys 28nm Femto High-Speed USB PHY driver support, which
> > is usually paired with Synopsys DWC3 USB controllers on Qualcomm SoCs.
> >
> > Signed-off-by: Shawn Guo <[email protected]>
> > ---
> > drivers/phy/qualcomm/Kconfig | 10 +
> > drivers/phy/qualcomm/Makefile | 1 +
> > .../phy/qualcomm/phy-qcom-usb-hs-snsp-28nm.c | 529 ++++++++++++++++++
>
> Just caught this...
> s/snsp/snps/ in the file name? The bindings doc in Patch 1 is named
> correctly.

Oops, I will fix it with v6. Thanks for spotting it.

Shawn