Re: usb typec not doing handling in-kernel

[Heiko Stuebner]

Hi,

Am Mittwoch, 15. August 2018, 16:46:36 CEST schrieb Heikki Krogerus:
> On Tue, Aug 14, 2018 at 03:58:31PM +0200, Heiko Stuebner wrote:
> > Am Montag, 13. August 2018, 15:36:37 CEST schrieb Heikki Krogerus:
> > > On Mon, Aug 13, 2018 at 12:36:55PM +0200, Heiko Stuebner wrote:ß
> > > > I'm currently trying to wrap my head around the new typec subsystem and
> > > > also how to do it correctly on Rockchip rk3399 devices.
> > > > 
> > > > The issue (and Guenter might know quite a bit about that) is that on
> > > > ChromeOS devices the embedded controller hides the whole tcpm/vdm
> > > > logic from the operating system and just provides a custom interface to
> > > > query things like cable state, display-port hotplug status and so on.
> > > > 
> > > > So right now the rk3399-typec-phy uses that extcon-based interface to
> > > > get all status changes but that of course leaves out all systems 
> > > > directly
> > > > talking to a fusb302. I did a small drawing to showcase that:
> > > > 
> > > > ---
> > > > | typec-phy || extcon-cros-ec |\
> > > > --- \
> > > >  |\  \
> > > > -  \ --   \ ---
> > > > |  cdn-dp   |   \| ?  |-| fusb302 |
> > > > --- ---
> > > > 
> > > > So to bring everything on the same page, I guess the cros-ec extcon
> > > > (drivers/extcon/extcon-usbc-cros-ec.c) should somehow use the typec
> > > > functions instead of implementing an extcon?
> > > 
> > > I don't think the two necessary exclude each other. You can continue
> > > to register the extcon device and use it for communication with the
> > > phy driver, and also register your Type-C port(s), partners, and
> > > optionally the port and partner alternate modes. I guess Guenter has
> > > patches for that already?
> > 
> > The issue is less with the working ChromeOS devices :-) .
> > 
> > What I'm trying to fit in there are all the other boards directly talking
> > to a fusb302 via i2c and needing to do all these negotiations.
> 
> Ah, OK. Now I get it.
> 
> > So the rockchip typec phy would need to handle both cases. In the Rockchip
> > vendor kernel they bolted the extcon export onto their fusb302 driver
> > but I don't think that is really future proof ;-) .
> > 
> > Hence the easiest way would probably be to have everything use the newer
> > typec APIs and not try to make the Rockchip typec-phy handle both cases.
> > 
> > 
> > And looking at Guenters mail, it seems like he had the same idea as well
> > in the past, so I'll hope for his archeology-skills :-) .
> > 
> > 
> > > It looks to me like that phy driver could just register a Type-C
> > > switch for the orientation, and mux for the mode. Those seem to be the
> > > only details the driver needs from extcon-usbc-cros-ec.
> > 
> > Looks like it - I'm still trying to find my way through the typec subsystem
> > though.
> > 
> > > > But from reading into the typec code, it somehow looks like the
> > > > typec framework expects to be in control of things like altmode
> > > > negotiations, or am I misreading something?
> > > 
> > > The alternate mode drivers will assume they are in control of the
> > > negotiation with the partner, but note that you will not always need
> > > them. The rest of the code in the framework doesn't expect to be in
> > > control of the communication.
> > > 
> > > If the EC (or some other microcontroller) firmware is taking care of
> > > the actual entering and configuring of the alternate modes, the port
> > > driver (so extcon-usbc-cros-ec in your case) will need to "emulate"
> > > the VDM communication if the alt mode drivers need to be used, and
> > > that means they need to do so with every supported alternate mode
> > > separately.
> > > 
> > > Of course if the details that for example the DisplayPort alt mode
> > > driver supplies to the user space is not relevant on your system, and
> > > there is no requirement to allow the user to be able to reconfigure
> > > the DisplayPort alt mode (note: you will also be unable to exit the
> > > mode from sysfs in this case), you can still register the partner alt
> > > mode device and simply

Re: [PATCH 0/3] add dwc2 support for px30

[Heiko Stuebner]

Am Donnerstag, 2. August 2018, 15:01:30 CEST schrieb Heiko Stuebner:
> This is split out from the series adding the px30 support, due to
> the dwc2 binding change not having landed yet in a maintainer tree.
> 
> The Acked binding change should go through some usb tree, while
> I'll pick up the dts changes once that has happened.
> 
> The binding itself is unchanged.
> 
> 
> Heiko Stuebner (2):
>   arm64: dts: rockchip: add dwc2 otg controller on px30
>   arm64: dts: rockchip: enable dwc2-based otg controller on px30-evb
> 
> Liang Chen (1):
>   dt-bindings: usb: dwc2: add description for px30

applied all 3 patches for 4.20 now.

Re: usb typec not doing handling in-kernel

[Heiko Stuebner]

Hi Guenter,

Am Montag, 13. August 2018, 14:29:15 CEST schrieb Guenter Roeck:
> On 08/13/2018 03:36 AM, Heiko Stuebner wrote:
> > Hi,
> > 
> > I'm currently trying to wrap my head around the new typec subsystem and
> > also how to do it correctly on Rockchip rk3399 devices.
> > 
> > The issue (and Guenter might know quite a bit about that) is that on
> > ChromeOS devices the embedded controller hides the whole tcpm/vdm
> > logic from the operating system and just provides a custom interface to
> > query things like cable state, display-port hotplug status and so on.
> > 
> > So right now the rk3399-typec-phy uses that extcon-based interface to
> > get all status changes but that of course leaves out all systems directly
> > talking to a fusb302. I did a small drawing to showcase that:
> > 
> > ---
> > | typec-phy || extcon-cros-ec |\
> > --- \
> >   |\  \
> > -  \ --   \ ---
> > |  cdn-dp   |   \| ?  |-| fusb302 |
> > --- ---
> > 
> > So to bring everything on the same page, I guess the cros-ec extcon
> > (drivers/extcon/extcon-usbc-cros-ec.c) should somehow use the typec
> > functions instead of implementing an extcon? But from reading into the
> > typec code, it somehow looks like the typec framework expects to be in
> > control of things like altmode negotiations, or am I misreading something?
> > 
> I used to have a patch for the cros-ec extcon driver which ties it into the
> typec subsystem. Let me see if I can dig it up.

were your archeological skills working in finding said old patch?

Thanks
Heiko

Re: [PATCH 1/3] dt-bindings: usb: dwc2: add description for px30

[Heiko Stuebner]

Hi Greg, Felipe,

Am Donnerstag, 2. August 2018, 15:01:31 CEST schrieb Heiko Stuebner:
> From: Liang Chen 
> 
> This patch adds the compatible of dwc2 for PX30 SoCs.
> 
> Signed-off-by: Liang Chen 
> Acked-by: Rob Herring 
> Signed-off-by: Heiko Stuebner 

Do you want to pick that patch through one of the usb trees, or should
I just apply it with the arm64 devicetree-patches?


Thanks
Heiko


> unchanged from it being part of the general px30 series
> 
>  Documentation/devicetree/bindings/usb/dwc2.txt | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/Documentation/devicetree/bindings/usb/dwc2.txt 
> b/Documentation/devicetree/bindings/usb/dwc2.txt
> index 46da5f184460..6dc3c4a34483 100644
> --- a/Documentation/devicetree/bindings/usb/dwc2.txt
> +++ b/Documentation/devicetree/bindings/usb/dwc2.txt
> @@ -6,6 +6,7 @@ Required properties:
>- brcm,bcm2835-usb: The DWC2 USB controller instance in the BCM2835 SoC.
>- hisilicon,hi6220-usb: The DWC2 USB controller instance in the hi6220 SoC.
>- rockchip,rk3066-usb: The DWC2 USB controller instance in the rk3066 Soc;
> +  - "rockchip,px30-usb", "rockchip,rk3066-usb", "snps,dwc2": for px30 Soc;
>- "rockchip,rk3188-usb", "rockchip,rk3066-usb", "snps,dwc2": for rk3188 
> Soc;
>- "rockchip,rk3288-usb", "rockchip,rk3066-usb", "snps,dwc2": for rk3288 
> Soc;
>- "lantiq,arx100-usb": The DWC2 USB controller instance in Lantiq ARX SoCs;
> 

Re: usb typec not doing handling in-kernel

[Heiko Stuebner]

Hi Heikki,

Am Montag, 13. August 2018, 15:36:37 CEST schrieb Heikki Krogerus:
> On Mon, Aug 13, 2018 at 12:36:55PM +0200, Heiko Stuebner wrote:
> > I'm currently trying to wrap my head around the new typec subsystem and
> > also how to do it correctly on Rockchip rk3399 devices.
> > 
> > The issue (and Guenter might know quite a bit about that) is that on
> > ChromeOS devices the embedded controller hides the whole tcpm/vdm
> > logic from the operating system and just provides a custom interface to
> > query things like cable state, display-port hotplug status and so on.
> > 
> > So right now the rk3399-typec-phy uses that extcon-based interface to
> > get all status changes but that of course leaves out all systems directly
> > talking to a fusb302. I did a small drawing to showcase that:
> > 
> > ---
> > | typec-phy || extcon-cros-ec |\
> > --- \
> >  |\  \
> > -  \ --   \ ---
> > |  cdn-dp   |   \| ?  |-| fusb302 |
> > --- ---
> > 
> > So to bring everything on the same page, I guess the cros-ec extcon
> > (drivers/extcon/extcon-usbc-cros-ec.c) should somehow use the typec
> > functions instead of implementing an extcon?
> 
> I don't think the two necessary exclude each other. You can continue
> to register the extcon device and use it for communication with the
> phy driver, and also register your Type-C port(s), partners, and
> optionally the port and partner alternate modes. I guess Guenter has
> patches for that already?

The issue is less with the working ChromeOS devices :-) .

What I'm trying to fit in there are all the other boards directly talking
to a fusb302 via i2c and needing to do all these negotiations.

So the rockchip typec phy would need to handle both cases. In the Rockchip
vendor kernel they bolted the extcon export onto their fusb302 driver
but I don't think that is really future proof ;-) .

Hence the easiest way would probably be to have everything use the newer
typec APIs and not try to make the Rockchip typec-phy handle both cases.


And looking at Guenters mail, it seems like he had the same idea as well
in the past, so I'll hope for his archeology-skills :-) .


> It looks to me like that phy driver could just register a Type-C
> switch for the orientation, and mux for the mode. Those seem to be the
> only details the driver needs from extcon-usbc-cros-ec.

Looks like it - I'm still trying to find my way through the typec subsystem
though.

> > But from reading into the typec code, it somehow looks like the
> > typec framework expects to be in control of things like altmode
> > negotiations, or am I misreading something?
> 
> The alternate mode drivers will assume they are in control of the
> negotiation with the partner, but note that you will not always need
> them. The rest of the code in the framework doesn't expect to be in
> control of the communication.
> 
> If the EC (or some other microcontroller) firmware is taking care of
> the actual entering and configuring of the alternate modes, the port
> driver (so extcon-usbc-cros-ec in your case) will need to "emulate"
> the VDM communication if the alt mode drivers need to be used, and
> that means they need to do so with every supported alternate mode
> separately.
> 
> Of course if the details that for example the DisplayPort alt mode
> driver supplies to the user space is not relevant on your system, and
> there is no requirement to allow the user to be able to reconfigure
> the DisplayPort alt mode (note: you will also be unable to exit the
> mode from sysfs in this case), you can still register the partner alt
> mode device and simply allow the binding to the driver fail, or don't
> register the partner alt modes with the USB Type-C framework at all.

As said above, I'm mainly trying to make the typec framework usable
for all the rk3399 boards using the "standard" setup of talking directly
to the fusb302 but of course want to pull the cros-ec special case along,
to not create to much overhead anywhere.

Thankfully it is really only the DisplayPort Alt Mode that is supported
on the rk3399.

While the extcon driver doesn't seem to use it right now, looking through
the ec-commands shows that muxes, roles etc seem configurable from the
host side.


> I've prepared patches for the ucsi driver that add displayport alt
> mode support to it. UCSI is just a standardised firmware interface for
> USB Type-C conncetors, so the situation is exactly the same as with
> extcon-usbc-cros-ec. I was planning to send the patches out for review
> after next -rc1,

usb typec not doing handling in-kernel

[Heiko Stuebner]

Hi,

I'm currently trying to wrap my head around the new typec subsystem and
also how to do it correctly on Rockchip rk3399 devices.

The issue (and Guenter might know quite a bit about that) is that on
ChromeOS devices the embedded controller hides the whole tcpm/vdm
logic from the operating system and just provides a custom interface to
query things like cable state, display-port hotplug status and so on.

So right now the rk3399-typec-phy uses that extcon-based interface to
get all status changes but that of course leaves out all systems directly
talking to a fusb302. I did a small drawing to showcase that:

---
| typec-phy || extcon-cros-ec |\
--- \
 |\  \
-  \ --   \ ---
|  cdn-dp   |   \| ?  |-| fusb302 |
--- ---

So to bring everything on the same page, I guess the cros-ec extcon
(drivers/extcon/extcon-usbc-cros-ec.c) should somehow use the typec
functions instead of implementing an extcon? But from reading into the
typec code, it somehow looks like the typec framework expects to be in
control of things like altmode negotiations, or am I misreading something?


Thanks
Heiko

[PATCH 3/3] arm64: dts: rockchip: enable dwc2-based otg controller on px30-evb

[Heiko Stuebner]

Enable the newly added controller on the px30 evaluation board.

Signed-off-by: Heiko Stuebner 
---
 arch/arm64/boot/dts/rockchip/px30-evb.dts | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm64/boot/dts/rockchip/px30-evb.dts 
b/arch/arm64/boot/dts/rockchip/px30-evb.dts
index c74aa910a631..263d7f3dbc44 100644
--- a/arch/arm64/boot/dts/rockchip/px30-evb.dts
+++ b/arch/arm64/boot/dts/rockchip/px30-evb.dts
@@ -206,6 +206,10 @@
status = "okay";
 };
 
+_otg {
+   status = "okay";
+};
+
 _host0_ehci {
status = "okay";
 };
-- 
2.17.0

--
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 0/3] add dwc2 support for px30

[Heiko Stuebner]

This is split out from the series adding the px30 support, due to
the dwc2 binding change not having landed yet in a maintainer tree.

The Acked binding change should go through some usb tree, while
I'll pick up the dts changes once that has happened.

The binding itself is unchanged.


Heiko Stuebner (2):
  arm64: dts: rockchip: add dwc2 otg controller on px30
  arm64: dts: rockchip: enable dwc2-based otg controller on px30-evb

Liang Chen (1):
  dt-bindings: usb: dwc2: add description for px30

 Documentation/devicetree/bindings/usb/dwc2.txt |  1 +
 arch/arm64/boot/dts/rockchip/px30-evb.dts  |  4 
 arch/arm64/boot/dts/rockchip/px30.dtsi | 16 
 3 files changed, 21 insertions(+)

-- 
2.17.0

--
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/3] dt-bindings: usb: dwc2: add description for px30

[Heiko Stuebner]

From: Liang Chen 

This patch adds the compatible of dwc2 for PX30 SoCs.

Signed-off-by: Liang Chen 
Acked-by: Rob Herring 
Signed-off-by: Heiko Stuebner 
---
unchanged from it being part of the general px30 series

 Documentation/devicetree/bindings/usb/dwc2.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/usb/dwc2.txt 
b/Documentation/devicetree/bindings/usb/dwc2.txt
index 46da5f184460..6dc3c4a34483 100644
--- a/Documentation/devicetree/bindings/usb/dwc2.txt
+++ b/Documentation/devicetree/bindings/usb/dwc2.txt
@@ -6,6 +6,7 @@ Required properties:
   - brcm,bcm2835-usb: The DWC2 USB controller instance in the BCM2835 SoC.
   - hisilicon,hi6220-usb: The DWC2 USB controller instance in the hi6220 SoC.
   - rockchip,rk3066-usb: The DWC2 USB controller instance in the rk3066 Soc;
+  - "rockchip,px30-usb", "rockchip,rk3066-usb", "snps,dwc2": for px30 Soc;
   - "rockchip,rk3188-usb", "rockchip,rk3066-usb", "snps,dwc2": for rk3188 Soc;
   - "rockchip,rk3288-usb", "rockchip,rk3066-usb", "snps,dwc2": for rk3288 Soc;
   - "lantiq,arx100-usb": The DWC2 USB controller instance in Lantiq ARX SoCs;
-- 
2.17.0

--
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/3] arm64: dts: rockchip: add dwc2 otg controller on px30

[Heiko Stuebner]

Add the node for the dwc2-based otg controller on the px30 soc.

Signed-off-by: Heiko Stuebner 
---
 arch/arm64/boot/dts/rockchip/px30.dtsi | 16 
 1 file changed, 16 insertions(+)

diff --git a/arch/arm64/boot/dts/rockchip/px30.dtsi 
b/arch/arm64/boot/dts/rockchip/px30.dtsi
index dc3b22ca9a0e..fed782194a94 100644
--- a/arch/arm64/boot/dts/rockchip/px30.dtsi
+++ b/arch/arm64/boot/dts/rockchip/px30.dtsi
@@ -702,6 +702,22 @@
<1>, <2>;
};
 
+   usb20_otg: usb@ff30 {
+   compatible = "rockchip,px30-usb", "rockchip,rk3066-usb",
+"snps,dwc2";
+   reg = <0x0 0xff30 0x0 0x4>;
+   interrupts = ;
+   clocks = < HCLK_OTG>;
+   clock-names = "otg";
+   dr_mode = "otg";
+   g-np-tx-fifo-size = <16>;
+   g-rx-fifo-size = <280>;
+   g-tx-fifo-size = <256 128 128 64 32 16>;
+   g-use-dma;
+   power-domains = < PX30_PD_USB>;
+   status = "disabled";
+   };
+
usb_host0_ehci: usb@ff34 {
compatible = "generic-ehci";
reg = <0x0 0xff34 0x0 0x1>;
-- 
2.17.0

--
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/2] usb: dwc2: fix isoc split in transfer issue

[Heiko Stuebner]

Am Freitag, 11. Mai 2018, 11:46:30 CEST schrieb William Wu:
> This patch fix dma unaligned problem and data lost problem for
> isoc split in transfer.
> 
> Test on rk3288 platform, use an usb hs Hub (GL852G-12) and an usb
> fs audio device (Plantronics headset) to capture and playback.
> 
> William Wu (2):
>   usb: dwc2: alloc dma aligned buffer for isoc split in
>   usb: dwc2: fix isoc split in transfer with no data

On rk3036, rk3188, rk3288 and rk3328
Tested-by: Heiko Stuebner <he...@sntech.de>




--
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] usb: dwc2: dwc2_vbus_supply_init: fix error check

[Heiko Stuebner]

Am Montag, 26. März 2018, 11:00:01 CEST schrieb Tomeu Vizoso:
> devm_regulator_get_optional returns -ENODEV if the regulator isn't
> there, so if that's the case we have to make sure not to leave -ENODEV
> in the regulator pointer.
> 
> Also, make sure we return 0 in that case, but correctly propagate any
> other errors. Also propagate the error from _dwc2_hcd_start.
> 
> Fixes: 531ef5ebea96 ("usb: dwc2: add support for host mode external vbus 
> supply")
> Cc: Amelie Delaunay <amelie.delau...@st.com>
> Signed-off-by: Tomeu Vizoso <tomeu.viz...@collabora.com>

The patch that gets fixed here also breaks display-output on dwc2-based
Rockchip devices (likely even more), probably due to making the regulator
framework hickup.

With this patch applied, apart from not seeing the NULL-ptr, I also get
display output on my rk3288-veycron Chromebook again, so

Tested-by: Heiko Stuebner <he...@sntech.de>


> v2: Only overwrite the error in the pointer after checking it (Heiko
> Stübner <he...@sntech.de>)
> v3: Remove hunks that shouldn't be in this patch
> v4: Don't overwrite the error code before returning it (kbuild test
> robot <l...@intel.com>)
> ---
>  drivers/usb/dwc2/hcd.c | 13 -
>  1 file changed, 8 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/usb/dwc2/hcd.c b/drivers/usb/dwc2/hcd.c
> index 190f95964000..c51b73b3e048 100644
> --- a/drivers/usb/dwc2/hcd.c
> +++ b/drivers/usb/dwc2/hcd.c
> @@ -358,9 +358,14 @@ static void dwc2_gusbcfg_init(struct dwc2_hsotg *hsotg)
>  
>  static int dwc2_vbus_supply_init(struct dwc2_hsotg *hsotg)
>  {
> + int ret;
> +
>   hsotg->vbus_supply = devm_regulator_get_optional(hsotg->dev, "vbus");
> - if (IS_ERR(hsotg->vbus_supply))
> - return 0;
> + if (IS_ERR(hsotg->vbus_supply)) {
> + ret = PTR_ERR(hsotg->vbus_supply);
> + hsotg->vbus_supply = NULL;
> + return ret == -ENODEV ? 0 : ret;
> + }
>  
>   return regulator_enable(hsotg->vbus_supply);
>  }
> @@ -4342,9 +4347,7 @@ static int _dwc2_hcd_start(struct usb_hcd *hcd)
>  
>   spin_unlock_irqrestore(>lock, flags);
>  
> - dwc2_vbus_supply_init(hsotg);
> -
> - return 0;
> + return dwc2_vbus_supply_init(hsotg);
>  }
>  
>  /*
> 


--
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 1/4] dt-bindings: usb: add DT binding for RK3328 dwc3 controller

[Heiko Stuebner]

Am Montag, 4. Dezember 2017, 10:40:38 CET schrieb Heiko Stuebner:
> From: William Wu <william...@rock-chips.com>
> 
> Adds the device tree bindings description for RK3328 and
> compatible USB DWC3 controller.
> 
> Signed-off-by: William Wu <william...@rock-chips.com>
> Acked-by: Rob Herring <r...@kernel.org>
> Signed-off-by: Heiko Stuebner <he...@sntech.de>

applied all 4 with Felipe's Ack on patch1
--
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 1/4] dt-bindings: usb: add DT binding for RK3328 dwc3 controller

[Heiko Stuebner]

Hi Greg, Felipe,

Am Montag, 4. Dezember 2017, 10:40:38 CET schrieb Heiko Stuebner:
> From: William Wu <william...@rock-chips.com>
> 
> Adds the device tree bindings description for RK3328 and
> compatible USB DWC3 controller.
> 
> Signed-off-by: William Wu <william...@rock-chips.com>
> Acked-by: Rob Herring <r...@kernel.org>
> Signed-off-by: Heiko Stuebner <he...@sntech.de>

do you want to pick this patch with only the small dt-binding
change or Ack it for me to pick up together with the actual
devicetree changes in the other patches?


Thanks
Heiko

> ---
> changes in v2:
> - add Rob's Ack
> 
> Ideally usb maintainers would pick up this patch to the binding
> document and I'll take the devicetree changes after that.
> 
> But if so desired, I can also pick up the binding change myself
> but would need an Ack for that.
> 
>  Documentation/devicetree/bindings/usb/rockchip,dwc3.txt | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/devicetree/bindings/usb/rockchip,dwc3.txt 
> b/Documentation/devicetree/bindings/usb/rockchip,dwc3.txt
> index 50a31536e975..2c3f6a467fda 100644
> --- a/Documentation/devicetree/bindings/usb/rockchip,dwc3.txt
> +++ b/Documentation/devicetree/bindings/usb/rockchip,dwc3.txt
> @@ -1,7 +1,9 @@
>  Rockchip SuperSpeed DWC3 USB SoC controller
>  
>  Required properties:
> -- compatible:should contain "rockchip,rk3399-dwc3" for rk3399 SoC
> +- compatible:should be one of the following:
> +  - "rockchip,rk3399-dwc3": for rk3399 SoC
> +  - "rockchip,rk3328-dwc3", "rockchip,rk3399-dwc3": for rk3328 SoC
>  - clocks:A list of phandle + clock-specifier pairs for the
>   clocks listed in clock-names
>  - clock-names:   Should contain the following:
> 


--
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 1/4] dt-bindings: usb: add DT binding for RK3328 dwc3 controller

[Heiko Stuebner]

Am Montag, 4. Dezember 2017, 10:40:38 CET schrieb Heiko Stuebner:
> From: William Wu <william...@rock-chips.com>
> 
> Adds the device tree bindings description for RK3328 and
> compatible USB DWC3 controller.
> 
> Signed-off-by: William Wu <william...@rock-chips.com>
> Acked-by: Rob Herring <r...@kernel.org>
> Signed-off-by: Heiko Stuebner <he...@sntech.de>
> ---
> changes in v2:
> - add Rob's Ack
> 
> Ideally usb maintainers would pick up this patch to the binding
> document and I'll take the devicetree changes after that.
> 
> But if so desired, I can also pick up the binding change myself
> but would need an Ack for that.

just realized, the last version from august was actually v3, so this
should be v4, not v2 ... sorry about that.

Heiko
--
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] arm64: dts: rockchip: add usb3 controller node for RK3328 SoCs

[Heiko Stuebner]

From: William Wu <william...@rock-chips.com>

RK3328 has one USB 3.0 OTG controller which uses DWC_USB3
core's general architecture. It can act as static xHCI host
controller, static device controller, USB 3.0/2.0 OTG basing
on ID of USB3.0 PHY.

Signed-off-by: William Wu <william...@rock-chips.com>
Signed-off-by: Heiko Stuebner <he...@sntech.de>
---
changes in v2:
none

 arch/arm64/boot/dts/rockchip/rk3328.dtsi | 27 +++
 1 file changed, 27 insertions(+)

diff --git a/arch/arm64/boot/dts/rockchip/rk3328.dtsi 
b/arch/arm64/boot/dts/rockchip/rk3328.dtsi
index 41d61840fb99..cafc572a68e0 100644
--- a/arch/arm64/boot/dts/rockchip/rk3328.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3328.dtsi
@@ -805,6 +805,33 @@
status = "disabled";
};
 
+   usbdrd3: usb@ff60 {
+   compatible = "rockchip,rk3328-dwc3", "rockchip,rk3399-dwc3";
+   clocks = < SCLK_USB3OTG_REF>, < SCLK_USB3OTG_SUSPEND>,
+< ACLK_USB3OTG>;
+   clock-names = "ref_clk", "suspend_clk",
+ "bus_clk";
+   #address-cells = <2>;
+   #size-cells = <2>;
+   ranges;
+   status = "disabled";
+
+   usbdrd_dwc3: dwc3@ff60 {
+   compatible = "snps,dwc3";
+   reg = <0x0 0xff60 0x0 0x10>;
+   interrupts = ;
+   dr_mode = "otg";
+   phy_type = "utmi_wide";
+   snps,dis_enblslpm_quirk;
+   snps,dis-u2-freeclk-exists-quirk;
+   snps,dis_u2_susphy_quirk;
+   snps,dis_u3_susphy_quirk;
+   snps,dis-del-phy-power-chg-quirk;
+   snps,dis-tx-ipgap-linecheck-quirk;
+   status = "disabled";
+   };
+   };
+
gic: interrupt-controller@ff811000 {
compatible = "arm,gic-400";
#interrupt-cells = <3>;
-- 
2.14.2

--
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] arm64: dts: rockchip: enable usb3 for RK3328 evaluation board

[Heiko Stuebner]

From: William Wu <william...@rock-chips.com>

Rockchip's RK3328 evaluation board has one USB 3.0 OTG controller,
we enable it and set it act as static xHCI host controller to
support USB 3.0 HOST on RK3328 evaluation board.

Signed-off-by: William Wu <william...@rock-chips.com>
Signed-off-by: Heiko Stuebner <he...@sntech.de>
---
changes in v2:
none

 arch/arm64/boot/dts/rockchip/rk3328-evb.dts | 9 +
 1 file changed, 9 insertions(+)

diff --git a/arch/arm64/boot/dts/rockchip/rk3328-evb.dts 
b/arch/arm64/boot/dts/rockchip/rk3328-evb.dts
index 3d551e3e6c23..95fba84239a7 100644
--- a/arch/arm64/boot/dts/rockchip/rk3328-evb.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3328-evb.dts
@@ -306,3 +306,12 @@
 _host0_ohci {
status = "okay";
 };
+
+ {
+   status = "okay";
+};
+
+_dwc3 {
+   dr_mode = "host";
+   status = "okay";
+};
-- 
2.14.2

--
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 1/4] dt-bindings: usb: add DT binding for RK3328 dwc3 controller

[Heiko Stuebner]

From: William Wu <william...@rock-chips.com>

Adds the device tree bindings description for RK3328 and
compatible USB DWC3 controller.

Signed-off-by: William Wu <william...@rock-chips.com>
Acked-by: Rob Herring <r...@kernel.org>
Signed-off-by: Heiko Stuebner <he...@sntech.de>
---
changes in v2:
- add Rob's Ack

Ideally usb maintainers would pick up this patch to the binding
document and I'll take the devicetree changes after that.

But if so desired, I can also pick up the binding change myself
but would need an Ack for that.

 Documentation/devicetree/bindings/usb/rockchip,dwc3.txt | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/usb/rockchip,dwc3.txt 
b/Documentation/devicetree/bindings/usb/rockchip,dwc3.txt
index 50a31536e975..2c3f6a467fda 100644
--- a/Documentation/devicetree/bindings/usb/rockchip,dwc3.txt
+++ b/Documentation/devicetree/bindings/usb/rockchip,dwc3.txt
@@ -1,7 +1,9 @@
 Rockchip SuperSpeed DWC3 USB SoC controller
 
 Required properties:
-- compatible:  should contain "rockchip,rk3399-dwc3" for rk3399 SoC
+- compatible:  should be one of the following:
+  - "rockchip,rk3399-dwc3": for rk3399 SoC
+  - "rockchip,rk3328-dwc3", "rockchip,rk3399-dwc3": for rk3328 SoC
 - clocks:  A list of phandle + clock-specifier pairs for the
clocks listed in clock-names
 - clock-names: Should contain the following:
-- 
2.14.2

--
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] arm64: dts: rockchip: enable usb3 nodes on rk3328-rock64

[Heiko Stuebner]

Enable the nodes to make the usb3 port usable on that board.

Signed-off-by: Heiko Stuebner <he...@sntech.de>
---
changes in v2:
- new patch

 arch/arm64/boot/dts/rockchip/rk3328-rock64.dts | 9 +
 1 file changed, 9 insertions(+)

diff --git a/arch/arm64/boot/dts/rockchip/rk3328-rock64.dts 
b/arch/arm64/boot/dts/rockchip/rk3328-rock64.dts
index d4f80786e7c2..e393c3586c11 100644
--- a/arch/arm64/boot/dts/rockchip/rk3328-rock64.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3328-rock64.dts
@@ -331,3 +331,12 @@
 _host0_ohci {
status = "okay";
 };
+
+ {
+   status = "okay";
+};
+
+_dwc3 {
+   dr_mode = "host";
+   status = "okay";
+};
-- 
2.14.2

--
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: usb: dwc2: NMI watchdog: BUG: soft lockup - CPU#0 stuck for 146s

[Heiko Stuebner]

Hi Stefan,

Am Montag, 17. April 2017, 13:05:40 CEST schrieb Stefan Wahren:
> > Stefan Wahren  hat am 31. Oktober 2016 um 21:34 
> > geschrieben:
> > 
> > 
> > I inspired by this issue [1] i build up a slightly modified setup with a
> > Raspberry Pi B (mainline kernel 4.9rc3), a powered 7 port USB hub and 5 
> > Prolific
> > PL2303 USB to serial convertors. I modified the usb_test for dwc2 [2], which
> > only tries to open all ttyUSB devices one after the other. 
> > 
> > Unfortunately the complete system stuck after opening the first ttyUSB 
> > device (
> > heartbeat LED stop blinking, no reaction to debug UART). The only way to
> > reanimate the system is to powerdown the USB hub with the USB to serial
> > convertors.
> > 
> > [1] - https://github.com/raspberrypi/linux/issues/1692
> > [2] - https://gist.github.com/lategoodbye/dd0d30af27b6f101b03d5923b279dbaa
> 
> since this issue still exists with 4.11 (even without or with microframe 
> scheduler enabled), i want to ask some additional questions:
> 
> Is this issue reproducible with other dwc2 platforms than bcm2835?
> Does the soft lockup also occurs after opening the second serial convertor or 
> later?

A friend of mine uses a rk3288-veyron-jerry as work-device also with a
slightly interesting usb topology (multiple hubs, keyboard, mouse,
smartcard-reader and printer) but not usb-serial adapters.

On the 4.9 that is currently on there, the system sometimes locks up when
trying to print things, sadly there is no serial console on it and the lockup
also kills the whole ui and we haven't managed to dig deeper yet.
[cpufreq is set to 600MHz minimum to mitigate the worst dwc2 issues].


Heiko


> > 
> > pi@raspberrypi:~$ lsusb -t
> > /:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=dwc2/1p, 480M
> > |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/3p, 480M
> > |__ Port 1: Dev 3, If 0, Class=Vendor Specific Class, 
> > Driver=smsc95xx,
> > 480M
> > |__ Port 2: Dev 11, If 0, Class=Hub, Driver=hub/4p, 480M
> > |__ Port 3: Dev 15, If 0, Class=Vendor Specific Class,
> > Driver=pl2303, 12M
> > |__ Port 1: Dev 12, If 0, Class=Hub, Driver=hub/4p, 480M
> > |__ Port 2: Dev 14, If 0, Class=Vendor Specific Class,
> > Driver=pl2303, 12M
> > |__ Port 3: Dev 16, If 0, Class=Vendor Specific Class,
> > Driver=pl2303, 12M
> > |__ Port 4: Dev 17, If 0, Class=Vendor Specific Class,
> > Driver=pl2303, 12M
> > |__ Port 2: Dev 13, If 0, Class=Vendor Specific Class,
> > Driver=pl2303, 12M
> > 
> > pi@raspberrypi:~$ ./usb_test
> > idle
> > opening [/dev/ttyUSB0] ok
> > [  232.658768] NMI watchdog: BUG: soft lockup - CPU#0 stuck for 146s!
> > [usb_test:522]
> > [  232.678443] Modules linked in: pwm_bcm2835 vchiq(C)
> > [  232.678481] CPU: 0 PID: 522 Comm: usb_test Tainted: G C
> >  4.9.0-rc3+ #33
> > [  232.678486] Hardware name: BCM2835
> > [  232.678498] task: cab54e40 task.stack: c688c000
> > [  232.678520] PC is at __do_softirq+0x68/0x2a8
> > [  232.678538] LR is at irq_exit+0xb8/0x120
> > [  232.678552] pc : []lr : []psr: 6113
> > sp : c688da60  ip : c688daa8  fp : c688daa4
> > [  232.678560] r10: c0b7f800  r9 : c688c000  r8 : 0040
> > [  232.678567] r7 : 000a  r6 : cb802400  r5 :   r4 : 0001
> > [  232.678575] r3 :   r2 : 0100  r1 : 0040  r0 : 
> > [  232.678585] Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment 
> > none
> > [  232.678593] Control: 00c5387d  Table: 068a4008  DAC: 0051
> > [  232.678604] CPU: 0 PID: 522 Comm: usb_test Tainted: G C
> >  4.9.0-rc3+ #33
> > [  232.678609] Hardware name: BCM2835
> > [  232.678667] [] (unwind_backtrace) from []
> > (show_stack+0x20/0x24)
> > [  232.678695] [] (show_stack) from []
> > (dump_stack+0x20/0x28)
> > [  232.678718] [] (dump_stack) from [] 
> > (show_regs+0x1c/0x20)
> > [  232.678752] [] (show_regs) from []
> > (watchdog_timer_fn+0x140/0x19c)
> > [  232.678779] [] (watchdog_timer_fn) from []
> > (__hrtimer_run_queues.constprop.3+0xec/0x210)
> > [  232.678798] [] (__hrtimer_run_queues.constprop.3) from 
> > []
> > (hrtimer_interrupt+0xa4/0x1cc)
> > [  232.678827] [] (hrtimer_interrupt) from []
> > (bcm2835_time_interrupt+0x40/0x48)
> > [  232.678865] [] (bcm2835_time_interrupt) from []
> > (__handle_irq_event_percpu+0x68/0x1b8)
> > [  232.678891] [] (__handle_irq_event_percpu) from []
> > (handle_irq_event_percpu+0x2c/0x68)
> > [  232.678915] [] (handle_irq_event_percpu) from []
> > (handle_irq_event+0x38/0x4c)
> > [  232.678939] [] (handle_irq_event) from []
> > (handle_level_irq+0xc4/0xf8)
> > [  232.678960] [] (handle_level_irq) from []
> > (generic_handle_irq+0x28/0x38)
> > [  232.678983] [] (generic_handle_irq) from []
> > (__handle_domain_irq+0x90/0xb8)
> > [  232.679004] [] (__handle_domain_irq) from []
> > (bcm2835_handle_irq+0x30/0x48)
> > [  232.679022] [] (bcm2835_handle_irq) from []
> > 

Re: [PATCH v2 2/3] Documentation: bindings: add DT documentation for u2phy and u2phy grf

[Heiko Stuebner]

Am Freitag, 3. März 2017, 00:21:56 CET schrieb Rob Herring:
> On Thu, Mar 02, 2017 at 03:49:04PM +0800, Meng Dongyang wrote:
> > Due to the u2phy registers are separated from general grf, we need to
> > add u2phy grf node and place u2phy node in it. So this patch add u2phy
> > grf node.
> 
> Similar comment on the subject.
> 
> > Changes in v2:
> >  - add u2phy grf specification
> > 
> > Signed-off-by: Meng Dongyang 
> > ---
> > 
> >  Documentation/devicetree/bindings/soc/rockchip/grf.txt | 15
> >  +++
> >  1 file changed, 15 insertions(+)
> > 
> > diff --git a/Documentation/devicetree/bindings/soc/rockchip/grf.txt
> > b/Documentation/devicetree/bindings/soc/rockchip/grf.txt index
> > 013e71a..6ac23f9 100644
> > --- a/Documentation/devicetree/bindings/soc/rockchip/grf.txt
> > +++ b/Documentation/devicetree/bindings/soc/rockchip/grf.txt
> > @@ -7,6 +7,9 @@ From RK3368 SoCs, the GRF is divided into two sections,
> > 
> >  - GRF, used for general non-secure system,
> >  - PMUGRF, used for always on system
> > 
> > +On RK3328 SoCs, the GRF is divided into three sections,
> > +except GRF and PMUGRF, add a section for USB2PHYGRF,
> > +
> > 
> >  Required Properties:
> >  
> >  - compatible: GRF should be one of the followings
> > 
> > @@ -19,6 +22,8 @@ Required Properties:
> >  - compatible: PMUGRF should be one of the followings
> >  
> > - "rockchip,rk3368-pmugrf", "syscon": for rk3368
> > - "rockchip,rk3399-pmugrf", "syscon": for rk3399
> > 
> > +- compatible: USB2GRF should be one of the followings
> > +   - "rockchip,rk3328-usb2phy-grf", "syscon": for rk3328
> > 
> >  - reg: physical base address of the controller and length of memory
> >  mapped
> >  
> >region.
> > 
> > @@ -33,3 +38,13 @@ Example: GRF and PMUGRF of RK3399 SoCs
> > 
> > compatible = "rockchip,rk3399-grf", "syscon";
> > reg = <0x0 0xff77 0x0 0x1>;
> > 
> > };
> > 
> > +
> > +Example: USB2GRF of RK3328 SoCs
> > +
> > +   usb2phy_grf: syscon@ff45 {
> > +   compatible = "rockchip,rk3328-usb2phy-grf", "syscon",
> > +"simple-mfd";
> 
> simple-mfd is not documented. Do you have child nodes?

Yes, this will have child nodes and I guess we don't really need the 
additional example, that only differs in the compatible.


> What makes this a syscon? It has non-PHY registers?

It is still a "General Register Files" block in all of the socs manual
and yes, that special area also contains registers not used by the phy driver.


Heiko
--
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 1/2] Documentation: bindings: add DT documentation for u2phy and u2phy grf

[Heiko Stuebner]

Hi Daniel,

Am Mittwoch, 1. März 2017, 18:34:22 CET schrieb Meng Dongyang:
> Due to the u2phy registers are separated from general grf, we need to
> add u2phy grf node and place u2phy node in it. And on some platform,
> the 480m clock may need to assign clock parent in dts in stead of
> clock driver. So this patch add u2phy grf node and property of
> assigned-clocks and assigned-clock-parents to assign parent for 480m
> clock.
> 
> Signed-off-by: Meng Dongyang 
> ---
>  .../bindings/phy/phy-rockchip-inno-usb2.txt| 47
> ++ 1 file changed, 47 insertions(+)
> 
> diff --git
> a/Documentation/devicetree/bindings/phy/phy-rockchip-inno-usb2.txt
> b/Documentation/devicetree/bindings/phy/phy-rockchip-inno-usb2.txt index
> 3c29c77..dda9f22 100644
> --- a/Documentation/devicetree/bindings/phy/phy-rockchip-inno-usb2.txt
> +++ b/Documentation/devicetree/bindings/phy/phy-rockchip-inno-usb2.txt
> @@ -2,6 +2,7 @@ ROCKCHIP USB2.0 PHY WITH INNO IP BLOCK
> 
>  Required properties (phy (parent) node):
>   - compatible : should be one of the listed compatibles:
> + * "rockchip,rk3328-usb2phy"
>   * "rockchip,rk3366-usb2phy"
>   * "rockchip,rk3399-usb2phy"
>   - reg : the address offset of grf for usb-phy configuration.
> @@ -11,6 +12,11 @@ Required properties (phy (parent) node):
>  Optional properties:
>   - clocks : phandle + phy specifier pair, for the input clock of phy.
>   - clock-names : input clock name of phy, must be "phyclk".
> + - assigned-clocks : phandle of usb 480m clock.
> + - assigned-clock-parents : parent of usb 480m clock, select between
> +  usb-phy output 480m and xin24m.
> +  Refer to clk/clock-bindings.txt for generic clock
> +  consumer properties.
> 
>  Required nodes : a sub-node is required for each port the phy provides.
>The sub-node name is used to identify host or otg port,

this block looks good


> @@ -62,3 +68,44 @@ grf: syscon@ff77 {
>   };
>   };
>  };


> +
> +Required properties (usb2phy grf node):
> + - compatible : should be one of the listed compatibles:
> + "rockchip,rk3328-usb2phy-grf", "syscon", "simple-mfd";
> + - reg : the address offset of grf for usb-phy configuration.
> + - #address-cells : should be 1.
> + - #size-cells : should be 1.
> +
> +Required nodes : a sub-node is required for the phy provides.
> +  The sub-node name is used to identify each phy,
> +  and shall be the following entries:
> +
> +Example:
> +
> +usb2phy_grf: syscon@ff45 {
> + compatible = "rockchip,rk3328-usb2phy-grf", "syscon",
> +  "simple-mfd";
> + reg = <0x0 0xff45 0x0 0x1>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + u2phy: usb2-phy@100 {
> + compatible = "rockchip,rk3328-usb2phy";
> + reg = <0x100 0x10>;
> + clocks = <>;
> + clock-names = "phyclk";
> + #clock-cells = <0>;
> + assigned-clocks = < USB480M>;
> + assigned-clock-parents = <>;
> + clock-output-names = "usb480m_phy";
> + status = "disabled";
> +
> + u2phy_host: host-port {
> + #phy-cells = <0>;
> + interrupts = ;
> + interrupt-names = "linestate";
> + status = "disabled";
> + };
> + };
> +};
> +

please don't add this here.

I've looked it up in the TRM and usb2phy-grf are still just "General Register 
Files", which also include some other registers besides this phy - so 
structure-wise this is good.
But please document the new grf-compatible in the regular
Documentation/devicetree/bindings/soc/rockchip/grf.txt .

And there is no need for a duplicate example, as it is the same structure as 
before, so maybe just add the assigned-clocks parts to the existing example.


Thanks
Heiko
--
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 2/2] phy: rockchip-inno-usb2: add support of u2phy for rk3328

[Heiko Stuebner]

Am Mittwoch, 1. März 2017, 18:34:23 CET schrieb Meng Dongyang:
> Add u2phy config information in the data of match table for
> rk3328.
> 
> Signed-off-by: Meng Dongyang <daniel.m...@rock-chips.com>

in general looks good, so
Reviewed-by: Heiko Stuebner <he...@sntech.de>

one question below


>  drivers/phy/phy-rockchip-inno-usb2.c | 21 +
>  1 file changed, 21 insertions(+)
> 
> diff --git a/drivers/phy/phy-rockchip-inno-usb2.c
> b/drivers/phy/phy-rockchip-inno-usb2.c index 4ea95c2..cf2729c 100644
> --- a/drivers/phy/phy-rockchip-inno-usb2.c
> +++ b/drivers/phy/phy-rockchip-inno-usb2.c
> @@ -1141,6 +1141,26 @@ static int rockchip_usb2phy_probe(struct
> platform_device *pdev) return ret;
>  }
> 
> +static const struct rockchip_usb2phy_cfg rk3328_phy_cfgs[] = {
> + {
> + .reg = 0x100,
> + .num_ports  = 2,
> + .phy_tuning = rk3328_usb2phy_tuning,
> + .clkout_ctl = { 0x108, 4, 4, 1, 0 },
> + .port_cfgs  = {
> + [USB2PHY_PORT_HOST] = {
> + .phy_sus= { 0x104, 15, 0, 0, 0x1d1 },
> + .ls_det_en  = { 0x110, 1, 1, 0, 1 },
> + .ls_det_st  = { 0x114, 1, 1, 0, 1 },
> + .ls_det_clr = { 0x118, 1, 1, 0, 1 },
> + .utmi_ls= { 0x120, 17, 16, 0, 1 },
> + .utmi_hstdet= { 0x120, 19, 19, 0, 1 }
> + }
> + },
> + },

The TRM also talks about the otg-port, so is there a reason for not including 
it here?


Heiko

> + { /* sentinel */ }
> +};
> +
>  static const struct rockchip_usb2phy_cfg rk3366_phy_cfgs[] = {
>   {
>   .reg = 0x700,
> @@ -1223,6 +1243,7 @@ static int rockchip_usb2phy_probe(struct
> platform_device *pdev) };
> 
>  static const struct of_device_id rockchip_usb2phy_dt_match[] = {
> + { .compatible = "rockchip,rk3328-usb2phy", .data = _phy_cfgs },
>   { .compatible = "rockchip,rk3366-usb2phy", .data = _phy_cfgs },
>   { .compatible = "rockchip,rk3399-usb2phy", .data = _phy_cfgs },
>   {}


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

dwc2 gadget issues (was: RK3288 USB OTG controller in peripheral mode)

[Heiko Stuebner]

Hi Francesco,

Am Donnerstag, 23. Februar 2017, 19:11:37 CET schrieb Francesco Lavra:
> I'm having trouble getting the RK3288 OTG controller (the one at
> ff58) to work in peripheral mode. I'm using a Firefly Reload board,
> and I know the hardware is fine because I can successfully use the port
> in device mode with U-Boot's mass storage gadget driver.
> Under Linux, the OTG port works fine when used in host mode, but fails
> to work in device mode: nothing happens when the a USB host is plugged
> into the OTG port, not even a single interrupt is generated by the
> controller. I'm using the latest device tree definitions from
> git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip.git.

you shouldn't use my tree as base for any real work :-) . Best to use the 
regular mainline kernel or alternatively try linux-next to get all recent usb 
changes schedules for the next release.


> Tried with different gadget drivers (g_audio, g_ether, g_mass_storage),
> but it makes no difference.
> Tried also forcing peripheral mode in the device tree, with dr_mode =
> "peripheral", to no avail.
> 
> Are there any known problems with the RK3288 OTG controller?

In general the controller is a dwc2 and there was quite some activity on the 
driver recently. So maybe really try linux-next first and see if any of the 
changes included there improve the situation.

I've included some usb lists + people, maybe they know if anything recent may 
have changed things.


> Here is the relevant log when the dwc2 driver is loaded at boot:
> 
> [1.376935] ff58.usb supply vusb_d not found, using dummy regulator
> [1.383683] ff58.usb supply vusb_a not found, using dummy regulator
> [1.390627] dwc2 ff58.usb: dwc2_core_reset() HANG! Soft Reset
> GRSTCTL=8001
> [1.509048] dwc2 ff58.usb: dwc2_wait_for_mode: Couldn't set
> device mode
> [1.750626] dwc2 ff58.usb: dwc2_check_param_tx_fifo_sizes:
> Invalid parameter g-tx-fifo-size, setting to default average
> [1.761828] dwc2 ff58.usb: dwc2_check_param_tx_fifo_sizes:
> Invalid parameter g_tx_fifo_size[1]=104
> [1.771192] dwc2 ff58.usb: dwc2_check_param_tx_fifo_sizes:
> Invalid parameter g_tx_fifo_size[2]=104
> [1.780529] dwc2 ff58.usb: dwc2_check_param_tx_fifo_sizes:
> Invalid parameter g_tx_fifo_size[3]=104
> [1.789888] dwc2 ff58.usb: dwc2_check_param_tx_fifo_sizes:
> Invalid parameter g_tx_fifo_size[4]=104
> [1.799245] dwc2 ff58.usb: dwc2_check_param_tx_fifo_sizes:
> Invalid parameter g_tx_fifo_size[5]=104
> [1.808614] dwc2 ff58.usb: dwc2_check_param_tx_fifo_sizes:
> Invalid parameter g_tx_fifo_size[6]=104
> [1.817993] usb 1-1: new high-speed USB device number 2 using dwc2
> [1.824390] dwc2 ff58.usb: EPs: 10, dedicated fifos, 972 entries
> in SPRAM
> [1.832098] dwc2 ff58.usb: DWC OTG Controller
> [1.836924] dwc2 ff58.usb: new USB bus registered, assigned bus
> number 2
> [1.844125] dwc2 ff58.usb: irq 41, io mem 0xff58
> [1.849747] usb usb2: New USB device found, idVendor=1d6b, idProduct=0002
> [1.856598] usb usb2: New USB device strings: Mfr=3, Product=2,
> SerialNumber=1
> [1.863875] usb usb2: Product: DWC OTG Controller
> [1.868601] usb usb2: Manufacturer: Linux 4.8.1+ dwc2_hsotg
> [1.874215] usb usb2: SerialNumber: ff58.usb
> 
> and this is what I get when I load a gadget driver (in this case, g_audio):
> 
> [   19.848590] dwc2 ff58.usb: bound driver g_audio
> [   19.853816] dwc2 ff58.usb: dwc2_hsotg_enqueue_setup: failed queue
> (-11)


Heiko
--
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 1/1] usb: dwc2: add multiple clock handling

[Heiko Stuebner]

Hi Frank,

Am Sonntag, 5. Februar 2017, 10:51:01 CET schrieb Frank Wang:
> Originally, dwc2 just handle one clock named otg, however, it may have
> two or more clock need to manage for some new SoCs, so this adds
> change clk to clk's array of dwc2_hsotg to handle more clocks operation.
> 
> Signed-off-by: Frank Wang 
> ---
>  drivers/usb/dwc2/core.h |  5 -
>  drivers/usb/dwc2/platform.c | 39 ++-
>  2 files changed, 30 insertions(+), 14 deletions(-)
> 
> diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h
> index 1a7e830..d10a466 100644
> --- a/drivers/usb/dwc2/core.h
> +++ b/drivers/usb/dwc2/core.h
> @@ -121,6 +121,9 @@ static inline void dwc2_writel(u32 value, void __iomem
> *addr) /* Maximum number of Endpoints/HostChannels */
>  #define MAX_EPS_CHANNELS 16
> 
> +/* Maximum number of dwc2 clocks */
> +#define DWC2_MAX_CLKS 3

why 3 clocks?

I.e. the binding currently only specifies the "otg" clock, so you should 
definitly amend it to also specifiy this "pmu" clock - in a separate patch 
before this one of course :-) .
"pmu" also looks like a good name for that clock-binding and these new clocks 
of course should be optional in the binding.

And ideally also just specify this mysterious third clock as well while you're 
at it.

> +
>  /* dwc2-hsotg declarations */
>  static const char * const dwc2_hsotg_supply_names[] = {
>   "vusb_d",   /* digital USB supply, 1.2V */
> @@ -913,7 +916,7 @@ struct dwc2_hsotg {
>   spinlock_t lock;
>   void *priv;
>   int irq;
> - struct clk *clk;
> + struct clk *clks[DWC2_MAX_CLKS];
>   struct reset_control *reset;
> 
>   unsigned int queuing_high_bandwidth:1;

[...]

> @@ -123,17 +123,20 @@ static int dwc2_get_dr_mode(struct dwc2_hsotg *hsotg)
>  static int __dwc2_lowlevel_hw_enable(struct dwc2_hsotg *hsotg)
>  {
>   struct platform_device *pdev = to_platform_device(hsotg->dev);
> - int ret;
> + int clk, ret;
> 
>   ret = regulator_bulk_enable(ARRAY_SIZE(hsotg->supplies),
>   hsotg->supplies);
>   if (ret)
>   return ret;
> 
> - if (hsotg->clk) {
> - ret = clk_prepare_enable(hsotg->clk);
> - if (ret)
> + for (clk = 0; clk < DWC2_MAX_CLKS && hsotg->clks[clk]; clk++) {
> + ret = clk_prepare_enable(hsotg->clks[clk]);
> + if (ret) {
> + while (--clk >= 0)
> + clk_disable_unprepare(hsotg->clks[clk]);
>   return ret;
> + }
>   }
> 
>   if (hsotg->uphy) {
> @@ -168,7 +171,7 @@ int dwc2_lowlevel_hw_enable(struct dwc2_hsotg *hsotg)
>  static int __dwc2_lowlevel_hw_disable(struct dwc2_hsotg *hsotg)
>  {
>   struct platform_device *pdev = to_platform_device(hsotg->dev);
> - int ret = 0;
> + int clk, ret = 0;
> 
>   if (hsotg->uphy) {
>   usb_phy_shutdown(hsotg->uphy);
> @@ -182,8 +185,9 @@ static int __dwc2_lowlevel_hw_disable(struct dwc2_hsotg
> *hsotg) if (ret)
>   return ret;
> 
> - if (hsotg->clk)
> - clk_disable_unprepare(hsotg->clk);
> + for (clk = DWC2_MAX_CLKS - 1; clk >= 0; clk--)
> + if (hsotg->clks[clk])
> + clk_disable_unprepare(hsotg->clks[clk]);
>   ret = regulator_bulk_disable(ARRAY_SIZE(hsotg->supplies),
>hsotg->supplies);
> @@ -209,7 +213,7 @@ int dwc2_lowlevel_hw_disable(struct dwc2_hsotg *hsotg)
> 
>  static int dwc2_lowlevel_hw_init(struct dwc2_hsotg *hsotg)
>  {
> - int i, ret;
> + int i, clk, ret;
> 
>   hsotg->reset = devm_reset_control_get_optional(hsotg->dev, "dwc2");
>   if (IS_ERR(hsotg->reset)) {
> @@ -282,11 +286,20 @@ static int dwc2_lowlevel_hw_init(struct dwc2_hsotg
> *hsotg) hsotg->phyif = GUSBCFG_PHYIF8;
>   }
> 
> - /* Clock */
> - hsotg->clk = devm_clk_get(hsotg->dev, "otg");
> - if (IS_ERR(hsotg->clk)) {
> - hsotg->clk = NULL;
> - dev_dbg(hsotg->dev, "cannot get otg clock\n");
> + /* Clocks */
> + for (clk = 0; clk < DWC2_MAX_CLKS; clk++) {
> + hsotg->clks[clk] = of_clk_get(hsotg->dev->of_node, clk);
> + if (IS_ERR(hsotg->clks[clk])) {
> + ret = PTR_ERR(hsotg->clks[clk]);
> + if (ret == -EPROBE_DEFER) {
> + while (--clk >= 0)
> + clk_put(hsotg->clks[clk]);
> + return ret;
> + }
> +
> + hsotg->clks[clk] = NULL;
> + break;
> + }

I guess this depends on the feelings of the usb-people, but for me it might 
make more sense to not carry the clocks in an anonymous array but instead as 
named members in struct dwc2_hsotg - aka clk_otg, clk_pmu, clk_??? .

Because the otg clocks is actually marked as 

Re: [RESEND PATCH 0/1] add multiple clock handling for dwc2 driver

[Heiko Stuebner]

Hi Frank,

Am Montag, 6. Februar 2017, 09:40:35 CET schrieb Frank Wang:
> On 2017/2/5 17:41, Heiko Stuebner wrote:
> > Am Sonntag, 5. Februar 2017, 10:51:00 CET schrieb Frank Wang:
> >> The original posting on Jan 19th have not received any responses, so I
> >> resend them.
> >> 
> >> The Current default dwc2 just handle one clock named otg, however, it may
> >> have two or more clock need to manage for some new SoCs(such as RK3328),
> >> so
> >> this adds change clk to clk's array of dwc2_hsotg to handle more clocks
> >> operation.
> > 
> > can you please give a bit more detail on the specific layout.
> > 
> > I guess you're talking about hclk_otg_pmu, right? What component does it
> > supply, because I didn't find anything in the partial TRM in the PMU
> > section relating to the "otg".
> 
> Yes, it is hclk_otg_pmu.
> 
> The rock-chip hclk_otg_pmu is an input clock for dwc2 PMU module which
> named pmu_hclk in chapter 2.4 of dwc otg databook v3.10.

ok great, on establishing that this is a actual part of the IP block.

I'm going to comment on the actual code change in a minute, so see you over 
there :-)

Heiko
--
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 0/1] add multiple clock handling for dwc2 driver

[Heiko Stuebner]

Hi Frank,

Am Sonntag, 5. Februar 2017, 10:51:00 CET schrieb Frank Wang:
> The original posting on Jan 19th have not received any responses, so I
> resend them.
> 
> The Current default dwc2 just handle one clock named otg, however, it may
> have two or more clock need to manage for some new SoCs(such as RK3328), so
> this adds change clk to clk's array of dwc2_hsotg to handle more clocks
> operation.

can you please give a bit more detail on the specific layout.

I guess you're talking about hclk_otg_pmu, right? What component does it 
supply, because I didn't find anything in the partial TRM in the PMU section 
relating to the "otg".

This meant to make sure, you're actually controlling some part of the dwc2 
with that second/third/... clock and not some separate component.


Heiko
--
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 v7 2/8] power: add power sequence library

[Heiko Stuebner]

Am Donnerstag, 13. Oktober 2016, 09:22:16 CEST schrieb Peter Chen:
> On Wed, Oct 12, 2016 at 12:30:29PM +0200, Heiko Stuebner wrote:
> > Hi,
> > 
> > Am Dienstag, 20. September 2016, 11:36:41 CEST schrieb Peter Chen:
> > > We have an well-known problem that the device needs to do some power
> > > sequence before it can be recognized by related host, the typical
> > > example like hard-wired mmc devices and usb devices.
> > > 
> > > This power sequence is hard to be described at device tree and handled
> > > by
> > > related host driver, so we have created a common power sequence
> > > library to cover this requirement. The core code has supplied
> > > some common helpers for host driver, and individual power sequence
> > > libraries handle kinds of power sequence for devices.
> > > 
> > > pwrseq_generic is intended for general purpose of power sequence, which
> > > handles gpios and clocks currently, and can cover regulator and pinctrl
> > > in future. The host driver just needs to call of_pwrseq_on/of_pwrseq_off
> > > if only one power sequence is needed, else call of_pwrseq_on_list
> > > /of_pwrseq_off_list instead (eg, USB hub driver).
> > > 
> > > Signed-off-by: Peter Chen <peter.c...@nxp.com>
> > > Tested-by Joshua Clayton <stillcompil...@gmail.com>
> > > Reviewed-by: Matthias Kaehlcke <m...@chromium.org>
> > > Tested-by: Matthias Kaehlcke <m...@chromium.org>
> > 
> > first of all, glad to see this move forward. I've only some qualms with
> > the
> > static number of allocated power sequences below.
> 
> Thanks for commenting it, the preallocate way is not a good way, but I
> can't find suitable way. See below comments.
> 
> > > +static int __init pwrseq_generic_register(void)
> > > +{
> > > + struct pwrseq_generic *pwrseq_gen;
> > > + int i;
> > > +
> > > + for (i = 0; i < CONFIG_PWRSEQ_GENERIC_INSTANCE_NUMBER; i++) {
> > > + pwrseq_gen = kzalloc(sizeof(*pwrseq_gen), GFP_KERNEL);
> > > + if (!pwrseq_gen)
> > > + return -ENOMEM;
> > > +
> > > + pwrseq_gen->pwrseq.pwrseq_of_match_table = generic_id_table;
> > > + pwrseq_gen->pwrseq.get = pwrseq_generic_get;
> > > + pwrseq_gen->pwrseq.on = pwrseq_generic_on;
> > > + pwrseq_gen->pwrseq.off = pwrseq_generic_off;
> > > + pwrseq_gen->pwrseq.put = pwrseq_generic_put;
> > > + pwrseq_gen->pwrseq.free = pwrseq_generic_free;
> > > +
> > > + pwrseq_register(_gen->pwrseq);
> > > + }
> > > +
> > > + return 0;
> > > +}
> > > +postcore_initcall(pwrseq_generic_register)
> > 
> > I see that you need to have it preallocated for the compatible matching,
> > but wouldn't it also work to either just register the type and allocate
> > dynamically or otherwise just allocate a new spare everytime
> > pwrseq_generic_get() picks up the previous spare?
> 
> Before compatible matching, the host driver doesn't know which pwrseq type
> for its child node, then doesn't know which pwrseq instance needs to be
> allocated. From dts, we don't know which pwrseq type for the node.

yes, that is why I was suggesting allocating one (or two) here in 
pwrseq_generic_register() and every time pwrseq_generic_get() grabs the last 
free sequence instance, you allocate a new free spare one in that function.
--
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 v7 2/8] power: add power sequence library

[Heiko Stuebner]

Hi,

Am Dienstag, 20. September 2016, 11:36:41 CEST schrieb Peter Chen:
> We have an well-known problem that the device needs to do some power
> sequence before it can be recognized by related host, the typical
> example like hard-wired mmc devices and usb devices.
> 
> This power sequence is hard to be described at device tree and handled by
> related host driver, so we have created a common power sequence
> library to cover this requirement. The core code has supplied
> some common helpers for host driver, and individual power sequence
> libraries handle kinds of power sequence for devices.
> 
> pwrseq_generic is intended for general purpose of power sequence, which
> handles gpios and clocks currently, and can cover regulator and pinctrl
> in future. The host driver just needs to call of_pwrseq_on/of_pwrseq_off
> if only one power sequence is needed, else call of_pwrseq_on_list
> /of_pwrseq_off_list instead (eg, USB hub driver).
>
> Signed-off-by: Peter Chen 
> Tested-by Joshua Clayton 
> Reviewed-by: Matthias Kaehlcke 
> Tested-by: Matthias Kaehlcke 

first of all, glad to see this move forward. I've only some qualms with the 
static number of allocated power sequences below.

[...]

> diff --git a/drivers/power/pwrseq/Kconfig b/drivers/power/pwrseq/Kconfig
> new file mode 100644
> index 000..dff5e35
> --- /dev/null
> +++ b/drivers/power/pwrseq/Kconfig
> @@ -0,0 +1,45 @@
> +#
> +# Power Sequence library
> +#
> +
> +config POWER_SEQUENCE
> + bool
> +
> +menu "Power Sequence Support"
> +
> +config PWRSEQ_GENERIC
> + bool "Generic power sequence control"
> + depends on OF
> + select POWER_SEQUENCE
> + help
> +It is used for drivers which needs to do power sequence
> +(eg, turn on clock, toggle reset gpio) before the related
> +devices can be found by hardware. This generic one can be
> +used for common power sequence control.
> +
> +config PWRSEQ_GENERIC_INSTANCE_NUMBER
> + int "Number of Generic Power Sequence Instance"
> + depends on PWRSEQ_GENERIC
> + range 1 10
> + default 2
> + help
> +Usually, there are not so many devices needs power sequence, we set 
> two
> +as default value.

limiting this to some arbitary compile-time number somehow seems crippling for 
the single-image approach. I.e. a distribution might select something and 
during its lifetime the board requiring n+1 power-sequences appears and thus 
needs a different kernel version just to support that additional sequence.

Also, board designers are creative, and there were already complex examples 
mentioned elsewhere, so nothing keeps people from inventing something even 
more complex.

[...]

> diff --git a/drivers/power/pwrseq/pwrseq_generic.c
> b/drivers/power/pwrseq/pwrseq_generic.c new file mode 100644
> index 000..bcd16c3
> --- /dev/null
> +++ b/drivers/power/pwrseq/pwrseq_generic.c

[...]

> +static int pwrseq_generic_get(struct device_node *np, struct pwrseq
> *pwrseq) +{
> + struct pwrseq_generic *pwrseq_gen = to_generic_pwrseq(pwrseq);
> + enum of_gpio_flags flags;
> + int reset_gpio, clk, ret = 0;
> +
> + for (clk = 0; clk < PWRSEQ_MAX_CLKS; clk++) {
> + pwrseq_gen->clks[clk] = of_clk_get(np, clk);
> + if (IS_ERR(pwrseq_gen->clks[clk])) {
> + ret = PTR_ERR(pwrseq_gen->clks[clk]);
> + if (ret != -ENOENT)
> + goto err_put_clks;
> + pwrseq_gen->clks[clk] = NULL;
> + break;
> + }
> + }
> +
> + reset_gpio = of_get_named_gpio_flags(np, "reset-gpios", 0, );
> + if (gpio_is_valid(reset_gpio)) {
> + unsigned long gpio_flags;
> +
> + if (flags & OF_GPIO_ACTIVE_LOW)
> + gpio_flags = GPIOF_ACTIVE_LOW | GPIOF_OUT_INIT_LOW;
> + else
> + gpio_flags = GPIOF_OUT_INIT_HIGH;
> +
> + ret = gpio_request_one(reset_gpio, gpio_flags,
> + "pwrseq-reset-gpios");
> + if (ret)
> + goto err_put_clks;
> +
> + pwrseq_gen->gpiod_reset = gpio_to_desc(reset_gpio);
> + of_property_read_u32(np, "reset-duration-us",
> + _gen->duration_us);
> + } else {
> + if (reset_gpio == -ENOENT)
> + return 0;
> +
> + ret = reset_gpio;
> + pr_err("Failed to get reset gpio on %s, err = %d\n",
> + np->full_name, reset_gpio);
> + goto err_put_clks;
> + }
> +
> + return ret;
> +
> +err_put_clks:
> + while (--clk >= 0)
> + clk_put(pwrseq_gen->clks[clk]);
> + return ret;
> +}
> +
> +static const struct of_device_id generic_id_table[] = {
> + { .compatible = "generic",},
> + { /* sentinel */ }
> +};
> +
> 

Re: [RESEND PATCH v7 0/4] the fix for the USB HOST1 at rk3288 platform

[Heiko Stuebner]

Am Dienstag, 13. September 2016, 19:26:03 CEST schrieb ayaka:
> On 09/13/2016 07:06 PM, Heiko Stuebner wrote:
> > Hi Randy,
> > 
> > could you check if the other host-only dwc2 are also affected by this
> > (rk3188, rk3036) please? Because they also seem to act up in some strange
> > way
> But I don't have those board currently. I would arrange them anyway.
> Btw, I would send a new version to correct the fault reported by the
> auto build machine.

What I meant was, if you could check with some hardware-people first, if the
other host-only dwc2 are supposedly also affected. Right now I'm trying to
determine if this effect is somehow related with the usb debounce issue
I'm seeing with some recent dwc2 patches [0].


Heiko

[0] 
http://lists.infradead.org/pipermail/linux-rockchip/2016-September/012141.html
https://git.kernel.org/cgit/linux/kernel/git/balbi/usb.git/commit/?h=testing/next=2938fc63e0c26bf694436ac81bc776c8b7eced0c

--
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 v7 0/4] the fix for the USB HOST1 at rk3288 platform

[Heiko Stuebner]

Hi Randy,

could you check if the other host-only dwc2 are also affected by this (rk3188, 
rk3036) please? Because they also seem to act up in some strange way 
sometimes.

Thanks
Heiko

Am Samstag, 10. September 2016, 02:59:36 CEST schrieb Randy Li:
>   At this stage it is the only "full features" and well verified
> USB EHCI controller in this platform. More review is always necessary.
>
> Changelog:
>  - v7:
> adding a wrapper for the reset operation for phy
> using that wrapper
>  - v6:
> move pwms pinctrl to pwms node
> fix the order of the dtb file in Makefile
>  - v5:
>- correct the mail format
>  - v4:
>- re-order some nodes in alphabetical order
>- fix some minor bugs
>- add a entry in vendor list
>  - v3:
>- fixing the rtc clock, using clock source from PMIC
>- enable the tmu
>- enable the fimc for elite board
>- suuport the audio codec at elite board
>- fixing minor bugs in the last commit
>  - v2:
>- removing rtc node
>  the clock source driver is not done yet.
>- adding exynos-bus
>- fixing the MFC
> 
> Randy Li (4):
>   phy: Add reset callback
>   phy: rockchip-usb: use rockchip_usb_phy_reset to reset phy during
> wakeup
>   usb: dwc2: assert phy reset when waking up in rk3288 platform
>   ARM: dts: rockchip: Point rk3288 dwc2 usb at the full PHY reset
> 
>  .../devicetree/bindings/phy/rockchip-usb-phy.txt |  3 +++
>  arch/arm/boot/dts/rk3288.dtsi|  4 
>  drivers/phy/phy-core.c   | 14 ++
>  drivers/phy/phy-rockchip-usb.c   | 20
>  drivers/usb/dwc2/core_intr.c |
> 11 +++ include/linux/phy/phy.h  |  3
> +++
>  6 files changed, 55 insertions(+)


--
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 v7 1/4] phy: Add reset callback

[Heiko Stuebner]

Hi Randy,

Am Samstag, 10. September 2016, 02:59:37 CEST schrieb Randy Li:
> The only use for this is for solving a hardware design problem in
> usb of Rockchip RK3288.
> 
> Signed-off-by: Randy Li <ay...@soulik.info>

When sending new versions, please carry over received Reviewed- / Tested- / 
Acked-by tags received on old versions.

So again, to me this looks good.

Although Kishon suggested earlier to have the init callback do the reset and 
simply call it again in the reset-case, the whole refcounting done in phy_init 
and phy_exit (phy->init_count) really shows that init and exit should be 
called pairwise, so that extra reset callback seems justified, so from my phy-
noob-pov

Reviewed-by: Heiko Stuebner <he...@sntech.de>

> ---
>  drivers/phy/phy-core.c  | 14 ++
>  include/linux/phy/phy.h |  3 +++
>  2 files changed, 17 insertions(+)
> 
> diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
> index 8eca906..32e838d 100644
> --- a/drivers/phy/phy-core.c
> +++ b/drivers/phy/phy-core.c
> @@ -357,6 +357,20 @@ int phy_set_mode(struct phy *phy, enum phy_mode mode)
>  }
>  EXPORT_SYMBOL_GPL(phy_set_mode);
> 
> +int phy_reset(struct phy *phy)
> +{
> + int ret;
> + if (!phy || !phy->ops->reset)
> + return 0;
> +
> + mutex_lock(>mutex);
> + ret = phy->ops->reset(phy);
> + mutex_unlock(>mutex);
> +
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(phy_reset);
> +
>  /**
>   * _of_phy_get() - lookup and obtain a reference to a phy by phandle
>   * @np: device_node for which to get the phy
> diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h
> index f08b672..7978df6 100644
> --- a/include/linux/phy/phy.h
> +++ b/include/linux/phy/phy.h
> @@ -36,6 +36,7 @@ enum phy_mode {
>   * @power_on: powering on the phy
>   * @power_off: powering off the phy
>   * @set_mode: set the mode of the phy
> + * @reset: reseting the phy
>   * @owner: the module owner containing the ops
>   */
>  struct phy_ops {
> @@ -44,6 +45,7 @@ struct phy_ops {
>   int (*power_on)(struct phy *phy);
>   int (*power_off)(struct phy *phy);
>   int (*set_mode)(struct phy *phy, enum phy_mode mode);
> + int (*reset)(struct phy *phy);
>   struct module *owner;
>  };
> 
> @@ -136,6 +138,7 @@ int phy_exit(struct phy *phy);
>  int phy_power_on(struct phy *phy);
>  int phy_power_off(struct phy *phy);
>  int phy_set_mode(struct phy *phy, enum phy_mode mode);
> +int phy_reset(struct phy *phy);
>  static inline int phy_get_bus_width(struct phy *phy)
>  {
>   return phy->attrs.bus_width;


--
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/4] phy: Add reset callback

[Heiko Stuebner]

Am Donnerstag, 8. September 2016, 22:27:13 CEST schrieb Randy Li:
> The only use for this is for solving a hardware design problem in
> usb of Rockchip RK3288.
> 
> Signed-off-by: Randy Li <ay...@soulik.info>

to me this looks good.

Although Kishon suggested earlier to have the init callback do the reset and 
simply call it again in the reset-case, the whole refcounting done in phy_init 
and phy_exit (phy->init_count) really shows that init and exit should be 
called pairwise, so that extra reset callback seems justified, so from my phy-
noob-pov

Reviewed-by: Heiko Stuebner <he...@sntech.de>

with one minor style nitpick below

> ---
>  drivers/phy/phy-core.c  | 14 ++
>  include/linux/phy/phy.h |  3 +++
>  2 files changed, 17 insertions(+)
> 
> diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
> index 8eca906..32e838d 100644
> --- a/drivers/phy/phy-core.c
> +++ b/drivers/phy/phy-core.c
> @@ -357,6 +357,20 @@ int phy_set_mode(struct phy *phy, enum phy_mode mode)
>  }
>  EXPORT_SYMBOL_GPL(phy_set_mode);
> 
> +int phy_reset(struct phy *phy)
> +{
> + int ret;

I think a blank line between declarations and code is customary.

> + if (!phy || !phy->ops->reset)
> + return 0;
> +
> + mutex_lock(>mutex);
> + ret = phy->ops->reset(phy);
> + mutex_unlock(>mutex);
> +
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(phy_reset);
> +
>  /**
>   * _of_phy_get() - lookup and obtain a reference to a phy by phandle
>   * @np: device_node for which to get the phy

Heiko
--
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 3/5] usb: dwc3: add phyif_utmi_quirk

[Heiko Stuebner]

Am Samstag, 9. Juli 2016, 11:38:00 schrieb William.wu:
> Dear Heiko & Balbi，
> 
> On 2016/7/8 21:29, Felipe Balbi wrote:
> > Hi,
> > 
> > Heiko Stuebner <he...@sntech.de> writes:
> >> Am Donnerstag, 7. Juli 2016, 10:54:24 schrieb William Wu:
> >>> Add a quirk to configure the core to support the
> >>> UTMI+ PHY with an 8- or 16-bit interface. UTMI+ PHY
> >>> interface is hardware property, and it's platform
> >>> dependent. Normall, the PHYIf can be configured
> >>> during coreconsultant. But for some specific usb
> >>> cores(e.g. rk3399 soc dwc3), the default PHYIf
> >>> configuration value is fault, so we need to
> >>> reconfigure it by software.
> >>> 
> >>> And refer to the dwc3 databook, the GUSB2PHYCFG.USBTRDTIM
> >>> must be set to the corresponding value according to
> >>> the UTMI+ PHY interface.
> >>> 
> >>> Signed-off-by: William Wu <william...@rock-chips.com>
> >>> ---
> >> 
> >> [...]
> >> 
> >>> diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt
> >>> b/Documentation/devicetree/bindings/usb/dwc3.txt index
> >>> 020b0e9..8d7317d
> >>> 100644
> >>> --- a/Documentation/devicetree/bindings/usb/dwc3.txt
> >>> +++ b/Documentation/devicetree/bindings/usb/dwc3.txt
> >>> 
> >>> @@ -42,6 +42,10 @@ Optional properties:
> >>>- snps,dis-u2-freeclk-exists-quirk: when set, clear the
> >>> 
> >>> u2_freeclk_exists in GUSB2PHYCFG, specify that USB2 PHY doesn't
> >>> provide
> >>> 
> >>>   a free-running PHY clock.
> >>> 
> >>> + - snps,phyif-utmi-quirk: when set core will set phyif UTMI+
> >>> interface.
> >>> + - snps,phyif-utmi: the value to configure the core to support a
> >>> UTMI+
> >>> PHY + with an 8- or 16-bit interface. Value 0 
select 8-bit
> >>> + interface, value 1 select 16-bit interface.
> >> 
> >> maybe
> >> 
> >>snps,phyif-utmi-width = <8> or <16>;
> >> 
> >> devicetree is about describing the hardware, not the things that get
> >> written to registers :-) . The conversion from the described width to
> >> the register value can easily be done in the driver.
> 
> Thanks for your suggestion:-)
> Yes， “snps,phyif-utmi-width = <8> or <16>” is much clearer and easier to
> understand.
> And I have considered the same dts property for phyif-utmi, but I have
> no good idea about
> the conversion from described width to the registers value for the time
> being.
> 
> About phyif utmi width configuration， we need to set two places in
> GUSB2PHYCFG register，
> according to DWC3 USB3.0 controller databook version3.00a，6.3.46
> GUSB2PHYCFG
> 
> --
>  Bits   |  Name | Description
> --
>  13:10  |   USBTRDTIM   | Sets the turnaround
> time in PHY clocks.
>  || 4'h5: When the MAC
> 
> interface is 16-bit UTMI+
> 
>  || 4'h9: When the MAC
> 
> interface is 8-bit UTMI+/ULPI.
> --
>  3|   PHYIF|If UTMI+ is
> selected, the application uses this bit to configure
> 
>  ||core to support a UTMI+
> 
> PHY with an 8- or 16-bit interface.
> 
>  ||1'b0: 8 bits
>  ||1'b1: 16 bits
> 
> --
> 
> 
> And I think maybe I can try to do this:
> change it in dts:
>  snps,phyif-utmi-width = <8> or <16>;
> 
> Then convert to register value like this：
> device_property_read_u8(dev, "snps,phyif-utmi-width",
>   _utmi_width);
> 
> dwc->phyif_utmi = phyif_utmi_width >> 4;
> 
>   Ater the conversion， dwc->phyif_utmi value 0 means 8 bits, value 1
> means 16 bits,
>   and it's easier for us to config GUSB2PHYCFG.
> 
> Is it OK?

or you could just store the 

Re: [PATCH v6 3/5] usb: dwc3: add phyif_utmi_quirk

[Heiko Stuebner]

Hi William,

Am Donnerstag, 7. Juli 2016, 10:54:24 schrieb William Wu:
> Add a quirk to configure the core to support the
> UTMI+ PHY with an 8- or 16-bit interface. UTMI+ PHY
> interface is hardware property, and it's platform
> dependent. Normall, the PHYIf can be configured
> during coreconsultant. But for some specific usb
> cores(e.g. rk3399 soc dwc3), the default PHYIf
> configuration value is fault, so we need to
> reconfigure it by software.
> 
> And refer to the dwc3 databook, the GUSB2PHYCFG.USBTRDTIM
> must be set to the corresponding value according to
> the UTMI+ PHY interface.
> 
> Signed-off-by: William Wu 
> ---
[...]
> diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt
> b/Documentation/devicetree/bindings/usb/dwc3.txt index 020b0e9..8d7317d
> 100644
> --- a/Documentation/devicetree/bindings/usb/dwc3.txt
> +++ b/Documentation/devicetree/bindings/usb/dwc3.txt
> @@ -42,6 +42,10 @@ Optional properties:
>   - snps,dis-u2-freeclk-exists-quirk: when set, clear the
> u2_freeclk_exists in GUSB2PHYCFG, specify that USB2 PHY doesn't provide
>   a free-running PHY clock.
> + - snps,phyif-utmi-quirk: when set core will set phyif UTMI+ interface.
> + - snps,phyif-utmi: the value to configure the core to support a UTMI+
> PHY + with an 8- or 16-bit interface. Value 0 select 8-bit
> + interface, value 1 select 16-bit interface.

maybe
snps,phyif-utmi-width = <8> or <16>;

devicetree is about describing the hardware, not the things that get written 
to registers :-) . The conversion from the described width to the register 
value can easily be done in the driver.


Also I don't think you need two properties for this. If the snps,phyif-utmi 
property is specified it indicates that you want to manually set the width 
and if it is absent you want to use the IC default. All functions reading 
property-values indicate if the property is missing.

But it looks like there is already a precendence in 
snps,tx_de_emphasis(_quirk), so maybe Felipe has a different opinion here?



>   - snps,is-utmi-l1-suspend: true when DWC3 asserts output signal
>   utmi_l1_suspend_n, false when asserts utmi_sleep_n
>   - snps,hird-threshold: HIRD threshold
> diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
> index 0b7bfd2..94036b1 100644
> --- a/drivers/usb/dwc3/core.c
> +++ b/drivers/usb/dwc3/core.c
> @@ -408,6 +408,7 @@ static void dwc3_cache_hwparams(struct dwc3 *dwc)
>  static int dwc3_phy_setup(struct dwc3 *dwc)
>  {
>   u32 reg;
> + u32 usbtrdtim;
>   int ret;
> 
>   reg = dwc3_readl(dwc->regs, DWC3_GUSB3PIPECTL(0));
> @@ -503,6 +504,15 @@ static int dwc3_phy_setup(struct dwc3 *dwc)
>   if (dwc->dis_u2_freeclk_exists_quirk)
>   reg &= ~DWC3_GUSB2PHYCFG_U2_FREECLK_EXISTS;
> 
> + if (dwc->phyif_utmi_quirk) {
> + reg &= ~(DWC3_GUSB2PHYCFG_PHYIF_MASK |
> +DWC3_GUSB2PHYCFG_USBTRDTIM_MASK);
> + usbtrdtim = dwc->phyif_utmi ? USBTRDTIM_UTMI_16_BIT :
> + USBTRDTIM_UTMI_8_BIT;
> + reg |= DWC3_GUSB2PHYCFG_PHYIF(dwc->phyif_utmi) |
> +DWC3_GUSB2PHYCFG_USBTRDTIM(usbtrdtim);
> + }
> +
>   dwc3_writel(dwc->regs, DWC3_GUSB2PHYCFG(0), reg);
> 
>   return 0;
> @@ -834,6 +844,7 @@ static int dwc3_probe(struct platform_device *pdev)
>   struct resource *res;
>   struct dwc3 *dwc;
>   u8  lpm_nyet_threshold;
> + u8  phyif_utmi;
>   u8  tx_de_emphasis;
>   u8  hird_threshold;
> 
> @@ -880,6 +891,9 @@ static int dwc3_probe(struct platform_device *pdev)
>   /* default to highest possible threshold */
>   lpm_nyet_threshold = 0xff;
> 
> + /* default to UTMI+ 8-bit interface */
> + phyif_utmi = 0;
> +
>   /* default to -3.5dB de-emphasis */
>   tx_de_emphasis = 1;
> 
> @@ -929,6 +943,10 @@ static int dwc3_probe(struct platform_device *pdev)
>   "snps,dis_rxdet_inp3_quirk");
>   dwc->dis_u2_freeclk_exists_quirk = device_property_read_bool(dev,
>   "snps,dis-u2-freeclk-exists-quirk");
> + dwc->phyif_utmi_quirk = device_property_read_bool(dev,
> + "snps,phyif-utmi-quirk");
> +  device_property_read_u8(dev, "snps,phyif-utmi",
> +  _utmi);


As described above device_property_read_u8 will return an error if the 
property is not present, so you could fill your dwc->phyif_utmi_quirk from 
that:

ret = device_property_read_u8(dev, "snps,phyif-utmi",
 _utmi);
dwc->phyif_utmi_quirk = (ret == 0) ? true : false;


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

Re: [PATCH v5 5/5] usb: dwc3: rockchip: add devicetree bindings documentation

[Heiko Stuebner]

Hi William,

Am Donnerstag, 30. Juni 2016, 19:16:40 schrieb William Wu:
> This patch adds the devicetree documentation required for Rockchip
> USB3.0 core wrapper consisting of USB3.0 IP from Synopsys.
> 
> It supports DRD mode, and could operate in device mode (SS, HS, FS)
> and host mode (SS, HS, FS, LS).
> 
> Signed-off-by: William Wu 
> ---
> Changes in v5:
> - rename clock-names, and remove unnecessary clocks (Heiko)
> 
> Changes in v4:
> - modify commit log, and add phy documentation location (Sergei)
> 
> Changes in v3:
> - add dwc3 address (balbi)
> 
> Changes in v2:
> - add rockchip,dwc3.txt to Documentation/devicetree/bindings/ (balbi,
> Brian)
> 
>  .../devicetree/bindings/usb/rockchip,dwc3.txt  | 40
> ++ 1 file changed, 40 insertions(+)
>  create mode 100644
> Documentation/devicetree/bindings/usb/rockchip,dwc3.txt
> 
> diff --git a/Documentation/devicetree/bindings/usb/rockchip,dwc3.txt
> b/Documentation/devicetree/bindings/usb/rockchip,dwc3.txt new file mode
> 100644
> index 000..9c85e19
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/usb/rockchip,dwc3.txt
> @@ -0,0 +1,40 @@
> +Rockchip SuperSpeed DWC3 USB SoC controller
> +
> +Required properties:
> +- compatible:should contain "rockchip,rk3399-dwc3" for rk3399 SoC
> +- clocks:A list of phandle + clock-specifier pairs for the
> + clocks listed in clock-names
> +- clock-names:   Should contain the following:
> +  "ref_clk"  Controller reference clk, have to be 24 MHz
> +  "suspend_clk"  Controller suspend clk, have to be 24 MHz or 32 KHz
> +  "bus_clk_otg0"Master/Core clock, have to be >= 62.5 MHz for SS
> + operation and >= 60MHz for HS operation

why is it called "bus_clk_otg0" not just simply "bus_clk". As far as I
understand it (and see it in the TRM), you have two dwc3 controllers
(otg0 and otg1) and clock-names are always meant from the perspective of
the individual ip-block. So a devicetree would have:

usbdrd3_0: usb@fe80 {
compatible = "rockchip,rk3399-dwc3";
clocks = < SCLK_USB3OTG0_REF>, < SCLK_USB3OTG0_SUSPEND>,
 < ACLK_USB3OTG0>, < ACLK_USB3_GRF>;
clock-names = "ref_clk", "suspend_clk",
  "bus_clk", "grf_clk";
...
};

usbdrd3_1: usb@fe90 {
compatible = "rockchip,rk3399-dwc3";
clocks = < SCLK_USB3OTG1_REF>, < SCLK_USB3OTG1_SUSPEND>,
 < ACLK_USB3OTG1>, < ACLK_USB3_GRF>;
clock-names = "ref_clk", "suspend_clk",
  "bus_clk", "grf_clk";
...
};


The rest looks really nice now.


Heiko

> +  "grf_clk"  Controller grf clk
> +
> +Required child node:
> +A child node must exist to represent the core DWC3 IP block. The name of
> +the node is not important. The content of the node is defined in
> dwc3.txt. +
> +Phy documentation is provided in the following places:
> +Documentation/devicetree/bindings/phy/rockchip,dwc3-usb-phy.txt
> +
> +Example device nodes:
> +
> + usbdrd3_0: usb@fe80 {
> + compatible = "rockchip,rk3399-dwc3";
> + clocks = < SCLK_USB3OTG0_REF>, < SCLK_USB3OTG0_SUSPEND>,
> +  < ACLK_USB3OTG0>, < ACLK_USB3_GRF>;
> + clock-names = "ref_clk", "suspend_clk",
> +   "bus_clk_otg0", "grf_clk";
> + #address-cells = <2>;
> + #size-cells = <2>;
> + ranges;
> + status = "disabled";
> + usbdrd_dwc3_0: dwc3@fe80 {
> + compatible = "snps,dwc3";
> + reg = <0x0 0xfe80 0x0 0x10>;
> + interrupts = ;
> + dr_mode = "otg";
> + status = "disabled";
> + };
> + };
> --
> 1.9.1

--
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 2/2] phy: rockchip-inno-usb2: add a new driver for Rockchip usb2phy

[Heiko Stuebner]

Hi Kishon,

Am Mittwoch, 29. Juni 2016, 19:44:52 schrieb Kishon Vijay Abraham I:
> On Friday 17 June 2016 10:16 PM, Heiko Stübner wrote:
> > Am Freitag, 17. Juni 2016, 17:24:46 schrieb Kishon Vijay Abraham I:
> > [...]
> > 
> >>> + /* find out a proper config which can be matched with dt. */
> >>> + index = 0;
> >>> + while (phy_cfgs[index].reg) {
> >>> + if (phy_cfgs[index].reg == reg) {
> >> 
> >> Why not pass these config values from dt? Moreover finding the config
> >> using register offset is bound to break.
> > 
> > As you have probably seen, this phy block is no stand-alone
> > (mmio-)device, but gets controlled through special register/bits in the
> > so called "General Register Files" syscon.
> > 
> > The values stored and accessed here, are the location and layout of
> > those
> > control registers. Bits in those phy control registers at times move
> > between phy-versions in different socs (rk3036, rk3228, rk3366, rk3368,
> > rk3399) and some are even missing. So I don't really see a nice way to
> > describe that in dt without describing the register and offset of each
> > of those 22 used bits individually.
> > 
> > 
> > I'm also not sure where you expect it to break? The reg-offset is the
> > offset of the phy inside the GRF and the Designware-phy also already
> > does something similar to select some appropriate values.
> 
> I'm concerned the phy can be placed in the different reg-offset within GRF
> (like in the next silicon revision) and this driver can't be used.

That is something that has not happened with all Rockchip SoCs I have had in 
my hands so far.

While the GRF is some sort-of wild-west area with settings for vastly 
different blocks in there and always changes between different socs (rk3288 
[4-core A17] <-> rk3366 <-> rk3368 [8-core A53] <-> rk3399 etc) there 
haven't been such changes (different register offsets) between soc-revisions 
of the same soc that I know off.

The GRF also includes such important things like the whole pinctrl handling, 
so if there were such offset changes in the GRF a lot of drivers (and 
maintainers) would get very unhappy - me included :-) .


Heiko
--
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 5/5] usb: dwc3: rockchip: add devicetree bindings documentation

[Heiko Stuebner]

Hi William,

Am Dienstag, 28. Juni 2016, 11:18:04 schrieb William Wu:
> >> So about the usb3 controller clk management, I think it should contain
> >> the following clk:
> >> 1.  aclk_usb3otg1
> >> 2.  aclk_usb3otg0
> >> 3.  aclk_usb3_grf
> > 
> > correct, aclk_usb3otgX would then be the busclk for each controller if
> > I'm not mistaken and the grf clock should also get enabled, like we
> > also plan on doing for the vio_grf clock in the display area.
> 
> OK, so  aclk_usb3_grf should be marked as critical, right?

nope ... the consensus for the vio_grf clock was that the driver accessing 
it should control it. So for the usb3_grf clock this would be your dwc3-
based driver being responsible for the grf-clock.


> I found that most of the grf clocks haven't been marked as critical,
> apart from vio_grf. So may I keep the aclk_usb3_grf in usb3 dts, and
> remove it after clock manager adds it to critical clocks?

you should keep the usb3-grf clock in the dts all the time.


> >> 4.  aclk_usb3_noc
> >> For "aclk_usb3_noc", I discuss with our clk manager, the clk is always
> >> on before,
> >> but according to upstream maintainer's suggestion, we need to manage
> >> the
> >> noc clk by each module.
> > 
> > can you point me to this discussion? The bus-interconnect is a very
> > separate component, which we don't model so far and thus we have all
> > the noc clocks simply marked as critical.
> > 
> > As this clock doesn't belong to the actual usb controller block, but
> > said
> > separate component, handling it in the controller seems somehow wrong to
> > me.
> > 
> > So my (current) opinion would again be to mark the noc clock as critical
> > for the time being.
> 
> Sorry, it seems that I get the new information about clk management too
> late.:-)
> 
> There's no dedicated discussion about noc clk, but similar to grf clock,
> please refer to "https://patchwork.kernel.org/patch/9171467/; for add
> pclk_vio_grf to critical clock on the RK3399, and you have agreed on
> that mark vio grf clk as critical. So I agree with your opinion, thanks~

The difference as I see it is, that the GRF parts are _part_ of the usb3 
controller, while the interconnect really is a separate component, 
connecting the controller to the rest of the system.

--  
|  USB3  |[Interconnect][rest of the system]
| [+GRF] |  
--  

So the controller binding + driver should handle all clocks it needs to 
operate. We currently don't model and handle the separate interconnect 
though, so that noc clock should be critical for the time being.


Heiko

--
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 v7 2/2] phy: rockchip-inno-usb2: add a new driver for Rockchip usb2phy

[Heiko Stuebner]

Am Dienstag, 21. Juni 2016, 18:30:05 schrieb Frank Wang:
> The newer SoCs (rk3366, rk3399) take a different usb-phy IP block
> than rk3288 and before, and most of phy-related registers are also
> different from the past, so a new phy driver is required necessarily.
> 
> Signed-off-by: Frank Wang <frank.w...@rock-chips.com>
> Suggested-by: Heiko Stuebner <he...@sntech.de>
> Suggested-by: Guenter Roeck <li...@roeck-us.net>
> Suggested-by: Doug Anderson <diand...@chromium.org>

still looks nice, so still
Reviewed-by: Heiko Stuebner <he...@sntech.de>
--
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 5/5] usb: dwc3: rockchip: add devicetree bindings documentation

[Heiko Stuebner]

Hi William,

Am Dienstag, 21. Juni 2016, 17:11:44 schrieb William Wu:
> On 06/20/2016 10:44 PM, Heiko Stübner wrote:
> > Am Freitag, 17. Juni 2016, 17:18:59 schrieb William Wu:
> >> On 06/17/2016 07:15 AM, Heiko Stübner wrote:
> >>> Am Donnerstag, 2. Juni 2016, 20:34:56 schrieb William Wu:
>  This patch adds the devicetree documentation required for Rockchip
>  USB3.0 core wrapper consisting of USB3.0 IP from Synopsys.
>  
>  It supports DRD mode, and could operate in device mode (SS, HS, FS)
>  and host mode (SS, HS, FS, LS).
>  
>  Signed-off-by: William Wu 
> > 
> > [...]
> > 
>  +Optional clocks:
>  +  "aclk_usb3otg0"   Aclk for specific usb controller clock.
> > 
> > what does this clock do? Also most likely same argument as below.
> 
> Here is partial rk3399 clk tree about usb3:
> 
> aclk_usb3   77   29700 0 0
>   aclk_usb3_grf11
> 29700  0 0
>   aclk_usb3_rksoc_axi_perf 11
> 29700  0 0
>   aclk_usb3otg111
> 29700  0 0
>   aclk_usb3otg011
> 29700  0 0
>   aclk_usb3_noc11
> 29700  0 0
> 
> from the clk tree, and check with our IC designers, we can see that:
> 1. aclk_usb3 is the parent clk of aclk_usb3
> 2. aclk_usb3_grf  is used for both otg0 and otg1 grf, and these usb3 grf
> can be set
> to control otg0 and otg1 controller, but not the phy.
> 3. aclk_usb3otg1 is otg1 controller clk,  aclk_usb3otg0 is otg0
> controller clk.
> 4. aclk_usb3_rksoc_axi_perf is the clk for usb3 performance monitor
> module. 5. aclk_usb3_noc is the clk for soc bus interconnect.
> 
>  +  "aclk_usb3_rksoc_axi_perf"  USB AXI perf clock.  Not present on
>  all
>  platforms.
> >>> 
> >>> The clock names looks pretty strange. What are they for? Especially as
> >>> nothing seems to use them right now.
> >> 
> >> "aclk_usb3_rksoc_axi_perf", it's the clk for usb3 performance monitor
> >> module, you can refer to the GRF_USB3_PERF_xxx. And we don't use the
> >> usb3
> >> performance monitor control registers right now.
> > 
> > ok, then I'd suggest not defining the clock for now.
> > 
> > For one, there are more perf blocks in the GRF (usb3, pcie, hdcp22,
> > gmac, gpu, etc) which all seem to share a somewhat similar design, so
> > they will maybe result in a separate driver of some form for the
> > performance monitors.
> > 
> > And secondly, it is somewhat easy to add new optional properties, but
> > you
> > cannot remove anything defined previously. So if we later decide to
> > handle all the performance monitors differently, you can't remove that
> > clock from the binding again. (or at least only with quite a bit of
> > hassle).
> > 
> > So as this clock isn't used at all yet, I guess it should not get
> > included now.
> 
> Yes, I agree with you. We can remove the aclk_usb3_rksoc_axi_perf right
> now.
>  +  "aclk_usb3_grf"   USB grf clock.  Not present on all platforms.
> >>> 
> >>> for my own education, which part of the GRF does this clock supply?
> >> 
> >> "aclk_usb3_grf", it's the clk for USB3 grf, e.g. GRF_USB3OTGX_CONX
> > 
> > Hmm, this looks more like it belongs to the otg phy?
> > Anyway, also seems unused right now, so same argument as above applies
> > here.
> As I have described above, the "aclk_usb3_grf" is  used for both otg0
> and otg1 grf,
> and these usb3 grf can be set to control otg0 and otg1 controller, but
> not the phy.
> And we have done a test that remove the grf clk, and the result showed
> that usb3
> controller can't work normally. So I think we need the usb3 grf clk.
> 
> So about the usb3 controller clk management, I think it should contain
> the following clk:
> 1.  aclk_usb3otg1
> 2.  aclk_usb3otg0
> 3.  aclk_usb3_grf

correct, aclk_usb3otgX would then be the busclk for each controller if I'm 
not mistaken and the grf clock should also get enabled, like we also plan on 
doing for the vio_grf clock in the display area.

> 4.  aclk_usb3_noc
> For "aclk_usb3_noc", I discuss with our clk manager, the clk is always
> on before,
> but according to upstream maintainer's suggestion, we need to manage the
> noc clk by each module.

can you point me to this discussion? The bus-interconnect is a very separate 
component, which we don't model so far and thus we have all the noc clocks 
simply marked as critical.

As this clock doesn't belong to the actual usb controller block, but said 
separate component, handling it in the controller seems somehow wrong to me.

So my (current) opinion would again be to mark the noc clock as critical for 
the time being.


> and the follow two clk can be removed:
> 1. aclk_usb3
> 2. aclk_usb3_rksoc_axi_perf
> 
> Is it ok?

yep, apart from the noc-clock, this looks great.


Heiko
--
To unsubscribe from 

Re: [PATCH v2 0/5] support rockchip dwc3 driver

[Heiko Stuebner]

Hi William,

Am Freitag, 13. Mai 2016, 17:24:56 schrieb William Wu:
> This series add support for rockchip dwc3 driver,
> and add additional optional properties for specific
> platforms (e.g., rockchip platform).

when submitting new versions of patchsets please also start a new thread.
It is hard to find such new versions in a big threaded mail view later on.

No need to resend this v2, just to keep in mind for later patches.


Heiko
--
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: dwc2: Add extra delay when forcing dr_mode

[Heiko Stuebner]

Am Donnerstag, 4. Februar 2016, 17:50:34 schrieb John Youn:
> Fixes an issue found on rockchip rk3036-based SOC platforms. For some
> reason, the existing msleep(25) is not enough after the force mode. The
> following patch was reported to fix the issue.
> 
> This does increase the probe delay again slightly, but not up to the
> level it was before the original series of patches that this fixes. It
> does not cause any other issues when tested on Synopsys HAPS and Altera
> socfpga platforms.
> 
> Need to revisit this series next release to see if we can address these
> issues without having an unconditional delay.
> 
> Fixes: 09c96980dc72 ("usb: dwc2: Add functions to set and clear force
> mode") Reported-by: Caesar Wang <caesar.upstr...@gmail.com>
> Tested-by: Caesar Wang <caesar.upstr...@gmail.com>
> Signed-off-by: John Youn <johny...@synopsys.com>

Tested-by: Heiko Stuebner <he...@sntech.de>
(also on a rk3036 where I hit the described problem)

--
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: dwc2: host: Properly set the HFIR

[Heiko Stuebner]

Am Freitag, 22. Januar 2016, 15:56:10 schrieb Douglas Anderson:
> According to the most up to date version of the dwc2 databook, the FRINT
> field of the HFIR register should be programmed to:
> * 125 us * (PHY clock freq for HS) - 1
> * 1000 us * (PHY clock freq for FS/LS) - 1
> 
> This is opposed to older versions of the doc that claimed it should be:
> * 125 us * (PHY clock freq for HS)
> * 1000 us * (PHY clock freq for FS/LS)
> 
> In case you didn't spot it, the difference is the "- 1".
> 
> Let's add the "- 1" to match the newest user manual.  It's presumed that
> the "- 1" should have always been there and that this was always a
> documentation error.  If some hardware needs the "- 1" and other
> hardware doesn't, we'll have to add a configuration parameter for it in
> the future.

Same setup and description as in Doug's 21-patch series, so on a
veyron-jerry:

Tested-by: Heiko Stuebner <he...@sntech.de>


Heiko
--
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/21] usb: dwc2: host: Fix and speed up all the stuff, especially with splits

[Heiko Stuebner]

Hi,

Am Freitag, 22. Januar 2016, 10:18:35 schrieb Douglas Anderson:
> This is a bit of catchall series for all the bug fix and performance
> patches I've been working on over the last few months.  Note that for
> dwc2 we need to do LOTS in software and need super low interrupt
> latency, so most performance improvements actually fix real bugs.
> 
> Patches are structured to start with no-brainer stuff that could be
> applied ASAP, especially things I've already gotten Acks for.  Things
> get slightly more RFC / RFT like as we get farther down the series.
> Anything that can be landed sooner rather than later (especially those
> Acked long ago) would help in re-posts (I'm not biased, of course).
> 
> It's been a few months since my last post of this series.  In the
> meantime I've added a bunch of small bugfixes to the start of it and
> also TOTALLY REWROTE the microframe scheduler.  I'll say up front: I
> know nothing about USB.  I haven't read the whole spec.  I'm not
> terribly familiar with the OHCI, EHCI, and XHCI drivers in the kernel.
> ...and I'm pretty clueless overall.  Nevertheless, I've attempted to
> write up a fancy scheduler based on the portion of the spec talking
> about microframe scheduling requirements.  This rewritten scheduler does
> seem to help when I start jamming lots of USB things into a hub, so
> presumably the code is a reasonably starting point.  Given my current
> understanding of USB the old code was fairly insane, so presumably even
> if my new patch isn't perfect it's better than what we had.

I've tested this series (+the low-speed fix from today) on the following
usb-tree on a rk3288-veyron-jerry:

/:  Bus 03.Port 1: Dev 1, Class=root_hub, Driver=ehci-platform/1p, 480M
|__ Port 1: Dev 2, If 0, Class=Video, Driver=, 480M
|__ Port 1: Dev 2, If 1, Class=Video, Driver=, 480M
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=dwc2/1p, 480M
|__ Port 1: Dev 2, If 0, Class=Vendor Specific Class, Driver=zd1211rw, 480M
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=dwc2/1p, 480M
|__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/5p, 480M
|__ Port 1: Dev 3, If 0, Class=Vendor Specific Class, Driver=smsc95xx, 
480M
|__ Port 3: Dev 4, If 0, Class=Hub, Driver=hub/4p, 480M
|__ Port 1: Dev 6, If 0, Class=Vendor Specific Class, Driver=, 12M
|__ Port 3: Dev 8, If 0, Class=Hub, Driver=hub/4p, 480M
|__ Port 1: Dev 10, If 0, Class=Human Interface Device, 
Driver=usbhid, 1.5M
|__ Port 1: Dev 10, If 1, Class=Human Interface Device, 
Driver=usbhid, 1.5M
|__ Port 2: Dev 11, If 0, Class=Human Interface Device, 
Driver=usbhid, 1.5M
|__ Port 2: Dev 11, If 1, Class=Human Interface Device, 
Driver=usbhid, 1.5M
|__ Port 3: Dev 12, If 0, Class=Human Interface Device, 
Driver=usbhid, 1.5M
|__ Port 4: Dev 13, If 0, Class=Mass Storage, 
Driver=usb-storage, 480M
|__ Port 4: Dev 9, If 0, Class=Human Interface Device, 
Driver=usbhid, 1.5M
|__ Port 4: Dev 5, If 0, Class=Mass Storage, Driver=usb-storage, 480M
|__ Port 5: Dev 7, If 0, Class=Mass Storage, Driver=usb-storage, 480M


At first we were maxing out the 9 channels of the otg port, which the
driver didn't seem to care about in 4.4-rc6, but after realizing that and
switching over to the 16ch host-port it ran really nicely, especially wrt
faster handling of all the keyboard input.

When looking over to the other desk and the person using that veyron-
jerry not cursing anymore, it seem to be running fine in a real-world use
for 2 hours now ;-)

So,
Tested-by: Heiko Stuebner <he...@sntech.de>


> The patches here will speed up the interrupt controller significantly.
> After this series, I have a hard time seeing the interrupt controller
> taking > 20 us and I don't ever see it taking > 30 us ever in my tests
> unless I bring the cpufreq back down.  With the cpufreq at 126 MHz I can
> still see the interrupt handler take > 50 us, so I'm sure we could
> improve this further.  ...but hey, it's a start.

In the configuration described above, we were still able to run the
interrupt handlers capabilities when the cpufreq is at 126MHz, but
once set to a sane minimum it is running really nice now.


Heiko
--
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 0/2] usb: dwc2: Fix regressions on bcm2835

[Heiko Stuebner]

Am Montag, 11. Januar 2016, 16:32:00 schrieb John Youn:
> This series fixes a couple regressions reported on Raspberry Pi.

same regressions (Isaw strange usb resets) seem to affect Rockchip as well 
and these two patches seem to fix that there too, so

Tested-by: Heiko Stuebner <he...@sntech.de>
--
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/3] dwc2: Speed up the interrupt handler quite a bit

[Heiko Stuebner]

Am Mittwoch, 4. November 2015, 14:53:02 schrieb Douglas Anderson:
> The dwc2 interrupt handler is quite slow.  On rk3288 with a few things
> plugged into the ports and with cpufreq locked at 696MHz (to simulate
> real world idle system), I can easily observe dwc2_handle_hcd_intr()
> taking > 120 us, sometimes > 150 us.  Note that SOF interrupts come
> every 125 us with high speed USB, so taking > 120 us in the interrupt
> handler is a big deal.
> 
> The patches here will speed up the interrupt controller significantly.
> After this series, I have a hard time seeing the interrupt controller
> taking > 20 us and I don't ever see it taking > 30 us ever in my tests
> unless I bring the cpufreq back down.  With the cpufreq at 126 MHz I can
> still see the interrupt handler take > 50 us, so I'm sure we could
> improve this further.  ...but hey, it's a start.
> 
> In addition to the speedup, this series also has the advantage of
> simplifying dwc2 and making it more like everyone else (introducing the
> possibility of future simplifications).  Picking this series up will
> help your diffstat and likely win you friends.  ;)

I gave this a simple spin on my veyron-pinky with both a device attached 
directly to the port as well as with an usb-hub in between. Everything was 
still working smoothly, so

Tested-by: Heiko Stuebner <he...@sntech.de>
--
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: dwc2: host: Fix remote wakeup when not in DWC2_L2

[Heiko Stuebner]

Am Donnerstag, 22. Oktober 2015, 13:05:03 schrieb Douglas Anderson:
> In commit 734643dfbdde ("usb: dwc2: host: add flag to reflect bus
> state") we changed dwc2_port_suspend() not to set the lx_state
> anymore (instead it sets the new bus_suspended variable).  This
> introduced a bug where we would fail to detect device insertions if:
> 
> 1. Plug empty hub into dwc2
> 2. Plug USB flash drive into the empty hub.
> 3. Wait a few seconds
> 4. Unplug USB flash drive
> 5. Less than 2 seconds after step 4, plug the USB flash drive in again.
> 
> The dwc2_hcd_rem_wakeup() function should have been changed to look at
> the new bus_suspended variable.
> 
> Let's fix it.  Since commit b46146d59fda ("usb: dwc2: host: resume root
> hub on remote wakeup") talks about needing the root hub resumed if the
> bus was suspended, we'll include it in our test.
> 
> It appears that the "port_l1_change" should only be set to 1 if we were
> in DWC2_L1 (the driver currently never sets this), so we'll update the
> former "else" case based on this test.
> 
> Fixes: 734643dfbdde ("usb: dwc2: host: add flag to reflect bus state")
> Signed-off-by: Douglas Anderson <diand...@chromium.org>

I've talked with Doug a lot about that problem today and from reading
this change and the referenced causing change, it looks correct
and good to me, so

Reviewed-by: Heiko Stuebner <he...@sntech..de>


--
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 00/22] usb: third series of updates for dwc2 driver

[Heiko Stuebner]

Hi,

Am Mittwoch, 29. April 2015, 22:08:58 schrieb Mian Yousaf Kaukab:
 Hi,
 This patchset consists of some bug fixes and feature enhancements for
 the dwc2 driver. All the patches are verified on dwc2 v3.0a with
 dedicated fifos. Main focus of testing was with dma enabled. Although
 basic testing without dma was also done.
 
 This is based on testing/next branch in Felipe's git.
 
 Thank you,
 
 Best regards,
 Yousaf
 
 History:
 v5:
  - Fixed comments from Felipe Balbi
 v4:
  - Fixed comment from Julius Werner
 v3:
  - Fixed comments from Julius Werner and Sergei Shtylyov
  - Dropped usb: dwc2: allow dwc2_pci to be a module even when dwc2 is
 statically linked due to
 http://marc.info/?l=linux-usbm=142661773703793w=2
  - usb: dwc2: host: ensure qtb exists before dereferencing it is added
to fix a NULL pointer dereferencing bug
 v2:
  - Fixed comments from John Youn and Julius Werner
  - Fixed regression, found by John, when switching to gadget mode
after running host mode
  - Added patch to add core parameter for enabling/disabling hibernation
  - Added patch to build dwc2_pci.ko independent from dwc2.ko
 v1:
  - Fixed comments from John Youn and Robert Baldyga
  - Dropped all changes to pci.c due to
http://permalink.gmane.org/gmane.linux.usb.general/123411
  - Added patch to remove unnecessary EXPORT_SYMBOL_GPL calls

With this series applied I get the warning below about a sleeping
function, that is not present without it. This happens quite often (on boot,
when going to suspend, etc).

Other than that, usb still works and the dwc2 now also
finally suspends :-D, so on a rk3288

Tested-by: Heiko Stuebner he...@sntech.de

-- 8 --
[   19.799200] BUG: sleeping function called from invalid context at 
mm/slab.c:2863
[   19.806601] in_atomic(): 1, irqs_disabled(): 128, pid: 101, name: kworker/0:2
[   19.813728] INFO: lockdep is turned off.
[   19.817649] irq event stamp: 0
[   19.820702] hardirqs last  enabled at (0): [  (null)]   (null)
[   19.826720] hardirqs last disabled at (0): [c00273f4] 
copy_process.part.46+0x430/0x1784
[   19.834916] softirqs last  enabled at (0): [c00273f4] 
copy_process.part.46+0x430/0x1784
[   19.843104] softirqs last disabled at (0): [  (null)]   (null)
[   19.849126] CPU: 0 PID: 101 Comm: kworker/0:2 Tainted: GW   
4.1.0-rc4+ #1963
[   19.857208] Hardware name: Rockchip (Device Tree)
[   19.861916] Workqueue: events usbnet_deferred_kevent
[   19.866910] [c00189a0] (unwind_backtrace) from [c0013b04] 
(show_stack+0x20/0x24)
[   19.874659] [c0013b04] (show_stack) from [c075c154] 
(dump_stack+0x8c/0xbc)
[   19.881888] [c075c154] (dump_stack) from [c0053188] 
(___might_sleep+0x238/0x284)
[   19.889636] [c0053188] (___might_sleep) from [c0053264] 
(__might_sleep+0x90/0xa4)
[   19.897468] [c0053264] (__might_sleep) from [c0154aa8] 
(kmem_cache_alloc_trace+0x90/0x3e0)
[   19.906081] [c0154aa8] (kmem_cache_alloc_trace) from [c0442a68] 
(_dwc2_hcd_urb_enqueue+0x298/0x464)
[   19.915476] [c0442a68] (_dwc2_hcd_urb_enqueue) from [c042a748] 
(usb_hcd_submit_urb+0x7bc/0x8f0)
[   19.924522] [c042a748] (usb_hcd_submit_urb) from [c042c158] 
(usb_submit_urb+0x45c/0x4ac)
[   19.932961] [c042c158] (usb_submit_urb) from [c042cc60] 
(usb_start_wait_urb+0x54/0x148)
[   19.941314] [c042cc60] (usb_start_wait_urb) from [c042cf44] 
(usb_control_msg+0xac/0xe0)
[   19.949668] [c042cf44] (usb_control_msg) from [c041c4d4] 
(__usbnet_read_cmd+0xc0/0x104)
[   19.958021] [c041c4d4] (__usbnet_read_cmd) from [c041c63c] 
(usbnet_read_cmd+0x64/0x84)
[   19.966294] [c041c63c] (usbnet_read_cmd) from [bf13c790] 
(__smsc95xx_read_reg+0x68/0xa4 [smsc95xx])
[   19.975698] [bf13c790] (__smsc95xx_read_reg [smsc95xx]) from [bf13c80c] 
(__smsc95xx_phy_wait_not_busy+0x40/0x8c [smsc95xx])
[   19.987180] [bf13c80c] (__smsc95xx_phy_wait_not_busy [smsc95xx]) from 
[bf13cd04] (__smsc95xx_mdio_read+0x48/0x110 [smsc95xx])
[   19.998836] [bf13cd04] (__smsc95xx_mdio_read [smsc95xx]) from [bf13cde8] 
(smsc95xx_mdio_read+0x1c/0x20 [smsc95xx])
[   20.009539] [bf13cde8] (smsc95xx_mdio_read [smsc95xx]) from [bf13ce34] 
(smsc95xx_link_reset+0x48/0x2d4 [smsc95xx])
[   20.020237] [bf13ce34] (smsc95xx_link_reset [smsc95xx]) from [c041f7e4] 
(usbnet_deferred_kevent+0x244/0x344)
[   20.030410] [c041f7e4] (usbnet_deferred_kevent) from [c0044d28] 
(process_one_work+0x360/0x7f4)
[   20.039367] [c0044d28] (process_one_work) from [c00454a8] 
(worker_thread+0x2b0/0x414)
[   20.047546] [c00454a8] (worker_thread) from [c004afe8] 
(kthread+0x104/0x11c)
[   20.054947] [c004afe8] (kthread) from [c0010010] 
(ret_from_fork+0x14/0x24)
[   20.062456] smsc95xx 2-1.1:1.0 eth0: kevent 4 may have been dropped
[   20.071768] smsc95xx 2-1.1:1.0 eth0: link up, 100Mbps, full-duplex, lpa 
0x4DE1
[   20.089180] smsc95xx 2-1.1:1.0 eth0: link up, 100Mbps, full-duplex, lpa 
0x4DE1

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