Re: [PATCH v2] arm64: dts: msm8996: Use dwc3-qcom glue driver for USB

[Vivek Gautam]

Hi,


On 6/11/2018 12:06 PM, Julien Massot wrote:

Hi,


On 5/31/2018 4:17 PM, Manu Gautam wrote:

Move from dwc3-of-simple to dwc3-qcom glue driver to
support peripheral mode which requires qscratch wrapper
programming on VBUS event.

I would like to test usb otg as peripheral role, but that's not clear
for me which patches
are required on top of linux master branch or linaro qcom-lt
integration branch, or a
custom branch which integrate dt-binding phy or usb related patch.

Can you point me the patches I need to apply, or a branch, to test
peripheral feature ?


I have a branch that's based on 4.17. You can pick that.
https://github.com/vivekgautam1/linux/commits/v4.17/db820c

Thanks
Vivek


Thanks,
Julien



--
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

Re: [PATCH v2] arm64: dts: msm8996: Use dwc3-qcom glue driver for USB

[Vivek Gautam]

On 5/31/2018 4:17 PM, Manu Gautam wrote:

Move from dwc3-of-simple to dwc3-qcom glue driver to
support peripheral mode which requires qscratch wrapper
programming on VBUS event.

Fixes: a4333c3a6ba9 ("usb: dwc3: Add Qualcomm DWC3 glue driver")
Signed-off-by: Manu Gautam 
---

Changes since v1:
  - Update unit address of DT node as per Doug's comment

  arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi |  6 --
  arch/arm64/boot/dts/qcom/msm8996.dtsi| 10 ++
  2 files changed, 10 insertions(+), 6 deletions(-)


Tested on DB820c. Works fine.
Tested-by: Vivek Gautam 

BRs
Vivek


diff --git a/arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi 
b/arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi
index f45a0ab30d30..00be0d53891a 100644
--- a/arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi
+++ b/arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi
@@ -106,8 +106,9 @@
status = "okay";
};
  
-		usb@6a0 {

+   usb@6af8800 {
status = "okay";
+   extcon = <_id>;
  
  			dwc3@6a0 {

extcon = <_id>;
@@ -122,8 +123,9 @@
pinctrl-0 = <_vbus_det_gpio>;
};
  
-		usb@760 {

+   usb@76f8800 {
status = "okay";
+   extcon = <_id>;
  
  			dwc3@760 {

extcon = <_id>;
diff --git a/arch/arm64/boot/dts/qcom/msm8996.dtsi 
b/arch/arm64/boot/dts/qcom/msm8996.dtsi
index 26292027ba9b..8b6dd5443524 100644
--- a/arch/arm64/boot/dts/qcom/msm8996.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8996.dtsi
@@ -776,8 +776,9 @@
status = "disabled";
};
  
-		usb2: usb@760 {

-   compatible = "qcom,dwc3";
+   usb2: usb@76f8800 {
+   compatible = "qcom,msm8996-dwc3", "qcom,dwc3";
+   reg = <0x76f8800 0x400>;
#address-cells = <1>;
#size-cells = <1>;
ranges;
@@ -804,8 +805,9 @@
};
};
  
-		usb3: usb@6a0 {

-   compatible = "qcom,dwc3";
+   usb3: usb@6af8800 {
+   compatible = "qcom,msm8996-dwc3", "qcom,dwc3";
+   reg = <0x6af8800 0x400>;
#address-cells = <1>;
#size-cells = <1>;
ranges;


--
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

Re: [PATCH] usb: dwc3: of-simple: use managed and shared reset control

[Vivek Gautam]

On 4/3/2018 3:49 PM, Masahiro Yamada wrote:

2018-04-03 17:46 GMT+09:00 Philipp Zabel :

On Tue, 2018-04-03 at 17:30 +0900, Masahiro Yamada wrote:

2018-04-03 17:00 GMT+09:00 Philipp Zabel :

On Thu, 2018-03-29 at 15:07 +0900, Masahiro Yamada wrote:

This driver handles the reset control in a common manner; deassert
resets before use, assert them after use.  There is no good reason
why it should be exclusive.

Is this preemptive cleanup, or do you have hardware on the horizon that
shares these reset lines with other peripherals?

This patch is necessary for Socionext SoCs.

The same reset lines are shared between
this dwc3-of_simple and other glue circuits.

Thanks, this is helpful information.


Also, use devm_ for clean-up.

Signed-off-by: Masahiro Yamada 
---

CCing Philipp Zabel.
I see his sob in commit 06c47e6286d5.

At the time I was concerned with the reset_control_array addition and
didn't look closely at the exclusive vs shared issue.

  drivers/usb/dwc3/dwc3-of-simple.c | 7 ++-
  1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/drivers/usb/dwc3/dwc3-of-simple.c 
b/drivers/usb/dwc3/dwc3-of-simple.c
index e54c362..bd6ab65 100644
--- a/drivers/usb/dwc3/dwc3-of-simple.c
+++ b/drivers/usb/dwc3/dwc3-of-simple.c
@@ -91,7 +91,7 @@ static int dwc3_of_simple_probe(struct platform_device *pdev)
   platform_set_drvdata(pdev, simple);
   simple->dev = dev;

- simple->resets = of_reset_control_array_get_optional_exclusive(np);
+ simple->resets = devm_reset_control_array_get_optional_shared(dev);

 From the usage in the driver, it does indeed look like _shared reset
usage is appropriate. I assume that the hardware has no need for the
reset to be asserted right before probe or after remove, it just
requires that the reset line is kept deasserted while the driver is
probed.


   if (IS_ERR(simple->resets)) {
   ret = PTR_ERR(simple->resets);
   dev_err(dev, "failed to get device resets, err=%d\n", ret);
@@ -100,7 +100,7 @@ static int dwc3_of_simple_probe(struct platform_device 
*pdev)

   ret = reset_control_deassert(simple->resets);
   if (ret)
- goto err_resetc_put;
+ return ret;

   ret = dwc3_of_simple_clk_init(simple, of_count_phandle_with_args(np,
   "clocks", "#clock-cells"));
@@ -126,8 +126,6 @@ static int dwc3_of_simple_probe(struct platform_device 
*pdev)
  err_resetc_assert:
   reset_control_assert(simple->resets);

-err_resetc_put:
- reset_control_put(simple->resets);
   return ret;
  }

@@ -146,7 +144,6 @@ static int dwc3_of_simple_remove(struct platform_device 
*pdev)
   simple->num_clocks = 0;

   reset_control_assert(simple->resets);
- reset_control_put(simple->resets);

   pm_runtime_put_sync(dev);
   pm_runtime_disable(dev);

Changing to devm_ changes the order here. Whether or not it could be a
problem to assert the reset only after pm_runtime_put (or potentially
never), I can't say. I assume this is a non-issue, but somebody who
knows the hardware better would have to decide.



I do not understand what you mean.

Sorry for the confusion, I have mixed up things here.


Can you describe your concern in more details?

I am not touching reset_control_assert() here.

With the change to shared reset control, reset_control_assert
potentially does nothing, so it could be possible that
pm_runtime_put_sync cuts the power before the reset es asserted again.


I am delaying the call for reset_control_put().

Yes, please disregard my comment about the devm_ change, that should
have no effect whatsoever and looks fine to me.


If I understand reset_control_put() correctly,
the effects of this change are:
   - The ref_count and module ownership for the reset controller
 driver will be held a little longer
   - The call for kfree() will be a little bit delayed.

Correct.


Why do you need knowledge about this hardware?

Is it ok to keep the reset deasserted while the power is cut?
Or do you
have to guarantee that drivers sharing the same reset also keep the same
power domains active?


If this were really a problem, the driver would have to check
the error code from reset_control_assert().


Just to understand this - If the power domain isn't active for the said 
device,

does it matter if it is in reset state or not?




  ret = reset_control_assert(simple->resets);
  if (ret)
return ret; /* if we cannot assert reset, do not allow
driver detach */


What's the point of this. The power domain and reset should be independent
of each other, and when we are doing a driver detach, the state of hardware
should be of less concern.
The device should anyways not leak power when the power domain isn't active.

Regards
Vivek


  pm_runtime_put_sync(dev);
  pm_runtime_disable(dev);
  return 0;



What I can tell is, the current situation is
blocking 

Re: [PATCH v4 09/16] phy: qcom-qusb2: Add support for QUSB2 V2 version

[Vivek Gautam]

On Wed, Jan 3, 2018 at 4:58 PM, Manu Gautam <mgau...@codeaurora.org> wrote:
> Use register layout to add additional registers present
> on QUSB2 PHY V2 version for PHY initialization.
> Other than new registers on V2, following two register's
> offset and bit definitions are different: POWERDOWN control
> and PLL_STATUS.
>
> Signed-off-by: Manu Gautam <mgau...@codeaurora.org>
> ---
>  drivers/phy/qualcomm/phy-qcom-qusb2.c | 64 
> +++
>  1 file changed, 64 insertions(+)
>
> diff --git a/drivers/phy/qualcomm/phy-qcom-qusb2.c 
> b/drivers/phy/qualcomm/phy-qcom-qusb2.c
> index b65635f..8d0579e 100644
> --- a/drivers/phy/qualcomm/phy-qcom-qusb2.c
> +++ b/drivers/phy/qualcomm/phy-qcom-qusb2.c
> @@ -40,15 +40,34 @@
>  /* QUSB2PHY_PLL_STATUS register bits */
>  #define PLL_LOCKED BIT(5)
>
> +/* QUSB2PHY_PLL_COMMON_STATUS_ONE register bits */
> +#define CORE_READY_STATUS  BIT(0)
> +
>  /* QUSB2PHY_PORT_POWERDOWN register bits */
>  #define CLAMP_N_EN BIT(5)
>  #define FREEZIO_N  BIT(1)
>  #define POWER_DOWN BIT(0)
>
> +/* QUSB2PHY_PWR_CTRL1 register bits */
> +#define PWR_CTRL1_VREF_SUPPLY_TRIM BIT(5)
> +#define PWR_CTRL1_CLAMP_N_EN   BIT(1)
> +
>  #define QUSB2PHY_REFCLK_ENABLE BIT(0)
>
>  #define PHY_CLK_SCHEME_SEL BIT(0)
>
> +#defineQUSB2PHY_PLL_ANALOG_CONTROLS_TWO0x04
> +#defineQUSB2PHY_PLL_CLOCK_INVERTERS0x18c
> +#defineQUSB2PHY_PLL_CMODE  0x2c
> +#defineQUSB2PHY_PLL_LOCK_DELAY 0x184
> +#defineQUSB2PHY_PLL_DIGITAL_TIMERS_TWO 0xb4
> +#defineQUSB2PHY_PLL_BIAS_CONTROL_1 0x194
> +#defineQUSB2PHY_PLL_BIAS_CONTROL_2 0x198
> +#defineQUSB2PHY_PWR_CTRL2  0x214
> +#defineQUSB2PHY_IMP_CTRL1  0x220
> +#defineQUSB2PHY_IMP_CTRL2  0x224
> +#defineQUSB2PHY_CHG_CTRL2  0x23c

nit: Replace these tabs with simple spaces.

Rest all look good.
Reviewed-by: Vivek Gautam <vivek.gau...@codeaurora.org>

Thanks
Vivek

> +
>  struct qusb2_phy_init_tbl {
> unsigned int offset;
> unsigned int val;
> @@ -113,6 +132,38 @@ enum qusb2phy_reg_layout {
> QUSB2_PHY_INIT_CFG(QUSB2PHY_PLL_PWR_CTRL, 0x00),
>  };
>
> +static const unsigned int qusb2_v2_regs_layout[] = {
> +   [QUSB2PHY_PLL_STATUS]   = 0x1a0,
> +   [QUSB2PHY_PORT_TUNE1]   = 0x240,
> +   [QUSB2PHY_PORT_TUNE2]   = 0x244,
> +   [QUSB2PHY_PORT_TUNE3]   = 0x248,
> +   [QUSB2PHY_PORT_TUNE4]   = 0x24c,
> +   [QUSB2PHY_PORT_TUNE5]   = 0x250,
> +   [QUSB2PHY_PORT_TEST2]   = 0x258,
> +   [QUSB2PHY_PORT_POWERDOWN]   = 0x210,
> +};
> +
> +static const struct qusb2_phy_init_tbl qusb2_v2_init_tbl[] = {
> +   QUSB2_PHY_INIT_CFG(QUSB2PHY_PLL_ANALOG_CONTROLS_TWO, 0x03),
> +   QUSB2_PHY_INIT_CFG(QUSB2PHY_PLL_CLOCK_INVERTERS, 0x7c),
> +   QUSB2_PHY_INIT_CFG(QUSB2PHY_PLL_CMODE, 0x80),
> +   QUSB2_PHY_INIT_CFG(QUSB2PHY_PLL_LOCK_DELAY, 0x0a),
> +   QUSB2_PHY_INIT_CFG(QUSB2PHY_PLL_DIGITAL_TIMERS_TWO, 0x19),
> +   QUSB2_PHY_INIT_CFG(QUSB2PHY_PLL_BIAS_CONTROL_1, 0x40),
> +   QUSB2_PHY_INIT_CFG(QUSB2PHY_PLL_BIAS_CONTROL_2, 0x20),
> +   QUSB2_PHY_INIT_CFG(QUSB2PHY_PWR_CTRL2, 0x21),
> +   QUSB2_PHY_INIT_CFG(QUSB2PHY_IMP_CTRL1, 0x0),
> +   QUSB2_PHY_INIT_CFG(QUSB2PHY_IMP_CTRL2, 0x58),
> +
> +   QUSB2_PHY_INIT_CFG_L(QUSB2PHY_PORT_TUNE1, 0x30),
> +   QUSB2_PHY_INIT_CFG_L(QUSB2PHY_PORT_TUNE2, 0x29),
> +   QUSB2_PHY_INIT_CFG_L(QUSB2PHY_PORT_TUNE3, 0xca),
> +   QUSB2_PHY_INIT_CFG_L(QUSB2PHY_PORT_TUNE4, 0x04),
> +   QUSB2_PHY_INIT_CFG_L(QUSB2PHY_PORT_TUNE5, 0x03),
> +
> +   QUSB2_PHY_INIT_CFG(QUSB2PHY_CHG_CTRL2, 0x0),
> +};
> +
>  struct qusb2_phy_cfg {
> const struct qusb2_phy_init_tbl *tbl;
> /* number of entries in the table */
> @@ -142,6 +193,16 @@ struct qusb2_phy_cfg {
> .mask_core_ready = PLL_LOCKED,
>  };
>
> +static const struct qusb2_phy_cfg qusb2_v2_phy_cfg = {
> +   .tbl= qusb2_v2_init_tbl,
> +   .tbl_num= ARRAY_SIZE(qusb2_v2_init_tbl),
> +   .regs   = qusb2_v2_regs_layout,
> +
> +   .disable_ctrl   = (PWR_CTRL1_VREF_SUPPLY_TRIM | PWR_CTRL1_CLAMP_N_EN |
> +  POWER_DOWN),
> +   .mask_core_ready = CORE_READY_STATUS,
> +};
> +
>  static const char * const qusb2_phy_vreg_names[] = {
> 

Re: [PATCH v4 07/16] phy: qcom-qusb2: Add support for different register layouts

[Vivek Gautam]

On Wed, Jan 3, 2018 at 4:58 PM, Manu Gautam <mgau...@codeaurora.org> wrote:
> New version of QUSB2 PHY has some registers offset changed.
> Add support to have register layout for a target and update
> the same in phy_configuration.
>
> Signed-off-by: Manu Gautam <mgau...@codeaurora.org>
> ---

LGTM.
Reviewed-by: Vivek Gautam <vivek.gau...@codeaurora.org>

>  drivers/phy/qualcomm/phy-qcom-qusb2.c | 149 
> +-
>  1 file changed, 109 insertions(+), 40 deletions(-)
>
> diff --git a/drivers/phy/qualcomm/phy-qcom-qusb2.c 
> b/drivers/phy/qualcomm/phy-qcom-qusb2.c
> index 4a5b2a1..b65635f 100644
> --- a/drivers/phy/qualcomm/phy-qcom-qusb2.c
> +++ b/drivers/phy/qualcomm/phy-qcom-qusb2.c
> @@ -37,17 +37,10 @@
>  #define QUSB2PHY_PLL_AUTOPGM_CTL1  0x1c
>  #define QUSB2PHY_PLL_PWR_CTRL  0x18
>
> -#define QUSB2PHY_PLL_STATUS0x38
> +/* QUSB2PHY_PLL_STATUS register bits */
>  #define PLL_LOCKED BIT(5)
>
> -#define QUSB2PHY_PORT_TUNE10x80
> -#define QUSB2PHY_PORT_TUNE20x84
> -#define QUSB2PHY_PORT_TUNE30x88
> -#define QUSB2PHY_PORT_TUNE40x8c
> -#define QUSB2PHY_PORT_TUNE50x90
> -#define QUSB2PHY_PORT_TEST20x9c
> -
> -#define QUSB2PHY_PORT_POWERDOWN0xb4
> +/* QUSB2PHY_PORT_POWERDOWN register bits */
>  #define CLAMP_N_EN BIT(5)
>  #define FREEZIO_N  BIT(1)
>  #define POWER_DOWN BIT(0)
> @@ -59,6 +52,11 @@
>  struct qusb2_phy_init_tbl {
> unsigned int offset;
> unsigned int val;
> +   /*
> +* register part of layout ?
> +* if yes, then offset gives index in the reg-layout
> +*/
> +   int in_layout;
>  };
>
>  #define QUSB2_PHY_INIT_CFG(o, v) \
> @@ -67,15 +65,50 @@ struct qusb2_phy_init_tbl {
> .val = v,   \
> }
>
> +#define QUSB2_PHY_INIT_CFG_L(o, v) \
> +   {   \
> +   .offset = o,\
> +   .val = v,   \
> +   .in_layout = 1, \
> +   }
> +
> +/* set of registers with offsets different per-PHY */
> +enum qusb2phy_reg_layout {
> +   QUSB2PHY_PLL_STATUS,
> +   QUSB2PHY_PORT_TUNE1,
> +   QUSB2PHY_PORT_TUNE2,
> +   QUSB2PHY_PORT_TUNE3,
> +   QUSB2PHY_PORT_TUNE4,
> +   QUSB2PHY_PORT_TUNE5,
> +   QUSB2PHY_PORT_TEST1,
> +   QUSB2PHY_PORT_TEST2,
> +   QUSB2PHY_PORT_POWERDOWN,
> +   QUSB2PHY_INTR_CTRL,
> +};
> +
> +static const unsigned int msm8996_regs_layout[] = {
> +   [QUSB2PHY_PLL_STATUS]   = 0x38,
> +   [QUSB2PHY_PORT_TUNE1]   = 0x80,
> +   [QUSB2PHY_PORT_TUNE2]   = 0x84,
> +   [QUSB2PHY_PORT_TUNE3]   = 0x88,
> +   [QUSB2PHY_PORT_TUNE4]   = 0x8c,
> +   [QUSB2PHY_PORT_TUNE5]   = 0x90,
> +   [QUSB2PHY_PORT_TEST2]   = 0x9c,
> +   [QUSB2PHY_PORT_POWERDOWN]   = 0xb4,
> +};
> +
>  static const struct qusb2_phy_init_tbl msm8996_init_tbl[] = {
> -   QUSB2_PHY_INIT_CFG(QUSB2PHY_PORT_TUNE1, 0xf8),
> -   QUSB2_PHY_INIT_CFG(QUSB2PHY_PORT_TUNE2, 0xb3),
> -   QUSB2_PHY_INIT_CFG(QUSB2PHY_PORT_TUNE3, 0x83),
> -   QUSB2_PHY_INIT_CFG(QUSB2PHY_PORT_TUNE4, 0xc0),
> +   QUSB2_PHY_INIT_CFG_L(QUSB2PHY_PORT_TUNE1, 0xf8),
> +   QUSB2_PHY_INIT_CFG_L(QUSB2PHY_PORT_TUNE2, 0xb3),
> +   QUSB2_PHY_INIT_CFG_L(QUSB2PHY_PORT_TUNE3, 0x83),
> +   QUSB2_PHY_INIT_CFG_L(QUSB2PHY_PORT_TUNE4, 0xc0),
> +
> QUSB2_PHY_INIT_CFG(QUSB2PHY_PLL_TUNE, 0x30),
> QUSB2_PHY_INIT_CFG(QUSB2PHY_PLL_USER_CTL1, 0x79),
> QUSB2_PHY_INIT_CFG(QUSB2PHY_PLL_USER_CTL2, 0x21),
> -   QUSB2_PHY_INIT_CFG(QUSB2PHY_PORT_TEST2, 0x14),
> +
> +   QUSB2_PHY_INIT_CFG_L(QUSB2PHY_PORT_TEST2, 0x14),
> +
> QUSB2_PHY_INIT_CFG(QUSB2PHY_PLL_AUTOPGM_CTL1, 0x9f),
> QUSB2_PHY_INIT_CFG(QUSB2PHY_PLL_PWR_CTRL, 0x00),
>  };
> @@ -86,11 +119,27 @@ struct qusb2_phy_cfg {
> unsigned int tbl_num;
> /* offset to PHY_CLK_SCHEME register in TCSR map */
> unsigned int clk_scheme_offset;
> +
> +   /* array of registers with different offsets */
> +   const unsigned int *regs;
> +   unsigned int mask_core_ready;
> +   unsigned int disable_ctrl;
> +
> +   /* true if PHY has PLL_TEST register to select clk_scheme */
> +   bool has_pll_test;
> +
> +   /* true if TUNE1 register must be updated by fused value, else TUNE2 
> */
> +   bool update_tune1_with_efuse;
>  };
>
>  static const struct qusb2_phy_cfg msm8996_phy_cfg = {

Re: [PATCH v4 05/16] phy: qcom-qmp: Fix PHY block reset sequence

[Vivek Gautam]

On Fri, Jan 12, 2018 at 2:16 PM, Manu Gautam <mgau...@codeaurora.org> wrote:
> Hi Vivek,
>
>
> On 1/12/2018 2:14 PM, Vivek Gautam wrote:
>> On Wed, Jan 3, 2018 at 4:58 PM, Manu Gautam <mgau...@codeaurora.org> wrote:
>>> PHY block or asynchronous reset requires signal
>>> to be asserted before de-asserting. Driver is only
>>> de-asserting signal which is already low, hence
>>> reset operation is a no-op. Fix this by asserting
>>> signal first. Also, resetting requires PHY clocks
>>> to be turned ON only after reset is finished. Fix
>>> that as well.
>>>
>>> Signed-off-by: Manu Gautam <mgau...@codeaurora.org>
>>> ---
>>>  drivers/phy/qualcomm/phy-qcom-qmp.c | 28 +++-
>>>  1 file changed, 19 insertions(+), 9 deletions(-)
>>>
>>> diff --git a/drivers/phy/qualcomm/phy-qcom-qmp.c 
>>> b/drivers/phy/qualcomm/phy-qcom-qmp.c
>>> index 1b82cea..ecff261 100644
>>> --- a/drivers/phy/qualcomm/phy-qcom-qmp.c
>>> +++ b/drivers/phy/qualcomm/phy-qcom-qmp.c
>>> @@ -752,13 +752,16 @@ static int qcom_qmp_phy_com_init(struct qcom_qmp *qmp)
>>> goto err_reg_enable;
>>> }
>>>
>>> -   ret = clk_bulk_prepare_enable(cfg->num_clks, qmp->clks);
>>> -   if (ret) {
>>> -   dev_err(qmp->dev, "failed to enable clks, err=%d\n", ret);
>>> -   goto err_clk_enable;
>>> +   for (i = 0; i < cfg->num_resets; i++) {
>>> +   ret = reset_control_assert(qmp->resets[i]);
>>> +   if (ret) {
>>> +   dev_err(qmp->dev, "%s reset assert failed\n",
>>> +   cfg->reset_list[i]);
>>> +   goto err_rst_assert;
>>> +   }
>>> }
>>>
>>> -   for (i = 0; i < cfg->num_resets; i++) {
>>> +   for (i = cfg->num_resets - 1; i >= 0; i--) {
>> Do we a dependency on the order in which these resets are
>> applied?
>> If not then we can use the 'bulk reset' APIs as well.
>
> We need to follow an order for assert and opposite order for
> de-assert, hence cant use 'bulk reset' APIs.

Okay, you can add my review then.
Thanks.
>
>>
>> With that bulk reset change you can add my review.
>>
>> Reviewed-by: Vivek Gautam <vivek.gau...@codeaurora.org>
>>
>> Thanks
>> Vivek
>>
>>> ret = reset_control_deassert(qmp->resets[i]);
>>> if (ret) {
>>> dev_err(qmp->dev, "%s reset deassert failed\n",
>>> @@ -767,6 +770,12 @@ static int qcom_qmp_phy_com_init(struct qcom_qmp *qmp)
>>> }
>>> }
>>>
>>> +   ret = clk_bulk_prepare_enable(cfg->num_clks, qmp->clks);
>>> +   if (ret) {
>>> +   dev_err(qmp->dev, "failed to enable clks, err=%d\n", ret);
>>> +   goto err_rst;
>>> +   }
>>> +
>>> if (cfg->has_phy_com_ctrl)
>>> qphy_setbits(serdes, cfg->regs[QPHY_COM_POWER_DOWN_CONTROL],
>>>  SW_PWRDN);
>>> @@ -791,7 +800,7 @@ static int qcom_qmp_phy_com_init(struct qcom_qmp *qmp)
>>> if (ret) {
>>> dev_err(qmp->dev,
>>> "phy common block init timed-out\n");
>>> -   goto err_rst;
>>> +   goto err_com_init;
>>> }
>>> }
>>>
>>> @@ -799,11 +808,12 @@ static int qcom_qmp_phy_com_init(struct qcom_qmp *qmp)
>>>
>>> return 0;
>>>
>>> +err_com_init:
>>> +   clk_bulk_disable_unprepare(cfg->num_clks, qmp->clks);
>>>  err_rst:
>>> -   while (--i >= 0)
>>> +   while (++i < cfg->num_resets)
>>> reset_control_assert(qmp->resets[i]);
>>> -   clk_bulk_disable_unprepare(cfg->num_clks, qmp->clks);
>>> -err_clk_enable:
>>> +err_rst_assert:
>>> regulator_bulk_disable(cfg->num_vregs, qmp->vregs);
>>>  err_reg_enable:
>>> mutex_unlock(>phy_mutex);
>>> --
>>> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
>>> a Linux Foundation Collaborative Project
>>>
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
>>> the body of a message to majord...@vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
>>
>
> --
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project
>



-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
--
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

Re: [PATCH v4 05/16] phy: qcom-qmp: Fix PHY block reset sequence

[Vivek Gautam]

On Wed, Jan 3, 2018 at 4:58 PM, Manu Gautam <mgau...@codeaurora.org> wrote:
> PHY block or asynchronous reset requires signal
> to be asserted before de-asserting. Driver is only
> de-asserting signal which is already low, hence
> reset operation is a no-op. Fix this by asserting
> signal first. Also, resetting requires PHY clocks
> to be turned ON only after reset is finished. Fix
> that as well.
>
> Signed-off-by: Manu Gautam <mgau...@codeaurora.org>
> ---
>  drivers/phy/qualcomm/phy-qcom-qmp.c | 28 +++-
>  1 file changed, 19 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/phy/qualcomm/phy-qcom-qmp.c 
> b/drivers/phy/qualcomm/phy-qcom-qmp.c
> index 1b82cea..ecff261 100644
> --- a/drivers/phy/qualcomm/phy-qcom-qmp.c
> +++ b/drivers/phy/qualcomm/phy-qcom-qmp.c
> @@ -752,13 +752,16 @@ static int qcom_qmp_phy_com_init(struct qcom_qmp *qmp)
> goto err_reg_enable;
> }
>
> -   ret = clk_bulk_prepare_enable(cfg->num_clks, qmp->clks);
> -   if (ret) {
> -   dev_err(qmp->dev, "failed to enable clks, err=%d\n", ret);
> -   goto err_clk_enable;
> +   for (i = 0; i < cfg->num_resets; i++) {
> +   ret = reset_control_assert(qmp->resets[i]);
> +   if (ret) {
> +   dev_err(qmp->dev, "%s reset assert failed\n",
> +   cfg->reset_list[i]);
> +   goto err_rst_assert;
> +   }
> }
>
> -   for (i = 0; i < cfg->num_resets; i++) {
> +   for (i = cfg->num_resets - 1; i >= 0; i--) {

Do we a dependency on the order in which these resets are
applied?
If not then we can use the 'bulk reset' APIs as well.

With that bulk reset change you can add my review.

Reviewed-by: Vivek Gautam <vivek.gau...@codeaurora.org>

Thanks
Vivek

> ret = reset_control_deassert(qmp->resets[i]);
> if (ret) {
> dev_err(qmp->dev, "%s reset deassert failed\n",
> @@ -767,6 +770,12 @@ static int qcom_qmp_phy_com_init(struct qcom_qmp *qmp)
> }
> }
>
> +   ret = clk_bulk_prepare_enable(cfg->num_clks, qmp->clks);
> +   if (ret) {
> +   dev_err(qmp->dev, "failed to enable clks, err=%d\n", ret);
> +   goto err_rst;
> +   }
> +
> if (cfg->has_phy_com_ctrl)
> qphy_setbits(serdes, cfg->regs[QPHY_COM_POWER_DOWN_CONTROL],
>  SW_PWRDN);
> @@ -791,7 +800,7 @@ static int qcom_qmp_phy_com_init(struct qcom_qmp *qmp)
> if (ret) {
> dev_err(qmp->dev,
> "phy common block init timed-out\n");
> -   goto err_rst;
> +   goto err_com_init;
> }
> }
>
> @@ -799,11 +808,12 @@ static int qcom_qmp_phy_com_init(struct qcom_qmp *qmp)
>
> return 0;
>
> +err_com_init:
> +   clk_bulk_disable_unprepare(cfg->num_clks, qmp->clks);
>  err_rst:
> -   while (--i >= 0)
> +   while (++i < cfg->num_resets)
> reset_control_assert(qmp->resets[i]);
> -   clk_bulk_disable_unprepare(cfg->num_clks, qmp->clks);
> -err_clk_enable:
> +err_rst_assert:
> regulator_bulk_disable(cfg->num_vregs, qmp->vregs);
>  err_reg_enable:
> mutex_unlock(>phy_mutex);
> --
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
--
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

Re: [PATCH v4 04/16] phy: qcom-qusb2: Power-on PHY before initialization

[Vivek Gautam]

On Wed, Jan 3, 2018 at 4:58 PM, Manu Gautam <mgau...@codeaurora.org> wrote:
> PHY must be powered on before turning ON clocks and
> attempting to initialize it. Driver is exposing
> separate init and power_on routines for this.
> Apparently USB dwc3 core driver performs power-on
> after init. Also, poweron and init for QUSB2 PHY
> need to be executed together always, hence remove
> poweron callback from phy_ops and explicitly perform
> this from init, similar changes needed for poweroff.
>
> Signed-off-by: Manu Gautam <mgau...@codeaurora.org>
> ---

Looks good.

Reviewed-by: Vivek Gautam <vivek.gau...@codeaurora.org>

Thanks
Vivek

>  drivers/phy/qualcomm/phy-qcom-qusb2.c | 47 
> +++
>  1 file changed, 15 insertions(+), 32 deletions(-)
>
> diff --git a/drivers/phy/qualcomm/phy-qcom-qusb2.c 
> b/drivers/phy/qualcomm/phy-qcom-qusb2.c
> index 6c57524..4a5b2a1 100644
> --- a/drivers/phy/qualcomm/phy-qcom-qusb2.c
> +++ b/drivers/phy/qualcomm/phy-qcom-qusb2.c
> @@ -195,54 +195,31 @@ static void qusb2_phy_set_tune2_param(struct qusb2_phy 
> *qphy)
> qusb2_setbits(qphy->base, QUSB2PHY_PORT_TUNE2, val[0] << 0x4);
>  }
>
> -static int qusb2_phy_poweron(struct phy *phy)
> +static int qusb2_phy_init(struct phy *phy)
>  {
> struct qusb2_phy *qphy = phy_get_drvdata(phy);
> -   int num = ARRAY_SIZE(qphy->vregs);
> +   unsigned int val;
> +   unsigned int clk_scheme;
> int ret;
>
> -   dev_vdbg(>dev, "%s(): Powering-on QUSB2 phy\n", __func__);
> +   dev_vdbg(>dev, "%s(): Initializing QUSB2 phy\n", __func__);
>
> /* turn on regulator supplies */
> -   ret = regulator_bulk_enable(num, qphy->vregs);
> +   ret = regulator_bulk_enable(ARRAY_SIZE(qphy->vregs), qphy->vregs);
> if (ret)
> return ret;
>
> ret = clk_prepare_enable(qphy->iface_clk);
> if (ret) {
> dev_err(>dev, "failed to enable iface_clk, %d\n", ret);
> -   regulator_bulk_disable(num, qphy->vregs);
> -   return ret;
> +   goto poweroff_phy;
> }
>
> -   return 0;
> -}
> -
> -static int qusb2_phy_poweroff(struct phy *phy)
> -{
> -   struct qusb2_phy *qphy = phy_get_drvdata(phy);
> -
> -   clk_disable_unprepare(qphy->iface_clk);
> -
> -   regulator_bulk_disable(ARRAY_SIZE(qphy->vregs), qphy->vregs);
> -
> -   return 0;
> -}
> -
> -static int qusb2_phy_init(struct phy *phy)
> -{
> -   struct qusb2_phy *qphy = phy_get_drvdata(phy);
> -   unsigned int val;
> -   unsigned int clk_scheme;
> -   int ret;
> -
> -   dev_vdbg(>dev, "%s(): Initializing QUSB2 phy\n", __func__);
> -
> /* enable ahb interface clock to program phy */
> ret = clk_prepare_enable(qphy->cfg_ahb_clk);
> if (ret) {
> dev_err(>dev, "failed to enable cfg ahb clock, %d\n", 
> ret);
> -   return ret;
> +   goto disable_iface_clk;
> }
>
> /* Perform phy reset */
> @@ -344,6 +321,11 @@ static int qusb2_phy_init(struct phy *phy)
> reset_control_assert(qphy->phy_reset);
>  disable_ahb_clk:
> clk_disable_unprepare(qphy->cfg_ahb_clk);
> +disable_iface_clk:
> +   clk_disable_unprepare(qphy->iface_clk);
> +poweroff_phy:
> +   regulator_bulk_disable(ARRAY_SIZE(qphy->vregs), qphy->vregs);
> +
> return ret;
>  }
>
> @@ -361,6 +343,9 @@ static int qusb2_phy_exit(struct phy *phy)
> reset_control_assert(qphy->phy_reset);
>
> clk_disable_unprepare(qphy->cfg_ahb_clk);
> +   clk_disable_unprepare(qphy->iface_clk);
> +
> +   regulator_bulk_disable(ARRAY_SIZE(qphy->vregs), qphy->vregs);
>
> return 0;
>  }
> @@ -368,8 +353,6 @@ static int qusb2_phy_exit(struct phy *phy)
>  static const struct phy_ops qusb2_phy_gen_ops = {
> .init   = qusb2_phy_init,
> .exit   = qusb2_phy_exit,
> -   .power_on   = qusb2_phy_poweron,
> -   .power_off  = qusb2_phy_poweroff,
> .owner  = THIS_MODULE,
>  };
>
> --
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
--
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

Re: [PATCH v4 03/16] phy: qcom-qmp: Power-on PHY before initialization

[Vivek Gautam]

On Wed, Jan 3, 2018 at 4:58 PM, Manu Gautam  wrote:
> PHY regulators which are enabled from power_on() must be ON
> before turning-on clocks and initializing it as part of init().
> As most of the core drivers perform power_on() after init(), move
> PHY regulators enable to com_init() and use power_on() to
> only enable pipe_clk. This pipe_clk is output from PHY and some
> core drivers e.g. PCIe follow specific sequence after phy_init()
> that mandates pipe_clk to be enabled from power_on() only.
> On similar lines move clk_enable from init() to com_init() which
> executes once for multi lane PHYs.
>
> Signed-off-by: Manu Gautam 
> ---

Adding Subhash Jadvani to look at this change from UFS perspective.

>  drivers/phy/qualcomm/phy-qcom-qmp.c | 61 
> +++--
>  1 file changed, 24 insertions(+), 37 deletions(-)
>
> diff --git a/drivers/phy/qualcomm/phy-qcom-qmp.c 
> b/drivers/phy/qualcomm/phy-qcom-qmp.c
> index 5fed1ae..1b82cea 100644
> --- a/drivers/phy/qualcomm/phy-qcom-qmp.c
> +++ b/drivers/phy/qualcomm/phy-qcom-qmp.c
> @@ -724,36 +724,13 @@ static int qcom_qmp_phy_poweron(struct phy *phy)
>  {
> struct qmp_phy *qphy = phy_get_drvdata(phy);
> struct qcom_qmp *qmp = qphy->qmp;
> -   int num = qmp->cfg->num_vregs;
> int ret;
>
> -   dev_vdbg(>dev, "Powering on QMP phy\n");
> -
> -   /* turn on regulator supplies */
> -   ret = regulator_bulk_enable(num, qmp->vregs);
> -   if (ret) {
> -   dev_err(qmp->dev, "failed to enable regulators, err=%d\n", 
> ret);
> -   return ret;
> -   }
> -
> ret = clk_prepare_enable(qphy->pipe_clk);
> -   if (ret) {
> +   if (ret)
> dev_err(qmp->dev, "pipe_clk enable failed, err=%d\n", ret);
> -   regulator_bulk_disable(num, qmp->vregs);
> -   return ret;
> -   }
>
> -   return 0;
> -}
> -
> -static int qcom_qmp_phy_poweroff(struct phy *phy)
> -{
> -   struct qmp_phy *qphy = phy_get_drvdata(phy);
> -   struct qcom_qmp *qmp = qphy->qmp;
> -
> -   regulator_bulk_disable(qmp->cfg->num_vregs, qmp->vregs);
> -
> -   return 0;
> +   return ret;
>  }
>
>  static int qcom_qmp_phy_com_init(struct qcom_qmp *qmp)
> @@ -768,6 +745,19 @@ static int qcom_qmp_phy_com_init(struct qcom_qmp *qmp)
> return 0;
> }
>
> +   /* turn on regulator supplies */
> +   ret = regulator_bulk_enable(cfg->num_vregs, qmp->vregs);
> +   if (ret) {
> +   dev_err(qmp->dev, "failed to enable regulators, err=%d\n", 
> ret);
> +   goto err_reg_enable;
> +   }
> +
> +   ret = clk_bulk_prepare_enable(cfg->num_clks, qmp->clks);
> +   if (ret) {
> +   dev_err(qmp->dev, "failed to enable clks, err=%d\n", ret);
> +   goto err_clk_enable;
> +   }
> +
> for (i = 0; i < cfg->num_resets; i++) {
> ret = reset_control_deassert(qmp->resets[i]);
> if (ret) {
> @@ -812,6 +802,10 @@ static int qcom_qmp_phy_com_init(struct qcom_qmp *qmp)
>  err_rst:
> while (--i >= 0)
> reset_control_assert(qmp->resets[i]);
> +   clk_bulk_disable_unprepare(cfg->num_clks, qmp->clks);
> +err_clk_enable:
> +   regulator_bulk_disable(cfg->num_vregs, qmp->vregs);
> +err_reg_enable:
> mutex_unlock(>phy_mutex);
>
> return ret;
> @@ -841,6 +835,10 @@ static int qcom_qmp_phy_com_exit(struct qcom_qmp *qmp)
> while (--i >= 0)
> reset_control_assert(qmp->resets[i]);
>
> +   clk_bulk_disable_unprepare(cfg->num_clks, qmp->clks);
> +
> +   regulator_bulk_disable(cfg->num_vregs, qmp->vregs);
> +
> mutex_unlock(>phy_mutex);
>
> return 0;
> @@ -861,15 +859,9 @@ static int qcom_qmp_phy_init(struct phy *phy)
>
> dev_vdbg(qmp->dev, "Initializing QMP phy\n");
>
> -   ret = clk_bulk_prepare_enable(cfg->num_clks, qmp->clks);
> -   if (ret) {
> -   dev_err(qmp->dev, "failed to enable clks, err=%d\n", ret);
> -   return ret;
> -   }
> -
> ret = qcom_qmp_phy_com_init(qmp);
> if (ret)
> -   goto err_com_init;
> +   return ret;
>
> if (cfg->has_lane_rst) {
> ret = reset_control_deassert(qphy->lane_rst);
> @@ -917,8 +909,6 @@ static int qcom_qmp_phy_init(struct phy *phy)
> reset_control_assert(qphy->lane_rst);
>  err_lane_rst:
> qcom_qmp_phy_com_exit(qmp);
> -err_com_init:
> -   clk_bulk_disable_unprepare(cfg->num_clks, qmp->clks);
>
> return ret;
>  }
> @@ -945,8 +935,6 @@ static int qcom_qmp_phy_exit(struct phy *phy)
>
> qcom_qmp_phy_com_exit(qmp);
>
> -   clk_bulk_disable_unprepare(cfg->num_clks, qmp->clks);
> -
> return 0;
>  }
>
> @@ -1060,7 +1048,6 @@ static int phy_pipe_clk_register(struct qcom_qmp *qmp, 
> struct device_node *np)
> .init 

Re: [PATCH v4 10/16] phy: qcom-qmp: Move register offsets to header file

[Vivek Gautam]

Hi Manu,

On Wed, Jan 3, 2018 at 4:58 PM, Manu Gautam  wrote:
> New revision (v3) of QMP PHY uses different offsets
> for almost all of the registers. Hence, move these
> definitions to header file so that updated offsets
> can be added for QMP v3.
>
> Signed-off-by: Manu Gautam 
> ---
>  drivers/phy/qualcomm/phy-qcom-qmp.c | 119 +--
>  drivers/phy/qualcomm/phy-qcom-qmp.h | 137 
> 
>  2 files changed, 138 insertions(+), 118 deletions(-)
>  create mode 100644 drivers/phy/qualcomm/phy-qcom-qmp.h
>

[snip]

> diff --git a/drivers/phy/qualcomm/phy-qcom-qmp.h 
> b/drivers/phy/qualcomm/phy-qcom-qmp.h
> new file mode 100644
> index 000..d930ca7
> --- /dev/null
> +++ b/drivers/phy/qualcomm/phy-qcom-qmp.h
> @@ -0,0 +1,137 @@
> +/*
> + * Copyright (c) 2017, Linux Foundation. All rights reserved.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 and
> + * only version 2 as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + */

nit: "SPDX-License" identifier now? That's less number of lines too :)
And when you are doing that, can you please consider moving
phy-qcom-qmp and phy-qcom-qusb2 as well to the new SPDX license
identifier. That will be cleaner.
Thanks!

> +
> +#ifndef QCOM_PHY_QMP_H_
> +#define QCOM_PHY_QMP_H_
> +
> +/* Only for QMP V2 PHY - QSERDES COM registers */
> +#define QSERDES_COM_BG_TIMER   0x00c
> +#define QSERDES_COM_SSC_EN_CENTER  0x010
> +#define QSERDES_COM_SSC_ADJ_PER1   0x014
> +#define QSERDES_COM_SSC_ADJ_PER2   0x018
> +#define QSERDES_COM_SSC_PER1   0x01c
> +#define QSERDES_COM_SSC_PER2   0x020
> +#define QSERDES_COM_SSC_STEP_SIZE1 0x024
> +#define QSERDES_COM_SSC_STEP_SIZE2 0x028
> +#define QSERDES_COM_BIAS_EN_CLKBUFLR_EN0x034
> +#define QSERDES_COM_CLK_ENABLE10x038
> +#define QSERDES_COM_SYS_CLK_CTRL   0x03c
> +#define QSERDES_COM_SYSCLK_BUF_ENABLE  0x040
> +#define QSERDES_COM_PLL_IVCO   0x048
> +#define QSERDES_COM_LOCK_CMP1_MODE00x04c
> +#define QSERDES_COM_LOCK_CMP2_MODE00x050
> +#define QSERDES_COM_LOCK_CMP3_MODE00x054
> +#define QSERDES_COM_LOCK_CMP1_MODE10x058
> +#define QSERDES_COM_LOCK_CMP2_MODE10x05c
> +#define QSERDES_COM_LOCK_CMP3_MODE10x060
> +#define QSERDES_COM_BG_TRIM0x070
> +#define QSERDES_COM_CLK_EP_DIV 0x074
> +#define QSERDES_COM_CP_CTRL_MODE0  0x078
> +#define QSERDES_COM_CP_CTRL_MODE1  0x07c
> +#define QSERDES_COM_PLL_RCTRL_MODE00x084
> +#define QSERDES_COM_PLL_RCTRL_MODE10x088
> +#define QSERDES_COM_PLL_CCTRL_MODE00x090
> +#define QSERDES_COM_PLL_CCTRL_MODE10x094
> +#define QSERDES_COM_BIAS_EN_CTRL_BY_PSM0x0a8
> +#define QSERDES_COM_SYSCLK_EN_SEL  0x0ac
> +#define QSERDES_COM_RESETSM_CNTRL  0x0b4
> +#define QSERDES_COM_RESTRIM_CTRL   0x0bc
> +#define QSERDES_COM_RESCODE_DIV_NUM0x0c4
> +#define QSERDES_COM_LOCK_CMP_EN0x0c8
> +#define QSERDES_COM_LOCK_CMP_CFG   0x0cc
> +#define QSERDES_COM_DEC_START_MODE00x0d0
> +#define QSERDES_COM_DEC_START_MODE10x0d4
> +#define QSERDES_COM_DIV_FRAC_START1_MODE0  0x0dc
> +#define QSERDES_COM_DIV_FRAC_START2_MODE0  0x0e0
> +#define QSERDES_COM_DIV_FRAC_START3_MODE0  0x0e4
> +#define QSERDES_COM_DIV_FRAC_START1_MODE1  0x0e8
> +#define QSERDES_COM_DIV_FRAC_START2_MODE1  0x0ec
> +#define QSERDES_COM_DIV_FRAC_START3_MODE1  0x0f0
> +#define QSERDES_COM_INTEGLOOP_GAIN0_MODE0  0x108
> +#define QSERDES_COM_INTEGLOOP_GAIN1_MODE0  0x10c
> +#define QSERDES_COM_INTEGLOOP_GAIN0_MODE1  0x110
> +#define QSERDES_COM_INTEGLOOP_GAIN1_MODE1  0x114
> +#define QSERDES_COM_VCO_TUNE_CTRL  0x124
> +#define QSERDES_COM_VCO_TUNE_MAP   0x128
> +#define QSERDES_COM_VCO_TUNE1_MODE00x12c
> +#define QSERDES_COM_VCO_TUNE2_MODE00x130
> 

Re: [PATCH v3 02/16] phy: qcom-qmp: Adapt to clk_bulk_* APIs

[Vivek Gautam]

Hi Manu,


On Tue, Nov 21, 2017 at 2:53 PM, Manu Gautam <mgau...@codeaurora.org> wrote:
> From: Vivek Gautam <vivek.gau...@codeaurora.org>
>
> Move from using array of clocks to clk_bulk_* APIs that
> are available now.
>
> Signed-off-by: Vivek Gautam <vivek.gau...@codeaurora.org>
> Signed-off-by: Manu Gautam <mgau...@codeaurora.org>
> ---
>  drivers/phy/qualcomm/phy-qcom-qmp.c | 50 
> -
>  1 file changed, 16 insertions(+), 34 deletions(-)
>
> diff --git a/drivers/phy/qualcomm/phy-qcom-qmp.c 
> b/drivers/phy/qualcomm/phy-qcom-qmp.c
> index 76acaec..90794dd 100644
> --- a/drivers/phy/qualcomm/phy-qcom-qmp.c
> +++ b/drivers/phy/qualcomm/phy-qcom-qmp.c

[snip]

> @@ -998,29 +992,17 @@ static int qcom_qmp_phy_reset_init(struct device *dev)
>  static int qcom_qmp_phy_clk_init(struct device *dev)
>  {
> struct qcom_qmp *qmp = dev_get_drvdata(dev);
> -   int ret, i;
> +   int num = qmp->cfg->num_clks;
> +   int i;
>
> -   qmp->clks = devm_kcalloc(dev, qmp->cfg->num_clks,
> -sizeof(*qmp->clks), GFP_KERNEL);
> +   qmp->clks = devm_kcalloc(dev, num, sizeof(*qmp->clks), GFP_KERNEL);
> if (!qmp->clks)
> return -ENOMEM;
>
> -   for (i = 0; i < qmp->cfg->num_clks; i++) {
> -   struct clk *_clk;
> -   const char *name = qmp->cfg->clk_list[i];
> -
> -   _clk = devm_clk_get(dev, name);
> -   if (IS_ERR(_clk)) {
> -   ret = PTR_ERR(_clk);
> -   if (ret != -EPROBE_DEFER)
> -   dev_err(dev, "failed to get %s clk, %d\n",
> -   name, ret);
> -   return ret;
> -   }
> -   qmp->clks[i] = _clk;
> -   }
> +   for (i = 0; i < num; i++)
> +   qmp->clks->id = qmp->cfg->clk_list[i];

I think i missed this one while rebasing.
We need to use index with this. Should be:
qmp->clks[i]->id = qmp->cfg->clk_list[i];


Regards
Vivek


-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
--
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

Re: [PATCH v3 07/16] phy: qcom-qusb2: Add support for different register layouts

[Vivek Gautam]

On 11/21/2017 02:53 PM, Manu Gautam wrote:

New version of QUSB2 PHY has some registers offset changed.
Add support to have register layout for a target and update
the same in phy_configuration.

Signed-off-by: Manu Gautam 
---
  drivers/phy/qualcomm/phy-qcom-qusb2.c | 131 --
  1 file changed, 95 insertions(+), 36 deletions(-)

diff --git a/drivers/phy/qualcomm/phy-qcom-qusb2.c 
b/drivers/phy/qualcomm/phy-qcom-qusb2.c
index 4a5b2a1..c0c5358 100644
--- a/drivers/phy/qualcomm/phy-qcom-qusb2.c
+++ b/drivers/phy/qualcomm/phy-qcom-qusb2.c

[snip]

  /*
@@ -198,7 +249,8 @@ static void qusb2_phy_set_tune2_param(struct qusb2_phy 
*qphy)


We need to add following change to qusb2_phy_set_tune2_param()
since we have register layout now.

@@ -333,7 +334,7 @@ static void qusb2_phy_set_tune2_param(struct 
qusb2_phy *qphy)

}

/* Fused TUNE2 value is the higher nibble only */
-   qusb2_setbits(qphy->base, QUSB2PHY_PORT_TUNE2, val[0] << 0x4);
+   qusb2_setbits(qphy->base, cfg->regs[QUSB2PHY_PORT_TUNE2], val[0] 
<< 0x4);

 }

regards
Vivek

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

--
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

Re: [PATCH V2] usb: dwc3: Initialize DMA ops/mask for xhci-hcd

[Vivek Gautam]

Hi Adam,


On Mon, Aug 28, 2017 at 10:05 PM, Adam Wallis  wrote:
> The dma ops from the parent DWC device are not getting passed to the
> child xhci-hcd device. This patch makes use of
> platform_device_register_full to set the DMA ops. For the DT/OF case,
> dma_ops were still null after the the device register, so
> of_dma_configure is called in only the OF case.
>
> Signed-off-by: Adam Wallis 
> ---
>  drivers/usb/dwc3/host.c | 39 +--
>  1 file changed, 17 insertions(+), 22 deletions(-)
>
> diff --git a/drivers/usb/dwc3/host.c b/drivers/usb/dwc3/host.c
> index 76f0b0d..c289da1 100644
> --- a/drivers/usb/dwc3/host.c
> +++ b/drivers/usb/dwc3/host.c
> @@ -16,6 +16,7 @@
>   */
>
>  #include 
> +#include 
>
>  #include "core.h"
>
> @@ -56,6 +57,7 @@ int dwc3_host_init(struct dwc3 *dwc)
>  {
> struct property_entry   props[3];
> struct platform_device  *xhci;
> +   struct platform_device_info dwc_plat_info = {};
> int ret, irq;
> struct resource *res;
> struct platform_device  *dwc3_pdev = to_platform_device(dwc->dev);
> @@ -79,22 +81,22 @@ int dwc3_host_init(struct dwc3 *dwc)
> dwc->xhci_resources[1].flags = res->flags;
> dwc->xhci_resources[1].name = res->name;
>
> -   xhci = platform_device_alloc("xhci-hcd", PLATFORM_DEVID_AUTO);
> -   if (!xhci) {
> -   dev_err(dwc->dev, "couldn't allocate xHCI device\n");
> -   return -ENOMEM;
> -   }
> +   dwc_plat_info.name = "xhci-hcd";
> +   dwc_plat_info.parent = dwc->sysdev;
> +   dwc_plat_info.res = dwc->xhci_resources;
> +   dwc_plat_info.num_res = DWC3_XHCI_RESOURCES_NUM;
> +   dwc_plat_info.fwnode = dwc->sysdev->fwnode;
> +   dwc_plat_info.dma_mask = *dwc->sysdev->dma_mask;
>
> -   xhci->dev.parent= dwc->dev;
> +   xhci = platform_device_register_full(_plat_info);
> +   if (IS_ERR(xhci)) {
> +   dev_err(dwc->dev, "failed to register xHCI device\n");
> +   return PTR_ERR(xhci);
> +   }
>
> dwc->xhci = xhci;
> -
> -   ret = platform_device_add_resources(xhci, dwc->xhci_resources,
> -   DWC3_XHCI_RESOURCES_NUM);
> -   if (ret) {
> -   dev_err(dwc->dev, "couldn't add resources to xHCI device\n");
> -   goto err1;
> -   }
> +   if (dwc->sysdev->of_node)
> +   of_dma_configure(>dev, dwc->sysdev->of_node);

Isn't this code doing the same thing what the xhci-plat also does right now
since dwc->sysdev is either dwc->dev or dwc->dev->parent.

>From xhci_plat_probe():
sysdev = >dev;
if (sysdev->parent && !sysdev->of_node && sysdev->parent->of_node)
sysdev = sysdev->parent;

after which it tries to set the dma masks.




regards
Vivek
-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
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

Re: [PATCH] phy: qcom-qmp: Fix failure path in phy_init functions

[Vivek Gautam]

On Wed, Aug 2, 2017 at 10:39 AM, Kishon Vijay Abraham I <kis...@ti.com> wrote:
> Vivek,
>
> On Monday 31 July 2017 10:58 AM, Vivek Gautam wrote:
>> Hi Kishon,
>>
>>
>> On Tue, Jun 20, 2017 at 11:27 AM, Vivek Gautam
>> <vivek.gau...@codeaurora.org> wrote:
>>> Fixing the clk enable failure path in qcom_qmp_phy_init()
>>> and cleanup the reset control deassertion failure path in
>>> qcom_qmp_phy_com_init().
>>>
>>> Fixes: e78f3d15e115 ("phy: qcom-qmp: new qmp phy driver for qcom-chipsets")
>>>
>>> Cc: Kishon Vijay Abraham I <kis...@ti.com>
>>> Signed-off-by: Vivek Gautam <vivek.gau...@codeaurora.org>
>>
>> This patch got missed. Can you please pull this in?
>
> merged now, thanks!

Thanks Kishon.

regards
Vivek

>
> -Kishon
>>
>> regards
>> Vivek
>>
>>> ---
>>>  drivers/phy/qualcomm/phy-qcom-qmp.c | 15 ++-
>>>  1 file changed, 6 insertions(+), 9 deletions(-)
>>>
>>> diff --git a/drivers/phy/qualcomm/phy-qcom-qmp.c 
>>> b/drivers/phy/qualcomm/phy-qcom-qmp.c
>>> index 78ca62897784..7b739571b301 100644
>>> --- a/drivers/phy/qualcomm/phy-qcom-qmp.c
>>> +++ b/drivers/phy/qualcomm/phy-qcom-qmp.c
>>> @@ -654,8 +654,6 @@ static int qcom_qmp_phy_com_init(struct qcom_qmp *qmp)
>>> if (ret) {
>>> dev_err(qmp->dev, "%s reset deassert failed\n",
>>> qmp->cfg->reset_list[i]);
>>> -   while (--i >= 0)
>>> -   reset_control_assert(qmp->resets[i]);
>>> goto err_rst;
>>> }
>>> }
>>> @@ -684,7 +682,7 @@ static int qcom_qmp_phy_com_init(struct qcom_qmp *qmp)
>>> if (ret) {
>>> dev_err(qmp->dev,
>>> "phy common block init timed-out\n");
>>> -   goto err_com_init;
>>> +   goto err_rst;
>>> }
>>> }
>>>
>>> @@ -692,11 +690,11 @@ static int qcom_qmp_phy_com_init(struct qcom_qmp *qmp)
>>>
>>> return 0;
>>>
>>> -err_com_init:
>>> +err_rst:
>>> while (--i >= 0)
>>> reset_control_assert(qmp->resets[i]);
>>> -err_rst:
>>> mutex_unlock(>phy_mutex);
>>> +
>>> return ret;
>>>  }
>>>
>>> @@ -749,14 +747,13 @@ static int qcom_qmp_phy_init(struct phy *phy)
>>> if (ret) {
>>> dev_err(qmp->dev, "failed to enable %s clk, 
>>> err=%d\n",
>>> qmp->cfg->clk_list[i], ret);
>>> -   while (--i >= 0)
>>> -   clk_disable_unprepare(qmp->clks[i]);
>>> +   goto err_clk;
>>> }
>>> }
>>>
>>> ret = qcom_qmp_phy_com_init(qmp);
>>> if (ret)
>>> -   goto err_com_init;
>>> +   goto err_clk;
>>>
>>> if (cfg->has_lane_rst) {
>>> ret = reset_control_deassert(qphy->lane_rst);
>>> @@ -804,7 +801,7 @@ static int qcom_qmp_phy_init(struct phy *phy)
>>> reset_control_assert(qphy->lane_rst);
>>>  err_lane_rst:
>>> qcom_qmp_phy_com_exit(qmp);
>>> -err_com_init:
>>> +err_clk:
>>> while (--i >= 0)
>>> clk_disable_unprepare(qmp->clks[i]);
>>>
>>> --
>>> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
>>> a Linux Foundation Collaborative Project
>>>
>>
>>
>>
> --
> 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



-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
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

Re: [PATCH] phy: qcom-qmp: Fix failure path in phy_init functions

[Vivek Gautam]

Hi Kishon,


On Tue, Jun 20, 2017 at 11:27 AM, Vivek Gautam
<vivek.gau...@codeaurora.org> wrote:
> Fixing the clk enable failure path in qcom_qmp_phy_init()
> and cleanup the reset control deassertion failure path in
> qcom_qmp_phy_com_init().
>
> Fixes: e78f3d15e115 ("phy: qcom-qmp: new qmp phy driver for qcom-chipsets")
>
> Cc: Kishon Vijay Abraham I <kis...@ti.com>
> Signed-off-by: Vivek Gautam <vivek.gau...@codeaurora.org>

This patch got missed. Can you please pull this in?

regards
Vivek

> ---
>  drivers/phy/qualcomm/phy-qcom-qmp.c | 15 ++-
>  1 file changed, 6 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/phy/qualcomm/phy-qcom-qmp.c 
> b/drivers/phy/qualcomm/phy-qcom-qmp.c
> index 78ca62897784..7b739571b301 100644
> --- a/drivers/phy/qualcomm/phy-qcom-qmp.c
> +++ b/drivers/phy/qualcomm/phy-qcom-qmp.c
> @@ -654,8 +654,6 @@ static int qcom_qmp_phy_com_init(struct qcom_qmp *qmp)
> if (ret) {
> dev_err(qmp->dev, "%s reset deassert failed\n",
> qmp->cfg->reset_list[i]);
> -   while (--i >= 0)
> -   reset_control_assert(qmp->resets[i]);
> goto err_rst;
> }
> }
> @@ -684,7 +682,7 @@ static int qcom_qmp_phy_com_init(struct qcom_qmp *qmp)
> if (ret) {
> dev_err(qmp->dev,
> "phy common block init timed-out\n");
> -   goto err_com_init;
> +   goto err_rst;
> }
> }
>
> @@ -692,11 +690,11 @@ static int qcom_qmp_phy_com_init(struct qcom_qmp *qmp)
>
> return 0;
>
> -err_com_init:
> +err_rst:
> while (--i >= 0)
> reset_control_assert(qmp->resets[i]);
> -err_rst:
> mutex_unlock(>phy_mutex);
> +
> return ret;
>  }
>
> @@ -749,14 +747,13 @@ static int qcom_qmp_phy_init(struct phy *phy)
> if (ret) {
> dev_err(qmp->dev, "failed to enable %s clk, err=%d\n",
> qmp->cfg->clk_list[i], ret);
> -   while (--i >= 0)
> -   clk_disable_unprepare(qmp->clks[i]);
> +   goto err_clk;
> }
> }
>
> ret = qcom_qmp_phy_com_init(qmp);
> if (ret)
> -   goto err_com_init;
> +   goto err_clk;
>
> if (cfg->has_lane_rst) {
> ret = reset_control_deassert(qphy->lane_rst);
> @@ -804,7 +801,7 @@ static int qcom_qmp_phy_init(struct phy *phy)
> reset_control_assert(qphy->lane_rst);
>  err_lane_rst:
> qcom_qmp_phy_com_exit(qmp);
> -err_com_init:
> +err_clk:
> while (--i >= 0)
> clk_disable_unprepare(qmp->clks[i]);
>
> --
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project
>



-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
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

[PATCH] phy: qcom-qmp: Fix failure path in phy_init functions

[Vivek Gautam]

Fixing the clk enable failure path in qcom_qmp_phy_init()
and cleanup the reset control deassertion failure path in
qcom_qmp_phy_com_init().

Fixes: e78f3d15e115 ("phy: qcom-qmp: new qmp phy driver for qcom-chipsets")

Cc: Kishon Vijay Abraham I <kis...@ti.com>
Signed-off-by: Vivek Gautam <vivek.gau...@codeaurora.org>
---
 drivers/phy/qualcomm/phy-qcom-qmp.c | 15 ++-
 1 file changed, 6 insertions(+), 9 deletions(-)

diff --git a/drivers/phy/qualcomm/phy-qcom-qmp.c 
b/drivers/phy/qualcomm/phy-qcom-qmp.c
index 78ca62897784..7b739571b301 100644
--- a/drivers/phy/qualcomm/phy-qcom-qmp.c
+++ b/drivers/phy/qualcomm/phy-qcom-qmp.c
@@ -654,8 +654,6 @@ static int qcom_qmp_phy_com_init(struct qcom_qmp *qmp)
if (ret) {
dev_err(qmp->dev, "%s reset deassert failed\n",
qmp->cfg->reset_list[i]);
-   while (--i >= 0)
-   reset_control_assert(qmp->resets[i]);
goto err_rst;
}
}
@@ -684,7 +682,7 @@ static int qcom_qmp_phy_com_init(struct qcom_qmp *qmp)
if (ret) {
dev_err(qmp->dev,
"phy common block init timed-out\n");
-   goto err_com_init;
+   goto err_rst;
}
}
 
@@ -692,11 +690,11 @@ static int qcom_qmp_phy_com_init(struct qcom_qmp *qmp)
 
return 0;
 
-err_com_init:
+err_rst:
while (--i >= 0)
reset_control_assert(qmp->resets[i]);
-err_rst:
mutex_unlock(>phy_mutex);
+
return ret;
 }
 
@@ -749,14 +747,13 @@ static int qcom_qmp_phy_init(struct phy *phy)
if (ret) {
dev_err(qmp->dev, "failed to enable %s clk, err=%d\n",
qmp->cfg->clk_list[i], ret);
-   while (--i >= 0)
-   clk_disable_unprepare(qmp->clks[i]);
+   goto err_clk;
}
}
 
ret = qcom_qmp_phy_com_init(qmp);
if (ret)
-   goto err_com_init;
+   goto err_clk;
 
if (cfg->has_lane_rst) {
ret = reset_control_deassert(qphy->lane_rst);
@@ -804,7 +801,7 @@ static int qcom_qmp_phy_init(struct phy *phy)
reset_control_assert(qphy->lane_rst);
 err_lane_rst:
qcom_qmp_phy_com_exit(qmp);
-err_com_init:
+err_clk:
while (--i >= 0)
clk_disable_unprepare(qmp->clks[i]);
 
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

--
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

Re: [PATCH v5 3/6] reset: hide reset control arrays behind struct reset_control

[Vivek Gautam]

Hi Philipp,


On 06/19/2017 05:48 PM, Philipp Zabel wrote:

Hi Vivek,

On Tue, 2017-06-13 at 12:16 +0530, Vivek Gautam wrote:
[...]

@@ -102,18 +94,6 @@ static inline struct reset_control 
*__devm_reset_control_get(
return optional ? NULL : ERR_PTR(-ENOTSUPP);
   }
   
-static inline

-int reset_control_array_assert(struct reset_control_array *resets)
-{
-   return 0;
-}
-
-static inline
-int reset_control_array_deassert(struct reset_control_array *resets)
-{
-   return 0;
-}
-
   static inline struct reset_control_array *

This has to return just 'struct reset_control *'.
That should resolve kbuild errors.

Rest looks good to me.
Reviewed-by: Vivek Gautam <vivek.gau...@codeaurora.org>

Thanks, I had already fixed this locally, prompted by the kbuild test
robot. I'll send a v6. I would like to merge this patch into the first
"reset: Add APIs to manage array of resets" patch, if that's ok with
you.


Thanks.
You are right. It makes more sense to merge these two patches
if Jon finds it okay to put reset_control_array behind reset_control.

I am cool with squashing this patch.


Best regards
Vivek



regards
Philipp



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

--
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

Re: [PATCH v5 0/6] reset: APIs to manage a list of resets

[Vivek Gautam]

On 06/01/2017 10:21 PM, Philipp Zabel wrote:

A set of patches to allow consumers to get and de/assert or trigger
a number of resets at the same time. A patch on top of Vivek's original
API extension is added to hide the reset_control_array behind a struct
reset_control so that the consumer doesn't have care about the difference
between a singular reset control and reset control controlling an array
of resets, except when requesting the control.

This series also contains reset controls patches for dwc3-of-simple
and tegra pmc drivers.
A small patch is added in this series to correctly re-order the
resource handling in dwc3_of_simple_remove().

The series is tested on torvald's master branch the device tree
patches to enable usb on db820c.

Changes since v4:
  - Added a patch to hide reset control arrays behind struct reset_control
and adapted the consumer patches. This could be merged with the reset
array API patch if we think this is a good idea.


Hi Philipp,

I tested this series again on my db820c setup. Things work fine.
We can merge this series after fixing the 3/6 patch in this series.

Thanks

Hi Felipe,
If you are okay with changes in dwc3, can you kindly consider Ack'ing this
series. May be Philipp can pull the entire series after fixing.

Thanks
Vivek



Changes since v3:
  - Squashed of_reset_control_get_count() patch in the second patch that
adds the reset control array APIs.
  - The error path after getting count through of_reset_control_get_count()
now returns NULL pointer in case when 'optional' flag is true.
  - Added code in reset_control_array_assert() to deassert the
already asserted resets in the error case.
  - Using of_reset_control_array_get_optional_exclusive() in dwc3 patch
to request the reset control array.
  - Added a patch to fix the order in which resources are handled in
dwc3_of_simple_remove() path.
  - Added tegra_powergate->reset to take care of single reset control
passed from the client drivers.

Changes since v2:
  - Addressed comments to make APIs inline with gpiod API.
  - Moved number of reset controls in 'struct reset_control_array'
so that the footprint is reduced.
  - of_reset_control_array_get() and devm_reset_control_array_get()
now return pointer to the newly created reset control array.
  - Added comments to mention that the reset control array APIs don't
guarantee any particular order when handling the reset controls.
  - Dropped 'name' from reset_control_array' since the interface is meant
for a bunch of anonymous resets that can all be asserted or deasserted
in arbitrary order.
  - Fixed returns for APIs reported by kbuild.
  - Fixed 'for' clause guards reported by kbuild.

Changes since v1:
  - Addressed comment for error handling in of_reset_control_get_count()
  - Added patch to manage reset controller array.
  - Rebased dwc3-of-simple changes based on the new set of APIs
for reset control array.
  - Added a patch for soc/tegra/pmc driver to use the new set of
reset control array APIs.

Philipp Zabel (2):
   reset: use kref for reference counting
   reset: hide reset control arrays behind struct reset_control

Vivek Gautam (4):
   reset: Add APIs to manage array of resets
   usb: dwc3: of-simple: Re-order resource handling in remove
   usb: dwc3: of-simple: Add support to get resets for the device
   soc/tegra: pmc: Use the new reset APIs to manage reset controllers

  drivers/reset/core.c  | 234 --
  drivers/soc/tegra/pmc.c   |  82 -
  drivers/usb/dwc3/dwc3-of-simple.c |  29 -
  include/linux/reset.h |  73 
  4 files changed, 344 insertions(+), 74 deletions(-)



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

--
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

Re: [PATCH v5 3/6] reset: hide reset control arrays behind struct reset_control

[Vivek Gautam]

Hi Philipp,


On 06/01/2017 10:22 PM, Philipp Zabel wrote:

Reset controls already may control multiple reset lines with a single
hardware bit. So from the user perspective, reset control arrays are not
at all different from single reset controls.
Therefore, hide reset control arrays behind struct reset_control to
avoid having to introduce new API functions for array (de)assert/reset.

Cc: Vivek Gautam <vivek.gau...@codeaurora.org>
Cc: Jon Hunter <jonath...@nvidia.com>
Signed-off-by: Philipp Zabel <p.za...@pengutronix.de>
---
  drivers/reset/core.c  | 225 ++
  include/linux/reset.h |  44 +++---
  2 files changed, 128 insertions(+), 141 deletions(-)

diff --git a/drivers/reset/core.c b/drivers/reset/core.c
index 1747000757211..c8fb4426b218a 100644
--- a/drivers/reset/core.c
+++ b/drivers/reset/core.c
@@ -43,11 +43,24 @@ struct reset_control {
unsigned int id;
struct kref refcnt;
bool shared;
+   bool array;
atomic_t deassert_count;
atomic_t triggered_count;
  };
  
  /**

+ * struct reset_control_array - an array of reset controls
+ * @base: reset control for compatibility with reset control API functions
+ * @num_rstcs: number of reset controls
+ * @rstc: array of reset controls
+ */
+struct reset_control_array {
+   struct reset_control base;
+   unsigned int num_rstcs;
+   struct reset_control *rstc[];
+};
+
+/**
   * of_reset_simple_xlate - translate reset_spec to the reset line number
   * @rcdev: a pointer to the reset controller device
   * @reset_spec: reset line specifier as found in the device tree
@@ -135,6 +148,65 @@ int devm_reset_controller_register(struct device *dev,
  }
  EXPORT_SYMBOL_GPL(devm_reset_controller_register);
  
+static inline struct reset_control_array *

+rstc_to_array(struct reset_control *rstc) {
+   return container_of(rstc, struct reset_control_array, base);
+}
+
+static int reset_control_array_reset(struct reset_control_array *resets)
+{
+   int ret, i;
+
+   for (i = 0; i < resets->num_rstcs; i++) {
+   ret = reset_control_reset(resets->rstc[i]);
+   if (ret)
+   return ret;
+   }
+
+   return 0;
+}
+
+static int reset_control_array_assert(struct reset_control_array *resets)
+{
+   int ret, i;
+
+   for (i = 0; i < resets->num_rstcs; i++) {
+   ret = reset_control_assert(resets->rstc[i]);
+   if (ret)
+   goto err;
+   }
+
+   return 0;
+
+err:
+   while (i--)
+   reset_control_deassert(resets->rstc[i]);
+   return ret;
+}
+
+static int reset_control_array_deassert(struct reset_control_array *resets)
+{
+   int ret, i;
+
+   for (i = 0; i < resets->num_rstcs; i++) {
+   ret = reset_control_deassert(resets->rstc[i]);
+   if (ret)
+   goto err;
+   }
+
+   return 0;
+
+err:
+   while (i--)
+   reset_control_assert(resets->rstc[i]);
+   return ret;
+}
+
+static inline bool reset_control_is_array(struct reset_control *rstc)
+{
+   return rstc->array;
+}
+
  /**
   * reset_control_reset - reset the controlled device
   * @rstc: reset controller
@@ -158,6 +230,9 @@ int reset_control_reset(struct reset_control *rstc)
if (WARN_ON(IS_ERR(rstc)))
return -EINVAL;
  
+	if (reset_control_is_array(rstc))

+   return reset_control_array_reset(rstc_to_array(rstc));
+
if (!rstc->rcdev->ops->reset)
return -ENOTSUPP;
  
@@ -202,6 +277,9 @@ int reset_control_assert(struct reset_control *rstc)

if (WARN_ON(IS_ERR(rstc)))
return -EINVAL;
  
+	if (reset_control_is_array(rstc))

+   return reset_control_array_assert(rstc_to_array(rstc));
+
if (!rstc->rcdev->ops->assert)
return -ENOTSUPP;
  
@@ -240,6 +318,9 @@ int reset_control_deassert(struct reset_control *rstc)

if (WARN_ON(IS_ERR(rstc)))
return -EINVAL;
  
+	if (reset_control_is_array(rstc))

+   return reset_control_array_deassert(rstc_to_array(rstc));
+
if (!rstc->rcdev->ops->deassert)
return -ENOTSUPP;
  
@@ -266,7 +347,7 @@ int reset_control_status(struct reset_control *rstc)

if (!rstc)
return 0;
  
-	if (WARN_ON(IS_ERR(rstc)))

+   if (WARN_ON(IS_ERR(rstc)) || reset_control_is_array(rstc))
return -EINVAL;
  
  	if (rstc->rcdev->ops->status)

@@ -404,6 +485,16 @@ struct reset_control *__reset_control_get(struct device 
*dev, const char *id,
  }
  EXPORT_SYMBOL_GPL(__reset_control_get);
  
+static void reset_control_array_put(struct reset_control_array *resets)

+{
+   int i;
+
+   mutex_lock(_list_mutex);
+   for (i = 0; i < resets->num_rstcs; i++)

Re: [PATCH v4 4/4] soc/tegra: pmc: Use the new reset APIs to manage reset controllers

[Vivek Gautam]

Hi,

On Wed, May 31, 2017 at 7:53 PM, Jon Hunter <jonath...@nvidia.com> wrote:
>
> On 22/05/17 12:23, Vivek Gautam wrote:
>> Make use of reset_control_array_*() set of APIs to manage
>> an array of reset controllers available with the device.
>>
>> Cc: Jon Hunter <jonath...@nvidia.com>
>> Cc: Thierry Reding <tred...@nvidia.com>
>> Cc: Philipp Zabel <p.za...@pengutronix.de>
>> Signed-off-by: Vivek Gautam <vivek.gau...@codeaurora.org>
>> ---
>>  drivers/soc/tegra/pmc.c | 91 
>> +
>>  1 file changed, 31 insertions(+), 60 deletions(-)
>>
>> diff --git a/drivers/soc/tegra/pmc.c b/drivers/soc/tegra/pmc.c
>> index e233dd5dcab3..668f5d3d3635 100644
>> --- a/drivers/soc/tegra/pmc.c
>> +++ b/drivers/soc/tegra/pmc.c
>> @@ -124,8 +124,8 @@ struct tegra_powergate {
>>   unsigned int id;
>>   struct clk **clks;
>>   unsigned int num_clks;
>> - struct reset_control **resets;
>> - unsigned int num_resets;
>> + struct reset_control *reset;
>> + struct reset_control_array *resets;
>
> It's a shame we can't avoid this additional reset pointer, but maybe
> there is no good alternative for now. So ...
>
> Acked-by: Jon Hunter <jonath...@nvidia.com>
> Tested-by: Jon Hunter <jonath...@nvidia.com>

Thanks for the testing and Ack.

Best regards
Vivek

>
> Cheers
> Jon
>
> --
> nvpublic
> --
> 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


-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
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

[PATCH v4 0/4] reset: APIs to manage a list of resets

[Vivek Gautam]

Set of patches to support getting and de/asserting a list (array)
of reset controllers available with the device.
This series also contains reset controls patches for dwc3-of-simple
and tegra pmc drivers.
A small patch is added in this series to correctly re-order the
resource handling in dwc3_of_simple_remove().

The series is tested on torvald's master branch the device tree
patches to enable usb on db820c.

Changes since v3:
 - Squashed of_reset_control_get_count() patch in the second patch that
   adds the reset control array APIs.
 - The error path after getting count through of_reset_control_get_count()
   now returns NULL pointer in case when 'optional' flag is true.
 - Added code in reset_control_array_assert() to deassert the
   already asserted resets in the error case.
 - Using of_reset_control_array_get_optional_exclusive() in dwc3 patch
   to request the reset control array.
 - Added a patch to fix the order in which resources are handled in
   dwc3_of_simple_remove() path.
 - Added tegra_powergate->reset to take care of single reset control
   passed from the client drivers.

Changes since v2:
 - Addressed comments to make APIs inline with gpiod API.
 - Moved number of reset controls in 'struct reset_control_array'
   so that the footprint is reduced.
 - of_reset_control_array_get() and devm_reset_control_array_get()
   now return pointer to the newly created reset control array.
 - Added comments to mention that the reset control array APIs don't
   guarantee any particular order when handling the reset controls.
 - Dropped 'name' from reset_control_array' since the interface is meant
   for a bunch of anonymous resets that can all be asserted or deasserted
   in arbitrary order.
 - Fixed returns for APIs reported by kbuild.
 - Fixed 'for' clause guards reported by kbuild.

Changes since v1:
 - Addressed comment for error handling in of_reset_control_get_count()
 - Added patch to manage reset controller array.
 - Rebased dwc3-of-simple changes based on the new set of APIs
   for reset control array.
 - Added a patch for soc/tegra/pmc driver to use the new set of
   reset control array APIs.

Vivek Gautam (4):
  usb: dwc3: of-simple: Re-order resource handling in remove
  reset: Add APIs to manage array of resets
  usb: dwc3: of-simple: Add support to get resets for the device
  soc/tegra: pmc: Use the new reset APIs to manage reset controllers

 drivers/reset/core.c  | 204 ++
 drivers/soc/tegra/pmc.c   |  91 ++---
 drivers/usb/dwc3/dwc3-of-simple.c |  29 +-
 include/linux/reset.h |  93 +
 4 files changed, 354 insertions(+), 63 deletions(-)

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

--
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

[PATCH v4 2/4] reset: Add APIs to manage array of resets

[Vivek Gautam]

Many devices may want to request a bunch of resets
and control them. So it's better to manage them as an
array. Add APIs to _get(), _assert(), and _deassert()
an array of reset_control.
Note that, these APIs don't guarantee that the reset lines
managed in the array are handled in any particular order.

Cc: Felipe Balbi <ba...@kernel.org>
Cc: Jon Hunter <jonath...@nvidia.com>
Cc: Philipp Zabel <p.za...@pengutronix.de>
Signed-off-by: Vivek Gautam <vivek.gau...@codeaurora.org>
---
 drivers/reset/core.c  | 204 ++
 include/linux/reset.h |  93 +++
 2 files changed, 297 insertions(+)

diff --git a/drivers/reset/core.c b/drivers/reset/core.c
index cd739d2fa160..dfb782f862e0 100644
--- a/drivers/reset/core.c
+++ b/drivers/reset/core.c
@@ -465,3 +465,207 @@ int device_reset(struct device *dev)
return ret;
 }
 EXPORT_SYMBOL_GPL(device_reset);
+
+/**
+ * APIs to manage an array of reset controls.
+ */
+/**
+ * of_reset_control_get_count - Count number of resets available with a device
+ *
+ * @node: device node that contains 'resets'.
+ *
+ * Returns positive reset count on success, or error number on failure and
+ * on count being zero.
+ */
+static int of_reset_control_get_count(struct device_node *node)
+{
+   int count;
+
+   if (!node)
+   return -EINVAL;
+
+   count = of_count_phandle_with_args(node, "resets", "#reset-cells");
+   if (count == 0)
+   count = -ENOENT;
+
+   return count;
+}
+
+/**
+ * reset_control_array_assert: assert a list of resets
+ *
+ * @resets: reset control array holding info about the list of resets
+ *
+ * This API doesn't guarantee that the reset lines controlled by
+ * the reset array are asserted in any particular order.
+ *
+ * Returns 0 on success or error number on failure.
+ */
+int reset_control_array_assert(struct reset_control_array *resets)
+{
+   int ret, i;
+
+   if (!resets)
+   return 0;
+
+   if (IS_ERR(resets))
+   return -EINVAL;
+
+   for (i = 0; i < resets->num_rstcs; i++) {
+   ret = reset_control_assert(resets->rstc[i]);
+   if (ret)
+   goto err;
+   }
+
+   return 0;
+
+err:
+   while (i--)
+   reset_control_deassert(resets->rstc[i]);
+   return ret;
+}
+EXPORT_SYMBOL_GPL(reset_control_array_assert);
+
+/**
+ * reset_control_array_deassert: deassert a list of resets
+ *
+ * @resets: reset control array holding info about the list of resets
+ *
+ * This API doesn't guarantee that the reset lines controlled by
+ * the reset array are deasserted in any particular order.
+ *
+ * Returns 0 on success or error number on failure.
+ */
+int reset_control_array_deassert(struct reset_control_array *resets)
+{
+   int ret, i;
+
+   if (!resets)
+   return 0;
+
+   if (IS_ERR(resets))
+   return -EINVAL;
+
+   for (i = 0; i < resets->num_rstcs; i++) {
+   ret = reset_control_deassert(resets->rstc[i]);
+   if (ret)
+   goto err;
+   }
+
+   return 0;
+
+err:
+   while (i--)
+   reset_control_assert(resets->rstc[i]);
+   return ret;
+}
+EXPORT_SYMBOL_GPL(reset_control_array_deassert);
+
+static void devm_reset_control_array_release(struct device *dev, void *res)
+{
+   struct reset_control_array *resets = res;
+
+   reset_control_array_put(resets);
+}
+
+/**
+ * of_reset_control_array_get - Get a list of reset controls using
+ * device node.
+ *
+ * @np: device node for the device that requests the reset controls array
+ * @shared: whether reset controls are shared or not
+ * @optional: whether it is optional to get the reset controls
+ *
+ * Returns pointer to allocated reset_control_array on success or
+ * error on failure
+ */
+struct reset_control_array *
+of_reset_control_array_get(struct device_node *np, bool shared, bool optional)
+{
+   struct reset_control_array *resets;
+   struct reset_control *rstc;
+   int num, i;
+   void *err;
+
+   num = of_reset_control_get_count(np);
+   if (num < 0)
+   return optional ? NULL : ERR_PTR(num);
+
+   resets = kzalloc(sizeof(*resets) + sizeof(resets->rstc[0]) * num,
+GFP_KERNEL);
+   if (!resets)
+   return ERR_PTR(-ENOMEM);
+
+   for (i = 0; i < num; i++) {
+   rstc = __of_reset_control_get(np, NULL, i, shared, optional);
+   if (IS_ERR(rstc)) {
+   err = ERR_CAST(rstc);
+   goto err_rst;
+   }
+   resets->rstc[i] = rstc;
+   }
+   resets->num_rstcs = num;
+
+   return resets;
+
+err_rst:
+   while (--i >= 0)
+   reset_control_put(resets->rstc[i]);
+
+   

[PATCH v4 3/4] usb: dwc3: of-simple: Add support to get resets for the device

[Vivek Gautam]

Add support to get a list of resets available for the device.
These resets must be kept de-asserted until the device is
in use.

Cc: Felipe Balbi <ba...@kernel.org>
Cc: Philipp Zabel <p.za...@pengutronix.de>
Signed-off-by: Vivek Gautam <vivek.gau...@codeaurora.org>
---
 drivers/usb/dwc3/dwc3-of-simple.c | 27 +--
 1 file changed, 25 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/dwc3/dwc3-of-simple.c 
b/drivers/usb/dwc3/dwc3-of-simple.c
index a9bac09d3750..463b744d6688 100644
--- a/drivers/usb/dwc3/dwc3-of-simple.c
+++ b/drivers/usb/dwc3/dwc3-of-simple.c
@@ -29,11 +29,13 @@
 #include 
 #include 
 #include 
+#include 
 
 struct dwc3_of_simple {
struct device   *dev;
struct clk  **clks;
int num_clocks;
+   struct reset_control_array *resets;
 };
 
 static int dwc3_of_simple_clk_init(struct dwc3_of_simple *simple, int count)
@@ -96,9 +98,20 @@ static int dwc3_of_simple_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, simple);
simple->dev = dev;
 
+   simple->resets = of_reset_control_array_get_optional_exclusive(np);
+   if (IS_ERR(simple->resets)) {
+   ret = PTR_ERR(simple->resets);
+   dev_err(dev, "failed to get device resets, err=%d\n", ret);
+   return ret;
+   }
+
+   ret = reset_control_array_deassert(simple->resets);
+   if (ret)
+   goto err_resetc_put;
+
ret = dwc3_of_simple_clk_init(simple, of_clk_get_parent_count(np));
if (ret)
-   return ret;
+   goto err_resetc_assert;
 
ret = of_platform_populate(np, NULL, NULL, dev);
if (ret) {
@@ -107,7 +120,7 @@ static int dwc3_of_simple_probe(struct platform_device 
*pdev)
clk_put(simple->clks[i]);
}
 
-   return ret;
+   goto err_resetc_assert;
}
 
pm_runtime_set_active(dev);
@@ -115,6 +128,13 @@ static int dwc3_of_simple_probe(struct platform_device 
*pdev)
pm_runtime_get_sync(dev);
 
return 0;
+
+err_resetc_assert:
+   reset_control_array_assert(simple->resets);
+
+err_resetc_put:
+   reset_control_array_put(simple->resets);
+   return ret;
 }
 
 static int dwc3_of_simple_remove(struct platform_device *pdev)
@@ -130,6 +150,9 @@ static int dwc3_of_simple_remove(struct platform_device 
*pdev)
clk_put(simple->clks[i]);
}
 
+   reset_control_array_assert(simple->resets);
+   reset_control_array_put(simple->resets);
+
pm_runtime_put_sync(dev);
pm_runtime_disable(dev);
 
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

--
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

[PATCH v4 1/4] usb: dwc3: of-simple: Re-order resource handling in remove

[Vivek Gautam]

Move clock handling after of_platform_depopulate to achieve
a sequence that is reverse of the probe sequence.

Cc: Felipe Balbi <ba...@kernel.org>
Signed-off-by: Vivek Gautam <vivek.gau...@codeaurora.org>
---

 - new patch in this series.

 drivers/usb/dwc3/dwc3-of-simple.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/dwc3/dwc3-of-simple.c 
b/drivers/usb/dwc3/dwc3-of-simple.c
index fe414e7a9c78..a9bac09d3750 100644
--- a/drivers/usb/dwc3/dwc3-of-simple.c
+++ b/drivers/usb/dwc3/dwc3-of-simple.c
@@ -123,13 +123,13 @@ static int dwc3_of_simple_remove(struct platform_device 
*pdev)
struct device   *dev = >dev;
int i;
 
+   of_platform_depopulate(dev);
+
for (i = 0; i < simple->num_clocks; i++) {
clk_disable_unprepare(simple->clks[i]);
clk_put(simple->clks[i]);
}
 
-   of_platform_depopulate(dev);
-
pm_runtime_put_sync(dev);
pm_runtime_disable(dev);
 
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

--
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

[PATCH v4 4/4] soc/tegra: pmc: Use the new reset APIs to manage reset controllers

[Vivek Gautam]

Make use of reset_control_array_*() set of APIs to manage
an array of reset controllers available with the device.

Cc: Jon Hunter <jonath...@nvidia.com>
Cc: Thierry Reding <tred...@nvidia.com>
Cc: Philipp Zabel <p.za...@pengutronix.de>
Signed-off-by: Vivek Gautam <vivek.gau...@codeaurora.org>
---
 drivers/soc/tegra/pmc.c | 91 +
 1 file changed, 31 insertions(+), 60 deletions(-)

diff --git a/drivers/soc/tegra/pmc.c b/drivers/soc/tegra/pmc.c
index e233dd5dcab3..668f5d3d3635 100644
--- a/drivers/soc/tegra/pmc.c
+++ b/drivers/soc/tegra/pmc.c
@@ -124,8 +124,8 @@ struct tegra_powergate {
unsigned int id;
struct clk **clks;
unsigned int num_clks;
-   struct reset_control **resets;
-   unsigned int num_resets;
+   struct reset_control *reset;
+   struct reset_control_array *resets;
 };
 
 struct tegra_io_pad_soc {
@@ -348,32 +348,20 @@ static int tegra_powergate_enable_clocks(struct 
tegra_powergate *pg)
return err;
 }
 
-static int tegra_powergate_reset_assert(struct tegra_powergate *pg)
+static inline int tegra_powergate_reset_assert(struct tegra_powergate *pg)
 {
-   unsigned int i;
-   int err;
+   if (!IS_ERR_OR_NULL(pg->reset))
+   return reset_control_assert(pg->reset);
 
-   for (i = 0; i < pg->num_resets; i++) {
-   err = reset_control_assert(pg->resets[i]);
-   if (err)
-   return err;
-   }
-
-   return 0;
+   return reset_control_array_assert(pg->resets);
 }
 
-static int tegra_powergate_reset_deassert(struct tegra_powergate *pg)
+static inline int tegra_powergate_reset_deassert(struct tegra_powergate *pg)
 {
-   unsigned int i;
-   int err;
+   if (!IS_ERR_OR_NULL(pg->reset))
+   return reset_control_deassert(pg->reset);
 
-   for (i = 0; i < pg->num_resets; i++) {
-   err = reset_control_deassert(pg->resets[i]);
-   if (err)
-   return err;
-   }
-
-   return 0;
+   return reset_control_array_deassert(pg->resets);
 }
 
 static int tegra_powergate_power_up(struct tegra_powergate *pg,
@@ -566,8 +554,13 @@ int tegra_powergate_sequence_power_up(unsigned int id, 
struct clk *clk,
pg.id = id;
pg.clks = 
pg.num_clks = 1;
-   pg.resets = 
-   pg.num_resets = 1;
+
+   /*
+* Handle the reset control passed from the client separately.
+* So, the pmc will either have this single reset control, or,
+* have a list of reset controls managed by the driver on its own.
+*/
+   pg.reset = rst;
 
err = tegra_powergate_power_up(, false);
if (err)
@@ -755,45 +748,26 @@ static int tegra_powergate_of_get_clks(struct 
tegra_powergate *pg,
 static int tegra_powergate_of_get_resets(struct tegra_powergate *pg,
 struct device_node *np, bool off)
 {
-   struct reset_control *rst;
-   unsigned int i, count;
int err;
 
-   count = of_count_phandle_with_args(np, "resets", "#reset-cells");
-   if (count == 0)
-   return -ENODEV;
-
-   pg->resets = kcalloc(count, sizeof(rst), GFP_KERNEL);
-   if (!pg->resets)
-   return -ENOMEM;
-
-   for (i = 0; i < count; i++) {
-   pg->resets[i] = of_reset_control_get_by_index(np, i);
-   if (IS_ERR(pg->resets[i])) {
-   err = PTR_ERR(pg->resets[i]);
-   goto error;
-   }
-
-   if (off)
-   err = reset_control_assert(pg->resets[i]);
-   else
-   err = reset_control_deassert(pg->resets[i]);
-
-   if (err) {
-   reset_control_put(pg->resets[i]);
-   goto error;
-   }
+   pg->resets = of_reset_control_array_get_exclusive(np);
+   if (IS_ERR(pg->resets)) {
+   pr_err("failed to get device resets\n");
+   return PTR_ERR(pg->resets);
}
 
-   pg->num_resets = count;
+   if (off)
+   err = reset_control_array_assert(pg->resets);
+   else
+   err = reset_control_array_deassert(pg->resets);
 
-   return 0;
+   if (err)
+   goto put_reset;
 
-error:
-   while (i--)
-   reset_control_put(pg->resets[i]);
+   return 0;
 
-   kfree(pg->resets);
+put_reset:
+   reset_control_array_put(pg->resets);
 
return err;
 }
@@ -885,10 +859,7 @@ static void tegra_powergate_add(struct tegra_pmc *pmc, 
struct device_node *np)
pm_genpd_remove(>genpd);
 
 remove_resets:
-   while (pg->num_resets--)
-   reset_control_put(pg->resets[pg->num_resets]);
-
-   kfree(p

Re: [PATCH v5 3/3] phy: Group vendor specific phy drivers

[Vivek Gautam]

On 05/16/2017 03:40 PM, Kishon Vijay Abraham I wrote:

Hi Vivek,

On Thursday 11 May 2017 12:17 PM, Vivek Gautam wrote:

Adding vendor specific directories in phy to group
phy drivers under their respective vendor umbrella.

Also updated the MAINTAINERS file to reflect the correct
directory structure for phy drivers.

Signed-off-by: Vivek Gautam <vivek.gau...@codeaurora.org>
Acked-by: Heiko Stuebner <he...@sntech.de>
Acked-by: Viresh Kumar <viresh.ku...@linaro.org>
Acked-by: Krzysztof Kozlowski <k...@kernel.org>
Acked-by: Yoshihiro Shimoda <yoshihiro.shimoda...@renesas.com>
Reviewed-by: Jaehoon Chung <jh80.ch...@samsung.com>
Cc: Kishon Vijay Abraham I <kis...@ti.com>
Cc: David S. Miller <da...@davemloft.net>
Cc: Geert Uytterhoeven <geert+rene...@glider.be>
Cc: Yoshihiro Shimoda <yoshihiro.shimoda...@renesas.com>
Cc: Guenter Roeck <li...@roeck-us.net>
Cc: Heiko Stuebner <he...@sntech.de>
Cc: Viresh Kumar <viresh.ku...@linaro.org>
Cc: Maxime Ripard <maxime.rip...@free-electrons.com>
Cc: Chen-Yu Tsai <w...@csie.org>
Cc: Sylwester Nawrocki <s.nawro...@samsung.com>
Cc: Krzysztof Kozlowski <k...@kernel.org>
Cc: Jaehoon Chung <jh80.ch...@samsung.com>
Cc: Stephen Boyd <stephen.b...@linaro.org>
Cc: Martin Blumenstingl <martin.blumensti...@googlemail.com>
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-arm-...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Cc: linux-o...@vger.kernel.org
Cc: linux-renesas-...@vger.kernel.org
Cc: linux-rockc...@lists.infradead.org
Cc: linux-samsung-...@vger.kernel.org
Cc: linux-usb@vger.kernel.org
---

Changes since v4:
  - Reprepared the patch based on latest torvalds/master.
  - Added new directory for amlogic, since there's a new patch [1]
coming in for amlogic platforms.

Changes since v3:
  - Added 'Acked-by' and 'Reviewed by' tags received for this patch.
  - No functional change.

Changes since v2:
  - Rebased on linux-phy/next.
  - Took care of drivers added/removed for each vendors since v2.
  - Updated the 'Signed-off-by' tag with my current email id.

Changes from v1:
  - Updated the MAINTAINERS file to reflect the same change
in directory structure.
  - Removed PHY_PLAT config as pointed out by Kishon.
So we don't require the second patch in the v1 of this series:
[PATCH 2/2] arm: mach-spear: Enable PHY_PLAT to meet dependency
  - Renamed sunxi --> allwinner; rcar --> renesas.
  - Fixed error coming with qcom Makefile.

* Build tested multi_v7_defconfig.
* Build tested arm64 defconfig with all the involved configs enabled.

[1] https://patchwork.kernel.org/patch/9684303/


.
.

.
.

diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index afaf7b643eeb..b353ac603ea0 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -15,73 +15,6 @@ config GENERIC_PHY
  phy users can obtain reference to the PHY. All the users of this

.
.

.
.

-
+menu "Platform Phy drivers"

I don't think creating a new menu is required. I removed it and merged into
linux-phy.


Right. No need for a new menu. Thank you for fixing it and pushing out.

Best Regards
Vivek



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


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

--
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

Re: [PATCH v5 3/3] phy: Group vendor specific phy drivers

[Vivek Gautam]

On 05/12/2017 02:15 PM, Kishon Vijay Abraham I wrote:

Hi Vivek,

On Thursday 11 May 2017 12:17 PM, Vivek Gautam wrote:

Adding vendor specific directories in phy to group
phy drivers under their respective vendor umbrella.

Also updated the MAINTAINERS file to reflect the correct
directory structure for phy drivers.

Signed-off-by: Vivek Gautam <vivek.gau...@codeaurora.org>
Acked-by: Heiko Stuebner <he...@sntech.de>
Acked-by: Viresh Kumar <viresh.ku...@linaro.org>
Acked-by: Krzysztof Kozlowski <k...@kernel.org>
Acked-by: Yoshihiro Shimoda <yoshihiro.shimoda...@renesas.com>
Reviewed-by: Jaehoon Chung <jh80.ch...@samsung.com>
Cc: Kishon Vijay Abraham I <kis...@ti.com>
Cc: David S. Miller <da...@davemloft.net>
Cc: Geert Uytterhoeven <geert+rene...@glider.be>
Cc: Yoshihiro Shimoda <yoshihiro.shimoda...@renesas.com>
Cc: Guenter Roeck <li...@roeck-us.net>
Cc: Heiko Stuebner <he...@sntech.de>
Cc: Viresh Kumar <viresh.ku...@linaro.org>
Cc: Maxime Ripard <maxime.rip...@free-electrons.com>
Cc: Chen-Yu Tsai <w...@csie.org>
Cc: Sylwester Nawrocki <s.nawro...@samsung.com>
Cc: Krzysztof Kozlowski <k...@kernel.org>
Cc: Jaehoon Chung <jh80.ch...@samsung.com>
Cc: Stephen Boyd <stephen.b...@linaro.org>
Cc: Martin Blumenstingl <martin.blumensti...@googlemail.com>
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-arm-...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Cc: linux-o...@vger.kernel.org
Cc: linux-renesas-...@vger.kernel.org
Cc: linux-rockc...@lists.infradead.org
Cc: linux-samsung-...@vger.kernel.org
Cc: linux-usb@vger.kernel.org
---

Changes since v4:
  - Reprepared the patch based on latest torvalds/master.
  - Added new directory for amlogic, since there's a new patch [1]
coming in for amlogic platforms.

I don't prefer placeholder directories but this is not a placeholder directory
since phy-meson8b-usb2.c is already added in amlogic.


Right, since phy-meson8b-usb2.c was already there and phy-meson-gxl-usb2.c
is also coming, i decided to add this directory.

Btw, thank you for sending this patch. Will queue this once -rc1 is tagged.


Cool. Thanks Kishon.

Regards
Vivek



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


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

--
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

[PATCH v5 1/3] phy: qcom-usb: Remove unused ulpi phy header

[Vivek Gautam]

Ulpi phy header is not used for anything. Remove the same
from qcom-hs and qcom-hsic phy drivers.

Signed-off-by: Vivek Gautam <vivek.gau...@codeaurora.org>
Suggested-by: Stephen Boyd <stephen.b...@linaro.org>
Cc: Kishon Vijay Abraham I <kis...@ti.com>
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-arm-...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Cc: linux-usb@vger.kernel.org
---

Changes since v4:
 - None.

Changes since v3:
 - New patch added in the series.
   Removing headers as per Stephen's suggestion.

 drivers/phy/phy-qcom-usb-hs.c   | 2 --
 drivers/phy/phy-qcom-usb-hsic.c | 2 --
 2 files changed, 4 deletions(-)

diff --git a/drivers/phy/phy-qcom-usb-hs.c b/drivers/phy/phy-qcom-usb-hs.c
index 94dfbfd739c3..43704f4f23e9 100644
--- a/drivers/phy/phy-qcom-usb-hs.c
+++ b/drivers/phy/phy-qcom-usb-hs.c
@@ -15,8 +15,6 @@
 #include 
 #include 
 
-#include "ulpi_phy.h"
-
 #define ULPI_PWR_CLK_MNG_REG   0x88
 # define ULPI_PWR_OTG_COMP_DISABLE BIT(0)
 
diff --git a/drivers/phy/phy-qcom-usb-hsic.c b/drivers/phy/phy-qcom-usb-hsic.c
index 47690f9945b9..6dcaf04fa367 100644
--- a/drivers/phy/phy-qcom-usb-hsic.c
+++ b/drivers/phy/phy-qcom-usb-hsic.c
@@ -13,8 +13,6 @@
 #include 
 #include 
 
-#include "ulpi_phy.h"
-
 #define ULPI_HSIC_CFG  0x30
 #define ULPI_HSIC_IO_CAL   0x33
 
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

--
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

[PATCH v5 2/3] phy: Move ULPI phy header out of drivers to include path

[Vivek Gautam]

Although ULPI phy is currently being used by tusb1210,
there can be other consumers too in future. So move this
to the includes path for phy.

Signed-off-by: Vivek Gautam <vivek.gau...@codeaurora.org>
Cc: Stephen Boyd <stephen.b...@linaro.org>
Cc: Heikki Krogerus <heikki.kroge...@linux.intel.com>
Cc: Kishon Vijay Abraham I <kis...@ti.com>
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-ker...@vger.kernel.org
Cc: linux-o...@vger.kernel.org
Cc: linux-usb@vger.kernel.org
---

Changes since v4:
 - None.

Changes since v3:
 - Removed qcom phy changes, since patch - 1/3 addressed that now.

Changes since v2:
 - Updated the location for this header in drivers using it.

 drivers/phy/phy-tusb1210.c| 3 +--
 {drivers => include/linux}/phy/ulpi_phy.h | 0
 2 files changed, 1 insertion(+), 2 deletions(-)
 rename {drivers => include/linux}/phy/ulpi_phy.h (100%)

diff --git a/drivers/phy/phy-tusb1210.c b/drivers/phy/phy-tusb1210.c
index 4f6d5e71507d..bb3fb031c478 100644
--- a/drivers/phy/phy-tusb1210.c
+++ b/drivers/phy/phy-tusb1210.c
@@ -12,8 +12,7 @@
 #include 
 #include 
 #include 
-
-#include "ulpi_phy.h"
+#include 
 
 #define TUSB1210_VENDOR_SPECIFIC2  0x80
 #define TUSB1210_VENDOR_SPECIFIC2_IHSTX_SHIFT  0
diff --git a/drivers/phy/ulpi_phy.h b/include/linux/phy/ulpi_phy.h
similarity index 100%
rename from drivers/phy/ulpi_phy.h
rename to include/linux/phy/ulpi_phy.h
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

--
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

[PATCH v5 3/3] phy: Group vendor specific phy drivers

[Vivek Gautam]

Adding vendor specific directories in phy to group
phy drivers under their respective vendor umbrella.

Also updated the MAINTAINERS file to reflect the correct
directory structure for phy drivers.

Signed-off-by: Vivek Gautam <vivek.gau...@codeaurora.org>
Acked-by: Heiko Stuebner <he...@sntech.de>
Acked-by: Viresh Kumar <viresh.ku...@linaro.org>
Acked-by: Krzysztof Kozlowski <k...@kernel.org>
Acked-by: Yoshihiro Shimoda <yoshihiro.shimoda...@renesas.com>
Reviewed-by: Jaehoon Chung <jh80.ch...@samsung.com>
Cc: Kishon Vijay Abraham I <kis...@ti.com>
Cc: David S. Miller <da...@davemloft.net>
Cc: Geert Uytterhoeven <geert+rene...@glider.be>
Cc: Yoshihiro Shimoda <yoshihiro.shimoda...@renesas.com>
Cc: Guenter Roeck <li...@roeck-us.net>
Cc: Heiko Stuebner <he...@sntech.de>
Cc: Viresh Kumar <viresh.ku...@linaro.org>
Cc: Maxime Ripard <maxime.rip...@free-electrons.com>
Cc: Chen-Yu Tsai <w...@csie.org>
Cc: Sylwester Nawrocki <s.nawro...@samsung.com>
Cc: Krzysztof Kozlowski <k...@kernel.org>
Cc: Jaehoon Chung <jh80.ch...@samsung.com>
Cc: Stephen Boyd <stephen.b...@linaro.org>
Cc: Martin Blumenstingl <martin.blumensti...@googlemail.com>
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-arm-...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Cc: linux-o...@vger.kernel.org
Cc: linux-renesas-...@vger.kernel.org
Cc: linux-rockc...@lists.infradead.org
Cc: linux-samsung-...@vger.kernel.org
Cc: linux-usb@vger.kernel.org
---

Changes since v4:
 - Reprepared the patch based on latest torvalds/master.
 - Added new directory for amlogic, since there's a new patch [1]
   coming in for amlogic platforms.

Changes since v3:
 - Added 'Acked-by' and 'Reviewed by' tags received for this patch.
 - No functional change.

Changes since v2:
 - Rebased on linux-phy/next.
 - Took care of drivers added/removed for each vendors since v2.
 - Updated the 'Signed-off-by' tag with my current email id.

Changes from v1:
 - Updated the MAINTAINERS file to reflect the same change
   in directory structure.
 - Removed PHY_PLAT config as pointed out by Kishon.
   So we don't require the second patch in the v1 of this series:
   [PATCH 2/2] arm: mach-spear: Enable PHY_PLAT to meet dependency
 - Renamed sunxi --> allwinner; rcar --> renesas.
 - Fixed error coming with qcom Makefile.

* Build tested multi_v7_defconfig.
* Build tested arm64 defconfig with all the involved configs enabled.

[1] https://patchwork.kernel.org/patch/9684303/

 MAINTAINERS|  18 +-
 drivers/phy/Kconfig| 493 +
 drivers/phy/Makefile   |  70 +--
 drivers/phy/allwinner/Kconfig  |  31 ++
 drivers/phy/allwinner/Makefile |   2 +
 drivers/phy/{ => allwinner}/phy-sun4i-usb.c|   0
 drivers/phy/{ => allwinner}/phy-sun9i-usb.c|   0
 drivers/phy/amlogic/Kconfig|  14 +
 drivers/phy/amlogic/Makefile   |   1 +
 drivers/phy/{ => amlogic}/phy-meson8b-usb2.c   |   0
 drivers/phy/broadcom/Kconfig   |  55 +++
 drivers/phy/broadcom/Makefile  |   6 +
 drivers/phy/{ => broadcom}/phy-bcm-cygnus-pcie.c   |   0
 drivers/phy/{ => broadcom}/phy-bcm-kona-usb2.c |   0
 drivers/phy/{ => broadcom}/phy-bcm-ns-usb2.c   |   0
 drivers/phy/{ => broadcom}/phy-bcm-ns-usb3.c   |   0
 drivers/phy/{ => broadcom}/phy-bcm-ns2-pcie.c  |   0
 drivers/phy/{ => broadcom}/phy-brcm-sata.c |   0
 drivers/phy/hisilicon/Kconfig  |  20 +
 drivers/phy/hisilicon/Makefile |   2 +
 drivers/phy/{ => hisilicon}/phy-hi6220-usb.c   |   0
 drivers/phy/{ => hisilicon}/phy-hix5hd2-sata.c |   0
 drivers/phy/marvell/Kconfig|  50 +++
 drivers/phy/marvell/Makefile   |   6 +
 drivers/phy/{ => marvell}/phy-armada375-usb2.c |   0
 drivers/phy/{ => marvell}/phy-berlin-sata.c|   0
 drivers/phy/{ => marvell}/phy-berlin-usb.c |   0
 drivers/phy/{ => marvell}/phy-mvebu-sata.c |   0
 drivers/phy/{ => marvell}/phy-pxa-28nm-hsic.c  |   0
 drivers/phy/{ => marvell}/phy-pxa-28nm-usb2.c  |   0
 drivers/phy/qualcomm/Kconfig   |  58 +++
 drivers/phy/qualcomm/Makefile  |   9 +
 drivers/phy/{ => qualcomm}/phy-qcom-apq8064-sata.c |   0
 drivers/phy/{ => qualcomm}/phy-qcom-ipq806x-sata.c |   0
 drivers/phy/{ => qualcomm}/phy-qcom-qmp.c  |   0
 drivers/phy/{ => qualcomm}/phy-qcom-qusb2.c|   0
 drivers/phy/{ => qualcomm}/phy-qcom-ufs-i.h|   0
 drivers/phy/{ => qualcomm}/phy-qcom-ufs-qmp-14nm.c |   0
 drivers/phy/{ => qualcomm}/phy-qcom-ufs-qmp-14nm.h |   0
 drivers/phy/{ => qualcomm}/phy-qcom-uf

Re: [PATCH V3 4/4] soc/tegra: pmc: Use the new reset APIs to manage reset controllers

[Vivek Gautam]

On Tue, Apr 25, 2017 at 4:41 PM, Jon Hunter <jonath...@nvidia.com> wrote:
>
> On 25/04/17 12:06, Vivek Gautam wrote:
>> On 04/25/2017 04:24 PM, Jon Hunter wrote:
>>> On 25/04/17 11:33, Philipp Zabel wrote:
>>>> On Tue, 2017-04-25 at 11:05 +0100, Jon Hunter wrote:
>>>>> On 25/04/17 05:15, Vivek Gautam wrote:
>>>>>> On 04/24/2017 06:15 PM, Jon Hunter wrote:
>>>>>>> On 18/04/17 12:21, Vivek Gautam wrote:
>>>>>>>> Make use of reset_control_array_*() set of APIs to manage
>>>>>>>> an array of reset controllers available with the device.
>>>>>>> Before we apply this patch, I need to check to see if the order of
>>>>>>> the
>>>>>>> resets managed by the PMC driver matter. Today the order of the
>>>>>>> resets
>>>>>>> is determined by the order they appear in the DT node and although
>>>>>>> the
>>>>>>> new APIs work in the same way they do not guarantee this. So let me
>>>>>>> check to see if we can any concerns about ordering here. Otherwise
>>>>>>> would
>>>>>>> be nice to use these APIs.
>>>>>> Right, that will be perfect.
>>>>> So I don't see any restrictions here and so I think this change is
>>>>> fine.
>>>> Thank you for checking.
>>>>
>>>>> BTW, for the DT case, is there any reason why we don't just say the
>>>>> order will be determine by the order the resets are list in the DT
>>>>> node?
>>>> I'd rather not make any promises, so I don't have to care about keeping
>>>> them. This makes it easier to think about and allows for more freedom in
>>>> changing the core code if needed.
>>>>
>>>> What if in the future there is a use case for enabling a bunch of resets
>>>> by flipping a number of bits in a single register at the same time? Or
>>>> if people accidentally depend on the ordering when in reality there is a
>>>> small delay necessary between assertions that just happens to be hidden
>>>> by the framework overhead?
>>>>
>>>> If there is a use case for an array of reset controls that must be
>>>> (de)asserted in a fixed order and doesn't need any delay between the
>>>> steps and is not suitable to be described by named resets for some
>>>> reason, we can discuss this. Until then, I'm happy that tegra pmc can
>>>> handle arrays without any particular ordering.
>>> OK, makes sense.
>>
>> Thanks Jon for testing this.
>
> Not tested yet :-)
>
> However, I will test this just to confirm. Are you planning on sending
> out a v4 soon?

Yes, I will send a v4 soon this week.

Thanks
Vivek


-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
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

Re: [PATCH V3 4/4] soc/tegra: pmc: Use the new reset APIs to manage reset controllers

[Vivek Gautam]

On 04/25/2017 04:24 PM, Jon Hunter wrote:

On 25/04/17 11:33, Philipp Zabel wrote:

On Tue, 2017-04-25 at 11:05 +0100, Jon Hunter wrote:

On 25/04/17 05:15, Vivek Gautam wrote:

On 04/24/2017 06:15 PM, Jon Hunter wrote:

On 18/04/17 12:21, Vivek Gautam wrote:

Make use of reset_control_array_*() set of APIs to manage
an array of reset controllers available with the device.

Before we apply this patch, I need to check to see if the order of the
resets managed by the PMC driver matter. Today the order of the resets
is determined by the order they appear in the DT node and although the
new APIs work in the same way they do not guarantee this. So let me
check to see if we can any concerns about ordering here. Otherwise would
be nice to use these APIs.

Right, that will be perfect.

So I don't see any restrictions here and so I think this change is fine.

Thank you for checking.


BTW, for the DT case, is there any reason why we don't just say the
order will be determine by the order the resets are list in the DT node?

I'd rather not make any promises, so I don't have to care about keeping
them. This makes it easier to think about and allows for more freedom in
changing the core code if needed.

What if in the future there is a use case for enabling a bunch of resets
by flipping a number of bits in a single register at the same time? Or
if people accidentally depend on the ordering when in reality there is a
small delay necessary between assertions that just happens to be hidden
by the framework overhead?

If there is a use case for an array of reset controls that must be
(de)asserted in a fixed order and doesn't need any delay between the
steps and is not suitable to be described by named resets for some
reason, we can discuss this. Until then, I'm happy that tegra pmc can
handle arrays without any particular ordering.

OK, makes sense.


Thanks Jon for testing this.

Best Regards
Vivek


Thanks
Jon



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

--
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

Re: [PATCH V3 4/4] soc/tegra: pmc: Use the new reset APIs to manage reset controllers

[Vivek Gautam]

On 04/24/2017 06:15 PM, Jon Hunter wrote:

On 18/04/17 12:21, Vivek Gautam wrote:

Make use of reset_control_array_*() set of APIs to manage
an array of reset controllers available with the device.

Before we apply this patch, I need to check to see if the order of the
resets managed by the PMC driver matter. Today the order of the resets
is determined by the order they appear in the DT node and although the
new APIs work in the same way they do not guarantee this. So let me
check to see if we can any concerns about ordering here. Otherwise would
be nice to use these APIs.


Right, that will be perfect.

Best regards
Vivek



Cheers
Jon



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

--
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

Re: [PATCH V3 3/4] usb: dwc3: of-simple: Add support to get resets for the device

[Vivek Gautam]

On 04/19/2017 04:02 PM, Philipp Zabel wrote:

On Tue, 2017-04-18 at 16:51 +0530, Vivek Gautam wrote:

Add support to get a list of resets available for the device.
These resets must be kept de-asserted until the device is
in use.

Cc: Felipe Balbi <ba...@kernel.org>
Cc: Philipp Zabel <p.za...@pengutronix.de>
Signed-off-by: Vivek Gautam <vivek.gau...@codeaurora.org>
---
  drivers/usb/dwc3/dwc3-of-simple.c | 36 
  1 file changed, 36 insertions(+)

diff --git a/drivers/usb/dwc3/dwc3-of-simple.c 
b/drivers/usb/dwc3/dwc3-of-simple.c
index fe414e7a9c78..9116df649f0b 100644
--- a/drivers/usb/dwc3/dwc3-of-simple.c
+++ b/drivers/usb/dwc3/dwc3-of-simple.c
@@ -29,13 +29,39 @@
  #include 
  #include 
  #include 
+#include 
  
  struct dwc3_of_simple {

struct device   *dev;
struct clk  **clks;
int num_clocks;
+   struct reset_control_array *resets;
  };
  
+static int dwc3_of_simple_reset_init(struct dwc3_of_simple *simple)

+{
+   struct device   *dev = simple->dev;
+   int ret;
+
+   simple->resets = of_reset_control_array_get_exclusive(dev->of_node);
+   if (IS_ERR(simple->resets)) {
+   ret = PTR_ERR(simple->resets);
+   if (ret == -ENOENT)
+   /* not all controllers required resets */
+   return 0;

If you use the of_reset_control_array_get_optional_exclusive variant,
you can remove the three lines directly above.


No, it's a little tricky here.
of_reset_control_get_count() returns an error code, that we then return from
of_reset_control_array_get().

This is something that tegra/pmc driver required (return errorno in case 
count

of reset controls is zero.

So we handle that error separately here.




+   dev_err(dev, "failed to get device resets\n");

It would be nice to print the error code here.


Sure.




+   return ret;
+   }
+
+   ret = reset_control_array_deassert(simple->resets);
+   if (ret) {
+   reset_control_array_put(simple->resets);
+   return ret;
+   }
+
+   return 0;
+}
+
  static int dwc3_of_simple_clk_init(struct dwc3_of_simple *simple, int count)
  {
struct device   *dev = simple->dev;
@@ -100,6 +126,10 @@ static int dwc3_of_simple_probe(struct platform_device 
*pdev)
if (ret)
return ret;
  
+	ret = dwc3_of_simple_reset_init(simple);

+   if (ret)
+   return ret;
+

I would just move the contents of dwc3_of_simple_reset_init here and add
a goto error path at the end of dwc3_of_simple_clk_init to handle the
reset control cleanup as needed.


Okay, i can restructure it.




ret = of_platform_populate(np, NULL, NULL, dev);
if (ret) {
for (i = 0; i < simple->num_clocks; i++) {
@@ -107,6 +137,9 @@ static int dwc3_of_simple_probe(struct platform_device 
*pdev)
clk_put(simple->clks[i]);
}
  
+		reset_control_array_assert(simple->resets);

+   reset_control_array_put(simple->resets);
+
return ret;
}
  
@@ -128,6 +161,9 @@ static int dwc3_of_simple_remove(struct platform_device *pdev)

clk_put(simple->clks[i]);
}
  
+	reset_control_array_assert(simple->resets);

+   reset_control_array_put(simple->resets);
+

Must the reset be asserted before of_platform_depopulate?


Right, the order must be taken care of here. Will change this.




of_platform_depopulate(dev);

Given the order above, I'd expect the reset cleanup here.


Sure.




pm_runtime_put_sync(dev);

regards
Philipp


Thanks for reviewing.

Best Regards
Vivek

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

--
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

Re: [PATCH V3 2/4] reset: Add APIs to manage array of resets

[Vivek Gautam]

Hi Philipp,


On 04/19/2017 04:01 PM, Philipp Zabel wrote:

On Tue, 2017-04-18 at 16:51 +0530, Vivek Gautam wrote:

Many devices may want to request a bunch of resets
and control them. So it's better to manage them as an
array. Add APIs to _get(), _assert(), and _deassert()
an array of reset_control.

Thanks! This looks good to me, one small issue below.


Cc: Philipp Zabel <p.za...@pengutronix.de>
Signed-off-by: Vivek Gautam <vivek.gau...@codeaurora.org>
---
  drivers/reset/core.c  | 177 ++
  include/linux/reset.h |  93 ++
  2 files changed, 270 insertions(+)

diff --git a/drivers/reset/core.c b/drivers/reset/core.c
index f0a06a7aca93..54bd3be5e7a4 100644
--- a/drivers/reset/core.c
+++ b/drivers/reset/core.c
@@ -488,3 +488,180 @@ int of_reset_control_get_count(struct device_node *node)
return count;
  }
  EXPORT_SYMBOL_GPL(of_reset_control_get_count);
+
+/**
+ * APIs to manage an array of reset controls.
+ */
+/**
+ * reset_control_array_assert: assert a list of resets
+ *
+ * @resets: reset control array holding info about the list of resets
+ *
+ * This API doesn't guarantee that the reset lines controlled by
+ * the reset array are asserted in any particular order.
+ *
+ * Returns 0 on success or error number on failure.
+ */
+int reset_control_array_assert(struct reset_control_array *resets)
+{
+   int ret, i;
+
+   if (!resets)
+   return 0;
+
+   if (IS_ERR(resets))
+   return -EINVAL;
+
+   for (i = 0; i < resets->num_rstcs; i++) {
+   ret = reset_control_assert(resets->rstc[i]);
+   if (ret)
+   return ret;

This should try to deassert the already asserted resets in the error
case.


I assumed that the user will call _assert in case of failure, driver removal
or may be suspend, and thought that we may not care even if the _assert
failed. But i see now that we also care about the (de)assert count, so that
the shared resets are handled properly.

Will add the core to deassert the already asserted resets in error case.

Thanks




+   }
+
+   return 0;
+}
+EXPORT_SYMBOL_GPL(reset_control_array_assert);
+
+/**
+ * reset_control_array_deassert: deassert a list of resets
+ *
+ * @resets: reset control array holding info about the list of resets
+ *
+ * This API doesn't guarantee that the reset lines controlled by
+ * the reset array are deasserted in any particular order.
+ *
+ * Returns 0 on success or error number on failure.
+ */
+int reset_control_array_deassert(struct reset_control_array *resets)
+{
+   int ret, i;
+
+   if (!resets)
+   return 0;
+
+   if (IS_ERR(resets))
+   return -EINVAL;
+
+   for (i = 0; i < resets->num_rstcs; i++) {
+   ret = reset_control_deassert(resets->rstc[i]);
+   if (ret)
+   goto err;
+   }
+
+   return 0;
+
+err:
+   while (i--)
+   reset_control_assert(resets->rstc[i]);
+   return ret;
+}
+EXPORT_SYMBOL_GPL(reset_control_array_deassert);

As this already does.


Yea, like this one.

Best Regards
Vivek



regards
Philipp



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

--
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

Re: [PATCH V3 1/4] reset: Add API to count number of reset available with device

[Vivek Gautam]

On 04/19/2017 03:55 PM, Philipp Zabel wrote:

On Tue, 2017-04-18 at 16:51 +0530, Vivek Gautam wrote:

Count number of reset phandles available with the device node
to know the resets a given device has.

Cc: Philipp Zabel <p.za...@pengutronix.de>
Signed-off-by: Vivek Gautam <vivek.gau...@codeaurora.org>
---
  drivers/reset/core.c  | 23 +++
  include/linux/reset.h |  6 ++
  2 files changed, 29 insertions(+)

diff --git a/drivers/reset/core.c b/drivers/reset/core.c
index cd739d2fa160..f0a06a7aca93 100644
--- a/drivers/reset/core.c
+++ b/drivers/reset/core.c
@@ -465,3 +465,26 @@ int device_reset(struct device *dev)
return ret;
  }
  EXPORT_SYMBOL_GPL(device_reset);
+
+/**
+ * of_reset_control_get_count - Count number of resets available with a device
+ *
+ * @node: device node that contains 'resets'.
+ *
+ * Returns positive reset count on success, or error number on failure and
+ * on count being zero.
+ */
+int of_reset_control_get_count(struct device_node *node)
+{
+   int count;
+
+   if (!node)
+   return -EINVAL;
+
+   count = of_count_phandle_with_args(node, "resets", "#reset-cells");
+   if (count == 0)
+   count = -ENOENT;
+
+   return count;
+}
+EXPORT_SYMBOL_GPL(of_reset_control_get_count);

This doesn't need to be public anymore. You can make it static and merge
it into the second patch.


Thanks for reviewing the series.
Sure, make sense to make it static and squash in the second patch.

Best Regards
Vivek



regards
Philipp



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

--
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

[PATCH V3 2/4] reset: Add APIs to manage array of resets

[Vivek Gautam]

Many devices may want to request a bunch of resets
and control them. So it's better to manage them as an
array. Add APIs to _get(), _assert(), and _deassert()
an array of reset_control.

Cc: Philipp Zabel <p.za...@pengutronix.de>
Signed-off-by: Vivek Gautam <vivek.gau...@codeaurora.org>
---
 drivers/reset/core.c  | 177 ++
 include/linux/reset.h |  93 ++
 2 files changed, 270 insertions(+)

diff --git a/drivers/reset/core.c b/drivers/reset/core.c
index f0a06a7aca93..54bd3be5e7a4 100644
--- a/drivers/reset/core.c
+++ b/drivers/reset/core.c
@@ -488,3 +488,180 @@ int of_reset_control_get_count(struct device_node *node)
return count;
 }
 EXPORT_SYMBOL_GPL(of_reset_control_get_count);
+
+/**
+ * APIs to manage an array of reset controls.
+ */
+/**
+ * reset_control_array_assert: assert a list of resets
+ *
+ * @resets: reset control array holding info about the list of resets
+ *
+ * This API doesn't guarantee that the reset lines controlled by
+ * the reset array are asserted in any particular order.
+ *
+ * Returns 0 on success or error number on failure.
+ */
+int reset_control_array_assert(struct reset_control_array *resets)
+{
+   int ret, i;
+
+   if (!resets)
+   return 0;
+
+   if (IS_ERR(resets))
+   return -EINVAL;
+
+   for (i = 0; i < resets->num_rstcs; i++) {
+   ret = reset_control_assert(resets->rstc[i]);
+   if (ret)
+   return ret;
+   }
+
+   return 0;
+}
+EXPORT_SYMBOL_GPL(reset_control_array_assert);
+
+/**
+ * reset_control_array_deassert: deassert a list of resets
+ *
+ * @resets: reset control array holding info about the list of resets
+ *
+ * This API doesn't guarantee that the reset lines controlled by
+ * the reset array are deasserted in any particular order.
+ *
+ * Returns 0 on success or error number on failure.
+ */
+int reset_control_array_deassert(struct reset_control_array *resets)
+{
+   int ret, i;
+
+   if (!resets)
+   return 0;
+
+   if (IS_ERR(resets))
+   return -EINVAL;
+
+   for (i = 0; i < resets->num_rstcs; i++) {
+   ret = reset_control_deassert(resets->rstc[i]);
+   if (ret)
+   goto err;
+   }
+
+   return 0;
+
+err:
+   while (i--)
+   reset_control_assert(resets->rstc[i]);
+   return ret;
+}
+EXPORT_SYMBOL_GPL(reset_control_array_deassert);
+
+static void devm_reset_control_array_release(struct device *dev, void *res)
+{
+   struct reset_control_array *resets = res;
+
+   reset_control_array_put(resets);
+}
+
+/**
+ * of_reset_control_array_get - Get a list of reset controls using
+ * device node.
+ *
+ * @np: device node for the device that requests the reset controls array
+ * @shared: whether reset controls are shared or not
+ * @optional: whether it is optional to get the reset controls
+ *
+ * Returns pointer to allocated reset_control_array on success or
+ * error on failure
+ */
+struct reset_control_array *
+of_reset_control_array_get(struct device_node *np, bool shared, bool optional)
+{
+   struct reset_control_array *resets;
+   struct reset_control *rstc;
+   int num, i;
+   void *err;
+
+   num = of_reset_control_get_count(np);
+   if (num < 0)
+   return ERR_PTR(num);
+
+   resets = kzalloc(sizeof(*resets) + sizeof(resets->rstc[0]) * num,
+GFP_KERNEL);
+   if (!resets)
+   return ERR_PTR(-ENOMEM);
+
+   for (i = 0; i < num; i++) {
+   rstc = __of_reset_control_get(np, NULL, i, shared, optional);
+   if (IS_ERR(rstc)) {
+   err = ERR_CAST(rstc);
+   goto err_rst;
+   }
+   resets->rstc[i] = rstc;
+   }
+   resets->num_rstcs = num;
+
+   return resets;
+
+err_rst:
+   while (--i >= 0)
+   reset_control_put(resets->rstc[i]);
+
+   kfree(resets);
+
+   return err;
+}
+EXPORT_SYMBOL_GPL(of_reset_control_array_get);
+
+/**
+ * devm_reset_control_array_get - Resource managed reset control array get
+ *
+ * @dev: device that requests the list of reset controls
+ * @shared: whether reset controls are shared or not
+ * @optional: whether it is optional to get the reset controls
+ *
+ * The reset control array APIs are intended for a list of resets
+ * that just have to be asserted or deasserted, without any
+ * requirements on the order.
+ *
+ * Returns pointer to allocated reset_control_array on success or
+ * error on failure
+ */
+struct reset_control_array *
+devm_reset_control_array_get(struct device *dev, bool shared, bool optional)
+{
+   struct reset_control_array **devres;
+   struct reset_control_array *resets;
+
+   devres = devres_alloc(devm_reset_control_array

[PATCH V3 4/4] soc/tegra: pmc: Use the new reset APIs to manage reset controllers

[Vivek Gautam]

Make use of reset_control_array_*() set of APIs to manage
an array of reset controllers available with the device.

Cc: Thierry Reding <tred...@nvidia.com>
Cc: Philipp Zabel <p.za...@pengutronix.de>
Signed-off-by: Vivek Gautam <vivek.gau...@codeaurora.org>
---
 drivers/soc/tegra/pmc.c | 99 ++---
 1 file changed, 36 insertions(+), 63 deletions(-)

diff --git a/drivers/soc/tegra/pmc.c b/drivers/soc/tegra/pmc.c
index e233dd5dcab3..4d039fa3db1b 100644
--- a/drivers/soc/tegra/pmc.c
+++ b/drivers/soc/tegra/pmc.c
@@ -124,8 +124,7 @@ struct tegra_powergate {
unsigned int id;
struct clk **clks;
unsigned int num_clks;
-   struct reset_control **resets;
-   unsigned int num_resets;
+   struct reset_control_array *resets;
 };
 
 struct tegra_io_pad_soc {
@@ -348,32 +347,14 @@ static int tegra_powergate_enable_clocks(struct 
tegra_powergate *pg)
return err;
 }
 
-static int tegra_powergate_reset_assert(struct tegra_powergate *pg)
+static inline int tegra_powergate_reset_assert(struct tegra_powergate *pg)
 {
-   unsigned int i;
-   int err;
-
-   for (i = 0; i < pg->num_resets; i++) {
-   err = reset_control_assert(pg->resets[i]);
-   if (err)
-   return err;
-   }
-
-   return 0;
+   return reset_control_array_assert(pg->resets);
 }
 
-static int tegra_powergate_reset_deassert(struct tegra_powergate *pg)
+static inline int tegra_powergate_reset_deassert(struct tegra_powergate *pg)
 {
-   unsigned int i;
-   int err;
-
-   for (i = 0; i < pg->num_resets; i++) {
-   err = reset_control_deassert(pg->resets[i]);
-   if (err)
-   return err;
-   }
-
-   return 0;
+   return reset_control_array_deassert(pg->resets);
 }
 
 static int tegra_powergate_power_up(struct tegra_powergate *pg,
@@ -558,6 +539,7 @@ int tegra_powergate_sequence_power_up(unsigned int id, 
struct clk *clk,
  struct reset_control *rst)
 {
struct tegra_powergate pg;
+   struct reset_control_array *resets;
int err;
 
if (!tegra_powergate_is_available(id))
@@ -566,12 +548,25 @@ int tegra_powergate_sequence_power_up(unsigned int id, 
struct clk *clk,
pg.id = id;
pg.clks = 
pg.num_clks = 1;
-   pg.resets = 
-   pg.num_resets = 1;
+
+   resets = kzalloc(sizeof(*resets) + sizeof(resets->rstc[0]) * 1,
+GFP_KERNEL);
+   if (!resets)
+   return -ENOMEM;
+
+   resets->rstc[0] = rst;
+   pg.resets = resets;
 
err = tegra_powergate_power_up(, false);
-   if (err)
+   if (err) {
pr_err("failed to turn on partition %d: %d\n", id, err);
+   goto free_reset;
+   }
+
+   return 0;
+
+free_reset:
+   kfree(resets);
 
return err;
 }
@@ -755,45 +750,26 @@ static int tegra_powergate_of_get_clks(struct 
tegra_powergate *pg,
 static int tegra_powergate_of_get_resets(struct tegra_powergate *pg,
 struct device_node *np, bool off)
 {
-   struct reset_control *rst;
-   unsigned int i, count;
int err;
 
-   count = of_count_phandle_with_args(np, "resets", "#reset-cells");
-   if (count == 0)
-   return -ENODEV;
-
-   pg->resets = kcalloc(count, sizeof(rst), GFP_KERNEL);
-   if (!pg->resets)
-   return -ENOMEM;
-
-   for (i = 0; i < count; i++) {
-   pg->resets[i] = of_reset_control_get_by_index(np, i);
-   if (IS_ERR(pg->resets[i])) {
-   err = PTR_ERR(pg->resets[i]);
-   goto error;
-   }
-
-   if (off)
-   err = reset_control_assert(pg->resets[i]);
-   else
-   err = reset_control_deassert(pg->resets[i]);
-
-   if (err) {
-   reset_control_put(pg->resets[i]);
-   goto error;
-   }
+   pg->resets = of_reset_control_array_get_exclusive(np);
+   if (IS_ERR(pg->resets)) {
+   pr_err("failed to get device resets\n");
+   return PTR_ERR(pg->resets);
}
 
-   pg->num_resets = count;
+   if (off)
+   err = reset_control_array_assert(pg->resets);
+   else
+   err = reset_control_array_deassert(pg->resets);
 
-   return 0;
+   if (err)
+   goto put_reset;
 
-error:
-   while (i--)
-   reset_control_put(pg->resets[i]);
+   return 0;
 
-   kfree(pg->resets);
+put_reset:
+   reset_control_array_put(pg->resets);
 
return err;
 }
@@ -885,10 +861,7 @@ static void tegra_

[PATCH V3 1/4] reset: Add API to count number of reset available with device

[Vivek Gautam]

Count number of reset phandles available with the device node
to know the resets a given device has.

Cc: Philipp Zabel <p.za...@pengutronix.de>
Signed-off-by: Vivek Gautam <vivek.gau...@codeaurora.org>
---
 drivers/reset/core.c  | 23 +++
 include/linux/reset.h |  6 ++
 2 files changed, 29 insertions(+)

diff --git a/drivers/reset/core.c b/drivers/reset/core.c
index cd739d2fa160..f0a06a7aca93 100644
--- a/drivers/reset/core.c
+++ b/drivers/reset/core.c
@@ -465,3 +465,26 @@ int device_reset(struct device *dev)
return ret;
 }
 EXPORT_SYMBOL_GPL(device_reset);
+
+/**
+ * of_reset_control_get_count - Count number of resets available with a device
+ *
+ * @node: device node that contains 'resets'.
+ *
+ * Returns positive reset count on success, or error number on failure and
+ * on count being zero.
+ */
+int of_reset_control_get_count(struct device_node *node)
+{
+   int count;
+
+   if (!node)
+   return -EINVAL;
+
+   count = of_count_phandle_with_args(node, "resets", "#reset-cells");
+   if (count == 0)
+   count = -ENOENT;
+
+   return count;
+}
+EXPORT_SYMBOL_GPL(of_reset_control_get_count);
diff --git a/include/linux/reset.h b/include/linux/reset.h
index 13d8681210d5..1b5a6aafd3e6 100644
--- a/include/linux/reset.h
+++ b/include/linux/reset.h
@@ -24,6 +24,7 @@ struct reset_control *__devm_reset_control_get(struct device 
*dev,
 bool optional);
 
 int __must_check device_reset(struct device *dev);
+int of_reset_control_get_count(struct device_node *node);
 
 static inline int device_reset_optional(struct device *dev)
 {
@@ -89,6 +90,11 @@ static inline struct reset_control *__devm_reset_control_get(
return optional ? NULL : ERR_PTR(-ENOTSUPP);
 }
 
+static inline int of_reset_control_get_count(struct device_node *node)
+{
+   return -ENOTSUPP;
+}
+
 #endif /* CONFIG_RESET_CONTROLLER */
 
 /**
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

--
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

[PATCH V3 0/4] reset: APIs to manage a list of resets

[Vivek Gautam]

Set of patches to support getting and de/asserting a list (array)
of reset controllers available with the device.
This series also contains reset controls patches for dwc3-of-simple
and tegra pmc drivers.

This V3 version addresses Philipp's review comments to make the
APIs inline with gpiod APIs. So, the reset framework does all the
job of storing the reset controls and their count.
The users can just pass the device pointer/node along with 'optional'
'shared' flags.
The *_reset_control_array_* APIs _assert() and _deassert() required
'struct reset_control_array' to handle the reset controls.

The series is tested on torvald's master branch with following support -
a) pza/linux - reset/next
b) gregkh/usb - usb-next
c) agross/linux - for-next
d) device tree patches to enable usb on db820c.

Changes since v2:
 - Addressed comments to make APIs inline with gpiod API.
 - Moved number of reset controls in 'struct reset_control_array'
   so that the footprint is reduced.
 - of_reset_control_array_get() and devm_reset_control_array_get()
   now return pointer to the newly created reset control array.
 - Added comments to mention that the reset control array APIs don't
   guarantee any particular order when handling the reset controls.
 - Dropped 'name' from reset_control_array' since the interface is meant
   for a bunch of anonymous resets that can all be asserted or deasserted
   in arbitrary order.
 - Fixed returns for APIs reported by kbuild.
 - Fixed 'for' clause guards reported by kbuild.

Changes since v1:
 - Addressed comment for error handling in of_reset_control_get_count()
 - Added patch to manage reset controller array.
 - Rebased dwc3-of-simple changes based on the new set of APIs
   for reset control array.
 - Added a patch for soc/tegra/pmc driver to use the new set of
   reset control array APIs.

Vivek Gautam (4):
  reset: Add API to count number of reset available with device
  reset: Add APIs to manage array of resets
  usb: dwc3: of-simple: Add support to get resets for the device
  soc/tegra: pmc: Use the new reset APIs to manage reset controllers

 drivers/reset/core.c  | 200 ++
 drivers/soc/tegra/pmc.c   |  99 +++
 drivers/usb/dwc3/dwc3-of-simple.c |  36 +++
 include/linux/reset.h |  99 +++
 4 files changed, 371 insertions(+), 63 deletions(-)

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

--
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

[PATCH V3 3/4] usb: dwc3: of-simple: Add support to get resets for the device

[Vivek Gautam]

Add support to get a list of resets available for the device.
These resets must be kept de-asserted until the device is
in use.

Cc: Felipe Balbi <ba...@kernel.org>
Cc: Philipp Zabel <p.za...@pengutronix.de>
Signed-off-by: Vivek Gautam <vivek.gau...@codeaurora.org>
---
 drivers/usb/dwc3/dwc3-of-simple.c | 36 
 1 file changed, 36 insertions(+)

diff --git a/drivers/usb/dwc3/dwc3-of-simple.c 
b/drivers/usb/dwc3/dwc3-of-simple.c
index fe414e7a9c78..9116df649f0b 100644
--- a/drivers/usb/dwc3/dwc3-of-simple.c
+++ b/drivers/usb/dwc3/dwc3-of-simple.c
@@ -29,13 +29,39 @@
 #include 
 #include 
 #include 
+#include 
 
 struct dwc3_of_simple {
struct device   *dev;
struct clk  **clks;
int num_clocks;
+   struct reset_control_array *resets;
 };
 
+static int dwc3_of_simple_reset_init(struct dwc3_of_simple *simple)
+{
+   struct device   *dev = simple->dev;
+   int ret;
+
+   simple->resets = of_reset_control_array_get_exclusive(dev->of_node);
+   if (IS_ERR(simple->resets)) {
+   ret = PTR_ERR(simple->resets);
+   if (ret == -ENOENT)
+   /* not all controllers required resets */
+   return 0;
+   dev_err(dev, "failed to get device resets\n");
+   return ret;
+   }
+
+   ret = reset_control_array_deassert(simple->resets);
+   if (ret) {
+   reset_control_array_put(simple->resets);
+   return ret;
+   }
+
+   return 0;
+}
+
 static int dwc3_of_simple_clk_init(struct dwc3_of_simple *simple, int count)
 {
struct device   *dev = simple->dev;
@@ -100,6 +126,10 @@ static int dwc3_of_simple_probe(struct platform_device 
*pdev)
if (ret)
return ret;
 
+   ret = dwc3_of_simple_reset_init(simple);
+   if (ret)
+   return ret;
+
ret = of_platform_populate(np, NULL, NULL, dev);
if (ret) {
for (i = 0; i < simple->num_clocks; i++) {
@@ -107,6 +137,9 @@ static int dwc3_of_simple_probe(struct platform_device 
*pdev)
clk_put(simple->clks[i]);
}
 
+   reset_control_array_assert(simple->resets);
+   reset_control_array_put(simple->resets);
+
return ret;
}
 
@@ -128,6 +161,9 @@ static int dwc3_of_simple_remove(struct platform_device 
*pdev)
clk_put(simple->clks[i]);
}
 
+   reset_control_array_assert(simple->resets);
+   reset_control_array_put(simple->resets);
+
of_platform_depopulate(dev);
 
pm_runtime_put_sync(dev);
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

--
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

Re: [PATCH] phy: qcom-qmp: Add dependency on COMMON_CLK

[Vivek Gautam]

On 2017-04-10 10:52, Kishon Vijay Abraham I wrote:

On Friday 07 April 2017 01:37 AM, Vivek Gautam wrote:

The driver uses clock provider interface, and therefore
it fails to build when enabled for COMPILE_TEST, since
COMMON_CLK is not enabled at that time.
So, make PHY_QCOM_QMP depend on COMMON_CLK as well.

Cc: Fengguang Wu <fengguang...@intel.com>
Cc: Kishon Vijay Abraham I <kis...@ti.com>
Signed-off-by: Vivek Gautam <vivek.gau...@codeaurora.org>
---

Hi Kishon,

This patch is fixing the build failures for architectures
such as, tile, and ia64, that don't enable COMMON_CLK by default.
You can either squash this into the qmp phy driver patch,
or put it as a separate patch with 'Fix' tag.
Let me know if you want me to add a 'fix' tag with a reference
to the commit ID.


I squashed it with your earlier patch and pushed.


Thanks Kishon.

Regards
Vivek



Thanks
Kishon



Regards
Vivek

 drivers/phy/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index bb8140355608..8550d3dc0b71 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -441,7 +441,7 @@ config PHY_STIH407_USB

 config PHY_QCOM_QMP
tristate "Qualcomm QMP PHY Driver"
-   depends on OF && (ARCH_QCOM || COMPILE_TEST)
+   depends on OF && COMMON_CLK && (ARCH_QCOM || COMPILE_TEST)
select GENERIC_PHY
help
  Enable this to support the QMP PHY transceiver that is used


--
To unsubscribe from this list: send the line "unsubscribe 
linux-arm-msm" 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-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] phy: qcom-qmp: Add dependency on COMMON_CLK

[Vivek Gautam]

The driver uses clock provider interface, and therefore
it fails to build when enabled for COMPILE_TEST, since
COMMON_CLK is not enabled at that time.
So, make PHY_QCOM_QMP depend on COMMON_CLK as well.

Cc: Fengguang Wu <fengguang...@intel.com>
Cc: Kishon Vijay Abraham I <kis...@ti.com>
Signed-off-by: Vivek Gautam <vivek.gau...@codeaurora.org>
---

Hi Kishon,

This patch is fixing the build failures for architectures
such as, tile, and ia64, that don't enable COMMON_CLK by default.
You can either squash this into the qmp phy driver patch,
or put it as a separate patch with 'Fix' tag.
Let me know if you want me to add a 'fix' tag with a reference
to the commit ID.

Regards
Vivek

 drivers/phy/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index bb8140355608..8550d3dc0b71 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -441,7 +441,7 @@ config PHY_STIH407_USB
 
 config PHY_QCOM_QMP
tristate "Qualcomm QMP PHY Driver"
-   depends on OF && (ARCH_QCOM || COMPILE_TEST)
+   depends on OF && COMMON_CLK && (ARCH_QCOM || COMPILE_TEST)
select GENERIC_PHY
help
  Enable this to support the QMP PHY transceiver that is used
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

--
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

Re: [PATCH V8 0/4] phy: USB and PCIe phy drivers for Qcom chipsets

[Vivek Gautam]

On 04/06/2017 03:41 PM, Kishon Vijay Abraham I wrote:


On Thursday 06 April 2017 11:21 AM, Vivek Gautam wrote:

Hi Kishon,
Here's the series with fixed checkpatch warnings/checks.
Please pick it for phy/next.

This patch series adds couple of PHY drivers for Qualcomm chipsets.
a) qcom-qusb2 phy driver: that provides High Speed USB functionality.
b) qcom-qmp phy driver: that is a combo phy providing support for
USB3, PCIe, UFS and few other controllers.

The patches are based on next branch of linux-phy tree.

These patches have been tested on Dragon board db820c hardware with
required set of dt patches.
The tested branch[3] is based on torvald's master with greg's usb/usb-next
merged. Additionally the patches to get rpm up on msm8996 are also pulled
in.

merged, thanks!


Thanks Kishon.

BRs
Vivek



-Kishon

Changes since v7:
  - Fixed 'checkpatch --strict' alignment warnings/checks, and
added Stephen's Reviewed-by tag.

Changes since v6:
  - Rebased on phy/next and *not* including phy grouping series[4].
  - qusb2-phy: addressed Stephen's comment.
- Dropped pm8994_s2 corner regulator from QUSB2 phy bindings.
  - qmp-phy: none on functionality side.
  
Changes since v5:

  - Addressed review comments from Bjorn:
- Removed instances of readl/wirtel_relaxed calls from the drivers.
  Instead, using simple readl/writel. Inserting a readl after a writel
  to ensure the write is through to the device.
- Replaced regulator handling with regulator_bulk_** apis. This helps
  in cutting down a lot of regulator handling code.
- Fixed minor return statements.

Changes since v4:
  - Addressed comment to add child nodes for qmp phy driver. Each phy lane
now has a separate child node under the main qmp node.
  - Modified the clock and reset initialization and enable methods.
Different phys - pcie, usb and later ufs, have varying number of clocks
and resets that are mandatory. So adding provision for clocks and reset
lists helps in requesting all mandatory resources for individual phys
and handle their failure cases accordingly.

Changes since v3:
  - Addressed review comments given by Rob and Stephen for qusb2 phy
and qmp phy bindings respectively.
  - Addressed review comments given by Stephen and Bjorn for qmp phy driver.

Changes since v2:
  - Addressed review comments given by Rob and Stephen for bindings.
  - Addressed the review comments given by Stephen for the qusb2 and qmp
phy drivers.

Changes since v1:
  - Moved device tree binding documentation to separate patches, as suggested
by Rob.
  - Addressed review comment regarding qfprom accesses by qusb2 phy driver,
given by Rob.
  - Addressed review comments from Kishon.
  - Addressed review comments from Srinivas for QMP phy driver.
  - Addressed kbuild warning.

Please see individual patches for detailed changelogs.

[1] https://patchwork.kernel.org/patch/9567767/
[2] https://patchwork.kernel.org/patch/9567779/
[3] https://github.com/vivekgautam1/linux/tree/linux-v4.11-rc5-qmp-phy-db820c
[4] https://lkml.org/lkml/2017/3/20/407

Vivek Gautam (4):
   dt-bindings: phy: Add support for QUSB2 phy
   phy: qcom-qusb2: New driver for QUSB2 PHY on Qcom chips
   dt-bindings: phy: Add support for QMP phy
   phy: qcom-qmp: new qmp phy driver for qcom-chipsets

  .../devicetree/bindings/phy/qcom-qmp-phy.txt   |  106 ++
  .../devicetree/bindings/phy/qcom-qusb2-phy.txt |   43 +
  drivers/phy/Kconfig|   18 +
  drivers/phy/Makefile   |2 +
  drivers/phy/phy-qcom-qmp.c | 1153 
  drivers/phy/phy-qcom-qusb2.c   |  493 +
  6 files changed, 1815 insertions(+)
  create mode 100644 Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt
  create mode 100644 Documentation/devicetree/bindings/phy/qcom-qusb2-phy.txt
  create mode 100644 drivers/phy/phy-qcom-qmp.c
  create mode 100644 drivers/phy/phy-qcom-qusb2.c



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

--
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

[PATCH V8 1/4] dt-bindings: phy: Add support for QUSB2 phy

[Vivek Gautam]

Qualcomm chipsets have QUSB2 phy controller that provides
HighSpeed functionality for DWC3 controller.
Adding dt binding information for the same.

Signed-off-by: Vivek Gautam <vivek.gau...@codeaurora.org>
Reviewed-by: Stephen Boyd <sb...@codeaurora.org>
Acked-by: Rob Herring <r...@kernel.org>
---

Changes since v7:
 - None, just added Stephen's Reviewed-by tag.

Changes since v6:
 - Dropped 'vdd-phy-supply' that used pm8994_s2 regulator, from bindings.
   As Stephen said, the pm8994_s2 is a 'corner' regulator and it shouldn't
   be right to put it as a regulator supply.
   Work is in progress to handle these sort of power supplies.

Changes since v5:
 - Removed leading 0 from the address in 'reg' property.

Changes since v4:
 - None.

Changes since v3:
 - Added 'Acked-by' from Rob.
 - Removed 'reset-names' and 'nvmem-cell-names' from the bindings
   since we use only one cell.

Changes since v2:
 - Removed binding for "ref_clk_src" since we don't request this
   clock in the driver.
 - Addressed s/vdda-phy-dpdm/vdda-phy-dpdm-supply.
 - Addressed s/ref_clk/ref. Don't need to add '_clk' suffix to clock names.
 - Addressed s/tune2_hstx_trim_efuse/tune2_hstx_trim. Don't need to add
   'efuse' suffix to nvmem cell.
 - Addressed s/qusb2phy/phy for the node name.

Changes since v1:
 - New patch, forked out of the original driver patch:
   "phy: qcom-qusb2: New driver for QUSB2 PHY on Qcom chips"
 - Updated dt bindings to remove 'hstx-trim-bit-offset' and
   'hstx-trim-bit-len' bindings.

 .../devicetree/bindings/phy/qcom-qusb2-phy.txt | 43 ++
 1 file changed, 43 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/phy/qcom-qusb2-phy.txt

diff --git a/Documentation/devicetree/bindings/phy/qcom-qusb2-phy.txt 
b/Documentation/devicetree/bindings/phy/qcom-qusb2-phy.txt
new file mode 100644
index ..aa0fcb05acb3
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/qcom-qusb2-phy.txt
@@ -0,0 +1,43 @@
+Qualcomm QUSB2 phy controller
+=
+
+QUSB2 controller supports LS/FS/HS usb connectivity on Qualcomm chipsets.
+
+Required properties:
+ - compatible: compatible list, contains "qcom,msm8996-qusb2-phy".
+ - reg: offset and length of the PHY register set.
+ - #phy-cells: must be 0.
+
+ - clocks: a list of phandles and clock-specifier pairs,
+  one for each entry in clock-names.
+ - clock-names: must be "cfg_ahb" for phy config clock,
+   "ref" for 19.2 MHz ref clk,
+   "iface" for phy interface clock (Optional).
+
+ - vdda-pll-supply: Phandle to 1.8V regulator supply to PHY refclk pll block.
+ - vdda-phy-dpdm-supply: Phandle to 3.1V regulator supply to Dp/Dm port 
signals.
+
+ - resets: Phandle to reset to phy block.
+
+Optional properties:
+ - nvmem-cells: Phandle to nvmem cell that contains 'HS Tx trim'
+   tuning parameter value for qusb2 phy.
+
+ - qcom,tcsr-syscon: Phandle to TCSR syscon register region.
+
+Example:
+   hsusb_phy: phy@7411000 {
+   compatible = "qcom,msm8996-qusb2-phy";
+   reg = <0x7411000 0x180>;
+   #phy-cells = <0>;
+
+   clocks = < GCC_USB_PHY_CFG_AHB2PHY_CLK>,
+   < GCC_RX1_USB2_CLKREF_CLK>,
+   clock-names = "cfg_ahb", "ref";
+
+   vdda-pll-supply = <_l12>;
+   vdda-phy-dpdm-supply = <_l24>;
+
+   resets = < GCC_QUSB2PHY_PRIM_BCR>;
+   nvmem-cells = <_hstx_trim>;
+};
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

--
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

[PATCH V8 0/4] phy: USB and PCIe phy drivers for Qcom chipsets

[Vivek Gautam]

Hi Kishon,
Here's the series with fixed checkpatch warnings/checks.
Please pick it for phy/next.

This patch series adds couple of PHY drivers for Qualcomm chipsets.
a) qcom-qusb2 phy driver: that provides High Speed USB functionality.
b) qcom-qmp phy driver: that is a combo phy providing support for
   USB3, PCIe, UFS and few other controllers.

The patches are based on next branch of linux-phy tree.

These patches have been tested on Dragon board db820c hardware with
required set of dt patches.
The tested branch[3] is based on torvald's master with greg's usb/usb-next
merged. Additionally the patches to get rpm up on msm8996 are also pulled
in.

Changes since v7:
 - Fixed 'checkpatch --strict' alignment warnings/checks, and
   added Stephen's Reviewed-by tag.

Changes since v6:
 - Rebased on phy/next and *not* including phy grouping series[4].
 - qusb2-phy: addressed Stephen's comment.
   - Dropped pm8994_s2 corner regulator from QUSB2 phy bindings.
 - qmp-phy: none on functionality side.
 
Changes since v5:
 - Addressed review comments from Bjorn:
   - Removed instances of readl/wirtel_relaxed calls from the drivers.
 Instead, using simple readl/writel. Inserting a readl after a writel
 to ensure the write is through to the device.
   - Replaced regulator handling with regulator_bulk_** apis. This helps
 in cutting down a lot of regulator handling code.
   - Fixed minor return statements.

Changes since v4:
 - Addressed comment to add child nodes for qmp phy driver. Each phy lane
   now has a separate child node under the main qmp node.
 - Modified the clock and reset initialization and enable methods.
   Different phys - pcie, usb and later ufs, have varying number of clocks
   and resets that are mandatory. So adding provision for clocks and reset
   lists helps in requesting all mandatory resources for individual phys
   and handle their failure cases accordingly.

Changes since v3:
 - Addressed review comments given by Rob and Stephen for qusb2 phy
   and qmp phy bindings respectively.
 - Addressed review comments given by Stephen and Bjorn for qmp phy driver.

Changes since v2:
 - Addressed review comments given by Rob and Stephen for bindings.
 - Addressed the review comments given by Stephen for the qusb2 and qmp
   phy drivers.

Changes since v1:
 - Moved device tree binding documentation to separate patches, as suggested
   by Rob.
 - Addressed review comment regarding qfprom accesses by qusb2 phy driver,
   given by Rob.
 - Addressed review comments from Kishon.
 - Addressed review comments from Srinivas for QMP phy driver.
 - Addressed kbuild warning.

Please see individual patches for detailed changelogs.

[1] https://patchwork.kernel.org/patch/9567767/
[2] https://patchwork.kernel.org/patch/9567779/
[3] https://github.com/vivekgautam1/linux/tree/linux-v4.11-rc5-qmp-phy-db820c
[4] https://lkml.org/lkml/2017/3/20/407

Vivek Gautam (4):
  dt-bindings: phy: Add support for QUSB2 phy
  phy: qcom-qusb2: New driver for QUSB2 PHY on Qcom chips
  dt-bindings: phy: Add support for QMP phy
  phy: qcom-qmp: new qmp phy driver for qcom-chipsets

 .../devicetree/bindings/phy/qcom-qmp-phy.txt   |  106 ++
 .../devicetree/bindings/phy/qcom-qusb2-phy.txt |   43 +
 drivers/phy/Kconfig|   18 +
 drivers/phy/Makefile   |2 +
 drivers/phy/phy-qcom-qmp.c | 1153 
 drivers/phy/phy-qcom-qusb2.c   |  493 +
 6 files changed, 1815 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt
 create mode 100644 Documentation/devicetree/bindings/phy/qcom-qusb2-phy.txt
 create mode 100644 drivers/phy/phy-qcom-qmp.c
 create mode 100644 drivers/phy/phy-qcom-qusb2.c

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

--
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

[PATCH V8 4/4] phy: qcom-qmp: new qmp phy driver for qcom-chipsets

[Vivek Gautam]

Qualcomm SOCs have QMP phy controller that provides support
to a number of controller, viz. PCIe, UFS, and USB.
Add a new driver, based on generic phy framework, for this
phy controller.

Signed-off-by: Vivek Gautam <vivek.gau...@codeaurora.org>
Tested-by: Srinivas Kandagatla <srinivas.kandaga...@linaro.org>
Reviewed-by: Stephen Boyd <sb...@codeaurora.org>
---

Changes since v7:
 - Fixed 'checkpatch --strict' alignment warnings/checks.
 - Added Stephen's Reviewed-by tag.

Changes since v6:
 - Rebased on phy/next and *not* including phy grouping series.

Changes since v5:
 - Rebased on top of phy grouping series. So the driver now sits in
   drivers/phy/qualcomm/
 - Removed instances of readl_relaxed() and writel_relaxed(), and using
   readl() and writel() instead.
 - Replaced regulator handling with regulator_bulk() apis, so that
   qusb2_phy_toggle_power() method is completely dropped.
 - Removed memory barriers from the driver. Instead, added an extra readl()
   over the register in qphy_setbits() and qphy_clrbits() to ensure that
   the write is through to the device.
 - Fixed nits about return statement from probe(), phy_pipe_clk_register()
   and qcom_qmp_phy_create().

Changes since v4:
 - Added provision for child nodes representing each phy lane.
   Each of these nodes have their own register space for tx, rx and pcs
   blocks. Added provision in qcom_qmp_phy_create() to iomap these
   address spaces.
 - Added list of clocks and resets that are mandatory for each phy.
   qcom_qmp_phy_clk_init(), and qcom_qmp_phy_reset_init() methods
   request this list and maintains it with qmp.
   The clocks and resets are then enabled/de-asserted based on this list.
   This list is also updated in the binding documentation.
 - Removed qcom_qmp_phy_xlate() method as we don't need it with
   #phy-cells 0.
 - Removed unnecessary of_match_ptr() cast for the match table,
   since the driver is compiled for CONFIG_OF.
 - Updated copyright year to 2017.

Changes since v3:
 - Renamed 'struct qcom_qmp_phy' to 'struct qcom_qmp' and
   'struct qmp_phy_desc' to 'struct qmp_phy' to avoid any confusion
   in distinguishing between QMP phy block and per-lane phy which is
   the actual phy in Linux eyes (suggested by Bjorn Andersson).
 - Made error labels more idiomatic.
 - Modified status checking for phy pcs.
 - Fixed power_down_delay check.
 - Refactored phy_pipe_clk_register() to register the pipe clock source
   using devm_clk_hw_register() (suggested by Stephen).
 - qcom_qmp_phy_xlate() function:
   - Removed unnecessary 'for loop'.
   - Added additional check for '0' or -ve args_count.
 - Fixed the mixed tabs and spaces in pipe_clk_src diagram.
 - Removed instances of memset() since we use snprintf() for the
   buffers.
 - Refactored qphy_setbits() and qphy_clrbits() a little bit to accept
   base address and register offset as two separate arguments.

Changes since v2:
 - Removed selecting 'RESET_CONTROLLER' config.
 - Added error handling for clk_prepare_enable paths.
 - Removed 'ref_clk_src' handling. Driver doesn't need to request and
   handle this clock.
 - Using readl_poll_timeout() to simplify pcs ready status polling.
   Also fixed the polling condition for pcs block ready status:
   'Common block ready status bit is set on phy init completion, while
   PCS block ready status bit (PHYSTATUS) is reset on phy init
   completion.'
 - Moved out the per-lane phy creation from probe() to separate
   function.
 - Registering pipe clock source as a fixed rate clock that comes
   out of the PLL block of QMP phy. These source clocks serve as
   parent to 'pipe_clks' that are requested by pcie or usb3 phys.
 - Using of_device_get_match_data() to get match data.
 - Fixed sparse warnings for 'static' and 'const'.
 - Using shorter variable names in structure and in functions.
 - Handling various comment style shortcomings.

Changes since v1:
 - Fixed missing mutex_unlock() calls in error cases, reported by
   Julia Lawall.
 - Selecting CONFIG_RESET_CONTROLLER when this driver is enabled.
 - Added a boolean property to check if the phy has individual lane
   reset available.
 - Took care or EPROBE_DEFER, dev_vdbg() and other minor nits.
 - Removed references to non-lkml links from commit message.
 - Moved to use separate iomem resources for each lanes.
   Tx, Rx and PCS offsets per lane can now come from dt bindings.

 drivers/phy/Kconfig|8 +
 drivers/phy/Makefile   |1 +
 drivers/phy/phy-qcom-qmp.c | 1153 
 3 files changed, 1162 insertions(+)
 create mode 100644 drivers/phy/phy-qcom-qmp.c

diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index ccc9178e32cd..bb8140355608 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -439,6 +439,14 @@ config PHY_STIH407_USB
  Enable this support to enable the picoPHY device used by USB2
  and USB3 controllers on STMicroelectronics STiH407 SoC families.
 
+config PHY_QCOM_QM

[PATCH V8 3/4] dt-bindings: phy: Add support for QMP phy

[Vivek Gautam]

Qualcomm chipsets have QMP phy controller that provides
support to a number of controller, viz. PCIe, UFS, and USB.
Adding dt binding information for the same.

Signed-off-by: Vivek Gautam <vivek.gau...@codeaurora.org>
Reviewed-by: Stephen Boyd <sb...@codeaurora.org>
Acked-by: Rob Herring <r...@kernel.org>
---

Changes since v7:
 - None, just added Stephen's Reviewed-by tag.

Changes since v6:
 - none.

Changes since v5:
 - Added Rob's 'Ack' for the new child nodes based bindings.
 - Dropped leading 0 from the address in 'reg' property.
 - Fixed '@xyz' part of the node name with correct address.

Changes since v4:
 - Added bindings for child nodes. Each phy lane is represented by child
   node with its own register space (for tx, rx and pcs blocks), and clocks
   and resets for power control facility.
 - Removed register space and lane offsets for tx, rx and pcs blocks from
   qmp phy node.
 - #phy-cells is now part of each child node and thus must be 0.
 - Added information on list of mandatory clocks and resets for each phy.

Changes since v3:
 - Added #clock-cells = <1>, indicating that phy is a clock provider.

Changes since v2:
 - Removed binding for "ref_clk_src" since we don't request this
   clock in the driver.
 - Addressed s/ref_clk/ref. Don't need to add '_clk' suffix to clock names.
 - Using 'phy' for the node name.

Changes since v1:
 - New patch, forked out of the original driver patch:
   "phy: qcom-qmp: new qmp phy driver for qcom-chipsets"
 - Added 'Acked-by' from Rob.
 - Updated bindings to include mem resource as a list of
   offset - length pair for serdes block and for each lane.
 - Added a new binding for 'lane-offsets' that contains offsets
   to tx, rx and pcs blocks from each lane base address.

 .../devicetree/bindings/phy/qcom-qmp-phy.txt   | 106 +
 1 file changed, 106 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt

diff --git a/Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt 
b/Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt
new file mode 100644
index ..e11c563a65ec
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt
@@ -0,0 +1,106 @@
+Qualcomm QMP PHY controller
+===
+
+QMP phy controller supports physical layer functionality for a number of
+controllers on Qualcomm chipsets, such as, PCIe, UFS, and USB.
+
+Required properties:
+ - compatible: compatible list, contains:
+  "qcom,msm8996-qmp-pcie-phy" for 14nm PCIe phy on msm8996,
+  "qcom,msm8996-qmp-usb3-phy" for 14nm USB3 phy on msm8996.
+
+ - reg: offset and length of register set for PHY's common serdes block.
+
+ - #clock-cells: must be 1
+- Phy pll outputs a bunch of clocks for Tx, Rx and Pipe
+  interface (for pipe based PHYs). These clock are then gate-controlled
+  by gcc.
+ - #address-cells: must be 1
+ - #size-cells: must be 1
+ - ranges: must be present
+
+ - clocks: a list of phandles and clock-specifier pairs,
+  one for each entry in clock-names.
+ - clock-names: "cfg_ahb" for phy config clock,
+   "aux" for phy aux clock,
+   "ref" for 19.2 MHz ref clk,
+   For "qcom,msm8996-qmp-pcie-phy" must contain:
+   "aux", "cfg_ahb", "ref".
+   For "qcom,msm8996-qmp-usb3-phy" must contain:
+   "aux", "cfg_ahb", "ref".
+
+ - resets: a list of phandles and reset controller specifier pairs,
+  one for each entry in reset-names.
+ - reset-names: "phy" for reset of phy block,
+   "common" for phy common block reset,
+   "cfg" for phy's ahb cfg block reset (Optional).
+   For "qcom,msm8996-qmp-pcie-phy" must contain:
+"phy", "common", "cfg".
+   For "qcom,msm8996-qmp-usb3-phy" must contain
+"phy", "common".
+
+ - vdda-phy-supply: Phandle to a regulator supply to PHY core block.
+ - vdda-pll-supply: Phandle to 1.8V regulator supply to PHY refclk pll block.
+
+Optional properties:
+ - vddp-ref-clk-supply: Phandle to a regulator supply to any specific refclk
+   pll block.
+
+Required nodes:
+ - Each device node of QMP phy is required to have as many child nodes as
+   the number of lanes the PHY has.
+
+Required properties for child node:
+ - reg: list of offset and length pairs of register sets for PHY blocks -
+   tx, rx and pcs.
+
+ - #phy-cells: must be 0
+
+ - clocks: a list of phandles and clock-specifier pairs,
+  one for each entry in clock-names.
+ - clock-names: Must contain following for pcie and usb qmp phys:
+"pipe" for pipe clock s

[PATCH V8 2/4] phy: qcom-qusb2: New driver for QUSB2 PHY on Qcom chips

[Vivek Gautam]

PHY transceiver driver for QUSB2 phy controller that provides
HighSpeed functionality for DWC3 controller present on
Qualcomm chipsets.

Signed-off-by: Vivek Gautam <vivek.gau...@codeaurora.org>
Reviewed-by: Stephen Boyd <sb...@codeaurora.org>
---

Changes since v7:
 - Fixed 'checkpatch --strict' alignment warnings/checks.

Changes since v6:
 - Dropped 'vdd-phy' from list of regulators.
 - Rebased on phy/next and *not* including phy grouping series.

Changes since v5:
 - Rebased on top of phy grouping series. So the driver now sits in
   drivers/phy/qualcomm/
 - Removed instances of readl_relaxed() and writel_relaxed(), and using
   readl() and writel() instead.
 - Replaced regulator handling with regulator_bulk() apis, so that
   qusb2_phy_toggle_power() method is completely dropped.
 - Removed memory barriers from the driver. Instead, using readl() over
   the register to ensure that the write is through to the device.
 - Fixed nits about return statement from probe() and qusb2_phy_poweron().

Changes since v4:
 - Updated the copyright year to 2017.
 - Removed unnecessary of_match_ptr() cast for the match table,
   since the driver is compiled for CONFIG_OF.

Changes since v3:
 - Added 'Reviewed-by' from Stephen.
 - Fixed debug message for qusb2_phy_set_tune2_param().
 - Replaced devm_reset_control_get() with devm_reset_control_get_by_index()
   since we are requesting only one reset.
 - Updated devm_nvmem_cell_get() with a NULL cell id.
 - Made error labels more idiomatic.
 - Refactored qusb2_setbits() and qusb2_clrbits() a little bit to accept
   base address and register offset as two separate arguments.

Changes since v2:
 - Removed selecting 'RESET_CONTROLLER' config.
 - Added error handling for clk_prepare_enable paths.
 - Removed explicitly setting ref_clk rate to 19.2 MHz. Don't need to
   do that since 'xo' is modeled as parent to this clock.
 - Removed 'ref_clk_src' handling. Driver doesn't need to request and
   handle this clock.
 - Moved nvmem_cell_get() to probe function.
 - Simplified phy pll status handling.
 - Using of_device_get_match_data() to get match data.
 - Uniformly using lowercase for hex numbers.
 - Fixed sparse warnings.
 - Using shorter variable names in structure and in functions.
 - Handling various comment style shortcomings.

Changes since v1:
 - removed reference to clk_enabled/pwr_enabled.
 - moved clock and regulator enable code to phy_power_on/off() callbacks.
 - fixed return on EPROBE_DEFER in qusb2_phy_probe().
 - fixed phy create and phy register ordering.
 - removed references to non-lkml links from commit message.
 - took care of other minor nits.
 - Fixed coccinelle warnings -
   'PTR_ERR applied after initialization to constant'
 - Addressed review comment, regarding qfprom access for tune2 param value.
   This driver is now based on qfprom patch[1] that allows byte access now.

 drivers/phy/Kconfig  |  10 +
 drivers/phy/Makefile |   1 +
 drivers/phy/phy-qcom-qusb2.c | 493 +++
 3 files changed, 504 insertions(+)
 create mode 100644 drivers/phy/phy-qcom-qusb2.c

diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index dc5277ad1b5a..ccc9178e32cd 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -439,6 +439,16 @@ config PHY_STIH407_USB
  Enable this support to enable the picoPHY device used by USB2
  and USB3 controllers on STMicroelectronics STiH407 SoC families.
 
+config PHY_QCOM_QUSB2
+   tristate "Qualcomm QUSB2 PHY Driver"
+   depends on OF && (ARCH_QCOM || COMPILE_TEST)
+   select GENERIC_PHY
+   help
+ Enable this to support the HighSpeed QUSB2 PHY transceiver for USB
+ controllers on Qualcomm chips. This driver supports the high-speed
+ PHY which is usually paired with either the ChipIdea or Synopsys DWC3
+ USB IPs on MSM SOCs.
+
 config PHY_QCOM_UFS
tristate "Qualcomm UFS PHY driver"
depends on OF && ARCH_QCOM
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index e7b0feb1e125..0375c6a32697 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -50,6 +50,7 @@ obj-$(CONFIG_PHY_ST_SPEAR1310_MIPHY)  += phy-spear1310-miphy.o
 obj-$(CONFIG_PHY_ST_SPEAR1340_MIPHY)   += phy-spear1340-miphy.o
 obj-$(CONFIG_PHY_XGENE)+= phy-xgene.o
 obj-$(CONFIG_PHY_STIH407_USB)  += phy-stih407-usb.o
+obj-$(CONFIG_PHY_QCOM_QUSB2)   += phy-qcom-qusb2.o
 obj-$(CONFIG_PHY_QCOM_UFS) += phy-qcom-ufs.o
 obj-$(CONFIG_PHY_QCOM_UFS) += phy-qcom-ufs-qmp-20nm.o
 obj-$(CONFIG_PHY_QCOM_UFS) += phy-qcom-ufs-qmp-14nm.o
diff --git a/drivers/phy/phy-qcom-qusb2.c b/drivers/phy/phy-qcom-qusb2.c
new file mode 100644
index ..6c575244c0fb
--- /dev/null
+++ b/drivers/phy/phy-qcom-qusb2.c
@@ -0,0 +1,493 @@
+/*
+ * Copyright (c) 2017, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redi

Re: [PATCH V7 0/4] phy: USB and PCIe phy drivers for Qcom chipsets

[Vivek Gautam]

Hi Kishon,


On Wed, Apr 5, 2017 at 7:08 PM, Kishon Vijay Abraham I <kis...@ti.com> wrote:
> Hi Vivek,
>
> On Wednesday 05 April 2017 06:02 PM, Vivek Gautam wrote:
>> This patch series adds couple of PHY drivers for Qualcomm chipsets.
>> a) qcom-qusb2 phy driver: that provides High Speed USB functionality.
>> b) qcom-qmp phy driver: that is a combo phy providing support for
>>USB3, PCIe, UFS and few other controllers.
>>
>> The patches are based on next branch of linux-phy tree.
>>
>> These patches have been tested on Dragon board db820c hardware with
>> required set of dt patches and the patches to get rpm up on msm8996.
>> Couple of other patches [1, 2] fixing DMA config for XHCI are also
>> pulled in for testing.
>> A branch based on torvald's master is available in github [3].
>
> I get a bunch of checkpatch errors/warnings when I run checkpatch with 
> --strict
> option. Those look simple enough to be fixed. Can you respin your series 
> fixing
> those?

Sure, I am on it.
Thanks for pointing out.

Regards
Vivek

>
> Thanks
> Kishon
>
>>
>> Changes since v6:
>>  - Rebased on phy/next and *not* including phy grouping series[4].
>>  - qusb2-phy: addressed Stephen's comment.
>>- Dropped pm8994_s2 corner regulator from QUSB2 phy bindings.
>>  - qmp-phy: none on functionality side.
>>
>> Changes since v5:
>>  - Addressed review comments from Bjorn:
>>- Removed instances of readl/wirtel_relaxed calls from the drivers.
>>  Instead, using simple readl/writel. Inserting a readl after a writel
>>  to ensure the write is through to the device.
>>- Replaced regulator handling with regulator_bulk_** apis. This helps
>>  in cutting down a lot of regulator handling code.
>>- Fixed minor return statements.
>>
>> Changes since v4:
>>  - Addressed comment to add child nodes for qmp phy driver. Each phy lane
>>now has a separate child node under the main qmp node.
>>  - Modified the clock and reset initialization and enable methods.
>>Different phys - pcie, usb and later ufs, have varying number of clocks
>>and resets that are mandatory. So adding provision for clocks and reset
>>lists helps in requesting all mandatory resources for individual phys
>>and handle their failure cases accordingly.
>>
>> Changes since v3:
>>  - Addressed review comments given by Rob and Stephen for qusb2 phy
>>and qmp phy bindings respectively.
>>  - Addressed review comments given by Stephen and Bjorn for qmp phy driver.
>>
>> Changes since v2:
>>  - Addressed review comments given by Rob and Stephen for bindings.
>>  - Addressed the review comments given by Stephen for the qusb2 and qmp
>>phy drivers.
>>
>> Changes since v1:
>>  - Moved device tree binding documentation to separate patches, as suggested
>>by Rob.
>>  - Addressed review comment regarding qfprom accesses by qusb2 phy driver,
>>given by Rob.
>>  - Addressed review comments from Kishon.
>>  - Addressed review comments from Srinivas for QMP phy driver.
>>  - Addressed kbuild warning.
>>
>> Please see individual patches for detailed changelogs.
>>
>> [1] https://patchwork.kernel.org/patch/9567767/
>> [2] https://patchwork.kernel.org/patch/9567779/
>> [3] https://github.com/vivekgautam1/linux/tree/linux-v4.11-rc5-qmp-phy-db820c
>> [4] https://lkml.org/lkml/2017/3/20/407
>>
>> Vivek Gautam (4):
>>   dt-bindings: phy: Add support for QUSB2 phy
>>   phy: qcom-qusb2: New driver for QUSB2 PHY on Qcom chips
>>   dt-bindings: phy: Add support for QMP phy
>>   phy: qcom-qmp: new qmp phy driver for qcom-chipsets
>>
>>  .../devicetree/bindings/phy/qcom-qmp-phy.txt   |  106 ++
>>  .../devicetree/bindings/phy/qcom-qusb2-phy.txt |   43 +
>>  drivers/phy/Kconfig|   18 +
>>  drivers/phy/Makefile   |2 +
>>  drivers/phy/phy-qcom-qmp.c | 1153 
>> 
>>  drivers/phy/phy-qcom-qusb2.c   |  491 +
>>  6 files changed, 1813 insertions(+)
>>  create mode 100644 Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt
>>  create mode 100644 Documentation/devicetree/bindings/phy/qcom-qusb2-phy.txt
>>  create mode 100644 drivers/phy/phy-qcom-qmp.c
>>  create mode 100644 drivers/phy/phy-qcom-qusb2.c
>>
> --
> 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



-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
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

[PATCH V7 4/4] phy: qcom-qmp: new qmp phy driver for qcom-chipsets

[Vivek Gautam]

Qualcomm SOCs have QMP phy controller that provides support
to a number of controller, viz. PCIe, UFS, and USB.
Add a new driver, based on generic phy framework, for this
phy controller.

Signed-off-by: Vivek Gautam <vivek.gau...@codeaurora.org>
Tested-by: Srinivas Kandagatla <srinivas.kandaga...@linaro.org>
---

Changes since v6:
 - Rebased on phy/next and *not* including phy grouping series.

Changes since v5:
 - Rebased on top of phy grouping series. So the driver now sits in
   drivers/phy/qualcomm/
 - Removed instances of readl_relaxed() and writel_relaxed(), and using
   readl() and writel() instead.
 - Replaced regulator handling with regulator_bulk() apis, so that
   qusb2_phy_toggle_power() method is completely dropped.
 - Removed memory barriers from the driver. Instead, added an extra readl()
   over the register in qphy_setbits() and qphy_clrbits() to ensure that
   the write is through to the device.
 - Fixed nits about return statement from probe(), phy_pipe_clk_register()
   and qcom_qmp_phy_create().

Changes since v4:
 - Added provision for child nodes representing each phy lane.
   Each of these nodes have their own register space for tx, rx and pcs
   blocks. Added provision in qcom_qmp_phy_create() to iomap these
   address spaces.
 - Added list of clocks and resets that are mandatory for each phy.
   qcom_qmp_phy_clk_init(), and qcom_qmp_phy_reset_init() methods
   request this list and maintains it with qmp.
   The clocks and resets are then enabled/de-asserted based on this list.
   This list is also updated in the binding documentation.
 - Removed qcom_qmp_phy_xlate() method as we don't need it with
   #phy-cells 0.
 - Removed unnecessary of_match_ptr() cast for the match table,
   since the driver is compiled for CONFIG_OF.
 - Updated copyright year to 2017.

Changes since v3:
 - Renamed 'struct qcom_qmp_phy' to 'struct qcom_qmp' and
   'struct qmp_phy_desc' to 'struct qmp_phy' to avoid any confusion
   in distinguishing between QMP phy block and per-lane phy which is
   the actual phy in Linux eyes (suggested by Bjorn Andersson).
 - Made error labels more idiomatic.
 - Modified status checking for phy pcs.
 - Fixed power_down_delay check.
 - Refactored phy_pipe_clk_register() to register the pipe clock source
   using devm_clk_hw_register() (suggested by Stephen).
 - qcom_qmp_phy_xlate() function:
   - Removed unnecessary 'for loop'.
   - Added additional check for '0' or -ve args_count.
 - Fixed the mixed tabs and spaces in pipe_clk_src diagram.
 - Removed instances of memset() since we use snprintf() for the
   buffers.
 - Refactored qphy_setbits() and qphy_clrbits() a little bit to accept
   base address and register offset as two separate arguments.

Changes since v2:
 - Removed selecting 'RESET_CONTROLLER' config.
 - Added error handling for clk_prepare_enable paths.
 - Removed 'ref_clk_src' handling. Driver doesn't need to request and
   handle this clock.
 - Using readl_poll_timeout() to simplify pcs ready status polling.
   Also fixed the polling condition for pcs block ready status:
   'Common block ready status bit is set on phy init completion, while
   PCS block ready status bit (PHYSTATUS) is reset on phy init
   completion.'
 - Moved out the per-lane phy creation from probe() to separate
   function.
 - Registering pipe clock source as a fixed rate clock that comes
   out of the PLL block of QMP phy. These source clocks serve as
   parent to 'pipe_clks' that are requested by pcie or usb3 phys.
 - Using of_device_get_match_data() to get match data.
 - Fixed sparse warnings for 'static' and 'const'.
 - Using shorter variable names in structure and in functions.
 - Handling various comment style shortcomings.

Changes since v1:
 - Fixed missing mutex_unlock() calls in error cases, reported by
   Julia Lawall.
 - Selecting CONFIG_RESET_CONTROLLER when this driver is enabled.
 - Added a boolean property to check if the phy has individual lane
   reset available.
 - Took care or EPROBE_DEFER, dev_vdbg() and other minor nits.
 - Removed references to non-lkml links from commit message.
 - Moved to use separate iomem resources for each lanes.
   Tx, Rx and PCS offsets per lane can now come from dt bindings.

 drivers/phy/Kconfig|8 +
 drivers/phy/Makefile   |1 +
 drivers/phy/phy-qcom-qmp.c | 1153 
 3 files changed, 1162 insertions(+)
 create mode 100644 drivers/phy/phy-qcom-qmp.c

diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index ccc9178e32cd..bb8140355608 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -439,6 +439,14 @@ config PHY_STIH407_USB
  Enable this support to enable the picoPHY device used by USB2
  and USB3 controllers on STMicroelectronics STiH407 SoC families.
 
+config PHY_QCOM_QMP
+   tristate "Qualcomm QMP PHY Driver"
+   depends on OF && (ARCH_QCOM || COMPILE_TEST)
+   select GENERIC_PHY
+   help
+ Enab

[PATCH V7 3/4] dt-bindings: phy: Add support for QMP phy

[Vivek Gautam]

Qualcomm chipsets have QMP phy controller that provides
support to a number of controller, viz. PCIe, UFS, and USB.
Adding dt binding information for the same.

Signed-off-by: Vivek Gautam <vivek.gau...@codeaurora.org>
Acked-by: Rob Herring <r...@kernel.org>
---

Changes since v6:
 - none.

Changes since v5:
 - Added Rob's 'Ack' for the new child nodes based bindings.
 - Dropped leading 0 from the address in 'reg' property.
 - Fixed '@xyz' part of the node name with correct address.

Changes since v4:
 - Added bindings for child nodes. Each phy lane is represented by child
   node with its own register space (for tx, rx and pcs blocks), and clocks
   and resets for power control facility.
 - Removed register space and lane offsets for tx, rx and pcs blocks from
   qmp phy node.
 - #phy-cells is now part of each child node and thus must be 0.
 - Added information on list of mandatory clocks and resets for each phy.

Changes since v3:
 - Added #clock-cells = <1>, indicating that phy is a clock provider.

Changes since v2:
 - Removed binding for "ref_clk_src" since we don't request this
   clock in the driver.
 - Addressed s/ref_clk/ref. Don't need to add '_clk' suffix to clock names.
 - Using 'phy' for the node name.

Changes since v1:
 - New patch, forked out of the original driver patch:
   "phy: qcom-qmp: new qmp phy driver for qcom-chipsets"
 - Added 'Acked-by' from Rob.
 - Updated bindings to include mem resource as a list of
   offset - length pair for serdes block and for each lane.
 - Added a new binding for 'lane-offsets' that contains offsets
   to tx, rx and pcs blocks from each lane base address.

 .../devicetree/bindings/phy/qcom-qmp-phy.txt   | 106 +
 1 file changed, 106 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt

diff --git a/Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt 
b/Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt
new file mode 100644
index ..e11c563a65ec
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt
@@ -0,0 +1,106 @@
+Qualcomm QMP PHY controller
+===
+
+QMP phy controller supports physical layer functionality for a number of
+controllers on Qualcomm chipsets, such as, PCIe, UFS, and USB.
+
+Required properties:
+ - compatible: compatible list, contains:
+  "qcom,msm8996-qmp-pcie-phy" for 14nm PCIe phy on msm8996,
+  "qcom,msm8996-qmp-usb3-phy" for 14nm USB3 phy on msm8996.
+
+ - reg: offset and length of register set for PHY's common serdes block.
+
+ - #clock-cells: must be 1
+- Phy pll outputs a bunch of clocks for Tx, Rx and Pipe
+  interface (for pipe based PHYs). These clock are then gate-controlled
+  by gcc.
+ - #address-cells: must be 1
+ - #size-cells: must be 1
+ - ranges: must be present
+
+ - clocks: a list of phandles and clock-specifier pairs,
+  one for each entry in clock-names.
+ - clock-names: "cfg_ahb" for phy config clock,
+   "aux" for phy aux clock,
+   "ref" for 19.2 MHz ref clk,
+   For "qcom,msm8996-qmp-pcie-phy" must contain:
+   "aux", "cfg_ahb", "ref".
+   For "qcom,msm8996-qmp-usb3-phy" must contain:
+   "aux", "cfg_ahb", "ref".
+
+ - resets: a list of phandles and reset controller specifier pairs,
+  one for each entry in reset-names.
+ - reset-names: "phy" for reset of phy block,
+   "common" for phy common block reset,
+   "cfg" for phy's ahb cfg block reset (Optional).
+   For "qcom,msm8996-qmp-pcie-phy" must contain:
+"phy", "common", "cfg".
+   For "qcom,msm8996-qmp-usb3-phy" must contain
+"phy", "common".
+
+ - vdda-phy-supply: Phandle to a regulator supply to PHY core block.
+ - vdda-pll-supply: Phandle to 1.8V regulator supply to PHY refclk pll block.
+
+Optional properties:
+ - vddp-ref-clk-supply: Phandle to a regulator supply to any specific refclk
+   pll block.
+
+Required nodes:
+ - Each device node of QMP phy is required to have as many child nodes as
+   the number of lanes the PHY has.
+
+Required properties for child node:
+ - reg: list of offset and length pairs of register sets for PHY blocks -
+   tx, rx and pcs.
+
+ - #phy-cells: must be 0
+
+ - clocks: a list of phandles and clock-specifier pairs,
+  one for each entry in clock-names.
+ - clock-names: Must contain following for pcie and usb qmp phys:
+"pipe" for pipe clock specific to each lane.
+
+ - resets: a list of phandles and reset controller specifier pairs,
+ 

[PATCH V7 1/4] dt-bindings: phy: Add support for QUSB2 phy

[Vivek Gautam]

Qualcomm chipsets have QUSB2 phy controller that provides
HighSpeed functionality for DWC3 controller.
Adding dt binding information for the same.

Signed-off-by: Vivek Gautam <vivek.gau...@codeaurora.org>
Acked-by: Rob Herring <r...@kernel.org>
---

Changes since v6:
 - Dropped 'vdd-phy-supply' that used pm8994_s2 regulator, from bindings.
   As Stephen said, the pm8994_s2 is a 'corner' regulator and it shouldn't
   be right to put it as a regulator supply.
   Work is in progress to handle these sort of power supplies.

Changes since v5:
 - Removed leading 0 from the address in 'reg' property.

Changes since v4:
 - None.

Changes since v3:
 - Added 'Acked-by' from Rob.
 - Removed 'reset-names' and 'nvmem-cell-names' from the bindings
   since we use only one cell.

Changes since v2:
 - Removed binding for "ref_clk_src" since we don't request this
   clock in the driver.
 - Addressed s/vdda-phy-dpdm/vdda-phy-dpdm-supply.
 - Addressed s/ref_clk/ref. Don't need to add '_clk' suffix to clock names.
 - Addressed s/tune2_hstx_trim_efuse/tune2_hstx_trim. Don't need to add
   'efuse' suffix to nvmem cell.
 - Addressed s/qusb2phy/phy for the node name.

Changes since v1:
 - New patch, forked out of the original driver patch:
   "phy: qcom-qusb2: New driver for QUSB2 PHY on Qcom chips"
 - Updated dt bindings to remove 'hstx-trim-bit-offset' and
   'hstx-trim-bit-len' bindings.

 .../devicetree/bindings/phy/qcom-qusb2-phy.txt | 43 ++
 1 file changed, 43 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/phy/qcom-qusb2-phy.txt

diff --git a/Documentation/devicetree/bindings/phy/qcom-qusb2-phy.txt 
b/Documentation/devicetree/bindings/phy/qcom-qusb2-phy.txt
new file mode 100644
index ..aa0fcb05acb3
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/qcom-qusb2-phy.txt
@@ -0,0 +1,43 @@
+Qualcomm QUSB2 phy controller
+=
+
+QUSB2 controller supports LS/FS/HS usb connectivity on Qualcomm chipsets.
+
+Required properties:
+ - compatible: compatible list, contains "qcom,msm8996-qusb2-phy".
+ - reg: offset and length of the PHY register set.
+ - #phy-cells: must be 0.
+
+ - clocks: a list of phandles and clock-specifier pairs,
+  one for each entry in clock-names.
+ - clock-names: must be "cfg_ahb" for phy config clock,
+   "ref" for 19.2 MHz ref clk,
+   "iface" for phy interface clock (Optional).
+
+ - vdda-pll-supply: Phandle to 1.8V regulator supply to PHY refclk pll block.
+ - vdda-phy-dpdm-supply: Phandle to 3.1V regulator supply to Dp/Dm port 
signals.
+
+ - resets: Phandle to reset to phy block.
+
+Optional properties:
+ - nvmem-cells: Phandle to nvmem cell that contains 'HS Tx trim'
+   tuning parameter value for qusb2 phy.
+
+ - qcom,tcsr-syscon: Phandle to TCSR syscon register region.
+
+Example:
+   hsusb_phy: phy@7411000 {
+   compatible = "qcom,msm8996-qusb2-phy";
+   reg = <0x7411000 0x180>;
+   #phy-cells = <0>;
+
+   clocks = < GCC_USB_PHY_CFG_AHB2PHY_CLK>,
+   < GCC_RX1_USB2_CLKREF_CLK>,
+   clock-names = "cfg_ahb", "ref";
+
+   vdda-pll-supply = <_l12>;
+   vdda-phy-dpdm-supply = <_l24>;
+
+   resets = < GCC_QUSB2PHY_PRIM_BCR>;
+   nvmem-cells = <_hstx_trim>;
+};
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

--
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

[PATCH V7 2/4] phy: qcom-qusb2: New driver for QUSB2 PHY on Qcom chips

[Vivek Gautam]

PHY transceiver driver for QUSB2 phy controller that provides
HighSpeed functionality for DWC3 controller present on
Qualcomm chipsets.

Signed-off-by: Vivek Gautam <vivek.gau...@codeaurora.org>
Reviewed-by: Stephen Boyd <sb...@codeaurora.org>
---

Changes since v6:
 - Dropped 'vdd-phy' from list of regulators.
 - Rebased on phy/next and *not* including phy grouping series.

Changes since v5:
 - Rebased on top of phy grouping series. So the driver now sits in
   drivers/phy/qualcomm/
 - Removed instances of readl_relaxed() and writel_relaxed(), and using
   readl() and writel() instead.
 - Replaced regulator handling with regulator_bulk() apis, so that
   qusb2_phy_toggle_power() method is completely dropped.
 - Removed memory barriers from the driver. Instead, using readl() over
   the register to ensure that the write is through to the device.
 - Fixed nits about return statement from probe() and qusb2_phy_poweron().

Changes since v4:
 - Updated the copyright year to 2017.
 - Removed unnecessary of_match_ptr() cast for the match table,
   since the driver is compiled for CONFIG_OF.

Changes since v3:
 - Added 'Reviewed-by' from Stephen.
 - Fixed debug message for qusb2_phy_set_tune2_param().
 - Replaced devm_reset_control_get() with devm_reset_control_get_by_index()
   since we are requesting only one reset.
 - Updated devm_nvmem_cell_get() with a NULL cell id.
 - Made error labels more idiomatic.
 - Refactored qusb2_setbits() and qusb2_clrbits() a little bit to accept
   base address and register offset as two separate arguments.

Changes since v2:
 - Removed selecting 'RESET_CONTROLLER' config.
 - Added error handling for clk_prepare_enable paths.
 - Removed explicitly setting ref_clk rate to 19.2 MHz. Don't need to
   do that since 'xo' is modeled as parent to this clock.
 - Removed 'ref_clk_src' handling. Driver doesn't need to request and
   handle this clock.
 - Moved nvmem_cell_get() to probe function.
 - Simplified phy pll status handling.
 - Using of_device_get_match_data() to get match data.
 - Uniformly using lowercase for hex numbers.
 - Fixed sparse warnings.
 - Using shorter variable names in structure and in functions.
 - Handling various comment style shortcomings.

Changes since v1:
 - removed reference to clk_enabled/pwr_enabled.
 - moved clock and regulator enable code to phy_power_on/off() callbacks.
 - fixed return on EPROBE_DEFER in qusb2_phy_probe().
 - fixed phy create and phy register ordering.
 - removed references to non-lkml links from commit message.
 - took care of other minor nits.
 - Fixed coccinelle warnings -
   'PTR_ERR applied after initialization to constant'
 - Addressed review comment, regarding qfprom access for tune2 param value.
   This driver is now based on qfprom patch[1] that allows byte access now.

 drivers/phy/Kconfig  |  10 +
 drivers/phy/Makefile |   1 +
 drivers/phy/phy-qcom-qusb2.c | 491 +++
 3 files changed, 502 insertions(+)
 create mode 100644 drivers/phy/phy-qcom-qusb2.c

diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index dc5277ad1b5a..ccc9178e32cd 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -439,6 +439,16 @@ config PHY_STIH407_USB
  Enable this support to enable the picoPHY device used by USB2
  and USB3 controllers on STMicroelectronics STiH407 SoC families.
 
+config PHY_QCOM_QUSB2
+   tristate "Qualcomm QUSB2 PHY Driver"
+   depends on OF && (ARCH_QCOM || COMPILE_TEST)
+   select GENERIC_PHY
+   help
+ Enable this to support the HighSpeed QUSB2 PHY transceiver for USB
+ controllers on Qualcomm chips. This driver supports the high-speed
+ PHY which is usually paired with either the ChipIdea or Synopsys DWC3
+ USB IPs on MSM SOCs.
+
 config PHY_QCOM_UFS
tristate "Qualcomm UFS PHY driver"
depends on OF && ARCH_QCOM
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index e7b0feb1e125..0375c6a32697 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -50,6 +50,7 @@ obj-$(CONFIG_PHY_ST_SPEAR1310_MIPHY)  += phy-spear1310-miphy.o
 obj-$(CONFIG_PHY_ST_SPEAR1340_MIPHY)   += phy-spear1340-miphy.o
 obj-$(CONFIG_PHY_XGENE)+= phy-xgene.o
 obj-$(CONFIG_PHY_STIH407_USB)  += phy-stih407-usb.o
+obj-$(CONFIG_PHY_QCOM_QUSB2)   += phy-qcom-qusb2.o
 obj-$(CONFIG_PHY_QCOM_UFS) += phy-qcom-ufs.o
 obj-$(CONFIG_PHY_QCOM_UFS) += phy-qcom-ufs-qmp-20nm.o
 obj-$(CONFIG_PHY_QCOM_UFS) += phy-qcom-ufs-qmp-14nm.o
diff --git a/drivers/phy/phy-qcom-qusb2.c b/drivers/phy/phy-qcom-qusb2.c
new file mode 100644
index ..045b0743a033
--- /dev/null
+++ b/drivers/phy/phy-qcom-qusb2.c
@@ -0,0 +1,491 @@
+/*
+ * Copyright (c) 2017, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General

[PATCH V7 0/4] phy: USB and PCIe phy drivers for Qcom chipsets

[Vivek Gautam]

This patch series adds couple of PHY drivers for Qualcomm chipsets.
a) qcom-qusb2 phy driver: that provides High Speed USB functionality.
b) qcom-qmp phy driver: that is a combo phy providing support for
   USB3, PCIe, UFS and few other controllers.

The patches are based on next branch of linux-phy tree.

These patches have been tested on Dragon board db820c hardware with
required set of dt patches and the patches to get rpm up on msm8996.
Couple of other patches [1, 2] fixing DMA config for XHCI are also
pulled in for testing.
A branch based on torvald's master is available in github [3].

Changes since v6:
 - Rebased on phy/next and *not* including phy grouping series[4].
 - qusb2-phy: addressed Stephen's comment.
   - Dropped pm8994_s2 corner regulator from QUSB2 phy bindings.
 - qmp-phy: none on functionality side.
 
Changes since v5:
 - Addressed review comments from Bjorn:
   - Removed instances of readl/wirtel_relaxed calls from the drivers.
 Instead, using simple readl/writel. Inserting a readl after a writel
 to ensure the write is through to the device.
   - Replaced regulator handling with regulator_bulk_** apis. This helps
 in cutting down a lot of regulator handling code.
   - Fixed minor return statements.

Changes since v4:
 - Addressed comment to add child nodes for qmp phy driver. Each phy lane
   now has a separate child node under the main qmp node.
 - Modified the clock and reset initialization and enable methods.
   Different phys - pcie, usb and later ufs, have varying number of clocks
   and resets that are mandatory. So adding provision for clocks and reset
   lists helps in requesting all mandatory resources for individual phys
   and handle their failure cases accordingly.

Changes since v3:
 - Addressed review comments given by Rob and Stephen for qusb2 phy
   and qmp phy bindings respectively.
 - Addressed review comments given by Stephen and Bjorn for qmp phy driver.

Changes since v2:
 - Addressed review comments given by Rob and Stephen for bindings.
 - Addressed the review comments given by Stephen for the qusb2 and qmp
   phy drivers.

Changes since v1:
 - Moved device tree binding documentation to separate patches, as suggested
   by Rob.
 - Addressed review comment regarding qfprom accesses by qusb2 phy driver,
   given by Rob.
 - Addressed review comments from Kishon.
 - Addressed review comments from Srinivas for QMP phy driver.
 - Addressed kbuild warning.

Please see individual patches for detailed changelogs.

[1] https://patchwork.kernel.org/patch/9567767/
[2] https://patchwork.kernel.org/patch/9567779/
[3] https://github.com/vivekgautam1/linux/tree/linux-v4.11-rc5-qmp-phy-db820c
[4] https://lkml.org/lkml/2017/3/20/407

Vivek Gautam (4):
  dt-bindings: phy: Add support for QUSB2 phy
  phy: qcom-qusb2: New driver for QUSB2 PHY on Qcom chips
  dt-bindings: phy: Add support for QMP phy
  phy: qcom-qmp: new qmp phy driver for qcom-chipsets

 .../devicetree/bindings/phy/qcom-qmp-phy.txt   |  106 ++
 .../devicetree/bindings/phy/qcom-qusb2-phy.txt |   43 +
 drivers/phy/Kconfig|   18 +
 drivers/phy/Makefile   |2 +
 drivers/phy/phy-qcom-qmp.c | 1153 
 drivers/phy/phy-qcom-qusb2.c   |  491 +
 6 files changed, 1813 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt
 create mode 100644 Documentation/devicetree/bindings/phy/qcom-qusb2-phy.txt
 create mode 100644 drivers/phy/phy-qcom-qmp.c
 create mode 100644 drivers/phy/phy-qcom-qusb2.c

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

--
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

Re: [PATCH v6 1/4] dt-bindings: phy: Add support for QUSB2 phy

[Vivek Gautam]

On 04/04/2017 11:58 PM, Stephen Boyd wrote:

On 03/20, Vivek Gautam wrote:

diff --git a/Documentation/devicetree/bindings/phy/qcom-qusb2-phy.txt 
b/Documentation/devicetree/bindings/phy/qcom-qusb2-phy.txt
new file mode 100644
index ..a6d19acde9e0
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/qcom-qusb2-phy.txt
@@ -0,0 +1,45 @@
+Qualcomm QUSB2 phy controller
+=
+
+QUSB2 controller supports LS/FS/HS usb connectivity on Qualcomm chipsets.
+
+Required properties:
+ - compatible: compatible list, contains "qcom,msm8996-qusb2-phy".
+ - reg: offset and length of the PHY register set.
+ - #phy-cells: must be 0.
+
+ - clocks: a list of phandles and clock-specifier pairs,
+  one for each entry in clock-names.
+ - clock-names: must be "cfg_ahb" for phy config clock,
+   "ref" for 19.2 MHz ref clk,
+   "iface" for phy interface clock (Optional).
+
+ - vdd-phy-supply: Phandle to a regulator supply to PHY core block.
+ - vdda-pll-supply: Phandle to 1.8V regulator supply to PHY refclk pll block.
+ - vdda-phy-dpdm-supply: Phandle to 3.1V regulator supply to Dp/Dm port 
signals.
+
+ - resets: Phandle to reset to phy block.
+
+Optional properties:
+ - nvmem-cells: Phandle to nvmem cell that contains 'HS Tx trim'
+   tuning parameter value for qusb2 phy.
+
+ - qcom,tcsr-syscon: Phandle to TCSR syscon register region.
+
+Example:
+   hsusb_phy: phy@7411000 {
+   compatible = "qcom,msm8996-qusb2-phy";
+   reg = <0x7411000 0x180>;
+   #phy-cells = <0>;
+
+   clocks = < GCC_USB_PHY_CFG_AHB2PHY_CLK>,
+   < GCC_RX1_USB2_CLKREF_CLK>,
+   clock-names = "cfg_ahb", "ref";
+
+   vdd-phy-supply = <_s2>;

pm8994_s2 is a "corner" regulator. I'm not sure how we're going
to have it listed here as something like a regulator supply in
the binding. We probably should leave it out for now and let the
power domain + pm_qos stuff for corners work out. From what I see
in the downstream driver the code is setting the corner to '4'
when active, and '1' when inactive.


Sure, let's allow power domain and corner voltage work handle
this. I will drop this regulator entry from bindings, and the driver.


Best regards
Vivek

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

--
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

Re: [PATCH v2 2/4] reset: Add APIs to manage array of resets

[Vivek Gautam]

Hi Philipp,


On 04/04/2017 06:17 PM, Philipp Zabel wrote:

Hi Vivek,

On Tue, 2017-04-04 at 16:09 +0530, Vivek Gautam wrote:
[...]

I'd prefer to mirror the gpiod API a little, and to have the number
contained in the array structure, similar to struct gpio_descs:

[...]

Alright, i can update this.
I took regulator_bulk interface as the reference, but now i see
gpio_descs has a smaller footprint.

Ok, understood.
I think the smaller footprint API is more convenient for the user.

[...]

+ * Returns 0 on success or error number on failure
+ */
+static int reset_control_array_get(struct device *dev, int num_rsts,
+   struct reset_control_array *resets,
+   bool shared, bool optional)

Can we make this count and return a pointer to the newly created array?

static struct reset_controls *
reset_control_array_get(struct device *dev, bool shared, bool optional)
{
...

That way the consumer doesn't have to care about counting and array
allocation.

Just trying to think again in line with the regulator bulk APIs.
Can't a user provide a list of reset controls as data and thus
request reset controls with a "id" and num_resets available.

e.g.
 const char * const rst_names[] = {
   "rst1", "rst2" ...
 };
 xyz_data = {
   .resets = rst_names;
   .num = ARRAY_SIZE(rst_names);
 };
and then the driver making use of reset_control_array APIs
to request this list of reset controls and assert/deassert them.

I am assuming this case when one user driver is used across a bunch
of platforms with different number of resets available.
We may not want to rely solely on the device tree entries, since
the resets can be mandatory in few cases and we may want to
return failure.

The way I understood the array API was as a method of handling a list of
anonymous resets, specified as

resets = < 1>, < 2>, < 3>;
// reset-names = "rst1", "rst2", "rst3"; /* don't care */

in the device tree.

Now if you want to handle a partial list of those as an unordered list,
with special consideration for others, that could be added as a separate
API when there is use for it. But I expect that most potential users of
this array API will not have to make such a distinction.


Alright, I will modify the array APIs as suggested to handle an
unordered list of resets passed from the device tree.
As you said, we can handle the special cases when the need arise.




@@ -85,6 +107,39 @@ static inline struct reset_control 
*__devm_reset_control_get(
return -ENOTSUPP;
   }
   
+static inline int reset_control_array_assert(int num_rsts,

+   struct reset_control_array *resets)
+{
+   return 0;
+}
+
+static inline int reset_control_array_deassert(int num_rsts,
+   struct reset_control_array *resets)
+{
+   return 0;
+}

Is this missing a stub for reset_control_array_get?

No, that's supposed to be a static function.

Oh right, it is static. Please ignore.


Thanks


regards
Philipp



Best Regards
Vivek

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

--
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

Re: [PATCH v2 2/4] reset: Add APIs to manage array of resets

[Vivek Gautam]

Hi Philipp,


On 04/03/2017 10:06 PM, Philipp Zabel wrote:

Hi Vivek,

thank you for the patch series. A few comments below: I'd like to reduce
the API surface a bit and include the counting and array allocation in
the _get functions, if possible.


Thank you for reviewing the patch. Please find my comments inline.



On Mon, 2017-04-03 at 19:12 +0530, Vivek Gautam wrote:

Many devices may want to request a bunch of resets
and control them. So it's better to manage them as an
array. Add APIs to _get(), _assert(), and _deassert()
an array of reset_control.

Cc: Philipp Zabel <p.za...@pengutronix.de>
Signed-off-by: Vivek Gautam <vivek.gau...@codeaurora.org>
---

Changes since v1:
  - New patch added to the series.

  drivers/reset/core.c  | 169 ++
  include/linux/reset.h | 108 
  2 files changed, 277 insertions(+)

diff --git a/drivers/reset/core.c b/drivers/reset/core.c
index 66db061165cb..fb908aa4f69e 100644
--- a/drivers/reset/core.c
+++ b/drivers/reset/core.c
@@ -477,3 +477,172 @@ int of_reset_control_get_count(struct device_node *node)
return count;
  }
  EXPORT_SYMBOL_GPL(of_reset_control_get_count);
+
+/*
+ * APIs to manage an array of reset controllers
+ */
+/**
+ * reset_control_array_assert: assert a list of resets
+ *
+ * @resets: reset control array holding info about a list of resets
+ * @num_rsts: number of resets to be asserted.

This should mention the API doesn't make any guarantees that the reset
lines controlled by the reset array are asserted or deasserted in any
particular order.


Sure, will add this comment.




+ * Returns 0 on success or error number on failure.
+ */
+int reset_control_array_assert(int num_rsts,
+   struct reset_control_array *resets)

I'd prefer to mirror the gpiod API a little, and to have the number
contained in the array structure, similar to struct gpio_descs:

struct reset_control_array {
unsigned int num_rstcs;
struct reset_control *rstc[];
};

int reset_control_array_assert(struct reset_control_array *resets)
{
...


Alright, i can update this.
I took regulator_bulk interface as the reference, but now i see
gpio_descs has a smaller footprint.


+{
+   int ret, i;
+
+   if (WARN_ON(IS_ERR_OR_NULL(resets)))
+   return -EINVAL;
+
+   for (i = 0; i < num_rsts; i++) {
+   ret = reset_control_assert(resets[i].rst);
+   if (ret)
+   return ret;
+   }
+
+   return 0;
+}
+EXPORT_SYMBOL_GPL(reset_control_array_assert);
+
+/**
+ * reset_control_array_deassert: deassert a list of resets
+ *
+ * @resets: reset control array holding info about a list of resets
+ * @num_rsts: number of resets to be deasserted.

Same here, no guarantees on the order in which the resets are
deasserted.


sure.




+ * Returns 0 on success or error number on failure.
+ */
+int reset_control_array_deassert(int num_rsts,
+   struct reset_control_array *resets)
+{
+   int ret, i;
+
+   if (WARN_ON(IS_ERR_OR_NULL(resets)))
+   return -EINVAL;
+
+   for (i = 0; i < num_rsts; i++)
+   ret = reset_control_deassert(resets[i].rst);
+   if (ret)
+   goto err;
+
+   return 0;
+
+err:
+   while (--i >= 0)
+   reset_control_assert(resets[i].rst);
+   return ret;
+}
+EXPORT_SYMBOL_GPL(reset_control_array_deassert);
+
+/**
+ * reset_control_array_get - Get a list of reset controllers

A list of "reset controls".


right, will update this.




+ *
+ * @dev: device that requests the list of reset controllers
+ * @num_rsts: number of reset controllers requested
+ * @resets: reset control array holding info about a list of resets
+ * @shared: whether reset controllers are shared or not
+ * @optional: whether it is optional to get the reset controllers
+ *

This should mention that the array API is intended for a list of resets
that just have to be asserted or deasserted, without any requirements on
the order.


Sure, will mention that.




+ * Returns 0 on success or error number on failure
+ */
+static int reset_control_array_get(struct device *dev, int num_rsts,
+   struct reset_control_array *resets,
+   bool shared, bool optional)

Can we make this count and return a pointer to the newly created array?

static struct reset_controls *
reset_control_array_get(struct device *dev, bool shared, bool optional)
{
...

That way the consumer doesn't have to care about counting and array
allocation.


Just trying to think again in line with the regulator bulk APIs.
Can't a user provide a list of reset controls as data and thus
request reset controls with a "id" and num_resets available.

e.g.
   const char * const rst_names[] = {
 "rst1", "rst2" ...
   };
   

Re: [PATCH v2 2/4] reset: Add APIs to manage array of resets

[Vivek Gautam]

On 04/04/2017 09:44 AM, kbuild test robot wrote:

Hi Vivek,

[auto build test WARNING on balbi-usb/next]
[also build test WARNING on v4.11-rc5 next-20170403]
[cannot apply to pza/reset/next]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Vivek-Gautam/reset-APIs-to-manage-a-list-of-resets/20170404-111639
base:   https://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git next
config: x86_64-randconfig-x004-201714 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
 # save the attached .config to linux build tree
 make ARCH=x86_64

All warnings (new ones prefixed by >>):

drivers/reset/core.c: In function 'reset_control_array_deassert':

drivers/reset/core.c:526:2: warning: this 'for' clause does not guard... 
[-Wmisleading-indentation]

  for (i = 0; i < num_rsts; i++)
  ^~~
drivers/reset/core.c:528:3: note: ...this statement, but the latter is 
misleadingly indented as if it is guarded by the 'for'
   if (ret)
   ^~


Right, gonna fix these warnings in the next version of the patch.
Thanks


vim +/for +526 drivers/reset/core.c

510 /**
511  * reset_control_array_deassert: deassert a list of resets
512  *
513  * @resets: reset control array holding info about a list of resets
514  * @num_rsts: number of resets to be deasserted.
515  *
516  * Returns 0 on success or error number on failure.
517  */
518 int reset_control_array_deassert(int num_rsts,
519 struct reset_control_array *resets)
520 {
521 int ret, i;
522 
523 if (WARN_ON(IS_ERR_OR_NULL(resets)))
524 return -EINVAL;
525 
  > 526  for (i = 0; i < num_rsts; i++)
527 ret = reset_control_deassert(resets[i].rst);
528 if (ret)
529 goto err;
530 
531 return 0;
532 
533 err:
534 while (--i >= 0)

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


BRs
Vivek

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

--
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

[PATCH v2 2/4] reset: Add APIs to manage array of resets

[Vivek Gautam]

Many devices may want to request a bunch of resets
and control them. So it's better to manage them as an
array. Add APIs to _get(), _assert(), and _deassert()
an array of reset_control.

Cc: Philipp Zabel <p.za...@pengutronix.de>
Signed-off-by: Vivek Gautam <vivek.gau...@codeaurora.org>
---

Changes since v1:
 - New patch added to the series.

 drivers/reset/core.c  | 169 ++
 include/linux/reset.h | 108 
 2 files changed, 277 insertions(+)

diff --git a/drivers/reset/core.c b/drivers/reset/core.c
index 66db061165cb..fb908aa4f69e 100644
--- a/drivers/reset/core.c
+++ b/drivers/reset/core.c
@@ -477,3 +477,172 @@ int of_reset_control_get_count(struct device_node *node)
return count;
 }
 EXPORT_SYMBOL_GPL(of_reset_control_get_count);
+
+/*
+ * APIs to manage an array of reset controllers
+ */
+/**
+ * reset_control_array_assert: assert a list of resets
+ *
+ * @resets: reset control array holding info about a list of resets
+ * @num_rsts: number of resets to be asserted.
+ *
+ * Returns 0 on success or error number on failure.
+ */
+int reset_control_array_assert(int num_rsts,
+   struct reset_control_array *resets)
+{
+   int ret, i;
+
+   if (WARN_ON(IS_ERR_OR_NULL(resets)))
+   return -EINVAL;
+
+   for (i = 0; i < num_rsts; i++) {
+   ret = reset_control_assert(resets[i].rst);
+   if (ret)
+   return ret;
+   }
+
+   return 0;
+}
+EXPORT_SYMBOL_GPL(reset_control_array_assert);
+
+/**
+ * reset_control_array_deassert: deassert a list of resets
+ *
+ * @resets: reset control array holding info about a list of resets
+ * @num_rsts: number of resets to be deasserted.
+ *
+ * Returns 0 on success or error number on failure.
+ */
+int reset_control_array_deassert(int num_rsts,
+   struct reset_control_array *resets)
+{
+   int ret, i;
+
+   if (WARN_ON(IS_ERR_OR_NULL(resets)))
+   return -EINVAL;
+
+   for (i = 0; i < num_rsts; i++)
+   ret = reset_control_deassert(resets[i].rst);
+   if (ret)
+   goto err;
+
+   return 0;
+
+err:
+   while (--i >= 0)
+   reset_control_assert(resets[i].rst);
+   return ret;
+}
+EXPORT_SYMBOL_GPL(reset_control_array_deassert);
+
+/**
+ * reset_control_array_get - Get a list of reset controllers
+ *
+ * @dev: device that requests the list of reset controllers
+ * @num_rsts: number of reset controllers requested
+ * @resets: reset control array holding info about a list of resets
+ * @shared: whether reset controllers are shared or not
+ * @optional: whether it is optional to get the reset controllers
+ *
+ * Returns 0 on success or error number on failure
+ */
+static int reset_control_array_get(struct device *dev, int num_rsts,
+   struct reset_control_array *resets,
+   bool shared, bool optional)
+{
+   int ret, i;
+   struct reset_control *rstc;
+
+   for (i = 0; i < num_rsts; i++) {
+   rstc = __of_reset_control_get(dev ? dev->of_node : NULL,
+   resets[i].name, i, shared, optional);
+   if (IS_ERR(rstc)) {
+   ret = PTR_ERR(rstc);
+   goto err_rst;
+   }
+   resets[i].rst = rstc;
+   }
+
+   return 0;
+
+err_rst:
+   while (--i >= 0)
+   reset_control_put(resets[i].rst);
+   return ret;
+}
+
+static void devm_reset_control_array_release(struct device *dev, void *res)
+{
+   struct reset_control_devres *ptr = res;
+   int i;
+
+   for (i = 0; i < ptr->num_resets; i++)
+   reset_control_put(ptr->resets[i].rst);
+}
+
+/**
+ * devm_reset_control_array_get - Resource managed reset_control_array_get
+ *   See reset_control_array_get() for more
+ *   details
+ *
+ * Returns 0 on success or error number on failure
+ */
+int devm_reset_control_array_get(struct device *dev, int num_rsts,
+   struct reset_control_array *resets,
+   bool shared, bool optional)
+{
+   struct reset_control_devres *ptr;
+   int ret;
+
+   ptr = devres_alloc(devm_reset_control_array_release, sizeof(*ptr),
+  GFP_KERNEL);
+   if (!ptr)
+   return -ENOMEM;
+
+   ret = reset_control_array_get(dev, num_rsts, resets,
+   shared, optional);
+   if (ret) {
+   ptr->resets = resets;
+   ptr->num_resets = num_rsts;
+   devres_add(dev, ptr);
+   } else {
+   devres_free(ptr);
+   }
+
+   return 0;
+}
+EXPORT_SYMBOL_GPL(devm_reset_control_array_get);
+
+int of_res

[PATCH v2 1/4] reset: Add API to count number of reset available with device

[Vivek Gautam]

Count number of reset phandles available with the device node
to know the resets a given device has.

Cc: Philipp Zabel <p.za...@pengutronix.de>
Signed-off-by: Vivek Gautam <vivek.gau...@codeaurora.org>
---

Changes since v1:
 - Handling the error path by returning error code for failures
   and ENODEV for count equal to 0.
 - Moved the function to drivers instead of putting in the includes.

 drivers/reset/core.c  | 22 ++
 include/linux/reset.h |  6 ++
 2 files changed, 28 insertions(+)

diff --git a/drivers/reset/core.c b/drivers/reset/core.c
index f1e5e65388bb..66db061165cb 100644
--- a/drivers/reset/core.c
+++ b/drivers/reset/core.c
@@ -455,3 +455,25 @@ int device_reset(struct device *dev)
return ret;
 }
 EXPORT_SYMBOL_GPL(device_reset);
+
+/**
+ * of_reset_control_get_count - Count number of resets available with a device
+ *
+ * @node: device node that contains 'resets'.
+ *
+ * Returns positive reset count on success, or error number on failure and
+ * on count being zero.
+ */
+int of_reset_control_get_count(struct device_node *node)
+{
+   int count;
+
+   count = of_count_phandle_with_args(node, "resets", "#reset-cells");
+   if (count < 0)
+   return count;
+   if (count == 0)
+   return -ENODEV;
+
+   return count;
+}
+EXPORT_SYMBOL_GPL(of_reset_control_get_count);
diff --git a/include/linux/reset.h b/include/linux/reset.h
index 96fb139bdd08..d89556412ccc 100644
--- a/include/linux/reset.h
+++ b/include/linux/reset.h
@@ -21,6 +21,7 @@ struct reset_control *__devm_reset_control_get(struct device 
*dev,
 bool optional);
 
 int __must_check device_reset(struct device *dev);
+int of_reset_control_get_count(struct device_node *node);
 
 static inline int device_reset_optional(struct device *dev)
 {
@@ -79,6 +80,11 @@ static inline struct reset_control *__devm_reset_control_get(
return optional ? NULL : ERR_PTR(-ENOTSUPP);
 }
 
+static inline int of_reset_control_get_count(struct device_node *node);
+{
+   return -ENOTSUPP;
+}
+
 #endif /* CONFIG_RESET_CONTROLLER */
 
 /**
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

--
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

[PATCH v2 3/4] usb: dwc3: of-simple: Add support to get resets for the device

[Vivek Gautam]

Add support to get a list of resets available for the device.
These resets must be kept de-asserted until the device is
in use.

Cc: Felipe Balbi <ba...@kernel.org>
Cc: Philipp Zabel <p.za...@pengutronix.de>
Signed-off-by: Vivek Gautam <vivek.gau...@codeaurora.org>
---

Changes since v1:
 - Using new APIs for reset control array.
 - Using the *_get_exclusive() API.
 - Added reset_control_array_put() to error and driver removal path.

 drivers/usb/dwc3/dwc3-of-simple.c | 45 +++
 1 file changed, 45 insertions(+)

diff --git a/drivers/usb/dwc3/dwc3-of-simple.c 
b/drivers/usb/dwc3/dwc3-of-simple.c
index fe414e7a9c78..96786f5ede0b 100644
--- a/drivers/usb/dwc3/dwc3-of-simple.c
+++ b/drivers/usb/dwc3/dwc3-of-simple.c
@@ -29,13 +29,48 @@
 #include 
 #include 
 #include 
+#include 
 
 struct dwc3_of_simple {
struct device   *dev;
struct clk  **clks;
int num_clocks;
+   int num_resets;
+   struct reset_control_array *resets;
 };
 
+static int dwc3_of_simple_reset_init(struct dwc3_of_simple *simple, int count)
+{
+   struct device   *dev = simple->dev;
+   int ret;
+
+   /* Not all platforms have resets, so don't return a failure */
+   if (count < 0)
+   return 0;
+
+   simple->num_resets = count;
+
+   simple->resets = devm_kcalloc(dev, count, sizeof(simple->resets),
+   GFP_KERNEL);
+   if (!simple->resets)
+   return -ENOMEM;
+
+   ret = of_reset_control_array_get_exclusive(dev->of_node, count,
+   simple->resets);
+   if (ret) {
+   dev_err(dev, "failed to get device resets\n");
+   return ret;
+   }
+
+   ret = reset_control_array_deassert(count, simple->resets);
+   if (ret) {
+   reset_control_array_put(count, simple->resets);
+   return ret;
+   }
+
+   return 0;
+}
+
 static int dwc3_of_simple_clk_init(struct dwc3_of_simple *simple, int count)
 {
struct device   *dev = simple->dev;
@@ -100,6 +135,10 @@ static int dwc3_of_simple_probe(struct platform_device 
*pdev)
if (ret)
return ret;
 
+   ret = dwc3_of_simple_reset_init(simple, of_reset_control_get_count(np));
+   if (ret)
+   return ret;
+
ret = of_platform_populate(np, NULL, NULL, dev);
if (ret) {
for (i = 0; i < simple->num_clocks; i++) {
@@ -107,6 +146,9 @@ static int dwc3_of_simple_probe(struct platform_device 
*pdev)
clk_put(simple->clks[i]);
}
 
+   reset_control_array_assert(simple->num_resets, simple->resets);
+   reset_control_array_put(simple->num_resets, simple->resets);
+
return ret;
}
 
@@ -128,6 +170,9 @@ static int dwc3_of_simple_remove(struct platform_device 
*pdev)
clk_put(simple->clks[i]);
}
 
+   reset_control_array_assert(simple->num_resets, simple->resets);
+   reset_control_array_put(simple->num_resets, simple->resets);
+
of_platform_depopulate(dev);
 
pm_runtime_put_sync(dev);
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

--
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

[PATCH v2 0/4] reset: APIs to manage a list of resets

[Vivek Gautam]

Set of patches to support getting and de/asserting a list (array)
of reset controllers available with the device.

These patches address the comments received for the earlier
posted series [1,2].
The users can pass a list of reset controllers and the number of
resets available in the driver or the ones using device tree can
request the total number of reset controllers available in the
device node and pass the information to reset_control_array_* APIs
to _get(), _assert() and _deassert() the list of resets.

Changes since v1:
 - Addressed comment for error handling in of_reset_control_get_count()
 - Added patch to manage reset controller array.
 - Rebased dwc3-of-simple changes based on the new set of APIs
   for reset control array.
 - Added a patch for soc/tegra/pmc driver to use the new set of
   reset control array APIs.

-- Based on Torvald's master branch.
-- Tested usb on db820c target for dwc3-of-simple driver.
-- Build tested for tegra/pmc driver. Needs testing.

[1] https://lkml.org/lkml/2017/2/22/12
[2] https://lkml.org/lkml/2017/2/22/11

Vivek Gautam (4):
  reset: Add API to count number of reset available with device
  reset: Add APIs to manage array of resets
  usb: dwc3: of-simple: Add support to get resets for the device
  soc/tegra: pmc: Use the new reset APIs to manage reset controllers

 drivers/reset/core.c  | 191 ++
 drivers/soc/tegra/pmc.c   |  92 --
 drivers/usb/dwc3/dwc3-of-simple.c |  45 +
 include/linux/reset.h | 114 +++
 4 files changed, 389 insertions(+), 53 deletions(-)

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

--
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

[PATCH v2 4/4] soc/tegra: pmc: Use the new reset APIs to manage reset controllers

[Vivek Gautam]

Make use of reset_control_array_*() set of APIs to manage
an array of reset controllers available with the device.

Cc: Thierry Reding <tred...@nvidia.com>
Cc: Philipp Zabel <p.za...@pengutronix.de>
Signed-off-by: Vivek Gautam <vivek.gau...@codeaurora.org>
---

Changes since v1:
 - New patch added to the series to enable this driver use the
   newer set of APIs that manage reset control array.

 drivers/soc/tegra/pmc.c | 92 +
 1 file changed, 39 insertions(+), 53 deletions(-)

diff --git a/drivers/soc/tegra/pmc.c b/drivers/soc/tegra/pmc.c
index e233dd5dcab3..d06e624381aa 100644
--- a/drivers/soc/tegra/pmc.c
+++ b/drivers/soc/tegra/pmc.c
@@ -124,7 +124,7 @@ struct tegra_powergate {
unsigned int id;
struct clk **clks;
unsigned int num_clks;
-   struct reset_control **resets;
+   struct reset_control_array *resets;
unsigned int num_resets;
 };
 
@@ -348,32 +348,14 @@ static int tegra_powergate_enable_clocks(struct 
tegra_powergate *pg)
return err;
 }
 
-static int tegra_powergate_reset_assert(struct tegra_powergate *pg)
+static inline int tegra_powergate_reset_assert(struct tegra_powergate *pg)
 {
-   unsigned int i;
-   int err;
-
-   for (i = 0; i < pg->num_resets; i++) {
-   err = reset_control_assert(pg->resets[i]);
-   if (err)
-   return err;
-   }
-
-   return 0;
+   return reset_control_array_assert(pg->num_resets, pg->resets);
 }
 
-static int tegra_powergate_reset_deassert(struct tegra_powergate *pg)
+static inline int tegra_powergate_reset_deassert(struct tegra_powergate *pg)
 {
-   unsigned int i;
-   int err;
-
-   for (i = 0; i < pg->num_resets; i++) {
-   err = reset_control_deassert(pg->resets[i]);
-   if (err)
-   return err;
-   }
-
-   return 0;
+   return reset_control_array_deassert(pg->num_resets, pg->resets);
 }
 
 static int tegra_powergate_power_up(struct tegra_powergate *pg,
@@ -566,12 +548,24 @@ int tegra_powergate_sequence_power_up(unsigned int id, 
struct clk *clk,
pg.id = id;
pg.clks = 
pg.num_clks = 1;
-   pg.resets = 
pg.num_resets = 1;
 
+   pg.resets = kcalloc(1, sizeof(pg.resets), GFP_KERNEL);
+   if (!pg.resets)
+   return -ENOMEM;
+
+   pg.resets[0].rst = rst;
+
err = tegra_powergate_power_up(, false);
-   if (err)
+   if (err) {
pr_err("failed to turn on partition %d: %d\n", id, err);
+   goto free_reset;
+   }
+
+   return 0;
+
+free_reset:
+   kfree(pg.resets);
 
return err;
 }
@@ -755,44 +749,38 @@ static int tegra_powergate_of_get_clks(struct 
tegra_powergate *pg,
 static int tegra_powergate_of_get_resets(struct tegra_powergate *pg,
 struct device_node *np, bool off)
 {
-   struct reset_control *rst;
-   unsigned int i, count;
+   unsigned int count;
int err;
 
-   count = of_count_phandle_with_args(np, "resets", "#reset-cells");
-   if (count == 0)
-   return -ENODEV;
+   count = of_reset_control_get_count(np);
+   if (count < 0)
+   return count;
 
-   pg->resets = kcalloc(count, sizeof(rst), GFP_KERNEL);
+   pg->resets = kcalloc(count, sizeof(pg->resets), GFP_KERNEL);
if (!pg->resets)
return -ENOMEM;
 
-   for (i = 0; i < count; i++) {
-   pg->resets[i] = of_reset_control_get_by_index(np, i);
-   if (IS_ERR(pg->resets[i])) {
-   err = PTR_ERR(pg->resets[i]);
-   goto error;
-   }
+   err = of_reset_control_array_get_exclusive(np, count, pg->resets);
+   if (err) {
+   pr_err("failed to get device resets\n");
+   goto free_reset;
+   }
 
-   if (off)
-   err = reset_control_assert(pg->resets[i]);
-   else
-   err = reset_control_deassert(pg->resets[i]);
+   if (off)
+   err = reset_control_array_assert(count, pg->resets);
+   else
+   err = reset_control_array_deassert(count, pg->resets);
 
-   if (err) {
-   reset_control_put(pg->resets[i]);
-   goto error;
-   }
-   }
+   if (err)
+   goto put_reset;
 
pg->num_resets = count;
 
return 0;
 
-error:
-   while (i--)
-   reset_control_put(pg->resets[i]);
-
+put_reset:
+   reset_control_array_put(count, pg->resets);
+free_reset:
kfree(pg->resets);
 
return err;
@@ -885,9 +873,7 @@ static void tegra_powergate_add(struct tegra_pmc *pmc, 
struct dev

Re: [PATCH v6 0/4] phy: USB and PCIe phy drivers for Qcom chipsets

[Vivek Gautam]

On 03/20/2017 07:24 PM, Vivek Gautam wrote:

This patch series adds couple of PHY drivers for Qualcomm chipsets.
a) qcom-qusb2 phy driver: that provides High Speed USB functionality.
b) qcom-qmp phy driver: that is a combo phy providing support for
USB3, PCIe, UFS and few other controllers.

The patches are based on next branch of linux-phy tree, and depends
on phy driver grouping series[1]:
[PATCH v4 0/3] phy: Group phy drivers based on vendor listing.

These patches have been tested on Dragon board db820c hardware with
required set of dt patches and the patches to get rpm up on msm8996.
Couple of other patches [2, 3] fixing DMA config for XHCI are also
pulled in for testing.
The complete branch is available in github [4].

Changes since v5:
  - Addressed review comments from Bjorn:
- Removed instances of readl/wirtel_relaxed calls from the drivers.
  Instead, using simple readl/writel. Inserting a readl after a writel
  to ensure the write is through to the device.
- Replaced regulator handling with regulator_bulk_** apis. This helps
  in cutting down a lot of regulator handling code.
- Fixed minor return statements.

Changes since v4:
  - Addressed comment to add child nodes for qmp phy driver. Each phy lane
now has a separate child node under the main qmp node.
  - Modified the clock and reset initialization and enable methods.
Different phys - pcie, usb and later ufs, have varying number of clocks
and resets that are mandatory. So adding provision for clocks and reset
lists helps in requesting all mandatory resources for individual phys
and handle their failure cases accordingly.

Changes since v3:
  - Addressed review comments given by Rob and Stephen for qusb2 phy
and qmp phy bindings respectively.
  - Addressed review comments given by Stephen and Bjorn for qmp phy driver.

Changes since v2:
  - Addressed review comments given by Rob and Stephen for bindings.
  - Addressed the review comments given by Stephen for the qusb2 and qmp
phy drivers.

Changes since v1:
  - Moved device tree binding documentation to separate patches, as suggested
by Rob.
  - Addressed review comment regarding qfprom accesses by qusb2 phy driver,
given by Rob.
  - Addressed review comments from Kishon.
  - Addressed review comments from Srinivas for QMP phy driver.
  - Addressed kbuild warning.

Please see individual patches for detailed changelogs.

[1] https://www.spinics.net/lists/arm-kernel/msg569990.html
[2] https://patchwork.kernel.org/patch/9567767/
[3] https://patchwork.kernel.org/patch/9567779/
[4] https://github.com/vivekgautam1/linux/tree/linux-phy-next-qcom-phy-db820c

Vivek Gautam (4):
   dt-bindings: phy: Add support for QUSB2 phy
   phy: qcom-qusb2: New driver for QUSB2 PHY on Qcom chips
   dt-bindings: phy: Add support for QMP phy
   phy: qcom-qmp: new qmp phy driver for qcom-chipsets


Gentle ping!
Any more comments on this series, or are we planning to get this in for 
4.12 ?


Regards
Vivek



  .../devicetree/bindings/phy/qcom-qmp-phy.txt   |  106 ++
  .../devicetree/bindings/phy/qcom-qusb2-phy.txt |   45 +
  drivers/phy/qualcomm/Kconfig   |   18 +
  drivers/phy/qualcomm/Makefile  |2 +
  drivers/phy/qualcomm/phy-qcom-qmp.c| 1153 
  drivers/phy/qualcomm/phy-qcom-qusb2.c  |  491 +
  6 files changed, 1815 insertions(+)
  create mode 100644 Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt
  create mode 100644 Documentation/devicetree/bindings/phy/qcom-qusb2-phy.txt
  create mode 100644 drivers/phy/qualcomm/phy-qcom-qmp.c
  create mode 100644 drivers/phy/qualcomm/phy-qcom-qusb2.c



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

--
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

[PATCH v6 0/4] phy: USB and PCIe phy drivers for Qcom chipsets

[Vivek Gautam]

This patch series adds couple of PHY drivers for Qualcomm chipsets.
a) qcom-qusb2 phy driver: that provides High Speed USB functionality.
b) qcom-qmp phy driver: that is a combo phy providing support for
   USB3, PCIe, UFS and few other controllers.

The patches are based on next branch of linux-phy tree, and depends
on phy driver grouping series[1]:
[PATCH v4 0/3] phy: Group phy drivers based on vendor listing.

These patches have been tested on Dragon board db820c hardware with
required set of dt patches and the patches to get rpm up on msm8996.
Couple of other patches [2, 3] fixing DMA config for XHCI are also
pulled in for testing.
The complete branch is available in github [4].

Changes since v5:
 - Addressed review comments from Bjorn:
   - Removed instances of readl/wirtel_relaxed calls from the drivers.
 Instead, using simple readl/writel. Inserting a readl after a writel
 to ensure the write is through to the device.
   - Replaced regulator handling with regulator_bulk_** apis. This helps
 in cutting down a lot of regulator handling code.
   - Fixed minor return statements.

Changes since v4:
 - Addressed comment to add child nodes for qmp phy driver. Each phy lane
   now has a separate child node under the main qmp node.
 - Modified the clock and reset initialization and enable methods.
   Different phys - pcie, usb and later ufs, have varying number of clocks
   and resets that are mandatory. So adding provision for clocks and reset
   lists helps in requesting all mandatory resources for individual phys
   and handle their failure cases accordingly.

Changes since v3:
 - Addressed review comments given by Rob and Stephen for qusb2 phy
   and qmp phy bindings respectively.
 - Addressed review comments given by Stephen and Bjorn for qmp phy driver.

Changes since v2:
 - Addressed review comments given by Rob and Stephen for bindings.
 - Addressed the review comments given by Stephen for the qusb2 and qmp
   phy drivers.

Changes since v1:
 - Moved device tree binding documentation to separate patches, as suggested
   by Rob.
 - Addressed review comment regarding qfprom accesses by qusb2 phy driver,
   given by Rob.
 - Addressed review comments from Kishon.
 - Addressed review comments from Srinivas for QMP phy driver.
 - Addressed kbuild warning.

Please see individual patches for detailed changelogs.

[1] https://www.spinics.net/lists/arm-kernel/msg569990.html
[2] https://patchwork.kernel.org/patch/9567767/
[3] https://patchwork.kernel.org/patch/9567779/
[4] https://github.com/vivekgautam1/linux/tree/linux-phy-next-qcom-phy-db820c

Vivek Gautam (4):
  dt-bindings: phy: Add support for QUSB2 phy
  phy: qcom-qusb2: New driver for QUSB2 PHY on Qcom chips
  dt-bindings: phy: Add support for QMP phy
  phy: qcom-qmp: new qmp phy driver for qcom-chipsets

 .../devicetree/bindings/phy/qcom-qmp-phy.txt   |  106 ++
 .../devicetree/bindings/phy/qcom-qusb2-phy.txt |   45 +
 drivers/phy/qualcomm/Kconfig   |   18 +
 drivers/phy/qualcomm/Makefile  |2 +
 drivers/phy/qualcomm/phy-qcom-qmp.c| 1153 
 drivers/phy/qualcomm/phy-qcom-qusb2.c  |  491 +
 6 files changed, 1815 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt
 create mode 100644 Documentation/devicetree/bindings/phy/qcom-qusb2-phy.txt
 create mode 100644 drivers/phy/qualcomm/phy-qcom-qmp.c
 create mode 100644 drivers/phy/qualcomm/phy-qcom-qusb2.c

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

--
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

[PATCH v6 1/4] dt-bindings: phy: Add support for QUSB2 phy

[Vivek Gautam]

Qualcomm chipsets have QUSB2 phy controller that provides
HighSpeed functionality for DWC3 controller.
Adding dt binding information for the same.

Signed-off-by: Vivek Gautam <vivek.gau...@codeaurora.org>
Acked-by: Rob Herring <r...@kernel.org>
---

Changes since v5:
 - Removed leading 0 from the address in 'reg' property.

Changes since v4:
 - None.

Changes since v3:
 - Added 'Acked-by' from Rob.
 - Removed 'reset-names' and 'nvmem-cell-names' from the bindings
   since we use only one cell.

Changes since v2:
 - Removed binding for "ref_clk_src" since we don't request this
   clock in the driver.
 - Addressed s/vdda-phy-dpdm/vdda-phy-dpdm-supply.
 - Addressed s/ref_clk/ref. Don't need to add '_clk' suffix to clock names.
 - Addressed s/tune2_hstx_trim_efuse/tune2_hstx_trim. Don't need to add
   'efuse' suffix to nvmem cell.
 - Addressed s/qusb2phy/phy for the node name.

Changes since v1:
 - New patch, forked out of the original driver patch:
   "phy: qcom-qusb2: New driver for QUSB2 PHY on Qcom chips"
 - Updated dt bindings to remove 'hstx-trim-bit-offset' and
   'hstx-trim-bit-len' bindings.

 .../devicetree/bindings/phy/qcom-qusb2-phy.txt | 45 ++
 1 file changed, 45 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/phy/qcom-qusb2-phy.txt

diff --git a/Documentation/devicetree/bindings/phy/qcom-qusb2-phy.txt 
b/Documentation/devicetree/bindings/phy/qcom-qusb2-phy.txt
new file mode 100644
index ..a6d19acde9e0
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/qcom-qusb2-phy.txt
@@ -0,0 +1,45 @@
+Qualcomm QUSB2 phy controller
+=
+
+QUSB2 controller supports LS/FS/HS usb connectivity on Qualcomm chipsets.
+
+Required properties:
+ - compatible: compatible list, contains "qcom,msm8996-qusb2-phy".
+ - reg: offset and length of the PHY register set.
+ - #phy-cells: must be 0.
+
+ - clocks: a list of phandles and clock-specifier pairs,
+  one for each entry in clock-names.
+ - clock-names: must be "cfg_ahb" for phy config clock,
+   "ref" for 19.2 MHz ref clk,
+   "iface" for phy interface clock (Optional).
+
+ - vdd-phy-supply: Phandle to a regulator supply to PHY core block.
+ - vdda-pll-supply: Phandle to 1.8V regulator supply to PHY refclk pll block.
+ - vdda-phy-dpdm-supply: Phandle to 3.1V regulator supply to Dp/Dm port 
signals.
+
+ - resets: Phandle to reset to phy block.
+
+Optional properties:
+ - nvmem-cells: Phandle to nvmem cell that contains 'HS Tx trim'
+   tuning parameter value for qusb2 phy.
+
+ - qcom,tcsr-syscon: Phandle to TCSR syscon register region.
+
+Example:
+   hsusb_phy: phy@7411000 {
+   compatible = "qcom,msm8996-qusb2-phy";
+   reg = <0x7411000 0x180>;
+   #phy-cells = <0>;
+
+   clocks = < GCC_USB_PHY_CFG_AHB2PHY_CLK>,
+   < GCC_RX1_USB2_CLKREF_CLK>,
+   clock-names = "cfg_ahb", "ref";
+
+   vdd-phy-supply = <_s2>;
+   vdda-pll-supply = <_l12>;
+   vdda-phy-dpdm-supply = <_l24>;
+
+   resets = < GCC_QUSB2PHY_PRIM_BCR>;
+   nvmem-cells = <_hstx_trim>;
+};
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

--
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

[PATCH v6 2/4] phy: qcom-qusb2: New driver for QUSB2 PHY on Qcom chips

[Vivek Gautam]

PHY transceiver driver for QUSB2 phy controller that provides
HighSpeed functionality for DWC3 controller present on
Qualcomm chipsets.

Signed-off-by: Vivek Gautam <vivek.gau...@codeaurora.org>
Reviewed-by: Stephen Boyd <sb...@codeaurora.org>
---

Changes since v5:
 - Rebased on top of phy grouping series. So the driver now sits in
   drivers/phy/qualcomm/
 - Removed instances of readl_relaxed() and writel_relaxed(), and using
   readl() and writel() instead.
 - Replaced regulator handling with regulator_bulk() apis, so that
   qusb2_phy_toggle_power() method is completely dropped.
 - Removed memory barriers from the driver. Instead, using readl() over
   the register to ensure that the write is through to the device.
 - Fixed nits about return statement from probe() and qusb2_phy_poweron().

Changes since v4:
 - Updated the copyright year to 2017.
 - Removed unnecessary of_match_ptr() cast for the match table,
   since the driver is compiled for CONFIG_OF.

Changes since v3:
 - Added 'Reviewed-by' from Stephen.
 - Fixed debug message for qusb2_phy_set_tune2_param().
 - Replaced devm_reset_control_get() with devm_reset_control_get_by_index()
   since we are requesting only one reset.
 - Updated devm_nvmem_cell_get() with a NULL cell id.
 - Made error labels more idiomatic.
 - Refactored qusb2_setbits() and qusb2_clrbits() a little bit to accept
   base address and register offset as two separate arguments.

Changes since v2:
 - Removed selecting 'RESET_CONTROLLER' config.
 - Added error handling for clk_prepare_enable paths.
 - Removed explicitly setting ref_clk rate to 19.2 MHz. Don't need to
   do that since 'xo' is modeled as parent to this clock.
 - Removed 'ref_clk_src' handling. Driver doesn't need to request and
   handle this clock.
 - Moved nvmem_cell_get() to probe function.
 - Simplified phy pll status handling.
 - Using of_device_get_match_data() to get match data.
 - Uniformly using lowercase for hex numbers.
 - Fixed sparse warnings.
 - Using shorter variable names in structure and in functions.
 - Handling various comment style shortcomings.

Changes since v1:
 - removed reference to clk_enabled/pwr_enabled.
 - moved clock and regulator enable code to phy_power_on/off() callbacks.
 - fixed return on EPROBE_DEFER in qusb2_phy_probe().
 - fixed phy create and phy register ordering.
 - removed references to non-lkml links from commit message.
 - took care of other minor nits.
 - Fixed coccinelle warnings -
   'PTR_ERR applied after initialization to constant'
 - Addressed review comment, regarding qfprom access for tune2 param value.
   This driver is now based on qfprom patch[1] that allows byte access now.

 drivers/phy/qualcomm/Kconfig  |  10 +
 drivers/phy/qualcomm/Makefile |   1 +
 drivers/phy/qualcomm/phy-qcom-qusb2.c | 491 ++
 3 files changed, 502 insertions(+)
 create mode 100644 drivers/phy/qualcomm/phy-qcom-qusb2.c

diff --git a/drivers/phy/qualcomm/Kconfig b/drivers/phy/qualcomm/Kconfig
index 458d224f18a5..f31f05066da8 100644
--- a/drivers/phy/qualcomm/Kconfig
+++ b/drivers/phy/qualcomm/Kconfig
@@ -15,6 +15,16 @@ config PHY_QCOM_IPQ806X_SATA
depends on OF
select GENERIC_PHY
 
+config PHY_QCOM_QUSB2
+   tristate "Qualcomm QUSB2 PHY Driver"
+   depends on OF && (ARCH_QCOM || COMPILE_TEST)
+   select GENERIC_PHY
+   help
+ Enable this to support the HighSpeed QUSB2 PHY transceiver for USB
+ controllers on Qualcomm chips. This driver supports the high-speed
+ PHY which is usually paired with either the ChipIdea or Synopsys DWC3
+ USB IPs on MSM SOCs.
+
 config PHY_QCOM_UFS
tristate "Qualcomm UFS PHY driver"
depends on OF && ARCH_QCOM
diff --git a/drivers/phy/qualcomm/Makefile b/drivers/phy/qualcomm/Makefile
index 07f7c7896f4d..eed5327a9206 100644
--- a/drivers/phy/qualcomm/Makefile
+++ b/drivers/phy/qualcomm/Makefile
@@ -1,5 +1,6 @@
 obj-$(CONFIG_PHY_QCOM_APQ8064_SATA)+= phy-qcom-apq8064-sata.o
 obj-$(CONFIG_PHY_QCOM_IPQ806X_SATA)+= phy-qcom-ipq806x-sata.o
+obj-$(CONFIG_PHY_QCOM_QUSB2)   += phy-qcom-qusb2.o
 obj-$(CONFIG_PHY_QCOM_UFS) += phy-qcom-ufs.o
 obj-$(CONFIG_PHY_QCOM_UFS) += phy-qcom-ufs-qmp-20nm.o
 obj-$(CONFIG_PHY_QCOM_UFS) += phy-qcom-ufs-qmp-14nm.o
diff --git a/drivers/phy/qualcomm/phy-qcom-qusb2.c 
b/drivers/phy/qualcomm/phy-qcom-qusb2.c
new file mode 100644
index ..2b2b2b5222c4
--- /dev/null
+++ b/drivers/phy/qualcomm/phy-qcom-qusb2.c
@@ -0,0 +1,491 @@
+/*
+ * Copyright (c) 2017, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT

[PATCH v6 3/4] dt-bindings: phy: Add support for QMP phy

[Vivek Gautam]

Qualcomm chipsets have QMP phy controller that provides
support to a number of controller, viz. PCIe, UFS, and USB.
Adding dt binding information for the same.

Signed-off-by: Vivek Gautam <vivek.gau...@codeaurora.org>
Acked-by: Rob Herring <r...@kernel.org>
---

Changes since v5:
 - Added Rob's 'Ack' for the new child nodes based bindings.
 - Dropped leading 0 from the address in 'reg' property.
 - Fixed '@xyz' part of the node name with correct address.

Changes since v4:
 - Added bindings for child nodes. Each phy lane is represented by child
   node with its own register space (for tx, rx and pcs blocks), and clocks
   and resets for power control facility.
 - Removed register space and lane offsets for tx, rx and pcs blocks from
   qmp phy node.
 - #phy-cells is now part of each child node and thus must be 0.
 - Added information on list of mandatory clocks and resets for each phy.

Changes since v3:
 - Added #clock-cells = <1>, indicating that phy is a clock provider.

Changes since v2:
 - Removed binding for "ref_clk_src" since we don't request this
   clock in the driver.
 - Addressed s/ref_clk/ref. Don't need to add '_clk' suffix to clock names.
 - Using 'phy' for the node name.

Changes since v1:
 - New patch, forked out of the original driver patch:
   "phy: qcom-qmp: new qmp phy driver for qcom-chipsets"
 - Added 'Acked-by' from Rob.
 - Updated bindings to include mem resource as a list of
   offset - length pair for serdes block and for each lane.
 - Added a new binding for 'lane-offsets' that contains offsets
   to tx, rx and pcs blocks from each lane base address.

 .../devicetree/bindings/phy/qcom-qmp-phy.txt   | 106 +
 1 file changed, 106 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt

diff --git a/Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt 
b/Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt
new file mode 100644
index ..e11c563a65ec
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt
@@ -0,0 +1,106 @@
+Qualcomm QMP PHY controller
+===
+
+QMP phy controller supports physical layer functionality for a number of
+controllers on Qualcomm chipsets, such as, PCIe, UFS, and USB.
+
+Required properties:
+ - compatible: compatible list, contains:
+  "qcom,msm8996-qmp-pcie-phy" for 14nm PCIe phy on msm8996,
+  "qcom,msm8996-qmp-usb3-phy" for 14nm USB3 phy on msm8996.
+
+ - reg: offset and length of register set for PHY's common serdes block.
+
+ - #clock-cells: must be 1
+- Phy pll outputs a bunch of clocks for Tx, Rx and Pipe
+  interface (for pipe based PHYs). These clock are then gate-controlled
+  by gcc.
+ - #address-cells: must be 1
+ - #size-cells: must be 1
+ - ranges: must be present
+
+ - clocks: a list of phandles and clock-specifier pairs,
+  one for each entry in clock-names.
+ - clock-names: "cfg_ahb" for phy config clock,
+   "aux" for phy aux clock,
+   "ref" for 19.2 MHz ref clk,
+   For "qcom,msm8996-qmp-pcie-phy" must contain:
+   "aux", "cfg_ahb", "ref".
+   For "qcom,msm8996-qmp-usb3-phy" must contain:
+   "aux", "cfg_ahb", "ref".
+
+ - resets: a list of phandles and reset controller specifier pairs,
+  one for each entry in reset-names.
+ - reset-names: "phy" for reset of phy block,
+   "common" for phy common block reset,
+   "cfg" for phy's ahb cfg block reset (Optional).
+   For "qcom,msm8996-qmp-pcie-phy" must contain:
+"phy", "common", "cfg".
+   For "qcom,msm8996-qmp-usb3-phy" must contain
+"phy", "common".
+
+ - vdda-phy-supply: Phandle to a regulator supply to PHY core block.
+ - vdda-pll-supply: Phandle to 1.8V regulator supply to PHY refclk pll block.
+
+Optional properties:
+ - vddp-ref-clk-supply: Phandle to a regulator supply to any specific refclk
+   pll block.
+
+Required nodes:
+ - Each device node of QMP phy is required to have as many child nodes as
+   the number of lanes the PHY has.
+
+Required properties for child node:
+ - reg: list of offset and length pairs of register sets for PHY blocks -
+   tx, rx and pcs.
+
+ - #phy-cells: must be 0
+
+ - clocks: a list of phandles and clock-specifier pairs,
+  one for each entry in clock-names.
+ - clock-names: Must contain following for pcie and usb qmp phys:
+"pipe" for pipe clock specific to each lane.
+
+ - resets: a list of phandles and reset controller specifier pairs,
+  one for each entry in reset-names.

[PATCH v6 4/4] phy: qcom-qmp: new qmp phy driver for qcom-chipsets

[Vivek Gautam]

Qualcomm SOCs have QMP phy controller that provides support
to a number of controller, viz. PCIe, UFS, and USB.
Add a new driver, based on generic phy framework, for this
phy controller.

Signed-off-by: Vivek Gautam <vivek.gau...@codeaurora.org>
Tested-by: Srinivas Kandagatla <srinivas.kandaga...@linaro.org>
---

Changes since v5:
 - Rebased on top of phy grouping series. So the driver now sits in
   drivers/phy/qualcomm/
 - Removed instances of readl_relaxed() and writel_relaxed(), and using
   readl() and writel() instead.
 - Replaced regulator handling with regulator_bulk() apis, so that
   qusb2_phy_toggle_power() method is completely dropped.
 - Removed memory barriers from the driver. Instead, added an extra readl()
   over the register in qphy_setbits() and qphy_clrbits() to ensure that
   the write is through to the device.
 - Fixed nits about return statement from probe(), phy_pipe_clk_register()
   and qcom_qmp_phy_create().

Changes since v4:
 - Added provision for child nodes representing each phy lane.
   Each of these nodes have their own register space for tx, rx and pcs
   blocks. Added provision in qcom_qmp_phy_create() to iomap these
   address spaces.
 - Added list of clocks and resets that are mandatory for each phy.
   qcom_qmp_phy_clk_init(), and qcom_qmp_phy_reset_init() methods
   request this list and maintains it with qmp.
   The clocks and resets are then enabled/de-asserted based on this list.
   This list is also updated in the binding documentation.
 - Removed qcom_qmp_phy_xlate() method as we don't need it with
   #phy-cells 0.
 - Removed unnecessary of_match_ptr() cast for the match table,
   since the driver is compiled for CONFIG_OF.
 - Updated copyright year to 2017.

Changes since v3:
 - Renamed 'struct qcom_qmp_phy' to 'struct qcom_qmp' and
   'struct qmp_phy_desc' to 'struct qmp_phy' to avoid any confusion
   in distinguishing between QMP phy block and per-lane phy which is
   the actual phy in Linux eyes (suggested by Bjorn Andersson).
 - Made error labels more idiomatic.
 - Modified status checking for phy pcs.
 - Fixed power_down_delay check.
 - Refactored phy_pipe_clk_register() to register the pipe clock source
   using devm_clk_hw_register() (suggested by Stephen).
 - qcom_qmp_phy_xlate() function:
   - Removed unnecessary 'for loop'.
   - Added additional check for '0' or -ve args_count.
 - Fixed the mixed tabs and spaces in pipe_clk_src diagram.
 - Removed instances of memset() since we use snprintf() for the
   buffers.
 - Refactored qphy_setbits() and qphy_clrbits() a little bit to accept
   base address and register offset as two separate arguments.

Changes since v2:
 - Removed selecting 'RESET_CONTROLLER' config.
 - Added error handling for clk_prepare_enable paths.
 - Removed 'ref_clk_src' handling. Driver doesn't need to request and
   handle this clock.
 - Using readl_poll_timeout() to simplify pcs ready status polling.
   Also fixed the polling condition for pcs block ready status:
   'Common block ready status bit is set on phy init completion, while
   PCS block ready status bit (PHYSTATUS) is reset on phy init
   completion.'
 - Moved out the per-lane phy creation from probe() to separate
   function.
 - Registering pipe clock source as a fixed rate clock that comes
   out of the PLL block of QMP phy. These source clocks serve as
   parent to 'pipe_clks' that are requested by pcie or usb3 phys.
 - Using of_device_get_match_data() to get match data.
 - Fixed sparse warnings for 'static' and 'const'.
 - Using shorter variable names in structure and in functions.
 - Handling various comment style shortcomings.

Changes since v1:
 - Fixed missing mutex_unlock() calls in error cases, reported by
   Julia Lawall.
 - Selecting CONFIG_RESET_CONTROLLER when this driver is enabled.
 - Added a boolean property to check if the phy has individual lane
   reset available.
 - Took care or EPROBE_DEFER, dev_vdbg() and other minor nits.
 - Removed references to non-lkml links from commit message.
 - Moved to use separate iomem resources for each lanes.
   Tx, Rx and PCS offsets per lane can now come from dt bindings.

 drivers/phy/qualcomm/Kconfig|8 +
 drivers/phy/qualcomm/Makefile   |1 +
 drivers/phy/qualcomm/phy-qcom-qmp.c | 1153 +++
 3 files changed, 1162 insertions(+)
 create mode 100644 drivers/phy/qualcomm/phy-qcom-qmp.c

diff --git a/drivers/phy/qualcomm/Kconfig b/drivers/phy/qualcomm/Kconfig
index f31f05066da8..604c7efcb221 100644
--- a/drivers/phy/qualcomm/Kconfig
+++ b/drivers/phy/qualcomm/Kconfig
@@ -15,6 +15,14 @@ config PHY_QCOM_IPQ806X_SATA
depends on OF
select GENERIC_PHY
 
+config PHY_QCOM_QMP
+   tristate "Qualcomm QMP PHY Driver"
+   depends on OF && (ARCH_QCOM || COMPILE_TEST)
+   select GENERIC_PHY
+   help
+ Enable this to support the QMP PHY transceiver that is used
+ with controllers such as PCIe, UFS, and US

[PATCH v4 1/3] phy: qcom-usb: Remove unused ulpi phy header

[Vivek Gautam]

Ulpi phy header is not used for anything. Remove the same
from qcom-hs and qcom-hsic phy drivers.

Signed-off-by: Vivek Gautam <vivek.gau...@codeaurora.org>
Suggested-by: Stephen Boyd <stephen.b...@linaro.org>
Cc: Kishon Vijay Abraham I <kis...@ti.com>
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-arm-...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Cc: linux-usb@vger.kernel.org
---

 - New patch added in the series.
   Removing headers as per Stephen's suggestion.

 drivers/phy/phy-qcom-usb-hs.c   | 2 --
 drivers/phy/phy-qcom-usb-hsic.c | 2 --
 2 files changed, 4 deletions(-)

diff --git a/drivers/phy/phy-qcom-usb-hs.c b/drivers/phy/phy-qcom-usb-hs.c
index 94dfbfd739c3..43704f4f23e9 100644
--- a/drivers/phy/phy-qcom-usb-hs.c
+++ b/drivers/phy/phy-qcom-usb-hs.c
@@ -15,8 +15,6 @@
 #include 
 #include 
 
-#include "ulpi_phy.h"
-
 #define ULPI_PWR_CLK_MNG_REG   0x88
 # define ULPI_PWR_OTG_COMP_DISABLE BIT(0)
 
diff --git a/drivers/phy/phy-qcom-usb-hsic.c b/drivers/phy/phy-qcom-usb-hsic.c
index 47690f9945b9..6dcaf04fa367 100644
--- a/drivers/phy/phy-qcom-usb-hsic.c
+++ b/drivers/phy/phy-qcom-usb-hsic.c
@@ -13,8 +13,6 @@
 #include 
 #include 
 
-#include "ulpi_phy.h"
-
 #define ULPI_HSIC_CFG  0x30
 #define ULPI_HSIC_IO_CAL   0x33
 
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

--
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

[PATCH v4 0/3] phy: Group phy drivers based on vendor listing

[Vivek Gautam]

This is the next version to an earlier posted series [1].
Missed Cc'ing the first patch of the previous series [1] to lkml.
Posting out this series now after addressing comments
and after adding the received 'Acked-by' and 'Reviewed-by'
tags.

This series is based on linux-phy/next branch.

[1] https://www.spinics.net/lists/arm-kernel/msg568370.html

Signed-off-by: Vivek Gautam <vivek.gau...@codeaurora.org>
Cc: Kishon Vijay Abraham I <kis...@ti.com>
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-arm-...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Cc: linux-usb@vger.kernel.org

--
Vivek Gautam (3):
  phy: qcom-usb: Remove unused ulpi phy header
  phy: Move ULPI phy header out of drivers to include path
  phy: Group vendor specific phy drivers

 MAINTAINERS|  18 +-
 drivers/phy/Kconfig| 471 +
 drivers/phy/Makefile   |  67 +--
 drivers/phy/allwinner/Kconfig  |  31 ++
 drivers/phy/allwinner/Makefile |   2 +
 drivers/phy/{ => allwinner}/phy-sun4i-usb.c|   0
 drivers/phy/{ => allwinner}/phy-sun9i-usb.c|   0
 drivers/phy/broadcom/Kconfig   |  64 +++
 drivers/phy/broadcom/Makefile  |   7 +
 drivers/phy/{ => broadcom}/phy-bcm-cygnus-pcie.c   |   0
 drivers/phy/{ => broadcom}/phy-bcm-kona-usb2.c |   0
 drivers/phy/{ => broadcom}/phy-bcm-ns-usb2.c   |   0
 drivers/phy/{ => broadcom}/phy-bcm-ns-usb3.c   |   0
 drivers/phy/{ => broadcom}/phy-bcm-ns2-pcie.c  |   0
 drivers/phy/{ => broadcom}/phy-bcm-nsp-usb3.c  |   0
 drivers/phy/{ => broadcom}/phy-brcm-sata.c |   0
 drivers/phy/hisilicon/Kconfig  |  20 +
 drivers/phy/hisilicon/Makefile |   2 +
 drivers/phy/{ => hisilicon}/phy-hi6220-usb.c   |   0
 drivers/phy/{ => hisilicon}/phy-hix5hd2-sata.c |   0
 drivers/phy/marvell/Kconfig|  50 +++
 drivers/phy/marvell/Makefile   |   6 +
 drivers/phy/{ => marvell}/phy-armada375-usb2.c |   0
 drivers/phy/{ => marvell}/phy-berlin-sata.c|   0
 drivers/phy/{ => marvell}/phy-berlin-usb.c |   0
 drivers/phy/{ => marvell}/phy-mvebu-sata.c |   0
 drivers/phy/{ => marvell}/phy-pxa-28nm-hsic.c  |   0
 drivers/phy/{ => marvell}/phy-pxa-28nm-usb2.c  |   0
 drivers/phy/qualcomm/Kconfig   |  38 ++
 drivers/phy/qualcomm/Makefile  |   7 +
 drivers/phy/{ => qualcomm}/phy-qcom-apq8064-sata.c |   0
 drivers/phy/{ => qualcomm}/phy-qcom-ipq806x-sata.c |   0
 drivers/phy/{ => qualcomm}/phy-qcom-ufs-i.h|   0
 drivers/phy/{ => qualcomm}/phy-qcom-ufs-qmp-14nm.c |   0
 drivers/phy/{ => qualcomm}/phy-qcom-ufs-qmp-14nm.h |   0
 drivers/phy/{ => qualcomm}/phy-qcom-ufs-qmp-20nm.c |   0
 drivers/phy/{ => qualcomm}/phy-qcom-ufs-qmp-20nm.h |   0
 drivers/phy/{ => qualcomm}/phy-qcom-ufs.c  |   0
 drivers/phy/{ => qualcomm}/phy-qcom-usb-hs.c   |   2 -
 drivers/phy/{ => qualcomm}/phy-qcom-usb-hsic.c |   2 -
 drivers/phy/renesas/Kconfig|  17 +
 drivers/phy/renesas/Makefile   |   2 +
 drivers/phy/{ => renesas}/phy-rcar-gen2.c  |   0
 drivers/phy/{ => renesas}/phy-rcar-gen3-usb2.c |   0
 drivers/phy/rockchip/Kconfig   |  51 +++
 drivers/phy/rockchip/Makefile  |   6 +
 drivers/phy/{ => rockchip}/phy-rockchip-dp.c   |   0
 drivers/phy/{ => rockchip}/phy-rockchip-emmc.c |   0
 .../phy/{ => rockchip}/phy-rockchip-inno-usb2.c|   0
 drivers/phy/{ => rockchip}/phy-rockchip-pcie.c |   0
 drivers/phy/{ => rockchip}/phy-rockchip-typec.c|   0
 drivers/phy/{ => rockchip}/phy-rockchip-usb.c  |   0
 drivers/phy/samsung/Kconfig|  96 +
 drivers/phy/samsung/Makefile   |  11 +
 drivers/phy/{ => samsung}/phy-exynos-dp-video.c|   0
 drivers/phy/{ => samsung}/phy-exynos-mipi-video.c  |   0
 drivers/phy/{ => samsung}/phy-exynos-pcie.c|   0
 drivers/phy/{ => samsung}/phy-exynos4210-usb2.c|   0
 drivers/phy/{ => samsung}/phy-exynos4x12-usb2.c|   0
 drivers/phy/{ => samsung}/phy-exynos5-usbdrd.c |   0
 drivers/phy/{ => samsung}/phy-exynos5250-sata.c|   0
 drivers/phy/{ => samsung}/phy-exynos5250-usb2.c|   0
 drivers/phy/{ => samsung}/phy-s5pv210-usb2.c   |   0
 drivers/phy/{ => samsung}/phy-samsung-usb2.c   |   0
 drivers/phy/{ => samsung}/phy-samsung-usb2.h   |   0
 drivers/phy/st/Kconfig |  33 ++
 drivers/phy/st/Makefile|   4 +
 drivers/phy/{ => st}/phy-miphy28lp.c   |   0
 drivers/phy/{ => st}/phy-spear1310-miphy

[PATCH v4 3/3] phy: Group vendor specific phy drivers

[Vivek Gautam]

Adding vendor specific directories in phy to group
phy drivers under their respective vendor umbrella.

Also updated the MAINTAINERS file to reflect the correct
directory structure for phy drivers.

Signed-off-by: Vivek Gautam <vivek.gau...@codeaurora.org>
Acked-by: Heiko Stuebner <he...@sntech.de>
Acked-by: Viresh Kumar <viresh.ku...@linaro.org>
Acked-by: Krzysztof Kozlowski <k...@kernel.org>
Acked-by: Yoshihiro Shimoda <yoshihiro.shimoda...@renesas.com>
Reviewed-by: Jaehoon Chung <jh80.ch...@samsung.com>
Cc: Kishon Vijay Abraham I <kis...@ti.com>
Cc: David S. Miller <da...@davemloft.net>
Cc: Geert Uytterhoeven <geert+rene...@glider.be>
Cc: Yoshihiro Shimoda <yoshihiro.shimoda...@renesas.com>
Cc: Guenter Roeck <li...@roeck-us.net>
Cc: Heiko Stuebner <he...@sntech.de>
Cc: Viresh Kumar <viresh.ku...@linaro.org>
Cc: Maxime Ripard <maxime.rip...@free-electrons.com>
Cc: Chen-Yu Tsai <w...@csie.org>
Cc: Sylwester Nawrocki <s.nawro...@samsung.com>
Cc: Krzysztof Kozlowski <k...@kernel.org>
Cc: Jaehoon Chung <jh80.ch...@samsung.com>
Cc: Stephen Boyd <stephen.b...@linaro.org>
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-arm-...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Cc: linux-o...@vger.kernel.org
Cc: linux-renesas-...@vger.kernel.org
Cc: linux-rockc...@lists.infradead.org
Cc: linux-samsung-...@vger.kernel.org
Cc: linux-usb@vger.kernel.org
---

Changes since v3:
 - Added 'Acked-by' and 'Reviewed by' tags received for this patch.
 - No functional change.

Changes since v2:
 - Rebased on linux-phy/next.
 - Took care of drivers added/removed for each vendors since v2.
 - Updated the 'Signed-off-by' tag with my current email id.

Changes from v1:
 - Updated the MAINTAINERS file to reflect the same change
   in directory structure.
 - Removed PHY_PLAT config as pointed out by Kishon.
   So we don't require the second patch in the v1 of this series:
   [PATCH 2/2] arm: mach-spear: Enable PHY_PLAT to meet dependency
 - Renamed sunxi --> allwinner; rcar --> renesas.
 - Fixed error coming with qcom Makefile.

* Build tested multi_v7_defconfig.
* Build tested arm64 defconfig with all the involved configs enabled.

 MAINTAINERS|  18 +-
 drivers/phy/Kconfig| 471 +
 drivers/phy/Makefile   |  67 +--
 drivers/phy/allwinner/Kconfig  |  31 ++
 drivers/phy/allwinner/Makefile |   2 +
 drivers/phy/{ => allwinner}/phy-sun4i-usb.c|   0
 drivers/phy/{ => allwinner}/phy-sun9i-usb.c|   0
 drivers/phy/broadcom/Kconfig   |  64 +++
 drivers/phy/broadcom/Makefile  |   7 +
 drivers/phy/{ => broadcom}/phy-bcm-cygnus-pcie.c   |   0
 drivers/phy/{ => broadcom}/phy-bcm-kona-usb2.c |   0
 drivers/phy/{ => broadcom}/phy-bcm-ns-usb2.c   |   0
 drivers/phy/{ => broadcom}/phy-bcm-ns-usb3.c   |   0
 drivers/phy/{ => broadcom}/phy-bcm-ns2-pcie.c  |   0
 drivers/phy/{ => broadcom}/phy-bcm-nsp-usb3.c  |   0
 drivers/phy/{ => broadcom}/phy-brcm-sata.c |   0
 drivers/phy/hisilicon/Kconfig  |  20 +
 drivers/phy/hisilicon/Makefile |   2 +
 drivers/phy/{ => hisilicon}/phy-hi6220-usb.c   |   0
 drivers/phy/{ => hisilicon}/phy-hix5hd2-sata.c |   0
 drivers/phy/marvell/Kconfig|  50 +++
 drivers/phy/marvell/Makefile   |   6 +
 drivers/phy/{ => marvell}/phy-armada375-usb2.c |   0
 drivers/phy/{ => marvell}/phy-berlin-sata.c|   0
 drivers/phy/{ => marvell}/phy-berlin-usb.c |   0
 drivers/phy/{ => marvell}/phy-mvebu-sata.c |   0
 drivers/phy/{ => marvell}/phy-pxa-28nm-hsic.c  |   0
 drivers/phy/{ => marvell}/phy-pxa-28nm-usb2.c  |   0
 drivers/phy/qualcomm/Kconfig   |  38 ++
 drivers/phy/qualcomm/Makefile  |   7 +
 drivers/phy/{ => qualcomm}/phy-qcom-apq8064-sata.c |   0
 drivers/phy/{ => qualcomm}/phy-qcom-ipq806x-sata.c |   0
 drivers/phy/{ => qualcomm}/phy-qcom-ufs-i.h|   0
 drivers/phy/{ => qualcomm}/phy-qcom-ufs-qmp-14nm.c |   0
 drivers/phy/{ => qualcomm}/phy-qcom-ufs-qmp-14nm.h |   0
 drivers/phy/{ => qualcomm}/phy-qcom-ufs-qmp-20nm.c |   0
 drivers/phy/{ => qualcomm}/phy-qcom-ufs-qmp-20nm.h |   0
 drivers/phy/{ => qualcomm}/phy-qcom-ufs.c  |   0
 drivers/phy/{ => qualcomm}/phy-qcom-usb-hs.c   |   0
 drivers/phy/{ => qualcomm}/phy-qcom-usb-hsic.c |   0
 drivers/phy/renesas/Kconfig|  17 +
 drivers/phy/renesas/Makefile   |   2 +
 drivers/phy/{ => renesas}/phy-rcar-gen2.c  |   0
 drivers/phy/{ => renesas}/phy-rcar-gen3-usb2.c |   0
 drivers/phy/rockchip/Kconfig 

[PATCH v4 2/3] phy: Move ULPI phy header out of drivers to include path

[Vivek Gautam]

Although ULPI phy is currently being used by tusb1210,
there can be other consumers too in future. So move this
to the includes path for phy.

Signed-off-by: Vivek Gautam <vivek.gau...@codeaurora.org>
Cc: Stephen Boyd <stephen.b...@linaro.org>
Cc: Heikki Krogerus <heikki.kroge...@linux.intel.com>
Cc: Kishon Vijay Abraham I <kis...@ti.com>
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-ker...@vger.kernel.org
Cc: linux-o...@vger.kernel.org
Cc: linux-usb@vger.kernel.org
---

Changes since v3:
 - Removed qcom phy changes, since patch - 1/3 addressed that now.

Changes since v2:
 - Updated the location for this header in drivers using it.

 drivers/phy/phy-tusb1210.c| 3 +--
 {drivers => include/linux}/phy/ulpi_phy.h | 0
 2 files changed, 1 insertion(+), 2 deletions(-)
 rename {drivers => include/linux}/phy/ulpi_phy.h (100%)

diff --git a/drivers/phy/phy-tusb1210.c b/drivers/phy/phy-tusb1210.c
index 4f6d5e71507d..bb3fb031c478 100644
--- a/drivers/phy/phy-tusb1210.c
+++ b/drivers/phy/phy-tusb1210.c
@@ -12,8 +12,7 @@
 #include 
 #include 
 #include 
-
-#include "ulpi_phy.h"
+#include 
 
 #define TUSB1210_VENDOR_SPECIFIC2  0x80
 #define TUSB1210_VENDOR_SPECIFIC2_IHSTX_SHIFT  0
diff --git a/drivers/phy/ulpi_phy.h b/include/linux/phy/ulpi_phy.h
similarity index 100%
rename from drivers/phy/ulpi_phy.h
rename to include/linux/phy/ulpi_phy.h
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

--
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

Re: [PATCH] usb: dwc3 dwc3_exynos_probe() change goto labels to meaningful names

[Vivek Gautam]

On Tue, Jan 31, 2017 at 12:55 AM, Shuah Khan  wrote:
> Change goto labels to meaningful names from a series of errNs.
>
> Signed-off-by: Shuah Khan 
> ---
>
> Rebased to usb-next
>
>  drivers/usb/dwc3/dwc3-exynos.c | 22 +++---
>  1 file changed, 11 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/usb/dwc3/dwc3-exynos.c b/drivers/usb/dwc3/dwc3-exynos.c
> index 1515d45..98f74ff 100644
> --- a/drivers/usb/dwc3/dwc3-exynos.c
> +++ b/drivers/usb/dwc3/dwc3-exynos.c
> @@ -147,53 +147,53 @@ static int dwc3_exynos_probe(struct platform_device 
> *pdev)
> exynos->vdd33 = devm_regulator_get(dev, "vdd33");
> if (IS_ERR(exynos->vdd33)) {
> ret = PTR_ERR(exynos->vdd33);
> -   goto err2;
> +   goto vdd33_err;

While you are changing this in probe, care to change in
dwc3_exynos_register_phys() as well ?

[snip]

Regards
Vivek

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
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

Re: [PATCH 2/2] usb; dwc3: of-simple: Add support to get resets for the device

[Vivek Gautam]

Hi,


On 03/15/2017 04:15 PM, Philipp Zabel wrote:

On Wed, 2017-02-22 at 10:54 +0530, Vivek Gautam wrote:

Add support to get a list of resets available for the device.
These resets must be kept de-asserted until the device is
in use.

Cc: Felipe Balbi <ba...@kernel.org>
Signed-off-by: Vivek Gautam <vivek.gau...@codeaurora.org>
---

Based on torvald's master branch.

  drivers/usb/dwc3/dwc3-of-simple.c | 49 +++
  1 file changed, 49 insertions(+)

diff --git a/drivers/usb/dwc3/dwc3-of-simple.c 
b/drivers/usb/dwc3/dwc3-of-simple.c
index fe414e7a9c78..025de7342d28 100644
--- a/drivers/usb/dwc3/dwc3-of-simple.c
+++ b/drivers/usb/dwc3/dwc3-of-simple.c
@@ -29,13 +29,52 @@
  #include 
  #include 
  #include 
+#include 
  
  struct dwc3_of_simple {

struct device   *dev;
struct clk  **clks;
int num_clocks;
+   struct reset_control**resets;
+   int num_resets;
  };
  
+static int dwc3_of_simple_reset_init(struct dwc3_of_simple *simple, int count)

+{
+   struct device   *dev = simple->dev;
+   int i;
+
+   simple->num_resets = count;
+
+   if (!count)
+   return 0;
+
+   simple->resets = devm_kcalloc(dev, simple->num_resets,
+   sizeof(struct reset_control *), GFP_KERNEL);
+   if (!simple->resets)
+   return -ENOMEM;
+
+   for (i = 0; i < simple->num_resets; i++) {
+   struct reset_control *reset;
+   int ret;
+
+   reset = devm_reset_control_get_by_index(dev, i);

Please use devm_reset_control_get_exclusive_by_index instead. See
include/linux/reset.h for details.


Sure, will make use of *exclusive version of the api.




+   if (IS_ERR(reset))
+   return PTR_ERR(reset);
+
+   simple->resets[i] = reset;
+
+   ret = reset_control_deassert(reset);
+   if (ret) {
+   while (--i >= 0)
+   reset_control_assert(reset);
+   return ret;
+   }
+   }
+
+   return 0;
+}

This looks rather generic. Should we have a
reset_control_get/assert/deassert_array functionality at the reset API
level?


Yes, i think we should. Something on the lines of 'regulator_bulk_*' 
interface?





  static int dwc3_of_simple_clk_init(struct dwc3_of_simple *simple, int count)
  {
struct device   *dev = simple->dev;
@@ -100,6 +139,10 @@ static int dwc3_of_simple_probe(struct platform_device 
*pdev)
if (ret)
return ret;
  
+	ret = dwc3_of_simple_reset_init(simple, of_reset_control_get_count(np));

+   if (ret)
+   return ret;
+

Not a blocker, but it seems a bit inconsistent to count the reset
controls via the device node (of_...), but then get them via the device
(devm_reset_control_get_... instead of of_reset_control_get_...).


You are right, it looks inconsistent. I thought of using a resource
managed API. But now i think it doesn't make much sense.


Best Regards
Vivek



regards
Philipp



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

--
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

Re: [PATCH 1/2] reset: Add API to count number of reset available with device

[Vivek Gautam]

Hi Philipp,


On Wed, Mar 15, 2017 at 4:10 PM, Philipp Zabel <p.za...@pengutronix.de> wrote:
> Hi Vivek,
>
> On Fri, 2017-03-10 at 20:10 +0530, Vivek Gautam wrote:
>> Hi Philipp,
>>
>>
>> On Wed, Feb 22, 2017 at 10:54 AM, Vivek Gautam
>> <vivek.gau...@codeaurora.org> wrote:
>> > Count number of reset phandles available with the device node
>> > to know the resets a given device has.
>> >
>> > Cc: Philipp Zabel <p.za...@pengutronix.de>
>> > Signed-off-by: Vivek Gautam <vivek.gau...@codeaurora.org>
>> > ---
>>
>> Any thoughts on this change?
>> A small addition that seems useful.
>
> Sorry I missed this one earlier.
>
>> >
>> > Based on torvald's master branch.
>> >
>> >  include/linux/reset.h | 16 
>> >  1 file changed, 16 insertions(+)
>> >
>> > diff --git a/include/linux/reset.h b/include/linux/reset.h
>> > index 5daff15722d3..88f63a640153 100644
>> > --- a/include/linux/reset.h
>> > +++ b/include/linux/reset.h
>> > @@ -2,6 +2,7 @@
>> >  #define _LINUX_RESET_H_
>> >
>> >  #include 
>> > +#include 
>> >
>> >  struct reset_control;
>> >
>> > @@ -234,6 +235,21 @@ static inline struct reset_control 
>> > *of_reset_control_get_shared_by_index(
>> >  }
>> >
>> >  /**
>> > + * of_reset_control_get_count - Count number of resets available with a 
>> > device
>> > + * @node: device to be reset by the controller
>> > + */
>> > +static inline unsigned int of_reset_control_get_count(struct device_node 
>> > *node)
>> > +{
>> > +   int count;
>> > +
>> > +   count = of_count_phandle_with_args(node, "resets", "#reset-cells");
>> > +   if (count < 0)
>> > +   return 0;
>
> Please don't silently ignore errors. gpiod_count doesn't ignore errors
> either. tegra_powergate_of_resets in drivers/soc/tegra/pmc.c open codes
> this, too. This should be changed so it can be used there, too.

Sure, will change this. I can prepare a patch for tegra/pmc.c as well
using this.

Best regards
Vivek

>
> regards
> Philipp
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
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

Re: [RESEND PATCH v3 2/2] phy: Group vendor specific phy drivers

[Vivek Gautam]

On Wed, Mar 15, 2017 at 1:38 PM, Heiko Stübner <he...@sntech.de> wrote:
> Am Dienstag, 14. März 2017, 11:52:50 CET schrieb Vivek Gautam:
>> Adding vendor specific directories in phy to group
>> phy drivers under their respective vendor umbrella.
>>
>> Also updated the MAINTAINERS file to reflect the correct
>> directory structure for phy drivers.
>>
>> Signed-off-by: Vivek Gautam <vivek.gau...@codeaurora.org>
>> Acked-by: Heiko Stuebner <he...@sntech.de>
>> Acked-by: Viresh Kumar <viresh.ku...@linaro.org>
>> Cc: Kishon Vijay Abraham I <kis...@ti.com>
>> Cc: David S. Miller <da...@davemloft.net>
>> Cc: Geert Uytterhoeven <geert+rene...@glider.be>
>> Cc: Yoshihiro Shimoda <yoshihiro.shimoda...@renesas.com>
>> Cc: Guenter Roeck <li...@roeck-us.net>
>> Cc: Heiko Stuebner <he...@sntech.de>
>> Cc: Viresh Kumar <viresh.ku...@linaro.org>
>> Cc: Maxime Ripard <maxime.rip...@free-electrons.com>
>> Cc: Chen-Yu Tsai <w...@csie.org>
>> Cc: Sylwester Nawrocki <s.nawro...@samsung.com>
>> Cc: Krzysztof Kozlowski <k...@kernel.org>
>> Cc: Jaehoon Chung <jh80.ch...@samsung.com>
>> Cc: linux-arm-ker...@lists.infradead.org
>> Cc: linux-arm-...@vger.kernel.org
>> Cc: linux-ker...@vger.kernel.org
>> Cc: linux-o...@vger.kernel.org
>> Cc: linux-renesas-...@vger.kernel.org
>> Cc: linux-rockc...@lists.infradead.org
>> Cc: linux-samsung-...@vger.kernel.org
>> Cc: linux-usb@vger.kernel.org
>> ---
>>
>> Corrected Krzysztof's email-id. Added linux-arm-msm.
>>
>> Hi Heiko, Viresh,
>> It's been a year since the last version of this patch was posted.
>> Kishon has agreed to pull this change now. I am carrying forward
>> your Acks since there are no functional changes.
>> I have taken care of the drivers that were added/removed since
>> the last version.
>> Please feel free to jump in if you have any concerns.
>
> still looks all good and I gave that a try on 4.11-rc2 yesterday as well.

Thanks Heiko for testing this patch.

Best Regards
Vivek
>
>
> Heiko
> --
> To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
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

Re: [RESEND PATCH v3 2/2] phy: Group vendor specific phy drivers

[Vivek Gautam]

Hi Krzysztof,


On 03/14/2017 12:14 PM, Krzysztof Kozlowski wrote:

On Tue, Mar 14, 2017 at 8:22 AM, Vivek Gautam
<vivek.gau...@codeaurora.org> wrote:

Adding vendor specific directories in phy to group
phy drivers under their respective vendor umbrella.

Also updated the MAINTAINERS file to reflect the correct
directory structure for phy drivers.

Signed-off-by: Vivek Gautam <vivek.gau...@codeaurora.org>
Acked-by: Heiko Stuebner <he...@sntech.de>
Acked-by: Viresh Kumar <viresh.ku...@linaro.org>
Cc: Kishon Vijay Abraham I <kis...@ti.com>
Cc: David S. Miller <da...@davemloft.net>
Cc: Geert Uytterhoeven <geert+rene...@glider.be>
Cc: Yoshihiro Shimoda <yoshihiro.shimoda...@renesas.com>
Cc: Guenter Roeck <li...@roeck-us.net>
Cc: Heiko Stuebner <he...@sntech.de>
Cc: Viresh Kumar <viresh.ku...@linaro.org>
Cc: Maxime Ripard <maxime.rip...@free-electrons.com>
Cc: Chen-Yu Tsai <w...@csie.org>
Cc: Sylwester Nawrocki <s.nawro...@samsung.com>
Cc: Krzysztof Kozlowski <k...@kernel.org>
Cc: Jaehoon Chung <jh80.ch...@samsung.com>
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-arm-...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Cc: linux-o...@vger.kernel.org
Cc: linux-renesas-...@vger.kernel.org
Cc: linux-rockc...@lists.infradead.org
Cc: linux-samsung-...@vger.kernel.org
Cc: linux-usb@vger.kernel.org
---

Corrected Krzysztof's email-id. Added linux-arm-msm.

Hi Heiko, Viresh,
It's been a year since the last version of this patch was posted.
Kishon has agreed to pull this change now. I am carrying forward
your Acks since there are no functional changes.
I have taken care of the drivers that were added/removed since
the last version.
Please feel free to jump in if you have any concerns.

Changes since v2
  - Rebased on linux-phy/next.
  - Took care of drivers added/removed for each vendors since v2.
  - Updated the 'Signed-off-by' tag with my current email id.

Changes from v1:
  - Updated the MAINTAINERS file to reflect the same change
in directory structure.
  - Removed PHY_PLAT config as pointed out by Kishon.
So we don't require the second patch in the v1 of this series:
[PATCH 2/2] arm: mach-spear: Enable PHY_PLAT to meet dependency
  - Renamed sunxi --> allwinner; rcar --> renesas.
  - Fixed error coming with qcom Makefile.

* Build tested multi_v7_defconfig.
* Build tested arm64 defconfig with all the involved configs enabled.

  MAINTAINERS|  18 +-
  drivers/phy/Kconfig| 471 +
  drivers/phy/Makefile   |  67 +--
  drivers/phy/allwinner/Kconfig  |  31 ++
  drivers/phy/allwinner/Makefile |   2 +
  drivers/phy/{ => allwinner}/phy-sun4i-usb.c|   0
  drivers/phy/{ => allwinner}/phy-sun9i-usb.c|   0
  drivers/phy/broadcom/Kconfig   |  64 +++
  drivers/phy/broadcom/Makefile  |   7 +
  drivers/phy/{ => broadcom}/phy-bcm-cygnus-pcie.c   |   0
  drivers/phy/{ => broadcom}/phy-bcm-kona-usb2.c |   0
  drivers/phy/{ => broadcom}/phy-bcm-ns-usb2.c   |   0
  drivers/phy/{ => broadcom}/phy-bcm-ns-usb3.c   |   0
  drivers/phy/{ => broadcom}/phy-bcm-ns2-pcie.c  |   0
  drivers/phy/{ => broadcom}/phy-bcm-nsp-usb3.c  |   0
  drivers/phy/{ => broadcom}/phy-brcm-sata.c |   0
  drivers/phy/hisilicon/Kconfig  |  20 +
  drivers/phy/hisilicon/Makefile |   2 +
  drivers/phy/{ => hisilicon}/phy-hi6220-usb.c   |   0
  drivers/phy/{ => hisilicon}/phy-hix5hd2-sata.c |   0
  drivers/phy/marvell/Kconfig|  50 +++
  drivers/phy/marvell/Makefile   |   6 +
  drivers/phy/{ => marvell}/phy-armada375-usb2.c |   0
  drivers/phy/{ => marvell}/phy-berlin-sata.c|   0
  drivers/phy/{ => marvell}/phy-berlin-usb.c |   0
  drivers/phy/{ => marvell}/phy-mvebu-sata.c |   0
  drivers/phy/{ => marvell}/phy-pxa-28nm-hsic.c  |   0
  drivers/phy/{ => marvell}/phy-pxa-28nm-usb2.c  |   0
  drivers/phy/qualcomm/Kconfig   |  38 ++
  drivers/phy/qualcomm/Makefile  |   7 +
  drivers/phy/{ => qualcomm}/phy-qcom-apq8064-sata.c |   0
  drivers/phy/{ => qualcomm}/phy-qcom-ipq806x-sata.c |   0
  drivers/phy/{ => qualcomm}/phy-qcom-ufs-i.h|   0
  drivers/phy/{ => qualcomm}/phy-qcom-ufs-qmp-14nm.c |   0
  drivers/phy/{ => qualcomm}/phy-qcom-ufs-qmp-14nm.h |   0
  drivers/phy/{ => qualcomm}/phy-qcom-ufs-qmp-20nm.c |   0
  drivers/phy/{ => qualcomm}/phy-qcom-ufs-qmp-20nm.h |   0
  drivers/phy/{ => qualcomm}/phy-qcom-ufs.c  |   0
  drivers/phy/{ => qualcomm}/phy-qcom-usb-hs.c   |   0
  drivers/phy/{ => qualcomm}/phy-qcom-usb-hsic.c |   0
  drivers/p

[RESEND PATCH v3 2/2] phy: Group vendor specific phy drivers

[Vivek Gautam]

Adding vendor specific directories in phy to group
phy drivers under their respective vendor umbrella.

Also updated the MAINTAINERS file to reflect the correct
directory structure for phy drivers.

Signed-off-by: Vivek Gautam <vivek.gau...@codeaurora.org>
Acked-by: Heiko Stuebner <he...@sntech.de>
Acked-by: Viresh Kumar <viresh.ku...@linaro.org>
Cc: Kishon Vijay Abraham I <kis...@ti.com>
Cc: David S. Miller <da...@davemloft.net>
Cc: Geert Uytterhoeven <geert+rene...@glider.be>
Cc: Yoshihiro Shimoda <yoshihiro.shimoda...@renesas.com>
Cc: Guenter Roeck <li...@roeck-us.net>
Cc: Heiko Stuebner <he...@sntech.de>
Cc: Viresh Kumar <viresh.ku...@linaro.org>
Cc: Maxime Ripard <maxime.rip...@free-electrons.com>
Cc: Chen-Yu Tsai <w...@csie.org>
Cc: Sylwester Nawrocki <s.nawro...@samsung.com>
Cc: Krzysztof Kozlowski <k...@kernel.org>
Cc: Jaehoon Chung <jh80.ch...@samsung.com>
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-arm-...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Cc: linux-o...@vger.kernel.org
Cc: linux-renesas-...@vger.kernel.org
Cc: linux-rockc...@lists.infradead.org
Cc: linux-samsung-...@vger.kernel.org
Cc: linux-usb@vger.kernel.org
---

Corrected Krzysztof's email-id. Added linux-arm-msm.

Hi Heiko, Viresh,
It's been a year since the last version of this patch was posted.
Kishon has agreed to pull this change now. I am carrying forward
your Acks since there are no functional changes.
I have taken care of the drivers that were added/removed since
the last version.
Please feel free to jump in if you have any concerns.

Changes since v2
 - Rebased on linux-phy/next.
 - Took care of drivers added/removed for each vendors since v2.
 - Updated the 'Signed-off-by' tag with my current email id.

Changes from v1:
 - Updated the MAINTAINERS file to reflect the same change
   in directory structure.
 - Removed PHY_PLAT config as pointed out by Kishon.
   So we don't require the second patch in the v1 of this series:
   [PATCH 2/2] arm: mach-spear: Enable PHY_PLAT to meet dependency
 - Renamed sunxi --> allwinner; rcar --> renesas.
 - Fixed error coming with qcom Makefile.

* Build tested multi_v7_defconfig.
* Build tested arm64 defconfig with all the involved configs enabled.

 MAINTAINERS|  18 +-
 drivers/phy/Kconfig| 471 +
 drivers/phy/Makefile   |  67 +--
 drivers/phy/allwinner/Kconfig  |  31 ++
 drivers/phy/allwinner/Makefile |   2 +
 drivers/phy/{ => allwinner}/phy-sun4i-usb.c|   0
 drivers/phy/{ => allwinner}/phy-sun9i-usb.c|   0
 drivers/phy/broadcom/Kconfig   |  64 +++
 drivers/phy/broadcom/Makefile  |   7 +
 drivers/phy/{ => broadcom}/phy-bcm-cygnus-pcie.c   |   0
 drivers/phy/{ => broadcom}/phy-bcm-kona-usb2.c |   0
 drivers/phy/{ => broadcom}/phy-bcm-ns-usb2.c   |   0
 drivers/phy/{ => broadcom}/phy-bcm-ns-usb3.c   |   0
 drivers/phy/{ => broadcom}/phy-bcm-ns2-pcie.c  |   0
 drivers/phy/{ => broadcom}/phy-bcm-nsp-usb3.c  |   0
 drivers/phy/{ => broadcom}/phy-brcm-sata.c |   0
 drivers/phy/hisilicon/Kconfig  |  20 +
 drivers/phy/hisilicon/Makefile |   2 +
 drivers/phy/{ => hisilicon}/phy-hi6220-usb.c   |   0
 drivers/phy/{ => hisilicon}/phy-hix5hd2-sata.c |   0
 drivers/phy/marvell/Kconfig|  50 +++
 drivers/phy/marvell/Makefile   |   6 +
 drivers/phy/{ => marvell}/phy-armada375-usb2.c |   0
 drivers/phy/{ => marvell}/phy-berlin-sata.c|   0
 drivers/phy/{ => marvell}/phy-berlin-usb.c |   0
 drivers/phy/{ => marvell}/phy-mvebu-sata.c |   0
 drivers/phy/{ => marvell}/phy-pxa-28nm-hsic.c  |   0
 drivers/phy/{ => marvell}/phy-pxa-28nm-usb2.c  |   0
 drivers/phy/qualcomm/Kconfig   |  38 ++
 drivers/phy/qualcomm/Makefile  |   7 +
 drivers/phy/{ => qualcomm}/phy-qcom-apq8064-sata.c |   0
 drivers/phy/{ => qualcomm}/phy-qcom-ipq806x-sata.c |   0
 drivers/phy/{ => qualcomm}/phy-qcom-ufs-i.h|   0
 drivers/phy/{ => qualcomm}/phy-qcom-ufs-qmp-14nm.c |   0
 drivers/phy/{ => qualcomm}/phy-qcom-ufs-qmp-14nm.h |   0
 drivers/phy/{ => qualcomm}/phy-qcom-ufs-qmp-20nm.c |   0
 drivers/phy/{ => qualcomm}/phy-qcom-ufs-qmp-20nm.h |   0
 drivers/phy/{ => qualcomm}/phy-qcom-ufs.c  |   0
 drivers/phy/{ => qualcomm}/phy-qcom-usb-hs.c   |   0
 drivers/phy/{ => qualcomm}/phy-qcom-usb-hsic.c |   0
 drivers/phy/renesas/Kconfig|  17 +
 drivers/phy/renesas/Makefile   |   2 +
 drivers/phy/{ => renesas}/phy-rcar-gen2.c  |   0
 drivers/phy/{ => renesas}/phy-rcar-gen3-u

[PATCH v3 2/2] phy: Group vendor specific phy drivers

[Vivek Gautam]

Adding vendor specific directories in phy to group
phy drivers under their respective vendor umbrella.

Also updated the MAINTAINERS file to reflect the correct
directory structure for phy drivers.

Signed-off-by: Vivek Gautam <vivek.gau...@codeaurora.org>
Acked-by: Heiko Stuebner <he...@sntech.de>
Acked-by: Viresh Kumar <viresh.ku...@linaro.org>
Cc: Kishon Vijay Abraham I <kis...@ti.com>
Cc: David S. Miller <da...@davemloft.net>
Cc: Geert Uytterhoeven <geert+rene...@glider.be>
Cc: Yoshihiro Shimoda <yoshihiro.shimoda...@renesas.com>
Cc: Guenter Roeck <li...@roeck-us.net>
Cc: Heiko Stuebner <he...@sntech.de>
Cc: Viresh Kumar <viresh.ku...@linaro.org>
Cc: Maxime Ripard <maxime.rip...@free-electrons.com>
Cc: Chen-Yu Tsai <w...@csie.org>
Cc: Sylwester Nawrocki <s.nawro...@samsung.com>
Cc: Krzysztof Kozlowski <k.kozlow...@samsung.com>
Cc: Jaehoon Chung <jh80.ch...@samsung.com>
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-ker...@vger.kernel.org
Cc: linux-o...@vger.kernel.org
Cc: linux-samsung-...@vger.kernel.org
Cc: linux-renesas-...@vger.kernel.org
Cc: linux-rockc...@lists.infradead.org
Cc: linux-usb@vger.kernel.org
---

Hi Heiko, Viresh,
It's been a year since the last version of this patch was posted.
Kishon has agreed to pull this change now. I am carrying forward
your Acks since there are no functional changes.
I have taken care of the drivers that were added/removed since
the last version.
Please feel free to jump in if you have any concerns.

Changes since v2
 - Rebased on linux-phy/next.
 - Took care of drivers added/removed for each vendors since v2.
 - Updated the 'Signed-off-by' tag with my current email id.

Changes from v1:
 - Updated the MAINTAINERS file to reflect the same change
   in directory structure.
 - Removed PHY_PLAT config as pointed out by Kishon.
   So we don't require the second patch in the v1 of this series:
   [PATCH 2/2] arm: mach-spear: Enable PHY_PLAT to meet dependency
 - Renamed sunxi --> allwinner; rcar --> renesas.
 - Fixed error coming with qcom Makefile.

* Build tested multi_v7_defconfig.
* Build tested arm64 defconfig with all the involved configs enabled.

 MAINTAINERS|  18 +-
 drivers/phy/Kconfig| 471 +
 drivers/phy/Makefile   |  67 +--
 drivers/phy/allwinner/Kconfig  |  31 ++
 drivers/phy/allwinner/Makefile |   2 +
 drivers/phy/{ => allwinner}/phy-sun4i-usb.c|   0
 drivers/phy/{ => allwinner}/phy-sun9i-usb.c|   0
 drivers/phy/broadcom/Kconfig   |  64 +++
 drivers/phy/broadcom/Makefile  |   7 +
 drivers/phy/{ => broadcom}/phy-bcm-cygnus-pcie.c   |   0
 drivers/phy/{ => broadcom}/phy-bcm-kona-usb2.c |   0
 drivers/phy/{ => broadcom}/phy-bcm-ns-usb2.c   |   0
 drivers/phy/{ => broadcom}/phy-bcm-ns-usb3.c   |   0
 drivers/phy/{ => broadcom}/phy-bcm-ns2-pcie.c  |   0
 drivers/phy/{ => broadcom}/phy-bcm-nsp-usb3.c  |   0
 drivers/phy/{ => broadcom}/phy-brcm-sata.c |   0
 drivers/phy/hisilicon/Kconfig  |  20 +
 drivers/phy/hisilicon/Makefile |   2 +
 drivers/phy/{ => hisilicon}/phy-hi6220-usb.c   |   0
 drivers/phy/{ => hisilicon}/phy-hix5hd2-sata.c |   0
 drivers/phy/marvell/Kconfig|  50 +++
 drivers/phy/marvell/Makefile   |   6 +
 drivers/phy/{ => marvell}/phy-armada375-usb2.c |   0
 drivers/phy/{ => marvell}/phy-berlin-sata.c|   0
 drivers/phy/{ => marvell}/phy-berlin-usb.c |   0
 drivers/phy/{ => marvell}/phy-mvebu-sata.c |   0
 drivers/phy/{ => marvell}/phy-pxa-28nm-hsic.c  |   0
 drivers/phy/{ => marvell}/phy-pxa-28nm-usb2.c  |   0
 drivers/phy/qualcomm/Kconfig   |  38 ++
 drivers/phy/qualcomm/Makefile  |   7 +
 drivers/phy/{ => qualcomm}/phy-qcom-apq8064-sata.c |   0
 drivers/phy/{ => qualcomm}/phy-qcom-ipq806x-sata.c |   0
 drivers/phy/{ => qualcomm}/phy-qcom-ufs-i.h|   0
 drivers/phy/{ => qualcomm}/phy-qcom-ufs-qmp-14nm.c |   0
 drivers/phy/{ => qualcomm}/phy-qcom-ufs-qmp-14nm.h |   0
 drivers/phy/{ => qualcomm}/phy-qcom-ufs-qmp-20nm.c |   0
 drivers/phy/{ => qualcomm}/phy-qcom-ufs-qmp-20nm.h |   0
 drivers/phy/{ => qualcomm}/phy-qcom-ufs.c  |   0
 drivers/phy/{ => qualcomm}/phy-qcom-usb-hs.c   |   0
 drivers/phy/{ => qualcomm}/phy-qcom-usb-hsic.c |   0
 drivers/phy/renesas/Kconfig|  17 +
 drivers/phy/renesas/Makefile   |   2 +
 drivers/phy/{ => renesas}/phy-rcar-gen2.c  |   0
 drivers/phy/{ => renesas}/phy-rcar-gen3-usb2.c |   0
 drivers/phy/rockchip/Kconfig   |  51 +++
 

Re: [PATCH 1/2] reset: Add API to count number of reset available with device

[Vivek Gautam]

Hi Philipp,


On Wed, Feb 22, 2017 at 10:54 AM, Vivek Gautam
<vivek.gau...@codeaurora.org> wrote:
> Count number of reset phandles available with the device node
> to know the resets a given device has.
>
> Cc: Philipp Zabel <p.za...@pengutronix.de>
> Signed-off-by: Vivek Gautam <vivek.gau...@codeaurora.org>
> ---

Any thoughts on this change?
A small addition that seems useful.

>
> Based on torvald's master branch.
>
>  include/linux/reset.h | 16 
>  1 file changed, 16 insertions(+)
>
> diff --git a/include/linux/reset.h b/include/linux/reset.h
> index 5daff15722d3..88f63a640153 100644
> --- a/include/linux/reset.h
> +++ b/include/linux/reset.h
> @@ -2,6 +2,7 @@
>  #define _LINUX_RESET_H_
>
>  #include 
> +#include 
>
>  struct reset_control;
>
> @@ -234,6 +235,21 @@ static inline struct reset_control 
> *of_reset_control_get_shared_by_index(
>  }
>
>  /**
> + * of_reset_control_get_count - Count number of resets available with a 
> device
> + * @node: device to be reset by the controller
> + */
> +static inline unsigned int of_reset_control_get_count(struct device_node 
> *node)
> +{
> +   int count;
> +
> +   count = of_count_phandle_with_args(node, "resets", "#reset-cells");
> +   if (count < 0)
> +   return 0;
> +
> +   return count;
> +}
> +
> +/**
>   * devm_reset_control_get_exclusive - resource managed
>   *reset_control_get_exclusive()
>   * @dev: device to be reset by the controller
> --
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


Regards
Vivek
-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
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

Re: [PATCH 2/2] usb; dwc3: of-simple: Add support to get resets for the device

[Vivek Gautam]

On Fri, Mar 10, 2017 at 4:54 PM, Felipe Balbi <ba...@kernel.org> wrote:
> Vivek Gautam <vivek.gau...@codeaurora.org> writes:
>
>> Add support to get a list of resets available for the device.
>> These resets must be kept de-asserted until the device is
>> in use.
>>
>> Cc: Felipe Balbi <ba...@kernel.org>
>> Signed-off-by: Vivek Gautam <vivek.gau...@codeaurora.org>
>
> how do you plan on merging this since it depends on previous patch?

Will ask Phillip if he is fine with the previous patch. He can then consider
giving an ack so that both patches can be pulled in together.

Will it be okay to do that ?

Regards
Vivek

>
> --
> balbi



-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
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

Re: [PATCH v2 4/4] usb: dwc3: Workaround for super-speed host on dra7 in dual-role mode

[Vivek Gautam]

On Sat, Feb 25, 2017 at 9:20 AM, Chanwoo Choi <cwcho...@gmail.com> wrote:
> 2017-02-25 12:46 GMT+09:00 Chanwoo Choi <cwcho...@gmail.com>:
>> Hi,
>>
>> 2017-02-24 21:02 GMT+09:00 Roger Quadros <rog...@ti.com>:
>>> +Chanwoo
>>>
>>> Hi Vivek,
>>>
>>> On 23/02/17 10:34, Vivek Gautam wrote:
>>>>
>>>>
>>>> On 02/16/2017 06:36 PM, Roger Quadros wrote:
>>>>> dra7 OTG core limits the host controller to USB2.0 (high-speed) mode
>>>>> when we're operating in dual-role.
>>>>>
>>>>> We work around that by bypassing the OTG core and reading the
>>>>> extcon framework directly for ID/VBUS events.
>>>>>
>>>>> Signed-off-by: Roger Quadros <rog...@ti.com>
>>>>> ---
>>>>>   Documentation/devicetree/bindings/usb/dwc3.txt |   2 +
>>>>>   drivers/usb/dwc3/core.c| 169 
>>>>> -
>>>>>   drivers/usb/dwc3/core.h|   5 +
>>>>>   3 files changed, 170 insertions(+), 6 deletions(-)
>>>>>
>>>>> diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt 
>>>>> b/Documentation/devicetree/bindings/usb/dwc3.txt
>>>>> index e3e6983..9955c0d 100644
>>>>> --- a/Documentation/devicetree/bindings/usb/dwc3.txt
>>>>> +++ b/Documentation/devicetree/bindings/usb/dwc3.txt
>>>>> @@ -53,6 +53,8 @@ Optional properties:
>>>>>- snps,quirk-frame-length-adjustment: Value for GFLADJ_30MHZ field of 
>>>>> GFLADJ
>>>>>   register for post-silicon frame length adjustment when the
>>>>>   fladj_30mhz_sdbnd signal is invalid or incorrect.
>>>>> + - extcon: phandle to the USB connector extcon device. If present, extcon
>>>>> +device will be used to get USB cable events instead of OTG 
>>>>> controller.
>>>>>  -  tx-fifo-resize: determines if the FIFO *has* to be 
>>>>> reallocated.
>>>>>   diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
>>>>> index 619fa7c..b02d911 100644
>>>>> --- a/drivers/usb/dwc3/core.c
>>>>> +++ b/drivers/usb/dwc3/core.c
>>>>
>>>> [snip]
>>>>
>>>>> @@ -1587,6 +1727,14 @@ static int dwc3_probe(struct platform_device *pdev)
>>>>> dwc3_get_properties(dwc);
>>>>>   +if (dev->of_node) {
>>>>> +if (of_property_read_bool(dev->of_node, "extcon"))
>>>>> +dwc->edev = extcon_get_edev_by_phandle(dev, 0);
>>>>
>>>> Don't we want separate edev's for vbus and id ?
>>>> One can have separate pins connected to them and in that case
>>>> we can't get the events out of one pin only.
>>>
>>> Is such kind of hardware really there? Ideally one extcon device
>>> represents one connector. So VBUS and ID events of a single USB
>>> port should come on one extcon device.
>>> If it doesn't then you need to fix your platforms extcon driver
>>> so that it does.

Right, i see it now. One edev for one connector.

>>> Chanwoo can correct me if I'm wrong on this understanding.
>>>
>>> Currently, if VBUS and ID come on GPIOs the extcon-usb-gpio driver
>>> takes care of both.
>>
>> Basically, one extcon device driver can support the multiple
>> external connectors if the detection h/w or port is same.
>>
>> One extcon device with extcon-usb-gpio.c can support the detection
>> of both ID and VBUS.
>>
>> But, if there is any issue of h/w schematic, we need to consider
>> how to use the extcon device.
>
> Additionally, the extcon-usb-gpio.c use the two gpio pins
> to detect both ID and VBUS pins. We can check it on documentation[1]
> of extcon-usb-gpio driver.
>
> [1] 
> https://git.kernel.org/cgit/linux/kernel/git/chanwoo/extcon.git/tree/Documentation/devicetree/bindings/extcon/extcon-usb-gpio.txt

Thanks Chanwoo, i understand it now. The extcon-usb-gpio supports
both vbus and id gpio, and updates the state of the edev likewise.

>
> --
> Best Regards,
> Chanwoo Choi
> Samsung Electronics
> --
> 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


regards
Vivek
-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
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

Re: [PATCH v2 4/4] usb: dwc3: Workaround for super-speed host on dra7 in dual-role mode

[Vivek Gautam]

On 02/24/2017 06:27 AM, Peter Chen wrote:

On Thu, Feb 23, 2017 at 02:04:50PM +0530, Vivek Gautam wrote:


On 02/16/2017 06:36 PM, Roger Quadros wrote:

dra7 OTG core limits the host controller to USB2.0 (high-speed) mode
when we're operating in dual-role.

We work around that by bypassing the OTG core and reading the
extcon framework directly for ID/VBUS events.

Signed-off-by: Roger Quadros <rog...@ti.com>
---
  Documentation/devicetree/bindings/usb/dwc3.txt |   2 +
  drivers/usb/dwc3/core.c| 169 -
  drivers/usb/dwc3/core.h|   5 +
  3 files changed, 170 insertions(+), 6 deletions(-)

diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt 
b/Documentation/devicetree/bindings/usb/dwc3.txt
index e3e6983..9955c0d 100644
--- a/Documentation/devicetree/bindings/usb/dwc3.txt
+++ b/Documentation/devicetree/bindings/usb/dwc3.txt
@@ -53,6 +53,8 @@ Optional properties:
   - snps,quirk-frame-length-adjustment: Value for GFLADJ_30MHZ field of GFLADJ
register for post-silicon frame length adjustment when the
fladj_30mhz_sdbnd signal is invalid or incorrect.
+ - extcon: phandle to the USB connector extcon device. If present, extcon
+   device will be used to get USB cable events instead of OTG controller.
   -  tx-fifo-resize: determines if the FIFO *has* to be 
reallocated.
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 619fa7c..b02d911 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c

[snip]


@@ -1587,6 +1727,14 @@ static int dwc3_probe(struct platform_device *pdev)
dwc3_get_properties(dwc);
+   if (dev->of_node) {
+   if (of_property_read_bool(dev->of_node, "extcon"))
+   dwc->edev = extcon_get_edev_by_phandle(dev, 0);

Don't we want separate edev's for vbus and id ?
One can have separate pins connected to them and in that case
we can't get the events out of one pin only.


Current extcon-usb-gpio driver supports id and vbus at the same time,
that means there are two optional gpios under one extcon node.



Right, and we would want to leverage that by providing couple
of phandles for vbus and id, and requesting the two in driver.


Regards
Vivek

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

--
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

Re: [PATCH v2 4/4] usb: dwc3: Workaround for super-speed host on dra7 in dual-role mode

[Vivek Gautam]

On 02/16/2017 06:36 PM, Roger Quadros wrote:

dra7 OTG core limits the host controller to USB2.0 (high-speed) mode
when we're operating in dual-role.

We work around that by bypassing the OTG core and reading the
extcon framework directly for ID/VBUS events.

Signed-off-by: Roger Quadros 
---
  Documentation/devicetree/bindings/usb/dwc3.txt |   2 +
  drivers/usb/dwc3/core.c| 169 -
  drivers/usb/dwc3/core.h|   5 +
  3 files changed, 170 insertions(+), 6 deletions(-)

diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt 
b/Documentation/devicetree/bindings/usb/dwc3.txt
index e3e6983..9955c0d 100644
--- a/Documentation/devicetree/bindings/usb/dwc3.txt
+++ b/Documentation/devicetree/bindings/usb/dwc3.txt
@@ -53,6 +53,8 @@ Optional properties:
   - snps,quirk-frame-length-adjustment: Value for GFLADJ_30MHZ field of GFLADJ
register for post-silicon frame length adjustment when the
fladj_30mhz_sdbnd signal is invalid or incorrect.
+ - extcon: phandle to the USB connector extcon device. If present, extcon
+   device will be used to get USB cable events instead of OTG controller.
  
   -  tx-fifo-resize: determines if the FIFO *has* to be reallocated.
  
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c

index 619fa7c..b02d911 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c


[snip]


@@ -1587,6 +1727,14 @@ static int dwc3_probe(struct platform_device *pdev)
  
  	dwc3_get_properties(dwc);
  
+	if (dev->of_node) {

+   if (of_property_read_bool(dev->of_node, "extcon"))
+   dwc->edev = extcon_get_edev_by_phandle(dev, 0);


Don't we want separate edev's for vbus and id ?
One can have separate pins connected to them and in that case
we can't get the events out of one pin only.


+
+   if (IS_ERR(dwc->edev))
+   return PTR_ERR(dwc->edev);


 Took me a while to get to this. :)

if (IS_ERR(dwc->edev)) {
   ret = PTR_ERR(dwc->edev);
   goto err0;
}

We want to reset the res->start back to its original offset.

Testing this series currently. Will get back with my results.


Regards
Vivek

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

--
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

[PATCH 1/2] reset: Add API to count number of reset available with device

[Vivek Gautam]

Count number of reset phandles available with the device node
to know the resets a given device has.

Cc: Philipp Zabel <p.za...@pengutronix.de>
Signed-off-by: Vivek Gautam <vivek.gau...@codeaurora.org>
---

Based on torvald's master branch.

 include/linux/reset.h | 16 
 1 file changed, 16 insertions(+)

diff --git a/include/linux/reset.h b/include/linux/reset.h
index 5daff15722d3..88f63a640153 100644
--- a/include/linux/reset.h
+++ b/include/linux/reset.h
@@ -2,6 +2,7 @@
 #define _LINUX_RESET_H_
 
 #include 
+#include 
 
 struct reset_control;
 
@@ -234,6 +235,21 @@ static inline struct reset_control 
*of_reset_control_get_shared_by_index(
 }
 
 /**
+ * of_reset_control_get_count - Count number of resets available with a device
+ * @node: device to be reset by the controller
+ */
+static inline unsigned int of_reset_control_get_count(struct device_node *node)
+{
+   int count;
+
+   count = of_count_phandle_with_args(node, "resets", "#reset-cells");
+   if (count < 0)
+   return 0;
+
+   return count;
+}
+
+/**
  * devm_reset_control_get_exclusive - resource managed
  *reset_control_get_exclusive()
  * @dev: device to be reset by the controller
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

--
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

[PATCH 2/2] usb; dwc3: of-simple: Add support to get resets for the device

[Vivek Gautam]

Add support to get a list of resets available for the device.
These resets must be kept de-asserted until the device is
in use.

Cc: Felipe Balbi <ba...@kernel.org>
Signed-off-by: Vivek Gautam <vivek.gau...@codeaurora.org>
---

Based on torvald's master branch.

 drivers/usb/dwc3/dwc3-of-simple.c | 49 +++
 1 file changed, 49 insertions(+)

diff --git a/drivers/usb/dwc3/dwc3-of-simple.c 
b/drivers/usb/dwc3/dwc3-of-simple.c
index fe414e7a9c78..025de7342d28 100644
--- a/drivers/usb/dwc3/dwc3-of-simple.c
+++ b/drivers/usb/dwc3/dwc3-of-simple.c
@@ -29,13 +29,52 @@
 #include 
 #include 
 #include 
+#include 
 
 struct dwc3_of_simple {
struct device   *dev;
struct clk  **clks;
int num_clocks;
+   struct reset_control**resets;
+   int num_resets;
 };
 
+static int dwc3_of_simple_reset_init(struct dwc3_of_simple *simple, int count)
+{
+   struct device   *dev = simple->dev;
+   int i;
+
+   simple->num_resets = count;
+
+   if (!count)
+   return 0;
+
+   simple->resets = devm_kcalloc(dev, simple->num_resets,
+   sizeof(struct reset_control *), GFP_KERNEL);
+   if (!simple->resets)
+   return -ENOMEM;
+
+   for (i = 0; i < simple->num_resets; i++) {
+   struct reset_control *reset;
+   int ret;
+
+   reset = devm_reset_control_get_by_index(dev, i);
+   if (IS_ERR(reset))
+   return PTR_ERR(reset);
+
+   simple->resets[i] = reset;
+
+   ret = reset_control_deassert(reset);
+   if (ret) {
+   while (--i >= 0)
+   reset_control_assert(reset);
+   return ret;
+   }
+   }
+
+   return 0;
+}
+
 static int dwc3_of_simple_clk_init(struct dwc3_of_simple *simple, int count)
 {
struct device   *dev = simple->dev;
@@ -100,6 +139,10 @@ static int dwc3_of_simple_probe(struct platform_device 
*pdev)
if (ret)
return ret;
 
+   ret = dwc3_of_simple_reset_init(simple, of_reset_control_get_count(np));
+   if (ret)
+   return ret;
+
ret = of_platform_populate(np, NULL, NULL, dev);
if (ret) {
for (i = 0; i < simple->num_clocks; i++) {
@@ -107,6 +150,9 @@ static int dwc3_of_simple_probe(struct platform_device 
*pdev)
clk_put(simple->clks[i]);
}
 
+   for (i = 0; i < simple->num_resets; i++)
+   reset_control_assert(simple->resets[i]);
+
return ret;
}
 
@@ -128,6 +174,9 @@ static int dwc3_of_simple_remove(struct platform_device 
*pdev)
clk_put(simple->clks[i]);
}
 
+   for (i = 0; i < simple->num_resets; i++)
+   reset_control_assert(simple->resets[i]);
+
of_platform_depopulate(dev);
 
pm_runtime_put_sync(dev);
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

--
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

Re: [PATCH v13 06/12] usb: xhci: use bus->sysdev for DMA configuration

[Vivek Gautam]

On 02/11/2017 06:57 AM, Peter Chen wrote:

From: Arnd Bergmann <a...@arndb.de>

For xhci-hcd platform device, all the DMA parameters are not
configured properly, notably dma ops for dwc3 devices. So, set
the dma for xhci from sysdev. sysdev is pointing to device that
is known to the system firmware or hardware.

Cc: Baolin Wang <baolin.w...@linaro.org>
Cc: Vivek Gautam <vivek.gau...@codeaurora.org>
Cc: Alexander Sverdlin <alexander.sverd...@nokia.com>
Cc: Mathias Nyman <mathias.ny...@linux.intel.com>

Signed-off-by: Arnd Bergmann <a...@arndb.de>
Signed-off-by: Sriram Dash <sriram.d...@nxp.com>
---
Hi, Baolin, Vivek and Alexander,
I removed your tested-by tag due to add one change that adding sysdev
for shared hcd too, if your test shows this change works for you or
has no effect for you, please consider adding tested-by tag again,
thanks.


Works well with 4.10-rc8 branch merged with usb-next and the
set of phy patches for msm8996 and corresponding dt patches.

Tested-by: Vivek Gautam <vivek.gau...@codeaurora.org>

Thanks
Vivek


  drivers/usb/host/xhci-mem.c  | 12 ++--
  drivers/usb/host/xhci-plat.c | 35 +++
  drivers/usb/host/xhci.c  | 15 +++
  3 files changed, 44 insertions(+), 18 deletions(-)

diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c
index ba1853f4..032a702 100644
--- a/drivers/usb/host/xhci-mem.c
+++ b/drivers/usb/host/xhci-mem.c
@@ -586,7 +586,7 @@ static void xhci_free_stream_ctx(struct xhci_hcd *xhci,
unsigned int num_stream_ctxs,
struct xhci_stream_ctx *stream_ctx, dma_addr_t dma)
  {
-   struct device *dev = xhci_to_hcd(xhci)->self.controller;
+   struct device *dev = xhci_to_hcd(xhci)->self.sysdev;
size_t size = sizeof(struct xhci_stream_ctx) * num_stream_ctxs;
  
  	if (size > MEDIUM_STREAM_ARRAY_SIZE)

@@ -614,7 +614,7 @@ static struct xhci_stream_ctx *xhci_alloc_stream_ctx(struct 
xhci_hcd *xhci,
unsigned int num_stream_ctxs, dma_addr_t *dma,
gfp_t mem_flags)
  {
-   struct device *dev = xhci_to_hcd(xhci)->self.controller;
+   struct device *dev = xhci_to_hcd(xhci)->self.sysdev;
size_t size = sizeof(struct xhci_stream_ctx) * num_stream_ctxs;
  
  	if (size > MEDIUM_STREAM_ARRAY_SIZE)

@@ -1686,7 +1686,7 @@ void xhci_slot_copy(struct xhci_hcd *xhci,
  static int scratchpad_alloc(struct xhci_hcd *xhci, gfp_t flags)
  {
int i;
-   struct device *dev = xhci_to_hcd(xhci)->self.controller;
+   struct device *dev = xhci_to_hcd(xhci)->self.sysdev;
int num_sp = HCS_MAX_SCRATCHPAD(xhci->hcs_params2);
  
  	xhci_dbg_trace(xhci, trace_xhci_dbg_init,

@@ -1758,7 +1758,7 @@ static void scratchpad_free(struct xhci_hcd *xhci)
  {
int num_sp;
int i;
-   struct device *dev = xhci_to_hcd(xhci)->self.controller;
+   struct device *dev = xhci_to_hcd(xhci)->self.sysdev;
  
  	if (!xhci->scratchpad)

return;
@@ -1831,7 +1831,7 @@ void xhci_free_command(struct xhci_hcd *xhci,
  
  void xhci_mem_cleanup(struct xhci_hcd *xhci)

  {
-   struct device   *dev = xhci_to_hcd(xhci)->self.controller;
+   struct device   *dev = xhci_to_hcd(xhci)->self.sysdev;
int size;
int i, j, num_ports;
  
@@ -2373,7 +2373,7 @@ static int xhci_setup_port_arrays(struct xhci_hcd *xhci, gfp_t flags)

  int xhci_mem_init(struct xhci_hcd *xhci, gfp_t flags)
  {
dma_addr_t  dma;
-   struct device   *dev = xhci_to_hcd(xhci)->self.controller;
+   struct device   *dev = xhci_to_hcd(xhci)->self.sysdev;
unsigned intval, val2;
u64 val_64;
struct xhci_segment *seg;
diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index 6d33b42..4ecb3fd 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -14,6 +14,7 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  #include 
  #include 
@@ -148,6 +149,7 @@ static int xhci_plat_probe(struct platform_device *pdev)
  {
const struct of_device_id *match;
const struct hc_driver  *driver;
+   struct device   *sysdev;
struct xhci_hcd *xhci;
struct resource *res;
struct usb_hcd  *hcd;
@@ -164,22 +166,39 @@ static int xhci_plat_probe(struct platform_device *pdev)
if (irq < 0)
return -ENODEV;
  
+	/*

+* sysdev must point to a device that is known to the system firmware
+* or PCI hardware. We handle these three cases here:
+* 1. xhci_plat comes from firmware
+* 2. xhci_plat is child of a device from firmware (dwc3-plat)
+* 3. xhci_plat is grandchild of a pci device (dwc3-pci)
+*/
+   sysdev = >dev;
+   if (sysdev->parent && !sysdev->of_node && sysdev->

Re: [PATCH v12 6/9] usb: xhci: use bus->sysdev for DMA configuration

[Vivek Gautam]

On Thu, Feb 9, 2017 at 5:24 PM, Roger Quadros <rog...@ti.com> wrote:
>
>
> On 09/02/17 13:53, Roger Quadros wrote:
>>
>>
>> On 08/02/17 22:43, Jack Pham wrote:
>>> Hi Peter, Sriram, Arnd,
>>>
>>> On Mon, Feb 06, 2017 at 05:13:38PM +0800, Peter Chen wrote:
>>>> From: Arnd Bergmann <a...@arndb.de>
>>>>
>>>> For xhci-hcd platform device, all the DMA parameters are not
>>>> configured properly, notably dma ops for dwc3 devices. So, set
>>>> the dma for xhci from sysdev. sysdev is pointing to device that
>>>> is known to the system firmware or hardware.
>>>>
>>>> Signed-off-by: Arnd Bergmann <a...@arndb.de>
>>>> Signed-off-by: Sriram Dash <sriram.d...@nxp.com>
>>>> Tested-by: Baolin Wang <baolin.w...@linaro.org>
>>>> Tested-by: Vivek Gautam <vivek.gau...@codeaurora.org>
>>>> Tested-by: Alexander Sverdlin <alexander.sverd...@nokia.com>
>>>> Signed-off-by: Mathias Nyman <mathias.ny...@linux.intel.com>
>>>> ---
>>>> diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
>>>> index 6d33b42..7a9c860 100644
>>>> --- a/drivers/usb/host/xhci-plat.c
>>>> +++ b/drivers/usb/host/xhci-plat.c
>>>
>>>> -   hcd = usb_create_hcd(driver, >dev, dev_name(>dev));
>>>> +   hcd = __usb_create_hcd(driver, sysdev, >dev,
>>>> +  dev_name(>dev), NULL);
>>>
>>> As mentioned already in [1], usb_create_shared_hcd() is called to create
>>> the second bus, however it also needs to be converted.
>>>
>>> Not exactly as Roger's suggestion but this worked for me:
>>>
>>> -   xhci->shared_hcd = usb_create_shared_hcd(driver, >dev,
>>> +   xhci->shared_hcd = __usb_create_hcd(driver, sysdev, >dev,
>>> dev_name(>dev), hcd);
>>
>> But we're creating a shared_hcd and there is an API for that so why not use 
>> it
>> instead of calling __usb_create_hcd()?
>>
>
> Just realized after I pressed send that there is no sysdev parameter
> for create_shared_hcd().

That's right. The create_shared_hcd() makes use of only pdev->dev,
and we need to configure dma for shared_hcd as well though sysdev.

Sorry my mail client didn't show this mail in time. Please ignore my
earlier comment.

>
>>> if (!xhci->shared_hcd) {
>>> ret = -ENOMEM;
>>>
>>> Without this, SuperSpeed devices fail to enumerate:
>>>
>>>  usb 2-1: new SuperSpeed USB device number 2 using xhci-hcd
>>>  usb 2-1: device descriptor read/8, error -11
>>>  usb 2-1: new SuperSpeed USB device number 2 using xhci-hcd
>>>  usb 2-1: device descriptor read/8, error -11
>>>  usb 2-1: new SuperSpeed USB device number 3 using xhci-hcd
>>>  usb 2-1: device descriptor read/8, error -11
>>>  usb 2-1: new SuperSpeed USB device number 3 using xhci-hcd
>>>  usb 2-1: device descriptor read/8, error -11
>>>  
>>>
>>> Thanks,
>>> Jack
>>>
>>> [1] https://lkml.org/lkml/2016/12/9/240
>>>
>>
>
> --
> cheers,
> -roger
> --
> 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



-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
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

Re: [PATCH v12 6/9] usb: xhci: use bus->sysdev for DMA configuration

[Vivek Gautam]

On Thu, Feb 9, 2017 at 5:23 PM, Roger Quadros <rog...@ti.com> wrote:
>
>
> On 08/02/17 22:43, Jack Pham wrote:
>> Hi Peter, Sriram, Arnd,
>>
>> On Mon, Feb 06, 2017 at 05:13:38PM +0800, Peter Chen wrote:
>>> From: Arnd Bergmann <a...@arndb.de>
>>>
>>> For xhci-hcd platform device, all the DMA parameters are not
>>> configured properly, notably dma ops for dwc3 devices. So, set
>>> the dma for xhci from sysdev. sysdev is pointing to device that
>>> is known to the system firmware or hardware.
>>>
>>> Signed-off-by: Arnd Bergmann <a...@arndb.de>
>>> Signed-off-by: Sriram Dash <sriram.d...@nxp.com>
>>> Tested-by: Baolin Wang <baolin.w...@linaro.org>
>>> Tested-by: Vivek Gautam <vivek.gau...@codeaurora.org>
>>> Tested-by: Alexander Sverdlin <alexander.sverd...@nokia.com>
>>> Signed-off-by: Mathias Nyman <mathias.ny...@linux.intel.com>
>>> ---
>>> diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
>>> index 6d33b42..7a9c860 100644
>>> --- a/drivers/usb/host/xhci-plat.c
>>> +++ b/drivers/usb/host/xhci-plat.c
>>
>>> -hcd = usb_create_hcd(driver, >dev, dev_name(>dev));
>>> +hcd = __usb_create_hcd(driver, sysdev, >dev,
>>> +   dev_name(>dev), NULL);
>>
>> As mentioned already in [1], usb_create_shared_hcd() is called to create
>> the second bus, however it also needs to be converted.
>>
>> Not exactly as Roger's suggestion but this worked for me:
>>
>> -   xhci->shared_hcd = usb_create_shared_hcd(driver, >dev,
>> +   xhci->shared_hcd = __usb_create_hcd(driver, sysdev, >dev,
>> dev_name(>dev), hcd);
>
> But we're creating a shared_hcd and there is an API for that so why not use it
> instead of calling __usb_create_hcd()?

Do we not want to pass on the DMA configuration from sysdev to
shared_hcd as well?

>
>> if (!xhci->shared_hcd) {
>> ret = -ENOMEM;
>>
>> Without this, SuperSpeed devices fail to enumerate:
>>
>>  usb 2-1: new SuperSpeed USB device number 2 using xhci-hcd
>>  usb 2-1: device descriptor read/8, error -11
>>  usb 2-1: new SuperSpeed USB device number 2 using xhci-hcd
>>  usb 2-1: device descriptor read/8, error -11
>>  usb 2-1: new SuperSpeed USB device number 3 using xhci-hcd
>>  usb 2-1: device descriptor read/8, error -11
>>  usb 2-1: new SuperSpeed USB device number 3 using xhci-hcd
>>  usb 2-1: device descriptor read/8, error -11
>>  
>>
>> Thanks,
>> Jack
>>
>> [1] https://lkml.org/lkml/2016/12/9/240
>>
>
> --
> cheers,
> -roger
> --
> 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



-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
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

Re: [PATCH 0/8] usb: dwc3: add dual-role support

[Vivek Gautam]

On Thu, Feb 9, 2017 at 1:19 PM, Roger Quadros <rog...@ti.com> wrote:
> Vivek,
>
> On 09/02/17 08:42, Vivek Gautam wrote:
>> Hi Roger,
>>
>> On Mon, Jan 23, 2017 at 4:49 PM, Roger Quadros <rog...@ti.com> wrote:
>>> Hi,
>>>
>>> We rely on the OTG controller block to provide us with
>>> VBUS and ID line status via an interrupt.
>>>
>>> This is then used to switch the controller between host, peripheral
>>> and idle roles based on the following table.
>>>
>>> ID  VBUSdual-role state
>>> --  ---
>>> 0   x   A_HOST - Host controller active
>>> 1   0   B_IDLE - Both Host and Gadget controllers inactive
>>> 1   1   B_PERIPHERAL - Gadget controller active
>>>
>>
>> Thanks for this series.
>> Sorry, i was held up with something else so couldn't take a look at it.
>> I will integrate this with my work, and add some basic extcon
>> support to enable passing vbus and id events to dwc3 layer to test
>> this out on msm platforms.
>
> I already have this done for one of our platforms to workaround
> a limitation with the OTG IP block on it.
> I can post it today and you can give your comments.

Okay, cool. Thanks. I will wait.


Regards
Vivek

>
> cheers,
> -roger
>>
>>
>> Regards
>> Vivek
>>
>>> Couple of things to clarify:
>>> - There is a small window where we can potentially miss an
>>> event related to OTG. I've added a comment in the code where this
>>> could happen. How can we prevent this? Is it better to just leave
>>> the OTG events unmasked (but keep otg_irq on ARM GIC disabled)
>>> so that any new events can be captured by the OTG event register
>>> and interrupt re-triggered if it has not been serviced by the
>>> previous interrupt.
>>> - I'm running the entire dual-role state change logic inside
>>> the threaded interrupt handler with dwc->lock (spinlock) held
>>> but IRQs enabled. OTG events are very rare i.e. manual intervention
>>> so I don't see this as a problem. Just wanted to double check.
>>> - Some SoC's (e.g. Qualcomm MSM) do not have the OTG controller block
>>> but do have both host and peripheral controllers and so can operate
>>> in dual role mode. Current series does not address this case.
>>> We can get dual-role to work with such SoCs if core.c can get
>>> information about ID and VBUS somehow (private interface
>>> from parent or directly read extcon?).
>>>
>>> cheers,
>>> -roger
>>>
>>> Roger Quadros (8):
>>>   usb: otg-fsm: Prevent build warning "VDBG" redefined
>>>   usb: dwc3-omap: Fix missing break in dwc3_omap_set_mailbox()
>>>   usb: dwc3: use BIT() macro where possible
>>>   usb: dwc3: core.h: add some register definitions
>>>   usb: dwc3: add dual-role support
>>>   ARM: dts: dra7x-evm: Enable dual-role mode for USB1
>>>   ARM: dts: am43xx: Enable dual-role mode for USB1
>>>   ARM: dts: am57xx-idk: Enable dual-role mode for USB2
>>>
>>>  arch/arm/boot/dts/am437x-gp-evm.dts  |   2 +-
>>>  arch/arm/boot/dts/am437x-sk-evm.dts  |   2 +-
>>>  arch/arm/boot/dts/am43x-epos-evm.dts |   2 +-
>>>  arch/arm/boot/dts/am57xx-idk-common.dtsi |   2 +-
>>>  arch/arm/boot/dts/dra7-evm.dts   |   2 +-
>>>  arch/arm/boot/dts/dra72-evm-common.dtsi  |   2 +-
>>>  drivers/usb/common/usb-otg-fsm.c |   7 +
>>>  drivers/usb/dwc3/core.c  | 583 
>>> ++-
>>>  drivers/usb/dwc3/core.h  | 312 -
>>>  drivers/usb/dwc3/dwc3-omap.c |  49 +--
>>>  drivers/usb/dwc3/gadget.c|  18 +-
>>>  drivers/usb/dwc3/gadget.h|  20 +-
>>>  drivers/usb/phy/phy-fsl-usb.c|   7 +
>>>  include/linux/usb/otg-fsm.h  |  15 -
>>>  14 files changed, 848 insertions(+), 175 deletions(-)
>>>
>>> --
>>> 2.7.4
>>>
>>
>
> --
> cheers,
> -roger



-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
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

Re: [PATCH 0/8] usb: dwc3: add dual-role support

[Vivek Gautam]

Hi Roger,

On Mon, Jan 23, 2017 at 4:49 PM, Roger Quadros  wrote:
> Hi,
>
> We rely on the OTG controller block to provide us with
> VBUS and ID line status via an interrupt.
>
> This is then used to switch the controller between host, peripheral
> and idle roles based on the following table.
>
> ID  VBUSdual-role state
> --  ---
> 0   x   A_HOST - Host controller active
> 1   0   B_IDLE - Both Host and Gadget controllers inactive
> 1   1   B_PERIPHERAL - Gadget controller active
>

Thanks for this series.
Sorry, i was held up with something else so couldn't take a look at it.
I will integrate this with my work, and add some basic extcon
support to enable passing vbus and id events to dwc3 layer to test
this out on msm platforms.


Regards
Vivek

> Couple of things to clarify:
> - There is a small window where we can potentially miss an
> event related to OTG. I've added a comment in the code where this
> could happen. How can we prevent this? Is it better to just leave
> the OTG events unmasked (but keep otg_irq on ARM GIC disabled)
> so that any new events can be captured by the OTG event register
> and interrupt re-triggered if it has not been serviced by the
> previous interrupt.
> - I'm running the entire dual-role state change logic inside
> the threaded interrupt handler with dwc->lock (spinlock) held
> but IRQs enabled. OTG events are very rare i.e. manual intervention
> so I don't see this as a problem. Just wanted to double check.
> - Some SoC's (e.g. Qualcomm MSM) do not have the OTG controller block
> but do have both host and peripheral controllers and so can operate
> in dual role mode. Current series does not address this case.
> We can get dual-role to work with such SoCs if core.c can get
> information about ID and VBUS somehow (private interface
> from parent or directly read extcon?).
>
> cheers,
> -roger
>
> Roger Quadros (8):
>   usb: otg-fsm: Prevent build warning "VDBG" redefined
>   usb: dwc3-omap: Fix missing break in dwc3_omap_set_mailbox()
>   usb: dwc3: use BIT() macro where possible
>   usb: dwc3: core.h: add some register definitions
>   usb: dwc3: add dual-role support
>   ARM: dts: dra7x-evm: Enable dual-role mode for USB1
>   ARM: dts: am43xx: Enable dual-role mode for USB1
>   ARM: dts: am57xx-idk: Enable dual-role mode for USB2
>
>  arch/arm/boot/dts/am437x-gp-evm.dts  |   2 +-
>  arch/arm/boot/dts/am437x-sk-evm.dts  |   2 +-
>  arch/arm/boot/dts/am43x-epos-evm.dts |   2 +-
>  arch/arm/boot/dts/am57xx-idk-common.dtsi |   2 +-
>  arch/arm/boot/dts/dra7-evm.dts   |   2 +-
>  arch/arm/boot/dts/dra72-evm-common.dtsi  |   2 +-
>  drivers/usb/common/usb-otg-fsm.c |   7 +
>  drivers/usb/dwc3/core.c  | 583 
> ++-
>  drivers/usb/dwc3/core.h  | 312 -
>  drivers/usb/dwc3/dwc3-omap.c |  49 +--
>  drivers/usb/dwc3/gadget.c|  18 +-
>  drivers/usb/dwc3/gadget.h|  20 +-
>  drivers/usb/phy/phy-fsl-usb.c|   7 +
>  include/linux/usb/otg-fsm.h  |  15 -
>  14 files changed, 848 insertions(+), 175 deletions(-)
>
> --
> 2.7.4
>

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
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

Re: [PATCH v12 3/9] usb: separate out sysdev pointer from usb_bus

[Vivek Gautam]

Hi,

On Mon, Feb 6, 2017 at 2:43 PM, Peter Chen <peter.c...@nxp.com> wrote:
> From: Arnd Bergmann <a...@arndb.de>
>
> For xhci-hcd platform device, all the DMA parameters are not
> configured properly, notably dma ops for dwc3 devices.
>
> The idea here is that you pass in the parent of_node along with
> the child device pointer, so it would behave exactly like the
> parent already does. The difference is that it also handles all
> the other attributes besides the mask.
>
> sysdev will represent the physical device, as seen from firmware
> or bus.Splitting the usb_bus->controller field into the
> Linux-internal device (used for the sysfs hierarchy, for printks
> and for power management) and a new pointer (used for DMA,
> DT enumeration and phy lookup) probably covers all that we really
> need.
>
> Signed-off-by: Arnd Bergmann <a...@arndb.de>
> Signed-off-by: Sriram Dash <sriram.d...@nxp.com>
> Tested-by: Baolin Wang <baolin.w...@linaro.org>
> Tested-by: Brian Norris <briannor...@chromium.org>
> Tested-by: Alexander Sverdlin <alexander.sverd...@nokia.com>
> Tested-by: Vivek Gautam <vivek.gau...@codeaurora.org>
> Signed-off-by: Mathias Nyman <mathias.ny...@linux.intel.com>
> Cc: Felipe Balbi <felipe.ba...@linux.intel.com>
> Cc: Grygorii Strashko <grygorii.stras...@ti.com>
> Cc: Sinjan Kumar <sinj...@codeaurora.org>
> Cc: David Fisher <david.fish...@synopsys.com>
> Cc: Catalin Marinas <catalin.mari...@arm.com>
> Cc: "Thang Q. Nguyen" <tqngu...@apm.com>
> Cc: Yoshihiro Shimoda <yoshihiro.shimoda...@renesas.com>
> Cc: Stephen Boyd <sb...@codeaurora.org>
> Cc: Bjorn Andersson <bjorn.anders...@linaro.org>
> Cc: Ming Lei <tom.leim...@gmail.com>
> Cc: Jon Masters <j...@redhat.com>
> Cc: Dann Frazier <dann.fraz...@canonical.com>
> Cc: Peter Chen <peter.c...@nxp.com>
> Cc: Leo Li <pku@gmail.com>
> ---
>  drivers/usb/core/buffer.c | 12 ++--
>  drivers/usb/core/hcd.c| 48 
> ---
>  drivers/usb/core/usb.c| 18 +-
>  include/linux/usb.h   |  1 +
>  include/linux/usb/hcd.h   |  3 +++
>  5 files changed, 48 insertions(+), 34 deletions(-)

[snip]

> @@ -2511,8 +2512,8 @@ static void init_giveback_urb_bh(struct giveback_urb_bh 
> *bh)
>   * Return: On success, a pointer to the created and initialized HCD 
> structure.
>   * On failure (e.g. if memory is unavailable), %NULL.
>   */

sorry for the noise, but a minor nit here.
The comments section above explains usb_create_shared_hcd() method
and so should be moved down to its place.

> -struct usb_hcd *usb_create_shared_hcd(const struct hc_driver *driver,
> -   struct device *dev, const char *bus_name,
> +struct usb_hcd *__usb_create_hcd(const struct hc_driver *driver,
> +   struct device *sysdev, struct device *dev, const char 
> *bus_name,
> struct usb_hcd *primary_hcd)
>  {
> struct usb_hcd *hcd;
> @@ -2553,8 +2554,9 @@ struct usb_hcd *usb_create_shared_hcd(const struct 
> hc_driver *driver,
>
> usb_bus_init(>self);
> hcd->self.controller = dev;
> +   hcd->self.sysdev = sysdev;
> hcd->self.bus_name = bus_name;
> -   hcd->self.uses_dma = (dev->dma_mask != NULL);
> +   hcd->self.uses_dma = (sysdev->dma_mask != NULL);
>
> init_timer(>rh_timer);
> hcd->rh_timer.function = rh_timer_func;
> @@ -2569,6 +2571,14 @@ struct usb_hcd *usb_create_shared_hcd(const struct 
> hc_driver *driver,
> "USB Host Controller";
> return hcd;
>  }
> +EXPORT_SYMBOL_GPL(__usb_create_hcd);
> +
> +struct usb_hcd *usb_create_shared_hcd(const struct hc_driver *driver,
> +   struct device *dev, const char *bus_name,
> +   struct usb_hcd *primary_hcd)
> +{
> +   return __usb_create_hcd(driver, dev, dev, bus_name, primary_hcd);
> +}
>  EXPORT_SYMBOL_GPL(usb_create_shared_hcd);


Regards
Vivek

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
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

Re: [PATCH v12 6/9] usb: xhci: use bus->sysdev for DMA configuration

[Vivek Gautam]

On Thu, Feb 9, 2017 at 7:11 AM, Peter Chen <hzpeterc...@gmail.com> wrote:
> On Wed, Feb 08, 2017 at 12:43:00PM -0800, Jack Pham wrote:
>> Hi Peter, Sriram, Arnd,
>>
>> On Mon, Feb 06, 2017 at 05:13:38PM +0800, Peter Chen wrote:
>> > From: Arnd Bergmann <a...@arndb.de>
>> >
>> > For xhci-hcd platform device, all the DMA parameters are not
>> > configured properly, notably dma ops for dwc3 devices. So, set
>> > the dma for xhci from sysdev. sysdev is pointing to device that
>> > is known to the system firmware or hardware.
>> >
>> > Signed-off-by: Arnd Bergmann <a...@arndb.de>
>> > Signed-off-by: Sriram Dash <sriram.d...@nxp.com>
>> > Tested-by: Baolin Wang <baolin.w...@linaro.org>
>> > Tested-by: Vivek Gautam <vivek.gau...@codeaurora.org>
>> > Tested-by: Alexander Sverdlin <alexander.sverd...@nokia.com>
>> > Signed-off-by: Mathias Nyman <mathias.ny...@linux.intel.com>
>> > ---
>> > diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
>> > index 6d33b42..7a9c860 100644
>> > --- a/drivers/usb/host/xhci-plat.c
>> > +++ b/drivers/usb/host/xhci-plat.c
>>
>> > -   hcd = usb_create_hcd(driver, >dev, dev_name(>dev));
>> > +   hcd = __usb_create_hcd(driver, sysdev, >dev,
>> > +  dev_name(>dev), NULL);
>>
>> As mentioned already in [1], usb_create_shared_hcd() is called to create
>> the second bus, however it also needs to be converted.
>>
>> Not exactly as Roger's suggestion but this worked for me:
>>
>> -   xhci->shared_hcd = usb_create_shared_hcd(driver, >dev,
>> +   xhci->shared_hcd = __usb_create_hcd(driver, sysdev, >dev,
>> dev_name(>dev), hcd);
>> if (!xhci->shared_hcd) {
>> ret = -ENOMEM;
>>
>> Without this, SuperSpeed devices fail to enumerate:
>>
>>  usb 2-1: new SuperSpeed USB device number 2 using xhci-hcd
>>  usb 2-1: device descriptor read/8, error -11
>>  usb 2-1: new SuperSpeed USB device number 2 using xhci-hcd
>>  usb 2-1: device descriptor read/8, error -11
>>  usb 2-1: new SuperSpeed USB device number 3 using xhci-hcd
>>  usb 2-1: device descriptor read/8, error -11
>>  usb 2-1: new SuperSpeed USB device number 3 using xhci-hcd
>>  usb 2-1: device descriptor read/8, error -11
>>  
>>
>> Thanks,
>> Jack
>>
>
> Do you work at same platform with Vivek Gautam? I see his tested-by
> tag in this patch.

The patches [1] had worked for me on 4.9-rc4.
But with
(a) usb-next merged on 4.10-rc7
(b) this patch and [PATCH 3/9] in this series:
  [PATCH v12 3/9] usb: separate out sysdev pointer from usb_bus
and,
(c) phy patches for msm8996 [2] along with necessary device tree patches
I get a hang when SuperSpeed device is being enumerated on db820c.

The change above suggested by Jack works for me too, and i hope that's
the right way to do things.

I can give a Tested-by again with the changes for shared_hcd in the
next version.

[1] https://lkml.org/lkml/2016/11/17/339
[2] https://lkml.org/lkml/2017/1/10/225

>
> I have no dwc3 platform to test, I only got patches from [1], and rebase to
> Greg's usb-next, the rebase has a conflict, and I made a
> change which is similar to revert below patch, but it is definitely
> not your problem.
>
> commit 488dc164914ff5ce5e913abd32048d28fc0d06b8
> Author: Mathias Nyman <mathias.ny...@linux.intel.com>
> Date:   Fri Jan 20 15:38:24 2017 +0200
>
> xhci: remove WARN_ON if dma mask is not set for platform devices
>
>
> [1] http://www.spinics.net/lists/linux-usb/msg152375.html
>
> --
>
> Best Regards,
> Peter Chen
> --
> 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



-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
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

Re: [PATCH v12 6/9] usb: xhci: use bus->sysdev for DMA configuration

[Vivek Gautam]

Hi,


On Mon, Feb 6, 2017 at 2:43 PM, Peter Chen <peter.c...@nxp.com> wrote:
> From: Arnd Bergmann <a...@arndb.de>
>
> For xhci-hcd platform device, all the DMA parameters are not
> configured properly, notably dma ops for dwc3 devices. So, set
> the dma for xhci from sysdev. sysdev is pointing to device that
> is known to the system firmware or hardware.
>
> Signed-off-by: Arnd Bergmann <a...@arndb.de>
> Signed-off-by: Sriram Dash <sriram.d...@nxp.com>
> Tested-by: Baolin Wang <baolin.w...@linaro.org>
> Tested-by: Vivek Gautam <vivek.gau...@codeaurora.org>
> Tested-by: Alexander Sverdlin <alexander.sverd...@nokia.com>
> Signed-off-by: Mathias Nyman <mathias.ny...@linux.intel.com>
> ---

This patch doesn't work for me anymore on db820c target [1].
While the same kernel with reverts of patches [2] [3] and an older
patch [4] by Grygorii Strashko works [5].

[1] 
https://github.com/vivekgautam1/linux/tree/linux-v4.10-rc7-usb-db820c-nonworking
[2] 8c9f2de459c7 usb: dwc3: Do not set dma coherent mask
[3] d64ff406e51e usb: dwc3: use bus->sysdev for DMA configuration
[4] https://lkml.org/lkml/2016/4/25/813
[5] https://github.com/vivekgautam1/linux/tree/linux-v4.10-rc7-usb-db820c


regards
Vivek

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
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

Re: [PATCH v11 08/14] usb: otg: add OTG/dual-role core

[Vivek Gautam]

On 01/20/2017 02:00 PM, Roger Quadros wrote:

Vivek,

On 19/01/17 17:15, vivek.gau...@codeaurora.org wrote:

Hi Roger,

On 2017-01-19 17:45, Roger Quadros wrote:

Vivek,

On 19/01/17 13:56, Vivek Gautam wrote:

Hi,


On Wed, Jun 22, 2016 at 2:00 PM, Roger Quadros <rog...@ti.com> wrote:

Luckily hit this thread while checking about DRD role functionality for DWC3.


On 22/06/16 11:14, Felipe Balbi wrote:

Hi,

Roger Quadros <rog...@ti.com> writes:

For the real use case, some Carplay platforms need it.

Carplay does *NOT* rely on OTG. Apple has its own proprietary and closed
specification which is not OTG-compliant.


Yes, it is not OTG-compliant, but it can co-work with some standard OTG FSM
states to finish role swap.

What are you referring to as "finish role swap"? I don't get that.

Change current role from host to peripheral.

Okay, we have two scenarios here:

1. You need full OTG compliance

   For this, granted, you need the state machine if your HW doesn't
   track it. This is a given. With only one user, however, perhaps
   we don't need a generic layer. There are not enough different
   setups to design a good enough generic layer. We will end up
   with a pseudo-generic framework which is coupled with its only
   user.

2. Dual-role support, without OTG compliance

   In this case, you don't need a stack. All you need is a signal
   to tell you state of ID pin and another to tell you state of
   VBUS level. If you have those, you don't need to walk an OTG
   state machine at all. You don't need any of those quirky OTG
   timers, agreed?

   Given the above, why would you even want to use a subset of OTG
   state machine to implement something that's _usually_ as simple
   as:

8<--
   vbus = read(VBUS_STATE); /* could be a gpio_get_value() */
 id = read(ID_STATE); /* could be a gpio_get_value() */

 set_role(id);
 set_vbus(vbus);



In fact, the individual driver can do it by itself. The chipidea driver
handles OTG and dual-role well currently. By considering this OTG/DRD
framework is worthwhile or not, we would like to see if it can
simplify DRD design for each driver, and can benefit the platforms which
has different drivers for host and peripheral to finish the role switch
well.

simplify how?  By adding unnecessary workqueues and a level indirection
that just goes back to the same driver?

What do you mean by same driver?

dwc3 registers to OTG layer. dwc3 also registers as UDC to UDC
layer. When dwc3 OTG IRQ fires, dwc3 tells OTG layer about it and OTG
layer jumps to a callback that goes back to dwc3 to e.g. start
peripheral side.

See ?!? Starts on dwc3, goes to OTG layer, goes back to DWC3.


Gadget driver, host driver and PHY (or MUX) driver (for ID/VBUS) can
be 3 totally independent drivers unlike dwc3 where you have a single
driver in control of both host and gadget.

That's a totally different issue and one not being tackled by OTG
layer, because there are no such users yet. We can't design anything
based solely on speculation of what might happen.

If there aren't enough users, there is no way to design a good generic
layer.


Questions not clear to me are:

1) Which driver handles ID/VBUS events and makes a decision to do the
role swap?  Probably the PHY/MUX driver?

This is implementation dependent. For TI's USB subsystem, we have PMIC
sampling VBUS/ID that and using EXTCON to tell dwc3-omap to program UTMI
mailbox. The same mailbox can be used in HW-mode (see AM437x) where SW
has no intervention.

For Intel's USB subsystem, we have PMIC sampling VBUS/ID with an
internal mux (much like TI's UTMI mailbox, but slightly different) to
switch between a separate XHCI or a separate dwc3. The same mux can be
put in HW-mode where SW has no intervention.

In any case, for Intel's stuff most of the magic happens in ASL. Our PHY
driver just detects role (at least for Type-C based plats) and executes
_DSM with correct arguments [1]. _DSM will program internal MUX, toggle
VBUS and, for type-C, toggle VCONN when needed.


2) How does it perform the role swap? Probably a register write to the
PHY/MUX without needing to stop/start controllers? Easy case is both
controllers can run in co-existence without interference. Is there any
platform other than dwc3 where this is not the case?

Again speculation. But to answer your question, only dwc3 is in such a
case today. But even for dwc3 we can have DRD with a much, much simpler
setup as I have already explained.


3) Even if host and gadget controllers can operate in coexistence,
there is no need for both to be running for embedded applications
which are usually power conservative.  How can we achieve that?

Now you're also speculating that you're running on embedded applications
and that we _can_ power off parts of the IP. I happen to know that we
can't po

Re: [PATCH v11 08/14] usb: otg: add OTG/dual-role core

[vivek . gautam]

Hi Roger,

On 2017-01-19 17:45, Roger Quadros wrote:

Vivek,

On 19/01/17 13:56, Vivek Gautam wrote:

Hi,


On Wed, Jun 22, 2016 at 2:00 PM, Roger Quadros <rog...@ti.com> wrote:

Luckily hit this thread while checking about DRD role functionality 
for DWC3.



On 22/06/16 11:14, Felipe Balbi wrote:


Hi,

Roger Quadros <rog...@ti.com> writes:

For the real use case, some Carplay platforms need it.


Carplay does *NOT* rely on OTG. Apple has its own 
proprietary and closed

specification which is not OTG-compliant.



Yes, it is not OTG-compliant, but it can co-work with some 
standard OTG FSM

states to finish role swap.


What are you referring to as "finish role swap"? I don't get 
that.


Change current role from host to peripheral.


Okay, we have two scenarios here:

1. You need full OTG compliance

  For this, granted, you need the state machine if your HW 
doesn't
  track it. This is a given. With only one user, however, 
perhaps

  we don't need a generic layer. There are not enough different
  setups to design a good enough generic layer. We will end up
  with a pseudo-generic framework which is coupled with its only
  user.

2. Dual-role support, without OTG compliance

  In this case, you don't need a stack. All you need is a signal
  to tell you state of ID pin and another to tell you state of
  VBUS level. If you have those, you don't need to walk an OTG
  state machine at all. You don't need any of those quirky OTG
  timers, agreed?

  Given the above, why would you even want to use a subset of 
OTG
  state machine to implement something that's _usually_ as 
simple

  as:

8<--
  vbus = read(VBUS_STATE); /* could be a gpio_get_value() */
id = read(ID_STATE); /* could be a gpio_get_value() */

set_role(id);
set_vbus(vbus);




In fact, the individual driver can do it by itself. The chipidea 
driver
handles OTG and dual-role well currently. By considering this 
OTG/DRD

framework is worthwhile or not, we would like to see if it can
simplify DRD design for each driver, and can benefit the 
platforms which
has different drivers for host and peripheral to finish the role 
switch

well.


simplify how?  By adding unnecessary workqueues and a level 
indirection

that just goes back to the same driver?


What do you mean by same driver?


dwc3 registers to OTG layer. dwc3 also registers as UDC to UDC
layer. When dwc3 OTG IRQ fires, dwc3 tells OTG layer about it and 
OTG

layer jumps to a callback that goes back to dwc3 to e.g. start
peripheral side.

See ?!? Starts on dwc3, goes to OTG layer, goes back to DWC3.

Gadget driver, host driver and PHY (or MUX) driver (for ID/VBUS) 
can
be 3 totally independent drivers unlike dwc3 where you have a 
single

driver in control of both host and gadget.


That's a totally different issue and one not being tackled by OTG
layer, because there are no such users yet. We can't design anything
based solely on speculation of what might happen.

If there aren't enough users, there is no way to design a good 
generic

layer.


Questions not clear to me are:

1) Which driver handles ID/VBUS events and makes a decision to do 
the

role swap?  Probably the PHY/MUX driver?


This is implementation dependent. For TI's USB subsystem, we have 
PMIC
sampling VBUS/ID that and using EXTCON to tell dwc3-omap to program 
UTMI
mailbox. The same mailbox can be used in HW-mode (see AM437x) where 
SW

has no intervention.

For Intel's USB subsystem, we have PMIC sampling VBUS/ID with an
internal mux (much like TI's UTMI mailbox, but slightly different) 
to
switch between a separate XHCI or a separate dwc3. The same mux can 
be

put in HW-mode where SW has no intervention.

In any case, for Intel's stuff most of the magic happens in ASL. Our 
PHY
driver just detects role (at least for Type-C based plats) and 
executes
_DSM with correct arguments [1]. _DSM will program internal MUX, 
toggle

VBUS and, for type-C, toggle VCONN when needed.

2) How does it perform the role swap? Probably a register write to 
the
PHY/MUX without needing to stop/start controllers? Easy case is 
both
controllers can run in co-existence without interference. Is there 
any

platform other than dwc3 where this is not the case?


Again speculation. But to answer your question, only dwc3 is in such 
a
case today. But even for dwc3 we can have DRD with a much, much 
simpler

setup as I have already explained.


3) Even if host and gadget controllers can operate in coexistence,
there is no need for both to be running for embedded applications
which are usually power conservative.  How can we achieve that?


Now you're also speculating that you're running on embedded 
applications
and that we _can_ power off parts of the IP. I happen to know that 
we
can't power off XHCI part of dwc3 in TI's SoC because that's fed by 
sam

Re: [PATCH v11 08/14] usb: otg: add OTG/dual-role core

[Vivek Gautam]

Hi,


On Wed, Jun 22, 2016 at 2:00 PM, Roger Quadros  wrote:

Luckily hit this thread while checking about DRD role functionality for DWC3.

> On 22/06/16 11:14, Felipe Balbi wrote:
>>
>> Hi,
>>
>> Roger Quadros  writes:
>>> For the real use case, some Carplay platforms need it.
>>
>> Carplay does *NOT* rely on OTG. Apple has its own proprietary and 
>> closed
>> specification which is not OTG-compliant.
>>
>
> Yes, it is not OTG-compliant, but it can co-work with some standard 
> OTG FSM
> states to finish role swap.

 What are you referring to as "finish role swap"? I don't get that.
>>>
>>> Change current role from host to peripheral.
>>
>> Okay, we have two scenarios here:
>>
>> 1. You need full OTG compliance
>>
>>   For this, granted, you need the state machine if your HW doesn't
>>   track it. This is a given. With only one user, however, perhaps
>>   we don't need a generic layer. There are not enough different
>>   setups to design a good enough generic layer. We will end up
>>   with a pseudo-generic framework which is coupled with its only
>>   user.
>>
>> 2. Dual-role support, without OTG compliance
>>
>>   In this case, you don't need a stack. All you need is a signal
>>   to tell you state of ID pin and another to tell you state of
>>   VBUS level. If you have those, you don't need to walk an OTG
>>   state machine at all. You don't need any of those quirky OTG
>>   timers, agreed?
>>
>>   Given the above, why would you even want to use a subset of OTG
>>   state machine to implement something that's _usually_ as simple
>>   as:
>>
>> 8<--
>>   vbus = read(VBUS_STATE); /* could be a gpio_get_value() */
>> id = read(ID_STATE); /* could be a gpio_get_value() */
>>
>> set_role(id);
>> set_vbus(vbus);
>> 
>>
>
> In fact, the individual driver can do it by itself. The chipidea driver
> handles OTG and dual-role well currently. By considering this OTG/DRD
> framework is worthwhile or not, we would like to see if it can
> simplify DRD design for each driver, and can benefit the platforms which
> has different drivers for host and peripheral to finish the role switch
> well.

 simplify how?  By adding unnecessary workqueues and a level indirection
 that just goes back to the same driver?
>>>
>>> What do you mean by same driver?
>>
>> dwc3 registers to OTG layer. dwc3 also registers as UDC to UDC
>> layer. When dwc3 OTG IRQ fires, dwc3 tells OTG layer about it and OTG
>> layer jumps to a callback that goes back to dwc3 to e.g. start
>> peripheral side.
>>
>> See ?!? Starts on dwc3, goes to OTG layer, goes back to DWC3.
>>
>>> Gadget driver, host driver and PHY (or MUX) driver (for ID/VBUS) can
>>> be 3 totally independent drivers unlike dwc3 where you have a single
>>> driver in control of both host and gadget.
>>
>> That's a totally different issue and one not being tackled by OTG
>> layer, because there are no such users yet. We can't design anything
>> based solely on speculation of what might happen.
>>
>> If there aren't enough users, there is no way to design a good generic
>> layer.
>>
>>> Questions not clear to me are:
>>>
>>> 1) Which driver handles ID/VBUS events and makes a decision to do the
>>> role swap?  Probably the PHY/MUX driver?
>>
>> This is implementation dependent. For TI's USB subsystem, we have PMIC
>> sampling VBUS/ID that and using EXTCON to tell dwc3-omap to program UTMI
>> mailbox. The same mailbox can be used in HW-mode (see AM437x) where SW
>> has no intervention.
>>
>> For Intel's USB subsystem, we have PMIC sampling VBUS/ID with an
>> internal mux (much like TI's UTMI mailbox, but slightly different) to
>> switch between a separate XHCI or a separate dwc3. The same mux can be
>> put in HW-mode where SW has no intervention.
>>
>> In any case, for Intel's stuff most of the magic happens in ASL. Our PHY
>> driver just detects role (at least for Type-C based plats) and executes
>> _DSM with correct arguments [1]. _DSM will program internal MUX, toggle
>> VBUS and, for type-C, toggle VCONN when needed.
>>
>>> 2) How does it perform the role swap? Probably a register write to the
>>> PHY/MUX without needing to stop/start controllers? Easy case is both
>>> controllers can run in co-existence without interference. Is there any
>>> platform other than dwc3 where this is not the case?
>>
>> Again speculation. But to answer your question, only dwc3 is in such a
>> case today. But even for dwc3 we can have DRD with a much, much simpler
>> setup as I have already explained.
>>
>>> 3) Even if host and gadget controllers can 

Re: [PATCH] usb: dwc3-exynos fix unspecified suspend clk error handling

[vivek . gautam]

On 2017-01-10 22:39, Bartlomiej Zolnierkiewicz wrote:

Hi,

On Tuesday, January 10, 2017 09:28:52 AM Shuah Khan wrote:

On 01/10/2017 09:05 AM, Bartlomiej Zolnierkiewicz wrote:
>
> Hi,
>
> On Tuesday, January 10, 2017 07:36:35 AM Shuah Khan wrote:
>> On 01/10/2017 07:16 AM, Shuah Khan wrote:
>>> On 01/10/2017 05:05 AM, Bartlomiej Zolnierkiewicz wrote:
>>>>
>>>> Hi,
>>>>
>>>> On Monday, January 09, 2017 07:21:31 PM Shuah Khan wrote:
>>>>> Fix dwc3_exynos_probe() to call clk_prepare_enable() only when suspend
>>>>> clock is specified. Call clk_disable_unprepare() from remove and probe
>>>>> error path only when susp_clk has been set from remove and probe error
>>>>> paths.
>>>>
>>>> It is legal to call clk_prepare_enable() and clk_disable_unprepare()
>>>> for NULL clock.  Also your patch changes susp_clk handling while
>>>> leaves axius_clk handling (which also can be NULL) untouched.
>>>>
>>>> Do you actually see some runtime problem with the current code?
>>>>
>>>> If not then the patch should probably be dropped.
>>>>
>>>> Best regards,
>>>> --
>>>> Bartlomiej Zolnierkiewicz
>>>> Samsung R Institute Poland
>>>> Samsung Electronics
>>>
>>> Hi Bartlomiej,
>>>
>>> I am seeing the "no suspend clk specified" message in dmesg.
>>> After that it sets the exynos->susp_clk = NULL and starts
>>> calling clk_prepare_enable(exynos->susp_clk);
>>>
>>> That can't be good. If you see the logic right above this
>>> one for exynos->clk, it returns error and fails the probe.
>>> This this case it doesn't, but tries to use null susp_clk.
>
> exynos->susp_clk is optional, exynos->clk is not.

Right. That is clear since we don't fail the probe.

>
>>> I believe this patch is necessary.
>>
>> Let me clarify this a bit further. Since we already know
>> susp_clk is null, with this patch we can avoid extra calls
>> to clk_prepare_enable() and clk_disable_unprepare().
>>
>> One can say, it also adds extra checks, hence I will let you
>> decide one way or the other. :)


Hi Shuah Khan,

Like Bartlomiej mentioned below, it is completely fair to call
clk_prepare_enable() with NULL clocks. That's how most of the
optional clocks are handled in the kernel. So, i don't think
there's any need of adding an additional check for the 
'exynos->susp_clk'.


The 'exynos->clk' is the main IP clock that is mandatory, and hence
the probe fails in case that is not present.


>
> I would prefer to leave the things as they are currently.
>
> The code in question is not performance sensitive so extra
> calls are not a problem.  No extra checks means less code.
>
> Also the current code seems to be more in line with the rest
> of the kernel.

What functionality is missing without the suspend clock? Would
it make sense to change the info. message to include what it
means. At the moment it doesn't anything more than "no suspend
clock" which is a very cryptic user visible message. It would be
helpful for it to also include what functionality is impacted.


Well, all I know is what the original commit descriptions says and
that the commit itself comes from patchset adding Exynos7 USB 3.0
support [1]:

commit 72d996fc7a01c2e4d581a15db7d001e2799ffb29
Author: Vivek Gautam <gautam.vi...@samsung.com>
Date:   Fri Nov 21 19:05:46 2014 +0530

usb: dwc3: exynos: Add provision for suspend clock

DWC3 controller on Exynos SoC series have separate control for
suspend clock which replaces pipe3_rx_pclk as clock source to
a small part of DWC3 core that operates when SS PHY is in its
lowest power state (P3) in states SS.disabled and U3.

Suggested-by: Anton Tikhomirov <av.tikhomi...@samsung.com>
Signed-off-by: Vivek Gautam <gautam.vi...@samsung.com>
Signed-off-by: Felipe Balbi <ba...@ti.com>



Hi Bartlomiej,


Anton's & Vivek's Samsung email addresses are no longer valid but
I added current Vivek's email address to Cc:.


Thanks for adding me to the thread.



BTW What is interesting is that the Exynos7 dts patch [2] has never
made it into upstream for some reason.  In the meantime however
Exynos5433 (similar to Exynos7 to some degree) became the user of
susp_clk.


You are right. The exynos7 device tree patches could not make it to
upstream for some reasons. I think there are few guys looking at USB
for Exynos.
If there's something needed on Exynos7 USB side, i have added
Pankaj Dubey <pankaj.du...@samsung.com> to this thread.

Hi Pankaj,
I am adding you to please help us with any future requirements
for exynos USB in the upstream.
Thanks!



[1] https://lkml.org/lkml/2014/11/21/247
[2] https://patchwork.kernel.org/patch/5355161/

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R Institute Poland
Samsung Electronics


[snip]


Best Regards
Vivek
--
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