[PATCH v4 0/3] Support for USB DRD Phy driver for NS2

[PATCH v4 0/3] Support for USB DRD Phy driver for NS2

[Raviteja Garimella]

Changes in v4:
=============
Remove references to edev->name in debug prints.

<clip: as before>
Changes in v3:
=============
Remove unnecessary checks for poweron as suggested in review.

Changes in v2:
=============
1. Initialize file operations .owner field with THIS_MODULE.
2. Remove unnecessary gpio example in DT bindings documentation.
   This is previously acked by Rob Herring <robh@kernel.org>

Introduction for PATCH v1:

This patch adds support for USB Dual Role Device Phy for Broadcom
Northstar2 SoC. Apart from the new phy driver, this patchset contains
changes to Kconfig, Makefile, and Device tree files.

This patchset is tested on Broadcom NS2 BCM958712K reference board.

Repo: https://github.com/Broadcom/arm64-linux.git
Branch: ns2_drdphy_v4

Raviteja Garimella (3):
  Add DT bindings documentation for NS2 USB DRD phy
  Broadcom USB DRD Phy driver for Northstar2
  DT nodes for Broadcom Northstar2 USB DRD Phy

 .../devicetree/bindings/phy/brcm,ns2-drd-phy.txt   |  30 ++
 arch/arm64/boot/dts/broadcom/ns2.dtsi              |  14 +
 drivers/phy/Kconfig                                |  13 +
 drivers/phy/Makefile                               |   1 +
 drivers/phy/phy-bcm-ns2-usbdrd.c                   | 567 +++++++++++++++++++++
 5 files changed, 625 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/phy/brcm,ns2-drd-phy.txt
 create mode 100644 drivers/phy/phy-bcm-ns2-usbdrd.c

-- 
2.1.0

[PATCH v4 1/3] Add DT bindings documentation for NS2 USB DRD phy

[Raviteja Garimella]

This patch adds documentation for NS2 DRD Phy driver DT bindings

Signed-off-by: Raviteja Garimella <raviteja.garimella@broadcom.com>
Acked-by: Rob Herring <robh@kernel.org>
---
 .../devicetree/bindings/phy/brcm,ns2-drd-phy.txt   | 30 ++++++++++++++++++++++
 1 file changed, 30 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/phy/brcm,ns2-drd-phy.txt

diff --git a/Documentation/devicetree/bindings/phy/brcm,ns2-drd-phy.txt b/Documentation/devicetree/bindings/phy/brcm,ns2-drd-phy.txt
new file mode 100644
index 0000000..04f063a
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/brcm,ns2-drd-phy.txt
@@ -0,0 +1,30 @@
+BROADCOM NORTHSTAR2 USB2 (DUAL ROLE DEVICE) PHY
+
+Required properties:
+ - compatible: brcm,ns2-drd-phy
+ - reg: offset and length of the NS2 PHY related registers.
+ - reg-names
+   The below registers must be provided.
+   icfg - for DRD ICFG configurations
+   rst-ctrl - for DRD IDM reset
+   crmu-ctrl - for CRMU core vdd, PHY and PHY PLL reset
+   usb2-strap - for port over current polarity reversal
+ - #phy-cells: Must be 0. No args required.
+ - vbus-gpios: vbus gpio binding
+ - id-gpios: id gpio binding
+
+Refer to phy/phy-bindings.txt for the generic PHY binding properties
+
+Example:
+	usbdrd_phy: phy@66000960 {
+			#phy-cells = <0>;
+			compatible = "brcm,ns2-drd-phy";
+			reg = <0x66000960 0x24>,
+			      <0x67012800 0x4>,
+			      <0x6501d148 0x4>,
+			      <0x664d0700 0x4>;
+			reg-names = "icfg", "rst-ctrl",
+				    "crmu-ctrl", "usb2-strap";
+			id-gpios = <&gpio_g 30 0>;
+			vbus-gpios = <&gpio_g 31 0>;
+	};
-- 
2.1.0

[PATCH v4 2/3] Broadcom USB DRD Phy driver for Northstar2

[Raviteja Garimella]

This is driver for USB DRD Phy used in Broadcom's Northstar2
SoC. The phy can be configured to be in Device mode or Host
mode based on the type of cable connected to the port. The
driver registers to  extcon framework to get appropriate
connect events for Host/Device cables connect/disconnect
states based on VBUS and ID interrupts.

Signed-off-by: Raviteja Garimella <raviteja.garimella@broadcom.com>
---
 drivers/phy/Kconfig              |  13 +
 drivers/phy/Makefile             |   1 +
 drivers/phy/phy-bcm-ns2-usbdrd.c | 567 +++++++++++++++++++++++++++++++++++++++
 3 files changed, 581 insertions(+)
 create mode 100644 drivers/phy/phy-bcm-ns2-usbdrd.c

diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index dc5277a..001bc33 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -487,6 +487,19 @@ config PHY_CYGNUS_PCIE
 	  Enable this to support the Broadcom Cygnus PCIe PHY.
 	  If unsure, say N.
 
+config PHY_NS2_USB_DRD
+	tristate "Broadcom Northstar2 USB DRD PHY support"
+	depends on OF && (ARCH_BCM_IPROC || COMPILE_TEST)
+	select GENERIC_PHY
+	select EXTCON
+	default ARCH_BCM_IPROC
+	help
+	  Enable this to support the Broadcom Northstar2 USB DRD PHY.
+	  This driver initializes the PHY in either HOST or DEVICE mode.
+	  The host or device configuration is read from device tree.
+
+	  If unsure, say N.
+
 source "drivers/phy/tegra/Kconfig"
 
 config PHY_NS2_PCIE
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index e7b0feb..122eee6 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -59,6 +59,7 @@ obj-$(CONFIG_PHY_TUSB1210)		+= phy-tusb1210.o
 obj-$(CONFIG_PHY_BRCM_SATA)		+= phy-brcm-sata.o
 obj-$(CONFIG_PHY_PISTACHIO_USB)		+= phy-pistachio-usb.o
 obj-$(CONFIG_PHY_CYGNUS_PCIE)		+= phy-bcm-cygnus-pcie.o
+obj-$(CONFIG_PHY_NS2_USB_DRD)		+= phy-bcm-ns2-usbdrd.o
 obj-$(CONFIG_ARCH_TEGRA) += tegra/
 obj-$(CONFIG_PHY_NS2_PCIE)		+= phy-bcm-ns2-pcie.o
 obj-$(CONFIG_PHY_MESON8B_USB2)		+= phy-meson8b-usb2.o
diff --git a/drivers/phy/phy-bcm-ns2-usbdrd.c b/drivers/phy/phy-bcm-ns2-usbdrd.c
new file mode 100644
index 0000000..f41763f
--- /dev/null
+++ b/drivers/phy/phy-bcm-ns2-usbdrd.c
@@ -0,0 +1,567 @@
+/*
+ * Copyright (C) 2016 Broadcom
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include <linux/delay.h>
+#include <linux/extcon.h>
+#include <linux/gpio.h>
+#include <linux/gpio/consumer.h>
+#include <linux/init.h>
+#include <linux/interrupt.h>
+#include <linux/io.h>
+#include <linux/irq.h>
+#include <linux/mfd/syscon.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/phy/phy.h>
+#include <linux/platform_device.h>
+#include <linux/regmap.h>
+#include <linux/slab.h>
+#include <linux/workqueue.h>
+
+#define ICFG_DRD_AFE		0x0
+#define ICFG_MISC_STAT		0x18
+#define ICFG_DRD_P0CTL		0x1C
+#define ICFG_STRAP_CTRL		0x20
+#define ICFG_FSM_CTRL		0x24
+
+#define IDM_RST_BIT		BIT(0)
+#define AFE_CORERDY_VDDC	BIT(18)
+#define PHY_PLL_RESETB		BIT(15)
+#define PHY_RESETB		BIT(14)
+#define PHY_PLL_LOCK		BIT(0)
+
+#define DRD_DEV_MODE		BIT(20)
+#define OHCI_OVRCUR_POL		BIT(11)
+#define ICFG_OFF_MODE		BIT(6)
+#define PLL_LOCK_RETRY		1000
+
+#define EVT_DEVICE		0
+#define EVT_HOST		1
+#define EVT_IDLE		2
+
+#define DRD_HOST_MODE		(BIT(2) | BIT(3))
+#define DRD_DEVICE_MODE		(BIT(4) | BIT(5))
+#define DRD_HOST_VAL		0x803
+#define DRD_DEV_VAL		0x807
+#define GPIO_DELAY		20
+#define PHY_WQ_DELAY		msecs_to_jiffies(600)
+
+struct ns2_phy_data;
+struct ns2_phy_driver {
+	void __iomem *icfgdrd_regs;
+	void __iomem *idmdrd_rst_ctrl;
+	void __iomem *crmu_usb2_ctrl;
+	void __iomem *usb2h_strap_reg;
+	spinlock_t lock; /* spin lock for phy driver */
+	struct ns2_phy_data *data;
+	struct extcon_specific_cable_nb extcon_dev;
+	struct extcon_specific_cable_nb extcon_host;
+	struct notifier_block host_nb;
+	struct notifier_block dev_nb;
+	struct delayed_work conn_work;
+	struct extcon_dev *edev;
+	struct gpio_desc *vbus_gpiod;
+	struct gpio_desc *id_gpiod;
+	int id_irq;
+	int vbus_irq;
+	unsigned long debounce_jiffies;
+	struct delayed_work wq_extcon;
+};
+
+struct ns2_phy_data {
+	struct ns2_phy_driver *driver;
+	struct phy *phy;
+	int new_state;
+};
+
+static const unsigned int usb_extcon_cable[] = {
+	EXTCON_USB,
+	EXTCON_USB_HOST,
+	EXTCON_NONE,
+};
+
+static inline int pll_lock_stat(u32 usb_reg, int reg_mask,
+				struct ns2_phy_driver *driver)
+{
+	int retry = PLL_LOCK_RETRY;
+	u32 val;
+
+	do {
+		udelay(1);
+		val = readl(driver->icfgdrd_regs + usb_reg);
+		if (val & reg_mask)
+			return 0;
+	} while (--retry > 0);
+
+	return -EBUSY;
+}
+
+static int ns2_drd_phy_init(struct phy *phy)
+{
+	struct ns2_phy_data *data = phy_get_drvdata(phy);
+	struct ns2_phy_driver *driver = data->driver;
+	unsigned long flags;
+	u32 val;
+
+	spin_lock_irqsave(&driver->lock, flags);
+
+	val = readl(driver->icfgdrd_regs + ICFG_FSM_CTRL);
+
+	if (data->new_state == EVT_HOST) {
+		val &= ~DRD_DEVICE_MODE;
+		val |= DRD_HOST_MODE;
+	} else {
+		val &= ~DRD_HOST_MODE;
+		val |= DRD_DEVICE_MODE;
+	}
+	writel(val, driver->icfgdrd_regs + ICFG_FSM_CTRL);
+
+	spin_unlock_irqrestore(&driver->lock, flags);
+	return 0;
+}
+
+static int ns2_drd_phy_shutdown(struct phy *phy)
+{
+	struct ns2_phy_data *data = phy_get_drvdata(phy);
+	struct ns2_phy_driver *driver = data->driver;
+	unsigned long flags;
+	u32 val;
+
+	spin_lock_irqsave(&driver->lock, flags);
+
+	val = readl(driver->crmu_usb2_ctrl);
+	val &= ~AFE_CORERDY_VDDC;
+	writel(val, driver->crmu_usb2_ctrl);
+
+	val = readl(driver->crmu_usb2_ctrl);
+	val &= ~DRD_DEV_MODE;
+	writel(val, driver->crmu_usb2_ctrl);
+
+	/* Disable Host and Device Mode */
+	val = readl(driver->icfgdrd_regs + ICFG_FSM_CTRL);
+	val &= ~(DRD_HOST_MODE | DRD_DEVICE_MODE | ICFG_OFF_MODE);
+	writel(val, driver->icfgdrd_regs + ICFG_FSM_CTRL);
+
+	spin_unlock_irqrestore(&driver->lock, flags);
+	return 0;
+}
+
+static int ns2_drd_phy_poweron(struct phy *phy)
+{
+	struct ns2_phy_data *data = phy_get_drvdata(phy);
+	struct ns2_phy_driver *driver = data->driver;
+	u32 extcon_event = data->new_state;
+	unsigned long flags;
+	int ret;
+	u32 val;
+
+	spin_lock_irqsave(&driver->lock, flags);
+	if (extcon_event == EVT_DEVICE) {
+		writel(DRD_DEV_VAL, driver->icfgdrd_regs + ICFG_DRD_P0CTL);
+
+		val = readl(driver->icfgdrd_regs + ICFG_FSM_CTRL);
+		val &= ~(DRD_HOST_MODE | ICFG_OFF_MODE);
+		val |= DRD_DEVICE_MODE;
+		writel(val, driver->icfgdrd_regs + ICFG_FSM_CTRL);
+
+		val = readl(driver->idmdrd_rst_ctrl);
+		val &= ~IDM_RST_BIT;
+		writel(val, driver->idmdrd_rst_ctrl);
+
+		val = readl(driver->crmu_usb2_ctrl);
+		val |= (AFE_CORERDY_VDDC | DRD_DEV_MODE);
+		writel(val, driver->crmu_usb2_ctrl);
+
+		/* Bring PHY and PHY_PLL out of Reset */
+		val = readl(driver->crmu_usb2_ctrl);
+		val |= (PHY_PLL_RESETB | PHY_RESETB);
+		writel(val, driver->crmu_usb2_ctrl);
+
+		ret = pll_lock_stat(ICFG_MISC_STAT, PHY_PLL_LOCK, driver);
+		if (ret < 0) {
+			dev_err(&phy->dev, "Phy PLL lock failed\n");
+			goto err_shutdown;
+		}
+	} else {
+		writel(DRD_HOST_VAL, driver->icfgdrd_regs + ICFG_DRD_P0CTL);
+
+		val = readl(driver->icfgdrd_regs + ICFG_FSM_CTRL);
+		val &= ~(DRD_DEVICE_MODE | ICFG_OFF_MODE);
+		val |= DRD_HOST_MODE;
+		writel(val, driver->icfgdrd_regs + ICFG_FSM_CTRL);
+
+		val = readl(driver->crmu_usb2_ctrl);
+		val |= AFE_CORERDY_VDDC;
+		writel(val, driver->crmu_usb2_ctrl);
+
+		ret = pll_lock_stat(ICFG_MISC_STAT, PHY_PLL_LOCK, driver);
+		if (ret < 0) {
+			dev_err(&phy->dev, "Phy PLL lock failed\n");
+			goto err_shutdown;
+		}
+
+		val = readl(driver->idmdrd_rst_ctrl);
+		val &= ~IDM_RST_BIT;
+		writel(val, driver->idmdrd_rst_ctrl);
+
+		/* port over current Polarity */
+		val = readl(driver->usb2h_strap_reg);
+		val |= OHCI_OVRCUR_POL;
+		writel(val, driver->usb2h_strap_reg);
+	}
+	spin_unlock_irqrestore(&driver->lock, flags);
+	return 0;
+
+err_shutdown:
+	spin_unlock_irqrestore(&driver->lock, flags);
+	ns2_drd_phy_shutdown(phy);
+	return ret;
+}
+
+static void connect_work(struct work_struct *work)
+{
+	struct ns2_phy_driver *driver;
+	struct ns2_phy_data *data;
+	u32 extcon_event;
+
+	driver  = container_of(to_delayed_work(work),
+			       struct ns2_phy_driver, conn_work);
+	data = driver->data;
+	extcon_event = data->new_state;
+
+	if (extcon_event == EVT_DEVICE || extcon_event == EVT_HOST) {
+		ns2_drd_phy_init(data->phy);
+		ns2_drd_phy_poweron(data->phy);
+	} else if (extcon_event == EVT_IDLE) {
+		ns2_drd_phy_shutdown(data->phy);
+	}
+}
+
+static int drd_device_notify(struct notifier_block *self,
+			     unsigned long event, void *ptr)
+{
+	struct ns2_phy_driver *driver = container_of(self,
+					struct ns2_phy_driver, dev_nb);
+
+	if (event) {
+		pr_debug("Device connected\n");
+		driver->data->new_state = EVT_DEVICE;
+		schedule_delayed_work(&driver->conn_work, 0);
+	} else {
+		pr_debug("Device disconnected\n");
+		driver->data->new_state = EVT_IDLE;
+		schedule_delayed_work(&driver->conn_work, PHY_WQ_DELAY);
+	}
+
+	return NOTIFY_DONE;
+}
+
+static int drd_host_notify(struct notifier_block *self,
+			   unsigned long event, void *ptr)
+{
+	struct ns2_phy_driver *driver = container_of(self,
+					struct ns2_phy_driver, host_nb);
+
+	if (event) {
+		pr_debug("Host connected\n");
+		driver->data->new_state = EVT_HOST;
+		schedule_delayed_work(&driver->conn_work, 0);
+	} else {
+		pr_debug("Host disconnected\n");
+		driver->data->new_state = EVT_IDLE;
+		schedule_delayed_work(&driver->conn_work, PHY_WQ_DELAY);
+	}
+
+	return NOTIFY_DONE;
+}
+
+static void extcon_work(struct work_struct *work)
+{
+	struct ns2_phy_driver *driver;
+	int vbus;
+	int id;
+
+	driver  = container_of(to_delayed_work(work),
+			       struct ns2_phy_driver, wq_extcon);
+
+	id = gpiod_get_value_cansleep(driver->id_gpiod);
+	vbus = gpiod_get_value_cansleep(driver->vbus_gpiod);
+
+	if (!id && vbus) {
+		extcon_set_cable_state_(driver->edev, EXTCON_USB_HOST, true);
+	} else if (id && !vbus) {
+		extcon_set_cable_state_(driver->edev, EXTCON_USB_HOST, false);
+		extcon_set_cable_state_(driver->edev, EXTCON_USB, false);
+	} else if (id && vbus) {
+		extcon_set_cable_state_(driver->edev, EXTCON_USB, true);
+	}
+}
+
+static irqreturn_t gpio_irq_handler(int irq, void *dev_id)
+{
+	struct ns2_phy_driver *driver = dev_id;
+
+	queue_delayed_work(system_power_efficient_wq, &driver->wq_extcon,
+			   driver->debounce_jiffies);
+
+	return IRQ_HANDLED;
+}
+
+static int register_extcon_notifier(struct ns2_phy_driver *phy_driver,
+				    struct device *dev)
+{
+	struct extcon_dev *edev;
+	int ret;
+
+	phy_driver->host_nb.notifier_call = drd_host_notify;
+	phy_driver->dev_nb.notifier_call = drd_device_notify;
+
+	edev = phy_driver->edev;
+
+	/* Register for device change notification */
+	ret = extcon_register_notifier(edev, EXTCON_USB,
+				       &phy_driver->dev_nb);
+	if (ret < 0) {
+		dev_err(dev, "can't register extcon_dev\n");
+		return ret;
+	}
+
+	/* Register for host change notification */
+	ret = extcon_register_notifier(edev, EXTCON_USB_HOST,
+				       &phy_driver->host_nb);
+	if (ret < 0) {
+		dev_err(dev, "can't register extcon_dev\n");
+		goto err_dev;
+	}
+
+	/* Check the device cable connect state */
+	ret = extcon_get_cable_state_(edev, EXTCON_USB);
+	if (ret < 0) {
+		dev_err(dev, "can't get extcon_dev state\n");
+		goto err_host;
+	} else if (ret) {
+		phy_driver->data->new_state = EVT_DEVICE;
+	}
+
+	/* Check the host cable connect state */
+	ret = extcon_get_cable_state_(edev, EXTCON_USB_HOST);
+	if (ret < 0) {
+		dev_err(dev, "can't get extcon_dev state\n");
+		goto err_host;
+	} else if (ret) {
+		phy_driver->data->new_state = EVT_HOST;
+	}
+
+	return 0;
+
+err_host:
+	ret = extcon_unregister_notifier(edev, EXTCON_USB_HOST,
+					&phy_driver->host_nb);
+err_dev:
+	ret = extcon_unregister_notifier(edev, EXTCON_USB,
+					&phy_driver->dev_nb);
+	return ret;
+}
+
+static struct phy_ops ops = {
+	.init		= ns2_drd_phy_init,
+	.power_on	= ns2_drd_phy_poweron,
+	.power_off	= ns2_drd_phy_shutdown,
+	.owner		= THIS_MODULE,
+};
+
+static const struct of_device_id ns2_drd_phy_dt_ids[] = {
+	{ .compatible = "brcm,ns2-drd-phy", },
+	{ }
+};
+
+static int ns2_drd_phy_remove(struct platform_device *pdev)
+{
+	struct ns2_phy_driver *driver = dev_get_drvdata(&pdev->dev);
+
+	if (driver->edev) {
+		extcon_unregister_notifier(driver->edev, EXTCON_USB_HOST,
+					  &driver->host_nb);
+		extcon_unregister_notifier(driver->edev, EXTCON_USB,
+					  &driver->dev_nb);
+	}
+
+	return 0;
+}
+static int ns2_drd_phy_probe(struct platform_device *pdev)
+{
+	struct phy_provider *phy_provider;
+	struct device *dev = &pdev->dev;
+	struct ns2_phy_driver *driver;
+	struct ns2_phy_data *data;
+	struct resource *res;
+	int ret;
+	u32 val;
+
+	driver = devm_kzalloc(dev, sizeof(struct ns2_phy_driver),
+			      GFP_KERNEL);
+	if (!driver)
+		return -ENOMEM;
+
+	driver->data = devm_kzalloc(dev, sizeof(struct ns2_phy_data),
+				  GFP_KERNEL);
+	if (!driver->data)
+		return -ENOMEM;
+
+	spin_lock_init(&driver->lock);
+
+	res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "icfg");
+	driver->icfgdrd_regs = devm_ioremap_resource(dev, res);
+	if (IS_ERR(driver->icfgdrd_regs))
+		return PTR_ERR(driver->icfgdrd_regs);
+
+	res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "rst-ctrl");
+	driver->idmdrd_rst_ctrl = devm_ioremap_resource(dev, res);
+	if (IS_ERR(driver->idmdrd_rst_ctrl))
+		return PTR_ERR(driver->idmdrd_rst_ctrl);
+
+	res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "crmu-ctrl");
+	driver->crmu_usb2_ctrl = devm_ioremap_resource(dev, res);
+	if (IS_ERR(driver->crmu_usb2_ctrl))
+		return PTR_ERR(driver->crmu_usb2_ctrl);
+
+	res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "usb2-strap");
+	driver->usb2h_strap_reg = devm_ioremap_resource(dev, res);
+	if (IS_ERR(driver->usb2h_strap_reg))
+		return PTR_ERR(driver->usb2h_strap_reg);
+
+	 /* create extcon */
+	driver->id_gpiod = devm_gpiod_get(&pdev->dev, "id", GPIOD_IN);
+	if (IS_ERR(driver->id_gpiod)) {
+		dev_err(dev, "failed to get ID GPIO\n");
+		return PTR_ERR(driver->id_gpiod);
+	}
+	driver->vbus_gpiod = devm_gpiod_get(&pdev->dev, "vbus", GPIOD_IN);
+	if (IS_ERR(driver->vbus_gpiod)) {
+		dev_err(dev, "failed to get VBUS GPIO\n");
+		return PTR_ERR(driver->vbus_gpiod);
+	}
+
+	driver->edev = devm_extcon_dev_allocate(dev, usb_extcon_cable);
+	if (IS_ERR(driver->edev)) {
+		dev_err(dev, "failed to allocate extcon device\n");
+		return -ENOMEM;
+	}
+
+	ret = devm_extcon_dev_register(dev, driver->edev);
+	if (ret < 0) {
+		dev_err(dev, "failed to register extcon device\n");
+		goto extcon_free;
+	}
+
+	ret = gpiod_set_debounce(driver->id_gpiod, GPIO_DELAY * 1000);
+	if (ret < 0)
+		driver->debounce_jiffies = msecs_to_jiffies(GPIO_DELAY);
+
+	INIT_DELAYED_WORK(&driver->wq_extcon, extcon_work);
+
+	driver->id_irq = gpiod_to_irq(driver->id_gpiod);
+	if (driver->id_irq < 0) {
+		dev_err(dev, "failed to get ID IRQ\n");
+		ret = driver->id_irq;
+		goto extcon_unregister;
+	}
+	driver->vbus_irq = gpiod_to_irq(driver->vbus_gpiod);
+	if (driver->vbus_irq < 0) {
+		dev_err(dev, "failed to get ID IRQ\n");
+		ret = driver->vbus_irq;
+		goto extcon_unregister;
+	}
+
+	ret = devm_request_threaded_irq(dev, driver->id_irq, NULL,
+					gpio_irq_handler,
+					IRQF_TRIGGER_RISING |
+					IRQF_TRIGGER_FALLING | IRQF_ONESHOT,
+					"usb_id", driver);
+	if (ret < 0) {
+		dev_err(dev, "failed to request handler for ID IRQ\n");
+		goto extcon_unregister;
+	}
+	ret = devm_request_threaded_irq(dev, driver->vbus_irq, NULL,
+					gpio_irq_handler,
+					IRQF_TRIGGER_RISING |
+					IRQF_TRIGGER_FALLING | IRQF_ONESHOT,
+					"usb_vbus", driver);
+	if (ret < 0) {
+		dev_err(dev, "failed to request handler for VBUS IRQ\n");
+		goto extcon_unregister;
+	}
+
+	dev_set_drvdata(dev, driver);
+
+	/* Shutdown all ports. They can be powered up as required */
+	val = readl(driver->crmu_usb2_ctrl);
+	val &= ~(AFE_CORERDY_VDDC | PHY_RESETB);
+	writel(val, driver->crmu_usb2_ctrl);
+
+	data = driver->data;
+	data->phy = devm_phy_create(dev, dev->of_node, &ops);
+	if (IS_ERR(data->phy)) {
+		dev_err(dev, "Failed to create usb drd phy\n");
+		ret = PTR_ERR(data->phy);
+		goto extcon_unregister;
+	}
+
+	data->driver = driver;
+	phy_set_drvdata(data->phy, data);
+
+	phy_provider = devm_of_phy_provider_register(dev, of_phy_simple_xlate);
+	if (IS_ERR(phy_provider)) {
+		dev_err(dev, "Failed to register as phy provider\n");
+		ret = PTR_ERR(phy_provider);
+		goto extcon_unregister;
+	}
+
+	INIT_DELAYED_WORK(&driver->conn_work, connect_work);
+	platform_set_drvdata(pdev, driver);
+
+	ret = register_extcon_notifier(driver, dev);
+	if (ret < 0) {
+		dev_err(dev, "register extcon notifier failed (%d)\n", ret);
+		goto extcon_unregister;
+	}
+	dev_info(dev, "Registered extcon device\n");
+	queue_delayed_work(system_power_efficient_wq, &driver->wq_extcon,
+			   driver->debounce_jiffies);
+
+	return 0;
+
+extcon_unregister:
+	devm_extcon_dev_unregister(dev, driver->edev);
+extcon_free:
+	devm_extcon_dev_free(dev, driver->edev);
+	return ret;
+}
+
+MODULE_DEVICE_TABLE(of, ns2_drd_phy_dt_ids);
+
+static struct platform_driver ns2_drd_phy_driver = {
+	.probe = ns2_drd_phy_probe,
+	.remove = ns2_drd_phy_remove,
+	.driver = {
+		.name = "bcm-ns2-usbphy",
+		.of_match_table = of_match_ptr(ns2_drd_phy_dt_ids),
+	},
+};
+module_platform_driver(ns2_drd_phy_driver);
+
+MODULE_ALIAS("platform:bcm-ns2-drd-phy");
+MODULE_AUTHOR("Broadcom");
+MODULE_DESCRIPTION("Broadcom NS2 USB2 PHY driver");
+MODULE_LICENSE("GPL v2");
-- 
2.1.0

[PATCH v4 3/3] DT nodes for Broadcom Northstar2 USB DRD Phy

[Raviteja Garimella]

This patch adds device tree nodes for USB Dual Role Device Phy for
Broadcom's Northstar2 SoC.

Signed-off-by: Raviteja Garimella <raviteja.garimella@broadcom.com>
---
 arch/arm64/boot/dts/broadcom/ns2.dtsi | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/arch/arm64/boot/dts/broadcom/ns2.dtsi b/arch/arm64/boot/dts/broadcom/ns2.dtsi
index 9f9e203..97c35c4 100644
--- a/arch/arm64/boot/dts/broadcom/ns2.dtsi
+++ b/arch/arm64/boot/dts/broadcom/ns2.dtsi
@@ -428,6 +428,20 @@
 			};
 		};
 
+		usbdrd_phy: phy@66000960 {
+			#phy-cells = <0>;
+			compatible = "brcm,ns2-drd-phy";
+			reg = <0x66000960 0x24>,
+			      <0x67012800 0x4>,
+			      <0x6501d148 0x4>,
+			      <0x664d0700 0x4>;
+			reg-names = "icfg", "rst-ctrl",
+				    "crmu-ctrl", "usb2-strap";
+			id-gpios = <&gpio_g 30 0>;
+			vbus-gpios = <&gpio_g 31 0>;
+			status = "disabled";
+		};
+
 		pwm: pwm@66010000 {
 			compatible = "brcm,iproc-pwm";
 			reg = <0x66010000 0x28>;
-- 
2.1.0

Re: [PATCH v4 2/3] Broadcom USB DRD Phy driver for Northstar2

[Kishon Vijay Abraham I]

Hi,

On Tuesday 28 March 2017 05:57 PM, Raviteja Garimella wrote:
> This is driver for USB DRD Phy used in Broadcom's Northstar2
> SoC. The phy can be configured to be in Device mode or Host
> mode based on the type of cable connected to the port. The
> driver registers to  extcon framework to get appropriate
> connect events for Host/Device cables connect/disconnect
> states based on VBUS and ID interrupts.

$patch should be phy: phy-bcm-ns2-usbdrd: USB DRD Phy driver for Broadcoms
Northstar2.

Sorry for not letting you know this earlier. But I feel the design of the
driver should be changed. Extcon shouldn't be used here. The extcon
notifications should be sent to the consumer driver and the consumer driver
should be responsible for invoking the phy ops.

The phy ops being invoked during extcon events doesn't look right.

Thanks
Kishon

Re: [PATCH v4 2/3] Broadcom USB DRD Phy driver for Northstar2

[Raviteja Garimella]

Hi Kishon,

On Wed, Apr 5, 2017 at 4:30 PM, Kishon Vijay Abraham I <kishon@ti.com> wrote:
> Hi,
>
> On Tuesday 28 March 2017 05:57 PM, Raviteja Garimella wrote:
>> This is driver for USB DRD Phy used in Broadcom's Northstar2
>> SoC. The phy can be configured to be in Device mode or Host
>> mode based on the type of cable connected to the port. The
>> driver registers to  extcon framework to get appropriate
>> connect events for Host/Device cables connect/disconnect
>> states based on VBUS and ID interrupts.
>
> $patch should be phy: phy-bcm-ns2-usbdrd: USB DRD Phy driver for Broadcoms
> Northstar2.
>

Will do.

> Sorry for not letting you know this earlier. But I feel the design of the
> driver should be changed. Extcon shouldn't be used here. The extcon
> notifications should be sent to the consumer driver and the consumer driver
> should be responsible for invoking the phy ops.
>

The consumer drivers here would be a UDC driver (USB device
controller), EHCI and OHCI host controller drivers.
I was already suggested in UDC driver review to deal with extcon in Phy driver.

This phy connects to 2 host controllers, and one device controller.
That's the design in Broadcom Northstar2
platform. The values of the VBUS and ID pins of this port are
determined based on the type of the cable (device cable
or host cable). And. phy has to be configured accordingly.

> The phy ops being invoked during extcon events doesn't look right.

Could you please elaborate on the concern, so that we can think of
mitigating those issues in this driver?
Since we are dealing with phy init/shutdown in this driver itself, are
you okay with moving the extcon handling code
out of phy ops ?

Thanks,
Ravi
>
> Thanks
> Kishon

Re: [PATCH v4 2/3] Broadcom USB DRD Phy driver for Northstar2

[Kishon Vijay Abraham I]

Hi Ravi,

On Wednesday 05 April 2017 06:30 PM, Raviteja Garimella wrote:
> Hi Kishon,
> 
> On Wed, Apr 5, 2017 at 4:30 PM, Kishon Vijay Abraham I <kishon@ti.com> wrote:
>> Hi,
>>
>> On Tuesday 28 March 2017 05:57 PM, Raviteja Garimella wrote:
>>> This is driver for USB DRD Phy used in Broadcom's Northstar2
>>> SoC. The phy can be configured to be in Device mode or Host
>>> mode based on the type of cable connected to the port. The
>>> driver registers to  extcon framework to get appropriate
>>> connect events for Host/Device cables connect/disconnect
>>> states based on VBUS and ID interrupts.
>>
>> $patch should be phy: phy-bcm-ns2-usbdrd: USB DRD Phy driver for Broadcoms
>> Northstar2.
>>
> 
> Will do.
> 
>> Sorry for not letting you know this earlier. But I feel the design of the
>> driver should be changed. Extcon shouldn't be used here. The extcon
>> notifications should be sent to the consumer driver and the consumer driver
>> should be responsible for invoking the phy ops.
>>
> 
> The consumer drivers here would be a UDC driver (USB device
> controller), EHCI and OHCI host controller drivers.
> I was already suggested in UDC driver review to deal with extcon in Phy driver.
> 
> This phy connects to 2 host controllers, and one device controller.
> That's the design in Broadcom Northstar2
> platform. The values of the VBUS and ID pins of this port are
> determined based on the type of the cable (device cable
> or host cable). And. phy has to be configured accordingly.
> 
>> The phy ops being invoked during extcon events doesn't look right.
> 
> Could you please elaborate on the concern, so that we can think of
> mitigating those issues in this driver?
> Since we are dealing with phy init/shutdown in this driver itself, are
> you okay with moving the extcon handling code
> out of phy ops ?

yeah, For e.g., ns2_drd_phy_init is part of phy_ops and is being invoked from
extcon events too. Can a phy which is initialized by a phy consumer (say your
UDC invokes phy_init) can be shutdown by an extcon event?

Maybe a clear explanation of when phy_ops here will be invoked and when it will
set using extcon events might help.

Thanks
Kishon

Re: [PATCH v4 2/3] Broadcom USB DRD Phy driver for Northstar2

[Raviteja Garimella]

Hi Kishon,

On Wed, Apr 5, 2017 at 7:04 PM, Kishon Vijay Abraham I <kishon@ti.com> wrote:
> Hi Ravi,
>
> On Wednesday 05 April 2017 06:30 PM, Raviteja Garimella wrote:
>> Hi Kishon,
>>
>> On Wed, Apr 5, 2017 at 4:30 PM, Kishon Vijay Abraham I <kishon@ti.com> wrote:
>>> Hi,
>>>
>>> On Tuesday 28 March 2017 05:57 PM, Raviteja Garimella wrote:
>>>> This is driver for USB DRD Phy used in Broadcom's Northstar2
>>>> SoC. The phy can be configured to be in Device mode or Host
>>>> mode based on the type of cable connected to the port. The
>>>> driver registers to  extcon framework to get appropriate
>>>> connect events for Host/Device cables connect/disconnect
>>>> states based on VBUS and ID interrupts.
>>>
>>> $patch should be phy: phy-bcm-ns2-usbdrd: USB DRD Phy driver for Broadcoms
>>> Northstar2.
>>>
>>
>> Will do.
>>
>>> Sorry for not letting you know this earlier. But I feel the design of the
>>> driver should be changed. Extcon shouldn't be used here. The extcon
>>> notifications should be sent to the consumer driver and the consumer driver
>>> should be responsible for invoking the phy ops.
>>>
>>
>> The consumer drivers here would be a UDC driver (USB device
>> controller), EHCI and OHCI host controller drivers.
>> I was already suggested in UDC driver review to deal with extcon in Phy driver.
>>
>> This phy connects to 2 host controllers, and one device controller.
>> That's the design in Broadcom Northstar2
>> platform. The values of the VBUS and ID pins of this port are
>> determined based on the type of the cable (device cable
>> or host cable). And. phy has to be configured accordingly.
>>
>>> The phy ops being invoked during extcon events doesn't look right.
>>
>> Could you please elaborate on the concern, so that we can think of
>> mitigating those issues in this driver?
>> Since we are dealing with phy init/shutdown in this driver itself, are
>> you okay with moving the extcon handling code
>> out of phy ops ?
>
> yeah, For e.g., ns2_drd_phy_init is part of phy_ops and is being invoked from
> extcon events too. Can a phy which is initialized by a phy consumer (say your
> UDC invokes phy_init) can be shutdown by an extcon event?
>
> Maybe a clear explanation of when phy_ops here will be invoked and when it will
> set using extcon events might help.
>

Say, we have a USB pendrive which is connected to the DRD port through
a host cable.
Now the PHY will be initialized to be in host mode.
When the pendrive is unplugged, and we now connect the NS2 device to
some linux PC,
now the PHY has to be shutdown, and re-initialized to be in Device mode.

On unplug event, it is set neither to Host nor Device mode (basically
shutdown). Next time which ever cable is connected, the PHY is
initialized to the respective
mode.

Please let me know if it's fine to do these initializations outside
phy ops, because those will
be irrelevant for phy consumers (the controllers) as it's anyways
dealt in the phy driver through
extcon.

Thanks,
Ravi


> Thanks
> Kishon

Re: [PATCH v4 2/3] Broadcom USB DRD Phy driver for Northstar2

[Kishon Vijay Abraham I]

Hi,

On Wednesday 05 April 2017 07:40 PM, Raviteja Garimella wrote:
> Hi Kishon,
> 
> On Wed, Apr 5, 2017 at 7:04 PM, Kishon Vijay Abraham I <kishon@ti.com> wrote:
>> Hi Ravi,
>>
>> On Wednesday 05 April 2017 06:30 PM, Raviteja Garimella wrote:
>>> Hi Kishon,
>>>
>>> On Wed, Apr 5, 2017 at 4:30 PM, Kishon Vijay Abraham I <kishon@ti.com> wrote:
>>>> Hi,
>>>>
>>>> On Tuesday 28 March 2017 05:57 PM, Raviteja Garimella wrote:
>>>>> This is driver for USB DRD Phy used in Broadcom's Northstar2
>>>>> SoC. The phy can be configured to be in Device mode or Host
>>>>> mode based on the type of cable connected to the port. The
>>>>> driver registers to  extcon framework to get appropriate
>>>>> connect events for Host/Device cables connect/disconnect
>>>>> states based on VBUS and ID interrupts.
>>>>
>>>> $patch should be phy: phy-bcm-ns2-usbdrd: USB DRD Phy driver for Broadcoms
>>>> Northstar2.
>>>>
>>>
>>> Will do.
>>>
>>>> Sorry for not letting you know this earlier. But I feel the design of the
>>>> driver should be changed. Extcon shouldn't be used here. The extcon
>>>> notifications should be sent to the consumer driver and the consumer driver
>>>> should be responsible for invoking the phy ops.
>>>>
>>>
>>> The consumer drivers here would be a UDC driver (USB device
>>> controller), EHCI and OHCI host controller drivers.
>>> I was already suggested in UDC driver review to deal with extcon in Phy driver.
>>>
>>> This phy connects to 2 host controllers, and one device controller.
>>> That's the design in Broadcom Northstar2
>>> platform. The values of the VBUS and ID pins of this port are
>>> determined based on the type of the cable (device cable
>>> or host cable). And. phy has to be configured accordingly.
>>>
>>>> The phy ops being invoked during extcon events doesn't look right.
>>>
>>> Could you please elaborate on the concern, so that we can think of
>>> mitigating those issues in this driver?
>>> Since we are dealing with phy init/shutdown in this driver itself, are
>>> you okay with moving the extcon handling code
>>> out of phy ops ?
>>
>> yeah, For e.g., ns2_drd_phy_init is part of phy_ops and is being invoked from
>> extcon events too. Can a phy which is initialized by a phy consumer (say your
>> UDC invokes phy_init) can be shutdown by an extcon event?
>>
>> Maybe a clear explanation of when phy_ops here will be invoked and when it will
>> set using extcon events might help.
>>
> 
> Say, we have a USB pendrive which is connected to the DRD port through
> a host cable.
> Now the PHY will be initialized to be in host mode.
> When the pendrive is unplugged, and we now connect the NS2 device to
> some linux PC,
> now the PHY has to be shutdown, and re-initialized to be in Device mode.
> 
> On unplug event, it is set neither to Host nor Device mode (basically
> shutdown). Next time which ever cable is connected, the PHY is
> initialized to the respective
> mode.
> 
> Please let me know if it's fine to do these initializations outside
> phy ops, because those will
> be irrelevant for phy consumers (the controllers) as it's anyways
> dealt in the phy driver through
> extcon.

How does the consumer get to know whether they have to operate in host mode or
device mode?

Thanks
Kishon

Re: [PATCH v4 2/3] Broadcom USB DRD Phy driver for Northstar2

[Raviteja Garimella]

Hi,

On Mon, Apr 10, 2017 at 10:55 AM, Kishon Vijay Abraham I <kishon@ti.com> wrote:
> Hi,
>
> On Wednesday 05 April 2017 07:40 PM, Raviteja Garimella wrote:
>> Hi Kishon,
>>
>> On Wed, Apr 5, 2017 at 7:04 PM, Kishon Vijay Abraham I <kishon@ti.com> wrote:
>>> Hi Ravi,
>>>
>>> On Wednesday 05 April 2017 06:30 PM, Raviteja Garimella wrote:
>>>> Hi Kishon,
>>>>
>>>> On Wed, Apr 5, 2017 at 4:30 PM, Kishon Vijay Abraham I <kishon@ti.com> wrote:
>>>>> Hi,
>>>>>
>>>>> On Tuesday 28 March 2017 05:57 PM, Raviteja Garimella wrote:
>>>>>> This is driver for USB DRD Phy used in Broadcom's Northstar2
>>>>>> SoC. The phy can be configured to be in Device mode or Host
>>>>>> mode based on the type of cable connected to the port. The
>>>>>> driver registers to  extcon framework to get appropriate
>>>>>> connect events for Host/Device cables connect/disconnect
>>>>>> states based on VBUS and ID interrupts.
>>>>>
>>>>> $patch should be phy: phy-bcm-ns2-usbdrd: USB DRD Phy driver for Broadcoms
>>>>> Northstar2.
>>>>>
>>>>
>>>> Will do.
>>>>
>>>>> Sorry for not letting you know this earlier. But I feel the design of the
>>>>> driver should be changed. Extcon shouldn't be used here. The extcon
>>>>> notifications should be sent to the consumer driver and the consumer driver
>>>>> should be responsible for invoking the phy ops.
>>>>>
>>>>
>>>> The consumer drivers here would be a UDC driver (USB device
>>>> controller), EHCI and OHCI host controller drivers.
>>>> I was already suggested in UDC driver review to deal with extcon in Phy driver.
>>>>
>>>> This phy connects to 2 host controllers, and one device controller.
>>>> That's the design in Broadcom Northstar2
>>>> platform. The values of the VBUS and ID pins of this port are
>>>> determined based on the type of the cable (device cable
>>>> or host cable). And. phy has to be configured accordingly.
>>>>
>>>>> The phy ops being invoked during extcon events doesn't look right.
>>>>
>>>> Could you please elaborate on the concern, so that we can think of
>>>> mitigating those issues in this driver?
>>>> Since we are dealing with phy init/shutdown in this driver itself, are
>>>> you okay with moving the extcon handling code
>>>> out of phy ops ?
>>>
>>> yeah, For e.g., ns2_drd_phy_init is part of phy_ops and is being invoked from
>>> extcon events too. Can a phy which is initialized by a phy consumer (say your
>>> UDC invokes phy_init) can be shutdown by an extcon event?
>>>
>>> Maybe a clear explanation of when phy_ops here will be invoked and when it will
>>> set using extcon events might help.
>>>
>>
>> Say, we have a USB pendrive which is connected to the DRD port through
>> a host cable.
>> Now the PHY will be initialized to be in host mode.
>> When the pendrive is unplugged, and we now connect the NS2 device to
>> some linux PC,
>> now the PHY has to be shutdown, and re-initialized to be in Device mode.
>>
>> On unplug event, it is set neither to Host nor Device mode (basically
>> shutdown). Next time which ever cable is connected, the PHY is
>> initialized to the respective
>> mode.
>>
>> Please let me know if it's fine to do these initializations outside
>> phy ops, because those will
>> be irrelevant for phy consumers (the controllers) as it's anyways
>> dealt in the phy driver through
>> extcon.
>
> How does the consumer get to know whether they have to operate in host mode or
> device mode?
>
In NS2, we have host controllers and device controller (not OTG/other
that can switch
between host and device mode). It's only phy that can be in host/device mode.
Since both Host Controllers and Device Controller are connected to the same PHY,
it is based on the extcon logic (the type of cable connected) that PHY
will be in one
of the modes host/device and the respective controller will operate.

> Thanks
> Kishon

Re: [PATCH v4 2/3] Broadcom USB DRD Phy driver for Northstar2

[Kishon Vijay Abraham I]

Hi,

On Monday 10 April 2017 12:57 PM, Raviteja Garimella wrote:
> Hi,
> 
> On Mon, Apr 10, 2017 at 10:55 AM, Kishon Vijay Abraham I <kishon@ti.com> wrote:
>> Hi,
>>
>> On Wednesday 05 April 2017 07:40 PM, Raviteja Garimella wrote:
>>> Hi Kishon,
>>>
>>> On Wed, Apr 5, 2017 at 7:04 PM, Kishon Vijay Abraham I <kishon@ti.com> wrote:
>>>> Hi Ravi,
>>>>
>>>> On Wednesday 05 April 2017 06:30 PM, Raviteja Garimella wrote:
>>>>> Hi Kishon,
>>>>>
>>>>> On Wed, Apr 5, 2017 at 4:30 PM, Kishon Vijay Abraham I <kishon@ti.com> wrote:
>>>>>> Hi,
>>>>>>
>>>>>> On Tuesday 28 March 2017 05:57 PM, Raviteja Garimella wrote:
>>>>>>> This is driver for USB DRD Phy used in Broadcom's Northstar2
>>>>>>> SoC. The phy can be configured to be in Device mode or Host
>>>>>>> mode based on the type of cable connected to the port. The
>>>>>>> driver registers to  extcon framework to get appropriate
>>>>>>> connect events for Host/Device cables connect/disconnect
>>>>>>> states based on VBUS and ID interrupts.
>>>>>>
>>>>>> $patch should be phy: phy-bcm-ns2-usbdrd: USB DRD Phy driver for Broadcoms
>>>>>> Northstar2.
>>>>>>
>>>>>
>>>>> Will do.
>>>>>
>>>>>> Sorry for not letting you know this earlier. But I feel the design of the
>>>>>> driver should be changed. Extcon shouldn't be used here. The extcon
>>>>>> notifications should be sent to the consumer driver and the consumer driver
>>>>>> should be responsible for invoking the phy ops.
>>>>>>
>>>>>
>>>>> The consumer drivers here would be a UDC driver (USB device
>>>>> controller), EHCI and OHCI host controller drivers.
>>>>> I was already suggested in UDC driver review to deal with extcon in Phy driver.
>>>>>
>>>>> This phy connects to 2 host controllers, and one device controller.
>>>>> That's the design in Broadcom Northstar2
>>>>> platform. The values of the VBUS and ID pins of this port are
>>>>> determined based on the type of the cable (device cable
>>>>> or host cable). And. phy has to be configured accordingly.
>>>>>
>>>>>> The phy ops being invoked during extcon events doesn't look right.
>>>>>
>>>>> Could you please elaborate on the concern, so that we can think of
>>>>> mitigating those issues in this driver?
>>>>> Since we are dealing with phy init/shutdown in this driver itself, are
>>>>> you okay with moving the extcon handling code
>>>>> out of phy ops ?
>>>>
>>>> yeah, For e.g., ns2_drd_phy_init is part of phy_ops and is being invoked from
>>>> extcon events too. Can a phy which is initialized by a phy consumer (say your
>>>> UDC invokes phy_init) can be shutdown by an extcon event?
>>>>
>>>> Maybe a clear explanation of when phy_ops here will be invoked and when it will
>>>> set using extcon events might help.
>>>>
>>>
>>> Say, we have a USB pendrive which is connected to the DRD port through
>>> a host cable.
>>> Now the PHY will be initialized to be in host mode.
>>> When the pendrive is unplugged, and we now connect the NS2 device to
>>> some linux PC,
>>> now the PHY has to be shutdown, and re-initialized to be in Device mode.
>>>
>>> On unplug event, it is set neither to Host nor Device mode (basically
>>> shutdown). Next time which ever cable is connected, the PHY is
>>> initialized to the respective
>>> mode.
>>>
>>> Please let me know if it's fine to do these initializations outside
>>> phy ops, because those will
>>> be irrelevant for phy consumers (the controllers) as it's anyways
>>> dealt in the phy driver through
>>> extcon.
>>
>> How does the consumer get to know whether they have to operate in host mode or
>> device mode?
>>
> In NS2, we have host controllers and device controller (not OTG/other
> that can switch
> between host and device mode). It's only phy that can be in host/device mode.
> Since both Host Controllers and Device Controller are connected to the same PHY,
> it is based on the extcon logic (the type of cable connected) that PHY
> will be in one
> of the modes host/device and the respective controller will operate.

So at a point of time either the host controller or the device controller will
be active? and the PHY decides which of them should be active? Is that right?

Thanks
Kishon

Re: [PATCH v4 2/3] Broadcom USB DRD Phy driver for Northstar2

[Raviteja Garimella]

Hi

On Mon, Apr 10, 2017 at 1:57 PM, Kishon Vijay Abraham I <kishon@ti.com> wrote:
> Hi,
>
> On Monday 10 April 2017 12:57 PM, Raviteja Garimella wrote:
>> Hi,
>>
>> On Mon, Apr 10, 2017 at 10:55 AM, Kishon Vijay Abraham I <kishon@ti.com> wrote:
>>> Hi,
>>>
>>> On Wednesday 05 April 2017 07:40 PM, Raviteja Garimella wrote:
>>>> Hi Kishon,
>>>>
>>>> On Wed, Apr 5, 2017 at 7:04 PM, Kishon Vijay Abraham I <kishon@ti.com> wrote:
>>>>> Hi Ravi,
>>>>>
>>>>> On Wednesday 05 April 2017 06:30 PM, Raviteja Garimella wrote:
>>>>>> Hi Kishon,
>>>>>>
>>>>>> On Wed, Apr 5, 2017 at 4:30 PM, Kishon Vijay Abraham I <kishon@ti.com> wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> On Tuesday 28 March 2017 05:57 PM, Raviteja Garimella wrote:
>>>>>>>> This is driver for USB DRD Phy used in Broadcom's Northstar2
>>>>>>>> SoC. The phy can be configured to be in Device mode or Host
>>>>>>>> mode based on the type of cable connected to the port. The
>>>>>>>> driver registers to  extcon framework to get appropriate
>>>>>>>> connect events for Host/Device cables connect/disconnect
>>>>>>>> states based on VBUS and ID interrupts.
>>>>>>>
>>>>>>> $patch should be phy: phy-bcm-ns2-usbdrd: USB DRD Phy driver for Broadcoms
>>>>>>> Northstar2.
>>>>>>>
>>>>>>
>>>>>> Will do.
>>>>>>
>>>>>>> Sorry for not letting you know this earlier. But I feel the design of the
>>>>>>> driver should be changed. Extcon shouldn't be used here. The extcon
>>>>>>> notifications should be sent to the consumer driver and the consumer driver
>>>>>>> should be responsible for invoking the phy ops.
>>>>>>>
>>>>>>
>>>>>> The consumer drivers here would be a UDC driver (USB device
>>>>>> controller), EHCI and OHCI host controller drivers.
>>>>>> I was already suggested in UDC driver review to deal with extcon in Phy driver.
>>>>>>
>>>>>> This phy connects to 2 host controllers, and one device controller.
>>>>>> That's the design in Broadcom Northstar2
>>>>>> platform. The values of the VBUS and ID pins of this port are
>>>>>> determined based on the type of the cable (device cable
>>>>>> or host cable). And. phy has to be configured accordingly.
>>>>>>
>>>>>>> The phy ops being invoked during extcon events doesn't look right.
>>>>>>
>>>>>> Could you please elaborate on the concern, so that we can think of
>>>>>> mitigating those issues in this driver?
>>>>>> Since we are dealing with phy init/shutdown in this driver itself, are
>>>>>> you okay with moving the extcon handling code
>>>>>> out of phy ops ?
>>>>>
>>>>> yeah, For e.g., ns2_drd_phy_init is part of phy_ops and is being invoked from
>>>>> extcon events too. Can a phy which is initialized by a phy consumer (say your
>>>>> UDC invokes phy_init) can be shutdown by an extcon event?
>>>>>
>>>>> Maybe a clear explanation of when phy_ops here will be invoked and when it will
>>>>> set using extcon events might help.
>>>>>
>>>>
>>>> Say, we have a USB pendrive which is connected to the DRD port through
>>>> a host cable.
>>>> Now the PHY will be initialized to be in host mode.
>>>> When the pendrive is unplugged, and we now connect the NS2 device to
>>>> some linux PC,
>>>> now the PHY has to be shutdown, and re-initialized to be in Device mode.
>>>>
>>>> On unplug event, it is set neither to Host nor Device mode (basically
>>>> shutdown). Next time which ever cable is connected, the PHY is
>>>> initialized to the respective
>>>> mode.
>>>>
>>>> Please let me know if it's fine to do these initializations outside
>>>> phy ops, because those will
>>>> be irrelevant for phy consumers (the controllers) as it's anyways
>>>> dealt in the phy driver through
>>>> extcon.
>>>
>>> How does the consumer get to know whether they have to operate in host mode or
>>> device mode?
>>>
>> In NS2, we have host controllers and device controller (not OTG/other
>> that can switch
>> between host and device mode). It's only phy that can be in host/device mode.
>> Since both Host Controllers and Device Controller are connected to the same PHY,
>> it is based on the extcon logic (the type of cable connected) that PHY
>> will be in one
>> of the modes host/device and the respective controller will operate.
>
> So at a point of time either the host controller or the device controller will
> be active? and the PHY decides which of them should be active? Is that right?
>

Yes

Thanks,
Ravi

> Thanks
> Kishon

Re: [PATCH v4 2/3] Broadcom USB DRD Phy driver for Northstar2

[Kishon Vijay Abraham I]

Hi,

On Wednesday 05 April 2017 07:40 PM, Raviteja Garimella wrote:
> Hi Kishon,
> 
> On Wed, Apr 5, 2017 at 7:04 PM, Kishon Vijay Abraham I <kishon@ti.com> wrote:
>> Hi Ravi,
>>
>> On Wednesday 05 April 2017 06:30 PM, Raviteja Garimella wrote:
>>> Hi Kishon,
>>>
>>> On Wed, Apr 5, 2017 at 4:30 PM, Kishon Vijay Abraham I <kishon@ti.com> wrote:
>>>> Hi,
>>>>
>>>> On Tuesday 28 March 2017 05:57 PM, Raviteja Garimella wrote:
>>>>> This is driver for USB DRD Phy used in Broadcom's Northstar2
>>>>> SoC. The phy can be configured to be in Device mode or Host
>>>>> mode based on the type of cable connected to the port. The
>>>>> driver registers to  extcon framework to get appropriate
>>>>> connect events for Host/Device cables connect/disconnect
>>>>> states based on VBUS and ID interrupts.
>>>>
>>>> $patch should be phy: phy-bcm-ns2-usbdrd: USB DRD Phy driver for Broadcoms
>>>> Northstar2.
>>>>
>>>
>>> Will do.
>>>
>>>> Sorry for not letting you know this earlier. But I feel the design of the
>>>> driver should be changed. Extcon shouldn't be used here. The extcon
>>>> notifications should be sent to the consumer driver and the consumer driver
>>>> should be responsible for invoking the phy ops.
>>>>
>>>
>>> The consumer drivers here would be a UDC driver (USB device
>>> controller), EHCI and OHCI host controller drivers.
>>> I was already suggested in UDC driver review to deal with extcon in Phy driver.
>>>
>>> This phy connects to 2 host controllers, and one device controller.
>>> That's the design in Broadcom Northstar2
>>> platform. The values of the VBUS and ID pins of this port are
>>> determined based on the type of the cable (device cable
>>> or host cable). And. phy has to be configured accordingly.
>>>
>>>> The phy ops being invoked during extcon events doesn't look right.
>>>
>>> Could you please elaborate on the concern, so that we can think of
>>> mitigating those issues in this driver?
>>> Since we are dealing with phy init/shutdown in this driver itself, are
>>> you okay with moving the extcon handling code
>>> out of phy ops ?
>>
>> yeah, For e.g., ns2_drd_phy_init is part of phy_ops and is being invoked from
>> extcon events too. Can a phy which is initialized by a phy consumer (say your
>> UDC invokes phy_init) can be shutdown by an extcon event?
>>
>> Maybe a clear explanation of when phy_ops here will be invoked and when it will
>> set using extcon events might help.
>>
> 
> Say, we have a USB pendrive which is connected to the DRD port through
> a host cable.
> Now the PHY will be initialized to be in host mode.
> When the pendrive is unplugged, and we now connect the NS2 device to
> some linux PC,
> now the PHY has to be shutdown, and re-initialized to be in Device mode.
> 
> On unplug event, it is set neither to Host nor Device mode (basically
> shutdown). Next time which ever cable is connected, the PHY is
> initialized to the respective
> mode.
> 
> Please let me know if it's fine to do these initializations outside
> phy ops, because those will
> be irrelevant for phy consumers (the controllers) as it's anyways
> dealt in the phy driver through
> extcon.

Yes. We shouldn't add phy_ops just for the sake of it. I think this should be
made as a purely extcon driver (though there are a couple of bits that looks
like initializing PHY) and keep it in drivers/extcon.

Thanks
Kishon

Re: [PATCH v4 2/3] Broadcom USB DRD Phy driver for Northstar2

[Raviteja Garimella]

Hi,

On Mon, Apr 10, 2017 at 2:07 PM, Kishon Vijay Abraham I <kishon@ti.com> wrote:
> Hi,
>
> On Wednesday 05 April 2017 07:40 PM, Raviteja Garimella wrote:
>> Hi Kishon,
>>
>> On Wed, Apr 5, 2017 at 7:04 PM, Kishon Vijay Abraham I <kishon@ti.com> wrote:
>>> Hi Ravi,
>>>
>>> On Wednesday 05 April 2017 06:30 PM, Raviteja Garimella wrote:
>>>> Hi Kishon,
>>>>
>>>> On Wed, Apr 5, 2017 at 4:30 PM, Kishon Vijay Abraham I <kishon@ti.com> wrote:
>>>>> Hi,
>>>>>
>>>>> On Tuesday 28 March 2017 05:57 PM, Raviteja Garimella wrote:
>>>>>> This is driver for USB DRD Phy used in Broadcom's Northstar2
>>>>>> SoC. The phy can be configured to be in Device mode or Host
>>>>>> mode based on the type of cable connected to the port. The
>>>>>> driver registers to  extcon framework to get appropriate
>>>>>> connect events for Host/Device cables connect/disconnect
>>>>>> states based on VBUS and ID interrupts.
>>>>>
>>>>> $patch should be phy: phy-bcm-ns2-usbdrd: USB DRD Phy driver for Broadcoms
>>>>> Northstar2.
>>>>>
>>>>
>>>> Will do.
>>>>
>>>>> Sorry for not letting you know this earlier. But I feel the design of the
>>>>> driver should be changed. Extcon shouldn't be used here. The extcon
>>>>> notifications should be sent to the consumer driver and the consumer driver
>>>>> should be responsible for invoking the phy ops.
>>>>>
>>>>
>>>> The consumer drivers here would be a UDC driver (USB device
>>>> controller), EHCI and OHCI host controller drivers.
>>>> I was already suggested in UDC driver review to deal with extcon in Phy driver.
>>>>
>>>> This phy connects to 2 host controllers, and one device controller.
>>>> That's the design in Broadcom Northstar2
>>>> platform. The values of the VBUS and ID pins of this port are
>>>> determined based on the type of the cable (device cable
>>>> or host cable). And. phy has to be configured accordingly.
>>>>
>>>>> The phy ops being invoked during extcon events doesn't look right.
>>>>
>>>> Could you please elaborate on the concern, so that we can think of
>>>> mitigating those issues in this driver?
>>>> Since we are dealing with phy init/shutdown in this driver itself, are
>>>> you okay with moving the extcon handling code
>>>> out of phy ops ?
>>>
>>> yeah, For e.g., ns2_drd_phy_init is part of phy_ops and is being invoked from
>>> extcon events too. Can a phy which is initialized by a phy consumer (say your
>>> UDC invokes phy_init) can be shutdown by an extcon event?
>>>
>>> Maybe a clear explanation of when phy_ops here will be invoked and when it will
>>> set using extcon events might help.
>>>
>>
>> Say, we have a USB pendrive which is connected to the DRD port through
>> a host cable.
>> Now the PHY will be initialized to be in host mode.
>> When the pendrive is unplugged, and we now connect the NS2 device to
>> some linux PC,
>> now the PHY has to be shutdown, and re-initialized to be in Device mode.
>>
>> On unplug event, it is set neither to Host nor Device mode (basically
>> shutdown). Next time which ever cable is connected, the PHY is
>> initialized to the respective
>> mode.
>>
>> Please let me know if it's fine to do these initializations outside
>> phy ops, because those will
>> be irrelevant for phy consumers (the controllers) as it's anyways
>> dealt in the phy driver through
>> extcon.
>
> Yes. We shouldn't add phy_ops just for the sake of it. I think this should be
> made as a purely extcon driver (though there are a couple of bits that looks
> like initializing PHY) and keep it in drivers/extcon.
>

Actually phy_ops would be required when we want phy to be shutdown/init
during power management, where USB controllers would call them.

I reworked on this driver to address the concerns raised here. Please check
PATCH v5 that I will submit shortly.
If we want to dynamically change the mode of PHY either to be in host mode
or device mode or idle, we don't have to do a full PHY init/power on (that
earlier required doing a PHY PLL lock and other resets). We just have to
program couple of register bits that are dedicated for this purpose.
I made those changes, now we don't have to call phy ops in the driver.
Phy_ops will be called only by the consumer drivers.

Thanks,
Ravi

> Thanks
> Kishon