Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1431357 > unrolled thread

[PATCH 00/21] Support qcom's HSIC USB and rewrite USB2 HS phy support

Back to article view | Back to linux.kernel

Contents

  [PATCH 00/21] Support qcom's HSIC USB and rewrite USB2 HS phy support Stephen Boyd <stephen.boyd@linaro.org> - 2016-06-26 09:30 +0200
    [PATCH 13/21] usb: chipidea: msm: Allow core to get usb phy Stephen Boyd <stephen.boyd@linaro.org> - 2016-06-26 09:30 +0200
      Re: [PATCH 13/21] usb: chipidea: msm: Allow core to get usb phy Peter Chen <hzpeterchen@gmail.com> - 2016-06-29 09:00 +0200
        Re: [PATCH 13/21] usb: chipidea: msm: Allow core to get usb phy Peter Chen <hzpeterchen@gmail.com> - 2016-06-29 13:50 +0200
          Re: [PATCH 13/21] usb: chipidea: msm: Allow core to get usb phy Peter Chen <hzpeterchen@gmail.com> - 2016-06-30 04:00 +0200
    [PATCH 09/21] usb: chipidea: Add support for ULPI PHY bus Stephen Boyd <stephen.boyd@linaro.org> - 2016-06-26 09:40 +0200
      Re: [PATCH 09/21] usb: chipidea: Add support for ULPI PHY bus Peter Chen <hzpeterchen@gmail.com> - 2016-06-29 08:40 +0200
    [PATCH 14/21] usb: chipidea: msm: Add proper clk and reset support Stephen Boyd <stephen.boyd@linaro.org> - 2016-06-26 09:40 +0200
      Re: [PATCH 14/21] usb: chipidea: msm: Add proper clk and reset  support Peter Chen <hzpeterchen@gmail.com> - 2016-06-29 09:10 +0200
    [PATCH 07/21] usb: chipidea: Notify of reset when switching into host mode Stephen Boyd <stephen.boyd@linaro.org> - 2016-06-26 09:40 +0200
    [PATCH 06/21] usb: chipidea: Initialize and reinitialize phy later Stephen Boyd <stephen.boyd@linaro.org> - 2016-06-26 09:40 +0200
      Re: [PATCH 06/21] usb: chipidea: Initialize and reinitialize phy  later Peter Chen <hzpeterchen@gmail.com> - 2016-06-29 04:40 +0200
        Re: [PATCH 06/21] usb: chipidea: Initialize and reinitialize phy  later Peter Chen <hzpeterchen@gmail.com> - 2016-06-30 03:30 +0200
    [PATCH 19/21] usb: chipidea: msm: Be silent on probe defer errors Stephen Boyd <stephen.boyd@linaro.org> - 2016-06-26 09:40 +0200
      Re: [PATCH 19/21] usb: chipidea: msm: Be silent on probe defer errors Peter Chen <hzpeterchen@gmail.com> - 2016-06-30 03:30 +0200
    [PATCH 03/21] usb: ulpi: Avoid reading/writing in device creation with OF devices Stephen Boyd <stephen.boyd@linaro.org> - 2016-06-26 09:40 +0200
    [PATCH 20/21] phy: Add support for Qualcomm's USB HSIC phy Stephen Boyd <stephen.boyd@linaro.org> - 2016-06-26 09:40 +0200
      Re: [PATCH 20/21] phy: Add support for Qualcomm's USB HSIC phy Neil Armstrong <narmstrong@baylibre.com> - 2016-06-28 10:50 +0200
        Re: [PATCH 20/21] phy: Add support for Qualcomm's USB HSIC phy Stephen Boyd <stephen.boyd@linaro.org> - 2016-06-29 00:10 +0200
          Re: [PATCH 20/21] phy: Add support for Qualcomm's USB HSIC phy Neil Armstrong <narmstrong@baylibre.com> - 2016-06-29 11:20 +0200
            Re: [PATCH 20/21] phy: Add support for Qualcomm's USB HSIC phy Stephen Boyd <stephen.boyd@linaro.org> - 2016-06-29 21:00 +0200
    [PATCH 05/21] usb: chipidea: Handle extcon events properly Stephen Boyd <stephen.boyd@linaro.org> - 2016-06-26 09:40 +0200
      Re: [PATCH 05/21] usb: chipidea: Handle extcon events properly Peter Chen <hzpeterchen@gmail.com> - 2016-06-28 12:10 +0200
    [PATCH 08/21] usb: chipidea: Kick OTG state machine for AVVIS with vbus extcon Stephen Boyd <stephen.boyd@linaro.org> - 2016-06-26 09:40 +0200
      Re: [PATCH 08/21] usb: chipidea: Kick OTG state machine for AVVIS  with vbus extcon Peter Chen <hzpeterchen@gmail.com> - 2016-06-29 05:20 +0200
        Re: [PATCH 08/21] usb: chipidea: Kick OTG state machine for AVVIS  with vbus extcon Peter Chen <hzpeterchen@gmail.com> - 2016-06-30 03:40 +0200
          RE: [PATCH 08/21] usb: chipidea: Kick OTG state machine for AVVIS  with vbus extcon Jun Li <jun.li@nxp.com> - 2016-06-30 04:10 +0200
    [PATCH 18/21] usb: chipidea: msm: Add reset controller for PHY POR bit Stephen Boyd <stephen.boyd@linaro.org> - 2016-06-26 09:40 +0200
      Re: [PATCH 18/21] usb: chipidea: msm: Add reset controller for PHY  POR bit kbuild test robot <lkp@intel.com> - 2016-06-27 05:50 +0200
      Re: [PATCH 18/21] usb: chipidea: msm: Add reset controller for PHY  POR bit kbuild test robot <lkp@intel.com> - 2016-06-27 07:00 +0200
      Re: [PATCH 18/21] usb: chipidea: msm: Add reset controller for PHY  POR bit kbuild test robot <lkp@intel.com> - 2016-06-27 10:00 +0200
      Re: [PATCH 18/21] usb: chipidea: msm: Add reset controller for PHY  POR bit Peter Chen <hzpeterchen@gmail.com> - 2016-06-29 14:00 +0200
    [PATCH 02/21] usb: ulpi: Support device discovery via DT Stephen Boyd <stephen.boyd@linaro.org> - 2016-06-26 09:40 +0200
      Re: [PATCH 02/21] usb: ulpi: Support device discovery via DT kbuild test robot <lkp@intel.com> - 2016-06-27 06:20 +0200
      Re: [PATCH 02/21] usb: ulpi: Support device discovery via DT Heikki Krogerus <heikki.krogerus@linux.intel.com> - 2016-06-27 16:40 +0200
        Re: [PATCH 02/21] usb: ulpi: Support device discovery via DT Heikki Krogerus <heikki.krogerus@linux.intel.com> - 2016-06-28 13:50 +0200
          Re: [PATCH 02/21] usb: ulpi: Support device discovery via DT Peter Chen <hzpeterchen@gmail.com> - 2016-06-29 04:10 +0200
      Re: [PATCH 02/21] usb: ulpi: Support device discovery via DT Rob Herring <robh@kernel.org> - 2016-06-28 23:00 +0200
        Re: [PATCH 02/21] usb: ulpi: Support device discovery via DT Rob Herring <robh@kernel.org> - 2016-07-01 03:10 +0200
    [PATCH 15/21] usb: chipidea: msm: Mux over secondary phy at the right time Stephen Boyd <stephen.boyd@linaro.org> - 2016-06-26 09:40 +0200
      Re: [PATCH 15/21] usb: chipidea: msm: Mux over secondary phy at the  right time Bjorn Andersson <bjorn.andersson@linaro.org> - 2016-06-28 07:00 +0200
      Re: [PATCH 15/21] usb: chipidea: msm: Mux over secondary phy at the  right time Peter Chen <hzpeterchen@gmail.com> - 2016-06-29 10:20 +0200
        Re: [PATCH 15/21] usb: chipidea: msm: Mux over secondary phy at the  right time Peter Chen <hzpeterchen@gmail.com> - 2016-06-30 04:00 +0200
    [PATCH 16/21] usb: chipidea: msm: Restore wrapper settings after reset Stephen Boyd <stephen.boyd@linaro.org> - 2016-06-26 09:40 +0200
      Re: [PATCH 16/21] usb: chipidea: msm: Restore wrapper settings after  reset Peter Chen <hzpeterchen@gmail.com> - 2016-06-29 10:40 +0200
        Re: [PATCH 16/21] usb: chipidea: msm: Restore wrapper settings after  reset Peter Chen <hzpeterchen@gmail.com> - 2016-06-30 11:10 +0200
          Re: [PATCH 16/21] usb: chipidea: msm: Restore wrapper settings after reset Stephen Boyd <stephen.boyd@linaro.org> - 2016-06-30 18:30 +0200
    [PATCH 11/21] usb: chipidea: msm: Use hw_write_id_reg() instead of writel directly Stephen Boyd <stephen.boyd@linaro.org> - 2016-06-26 09:40 +0200
      Re: [PATCH 11/21] usb: chipidea: msm: Use hw_write_id_reg() instead  of writel directly Peter Chen <hzpeterchen@gmail.com> - 2016-06-29 08:50 +0200
    [PATCH 21/21] phy: Add support for Qualcomm's USB HS phy Stephen Boyd <stephen.boyd@linaro.org> - 2016-06-26 09:40 +0200
    [PATCH 17/21] usb: chipidea: msm: Make platform data driver local instead of global Stephen Boyd <stephen.boyd@linaro.org> - 2016-06-26 09:40 +0200
      Re: [PATCH 17/21] usb: chipidea: msm: Make platform data driver  local instead of global Peter Chen <hzpeterchen@gmail.com> - 2016-06-29 13:40 +0200
        Re: [PATCH 17/21] usb: chipidea: msm: Make platform data driver  local instead of global Peter Chen <hzpeterchen@gmail.com> - 2016-06-30 11:20 +0200
    [PATCH 01/21] of: device: Support loading a module with OF based modalias Stephen Boyd <stephen.boyd@linaro.org> - 2016-06-26 09:40 +0200
      Re: [PATCH 01/21] of: device: Support loading a module with OF based  modalias Bjorn Andersson <bjorn.andersson@linaro.org> - 2016-06-28 06:20 +0200
    [PATCH 04/21] usb: chipidea: Only read/write OTGSC from one place Stephen Boyd <stephen.boyd@linaro.org> - 2016-06-26 09:40 +0200
      RE: [PATCH 04/21] usb: chipidea: Only read/write OTGSC from one place Jun Li <jun.li@nxp.com> - 2016-06-27 10:10 +0200
        RE: [PATCH 04/21] usb: chipidea: Only read/write OTGSC from one place Stephen Boyd <stephen.boyd@linaro.org> - 2016-06-27 21:10 +0200
          Re: [PATCH 04/21] usb: chipidea: Only read/write OTGSC from one place Peter Chen <hzpeterchen@gmail.com> - 2016-06-28 11:50 +0200
    Re: [PATCH 00/21] Support qcom's HSIC USB and rewrite USB2 HS phy support John Stultz <john.stultz@linaro.org> - 2016-06-28 05:10 +0200
      Re: [PATCH 00/21] Support qcom's HSIC USB and rewrite USB2 HS phy support John Stultz <john.stultz@linaro.org> - 2016-07-02 08:10 +0200
        Re: [PATCH 00/21] Support qcom's HSIC USB and rewrite USB2 HS phy support John Stultz <john.stultz@linaro.org> - 2016-07-05 21:40 +0200

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

#1433979 — Re: [PATCH 20/21] phy: Add support for Qualcomm's USB HSIC phy

Quoting Neil Armstrong (2016-06-29 02:16:51)
> On 06/28/2016 11:58 PM, Stephen Boyd wrote:
> > Quoting Neil Armstrong (2016-06-28 01:49:37)
> >> On 06/26/2016 09:28 AM, Stephen Boyd wrote:
> >>> +     uphy->cal_sleep_clk = clk = devm_clk_get(&ulpi->dev, "cal_sleep");
> >>> +     if (IS_ERR(clk))
> >>> +             return PTR_ERR(clk);
> >>
> >> Hi Stephen,
> >>
> >> In the bindings the cal_sleep is marked optional, and I think should be since AFAIK
> >> it's not present on MDM9615 for example.
> > 
> > The cal_sleep clk is just the sleep clk then (should be a board clk in
> > DT). Sometimes there's a gate in GCC to allow us to turn it off, other
> > times there isn't. Either way, it's always wired there so I'll update
> > the binding to say it isn't optional.
> 
> Sorry I don't understand !
> What should I do if GCC does not provide a gate here ? And looking at the driver, it could be optional.

You should set the property to point to &sleep_clk which should be under
the "clocks" node at the root of the OF tree. For example, see the
sleep_clk node in arch/arm/boot/dts/qcom-apq8064.dtsi.

[toc] | [prev] | [next] | [standalone]

#1431366 — [PATCH 05/21] usb: chipidea: Handle extcon events properly

We're currently emulating the vbus and id interrupts in the OTGSC
read API, but we also need to make sure that if we're handling
the events with extcon that we don't enable the interrupts for
those events in the hardware. Therefore, properly emulate this
register if we're using extcon, but don't enable the interrupts.
This allows me to get my cable connect/disconnect working
properly without getting spurious interrupts on my device that
uses an extcon for these two events.

Cc: Peter Chen <peter.chen@nxp.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: "Ivan T. Ivanov" <iivanov.xz@gmail.com>
Fixes: 3ecb3e09b042 ("usb: chipidea: Use extcon framework for VBUS and ID detect")
Signed-off-by: Stephen Boyd <stephen.boyd@linaro.org>
---
 drivers/usb/chipidea/otg.c   | 46 +++++++++++++++++++++++++++++++++++++++-----
 include/linux/usb/chipidea.h |  2 ++
 2 files changed, 43 insertions(+), 5 deletions(-)

diff --git a/drivers/usb/chipidea/otg.c b/drivers/usb/chipidea/otg.c
index 763a8332b009..b6a88bea4cac 100644
--- a/drivers/usb/chipidea/otg.c
+++ b/drivers/usb/chipidea/otg.c
@@ -44,12 +44,15 @@ u32 hw_read_otgsc(struct ci_hdrc *ci, u32 mask)
 		else
 			val &= ~OTGSC_BSVIS;
 
-		cable->changed = false;
-
 		if (cable->state)
 			val |= OTGSC_BSV;
 		else
 			val &= ~OTGSC_BSV;
+
+		if (cable->enabled)
+			val |= OTGSC_BSVIE;
+		else
+			val &= ~OTGSC_BSVIE;
 	}
 
 	cable = &ci->platdata->id_extcon;
@@ -59,15 +62,18 @@ u32 hw_read_otgsc(struct ci_hdrc *ci, u32 mask)
 		else
 			val &= ~OTGSC_IDIS;
 
-		cable->changed = false;
-
 		if (cable->state)
 			val |= OTGSC_ID;
 		else
 			val &= ~OTGSC_ID;
+
+		if (cable->enabled)
+			val |= OTGSC_IDIE;
+		else
+			val &= ~OTGSC_IDIE;
 	}
 
-	return val;
+	return val & mask;
 }
 
 /**
@@ -77,6 +83,36 @@ u32 hw_read_otgsc(struct ci_hdrc *ci, u32 mask)
  */
 void hw_write_otgsc(struct ci_hdrc *ci, u32 mask, u32 data)
 {
+	struct ci_hdrc_cable *cable;
+
+	cable = &ci->platdata->vbus_extcon;
+	if (!IS_ERR(cable->edev)) {
+		if (data & mask & OTGSC_BSVIS)
+			cable->changed = false;
+
+		/* Don't enable vbus interrupt if using external notifier */
+		if (data & mask & OTGSC_BSVIE) {
+			cable->enabled = true;
+			data &= ~OTGSC_BSVIE;
+		} else if (mask & OTGSC_BSVIE) {
+			cable->enabled = false;
+		}
+	}
+
+	cable = &ci->platdata->id_extcon;
+	if (!IS_ERR(cable->edev)) {
+		if (data & mask & OTGSC_IDIS)
+			cable->changed = false;
+
+		/* Don't enable id interrupt if using external notifier */
+		if (data & mask & OTGSC_IDIE) {
+			cable->enabled = true;
+			data &= ~OTGSC_IDIE;
+		} else if (mask & OTGSC_IDIE) {
+			cable->enabled = false;
+		}
+	}
+
 	hw_write(ci, OP_OTGSC, mask | OTGSC_INT_STATUS_BITS, data);
 }
 
diff --git a/include/linux/usb/chipidea.h b/include/linux/usb/chipidea.h
index 5dd75fa47dd8..f9be467d6695 100644
--- a/include/linux/usb/chipidea.h
+++ b/include/linux/usb/chipidea.h
@@ -14,6 +14,7 @@ struct ci_hdrc;
  * struct ci_hdrc_cable - structure for external connector cable state tracking
  * @state: current state of the line
  * @changed: set to true when extcon event happen
+ * @enabled: set to true if we've enabled the vbus or id interrupt
  * @edev: device which generate events
  * @ci: driver state of the chipidea device
  * @nb: hold event notification callback
@@ -22,6 +23,7 @@ struct ci_hdrc;
 struct ci_hdrc_cable {
 	bool				state;
 	bool				changed;
+	bool				enabled;
 	struct extcon_dev		*edev;
 	struct ci_hdrc			*ci;
 	struct notifier_block		nb;
-- 
2.9.0.rc2.8.ga28705d

[toc] | [prev] | [next] | [standalone]

#1432707 — Re: [PATCH 05/21] usb: chipidea: Handle extcon events properly

On Sun, Jun 26, 2016 at 12:28:22AM -0700, Stephen Boyd wrote:
> We're currently emulating the vbus and id interrupts in the OTGSC
> read API, but we also need to make sure that if we're handling
> the events with extcon that we don't enable the interrupts for
> those events in the hardware. Therefore, properly emulate this
> register if we're using extcon, but don't enable the interrupts.
> This allows me to get my cable connect/disconnect working
> properly without getting spurious interrupts on my device that
> uses an extcon for these two events.
> 
> Cc: Peter Chen <peter.chen@nxp.com>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: "Ivan T. Ivanov" <iivanov.xz@gmail.com>
> Fixes: 3ecb3e09b042 ("usb: chipidea: Use extcon framework for VBUS and ID detect")
> Signed-off-by: Stephen Boyd <stephen.boyd@linaro.org>
> ---
>  drivers/usb/chipidea/otg.c   | 46 +++++++++++++++++++++++++++++++++++++++-----
>  include/linux/usb/chipidea.h |  2 ++
>  2 files changed, 43 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/usb/chipidea/otg.c b/drivers/usb/chipidea/otg.c
> index 763a8332b009..b6a88bea4cac 100644
> --- a/drivers/usb/chipidea/otg.c
> +++ b/drivers/usb/chipidea/otg.c
> @@ -44,12 +44,15 @@ u32 hw_read_otgsc(struct ci_hdrc *ci, u32 mask)
>  		else
>  			val &= ~OTGSC_BSVIS;
>  
> -		cable->changed = false;
> -
>  		if (cable->state)
>  			val |= OTGSC_BSV;
>  		else
>  			val &= ~OTGSC_BSV;
> +
> +		if (cable->enabled)
> +			val |= OTGSC_BSVIE;
> +		else
> +			val &= ~OTGSC_BSVIE;
>  	}
>  
>  	cable = &ci->platdata->id_extcon;
> @@ -59,15 +62,18 @@ u32 hw_read_otgsc(struct ci_hdrc *ci, u32 mask)
>  		else
>  			val &= ~OTGSC_IDIS;
>  
> -		cable->changed = false;
> -
>  		if (cable->state)
>  			val |= OTGSC_ID;
>  		else
>  			val &= ~OTGSC_ID;
> +
> +		if (cable->enabled)
> +			val |= OTGSC_IDIE;
> +		else
> +			val &= ~OTGSC_IDIE;
>  	}
>  
> -	return val;
> +	return val & mask;
>  }
>  
>  /**
> @@ -77,6 +83,36 @@ u32 hw_read_otgsc(struct ci_hdrc *ci, u32 mask)
>   */
>  void hw_write_otgsc(struct ci_hdrc *ci, u32 mask, u32 data)
>  {
> +	struct ci_hdrc_cable *cable;
> +
> +	cable = &ci->platdata->vbus_extcon;
> +	if (!IS_ERR(cable->edev)) {
> +		if (data & mask & OTGSC_BSVIS)
> +			cable->changed = false;
> +
> +		/* Don't enable vbus interrupt if using external notifier */
> +		if (data & mask & OTGSC_BSVIE) {
> +			cable->enabled = true;
> +			data &= ~OTGSC_BSVIE;
> +		} else if (mask & OTGSC_BSVIE) {
> +			cable->enabled = false;
> +		}
> +	}
> +
> +	cable = &ci->platdata->id_extcon;
> +	if (!IS_ERR(cable->edev)) {
> +		if (data & mask & OTGSC_IDIS)
> +			cable->changed = false;
> +
> +		/* Don't enable id interrupt if using external notifier */
> +		if (data & mask & OTGSC_IDIE) {
> +			cable->enabled = true;
> +			data &= ~OTGSC_IDIE;
> +		} else if (mask & OTGSC_IDIE) {
> +			cable->enabled = false;
> +		}
> +	}
> +
>  	hw_write(ci, OP_OTGSC, mask | OTGSC_INT_STATUS_BITS, data);
>  }
>  
> diff --git a/include/linux/usb/chipidea.h b/include/linux/usb/chipidea.h
> index 5dd75fa47dd8..f9be467d6695 100644
> --- a/include/linux/usb/chipidea.h
> +++ b/include/linux/usb/chipidea.h
> @@ -14,6 +14,7 @@ struct ci_hdrc;
>   * struct ci_hdrc_cable - structure for external connector cable state tracking
>   * @state: current state of the line
>   * @changed: set to true when extcon event happen
> + * @enabled: set to true if we've enabled the vbus or id interrupt
>   * @edev: device which generate events
>   * @ci: driver state of the chipidea device
>   * @nb: hold event notification callback
> @@ -22,6 +23,7 @@ struct ci_hdrc;
>  struct ci_hdrc_cable {
>  	bool				state;
>  	bool				changed;
> +	bool				enabled;
>  	struct extcon_dev		*edev;
>  	struct ci_hdrc			*ci;
>  	struct notifier_block		nb;
> -- 

Acked-by: Peter Chen <peter.chen@nxp.com>

-- 

Best Regards,
Peter Chen

[toc] | [prev] | [next] | [standalone]

#1431367 — [PATCH 08/21] usb: chipidea: Kick OTG state machine for AVVIS with vbus extcon

Force the OTG state machine to go forward when we're using an
extcon for vbus detection. In this case, the controller may never
raise an interrupt for AVVIS, so we need to simulate the event by
toggling the appropriate OTG fsm bits and kicking the state
machine again.

Cc: Peter Chen <peter.chen@nxp.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Stephen Boyd <stephen.boyd@linaro.org>
---
 drivers/usb/chipidea/otg_fsm.c | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)

diff --git a/drivers/usb/chipidea/otg_fsm.c b/drivers/usb/chipidea/otg_fsm.c
index de8e22ec3902..aab076fc4d82 100644
--- a/drivers/usb/chipidea/otg_fsm.c
+++ b/drivers/usb/chipidea/otg_fsm.c
@@ -475,6 +475,14 @@ static void ci_otg_drv_vbus(struct otg_fsm *fsm, int on)
 				return;
 			}
 		}
+		/*
+		 * Force state machine forward if we use extcon
+		 * to detect vbus state (i.e. simulate AVVIS event)
+		 */
+		if (!IS_ERR(ci->platdata->vbus_extcon.edev)) {
+			fsm->a_vbus_vld = 1;
+			ci_otg_queue_work(ci);
+		}
 		/* Disable data pulse irq */
 		hw_write_otgsc(ci, OTGSC_DPIE, 0);
 
@@ -486,6 +494,15 @@ static void ci_otg_drv_vbus(struct otg_fsm *fsm, int on)
 
 		fsm->a_bus_drop = 1;
 		fsm->a_bus_req = 0;
+		/*
+		 * Force state machine forward if we use extcon
+		 * to detect vbus state (i.e. simulate AVVIS event)
+		 */
+		if (!IS_ERR(ci->platdata->vbus_extcon.edev)) {
+			fsm->a_vbus_vld = 0;
+			fsm->b_conn = 0;
+			ci_otg_queue_work(ci);
+		}
 	}
 }
 
-- 
2.9.0.rc2.8.ga28705d

[toc] | [prev] | [next] | [standalone]

#1433417 — Re: [PATCH 08/21] usb: chipidea: Kick OTG state machine for AVVIS with vbus extcon

On Sun, Jun 26, 2016 at 12:28:25AM -0700, Stephen Boyd wrote:
> Force the OTG state machine to go forward when we're using an
> extcon for vbus detection. In this case, the controller may never
> raise an interrupt for AVVIS, so we need to simulate the event by
> toggling the appropriate OTG fsm bits and kicking the state
> machine again.
> 

Well, I think you may misunderstand the OTG FSM and dual-role.
From my and Felipe's point, there are seldom users for USB FSM,
there are only OTG FSM spec and related OTG certification.

The OTG FSM needs related SoC support, the vbus will be off at
several states, and the SRP should be supported by SoC.

By default, the dts needs below properties for disabling it if you
choose otg fsm support at kernel configuration.

&usbotg1 {
	vbus-supply = <&reg_usb_otg1_vbus>;
	srp-disable;
	hnp-disable;
	adp-disable;
	status = "okay";
};

See Documentation/devicetree/bindings/usb/generic.txt.

Peter

> Cc: Peter Chen <peter.chen@nxp.com>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Signed-off-by: Stephen Boyd <stephen.boyd@linaro.org>
> ---
>  drivers/usb/chipidea/otg_fsm.c | 17 +++++++++++++++++
>  1 file changed, 17 insertions(+)
> 
> diff --git a/drivers/usb/chipidea/otg_fsm.c b/drivers/usb/chipidea/otg_fsm.c
> index de8e22ec3902..aab076fc4d82 100644
> --- a/drivers/usb/chipidea/otg_fsm.c
> +++ b/drivers/usb/chipidea/otg_fsm.c
> @@ -475,6 +475,14 @@ static void ci_otg_drv_vbus(struct otg_fsm *fsm, int on)
>  				return;
>  			}
>  		}
> +		/*
> +		 * Force state machine forward if we use extcon
> +		 * to detect vbus state (i.e. simulate AVVIS event)
> +		 */
> +		if (!IS_ERR(ci->platdata->vbus_extcon.edev)) {
> +			fsm->a_vbus_vld = 1;
> +			ci_otg_queue_work(ci);
> +		}
>  		/* Disable data pulse irq */
>  		hw_write_otgsc(ci, OTGSC_DPIE, 0);
>  
> @@ -486,6 +494,15 @@ static void ci_otg_drv_vbus(struct otg_fsm *fsm, int on)
>  
>  		fsm->a_bus_drop = 1;
>  		fsm->a_bus_req = 0;
> +		/*
> +		 * Force state machine forward if we use extcon
> +		 * to detect vbus state (i.e. simulate AVVIS event)
> +		 */
> +		if (!IS_ERR(ci->platdata->vbus_extcon.edev)) {
> +			fsm->a_vbus_vld = 0;
> +			fsm->b_conn = 0;
> +			ci_otg_queue_work(ci);
> +		}
>  	}
>  }
>  
> -- 
> 2.9.0.rc2.8.ga28705d
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 

Best Regards,
Peter Chen

[toc] | [prev] | [next] | [standalone]

#1434149 — Re: [PATCH 08/21] usb: chipidea: Kick OTG state machine for AVVIS with vbus extcon

On Wed, Jun 29, 2016 at 06:19:59PM -0700, Stephen Boyd wrote:
> Quoting Peter Chen (2016-06-28 20:09:13)
> > On Sun, Jun 26, 2016 at 12:28:25AM -0700, Stephen Boyd wrote:
> > > Force the OTG state machine to go forward when we're using an
> > > extcon for vbus detection. In this case, the controller may never
> > > raise an interrupt for AVVIS, so we need to simulate the event by
> > > toggling the appropriate OTG fsm bits and kicking the state
> > > machine again.
> > > 
> > 
> > Well, I think you may misunderstand the OTG FSM and dual-role.
> > From my and Felipe's point, there are seldom users for USB FSM,
> > there are only OTG FSM spec and related OTG certification.
> 
> Probably yes.
> 
> > 
> > The OTG FSM needs related SoC support, the vbus will be off at
> > several states, and the SRP should be supported by SoC.
> > 
> > By default, the dts needs below properties for disabling it if you
> > choose otg fsm support at kernel configuration.
> > 
> > &usbotg1 {
> >         vbus-supply = <&reg_usb_otg1_vbus>;
> >         srp-disable;
> >         hnp-disable;
> >         adp-disable;
> >         status = "okay";
> > };
> > 
> > See Documentation/devicetree/bindings/usb/generic.txt.
> 
> Does this mean we should be setting all those properties if we're using
> an extcon for vbus and id?

It is not related to how we know vbus and id. If your controller is
otg-capable, and you don't want to enable OTG FSM (just want dual-role),
you should set them at dts since the zImage is multi-platforms, the
CONFIG_USB_OTG and CONFIG_USB_OTG_FSM may be chosen.

> I have noticed that vbus is powered off after
> some time when no device is connected and we're in A_HOST state because
> the timeout for a B device connection happens.

I think it is not you want, but it is OTG compliance.

-- 

Best Regards,
Peter Chen

[toc] | [prev] | [next] | [standalone]

#1434178 — RE: [PATCH 08/21] usb: chipidea: Kick OTG state machine for AVVIS with vbus extcon

Hi Stephen,

> -----Original Message-----
> From: linux-usb-owner@vger.kernel.org [mailto:linux-usb-
> owner@vger.kernel.org] On Behalf Of Peter Chen
> Sent: Thursday, June 30, 2016 9:27 AM
> To: Stephen Boyd <stephen.boyd@linaro.org>
> Cc: linux-usb@vger.kernel.org; linux-arm-kernel@lists.infradead.org;
> linux-kernel@vger.kernel.org; linux-arm-msm@vger.kernel.org; Andy Gross
> <andy.gross@linaro.org>; Bjorn Andersson <bjorn.andersson@linaro.org>;
> Neil Armstrong <narmstrong@baylibre.com>; Arnd Bergmann <arnd@arndb.de>;
> Felipe Balbi <balbi@kernel.org>; Peter Chen <peter.chen@nxp.com>; Greg
> Kroah-Hartman <gregkh@linuxfoundation.org>
> Subject: Re: [PATCH 08/21] usb: chipidea: Kick OTG state machine for AVVIS
> with vbus extcon
> 
> On Wed, Jun 29, 2016 at 06:19:59PM -0700, Stephen Boyd wrote:
> > Quoting Peter Chen (2016-06-28 20:09:13)
> > > On Sun, Jun 26, 2016 at 12:28:25AM -0700, Stephen Boyd wrote:
> > > > Force the OTG state machine to go forward when we're using an
> > > > extcon for vbus detection. In this case, the controller may never
> > > > raise an interrupt for AVVIS, so we need to simulate the event by
> > > > toggling the appropriate OTG fsm bits and kicking the state
> > > > machine again.
> > > >
> > >
> > > Well, I think you may misunderstand the OTG FSM and dual-role.
> > > From my and Felipe's point, there are seldom users for USB FSM,
> > > there are only OTG FSM spec and related OTG certification.
> >
> > Probably yes.
> >
> > >
> > > The OTG FSM needs related SoC support, the vbus will be off at
> > > several states, and the SRP should be supported by SoC.
> > >
> > > By default, the dts needs below properties for disabling it if you
> > > choose otg fsm support at kernel configuration.
> > >
> > > &usbotg1 {
> > >         vbus-supply = <&reg_usb_otg1_vbus>;
> > >         srp-disable;
> > >         hnp-disable;
> > >         adp-disable;
> > >         status = "okay";
> > > };
> > >
> > > See Documentation/devicetree/bindings/usb/generic.txt.
> >
> > Does this mean we should be setting all those properties if we're
> > using an extcon for vbus and id?
> 
> It is not related to how we know vbus and id. If your controller is otg-
> capable, and you don't want to enable OTG FSM (just want dual-role), you
> should set them at dts since the zImage is multi-platforms, the
> CONFIG_USB_OTG and CONFIG_USB_OTG_FSM may be chosen.
> 
> > I have noticed that vbus is powered off after some time when no device
> > is connected and we're in A_HOST state because the timeout for a B
> > device connection happens.
> 
> I think it is not you want, but it is OTG compliance.

For simple, if you don't want OTG(i.e HNP&SRP) at all, just needs
dual role, you may disable CONFIG_USB_OTG and CONFIG_USB_OTG_FSM
in your menuconfig, then you don't need touch all those properties.

Li Jun

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

[toc] | [prev] | [next] | [standalone]

#1431368 — [PATCH 18/21] usb: chipidea: msm: Add reset controller for PHY POR bit

The MSM chipidea wrapper has two bits that are used to reset the
first or second phy. Add support for these bits via the reset
controller framework, so that phy drivers can reset their
hardware at the right time during initialization.

Cc: Peter Chen <peter.chen@nxp.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Stephen Boyd <stephen.boyd@linaro.org>
---
 drivers/usb/chipidea/ci_hdrc_msm.c | 43 +++++++++++++++++++++++++++++++++++++-
 1 file changed, 42 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/chipidea/ci_hdrc_msm.c b/drivers/usb/chipidea/ci_hdrc_msm.c
index fb4340f02c16..7d191928e55b 100644
--- a/drivers/usb/chipidea/ci_hdrc_msm.c
+++ b/drivers/usb/chipidea/ci_hdrc_msm.c
@@ -14,14 +14,17 @@
 #include <linux/mfd/syscon.h>
 #include <linux/regmap.h>
 #include <linux/io.h>
+#include <linux/reset-controller.h>
 #include <linux/extcon.h>
 #include <linux/of.h>
 
 #include "ci.h"
 
 #define HS_PHY_AHB_MODE			0x0098
+#define HS_PHY_CTRL			0x0240
 #define HS_PHY_SEC_CTRL			0x0278
 # define HS_PHY_DIG_CLAMP_N		BIT(16)
+# define HS_PHY_POR_ASSERT		BIT(0)
 
 #define HS_PHY_GENCONFIG		0x009c
 # define HS_PHY_TXFIFO_IDLE_FORCE_DIS	BIT(4)
@@ -38,11 +41,38 @@ struct ci_hdrc_msm {
 	struct clk *iface_clk;
 	struct extcon_dev *vbus_edev;
 	struct ci_hdrc_platform_data pdata;
+	struct reset_controller_dev rcdev;
 	bool secondary_phy;
 	bool hsic;
 	void __iomem *base;
 };
 
+static int
+ci_hdrc_msm_por_reset(struct reset_controller_dev *r, unsigned long id)
+{
+	struct ci_hdrc_msm *ci_msm = container_of(r, struct ci_hdrc_msm, rcdev);
+	void __iomem *addr = ci_msm->base;
+	u32 val;
+
+	if (id)
+		addr += HS_PHY_SEC_CTRL;
+	else
+		addr += HS_PHY_CTRL;
+
+	val = readl_relaxed(addr);
+	val |= HS_PHY_POR_ASSERT;
+	writel_relaxed(val, addr);
+	udelay(12);
+	val &= ~HS_PHY_POR_ASSERT;
+	writel(val, addr);
+
+	return 0;
+}
+
+static const struct reset_control_ops ci_hdrc_msm_reset_ops = {
+	.reset = ci_hdrc_msm_por_reset,
+};
+
 static void ci_hdrc_msm_notify_event(struct ci_hdrc *ci, unsigned event)
 {
 	struct device *dev = ci->dev->parent;
@@ -176,13 +206,21 @@ static int ci_hdrc_msm_probe(struct platform_device *pdev)
 		ci->vbus_edev = NULL;
 	}
 
+	ci->rcdev.owner = THIS_MODULE;
+	ci->rcdev.ops = &ci_hdrc_msm_reset_ops;
+	ci->rcdev.of_node = pdev->dev.of_node;
+	ci->rcdev.nr_resets = 2;
+	ret = reset_controller_register(&ci->rcdev);
+	if (ret)
+		return ret;
+
 	reset_control_assert(reset);
 	usleep_range(10000, 12000);
 	reset_control_deassert(reset);
 
 	ret = clk_prepare_enable(ci->core_clk);
 	if (ret)
-		return ret;
+		goto err_core;
 
 	ret = clk_prepare_enable(ci->iface_clk);
 	if (ret)
@@ -220,6 +258,8 @@ err_mux:
 	clk_disable_unprepare(ci->iface_clk);
 err_iface:
 	clk_disable_unprepare(ci->core_clk);
+err_core:
+	reset_controller_unregister(&ci->rcdev);
 	return ret;
 }
 
@@ -232,6 +272,7 @@ static int ci_hdrc_msm_remove(struct platform_device *pdev)
 	ci_hdrc_remove_device(ci->ci);
 	clk_disable_unprepare(ci->iface_clk);
 	clk_disable_unprepare(ci->core_clk);
+	reset_controller_unregister(&ci->rcdev);
 
 	return 0;
 }
-- 
2.9.0.rc2.8.ga28705d

[toc] | [prev] | [next] | [standalone]

#1431697 — Re: [PATCH 18/21] usb: chipidea: msm: Add reset controller for PHY POR bit

[Multipart message — attachments visible in raw view] — view raw

Hi,

[auto build test ERROR on peter.chen-usb/ci-for-usb-next]
[also build test ERROR on v4.7-rc5 next-20160624]
[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/Stephen-Boyd/Support-qcom-s-HSIC-USB-and-rewrite-USB2-HS-phy-support/20160627-102637
base:   https://git.kernel.org/pub/scm/linux/kernel/git/peter.chen/usb ci-for-usb-next
config: x86_64-acpi-redef (attached as .config)
compiler: gcc-6 (Debian 6.1.1-1) 6.1.1 20160430
reproduce:
        # save the attached .config to linux build tree
        make ARCH=x86_64 

All errors (new ones prefixed by >>):

   drivers/built-in.o: In function `ci_hdrc_msm_remove':
>> ci_hdrc_msm.c:(.text+0x4fffd2): undefined reference to `reset_controller_unregister'

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

[toc] | [prev] | [next] | [standalone]

#1431715 — Re: [PATCH 18/21] usb: chipidea: msm: Add reset controller for PHY POR bit

[Multipart message — attachments visible in raw view] — view raw

Hi,

[auto build test ERROR on peter.chen-usb/ci-for-usb-next]
[also build test ERROR on v4.7-rc5 next-20160624]
[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/Stephen-Boyd/Support-qcom-s-HSIC-USB-and-rewrite-USB2-HS-phy-support/20160627-102637
base:   https://git.kernel.org/pub/scm/linux/kernel/git/peter.chen/usb ci-for-usb-next
config: arm-multi_v5_defconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 5.3.1-8) 5.3.1 20160205
reproduce:
        wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # save the attached .config to linux build tree
        make.cross ARCH=arm 

All errors (new ones prefixed by >>):

   drivers/built-in.o: In function `ci_hdrc_msm_remove':
>> drivers/usb/chipidea/ci_hdrc_msm.c:275: undefined reference to `reset_controller_unregister'

vim +275 drivers/usb/chipidea/ci_hdrc_msm.c

   269	
   270		pm_runtime_put(&pdev->dev);
   271		pm_runtime_disable(&pdev->dev);
   272		ci_hdrc_remove_device(ci->ci);
   273		clk_disable_unprepare(ci->iface_clk);
   274		clk_disable_unprepare(ci->core_clk);
 > 275		reset_controller_unregister(&ci->rcdev);
   276	
   277		return 0;
   278	}

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

[toc] | [prev] | [next] | [standalone]

#1431792 — Re: [PATCH 18/21] usb: chipidea: msm: Add reset controller for PHY POR bit

[Multipart message — attachments visible in raw view] — view raw

Hi,

[auto build test ERROR on peter.chen-usb/ci-for-usb-next]
[also build test ERROR on v4.7-rc5 next-20160624]
[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/Stephen-Boyd/Support-qcom-s-HSIC-USB-and-rewrite-USB2-HS-phy-support/20160627-102637
base:   https://git.kernel.org/pub/scm/linux/kernel/git/peter.chen/usb ci-for-usb-next
config: x86_64-randconfig-s5-06271251 (attached as .config)
compiler: gcc-6 (Debian 6.1.1-1) 6.1.1 20160430
reproduce:
        # save the attached .config to linux build tree
        make ARCH=x86_64 

All errors (new ones prefixed by >>):

>> ERROR: "reset_controller_unregister" [drivers/usb/chipidea/ci_hdrc_msm.ko] undefined!

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

[toc] | [prev] | [next] | [standalone]

#1433696 — Re: [PATCH 18/21] usb: chipidea: msm: Add reset controller for PHY POR bit

On Sun, Jun 26, 2016 at 12:28:35AM -0700, Stephen Boyd wrote:
> The MSM chipidea wrapper has two bits that are used to reset the
> first or second phy. Add support for these bits via the reset
> controller framework, so that phy drivers can reset their
> hardware at the right time during initialization.
> 
> Cc: Peter Chen <peter.chen@nxp.com>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Signed-off-by: Stephen Boyd <stephen.boyd@linaro.org>
> ---
>  drivers/usb/chipidea/ci_hdrc_msm.c | 43 +++++++++++++++++++++++++++++++++++++-
>  1 file changed, 42 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/usb/chipidea/ci_hdrc_msm.c b/drivers/usb/chipidea/ci_hdrc_msm.c
> index fb4340f02c16..7d191928e55b 100644
> --- a/drivers/usb/chipidea/ci_hdrc_msm.c
> +++ b/drivers/usb/chipidea/ci_hdrc_msm.c
> @@ -14,14 +14,17 @@
>  #include <linux/mfd/syscon.h>
>  #include <linux/regmap.h>
>  #include <linux/io.h>
> +#include <linux/reset-controller.h>
>  #include <linux/extcon.h>
>  #include <linux/of.h>
>  
>  #include "ci.h"
>  
>  #define HS_PHY_AHB_MODE			0x0098
> +#define HS_PHY_CTRL			0x0240
>  #define HS_PHY_SEC_CTRL			0x0278
>  # define HS_PHY_DIG_CLAMP_N		BIT(16)
> +# define HS_PHY_POR_ASSERT		BIT(0)
>  
>  #define HS_PHY_GENCONFIG		0x009c
>  # define HS_PHY_TXFIFO_IDLE_FORCE_DIS	BIT(4)
> @@ -38,11 +41,38 @@ struct ci_hdrc_msm {
>  	struct clk *iface_clk;
>  	struct extcon_dev *vbus_edev;
>  	struct ci_hdrc_platform_data pdata;
> +	struct reset_controller_dev rcdev;
>  	bool secondary_phy;
>  	bool hsic;
>  	void __iomem *base;
>  };
>  
> +static int
> +ci_hdrc_msm_por_reset(struct reset_controller_dev *r, unsigned long id)
> +{
> +	struct ci_hdrc_msm *ci_msm = container_of(r, struct ci_hdrc_msm, rcdev);
> +	void __iomem *addr = ci_msm->base;

Like I mentioned at previous email, you can use vendor base for
0x200.

> +	u32 val;
> +
> +	if (id)
> +		addr += HS_PHY_SEC_CTRL;
> +	else
> +		addr += HS_PHY_CTRL;
> +
> +	val = readl_relaxed(addr);
> +	val |= HS_PHY_POR_ASSERT;
> +	writel_relaxed(val, addr);
> +	udelay(12);
> +	val &= ~HS_PHY_POR_ASSERT;
> +	writel(val, addr);
> +
> +	return 0;
> +}
> +
> +static const struct reset_control_ops ci_hdrc_msm_reset_ops = {
> +	.reset = ci_hdrc_msm_por_reset,
> +};
> +
>  static void ci_hdrc_msm_notify_event(struct ci_hdrc *ci, unsigned event)
>  {
>  	struct device *dev = ci->dev->parent;
> @@ -176,13 +206,21 @@ static int ci_hdrc_msm_probe(struct platform_device *pdev)
>  		ci->vbus_edev = NULL;
>  	}
>  
> +	ci->rcdev.owner = THIS_MODULE;
> +	ci->rcdev.ops = &ci_hdrc_msm_reset_ops;
> +	ci->rcdev.of_node = pdev->dev.of_node;
> +	ci->rcdev.nr_resets = 2;
> +	ret = reset_controller_register(&ci->rcdev);
> +	if (ret)
> +		return ret;
> +
>  	reset_control_assert(reset);
>  	usleep_range(10000, 12000);
>  	reset_control_deassert(reset);
>  
>  	ret = clk_prepare_enable(ci->core_clk);
>  	if (ret)
> -		return ret;
> +		goto err_core;
>  
>  	ret = clk_prepare_enable(ci->iface_clk);
>  	if (ret)
> @@ -220,6 +258,8 @@ err_mux:
>  	clk_disable_unprepare(ci->iface_clk);
>  err_iface:
>  	clk_disable_unprepare(ci->core_clk);
> +err_core:
> +	reset_controller_unregister(&ci->rcdev);
>  	return ret;
>  }
>  
> @@ -232,6 +272,7 @@ static int ci_hdrc_msm_remove(struct platform_device *pdev)
>  	ci_hdrc_remove_device(ci->ci);
>  	clk_disable_unprepare(ci->iface_clk);
>  	clk_disable_unprepare(ci->core_clk);
> +	reset_controller_unregister(&ci->rcdev);
>  
>  	return 0;
>  }
> -- 
> 2.9.0.rc2.8.ga28705d
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 

Best Regards,
Peter Chen

[toc] | [prev] | [next] | [standalone]

#1431369 — [PATCH 02/21] usb: ulpi: Support device discovery via DT

The qcom HSIC ulpi phy doesn't have any bits set in the vendor or
product id ulpi registers. This makes it impossible to make a
ulpi driver match against the id registers. Add support to
discover the ulpi phys via DT to help alleviate this problem.
We'll look for a ulpi bus node underneath the device registering
the ulpi viewport (or the parent of that device to support
chipidea's device layout) and then match up the phy node
underneath that with the ulpi device that's created.

The side benefit of this is that we can use standard DT
properties in the phy node like clks, regulators, gpios, etc.
because we don't have firmware like ACPI to turn these things on
for us. And we can use the DT phy binding to point our phy
consumer to the phy provider.

Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Cc: <devicetree@vger.kernel.org>
Cc: Rob Herring <robh+dt@kernel.org>
Signed-off-by: Stephen Boyd <stephen.boyd@linaro.org>
---
 Documentation/devicetree/bindings/usb/ulpi.txt | 20 +++++++++
 drivers/usb/common/ulpi.c                      | 56 +++++++++++++++++++++++++-
 2 files changed, 74 insertions(+), 2 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/usb/ulpi.txt

diff --git a/Documentation/devicetree/bindings/usb/ulpi.txt b/Documentation/devicetree/bindings/usb/ulpi.txt
new file mode 100644
index 000000000000..ca179dc4bd50
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/ulpi.txt
@@ -0,0 +1,20 @@
+ULPI bus binding
+----------------
+
+Phys that are behind a ULPI connection can be described with the following
+binding. The host controller shall have a "ulpi" named node as a child, and
+that node shall have one enabled node underneath it representing the ulpi
+device on the bus.
+
+EXAMPLE
+-------
+
+usb {
+	compatible = "vendor,usb-controller";
+
+	ulpi {
+		phy {
+			compatible = "vendor,phy";
+		};
+	};
+};
diff --git a/drivers/usb/common/ulpi.c b/drivers/usb/common/ulpi.c
index 01c0c0477a9e..980af672bfe3 100644
--- a/drivers/usb/common/ulpi.c
+++ b/drivers/usb/common/ulpi.c
@@ -16,6 +16,9 @@
 #include <linux/module.h>
 #include <linux/slab.h>
 #include <linux/acpi.h>
+#include <linux/of.h>
+#include <linux/of_device.h>
+#include <linux/clk/clk-conf.h>
 
 /* -------------------------------------------------------------------------- */
 
@@ -39,7 +42,10 @@ static int ulpi_match(struct device *dev, struct device_driver *driver)
 	struct ulpi *ulpi = to_ulpi_dev(dev);
 	const struct ulpi_device_id *id;
 
-	for (id = drv->id_table; id->vendor; id++)
+	if (of_driver_match_device(dev, driver))
+		return 1;
+
+	for (id = drv->id_table; id && id->vendor; id++)
 		if (id->vendor == ulpi->id.vendor &&
 		    id->product == ulpi->id.product)
 			return 1;
@@ -50,6 +56,11 @@ static int ulpi_match(struct device *dev, struct device_driver *driver)
 static int ulpi_uevent(struct device *dev, struct kobj_uevent_env *env)
 {
 	struct ulpi *ulpi = to_ulpi_dev(dev);
+	int ret;
+
+	ret = of_device_uevent_modalias(dev, env);
+	if (ret != -ENODEV)
+		return ret;
 
 	if (add_uevent_var(env, "MODALIAS=ulpi:v%04xp%04x",
 			   ulpi->id.vendor, ulpi->id.product))
@@ -60,6 +71,11 @@ static int ulpi_uevent(struct device *dev, struct kobj_uevent_env *env)
 static int ulpi_probe(struct device *dev)
 {
 	struct ulpi_driver *drv = to_ulpi_driver(dev->driver);
+	int ret;
+
+	ret = of_clk_set_defaults(dev->of_node, false);
+	if (ret < 0)
+		return ret;
 
 	return drv->probe(to_ulpi_dev(dev));
 }
@@ -87,8 +103,13 @@ static struct bus_type ulpi_bus = {
 static ssize_t modalias_show(struct device *dev, struct device_attribute *attr,
 			     char *buf)
 {
+	int len;
 	struct ulpi *ulpi = to_ulpi_dev(dev);
 
+	len = of_device_get_modalias(dev, buf, PAGE_SIZE - 1);
+	if (len != -ENODEV)
+		return len;
+
 	return sprintf(buf, "ulpi:v%04xp%04x\n",
 		       ulpi->id.vendor, ulpi->id.product);
 }
@@ -152,6 +173,28 @@ EXPORT_SYMBOL_GPL(ulpi_unregister_driver);
 
 /* -------------------------------------------------------------------------- */
 
+static int ulpi_of_register(struct ulpi *ulpi)
+{
+	struct device_node *np = NULL, *child;
+
+	/* Find a ulpi bus underneath the parent or the parent of the parent */
+	if (ulpi->dev.parent->of_node)
+		np = of_find_node_by_name(ulpi->dev.parent->of_node, "ulpi");
+	else if (ulpi->dev.parent->parent &&
+		 ulpi->dev.parent->parent->of_node)
+		np = of_find_node_by_name(ulpi->dev.parent->parent->of_node, "ulpi");
+	if (!np)
+		return 0;
+
+	child = of_get_next_available_child(np, NULL);
+	if (!child)
+		return -EINVAL;
+
+	ulpi->dev.of_node = child;
+
+	return 0;
+}
+
 static int ulpi_register(struct device *dev, struct ulpi *ulpi)
 {
 	int ret;
@@ -181,7 +224,15 @@ static int ulpi_register(struct device *dev, struct ulpi *ulpi)
 
 	ACPI_COMPANION_SET(&ulpi->dev, ACPI_COMPANION(dev));
 
-	request_module("ulpi:v%04xp%04x", ulpi->id.vendor, ulpi->id.product);
+	if (IS_ENABLED(CONFIG_OF)) {
+		ret = ulpi_of_register(ulpi);
+		if (ret)
+			return ret;
+	}
+
+	if (of_device_request_module(&ulpi->dev))
+		request_module("ulpi:v%04xp%04x", ulpi->id.vendor,
+			       ulpi->id.product);
 
 	ret = device_register(&ulpi->dev);
 	if (ret)
@@ -232,6 +283,7 @@ EXPORT_SYMBOL_GPL(ulpi_register_interface);
  */
 void ulpi_unregister_interface(struct ulpi *ulpi)
 {
+	of_node_put(ulpi->dev.of_node);
 	device_unregister(&ulpi->dev);
 }
 EXPORT_SYMBOL_GPL(ulpi_unregister_interface);
-- 
2.9.0.rc2.8.ga28705d

[toc] | [prev] | [next] | [standalone]

#1431702 — Re: [PATCH 02/21] usb: ulpi: Support device discovery via DT

[Multipart message — attachments visible in raw view] — view raw

Hi,

[auto build test ERROR on peter.chen-usb/ci-for-usb-next]
[also build test ERROR on v4.7-rc5 next-20160624]
[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/Stephen-Boyd/Support-qcom-s-HSIC-USB-and-rewrite-USB2-HS-phy-support/20160627-102637
base:   https://git.kernel.org/pub/scm/linux/kernel/git/peter.chen/usb ci-for-usb-next
config: x86_64-randconfig-h0-06270614 (attached as .config)
compiler: gcc-6 (Debian 6.1.1-1) 6.1.1 20160430
reproduce:
        # save the attached .config to linux build tree
        make ARCH=x86_64 

All errors (new ones prefixed by >>):

>> ERROR: "of_device_request_module" [drivers/usb/common/ulpi.ko] undefined!
>> ERROR: "of_device_get_modalias" [drivers/usb/common/ulpi.ko] undefined!
>> ERROR: "of_device_uevent_modalias" [drivers/usb/common/ulpi.ko] undefined!

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

[toc] | [prev] | [next] | [standalone]

#1432089 — Re: [PATCH 02/21] usb: ulpi: Support device discovery via DT

Hi,

I'm fine with most of the patch, except..

On Sun, Jun 26, 2016 at 12:28:19AM -0700, Stephen Boyd wrote:
> @@ -39,7 +42,10 @@ static int ulpi_match(struct device *dev, struct device_driver *driver)
>  	struct ulpi *ulpi = to_ulpi_dev(dev);
>  	const struct ulpi_device_id *id;
>  
> -	for (id = drv->id_table; id->vendor; id++)
> +	if (of_driver_match_device(dev, driver))
> +		return 1;

I don't like this part. We should match separately like that only
if the bus does not support native enumeration, and of course ULPI
with its vendor and product IDs does. There really should always be
IDs to match with here. So exceptions have to be solved before we
attempt matching.

Since we also have to support platforms where the PHY is initially
powered off and reading the IDs from the registers is not possible
because of that, I think we should consider getting the product and
vendor IDs optionally from device properties. Something like this:


diff --git a/drivers/usb/common/ulpi.c b/drivers/usb/common/ulpi.c
index 01c0c04..6228a85 100644
--- a/drivers/usb/common/ulpi.c
+++ b/drivers/usb/common/ulpi.c
@@ -152,7 +152,7 @@ EXPORT_SYMBOL_GPL(ulpi_unregister_driver);
 
 /* -------------------------------------------------------------------------- */
 
-static int ulpi_register(struct device *dev, struct ulpi *ulpi)
+static int ulpi_read_id(struct ulpi *ulpi)
 {
        int ret;
 
@@ -174,6 +174,21 @@ static int ulpi_register(struct device *dev, struct ulpi *ulpi)
        ulpi->id.product = ulpi_read(ulpi, ULPI_PRODUCT_ID_LOW);
        ulpi->id.product |= ulpi_read(ulpi, ULPI_PRODUCT_ID_HIGH) << 8;
 
+       return 0;
+}
+
+static int ulpi_register(struct device *dev, struct ulpi *ulpi)
+{
+       int ret;
+
+       ret = device_property_read_u16(dev, "ulpi-vendor", &ulpi->id.vendor);
+       ret |= device_property_read_u16(dev, "ulpi-product", &ulpi->id.product);
+       if (ret) {
+               ret = ulpi_read_id(ulpi);
+               if (ret)
+                       return ret;
+       }
+
        ulpi->dev.parent = dev;
        ulpi->dev.bus = &ulpi_bus;
        ulpi->dev.type = &ulpi_dev_type;


That should cover both cases. You would just have to create the IDs
yourself in this case.


Thanks,

-- 
heikki

[toc] | [prev] | [next] | [standalone]

#1432910 — Re: [PATCH 02/21] usb: ulpi: Support device discovery via DT

On Mon, Jun 27, 2016 at 03:10:40PM -0700, Stephen Boyd wrote:
> Quoting Heikki Krogerus (2016-06-27 07:34:22)
> > Hi,
> > 
> > I'm fine with most of the patch, except..
> > 
> > On Sun, Jun 26, 2016 at 12:28:19AM -0700, Stephen Boyd wrote:
> > > @@ -39,7 +42,10 @@ static int ulpi_match(struct device *dev, struct device_driver *driver)
> > >       struct ulpi *ulpi = to_ulpi_dev(dev);
> > >       const struct ulpi_device_id *id;
> > >  
> > > -     for (id = drv->id_table; id->vendor; id++)
> > > +     if (of_driver_match_device(dev, driver))
> > > +             return 1;
> > 
> > I don't like this part. We should match separately like that only
> > if the bus does not support native enumeration, and of course ULPI
> > with its vendor and product IDs does. There really should always be
> > IDs to match with here. So exceptions have to be solved before we
> > attempt matching.
> > 
> > Since we also have to support platforms where the PHY is initially
> > powered off and reading the IDs from the registers is not possible
> > because of that, I think we should consider getting the product and
> > vendor IDs optionally from device properties. Something like this:
> 
> Ok, I'm a little worried about conflating the powered off problem with
> this product/vendor ID missing problem. But if you're ok with that I'll
> combine the two patches into one using your approach below.
> 
> > 
> > 
> > diff --git a/drivers/usb/common/ulpi.c b/drivers/usb/common/ulpi.c
> > index 01c0c04..6228a85 100644
> > --- a/drivers/usb/common/ulpi.c
> > +++ b/drivers/usb/common/ulpi.c
> > @@ -152,7 +152,7 @@ EXPORT_SYMBOL_GPL(ulpi_unregister_driver);
> >  
> >  /* -------------------------------------------------------------------------- */
> >  
> > -static int ulpi_register(struct device *dev, struct ulpi *ulpi)
> > +static int ulpi_read_id(struct ulpi *ulpi)
> >  {
> >         int ret;
> >  
> > @@ -174,6 +174,21 @@ static int ulpi_register(struct device *dev, struct ulpi *ulpi)
> >         ulpi->id.product = ulpi_read(ulpi, ULPI_PRODUCT_ID_LOW);
> >         ulpi->id.product |= ulpi_read(ulpi, ULPI_PRODUCT_ID_HIGH) << 8;
> >  
> > +       return 0;
> > +}
> > +
> > +static int ulpi_register(struct device *dev, struct ulpi *ulpi)
> > +{
> > +       int ret;
> > +
> > +       ret = device_property_read_u16(dev, "ulpi-vendor", &ulpi->id.vendor);
> > +       ret |= device_property_read_u16(dev, "ulpi-product", &ulpi->id.product);
> > +       if (ret) {
> > +               ret = ulpi_read_id(ulpi);
> > +               if (ret)
> > +                       return ret;
> > +       }
> > +
> >         ulpi->dev.parent = dev;
> >         ulpi->dev.bus = &ulpi_bus;
> >         ulpi->dev.type = &ulpi_dev_type;
> > 
> > 
> > That should cover both cases. You would just have to create the IDs
> > yourself in this case.
> > 
> 
> Right, I would have to make up some IDs in this case. I suppose I can
> use the qcom vendor ID 0x05c6 and then product ids 0 and 1 for HS phy
> and HSIC phy? That doesn't make me feel great because it's all made up,
> but I guess there's no other option. I hope they don't decide to start
> populating these ids in the future though and then we may have
> conflicting product ids. If that happens I suppose we can do a
> workaround based on compatible strings in the DT node. Fun!
> 
> Nice side effect of all that is I can drop requesting the module by DT
> aliases and things become simpler. I'll try this out.

I was hoping that we could manage with product id 0 as an exception (I
failed to consider that you have multiple PHYs to deal with). I don't
think we can just come up with product id > 0.

I guess we should have the of_driver_match_device() call after all.
Let's just call it conditionally, only in cases where there is no
product ID, to make me feel a bit more better. I don't want to make it
too easy to use.

The properties for the vendor and product ID are still something that
we need to introduce in any case. We have the powered off problem on
all kinds of platforms, and not all of them use DT. Please feel free
to incorporate the diff into the patch you had for the powered off
case if you are OK with it. So I think in your case you would just
need to addthe correct ulpi-vendor id 0x05c6 and ulpi-product id 0 to
the chipidea device node, and I think this would work.

Sorry about the hassle.


Thanks,

-- 
heikki

[toc] | [prev] | [next] | [standalone]

#1433404 — Re: [PATCH 02/21] usb: ulpi: Support device discovery via DT

On Tue, Jun 28, 2016 at 02:42:05PM +0300, Heikki Krogerus wrote:
> On Mon, Jun 27, 2016 at 03:10:40PM -0700, Stephen Boyd wrote:
> > Quoting Heikki Krogerus (2016-06-27 07:34:22)
> > > Hi,
> > > 
> > > I'm fine with most of the patch, except..
> > > 
> > > On Sun, Jun 26, 2016 at 12:28:19AM -0700, Stephen Boyd wrote:
> > > > @@ -39,7 +42,10 @@ static int ulpi_match(struct device *dev, struct device_driver *driver)
> > > >       struct ulpi *ulpi = to_ulpi_dev(dev);
> > > >       const struct ulpi_device_id *id;
> > > >  
> > > > -     for (id = drv->id_table; id->vendor; id++)
> > > > +     if (of_driver_match_device(dev, driver))
> > > > +             return 1;
> > > 
> > > I don't like this part. We should match separately like that only
> > > if the bus does not support native enumeration, and of course ULPI
> > > with its vendor and product IDs does. There really should always be
> > > IDs to match with here. So exceptions have to be solved before we
> > > attempt matching.
> > > 
> > > Since we also have to support platforms where the PHY is initially
> > > powered off and reading the IDs from the registers is not possible
> > > because of that, I think we should consider getting the product and
> > > vendor IDs optionally from device properties. Something like this:
> > 
> > Ok, I'm a little worried about conflating the powered off problem with
> > this product/vendor ID missing problem. But if you're ok with that I'll
> > combine the two patches into one using your approach below.
> > 
> > > 
> > > 
> > > diff --git a/drivers/usb/common/ulpi.c b/drivers/usb/common/ulpi.c
> > > index 01c0c04..6228a85 100644
> > > --- a/drivers/usb/common/ulpi.c
> > > +++ b/drivers/usb/common/ulpi.c
> > > @@ -152,7 +152,7 @@ EXPORT_SYMBOL_GPL(ulpi_unregister_driver);
> > >  
> > >  /* -------------------------------------------------------------------------- */
> > >  
> > > -static int ulpi_register(struct device *dev, struct ulpi *ulpi)
> > > +static int ulpi_read_id(struct ulpi *ulpi)
> > >  {
> > >         int ret;
> > >  
> > > @@ -174,6 +174,21 @@ static int ulpi_register(struct device *dev, struct ulpi *ulpi)
> > >         ulpi->id.product = ulpi_read(ulpi, ULPI_PRODUCT_ID_LOW);
> > >         ulpi->id.product |= ulpi_read(ulpi, ULPI_PRODUCT_ID_HIGH) << 8;
> > >  
> > > +       return 0;
> > > +}
> > > +
> > > +static int ulpi_register(struct device *dev, struct ulpi *ulpi)
> > > +{
> > > +       int ret;
> > > +
> > > +       ret = device_property_read_u16(dev, "ulpi-vendor", &ulpi->id.vendor);
> > > +       ret |= device_property_read_u16(dev, "ulpi-product", &ulpi->id.product);
> > > +       if (ret) {
> > > +               ret = ulpi_read_id(ulpi);
> > > +               if (ret)
> > > +                       return ret;
> > > +       }
> > > +
> > >         ulpi->dev.parent = dev;
> > >         ulpi->dev.bus = &ulpi_bus;
> > >         ulpi->dev.type = &ulpi_dev_type;
> > > 
> > > 
> > > That should cover both cases. You would just have to create the IDs
> > > yourself in this case.
> > > 
> > 
> > Right, I would have to make up some IDs in this case. I suppose I can
> > use the qcom vendor ID 0x05c6 and then product ids 0 and 1 for HS phy
> > and HSIC phy? That doesn't make me feel great because it's all made up,
> > but I guess there's no other option. I hope they don't decide to start
> > populating these ids in the future though and then we may have
> > conflicting product ids. If that happens I suppose we can do a
> > workaround based on compatible strings in the DT node. Fun!
> > 
> > Nice side effect of all that is I can drop requesting the module by DT
> > aliases and things become simpler. I'll try this out.
> 
> I was hoping that we could manage with product id 0 as an exception (I
> failed to consider that you have multiple PHYs to deal with). I don't
> think we can just come up with product id > 0.
> 
> I guess we should have the of_driver_match_device() call after all.
> Let's just call it conditionally, only in cases where there is no
> product ID, to make me feel a bit more better. I don't want to make it
> too easy to use.
> 
> The properties for the vendor and product ID are still something that
> we need to introduce in any case. We have the powered off problem on
> all kinds of platforms, and not all of them use DT.

I am thinking power sequence framework, how power sequence elements
(eg, clock, reset-gpios) can get for non-DT platform? Does ACPI does power
sequence for x86 platforms?

-- 

Best Regards,
Peter Chen

[toc] | [prev] | [next] | [standalone]

#1433297 — Re: [PATCH 02/21] usb: ulpi: Support device discovery via DT

On Sun, Jun 26, 2016 at 12:28:19AM -0700, Stephen Boyd wrote:
> The qcom HSIC ulpi phy doesn't have any bits set in the vendor or
> product id ulpi registers. This makes it impossible to make a
> ulpi driver match against the id registers. Add support to
> discover the ulpi phys via DT to help alleviate this problem.
> We'll look for a ulpi bus node underneath the device registering
> the ulpi viewport (or the parent of that device to support
> chipidea's device layout) and then match up the phy node
> underneath that with the ulpi device that's created.
> 
> The side benefit of this is that we can use standard DT
> properties in the phy node like clks, regulators, gpios, etc.
> because we don't have firmware like ACPI to turn these things on
> for us. And we can use the DT phy binding to point our phy
> consumer to the phy provider.
> 
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Heikki Krogerus <heikki.krogerus@linux.intel.com>
> Cc: <devicetree@vger.kernel.org>
> Cc: Rob Herring <robh+dt@kernel.org>
> Signed-off-by: Stephen Boyd <stephen.boyd@linaro.org>
> ---
>  Documentation/devicetree/bindings/usb/ulpi.txt | 20 +++++++++
>  drivers/usb/common/ulpi.c                      | 56 +++++++++++++++++++++++++-
>  2 files changed, 74 insertions(+), 2 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/usb/ulpi.txt
> 
> diff --git a/Documentation/devicetree/bindings/usb/ulpi.txt b/Documentation/devicetree/bindings/usb/ulpi.txt
> new file mode 100644
> index 000000000000..ca179dc4bd50
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/usb/ulpi.txt
> @@ -0,0 +1,20 @@
> +ULPI bus binding
> +----------------
> +
> +Phys that are behind a ULPI connection can be described with the following
> +binding. The host controller shall have a "ulpi" named node as a child, and
> +that node shall have one enabled node underneath it representing the ulpi
> +device on the bus.

This needs to co-exist with the USB bus binding which has the controller 
ports for the child nodes. Maybe use the phy binding?

> +
> +EXAMPLE
> +-------
> +
> +usb {
> +	compatible = "vendor,usb-controller";
> +
> +	ulpi {
> +		phy {
> +			compatible = "vendor,phy";
> +		};
> +	};
> +};

[toc] | [prev] | [next] | [standalone]

#1434941 — Re: [PATCH 02/21] usb: ulpi: Support device discovery via DT

On Tue, Jun 28, 2016 at 03:09:21PM -0700, Stephen Boyd wrote:
> Quoting Rob Herring (2016-06-28 13:56:42)
> > On Sun, Jun 26, 2016 at 12:28:19AM -0700, Stephen Boyd wrote:
> > > The qcom HSIC ulpi phy doesn't have any bits set in the vendor or
> > > product id ulpi registers. This makes it impossible to make a
> > > ulpi driver match against the id registers. Add support to
> > > discover the ulpi phys via DT to help alleviate this problem.
> > > We'll look for a ulpi bus node underneath the device registering
> > > the ulpi viewport (or the parent of that device to support
> > > chipidea's device layout) and then match up the phy node
> > > underneath that with the ulpi device that's created.
> > > 
> > > The side benefit of this is that we can use standard DT
> > > properties in the phy node like clks, regulators, gpios, etc.
> > > because we don't have firmware like ACPI to turn these things on
> > > for us. And we can use the DT phy binding to point our phy
> > > consumer to the phy provider.
> > > 
> > > Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > > Cc: Heikki Krogerus <heikki.krogerus@linux.intel.com>
> > > Cc: <devicetree@vger.kernel.org>
> > > Cc: Rob Herring <robh+dt@kernel.org>
> > > Signed-off-by: Stephen Boyd <stephen.boyd@linaro.org>
> > > ---
> > >  Documentation/devicetree/bindings/usb/ulpi.txt | 20 +++++++++
> > >  drivers/usb/common/ulpi.c                      | 56 +++++++++++++++++++++++++-
> > >  2 files changed, 74 insertions(+), 2 deletions(-)
> > >  create mode 100644 Documentation/devicetree/bindings/usb/ulpi.txt
> > > 
> > > diff --git a/Documentation/devicetree/bindings/usb/ulpi.txt b/Documentation/devicetree/bindings/usb/ulpi.txt
> > > new file mode 100644
> > > index 000000000000..ca179dc4bd50
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/usb/ulpi.txt
> > > @@ -0,0 +1,20 @@
> > > +ULPI bus binding
> > > +----------------
> > > +
> > > +Phys that are behind a ULPI connection can be described with the following
> > > +binding. The host controller shall have a "ulpi" named node as a child, and
> > > +that node shall have one enabled node underneath it representing the ulpi
> > > +device on the bus.
> > 
> > This needs to co-exist with the USB bus binding which has the controller 
> > ports for the child nodes. Maybe use the phy binding?
> 
> Which binding is that? bindings/usb/usb-device.txt? 

Yes.

> This ulpi binding is
> to describe phys that are accessed through the ulpi "viewport" in the
> usb controller. So controller ports don't come into the picture here.

You just need to confirm that there's no collision with child nodes like 
it assumes all children are ports.

Rob

[toc] | [prev] | [next] | [standalone]

#1431370 — [PATCH 15/21] usb: chipidea: msm: Mux over secondary phy at the right time

We need to pick the correct phy at runtime based on how the SoC
has been wired onto the board. If the secondary phy is used, take
it out of reset and mux over to it by writing into the TCSR
register. Make sure to do this on reset too, because this
register is reset to the default value (primary phy) after the
RESET bit is set in USBCMD.

Cc: Peter Chen <peter.chen@nxp.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Stephen Boyd <stephen.boyd@linaro.org>
---
 drivers/usb/chipidea/ci_hdrc_msm.c | 78 +++++++++++++++++++++++++++++++++++---
 1 file changed, 73 insertions(+), 5 deletions(-)

diff --git a/drivers/usb/chipidea/ci_hdrc_msm.c b/drivers/usb/chipidea/ci_hdrc_msm.c
index 40249b0e3e93..df0f8b31db4f 100644
--- a/drivers/usb/chipidea/ci_hdrc_msm.c
+++ b/drivers/usb/chipidea/ci_hdrc_msm.c
@@ -8,30 +8,40 @@
 #include <linux/module.h>
 #include <linux/platform_device.h>
 #include <linux/pm_runtime.h>
-#include <linux/usb/gadget.h>
 #include <linux/usb/chipidea.h>
 #include <linux/clk.h>
 #include <linux/reset.h>
+#include <linux/mfd/syscon.h>
+#include <linux/regmap.h>
+#include <linux/io.h>
 
 #include "ci.h"
 
 #define HS_PHY_AHB_MODE			0x0098
+#define HS_PHY_SEC_CTRL			0x0278
+# define HS_PHY_DIG_CLAMP_N		BIT(16)
 
 struct ci_hdrc_msm {
 	struct platform_device *ci;
 	struct clk *core_clk;
 	struct clk *iface_clk;
+	bool secondary_phy;
+	void __iomem *base;
 };
 
 static void ci_hdrc_msm_notify_event(struct ci_hdrc *ci, unsigned event)
 {
-	struct device *dev = ci->gadget.dev.parent;
+	struct device *dev = ci->dev->parent;
+	struct ci_hdrc_msm *msm_ci = dev_get_drvdata(dev);
 
 	switch (event) {
 	case CI_HDRC_CONTROLLER_RESET_EVENT:
 		dev_dbg(dev, "CI_HDRC_CONTROLLER_RESET_EVENT received\n");
 		/* use AHB transactor, allow posted data writes */
 		hw_write_id_reg(ci, HS_PHY_AHB_MODE, 0xffffffff, 0x8);
+		if (msm_ci->secondary_phy)
+			hw_write_id_reg(ci, HS_PHY_SEC_CTRL, HS_PHY_DIG_CLAMP_N,
+					HS_PHY_DIG_CLAMP_N);
 		break;
 	default:
 		dev_dbg(dev, "unknown ci_hdrc event\n");
@@ -49,12 +59,58 @@ static struct ci_hdrc_platform_data ci_hdrc_msm_platdata = {
 	.notify_event		= ci_hdrc_msm_notify_event,
 };
 
+static int ci_hdrc_msm_mux_phy(struct ci_hdrc_msm *ci,
+			       struct platform_device *pdev)
+{
+	struct regmap *regmap;
+	struct device_node *syscon;
+	struct device *dev = &pdev->dev;
+	u32 off, val;
+	int ret;
+
+	syscon = of_parse_phandle(dev->of_node, "phy-select", 0);
+	if (!syscon)
+		return 0;
+
+	regmap = syscon_node_to_regmap(syscon);
+	if (IS_ERR(regmap))
+		return PTR_ERR(regmap);
+
+	ret = of_property_read_u32_index(dev->of_node, "phy-select", 1, &off);
+	if (ret < 0) {
+		dev_err(dev, "no offset in syscon\n");
+		return -EINVAL;
+	}
+
+	ret = of_property_read_u32_index(dev->of_node, "phy-select", 2, &val);
+	if (ret < 0) {
+		dev_err(dev, "no value in syscon\n");
+		return -EINVAL;
+	}
+
+	ret = regmap_write(regmap, off, val);
+	if (ret)
+		return ret;
+
+	ci->secondary_phy = !!val;
+	if (ci->secondary_phy) {
+		val = readl_relaxed(ci->base + HS_PHY_SEC_CTRL);
+		val |= HS_PHY_DIG_CLAMP_N;
+		writel_relaxed(val, ci->base + HS_PHY_SEC_CTRL);
+	}
+
+	return 0;
+}
+
 static int ci_hdrc_msm_probe(struct platform_device *pdev)
 {
 	struct ci_hdrc_msm *ci;
 	struct platform_device *plat_ci;
 	struct clk *clk;
 	struct reset_control *reset;
+	struct resource *res;
+	void __iomem *base;
+	resource_size_t size;
 	int ret;
 
 	dev_dbg(&pdev->dev, "ci_hdrc_msm_probe\n");
@@ -76,6 +132,15 @@ static int ci_hdrc_msm_probe(struct platform_device *pdev)
 	if (IS_ERR(clk))
 		return PTR_ERR(clk);
 
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	if (!res)
+		return -ENODEV;
+
+	size = resource_size(res);
+	ci->base = base = devm_ioremap(&pdev->dev, res->start, size);
+	if (!base)
+		return -ENOMEM;
+
 	reset_control_assert(reset);
 	usleep_range(10000, 12000);
 	reset_control_deassert(reset);
@@ -88,9 +153,12 @@ static int ci_hdrc_msm_probe(struct platform_device *pdev)
 	if (ret)
 		goto err_iface;
 
-	plat_ci = ci_hdrc_add_device(&pdev->dev,
-				pdev->resource, pdev->num_resources,
-				&ci_hdrc_msm_platdata);
+	ret = ci_hdrc_msm_mux_phy(ci, pdev);
+	if (ret)
+		goto err_mux;
+
+	plat_ci = ci_hdrc_add_device(&pdev->dev, pdev->resource,
+				     pdev->num_resources, &ci_hdrc_msm_platdata);
 	if (IS_ERR(plat_ci)) {
 		dev_err(&pdev->dev, "ci_hdrc_add_device failed!\n");
 		ret = PTR_ERR(plat_ci);
-- 
2.9.0.rc2.8.ga28705d

[toc] | [prev] | [next] | [standalone]

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

Back to top | Article view | linux.kernel

csiph-web