RE: [PATCH v2 1/4] dwc3: exynos: Add support for SCLK present on Exynos7

2014-10-13 Thread Anton Tikhomirov
Hello,

 Hi Anton,
 
 On 13.10.2014 06:54, Anton Tikhomirov wrote:
  Hi Vivek,
 
  Exynos7 also has a separate special gate clock going to the IP
  apart from the usual AHB clock. So add support for the same.
 
  As we discussed before, Exynos7 SoCs have 7 clocks to be controlled
  by the driver. Adding only sclk is not enough.
 
 
 I'm quite interested in this discussion. Has it happened on mailing
 lists?

No, we used company messenger for the discussion.

 
 In general, previous SoCs also gave the possibility of controlling all
 the bus clocks separately, in addition to bulk gates, but there was no

correct

 real advantage in using those, while burdening the clock tree with
 numerous clocks. Isn't Exynos7 similar in this aspect?

Exynos7 doesn't have Gating all clocks for USBDRD30 bit. The clocks
should be controlled separately.

 
 Best regards,
 Tomasz
 --
 To unsubscribe from this list: send the line unsubscribe linux-usb in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


RE: [PATCH v2 1/4] dwc3: exynos: Add support for SCLK present on Exynos7

2014-10-12 Thread Anton Tikhomirov
Hi Vivek,

 Exynos7 also has a separate special gate clock going to the IP
 apart from the usual AHB clock. So add support for the same.

As we discussed before, Exynos7 SoCs have 7 clocks to be controlled
by the driver. Adding only sclk is not enough. 

 
 Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
 ---
  drivers/usb/dwc3/dwc3-exynos.c |   16 
  1 file changed, 16 insertions(+)
 
 diff --git a/drivers/usb/dwc3/dwc3-exynos.c b/drivers/usb/dwc3/dwc3-
 exynos.c
 index 3951a65..7dc6a98 100644
 --- a/drivers/usb/dwc3/dwc3-exynos.c
 +++ b/drivers/usb/dwc3/dwc3-exynos.c
 @@ -35,6 +35,7 @@ struct dwc3_exynos {
   struct device   *dev;
 
   struct clk  *clk;

The clock clk in Exynos5 just gated all that above 7 clocks, which
we should control separately now in Exynos7.

 + struct clk  *sclk;
   struct regulator*vdd33;
   struct regulator*vdd10;
  };
 @@ -139,10 +140,21 @@ static int dwc3_exynos_probe(struct
 platform_device *pdev)
   return -EINVAL;
   }
 
 + /*
 +  * Exynos7 has a special gate clock going to this IP,
 +  * which in earlier SoCs was probably concealed.
 +  */
 + exynos-sclk = devm_clk_get(dev, usbdrd30_sclk);
 + if (IS_ERR(exynos-sclk)) {
 + dev_info(dev, no sclk specified\n);
 + exynos-sclk = NULL;
 + }
 +
   exynos-dev = dev;
   exynos-clk = clk;
 
   clk_prepare_enable(exynos-clk);
 + clk_prepare_enable(exynos-sclk);
 
   exynos-vdd33 = devm_regulator_get(dev, vdd33);
   if (IS_ERR(exynos-vdd33)) {
 @@ -185,6 +197,7 @@ err4:
  err3:
   regulator_disable(exynos-vdd33);
  err2:
 + clk_disable_unprepare(exynos-sclk);
   clk_disable_unprepare(clk);
   return ret;
  }
 @@ -197,6 +210,7 @@ static int dwc3_exynos_remove(struct
 platform_device *pdev)
   platform_device_unregister(exynos-usb2_phy);
   platform_device_unregister(exynos-usb3_phy);
 
 + clk_disable_unprepare(exynos-sclk);
   clk_disable_unprepare(exynos-clk);
 
   regulator_disable(exynos-vdd33);
 @@ -218,6 +232,7 @@ static int dwc3_exynos_suspend(struct device *dev)
  {
   struct dwc3_exynos *exynos = dev_get_drvdata(dev);
 
 + clk_disable(exynos-sclk);
   clk_disable(exynos-clk);
 
   regulator_disable(exynos-vdd33);
 @@ -243,6 +258,7 @@ static int dwc3_exynos_resume(struct device *dev)
   }
 
   clk_enable(exynos-clk);
 + clk_enable(exynos-sclk);
 
   /* runtime set active to reflect active state. */
   pm_runtime_disable(dev);
 --
 1.7.10.4
 
 --
 To unsubscribe from this list: send the line unsubscribe linux-usb in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


RE: [PATCH v2 2/4] phy: exynos5-usbdrd: Add pipe-clk and utmi-clk support

2014-10-12 Thread Anton Tikhomirov
Hi Vivek,

 Exynos7 SoC has now separate gate control for 125MHz pipe3 phy
 clock, as well as 60MHz utmi phy clock.
 So get the same and control in the phy-exynos5-usbdrd driver.

In case of the PHY the situation is pretty much the same as with
DWC3 core. Here we should control 6 clocks to make Exynos7 USB DRD
PHY working.

By the way, the driver name phy-exynos5-usbdrd.c doesn't imply it
supports Exynos7 :)

 
 Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
 ---
  .../devicetree/bindings/phy/samsung-phy.txt|4 
  drivers/phy/phy-exynos5-usbdrd.c   |   22
 
  2 files changed, 26 insertions(+)
 
 diff --git a/Documentation/devicetree/bindings/phy/samsung-phy.txt
 b/Documentation/devicetree/bindings/phy/samsung-phy.txt
 index 15e0f2c..c2bc9dc 100644
 --- a/Documentation/devicetree/bindings/phy/samsung-phy.txt
 +++ b/Documentation/devicetree/bindings/phy/samsung-phy.txt
 @@ -138,6 +138,10 @@ Required properties:
  PHY operations, associated by phy name. It is used to
  determine bit values for clock settings register.
  For Exynos5420 this is given as 'sclk_usbphy30' in CMU.
 + - optional clocks: Exynos7 SoC has now following additional
 +gate clocks available:
 +- phy_pipe: for PIPE3 phy
 +- phy_utmi: for UTMI+ phy
  - samsung,pmu-syscon: phandle for PMU system controller interface,
 used to
 control pmu registers for power isolation.
  - #phy-cells : from the generic PHY bindings, must be 1;
 diff --git a/drivers/phy/phy-exynos5-usbdrd.c b/drivers/phy/phy-
 exynos5-usbdrd.c
 index f756aca..013ee84 100644
 --- a/drivers/phy/phy-exynos5-usbdrd.c
 +++ b/drivers/phy/phy-exynos5-usbdrd.c
 @@ -148,6 +148,8 @@ struct exynos5_usbdrd_phy_drvdata {
   * @dev: pointer to device instance of this platform device
   * @reg_phy: usb phy controller register memory base
   * @clk: phy clock for register access
 + * @pipeclk: clock for pipe3 phy
 + * @utmiclk: clock for utmi+ phy
   * @drv_data: pointer to SoC level driver data structure
   * @phys[]: array for 'EXYNOS5_DRDPHYS_NUM' number of PHY
   *   instances each with its 'phy' and 'phy_cfg'.
 @@ -161,6 +163,8 @@ struct exynos5_usbdrd_phy {
   struct device *dev;
   void __iomem *reg_phy;
   struct clk *clk;
 + struct clk *pipeclk;
 + struct clk *utmiclk;
   const struct exynos5_usbdrd_phy_drvdata *drv_data;
   struct phy_usb_instance {
   struct phy *phy;
 @@ -446,6 +450,8 @@ static int exynos5_usbdrd_phy_power_on(struct phy
 *phy)
 
   dev_dbg(phy_drd-dev, Request to power_on usbdrd_phy phy\n);
 
 + clk_prepare_enable(phy_drd-utmiclk);
 + clk_prepare_enable(phy_drd-pipeclk);
   clk_prepare_enable(phy_drd-ref_clk);
 
   /* Enable VBUS supply */
 @@ -464,6 +470,8 @@ static int exynos5_usbdrd_phy_power_on(struct phy
 *phy)
 
  fail_vbus:
   clk_disable_unprepare(phy_drd-ref_clk);
 + clk_disable_unprepare(phy_drd-pipeclk);
 + clk_disable_unprepare(phy_drd-utmiclk);
 
   return ret;
  }
 @@ -483,6 +491,8 @@ static int exynos5_usbdrd_phy_power_off(struct phy
 *phy)
   regulator_disable(phy_drd-vbus);
 
   clk_disable_unprepare(phy_drd-ref_clk);
 + clk_disable_unprepare(phy_drd-pipeclk);
 + clk_disable_unprepare(phy_drd-utmiclk);
 
   return 0;
  }
 @@ -582,6 +592,18 @@ static int exynos5_usbdrd_phy_probe(struct
 platform_device *pdev)
   return PTR_ERR(phy_drd-clk);
   }
 
 + phy_drd-pipeclk = devm_clk_get(dev, phy_pipe);
 + if (IS_ERR(phy_drd-pipeclk)) {
 + dev_info(dev, PIPE3 phy operational clock not
 specified\n);
 + phy_drd-pipeclk = NULL;
 + }
 +
 + phy_drd-utmiclk = devm_clk_get(dev, phy_utmi);
 + if (IS_ERR(phy_drd-utmiclk)) {
 + dev_info(dev, UTMI phy operational clock not specified\n);
 + phy_drd-utmiclk = NULL;
 + }
 +
   phy_drd-ref_clk = devm_clk_get(dev, ref);
   if (IS_ERR(phy_drd-ref_clk)) {
   dev_err(dev, Failed to get reference clock of usbdrd
 phy\n);
 --
 1.7.10.4
 
 --
 To unsubscribe from this list: send the line unsubscribe linux-usb in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


RE: [PATCH v2 3/4] phy: exynos5-usbdrd: Add facility for VBUS-BOOST-5V supply

2014-10-12 Thread Anton Tikhomirov
Hi Vivek,

 Some Exynos SoCs have a separate regulator controlling a

I guess you meant the Exynos based *boards* instead of SoCs,
since Exynos SoCs don't have any boost regulators.

 Boost 5V supply which goes as input for VBUS regulator.
 So adding a control for the same in driver, to enable
 vbus supply on the port.
 
 Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
 ---
  drivers/phy/phy-exynos5-usbdrd.c |   30 --
  1 file changed, 28 insertions(+), 2 deletions(-)
 
 diff --git a/drivers/phy/phy-exynos5-usbdrd.c b/drivers/phy/phy-
 exynos5-usbdrd.c
 index 013ee84..57e8a0a 100644
 --- a/drivers/phy/phy-exynos5-usbdrd.c
 +++ b/drivers/phy/phy-exynos5-usbdrd.c
 @@ -176,6 +176,7 @@ struct exynos5_usbdrd_phy {
   u32 extrefclk;
   struct clk *ref_clk;
   struct regulator *vbus;
 + struct regulator *vbus_boost;
  };
 
  static inline
 @@ -455,11 +456,20 @@ static int exynos5_usbdrd_phy_power_on(struct phy
 *phy)
   clk_prepare_enable(phy_drd-ref_clk);
 
   /* Enable VBUS supply */
 + if (phy_drd-vbus_boost) {
 + ret = regulator_enable(phy_drd-vbus_boost);
 + if (ret) {
 + dev_err(phy_drd-dev,
 + Failed to enable VBUS boost supply\n);
 + goto fail_vbus;
 + }
 + }
 +
   if (phy_drd-vbus) {
   ret = regulator_enable(phy_drd-vbus);
   if (ret) {
   dev_err(phy_drd-dev, Failed to enable VBUS
 supply\n);
 - goto fail_vbus;
 + goto fail_vbus_boost;
   }
   }
 
 @@ -468,6 +478,10 @@ static int exynos5_usbdrd_phy_power_on(struct phy
 *phy)
 
   return 0;
 
 +fail_vbus_boost:
 + if (phy_drd-vbus_boost)
 + regulator_disable(phy_drd-vbus_boost);
 +
  fail_vbus:
   clk_disable_unprepare(phy_drd-ref_clk);
   clk_disable_unprepare(phy_drd-pipeclk);
 @@ -489,6 +503,8 @@ static int exynos5_usbdrd_phy_power_off(struct phy
 *phy)
   /* Disable VBUS supply */
   if (phy_drd-vbus)
   regulator_disable(phy_drd-vbus);
 + if (phy_drd-vbus_boost)
 + regulator_disable(phy_drd-vbus_boost);
 
   clk_disable_unprepare(phy_drd-ref_clk);
   clk_disable_unprepare(phy_drd-pipeclk);
 @@ -644,7 +660,7 @@ static int exynos5_usbdrd_phy_probe(struct
 platform_device *pdev)
   break;
   }
 
 - /* Get Vbus regulator */
 + /* Get Vbus regulators */
   phy_drd-vbus = devm_regulator_get(dev, vbus);
   if (IS_ERR(phy_drd-vbus)) {
   ret = PTR_ERR(phy_drd-vbus);
 @@ -655,6 +671,16 @@ static int exynos5_usbdrd_phy_probe(struct
 platform_device *pdev)
   phy_drd-vbus = NULL;
   }
 
 + phy_drd-vbus_boost = devm_regulator_get(dev, vbus-boost);
 + if (IS_ERR(phy_drd-vbus_boost)) {
 + ret = PTR_ERR(phy_drd-vbus_boost);
 + if (ret == -EPROBE_DEFER)
 + return ret;
 +
 + dev_warn(dev, Failed to get VBUS boost supply
 regulator\n);
 + phy_drd-vbus_boost = NULL;
 + }
 +
   dev_vdbg(dev, Creating usbdrd_phy phy\n);
 
   for (i = 0; i  EXYNOS5_DRDPHYS_NUM; i++) {
 --
 1.7.10.4
 
 --
 To unsubscribe from this list: send the line unsubscribe linux-usb in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


RE: [PATCH 3/3] usb: dwc3-exynos: Make provision for vdd regulators

2014-04-23 Thread Anton Tikhomirov
Hi,

 Hi Anton,
 
 
 On Wed, Apr 23, 2014 at 2:56 PM, Anton Tikhomirov
 av.tikhomi...@samsung.com wrote:
  Hello,
 
  -Original Message-
  From: Vivek Gautam [mailto:gautamvivek1...@gmail.com] On Behalf Of
  Vivek Gautam
  Sent: Monday, April 21, 2014 9:17 PM
  To: linux-...@vger.kernel.org; linux-samsung-soc@vger.kernel.org
  Cc: linux-ker...@vger.kernel.org; linux-o...@vger.kernel.org; linux-
  arm-ker...@lists.infradead.org; gre...@linuxfoundation.org;
  st...@rowland.harvard.edu; ba...@ti.com; kgene@samsung.com;
 Vivek
  Gautam; Anton Tikhomirov
  Subject: [PATCH 3/3] usb: dwc3-exynos: Make provision for vdd
  regulators
 
  Facilitate getting required 3.3V and 1.0V VDD supply for
  DWC3 controller on Exynos.
 
  With patches for regulators' nodes merged in 3.15:
  c8c253f ARM: dts: Add regulator entries to smdk5420
  275dcd2 ARM: dts: add max77686 pmic node for smdk5250,
 
  certain perripherals will now need to ensure that,
  they request VDD regulators in their drivers, and enable
  them so as to make them working.
 
  Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
  Cc: Anton Tikhomirov av.tikhomi...@samsung.com
  ---
 
  Based on 'usb-next' branch of Greg's USB tree.
  Also cleanly applies on 'next' branch of Balbi's USB tree.
 
   drivers/usb/dwc3/dwc3-exynos.c |   51
  ++--
   1 file changed, 49 insertions(+), 2 deletions(-)
 
  diff --git a/drivers/usb/dwc3/dwc3-exynos.c b/drivers/usb/dwc3/dwc3-
  exynos.c
  index 28c8ad7..c9d9102 100644
  --- a/drivers/usb/dwc3/dwc3-exynos.c
  +++ b/drivers/usb/dwc3/dwc3-exynos.c
  @@ -27,6 +27,7 @@
   #include linux/usb/usb_phy_gen_xceiv.h
   #include linux/of.h
   #include linux/of_platform.h
  +#include linux/regulator/consumer.h
 
   struct dwc3_exynos {
struct platform_device  *usb2_phy;
  @@ -34,6 +35,8 @@ struct dwc3_exynos {
struct device   *dev;
 
struct clk  *clk;
  + struct regulator*vdd33;
  + struct regulator*vdd10;
   };
 
   static int dwc3_exynos_register_phys(struct dwc3_exynos *exynos)
  @@ -144,20 +147,46 @@ static int dwc3_exynos_probe(struct
  platform_device *pdev)
 
clk_prepare_enable(exynos-clk);
 
  + exynos-vdd33 = devm_regulator_get(dev, vdd33);
  + if (IS_ERR(exynos-vdd33)) {
  + ret = PTR_ERR(exynos-vdd33);
  + goto err2;
 
  Is regulator property mandatory for dwc3-exynos? If it is not
  and device tree doesn't provide it, dwc3-exynos driver probe
 shouldn't
  fail here.
 
 These are the VDD regulators (from PMIC ldo supplies), in absence of
 which the controller will not be powered up.
 So doesn't it make sense to stop the probe when these are not supplied
 by device tree ?

Agree. Just curious, is there special reason for this change except making
things right?


--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


RE: [PATCH 1/3] usb: ohci-exynos: Make provision for vdd regulators

2014-04-23 Thread Anton Tikhomirov
Hi,

 -Original Message-
 From: linux-usb-ow...@vger.kernel.org [mailto:linux-usb-
 ow...@vger.kernel.org] On Behalf Of Vivek Gautam
 Sent: Monday, April 21, 2014 9:17 PM
 
 Facilitate getting required 3.3V and 1.0V VDD supply for
 OHCI controller on Exynos.
 
 With patches for regulators' nodes merged in 3.15:
 c8c253f ARM: dts: Add regulator entries to smdk5420
 275dcd2 ARM: dts: add max77686 pmic node for smdk5250,
 
 certain perripherals will now need to ensure that,
 they request VDD regulators in their drivers, and enable
 them so as to make them working.
 
 Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
 Cc: Jingoo Han jg1@samsung.com
 ---
 
 Based on 'usb-next' branch of Greg's usb tree.
 
  drivers/usb/host/ohci-exynos.c |   47
 
  1 file changed, 47 insertions(+)
 
 diff --git a/drivers/usb/host/ohci-exynos.c b/drivers/usb/host/ohci-
 exynos.c
 index 68588d8..e2e72a8 100644
 --- a/drivers/usb/host/ohci-exynos.c
 +++ b/drivers/usb/host/ohci-exynos.c
 @@ -18,6 +18,7 @@
  #include linux/module.h
  #include linux/of.h
  #include linux/platform_device.h
 +#include linux/regulator/consumer.h
  #include linux/usb/phy.h
  #include linux/usb/samsung_usb_phy.h
  #include linux/usb.h
 @@ -37,6 +38,8 @@ struct exynos_ohci_hcd {
   struct clk *clk;
   struct usb_phy *phy;
   struct usb_otg *otg;
 + struct regulator *vdd33;
 + struct regulator *vdd10;
  };
 
  static void exynos_ohci_phy_enable(struct platform_device *pdev)
 @@ -98,6 +101,28 @@ static int exynos_ohci_probe(struct platform_device
 *pdev)
   exynos_ohci-otg = phy-otg;
   }
 
 + exynos_ohci-vdd33 = devm_regulator_get(pdev-dev, vdd33);
 + if (IS_ERR(exynos_ohci-vdd33)) {
 + err = PTR_ERR(exynos_ohci-vdd33);
 + goto fail_regulator1;
 + }
 + err = regulator_enable(exynos_ohci-vdd33);
 + if (err) {
 + dev_err(pdev-dev, Failed to enable VDD33 supply\n);
 + goto fail_regulator1;
 + }
 +
 + exynos_ohci-vdd10 = devm_regulator_get(pdev-dev, vdd10);
 + if (IS_ERR(exynos_ohci-vdd10)) {
 + err = PTR_ERR(exynos_ohci-vdd10);
 + goto fail_regulator2;
 + }
 + err = regulator_enable(exynos_ohci-vdd10);
 + if (err) {
 + dev_err(pdev-dev, Failed to enable VDD10 supply\n);
 + goto fail_regulator2;
 + }
 +

Do we need to skip regulator settings together with PHY configuration
in case of exynos5440?

  skip_phy:
   exynos_ohci-clk = devm_clk_get(pdev-dev, usbhost);
 
 @@ -154,6 +179,10 @@ fail_add_hcd:
  fail_io:
   clk_disable_unprepare(exynos_ohci-clk);
  fail_clk:
 + regulator_disable(exynos_ohci-vdd10);
 +fail_regulator2:
 + regulator_disable(exynos_ohci-vdd33);
 +fail_regulator1:
   usb_put_hcd(hcd);
   return err;
  }
 @@ -172,6 +201,9 @@ static int exynos_ohci_remove(struct
 platform_device *pdev)
 
   clk_disable_unprepare(exynos_ohci-clk);
 
 + regulator_disable(exynos_ohci-vdd10);
 + regulator_disable(exynos_ohci-vdd33);
 +
   usb_put_hcd(hcd);
 
   return 0;
 @@ -208,6 +240,9 @@ static int exynos_ohci_suspend(struct device *dev)
 
   clk_disable_unprepare(exynos_ohci-clk);
 
 + regulator_disable(exynos_ohci-vdd10);
 + regulator_disable(exynos_ohci-vdd33);
 +
   spin_unlock_irqrestore(ohci-lock, flags);
 
   return 0;
 @@ -218,6 +253,18 @@ static int exynos_ohci_resume(struct device *dev)
   struct usb_hcd *hcd = dev_get_drvdata(dev);
   struct exynos_ohci_hcd *exynos_ohci = to_exynos_ohci(hcd);
   struct platform_device *pdev= to_platform_device(dev);
 + int ret;
 +
 + ret = regulator_enable(exynos_ohci-vdd33);
 + if (ret) {
 + dev_err(dev, Failed to enable VDD33 supply\n);
 + return ret;

Not sure, but shall we continue resuming and do everything
we can in case of error? At least it will avoid
WARN_ON(clk-enable_count == 0) on next system suspend.

 + }
 + ret = regulator_enable(exynos_ohci-vdd10);
 + if (ret) {
 + dev_err(dev, Failed to enable VDD10 supply\n);
 + return ret;
 + }
 
   clk_prepare_enable(exynos_ohci-clk);
 
 --

Thanks

--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


RE: [PATCH 1/3] usb: ohci-exynos: Make provision for vdd regulators

2014-04-23 Thread Anton Tikhomirov
Hi,

 Hi,
 
  -Original Message-
  From: linux-usb-ow...@vger.kernel.org [mailto:linux-usb-
  ow...@vger.kernel.org] On Behalf Of Vivek Gautam
  Sent: Monday, April 21, 2014 9:17 PM
 
  Facilitate getting required 3.3V and 1.0V VDD supply for
  OHCI controller on Exynos.
 
  With patches for regulators' nodes merged in 3.15:
  c8c253f ARM: dts: Add regulator entries to smdk5420
  275dcd2 ARM: dts: add max77686 pmic node for smdk5250,
 
  certain perripherals will now need to ensure that,
  they request VDD regulators in their drivers, and enable
  them so as to make them working.
 
  Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
  Cc: Jingoo Han jg1@samsung.com
  ---
 
  Based on 'usb-next' branch of Greg's usb tree.
 
   drivers/usb/host/ohci-exynos.c |   47
  
   1 file changed, 47 insertions(+)
 
  diff --git a/drivers/usb/host/ohci-exynos.c b/drivers/usb/host/ohci-
  exynos.c
  index 68588d8..e2e72a8 100644
  --- a/drivers/usb/host/ohci-exynos.c
  +++ b/drivers/usb/host/ohci-exynos.c
  @@ -18,6 +18,7 @@
   #include linux/module.h
   #include linux/of.h
   #include linux/platform_device.h
  +#include linux/regulator/consumer.h
   #include linux/usb/phy.h
   #include linux/usb/samsung_usb_phy.h
   #include linux/usb.h
  @@ -37,6 +38,8 @@ struct exynos_ohci_hcd {
  struct clk *clk;
  struct usb_phy *phy;
  struct usb_otg *otg;
  +   struct regulator *vdd33;
  +   struct regulator *vdd10;
   };
 
   static void exynos_ohci_phy_enable(struct platform_device *pdev)
  @@ -98,6 +101,28 @@ static int exynos_ohci_probe(struct
 platform_device
  *pdev)
  exynos_ohci-otg = phy-otg;
  }
 
  +   exynos_ohci-vdd33 = devm_regulator_get(pdev-dev, vdd33);
  +   if (IS_ERR(exynos_ohci-vdd33)) {
  +   err = PTR_ERR(exynos_ohci-vdd33);
  +   goto fail_regulator1;
  +   }
  +   err = regulator_enable(exynos_ohci-vdd33);
  +   if (err) {
  +   dev_err(pdev-dev, Failed to enable VDD33 supply\n);
  +   goto fail_regulator1;
  +   }
  +
  +   exynos_ohci-vdd10 = devm_regulator_get(pdev-dev, vdd10);
  +   if (IS_ERR(exynos_ohci-vdd10)) {
  +   err = PTR_ERR(exynos_ohci-vdd10);
  +   goto fail_regulator2;
  +   }
  +   err = regulator_enable(exynos_ohci-vdd10);
  +   if (err) {
  +   dev_err(pdev-dev, Failed to enable VDD10 supply\n);
  +   goto fail_regulator2;
  +   }
  +
 
 Do we need to skip regulator settings together with PHY configuration
 in case of exynos5440?
 
   skip_phy:
  exynos_ohci-clk = devm_clk_get(pdev-dev, usbhost);
 
  @@ -154,6 +179,10 @@ fail_add_hcd:
   fail_io:
  clk_disable_unprepare(exynos_ohci-clk);
   fail_clk:
  +   regulator_disable(exynos_ohci-vdd10);
  +fail_regulator2:
  +   regulator_disable(exynos_ohci-vdd33);
  +fail_regulator1:
  usb_put_hcd(hcd);
  return err;
   }
  @@ -172,6 +201,9 @@ static int exynos_ohci_remove(struct
  platform_device *pdev)
 
  clk_disable_unprepare(exynos_ohci-clk);
 
  +   regulator_disable(exynos_ohci-vdd10);
  +   regulator_disable(exynos_ohci-vdd33);
  +
  usb_put_hcd(hcd);
 
  return 0;
  @@ -208,6 +240,9 @@ static int exynos_ohci_suspend(struct device *dev)
 
  clk_disable_unprepare(exynos_ohci-clk);
 
  +   regulator_disable(exynos_ohci-vdd10);
  +   regulator_disable(exynos_ohci-vdd33);
  +
  spin_unlock_irqrestore(ohci-lock, flags);
 
  return 0;
  @@ -218,6 +253,18 @@ static int exynos_ohci_resume(struct device *dev)
  struct usb_hcd *hcd = dev_get_drvdata(dev);
  struct exynos_ohci_hcd *exynos_ohci = to_exynos_ohci(hcd);
  struct platform_device *pdev= to_platform_device(dev);
  +   int ret;
  +
  +   ret = regulator_enable(exynos_ohci-vdd33);
  +   if (ret) {
  +   dev_err(dev, Failed to enable VDD33 supply\n);
  +   return ret;
 
 Not sure, but shall we continue resuming and do everything
 we can in case of error? At least it will avoid
 WARN_ON(clk-enable_count == 0) on next system suspend.

On the other hand, if power is not applied to the controller,
register access in ohci_resume() may lead to undefined behavior.
What's your opinion?

 
  +   }
  +   ret = regulator_enable(exynos_ohci-vdd10);
  +   if (ret) {
  +   dev_err(dev, Failed to enable VDD10 supply\n);
  +   return ret;
  +   }
 
  clk_prepare_enable(exynos_ohci-clk);
 
  --
 
 Thanks

Thanks

--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


RE: [PATCH v9 3/4] phy: Add new Exynos USB 2.0 PHY driver

2014-03-06 Thread Anton Tikhomirov
Hi Kamil,

...

 +| 3. Supporting SoCs
 ++
 +
 +To support a new SoC a new file should be added to the drivers/phy
 +directory. Each SoC's configuration is stored in an instance of the
 +struct samsung_usb2_phy_config.
 +
 +struct samsung_usb2_phy_config {
 + const struct samsung_usb2_common_phy *phys;
 + unsigned int num_phys;
 + bool has_mode_switch;

You missed rate_to_clk here.

 +};
 +

...

 diff --git a/drivers/phy/phy-samsung-usb2.c b/drivers/phy/phy-samsung-
 usb2.c
 new file mode 100644
 index 000..c3b7719
 --- /dev/null
 +++ b/drivers/phy/phy-samsung-usb2.c
 @@ -0,0 +1,222 @@
 +/*
 + * Samsung SoC USB 1.1/2.0 PHY driver
 + *
 + * Copyright (C) 2013 Samsung Electronics Co., Ltd.
 + * Author: Kamil Debski k.deb...@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/mfd/syscon.h
 +#include linux/module.h
 +#include linux/of.h
 +#include linux/of_address.h
 +#include linux/phy/phy.h
 +#include linux/platform_device.h
 +#include linux/spinlock.h
 +#include phy-samsung-usb2.h
 +
 +static int samsung_usb2_phy_power_on(struct phy *phy)
 +{
 + struct samsung_usb2_phy_instance *inst = phy_get_drvdata(phy);
 + struct samsung_usb2_phy_driver *drv = inst-drv;
 + int ret;
 +
 + dev_dbg(drv-dev, Request to power_on \%s\ usb phy\n,
 + inst-cfg-label);
 + ret = clk_prepare_enable(drv-clk);

clk_prepare_enable() can sleep, and therefore doesn't allow
samusng_usb2_phy_power_on() to be used in atomic context
(e.g. inside spin_lock-ed area), what sometimes may be desirable.
What about to prepare clock in probe, and just enable it here
(note: clk_enable() doesn't sleep).

 + if (ret)
 + goto err_main_clk;
 + ret = clk_prepare_enable(drv-ref_clk);
 + if (ret)
 + goto err_instance_clk;
 + if (inst-cfg-power_on) {
 + spin_lock(drv-lock);
 + ret = inst-cfg-power_on(inst);
 + spin_unlock(drv-lock);
 + }
 +
 + return 0;

Thank you

--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


RE: [PATCH v9 3/4] phy: Add new Exynos USB 2.0 PHY driver

2014-03-06 Thread Anton Tikhomirov
Hello,

 Subject: Re: [PATCH v9 3/4] phy: Add new Exynos USB 2.0 PHY driver
 
 
 
 On Thursday 06 March 2014 01:56 PM, Anton Tikhomirov wrote:
  Hi Kamil,
 
  ...
 
  +| 3. Supporting SoCs
  ++
  +
  +To support a new SoC a new file should be added to the drivers/phy
  +directory. Each SoC's configuration is stored in an instance of the
  +struct samsung_usb2_phy_config.
  +
  +struct samsung_usb2_phy_config {
  +  const struct samsung_usb2_common_phy *phys;
  +  unsigned int num_phys;
  +  bool has_mode_switch;
 
  You missed rate_to_clk here.
 
  +};
  +
 
  ...
 
  diff --git a/drivers/phy/phy-samsung-usb2.c b/drivers/phy/phy-
 samsung-
  usb2.c
  new file mode 100644
  index 000..c3b7719
  --- /dev/null
  +++ b/drivers/phy/phy-samsung-usb2.c
  @@ -0,0 +1,222 @@
  +/*
  + * Samsung SoC USB 1.1/2.0 PHY driver
  + *
  + * Copyright (C) 2013 Samsung Electronics Co., Ltd.
  + * Author: Kamil Debski k.deb...@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/mfd/syscon.h
  +#include linux/module.h
  +#include linux/of.h
  +#include linux/of_address.h
  +#include linux/phy/phy.h
  +#include linux/platform_device.h
  +#include linux/spinlock.h
  +#include phy-samsung-usb2.h
  +
  +static int samsung_usb2_phy_power_on(struct phy *phy)
  +{
  +  struct samsung_usb2_phy_instance *inst = phy_get_drvdata(phy);
  +  struct samsung_usb2_phy_driver *drv = inst-drv;
  +  int ret;
  +
  +  dev_dbg(drv-dev, Request to power_on \%s\ usb phy\n,
  +  inst-cfg-label);
  +  ret = clk_prepare_enable(drv-clk);
 
  clk_prepare_enable() can sleep, and therefore doesn't allow
  samusng_usb2_phy_power_on() to be used in atomic context
  (e.g. inside spin_lock-ed area), what sometimes may be desirable.
  What about to prepare clock in probe, and just enable it here
  (note: clk_enable() doesn't sleep).
 
 The PHY power-on callback is anyway called with mutex held, so I guess
 it's fine to have clk_prepare_enable() here.

If we rely totally on generic PHY functions such as phy_power_on()
and friends, why do we need to use locking in callbacks at all.

 
 Thanks
 Kishon

--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


RE: [PATCH v9 3/4] phy: Add new Exynos USB 2.0 PHY driver

2014-03-06 Thread Anton Tikhomirov
Hi,

 Subject: RE: [PATCH v9 3/4] phy: Add new Exynos USB 2.0 PHY driver
 
 Hi,
 
  Subject: Re: [PATCH v9 3/4] phy: Add new Exynos USB 2.0 PHY driver
 
  Hi,
 
  On Thursday 06 March 2014 02:22 PM, Anton Tikhomirov wrote:
   Hello,
  
   Subject: Re: [PATCH v9 3/4] phy: Add new Exynos USB 2.0 PHY driver
  
  
  
   On Thursday 06 March 2014 01:56 PM, Anton Tikhomirov wrote:
   Hi Kamil,
  
   ...
  
   +| 3. Supporting SoCs
   ++
   +
   +To support a new SoC a new file should be added to the
  drivers/phy
   +directory. Each SoC's configuration is stored in an instance of
  the
   +struct samsung_usb2_phy_config.
   +
   +struct samsung_usb2_phy_config {
   +  const struct samsung_usb2_common_phy *phys;
   +  unsigned int num_phys;
   +  bool has_mode_switch;
  
   You missed rate_to_clk here.
  
   +};
   +
  
   ...
  
   diff --git a/drivers/phy/phy-samsung-usb2.c b/drivers/phy/phy-
   samsung-
   usb2.c
   new file mode 100644
   index 000..c3b7719
   --- /dev/null
   +++ b/drivers/phy/phy-samsung-usb2.c
   @@ -0,0 +1,222 @@
   +/*
   + * Samsung SoC USB 1.1/2.0 PHY driver
   + *
   + * Copyright (C) 2013 Samsung Electronics Co., Ltd.
   + * Author: Kamil Debski k.deb...@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/mfd/syscon.h
   +#include linux/module.h
   +#include linux/of.h
   +#include linux/of_address.h
   +#include linux/phy/phy.h
   +#include linux/platform_device.h
   +#include linux/spinlock.h
   +#include phy-samsung-usb2.h
   +
   +static int samsung_usb2_phy_power_on(struct phy *phy)
   +{
   +  struct samsung_usb2_phy_instance *inst =
  phy_get_drvdata(phy);
   +  struct samsung_usb2_phy_driver *drv = inst-drv;
   +  int ret;
   +
   +  dev_dbg(drv-dev, Request to power_on \%s\ usb phy\n,
   +  inst-cfg-label);
   +  ret = clk_prepare_enable(drv-clk);
  
   clk_prepare_enable() can sleep, and therefore doesn't allow
   samusng_usb2_phy_power_on() to be used in atomic context
   (e.g. inside spin_lock-ed area), what sometimes may be desirable.
   What about to prepare clock in probe, and just enable it here
   (note: clk_enable() doesn't sleep).
  
   The PHY power-on callback is anyway called with mutex held, so I
  guess
   it's fine to have clk_prepare_enable() here.
  
   If we rely totally on generic PHY functions such as phy_power_on()
   and friends, why do we need to use locking in callbacks at all.
 
  Didn't get you.. We don't want to invoke power_on when init is
 getting
  executed or you don't want power on or power off to get executed
  simultaneously right? So we need to protect it.
 
 I mean callbacks such as samsung_usb2_phy_power_on() which uses
 spin_lock.
 It's already protected by mutex in phy_power_on().

Well... phy_power_on() uses mutex to protect power_on() callback.
power_on() is samsung_usb2_phy_power_on() in our case.
samsung_usb2_phy_power_on() uses spinlock.
My question is why do we need to use spinlock _inside_ callback
if it is already protected by mutex.



--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


RE: [PATCH v9 3/4] phy: Add new Exynos USB 2.0 PHY driver

2014-03-06 Thread Anton Tikhomirov
Hi,

 Subject: Re: [PATCH v9 3/4] phy: Add new Exynos USB 2.0 PHY driver
 
 Hi,
 
 On Thursday 06 March 2014 02:49 PM, Anton Tikhomirov wrote:
  Hi,
 
  Subject: RE: [PATCH v9 3/4] phy: Add new Exynos USB 2.0 PHY driver
 
  Hi,
 
  Subject: Re: [PATCH v9 3/4] phy: Add new Exynos USB 2.0 PHY driver
 
  Hi,
 
  On Thursday 06 March 2014 02:22 PM, Anton Tikhomirov wrote:
  Hello,
 
  Subject: Re: [PATCH v9 3/4] phy: Add new Exynos USB 2.0 PHY
 driver
 
 
 
  On Thursday 06 March 2014 01:56 PM, Anton Tikhomirov wrote:
  Hi Kamil,
 
  ...
 
  +| 3. Supporting SoCs
  ++
  +
  +To support a new SoC a new file should be added to the
  drivers/phy
  +directory. Each SoC's configuration is stored in an instance
 of
  the
  +struct samsung_usb2_phy_config.
  +
  +struct samsung_usb2_phy_config {
  + const struct samsung_usb2_common_phy *phys;
  + unsigned int num_phys;
  + bool has_mode_switch;
 
  You missed rate_to_clk here.
 
  +};
  +
 
  ...
 
  diff --git a/drivers/phy/phy-samsung-usb2.c b/drivers/phy/phy-
  samsung-
  usb2.c
  new file mode 100644
  index 000..c3b7719
  --- /dev/null
  +++ b/drivers/phy/phy-samsung-usb2.c
  @@ -0,0 +1,222 @@
  +/*
  + * Samsung SoC USB 1.1/2.0 PHY driver
  + *
  + * Copyright (C) 2013 Samsung Electronics Co., Ltd.
  + * Author: Kamil Debski k.deb...@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/mfd/syscon.h
  +#include linux/module.h
  +#include linux/of.h
  +#include linux/of_address.h
  +#include linux/phy/phy.h
  +#include linux/platform_device.h
  +#include linux/spinlock.h
  +#include phy-samsung-usb2.h
  +
  +static int samsung_usb2_phy_power_on(struct phy *phy)
  +{
  + struct samsung_usb2_phy_instance *inst =
  phy_get_drvdata(phy);
  + struct samsung_usb2_phy_driver *drv = inst-drv;
  + int ret;
  +
  + dev_dbg(drv-dev, Request to power_on \%s\ usb phy\n,
  + inst-cfg-label);
  + ret = clk_prepare_enable(drv-clk);
 
  clk_prepare_enable() can sleep, and therefore doesn't allow
  samusng_usb2_phy_power_on() to be used in atomic context
  (e.g. inside spin_lock-ed area), what sometimes may be desirable.
  What about to prepare clock in probe, and just enable it here
  (note: clk_enable() doesn't sleep).
 
  The PHY power-on callback is anyway called with mutex held, so I
  guess
  it's fine to have clk_prepare_enable() here.
 
  If we rely totally on generic PHY functions such as phy_power_on()
  and friends, why do we need to use locking in callbacks at all.
 
  Didn't get you.. We don't want to invoke power_on when init is
  getting
  executed or you don't want power on or power off to get executed
  simultaneously right? So we need to protect it.
 
  I mean callbacks such as samsung_usb2_phy_power_on() which uses
  spin_lock.
  It's already protected by mutex in phy_power_on().
 
  Well... phy_power_on() uses mutex to protect power_on() callback.
  power_on() is samsung_usb2_phy_power_on() in our case.
  samsung_usb2_phy_power_on() uses spinlock.
  My question is why do we need to use spinlock _inside_ callback
  if it is already protected by mutex.
 
 It is needed when the same PHY provider implements multiple PHYs.
 phy-core can protect phy-ops of same PHY. However if the PHY provider
 implements multiple PHYs, phy-core won't be able to protect.

Thank you Kishon. Now it's clear.

--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


RE: [PATCH v4 3/9] phy: Add new Exynos USB PHY driver

2013-12-17 Thread Anton Tikhomirov
Hi Kamil,

 Hi Anton,
 
  From: Anton Tikhomirov [mailto:av.tikhomi...@samsung.com]
  Sent: Tuesday, December 10, 2013 3:43 AM
 
  Hi Kamil,
 
  Same USB2.0 PHY may be used by several HCDs, for example EHCI and
 OHCI.
  Consider the situation, when EHCI stops using the PHY and calls
  power_off, then OHCI becomes non-operational. In other words, PHY
  power_on and power_off calls must be balanced.
 
  Shall we handle it in your driver? (usage count?)
 
 Please look in the drivers/phy/phy-core.c file. Usage count is handled
 there - see phy_power_on and phy_power_off functions. I understand that
 after both EHCI and OHCI power on the phy, the usage count is 2. So
 powering off one of them (EHCI for instance) the usage count is still
 1, so the OHCI should still work properly.

Oops, sorry, missed that.

 
 [snip]
 
 Best wishes,
 --
 Kamil Debski
 Samsung RD Institute Poland

--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


RE: [PATCH 7/7] usb: dwc3: exynos: add pm_runtime support

2013-12-15 Thread Anton Tikhomirov
Hi Felipe,

 On Fri, Dec 13, 2013 at 02:01:32PM +0900, Anton Tikhomirov wrote:
  Hi Felipe,
 
   -static int dwc3_exynos_suspend(struct device *dev)
   +static int __dwc3_exynos_suspend(struct dwc3_exynos *exynos)
{
   - struct dwc3_exynos *exynos = dev_get_drvdata(dev);
   -
 clk_disable(exynos-clk);
  
 return 0;
}
  
   +static int __dwc3_exynos_resume(struct dwc3_exynos *exynos)
   +{
   + return clk_enable(exynos-clk);
   +}
   +
   +static int dwc3_exynos_suspend(struct device *dev)
   +{
   + struct dwc3_exynos *exynos = dev_get_drvdata(dev);
   +
   + return __dwc3_exynos_suspend(exynos);
 
  If dwc3-exynos is runtime suspended, the clock will be disabled
  second time here (unbalanced clk_enable/clk_disable).
 
 I don't get what you mean but there is something that probably needs
 fixing, I guess below makes it better:
 
 diff --git a/drivers/usb/dwc3/dwc3-exynos.c b/drivers/usb/dwc3/dwc3-
 exynos.c
 index c93919a..1e5720a 100644
 --- a/drivers/usb/dwc3/dwc3-exynos.c
 +++ b/drivers/usb/dwc3/dwc3-exynos.c
 @@ -218,6 +218,9 @@ static int dwc3_exynos_suspend(struct device *dev)
  {
   struct dwc3_exynos *exynos = dev_get_drvdata(dev);
 
 + if (pm_runtime_suspended(dev))
 + return 0;
 +
   return __dwc3_exynos_suspend(exynos);
  }
 
 
 Is that what you meant ?

Yes, this is exactly what I meant.

Thanks.

--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


RE: [PATCH 7/7] usb: dwc3: exynos: add pm_runtime support

2013-12-15 Thread Anton Tikhomirov
Hi Felipe,

 On Fri, Dec 13, 2013 at 01:56:18PM -0600, Felipe Balbi wrote:
  On Fri, Dec 13, 2013 at 02:01:32PM +0900, Anton Tikhomirov wrote:
   Hi Felipe,
  
-static int dwc3_exynos_suspend(struct device *dev)
+static int __dwc3_exynos_suspend(struct dwc3_exynos *exynos)
 {
-   struct dwc3_exynos *exynos = dev_get_drvdata(dev);
-
clk_disable(exynos-clk);
   
return 0;
 }
   
+static int __dwc3_exynos_resume(struct dwc3_exynos *exynos)
+{
+   return clk_enable(exynos-clk);
+}
+
+static int dwc3_exynos_suspend(struct device *dev)
+{
+   struct dwc3_exynos *exynos = dev_get_drvdata(dev);
+
+   return __dwc3_exynos_suspend(exynos);
  
   If dwc3-exynos is runtime suspended, the clock will be disabled
   second time here (unbalanced clk_enable/clk_disable).
 
  I don't get what you mean but there is something that probably needs
  fixing, I guess below makes it better:
 
  diff --git a/drivers/usb/dwc3/dwc3-exynos.c b/drivers/usb/dwc3/dwc3-
 exynos.c
  index c93919a..1e5720a 100644
  --- a/drivers/usb/dwc3/dwc3-exynos.c
  +++ b/drivers/usb/dwc3/dwc3-exynos.c
  @@ -218,6 +218,9 @@ static int dwc3_exynos_suspend(struct device *dev)
   {
  struct dwc3_exynos *exynos = dev_get_drvdata(dev);
 
  +   if (pm_runtime_suspended(dev))
  +   return 0;
  +
  return __dwc3_exynos_suspend(exynos);
   }
 
 
  Is that what you meant ?
 
 note, however, that this is *not* a case where we would fall today. See
 that we pm_runtime_get() in probe and only pm_runtime_put() during
 remove. So there would never be a case where we would try system
 suspend 
 while device was already runtime suspended.

You are right, while runtime PM is blocked by get_sync() in probe, this
check
doesn't matter.

 
 I have fixed all patches in my testing/next branch anyway, just to make
 sure we're idiot-proof when it comes to implementing real runtime pm
 later on :-)
 
 cheers
 
 --
 balbi

Thank you

--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


RE: [PATCH 7/7] usb: dwc3: exynos: add pm_runtime support

2013-12-12 Thread Anton Tikhomirov
Hi Felipe,

 -static int dwc3_exynos_suspend(struct device *dev)
 +static int __dwc3_exynos_suspend(struct dwc3_exynos *exynos)
  {
 - struct dwc3_exynos *exynos = dev_get_drvdata(dev);
 -
   clk_disable(exynos-clk);
 
   return 0;
  }
 
 +static int __dwc3_exynos_resume(struct dwc3_exynos *exynos)
 +{
 + return clk_enable(exynos-clk);
 +}
 +
 +static int dwc3_exynos_suspend(struct device *dev)
 +{
 + struct dwc3_exynos *exynos = dev_get_drvdata(dev);
 +
 + return __dwc3_exynos_suspend(exynos);

If dwc3-exynos is runtime suspended, the clock will be disabled
second time here (unbalanced clk_enable/clk_disable).

 +}
 +
  static int dwc3_exynos_resume(struct device *dev)
  {
   struct dwc3_exynos *exynos = dev_get_drvdata(dev);
 + int ret;
 
 - clk_enable(exynos-clk);
 + ret = __dwc3_exynos_resume(exynos);
 + if (ret)
 + return ret;
 
   /* runtime set active to reflect active state. */
   pm_runtime_disable(dev);
 @@ -207,8 +238,24 @@ static int dwc3_exynos_resume(struct device *dev)
   return 0;
  }
 
 +static int dwc3_exynos_runtime_suspend(struct device *dev)
 +{
 + struct dwc3_exynos *exynos = dev_get_drvdata(dev);
 +
 + return __dwc3_exynos_suspend(exynos);
 +}
 +
 +static int dwc3_exynos_runtime_resume(struct device *dev)
 +{
 + struct dwc3_exynos *exynos = dev_get_drvdata(dev);
 +
 + return __dwc3_exynos_resume(exynos);
 +}

Thanks

--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


RE: [PATCH v4 3/9] phy: Add new Exynos USB PHY driver

2013-12-09 Thread Anton Tikhomirov
Hi Kamil,

Same USB2.0 PHY may be used by several HCDs, for example EHCI and OHCI.
Consider the situation, when EHCI stops using the PHY and calls power_off,
then OHCI becomes non-operational. In other words, PHY power_on and
power_off calls must be balanced. 

Shall we handle it in your driver? (usage count?)

 Add a new driver for the Exynos USB PHY. The new driver uses the
 generic
 PHY framework. The driver includes support for the Exynos 4x10 and 4x12
 SoC families.
 
 Signed-off-by: Kamil Debski k.deb...@samsung.com
 Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
 ---
  .../devicetree/bindings/phy/samsung-usbphy.txt |   54 
  drivers/phy/Kconfig|   20 ++
  drivers/phy/Makefile   |3 +
  drivers/phy/phy-exynos4210-usb2.c  |  264
 +
  drivers/phy/phy-exynos4212-usb2.c  |  312
 
  drivers/phy/phy-samsung-usb2.c |  228
 ++
  drivers/phy/phy-samsung-usb2.h |   72 +
  7 files changed, 953 insertions(+)
  create mode 100644 Documentation/devicetree/bindings/phy/samsung-
 usbphy.txt
  create mode 100644 drivers/phy/phy-exynos4210-usb2.c
  create mode 100644 drivers/phy/phy-exynos4212-usb2.c
  create mode 100644 drivers/phy/phy-samsung-usb2.c
  create mode 100644 drivers/phy/phy-samsung-usb2.h
 
 diff --git a/Documentation/devicetree/bindings/phy/samsung-usbphy.txt
 b/Documentation/devicetree/bindings/phy/samsung-usbphy.txt
 new file mode 100644
 index 000..cadbf70
 --- /dev/null
 +++ b/Documentation/devicetree/bindings/phy/samsung-usbphy.txt
 @@ -0,0 +1,54 @@
 +Samsung S5P/EXYNOS SoC series USB PHY
 +-
 +
 +Required properties:
 +- compatible : should be one of the listed compatibles:
 + - samsung,exynos4210-usb2-phy
 + - samsung,exynos4212-usb2-phy
 +- reg : a list of registers used by phy driver
 + - first and obligatory is the location of phy modules registers
 +- samsung,sysreg-phandle - handle to syscon used to control the system
 registers
 +- samsung,pmureg-phandle - handle to syscon used to control PMU
 registers
 +- #phy-cells : from the generic phy bindings, must be 1;
 +- clocks and clock-names:
 + - the phy clocks is required by the phy module
 + - next for each of the phys a clock has to be assidned, this
 clock
 +   will be used to determine clocking frequency for the phys
 +   (the labels are specified in the paragraph below)
 +
 +The first phandle argument in the PHY specifier identifies the PHY,
 its
 +meaning is compatible dependent. For the currently supported SoCs
 (Exynos 4210
 +and Exynos 4212) it is as follows:
 +  0 - USB device (device),
 +  1 - USB host (host),
 +  2 - HSIC0 (hsic0),
 +  3 - HSIC1 (hsic1),
 +
 +Exynos 4210 and Exynos 4212 use mode switching and require that mode
 switch
 +register is supplied.
 +
 +Example:
 +
 +For Exynos 4412 (compatible with Exynos 4212):
 +
 +usbphy: phy@125B {
 + compatible = samsung,exynos4212-usb2-phy;
 + reg = 0x125B 0x100 0x10020704 0x0c 0x1001021c 0x4;
 + clocks = clock 305, clock 2, clock 2, clock 2,
 + clock 2;
 + clock-names = phy, device, host, hsic0, hsic1;
 + status = okay;
 + #phy-cells = 1;
 + samsung,sysreg-phandle = sys_reg;
 + samsung,pmureg-phandle = pmu_reg;
 +};
 +
 +Then the PHY can be used in other nodes such as:
 +
 +phy-consumer@1234 {
 + phys = usbphy 2;
 + phy-names = phy;
 +};
 +
 +Refer to DT bindings documentation of particular PHY consumer devices
 for more
 +information about required PHYs and the way of specification.
 diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
 index a344f3d..b29018f 100644
 --- a/drivers/phy/Kconfig
 +++ b/drivers/phy/Kconfig
 @@ -51,4 +51,24 @@ config PHY_EXYNOS_DP_VIDEO
   help
 Support for Display Port PHY found on Samsung EXYNOS SoCs.
 
 +config PHY_SAMSUNG_USB2
 + tristate Samsung USB 2.0 PHY driver
 + help
 +   Enable this to support Samsung USB phy helper driver for
 Samsung SoCs.
 +   This driver provides common interface to interact, for Samsung
 +   USB 2.0 PHY driver.
 +
 +config PHY_EXYNOS4210_USB2
 + bool Support for Exynos 4210
 + depends on PHY_SAMSUNG_USB2
 + depends on CPU_EXYNOS4210
 + help
 +   Enable USB PHY support for Exynos 4210
 +
 +config PHY_EXYNOS4212_USB2
 + bool Support for Exynos 4212
 + depends on PHY_SAMSUNG_USB2
 + depends on (SOC_EXYNOS4212 || SOC_EXYNOS4412)
 + help
 +   Enable USB PHY support for Exynos 4212
  endmenu
 diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
 index d0caae9..9f4befd 100644
 --- a/drivers/phy/Makefile
 +++ b/drivers/phy/Makefile
 @@ -7,3 +7,6 @@ obj-$(CONFIG_PHY_EXYNOS_DP_VIDEO) += phy-exynos-dp-
 video.o
  obj-$(CONFIG_PHY_EXYNOS_MIPI_VIDEO)  += 

RE: [PATCH v3 4/5] ARM: S3C64XX: Enabling samsung-usbphy driver

2012-08-10 Thread Anton Tikhomirov
Hi Praveen,

 -Original Message-
 From: linux-usb-ow...@vger.kernel.org [mailto:linux-usb-
 ow...@vger.kernel.org] On Behalf Of Praveen Paneri
 Sent: Wednesday, August 08, 2012 4:41 PM
 To: linux-...@vger.kernel.org
 Cc: devicetree-disc...@lists.ozlabs.org; linux-arm-
 ker...@lists.infradead.org; linux-samsung-soc@vger.kernel.org;
 kgene@samsung.com; ba...@ti.com; gre...@linuxfoundation.org;
 thomas.abra...@linaro.org; ben-li...@fluff.org;
 broo...@opensource.wolfsonmicro.com; l.majew...@samsung.com;
 kyungmin.p...@samsung.com; grant.lik...@secretlab.ca; he...@sntech.de
 Subject: [PATCH v3 4/5] ARM: S3C64XX: Enabling samsung-usbphy driver
 
 Adding platform device for samsung-usbphy driver. Enabling it for
 s3c64xx based machines using s3c-hsotg.
 
 Signed-off-by: Praveen Paneri p.pan...@samsung.com
 ---
  arch/arm/mach-s3c64xx/include/mach/map.h |2 +
  arch/arm/mach-s3c64xx/mach-crag6410.c|4 +++
  arch/arm/mach-s3c64xx/mach-smartq.c  |5 
  arch/arm/mach-s3c64xx/mach-smdk6410.c|4 +++
  arch/arm/mach-s3c64xx/setup-usb-phy.c|   14 +++
  arch/arm/plat-samsung/devs.c |   33
++
  arch/arm/plat-samsung/include/plat/devs.h|1 +
  arch/arm/plat-samsung/include/plat/usb-phy.h |1 +
  8 files changed, 64 insertions(+), 0 deletions(-)
 
 diff --git a/arch/arm/mach-s3c64xx/include/mach/map.h b/arch/arm/mach-
 s3c64xx/include/mach/map.h
 index 8e2097b..dc482bb 100644
 --- a/arch/arm/mach-s3c64xx/include/mach/map.h
 +++ b/arch/arm/mach-s3c64xx/include/mach/map.h
 @@ -65,6 +65,7 @@
 
  #define S3C64XX_PA_NAND  (0x7020)
  #define S3C64XX_PA_FB(0x7710)
 +#define S3C64XX_PA_USB_HSPHY (0x7C10)
  #define S3C64XX_PA_USB_HSOTG (0x7C00)
  #define S3C64XX_PA_WATCHDOG  (0x7E004000)
  #define S3C64XX_PA_RTC   (0x7E005000)
 @@ -113,6 +114,7 @@
  #define S3C_PA_FBS3C64XX_PA_FB
  #define S3C_PA_USBHOST   S3C64XX_PA_USBHOST
  #define S3C_PA_USB_HSOTG S3C64XX_PA_USB_HSOTG
 +#define S3C_PA_USB_PHY   S3C64XX_PA_USB_HSPHY
  #define S3C_PA_RTC   S3C64XX_PA_RTC
  #define S3C_PA_WDT   S3C64XX_PA_WATCHDOG
  #define S3C_PA_SPI0  S3C64XX_PA_SPI0
 diff --git a/arch/arm/mach-s3c64xx/mach-crag6410.c b/arch/arm/mach-
 s3c64xx/mach-crag6410.c
 index b0f5baf..fa02e2f 100644
 --- a/arch/arm/mach-s3c64xx/mach-crag6410.c
 +++ b/arch/arm/mach-s3c64xx/mach-crag6410.c
 @@ -31,6 +31,7 @@
  #include linux/spi/spi.h
 
  #include linux/i2c/pca953x.h
 +#include linux/platform_data/samsung-usbphy.h
 
  #include video/platform_lcd.h
 
 @@ -336,6 +337,7 @@ static struct platform_device wallvdd_device = {
  };
 
  static struct platform_device *crag6410_devices[] __initdata = {
 + samsung_device_usbphy,
   s3c_device_hsmmc0,
   s3c_device_hsmmc2,
   s3c_device_i2c0,
 @@ -765,6 +767,7 @@ static const struct gpio_led_platform_data
 gpio_leds_pdata = {
   .num_leds = ARRAY_SIZE(gpio_leds),
  };
 
 +static struct samsung_usbphy_data crag6410_usbphy_pdata;

Why don't you use __initdata for this structure? It will be duplicated
in s3c_set_platdata() and we don't need it in memory after booting.
I think you can even initialize it here (with s5p_usb_phy_pmu_isolation).

 
  static void __init crag6410_machine_init(void)
  {
 @@ -790,6 +793,7 @@ static void __init crag6410_machine_init(void)
   s3c_i2c0_set_platdata(i2c0_pdata);
   s3c_i2c1_set_platdata(i2c1_pdata);
   s3c_fb_set_platdata(crag6410_lcd_pdata);
 + samsung_usbphy_set_pdata(crag6410_usbphy_pdata);
 
   i2c_register_board_info(0, i2c_devs0, ARRAY_SIZE(i2c_devs0));
   i2c_register_board_info(1, i2c_devs1, ARRAY_SIZE(i2c_devs1));
 diff --git a/arch/arm/mach-s3c64xx/mach-smartq.c b/arch/arm/mach-
 s3c64xx/mach-smartq.c
 index 7400da1..e0c4df8 100644
 --- a/arch/arm/mach-s3c64xx/mach-smartq.c
 +++ b/arch/arm/mach-s3c64xx/mach-smartq.c
 @@ -18,6 +18,7 @@
  #include linux/serial_core.h
  #include linux/spi/spi_gpio.h
  #include linux/usb/gpio_vbus.h
 +#include linux/platform_data/samsung-usbphy.h
 
  #include asm/mach-types.h
  #include asm/mach/map.h
 @@ -234,6 +235,7 @@ static struct i2c_board_info smartq_i2c_devs[]
 __initdata = {
  };
 
  static struct platform_device *smartq_devices[] __initdata = {
 + samsung_device_usbphy,
   s3c_device_hsmmc1, /* Init iNAND first, ... */
   s3c_device_hsmmc0, /* ... then the external SD card */
   s3c_device_hsmmc2,
 @@ -380,9 +382,12 @@ void __init smartq_map_io(void)
   smartq_lcd_mode_set();
  }
 
 +static struct samsung_usbphy_data smartq_usbphy_pdata;

Same here

 +
  void __init smartq_machine_init(void)
  {
   s3c_i2c0_set_platdata(NULL);
 + samsung_usbphy_set_pdata(smartq_usbphy_pdata);
   s3c_hwmon_set_platdata(smartq_hwmon_pdata);
   s3c_sdhci1_set_platdata(smartq_internal_hsmmc_pdata);
   

[PATCH 1/3] ARM: SAMSUNG: Add support for EXYNOS SS USB 3.0 DRD controller

2012-02-06 Thread Anton Tikhomirov
Cc: Kukjin Kim kgene.kim at samsung.com
Cc: Greg Kroah-Hartman gregkh at suse.de
Cc: Felipe Balbi balbi at ti.com

Adds DRD global register definitions and related platform data.

Signed-off-by: Anton Tikhomirov av.tikhomi...@samsung.com
---
 .../include/plat/regs-usb3-exynos-drd.h|  305 
 arch/arm/plat-samsung/include/plat/udc-ss.h|   21 ++
 arch/arm/plat-samsung/include/plat/usb-phy.h   |1 +
 3 files changed, 327 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/plat-samsung/include/plat/regs-usb3-exynos-drd.h
 create mode 100644 arch/arm/plat-samsung/include/plat/udc-ss.h

diff --git a/arch/arm/plat-samsung/include/plat/regs-usb3-exynos-drd.h 
b/arch/arm/plat-samsung/include/plat/regs-usb3-exynos-drd.h
new file mode 100644
index 000..7006dc4
--- /dev/null
+++ b/arch/arm/plat-samsung/include/plat/regs-usb3-exynos-drd.h
@@ -0,0 +1,305 @@
+/* arch/arm/plat-samsung/include/plat/regs-usb3-exynos-drd.h
+ *
+ * Copyright (c) 2011 Samsung Electronics Co. Ltd
+ * Author: Anton Tikhomirov av.tikhomi...@samsung.com
+ *
+ * Exynos SuperSpeed USB 3.0 DRD Controller Global registers
+ *
+ * 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.
+ */
+
+#ifndef __SAMSUNG_PLAT_REGS_USB3_EXYNOS_DRD_H
+#define __SAMSUNG_PLAT_REGS_USB3_EXYNOS_DRD_H __FILE__
+
+#define EXYNOS_USB3_REG(x) (x)
+
+#define EXYNOS_USB3_GSBUSCFG0  EXYNOS_USB3_REG(0xC100)
+#define EXYNOS_USB3_GSBUSCFG0_SBusStoreAndForward  (1  12)
+#define EXYNOS_USB3_GSBUSCFG0_DatBigEnd(1  11)
+#define EXYNOS_USB3_GSBUSCFG0_INCR256BrstEna   (1  7)
+#define EXYNOS_USB3_GSBUSCFG0_INCR128BrstEna   (1  6)
+#define EXYNOS_USB3_GSBUSCFG0_INCR64BrstEna(1  5)
+#define EXYNOS_USB3_GSBUSCFG0_INCR32BrstEna(1  4)
+#define EXYNOS_USB3_GSBUSCFG0_INCR16BrstEna(1  3)
+#define EXYNOS_USB3_GSBUSCFG0_INCR8BrstEna (1  2)
+#define EXYNOS_USB3_GSBUSCFG0_INCR4BrstEna (1  1)
+#define EXYNOS_USB3_GSBUSCFG0_INCRBrstEna  (1  0)
+
+#define EXYNOS_USB3_GSBUSCFG1  EXYNOS_USB3_REG(0xC104)
+#define EXYNOS_USB3_GSBUSCFG1_EN1KPAGE (1  12)
+#define EXYNOS_USB3_GSBUSCFG1_BREQLIMIT_MASK   (0xf  8)
+#define EXYNOS_USB3_GSBUSCFG1_BREQLIMIT_SHIFT  8
+#define EXYNOS_USB3_GSBUSCFG1_BREQLIMIT(_x)((_x)  8)
+
+
+#define EXYNOS_USB3_GTXTHRCFG  EXYNOS_USB3_REG(0xC108)
+#define EXYNOS_USB3_GTXTHRCFG_USBTxPktCntSel   (1  29)
+#define EXYNOS_USB3_GTXTHRCFG_USBTxPktCnt_MASK (0xf  24)
+#define EXYNOS_USB3_GTXTHRCFG_USBTxPktCnt_SHIFT24
+#define EXYNOS_USB3_GTXTHRCFG_USBTxPktCnt(_x)  ((_x)  24)
+#define EXYNOS_USB3_GTXTHRCFG_USBMaxTxBurstSize_MASK   (0xff  16)
+#define EXYNOS_USB3_GTXTHRCFG_USBMaxTxBurstSize_SHIFT  16
+#define EXYNOS_USB3_GTXTHRCFG_USBMaxTxBurstSize(_x)((_x)  16)
+
+
+#define EXYNOS_USB3_GRXTHRCFG  EXYNOS_USB3_REG(0xC10C)
+#define EXYNOS_USB3_GRXTHRCFG_USBRxPktCntSel   (1  29)
+#define EXYNOS_USB3_GRXTHRCFG_USBRxPktCnt_MASK (0xf  24)
+#define EXYNOS_USB3_GRXTHRCFG_USBRxPktCnt_SHIFT24
+#define EXYNOS_USB3_GRXTHRCFG_USBRxPktCnt(_x)  ((_x)  24)
+#define EXYNOS_USB3_GRXTHRCFG_USBMaxRxBurstSize_MASK   (0x1f  19)
+#define EXYNOS_USB3_GRXTHRCFG_USBMaxRxBurstSize_SHIFT  19
+#define EXYNOS_USB3_GRXTHRCFG_USBMaxRxBurstSize(_x)((_x)  19)
+
+
+#define EXYNOS_USB3_GCTL   EXYNOS_USB3_REG(0xC110)
+#define EXYNOS_USB3_GCTL_PwrDnScale_MASK   (0x1fff  19)
+#define EXYNOS_USB3_GCTL_PwrDnScale_SHIFT  19
+#define EXYNOS_USB3_GCTL_PwrDnScale(_x)((_x)  19)
+#define EXYNOS_USB3_GCTL_U2RSTECN  (1  16)
+#define EXYNOS_USB3_GCTL_FRMSCLDWN_MASK(0x3  14)
+#define EXYNOS_USB3_GCTL_FRMSCLDWN_SHIFT   14
+#define EXYNOS_USB3_GCTL_FRMSCLDWN(_x) ((_x)  14)
+#define EXYNOS_USB3_GCTL_PrtCapDir_MASK(0x3  12)
+#define EXYNOS_USB3_GCTL_PrtCapDir_SHIFT   12
+#define EXYNOS_USB3_GCTL_PrtCapDir(_x) ((_x)  12)
+#define EXYNOS_USB3_GCTL_CoreSoftReset (1  11)
+#define EXYNOS_USB3_GCTL_LocalLpBkEn   (1  10)
+#define EXYNOS_USB3_GCTL_LpbkEn(1  9)
+#define EXYNOS_USB3_GCTL_DebugAttach   (1  8)
+#define EXYNOS_USB3_GCTL_RAMClkSel_MASK(0x3  6)
+#define EXYNOS_USB3_GCTL_RAMClkSel_SHIFT   6
+#define EXYNOS_USB3_GCTL_RAMClkSel(_x) ((_x)  6)
+#define EXYNOS_USB3_GCTL_ScaleDown_MASK(0x3  4)
+#define EXYNOS_USB3_GCTL_ScaleDown_SHIFT   4
+#define EXYNOS_USB3_GCTL_ScaleDown(_x) ((_x)  4)
+#define EXYNOS_USB3_GCTL_DisScramble

[PATCH 2/3] USB: SET SEL request definition

2012-02-06 Thread Anton Tikhomirov
Cc: Kukjin Kim kgene.kim at samsung.com
Cc: Greg Kroah-Hartman gregkh at suse.de
Cc: Felipe Balbi balbi at ti.com

Adds SET SEL standard request definition as defined by ch9
of the USB3.0 specification.

Signed-off-by: Anton Tikhomirov av.tikhomi...@samsung.com
---
 include/linux/usb/ch9.h |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/include/linux/usb/ch9.h b/include/linux/usb/ch9.h
index 61b2905..76ff771 100644
--- a/include/linux/usb/ch9.h
+++ b/include/linux/usb/ch9.h
@@ -88,6 +88,7 @@
 #define USB_REQ_GET_INTERFACE  0x0A
 #define USB_REQ_SET_INTERFACE  0x0B
 #define USB_REQ_SYNCH_FRAME0x0C
+#define USB_REQ_SET_SEL0x30
 
 #define USB_REQ_SET_ENCRYPTION 0x0D/* Wireless USB */
 #define USB_REQ_GET_ENCRYPTION 0x0E
-- 
1.7.1


--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 3/3] USB: EXYNOS USB3.0 device controller driver

2012-02-06 Thread Anton Tikhomirov
Hi Felipe,

I'm sorry for the misunderstanding from our side. We will implement the glue
layer for our Exynos SoC and reuse the dwc3 driver.

Thank you. 

Felipe Balbi wrote:
 Hi,
 
 On Mon, Feb 06, 2012 at 05:13:28PM +0900, Anton Tikhomirov wrote:
  Cc: Kukjin Kim kgene.kim at samsung.com
  Cc: Greg Kroah-Hartman gregkh at suse.de
  Cc: Felipe Balbi balbi at ti.com
 
 you can add the correct email, actually, but they should follow your
 Signed-off-by line.
 
 
  Adds Exynos USB3.0 device controller driver to support USB peripherals
  on Exynos5 chips.
 
  Signed-off-by: Anton Tikhomirov av.tikhomi...@samsung.com
  ---
   drivers/usb/gadget/Kconfig |   13 +
   drivers/usb/gadget/Makefile|1 +
   drivers/usb/gadget/exynos_ss_udc.c | 2511
  
   drivers/usb/gadget/exynos_ss_udc.h |  342 +
   4 files changed, 2867 insertions(+), 0 deletions(-)  create mode
  100644 drivers/usb/gadget/exynos_ss_udc.c
   create mode 100644 drivers/usb/gadget/exynos_ss_udc.h
 
  diff --git a/drivers/usb/gadget/Kconfig b/drivers/usb/gadget/Kconfig
  index 7ecb68a..8d3bc6e 100644
  --- a/drivers/usb/gadget/Kconfig
  +++ b/drivers/usb/gadget/Kconfig
  @@ -268,6 +268,19 @@ config USB_S3C_HSOTG
The Samsung S3C64XX USB2.0 high-speed gadget controller
integrated into the S3C64XX series SoC.
 
  +config USB_EXYNOS_SS_UDC
  +   tristate EXYNOS SuperSpeed USB 3.0 Device controller
  +   depends on EXYNOS_DEV_SS_UDC
  +   select USB_GADGET_DUALSPEED
  +   select USB_GADGET_SUPERSPEED
  +   help
  + The Samsung Exynos SuperSpeed USB 3.0 device controller
  + integrated into the Exynos5 series SoC.
  +
  + Say y to link the driver statically, or m to build a
  + dynamically linked module called exynos_ss_udc and force all
  + gadget drivers to also be dynamically linked.
  +
   config USB_IMX
  tristate Freescale i.MX1 USB Peripheral Controller
  depends on ARCH_MXC
  diff --git a/drivers/usb/gadget/Makefile b/drivers/usb/gadget/Makefile
  index b7f6eef..092bc76 100644
  --- a/drivers/usb/gadget/Makefile
  +++ b/drivers/usb/gadget/Makefile
  @@ -25,6 +25,7 @@ obj-$(CONFIG_USB_FSL_QE)  += fsl_qe_udc.o
   obj-$(CONFIG_USB_CI13XXX_PCI)  += ci13xxx_pci.o
   obj-$(CONFIG_USB_S3C_HSOTG)+= s3c-hsotg.o
   obj-$(CONFIG_USB_S3C_HSUDC)+= s3c-hsudc.o
  +obj-$(CONFIG_USB_EXYNOS_SS_UDC) += exynos_ss_udc.o
   obj-$(CONFIG_USB_LANGWELL) += langwell_udc.o
   obj-$(CONFIG_USB_EG20T)+= pch_udc.o
   obj-$(CONFIG_USB_MV_UDC)   += mv_udc.o
  diff --git a/drivers/usb/gadget/exynos_ss_udc.c
  b/drivers/usb/gadget/exynos_ss_udc.c
  new file mode 100644
  index 000..aaad33c
  --- /dev/null
  +++ b/drivers/usb/gadget/exynos_ss_udc.c
  @@ -0,0 +1,2511 @@
  +/* linux/drivers/usb/gadget/exynos_ss_udc.c
  + *
  + * Copyright 2011 Samsung Electronics Co., Ltd.
  + * http://www.samsung.com/
  + *
  + * EXYNOS SuperSpeed USB 3.0 Device Controlle driver
  + *
  + * 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/kernel.h
  +#include linux/module.h
  +#include linux/spinlock.h
  +#include linux/interrupt.h
  +#include linux/platform_device.h
  +#include linux/dma-mapping.h
  +#include linux/delay.h
  +#include linux/io.h
  +#include linux/slab.h
  +#include linux/clk.h
  +
  +#include linux/usb/ch9.h
  +#include linux/usb/gadget.h
  +
  +#include asm/byteorder.h
  +
  +#include mach/map.h
  +
  +#include plat/regs-usb3-exynos-drd.h #include plat/udc-ss.h
  +#include plat/usb-phy.h
 
 do _NOT_ depend on any arch-specific crap please. Registers can be defined
 on the C source code and other stuff could sit on linux/usb/ or
 linux/platform_data/ depending on what it is. I want to be able to
 compile this with whatever (cross) compiler I have available.
 
  +#include exynos_ss_udc.h
  +
  +static void exynos_ss_udc_kill_all_requests(struct exynos_ss_udc *udc,
  +   struct exynos_ss_udc_ep *udc_ep,
  +   int result);
  +static void exynos_ss_udc_complete_setup(struct usb_ep *ep,
  +struct usb_request *req);
  +static void exynos_ss_udc_complete_request(struct exynos_ss_udc *udc,
  +  struct exynos_ss_udc_ep *udc_ep,
  +  struct exynos_ss_udc_req *udc_req,
  +  int result);
  +static void exynos_ss_udc_start_req(struct exynos_ss_udc *udc,
  +   struct exynos_ss_udc_ep *udc_ep,
  +   struct exynos_ss_udc_req *udc_req,
  +   bool continuing);
  +static void exynos_ss_udc_ep_activate(struct exynos_ss_udc *udc,
  + struct exynos_ss_udc_ep *udc_ep

Re: [PATCH 2/3] USB: SET SEL request definition

2012-02-06 Thread Anton Tikhomirov
Hi,

Greg KH wrote:
 On Mon, Feb 06, 2012 at 05:12:33PM +0900, Anton Tikhomirov wrote:
  Cc: Kukjin Kim kgene.kim at samsung.com
  Cc: Greg Kroah-Hartman gregkh at suse.de
  Cc: Felipe Balbi balbi at ti.com
 
 What is that mess?  It belongs, with real email addresses, below your
 signed-off-by line, if at all.
 
  Adds SET SEL standard request definition as defined by ch9
  of the USB3.0 specification.
 
  Signed-off-by: Anton Tikhomirov av.tikhomi...@samsung.com
  ---
   include/linux/usb/ch9.h |1 +
   1 files changed, 1 insertions(+), 0 deletions(-)
 
  diff --git a/include/linux/usb/ch9.h b/include/linux/usb/ch9.h
  index 61b2905..76ff771 100644
  --- a/include/linux/usb/ch9.h
  +++ b/include/linux/usb/ch9.h
  @@ -88,6 +88,7 @@
   #define USB_REQ_GET_INTERFACE  0x0A
   #define USB_REQ_SET_INTERFACE  0x0B
   #define USB_REQ_SYNCH_FRAME0x0C
  +#define USB_REQ_SET_SEL0x30
 
   #define USB_REQ_SET_ENCRYPTION 0x0D/* Wireless USB */
   #define USB_REQ_GET_ENCRYPTION 0x0E
 
 Why did you insert this out of order?
 
 greg please note my email address change as well k-h

'Set SEL' is a standard device request according to USB3.0 spec. Wireless USB 
requests are not mentioned
in USB3.0 spec (and moreover are not in ch9 of it). So I put the definition to 
an appropriate group in my opinion.
If you insist I will move the definition below Wireless USB group with a space 
between.

--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html