* [PATCH RFC 1/4] phy: Add new Exynos5 USB 3.0 PHY driver
2013-10-31 7:45 ` [PATCH RFC 1/4] phy: Add new Exynos5 USB 3.0 PHY driver Vivek Gautam
@ 2013-11-04 6:54 ` Kishon Vijay Abraham I
2013-11-04 10:15 ` Kamil Debski
2013-11-04 12:26 ` Tomasz Figa
2013-11-10 14:08 ` Tomasz Figa
2013-11-21 12:26 ` Yuvaraj Cd
2 siblings, 2 replies; 36+ messages in thread
From: Kishon Vijay Abraham I @ 2013-11-04 6:54 UTC (permalink / raw)
To: linux-arm-kernel
Hi Vivek,
On Thursday 31 October 2013 01:15 PM, Vivek Gautam wrote:
> Add a new driver for the USB 3.0 PHY on Exynos5 series of SoCs.
> The new driver uses the generic PHY framework and will interact
> with DWC3 controller present on Exynos5 series of SoCs.
In Exynos, you have a single IP that supports both USB3 and USB2 PHY
right? I think that needs to be mentioned here.
Do you have separate registers that should be used for
initializing/powerin_on/powering_off etc.. for usb2 phy and usb3 phy? If
so, then you should model this driver as a single driver that supports
two PHYs similar to what Sylwester has done before?
Cheers
Kishon
>
> Signed-off-by: Vivek Gautam <gautam.vivek@samsung.com>
> ---
> .../devicetree/bindings/phy/samsung-phy.txt | 20 +
> drivers/phy/Kconfig | 7 +
> drivers/phy/Makefile | 1 +
> drivers/phy/phy-exynos5-usb3.c | 562 ++++++++++++++++++++
> 4 files changed, 590 insertions(+), 0 deletions(-)
> create mode 100644 drivers/phy/phy-exynos5-usb3.c
>
> diff --git a/Documentation/devicetree/bindings/phy/samsung-phy.txt b/Documentation/devicetree/bindings/phy/samsung-phy.txt
> index c0fccaa..9b5c111 100644
> --- a/Documentation/devicetree/bindings/phy/samsung-phy.txt
> +++ b/Documentation/devicetree/bindings/phy/samsung-phy.txt
> @@ -20,3 +20,23 @@ Required properties:
> - compatible : should be "samsung,exynos5250-dp-video-phy";
> - reg : offset and length of the Display Port PHY register set;
> - #phy-cells : from the generic PHY bindings, must be 0;
> +
> +Samsung Exynos5 SoC seiries USB 3.0 PHY controller
> +--------------------------------------------------
> +
> +Required properties:
> +- compatible :
> + should be "samsung,exynos5250-usb3phy" for exynos5250 SoC
> + should be "samsung,exynos5420-usb3phy" for exynos5420 SoC
> +- reg : Register offset and length array
> + - first field corresponds to USB 3.0 PHY register set;
> + - second field corresponds to PHY power isolation register
> + present in PMU;
> +- clocks: Clock IDs array as required by the controller
> +- clock-names: names of clocks correseponding to IDs in the clock property;
> + Required clocks:
> + - first clock is main PHY clock (same as USB 3.0 controller IP clock)
> + - second clock is reference clock (usually crystal clock)
> + optional clock:
> + - third clock is special clock used by PHY for operation
> +- #phy-cells : from the generic PHY bindings, must be 0;
> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
> index a344f3d..9a100c6 100644
> --- a/drivers/phy/Kconfig
> +++ b/drivers/phy/Kconfig
> @@ -51,4 +51,11 @@ config PHY_EXYNOS_DP_VIDEO
> help
> Support for Display Port PHY found on Samsung EXYNOS SoCs.
>
> +config PHY_EXYNOS5_USB3
> + tristate "Exynos5 SoC series USB 3.0 PHY driver"
> + depends on ARCH_EXYNOS5
> + select GENERIC_PHY
> + help
> + Enable USB 3.0 PHY support for Exynos 5 SoC series
> +
> endmenu
> diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
> index d0caae9..9c06a61 100644
> --- a/drivers/phy/Makefile
> +++ b/drivers/phy/Makefile
> @@ -7,3 +7,4 @@ obj-$(CONFIG_PHY_EXYNOS_DP_VIDEO) += phy-exynos-dp-video.o
> obj-$(CONFIG_PHY_EXYNOS_MIPI_VIDEO) += phy-exynos-mipi-video.o
> obj-$(CONFIG_OMAP_USB2) += phy-omap-usb2.o
> obj-$(CONFIG_TWL4030_USB) += phy-twl4030-usb.o
> +obj-$(CONFIG_PHY_EXYNOS5_USB3) += phy-exynos5-usb3.o
> diff --git a/drivers/phy/phy-exynos5-usb3.c b/drivers/phy/phy-exynos5-usb3.c
> new file mode 100644
> index 0000000..b9a2674
> --- /dev/null
> +++ b/drivers/phy/phy-exynos5-usb3.c
> @@ -0,0 +1,562 @@
> +/*
> + * Samsung EXYNOS5 SoC series USB 3.0 PHY driver
> + *
> + * Copyright (C) 2013 Samsung Electronics Co., Ltd.
> + * Author: Vivek Gautam <gautam.vivek@samsung.com>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#include <linux/clk.h>
> +#include <linux/delay.h>
> +#include <linux/io.h>
> +#include <linux/kernel.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/mutex.h>
> +
> +/* Exynos USB PHY registers */
> +#define EXYNOS5_FSEL_9MHZ6 0x0
> +#define EXYNOS5_FSEL_10MHZ 0x1
> +#define EXYNOS5_FSEL_12MHZ 0x2
> +#define EXYNOS5_FSEL_19MHZ2 0x3
> +#define EXYNOS5_FSEL_20MHZ 0x4
> +#define EXYNOS5_FSEL_24MHZ 0x5
> +#define EXYNOS5_FSEL_50MHZ 0x7
> +
> +/* EXYNOS5: USB 3.0 DRD PHY registers */
> +#define EXYNOS5_DRD_LINKSYSTEM (0x04)
> +
> +#define LINKSYSTEM_FLADJ_MASK (0x3f << 1)
> +#define LINKSYSTEM_FLADJ(_x) ((_x) << 1)
> +#define LINKSYSTEM_XHCI_VERSION_CONTROL (0x1 << 27)
> +
> +#define EXYNOS5_DRD_PHYUTMI (0x08)
> +
> +#define PHYUTMI_OTGDISABLE (0x1 << 6)
> +#define PHYUTMI_FORCESUSPEND (0x1 << 1)
> +#define PHYUTMI_FORCESLEEP (0x1 << 0)
> +
> +#define EXYNOS5_DRD_PHYPIPE (0x0c)
> +
> +#define EXYNOS5_DRD_PHYCLKRST (0x10)
> +
> +#define PHYCLKRST_SSC_REFCLKSEL_MASK (0xff << 23)
> +#define PHYCLKRST_SSC_REFCLKSEL(_x) ((_x) << 23)
> +
> +#define PHYCLKRST_SSC_RANGE_MASK (0x03 << 21)
> +#define PHYCLKRST_SSC_RANGE(_x) ((_x) << 21)
> +
> +#define PHYCLKRST_SSC_EN (0x1 << 20)
> +#define PHYCLKRST_REF_SSP_EN (0x1 << 19)
> +#define PHYCLKRST_REF_CLKDIV2 (0x1 << 18)
> +
> +#define PHYCLKRST_MPLL_MULTIPLIER_MASK (0x7f << 11)
> +#define PHYCLKRST_MPLL_MULTIPLIER_100MHZ_REF (0x19 << 11)
> +#define PHYCLKRST_MPLL_MULTIPLIER_50M_REF (0x02 << 11)
> +#define PHYCLKRST_MPLL_MULTIPLIER_24MHZ_REF (0x68 << 11)
> +#define PHYCLKRST_MPLL_MULTIPLIER_20MHZ_REF (0x7d << 11)
> +#define PHYCLKRST_MPLL_MULTIPLIER_19200KHZ_REF (0x02 << 11)
> +
> +#define PHYCLKRST_FSEL_MASK (0x3f << 5)
> +#define PHYCLKRST_FSEL(_x) ((_x) << 5)
> +#define PHYCLKRST_FSEL_PAD_100MHZ (0x27 << 5)
> +#define PHYCLKRST_FSEL_PAD_24MHZ (0x2a << 5)
> +#define PHYCLKRST_FSEL_PAD_20MHZ (0x31 << 5)
> +#define PHYCLKRST_FSEL_PAD_19_2MHZ (0x38 << 5)
> +
> +#define PHYCLKRST_RETENABLEN (0x1 << 4)
> +
> +#define PHYCLKRST_REFCLKSEL_MASK (0x03 << 2)
> +#define PHYCLKRST_REFCLKSEL_PAD_REFCLK (0x2 << 2)
> +#define PHYCLKRST_REFCLKSEL_EXT_REFCLK (0x3 << 2)
> +
> +#define PHYCLKRST_PORTRESET (0x1 << 1)
> +#define PHYCLKRST_COMMONONN (0x1 << 0)
> +
> +#define EXYNOS5_DRD_PHYREG0 (0x14)
> +#define EXYNOS5_DRD_PHYREG1 (0x18)
> +
> +#define EXYNOS5_DRD_PHYPARAM0 (0x1c)
> +
> +#define PHYPARAM0_REF_USE_PAD (0x1 << 31)
> +#define PHYPARAM0_REF_LOSLEVEL_MASK (0x1f << 26)
> +#define PHYPARAM0_REF_LOSLEVEL (0x9 << 26)
> +
> +#define EXYNOS5_DRD_PHYPARAM1 (0x20)
> +
> +#define PHYPARAM1_PCS_TXDEEMPH_MASK (0x1f << 0)
> +#define PHYPARAM1_PCS_TXDEEMPH (0x1c)
> +
> +#define EXYNOS5_DRD_PHYTERM (0x24)
> +
> +#define EXYNOS5_DRD_PHYTEST (0x28)
> +
> +#define PHYTEST_POWERDOWN_SSP (0x1 << 3)
> +#define PHYTEST_POWERDOWN_HSP (0x1 << 2)
> +
> +#define EXYNOS5_DRD_PHYADP (0x2c)
> +
> +#define EXYNOS5_DRD_PHYBATCHG (0x30)
> +
> +#define PHYBATCHG_UTMI_CLKSEL (0x1 << 2)
> +
> +#define EXYNOS5_DRD_PHYRESUME (0x34)
> +#define EXYNOS5_DRD_LINKPORT (0x44)
> +
> +
> +/* Isolation, configured in the power management unit */
> +#define EXYNOS5_USB_ISOL_DRD (1 << 0)
> +
> +#define CLKSEL_ERROR -1
> +
> +#ifndef KHZ
> +#define KHZ 1000
> +#endif
> +
> +#ifndef MHZ
> +#define MHZ (KHZ * KHZ)
> +#endif
> +
> +enum samsung_cpu_type {
> + TYPE_EXYNOS5250,
> + TYPE_EXYNOS5420,
> +};
> +
> +enum usb3phy_state {
> + STATE_OFF,
> + STATE_ON,
> +};
> +
> +struct usb3phy_config {
> + enum samsung_cpu_type cpu;
> + bool has_sclk_usbphy30;
> +};
> +
> +struct usb3phy_instance {
> + char *label;
> + struct usb3phy_driver *drv;
> + struct phy *phy;
> + enum usb3phy_state state;
> + u32 clk;
> + unsigned long rate;
> +};
> +
> +struct usb3phy_driver {
> + struct device *dev;
> + void __iomem *reg_phy;
> + void __iomem *reg_isol;
> + struct clk *clk;
> + struct clk *sclk_usbphy30;
> + struct usb3phy_instance instance;
> +};
> +
> +/*
> + * exynos5_rate_to_clk() converts the supplied clock rate to the value that
> + * can be written to the phy register.
> + */
> +static u32 exynos5_rate_to_clk(unsigned long rate)
> +{
> + unsigned int clksel;
> +
> + /* EXYNOS5_FSEL_MASK */
> +
> + switch (rate) {
> + case 9600 * KHZ:
> + clksel = EXYNOS5_FSEL_9MHZ6;
> + break;
> + case 10 * MHZ:
> + clksel = EXYNOS5_FSEL_10MHZ;
> + break;
> + case 12 * MHZ:
> + clksel = EXYNOS5_FSEL_12MHZ;
> + break;
> + case 19200 * KHZ:
> + clksel = EXYNOS5_FSEL_19MHZ2;
> + break;
> + case 20 * MHZ:
> + clksel = EXYNOS5_FSEL_20MHZ;
> + break;
> + case 24 * MHZ:
> + clksel = EXYNOS5_FSEL_24MHZ;
> + break;
> + case 50 * MHZ:
> + clksel = EXYNOS5_FSEL_50MHZ;
> + break;
> + default:
> + clksel = CLKSEL_ERROR;
> + }
> +
> + return clksel;
> +}
> +
> +static void exynos5_usb3phy_isol(struct usb3phy_instance *inst, bool on)
> +{
> + struct usb3phy_driver *drv = inst->drv;
> + u32 tmp;
> +
> + if (!drv->reg_isol)
> + return;
> +
> + tmp = readl(drv->reg_isol);
> + if (on)
> + tmp &= ~EXYNOS5_USB_ISOL_DRD;
> + else
> + tmp |= EXYNOS5_USB_ISOL_DRD;
> + writel(tmp, drv->reg_isol);
> +}
> +
> +/*
> + * Sets the phy clk as EXTREFCLK (XXTI) which is internal clock from clock core.
> + */
> +static u32 exynos5_usb3phy_set_refclk(struct usb3phy_instance *inst)
> +{
> + u32 reg;
> + u32 refclk;
> +
> + refclk = inst->clk;
> +
> + reg = PHYCLKRST_REFCLKSEL_EXT_REFCLK |
> + PHYCLKRST_FSEL(refclk);
> +
> + switch (refclk) {
> + case EXYNOS5_FSEL_50MHZ:
> + reg |= (PHYCLKRST_MPLL_MULTIPLIER_50M_REF |
> + PHYCLKRST_SSC_REFCLKSEL(0x00));
> + break;
> + case EXYNOS5_FSEL_20MHZ:
> + reg |= (PHYCLKRST_MPLL_MULTIPLIER_20MHZ_REF |
> + PHYCLKRST_SSC_REFCLKSEL(0x00));
> + break;
> + case EXYNOS5_FSEL_19MHZ2:
> + reg |= (PHYCLKRST_MPLL_MULTIPLIER_19200KHZ_REF |
> + PHYCLKRST_SSC_REFCLKSEL(0x88));
> + break;
> + case EXYNOS5_FSEL_24MHZ:
> + default:
> + reg |= (PHYCLKRST_MPLL_MULTIPLIER_24MHZ_REF |
> + PHYCLKRST_SSC_REFCLKSEL(0x88));
> + break;
> + }
> +
> + return reg;
> +}
> +
> +static void exynos5_usb3phy_init(struct usb3phy_instance *inst)
> +{
> + struct usb3phy_driver *drv = inst->drv;
> + u32 phyparam0;
> + u32 phyparam1;
> + u32 linksystem;
> + u32 phybatchg;
> + u32 phytest;
> + u32 phyclkrst;
> +
> + /* Reset USB 3.0 PHY */
> + writel(0x0, drv->reg_phy + EXYNOS5_DRD_PHYREG0);
> +
> + phyparam0 = readl(drv->reg_phy + EXYNOS5_DRD_PHYPARAM0);
> + /* Select PHY CLK source */
> + phyparam0 &= ~PHYPARAM0_REF_USE_PAD;
> + /* Set Loss-of-Signal Detector sensitivity */
> + phyparam0 &= ~PHYPARAM0_REF_LOSLEVEL_MASK;
> + phyparam0 |= PHYPARAM0_REF_LOSLEVEL;
> + writel(phyparam0, drv->reg_phy + EXYNOS5_DRD_PHYPARAM0);
> +
> + writel(0x0, drv->reg_phy + EXYNOS5_DRD_PHYRESUME);
> +
> + /*
> + * Setting the Frame length Adj value[6:1] to default 0x20
> + * See xHCI 1.0 spec, 5.2.4
> + */
> + linksystem = LINKSYSTEM_XHCI_VERSION_CONTROL |
> + LINKSYSTEM_FLADJ(0x20);
> + writel(linksystem, drv->reg_phy + EXYNOS5_DRD_LINKSYSTEM);
> +
> + phyparam1 = readl(drv->reg_phy + EXYNOS5_DRD_PHYPARAM1);
> + /* Set Tx De-Emphasis level */
> + phyparam1 &= ~PHYPARAM1_PCS_TXDEEMPH_MASK;
> + phyparam1 |= PHYPARAM1_PCS_TXDEEMPH;
> + writel(phyparam1, drv->reg_phy + EXYNOS5_DRD_PHYPARAM1);
> +
> + phybatchg = readl(drv->reg_phy + EXYNOS5_DRD_PHYBATCHG);
> + phybatchg |= PHYBATCHG_UTMI_CLKSEL;
> + writel(phybatchg, drv->reg_phy + EXYNOS5_DRD_PHYBATCHG);
> +
> + /* PHYTEST POWERDOWN Control */
> + phytest = readl(drv->reg_phy + EXYNOS5_DRD_PHYTEST);
> + phytest &= ~(PHYTEST_POWERDOWN_SSP |
> + PHYTEST_POWERDOWN_HSP);
> + writel(phytest, drv->reg_phy + EXYNOS5_DRD_PHYTEST);
> +
> + /* UTMI Power Control */
> + writel(PHYUTMI_OTGDISABLE, drv->reg_phy + EXYNOS5_DRD_PHYUTMI);
> +
> + phyclkrst = exynos5_usb3phy_set_refclk(inst);
> +
> + phyclkrst |= PHYCLKRST_PORTRESET |
> + /* Digital power supply in normal operating mode */
> + PHYCLKRST_RETENABLEN |
> + /* Enable ref clock for SS function */
> + PHYCLKRST_REF_SSP_EN |
> + /* Enable spread spectrum */
> + PHYCLKRST_SSC_EN |
> + /* Power down HS Bias and PLL blocks in suspend mode */
> + PHYCLKRST_COMMONONN;
> +
> + writel(phyclkrst, drv->reg_phy + EXYNOS5_DRD_PHYCLKRST);
> +
> + udelay(10);
> +
> + phyclkrst &= ~PHYCLKRST_PORTRESET;
> + writel(phyclkrst, drv->reg_phy + EXYNOS5_DRD_PHYCLKRST);
> +
> +}
> +
> +static void exynos5_usb3phy_exit(struct usb3phy_instance *inst)
> +{
> + struct usb3phy_driver *drv = inst->drv;
> + u32 phyutmi;
> + u32 phyclkrst;
> + u32 phytest;
> +
> + phyutmi = PHYUTMI_OTGDISABLE |
> + PHYUTMI_FORCESUSPEND |
> + PHYUTMI_FORCESLEEP;
> + writel(phyutmi, drv->reg_phy + EXYNOS5_DRD_PHYUTMI);
> +
> + /* Resetting the PHYCLKRST enable bits to reduce leakage current */
> + phyclkrst = readl(drv->reg_phy + EXYNOS5_DRD_PHYCLKRST);
> + phyclkrst &= ~(PHYCLKRST_REF_SSP_EN |
> + PHYCLKRST_SSC_EN |
> + PHYCLKRST_COMMONONN);
> + writel(phyclkrst, drv->reg_phy + EXYNOS5_DRD_PHYCLKRST);
> +
> + /* Control PHYTEST to remove leakage current */
> + phytest = readl(drv->reg_phy + EXYNOS5_DRD_PHYTEST);
> + phytest |= PHYTEST_POWERDOWN_SSP |
> + PHYTEST_POWERDOWN_HSP;
> + writel(phytest, drv->reg_phy + EXYNOS5_DRD_PHYTEST);
> +}
> +
> +static int exynos5_usb3phy_power_on(struct phy *phy)
> +{
> + struct usb3phy_instance *inst = phy_get_drvdata(phy);
> + struct usb3phy_driver *drv = inst->drv;
> + int ret;
> +
> + dev_info(drv->dev, "Request to power_on \"%s\" usb phy\n",
> + inst->label);
> +
> + if (drv->sclk_usbphy30)
> + clk_prepare_enable(drv->sclk_usbphy30);
> +
> + ret = clk_prepare_enable(drv->clk);
> + if (ret)
> + return ret;
> +
> + if (inst->state == STATE_ON) {
> + dev_err(drv->dev, "usb phy \"%s\" already on",
> + inst->label);
> + ret = -ENODEV;
> + goto err0;
> + }
> +
> + inst->state = STATE_ON;
> +
> + /* Initialize the PHY and power it ON */
> + exynos5_usb3phy_init(inst);
> + exynos5_usb3phy_isol(inst, 0);
> +
> +err0:
> + clk_disable_unprepare(drv->clk);
> +
> + return ret;
> +}
> +
> +static int exynos5_usb3phy_power_off(struct phy *phy)
> +{
> + struct usb3phy_instance *inst = phy_get_drvdata(phy);
> + struct usb3phy_driver *drv = inst->drv;
> + int ret;
> +
> + dev_info(drv->dev, "Request to power_off \"%s\" usb phy\n",
> + inst->label);
> + ret = clk_prepare_enable(drv->clk);
> + if (ret)
> + return ret;
> +
> + if (inst->state == STATE_OFF) {
> + dev_err(drv->dev, "usb phy \"%s\" already off",
> + inst->label);
> + ret = -ENODEV;
> + goto err0;
> + }
> +
> + inst->state = STATE_OFF;
> +
> + /* Power-off the PHY and de-initialize it */
> + exynos5_usb3phy_isol(inst, 1);
> + exynos5_usb3phy_exit(inst);
> +
> +err0:
> + clk_disable_unprepare(drv->clk);
> + if (drv->sclk_usbphy30)
> + clk_disable_unprepare(drv->sclk_usbphy30);
> +
> + return ret;
> +}
> +
> +static struct phy_ops exynos5_usb3phy_ops = {
> + .power_on = exynos5_usb3phy_power_on,
> + .power_off = exynos5_usb3phy_power_off,
> + .owner = THIS_MODULE,
> +};
> +
> +static const struct of_device_id exynos5_usb3phy_of_match[];
> +
> +static int exynos5_usb3phy_probe(struct platform_device *pdev)
> +{
> + struct device *dev = &pdev->dev;
> + struct usb3phy_driver *drv;
> + struct usb3phy_instance *inst;
> + struct phy_provider *phy_provider;
> + struct resource *res;
> + struct clk *clk;
> + const struct of_device_id *match;
> + const struct usb3phy_config *cfg;
> +
> + match = of_match_node(exynos5_usb3phy_of_match, pdev->dev.of_node);
> + if (!match) {
> + dev_err(dev, "of_match_node() failed\n");
> + return -EINVAL;
> + }
> + cfg = match->data;
> + if (!cfg) {
> + dev_err(dev, "Failed to get configuration\n");
> + return -EINVAL;
> + }
> +
> + drv = devm_kzalloc(dev, sizeof(struct usb3phy_driver), GFP_KERNEL);
> + if (!drv) {
> + dev_err(dev, "Failed to allocate memory\n");
> + return -ENOMEM;
> + }
> +
> + dev_set_drvdata(dev, drv);
> + drv->dev = dev;
> +
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + drv->reg_phy = devm_ioremap_resource(dev, res);
> + if (IS_ERR(drv->reg_phy)) {
> + dev_err(dev, "Failed to map register memory (phy)\n");
> + return PTR_ERR(drv->reg_phy);
> + }
> +
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
> + drv->reg_isol = devm_ioremap_resource(dev, res);
> + if (IS_ERR(drv->reg_isol)) {
> + dev_err(dev, "Failed to map register memory (isolation)\n");
> + return PTR_ERR(drv->reg_isol);
> + }
> +
> + phy_provider = devm_of_phy_provider_register(dev, of_phy_simple_xlate);
> + if (IS_ERR(phy_provider)) {
> + dev_err(drv->dev, "Failed to register phy provider\n");
> + return PTR_ERR(phy_provider);
> + }
> +
> + drv->clk = devm_clk_get(dev, "phy");
> + if (IS_ERR(drv->clk)) {
> + dev_err(dev, "Failed to get clock of phy controller\n");
> + return PTR_ERR(drv->clk);
> + }
> +
> + /*
> + * Exysno5420 SoC has an additional special clock, used for
> + * for USB 3.0 PHY operation, this clock goes to the PHY block
> + * as a reference clock to clock generation block of the controller.
> + */
> + if (cfg->has_sclk_usbphy30) {
> + drv->sclk_usbphy30 = devm_clk_get(dev, "sclk_usbphy30");
> + if (IS_ERR(drv->clk)) {
> + dev_err(dev, "Failed to get phy reference clock\n");
> + return PTR_ERR(drv->clk);
> + }
> + }
> +
> + inst = &drv->instance;
> + inst->drv = drv;
> + inst->label = "usb3drd";
> +
> + dev_info(dev, "Creating phy \"%s\"\n", inst->label);
> + inst->phy = devm_phy_create(dev, &exynos5_usb3phy_ops, NULL);
> + if (IS_ERR(inst->phy)) {
> + dev_err(drv->dev, "Failed to create usb3phy \"%s\"\n",
> + inst->label);
> + return PTR_ERR(inst->phy);
> + }
> +
> + phy_set_drvdata(inst->phy, inst);
> +
> + clk = clk_get(dev, inst->label);
> + if (IS_ERR(clk)) {
> + dev_err(dev, "Failed to get clock of \"%s\" phy\n",
> + inst->label);
> + return PTR_ERR(clk);
> + }
> +
> + inst->rate = clk_get_rate(clk);
> +
> + inst->clk = exynos5_rate_to_clk(inst->rate);
> + if (inst->clk == CLKSEL_ERROR) {
> + dev_err(dev, "Clock rate (%ld) not supported\n",
> + inst->rate);
> + clk_put(clk);
> + return -EINVAL;
> + }
> + clk_put(clk);
> +
> + return 0;
> +}
> +
> +const struct usb3phy_config exynos5420_usb3phy_cfg = {
> + .cpu = TYPE_EXYNOS5420,
> + .has_sclk_usbphy30 = true,
> +};
> +
> +const struct usb3phy_config exynos5250_usb3phy_cfg = {
> + .cpu = TYPE_EXYNOS5250,
> + .has_sclk_usbphy30 = false,
> +};
> +
> +static const struct of_device_id exynos5_usb3phy_of_match[] = {
> + {
> + .compatible = "samsung,exynos5250-usb3phy",
> + .data = &exynos5250_usb3phy_cfg
> + }, {
> + .compatible = "samsung,exynos5420-usb3phy",
> + .data = &exynos5420_usb3phy_cfg
> + },
> + { },
> +};
> +
> +static struct platform_driver exynos5_usb3phy_driver = {
> + .probe = exynos5_usb3phy_probe,
> + .driver = {
> + .of_match_table = exynos5_usb3phy_of_match,
> + .name = "exynos5-usb3phy",
> + .owner = THIS_MODULE,
> + }
> +};
> +
> +module_platform_driver(exynos5_usb3phy_driver);
> +MODULE_DESCRIPTION("Samsung EXYNOS5 series SoC USB 3.0 PHY driver");
> +MODULE_AUTHOR("Vivek Gautam <gautam.vivek@samsung.com>");
> +MODULE_LICENSE("GPL v2");
> +MODULE_ALIAS("platform:exynos5-usb3phy");
>
^ permalink raw reply [flat|nested] 36+ messages in thread* [PATCH RFC 1/4] phy: Add new Exynos5 USB 3.0 PHY driver
2013-11-04 6:54 ` Kishon Vijay Abraham I
@ 2013-11-04 10:15 ` Kamil Debski
2013-11-04 13:12 ` Kishon Vijay Abraham I
2013-11-04 12:26 ` Tomasz Figa
1 sibling, 1 reply; 36+ messages in thread
From: Kamil Debski @ 2013-11-04 10:15 UTC (permalink / raw)
To: linux-arm-kernel
Hi Kishon,
> From: Kishon Vijay Abraham I [mailto:kishon at ti.com]
> Sent: Monday, November 04, 2013 7:55 AM
>
> Hi Vivek,
>
> On Thursday 31 October 2013 01:15 PM, Vivek Gautam wrote:
> > Add a new driver for the USB 3.0 PHY on Exynos5 series of SoCs.
> > The new driver uses the generic PHY framework and will interact with
> > DWC3 controller present on Exynos5 series of SoCs.
>
> In Exynos, you have a single IP that supports both USB3 and USB2 PHY
> right? I think that needs to be mentioned here.
As far as I know the IP is different.
> Do you have separate registers that should be used for
> initializing/powerin_on/powering_off etc.. for usb2 phy and usb3 phy?
> If so, then you should model this driver as a single driver that
> supports two PHYs similar to what Sylwester has done before?
Best wishes,
Kamil
> Cheers
> Kishon
>
> >
> > Signed-off-by: Vivek Gautam <gautam.vivek@samsung.com>
> > ---
> > .../devicetree/bindings/phy/samsung-phy.txt | 20 +
> > drivers/phy/Kconfig | 7 +
> > drivers/phy/Makefile | 1 +
> > drivers/phy/phy-exynos5-usb3.c | 562
> ++++++++++++++++++++
> > 4 files changed, 590 insertions(+), 0 deletions(-)
> > create mode 100644 drivers/phy/phy-exynos5-usb3.c
> >
> > diff --git a/Documentation/devicetree/bindings/phy/samsung-phy.txt
> > b/Documentation/devicetree/bindings/phy/samsung-phy.txt
> > index c0fccaa..9b5c111 100644
> > --- a/Documentation/devicetree/bindings/phy/samsung-phy.txt
> > +++ b/Documentation/devicetree/bindings/phy/samsung-phy.txt
> > @@ -20,3 +20,23 @@ Required properties:
> > - compatible : should be "samsung,exynos5250-dp-video-phy";
> > - reg : offset and length of the Display Port PHY register set;
> > - #phy-cells : from the generic PHY bindings, must be 0;
> > +
> > +Samsung Exynos5 SoC seiries USB 3.0 PHY controller
> > +--------------------------------------------------
> > +
> > +Required properties:
> > +- compatible :
> > + should be "samsung,exynos5250-usb3phy" for exynos5250 SoC
> > + should be "samsung,exynos5420-usb3phy" for exynos5420 SoC
> > +- reg : Register offset and length array
> > + - first field corresponds to USB 3.0 PHY register set;
> > + - second field corresponds to PHY power isolation register
> > + present in PMU;
> > +- clocks: Clock IDs array as required by the controller
> > +- clock-names: names of clocks correseponding to IDs in the clock
> property;
> > + Required clocks:
> > + - first clock is main PHY clock (same as USB 3.0 controller IP
> clock)
> > + - second clock is reference clock (usually crystal clock)
> > + optional clock:
> > + - third clock is special clock used by PHY for operation
> > +- #phy-cells : from the generic PHY bindings, must be 0;
> > diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig index
> > a344f3d..9a100c6 100644
> > --- a/drivers/phy/Kconfig
> > +++ b/drivers/phy/Kconfig
> > @@ -51,4 +51,11 @@ config PHY_EXYNOS_DP_VIDEO
> > help
> > Support for Display Port PHY found on Samsung EXYNOS SoCs.
> >
> > +config PHY_EXYNOS5_USB3
> > + tristate "Exynos5 SoC series USB 3.0 PHY driver"
> > + depends on ARCH_EXYNOS5
> > + select GENERIC_PHY
> > + help
> > + Enable USB 3.0 PHY support for Exynos 5 SoC series
> > +
> > endmenu
> > diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile index
> > d0caae9..9c06a61 100644
> > --- a/drivers/phy/Makefile
> > +++ b/drivers/phy/Makefile
> > @@ -7,3 +7,4 @@ obj-$(CONFIG_PHY_EXYNOS_DP_VIDEO) += phy-exynos-dp-
> video.o
> > obj-$(CONFIG_PHY_EXYNOS_MIPI_VIDEO) += phy-exynos-mipi-video.o
> > obj-$(CONFIG_OMAP_USB2) += phy-omap-usb2.o
> > obj-$(CONFIG_TWL4030_USB) += phy-twl4030-usb.o
> > +obj-$(CONFIG_PHY_EXYNOS5_USB3) += phy-exynos5-usb3.o
> > diff --git a/drivers/phy/phy-exynos5-usb3.c
> > b/drivers/phy/phy-exynos5-usb3.c new file mode 100644 index
> > 0000000..b9a2674
> > --- /dev/null
> > +++ b/drivers/phy/phy-exynos5-usb3.c
> > @@ -0,0 +1,562 @@
> > +/*
> > + * Samsung EXYNOS5 SoC series USB 3.0 PHY driver
> > + *
> > + * Copyright (C) 2013 Samsung Electronics Co., Ltd.
> > + * Author: Vivek Gautam <gautam.vivek@samsung.com>
> > + *
> > + * This program is free software; you can redistribute it and/or
> > +modify
> > + * it under the terms of the GNU General Public License version 2 as
> > + * published by the Free Software Foundation.
> > + */
> > +
> > +#include <linux/clk.h>
> > +#include <linux/delay.h>
> > +#include <linux/io.h>
> > +#include <linux/kernel.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/mutex.h>
> > +
> > +/* Exynos USB PHY registers */
> > +#define EXYNOS5_FSEL_9MHZ6 0x0
> > +#define EXYNOS5_FSEL_10MHZ 0x1
> > +#define EXYNOS5_FSEL_12MHZ 0x2
> > +#define EXYNOS5_FSEL_19MHZ2 0x3
> > +#define EXYNOS5_FSEL_20MHZ 0x4
> > +#define EXYNOS5_FSEL_24MHZ 0x5
> > +#define EXYNOS5_FSEL_50MHZ 0x7
> > +
> > +/* EXYNOS5: USB 3.0 DRD PHY registers */
> > +#define EXYNOS5_DRD_LINKSYSTEM (0x04)
> > +
> > +#define LINKSYSTEM_FLADJ_MASK (0x3f << 1)
> > +#define LINKSYSTEM_FLADJ(_x) ((_x) << 1)
> > +#define LINKSYSTEM_XHCI_VERSION_CONTROL (0x1 << 27)
> > +
> > +#define EXYNOS5_DRD_PHYUTMI (0x08)
> > +
> > +#define PHYUTMI_OTGDISABLE (0x1 << 6)
> > +#define PHYUTMI_FORCESUSPEND (0x1 << 1)
> > +#define PHYUTMI_FORCESLEEP (0x1 << 0)
> > +
> > +#define EXYNOS5_DRD_PHYPIPE (0x0c)
> > +
> > +#define EXYNOS5_DRD_PHYCLKRST (0x10)
> > +
> > +#define PHYCLKRST_SSC_REFCLKSEL_MASK (0xff << 23)
> > +#define PHYCLKRST_SSC_REFCLKSEL(_x) ((_x) << 23)
> > +
> > +#define PHYCLKRST_SSC_RANGE_MASK (0x03 << 21)
> > +#define PHYCLKRST_SSC_RANGE(_x) ((_x) << 21)
> > +
> > +#define PHYCLKRST_SSC_EN (0x1 << 20)
> > +#define PHYCLKRST_REF_SSP_EN (0x1 << 19)
> > +#define PHYCLKRST_REF_CLKDIV2 (0x1 << 18)
> > +
> > +#define PHYCLKRST_MPLL_MULTIPLIER_MASK (0x7f << 11)
> > +#define PHYCLKRST_MPLL_MULTIPLIER_100MHZ_REF (0x19 << 11)
> > +#define PHYCLKRST_MPLL_MULTIPLIER_50M_REF (0x02 << 11)
> > +#define PHYCLKRST_MPLL_MULTIPLIER_24MHZ_REF (0x68 << 11)
> > +#define PHYCLKRST_MPLL_MULTIPLIER_20MHZ_REF (0x7d << 11)
> > +#define PHYCLKRST_MPLL_MULTIPLIER_19200KHZ_REF (0x02 << 11)
> > +
> > +#define PHYCLKRST_FSEL_MASK (0x3f << 5)
> > +#define PHYCLKRST_FSEL(_x) ((_x) << 5)
> > +#define PHYCLKRST_FSEL_PAD_100MHZ (0x27 << 5)
> > +#define PHYCLKRST_FSEL_PAD_24MHZ (0x2a << 5)
> > +#define PHYCLKRST_FSEL_PAD_20MHZ (0x31 << 5)
> > +#define PHYCLKRST_FSEL_PAD_19_2MHZ (0x38 << 5)
> > +
> > +#define PHYCLKRST_RETENABLEN (0x1 << 4)
> > +
> > +#define PHYCLKRST_REFCLKSEL_MASK (0x03 << 2)
> > +#define PHYCLKRST_REFCLKSEL_PAD_REFCLK (0x2 << 2)
> > +#define PHYCLKRST_REFCLKSEL_EXT_REFCLK (0x3 << 2)
> > +
> > +#define PHYCLKRST_PORTRESET (0x1 << 1)
> > +#define PHYCLKRST_COMMONONN (0x1 << 0)
> > +
> > +#define EXYNOS5_DRD_PHYREG0 (0x14)
> > +#define EXYNOS5_DRD_PHYREG1 (0x18)
> > +
> > +#define EXYNOS5_DRD_PHYPARAM0 (0x1c)
> > +
> > +#define PHYPARAM0_REF_USE_PAD (0x1 << 31)
> > +#define PHYPARAM0_REF_LOSLEVEL_MASK (0x1f << 26)
> > +#define PHYPARAM0_REF_LOSLEVEL (0x9 << 26)
> > +
> > +#define EXYNOS5_DRD_PHYPARAM1 (0x20)
> > +
> > +#define PHYPARAM1_PCS_TXDEEMPH_MASK (0x1f << 0)
> > +#define PHYPARAM1_PCS_TXDEEMPH (0x1c)
> > +
> > +#define EXYNOS5_DRD_PHYTERM (0x24)
> > +
> > +#define EXYNOS5_DRD_PHYTEST (0x28)
> > +
> > +#define PHYTEST_POWERDOWN_SSP (0x1 << 3)
> > +#define PHYTEST_POWERDOWN_HSP (0x1 << 2)
> > +
> > +#define EXYNOS5_DRD_PHYADP (0x2c)
> > +
> > +#define EXYNOS5_DRD_PHYBATCHG (0x30)
> > +
> > +#define PHYBATCHG_UTMI_CLKSEL (0x1 << 2)
> > +
> > +#define EXYNOS5_DRD_PHYRESUME (0x34)
> > +#define EXYNOS5_DRD_LINKPORT (0x44)
> > +
> > +
> > +/* Isolation, configured in the power management unit */
> > +#define EXYNOS5_USB_ISOL_DRD (1 << 0)
> > +
> > +#define CLKSEL_ERROR -1
> > +
> > +#ifndef KHZ
> > +#define KHZ 1000
> > +#endif
> > +
> > +#ifndef MHZ
> > +#define MHZ (KHZ * KHZ)
> > +#endif
> > +
> > +enum samsung_cpu_type {
> > + TYPE_EXYNOS5250,
> > + TYPE_EXYNOS5420,
> > +};
> > +
> > +enum usb3phy_state {
> > + STATE_OFF,
> > + STATE_ON,
> > +};
> > +
> > +struct usb3phy_config {
> > + enum samsung_cpu_type cpu;
> > + bool has_sclk_usbphy30;
> > +};
> > +
> > +struct usb3phy_instance {
> > + char *label;
> > + struct usb3phy_driver *drv;
> > + struct phy *phy;
> > + enum usb3phy_state state;
> > + u32 clk;
> > + unsigned long rate;
> > +};
> > +
> > +struct usb3phy_driver {
> > + struct device *dev;
> > + void __iomem *reg_phy;
> > + void __iomem *reg_isol;
> > + struct clk *clk;
> > + struct clk *sclk_usbphy30;
> > + struct usb3phy_instance instance;
> > +};
> > +
> > +/*
> > + * exynos5_rate_to_clk() converts the supplied clock rate to the
> > +value that
> > + * can be written to the phy register.
> > + */
> > +static u32 exynos5_rate_to_clk(unsigned long rate) {
> > + unsigned int clksel;
> > +
> > + /* EXYNOS5_FSEL_MASK */
> > +
> > + switch (rate) {
> > + case 9600 * KHZ:
> > + clksel = EXYNOS5_FSEL_9MHZ6;
> > + break;
> > + case 10 * MHZ:
> > + clksel = EXYNOS5_FSEL_10MHZ;
> > + break;
> > + case 12 * MHZ:
> > + clksel = EXYNOS5_FSEL_12MHZ;
> > + break;
> > + case 19200 * KHZ:
> > + clksel = EXYNOS5_FSEL_19MHZ2;
> > + break;
> > + case 20 * MHZ:
> > + clksel = EXYNOS5_FSEL_20MHZ;
> > + break;
> > + case 24 * MHZ:
> > + clksel = EXYNOS5_FSEL_24MHZ;
> > + break;
> > + case 50 * MHZ:
> > + clksel = EXYNOS5_FSEL_50MHZ;
> > + break;
> > + default:
> > + clksel = CLKSEL_ERROR;
> > + }
> > +
> > + return clksel;
> > +}
> > +
> > +static void exynos5_usb3phy_isol(struct usb3phy_instance *inst, bool
> > +on) {
> > + struct usb3phy_driver *drv = inst->drv;
> > + u32 tmp;
> > +
> > + if (!drv->reg_isol)
> > + return;
> > +
> > + tmp = readl(drv->reg_isol);
> > + if (on)
> > + tmp &= ~EXYNOS5_USB_ISOL_DRD;
> > + else
> > + tmp |= EXYNOS5_USB_ISOL_DRD;
> > + writel(tmp, drv->reg_isol);
> > +}
> > +
> > +/*
> > + * Sets the phy clk as EXTREFCLK (XXTI) which is internal clock from
> clock core.
> > + */
> > +static u32 exynos5_usb3phy_set_refclk(struct usb3phy_instance *inst)
> > +{
> > + u32 reg;
> > + u32 refclk;
> > +
> > + refclk = inst->clk;
> > +
> > + reg = PHYCLKRST_REFCLKSEL_EXT_REFCLK |
> > + PHYCLKRST_FSEL(refclk);
> > +
> > + switch (refclk) {
> > + case EXYNOS5_FSEL_50MHZ:
> > + reg |= (PHYCLKRST_MPLL_MULTIPLIER_50M_REF |
> > + PHYCLKRST_SSC_REFCLKSEL(0x00));
> > + break;
> > + case EXYNOS5_FSEL_20MHZ:
> > + reg |= (PHYCLKRST_MPLL_MULTIPLIER_20MHZ_REF |
> > + PHYCLKRST_SSC_REFCLKSEL(0x00));
> > + break;
> > + case EXYNOS5_FSEL_19MHZ2:
> > + reg |= (PHYCLKRST_MPLL_MULTIPLIER_19200KHZ_REF |
> > + PHYCLKRST_SSC_REFCLKSEL(0x88));
> > + break;
> > + case EXYNOS5_FSEL_24MHZ:
> > + default:
> > + reg |= (PHYCLKRST_MPLL_MULTIPLIER_24MHZ_REF |
> > + PHYCLKRST_SSC_REFCLKSEL(0x88));
> > + break;
> > + }
> > +
> > + return reg;
> > +}
> > +
> > +static void exynos5_usb3phy_init(struct usb3phy_instance *inst) {
> > + struct usb3phy_driver *drv = inst->drv;
> > + u32 phyparam0;
> > + u32 phyparam1;
> > + u32 linksystem;
> > + u32 phybatchg;
> > + u32 phytest;
> > + u32 phyclkrst;
> > +
> > + /* Reset USB 3.0 PHY */
> > + writel(0x0, drv->reg_phy + EXYNOS5_DRD_PHYREG0);
> > +
> > + phyparam0 = readl(drv->reg_phy + EXYNOS5_DRD_PHYPARAM0);
> > + /* Select PHY CLK source */
> > + phyparam0 &= ~PHYPARAM0_REF_USE_PAD;
> > + /* Set Loss-of-Signal Detector sensitivity */
> > + phyparam0 &= ~PHYPARAM0_REF_LOSLEVEL_MASK;
> > + phyparam0 |= PHYPARAM0_REF_LOSLEVEL;
> > + writel(phyparam0, drv->reg_phy + EXYNOS5_DRD_PHYPARAM0);
> > +
> > + writel(0x0, drv->reg_phy + EXYNOS5_DRD_PHYRESUME);
> > +
> > + /*
> > + * Setting the Frame length Adj value[6:1] to default 0x20
> > + * See xHCI 1.0 spec, 5.2.4
> > + */
> > + linksystem = LINKSYSTEM_XHCI_VERSION_CONTROL |
> > + LINKSYSTEM_FLADJ(0x20);
> > + writel(linksystem, drv->reg_phy + EXYNOS5_DRD_LINKSYSTEM);
> > +
> > + phyparam1 = readl(drv->reg_phy + EXYNOS5_DRD_PHYPARAM1);
> > + /* Set Tx De-Emphasis level */
> > + phyparam1 &= ~PHYPARAM1_PCS_TXDEEMPH_MASK;
> > + phyparam1 |= PHYPARAM1_PCS_TXDEEMPH;
> > + writel(phyparam1, drv->reg_phy + EXYNOS5_DRD_PHYPARAM1);
> > +
> > + phybatchg = readl(drv->reg_phy + EXYNOS5_DRD_PHYBATCHG);
> > + phybatchg |= PHYBATCHG_UTMI_CLKSEL;
> > + writel(phybatchg, drv->reg_phy + EXYNOS5_DRD_PHYBATCHG);
> > +
> > + /* PHYTEST POWERDOWN Control */
> > + phytest = readl(drv->reg_phy + EXYNOS5_DRD_PHYTEST);
> > + phytest &= ~(PHYTEST_POWERDOWN_SSP |
> > + PHYTEST_POWERDOWN_HSP);
> > + writel(phytest, drv->reg_phy + EXYNOS5_DRD_PHYTEST);
> > +
> > + /* UTMI Power Control */
> > + writel(PHYUTMI_OTGDISABLE, drv->reg_phy + EXYNOS5_DRD_PHYUTMI);
> > +
> > + phyclkrst = exynos5_usb3phy_set_refclk(inst);
> > +
> > + phyclkrst |= PHYCLKRST_PORTRESET |
> > + /* Digital power supply in normal operating mode */
> > + PHYCLKRST_RETENABLEN |
> > + /* Enable ref clock for SS function */
> > + PHYCLKRST_REF_SSP_EN |
> > + /* Enable spread spectrum */
> > + PHYCLKRST_SSC_EN |
> > + /* Power down HS Bias and PLL blocks in suspend mode
> */
> > + PHYCLKRST_COMMONONN;
> > +
> > + writel(phyclkrst, drv->reg_phy + EXYNOS5_DRD_PHYCLKRST);
> > +
> > + udelay(10);
> > +
> > + phyclkrst &= ~PHYCLKRST_PORTRESET;
> > + writel(phyclkrst, drv->reg_phy + EXYNOS5_DRD_PHYCLKRST);
> > +
> > +}
> > +
> > +static void exynos5_usb3phy_exit(struct usb3phy_instance *inst) {
> > + struct usb3phy_driver *drv = inst->drv;
> > + u32 phyutmi;
> > + u32 phyclkrst;
> > + u32 phytest;
> > +
> > + phyutmi = PHYUTMI_OTGDISABLE |
> > + PHYUTMI_FORCESUSPEND |
> > + PHYUTMI_FORCESLEEP;
> > + writel(phyutmi, drv->reg_phy + EXYNOS5_DRD_PHYUTMI);
> > +
> > + /* Resetting the PHYCLKRST enable bits to reduce leakage current
> */
> > + phyclkrst = readl(drv->reg_phy + EXYNOS5_DRD_PHYCLKRST);
> > + phyclkrst &= ~(PHYCLKRST_REF_SSP_EN |
> > + PHYCLKRST_SSC_EN |
> > + PHYCLKRST_COMMONONN);
> > + writel(phyclkrst, drv->reg_phy + EXYNOS5_DRD_PHYCLKRST);
> > +
> > + /* Control PHYTEST to remove leakage current */
> > + phytest = readl(drv->reg_phy + EXYNOS5_DRD_PHYTEST);
> > + phytest |= PHYTEST_POWERDOWN_SSP |
> > + PHYTEST_POWERDOWN_HSP;
> > + writel(phytest, drv->reg_phy + EXYNOS5_DRD_PHYTEST); }
> > +
> > +static int exynos5_usb3phy_power_on(struct phy *phy) {
> > + struct usb3phy_instance *inst = phy_get_drvdata(phy);
> > + struct usb3phy_driver *drv = inst->drv;
> > + int ret;
> > +
> > + dev_info(drv->dev, "Request to power_on \"%s\" usb phy\n",
> > + inst->label);
> > +
> > + if (drv->sclk_usbphy30)
> > + clk_prepare_enable(drv->sclk_usbphy30);
> > +
> > + ret = clk_prepare_enable(drv->clk);
> > + if (ret)
> > + return ret;
> > +
> > + if (inst->state == STATE_ON) {
> > + dev_err(drv->dev, "usb phy \"%s\" already on",
> > + inst->label);
> > + ret = -ENODEV;
> > + goto err0;
> > + }
> > +
> > + inst->state = STATE_ON;
> > +
> > + /* Initialize the PHY and power it ON */
> > + exynos5_usb3phy_init(inst);
> > + exynos5_usb3phy_isol(inst, 0);
> > +
> > +err0:
> > + clk_disable_unprepare(drv->clk);
> > +
> > + return ret;
> > +}
> > +
> > +static int exynos5_usb3phy_power_off(struct phy *phy) {
> > + struct usb3phy_instance *inst = phy_get_drvdata(phy);
> > + struct usb3phy_driver *drv = inst->drv;
> > + int ret;
> > +
> > + dev_info(drv->dev, "Request to power_off \"%s\" usb phy\n",
> > + inst->label);
> > + ret = clk_prepare_enable(drv->clk);
> > + if (ret)
> > + return ret;
> > +
> > + if (inst->state == STATE_OFF) {
> > + dev_err(drv->dev, "usb phy \"%s\" already off",
> > + inst->label);
> > + ret = -ENODEV;
> > + goto err0;
> > + }
> > +
> > + inst->state = STATE_OFF;
> > +
> > + /* Power-off the PHY and de-initialize it */
> > + exynos5_usb3phy_isol(inst, 1);
> > + exynos5_usb3phy_exit(inst);
> > +
> > +err0:
> > + clk_disable_unprepare(drv->clk);
> > + if (drv->sclk_usbphy30)
> > + clk_disable_unprepare(drv->sclk_usbphy30);
> > +
> > + return ret;
> > +}
> > +
> > +static struct phy_ops exynos5_usb3phy_ops = {
> > + .power_on = exynos5_usb3phy_power_on,
> > + .power_off = exynos5_usb3phy_power_off,
> > + .owner = THIS_MODULE,
> > +};
> > +
> > +static const struct of_device_id exynos5_usb3phy_of_match[];
> > +
> > +static int exynos5_usb3phy_probe(struct platform_device *pdev) {
> > + struct device *dev = &pdev->dev;
> > + struct usb3phy_driver *drv;
> > + struct usb3phy_instance *inst;
> > + struct phy_provider *phy_provider;
> > + struct resource *res;
> > + struct clk *clk;
> > + const struct of_device_id *match;
> > + const struct usb3phy_config *cfg;
> > +
> > + match = of_match_node(exynos5_usb3phy_of_match, pdev-
> >dev.of_node);
> > + if (!match) {
> > + dev_err(dev, "of_match_node() failed\n");
> > + return -EINVAL;
> > + }
> > + cfg = match->data;
> > + if (!cfg) {
> > + dev_err(dev, "Failed to get configuration\n");
> > + return -EINVAL;
> > + }
> > +
> > + drv = devm_kzalloc(dev, sizeof(struct usb3phy_driver),
> GFP_KERNEL);
> > + if (!drv) {
> > + dev_err(dev, "Failed to allocate memory\n");
> > + return -ENOMEM;
> > + }
> > +
> > + dev_set_drvdata(dev, drv);
> > + drv->dev = dev;
> > +
> > + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> > + drv->reg_phy = devm_ioremap_resource(dev, res);
> > + if (IS_ERR(drv->reg_phy)) {
> > + dev_err(dev, "Failed to map register memory (phy)\n");
> > + return PTR_ERR(drv->reg_phy);
> > + }
> > +
> > + res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
> > + drv->reg_isol = devm_ioremap_resource(dev, res);
> > + if (IS_ERR(drv->reg_isol)) {
> > + dev_err(dev, "Failed to map register memory (isolation)\n");
> > + return PTR_ERR(drv->reg_isol);
> > + }
> > +
> > + phy_provider = devm_of_phy_provider_register(dev,
> of_phy_simple_xlate);
> > + if (IS_ERR(phy_provider)) {
> > + dev_err(drv->dev, "Failed to register phy provider\n");
> > + return PTR_ERR(phy_provider);
> > + }
> > +
> > + drv->clk = devm_clk_get(dev, "phy");
> > + if (IS_ERR(drv->clk)) {
> > + dev_err(dev, "Failed to get clock of phy controller\n");
> > + return PTR_ERR(drv->clk);
> > + }
> > +
> > + /*
> > + * Exysno5420 SoC has an additional special clock, used for
> > + * for USB 3.0 PHY operation, this clock goes to the PHY block
> > + * as a reference clock to clock generation block of the
> controller.
> > + */
> > + if (cfg->has_sclk_usbphy30) {
> > + drv->sclk_usbphy30 = devm_clk_get(dev, "sclk_usbphy30");
> > + if (IS_ERR(drv->clk)) {
> > + dev_err(dev, "Failed to get phy reference clock\n");
> > + return PTR_ERR(drv->clk);
> > + }
> > + }
> > +
> > + inst = &drv->instance;
> > + inst->drv = drv;
> > + inst->label = "usb3drd";
> > +
> > + dev_info(dev, "Creating phy \"%s\"\n", inst->label);
> > + inst->phy = devm_phy_create(dev, &exynos5_usb3phy_ops, NULL);
> > + if (IS_ERR(inst->phy)) {
> > + dev_err(drv->dev, "Failed to create usb3phy \"%s\"\n",
> > + inst->label);
> > + return PTR_ERR(inst->phy);
> > + }
> > +
> > + phy_set_drvdata(inst->phy, inst);
> > +
> > + clk = clk_get(dev, inst->label);
> > + if (IS_ERR(clk)) {
> > + dev_err(dev, "Failed to get clock of \"%s\" phy\n",
> > + inst->label);
> > + return PTR_ERR(clk);
> > + }
> > +
> > + inst->rate = clk_get_rate(clk);
> > +
> > + inst->clk = exynos5_rate_to_clk(inst->rate);
> > + if (inst->clk == CLKSEL_ERROR) {
> > + dev_err(dev, "Clock rate (%ld) not supported\n",
> > + inst->rate);
> > + clk_put(clk);
> > + return -EINVAL;
> > + }
> > + clk_put(clk);
> > +
> > + return 0;
> > +}
> > +
> > +const struct usb3phy_config exynos5420_usb3phy_cfg = {
> > + .cpu = TYPE_EXYNOS5420,
> > + .has_sclk_usbphy30 = true,
> > +};
> > +
> > +const struct usb3phy_config exynos5250_usb3phy_cfg = {
> > + .cpu = TYPE_EXYNOS5250,
> > + .has_sclk_usbphy30 = false,
> > +};
> > +
> > +static const struct of_device_id exynos5_usb3phy_of_match[] = {
> > + {
> > + .compatible = "samsung,exynos5250-usb3phy",
> > + .data = &exynos5250_usb3phy_cfg
> > + }, {
> > + .compatible = "samsung,exynos5420-usb3phy",
> > + .data = &exynos5420_usb3phy_cfg
> > + },
> > + { },
> > +};
> > +
> > +static struct platform_driver exynos5_usb3phy_driver = {
> > + .probe = exynos5_usb3phy_probe,
> > + .driver = {
> > + .of_match_table = exynos5_usb3phy_of_match,
> > + .name = "exynos5-usb3phy",
> > + .owner = THIS_MODULE,
> > + }
> > +};
> > +
> > +module_platform_driver(exynos5_usb3phy_driver);
> > +MODULE_DESCRIPTION("Samsung EXYNOS5 series SoC USB 3.0 PHY driver");
> > +MODULE_AUTHOR("Vivek Gautam <gautam.vivek@samsung.com>");
> > +MODULE_LICENSE("GPL v2"); MODULE_ALIAS("platform:exynos5-usb3phy");
> >
^ permalink raw reply [flat|nested] 36+ messages in thread* [PATCH RFC 1/4] phy: Add new Exynos5 USB 3.0 PHY driver
2013-11-04 10:15 ` Kamil Debski
@ 2013-11-04 13:12 ` Kishon Vijay Abraham I
2013-11-05 7:20 ` Vivek Gautam
0 siblings, 1 reply; 36+ messages in thread
From: Kishon Vijay Abraham I @ 2013-11-04 13:12 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
On Monday 04 November 2013 03:45 PM, Kamil Debski wrote:
> Hi Kishon,
>
>> From: Kishon Vijay Abraham I [mailto:kishon at ti.com]
>> Sent: Monday, November 04, 2013 7:55 AM
>>
>> Hi Vivek,
>>
>> On Thursday 31 October 2013 01:15 PM, Vivek Gautam wrote:
>>> Add a new driver for the USB 3.0 PHY on Exynos5 series of SoCs.
>>> The new driver uses the generic PHY framework and will interact with
>>> DWC3 controller present on Exynos5 series of SoCs.
>>
>> In Exynos, you have a single IP that supports both USB3 and USB2 PHY
>> right? I think that needs to be mentioned here.
>
> As far as I know the IP is different.
Ok. Sometime back Vivek was mentioning about a single IP for both USB3
and USB2. Thought it should be this driver. Anyway thanks for the
clarification.
Cheers
Kishon
>
>> Do you have separate registers that should be used for
>> initializing/powerin_on/powering_off etc.. for usb2 phy and usb3 phy?
>> If so, then you should model this driver as a single driver that
>> supports two PHYs similar to what Sylwester has done before?
>
> Best wishes,
> Kamil
>
>> Cheers
>> Kishon
>>
>>>
>>> Signed-off-by: Vivek Gautam <gautam.vivek@samsung.com>
>>> ---
>>> .../devicetree/bindings/phy/samsung-phy.txt | 20 +
>>> drivers/phy/Kconfig | 7 +
>>> drivers/phy/Makefile | 1 +
>>> drivers/phy/phy-exynos5-usb3.c | 562
>> ++++++++++++++++++++
>>> 4 files changed, 590 insertions(+), 0 deletions(-)
>>> create mode 100644 drivers/phy/phy-exynos5-usb3.c
>>>
>>> diff --git a/Documentation/devicetree/bindings/phy/samsung-phy.txt
>>> b/Documentation/devicetree/bindings/phy/samsung-phy.txt
>>> index c0fccaa..9b5c111 100644
>>> --- a/Documentation/devicetree/bindings/phy/samsung-phy.txt
>>> +++ b/Documentation/devicetree/bindings/phy/samsung-phy.txt
>>> @@ -20,3 +20,23 @@ Required properties:
>>> - compatible : should be "samsung,exynos5250-dp-video-phy";
>>> - reg : offset and length of the Display Port PHY register set;
>>> - #phy-cells : from the generic PHY bindings, must be 0;
>>> +
>>> +Samsung Exynos5 SoC seiries USB 3.0 PHY controller
>>> +--------------------------------------------------
>>> +
>>> +Required properties:
>>> +- compatible :
>>> + should be "samsung,exynos5250-usb3phy" for exynos5250 SoC
>>> + should be "samsung,exynos5420-usb3phy" for exynos5420 SoC
>>> +- reg : Register offset and length array
>>> + - first field corresponds to USB 3.0 PHY register set;
>>> + - second field corresponds to PHY power isolation register
>>> + present in PMU;
>>> +- clocks: Clock IDs array as required by the controller
>>> +- clock-names: names of clocks correseponding to IDs in the clock
>> property;
>>> + Required clocks:
>>> + - first clock is main PHY clock (same as USB 3.0 controller IP
>> clock)
>>> + - second clock is reference clock (usually crystal clock)
>>> + optional clock:
>>> + - third clock is special clock used by PHY for operation
>>> +- #phy-cells : from the generic PHY bindings, must be 0;
>>> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig index
>>> a344f3d..9a100c6 100644
>>> --- a/drivers/phy/Kconfig
>>> +++ b/drivers/phy/Kconfig
>>> @@ -51,4 +51,11 @@ config PHY_EXYNOS_DP_VIDEO
>>> help
>>> Support for Display Port PHY found on Samsung EXYNOS SoCs.
>>>
>>> +config PHY_EXYNOS5_USB3
>>> + tristate "Exynos5 SoC series USB 3.0 PHY driver"
>>> + depends on ARCH_EXYNOS5
>>> + select GENERIC_PHY
>>> + help
>>> + Enable USB 3.0 PHY support for Exynos 5 SoC series
>>> +
>>> endmenu
>>> diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile index
>>> d0caae9..9c06a61 100644
>>> --- a/drivers/phy/Makefile
>>> +++ b/drivers/phy/Makefile
>>> @@ -7,3 +7,4 @@ obj-$(CONFIG_PHY_EXYNOS_DP_VIDEO) += phy-exynos-dp-
>> video.o
>>> obj-$(CONFIG_PHY_EXYNOS_MIPI_VIDEO) += phy-exynos-mipi-video.o
>>> obj-$(CONFIG_OMAP_USB2) += phy-omap-usb2.o
>>> obj-$(CONFIG_TWL4030_USB) += phy-twl4030-usb.o
>>> +obj-$(CONFIG_PHY_EXYNOS5_USB3) += phy-exynos5-usb3.o
>>> diff --git a/drivers/phy/phy-exynos5-usb3.c
>>> b/drivers/phy/phy-exynos5-usb3.c new file mode 100644 index
>>> 0000000..b9a2674
>>> --- /dev/null
>>> +++ b/drivers/phy/phy-exynos5-usb3.c
>>> @@ -0,0 +1,562 @@
>>> +/*
>>> + * Samsung EXYNOS5 SoC series USB 3.0 PHY driver
>>> + *
>>> + * Copyright (C) 2013 Samsung Electronics Co., Ltd.
>>> + * Author: Vivek Gautam <gautam.vivek@samsung.com>
>>> + *
>>> + * This program is free software; you can redistribute it and/or
>>> +modify
>>> + * it under the terms of the GNU General Public License version 2 as
>>> + * published by the Free Software Foundation.
>>> + */
>>> +
>>> +#include <linux/clk.h>
>>> +#include <linux/delay.h>
>>> +#include <linux/io.h>
>>> +#include <linux/kernel.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/mutex.h>
>>> +
>>> +/* Exynos USB PHY registers */
>>> +#define EXYNOS5_FSEL_9MHZ6 0x0
>>> +#define EXYNOS5_FSEL_10MHZ 0x1
>>> +#define EXYNOS5_FSEL_12MHZ 0x2
>>> +#define EXYNOS5_FSEL_19MHZ2 0x3
>>> +#define EXYNOS5_FSEL_20MHZ 0x4
>>> +#define EXYNOS5_FSEL_24MHZ 0x5
>>> +#define EXYNOS5_FSEL_50MHZ 0x7
>>> +
>>> +/* EXYNOS5: USB 3.0 DRD PHY registers */
>>> +#define EXYNOS5_DRD_LINKSYSTEM (0x04)
>>> +
>>> +#define LINKSYSTEM_FLADJ_MASK (0x3f << 1)
>>> +#define LINKSYSTEM_FLADJ(_x) ((_x) << 1)
>>> +#define LINKSYSTEM_XHCI_VERSION_CONTROL (0x1 << 27)
>>> +
>>> +#define EXYNOS5_DRD_PHYUTMI (0x08)
>>> +
>>> +#define PHYUTMI_OTGDISABLE (0x1 << 6)
>>> +#define PHYUTMI_FORCESUSPEND (0x1 << 1)
>>> +#define PHYUTMI_FORCESLEEP (0x1 << 0)
>>> +
>>> +#define EXYNOS5_DRD_PHYPIPE (0x0c)
>>> +
>>> +#define EXYNOS5_DRD_PHYCLKRST (0x10)
>>> +
>>> +#define PHYCLKRST_SSC_REFCLKSEL_MASK (0xff << 23)
>>> +#define PHYCLKRST_SSC_REFCLKSEL(_x) ((_x) << 23)
>>> +
>>> +#define PHYCLKRST_SSC_RANGE_MASK (0x03 << 21)
>>> +#define PHYCLKRST_SSC_RANGE(_x) ((_x) << 21)
>>> +
>>> +#define PHYCLKRST_SSC_EN (0x1 << 20)
>>> +#define PHYCLKRST_REF_SSP_EN (0x1 << 19)
>>> +#define PHYCLKRST_REF_CLKDIV2 (0x1 << 18)
>>> +
>>> +#define PHYCLKRST_MPLL_MULTIPLIER_MASK (0x7f << 11)
>>> +#define PHYCLKRST_MPLL_MULTIPLIER_100MHZ_REF (0x19 << 11)
>>> +#define PHYCLKRST_MPLL_MULTIPLIER_50M_REF (0x02 << 11)
>>> +#define PHYCLKRST_MPLL_MULTIPLIER_24MHZ_REF (0x68 << 11)
>>> +#define PHYCLKRST_MPLL_MULTIPLIER_20MHZ_REF (0x7d << 11)
>>> +#define PHYCLKRST_MPLL_MULTIPLIER_19200KHZ_REF (0x02 << 11)
>>> +
>>> +#define PHYCLKRST_FSEL_MASK (0x3f << 5)
>>> +#define PHYCLKRST_FSEL(_x) ((_x) << 5)
>>> +#define PHYCLKRST_FSEL_PAD_100MHZ (0x27 << 5)
>>> +#define PHYCLKRST_FSEL_PAD_24MHZ (0x2a << 5)
>>> +#define PHYCLKRST_FSEL_PAD_20MHZ (0x31 << 5)
>>> +#define PHYCLKRST_FSEL_PAD_19_2MHZ (0x38 << 5)
>>> +
>>> +#define PHYCLKRST_RETENABLEN (0x1 << 4)
>>> +
>>> +#define PHYCLKRST_REFCLKSEL_MASK (0x03 << 2)
>>> +#define PHYCLKRST_REFCLKSEL_PAD_REFCLK (0x2 << 2)
>>> +#define PHYCLKRST_REFCLKSEL_EXT_REFCLK (0x3 << 2)
>>> +
>>> +#define PHYCLKRST_PORTRESET (0x1 << 1)
>>> +#define PHYCLKRST_COMMONONN (0x1 << 0)
>>> +
>>> +#define EXYNOS5_DRD_PHYREG0 (0x14)
>>> +#define EXYNOS5_DRD_PHYREG1 (0x18)
>>> +
>>> +#define EXYNOS5_DRD_PHYPARAM0 (0x1c)
>>> +
>>> +#define PHYPARAM0_REF_USE_PAD (0x1 << 31)
>>> +#define PHYPARAM0_REF_LOSLEVEL_MASK (0x1f << 26)
>>> +#define PHYPARAM0_REF_LOSLEVEL (0x9 << 26)
>>> +
>>> +#define EXYNOS5_DRD_PHYPARAM1 (0x20)
>>> +
>>> +#define PHYPARAM1_PCS_TXDEEMPH_MASK (0x1f << 0)
>>> +#define PHYPARAM1_PCS_TXDEEMPH (0x1c)
>>> +
>>> +#define EXYNOS5_DRD_PHYTERM (0x24)
>>> +
>>> +#define EXYNOS5_DRD_PHYTEST (0x28)
>>> +
>>> +#define PHYTEST_POWERDOWN_SSP (0x1 << 3)
>>> +#define PHYTEST_POWERDOWN_HSP (0x1 << 2)
>>> +
>>> +#define EXYNOS5_DRD_PHYADP (0x2c)
>>> +
>>> +#define EXYNOS5_DRD_PHYBATCHG (0x30)
>>> +
>>> +#define PHYBATCHG_UTMI_CLKSEL (0x1 << 2)
>>> +
>>> +#define EXYNOS5_DRD_PHYRESUME (0x34)
>>> +#define EXYNOS5_DRD_LINKPORT (0x44)
>>> +
>>> +
>>> +/* Isolation, configured in the power management unit */
>>> +#define EXYNOS5_USB_ISOL_DRD (1 << 0)
>>> +
>>> +#define CLKSEL_ERROR -1
>>> +
>>> +#ifndef KHZ
>>> +#define KHZ 1000
>>> +#endif
>>> +
>>> +#ifndef MHZ
>>> +#define MHZ (KHZ * KHZ)
>>> +#endif
>>> +
>>> +enum samsung_cpu_type {
>>> + TYPE_EXYNOS5250,
>>> + TYPE_EXYNOS5420,
>>> +};
>>> +
>>> +enum usb3phy_state {
>>> + STATE_OFF,
>>> + STATE_ON,
>>> +};
>>> +
>>> +struct usb3phy_config {
>>> + enum samsung_cpu_type cpu;
>>> + bool has_sclk_usbphy30;
>>> +};
>>> +
>>> +struct usb3phy_instance {
>>> + char *label;
>>> + struct usb3phy_driver *drv;
>>> + struct phy *phy;
>>> + enum usb3phy_state state;
>>> + u32 clk;
>>> + unsigned long rate;
>>> +};
>>> +
>>> +struct usb3phy_driver {
>>> + struct device *dev;
>>> + void __iomem *reg_phy;
>>> + void __iomem *reg_isol;
>>> + struct clk *clk;
>>> + struct clk *sclk_usbphy30;
>>> + struct usb3phy_instance instance;
>>> +};
>>> +
>>> +/*
>>> + * exynos5_rate_to_clk() converts the supplied clock rate to the
>>> +value that
>>> + * can be written to the phy register.
>>> + */
>>> +static u32 exynos5_rate_to_clk(unsigned long rate) {
>>> + unsigned int clksel;
>>> +
>>> + /* EXYNOS5_FSEL_MASK */
>>> +
>>> + switch (rate) {
>>> + case 9600 * KHZ:
>>> + clksel = EXYNOS5_FSEL_9MHZ6;
>>> + break;
>>> + case 10 * MHZ:
>>> + clksel = EXYNOS5_FSEL_10MHZ;
>>> + break;
>>> + case 12 * MHZ:
>>> + clksel = EXYNOS5_FSEL_12MHZ;
>>> + break;
>>> + case 19200 * KHZ:
>>> + clksel = EXYNOS5_FSEL_19MHZ2;
>>> + break;
>>> + case 20 * MHZ:
>>> + clksel = EXYNOS5_FSEL_20MHZ;
>>> + break;
>>> + case 24 * MHZ:
>>> + clksel = EXYNOS5_FSEL_24MHZ;
>>> + break;
>>> + case 50 * MHZ:
>>> + clksel = EXYNOS5_FSEL_50MHZ;
>>> + break;
>>> + default:
>>> + clksel = CLKSEL_ERROR;
>>> + }
>>> +
>>> + return clksel;
>>> +}
>>> +
>>> +static void exynos5_usb3phy_isol(struct usb3phy_instance *inst, bool
>>> +on) {
>>> + struct usb3phy_driver *drv = inst->drv;
>>> + u32 tmp;
>>> +
>>> + if (!drv->reg_isol)
>>> + return;
>>> +
>>> + tmp = readl(drv->reg_isol);
>>> + if (on)
>>> + tmp &= ~EXYNOS5_USB_ISOL_DRD;
>>> + else
>>> + tmp |= EXYNOS5_USB_ISOL_DRD;
>>> + writel(tmp, drv->reg_isol);
>>> +}
>>> +
>>> +/*
>>> + * Sets the phy clk as EXTREFCLK (XXTI) which is internal clock from
>> clock core.
>>> + */
>>> +static u32 exynos5_usb3phy_set_refclk(struct usb3phy_instance *inst)
>>> +{
>>> + u32 reg;
>>> + u32 refclk;
>>> +
>>> + refclk = inst->clk;
>>> +
>>> + reg = PHYCLKRST_REFCLKSEL_EXT_REFCLK |
>>> + PHYCLKRST_FSEL(refclk);
>>> +
>>> + switch (refclk) {
>>> + case EXYNOS5_FSEL_50MHZ:
>>> + reg |= (PHYCLKRST_MPLL_MULTIPLIER_50M_REF |
>>> + PHYCLKRST_SSC_REFCLKSEL(0x00));
>>> + break;
>>> + case EXYNOS5_FSEL_20MHZ:
>>> + reg |= (PHYCLKRST_MPLL_MULTIPLIER_20MHZ_REF |
>>> + PHYCLKRST_SSC_REFCLKSEL(0x00));
>>> + break;
>>> + case EXYNOS5_FSEL_19MHZ2:
>>> + reg |= (PHYCLKRST_MPLL_MULTIPLIER_19200KHZ_REF |
>>> + PHYCLKRST_SSC_REFCLKSEL(0x88));
>>> + break;
>>> + case EXYNOS5_FSEL_24MHZ:
>>> + default:
>>> + reg |= (PHYCLKRST_MPLL_MULTIPLIER_24MHZ_REF |
>>> + PHYCLKRST_SSC_REFCLKSEL(0x88));
>>> + break;
>>> + }
>>> +
>>> + return reg;
>>> +}
>>> +
>>> +static void exynos5_usb3phy_init(struct usb3phy_instance *inst) {
>>> + struct usb3phy_driver *drv = inst->drv;
>>> + u32 phyparam0;
>>> + u32 phyparam1;
>>> + u32 linksystem;
>>> + u32 phybatchg;
>>> + u32 phytest;
>>> + u32 phyclkrst;
>>> +
>>> + /* Reset USB 3.0 PHY */
>>> + writel(0x0, drv->reg_phy + EXYNOS5_DRD_PHYREG0);
>>> +
>>> + phyparam0 = readl(drv->reg_phy + EXYNOS5_DRD_PHYPARAM0);
>>> + /* Select PHY CLK source */
>>> + phyparam0 &= ~PHYPARAM0_REF_USE_PAD;
>>> + /* Set Loss-of-Signal Detector sensitivity */
>>> + phyparam0 &= ~PHYPARAM0_REF_LOSLEVEL_MASK;
>>> + phyparam0 |= PHYPARAM0_REF_LOSLEVEL;
>>> + writel(phyparam0, drv->reg_phy + EXYNOS5_DRD_PHYPARAM0);
>>> +
>>> + writel(0x0, drv->reg_phy + EXYNOS5_DRD_PHYRESUME);
>>> +
>>> + /*
>>> + * Setting the Frame length Adj value[6:1] to default 0x20
>>> + * See xHCI 1.0 spec, 5.2.4
>>> + */
>>> + linksystem = LINKSYSTEM_XHCI_VERSION_CONTROL |
>>> + LINKSYSTEM_FLADJ(0x20);
>>> + writel(linksystem, drv->reg_phy + EXYNOS5_DRD_LINKSYSTEM);
>>> +
>>> + phyparam1 = readl(drv->reg_phy + EXYNOS5_DRD_PHYPARAM1);
>>> + /* Set Tx De-Emphasis level */
>>> + phyparam1 &= ~PHYPARAM1_PCS_TXDEEMPH_MASK;
>>> + phyparam1 |= PHYPARAM1_PCS_TXDEEMPH;
>>> + writel(phyparam1, drv->reg_phy + EXYNOS5_DRD_PHYPARAM1);
>>> +
>>> + phybatchg = readl(drv->reg_phy + EXYNOS5_DRD_PHYBATCHG);
>>> + phybatchg |= PHYBATCHG_UTMI_CLKSEL;
>>> + writel(phybatchg, drv->reg_phy + EXYNOS5_DRD_PHYBATCHG);
>>> +
>>> + /* PHYTEST POWERDOWN Control */
>>> + phytest = readl(drv->reg_phy + EXYNOS5_DRD_PHYTEST);
>>> + phytest &= ~(PHYTEST_POWERDOWN_SSP |
>>> + PHYTEST_POWERDOWN_HSP);
>>> + writel(phytest, drv->reg_phy + EXYNOS5_DRD_PHYTEST);
>>> +
>>> + /* UTMI Power Control */
>>> + writel(PHYUTMI_OTGDISABLE, drv->reg_phy + EXYNOS5_DRD_PHYUTMI);
>>> +
>>> + phyclkrst = exynos5_usb3phy_set_refclk(inst);
>>> +
>>> + phyclkrst |= PHYCLKRST_PORTRESET |
>>> + /* Digital power supply in normal operating mode */
>>> + PHYCLKRST_RETENABLEN |
>>> + /* Enable ref clock for SS function */
>>> + PHYCLKRST_REF_SSP_EN |
>>> + /* Enable spread spectrum */
>>> + PHYCLKRST_SSC_EN |
>>> + /* Power down HS Bias and PLL blocks in suspend mode
>> */
>>> + PHYCLKRST_COMMONONN;
>>> +
>>> + writel(phyclkrst, drv->reg_phy + EXYNOS5_DRD_PHYCLKRST);
>>> +
>>> + udelay(10);
>>> +
>>> + phyclkrst &= ~PHYCLKRST_PORTRESET;
>>> + writel(phyclkrst, drv->reg_phy + EXYNOS5_DRD_PHYCLKRST);
>>> +
>>> +}
>>> +
>>> +static void exynos5_usb3phy_exit(struct usb3phy_instance *inst) {
>>> + struct usb3phy_driver *drv = inst->drv;
>>> + u32 phyutmi;
>>> + u32 phyclkrst;
>>> + u32 phytest;
>>> +
>>> + phyutmi = PHYUTMI_OTGDISABLE |
>>> + PHYUTMI_FORCESUSPEND |
>>> + PHYUTMI_FORCESLEEP;
>>> + writel(phyutmi, drv->reg_phy + EXYNOS5_DRD_PHYUTMI);
>>> +
>>> + /* Resetting the PHYCLKRST enable bits to reduce leakage current
>> */
>>> + phyclkrst = readl(drv->reg_phy + EXYNOS5_DRD_PHYCLKRST);
>>> + phyclkrst &= ~(PHYCLKRST_REF_SSP_EN |
>>> + PHYCLKRST_SSC_EN |
>>> + PHYCLKRST_COMMONONN);
>>> + writel(phyclkrst, drv->reg_phy + EXYNOS5_DRD_PHYCLKRST);
>>> +
>>> + /* Control PHYTEST to remove leakage current */
>>> + phytest = readl(drv->reg_phy + EXYNOS5_DRD_PHYTEST);
>>> + phytest |= PHYTEST_POWERDOWN_SSP |
>>> + PHYTEST_POWERDOWN_HSP;
>>> + writel(phytest, drv->reg_phy + EXYNOS5_DRD_PHYTEST); }
>>> +
>>> +static int exynos5_usb3phy_power_on(struct phy *phy) {
>>> + struct usb3phy_instance *inst = phy_get_drvdata(phy);
>>> + struct usb3phy_driver *drv = inst->drv;
>>> + int ret;
>>> +
>>> + dev_info(drv->dev, "Request to power_on \"%s\" usb phy\n",
>>> + inst->label);
>>> +
>>> + if (drv->sclk_usbphy30)
>>> + clk_prepare_enable(drv->sclk_usbphy30);
>>> +
>>> + ret = clk_prepare_enable(drv->clk);
>>> + if (ret)
>>> + return ret;
>>> +
>>> + if (inst->state == STATE_ON) {
>>> + dev_err(drv->dev, "usb phy \"%s\" already on",
>>> + inst->label);
>>> + ret = -ENODEV;
>>> + goto err0;
>>> + }
>>> +
>>> + inst->state = STATE_ON;
>>> +
>>> + /* Initialize the PHY and power it ON */
>>> + exynos5_usb3phy_init(inst);
>>> + exynos5_usb3phy_isol(inst, 0);
>>> +
>>> +err0:
>>> + clk_disable_unprepare(drv->clk);
>>> +
>>> + return ret;
>>> +}
>>> +
>>> +static int exynos5_usb3phy_power_off(struct phy *phy) {
>>> + struct usb3phy_instance *inst = phy_get_drvdata(phy);
>>> + struct usb3phy_driver *drv = inst->drv;
>>> + int ret;
>>> +
>>> + dev_info(drv->dev, "Request to power_off \"%s\" usb phy\n",
>>> + inst->label);
>>> + ret = clk_prepare_enable(drv->clk);
>>> + if (ret)
>>> + return ret;
>>> +
>>> + if (inst->state == STATE_OFF) {
>>> + dev_err(drv->dev, "usb phy \"%s\" already off",
>>> + inst->label);
>>> + ret = -ENODEV;
>>> + goto err0;
>>> + }
>>> +
>>> + inst->state = STATE_OFF;
>>> +
>>> + /* Power-off the PHY and de-initialize it */
>>> + exynos5_usb3phy_isol(inst, 1);
>>> + exynos5_usb3phy_exit(inst);
>>> +
>>> +err0:
>>> + clk_disable_unprepare(drv->clk);
>>> + if (drv->sclk_usbphy30)
>>> + clk_disable_unprepare(drv->sclk_usbphy30);
>>> +
>>> + return ret;
>>> +}
>>> +
>>> +static struct phy_ops exynos5_usb3phy_ops = {
>>> + .power_on = exynos5_usb3phy_power_on,
>>> + .power_off = exynos5_usb3phy_power_off,
>>> + .owner = THIS_MODULE,
>>> +};
>>> +
>>> +static const struct of_device_id exynos5_usb3phy_of_match[];
>>> +
>>> +static int exynos5_usb3phy_probe(struct platform_device *pdev) {
>>> + struct device *dev = &pdev->dev;
>>> + struct usb3phy_driver *drv;
>>> + struct usb3phy_instance *inst;
>>> + struct phy_provider *phy_provider;
>>> + struct resource *res;
>>> + struct clk *clk;
>>> + const struct of_device_id *match;
>>> + const struct usb3phy_config *cfg;
>>> +
>>> + match = of_match_node(exynos5_usb3phy_of_match, pdev-
>>> dev.of_node);
>>> + if (!match) {
>>> + dev_err(dev, "of_match_node() failed\n");
>>> + return -EINVAL;
>>> + }
>>> + cfg = match->data;
>>> + if (!cfg) {
>>> + dev_err(dev, "Failed to get configuration\n");
>>> + return -EINVAL;
>>> + }
>>> +
>>> + drv = devm_kzalloc(dev, sizeof(struct usb3phy_driver),
>> GFP_KERNEL);
>>> + if (!drv) {
>>> + dev_err(dev, "Failed to allocate memory\n");
>>> + return -ENOMEM;
>>> + }
>>> +
>>> + dev_set_drvdata(dev, drv);
>>> + drv->dev = dev;
>>> +
>>> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>>> + drv->reg_phy = devm_ioremap_resource(dev, res);
>>> + if (IS_ERR(drv->reg_phy)) {
>>> + dev_err(dev, "Failed to map register memory (phy)\n");
>>> + return PTR_ERR(drv->reg_phy);
>>> + }
>>> +
>>> + res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
>>> + drv->reg_isol = devm_ioremap_resource(dev, res);
>>> + if (IS_ERR(drv->reg_isol)) {
>>> + dev_err(dev, "Failed to map register memory (isolation)\n");
>>> + return PTR_ERR(drv->reg_isol);
>>> + }
>>> +
>>> + phy_provider = devm_of_phy_provider_register(dev,
>> of_phy_simple_xlate);
>>> + if (IS_ERR(phy_provider)) {
>>> + dev_err(drv->dev, "Failed to register phy provider\n");
>>> + return PTR_ERR(phy_provider);
>>> + }
>>> +
>>> + drv->clk = devm_clk_get(dev, "phy");
>>> + if (IS_ERR(drv->clk)) {
>>> + dev_err(dev, "Failed to get clock of phy controller\n");
>>> + return PTR_ERR(drv->clk);
>>> + }
>>> +
>>> + /*
>>> + * Exysno5420 SoC has an additional special clock, used for
>>> + * for USB 3.0 PHY operation, this clock goes to the PHY block
>>> + * as a reference clock to clock generation block of the
>> controller.
>>> + */
>>> + if (cfg->has_sclk_usbphy30) {
>>> + drv->sclk_usbphy30 = devm_clk_get(dev, "sclk_usbphy30");
>>> + if (IS_ERR(drv->clk)) {
>>> + dev_err(dev, "Failed to get phy reference clock\n");
>>> + return PTR_ERR(drv->clk);
>>> + }
>>> + }
>>> +
>>> + inst = &drv->instance;
>>> + inst->drv = drv;
>>> + inst->label = "usb3drd";
>>> +
>>> + dev_info(dev, "Creating phy \"%s\"\n", inst->label);
>>> + inst->phy = devm_phy_create(dev, &exynos5_usb3phy_ops, NULL);
>>> + if (IS_ERR(inst->phy)) {
>>> + dev_err(drv->dev, "Failed to create usb3phy \"%s\"\n",
>>> + inst->label);
>>> + return PTR_ERR(inst->phy);
>>> + }
>>> +
>>> + phy_set_drvdata(inst->phy, inst);
>>> +
>>> + clk = clk_get(dev, inst->label);
>>> + if (IS_ERR(clk)) {
>>> + dev_err(dev, "Failed to get clock of \"%s\" phy\n",
>>> + inst->label);
>>> + return PTR_ERR(clk);
>>> + }
>>> +
>>> + inst->rate = clk_get_rate(clk);
>>> +
>>> + inst->clk = exynos5_rate_to_clk(inst->rate);
>>> + if (inst->clk == CLKSEL_ERROR) {
>>> + dev_err(dev, "Clock rate (%ld) not supported\n",
>>> + inst->rate);
>>> + clk_put(clk);
>>> + return -EINVAL;
>>> + }
>>> + clk_put(clk);
>>> +
>>> + return 0;
>>> +}
>>> +
>>> +const struct usb3phy_config exynos5420_usb3phy_cfg = {
>>> + .cpu = TYPE_EXYNOS5420,
>>> + .has_sclk_usbphy30 = true,
>>> +};
>>> +
>>> +const struct usb3phy_config exynos5250_usb3phy_cfg = {
>>> + .cpu = TYPE_EXYNOS5250,
>>> + .has_sclk_usbphy30 = false,
>>> +};
>>> +
>>> +static const struct of_device_id exynos5_usb3phy_of_match[] = {
>>> + {
>>> + .compatible = "samsung,exynos5250-usb3phy",
>>> + .data = &exynos5250_usb3phy_cfg
>>> + }, {
>>> + .compatible = "samsung,exynos5420-usb3phy",
>>> + .data = &exynos5420_usb3phy_cfg
>>> + },
>>> + { },
>>> +};
>>> +
>>> +static struct platform_driver exynos5_usb3phy_driver = {
>>> + .probe = exynos5_usb3phy_probe,
>>> + .driver = {
>>> + .of_match_table = exynos5_usb3phy_of_match,
>>> + .name = "exynos5-usb3phy",
>>> + .owner = THIS_MODULE,
>>> + }
>>> +};
>>> +
>>> +module_platform_driver(exynos5_usb3phy_driver);
>>> +MODULE_DESCRIPTION("Samsung EXYNOS5 series SoC USB 3.0 PHY driver");
>>> +MODULE_AUTHOR("Vivek Gautam <gautam.vivek@samsung.com>");
>>> +MODULE_LICENSE("GPL v2"); MODULE_ALIAS("platform:exynos5-usb3phy");
>>>
>
^ permalink raw reply [flat|nested] 36+ messages in thread* [PATCH RFC 1/4] phy: Add new Exynos5 USB 3.0 PHY driver
2013-11-04 13:12 ` Kishon Vijay Abraham I
@ 2013-11-05 7:20 ` Vivek Gautam
2013-11-05 9:34 ` Tomasz Figa
2013-11-05 9:36 ` Kamil Debski
0 siblings, 2 replies; 36+ messages in thread
From: Vivek Gautam @ 2013-11-05 7:20 UTC (permalink / raw)
To: linux-arm-kernel
Hi Kishon,
On Mon, Nov 4, 2013 at 6:42 PM, Kishon Vijay Abraham I <kishon@ti.com> wrote:
> Hi,
>
>
> On Monday 04 November 2013 03:45 PM, Kamil Debski wrote:
>>
>> Hi Kishon,
>>
>>> From: Kishon Vijay Abraham I [mailto:kishon at ti.com]
>>> Sent: Monday, November 04, 2013 7:55 AM
>>>
>>> Hi Vivek,
>>>
>>> On Thursday 31 October 2013 01:15 PM, Vivek Gautam wrote:
>>>>
>>>> Add a new driver for the USB 3.0 PHY on Exynos5 series of SoCs.
>>>> The new driver uses the generic PHY framework and will interact with
>>>> DWC3 controller present on Exynos5 series of SoCs.
>>>
>>>
>>> In Exynos, you have a single IP that supports both USB3 and USB2 PHY
>>> right? I think that needs to be mentioned here.
>>
>>
>> As far as I know the IP is different.
>
>
> Ok. Sometime back Vivek was mentioning about a single IP for both USB3 and
> USB2. Thought it should be this driver. Anyway thanks for the clarification.
Right Kishon, I had mentioned that Exynos5's dwc3 controller have a
single IP for USB2 and USB3 phy.
>From what i see, on exynos5 systems the dwc3 controller uses a combo
of usb 2 (utmi+) and usb 3 (pipe 3) phy
(with base address starting 0x12100000).
Kamil, Tomasz,
Please correct me if i am wrong.
>
> Cheers
> Kishon
>
>>
>>> Do you have separate registers that should be used for
>>> initializing/powerin_on/powering_off etc.. for usb2 phy and usb3 phy?
>>> If so, then you should model this driver as a single driver that
>>> supports two PHYs similar to what Sylwester has done before?
>>
>>
>> Best wishes,
>> Kamil
>>
>>> Cheers
>>> Kishon
>>>
>>>>
>>>> Signed-off-by: Vivek Gautam <gautam.vivek@samsung.com>
>>>> ---
>>>> .../devicetree/bindings/phy/samsung-phy.txt | 20 +
>>>> drivers/phy/Kconfig | 7 +
>>>> drivers/phy/Makefile | 1 +
>>>> drivers/phy/phy-exynos5-usb3.c | 562
>>>
>>> ++++++++++++++++++++
>>>>
>>>> 4 files changed, 590 insertions(+), 0 deletions(-)
>>>> create mode 100644 drivers/phy/phy-exynos5-usb3.c
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/phy/samsung-phy.txt
>>>> b/Documentation/devicetree/bindings/phy/samsung-phy.txt
>>>> index c0fccaa..9b5c111 100644
>>>> --- a/Documentation/devicetree/bindings/phy/samsung-phy.txt
>>>> +++ b/Documentation/devicetree/bindings/phy/samsung-phy.txt
>>>> @@ -20,3 +20,23 @@ Required properties:
>>>> - compatible : should be "samsung,exynos5250-dp-video-phy";
>>>> - reg : offset and length of the Display Port PHY register set;
>>>> - #phy-cells : from the generic PHY bindings, must be 0;
>>>> +
>>>> +Samsung Exynos5 SoC seiries USB 3.0 PHY controller
>>>> +--------------------------------------------------
>>>> +
>>>> +Required properties:
>>>> +- compatible :
>>>> + should be "samsung,exynos5250-usb3phy" for exynos5250 SoC
>>>> + should be "samsung,exynos5420-usb3phy" for exynos5420 SoC
>>>> +- reg : Register offset and length array
>>>> + - first field corresponds to USB 3.0 PHY register set;
>>>> + - second field corresponds to PHY power isolation register
>>>> + present in PMU;
>>>> +- clocks: Clock IDs array as required by the controller
>>>> +- clock-names: names of clocks correseponding to IDs in the clock
>>>
>>> property;
>>>>
>>>> + Required clocks:
>>>> + - first clock is main PHY clock (same as USB 3.0 controller IP
>>>
>>> clock)
>>>>
>>>> + - second clock is reference clock (usually crystal clock)
>>>> + optional clock:
>>>> + - third clock is special clock used by PHY for operation
>>>> +- #phy-cells : from the generic PHY bindings, must be 0;
>>>> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig index
>>>> a344f3d..9a100c6 100644
>>>> --- a/drivers/phy/Kconfig
>>>> +++ b/drivers/phy/Kconfig
>>>> @@ -51,4 +51,11 @@ config PHY_EXYNOS_DP_VIDEO
>>>> help
>>>> Support for Display Port PHY found on Samsung EXYNOS SoCs.
>>>>
>>>> +config PHY_EXYNOS5_USB3
>>>> + tristate "Exynos5 SoC series USB 3.0 PHY driver"
>>>> + depends on ARCH_EXYNOS5
>>>> + select GENERIC_PHY
>>>> + help
>>>> + Enable USB 3.0 PHY support for Exynos 5 SoC series
>>>> +
>>>> endmenu
>>>> diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile index
>>>> d0caae9..9c06a61 100644
>>>> --- a/drivers/phy/Makefile
>>>> +++ b/drivers/phy/Makefile
>>>> @@ -7,3 +7,4 @@ obj-$(CONFIG_PHY_EXYNOS_DP_VIDEO) +=
>>>> phy-exynos-dp-
>>>
>>> video.o
>>>>
>>>> obj-$(CONFIG_PHY_EXYNOS_MIPI_VIDEO) += phy-exynos-mipi-video.o
>>>> obj-$(CONFIG_OMAP_USB2) += phy-omap-usb2.o
>>>> obj-$(CONFIG_TWL4030_USB) += phy-twl4030-usb.o
>>>> +obj-$(CONFIG_PHY_EXYNOS5_USB3) += phy-exynos5-usb3.o
>>>> diff --git a/drivers/phy/phy-exynos5-usb3.c
>>>> b/drivers/phy/phy-exynos5-usb3.c new file mode 100644 index
>>>> 0000000..b9a2674
>>>> --- /dev/null
>>>> +++ b/drivers/phy/phy-exynos5-usb3.c
>>>> @@ -0,0 +1,562 @@
>>>> +/*
>>>> + * Samsung EXYNOS5 SoC series USB 3.0 PHY driver
>>>> + *
>>>> + * Copyright (C) 2013 Samsung Electronics Co., Ltd.
>>>> + * Author: Vivek Gautam <gautam.vivek@samsung.com>
>>>> + *
>>>> + * This program is free software; you can redistribute it and/or
>>>> +modify
>>>> + * it under the terms of the GNU General Public License version 2 as
>>>> + * published by the Free Software Foundation.
>>>> + */
>>>> +
>>>> +#include <linux/clk.h>
>>>> +#include <linux/delay.h>
>>>> +#include <linux/io.h>
>>>> +#include <linux/kernel.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/mutex.h>
>>>> +
>>>> +/* Exynos USB PHY registers */
>>>> +#define EXYNOS5_FSEL_9MHZ6 0x0
>>>> +#define EXYNOS5_FSEL_10MHZ 0x1
>>>> +#define EXYNOS5_FSEL_12MHZ 0x2
>>>> +#define EXYNOS5_FSEL_19MHZ2 0x3
>>>> +#define EXYNOS5_FSEL_20MHZ 0x4
>>>> +#define EXYNOS5_FSEL_24MHZ 0x5
>>>> +#define EXYNOS5_FSEL_50MHZ 0x7
>>>> +
>>>> +/* EXYNOS5: USB 3.0 DRD PHY registers */
>>>> +#define EXYNOS5_DRD_LINKSYSTEM (0x04)
>>>> +
>>>> +#define LINKSYSTEM_FLADJ_MASK (0x3f << 1)
>>>> +#define LINKSYSTEM_FLADJ(_x) ((_x) << 1)
>>>> +#define LINKSYSTEM_XHCI_VERSION_CONTROL (0x1 << 27)
>>>> +
>>>> +#define EXYNOS5_DRD_PHYUTMI (0x08)
>>>> +
>>>> +#define PHYUTMI_OTGDISABLE (0x1 << 6)
>>>> +#define PHYUTMI_FORCESUSPEND (0x1 << 1)
>>>> +#define PHYUTMI_FORCESLEEP (0x1 << 0)
>>>> +
>>>> +#define EXYNOS5_DRD_PHYPIPE (0x0c)
>>>> +
>>>> +#define EXYNOS5_DRD_PHYCLKRST (0x10)
>>>> +
>>>> +#define PHYCLKRST_SSC_REFCLKSEL_MASK (0xff << 23)
>>>> +#define PHYCLKRST_SSC_REFCLKSEL(_x) ((_x) << 23)
>>>> +
>>>> +#define PHYCLKRST_SSC_RANGE_MASK (0x03 << 21)
>>>> +#define PHYCLKRST_SSC_RANGE(_x) ((_x) << 21)
>>>> +
>>>> +#define PHYCLKRST_SSC_EN (0x1 << 20)
>>>> +#define PHYCLKRST_REF_SSP_EN (0x1 << 19)
>>>> +#define PHYCLKRST_REF_CLKDIV2 (0x1 << 18)
>>>> +
>>>> +#define PHYCLKRST_MPLL_MULTIPLIER_MASK (0x7f << 11)
>>>> +#define PHYCLKRST_MPLL_MULTIPLIER_100MHZ_REF (0x19 << 11)
>>>> +#define PHYCLKRST_MPLL_MULTIPLIER_50M_REF (0x02 << 11)
>>>> +#define PHYCLKRST_MPLL_MULTIPLIER_24MHZ_REF (0x68 << 11)
>>>> +#define PHYCLKRST_MPLL_MULTIPLIER_20MHZ_REF (0x7d << 11)
>>>> +#define PHYCLKRST_MPLL_MULTIPLIER_19200KHZ_REF (0x02 << 11)
>>>> +
>>>> +#define PHYCLKRST_FSEL_MASK (0x3f << 5)
>>>> +#define PHYCLKRST_FSEL(_x) ((_x) << 5)
>>>> +#define PHYCLKRST_FSEL_PAD_100MHZ (0x27 << 5)
>>>> +#define PHYCLKRST_FSEL_PAD_24MHZ (0x2a << 5)
>>>> +#define PHYCLKRST_FSEL_PAD_20MHZ (0x31 << 5)
>>>> +#define PHYCLKRST_FSEL_PAD_19_2MHZ (0x38 << 5)
>>>> +
>>>> +#define PHYCLKRST_RETENABLEN (0x1 << 4)
>>>> +
>>>> +#define PHYCLKRST_REFCLKSEL_MASK (0x03 << 2)
>>>> +#define PHYCLKRST_REFCLKSEL_PAD_REFCLK (0x2 << 2)
>>>> +#define PHYCLKRST_REFCLKSEL_EXT_REFCLK (0x3 << 2)
>>>> +
>>>> +#define PHYCLKRST_PORTRESET (0x1 << 1)
>>>> +#define PHYCLKRST_COMMONONN (0x1 << 0)
>>>> +
>>>> +#define EXYNOS5_DRD_PHYREG0 (0x14)
>>>> +#define EXYNOS5_DRD_PHYREG1 (0x18)
>>>> +
>>>> +#define EXYNOS5_DRD_PHYPARAM0 (0x1c)
>>>> +
>>>> +#define PHYPARAM0_REF_USE_PAD (0x1 << 31)
>>>> +#define PHYPARAM0_REF_LOSLEVEL_MASK (0x1f << 26)
>>>> +#define PHYPARAM0_REF_LOSLEVEL (0x9 << 26)
>>>> +
>>>> +#define EXYNOS5_DRD_PHYPARAM1 (0x20)
>>>> +
>>>> +#define PHYPARAM1_PCS_TXDEEMPH_MASK (0x1f << 0)
>>>> +#define PHYPARAM1_PCS_TXDEEMPH (0x1c)
>>>> +
>>>> +#define EXYNOS5_DRD_PHYTERM (0x24)
>>>> +
>>>> +#define EXYNOS5_DRD_PHYTEST (0x28)
>>>> +
>>>> +#define PHYTEST_POWERDOWN_SSP (0x1 << 3)
>>>> +#define PHYTEST_POWERDOWN_HSP (0x1 << 2)
>>>> +
>>>> +#define EXYNOS5_DRD_PHYADP (0x2c)
>>>> +
>>>> +#define EXYNOS5_DRD_PHYBATCHG (0x30)
>>>> +
>>>> +#define PHYBATCHG_UTMI_CLKSEL (0x1 << 2)
>>>> +
>>>> +#define EXYNOS5_DRD_PHYRESUME (0x34)
>>>> +#define EXYNOS5_DRD_LINKPORT (0x44)
>>>> +
>>>> +
>>>> +/* Isolation, configured in the power management unit */
>>>> +#define EXYNOS5_USB_ISOL_DRD (1 << 0)
>>>> +
>>>> +#define CLKSEL_ERROR -1
>>>> +
>>>> +#ifndef KHZ
>>>> +#define KHZ 1000
>>>> +#endif
>>>> +
>>>> +#ifndef MHZ
>>>> +#define MHZ (KHZ * KHZ)
>>>> +#endif
>>>> +
>>>> +enum samsung_cpu_type {
>>>> + TYPE_EXYNOS5250,
>>>> + TYPE_EXYNOS5420,
>>>> +};
>>>> +
>>>> +enum usb3phy_state {
>>>> + STATE_OFF,
>>>> + STATE_ON,
>>>> +};
>>>> +
>>>> +struct usb3phy_config {
>>>> + enum samsung_cpu_type cpu;
>>>> + bool has_sclk_usbphy30;
>>>> +};
>>>> +
>>>> +struct usb3phy_instance {
>>>> + char *label;
>>>> + struct usb3phy_driver *drv;
>>>> + struct phy *phy;
>>>> + enum usb3phy_state state;
>>>> + u32 clk;
>>>> + unsigned long rate;
>>>> +};
>>>> +
>>>> +struct usb3phy_driver {
>>>> + struct device *dev;
>>>> + void __iomem *reg_phy;
>>>> + void __iomem *reg_isol;
>>>> + struct clk *clk;
>>>> + struct clk *sclk_usbphy30;
>>>> + struct usb3phy_instance instance;
>>>> +};
>>>> +
>>>> +/*
>>>> + * exynos5_rate_to_clk() converts the supplied clock rate to the
>>>> +value that
>>>> + * can be written to the phy register.
>>>> + */
>>>> +static u32 exynos5_rate_to_clk(unsigned long rate) {
>>>> + unsigned int clksel;
>>>> +
>>>> + /* EXYNOS5_FSEL_MASK */
>>>> +
>>>> + switch (rate) {
>>>> + case 9600 * KHZ:
>>>> + clksel = EXYNOS5_FSEL_9MHZ6;
>>>> + break;
>>>> + case 10 * MHZ:
>>>> + clksel = EXYNOS5_FSEL_10MHZ;
>>>> + break;
>>>> + case 12 * MHZ:
>>>> + clksel = EXYNOS5_FSEL_12MHZ;
>>>> + break;
>>>> + case 19200 * KHZ:
>>>> + clksel = EXYNOS5_FSEL_19MHZ2;
>>>> + break;
>>>> + case 20 * MHZ:
>>>> + clksel = EXYNOS5_FSEL_20MHZ;
>>>> + break;
>>>> + case 24 * MHZ:
>>>> + clksel = EXYNOS5_FSEL_24MHZ;
>>>> + break;
>>>> + case 50 * MHZ:
>>>> + clksel = EXYNOS5_FSEL_50MHZ;
>>>> + break;
>>>> + default:
>>>> + clksel = CLKSEL_ERROR;
>>>> + }
>>>> +
>>>> + return clksel;
>>>> +}
>>>> +
>>>> +static void exynos5_usb3phy_isol(struct usb3phy_instance *inst, bool
>>>> +on) {
>>>> + struct usb3phy_driver *drv = inst->drv;
>>>> + u32 tmp;
>>>> +
>>>> + if (!drv->reg_isol)
>>>> + return;
>>>> +
>>>> + tmp = readl(drv->reg_isol);
>>>> + if (on)
>>>> + tmp &= ~EXYNOS5_USB_ISOL_DRD;
>>>> + else
>>>> + tmp |= EXYNOS5_USB_ISOL_DRD;
>>>> + writel(tmp, drv->reg_isol);
>>>> +}
>>>> +
>>>> +/*
>>>> + * Sets the phy clk as EXTREFCLK (XXTI) which is internal clock from
>>>
>>> clock core.
>>>>
>>>> + */
>>>> +static u32 exynos5_usb3phy_set_refclk(struct usb3phy_instance *inst)
>>>> +{
>>>> + u32 reg;
>>>> + u32 refclk;
>>>> +
>>>> + refclk = inst->clk;
>>>> +
>>>> + reg = PHYCLKRST_REFCLKSEL_EXT_REFCLK |
>>>> + PHYCLKRST_FSEL(refclk);
>>>> +
>>>> + switch (refclk) {
>>>> + case EXYNOS5_FSEL_50MHZ:
>>>> + reg |= (PHYCLKRST_MPLL_MULTIPLIER_50M_REF |
>>>> + PHYCLKRST_SSC_REFCLKSEL(0x00));
>>>> + break;
>>>> + case EXYNOS5_FSEL_20MHZ:
>>>> + reg |= (PHYCLKRST_MPLL_MULTIPLIER_20MHZ_REF |
>>>> + PHYCLKRST_SSC_REFCLKSEL(0x00));
>>>> + break;
>>>> + case EXYNOS5_FSEL_19MHZ2:
>>>> + reg |= (PHYCLKRST_MPLL_MULTIPLIER_19200KHZ_REF |
>>>> + PHYCLKRST_SSC_REFCLKSEL(0x88));
>>>> + break;
>>>> + case EXYNOS5_FSEL_24MHZ:
>>>> + default:
>>>> + reg |= (PHYCLKRST_MPLL_MULTIPLIER_24MHZ_REF |
>>>> + PHYCLKRST_SSC_REFCLKSEL(0x88));
>>>> + break;
>>>> + }
>>>> +
>>>> + return reg;
>>>> +}
>>>> +
>>>> +static void exynos5_usb3phy_init(struct usb3phy_instance *inst) {
>>>> + struct usb3phy_driver *drv = inst->drv;
>>>> + u32 phyparam0;
>>>> + u32 phyparam1;
>>>> + u32 linksystem;
>>>> + u32 phybatchg;
>>>> + u32 phytest;
>>>> + u32 phyclkrst;
>>>> +
>>>> + /* Reset USB 3.0 PHY */
>>>> + writel(0x0, drv->reg_phy + EXYNOS5_DRD_PHYREG0);
>>>> +
>>>> + phyparam0 = readl(drv->reg_phy + EXYNOS5_DRD_PHYPARAM0);
>>>> + /* Select PHY CLK source */
>>>> + phyparam0 &= ~PHYPARAM0_REF_USE_PAD;
>>>> + /* Set Loss-of-Signal Detector sensitivity */
>>>> + phyparam0 &= ~PHYPARAM0_REF_LOSLEVEL_MASK;
>>>> + phyparam0 |= PHYPARAM0_REF_LOSLEVEL;
>>>> + writel(phyparam0, drv->reg_phy + EXYNOS5_DRD_PHYPARAM0);
>>>> +
>>>> + writel(0x0, drv->reg_phy + EXYNOS5_DRD_PHYRESUME);
>>>> +
>>>> + /*
>>>> + * Setting the Frame length Adj value[6:1] to default 0x20
>>>> + * See xHCI 1.0 spec, 5.2.4
>>>> + */
>>>> + linksystem = LINKSYSTEM_XHCI_VERSION_CONTROL |
>>>> + LINKSYSTEM_FLADJ(0x20);
>>>> + writel(linksystem, drv->reg_phy + EXYNOS5_DRD_LINKSYSTEM);
>>>> +
>>>> + phyparam1 = readl(drv->reg_phy + EXYNOS5_DRD_PHYPARAM1);
>>>> + /* Set Tx De-Emphasis level */
>>>> + phyparam1 &= ~PHYPARAM1_PCS_TXDEEMPH_MASK;
>>>> + phyparam1 |= PHYPARAM1_PCS_TXDEEMPH;
>>>> + writel(phyparam1, drv->reg_phy + EXYNOS5_DRD_PHYPARAM1);
>>>> +
>>>> + phybatchg = readl(drv->reg_phy + EXYNOS5_DRD_PHYBATCHG);
>>>> + phybatchg |= PHYBATCHG_UTMI_CLKSEL;
>>>> + writel(phybatchg, drv->reg_phy + EXYNOS5_DRD_PHYBATCHG);
>>>> +
>>>> + /* PHYTEST POWERDOWN Control */
>>>> + phytest = readl(drv->reg_phy + EXYNOS5_DRD_PHYTEST);
>>>> + phytest &= ~(PHYTEST_POWERDOWN_SSP |
>>>> + PHYTEST_POWERDOWN_HSP);
>>>> + writel(phytest, drv->reg_phy + EXYNOS5_DRD_PHYTEST);
>>>> +
>>>> + /* UTMI Power Control */
>>>> + writel(PHYUTMI_OTGDISABLE, drv->reg_phy + EXYNOS5_DRD_PHYUTMI);
>>>> +
>>>> + phyclkrst = exynos5_usb3phy_set_refclk(inst);
>>>> +
>>>> + phyclkrst |= PHYCLKRST_PORTRESET |
>>>> + /* Digital power supply in normal operating mode */
>>>> + PHYCLKRST_RETENABLEN |
>>>> + /* Enable ref clock for SS function */
>>>> + PHYCLKRST_REF_SSP_EN |
>>>> + /* Enable spread spectrum */
>>>> + PHYCLKRST_SSC_EN |
>>>> + /* Power down HS Bias and PLL blocks in suspend
>>>> mode
>>>
>>> */
>>>>
>>>> + PHYCLKRST_COMMONONN;
>>>> +
>>>> + writel(phyclkrst, drv->reg_phy + EXYNOS5_DRD_PHYCLKRST);
>>>> +
>>>> + udelay(10);
>>>> +
>>>> + phyclkrst &= ~PHYCLKRST_PORTRESET;
>>>> + writel(phyclkrst, drv->reg_phy + EXYNOS5_DRD_PHYCLKRST);
>>>> +
>>>> +}
>>>> +
>>>> +static void exynos5_usb3phy_exit(struct usb3phy_instance *inst) {
>>>> + struct usb3phy_driver *drv = inst->drv;
>>>> + u32 phyutmi;
>>>> + u32 phyclkrst;
>>>> + u32 phytest;
>>>> +
>>>> + phyutmi = PHYUTMI_OTGDISABLE |
>>>> + PHYUTMI_FORCESUSPEND |
>>>> + PHYUTMI_FORCESLEEP;
>>>> + writel(phyutmi, drv->reg_phy + EXYNOS5_DRD_PHYUTMI);
>>>> +
>>>> + /* Resetting the PHYCLKRST enable bits to reduce leakage current
>>>
>>> */
>>>>
>>>> + phyclkrst = readl(drv->reg_phy + EXYNOS5_DRD_PHYCLKRST);
>>>> + phyclkrst &= ~(PHYCLKRST_REF_SSP_EN |
>>>> + PHYCLKRST_SSC_EN |
>>>> + PHYCLKRST_COMMONONN);
>>>> + writel(phyclkrst, drv->reg_phy + EXYNOS5_DRD_PHYCLKRST);
>>>> +
>>>> + /* Control PHYTEST to remove leakage current */
>>>> + phytest = readl(drv->reg_phy + EXYNOS5_DRD_PHYTEST);
>>>> + phytest |= PHYTEST_POWERDOWN_SSP |
>>>> + PHYTEST_POWERDOWN_HSP;
>>>> + writel(phytest, drv->reg_phy + EXYNOS5_DRD_PHYTEST); }
>>>> +
>>>> +static int exynos5_usb3phy_power_on(struct phy *phy) {
>>>> + struct usb3phy_instance *inst = phy_get_drvdata(phy);
>>>> + struct usb3phy_driver *drv = inst->drv;
>>>> + int ret;
>>>> +
>>>> + dev_info(drv->dev, "Request to power_on \"%s\" usb phy\n",
>>>> + inst->label);
>>>> +
>>>> + if (drv->sclk_usbphy30)
>>>> + clk_prepare_enable(drv->sclk_usbphy30);
>>>> +
>>>> + ret = clk_prepare_enable(drv->clk);
>>>> + if (ret)
>>>> + return ret;
>>>> +
>>>> + if (inst->state == STATE_ON) {
>>>> + dev_err(drv->dev, "usb phy \"%s\" already on",
>>>> + inst->label);
>>>> + ret = -ENODEV;
>>>> + goto err0;
>>>> + }
>>>> +
>>>> + inst->state = STATE_ON;
>>>> +
>>>> + /* Initialize the PHY and power it ON */
>>>> + exynos5_usb3phy_init(inst);
>>>> + exynos5_usb3phy_isol(inst, 0);
>>>> +
>>>> +err0:
>>>> + clk_disable_unprepare(drv->clk);
>>>> +
>>>> + return ret;
>>>> +}
>>>> +
>>>> +static int exynos5_usb3phy_power_off(struct phy *phy) {
>>>> + struct usb3phy_instance *inst = phy_get_drvdata(phy);
>>>> + struct usb3phy_driver *drv = inst->drv;
>>>> + int ret;
>>>> +
>>>> + dev_info(drv->dev, "Request to power_off \"%s\" usb phy\n",
>>>> + inst->label);
>>>> + ret = clk_prepare_enable(drv->clk);
>>>> + if (ret)
>>>> + return ret;
>>>> +
>>>> + if (inst->state == STATE_OFF) {
>>>> + dev_err(drv->dev, "usb phy \"%s\" already off",
>>>> + inst->label);
>>>> + ret = -ENODEV;
>>>> + goto err0;
>>>> + }
>>>> +
>>>> + inst->state = STATE_OFF;
>>>> +
>>>> + /* Power-off the PHY and de-initialize it */
>>>> + exynos5_usb3phy_isol(inst, 1);
>>>> + exynos5_usb3phy_exit(inst);
>>>> +
>>>> +err0:
>>>> + clk_disable_unprepare(drv->clk);
>>>> + if (drv->sclk_usbphy30)
>>>> + clk_disable_unprepare(drv->sclk_usbphy30);
>>>> +
>>>> + return ret;
>>>> +}
>>>> +
>>>> +static struct phy_ops exynos5_usb3phy_ops = {
>>>> + .power_on = exynos5_usb3phy_power_on,
>>>> + .power_off = exynos5_usb3phy_power_off,
>>>> + .owner = THIS_MODULE,
>>>> +};
>>>> +
>>>> +static const struct of_device_id exynos5_usb3phy_of_match[];
>>>> +
>>>> +static int exynos5_usb3phy_probe(struct platform_device *pdev) {
>>>> + struct device *dev = &pdev->dev;
>>>> + struct usb3phy_driver *drv;
>>>> + struct usb3phy_instance *inst;
>>>> + struct phy_provider *phy_provider;
>>>> + struct resource *res;
>>>> + struct clk *clk;
>>>> + const struct of_device_id *match;
>>>> + const struct usb3phy_config *cfg;
>>>> +
>>>> + match = of_match_node(exynos5_usb3phy_of_match, pdev-
>>>> dev.of_node);
>>>> + if (!match) {
>>>> + dev_err(dev, "of_match_node() failed\n");
>>>> + return -EINVAL;
>>>> + }
>>>> + cfg = match->data;
>>>> + if (!cfg) {
>>>> + dev_err(dev, "Failed to get configuration\n");
>>>> + return -EINVAL;
>>>> + }
>>>> +
>>>> + drv = devm_kzalloc(dev, sizeof(struct usb3phy_driver),
>>>
>>> GFP_KERNEL);
>>>>
>>>> + if (!drv) {
>>>> + dev_err(dev, "Failed to allocate memory\n");
>>>> + return -ENOMEM;
>>>> + }
>>>> +
>>>> + dev_set_drvdata(dev, drv);
>>>> + drv->dev = dev;
>>>> +
>>>> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>>>> + drv->reg_phy = devm_ioremap_resource(dev, res);
>>>> + if (IS_ERR(drv->reg_phy)) {
>>>> + dev_err(dev, "Failed to map register memory (phy)\n");
>>>> + return PTR_ERR(drv->reg_phy);
>>>> + }
>>>> +
>>>> + res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
>>>> + drv->reg_isol = devm_ioremap_resource(dev, res);
>>>> + if (IS_ERR(drv->reg_isol)) {
>>>> + dev_err(dev, "Failed to map register memory
>>>> (isolation)\n");
>>>> + return PTR_ERR(drv->reg_isol);
>>>> + }
>>>> +
>>>> + phy_provider = devm_of_phy_provider_register(dev,
>>>
>>> of_phy_simple_xlate);
>>>>
>>>> + if (IS_ERR(phy_provider)) {
>>>> + dev_err(drv->dev, "Failed to register phy provider\n");
>>>> + return PTR_ERR(phy_provider);
>>>> + }
>>>> +
>>>> + drv->clk = devm_clk_get(dev, "phy");
>>>> + if (IS_ERR(drv->clk)) {
>>>> + dev_err(dev, "Failed to get clock of phy controller\n");
>>>> + return PTR_ERR(drv->clk);
>>>> + }
>>>> +
>>>> + /*
>>>> + * Exysno5420 SoC has an additional special clock, used for
>>>> + * for USB 3.0 PHY operation, this clock goes to the PHY block
>>>> + * as a reference clock to clock generation block of the
>>>
>>> controller.
>>>>
>>>> + */
>>>> + if (cfg->has_sclk_usbphy30) {
>>>> + drv->sclk_usbphy30 = devm_clk_get(dev, "sclk_usbphy30");
>>>> + if (IS_ERR(drv->clk)) {
>>>> + dev_err(dev, "Failed to get phy reference
>>>> clock\n");
>>>> + return PTR_ERR(drv->clk);
>>>> + }
>>>> + }
>>>> +
>>>> + inst = &drv->instance;
>>>> + inst->drv = drv;
>>>> + inst->label = "usb3drd";
>>>> +
>>>> + dev_info(dev, "Creating phy \"%s\"\n", inst->label);
>>>> + inst->phy = devm_phy_create(dev, &exynos5_usb3phy_ops, NULL);
>>>> + if (IS_ERR(inst->phy)) {
>>>> + dev_err(drv->dev, "Failed to create usb3phy \"%s\"\n",
>>>> + inst->label);
>>>> + return PTR_ERR(inst->phy);
>>>> + }
>>>> +
>>>> + phy_set_drvdata(inst->phy, inst);
>>>> +
>>>> + clk = clk_get(dev, inst->label);
>>>> + if (IS_ERR(clk)) {
>>>> + dev_err(dev, "Failed to get clock of \"%s\" phy\n",
>>>> + inst->label);
>>>> + return PTR_ERR(clk);
>>>> + }
>>>> +
>>>> + inst->rate = clk_get_rate(clk);
>>>> +
>>>> + inst->clk = exynos5_rate_to_clk(inst->rate);
>>>> + if (inst->clk == CLKSEL_ERROR) {
>>>> + dev_err(dev, "Clock rate (%ld) not supported\n",
>>>> + inst->rate);
>>>> + clk_put(clk);
>>>> + return -EINVAL;
>>>> + }
>>>> + clk_put(clk);
>>>> +
>>>> + return 0;
>>>> +}
>>>> +
>>>> +const struct usb3phy_config exynos5420_usb3phy_cfg = {
>>>> + .cpu = TYPE_EXYNOS5420,
>>>> + .has_sclk_usbphy30 = true,
>>>> +};
>>>> +
>>>> +const struct usb3phy_config exynos5250_usb3phy_cfg = {
>>>> + .cpu = TYPE_EXYNOS5250,
>>>> + .has_sclk_usbphy30 = false,
>>>> +};
>>>> +
>>>> +static const struct of_device_id exynos5_usb3phy_of_match[] = {
>>>> + {
>>>> + .compatible = "samsung,exynos5250-usb3phy",
>>>> + .data = &exynos5250_usb3phy_cfg
>>>> + }, {
>>>> + .compatible = "samsung,exynos5420-usb3phy",
>>>> + .data = &exynos5420_usb3phy_cfg
>>>> + },
>>>> + { },
>>>> +};
>>>> +
>>>> +static struct platform_driver exynos5_usb3phy_driver = {
>>>> + .probe = exynos5_usb3phy_probe,
>>>> + .driver = {
>>>> + .of_match_table = exynos5_usb3phy_of_match,
>>>> + .name = "exynos5-usb3phy",
>>>> + .owner = THIS_MODULE,
>>>> + }
>>>> +};
>>>> +
>>>> +module_platform_driver(exynos5_usb3phy_driver);
>>>> +MODULE_DESCRIPTION("Samsung EXYNOS5 series SoC USB 3.0 PHY driver");
>>>> +MODULE_AUTHOR("Vivek Gautam <gautam.vivek@samsung.com>");
>>>> +MODULE_LICENSE("GPL v2"); MODULE_ALIAS("platform:exynos5-usb3phy");
>>>>
>>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
>
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Best Regards
Vivek Gautam
Samsung R&D Institute, Bangalore
India
^ permalink raw reply [flat|nested] 36+ messages in thread* [PATCH RFC 1/4] phy: Add new Exynos5 USB 3.0 PHY driver
2013-11-05 7:20 ` Vivek Gautam
@ 2013-11-05 9:34 ` Tomasz Figa
2013-11-05 9:36 ` Kamil Debski
1 sibling, 0 replies; 36+ messages in thread
From: Tomasz Figa @ 2013-11-05 9:34 UTC (permalink / raw)
To: linux-arm-kernel
On Tuesday 05 of November 2013 12:50:18 Vivek Gautam wrote:
> Hi Kishon,
>
> On Mon, Nov 4, 2013 at 6:42 PM, Kishon Vijay Abraham I <kishon@ti.com>
wrote:
> > Hi,
> >
> > On Monday 04 November 2013 03:45 PM, Kamil Debski wrote:
> >> Hi Kishon,
> >>
> >>> From: Kishon Vijay Abraham I [mailto:kishon at ti.com]
> >>> Sent: Monday, November 04, 2013 7:55 AM
> >>>
> >>> Hi Vivek,
> >>>
> >>> On Thursday 31 October 2013 01:15 PM, Vivek Gautam wrote:
> >>>> Add a new driver for the USB 3.0 PHY on Exynos5 series of SoCs.
> >>>> The new driver uses the generic PHY framework and will interact
> >>>> with
> >>>> DWC3 controller present on Exynos5 series of SoCs.
> >>>
> >>> In Exynos, you have a single IP that supports both USB3 and USB2 PHY
> >>> right? I think that needs to be mentioned here.
> >>
> >> As far as I know the IP is different.
> >
> > Ok. Sometime back Vivek was mentioning about a single IP for both USB3
> > and USB2. Thought it should be this driver. Anyway thanks for the
> > clarification.
> Right Kishon, I had mentioned that Exynos5's dwc3 controller have a
> single IP for USB2 and USB3 phy.
> From what i see, on exynos5 systems the dwc3 controller uses a combo
> of usb 2 (utmi+) and usb 3 (pipe 3) phy
> (with base address starting 0x12100000).
I meant there is a single PHY used with the USB 3.0 controller (dwc3) and
it is different from the PHY used with the USB 2.0 controller (s3c-hsotg
aka dwc2). The USB 3.0 PHY and controller blocks also support USB 2.0
operation, though. So we were both right. ;)
Best regards,
Tomasz
^ permalink raw reply [flat|nested] 36+ messages in thread
* [PATCH RFC 1/4] phy: Add new Exynos5 USB 3.0 PHY driver
2013-11-05 7:20 ` Vivek Gautam
2013-11-05 9:34 ` Tomasz Figa
@ 2013-11-05 9:36 ` Kamil Debski
2013-11-05 11:12 ` Jingoo Han
2013-11-05 17:56 ` Vivek Gautam
1 sibling, 2 replies; 36+ messages in thread
From: Kamil Debski @ 2013-11-05 9:36 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
> From: Vivek Gautam [mailto:gautamvivek1987 at gmail.com]
> Sent: Tuesday, November 05, 2013 8:20 AM
> To: Kishon Vijay Abraham I
> Cc: Kamil Debski; Vivek Gautam; Linux USB Mailing List; linux-samsung-
> soc at vger.kernel.org; linux-kernel at vger.kernel.org;
> devicetree at vger.kernel.org; linux-arm-kernel at lists.infradead.org;
> linux-doc at vger.kernel.org; Greg KH; Kukjin Kim; Sylwester Nawrocki;
> Tomasz Figa; Felipe Balbi; Julius Werner; Jingoo Han
> Subject: Re: [PATCH RFC 1/4] phy: Add new Exynos5 USB 3.0 PHY driver
>
> Hi Kishon,
>
>
>
> On Mon, Nov 4, 2013 at 6:42 PM, Kishon Vijay Abraham I <kishon@ti.com>
> wrote:
> > Hi,
> >
> >
> > On Monday 04 November 2013 03:45 PM, Kamil Debski wrote:
> >>
> >> Hi Kishon,
> >>
> >>> From: Kishon Vijay Abraham I [mailto:kishon at ti.com]
> >>> Sent: Monday, November 04, 2013 7:55 AM
> >>>
> >>> Hi Vivek,
> >>>
> >>> On Thursday 31 October 2013 01:15 PM, Vivek Gautam wrote:
> >>>>
> >>>> Add a new driver for the USB 3.0 PHY on Exynos5 series of SoCs.
> >>>> The new driver uses the generic PHY framework and will interact
> >>>> with
> >>>> DWC3 controller present on Exynos5 series of SoCs.
> >>>
> >>>
> >>> In Exynos, you have a single IP that supports both USB3 and USB2
> PHY
> >>> right? I think that needs to be mentioned here.
> >>
> >>
> >> As far as I know the IP is different.
> >
> >
> > Ok. Sometime back Vivek was mentioning about a single IP for both
> USB3
> > and USB2. Thought it should be this driver. Anyway thanks for the
> clarification.
>
> Right Kishon, I had mentioned that Exynos5's dwc3 controller have a
> single IP for USB2 and USB3 phy.
> From what i see, on exynos5 systems the dwc3 controller uses a combo of
> usb 2 (utmi+) and usb 3 (pipe 3) phy (with base address starting
> 0x12100000).
>
> Kamil, Tomasz,
>
> Please correct me if i am wrong.
I have the Exynos 5250 documentation and I found two phy register ranges:
1) USB 2.0 PHY having the base address of 0x1213 0000
Chapter 33. USB 2.0 Host Controller
Subchapter 33.5.2 Phy Control Register p. 1696
First register's description is
"USB2.0 phy control register"
2) USB 3.0 PHY (I guess) with the base address 0x1210 0000
Chapter 35. USB 3.0 DRD Controller
Subchapter 35.4.6 PHY Control Register p. 1872
Jingoo, could you comment on the above? You may know more than we do :)
In addition, I have a question to you Vivek - does your USB 3.0
PHY support both host and device?
[snip]
Best wishes,
Kamil Debski
^ permalink raw reply [flat|nested] 36+ messages in thread
* [PATCH RFC 1/4] phy: Add new Exynos5 USB 3.0 PHY driver
2013-11-05 9:36 ` Kamil Debski
@ 2013-11-05 11:12 ` Jingoo Han
2013-11-05 12:03 ` Jingoo Han
2013-11-05 17:56 ` Vivek Gautam
1 sibling, 1 reply; 36+ messages in thread
From: Jingoo Han @ 2013-11-05 11:12 UTC (permalink / raw)
To: linux-arm-kernel
On Tuesday, November 05, 2013 6:37 PM, Kamil Debski wrote:
> On Tuesday, November 05, 2013 8:20 AM, Vivek Gautam wrote:
> > On Mon, Nov 4, 2013 at 6:42 PM, Kishon Vijay Abraham I <kishon@ti.com> wrote:
> > > On Monday 04 November 2013 03:45 PM, Kamil Debski wrote:
> > >> On Monday, November 04, 2013 7:55 AM, Kishon Vijay Abraham I wrote:
> > >>> On Thursday 31 October 2013 01:15 PM, Vivek Gautam wrote:
> > >>>>
> > >>>> Add a new driver for the USB 3.0 PHY on Exynos5 series of SoCs.
> > >>>> The new driver uses the generic PHY framework and will interact
> > >>>> with
> > >>>> DWC3 controller present on Exynos5 series of SoCs.
> > >>>
> > >>>
> > >>> In Exynos, you have a single IP that supports both USB3 and USB2
> > PHY
> > >>> right? I think that needs to be mentioned here.
> > >>
> > >>
> > >> As far as I know the IP is different.
> > >
> > >
> > > Ok. Sometime back Vivek was mentioning about a single IP for both
> > USB3
> > > and USB2. Thought it should be this driver. Anyway thanks for the
> > clarification.
> >
> > Right Kishon, I had mentioned that Exynos5's dwc3 controller have a
> > single IP for USB2 and USB3 phy.
> > From what i see, on exynos5 systems the dwc3 controller uses a combo of
> > usb 2 (utmi+) and usb 3 (pipe 3) phy (with base address starting
> > 0x12100000).
> >
> > Kamil, Tomasz,
> >
> > Please correct me if i am wrong.
>
> I have the Exynos 5250 documentation and I found two phy register ranges:
> 1) USB 2.0 PHY having the base address of 0x1213 0000
> Chapter 33. USB 2.0 Host Controller
> Subchapter 33.5.2 Phy Control Register p. 1696
> First register's description is
> "USB2.0 phy control register"
> 2) USB 3.0 PHY (I guess) with the base address 0x1210 0000
> Chapter 35. USB 3.0 DRD Controller
> Subchapter 35.4.6 PHY Control Register p. 1872
>
> Jingoo, could you comment on the above? You may know more than we do :)
Hi Kamil,
Thank you for trusting me. :-)
I just asked my validation engineer about 5250 USB PHY.
As I know, she has the best knowledge about Samsung SoC USB hardware.
She said that there are 2 PHY controllers such as USB 2.0 PHY, USB 3.0 PHY.
1) USB2.0 PHY: USB2.0 HOST, USB2.0 Device
2) USB3.0 PHY: USB3.0 DRD (3.0 HOST & 3.0 Device)
> In addition, I have a question to you Vivek - does your USB 3.0
> PHY support both host and device?
According to her, USB3.0 PHY can support both 3.0 Host and 3.0 Device.
Thank you.
Best regards,
Jingoo Han
^ permalink raw reply [flat|nested] 36+ messages in thread
* [PATCH RFC 1/4] phy: Add new Exynos5 USB 3.0 PHY driver
2013-11-05 11:12 ` Jingoo Han
@ 2013-11-05 12:03 ` Jingoo Han
2013-11-05 17:58 ` Vivek Gautam
0 siblings, 1 reply; 36+ messages in thread
From: Jingoo Han @ 2013-11-05 12:03 UTC (permalink / raw)
To: linux-arm-kernel
On Tuesday, November 05, 2013 8:13 PM, Jingoo Han wrote:
> On Tuesday, November 05, 2013 6:37 PM, Kamil Debski wrote:
> > On Tuesday, November 05, 2013 8:20 AM, Vivek Gautam wrote:
> > > On Mon, Nov 4, 2013 at 6:42 PM, Kishon Vijay Abraham I <kishon@ti.com> wrote:
> > > > On Monday 04 November 2013 03:45 PM, Kamil Debski wrote:
> > > >> On Monday, November 04, 2013 7:55 AM, Kishon Vijay Abraham I wrote:
> > > >>> On Thursday 31 October 2013 01:15 PM, Vivek Gautam wrote:
> > > >>>>
> > > >>>> Add a new driver for the USB 3.0 PHY on Exynos5 series of SoCs.
> > > >>>> The new driver uses the generic PHY framework and will interact
> > > >>>> with
> > > >>>> DWC3 controller present on Exynos5 series of SoCs.
> > > >>>
> > > >>>
> > > >>> In Exynos, you have a single IP that supports both USB3 and USB2
> > > PHY
> > > >>> right? I think that needs to be mentioned here.
> > > >>
> > > >>
> > > >> As far as I know the IP is different.
> > > >
> > > >
> > > > Ok. Sometime back Vivek was mentioning about a single IP for both
> > > USB3
> > > > and USB2. Thought it should be this driver. Anyway thanks for the
> > > clarification.
> > >
> > > Right Kishon, I had mentioned that Exynos5's dwc3 controller have a
> > > single IP for USB2 and USB3 phy.
> > > From what i see, on exynos5 systems the dwc3 controller uses a combo of
> > > usb 2 (utmi+) and usb 3 (pipe 3) phy (with base address starting
> > > 0x12100000).
> > >
> > > Kamil, Tomasz,
> > >
> > > Please correct me if i am wrong.
> >
> > I have the Exynos 5250 documentation and I found two phy register ranges:
> > 1) USB 2.0 PHY having the base address of 0x1213 0000
> > Chapter 33. USB 2.0 Host Controller
> > Subchapter 33.5.2 Phy Control Register p. 1696
> > First register's description is
> > "USB2.0 phy control register"
> > 2) USB 3.0 PHY (I guess) with the base address 0x1210 0000
> > Chapter 35. USB 3.0 DRD Controller
> > Subchapter 35.4.6 PHY Control Register p. 1872
> >
> > Jingoo, could you comment on the above? You may know more than we do :)
>
> Hi Kamil,
>
> Thank you for trusting me. :-)
> I just asked my validation engineer about 5250 USB PHY.
> As I know, she has the best knowledge about Samsung SoC USB hardware.
> She said that there are 2 PHY controllers such as USB 2.0 PHY, USB 3.0 PHY.
>
> 1) USB2.0 PHY: USB2.0 HOST, USB2.0 Device
> 2) USB3.0 PHY: USB3.0 DRD (3.0 HOST & 3.0 Device)
>
> > In addition, I have a question to you Vivek - does your USB 3.0
> > PHY support both host and device?
>
> According to her, USB3.0 PHY can support both 3.0 Host and 3.0 Device.
> Thank you.
In addition to this,
Vivek's comment is also right. :-)
A few minutes ago, I asked one of my USB S/W engineers.
USB3.0 PHY consists of two blocks such as 3.0 block and 2.0 block.
This USB3.0 PHY can support UTMI+ and PIPE3 interface for 3.0 block
and 2.0 block, respectively.
Conclusion:
1) USB2.0 PHY: USB2.0 HOST, USB2.0 Device
Base address: 0x1213 0000
2) USB3.0 PHY: USB3.0 DRD (3.0 HOST & 3.0 Device)
Base address: 0x1210 0000
2.0 block(UTMI+) & 3.0 block(PIPE3)
Best regards,
Jingoo Han
^ permalink raw reply [flat|nested] 36+ messages in thread* [PATCH RFC 1/4] phy: Add new Exynos5 USB 3.0 PHY driver
2013-11-05 12:03 ` Jingoo Han
@ 2013-11-05 17:58 ` Vivek Gautam
2013-11-06 0:07 ` Jingoo Han
0 siblings, 1 reply; 36+ messages in thread
From: Vivek Gautam @ 2013-11-05 17:58 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Nov 5, 2013 at 5:33 PM, Jingoo Han <jg1.han@samsung.com> wrote:
> On Tuesday, November 05, 2013 8:13 PM, Jingoo Han wrote:
>> On Tuesday, November 05, 2013 6:37 PM, Kamil Debski wrote:
>> > On Tuesday, November 05, 2013 8:20 AM, Vivek Gautam wrote:
>> > > On Mon, Nov 4, 2013 at 6:42 PM, Kishon Vijay Abraham I <kishon@ti.com> wrote:
>> > > > On Monday 04 November 2013 03:45 PM, Kamil Debski wrote:
>> > > >> On Monday, November 04, 2013 7:55 AM, Kishon Vijay Abraham I wrote:
>> > > >>> On Thursday 31 October 2013 01:15 PM, Vivek Gautam wrote:
>> > > >>>>
>> > > >>>> Add a new driver for the USB 3.0 PHY on Exynos5 series of SoCs.
>> > > >>>> The new driver uses the generic PHY framework and will interact
>> > > >>>> with
>> > > >>>> DWC3 controller present on Exynos5 series of SoCs.
>> > > >>>
>> > > >>>
>> > > >>> In Exynos, you have a single IP that supports both USB3 and USB2
>> > > PHY
>> > > >>> right? I think that needs to be mentioned here.
>> > > >>
>> > > >>
>> > > >> As far as I know the IP is different.
>> > > >
>> > > >
>> > > > Ok. Sometime back Vivek was mentioning about a single IP for both
>> > > USB3
>> > > > and USB2. Thought it should be this driver. Anyway thanks for the
>> > > clarification.
>> > >
>> > > Right Kishon, I had mentioned that Exynos5's dwc3 controller have a
>> > > single IP for USB2 and USB3 phy.
>> > > From what i see, on exynos5 systems the dwc3 controller uses a combo of
>> > > usb 2 (utmi+) and usb 3 (pipe 3) phy (with base address starting
>> > > 0x12100000).
>> > >
>> > > Kamil, Tomasz,
>> > >
>> > > Please correct me if i am wrong.
>> >
>> > I have the Exynos 5250 documentation and I found two phy register ranges:
>> > 1) USB 2.0 PHY having the base address of 0x1213 0000
>> > Chapter 33. USB 2.0 Host Controller
>> > Subchapter 33.5.2 Phy Control Register p. 1696
>> > First register's description is
>> > "USB2.0 phy control register"
>> > 2) USB 3.0 PHY (I guess) with the base address 0x1210 0000
>> > Chapter 35. USB 3.0 DRD Controller
>> > Subchapter 35.4.6 PHY Control Register p. 1872
>> >
>> > Jingoo, could you comment on the above? You may know more than we do :)
>>
>> Hi Kamil,
>>
>> Thank you for trusting me. :-)
>> I just asked my validation engineer about 5250 USB PHY.
Thank you for clarifying this. This was really kind of you to help in
making things clear.
>> As I know, she has the best knowledge about Samsung SoC USB hardware.
>> She said that there are 2 PHY controllers such as USB 2.0 PHY, USB 3.0 PHY.
>>
>> 1) USB2.0 PHY: USB2.0 HOST, USB2.0 Device
>> 2) USB3.0 PHY: USB3.0 DRD (3.0 HOST & 3.0 Device)
>>
>> > In addition, I have a question to you Vivek - does your USB 3.0
>> > PHY support both host and device?
>>
>> According to her, USB3.0 PHY can support both 3.0 Host and 3.0 Device.
>> Thank you.
>
> In addition to this,
>
> Vivek's comment is also right. :-)
> A few minutes ago, I asked one of my USB S/W engineers.
>
> USB3.0 PHY consists of two blocks such as 3.0 block and 2.0 block.
> This USB3.0 PHY can support UTMI+ and PIPE3 interface for 3.0 block
> and 2.0 block, respectively.
>
> Conclusion:
>
> 1) USB2.0 PHY: USB2.0 HOST, USB2.0 Device
> Base address: 0x1213 0000
>
> 2) USB3.0 PHY: USB3.0 DRD (3.0 HOST & 3.0 Device)
> Base address: 0x1210 0000
> 2.0 block(UTMI+) & 3.0 block(PIPE3)
And this is ofcourse the PHY used by DWC3 controller, which works at
both High speed as well as Super Speed.
Right ?
>
>
> Best regards,
> Jingoo Han
>
--
Best Regards
Vivek Gautam
Samsung R&D Institute, Bangalore
India
^ permalink raw reply [flat|nested] 36+ messages in thread
* [PATCH RFC 1/4] phy: Add new Exynos5 USB 3.0 PHY driver
2013-11-05 17:58 ` Vivek Gautam
@ 2013-11-06 0:07 ` Jingoo Han
2013-11-11 11:11 ` Kishon Vijay Abraham I
0 siblings, 1 reply; 36+ messages in thread
From: Jingoo Han @ 2013-11-06 0:07 UTC (permalink / raw)
To: linux-arm-kernel
On Wednesday, November 06, 2013 2:58 AM, Vivek Gautam wrote:
> On Tue, Nov 5, 2013 at 5:33 PM, Jingoo Han <jg1.han@samsung.com> wrote:
[.....]
>> USB3.0 PHY consists of two blocks such as 3.0 block and 2.0 block.
>> This USB3.0 PHY can support UTMI+ and PIPE3 interface for 3.0 block
>> and 2.0 block, respectively.
>>
>> Conclusion:
>>
>> 1) USB2.0 PHY: USB2.0 HOST, USB2.0 Device
>> Base address: 0x1213 0000
>>
>> 2) USB3.0 PHY: USB3.0 DRD (3.0 HOST & 3.0 Device)
>> Base address: 0x1210 0000
>> 2.0 block(UTMI+) & 3.0 block(PIPE3)
>
> And this is of course the PHY used by DWC3 controller, which works at
> both High speed as well as Super Speed.
> Right ?
Right.
While 3.0 block(PIPE3) can be used for Super Speed, 2.0 block(UTMI+)
can be used for High speed.
Best regards,
Jingoo Han
^ permalink raw reply [flat|nested] 36+ messages in thread
* [PATCH RFC 1/4] phy: Add new Exynos5 USB 3.0 PHY driver
2013-11-06 0:07 ` Jingoo Han
@ 2013-11-11 11:11 ` Kishon Vijay Abraham I
2013-11-20 8:57 ` Vivek Gautam
0 siblings, 1 reply; 36+ messages in thread
From: Kishon Vijay Abraham I @ 2013-11-11 11:11 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
On Wednesday 06 November 2013 05:37 AM, Jingoo Han wrote:
> On Wednesday, November 06, 2013 2:58 AM, Vivek Gautam wrote:
>> On Tue, Nov 5, 2013 at 5:33 PM, Jingoo Han <jg1.han@samsung.com> wrote:
>
> [.....]
>
>>> USB3.0 PHY consists of two blocks such as 3.0 block and 2.0 block.
>>> This USB3.0 PHY can support UTMI+ and PIPE3 interface for 3.0 block
>>> and 2.0 block, respectively.
>>>
>>> Conclusion:
>>>
>>> 1) USB2.0 PHY: USB2.0 HOST, USB2.0 Device
>>> Base address: 0x1213 0000
>>>
>>> 2) USB3.0 PHY: USB3.0 DRD (3.0 HOST & 3.0 Device)
>>> Base address: 0x1210 0000
>>> 2.0 block(UTMI+) & 3.0 block(PIPE3)
>>
>> And this is of course the PHY used by DWC3 controller, which works at
>> both High speed as well as Super Speed.
>> Right ?
>
> Right.
>
> While 3.0 block(PIPE3) can be used for Super Speed, 2.0 block(UTMI+)
> can be used for High speed.
It should then come under *single IP muliple PHY* category similar to what
Sylwester has done.
Thanks
Kishon
^ permalink raw reply [flat|nested] 36+ messages in thread
* [PATCH RFC 1/4] phy: Add new Exynos5 USB 3.0 PHY driver
2013-11-11 11:11 ` Kishon Vijay Abraham I
@ 2013-11-20 8:57 ` Vivek Gautam
2013-11-20 9:04 ` Kishon Vijay Abraham I
0 siblings, 1 reply; 36+ messages in thread
From: Vivek Gautam @ 2013-11-20 8:57 UTC (permalink / raw)
To: linux-arm-kernel
Hi Kishon,
On Mon, Nov 11, 2013 at 4:41 PM, Kishon Vijay Abraham I <kishon@ti.com> wrote:
> Hi,
sorry for the delayed response.
>
> On Wednesday 06 November 2013 05:37 AM, Jingoo Han wrote:
>> On Wednesday, November 06, 2013 2:58 AM, Vivek Gautam wrote:
>>> On Tue, Nov 5, 2013 at 5:33 PM, Jingoo Han <jg1.han@samsung.com> wrote:
>>
>> [.....]
>>
>>>> USB3.0 PHY consists of two blocks such as 3.0 block and 2.0 block.
>>>> This USB3.0 PHY can support UTMI+ and PIPE3 interface for 3.0 block
>>>> and 2.0 block, respectively.
>>>>
>>>> Conclusion:
>>>>
>>>> 1) USB2.0 PHY: USB2.0 HOST, USB2.0 Device
>>>> Base address: 0x1213 0000
>>>>
>>>> 2) USB3.0 PHY: USB3.0 DRD (3.0 HOST & 3.0 Device)
>>>> Base address: 0x1210 0000
>>>> 2.0 block(UTMI+) & 3.0 block(PIPE3)
>>>
>>> And this is of course the PHY used by DWC3 controller, which works at
>>> both High speed as well as Super Speed.
>>> Right ?
>>
>> Right.
>>
>> While 3.0 block(PIPE3) can be used for Super Speed, 2.0 block(UTMI+)
>> can be used for High speed.
>
> It should then come under *single IP muliple PHY* category similar to what
> Sylwester has done.
Do you mean that i should be including PHY IDs for UTMI+ phy and PIPE3
phy present in this PHY block ?
AFAICS the two phys (UTMI+ and PIPE3) do not really have separate
registers to program, and that's the reason
we program the entire PHY in a shot.
>
> Thanks
> Kishon
--
Best Regards
Vivek Gautam
Samsung R&D Institute, Bangalore
India
^ permalink raw reply [flat|nested] 36+ messages in thread
* [PATCH RFC 1/4] phy: Add new Exynos5 USB 3.0 PHY driver
2013-11-20 8:57 ` Vivek Gautam
@ 2013-11-20 9:04 ` Kishon Vijay Abraham I
2013-11-20 9:32 ` Vivek Gautam
0 siblings, 1 reply; 36+ messages in thread
From: Kishon Vijay Abraham I @ 2013-11-20 9:04 UTC (permalink / raw)
To: linux-arm-kernel
On Wednesday 20 November 2013 02:27 PM, Vivek Gautam wrote:
> Hi Kishon,
>
>
> On Mon, Nov 11, 2013 at 4:41 PM, Kishon Vijay Abraham I <kishon@ti.com> wrote:
>> Hi,
> sorry for the delayed response.
>
>>
>> On Wednesday 06 November 2013 05:37 AM, Jingoo Han wrote:
>>> On Wednesday, November 06, 2013 2:58 AM, Vivek Gautam wrote:
>>>> On Tue, Nov 5, 2013 at 5:33 PM, Jingoo Han <jg1.han@samsung.com> wrote:
>>>
>>> [.....]
>>>
>>>>> USB3.0 PHY consists of two blocks such as 3.0 block and 2.0 block.
>>>>> This USB3.0 PHY can support UTMI+ and PIPE3 interface for 3.0 block
>>>>> and 2.0 block, respectively.
>>>>>
>>>>> Conclusion:
>>>>>
>>>>> 1) USB2.0 PHY: USB2.0 HOST, USB2.0 Device
>>>>> Base address: 0x1213 0000
>>>>>
>>>>> 2) USB3.0 PHY: USB3.0 DRD (3.0 HOST & 3.0 Device)
>>>>> Base address: 0x1210 0000
>>>>> 2.0 block(UTMI+) & 3.0 block(PIPE3)
>>>>
>>>> And this is of course the PHY used by DWC3 controller, which works at
>>>> both High speed as well as Super Speed.
>>>> Right ?
>>>
>>> Right.
>>>
>>> While 3.0 block(PIPE3) can be used for Super Speed, 2.0 block(UTMI+)
>>> can be used for High speed.
>>
>> It should then come under *single IP muliple PHY* category similar to what
>> Sylwester has done.
>
> Do you mean that i should be including PHY IDs for UTMI+ phy and PIPE3
> phy present in this PHY block ?
> AFAICS the two phys (UTMI+ and PIPE3) do not really have separate
> registers to program, and that's the reason
> we program the entire PHY in a shot.
you mean you program the same set of bits for UTMI+ and PIPE3?
Thanks
Kishon
^ permalink raw reply [flat|nested] 36+ messages in thread
* [PATCH RFC 1/4] phy: Add new Exynos5 USB 3.0 PHY driver
2013-11-20 9:04 ` Kishon Vijay Abraham I
@ 2013-11-20 9:32 ` Vivek Gautam
2013-11-20 15:44 ` Kishon Vijay Abraham I
0 siblings, 1 reply; 36+ messages in thread
From: Vivek Gautam @ 2013-11-20 9:32 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, Nov 20, 2013 at 2:34 PM, Kishon Vijay Abraham I <kishon@ti.com> wrote:
> On Wednesday 20 November 2013 02:27 PM, Vivek Gautam wrote:
>> Hi Kishon,
>>
>>
>> On Mon, Nov 11, 2013 at 4:41 PM, Kishon Vijay Abraham I <kishon@ti.com> wrote:
>>> Hi,
>> sorry for the delayed response.
>>
>>>
>>> On Wednesday 06 November 2013 05:37 AM, Jingoo Han wrote:
>>>> On Wednesday, November 06, 2013 2:58 AM, Vivek Gautam wrote:
>>>>> On Tue, Nov 5, 2013 at 5:33 PM, Jingoo Han <jg1.han@samsung.com> wrote:
>>>>
>>>> [.....]
>>>>
>>>>>> USB3.0 PHY consists of two blocks such as 3.0 block and 2.0 block.
>>>>>> This USB3.0 PHY can support UTMI+ and PIPE3 interface for 3.0 block
>>>>>> and 2.0 block, respectively.
>>>>>>
>>>>>> Conclusion:
>>>>>>
>>>>>> 1) USB2.0 PHY: USB2.0 HOST, USB2.0 Device
>>>>>> Base address: 0x1213 0000
>>>>>>
>>>>>> 2) USB3.0 PHY: USB3.0 DRD (3.0 HOST & 3.0 Device)
>>>>>> Base address: 0x1210 0000
>>>>>> 2.0 block(UTMI+) & 3.0 block(PIPE3)
>>>>>
>>>>> And this is of course the PHY used by DWC3 controller, which works at
>>>>> both High speed as well as Super Speed.
>>>>> Right ?
>>>>
>>>> Right.
>>>>
>>>> While 3.0 block(PIPE3) can be used for Super Speed, 2.0 block(UTMI+)
>>>> can be used for High speed.
>>>
>>> It should then come under *single IP muliple PHY* category similar to what
>>> Sylwester has done.
>>
>> Do you mean that i should be including PHY IDs for UTMI+ phy and PIPE3
>> phy present in this PHY block ?
>> AFAICS the two phys (UTMI+ and PIPE3) do not really have separate
>> registers to program, and that's the reason
>> we program the entire PHY in a shot.
>
> you mean you program the same set of bits for UTMI+ and PIPE3?
No, looking closely into PHY datasheet as well as Exynos5250 manual, i
can see that UTMI+ and PIPE3
phys have separate bit settings. So i think we should be able to
segregate the two PHYs (UTMI+ and PIPE3).
Pardon me for my earlier observations.
Let me clarify more with our h/w team also on this and then i will
confirm with this.
>
> Thanks
> Kishon
--
Best Regards
Vivek Gautam
Samsung R&D Institute, Bangalore
India
^ permalink raw reply [flat|nested] 36+ messages in thread
* [PATCH RFC 1/4] phy: Add new Exynos5 USB 3.0 PHY driver
2013-11-20 9:32 ` Vivek Gautam
@ 2013-11-20 15:44 ` Kishon Vijay Abraham I
2013-12-04 14:28 ` Kishon Vijay Abraham I
0 siblings, 1 reply; 36+ messages in thread
From: Kishon Vijay Abraham I @ 2013-11-20 15:44 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
On Wednesday 20 November 2013 03:02 PM, Vivek Gautam wrote:
> On Wed, Nov 20, 2013 at 2:34 PM, Kishon Vijay Abraham I <kishon@ti.com> wrote:
>> On Wednesday 20 November 2013 02:27 PM, Vivek Gautam wrote:
>>> Hi Kishon,
>>>
>>>
>>> On Mon, Nov 11, 2013 at 4:41 PM, Kishon Vijay Abraham I <kishon@ti.com> wrote:
>>>> Hi,
>>> sorry for the delayed response.
>>>
>>>>
>>>> On Wednesday 06 November 2013 05:37 AM, Jingoo Han wrote:
>>>>> On Wednesday, November 06, 2013 2:58 AM, Vivek Gautam wrote:
>>>>>> On Tue, Nov 5, 2013 at 5:33 PM, Jingoo Han <jg1.han@samsung.com> wrote:
>>>>>
>>>>> [.....]
>>>>>
>>>>>>> USB3.0 PHY consists of two blocks such as 3.0 block and 2.0 block.
>>>>>>> This USB3.0 PHY can support UTMI+ and PIPE3 interface for 3.0 block
>>>>>>> and 2.0 block, respectively.
>>>>>>>
>>>>>>> Conclusion:
>>>>>>>
>>>>>>> 1) USB2.0 PHY: USB2.0 HOST, USB2.0 Device
>>>>>>> Base address: 0x1213 0000
>>>>>>>
>>>>>>> 2) USB3.0 PHY: USB3.0 DRD (3.0 HOST & 3.0 Device)
>>>>>>> Base address: 0x1210 0000
>>>>>>> 2.0 block(UTMI+) & 3.0 block(PIPE3)
>>>>>>
>>>>>> And this is of course the PHY used by DWC3 controller, which works at
>>>>>> both High speed as well as Super Speed.
>>>>>> Right ?
>>>>>
>>>>> Right.
>>>>>
>>>>> While 3.0 block(PIPE3) can be used for Super Speed, 2.0 block(UTMI+)
>>>>> can be used for High speed.
>>>>
>>>> It should then come under *single IP muliple PHY* category similar to what
>>>> Sylwester has done.
>>>
>>> Do you mean that i should be including PHY IDs for UTMI+ phy and PIPE3
>>> phy present in this PHY block ?
>>> AFAICS the two phys (UTMI+ and PIPE3) do not really have separate
>>> registers to program, and that's the reason
>>> we program the entire PHY in a shot.
>>
>> you mean you program the same set of bits for UTMI+ and PIPE3?
>
> No, looking closely into PHY datasheet as well as Exynos5250 manual, i
> can see that UTMI+ and PIPE3
> phys have separate bit settings. So i think we should be able to
> segregate the two PHYs (UTMI+ and PIPE3).
> Pardon me for my earlier observations.
no problem..
> Let me clarify more with our h/w team also on this and then i will
> confirm with this.
sure, thanks.
Cheers
Kishon
>
>>
>> Thanks
>> Kishon
>
>
>
^ permalink raw reply [flat|nested] 36+ messages in thread
* [PATCH RFC 1/4] phy: Add new Exynos5 USB 3.0 PHY driver
2013-11-20 15:44 ` Kishon Vijay Abraham I
@ 2013-12-04 14:28 ` Kishon Vijay Abraham I
2013-12-05 8:14 ` Vivek Gautam
0 siblings, 1 reply; 36+ messages in thread
From: Kishon Vijay Abraham I @ 2013-12-04 14:28 UTC (permalink / raw)
To: linux-arm-kernel
Hi Vivek,
On Wednesday 20 November 2013 09:14 PM, Kishon Vijay Abraham I wrote:
> Hi,
>
> On Wednesday 20 November 2013 03:02 PM, Vivek Gautam wrote:
>> On Wed, Nov 20, 2013 at 2:34 PM, Kishon Vijay Abraham I <kishon@ti.com> wrote:
>>> On Wednesday 20 November 2013 02:27 PM, Vivek Gautam wrote:
>>>> Hi Kishon,
>>>>
>>>>
>>>> On Mon, Nov 11, 2013 at 4:41 PM, Kishon Vijay Abraham I <kishon@ti.com> wrote:
>>>>> Hi,
>>>> sorry for the delayed response.
>>>>
>>>>>
>>>>> On Wednesday 06 November 2013 05:37 AM, Jingoo Han wrote:
>>>>>> On Wednesday, November 06, 2013 2:58 AM, Vivek Gautam wrote:
>>>>>>> On Tue, Nov 5, 2013 at 5:33 PM, Jingoo Han <jg1.han@samsung.com> wrote:
>>>>>>
>>>>>> [.....]
>>>>>>
>>>>>>>> USB3.0 PHY consists of two blocks such as 3.0 block and 2.0 block.
>>>>>>>> This USB3.0 PHY can support UTMI+ and PIPE3 interface for 3.0 block
>>>>>>>> and 2.0 block, respectively.
>>>>>>>>
>>>>>>>> Conclusion:
>>>>>>>>
>>>>>>>> 1) USB2.0 PHY: USB2.0 HOST, USB2.0 Device
>>>>>>>> Base address: 0x1213 0000
>>>>>>>>
>>>>>>>> 2) USB3.0 PHY: USB3.0 DRD (3.0 HOST & 3.0 Device)
>>>>>>>> Base address: 0x1210 0000
>>>>>>>> 2.0 block(UTMI+) & 3.0 block(PIPE3)
>>>>>>>
>>>>>>> And this is of course the PHY used by DWC3 controller, which works at
>>>>>>> both High speed as well as Super Speed.
>>>>>>> Right ?
>>>>>>
>>>>>> Right.
>>>>>>
>>>>>> While 3.0 block(PIPE3) can be used for Super Speed, 2.0 block(UTMI+)
>>>>>> can be used for High speed.
>>>>>
>>>>> It should then come under *single IP muliple PHY* category similar to what
>>>>> Sylwester has done.
>>>>
>>>> Do you mean that i should be including PHY IDs for UTMI+ phy and PIPE3
>>>> phy present in this PHY block ?
>>>> AFAICS the two phys (UTMI+ and PIPE3) do not really have separate
>>>> registers to program, and that's the reason
>>>> we program the entire PHY in a shot.
>>>
>>> you mean you program the same set of bits for UTMI+ and PIPE3?
>>
>> No, looking closely into PHY datasheet as well as Exynos5250 manual, i
>> can see that UTMI+ and PIPE3
>> phys have separate bit settings. So i think we should be able to
>> segregate the two PHYs (UTMI+ and PIPE3).
>> Pardon me for my earlier observations.
>
> no problem..
>> Let me clarify more with our h/w team also on this and then i will
>> confirm with this.
Did you get more information on this?
Thanks
Kishon
^ permalink raw reply [flat|nested] 36+ messages in thread
* [PATCH RFC 1/4] phy: Add new Exynos5 USB 3.0 PHY driver
2013-12-04 14:28 ` Kishon Vijay Abraham I
@ 2013-12-05 8:14 ` Vivek Gautam
2013-12-24 17:45 ` Kishon Vijay Abraham I
0 siblings, 1 reply; 36+ messages in thread
From: Vivek Gautam @ 2013-12-05 8:14 UTC (permalink / raw)
To: linux-arm-kernel
Hi Kishon,
On Wed, Dec 4, 2013 at 7:58 PM, Kishon Vijay Abraham I <kishon@ti.com> wrote:
> Hi Vivek,
>
> On Wednesday 20 November 2013 09:14 PM, Kishon Vijay Abraham I wrote:
>> Hi,
>>
>> On Wednesday 20 November 2013 03:02 PM, Vivek Gautam wrote:
>>> On Wed, Nov 20, 2013 at 2:34 PM, Kishon Vijay Abraham I <kishon@ti.com> wrote:
>>>> On Wednesday 20 November 2013 02:27 PM, Vivek Gautam wrote:
>>>>> Hi Kishon,
>>>>>
>>>>>
>>>>> On Mon, Nov 11, 2013 at 4:41 PM, Kishon Vijay Abraham I <kishon@ti.com> wrote:
>>>>>> Hi,
>>>>> sorry for the delayed response.
>>>>>
>>>>>>
>>>>>> On Wednesday 06 November 2013 05:37 AM, Jingoo Han wrote:
>>>>>>> On Wednesday, November 06, 2013 2:58 AM, Vivek Gautam wrote:
>>>>>>>> On Tue, Nov 5, 2013 at 5:33 PM, Jingoo Han <jg1.han@samsung.com> wrote:
>>>>>>>
>>>>>>> [.....]
>>>>>>>
>>>>>>>>> USB3.0 PHY consists of two blocks such as 3.0 block and 2.0 block.
>>>>>>>>> This USB3.0 PHY can support UTMI+ and PIPE3 interface for 3.0 block
>>>>>>>>> and 2.0 block, respectively.
>>>>>>>>>
>>>>>>>>> Conclusion:
>>>>>>>>>
>>>>>>>>> 1) USB2.0 PHY: USB2.0 HOST, USB2.0 Device
>>>>>>>>> Base address: 0x1213 0000
>>>>>>>>>
>>>>>>>>> 2) USB3.0 PHY: USB3.0 DRD (3.0 HOST & 3.0 Device)
>>>>>>>>> Base address: 0x1210 0000
>>>>>>>>> 2.0 block(UTMI+) & 3.0 block(PIPE3)
>>>>>>>>
>>>>>>>> And this is of course the PHY used by DWC3 controller, which works at
>>>>>>>> both High speed as well as Super Speed.
>>>>>>>> Right ?
>>>>>>>
>>>>>>> Right.
>>>>>>>
>>>>>>> While 3.0 block(PIPE3) can be used for Super Speed, 2.0 block(UTMI+)
>>>>>>> can be used for High speed.
>>>>>>
>>>>>> It should then come under *single IP muliple PHY* category similar to what
>>>>>> Sylwester has done.
>>>>>
>>>>> Do you mean that i should be including PHY IDs for UTMI+ phy and PIPE3
>>>>> phy present in this PHY block ?
>>>>> AFAICS the two phys (UTMI+ and PIPE3) do not really have separate
>>>>> registers to program, and that's the reason
>>>>> we program the entire PHY in a shot.
>>>>
>>>> you mean you program the same set of bits for UTMI+ and PIPE3?
>>>
>>> No, looking closely into PHY datasheet as well as Exynos5250 manual, i
>>> can see that UTMI+ and PIPE3
>>> phys have separate bit settings. So i think we should be able to
>>> segregate the two PHYs (UTMI+ and PIPE3).
>>> Pardon me for my earlier observations.
>>
>> no problem..
>>> Let me clarify more with our h/w team also on this and then i will
>>> confirm with this.
>
> Did you get more information on this?
Yes, i have been in contact with our hardware team.
The functionality of setting up UTMI+ and PIPE3 phys separately, and
thereby using only one functionality of the two
at some point of time (either high speed or super speed) hasn't been
tested so far.
So i will be looking into this and try to find out proper init
sequences for the two available PHYs
separately and as soon as i get a working solution for this, i will update.
>
> Thanks
> Kishon
--
Best Regards
Vivek Gautam
Samsung R&D Institute, Bangalore
India
^ permalink raw reply [flat|nested] 36+ messages in thread
* [PATCH RFC 1/4] phy: Add new Exynos5 USB 3.0 PHY driver
2013-12-05 8:14 ` Vivek Gautam
@ 2013-12-24 17:45 ` Kishon Vijay Abraham I
2013-12-30 9:43 ` Vivek Gautam
0 siblings, 1 reply; 36+ messages in thread
From: Kishon Vijay Abraham I @ 2013-12-24 17:45 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
On Thursday 05 December 2013 01:44 PM, Vivek Gautam wrote:
> Hi Kishon,
>
>
> On Wed, Dec 4, 2013 at 7:58 PM, Kishon Vijay Abraham I <kishon@ti.com> wrote:
>> Hi Vivek,
>>
>> On Wednesday 20 November 2013 09:14 PM, Kishon Vijay Abraham I wrote:
>>> Hi,
>>>
>>> On Wednesday 20 November 2013 03:02 PM, Vivek Gautam wrote:
>>>> On Wed, Nov 20, 2013 at 2:34 PM, Kishon Vijay Abraham I <kishon@ti.com> wrote:
>>>>> On Wednesday 20 November 2013 02:27 PM, Vivek Gautam wrote:
>>>>>> Hi Kishon,
>>>>>>
>>>>>>
>>>>>> On Mon, Nov 11, 2013 at 4:41 PM, Kishon Vijay Abraham I <kishon@ti.com> wrote:
>>>>>>> Hi,
>>>>>> sorry for the delayed response.
>>>>>>
>>>>>>>
>>>>>>> On Wednesday 06 November 2013 05:37 AM, Jingoo Han wrote:
>>>>>>>> On Wednesday, November 06, 2013 2:58 AM, Vivek Gautam wrote:
>>>>>>>>> On Tue, Nov 5, 2013 at 5:33 PM, Jingoo Han <jg1.han@samsung.com> wrote:
>>>>>>>>
>>>>>>>> [.....]
>>>>>>>>
>>>>>>>>>> USB3.0 PHY consists of two blocks such as 3.0 block and 2.0 block.
>>>>>>>>>> This USB3.0 PHY can support UTMI+ and PIPE3 interface for 3.0 block
>>>>>>>>>> and 2.0 block, respectively.
>>>>>>>>>>
>>>>>>>>>> Conclusion:
>>>>>>>>>>
>>>>>>>>>> 1) USB2.0 PHY: USB2.0 HOST, USB2.0 Device
>>>>>>>>>> Base address: 0x1213 0000
>>>>>>>>>>
>>>>>>>>>> 2) USB3.0 PHY: USB3.0 DRD (3.0 HOST & 3.0 Device)
>>>>>>>>>> Base address: 0x1210 0000
>>>>>>>>>> 2.0 block(UTMI+) & 3.0 block(PIPE3)
>>>>>>>>>
>>>>>>>>> And this is of course the PHY used by DWC3 controller, which works at
>>>>>>>>> both High speed as well as Super Speed.
>>>>>>>>> Right ?
>>>>>>>>
>>>>>>>> Right.
>>>>>>>>
>>>>>>>> While 3.0 block(PIPE3) can be used for Super Speed, 2.0 block(UTMI+)
>>>>>>>> can be used for High speed.
>>>>>>>
>>>>>>> It should then come under *single IP muliple PHY* category similar to what
>>>>>>> Sylwester has done.
>>>>>>
>>>>>> Do you mean that i should be including PHY IDs for UTMI+ phy and PIPE3
>>>>>> phy present in this PHY block ?
>>>>>> AFAICS the two phys (UTMI+ and PIPE3) do not really have separate
>>>>>> registers to program, and that's the reason
>>>>>> we program the entire PHY in a shot.
>>>>>
>>>>> you mean you program the same set of bits for UTMI+ and PIPE3?
>>>>
>>>> No, looking closely into PHY datasheet as well as Exynos5250 manual, i
>>>> can see that UTMI+ and PIPE3
>>>> phys have separate bit settings. So i think we should be able to
>>>> segregate the two PHYs (UTMI+ and PIPE3).
>>>> Pardon me for my earlier observations.
>>>
>>> no problem..
>>>> Let me clarify more with our h/w team also on this and then i will
>>>> confirm with this.
>>
>> Did you get more information on this?
>
> Yes, i have been in contact with our hardware team.
> The functionality of setting up UTMI+ and PIPE3 phys separately, and
> thereby using only one functionality of the two
> at some point of time (either high speed or super speed) hasn't been
> tested so far.
Irrespective of whether we are able to test the functionality separately
or not, we should model it as multiple PHYs since you have separate bit
settings for UTMI+ and PIPE3.
(I'll review your next patch version shortly).
Cheers
Kishon
> So i will be looking into this and try to find out proper init
> sequences for the two available PHYs
> separately and as soon as i get a working solution for this, i will update.
>
>>
>> Thanks
>> Kishon
>
>
>
^ permalink raw reply [flat|nested] 36+ messages in thread
* [PATCH RFC 1/4] phy: Add new Exynos5 USB 3.0 PHY driver
2013-12-24 17:45 ` Kishon Vijay Abraham I
@ 2013-12-30 9:43 ` Vivek Gautam
2014-01-07 9:49 ` Kishon Vijay Abraham I
0 siblings, 1 reply; 36+ messages in thread
From: Vivek Gautam @ 2013-12-30 9:43 UTC (permalink / raw)
To: linux-arm-kernel
Hi Kishon,
On Tue, Dec 24, 2013 at 11:15 PM, Kishon Vijay Abraham I <kishon@ti.com> wrote:
> Hi,
>
>
> On Thursday 05 December 2013 01:44 PM, Vivek Gautam wrote:
>>
>> Hi Kishon,
>>
>>
>> On Wed, Dec 4, 2013 at 7:58 PM, Kishon Vijay Abraham I <kishon@ti.com>
>> wrote:
>>>
>>> Hi Vivek,
>>>
>>> On Wednesday 20 November 2013 09:14 PM, Kishon Vijay Abraham I wrote:
>>>>
>>>> Hi,
>>>>
>>>> On Wednesday 20 November 2013 03:02 PM, Vivek Gautam wrote:
>>>>>
>>>>> On Wed, Nov 20, 2013 at 2:34 PM, Kishon Vijay Abraham I <kishon@ti.com>
>>>>> wrote:
>>>>>>
>>>>>> On Wednesday 20 November 2013 02:27 PM, Vivek Gautam wrote:
>>>>>>>
>>>>>>> Hi Kishon,
>>>>>>>
>>>>>>>
>>>>>>> On Mon, Nov 11, 2013 at 4:41 PM, Kishon Vijay Abraham I
>>>>>>> <kishon@ti.com> wrote:
>>>>>>>>
>>>>>>>> Hi,
>>>>>>>
>>>>>>> sorry for the delayed response.
>>>>>>>
>>>>>>>>
>>>>>>>> On Wednesday 06 November 2013 05:37 AM, Jingoo Han wrote:
>>>>>>>>>
>>>>>>>>> On Wednesday, November 06, 2013 2:58 AM, Vivek Gautam wrote:
>>>>>>>>>>
>>>>>>>>>> On Tue, Nov 5, 2013 at 5:33 PM, Jingoo Han <jg1.han@samsung.com>
>>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> [.....]
>>>>>>>>>
>>>>>>>>>>> USB3.0 PHY consists of two blocks such as 3.0 block and 2.0
>>>>>>>>>>> block.
>>>>>>>>>>> This USB3.0 PHY can support UTMI+ and PIPE3 interface for 3.0
>>>>>>>>>>> block
>>>>>>>>>>> and 2.0 block, respectively.
>>>>>>>>>>>
>>>>>>>>>>> Conclusion:
>>>>>>>>>>>
>>>>>>>>>>> 1) USB2.0 PHY: USB2.0 HOST, USB2.0 Device
>>>>>>>>>>> Base address: 0x1213 0000
>>>>>>>>>>>
>>>>>>>>>>> 2) USB3.0 PHY: USB3.0 DRD (3.0 HOST & 3.0 Device)
>>>>>>>>>>> Base address: 0x1210 0000
>>>>>>>>>>> 2.0 block(UTMI+) & 3.0 block(PIPE3)
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> And this is of course the PHY used by DWC3 controller, which works
>>>>>>>>>> at
>>>>>>>>>> both High speed as well as Super Speed.
>>>>>>>>>> Right ?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Right.
>>>>>>>>>
>>>>>>>>> While 3.0 block(PIPE3) can be used for Super Speed, 2.0
>>>>>>>>> block(UTMI+)
>>>>>>>>> can be used for High speed.
>>>>>>>>
>>>>>>>>
>>>>>>>> It should then come under *single IP muliple PHY* category similar
>>>>>>>> to what
>>>>>>>> Sylwester has done.
>>>>>>>
>>>>>>>
>>>>>>> Do you mean that i should be including PHY IDs for UTMI+ phy and
>>>>>>> PIPE3
>>>>>>> phy present in this PHY block ?
>>>>>>> AFAICS the two phys (UTMI+ and PIPE3) do not really have separate
>>>>>>> registers to program, and that's the reason
>>>>>>> we program the entire PHY in a shot.
>>>>>>
>>>>>>
>>>>>> you mean you program the same set of bits for UTMI+ and PIPE3?
>>>>>
>>>>>
>>>>> No, looking closely into PHY datasheet as well as Exynos5250 manual, i
>>>>> can see that UTMI+ and PIPE3
>>>>> phys have separate bit settings. So i think we should be able to
>>>>> segregate the two PHYs (UTMI+ and PIPE3).
>>>>> Pardon me for my earlier observations.
>>>>
>>>>
>>>> no problem..
>>>>>
>>>>> Let me clarify more with our h/w team also on this and then i will
>>>>> confirm with this.
>>>
>>>
>>> Did you get more information on this?
>>
>>
>> Yes, i have been in contact with our hardware team.
>> The functionality of setting up UTMI+ and PIPE3 phys separately, and
>> thereby using only one functionality of the two
>> at some point of time (either high speed or super speed) hasn't been
>> tested so far.
>
>
> Irrespective of whether we are able to test the functionality separately or
> not, we should model it as multiple PHYs since you have separate bit
> settings for UTMI+ and PIPE3.
>
> (I'll review your next patch version shortly).
Thanks Kishon, i know i am disturbing you in the holiday season. :-)
But there's one concern, on Exynos5 platforms we have only one bit to
power control
the entire PHY (irrespective of the two PHYs present in the USB 3.0
PHY controller).
So anyways we won't be able to save anything on the power front even
if we program only
one PHY (UTMI/PIPE3).
Although there are PHY settings register bits which seem separate for
the two phys.
What do you suggest in that case ?
May be i am not able to understand you properly on the front of multiple PHYs
>
> Cheers
> Kishon
>
>
>> So i will be looking into this and try to find out proper init
>> sequences for the two available PHYs
>> separately and as soon as i get a working solution for this, i will
>> update.
>>
>>>
>>> Thanks
>>> Kishon
>>
>>
>>
>>
>
--
Best Regards
Vivek Gautam
Samsung R&D Institute, Bangalore
India
^ permalink raw reply [flat|nested] 36+ messages in thread
* [PATCH RFC 1/4] phy: Add new Exynos5 USB 3.0 PHY driver
2013-12-30 9:43 ` Vivek Gautam
@ 2014-01-07 9:49 ` Kishon Vijay Abraham I
2014-01-07 11:03 ` Vivek Gautam
0 siblings, 1 reply; 36+ messages in thread
From: Kishon Vijay Abraham I @ 2014-01-07 9:49 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
On Monday 30 December 2013 03:13 PM, Vivek Gautam wrote:
> Hi Kishon,
>
>
> On Tue, Dec 24, 2013 at 11:15 PM, Kishon Vijay Abraham I <kishon@ti.com> wrote:
>> Hi,
>>
>>
>> On Thursday 05 December 2013 01:44 PM, Vivek Gautam wrote:
>>>
>>> Hi Kishon,
>>>
>>>
>>> On Wed, Dec 4, 2013 at 7:58 PM, Kishon Vijay Abraham I <kishon@ti.com>
>>> wrote:
>>>>
>>>> Hi Vivek,
>>>>
>>>> On Wednesday 20 November 2013 09:14 PM, Kishon Vijay Abraham I wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> On Wednesday 20 November 2013 03:02 PM, Vivek Gautam wrote:
>>>>>>
>>>>>> On Wed, Nov 20, 2013 at 2:34 PM, Kishon Vijay Abraham I <kishon@ti.com>
>>>>>> wrote:
>>>>>>>
>>>>>>> On Wednesday 20 November 2013 02:27 PM, Vivek Gautam wrote:
>>>>>>>>
>>>>>>>> Hi Kishon,
>>>>>>>>
>>>>>>>>
>>>>>>>> On Mon, Nov 11, 2013 at 4:41 PM, Kishon Vijay Abraham I
>>>>>>>> <kishon@ti.com> wrote:
>>>>>>>>>
>>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> sorry for the delayed response.
>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Wednesday 06 November 2013 05:37 AM, Jingoo Han wrote:
>>>>>>>>>>
>>>>>>>>>> On Wednesday, November 06, 2013 2:58 AM, Vivek Gautam wrote:
>>>>>>>>>>>
>>>>>>>>>>> On Tue, Nov 5, 2013 at 5:33 PM, Jingoo Han <jg1.han@samsung.com>
>>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> [.....]
>>>>>>>>>>
>>>>>>>>>>>> USB3.0 PHY consists of two blocks such as 3.0 block and 2.0
>>>>>>>>>>>> block.
>>>>>>>>>>>> This USB3.0 PHY can support UTMI+ and PIPE3 interface for 3.0
>>>>>>>>>>>> block
>>>>>>>>>>>> and 2.0 block, respectively.
>>>>>>>>>>>>
>>>>>>>>>>>> Conclusion:
>>>>>>>>>>>>
>>>>>>>>>>>> 1) USB2.0 PHY: USB2.0 HOST, USB2.0 Device
>>>>>>>>>>>> Base address: 0x1213 0000
>>>>>>>>>>>>
>>>>>>>>>>>> 2) USB3.0 PHY: USB3.0 DRD (3.0 HOST & 3.0 Device)
>>>>>>>>>>>> Base address: 0x1210 0000
>>>>>>>>>>>> 2.0 block(UTMI+) & 3.0 block(PIPE3)
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> And this is of course the PHY used by DWC3 controller, which works
>>>>>>>>>>> at
>>>>>>>>>>> both High speed as well as Super Speed.
>>>>>>>>>>> Right ?
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Right.
>>>>>>>>>>
>>>>>>>>>> While 3.0 block(PIPE3) can be used for Super Speed, 2.0
>>>>>>>>>> block(UTMI+)
>>>>>>>>>> can be used for High speed.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> It should then come under *single IP muliple PHY* category similar
>>>>>>>>> to what
>>>>>>>>> Sylwester has done.
>>>>>>>>
>>>>>>>>
>>>>>>>> Do you mean that i should be including PHY IDs for UTMI+ phy and
>>>>>>>> PIPE3
>>>>>>>> phy present in this PHY block ?
>>>>>>>> AFAICS the two phys (UTMI+ and PIPE3) do not really have separate
>>>>>>>> registers to program, and that's the reason
>>>>>>>> we program the entire PHY in a shot.
>>>>>>>
>>>>>>>
>>>>>>> you mean you program the same set of bits for UTMI+ and PIPE3?
>>>>>>
>>>>>>
>>>>>> No, looking closely into PHY datasheet as well as Exynos5250 manual, i
>>>>>> can see that UTMI+ and PIPE3
>>>>>> phys have separate bit settings. So i think we should be able to
>>>>>> segregate the two PHYs (UTMI+ and PIPE3).
>>>>>> Pardon me for my earlier observations.
>>>>>
>>>>>
>>>>> no problem..
>>>>>>
>>>>>> Let me clarify more with our h/w team also on this and then i will
>>>>>> confirm with this.
>>>>
>>>>
>>>> Did you get more information on this?
>>>
>>>
>>> Yes, i have been in contact with our hardware team.
>>> The functionality of setting up UTMI+ and PIPE3 phys separately, and
>>> thereby using only one functionality of the two
>>> at some point of time (either high speed or super speed) hasn't been
>>> tested so far.
>>
>>
>> Irrespective of whether we are able to test the functionality separately or
>> not, we should model it as multiple PHYs since you have separate bit
>> settings for UTMI+ and PIPE3.
>>
>> (I'll review your next patch version shortly).
>
> Thanks Kishon, i know i am disturbing you in the holiday season. :-)
> But there's one concern, on Exynos5 platforms we have only one bit to
> power control
> the entire PHY (irrespective of the two PHYs present in the USB 3.0
> PHY controller).
> So anyways we won't be able to save anything on the power front even
> if we program only
> one PHY (UTMI/PIPE3).
> Although there are PHY settings register bits which seem separate for
> the two phys. r
> What do you suggest in that case ?
The idea is to model the driver as close to the hardware though I understand
there won't be any advantages w.r.t power or performance. maybe in later
versions of the IP we'll have separate bits to control usb3 and usb2.
I think for power control we should have both usb3 and usb2 power-on callback
calling a single function that controls the power bit.
Thanks
Kishon
^ permalink raw reply [flat|nested] 36+ messages in thread
* [PATCH RFC 1/4] phy: Add new Exynos5 USB 3.0 PHY driver
2014-01-07 9:49 ` Kishon Vijay Abraham I
@ 2014-01-07 11:03 ` Vivek Gautam
2014-01-20 13:45 ` Vivek Gautam
0 siblings, 1 reply; 36+ messages in thread
From: Vivek Gautam @ 2014-01-07 11:03 UTC (permalink / raw)
To: linux-arm-kernel
HI Kishon
On Tue, Jan 7, 2014 at 3:19 PM, Kishon Vijay Abraham I <kishon@ti.com> wrote:
> Hi,
>
> On Monday 30 December 2013 03:13 PM, Vivek Gautam wrote:
>> Hi Kishon,
>>
>>
>> On Tue, Dec 24, 2013 at 11:15 PM, Kishon Vijay Abraham I <kishon@ti.com> wrote:
>>> Hi,
>>>
>>>
>>> On Thursday 05 December 2013 01:44 PM, Vivek Gautam wrote:
>>>>
>>>> Hi Kishon,
>>>>
>>>>
>>>> On Wed, Dec 4, 2013 at 7:58 PM, Kishon Vijay Abraham I <kishon@ti.com>
>>>> wrote:
>>>>>
>>>>> Hi Vivek,
>>>>>
>>>>> On Wednesday 20 November 2013 09:14 PM, Kishon Vijay Abraham I wrote:
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> On Wednesday 20 November 2013 03:02 PM, Vivek Gautam wrote:
>>>>>>>
>>>>>>> On Wed, Nov 20, 2013 at 2:34 PM, Kishon Vijay Abraham I <kishon@ti.com>
>>>>>>> wrote:
>>>>>>>>
>>>>>>>> On Wednesday 20 November 2013 02:27 PM, Vivek Gautam wrote:
>>>>>>>>>
>>>>>>>>> Hi Kishon,
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Mon, Nov 11, 2013 at 4:41 PM, Kishon Vijay Abraham I
>>>>>>>>> <kishon@ti.com> wrote:
>>>>>>>>>>
>>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> sorry for the delayed response.
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Wednesday 06 November 2013 05:37 AM, Jingoo Han wrote:
>>>>>>>>>>>
>>>>>>>>>>> On Wednesday, November 06, 2013 2:58 AM, Vivek Gautam wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> On Tue, Nov 5, 2013 at 5:33 PM, Jingoo Han <jg1.han@samsung.com>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> [.....]
>>>>>>>>>>>
>>>>>>>>>>>>> USB3.0 PHY consists of two blocks such as 3.0 block and 2.0
>>>>>>>>>>>>> block.
>>>>>>>>>>>>> This USB3.0 PHY can support UTMI+ and PIPE3 interface for 3.0
>>>>>>>>>>>>> block
>>>>>>>>>>>>> and 2.0 block, respectively.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Conclusion:
>>>>>>>>>>>>>
>>>>>>>>>>>>> 1) USB2.0 PHY: USB2.0 HOST, USB2.0 Device
>>>>>>>>>>>>> Base address: 0x1213 0000
>>>>>>>>>>>>>
>>>>>>>>>>>>> 2) USB3.0 PHY: USB3.0 DRD (3.0 HOST & 3.0 Device)
>>>>>>>>>>>>> Base address: 0x1210 0000
>>>>>>>>>>>>> 2.0 block(UTMI+) & 3.0 block(PIPE3)
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> And this is of course the PHY used by DWC3 controller, which works
>>>>>>>>>>>> at
>>>>>>>>>>>> both High speed as well as Super Speed.
>>>>>>>>>>>> Right ?
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Right.
>>>>>>>>>>>
>>>>>>>>>>> While 3.0 block(PIPE3) can be used for Super Speed, 2.0
>>>>>>>>>>> block(UTMI+)
>>>>>>>>>>> can be used for High speed.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> It should then come under *single IP muliple PHY* category similar
>>>>>>>>>> to what
>>>>>>>>>> Sylwester has done.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Do you mean that i should be including PHY IDs for UTMI+ phy and
>>>>>>>>> PIPE3
>>>>>>>>> phy present in this PHY block ?
>>>>>>>>> AFAICS the two phys (UTMI+ and PIPE3) do not really have separate
>>>>>>>>> registers to program, and that's the reason
>>>>>>>>> we program the entire PHY in a shot.
>>>>>>>>
>>>>>>>>
>>>>>>>> you mean you program the same set of bits for UTMI+ and PIPE3?
>>>>>>>
>>>>>>>
>>>>>>> No, looking closely into PHY datasheet as well as Exynos5250 manual, i
>>>>>>> can see that UTMI+ and PIPE3
>>>>>>> phys have separate bit settings. So i think we should be able to
>>>>>>> segregate the two PHYs (UTMI+ and PIPE3).
>>>>>>> Pardon me for my earlier observations.
>>>>>>
>>>>>>
>>>>>> no problem..
>>>>>>>
>>>>>>> Let me clarify more with our h/w team also on this and then i will
>>>>>>> confirm with this.
>>>>>
>>>>>
>>>>> Did you get more information on this?
>>>>
>>>>
>>>> Yes, i have been in contact with our hardware team.
>>>> The functionality of setting up UTMI+ and PIPE3 phys separately, and
>>>> thereby using only one functionality of the two
>>>> at some point of time (either high speed or super speed) hasn't been
>>>> tested so far.
>>>
>>>
>>> Irrespective of whether we are able to test the functionality separately or
>>> not, we should model it as multiple PHYs since you have separate bit
>>> settings for UTMI+ and PIPE3.
>>>
>>> (I'll review your next patch version shortly).
>>
>> Thanks Kishon, i know i am disturbing you in the holiday season. :-)
>> But there's one concern, on Exynos5 platforms we have only one bit to
>> power control
>> the entire PHY (irrespective of the two PHYs present in the USB 3.0
>> PHY controller).
>> So anyways we won't be able to save anything on the power front even
>> if we program only
>> one PHY (UTMI/PIPE3).
>> Although there are PHY settings register bits which seem separate for
>> the two phys. r
>> What do you suggest in that case ?
>
> The idea is to model the driver as close to the hardware though I understand
> there won't be any advantages w.r.t power or performance. maybe in later
> versions of the IP we'll have separate bits to control usb3 and usb2.
Ok, i will prepare the next patchset for separating out the possible
code based on
the UTMI+ or PIPE3 phys. Though when experimenting with the PHY
settings i can see
there's little of such code :-)
>
> I think for power control we should have both usb3 and usb2 power-on callback
> calling a single function that controls the power bit.
Right. I will do that.
--
Best Regards
Vivek Gautam
Samsung R&D Institute, Bangalore
India
^ permalink raw reply [flat|nested] 36+ messages in thread
* [PATCH RFC 1/4] phy: Add new Exynos5 USB 3.0 PHY driver
2014-01-07 11:03 ` Vivek Gautam
@ 2014-01-20 13:45 ` Vivek Gautam
0 siblings, 0 replies; 36+ messages in thread
From: Vivek Gautam @ 2014-01-20 13:45 UTC (permalink / raw)
To: linux-arm-kernel
Hi Kishon,
[...]
>>>>>>>>>>>> Right.
>>>>>>>>>>>>
>>>>>>>>>>>> While 3.0 block(PIPE3) can be used for Super Speed, 2.0
>>>>>>>>>>>> block(UTMI+)
>>>>>>>>>>>> can be used for High speed.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> It should then come under *single IP muliple PHY* category similar
>>>>>>>>>>> to what
>>>>>>>>>>> Sylwester has done.
[...]
>>
>> The idea is to model the driver as close to the hardware though I understand
>> there won't be any advantages w.r.t power or performance. maybe in later
>> versions of the IP we'll have separate bits to control usb3 and usb2.
>
> Ok, i will prepare the next patchset for separating out the possible
> code based on
> the UTMI+ or PIPE3 phys. Though when experimenting with the PHY
> settings i can see
> there's little of such code :-)
>
>>
>> I think for power control we should have both usb3 and usb2 power-on callback
>> calling a single function that controls the power bit.
> Right. I will do that.
Have posted the next version of patch with functionality to support
multiple PHYs as suggested.
Please review the same.
Thanks !!
--
Best Regards
Vivek Gautam
Samsung R&D Institute, Bangalore
India
^ permalink raw reply [flat|nested] 36+ messages in thread
* [PATCH RFC 1/4] phy: Add new Exynos5 USB 3.0 PHY driver
2013-11-05 9:36 ` Kamil Debski
2013-11-05 11:12 ` Jingoo Han
@ 2013-11-05 17:56 ` Vivek Gautam
1 sibling, 0 replies; 36+ messages in thread
From: Vivek Gautam @ 2013-11-05 17:56 UTC (permalink / raw)
To: linux-arm-kernel
Hi Kamil,
On Tue, Nov 5, 2013 at 3:06 PM, Kamil Debski <k.debski@samsung.com> wrote:
> Hi,
>
>> From: Vivek Gautam [mailto:gautamvivek1987 at gmail.com]
>> Sent: Tuesday, November 05, 2013 8:20 AM
>> To: Kishon Vijay Abraham I
>> Cc: Kamil Debski; Vivek Gautam; Linux USB Mailing List; linux-samsung-
>> soc at vger.kernel.org; linux-kernel at vger.kernel.org;
>> devicetree at vger.kernel.org; linux-arm-kernel at lists.infradead.org;
>> linux-doc at vger.kernel.org; Greg KH; Kukjin Kim; Sylwester Nawrocki;
>> Tomasz Figa; Felipe Balbi; Julius Werner; Jingoo Han
>> Subject: Re: [PATCH RFC 1/4] phy: Add new Exynos5 USB 3.0 PHY driver
>>
>> Hi Kishon,
>>
>>
>>
>> On Mon, Nov 4, 2013 at 6:42 PM, Kishon Vijay Abraham I <kishon@ti.com>
>> wrote:
>> > Hi,
>> >
>> >
>> > On Monday 04 November 2013 03:45 PM, Kamil Debski wrote:
>> >>
>> >> Hi Kishon,
>> >>
>> >>> From: Kishon Vijay Abraham I [mailto:kishon at ti.com]
>> >>> Sent: Monday, November 04, 2013 7:55 AM
>> >>>
>> >>> Hi Vivek,
>> >>>
>> >>> On Thursday 31 October 2013 01:15 PM, Vivek Gautam wrote:
>> >>>>
>> >>>> Add a new driver for the USB 3.0 PHY on Exynos5 series of SoCs.
>> >>>> The new driver uses the generic PHY framework and will interact
>> >>>> with
>> >>>> DWC3 controller present on Exynos5 series of SoCs.
>> >>>
>> >>>
>> >>> In Exynos, you have a single IP that supports both USB3 and USB2
>> PHY
>> >>> right? I think that needs to be mentioned here.
>> >>
>> >>
>> >> As far as I know the IP is different.
>> >
>> >
>> > Ok. Sometime back Vivek was mentioning about a single IP for both
>> USB3
>> > and USB2. Thought it should be this driver. Anyway thanks for the
>> clarification.
>>
>> Right Kishon, I had mentioned that Exynos5's dwc3 controller have a
>> single IP for USB2 and USB3 phy.
>> From what i see, on exynos5 systems the dwc3 controller uses a combo of
>> usb 2 (utmi+) and usb 3 (pipe 3) phy (with base address starting
>> 0x12100000).
>>
>> Kamil, Tomasz,
>>
>> Please correct me if i am wrong.
>
> I have the Exynos 5250 documentation and I found two phy register ranges:
> 1) USB 2.0 PHY having the base address of 0x1213 0000
> Chapter 33. USB 2.0 Host Controller
> Subchapter 33.5.2 Phy Control Register p. 1696
> First register's description is
> "USB2.0 phy control register"
> 2) USB 3.0 PHY (I guess) with the base address 0x1210 0000
> Chapter 35. USB 3.0 DRD Controller
> Subchapter 35.4.6 PHY Control Register p. 1872
>
> Jingoo, could you comment on the above? You may know more than we do :)
>
> In addition, I have a question to you Vivek - does your USB 3.0
> PHY support both host and device?
Yes, this PHY driver supports both Host as well as device type of
operations of DWC3 controller.
This driver is a straight port from older driver available at
drivers/usb/phy/phy-samsung-usb3.c which also had been tested
for host as well as device operation of DWC3.
>
> [snip]
>
> Best wishes,
> Kamil Debski
>
--
Best Regards
Vivek Gautam
Samsung R&D Institute, Bangalore
India
^ permalink raw reply [flat|nested] 36+ messages in thread
* [PATCH RFC 1/4] phy: Add new Exynos5 USB 3.0 PHY driver
2013-11-04 6:54 ` Kishon Vijay Abraham I
2013-11-04 10:15 ` Kamil Debski
@ 2013-11-04 12:26 ` Tomasz Figa
2013-11-04 13:09 ` Kishon Vijay Abraham I
[not found] ` <CAFp+6iG5SAe5h0-RRsBuAhtWO_NBW6G=7jQeObd4Y2BQGaRHyA@mail.gmail.com>
1 sibling, 2 replies; 36+ messages in thread
From: Tomasz Figa @ 2013-11-04 12:26 UTC (permalink / raw)
To: linux-arm-kernel
Hi Kishon,
On Monday 04 of November 2013 12:24:42 Kishon Vijay Abraham I wrote:
> Hi Vivek,
>
> On Thursday 31 October 2013 01:15 PM, Vivek Gautam wrote:
> > Add a new driver for the USB 3.0 PHY on Exynos5 series of SoCs.
> > The new driver uses the generic PHY framework and will interact
> > with DWC3 controller present on Exynos5 series of SoCs.
>
> In Exynos, you have a single IP that supports both USB3 and USB2 PHY
> right? I think that needs to be mentioned here.
Nope. There are two separate, different IPs.
> Do you have separate registers that should be used for
> initializing/powerin_on/powering_off etc.. for usb2 phy and usb3 phy? If
> so, then you should model this driver as a single driver that supports
> two PHYs similar to what Sylwester has done before?
Sylwester's MIPI PHY uses such model because it has a single register
that controls both PHYs.
Best regards,
Tomasz
^ permalink raw reply [flat|nested] 36+ messages in thread* [PATCH RFC 1/4] phy: Add new Exynos5 USB 3.0 PHY driver
2013-11-04 12:26 ` Tomasz Figa
@ 2013-11-04 13:09 ` Kishon Vijay Abraham I
[not found] ` <CAFp+6iG5SAe5h0-RRsBuAhtWO_NBW6G=7jQeObd4Y2BQGaRHyA@mail.gmail.com>
1 sibling, 0 replies; 36+ messages in thread
From: Kishon Vijay Abraham I @ 2013-11-04 13:09 UTC (permalink / raw)
To: linux-arm-kernel
On Monday 04 November 2013 05:56 PM, Tomasz Figa wrote:
> Hi Kishon,
>
> On Monday 04 of November 2013 12:24:42 Kishon Vijay Abraham I wrote:
>> Hi Vivek,
>>
>> On Thursday 31 October 2013 01:15 PM, Vivek Gautam wrote:
>>> Add a new driver for the USB 3.0 PHY on Exynos5 series of SoCs.
>>> The new driver uses the generic PHY framework and will interact
>>> with DWC3 controller present on Exynos5 series of SoCs.
>>
>> In Exynos, you have a single IP that supports both USB3 and USB2 PHY
>> right? I think that needs to be mentioned here.
>
> Nope. There are two separate, different IPs.
Alright. Thanks for the clarification.
Cheers
Kishon
>
>> Do you have separate registers that should be used for
>> initializing/powerin_on/powering_off etc.. for usb2 phy and usb3 phy? If
>> so, then you should model this driver as a single driver that supports
>> two PHYs similar to what Sylwester has done before?
>
> Sylwester's MIPI PHY uses such model because it has a single register
> that controls both PHYs.
>
> Best regards,
> Tomasz
>
^ permalink raw reply [flat|nested] 36+ messages in thread[parent not found: <CAFp+6iG5SAe5h0-RRsBuAhtWO_NBW6G=7jQeObd4Y2BQGaRHyA@mail.gmail.com>]
* [PATCH RFC 1/4] phy: Add new Exynos5 USB 3.0 PHY driver
[not found] ` <CAFp+6iG5SAe5h0-RRsBuAhtWO_NBW6G=7jQeObd4Y2BQGaRHyA@mail.gmail.com>
@ 2013-11-05 7:12 ` Vivek Gautam
0 siblings, 0 replies; 36+ messages in thread
From: Vivek Gautam @ 2013-11-05 7:12 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Nov 5, 2013 at 11:06 AM, Vivek Gautam <gautamvivek1987@gmail.com> wrote:
> Hi Tomasz,
Sorry my mail client had some problem, so forwarding this again.
>
> On Nov 4, 2013 5:59 PM, "Tomasz Figa" <t.figa@samsung.com> wrote:
>>
>> Hi Kishon,
>>
>> On Monday 04 of November 2013 12:24:42 Kishon Vijay Abraham I wrote:
>> > Hi Vivek,
>> >
>> > On Thursday 31 October 2013 01:15 PM, Vivek Gautam wrote:
>> > > Add a new driver for the USB 3.0 PHY on Exynos5 series of SoCs.
>> > > The new driver uses the generic PHY framework and will interact
>> > > with DWC3 controller present on Exynos5 series of SoCs.
>> >
>> > In Exynos, you have a single IP that supports both USB3 and USB2 PHY
>> > right? I think that needs to be mentioned here.
>>
>> Nope. There are two separate, different IPs.
>
> AFAICS the dwc3 controller (aka usb 3.0 drd controller, as mentioned in
> exynos5 UM) uses a combo of usb 2 (utmi+) and usb 3 (pipe 3) phy (with base
> address starting 0x12100000), thereby giving the driver only freedom to
> control them as one. The entire set of registers with base 0x12100000 for
> exynos5250 and later 0x12500000 for exynos5420 are being programmed by this
> driver. That's the reason i structured the driver this way, and thereby it
> makes the dwc3 controller to just use only single phy.
> Please correct me if i am wrong.
>
>>
>> > Do you have separate registers that should be used for
>> > initializing/powerin_on/powering_off etc.. for usb2 phy and usb3 phy? If
>> > so, then you should model this driver as a single driver that supports
>> > two PHYs similar to what Sylwester has done before?
>>
>> Sylwester's MIPI PHY uses such model because it has a single register
>> that controls both PHYs.
>>
>> Best regards,
>> Tomasz
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>> the body of a message to majordomo at vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at http://www.tux.org/lkml/
--
Best Regards
Vivek Gautam
Samsung R&D Institute, Bangalore
India
^ permalink raw reply [flat|nested] 36+ messages in thread
* [PATCH RFC 1/4] phy: Add new Exynos5 USB 3.0 PHY driver
2013-10-31 7:45 ` [PATCH RFC 1/4] phy: Add new Exynos5 USB 3.0 PHY driver Vivek Gautam
2013-11-04 6:54 ` Kishon Vijay Abraham I
@ 2013-11-10 14:08 ` Tomasz Figa
2013-11-20 8:44 ` Vivek Gautam
2013-11-21 12:26 ` Yuvaraj Cd
2 siblings, 1 reply; 36+ messages in thread
From: Tomasz Figa @ 2013-11-10 14:08 UTC (permalink / raw)
To: linux-arm-kernel
Hi Vivek,
On Thursday 31 of October 2013 13:15:41 Vivek Gautam wrote:
> Add a new driver for the USB 3.0 PHY on Exynos5 series of SoCs.
> The new driver uses the generic PHY framework and will interact
> with DWC3 controller present on Exynos5 series of SoCs.
>
> Signed-off-by: Vivek Gautam <gautam.vivek@samsung.com>
> ---
> .../devicetree/bindings/phy/samsung-phy.txt | 20 +
> drivers/phy/Kconfig | 7 +
> drivers/phy/Makefile | 1 +
> drivers/phy/phy-exynos5-usb3.c | 562 ++++++++++++++++++++
> 4 files changed, 590 insertions(+), 0 deletions(-)
> create mode 100644 drivers/phy/phy-exynos5-usb3.c
>
> diff --git a/Documentation/devicetree/bindings/phy/samsung-phy.txt b/Documentation/devicetree/bindings/phy/samsung-phy.txt
> index c0fccaa..9b5c111 100644
> --- a/Documentation/devicetree/bindings/phy/samsung-phy.txt
> +++ b/Documentation/devicetree/bindings/phy/samsung-phy.txt
> @@ -20,3 +20,23 @@ Required properties:
> - compatible : should be "samsung,exynos5250-dp-video-phy";
> - reg : offset and length of the Display Port PHY register set;
> - #phy-cells : from the generic PHY bindings, must be 0;
> +
> +Samsung Exynos5 SoC seiries USB 3.0 PHY controller
typo: s/seiries/series/
> +--------------------------------------------------
> +
> +Required properties:
> +- compatible :
> + should be "samsung,exynos5250-usb3phy" for exynos5250 SoC
> + should be "samsung,exynos5420-usb3phy" for exynos5420 SoC
I'd slightly change this into something like this:
- compatible: Should be set to one of following supported values:
- "samsung,exynos5250-usb3phy" - for Exynos5250 SoC,
- "samsung,exynos5420-usb3phy" - for Exynos5420 SoC.
> +- reg : Register offset and length array
> + - first field corresponds to USB 3.0 PHY register set;
> + - second field corresponds to PHY power isolation register
> + present in PMU;
For consistency and to make things more future-proof, you should consider
using the PMU indirectly, through the syscon interface, as done in Leela
Krishna Amudala's series[1] in case of watchdog driver.
I will tell Kamil to do the same for USB 2.0 PHY as well.
[1] http://thread.gmane.org/gmane.linux.kernel.samsung-soc/24652
> +- clocks: Clock IDs array as required by the controller
> +- clock-names: names of clocks correseponding to IDs in the clock property;
> + Required clocks:
> + - first clock is main PHY clock (same as USB 3.0 controller IP clock)
> + - second clock is reference clock (usually crystal clock)
> + optional clock:
> + - third clock is special clock used by PHY for operation
Is this clock really optional? It looks like it's required for Exynos5420.
If so, you should instead change this to:
"Additional clocks required for Exynos5420:"
Also you have not specified names of the clocks, just what they are.
Please remember that those are input names, so you can imagine them as
names of clock input pins of the IP block, not SoC-level clock names.
> +- #phy-cells : from the generic PHY bindings, must be 0;
I'd also add an example of correct USB 3.0 PHY device tree node here.
> diff --git a/drivers/phy/phy-exynos5-usb3.c b/drivers/phy/phy-exynos5-usb3.c
> new file mode 100644
> index 0000000..b9a2674
> --- /dev/null
> +++ b/drivers/phy/phy-exynos5-usb3.c
> @@ -0,0 +1,562 @@
[snip]
> +#define EXYNOS5_DRD_PHYRESUME (0x34)
> +#define EXYNOS5_DRD_LINKPORT (0x44)
> +
> +
nit: Duplicate blank line.
> +/* Isolation, configured in the power management unit */
> +#define EXYNOS5_USB_ISOL_DRD (1 << 0)
> +
> +#define CLKSEL_ERROR -1
What's this?
> +
> +#ifndef KHZ
> +#define KHZ 1000
> +#endif
> +
> +#ifndef MHZ
> +#define MHZ (KHZ * KHZ)
> +#endif
Do you really need the #ifndef's above?
> +
> +enum samsung_cpu_type {
> + TYPE_EXYNOS5250,
> + TYPE_EXYNOS5420,
> +};
Instead of using this kind of enumeration, I'd rather introduce a struct
that describes the differences between all supported types.
> +
> +enum usb3phy_state {
> + STATE_OFF,
> + STATE_ON,
> +};
Hmm, isn't it a simple boolean value - false and true?
> +
> +struct usb3phy_config {
> + enum samsung_cpu_type cpu;
> + bool has_sclk_usbphy30;
> +};
Oh, you already have such struct, so there is even a bigger reason to drop
the samsung_cpu_type enum above.
> +
> +struct usb3phy_instance {
> + char *label;
> + struct usb3phy_driver *drv;
> + struct phy *phy;
> + enum usb3phy_state state;
> + u32 clk;
> + unsigned long rate;
> +};
You seem to have just one instance in this driver. Do you really
need this struct?
> +
> +struct usb3phy_driver {
> + struct device *dev;
> + void __iomem *reg_phy;
> + void __iomem *reg_isol;
> + struct clk *clk;
> + struct clk *sclk_usbphy30;
> + struct usb3phy_instance instance;
Fields from that struct could be simply moved here.
> +};
> +
> +/*
> + * exynos5_rate_to_clk() converts the supplied clock rate to the value that
> + * can be written to the phy register.
> + */
> +static u32 exynos5_rate_to_clk(unsigned long rate)
> +{
> + unsigned int clksel;
> +
> + /* EXYNOS5_FSEL_MASK */
> +
> + switch (rate) {
> + case 9600 * KHZ:
> + clksel = EXYNOS5_FSEL_9MHZ6;
> + break;
> + case 10 * MHZ:
> + clksel = EXYNOS5_FSEL_10MHZ;
> + break;
> + case 12 * MHZ:
> + clksel = EXYNOS5_FSEL_12MHZ;
> + break;
> + case 19200 * KHZ:
> + clksel = EXYNOS5_FSEL_19MHZ2;
> + break;
> + case 20 * MHZ:
> + clksel = EXYNOS5_FSEL_20MHZ;
> + break;
> + case 24 * MHZ:
> + clksel = EXYNOS5_FSEL_24MHZ;
> + break;
> + case 50 * MHZ:
> + clksel = EXYNOS5_FSEL_50MHZ;
> + break;
> + default:
> + clksel = CLKSEL_ERROR;
> + }
> +
> + return clksel;
> +}
> +
> +static void exynos5_usb3phy_isol(struct usb3phy_instance *inst, bool on)
> +{
> + struct usb3phy_driver *drv = inst->drv;
> + u32 tmp;
> +
> + if (!drv->reg_isol)
> + return;
> +
> + tmp = readl(drv->reg_isol);
> + if (on)
> + tmp &= ~EXYNOS5_USB_ISOL_DRD;
> + else
> + tmp |= EXYNOS5_USB_ISOL_DRD;
> + writel(tmp, drv->reg_isol);
> +}
> +
> +/*
> + * Sets the phy clk as EXTREFCLK (XXTI) which is internal clock from clock core.
> + */
> +static u32 exynos5_usb3phy_set_refclk(struct usb3phy_instance *inst)
> +{
> + u32 reg;
> + u32 refclk;
> +
> + refclk = inst->clk;
> +
> + reg = PHYCLKRST_REFCLKSEL_EXT_REFCLK |
> + PHYCLKRST_FSEL(refclk);
> +
> + switch (refclk) {
If I'm reading this correctly, you are switching a value returned by
another switch before (in exynos5_rate_to_clk()), which is only used in
this function.
You could instead drop the exynos5_rate_to_clk() function completely and
simply make a switch over the real clock frequency here.
> + case EXYNOS5_FSEL_50MHZ:
> + reg |= (PHYCLKRST_MPLL_MULTIPLIER_50M_REF |
> + PHYCLKRST_SSC_REFCLKSEL(0x00));
> + break;
> + case EXYNOS5_FSEL_20MHZ:
> + reg |= (PHYCLKRST_MPLL_MULTIPLIER_20MHZ_REF |
> + PHYCLKRST_SSC_REFCLKSEL(0x00));
> + break;
> + case EXYNOS5_FSEL_19MHZ2:
> + reg |= (PHYCLKRST_MPLL_MULTIPLIER_19200KHZ_REF |
> + PHYCLKRST_SSC_REFCLKSEL(0x88));
> + break;
> + case EXYNOS5_FSEL_24MHZ:
> + default:
This switch does not seem to handle all the cases handled by
exynos5_rate_to_clk(). Does it mean that the value for 24 MHz refclk can
be used for all the remaining cases or they are not supported?
> + reg |= (PHYCLKRST_MPLL_MULTIPLIER_24MHZ_REF |
> + PHYCLKRST_SSC_REFCLKSEL(0x88));
> + break;
> + }
> +
> + return reg;
> +}
[snip]
> +static int exynos5_usb3phy_power_on(struct phy *phy)
> +{
> + struct usb3phy_instance *inst = phy_get_drvdata(phy);
> + struct usb3phy_driver *drv = inst->drv;
> + int ret;
> +
> + dev_info(drv->dev, "Request to power_on \"%s\" usb phy\n",
> + inst->label);
dev_dbg()
> +
> + if (drv->sclk_usbphy30)
This check is incorrect. A NULL pointer is a correct value for a clock
as defined by Common Clock Framework, so IS_ERR() must be used here
instead.
> + clk_prepare_enable(drv->sclk_usbphy30);
Missing error check.
> +
> + ret = clk_prepare_enable(drv->clk);
> + if (ret)
> + return ret;
> +
All the code starting here...
> + if (inst->state == STATE_ON) {
> + dev_err(drv->dev, "usb phy \"%s\" already on",
> + inst->label);
> + ret = -ENODEV;
> + goto err0;
> + }
> +
> + inst->state = STATE_ON;
...and ending here, can be safely removed, since the PHY framework already
provides reference counting for PHYs.
> +
> + /* Initialize the PHY and power it ON */
> + exynos5_usb3phy_init(inst);
> + exynos5_usb3phy_isol(inst, 0);
> +
> +err0:
> + clk_disable_unprepare(drv->clk);
Is this clock needed for USB PHY operation or just for register accesses?
> +
> + return ret;
> +}
> +
> +static int exynos5_usb3phy_power_off(struct phy *phy)
> +{
> + struct usb3phy_instance *inst = phy_get_drvdata(phy);
> + struct usb3phy_driver *drv = inst->drv;
> + int ret;
> +
> + dev_info(drv->dev, "Request to power_off \"%s\" usb phy\n",
> + inst->label);
dev_dbg()
> + ret = clk_prepare_enable(drv->clk);
> + if (ret)
> + return ret;
> +
> + if (inst->state == STATE_OFF) {
> + dev_err(drv->dev, "usb phy \"%s\" already off",
> + inst->label);
> + ret = -ENODEV;
> + goto err0;
> + }
> +
> + inst->state = STATE_OFF;
Same comment about the PHY framework already doing reference counting.
> +
> + /* Power-off the PHY and de-initialize it */
> + exynos5_usb3phy_isol(inst, 1);
> + exynos5_usb3phy_exit(inst);
> +
> +err0:
> + clk_disable_unprepare(drv->clk);
> + if (drv->sclk_usbphy30)
> + clk_disable_unprepare(drv->sclk_usbphy30);
> +
> + return ret;
> +}
> +
> +static struct phy_ops exynos5_usb3phy_ops = {
> + .power_on = exynos5_usb3phy_power_on,
> + .power_off = exynos5_usb3phy_power_off,
> + .owner = THIS_MODULE,
> +};
> +
> +static const struct of_device_id exynos5_usb3phy_of_match[];
What about simply moving the definition here instead using a forward
declaration?
> +
> +static int exynos5_usb3phy_probe(struct platform_device *pdev)
> +{
> + struct device *dev = &pdev->dev;
> + struct usb3phy_driver *drv;
> + struct usb3phy_instance *inst;
> + struct phy_provider *phy_provider;
> + struct resource *res;
> + struct clk *clk;
> + const struct of_device_id *match;
> + const struct usb3phy_config *cfg;
> +
Just to be safe, you should check if pdev->dev.of_node is not NULL here,
to make sure that the driver got instantiated from device tree.
> + match = of_match_node(exynos5_usb3phy_of_match, pdev->dev.of_node);
> + if (!match) {
> + dev_err(dev, "of_match_node() failed\n");
> + return -EINVAL;
> + }
> + cfg = match->data;
> + if (!cfg) {
I don't think this is possible.
> + dev_err(dev, "Failed to get configuration\n");
> + return -EINVAL;
> + }
> +
> + drv = devm_kzalloc(dev, sizeof(struct usb3phy_driver), GFP_KERNEL);
sizeof(*drv)
> + if (!drv) {
> + dev_err(dev, "Failed to allocate memory\n");
kmalloc() and friends already print an error message for you.
> + return -ENOMEM;
> + }
> +
> + dev_set_drvdata(dev, drv);
> + drv->dev = dev;
> +
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + drv->reg_phy = devm_ioremap_resource(dev, res);
> + if (IS_ERR(drv->reg_phy)) {
> + dev_err(dev, "Failed to map register memory (phy)\n");
> + return PTR_ERR(drv->reg_phy);
> + }
> +
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
> + drv->reg_isol = devm_ioremap_resource(dev, res);
> + if (IS_ERR(drv->reg_isol)) {
> + dev_err(dev, "Failed to map register memory (isolation)\n");
> + return PTR_ERR(drv->reg_isol);
> + }
> +
> + phy_provider = devm_of_phy_provider_register(dev, of_phy_simple_xlate);
> + if (IS_ERR(phy_provider)) {
> + dev_err(drv->dev, "Failed to register phy provider\n");
> + return PTR_ERR(phy_provider);
> + }
The provider should be registered as the last thing in the sequence, as
the driver must be ready for handling PHY requests as soon as
of_phy_provider_register() returns.
> +
> + drv->clk = devm_clk_get(dev, "phy");
> + if (IS_ERR(drv->clk)) {
> + dev_err(dev, "Failed to get clock of phy controller\n");
> + return PTR_ERR(drv->clk);
> + }
> +
> + /*
> + * Exysno5420 SoC has an additional special clock, used for
> + * for USB 3.0 PHY operation, this clock goes to the PHY block
> + * as a reference clock to clock generation block of the controller.
> + */
> + if (cfg->has_sclk_usbphy30) {
> + drv->sclk_usbphy30 = devm_clk_get(dev, "sclk_usbphy30");
> + if (IS_ERR(drv->clk)) {
> + dev_err(dev, "Failed to get phy reference clock\n");
> + return PTR_ERR(drv->clk);
> + }
Seems like this clock is required for Exynos5420 indeed, as opposed to
what the DT binding documentation says.
> + }
> +
> + inst = &drv->instance;
> + inst->drv = drv;
This pointer does not seem to be needed.
> + inst->label = "usb3drd";
Do you need this label at all?
> +
> + dev_info(dev, "Creating phy \"%s\"\n", inst->label);
dev_dbg()
> + inst->phy = devm_phy_create(dev, &exynos5_usb3phy_ops, NULL);
> + if (IS_ERR(inst->phy)) {
> + dev_err(drv->dev, "Failed to create usb3phy \"%s\"\n",
> + inst->label);
> + return PTR_ERR(inst->phy);
> + }
> +
> + phy_set_drvdata(inst->phy, inst);
> +
> + clk = clk_get(dev, inst->label);
Since this driver provides only a single PHY, I think you should simply
use the clock name directly.
> + if (IS_ERR(clk)) {
> + dev_err(dev, "Failed to get clock of \"%s\" phy\n",
> + inst->label);
> + return PTR_ERR(clk);
> + }
> +
> + inst->rate = clk_get_rate(clk);
> +
> + inst->clk = exynos5_rate_to_clk(inst->rate);
> + if (inst->clk == CLKSEL_ERROR) {
> + dev_err(dev, "Clock rate (%ld) not supported\n",
> + inst->rate);
> + clk_put(clk);
> + return -EINVAL;
> + }
> + clk_put(clk);
Technically this should happen at the time of calling PHY enable, while
a reference to the clock should be kept through the whole PHY lifetime.
In addition, the clock should be prepare_enabled before it is used.
So, to recall, here you could call devm_clk_get(...). Then in
exynos5_usb3phy_power_on(), call clk_prepare_enable() on it, in
exynos5_usb3phy_set_refclk() call clk_get_rate() to get its frequency
and finally clk_disable_unprepare() it in exynos5_usb3phy_power_off().
Best regards,
Tomasz
^ permalink raw reply [flat|nested] 36+ messages in thread* [PATCH RFC 1/4] phy: Add new Exynos5 USB 3.0 PHY driver
2013-11-10 14:08 ` Tomasz Figa
@ 2013-11-20 8:44 ` Vivek Gautam
2013-11-20 8:55 ` Vivek Gautam
0 siblings, 1 reply; 36+ messages in thread
From: Vivek Gautam @ 2013-11-20 8:44 UTC (permalink / raw)
To: linux-arm-kernel
Hi Tomasz,
On Sun, Nov 10, 2013 at 7:38 PM, Tomasz Figa <tomasz.figa@gmail.com> wrote:
> Hi Vivek,
>
> On Thursday 31 of October 2013 13:15:41 Vivek Gautam wrote:
>> Add a new driver for the USB 3.0 PHY on Exynos5 series of SoCs.
>> The new driver uses the generic PHY framework and will interact
>> with DWC3 controller present on Exynos5 series of SoCs.
>>
>> Signed-off-by: Vivek Gautam <gautam.vivek@samsung.com>
>> ---
>> .../devicetree/bindings/phy/samsung-phy.txt | 20 +
>> drivers/phy/Kconfig | 7 +
>> drivers/phy/Makefile | 1 +
>> drivers/phy/phy-exynos5-usb3.c | 562 ++++++++++++++++++++
>> 4 files changed, 590 insertions(+), 0 deletions(-)
>> create mode 100644 drivers/phy/phy-exynos5-usb3.c
>>
>> diff --git a/Documentation/devicetree/bindings/phy/samsung-phy.txt b/Documentation/devicetree/bindings/phy/samsung-phy.txt
>> index c0fccaa..9b5c111 100644
>> --- a/Documentation/devicetree/bindings/phy/samsung-phy.txt
>> +++ b/Documentation/devicetree/bindings/phy/samsung-phy.txt
>> @@ -20,3 +20,23 @@ Required properties:
>> - compatible : should be "samsung,exynos5250-dp-video-phy";
>> - reg : offset and length of the Display Port PHY register set;
>> - #phy-cells : from the generic PHY bindings, must be 0;
>> +
>> +Samsung Exynos5 SoC seiries USB 3.0 PHY controller
>
> typo: s/seiries/series/
will correct it.
>
>> +--------------------------------------------------
>> +
>> +Required properties:
>> +- compatible :
>> + should be "samsung,exynos5250-usb3phy" for exynos5250 SoC
>> + should be "samsung,exynos5420-usb3phy" for exynos5420 SoC
>
> I'd slightly change this into something like this:
>
> - compatible: Should be set to one of following supported values:
> - "samsung,exynos5250-usb3phy" - for Exynos5250 SoC,
> - "samsung,exynos5420-usb3phy" - for Exynos5420 SoC.
sure, will make it as suggested.
>
>> +- reg : Register offset and length array
>> + - first field corresponds to USB 3.0 PHY register set;
>> + - second field corresponds to PHY power isolation register
>> + present in PMU;
>
> For consistency and to make things more future-proof, you should consider
> using the PMU indirectly, through the syscon interface, as done in Leela
> Krishna Amudala's series[1] in case of watchdog driver.
Right that's a better way to do.
But this will again introduce the register offset arithmetic once again.
And in case of multiple USB 3.0 PHY controllers (like for Exynos5420),
we would need to take extra care of each such offset, by having
provision for aliases
for the usb3phy nodes and then setting required offset before doing isolation.
For Exynos5420 USB3.0 PHY channel 0 is controlled by 0x10040704; and
USB3.0 PHY channel 1 is controlled by 0x10040708.
>
> I will tell Kamil to do the same for USB 2.0 PHY as well.
>
> [1] http://thread.gmane.org/gmane.linux.kernel.samsung-soc/24652
>
>> +- clocks: Clock IDs array as required by the controller
>> +- clock-names: names of clocks correseponding to IDs in the clock property;
>> + Required clocks:
>> + - first clock is main PHY clock (same as USB 3.0 controller IP clock)
>> + - second clock is reference clock (usually crystal clock)
>> + optional clock:
>> + - third clock is special clock used by PHY for operation
>
> Is this clock really optional? It looks like it's required for Exynos5420.
Yes, this clock is an additional clock for Exynos5420 rather then
being just optional
> If so, you should instead change this to:
>
> "Additional clocks required for Exynos5420:"
Ok will change this.
>
> Also you have not specified names of the clocks, just what they are.
> Please remember that those are input names, so you can imagine them as
> names of clock input pins of the IP block, not SoC-level clock names.
So you mean, similar to what driver requests (clocks with their input names) ?
will add clock names.
>
>> +- #phy-cells : from the generic PHY bindings, must be 0;
>
> I'd also add an example of correct USB 3.0 PHY device tree node here.
Sorry, forgot to add an example of the device node :-)
will add one.
>
>> diff --git a/drivers/phy/phy-exynos5-usb3.c b/drivers/phy/phy-exynos5-usb3.c
>> new file mode 100644
>> index 0000000..b9a2674
>> --- /dev/null
>> +++ b/drivers/phy/phy-exynos5-usb3.c
>> @@ -0,0 +1,562 @@
> [snip]
>> +#define EXYNOS5_DRD_PHYRESUME (0x34)
>> +#define EXYNOS5_DRD_LINKPORT (0x44)
>> +
>> +
>
> nit: Duplicate blank line.
will remove it.
>
>> +/* Isolation, configured in the power management unit */
>> +#define EXYNOS5_USB_ISOL_DRD (1 << 0)
>> +
>> +#define CLKSEL_ERROR -1
>
> What's this?
Hmm..i shouldn't be defining error codes out of blue, will remove it.
>
>> +
>> +#ifndef KHZ
>> +#define KHZ 1000
>> +#endif
>> +
>> +#ifndef MHZ
>> +#define MHZ (KHZ * KHZ)
>> +#endif
>
> Do you really need the #ifndef's above?
You are right. #ifndef not really needed, since no header included
here have these definitions.
Although for samsung i can see they are defined in
arch/arm/plat-samsung/include/plat/cpu.h;
and i am sure we don't want to include that here.
>
>> +
>> +enum samsung_cpu_type {
>> + TYPE_EXYNOS5250,
>> + TYPE_EXYNOS5420,
>> +};
>
> Instead of using this kind of enumeration, I'd rather introduce a struct
> that describes the differences between all supported types.
Will drop these, anyways they are not being used anywhere.
>
>> +
>> +enum usb3phy_state {
>> + STATE_OFF,
>> + STATE_ON,
>> +};
>
> Hmm, isn't it a simple boolean value - false and true?
Right :-)
>
>> +
>> +struct usb3phy_config {
>> + enum samsung_cpu_type cpu;
>> + bool has_sclk_usbphy30;
>> +};
>
> Oh, you already have such struct, so there is even a bigger reason to drop
> the samsung_cpu_type enum above.
Right, i created this structure to make distinction between various cpu types.
And moreover the "samsung_cpu_type" enumerations are not being used
anywhere right now.
I will drop the same.
>
>> +
>> +struct usb3phy_instance {
>> + char *label;
>> + struct usb3phy_driver *drv;
>> + struct phy *phy;
>> + enum usb3phy_state state;
>> + u32 clk;
>> + unsigned long rate;
>> +};
>
> You seem to have just one instance in this driver. Do you really
> need this struct?
Right, i was hoping to get a comment on this ;-)
Will move the field to "usb3phy_driver" structure.
>
>> +
>> +struct usb3phy_driver {
>> + struct device *dev;
>> + void __iomem *reg_phy;
>> + void __iomem *reg_isol;
>> + struct clk *clk;
>> + struct clk *sclk_usbphy30;
>> + struct usb3phy_instance instance;
>
> Fields from that struct could be simply moved here.
Hmm, will move them here.
>
>> +};
>> +
>> +/*
>> + * exynos5_rate_to_clk() converts the supplied clock rate to the value that
>> + * can be written to the phy register.
>> + */
>> +static u32 exynos5_rate_to_clk(unsigned long rate)
>> +{
>> + unsigned int clksel;
>> +
>> + /* EXYNOS5_FSEL_MASK */
>> +
>> + switch (rate) {
>> + case 9600 * KHZ:
>> + clksel = EXYNOS5_FSEL_9MHZ6;
>> + break;
>> + case 10 * MHZ:
>> + clksel = EXYNOS5_FSEL_10MHZ;
>> + break;
>> + case 12 * MHZ:
>> + clksel = EXYNOS5_FSEL_12MHZ;
>> + break;
>> + case 19200 * KHZ:
>> + clksel = EXYNOS5_FSEL_19MHZ2;
>> + break;
>> + case 20 * MHZ:
>> + clksel = EXYNOS5_FSEL_20MHZ;
>> + break;
>> + case 24 * MHZ:
>> + clksel = EXYNOS5_FSEL_24MHZ;
>> + break;
>> + case 50 * MHZ:
>> + clksel = EXYNOS5_FSEL_50MHZ;
>> + break;
>> + default:
>> + clksel = CLKSEL_ERROR;
>> + }
>> +
>> + return clksel;
>> +}
>> +
>> +static void exynos5_usb3phy_isol(struct usb3phy_instance *inst, bool on)
>> +{
>> + struct usb3phy_driver *drv = inst->drv;
>> + u32 tmp;
>> +
>> + if (!drv->reg_isol)
>> + return;
>> +
>> + tmp = readl(drv->reg_isol);
>> + if (on)
>> + tmp &= ~EXYNOS5_USB_ISOL_DRD;
>> + else
>> + tmp |= EXYNOS5_USB_ISOL_DRD;
>> + writel(tmp, drv->reg_isol);
>> +}
>> +
>> +/*
>> + * Sets the phy clk as EXTREFCLK (XXTI) which is internal clock from clock core.
>> + */
>> +static u32 exynos5_usb3phy_set_refclk(struct usb3phy_instance *inst)
>> +{
>> + u32 reg;
>> + u32 refclk;
>> +
>> + refclk = inst->clk;
>> +
>> + reg = PHYCLKRST_REFCLKSEL_EXT_REFCLK |
>> + PHYCLKRST_FSEL(refclk);
>> +
>> + switch (refclk) {
>
> If I'm reading this correctly, you are switching a value returned by
> another switch before (in exynos5_rate_to_clk()), which is only used in
> this function.
We are not only switching the refclk but also setting "PHYCLKRST_FSEL(__x)".
Below i have given a brief explanation about the PHYCLKRST register
settings required by PHY
for different input reference clock frequencies.
>
> You could instead drop the exynos5_rate_to_clk() function completely and
> simply make a switch over the real clock frequency here.
>
>> + case EXYNOS5_FSEL_50MHZ:
>> + reg |= (PHYCLKRST_MPLL_MULTIPLIER_50M_REF |
>> + PHYCLKRST_SSC_REFCLKSEL(0x00));
>> + break;
>> + case EXYNOS5_FSEL_20MHZ:
>> + reg |= (PHYCLKRST_MPLL_MULTIPLIER_20MHZ_REF |
>> + PHYCLKRST_SSC_REFCLKSEL(0x00));
>> + break;
>> + case EXYNOS5_FSEL_19MHZ2:
>> + reg |= (PHYCLKRST_MPLL_MULTIPLIER_19200KHZ_REF |
>> + PHYCLKRST_SSC_REFCLKSEL(0x88));
>> + break;
>> + case EXYNOS5_FSEL_24MHZ:
>> + default:
>
> This switch does not seem to handle all the cases handled by
> exynos5_rate_to_clk(). Does it mean that the value for 24 MHz refclk can
> be used for all the remaining cases or they are not supported?
I got the PHY databook from our H/w team.
Looking into that i can find that there are two ways the operational
clocks are generated by PHY block from input reference clock
for super-speed and high-speed operations :
1) either using shared reference clock for HS and SS operations (when
refclksel [3:2] = 0x10 in PHYCLKRST register of USB 3.0 PHY of
Exynos5250)
2) or using separate reference clock for HS and SS operations (when
refclksel [3:2] = 0x11 in PHYCLKRST register of USB 3.0 PHY of
Exynos5250)
Both approaches have different settings for PHYCLKRST register.
Right now we are using the second approach.
So, as given in databook
- the bit settings used for High-speed are defined for input reference
clock freq ranging from 9.6 MHz to 50MHz,
as given by exynos5_rate_to_clk() function. Only bit setting needs
to be done in this case is PHYCLKRST_FSEL(__x).
- And, for super-speed the bit settings are defined for input
reference clock freq ranging from 19.2 MHz to 200MHz.
Bit settings to be done in this case are
PHYCLKRST_MPLL_MULTIPLIER_** and PHYCLKRST_SSC_REFCLKSEL(__x).
So basically exynos5_usb3phy_set_refclk() function includes a subset
of input reference clock freq as defined by exynos5_rate_to_clk()
function.
Hope this explanation makes things a bit clear.
>
>> + reg |= (PHYCLKRST_MPLL_MULTIPLIER_24MHZ_REF |
>> + PHYCLKRST_SSC_REFCLKSEL(0x88));
>> + break;
>> + }
>> +
>> + return reg;
>> +}
> [snip]
>> +static int exynos5_usb3phy_power_on(struct phy *phy)
>> +{
>> + struct usb3phy_instance *inst = phy_get_drvdata(phy);
>> + struct usb3phy_driver *drv = inst->drv;
>> + int ret;
>> +
>> + dev_info(drv->dev, "Request to power_on \"%s\" usb phy\n",
>> + inst->label);
>
> dev_dbg()
sure
>
>> +
>> + if (drv->sclk_usbphy30)
>
> This check is incorrect. A NULL pointer is a correct value for a clock
> as defined by Common Clock Framework, so IS_ERR() must be used here
> instead.
Right, will instead check of IS_ERR(drv->sclk_usbphy30), and act accrodingly.
>
>> + clk_prepare_enable(drv->sclk_usbphy30);
>
> Missing error check.
Hmm, will add one.
>
>> +
>> + ret = clk_prepare_enable(drv->clk);
>> + if (ret)
>> + return ret;
>> +
>
> All the code starting here...
>
>> + if (inst->state == STATE_ON) {
>> + dev_err(drv->dev, "usb phy \"%s\" already on",
>> + inst->label);
>> + ret = -ENODEV;
>> + goto err0;
>> + }
>> +
>> + inst->state = STATE_ON;
>
> ...and ending here, can be safely removed, since the PHY framework already
> provides reference counting for PHYs.
Sure will remove this chunk of code for state checking.
>
>> +
>> + /* Initialize the PHY and power it ON */
>> + exynos5_usb3phy_init(inst);
>> + exynos5_usb3phy_isol(inst, 0);
>> +
>> +err0:
>> + clk_disable_unprepare(drv->clk);
>
> Is this clock needed for USB PHY operation or just for register accesses?
This clock is required for register accesses. The operational clocks
are derived out of reference clock
given to PHY block, which comes from XXTI (FIN_PLL).
>
>> +
>> + return ret;
>> +}
>> +
>> +static int exynos5_usb3phy_power_off(struct phy *phy)
>> +{
>> + struct usb3phy_instance *inst = phy_get_drvdata(phy);
>> + struct usb3phy_driver *drv = inst->drv;
>> + int ret;
>> +
>> + dev_info(drv->dev, "Request to power_off \"%s\" usb phy\n",
>> + inst->label);
>
> dev_dbg()
ok
>
>> + ret = clk_prepare_enable(drv->clk);
>> + if (ret)
>> + return ret;
>> +
>> + if (inst->state == STATE_OFF) {
>> + dev_err(drv->dev, "usb phy \"%s\" already off",
>> + inst->label);
>> + ret = -ENODEV;
>> + goto err0;
>> + }
>> +
>> + inst->state = STATE_OFF;
>
> Same comment about the PHY framework already doing reference counting.
Sure will remove this chunk of code for state checking.
>
>> +
>> + /* Power-off the PHY and de-initialize it */
>> + exynos5_usb3phy_isol(inst, 1);
>> + exynos5_usb3phy_exit(inst);
>> +
>> +err0:
>> + clk_disable_unprepare(drv->clk);
>> + if (drv->sclk_usbphy30)
>> + clk_disable_unprepare(drv->sclk_usbphy30);
>> +
>> + return ret;
>> +}
>> +
>> +static struct phy_ops exynos5_usb3phy_ops = {
>> + .power_on = exynos5_usb3phy_power_on,
>> + .power_off = exynos5_usb3phy_power_off,
>> + .owner = THIS_MODULE,
>> +};
>> +
>> +static const struct of_device_id exynos5_usb3phy_of_match[];
>
> What about simply moving the definition here instead using a forward
> declaration?
Ok, will move the of_device_id struct definition here. I just thought
i would be cleaner to place it below probe () ;-)
>
>> +
>> +static int exynos5_usb3phy_probe(struct platform_device *pdev)
>> +{
>> + struct device *dev = &pdev->dev;
>> + struct usb3phy_driver *drv;
>> + struct usb3phy_instance *inst;
>> + struct phy_provider *phy_provider;
>> + struct resource *res;
>> + struct clk *clk;
>> + const struct of_device_id *match;
>> + const struct usb3phy_config *cfg;
>> +
>
> Just to be safe, you should check if pdev->dev.of_node is not NULL here,
> to make sure that the driver got instantiated from device tree.
Sure will add check for pdev->dev.of_node; and will return from probe
with -ENODEV in case
we don't find any node since Exynos5 and above are anyways DT enabled systems.
>
>> + match = of_match_node(exynos5_usb3phy_of_match, pdev->dev.of_node);
>> + if (!match) {
>> + dev_err(dev, "of_match_node() failed\n");
>> + return -EINVAL;
>> + }
>> + cfg = match->data;
>> + if (!cfg) {
>
> I don't think this is possible.
Hmm, will remove this check completely.
>
>> + dev_err(dev, "Failed to get configuration\n");
>> + return -EINVAL;
>> + }
>> +
>> + drv = devm_kzalloc(dev, sizeof(struct usb3phy_driver), GFP_KERNEL);
>
> sizeof(*drv)
sure
>
>> + if (!drv) {
>> + dev_err(dev, "Failed to allocate memory\n");
>
> kmalloc() and friends already print an error message for you.
sorry i could not find the referred error message, can you please
point me to that ?
AFAICS most of the people print error messages if kmalloc() and friends failed.
I tried finding until include/linux/slab.h.
>
>> + return -ENOMEM;
>> + }
>> +
>> + dev_set_drvdata(dev, drv);
>> + drv->dev = dev;
>> +
>> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>> + drv->reg_phy = devm_ioremap_resource(dev, res);
>> + if (IS_ERR(drv->reg_phy)) {
>> + dev_err(dev, "Failed to map register memory (phy)\n");
>> + return PTR_ERR(drv->reg_phy);
>> + }
>> +
>> + res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
>> + drv->reg_isol = devm_ioremap_resource(dev, res);
>> + if (IS_ERR(drv->reg_isol)) {
>> + dev_err(dev, "Failed to map register memory (isolation)\n");
>> + return PTR_ERR(drv->reg_isol);
>> + }
>> +
>> + phy_provider = devm_of_phy_provider_register(dev, of_phy_simple_xlate);
>> + if (IS_ERR(phy_provider)) {
>> + dev_err(drv->dev, "Failed to register phy provider\n");
>> + return PTR_ERR(phy_provider);
>> + }
>
> The provider should be registered as the last thing in the sequence, as
> the driver must be ready for handling PHY requests as soon as
> of_phy_provider_register() returns.
Sure, will move this at the end of probe().
>
>> +
>> + drv->clk = devm_clk_get(dev, "phy");
>> + if (IS_ERR(drv->clk)) {
>> + dev_err(dev, "Failed to get clock of phy controller\n");
>> + return PTR_ERR(drv->clk);
>> + }
>> +
>> + /*
>> + * Exysno5420 SoC has an additional special clock, used for
>> + * for USB 3.0 PHY operation, this clock goes to the PHY block
>> + * as a reference clock to clock generation block of the controller.
>> + */
>> + if (cfg->has_sclk_usbphy30) {
>> + drv->sclk_usbphy30 = devm_clk_get(dev, "sclk_usbphy30");
>> + if (IS_ERR(drv->clk)) {
>> + dev_err(dev, "Failed to get phy reference clock\n");
>> + return PTR_ERR(drv->clk);
>> + }
>
> Seems like this clock is required for Exynos5420 indeed, as opposed to
> what the DT binding documentation says.
Yes, this is clock is required for Exynos5420. I will modify the
device tree documentation
further to avoid any confusion.
>
>> + }
>> +
>> + inst = &drv->instance;
>> + inst->drv = drv;
>
> This pointer does not seem to be needed.
Ok will drop it. In fact i am going to drop the instance thing
entirely, so this makes sense.
>
>> + inst->label = "usb3drd";
>
> Do you need this label at all?
not really when we use phy's name string directly. ;-)
will drop this.
>
>> +
>> + dev_info(dev, "Creating phy \"%s\"\n", inst->label);
>
> dev_dbg()
sure
>
>> + inst->phy = devm_phy_create(dev, &exynos5_usb3phy_ops, NULL);
>> + if (IS_ERR(inst->phy)) {
>> + dev_err(drv->dev, "Failed to create usb3phy \"%s\"\n",
>> + inst->label);
>> + return PTR_ERR(inst->phy);
>> + }
>> +
>> + phy_set_drvdata(inst->phy, inst);
>> +
>> + clk = clk_get(dev, inst->label);
>
> Since this driver provides only a single PHY, I think you should simply
> use the clock name directly.
Ok will use the name string directly.
>
>> + if (IS_ERR(clk)) {
>> + dev_err(dev, "Failed to get clock of \"%s\" phy\n",
>> + inst->label);
>> + return PTR_ERR(clk);
>> + }
>> +
>> + inst->rate = clk_get_rate(clk);
>> +
>> + inst->clk = exynos5_rate_to_clk(inst->rate);
>> + if (inst->clk == CLKSEL_ERROR) {
>> + dev_err(dev, "Clock rate (%ld) not supported\n",
>> + inst->rate);
>> + clk_put(clk);
>> + return -EINVAL;
>> + }
>> + clk_put(clk);
>
> Technically this should happen at the time of calling PHY enable, while
> a reference to the clock should be kept through the whole PHY lifetime.
> In addition, the clock should be prepare_enabled before it is used.
This is actually the FIN_PLL (XXTI) clock which is being used as
reference clock to
the PHY block, which has its own clock generator.
On knowing the rate of this FIN_PLL, the driver would like to program
the PHY registers
(PHYCLKRST in particular), which contain settings for generating
different operational clocks used by PHY
for high-speed and super-speed operations.
>
> So, to recall, here you could call devm_clk_get(...). Then in
> exynos5_usb3phy_power_on(), call clk_prepare_enable() on it, in
> exynos5_usb3phy_set_refclk() call clk_get_rate() to get its frequency
> and finally clk_disable_unprepare() it in exynos5_usb3phy_power_off().
So do we really need to call prepare_enable() and disable_unprepare()
over this Fin_PLL clock ?
I can move this to the place where PHY is enabled.
>
> Best regards,
> Tomasz
Thanks Tomasz for reviewing this. I will address your comments and
update the new patch-set soon.
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Best Regards
Vivek Gautam
Samsung R&D Institute, Bangalore
India
^ permalink raw reply [flat|nested] 36+ messages in thread* [PATCH RFC 1/4] phy: Add new Exynos5 USB 3.0 PHY driver
2013-11-20 8:44 ` Vivek Gautam
@ 2013-11-20 8:55 ` Vivek Gautam
0 siblings, 0 replies; 36+ messages in thread
From: Vivek Gautam @ 2013-11-20 8:55 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, Nov 20, 2013 at 2:14 PM, Vivek Gautam <gautamvivek1987@gmail.com> wrote:
> Hi Tomasz,
>
>
> On Sun, Nov 10, 2013 at 7:38 PM, Tomasz Figa <tomasz.figa@gmail.com> wrote:
>> Hi Vivek,
>>
>> On Thursday 31 of October 2013 13:15:41 Vivek Gautam wrote:
>>> Add a new driver for the USB 3.0 PHY on Exynos5 series of SoCs.
>>> The new driver uses the generic PHY framework and will interact
>>> with DWC3 controller present on Exynos5 series of SoCs.
>>>
>>> Signed-off-by: Vivek Gautam <gautam.vivek@samsung.com>
>>> ---
>>> .../devicetree/bindings/phy/samsung-phy.txt | 20 +
>>> drivers/phy/Kconfig | 7 +
>>> drivers/phy/Makefile | 1 +
>>> drivers/phy/phy-exynos5-usb3.c | 562 ++++++++++++++++++++
>>> 4 files changed, 590 insertions(+), 0 deletions(-)
>>> create mode 100644 drivers/phy/phy-exynos5-usb3.c
>>>
>>> diff --git a/Documentation/devicetree/bindings/phy/samsung-phy.txt b/Documentation/devicetree/bindings/phy/samsung-phy.txt
>>> index c0fccaa..9b5c111 100644
>>> --- a/Documentation/devicetree/bindings/phy/samsung-phy.txt
>>> +++ b/Documentation/devicetree/bindings/phy/samsung-phy.txt
>>> @@ -20,3 +20,23 @@ Required properties:
>>> - compatible : should be "samsung,exynos5250-dp-video-phy";
>>> - reg : offset and length of the Display Port PHY register set;
>>> - #phy-cells : from the generic PHY bindings, must be 0;
>>> +
>>> +Samsung Exynos5 SoC seiries USB 3.0 PHY controller
>>
>> typo: s/seiries/series/
> will correct it.
>
>>
>>> +--------------------------------------------------
>>> +
>>> +Required properties:
>>> +- compatible :
>>> + should be "samsung,exynos5250-usb3phy" for exynos5250 SoC
>>> + should be "samsung,exynos5420-usb3phy" for exynos5420 SoC
>>
>> I'd slightly change this into something like this:
>>
>> - compatible: Should be set to one of following supported values:
>> - "samsung,exynos5250-usb3phy" - for Exynos5250 SoC,
>> - "samsung,exynos5420-usb3phy" - for Exynos5420 SoC.
>
> sure, will make it as suggested.
>
>>
>>> +- reg : Register offset and length array
>>> + - first field corresponds to USB 3.0 PHY register set;
>>> + - second field corresponds to PHY power isolation register
>>> + present in PMU;
>>
>> For consistency and to make things more future-proof, you should consider
>> using the PMU indirectly, through the syscon interface, as done in Leela
>> Krishna Amudala's series[1] in case of watchdog driver.
>
> Right that's a better way to do.
> But this will again introduce the register offset arithmetic once again.
> And in case of multiple USB 3.0 PHY controllers (like for Exynos5420),
> we would need to take extra care of each such offset, by having
> provision for aliases
> for the usb3phy nodes and then setting required offset before doing isolation.
>
> For Exynos5420 USB3.0 PHY channel 0 is controlled by 0x10040704; and
> USB3.0 PHY channel 1 is controlled by 0x10040708.
Or i think i can add PHY IDs similar to what Sylwester does for
MIPI_CSIS and MIPI_DSIM,
so that i will have something like this:
enum exynos5_usb3phy_id {
EXYNOS5_USB3PHY0,
EXYNOS5_USB3PHY1,
};
and then make use of this to add respective offsets to the pmu reg
base address as obtained from syscon node (0x10040000).
>
>>
>> I will tell Kamil to do the same for USB 2.0 PHY as well.
>>
>> [1] http://thread.gmane.org/gmane.linux.kernel.samsung-soc/24652
>>
>>> +- clocks: Clock IDs array as required by the controller
>>> +- clock-names: names of clocks correseponding to IDs in the clock property;
>>> + Required clocks:
>>> + - first clock is main PHY clock (same as USB 3.0 controller IP clock)
>>> + - second clock is reference clock (usually crystal clock)
>>> + optional clock:
>>> + - third clock is special clock used by PHY for operation
>>
>> Is this clock really optional? It looks like it's required for Exynos5420.
>
> Yes, this clock is an additional clock for Exynos5420 rather then
> being just optional
>
>> If so, you should instead change this to:
>>
>> "Additional clocks required for Exynos5420:"
>
> Ok will change this.
>
>>
>> Also you have not specified names of the clocks, just what they are.
>> Please remember that those are input names, so you can imagine them as
>> names of clock input pins of the IP block, not SoC-level clock names.
>
> So you mean, similar to what driver requests (clocks with their input names) ?
> will add clock names.
>
>>
>>> +- #phy-cells : from the generic PHY bindings, must be 0;
>>
>> I'd also add an example of correct USB 3.0 PHY device tree node here.
>
> Sorry, forgot to add an example of the device node :-)
> will add one.
>
>>
>>> diff --git a/drivers/phy/phy-exynos5-usb3.c b/drivers/phy/phy-exynos5-usb3.c
>>> new file mode 100644
>>> index 0000000..b9a2674
>>> --- /dev/null
>>> +++ b/drivers/phy/phy-exynos5-usb3.c
>>> @@ -0,0 +1,562 @@
>> [snip]
>>> +#define EXYNOS5_DRD_PHYRESUME (0x34)
>>> +#define EXYNOS5_DRD_LINKPORT (0x44)
>>> +
>>> +
>>
>> nit: Duplicate blank line.
> will remove it.
>
>>
>>> +/* Isolation, configured in the power management unit */
>>> +#define EXYNOS5_USB_ISOL_DRD (1 << 0)
>>> +
>>> +#define CLKSEL_ERROR -1
>>
>> What's this?
> Hmm..i shouldn't be defining error codes out of blue, will remove it.
>
>>
>>> +
>>> +#ifndef KHZ
>>> +#define KHZ 1000
>>> +#endif
>>> +
>>> +#ifndef MHZ
>>> +#define MHZ (KHZ * KHZ)
>>> +#endif
>>
>> Do you really need the #ifndef's above?
>
> You are right. #ifndef not really needed, since no header included
> here have these definitions.
> Although for samsung i can see they are defined in
> arch/arm/plat-samsung/include/plat/cpu.h;
> and i am sure we don't want to include that here.
>
>>
>>> +
>>> +enum samsung_cpu_type {
>>> + TYPE_EXYNOS5250,
>>> + TYPE_EXYNOS5420,
>>> +};
>>
>> Instead of using this kind of enumeration, I'd rather introduce a struct
>> that describes the differences between all supported types.
>
> Will drop these, anyways they are not being used anywhere.
>
>>
>>> +
>>> +enum usb3phy_state {
>>> + STATE_OFF,
>>> + STATE_ON,
>>> +};
>>
>> Hmm, isn't it a simple boolean value - false and true?
> Right :-)
>
>>
>>> +
>>> +struct usb3phy_config {
>>> + enum samsung_cpu_type cpu;
>>> + bool has_sclk_usbphy30;
>>> +};
>>
>> Oh, you already have such struct, so there is even a bigger reason to drop
>> the samsung_cpu_type enum above.
>
> Right, i created this structure to make distinction between various cpu types.
> And moreover the "samsung_cpu_type" enumerations are not being used
> anywhere right now.
> I will drop the same.
>
>>
>>> +
>>> +struct usb3phy_instance {
>>> + char *label;
>>> + struct usb3phy_driver *drv;
>>> + struct phy *phy;
>>> + enum usb3phy_state state;
>>> + u32 clk;
>>> + unsigned long rate;
>>> +};
>>
>> You seem to have just one instance in this driver. Do you really
>> need this struct?
>
> Right, i was hoping to get a comment on this ;-)
> Will move the field to "usb3phy_driver" structure.
>
>>
>>> +
>>> +struct usb3phy_driver {
>>> + struct device *dev;
>>> + void __iomem *reg_phy;
>>> + void __iomem *reg_isol;
>>> + struct clk *clk;
>>> + struct clk *sclk_usbphy30;
>>> + struct usb3phy_instance instance;
>>
>> Fields from that struct could be simply moved here.
> Hmm, will move them here.
>
>>
>>> +};
>>> +
>>> +/*
>>> + * exynos5_rate_to_clk() converts the supplied clock rate to the value that
>>> + * can be written to the phy register.
>>> + */
>>> +static u32 exynos5_rate_to_clk(unsigned long rate)
>>> +{
>>> + unsigned int clksel;
>>> +
>>> + /* EXYNOS5_FSEL_MASK */
>>> +
>>> + switch (rate) {
>>> + case 9600 * KHZ:
>>> + clksel = EXYNOS5_FSEL_9MHZ6;
>>> + break;
>>> + case 10 * MHZ:
>>> + clksel = EXYNOS5_FSEL_10MHZ;
>>> + break;
>>> + case 12 * MHZ:
>>> + clksel = EXYNOS5_FSEL_12MHZ;
>>> + break;
>>> + case 19200 * KHZ:
>>> + clksel = EXYNOS5_FSEL_19MHZ2;
>>> + break;
>>> + case 20 * MHZ:
>>> + clksel = EXYNOS5_FSEL_20MHZ;
>>> + break;
>>> + case 24 * MHZ:
>>> + clksel = EXYNOS5_FSEL_24MHZ;
>>> + break;
>>> + case 50 * MHZ:
>>> + clksel = EXYNOS5_FSEL_50MHZ;
>>> + break;
>>> + default:
>>> + clksel = CLKSEL_ERROR;
>>> + }
>>> +
>>> + return clksel;
>>> +}
>>> +
>>> +static void exynos5_usb3phy_isol(struct usb3phy_instance *inst, bool on)
>>> +{
>>> + struct usb3phy_driver *drv = inst->drv;
>>> + u32 tmp;
>>> +
>>> + if (!drv->reg_isol)
>>> + return;
>>> +
>>> + tmp = readl(drv->reg_isol);
>>> + if (on)
>>> + tmp &= ~EXYNOS5_USB_ISOL_DRD;
>>> + else
>>> + tmp |= EXYNOS5_USB_ISOL_DRD;
>>> + writel(tmp, drv->reg_isol);
>>> +}
>>> +
>>> +/*
>>> + * Sets the phy clk as EXTREFCLK (XXTI) which is internal clock from clock core.
>>> + */
>>> +static u32 exynos5_usb3phy_set_refclk(struct usb3phy_instance *inst)
>>> +{
>>> + u32 reg;
>>> + u32 refclk;
>>> +
>>> + refclk = inst->clk;
>>> +
>>> + reg = PHYCLKRST_REFCLKSEL_EXT_REFCLK |
>>> + PHYCLKRST_FSEL(refclk);
>>> +
>>> + switch (refclk) {
>>
>> If I'm reading this correctly, you are switching a value returned by
>> another switch before (in exynos5_rate_to_clk()), which is only used in
>> this function.
>
> We are not only switching the refclk but also setting "PHYCLKRST_FSEL(__x)".
> Below i have given a brief explanation about the PHYCLKRST register
> settings required by PHY
> for different input reference clock frequencies.
>
>>
>> You could instead drop the exynos5_rate_to_clk() function completely and
>> simply make a switch over the real clock frequency here.
>>
>>> + case EXYNOS5_FSEL_50MHZ:
>>> + reg |= (PHYCLKRST_MPLL_MULTIPLIER_50M_REF |
>>> + PHYCLKRST_SSC_REFCLKSEL(0x00));
>>> + break;
>>> + case EXYNOS5_FSEL_20MHZ:
>>> + reg |= (PHYCLKRST_MPLL_MULTIPLIER_20MHZ_REF |
>>> + PHYCLKRST_SSC_REFCLKSEL(0x00));
>>> + break;
>>> + case EXYNOS5_FSEL_19MHZ2:
>>> + reg |= (PHYCLKRST_MPLL_MULTIPLIER_19200KHZ_REF |
>>> + PHYCLKRST_SSC_REFCLKSEL(0x88));
>>> + break;
>>> + case EXYNOS5_FSEL_24MHZ:
>>> + default:
>>
>> This switch does not seem to handle all the cases handled by
>> exynos5_rate_to_clk(). Does it mean that the value for 24 MHz refclk can
>> be used for all the remaining cases or they are not supported?
>
> I got the PHY databook from our H/w team.
> Looking into that i can find that there are two ways the operational
> clocks are generated by PHY block from input reference clock
> for super-speed and high-speed operations :
> 1) either using shared reference clock for HS and SS operations (when
> refclksel [3:2] = 0x10 in PHYCLKRST register of USB 3.0 PHY of
> Exynos5250)
> 2) or using separate reference clock for HS and SS operations (when
> refclksel [3:2] = 0x11 in PHYCLKRST register of USB 3.0 PHY of
> Exynos5250)
>
> Both approaches have different settings for PHYCLKRST register.
> Right now we are using the second approach.
> So, as given in databook
> - the bit settings used for High-speed are defined for input reference
> clock freq ranging from 9.6 MHz to 50MHz,
> as given by exynos5_rate_to_clk() function. Only bit setting needs
> to be done in this case is PHYCLKRST_FSEL(__x).
> - And, for super-speed the bit settings are defined for input
> reference clock freq ranging from 19.2 MHz to 200MHz.
> Bit settings to be done in this case are
> PHYCLKRST_MPLL_MULTIPLIER_** and PHYCLKRST_SSC_REFCLKSEL(__x).
>
> So basically exynos5_usb3phy_set_refclk() function includes a subset
> of input reference clock freq as defined by exynos5_rate_to_clk()
> function.
> Hope this explanation makes things a bit clear.
>
>>
>>> + reg |= (PHYCLKRST_MPLL_MULTIPLIER_24MHZ_REF |
>>> + PHYCLKRST_SSC_REFCLKSEL(0x88));
>>> + break;
>>> + }
>>> +
>>> + return reg;
>>> +}
>> [snip]
>>> +static int exynos5_usb3phy_power_on(struct phy *phy)
>>> +{
>>> + struct usb3phy_instance *inst = phy_get_drvdata(phy);
>>> + struct usb3phy_driver *drv = inst->drv;
>>> + int ret;
>>> +
>>> + dev_info(drv->dev, "Request to power_on \"%s\" usb phy\n",
>>> + inst->label);
>>
>> dev_dbg()
> sure
>
>>
>>> +
>>> + if (drv->sclk_usbphy30)
>>
>> This check is incorrect. A NULL pointer is a correct value for a clock
>> as defined by Common Clock Framework, so IS_ERR() must be used here
>> instead.
>
> Right, will instead check of IS_ERR(drv->sclk_usbphy30), and act accrodingly.
>
>>
>>> + clk_prepare_enable(drv->sclk_usbphy30);
>>
>> Missing error check.
>
> Hmm, will add one.
>
>>
>>> +
>>> + ret = clk_prepare_enable(drv->clk);
>>> + if (ret)
>>> + return ret;
>>> +
>>
>> All the code starting here...
>>
>>> + if (inst->state == STATE_ON) {
>>> + dev_err(drv->dev, "usb phy \"%s\" already on",
>>> + inst->label);
>>> + ret = -ENODEV;
>>> + goto err0;
>>> + }
>>> +
>>> + inst->state = STATE_ON;
>>
>> ...and ending here, can be safely removed, since the PHY framework already
>> provides reference counting for PHYs.
>
> Sure will remove this chunk of code for state checking.
>
>>
>>> +
>>> + /* Initialize the PHY and power it ON */
>>> + exynos5_usb3phy_init(inst);
>>> + exynos5_usb3phy_isol(inst, 0);
>>> +
>>> +err0:
>>> + clk_disable_unprepare(drv->clk);
>>
>> Is this clock needed for USB PHY operation or just for register accesses?
>
> This clock is required for register accesses. The operational clocks
> are derived out of reference clock
> given to PHY block, which comes from XXTI (FIN_PLL).
>
>>
>>> +
>>> + return ret;
>>> +}
>>> +
>>> +static int exynos5_usb3phy_power_off(struct phy *phy)
>>> +{
>>> + struct usb3phy_instance *inst = phy_get_drvdata(phy);
>>> + struct usb3phy_driver *drv = inst->drv;
>>> + int ret;
>>> +
>>> + dev_info(drv->dev, "Request to power_off \"%s\" usb phy\n",
>>> + inst->label);
>>
>> dev_dbg()
> ok
>
>>
>>> + ret = clk_prepare_enable(drv->clk);
>>> + if (ret)
>>> + return ret;
>>> +
>>> + if (inst->state == STATE_OFF) {
>>> + dev_err(drv->dev, "usb phy \"%s\" already off",
>>> + inst->label);
>>> + ret = -ENODEV;
>>> + goto err0;
>>> + }
>>> +
>>> + inst->state = STATE_OFF;
>>
>> Same comment about the PHY framework already doing reference counting.
>
> Sure will remove this chunk of code for state checking.
>
>>
>>> +
>>> + /* Power-off the PHY and de-initialize it */
>>> + exynos5_usb3phy_isol(inst, 1);
>>> + exynos5_usb3phy_exit(inst);
>>> +
>>> +err0:
>>> + clk_disable_unprepare(drv->clk);
>>> + if (drv->sclk_usbphy30)
>>> + clk_disable_unprepare(drv->sclk_usbphy30);
>>> +
>>> + return ret;
>>> +}
>>> +
>>> +static struct phy_ops exynos5_usb3phy_ops = {
>>> + .power_on = exynos5_usb3phy_power_on,
>>> + .power_off = exynos5_usb3phy_power_off,
>>> + .owner = THIS_MODULE,
>>> +};
>>> +
>>> +static const struct of_device_id exynos5_usb3phy_of_match[];
>>
>> What about simply moving the definition here instead using a forward
>> declaration?
>
> Ok, will move the of_device_id struct definition here. I just thought
> i would be cleaner to place it below probe () ;-)
>
>>
>>> +
>>> +static int exynos5_usb3phy_probe(struct platform_device *pdev)
>>> +{
>>> + struct device *dev = &pdev->dev;
>>> + struct usb3phy_driver *drv;
>>> + struct usb3phy_instance *inst;
>>> + struct phy_provider *phy_provider;
>>> + struct resource *res;
>>> + struct clk *clk;
>>> + const struct of_device_id *match;
>>> + const struct usb3phy_config *cfg;
>>> +
>>
>> Just to be safe, you should check if pdev->dev.of_node is not NULL here,
>> to make sure that the driver got instantiated from device tree.
>
> Sure will add check for pdev->dev.of_node; and will return from probe
> with -ENODEV in case
> we don't find any node since Exynos5 and above are anyways DT enabled systems.
>
>>
>>> + match = of_match_node(exynos5_usb3phy_of_match, pdev->dev.of_node);
>>> + if (!match) {
>>> + dev_err(dev, "of_match_node() failed\n");
>>> + return -EINVAL;
>>> + }
>>> + cfg = match->data;
>>> + if (!cfg) {
>>
>> I don't think this is possible.
> Hmm, will remove this check completely.
>
>>
>>> + dev_err(dev, "Failed to get configuration\n");
>>> + return -EINVAL;
>>> + }
>>> +
>>> + drv = devm_kzalloc(dev, sizeof(struct usb3phy_driver), GFP_KERNEL);
>>
>> sizeof(*drv)
>
> sure
>
>>
>>> + if (!drv) {
>>> + dev_err(dev, "Failed to allocate memory\n");
>>
>> kmalloc() and friends already print an error message for you.
>
> sorry i could not find the referred error message, can you please
> point me to that ?
> AFAICS most of the people print error messages if kmalloc() and friends failed.
> I tried finding until include/linux/slab.h.
>>
>>> + return -ENOMEM;
>>> + }
>>> +
>>> + dev_set_drvdata(dev, drv);
>>> + drv->dev = dev;
>>> +
>>> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>>> + drv->reg_phy = devm_ioremap_resource(dev, res);
>>> + if (IS_ERR(drv->reg_phy)) {
>>> + dev_err(dev, "Failed to map register memory (phy)\n");
>>> + return PTR_ERR(drv->reg_phy);
>>> + }
>>> +
>>> + res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
>>> + drv->reg_isol = devm_ioremap_resource(dev, res);
>>> + if (IS_ERR(drv->reg_isol)) {
>>> + dev_err(dev, "Failed to map register memory (isolation)\n");
>>> + return PTR_ERR(drv->reg_isol);
>>> + }
>>> +
>>> + phy_provider = devm_of_phy_provider_register(dev, of_phy_simple_xlate);
>>> + if (IS_ERR(phy_provider)) {
>>> + dev_err(drv->dev, "Failed to register phy provider\n");
>>> + return PTR_ERR(phy_provider);
>>> + }
>>
>> The provider should be registered as the last thing in the sequence, as
>> the driver must be ready for handling PHY requests as soon as
>> of_phy_provider_register() returns.
>
> Sure, will move this at the end of probe().
>
>>
>>> +
>>> + drv->clk = devm_clk_get(dev, "phy");
>>> + if (IS_ERR(drv->clk)) {
>>> + dev_err(dev, "Failed to get clock of phy controller\n");
>>> + return PTR_ERR(drv->clk);
>>> + }
>>> +
>>> + /*
>>> + * Exysno5420 SoC has an additional special clock, used for
>>> + * for USB 3.0 PHY operation, this clock goes to the PHY block
>>> + * as a reference clock to clock generation block of the controller.
>>> + */
>>> + if (cfg->has_sclk_usbphy30) {
>>> + drv->sclk_usbphy30 = devm_clk_get(dev, "sclk_usbphy30");
>>> + if (IS_ERR(drv->clk)) {
>>> + dev_err(dev, "Failed to get phy reference clock\n");
>>> + return PTR_ERR(drv->clk);
>>> + }
>>
>> Seems like this clock is required for Exynos5420 indeed, as opposed to
>> what the DT binding documentation says.
>
> Yes, this is clock is required for Exynos5420. I will modify the
> device tree documentation
> further to avoid any confusion.
>
>>
>>> + }
>>> +
>>> + inst = &drv->instance;
>>> + inst->drv = drv;
>>
>> This pointer does not seem to be needed.
> Ok will drop it. In fact i am going to drop the instance thing
> entirely, so this makes sense.
>
>>
>>> + inst->label = "usb3drd";
>>
>> Do you need this label at all?
>
> not really when we use phy's name string directly. ;-)
> will drop this.
>
>>
>>> +
>>> + dev_info(dev, "Creating phy \"%s\"\n", inst->label);
>>
>> dev_dbg()
> sure
>
>>
>>> + inst->phy = devm_phy_create(dev, &exynos5_usb3phy_ops, NULL);
>>> + if (IS_ERR(inst->phy)) {
>>> + dev_err(drv->dev, "Failed to create usb3phy \"%s\"\n",
>>> + inst->label);
>>> + return PTR_ERR(inst->phy);
>>> + }
>>> +
>>> + phy_set_drvdata(inst->phy, inst);
>>> +
>>> + clk = clk_get(dev, inst->label);
>>
>> Since this driver provides only a single PHY, I think you should simply
>> use the clock name directly.
>
> Ok will use the name string directly.
>
>>
>>> + if (IS_ERR(clk)) {
>>> + dev_err(dev, "Failed to get clock of \"%s\" phy\n",
>>> + inst->label);
>>> + return PTR_ERR(clk);
>>> + }
>>> +
>>> + inst->rate = clk_get_rate(clk);
>>> +
>>> + inst->clk = exynos5_rate_to_clk(inst->rate);
>>> + if (inst->clk == CLKSEL_ERROR) {
>>> + dev_err(dev, "Clock rate (%ld) not supported\n",
>>> + inst->rate);
>>> + clk_put(clk);
>>> + return -EINVAL;
>>> + }
>>> + clk_put(clk);
>>
>> Technically this should happen at the time of calling PHY enable, while
>> a reference to the clock should be kept through the whole PHY lifetime.
>> In addition, the clock should be prepare_enabled before it is used.
>
> This is actually the FIN_PLL (XXTI) clock which is being used as
> reference clock to
> the PHY block, which has its own clock generator.
> On knowing the rate of this FIN_PLL, the driver would like to program
> the PHY registers
> (PHYCLKRST in particular), which contain settings for generating
> different operational clocks used by PHY
> for high-speed and super-speed operations.
>
>>
>> So, to recall, here you could call devm_clk_get(...). Then in
>> exynos5_usb3phy_power_on(), call clk_prepare_enable() on it, in
>> exynos5_usb3phy_set_refclk() call clk_get_rate() to get its frequency
>> and finally clk_disable_unprepare() it in exynos5_usb3phy_power_off().
>
> So do we really need to call prepare_enable() and disable_unprepare()
> over this Fin_PLL clock ?
> I can move this to the place where PHY is enabled.
>
>>
>> Best regards,
>> Tomasz
>
> Thanks Tomasz for reviewing this. I will address your comments and
> update the new patch-set soon.
>
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
>> the body of a message to majordomo at vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
>
> --
> Best Regards
> Vivek Gautam
> Samsung R&D Institute, Bangalore
> India
--
Best Regards
Vivek Gautam
Samsung R&D Institute, Bangalore
India
^ permalink raw reply [flat|nested] 36+ messages in thread
* [PATCH RFC 1/4] phy: Add new Exynos5 USB 3.0 PHY driver
2013-10-31 7:45 ` [PATCH RFC 1/4] phy: Add new Exynos5 USB 3.0 PHY driver Vivek Gautam
2013-11-04 6:54 ` Kishon Vijay Abraham I
2013-11-10 14:08 ` Tomasz Figa
@ 2013-11-21 12:26 ` Yuvaraj Cd
2 siblings, 0 replies; 36+ messages in thread
From: Yuvaraj Cd @ 2013-11-21 12:26 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Oct 31, 2013 at 1:15 PM, Vivek Gautam <gautam.vivek@samsung.com> wrote:
> Add a new driver for the USB 3.0 PHY on Exynos5 series of SoCs.
> The new driver uses the generic PHY framework and will interact
> with DWC3 controller present on Exynos5 series of SoCs.
>
> Signed-off-by: Vivek Gautam <gautam.vivek@samsung.com>
> ---
> .../devicetree/bindings/phy/samsung-phy.txt | 20 +
> drivers/phy/Kconfig | 7 +
> drivers/phy/Makefile | 1 +
> drivers/phy/phy-exynos5-usb3.c | 562 ++++++++++++++++++++
> 4 files changed, 590 insertions(+), 0 deletions(-)
> create mode 100644 drivers/phy/phy-exynos5-usb3.c
>
> diff --git a/Documentation/devicetree/bindings/phy/samsung-phy.txt b/Documentation/devicetree/bindings/phy/samsung-phy.txt
> index c0fccaa..9b5c111 100644
> --- a/Documentation/devicetree/bindings/phy/samsung-phy.txt
> +++ b/Documentation/devicetree/bindings/phy/samsung-phy.txt
> @@ -20,3 +20,23 @@ Required properties:
> - compatible : should be "samsung,exynos5250-dp-video-phy";
> - reg : offset and length of the Display Port PHY register set;
> - #phy-cells : from the generic PHY bindings, must be 0;
> +
> +Samsung Exynos5 SoC seiries USB 3.0 PHY controller
> +--------------------------------------------------
> +
> +Required properties:
> +- compatible :
> + should be "samsung,exynos5250-usb3phy" for exynos5250 SoC
> + should be "samsung,exynos5420-usb3phy" for exynos5420 SoC
> +- reg : Register offset and length array
> + - first field corresponds to USB 3.0 PHY register set;
> + - second field corresponds to PHY power isolation register
> + present in PMU;
> +- clocks: Clock IDs array as required by the controller
> +- clock-names: names of clocks correseponding to IDs in the clock property;
> + Required clocks:
> + - first clock is main PHY clock (same as USB 3.0 controller IP clock)
> + - second clock is reference clock (usually crystal clock)
> + optional clock:
> + - third clock is special clock used by PHY for operation
> +- #phy-cells : from the generic PHY bindings, must be 0;
> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
> index a344f3d..9a100c6 100644
> --- a/drivers/phy/Kconfig
> +++ b/drivers/phy/Kconfig
> @@ -51,4 +51,11 @@ config PHY_EXYNOS_DP_VIDEO
> help
> Support for Display Port PHY found on Samsung EXYNOS SoCs.
>
> +config PHY_EXYNOS5_USB3
> + tristate "Exynos5 SoC series USB 3.0 PHY driver"
> + depends on ARCH_EXYNOS5
> + select GENERIC_PHY
> + help
> + Enable USB 3.0 PHY support for Exynos 5 SoC series
> +
> endmenu
> diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
> index d0caae9..9c06a61 100644
> --- a/drivers/phy/Makefile
> +++ b/drivers/phy/Makefile
> @@ -7,3 +7,4 @@ obj-$(CONFIG_PHY_EXYNOS_DP_VIDEO) += phy-exynos-dp-video.o
> obj-$(CONFIG_PHY_EXYNOS_MIPI_VIDEO) += phy-exynos-mipi-video.o
> obj-$(CONFIG_OMAP_USB2) += phy-omap-usb2.o
> obj-$(CONFIG_TWL4030_USB) += phy-twl4030-usb.o
> +obj-$(CONFIG_PHY_EXYNOS5_USB3) += phy-exynos5-usb3.o
> diff --git a/drivers/phy/phy-exynos5-usb3.c b/drivers/phy/phy-exynos5-usb3.c
> new file mode 100644
> index 0000000..b9a2674
> --- /dev/null
> +++ b/drivers/phy/phy-exynos5-usb3.c
> @@ -0,0 +1,562 @@
> +/*
> + * Samsung EXYNOS5 SoC series USB 3.0 PHY driver
> + *
> + * Copyright (C) 2013 Samsung Electronics Co., Ltd.
> + * Author: Vivek Gautam <gautam.vivek@samsung.com>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#include <linux/clk.h>
> +#include <linux/delay.h>
> +#include <linux/io.h>
> +#include <linux/kernel.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/mutex.h>
> +
> +/* Exynos USB PHY registers */
> +#define EXYNOS5_FSEL_9MHZ6 0x0
> +#define EXYNOS5_FSEL_10MHZ 0x1
> +#define EXYNOS5_FSEL_12MHZ 0x2
> +#define EXYNOS5_FSEL_19MHZ2 0x3
> +#define EXYNOS5_FSEL_20MHZ 0x4
> +#define EXYNOS5_FSEL_24MHZ 0x5
> +#define EXYNOS5_FSEL_50MHZ 0x7
> +
> +/* EXYNOS5: USB 3.0 DRD PHY registers */
> +#define EXYNOS5_DRD_LINKSYSTEM (0x04)
> +
> +#define LINKSYSTEM_FLADJ_MASK (0x3f << 1)
> +#define LINKSYSTEM_FLADJ(_x) ((_x) << 1)
> +#define LINKSYSTEM_XHCI_VERSION_CONTROL (0x1 << 27)
> +
> +#define EXYNOS5_DRD_PHYUTMI (0x08)
> +
> +#define PHYUTMI_OTGDISABLE (0x1 << 6)
> +#define PHYUTMI_FORCESUSPEND (0x1 << 1)
> +#define PHYUTMI_FORCESLEEP (0x1 << 0)
> +
> +#define EXYNOS5_DRD_PHYPIPE (0x0c)
> +
> +#define EXYNOS5_DRD_PHYCLKRST (0x10)
> +
> +#define PHYCLKRST_SSC_REFCLKSEL_MASK (0xff << 23)
> +#define PHYCLKRST_SSC_REFCLKSEL(_x) ((_x) << 23)
> +
> +#define PHYCLKRST_SSC_RANGE_MASK (0x03 << 21)
> +#define PHYCLKRST_SSC_RANGE(_x) ((_x) << 21)
> +
> +#define PHYCLKRST_SSC_EN (0x1 << 20)
> +#define PHYCLKRST_REF_SSP_EN (0x1 << 19)
> +#define PHYCLKRST_REF_CLKDIV2 (0x1 << 18)
> +
> +#define PHYCLKRST_MPLL_MULTIPLIER_MASK (0x7f << 11)
> +#define PHYCLKRST_MPLL_MULTIPLIER_100MHZ_REF (0x19 << 11)
> +#define PHYCLKRST_MPLL_MULTIPLIER_50M_REF (0x02 << 11)
> +#define PHYCLKRST_MPLL_MULTIPLIER_24MHZ_REF (0x68 << 11)
> +#define PHYCLKRST_MPLL_MULTIPLIER_20MHZ_REF (0x7d << 11)
> +#define PHYCLKRST_MPLL_MULTIPLIER_19200KHZ_REF (0x02 << 11)
> +
> +#define PHYCLKRST_FSEL_MASK (0x3f << 5)
> +#define PHYCLKRST_FSEL(_x) ((_x) << 5)
> +#define PHYCLKRST_FSEL_PAD_100MHZ (0x27 << 5)
> +#define PHYCLKRST_FSEL_PAD_24MHZ (0x2a << 5)
> +#define PHYCLKRST_FSEL_PAD_20MHZ (0x31 << 5)
> +#define PHYCLKRST_FSEL_PAD_19_2MHZ (0x38 << 5)
> +
> +#define PHYCLKRST_RETENABLEN (0x1 << 4)
> +
> +#define PHYCLKRST_REFCLKSEL_MASK (0x03 << 2)
> +#define PHYCLKRST_REFCLKSEL_PAD_REFCLK (0x2 << 2)
> +#define PHYCLKRST_REFCLKSEL_EXT_REFCLK (0x3 << 2)
> +
> +#define PHYCLKRST_PORTRESET (0x1 << 1)
> +#define PHYCLKRST_COMMONONN (0x1 << 0)
> +
> +#define EXYNOS5_DRD_PHYREG0 (0x14)
> +#define EXYNOS5_DRD_PHYREG1 (0x18)
> +
> +#define EXYNOS5_DRD_PHYPARAM0 (0x1c)
> +
> +#define PHYPARAM0_REF_USE_PAD (0x1 << 31)
> +#define PHYPARAM0_REF_LOSLEVEL_MASK (0x1f << 26)
> +#define PHYPARAM0_REF_LOSLEVEL (0x9 << 26)
> +
> +#define EXYNOS5_DRD_PHYPARAM1 (0x20)
> +
> +#define PHYPARAM1_PCS_TXDEEMPH_MASK (0x1f << 0)
> +#define PHYPARAM1_PCS_TXDEEMPH (0x1c)
> +
> +#define EXYNOS5_DRD_PHYTERM (0x24)
> +
> +#define EXYNOS5_DRD_PHYTEST (0x28)
> +
> +#define PHYTEST_POWERDOWN_SSP (0x1 << 3)
> +#define PHYTEST_POWERDOWN_HSP (0x1 << 2)
> +
> +#define EXYNOS5_DRD_PHYADP (0x2c)
> +
> +#define EXYNOS5_DRD_PHYBATCHG (0x30)
> +
> +#define PHYBATCHG_UTMI_CLKSEL (0x1 << 2)
> +
> +#define EXYNOS5_DRD_PHYRESUME (0x34)
> +#define EXYNOS5_DRD_LINKPORT (0x44)
> +
> +
> +/* Isolation, configured in the power management unit */
> +#define EXYNOS5_USB_ISOL_DRD (1 << 0)
> +
> +#define CLKSEL_ERROR -1
> +
> +#ifndef KHZ
> +#define KHZ 1000
> +#endif
> +
> +#ifndef MHZ
> +#define MHZ (KHZ * KHZ)
> +#endif
> +
> +enum samsung_cpu_type {
> + TYPE_EXYNOS5250,
> + TYPE_EXYNOS5420,
> +};
> +
> +enum usb3phy_state {
> + STATE_OFF,
> + STATE_ON,
> +};
> +
> +struct usb3phy_config {
> + enum samsung_cpu_type cpu;
> + bool has_sclk_usbphy30;
> +};
> +
> +struct usb3phy_instance {
> + char *label;
> + struct usb3phy_driver *drv;
> + struct phy *phy;
> + enum usb3phy_state state;
> + u32 clk;
> + unsigned long rate;
> +};
> +
> +struct usb3phy_driver {
> + struct device *dev;
> + void __iomem *reg_phy;
> + void __iomem *reg_isol;
> + struct clk *clk;
> + struct clk *sclk_usbphy30;
> + struct usb3phy_instance instance;
> +};
> +
> +/*
> + * exynos5_rate_to_clk() converts the supplied clock rate to the value that
> + * can be written to the phy register.
> + */
> +static u32 exynos5_rate_to_clk(unsigned long rate)
> +{
> + unsigned int clksel;
> +
> + /* EXYNOS5_FSEL_MASK */
> +
> + switch (rate) {
> + case 9600 * KHZ:
> + clksel = EXYNOS5_FSEL_9MHZ6;
> + break;
> + case 10 * MHZ:
> + clksel = EXYNOS5_FSEL_10MHZ;
> + break;
> + case 12 * MHZ:
> + clksel = EXYNOS5_FSEL_12MHZ;
> + break;
> + case 19200 * KHZ:
> + clksel = EXYNOS5_FSEL_19MHZ2;
> + break;
> + case 20 * MHZ:
> + clksel = EXYNOS5_FSEL_20MHZ;
> + break;
> + case 24 * MHZ:
> + clksel = EXYNOS5_FSEL_24MHZ;
> + break;
> + case 50 * MHZ:
> + clksel = EXYNOS5_FSEL_50MHZ;
> + break;
> + default:
> + clksel = CLKSEL_ERROR;
> + }
> +
> + return clksel;
> +}
> +
> +static void exynos5_usb3phy_isol(struct usb3phy_instance *inst, bool on)
> +{
> + struct usb3phy_driver *drv = inst->drv;
> + u32 tmp;
> +
> + if (!drv->reg_isol)
> + return;
> +
> + tmp = readl(drv->reg_isol);
> + if (on)
> + tmp &= ~EXYNOS5_USB_ISOL_DRD;
> + else
> + tmp |= EXYNOS5_USB_ISOL_DRD;
> + writel(tmp, drv->reg_isol);
> +}
> +
> +/*
> + * Sets the phy clk as EXTREFCLK (XXTI) which is internal clock from clock core.
> + */
> +static u32 exynos5_usb3phy_set_refclk(struct usb3phy_instance *inst)
> +{
> + u32 reg;
> + u32 refclk;
> +
> + refclk = inst->clk;
> +
> + reg = PHYCLKRST_REFCLKSEL_EXT_REFCLK |
> + PHYCLKRST_FSEL(refclk);
> +
> + switch (refclk) {
> + case EXYNOS5_FSEL_50MHZ:
> + reg |= (PHYCLKRST_MPLL_MULTIPLIER_50M_REF |
> + PHYCLKRST_SSC_REFCLKSEL(0x00));
> + break;
> + case EXYNOS5_FSEL_20MHZ:
> + reg |= (PHYCLKRST_MPLL_MULTIPLIER_20MHZ_REF |
> + PHYCLKRST_SSC_REFCLKSEL(0x00));
> + break;
> + case EXYNOS5_FSEL_19MHZ2:
> + reg |= (PHYCLKRST_MPLL_MULTIPLIER_19200KHZ_REF |
> + PHYCLKRST_SSC_REFCLKSEL(0x88));
> + break;
> + case EXYNOS5_FSEL_24MHZ:
> + default:
> + reg |= (PHYCLKRST_MPLL_MULTIPLIER_24MHZ_REF |
> + PHYCLKRST_SSC_REFCLKSEL(0x88));
> + break;
> + }
> +
> + return reg;
> +}
> +
> +static void exynos5_usb3phy_init(struct usb3phy_instance *inst)
> +{
> + struct usb3phy_driver *drv = inst->drv;
> + u32 phyparam0;
> + u32 phyparam1;
> + u32 linksystem;
> + u32 phybatchg;
> + u32 phytest;
> + u32 phyclkrst;
> +
> + /* Reset USB 3.0 PHY */
> + writel(0x0, drv->reg_phy + EXYNOS5_DRD_PHYREG0);
> +
> + phyparam0 = readl(drv->reg_phy + EXYNOS5_DRD_PHYPARAM0);
> + /* Select PHY CLK source */
> + phyparam0 &= ~PHYPARAM0_REF_USE_PAD;
> + /* Set Loss-of-Signal Detector sensitivity */
> + phyparam0 &= ~PHYPARAM0_REF_LOSLEVEL_MASK;
> + phyparam0 |= PHYPARAM0_REF_LOSLEVEL;
> + writel(phyparam0, drv->reg_phy + EXYNOS5_DRD_PHYPARAM0);
> +
> + writel(0x0, drv->reg_phy + EXYNOS5_DRD_PHYRESUME);
> +
> + /*
> + * Setting the Frame length Adj value[6:1] to default 0x20
> + * See xHCI 1.0 spec, 5.2.4
> + */
> + linksystem = LINKSYSTEM_XHCI_VERSION_CONTROL |
> + LINKSYSTEM_FLADJ(0x20);
> + writel(linksystem, drv->reg_phy + EXYNOS5_DRD_LINKSYSTEM);
> +
> + phyparam1 = readl(drv->reg_phy + EXYNOS5_DRD_PHYPARAM1);
> + /* Set Tx De-Emphasis level */
> + phyparam1 &= ~PHYPARAM1_PCS_TXDEEMPH_MASK;
> + phyparam1 |= PHYPARAM1_PCS_TXDEEMPH;
> + writel(phyparam1, drv->reg_phy + EXYNOS5_DRD_PHYPARAM1);
> +
> + phybatchg = readl(drv->reg_phy + EXYNOS5_DRD_PHYBATCHG);
> + phybatchg |= PHYBATCHG_UTMI_CLKSEL;
> + writel(phybatchg, drv->reg_phy + EXYNOS5_DRD_PHYBATCHG);
> +
> + /* PHYTEST POWERDOWN Control */
> + phytest = readl(drv->reg_phy + EXYNOS5_DRD_PHYTEST);
> + phytest &= ~(PHYTEST_POWERDOWN_SSP |
> + PHYTEST_POWERDOWN_HSP);
> + writel(phytest, drv->reg_phy + EXYNOS5_DRD_PHYTEST);
> +
> + /* UTMI Power Control */
> + writel(PHYUTMI_OTGDISABLE, drv->reg_phy + EXYNOS5_DRD_PHYUTMI);
> +
> + phyclkrst = exynos5_usb3phy_set_refclk(inst);
> +
> + phyclkrst |= PHYCLKRST_PORTRESET |
> + /* Digital power supply in normal operating mode */
> + PHYCLKRST_RETENABLEN |
> + /* Enable ref clock for SS function */
> + PHYCLKRST_REF_SSP_EN |
> + /* Enable spread spectrum */
> + PHYCLKRST_SSC_EN |
> + /* Power down HS Bias and PLL blocks in suspend mode */
> + PHYCLKRST_COMMONONN;
> +
> + writel(phyclkrst, drv->reg_phy + EXYNOS5_DRD_PHYCLKRST);
> +
> + udelay(10);
> +
> + phyclkrst &= ~PHYCLKRST_PORTRESET;
> + writel(phyclkrst, drv->reg_phy + EXYNOS5_DRD_PHYCLKRST);
> +
> +}
> +
> +static void exynos5_usb3phy_exit(struct usb3phy_instance *inst)
> +{
> + struct usb3phy_driver *drv = inst->drv;
> + u32 phyutmi;
> + u32 phyclkrst;
> + u32 phytest;
> +
> + phyutmi = PHYUTMI_OTGDISABLE |
> + PHYUTMI_FORCESUSPEND |
> + PHYUTMI_FORCESLEEP;
> + writel(phyutmi, drv->reg_phy + EXYNOS5_DRD_PHYUTMI);
> +
> + /* Resetting the PHYCLKRST enable bits to reduce leakage current */
> + phyclkrst = readl(drv->reg_phy + EXYNOS5_DRD_PHYCLKRST);
> + phyclkrst &= ~(PHYCLKRST_REF_SSP_EN |
> + PHYCLKRST_SSC_EN |
> + PHYCLKRST_COMMONONN);
> + writel(phyclkrst, drv->reg_phy + EXYNOS5_DRD_PHYCLKRST);
> +
> + /* Control PHYTEST to remove leakage current */
> + phytest = readl(drv->reg_phy + EXYNOS5_DRD_PHYTEST);
> + phytest |= PHYTEST_POWERDOWN_SSP |
> + PHYTEST_POWERDOWN_HSP;
> + writel(phytest, drv->reg_phy + EXYNOS5_DRD_PHYTEST);
> +}
> +
> +static int exynos5_usb3phy_power_on(struct phy *phy)
> +{
> + struct usb3phy_instance *inst = phy_get_drvdata(phy);
> + struct usb3phy_driver *drv = inst->drv;
> + int ret;
> +
> + dev_info(drv->dev, "Request to power_on \"%s\" usb phy\n",
> + inst->label);
> +
> + if (drv->sclk_usbphy30)
> + clk_prepare_enable(drv->sclk_usbphy30);
> +
> + ret = clk_prepare_enable(drv->clk);
> + if (ret)
> + return ret;
> +
> + if (inst->state == STATE_ON) {
> + dev_err(drv->dev, "usb phy \"%s\" already on",
> + inst->label);
> + ret = -ENODEV;
> + goto err0;
> + }
> +
> + inst->state = STATE_ON;
> +
> + /* Initialize the PHY and power it ON */
> + exynos5_usb3phy_init(inst);
I think with the above one, we are deviating from the generic PHY framework.
phy init supposed to be called from actual dwc3 core driver. dwc3
core driver has
phy_ops->init to do this .
@Kishon: Please correct me if i am wrong.
> + exynos5_usb3phy_isol(inst, 0);
> +
> +err0:
> + clk_disable_unprepare(drv->clk);
> +
> + return ret;
> +}
> +
> +static int exynos5_usb3phy_power_off(struct phy *phy)
> +{
> + struct usb3phy_instance *inst = phy_get_drvdata(phy);
> + struct usb3phy_driver *drv = inst->drv;
> + int ret;
> +
> + dev_info(drv->dev, "Request to power_off \"%s\" usb phy\n",
> + inst->label);
> + ret = clk_prepare_enable(drv->clk);
> + if (ret)
> + return ret;
> +
> + if (inst->state == STATE_OFF) {
> + dev_err(drv->dev, "usb phy \"%s\" already off",
> + inst->label);
> + ret = -ENODEV;
> + goto err0;
> + }
> +
> + inst->state = STATE_OFF;
> +
> + /* Power-off the PHY and de-initialize it */
> + exynos5_usb3phy_isol(inst, 1);
> + exynos5_usb3phy_exit(inst);
> +
> +err0:
> + clk_disable_unprepare(drv->clk);
> + if (drv->sclk_usbphy30)
> + clk_disable_unprepare(drv->sclk_usbphy30);
> +
> + return ret;
> +}
> +
> +static struct phy_ops exynos5_usb3phy_ops = {
> + .power_on = exynos5_usb3phy_power_on,
> + .power_off = exynos5_usb3phy_power_off,
> + .owner = THIS_MODULE,
> +};
> +
> +static const struct of_device_id exynos5_usb3phy_of_match[];
> +
> +static int exynos5_usb3phy_probe(struct platform_device *pdev)
> +{
> + struct device *dev = &pdev->dev;
> + struct usb3phy_driver *drv;
> + struct usb3phy_instance *inst;
> + struct phy_provider *phy_provider;
> + struct resource *res;
> + struct clk *clk;
> + const struct of_device_id *match;
> + const struct usb3phy_config *cfg;
> +
> + match = of_match_node(exynos5_usb3phy_of_match, pdev->dev.of_node);
> + if (!match) {
> + dev_err(dev, "of_match_node() failed\n");
> + return -EINVAL;
> + }
> + cfg = match->data;
> + if (!cfg) {
> + dev_err(dev, "Failed to get configuration\n");
> + return -EINVAL;
> + }
> +
> + drv = devm_kzalloc(dev, sizeof(struct usb3phy_driver), GFP_KERNEL);
> + if (!drv) {
> + dev_err(dev, "Failed to allocate memory\n");
> + return -ENOMEM;
> + }
> +
> + dev_set_drvdata(dev, drv);
> + drv->dev = dev;
> +
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + drv->reg_phy = devm_ioremap_resource(dev, res);
> + if (IS_ERR(drv->reg_phy)) {
> + dev_err(dev, "Failed to map register memory (phy)\n");
> + return PTR_ERR(drv->reg_phy);
> + }
> +
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
> + drv->reg_isol = devm_ioremap_resource(dev, res);
> + if (IS_ERR(drv->reg_isol)) {
> + dev_err(dev, "Failed to map register memory (isolation)\n");
> + return PTR_ERR(drv->reg_isol);
> + }
> +
> + phy_provider = devm_of_phy_provider_register(dev, of_phy_simple_xlate);
> + if (IS_ERR(phy_provider)) {
> + dev_err(drv->dev, "Failed to register phy provider\n");
> + return PTR_ERR(phy_provider);
> + }
> +
> + drv->clk = devm_clk_get(dev, "phy");
> + if (IS_ERR(drv->clk)) {
> + dev_err(dev, "Failed to get clock of phy controller\n");
> + return PTR_ERR(drv->clk);
> + }
> +
> + /*
> + * Exysno5420 SoC has an additional special clock, used for
> + * for USB 3.0 PHY operation, this clock goes to the PHY block
> + * as a reference clock to clock generation block of the controller.
> + */
> + if (cfg->has_sclk_usbphy30) {
> + drv->sclk_usbphy30 = devm_clk_get(dev, "sclk_usbphy30");
> + if (IS_ERR(drv->clk)) {
> + dev_err(dev, "Failed to get phy reference clock\n");
> + return PTR_ERR(drv->clk);
> + }
> + }
> +
> + inst = &drv->instance;
> + inst->drv = drv;
> + inst->label = "usb3drd";
> +
> + dev_info(dev, "Creating phy \"%s\"\n", inst->label);
> + inst->phy = devm_phy_create(dev, &exynos5_usb3phy_ops, NULL);
> + if (IS_ERR(inst->phy)) {
> + dev_err(drv->dev, "Failed to create usb3phy \"%s\"\n",
> + inst->label);
> + return PTR_ERR(inst->phy);
> + }
> +
> + phy_set_drvdata(inst->phy, inst);
> +
> + clk = clk_get(dev, inst->label);
> + if (IS_ERR(clk)) {
> + dev_err(dev, "Failed to get clock of \"%s\" phy\n",
> + inst->label);
> + return PTR_ERR(clk);
> + }
> +
> + inst->rate = clk_get_rate(clk);
> +
> + inst->clk = exynos5_rate_to_clk(inst->rate);
> + if (inst->clk == CLKSEL_ERROR) {
> + dev_err(dev, "Clock rate (%ld) not supported\n",
> + inst->rate);
> + clk_put(clk);
> + return -EINVAL;
> + }
> + clk_put(clk);
> +
> + return 0;
> +}
> +
> +const struct usb3phy_config exynos5420_usb3phy_cfg = {
> + .cpu = TYPE_EXYNOS5420,
> + .has_sclk_usbphy30 = true,
> +};
> +
> +const struct usb3phy_config exynos5250_usb3phy_cfg = {
> + .cpu = TYPE_EXYNOS5250,
> + .has_sclk_usbphy30 = false,
> +};
> +
> +static const struct of_device_id exynos5_usb3phy_of_match[] = {
> + {
> + .compatible = "samsung,exynos5250-usb3phy",
> + .data = &exynos5250_usb3phy_cfg
> + }, {
> + .compatible = "samsung,exynos5420-usb3phy",
> + .data = &exynos5420_usb3phy_cfg
> + },
> + { },
> +};
> +
> +static struct platform_driver exynos5_usb3phy_driver = {
> + .probe = exynos5_usb3phy_probe,
> + .driver = {
> + .of_match_table = exynos5_usb3phy_of_match,
> + .name = "exynos5-usb3phy",
> + .owner = THIS_MODULE,
> + }
> +};
> +
> +module_platform_driver(exynos5_usb3phy_driver);
> +MODULE_DESCRIPTION("Samsung EXYNOS5 series SoC USB 3.0 PHY driver");
> +MODULE_AUTHOR("Vivek Gautam <gautam.vivek@samsung.com>");
> +MODULE_LICENSE("GPL v2");
> +MODULE_ALIAS("platform:exynos5-usb3phy");
> --
> 1.7.6.5
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 36+ messages in thread