RE: Regarding the patch "let USB device know device node"

[Peter Chen]

 
>Hey Hi Peter,
>
>I hope you are doing good.
>
>We probably have similar usecase of yours as far as "let USB device know device
>node"
>is concerned.
>we have a device, where HUB is connected to one of USB port, and due to lack of
>control path from DT, it is always hard to maintain (manage)
>2 different devices (one is USB + One Platform).
>

two different devices? For example?

>When I looked at the mainline kernel, I realized no one is still making use of 
>the
>feature. I wanted to check with you whether you have any reference code which 
>you
>can share ?
>Any driver reference would be great.
>
 
My pwrseq library patchset [1] and Rafal's USB trigger patch are example.
Besides, I know some USB Ethernet driver which need it to know MAC
address also use it.


[1] http://www.spinics.net/lists/linux-usb/msg143700.html
[2] http://www.spinics.net/lists/linux-usb/msg143862.html

BRs,
Peter

Re: [PATCH v8 3/3] arm64: dts: rockchip: add usb2-phy support for rk3399

[Frank Wang]

Hi Doug,

On 2016/7/21 5:33, Doug Anderson wrote:

Hi,

On Tue, Jul 19, 2016 at 12:28 AM, Frank Wang  wrote:

You need a patch description here, even for simple patches.  All you
have now is a subject.



OK, I will describe it next version.


Signed-off-by: Frank Wang 
---
  arch/arm64/boot/dts/rockchip/rk3399-evb.dts |   19 +++
  arch/arm64/boot/dts/rockchip/rk3399.dtsi|   47 ++-

Personally I'd prefer to see EVB in a separate patch.



Yep, I would like to separate them :-) .


  2 files changed, 65 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/rockchip/rk3399-evb.dts 
b/arch/arm64/boot/dts/rockchip/rk3399-evb.dts
index 1a3eb14..31d4828 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-evb.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3399-evb.dts
@@ -69,6 +69,15 @@
 regulator-max-microvolt = <330>;
 };

+   vbus_host: vbus-host-regulator {
+   compatible = "regulator-fixed";
+   enable-active-high;
+   gpio = < 25 GPIO_ACTIVE_HIGH>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_vbus_drv>;
+   regulator-name = "vbus_host";
+   };
+

To match my schematics, this would probably be "vcc5v0_host".
Technically there are two regulators but since they are the same
voltage and enabled by the same GPIO it seems like modeling it as one
regulator is fine.


Yep, you are right, I will rename it.


If you really wanted to model things you could also include the input
supply (VCC5V0_SYS).  Not sure how much you care to model in EVB.



Actually, from 
"Documentation/devicetree/bindings/regulator/fixed-regulator.txt" show, 
input supply name is just optional property, and it seems that only do 
assign "vin" value for input_supply (the second member of struct 
fixed_voltage_config) if "vin-supply" is specified.


So is input supply name  (VCC5V0_SYS) required here? Would you like to 
give more comments please?



 vcc_phy: vcc-phy-regulator {
 compatible = "regulator-fixed";
 regulator-name = "vcc_phy";
@@ -93,6 +102,16 @@
 status = "okay";
  };

+_host {
+   phy-supply = <_host>;
+   status = "okay";
+};
+
+_host {
+   phy-supply = <_host>;
+   status = "okay";
+};
+

Technically "u2" sorts alphabetically before "uart".



Well, It will be sorted next version.


  _host0_ehci {
 status = "okay";
  };
diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi 
b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index d7f8e06..0383785 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -221,6 +221,8 @@
 interrupts = ;
 clocks = < HCLK_HOST0>, < HCLK_HOST0_ARB>;
 clock-names = "hclk_host0", "hclk_host0_arb";
+   phys = <_host>;
+   phy-names = "u2phy0";

This is wrong.  From
"Documentation/devicetree/bindings/usb/usb-ehci.txt" phy-names should
be "usb".


done.


 status = "disabled";
 };

@@ -239,6 +241,8 @@
 interrupts = ;
 clocks = < HCLK_HOST1>, < HCLK_HOST1_ARB>;
 clock-names = "hclk_host1", "hclk_host1_arb";
+   phys = <_host>;
+   phy-names = "u2phy1";

This is wrong.  From
"Documentation/devicetree/bindings/usb/usb-ehci.txt" phy-names should
be "usb".


done


 status = "disabled";
 };

@@ -481,8 +485,42 @@
 };

 grf: syscon@ff77 {
-   compatible = "rockchip,rk3399-grf", "syscon";
+   compatible = "rockchip,rk3399-grf", "syscon", "simple-mfd";
 reg = <0x0 0xff77 0x0 0x1>;
+   #address-cells = <1>;
+   #size-cells = <1>;
+
+   u2phy0: usb2-phy@e450 {
+   compatible = "rockchip,rk3399-usb2phy";
+   reg = <0xe450 0x10>;
+   clocks = < SCLK_USB2PHY0_REF>;
+   clock-names = "phyclk";
+   #clock-cells = <0>;
+   clock-output-names = "clk_usbphy0_480m";

Any reason why there isn't a 'status = "disabled";' here?



Refer to some explains from Heiko in another mail which sent at 6:07 AM 
on 21th July,  anyway, I will add ' status = "disabled" ' property next 
version.



+   u2phy0_host: host-port {
+   #phy-cells = <0>;
+   interrupts = ;
+   interrupt-names = "linestate";
+   status = "disabled";
+   };
+   };
+
+   u2phy1: usb2-phy@e460 {
+   compatible = "rockchip,rk3399-usb2phy";
+   reg = <0xe460 0x10>;
+   clocks = < SCLK_USB2PHY1_REF>;
+ 

Re: Fwd: USB HID problem

[Alan Stern]

On Wed, 20 Jul 2016, Bruce Korb wrote:

> Hi Alan,
> 
> I swapped the driver, so usb_device_supports_lpm() always returns "0".
> No change.  Bandwidth for a Class 10 SSD, but not for a mouse or

FYI, a Class 10 SSD does not have any bandwidth requirement.  If very 
little bandwidth is available, the SSD won't work very well but it will 
still work.  By contrast, a mouse or a keyboard does have a minimum 
bandwidth requirement.  It isn't at all large, but if the system can't 
guarantee that minimum then it won't accept the mouse/keyboard.

> keyboard.  There is a new message that I've not seen before,
> hub_port_status failed (err = -71) === EPROTO

Probably not important, unless it occurs regularly.

> [   64.792800] usb 2-1.1: Product: Gaming Mouse G400
> [   64.792804] usb 2-1.1: Manufacturer: Logitech
> 
> [   64.793125] usb 2-1.1: Not enough bandwidth for new device state.
> 
> [   64.793134] usb 2-1.1: can't set config #1, error -28
> [   64.82] usb 2-1.2: new full-speed USB device number 4 using xhci_hcd
> [   64.963478] usb 2-1.2: New USB device found, idVendor=05ac, idProduct=1002
> [   64.963486] usb 2-1.2: New USB device strings: Mfr=1, Product=2,
> SerialNumber=0
> [   64.963491] usb 2-1.2: Product: Hub in Apple Extended USB Keyboard
> [   64.963494] usb 2-1.2: Manufacturer: Mitsumi Electric
> [   64.963769] usb 2-1.2: ep 0x81 - rounding interval to 1024
> microframes, ep desc says 2040 microframes
> 
> [   64.963854] usb 2-1.2: Not enough bandwidth for new device state.
> 
> [   64.963862] usb 2-1.2: can't set config #1, error -28

Have you tried earlier kernel versions to see if they will work?

Alan Stern

--
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: Fwd: USB HID problem

[Bruce Korb]

Hi Alan,

I swapped the driver, so usb_device_supports_lpm() always returns "0".
No change.  Bandwidth for a Class 10 SSD, but not for a mouse or
keyboard.  There is a new message that I've not seen before,
hub_port_status failed (err = -71) === EPROTO

$ lsusb -t
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 480M
   |__ Port 1: Dev 10, If 0, Class=Hub, Driver=hub/4p, 480M
   |__ Port 4: Dev 13, If 0, Class=Mass Storage, Driver=usb-storage, 480M
   |__ Port 4: Dev 13, If 1, Class=Chip/SmartCard, Driver=, 480M

Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 010: ID 05e3:0610 Genesys Logic, Inc. 4-port hub
Bus 002 Device 011: ID 046d:c245 Logitech, Inc. G400 Optical Mouse
Bus 002 Device 012: ID 05ac:1002 Apple, Inc. Extended Keyboard Hub [Mitsumi]
Bus 002 Device 013: ID 048d:1366 Integrated Technology Express, Inc.

[   64.151834] usb 3-1: new SuperSpeed USB device number 2 using xhci_hcd
[   64.177249] usb 3-1: New USB device found, idVendor=05e3, idProduct=0617
[   64.177256] usb 3-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[   64.177261] usb 3-1: Product: USB3.0 Hub
[   64.177264] usb 3-1: Manufacturer: GenesysLogic
[   64.178851] hub 3-1:1.0: USB hub found
[   64.180975] hub 3-1:1.0: 4 ports detected
[   64.279431] usb 2-1: new high-speed USB device number 2 using xhci_hcd

[   64.284944] hub 3-1:1.0: hub_port_status failed (err = -71)

[   64.413740] usb 2-1: New USB device found, idVendor=05e3, idProduct=0610
[   64.413747] usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[   64.413752] usb 2-1: Product: USB2.0 Hub
[   64.413756] usb 2-1: Manufacturer: GenesysLogic
[   64.414637] hub 2-1:1.0: USB hub found
[   64.416752] hub 2-1:1.0: 4 ports detected
[   64.694900] usb 2-1.1: new full-speed USB device number 3 using xhci_hcd
[   64.792788] usb 2-1.1: New USB device found, idVendor=046d, idProduct=c245
[   64.792795] usb 2-1.1: New USB device strings: Mfr=1, Product=2,
SerialNumber=0
[   64.792800] usb 2-1.1: Product: Gaming Mouse G400
[   64.792804] usb 2-1.1: Manufacturer: Logitech

[   64.793125] usb 2-1.1: Not enough bandwidth for new device state.

[   64.793134] usb 2-1.1: can't set config #1, error -28
[   64.82] usb 2-1.2: new full-speed USB device number 4 using xhci_hcd
[   64.963478] usb 2-1.2: New USB device found, idVendor=05ac, idProduct=1002
[   64.963486] usb 2-1.2: New USB device strings: Mfr=1, Product=2,
SerialNumber=0
[   64.963491] usb 2-1.2: Product: Hub in Apple Extended USB Keyboard
[   64.963494] usb 2-1.2: Manufacturer: Mitsumi Electric
[   64.963769] usb 2-1.2: ep 0x81 - rounding interval to 1024
microframes, ep desc says 2040 microframes

[   64.963854] usb 2-1.2: Not enough bandwidth for new device state.

[   64.963862] usb 2-1.2: can't set config #1, error -28
[   65.034442] usb 2-1.4: new high-speed USB device number 5 using xhci_hcd
[   65.536523] usb 2-1.4: New USB device found, idVendor=048d, idProduct=1366
[   65.536530] usb 2-1.4: New USB device strings: Mfr=1, Product=2,
SerialNumber=3
[   65.536535] usb 2-1.4: Product: MultiCard Device
[   65.536539] usb 2-1.4: Manufacturer: Generic
[   65.536543] usb 2-1.4: SerialNumber: 0006
[   65.573533] usb-storage 2-1.4:1.0: USB Mass Storage device detected
[   65.573728] scsi host7: usb-storage 2-1.4:1.0
[   65.573981] usbcore: registered new interface driver usb-storage
[   65.574986] usbcore: registered new interface driver uas
[   67.406587] scsi 7:0:0:0: Direct-Access Generic  Storage Device
  0.00 PQ: 0 ANSI: 2
[   67.407200] sd 7:0:0:0: [sdd] 62521344 512-byte logical blocks:
(32.0 GB/29.8 GiB)
[   67.407418] sd 7:0:0:0: [sdd] Write Protect is off
[   67.407428] sd 7:0:0:0: [sdd] Mode Sense: 23 00 00 00
[   67.407459] sd 7:0:0:0: Attached scsi generic sg4 type 0
[   67.407656] sd 7:0:0:0: [sdd] Write cache: disabled, read cache:
enabled, doesn't support DPO or FUA
[   67.410939]  sdd: sdd1
[   67.413436] sd 7:0:0:0: [sdd] Attached SCSI removable disk
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v8 3/3] arm64: dts: rockchip: add usb2-phy support for rk3399

[Heiko Stübner]

Am Mittwoch, 20. Juli 2016, 14:33:25 schrieb Doug Anderson:
> > +   #address-cells = <1>;
> > +   #size-cells = <1>;
> > +
> > +   u2phy0: usb2-phy@e450 {
> > +   compatible = "rockchip,rk3399-usb2phy";
> > +   reg = <0xe450 0x10>;
> > +   clocks = < SCLK_USB2PHY0_REF>;
> > +   clock-names = "phyclk";
> > +   #clock-cells = <0>;
> > +   clock-output-names = "clk_usbphy0_480m";
> 
> Any reason why there isn't a 'status = "disabled";' here?

my guess would be, because we might need the provided clock anyway, even in 
the case where the actual phy is not used.

But that is better decided by the board/board-dts designer if the clock is 
really needed, so add the disabled here and enable in the board, as Doug 
suggested.


> > +   u2phy0_host: host-port {
> > +   #phy-cells = <0>;
> > +   interrupts =  > IRQ_TYPE_LEVEL_HIGH>; +   interrupt-names =
> > "linestate";
> > +   status = "disabled";
> > +   };
> > +   };
> > +
> > +   u2phy1: usb2-phy@e460 {
> > +   compatible = "rockchip,rk3399-usb2phy";
> > +   reg = <0xe460 0x10>;
> > +   clocks = < SCLK_USB2PHY1_REF>;
> > +   clock-names = "phyclk";
> > +   #clock-cells = <0>;
> > +   clock-output-names = "clk_usbphy1_480m";
> > +
> > +   u2phy1_host: host-port {
> > +   #phy-cells = <0>;
> > +   interrupts =  > IRQ_TYPE_LEVEL_HIGH>; +   interrupt-names =
> > "linestate";
> > +   status = "disabled";
> > +   };
> > +   };
> > 
> > };
> > 
> > watchdog@ff84 {
> > 
> > @@ -1009,5 +1047,12 @@
> > 
> > <1 14 RK_FUNC_1 _pull_none>;
> > 
> > };
> > 
> > };
> > 
> > +
> > +   usb2 {
> > +   host_vbus_drv: host-vbus-drv {
> > +   rockchip,pins =
> > +   <4 25 RK_FUNC_GPIO
> > _pull_none>; +   };
> > +   };
> 
> Are you certain this belongs in rk3399.dtsi?  It seems like it should
> be in the EVB file.

yep, while most boards follow a reference design, this is still highly board-
specific.
--
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 net-next v3] cdc_ether: Improve ZTE MF823/831/910 handling

[David Miller]

From: Kristian Evensen 
Date: Tue, 19 Jul 2016 16:54:11 +0200

> The firmware in several ZTE devices (at least the MF823/831/910
> modems/mifis) use OS fingerprinting to determine which type of device to
> export. In addition, these devices export a REST API which can be used to
> control the type of device. So far, on Linux, the devices have been seen as
> RNDIS or CDC Ether.
> 
> When CDC Ether is used, devices of the same type are, as with RNDIS,
> exported with the same, bogus random MAC address. In addition, the devices
> (at least on all firmware revisions I have found) use the bogus MAC when
> sending traffic routed from external networks. And as a final feature, the
> devices sometimes export the link state incorrectly. There are also
> references online to several other ZTE devices displaying this behavior,
> with several different PIDs and MAC addresses.
> 
> This patch tries to improve the handling of ZTE devices by doing the
> following:

Please fix these warnings and resubmit:

  CC [M]  drivers/net/usb/cdc_ether.o
drivers/net/usb/cdc_ether.c: In function ‘usbnet_cdc_zte_rx_fixup’:
drivers/net/usb/cdc_ether.c:461:5: warning: unused variable ‘buggy_hwaddrs_idx’ 
[-Wunused-variable]
  u8 buggy_hwaddrs_idx = 0;
 ^
drivers/net/usb/cdc_ether.c:460:5: warning: unused variable ‘num_buggy_hwaddrs’ 
[-Wunused-variable]
  u8 num_buggy_hwaddrs;
 ^

Re: [PATCH v8 3/3] arm64: dts: rockchip: add usb2-phy support for rk3399

[Doug Anderson]

Hi,

On Tue, Jul 19, 2016 at 12:28 AM, Frank Wang  wrote:

You need a patch description here, even for simple patches.  All you
have now is a subject.


> Signed-off-by: Frank Wang 
> ---
>  arch/arm64/boot/dts/rockchip/rk3399-evb.dts |   19 +++
>  arch/arm64/boot/dts/rockchip/rk3399.dtsi|   47 
> ++-

Personally I'd prefer to see EVB in a separate patch.


>  2 files changed, 65 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/boot/dts/rockchip/rk3399-evb.dts 
> b/arch/arm64/boot/dts/rockchip/rk3399-evb.dts
> index 1a3eb14..31d4828 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3399-evb.dts
> +++ b/arch/arm64/boot/dts/rockchip/rk3399-evb.dts
> @@ -69,6 +69,15 @@
> regulator-max-microvolt = <330>;
> };
>
> +   vbus_host: vbus-host-regulator {
> +   compatible = "regulator-fixed";
> +   enable-active-high;
> +   gpio = < 25 GPIO_ACTIVE_HIGH>;
> +   pinctrl-names = "default";
> +   pinctrl-0 = <_vbus_drv>;
> +   regulator-name = "vbus_host";
> +   };
> +

To match my schematics, this would probably be "vcc5v0_host".
Technically there are two regulators but since they are the same
voltage and enabled by the same GPIO it seems like modeling it as one
regulator is fine.

If you really wanted to model things you could also include the input
supply (VCC5V0_SYS).  Not sure how much you care to model in EVB.


> vcc_phy: vcc-phy-regulator {
> compatible = "regulator-fixed";
> regulator-name = "vcc_phy";
> @@ -93,6 +102,16 @@
> status = "okay";
>  };
>
> +_host {
> +   phy-supply = <_host>;
> +   status = "okay";
> +};
> +
> +_host {
> +   phy-supply = <_host>;
> +   status = "okay";
> +};
> +

Technically "u2" sorts alphabetically before "uart".


>  _host0_ehci {
> status = "okay";
>  };
> diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi 
> b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> index d7f8e06..0383785 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> +++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> @@ -221,6 +221,8 @@
> interrupts = ;
> clocks = < HCLK_HOST0>, < HCLK_HOST0_ARB>;
> clock-names = "hclk_host0", "hclk_host0_arb";
> +   phys = <_host>;
> +   phy-names = "u2phy0";

This is wrong.  From
"Documentation/devicetree/bindings/usb/usb-ehci.txt" phy-names should
be "usb".

> status = "disabled";
> };
>
> @@ -239,6 +241,8 @@
> interrupts = ;
> clocks = < HCLK_HOST1>, < HCLK_HOST1_ARB>;
> clock-names = "hclk_host1", "hclk_host1_arb";
> +   phys = <_host>;
> +   phy-names = "u2phy1";

This is wrong.  From
"Documentation/devicetree/bindings/usb/usb-ehci.txt" phy-names should
be "usb".

> status = "disabled";
> };
>
> @@ -481,8 +485,42 @@
> };
>
> grf: syscon@ff77 {
> -   compatible = "rockchip,rk3399-grf", "syscon";
> +   compatible = "rockchip,rk3399-grf", "syscon", "simple-mfd";
> reg = <0x0 0xff77 0x0 0x1>;
> +   #address-cells = <1>;
> +   #size-cells = <1>;
> +
> +   u2phy0: usb2-phy@e450 {
> +   compatible = "rockchip,rk3399-usb2phy";
> +   reg = <0xe450 0x10>;
> +   clocks = < SCLK_USB2PHY0_REF>;
> +   clock-names = "phyclk";
> +   #clock-cells = <0>;
> +   clock-output-names = "clk_usbphy0_480m";

Any reason why there isn't a 'status = "disabled";' here?


> +   u2phy0_host: host-port {
> +   #phy-cells = <0>;
> +   interrupts = ;
> +   interrupt-names = "linestate";
> +   status = "disabled";
> +   };
> +   };
> +
> +   u2phy1: usb2-phy@e460 {
> +   compatible = "rockchip,rk3399-usb2phy";
> +   reg = <0xe460 0x10>;
> +   clocks = < SCLK_USB2PHY1_REF>;
> +   clock-names = "phyclk";
> +   #clock-cells = <0>;
> +   clock-output-names = "clk_usbphy1_480m";
> +
> +   u2phy1_host: host-port {
> +   #phy-cells = <0>;
> +   interrupts = ;
> +   interrupt-names = "linestate";
> +   status = "disabled";
> +   };
> +   };
> };
>
> watchdog@ff84 {
> @@ -1009,5 +1047,12 @@
> <1 14 RK_FUNC_1 _pull_none>;
>  

Re: Fwd: USB HID problem

[Bruce Korb]

Hi Alan,

On Mon, Jul 18, 2016 at 6:09 PM, Alan Stern  wrote:
>> Given the repeatability, maybe I can dig into where stuff is going awry.
>> Maybe I can trace down how the bogus speed information is derived.
>
> If my guess was correct, there is no bogus speed information.

OK.

>> I do not believe "Link Power Management" is enabled, but don't know
>> exactly how to tell, either.  It would not be terribly hard to make xhci_hcd
>> more noisy.
>
> LPM is enabled by default.  You can turn it off in later kernels by
> adding a quirk entry, but I believe 4.1 doesn't include the LPM quirk.

Nope.  Looked for it.

> editing the usb_device_supports_lpm() routine in
> drivers/usb/core/hub.c.  Make it return 0 immediately.  That will be an
> easy way to tell whether my guess was right.

I've disabled it now and rebuilt the kernel.  Yesterday was a
replace-the-kitchen-faucet day, so I will be trying out the new
usbcore module later today.  I didn't vanish :)  I'd do it now, but
I'm in class:

https://www.creativelive.com/courses/creating-painterly-photographs-kathleen-clemons
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 2/3] doc: usb: ci-hdrc-usb2: add property over-current-active-high

[Rob Herring]

On Wed, Jul 20, 2016 at 04:02:41PM +0800, Li Jun wrote:
> Adding over-current-active-high to indicate the over current flag
> is high active as typically we use active low for over current
> polarity.
> 
> Signed-off-by: Li Jun 
> ---
>  Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt | 2 ++
>  1 file changed, 2 insertions(+)

Acked-by: Rob Herring 
--
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: pwc over musb: 100% frame drop (lost) on high resolution stream

[Matwey V. Kornilov]

2016-07-20 18:06 GMT+03:00 Bin Liu :
> Hi,
>
> On Wed, Jul 20, 2016 at 05:44:56PM +0300, Matwey V. Kornilov wrote:
>> 2016-07-20 17:13 GMT+03:00 Bin Liu :
>> > Hi,
>> >
>> > On Wed, Jul 20, 2016 at 09:09:42AM +0300, Matwey V. Kornilov wrote:
>> >> 2016-07-20 0:34 GMT+03:00 Bin Liu :
>> >> > Hi,
>> >> >
>> >> > On Wed, Jul 20, 2016 at 12:25:44AM +0300, Matwey V. Kornilov wrote:
>> >> >> 2016-07-19 23:56 GMT+03:00 Bin Liu :
>> >> >> > Hi,
>> >> >> >
>> >> >> > On Tue, Jul 19, 2016 at 11:21:17PM +0300, mat...@sai.msu.ru wrote:
>> >> >> >> Hello,
>> >> >> >>
>> >> >> >> I have Philips SPC 900 camera (0471:0329) connected to my AM335x 
>> >> >> >> based BeagleBoneBlack SBC.
>> >> >> >> I am sure that both of them are fine and work properly.
>> >> >> >> I am running Linux 4.6.4 (my kernel config is available at 
>> >> >> >> https://clck.ru/A2kQs ) and I've just discovered, that there is an 
>> >> >> >> issue with frame transfer when high resolution formats are used.
>> >> >> >>
>> >> >> >> The issue is the following. I use simple v4l2 example tool (taken 
>> >> >> >> from API docs), which source code is available at 
>> >> >> >> http://pastebin.com/grcNXxfe
>> >> >> >>
>> >> >> >> When I use (see line 488) 640x480 frames
>> >> >> >>
>> >> >> >> fmt.fmt.pix.width   = 640;
>> >> >> >> fmt.fmt.pix.height  = 480;
>> >> >> >>
>> >> >> >> then I get "select timeout" and don't get any frames.
>> >> >> >>
>> >> >> >> When I use 320x240 frames
>> >> >> >>
>> >> >> >> fmt.fmt.pix.width   = 320;
>> >> >> >> fmt.fmt.pix.height  = 240;
>> >> >> >>
>> >> >> >> then about 60% frames are missed. An example outpout of ./a.out -f 
>> >> >> >> is available at https://yadi.sk/d/aRka8xWPtSc4y
>> >> >> >> It looks like there are pauses between bulks of frames (frame 
>> >> >> >> counter and timestamp as returned from v4l2 API):
>> >> >> >>
>> >> >> >> 3 3705.142553
>> >> >> >> 8 3705.342533
>> >> >> >> 13 3705.542517
>> >> >> >> 110 3708.776208
>> >> >> >> 115 3708.976190
>> >> >> >> 120 3709.176169
>> >> >> >> 125 3709.376152
>> >> >> >> 130 3709.576144
>> >> >> >> 226 3712.807848
>> >> >> >>
>> >> >> >> When I use tiny 160x120 frames
>> >> >> >>
>> >> >> >> fmt.fmt.pix.width   = 160;
>> >> >> >> fmt.fmt.pix.height  = 120;
>> >> >> >>
>> >> >> >> then more frames are received. See output example at 
>> >> >> >> https://yadi.sk/d/DedBmH6ftSc9t
>> >> >> >> That is why I thought that everything was fine in May when used 
>> >> >> >> tiny xawtv window to check kernel OOPS presence (see 
>> >> >> >> http://www.spinics.net/lists/linux-usb/msg141188.html for reference)
>> >> >> >>
>> >> >> >> Even more. When I introduce USB hub between the host and the 
>> >> >> >> webcam, I can not receive even any 320x240 frames.
>> >> >> >>
>> >> >> >> I've managed to use ftrace to see what is going on when no frames 
>> >> >> >> are received.
>> >> >> >> I've found that pwc_isoc_handler is called frequently as the 
>> >> >> >> following:
>> >> >> >>
>> >> >> >>  0)   |  pwc_isoc_handler [pwc]() {
>> >> >> >>  0)   |usb_submit_urb [usbcore]() {
>> >> >> >>  0)   |  usb_submit_urb.part.3 [usbcore]() {
>> >> >> >>  0)   |usb_hcd_submit_urb [usbcore]() {
>> >> >> >>  0)   0.834 us|  usb_get_urb [usbcore]();
>> >> >> >>  0)   |  musb_map_urb_for_dma [musb_hdrc]() {
>> >> >> >>  0)   0.792 us|usb_hcd_map_urb_for_dma [usbcore]();
>> >> >> >>  0)   5.750 us|  }
>> >> >> >>  0)   |  musb_urb_enqueue [musb_hdrc]() {
>> >> >> >>  0)   0.750 us|_raw_spin_lock_irqsave();
>> >> >> >>  0)   |usb_hcd_link_urb_to_ep [usbcore]() {
>> >> >> >>  0)   0.792 us|  _raw_spin_lock();
>> >> >> >>  0)   0.791 us|  _raw_spin_unlock();
>> >> >> >>  0) + 10.500 us   |}
>> >> >> >>  0)   0.791 us|_raw_spin_unlock_irqrestore();
>> >> >> >>  0) + 25.375 us   |  }
>> >> >> >>  0) + 45.208 us   |}
>> >> >> >>  0) + 51.042 us   |  }
>> >> >> >>  0) + 56.084 us   |}
>> >> >> >>  0) + 61.292 us   |  }
>> >> >> >>
>> >> >> >> However, pwc_isoc_handler never calls vb2_buffer_done() that is why 
>> >> >> >> I get "select timeout" in userspace.
>> >> >> >> Unfortunately, my kernel is not compiled with 
>> >> >> >> CONFIG_USB_PWC_DEBUG=y but I can recompile it, if you think that it 
>> >> >> >> could provide more information. I am also ready to perform 
>> >> >> >> additional tests (use usbmon maybe?).
>> >> >> >>
>> >> >> >> How could this issue be resolved?
>> >> >> >>
>> >> >> >> Thank you.
>> >> >> >
>> >> >> > Do you have CPPI DMA enabled? If so I think you might hit on a known
>> >> >> > issue in CPPI Isoch transfer, in which the MUSB controller only 

Re: pwc over musb: 100% frame drop (lost) on high resolution stream

[Bin Liu]

Hi,

On Wed, Jul 20, 2016 at 05:44:56PM +0300, Matwey V. Kornilov wrote:
> 2016-07-20 17:13 GMT+03:00 Bin Liu :
> > Hi,
> >
> > On Wed, Jul 20, 2016 at 09:09:42AM +0300, Matwey V. Kornilov wrote:
> >> 2016-07-20 0:34 GMT+03:00 Bin Liu :
> >> > Hi,
> >> >
> >> > On Wed, Jul 20, 2016 at 12:25:44AM +0300, Matwey V. Kornilov wrote:
> >> >> 2016-07-19 23:56 GMT+03:00 Bin Liu :
> >> >> > Hi,
> >> >> >
> >> >> > On Tue, Jul 19, 2016 at 11:21:17PM +0300, mat...@sai.msu.ru wrote:
> >> >> >> Hello,
> >> >> >>
> >> >> >> I have Philips SPC 900 camera (0471:0329) connected to my AM335x 
> >> >> >> based BeagleBoneBlack SBC.
> >> >> >> I am sure that both of them are fine and work properly.
> >> >> >> I am running Linux 4.6.4 (my kernel config is available at 
> >> >> >> https://clck.ru/A2kQs ) and I've just discovered, that there is an 
> >> >> >> issue with frame transfer when high resolution formats are used.
> >> >> >>
> >> >> >> The issue is the following. I use simple v4l2 example tool (taken 
> >> >> >> from API docs), which source code is available at 
> >> >> >> http://pastebin.com/grcNXxfe
> >> >> >>
> >> >> >> When I use (see line 488) 640x480 frames
> >> >> >>
> >> >> >> fmt.fmt.pix.width   = 640;
> >> >> >> fmt.fmt.pix.height  = 480;
> >> >> >>
> >> >> >> then I get "select timeout" and don't get any frames.
> >> >> >>
> >> >> >> When I use 320x240 frames
> >> >> >>
> >> >> >> fmt.fmt.pix.width   = 320;
> >> >> >> fmt.fmt.pix.height  = 240;
> >> >> >>
> >> >> >> then about 60% frames are missed. An example outpout of ./a.out -f 
> >> >> >> is available at https://yadi.sk/d/aRka8xWPtSc4y
> >> >> >> It looks like there are pauses between bulks of frames (frame 
> >> >> >> counter and timestamp as returned from v4l2 API):
> >> >> >>
> >> >> >> 3 3705.142553
> >> >> >> 8 3705.342533
> >> >> >> 13 3705.542517
> >> >> >> 110 3708.776208
> >> >> >> 115 3708.976190
> >> >> >> 120 3709.176169
> >> >> >> 125 3709.376152
> >> >> >> 130 3709.576144
> >> >> >> 226 3712.807848
> >> >> >>
> >> >> >> When I use tiny 160x120 frames
> >> >> >>
> >> >> >> fmt.fmt.pix.width   = 160;
> >> >> >> fmt.fmt.pix.height  = 120;
> >> >> >>
> >> >> >> then more frames are received. See output example at 
> >> >> >> https://yadi.sk/d/DedBmH6ftSc9t
> >> >> >> That is why I thought that everything was fine in May when used tiny 
> >> >> >> xawtv window to check kernel OOPS presence (see 
> >> >> >> http://www.spinics.net/lists/linux-usb/msg141188.html for reference)
> >> >> >>
> >> >> >> Even more. When I introduce USB hub between the host and the webcam, 
> >> >> >> I can not receive even any 320x240 frames.
> >> >> >>
> >> >> >> I've managed to use ftrace to see what is going on when no frames 
> >> >> >> are received.
> >> >> >> I've found that pwc_isoc_handler is called frequently as the 
> >> >> >> following:
> >> >> >>
> >> >> >>  0)   |  pwc_isoc_handler [pwc]() {
> >> >> >>  0)   |usb_submit_urb [usbcore]() {
> >> >> >>  0)   |  usb_submit_urb.part.3 [usbcore]() {
> >> >> >>  0)   |usb_hcd_submit_urb [usbcore]() {
> >> >> >>  0)   0.834 us|  usb_get_urb [usbcore]();
> >> >> >>  0)   |  musb_map_urb_for_dma [musb_hdrc]() {
> >> >> >>  0)   0.792 us|usb_hcd_map_urb_for_dma [usbcore]();
> >> >> >>  0)   5.750 us|  }
> >> >> >>  0)   |  musb_urb_enqueue [musb_hdrc]() {
> >> >> >>  0)   0.750 us|_raw_spin_lock_irqsave();
> >> >> >>  0)   |usb_hcd_link_urb_to_ep [usbcore]() {
> >> >> >>  0)   0.792 us|  _raw_spin_lock();
> >> >> >>  0)   0.791 us|  _raw_spin_unlock();
> >> >> >>  0) + 10.500 us   |}
> >> >> >>  0)   0.791 us|_raw_spin_unlock_irqrestore();
> >> >> >>  0) + 25.375 us   |  }
> >> >> >>  0) + 45.208 us   |}
> >> >> >>  0) + 51.042 us   |  }
> >> >> >>  0) + 56.084 us   |}
> >> >> >>  0) + 61.292 us   |  }
> >> >> >>
> >> >> >> However, pwc_isoc_handler never calls vb2_buffer_done() that is why 
> >> >> >> I get "select timeout" in userspace.
> >> >> >> Unfortunately, my kernel is not compiled with CONFIG_USB_PWC_DEBUG=y 
> >> >> >> but I can recompile it, if you think that it could provide more 
> >> >> >> information. I am also ready to perform additional tests (use usbmon 
> >> >> >> maybe?).
> >> >> >>
> >> >> >> How could this issue be resolved?
> >> >> >>
> >> >> >> Thank you.
> >> >> >
> >> >> > Do you have CPPI DMA enabled? If so I think you might hit on a known
> >> >> > issue in CPPI Isoch transfer, in which the MUSB controller only sends 
> >> >> > IN
> >> >> > tokens in every other SOF, so only half of the bus bandwidth is
> >> >> > utilized, which causes video frame drops in higher 

Re: pwc over musb: 100% frame drop (lost) on high resolution stream

[Matwey V. Kornilov]

2016-07-20 17:13 GMT+03:00 Bin Liu :
> Hi,
>
> On Wed, Jul 20, 2016 at 09:09:42AM +0300, Matwey V. Kornilov wrote:
>> 2016-07-20 0:34 GMT+03:00 Bin Liu :
>> > Hi,
>> >
>> > On Wed, Jul 20, 2016 at 12:25:44AM +0300, Matwey V. Kornilov wrote:
>> >> 2016-07-19 23:56 GMT+03:00 Bin Liu :
>> >> > Hi,
>> >> >
>> >> > On Tue, Jul 19, 2016 at 11:21:17PM +0300, mat...@sai.msu.ru wrote:
>> >> >> Hello,
>> >> >>
>> >> >> I have Philips SPC 900 camera (0471:0329) connected to my AM335x based 
>> >> >> BeagleBoneBlack SBC.
>> >> >> I am sure that both of them are fine and work properly.
>> >> >> I am running Linux 4.6.4 (my kernel config is available at 
>> >> >> https://clck.ru/A2kQs ) and I've just discovered, that there is an 
>> >> >> issue with frame transfer when high resolution formats are used.
>> >> >>
>> >> >> The issue is the following. I use simple v4l2 example tool (taken from 
>> >> >> API docs), which source code is available at 
>> >> >> http://pastebin.com/grcNXxfe
>> >> >>
>> >> >> When I use (see line 488) 640x480 frames
>> >> >>
>> >> >> fmt.fmt.pix.width   = 640;
>> >> >> fmt.fmt.pix.height  = 480;
>> >> >>
>> >> >> then I get "select timeout" and don't get any frames.
>> >> >>
>> >> >> When I use 320x240 frames
>> >> >>
>> >> >> fmt.fmt.pix.width   = 320;
>> >> >> fmt.fmt.pix.height  = 240;
>> >> >>
>> >> >> then about 60% frames are missed. An example outpout of ./a.out -f is 
>> >> >> available at https://yadi.sk/d/aRka8xWPtSc4y
>> >> >> It looks like there are pauses between bulks of frames (frame counter 
>> >> >> and timestamp as returned from v4l2 API):
>> >> >>
>> >> >> 3 3705.142553
>> >> >> 8 3705.342533
>> >> >> 13 3705.542517
>> >> >> 110 3708.776208
>> >> >> 115 3708.976190
>> >> >> 120 3709.176169
>> >> >> 125 3709.376152
>> >> >> 130 3709.576144
>> >> >> 226 3712.807848
>> >> >>
>> >> >> When I use tiny 160x120 frames
>> >> >>
>> >> >> fmt.fmt.pix.width   = 160;
>> >> >> fmt.fmt.pix.height  = 120;
>> >> >>
>> >> >> then more frames are received. See output example at 
>> >> >> https://yadi.sk/d/DedBmH6ftSc9t
>> >> >> That is why I thought that everything was fine in May when used tiny 
>> >> >> xawtv window to check kernel OOPS presence (see 
>> >> >> http://www.spinics.net/lists/linux-usb/msg141188.html for reference)
>> >> >>
>> >> >> Even more. When I introduce USB hub between the host and the webcam, I 
>> >> >> can not receive even any 320x240 frames.
>> >> >>
>> >> >> I've managed to use ftrace to see what is going on when no frames are 
>> >> >> received.
>> >> >> I've found that pwc_isoc_handler is called frequently as the following:
>> >> >>
>> >> >>  0)   |  pwc_isoc_handler [pwc]() {
>> >> >>  0)   |usb_submit_urb [usbcore]() {
>> >> >>  0)   |  usb_submit_urb.part.3 [usbcore]() {
>> >> >>  0)   |usb_hcd_submit_urb [usbcore]() {
>> >> >>  0)   0.834 us|  usb_get_urb [usbcore]();
>> >> >>  0)   |  musb_map_urb_for_dma [musb_hdrc]() {
>> >> >>  0)   0.792 us|usb_hcd_map_urb_for_dma [usbcore]();
>> >> >>  0)   5.750 us|  }
>> >> >>  0)   |  musb_urb_enqueue [musb_hdrc]() {
>> >> >>  0)   0.750 us|_raw_spin_lock_irqsave();
>> >> >>  0)   |usb_hcd_link_urb_to_ep [usbcore]() {
>> >> >>  0)   0.792 us|  _raw_spin_lock();
>> >> >>  0)   0.791 us|  _raw_spin_unlock();
>> >> >>  0) + 10.500 us   |}
>> >> >>  0)   0.791 us|_raw_spin_unlock_irqrestore();
>> >> >>  0) + 25.375 us   |  }
>> >> >>  0) + 45.208 us   |}
>> >> >>  0) + 51.042 us   |  }
>> >> >>  0) + 56.084 us   |}
>> >> >>  0) + 61.292 us   |  }
>> >> >>
>> >> >> However, pwc_isoc_handler never calls vb2_buffer_done() that is why I 
>> >> >> get "select timeout" in userspace.
>> >> >> Unfortunately, my kernel is not compiled with CONFIG_USB_PWC_DEBUG=y 
>> >> >> but I can recompile it, if you think that it could provide more 
>> >> >> information. I am also ready to perform additional tests (use usbmon 
>> >> >> maybe?).
>> >> >>
>> >> >> How could this issue be resolved?
>> >> >>
>> >> >> Thank you.
>> >> >
>> >> > Do you have CPPI DMA enabled? If so I think you might hit on a known
>> >> > issue in CPPI Isoch transfer, in which the MUSB controller only sends IN
>> >> > tokens in every other SOF, so only half of the bus bandwidth is
>> >> > utilized, which causes video frame drops in higher resolution.
>> >> >
>> >>
>> >> Yes, I do use DMA:
>> >>
>> >> CONFIG_USB_TI_CPPI41_DMA=y
>> >
>> > Okay.
>> >
>> >>
>> >> > To confirm this, use a bus analyzer to capture a bus trace, you would
>> >> > see no IN tokens in every other SOF while transfering Isoch packets.
>> >> >
>> >>
>> >> I am sorry, I am new to 

[PATCH v2 3/3] usb: chipidea: imx: set over current polarity per dts setting

[Li Jun]

imx usb over current polarity is low active by default, with
over-current-active-high property added, user can config it to be high
active. Meanwhile keep this setting unchanged for existing platforms
so new platform must set the right value for active low by its usbmisc
init function if over current is enabled.

Signed-off-by: Li Jun 
---
 drivers/usb/chipidea/ci_hdrc_imx.c |  3 +++
 drivers/usb/chipidea/ci_hdrc_imx.h |  1 +
 drivers/usb/chipidea/usbmisc_imx.c | 22 +-
 3 files changed, 21 insertions(+), 5 deletions(-)

diff --git a/drivers/usb/chipidea/ci_hdrc_imx.c 
b/drivers/usb/chipidea/ci_hdrc_imx.c
index dedc33e..0991794 100644
--- a/drivers/usb/chipidea/ci_hdrc_imx.c
+++ b/drivers/usb/chipidea/ci_hdrc_imx.c
@@ -140,6 +140,9 @@ static struct imx_usbmisc_data 
*usbmisc_get_init_data(struct device *dev)
if (of_find_property(np, "disable-over-current", NULL))
data->disable_oc = 1;
 
+   if (of_find_property(np, "over-current-active-high", NULL))
+   data->oc_polarity = 1;
+
if (of_find_property(np, "external-vbus-divider", NULL))
data->evdo = 1;
 
diff --git a/drivers/usb/chipidea/ci_hdrc_imx.h 
b/drivers/usb/chipidea/ci_hdrc_imx.h
index 635717e..409aa5ca8 100644
--- a/drivers/usb/chipidea/ci_hdrc_imx.h
+++ b/drivers/usb/chipidea/ci_hdrc_imx.h
@@ -17,6 +17,7 @@ struct imx_usbmisc_data {
int index;
 
unsigned int disable_oc:1; /* over current detect disabled */
+   unsigned int oc_polarity:1; /* over current polarity if oc enabled */
unsigned int evdo:1; /* set external vbus divider option */
 };
 
diff --git a/drivers/usb/chipidea/usbmisc_imx.c 
b/drivers/usb/chipidea/usbmisc_imx.c
index ab8b027..20d02a5 100644
--- a/drivers/usb/chipidea/usbmisc_imx.c
+++ b/drivers/usb/chipidea/usbmisc_imx.c
@@ -56,6 +56,7 @@
 
 #define MX6_BM_NON_BURST_SETTING   BIT(1)
 #define MX6_BM_OVER_CUR_DISBIT(7)
+#define MX6_BM_OVER_CUR_POLARITY   BIT(8)
 #define MX6_BM_WAKEUP_ENABLE   BIT(10)
 #define MX6_BM_ID_WAKEUP   BIT(16)
 #define MX6_BM_VBUS_WAKEUP BIT(17)
@@ -266,11 +267,14 @@ static int usbmisc_imx6q_init(struct imx_usbmisc_data 
*data)
 
spin_lock_irqsave(>lock, flags);
 
+   reg = readl(usbmisc->base + data->index * 4);
if (data->disable_oc) {
-   reg = readl(usbmisc->base + data->index * 4);
-   writel(reg | MX6_BM_OVER_CUR_DIS,
-   usbmisc->base + data->index * 4);
+   reg |= MX6_BM_OVER_CUR_DIS;
+   } else if (data->oc_polarity == 1) {
+   /* High active */
+   reg &= ~(MX6_BM_OVER_CUR_DIS | MX6_BM_OVER_CUR_POLARITY);
}
+   writel(reg, usbmisc->base + data->index * 4);
 
/* SoC non-burst setting */
reg = readl(usbmisc->base + data->index * 4);
@@ -365,10 +369,14 @@ static int usbmisc_imx7d_init(struct imx_usbmisc_data 
*data)
return -EINVAL;
 
spin_lock_irqsave(>lock, flags);
+   reg = readl(usbmisc->base);
if (data->disable_oc) {
-   reg = readl(usbmisc->base);
-   writel(reg | MX6_BM_OVER_CUR_DIS, usbmisc->base);
+   reg |= MX6_BM_OVER_CUR_DIS;
+   } else if (data->oc_polarity == 1) {
+   /* High active */
+   reg &= ~(MX6_BM_OVER_CUR_DIS | MX6_BM_OVER_CUR_POLARITY);
}
+   writel(reg, usbmisc->base);
 
reg = readl(usbmisc->base + MX7D_USBNC_USB_CTRL2);
reg &= ~MX7D_USB_VBUS_WAKEUP_SOURCE_MASK;
@@ -492,6 +500,10 @@ static const struct of_device_id usbmisc_imx_dt_ids[] = {
.compatible = "fsl,imx6ul-usbmisc",
.data = _usbmisc_ops,
},
+   {
+   .compatible = "fsl,imx7d-usbmisc",
+   .data = _usbmisc_ops,
+   },
{ /* sentinel */ }
 };
 MODULE_DEVICE_TABLE(of, usbmisc_imx_dt_ids);
-- 
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: pwc over musb: 100% frame drop (lost) on high resolution stream

[Bin Liu]

Hi,

On Wed, Jul 20, 2016 at 09:09:42AM +0300, Matwey V. Kornilov wrote:
> 2016-07-20 0:34 GMT+03:00 Bin Liu :
> > Hi,
> >
> > On Wed, Jul 20, 2016 at 12:25:44AM +0300, Matwey V. Kornilov wrote:
> >> 2016-07-19 23:56 GMT+03:00 Bin Liu :
> >> > Hi,
> >> >
> >> > On Tue, Jul 19, 2016 at 11:21:17PM +0300, mat...@sai.msu.ru wrote:
> >> >> Hello,
> >> >>
> >> >> I have Philips SPC 900 camera (0471:0329) connected to my AM335x based 
> >> >> BeagleBoneBlack SBC.
> >> >> I am sure that both of them are fine and work properly.
> >> >> I am running Linux 4.6.4 (my kernel config is available at 
> >> >> https://clck.ru/A2kQs ) and I've just discovered, that there is an 
> >> >> issue with frame transfer when high resolution formats are used.
> >> >>
> >> >> The issue is the following. I use simple v4l2 example tool (taken from 
> >> >> API docs), which source code is available at 
> >> >> http://pastebin.com/grcNXxfe
> >> >>
> >> >> When I use (see line 488) 640x480 frames
> >> >>
> >> >> fmt.fmt.pix.width   = 640;
> >> >> fmt.fmt.pix.height  = 480;
> >> >>
> >> >> then I get "select timeout" and don't get any frames.
> >> >>
> >> >> When I use 320x240 frames
> >> >>
> >> >> fmt.fmt.pix.width   = 320;
> >> >> fmt.fmt.pix.height  = 240;
> >> >>
> >> >> then about 60% frames are missed. An example outpout of ./a.out -f is 
> >> >> available at https://yadi.sk/d/aRka8xWPtSc4y
> >> >> It looks like there are pauses between bulks of frames (frame counter 
> >> >> and timestamp as returned from v4l2 API):
> >> >>
> >> >> 3 3705.142553
> >> >> 8 3705.342533
> >> >> 13 3705.542517
> >> >> 110 3708.776208
> >> >> 115 3708.976190
> >> >> 120 3709.176169
> >> >> 125 3709.376152
> >> >> 130 3709.576144
> >> >> 226 3712.807848
> >> >>
> >> >> When I use tiny 160x120 frames
> >> >>
> >> >> fmt.fmt.pix.width   = 160;
> >> >> fmt.fmt.pix.height  = 120;
> >> >>
> >> >> then more frames are received. See output example at 
> >> >> https://yadi.sk/d/DedBmH6ftSc9t
> >> >> That is why I thought that everything was fine in May when used tiny 
> >> >> xawtv window to check kernel OOPS presence (see 
> >> >> http://www.spinics.net/lists/linux-usb/msg141188.html for reference)
> >> >>
> >> >> Even more. When I introduce USB hub between the host and the webcam, I 
> >> >> can not receive even any 320x240 frames.
> >> >>
> >> >> I've managed to use ftrace to see what is going on when no frames are 
> >> >> received.
> >> >> I've found that pwc_isoc_handler is called frequently as the following:
> >> >>
> >> >>  0)   |  pwc_isoc_handler [pwc]() {
> >> >>  0)   |usb_submit_urb [usbcore]() {
> >> >>  0)   |  usb_submit_urb.part.3 [usbcore]() {
> >> >>  0)   |usb_hcd_submit_urb [usbcore]() {
> >> >>  0)   0.834 us|  usb_get_urb [usbcore]();
> >> >>  0)   |  musb_map_urb_for_dma [musb_hdrc]() {
> >> >>  0)   0.792 us|usb_hcd_map_urb_for_dma [usbcore]();
> >> >>  0)   5.750 us|  }
> >> >>  0)   |  musb_urb_enqueue [musb_hdrc]() {
> >> >>  0)   0.750 us|_raw_spin_lock_irqsave();
> >> >>  0)   |usb_hcd_link_urb_to_ep [usbcore]() {
> >> >>  0)   0.792 us|  _raw_spin_lock();
> >> >>  0)   0.791 us|  _raw_spin_unlock();
> >> >>  0) + 10.500 us   |}
> >> >>  0)   0.791 us|_raw_spin_unlock_irqrestore();
> >> >>  0) + 25.375 us   |  }
> >> >>  0) + 45.208 us   |}
> >> >>  0) + 51.042 us   |  }
> >> >>  0) + 56.084 us   |}
> >> >>  0) + 61.292 us   |  }
> >> >>
> >> >> However, pwc_isoc_handler never calls vb2_buffer_done() that is why I 
> >> >> get "select timeout" in userspace.
> >> >> Unfortunately, my kernel is not compiled with CONFIG_USB_PWC_DEBUG=y 
> >> >> but I can recompile it, if you think that it could provide more 
> >> >> information. I am also ready to perform additional tests (use usbmon 
> >> >> maybe?).
> >> >>
> >> >> How could this issue be resolved?
> >> >>
> >> >> Thank you.
> >> >
> >> > Do you have CPPI DMA enabled? If so I think you might hit on a known
> >> > issue in CPPI Isoch transfer, in which the MUSB controller only sends IN
> >> > tokens in every other SOF, so only half of the bus bandwidth is
> >> > utilized, which causes video frame drops in higher resolution.
> >> >
> >>
> >> Yes, I do use DMA:
> >>
> >> CONFIG_USB_TI_CPPI41_DMA=y
> >
> > Okay.
> >
> >>
> >> > To confirm this, use a bus analyzer to capture a bus trace, you would
> >> > see no IN tokens in every other SOF while transfering Isoch packets.
> >> >
> >>
> >> I am sorry, I am new to USB debugging. Do you mean I need to use
> >> usbmon or some external hardware device?
> >
> > I barely use usbmon, and not sure if it gives the information I am
> > 

Re: [PATCH v8 2/3] phy: rockchip-inno-usb2: add a new driver for Rockchip usb2phy

[Heiko Stübner]

Am Dienstag, 19. Juli 2016, 15:27:40 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 
> Suggested-by: Heiko Stuebner 
> Suggested-by: Guenter Roeck 
> Suggested-by: Doug Anderson 

Reviewed-by: Heiko Stuebner 
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 4/6] usb: core: add power sequence handling for USB devices

[Peter Chen]

Some hard-wired USB devices need to do power sequence to let the
device work normally, the typical power sequence like: enable USB
PHY clock, toggle reset pin, etc. But current Linux USB driver
lacks of such code to do it, it may cause some hard-wired USB devices
works abnormal or can't be recognized by controller at all.

In this patch, it calls power sequence library APIs to finish
the power sequence events. At first, it calls pwrseq_alloc_generic
to create a generic power sequence instance, then it will do power
on sequence at hub's probe for all devices under this hub
(includes root hub).

At hub_disconnect, it will do power off sequence which is at powered
on list.

Signed-off-by: Peter Chen 
---
 drivers/usb/core/Makefile |   1 +
 drivers/usb/core/hub.c|  12 --
 drivers/usb/core/hub.h|  12 ++
 drivers/usb/core/pwrseq.c | 100 ++
 4 files changed, 122 insertions(+), 3 deletions(-)
 create mode 100644 drivers/usb/core/pwrseq.c

diff --git a/drivers/usb/core/Makefile b/drivers/usb/core/Makefile
index da36b78..5fd2f54 100644
--- a/drivers/usb/core/Makefile
+++ b/drivers/usb/core/Makefile
@@ -10,5 +10,6 @@ usbcore-y += port.o
 usbcore-$(CONFIG_OF)   += of.o
 usbcore-$(CONFIG_PCI)  += hcd-pci.o
 usbcore-$(CONFIG_ACPI) += usb-acpi.o
+usbcore-$(CONFIG_PWRSEQ_GENERIC) += pwrseq.o
 
 obj-$(CONFIG_USB)  += usbcore.o
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index bee1351..a346a8b 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -1700,6 +1700,7 @@ static void hub_disconnect(struct usb_interface *intf)
hub->error = 0;
hub_quiesce(hub, HUB_DISCONNECT);
 
+   hub_pwrseq_off(hub);
mutex_lock(_port_peer_mutex);
 
/* Avoid races with recursively_mark_NOTATTACHED() */
@@ -1733,6 +1734,7 @@ static int hub_probe(struct usb_interface *intf, const 
struct usb_device_id *id)
struct usb_endpoint_descriptor *endpoint;
struct usb_device *hdev;
struct usb_hub *hub;
+   int ret = -ENODEV;
 
desc = intf->cur_altsetting;
hdev = interface_to_usbdev(intf);
@@ -1839,6 +1841,7 @@ descriptor_error:
INIT_DELAYED_WORK(>leds, led_work);
INIT_DELAYED_WORK(>init_work, NULL);
INIT_WORK(>events, hub_event);
+   INIT_LIST_HEAD(>pwrseq_on_list);
usb_get_intf(intf);
usb_get_dev(hdev);
 
@@ -1852,11 +1855,14 @@ descriptor_error:
if (id->driver_info & HUB_QUIRK_CHECK_PORT_AUTOSUSPEND)
hub->quirk_check_port_auto_suspend = 1;
 
-   if (hub_configure(hub, endpoint) >= 0)
-   return 0;
+   if (hub_configure(hub, endpoint) >= 0) {
+   ret = hub_pwrseq_on(hub);
+   if (!ret)
+   return 0;
+   }
 
hub_disconnect(intf);
-   return -ENODEV;
+   return ret;
 }
 
 static int
diff --git a/drivers/usb/core/hub.h b/drivers/usb/core/hub.h
index 34c1a7e..9473f6f 100644
--- a/drivers/usb/core/hub.h
+++ b/drivers/usb/core/hub.h
@@ -78,6 +78,7 @@ struct usb_hub {
struct delayed_work init_work;
struct work_struct  events;
struct usb_port **ports;
+   struct list_headpwrseq_on_list; /* powered pwrseq node list */
 };
 
 /**
@@ -166,3 +167,14 @@ static inline int hub_port_debounce_be_stable(struct 
usb_hub *hub,
 {
return hub_port_debounce(hub, port1, false);
 }
+
+#if IS_ENABLED(CONFIG_PWRSEQ_GENERIC)
+int hub_pwrseq_on(struct usb_hub *hub);
+void hub_pwrseq_off(struct usb_hub *hub);
+#else
+static inline int hub_pwrseq_on(struct usb_hub *hub)
+{
+   return 0;
+}
+static inline void hub_pwrseq_off(struct usb_hub *hub) {}
+#endif /* CONFIG_PWRSEQ_GENERIC */
diff --git a/drivers/usb/core/pwrseq.c b/drivers/usb/core/pwrseq.c
new file mode 100644
index 000..837fe66
--- /dev/null
+++ b/drivers/usb/core/pwrseq.c
@@ -0,0 +1,100 @@
+/*
+ * pwrseq.cUSB device power sequence management
+ *
+ * Copyright (C) 2016 Freescale Semiconductor, Inc.
+ * Author: Peter Chen 
+ *
+ * This program is free software: you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2  of
+ * the License as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see .
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "hub.h"
+
+struct usb_pwrseq_node {
+   struct pwrseq *pwrseq;
+   struct list_head list;
+};
+
+static int hub_of_pwrseq_on(struct device_node *np, struct 

[PATCH v3 0/6] power: add power sequence library

[Peter Chen]

Hi all,

This is a follow-up for my last power sequence framework patch set [1].
According to Rob Herring and Ulf Hansson's comments[2], I use a generic
power sequence library for parsing the power sequence elements on DT,
and implement generic power sequence on library. The host driver
can allocate power sequence instance, and calls pwrseq APIs accordingly.

In future, if there are special power sequence requirements, the special
power sequence library can be created.

This patch set is tested on i.mx6 sabresx evk using a dts change, I use
two hot-plug devices to simulate this use case, the related binding
change is updated at patch [1/6], The udoo board changes were tested
using my last power sequence patch set.[3]

Except for hard-wired MMC and USB devices, I find the USB ULPI PHY also
need to power on itself before it can be found by ULPI bus.

[1] http://www.spinics.net/lists/linux-usb/msg142755.html
[2] http://www.spinics.net/lists/linux-usb/msg143106.html
[3] http://www.spinics.net/lists/linux-usb/msg142815.html

Changes for v3:
- Delete "power-sequence" property at binding-doc, and change related code
  at both library and user code.
- Change binding-doc example node name with Rob's comments
- of_get_named_gpio_flags only gets the gpio, but without setting gpio flags,
  add additional code request gpio with proper gpio flags
- Add Philipp Zabel's Ack and MAINTAINER's entry

Changes for v2:
- Delete "pwrseq" prefix and clock-names for properties at dt binding
- Should use structure not but its pointer for kzalloc
- Since chipidea core has no of_node, let core's of_node equals glue
  layer's at core's probe

Peter Chen (6):
  binding-doc: power: pwrseq-generic: add binding doc for generic power
sequence library
  power: add power sequence library
  binding-doc: usb: usb-device: add optional properties for power
sequence
  usb: core: add power sequence handling for USB devices
  usb: chipidea: let chipidea core device of_node equal's glue layer
device of_node
  ARM: dts: imx6qdl-udoo.dtsi: fix onboard USB HUB property

 .../bindings/power/pwrseq/pwrseq-generic.txt   |  48 +++
 .../devicetree/bindings/usb/usb-device.txt |  10 +-
 MAINTAINERS|   9 ++
 arch/arm/boot/dts/imx6qdl-udoo.dtsi|  26 ++--
 drivers/power/Kconfig  |   1 +
 drivers/power/Makefile |   1 +
 drivers/power/pwrseq/Kconfig   |  20 +++
 drivers/power/pwrseq/Makefile  |   2 +
 drivers/power/pwrseq/core.c|  71 ++
 drivers/power/pwrseq/pwrseq_generic.c  | 151 +
 drivers/usb/chipidea/core.c|  10 ++
 drivers/usb/core/Makefile  |   1 +
 drivers/usb/core/hub.c |  12 +-
 drivers/usb/core/hub.h |  12 ++
 drivers/usb/core/pwrseq.c  | 100 ++
 include/linux/power/pwrseq.h   |  50 +++
 16 files changed, 507 insertions(+), 17 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/power/pwrseq/pwrseq-generic.txt
 create mode 100644 drivers/power/pwrseq/Kconfig
 create mode 100644 drivers/power/pwrseq/Makefile
 create mode 100644 drivers/power/pwrseq/core.c
 create mode 100644 drivers/power/pwrseq/pwrseq_generic.c
 create mode 100644 drivers/usb/core/pwrseq.c
 create mode 100644 include/linux/power/pwrseq.h

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

[PATCH v3 2/6] power: add power sequence library

[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 calls pwrseq_alloc_generic to create
an generic pwrseq instance.

Signed-off-by: Peter Chen 
---
 MAINTAINERS   |   9 ++
 drivers/power/Kconfig |   1 +
 drivers/power/Makefile|   1 +
 drivers/power/pwrseq/Kconfig  |  20 +
 drivers/power/pwrseq/Makefile |   2 +
 drivers/power/pwrseq/core.c   |  71 
 drivers/power/pwrseq/pwrseq_generic.c | 151 ++
 include/linux/power/pwrseq.h  |  50 +++
 8 files changed, 305 insertions(+)
 create mode 100644 drivers/power/pwrseq/Kconfig
 create mode 100644 drivers/power/pwrseq/Makefile
 create mode 100644 drivers/power/pwrseq/core.c
 create mode 100644 drivers/power/pwrseq/pwrseq_generic.c
 create mode 100644 include/linux/power/pwrseq.h

diff --git a/MAINTAINERS b/MAINTAINERS
index 68a90d0..6fd879f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9243,6 +9243,15 @@ F:   include/linux/pm_*
 F: include/linux/powercap.h
 F: drivers/powercap/
 
+POWER SEQUENCE LIBRARY
+M: Peter Chen 
+T: git git://git.kernel.org/pub/scm/linux/kernel/git/peter.chen/usb.git
+L: linux...@vger.kernel.org
+S: Maintained
+F: Documentation/devicetree/bindings/power/pwrseq/
+F: drivers/power/pwrseq/
+F: include/linux/power/pwrseq.h/
+
 POWER SUPPLY CLASS/SUBSYSTEM and DRIVERS
 M: Sebastian Reichel 
 M: Dmitry Eremin-Solenikov 
diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig
index acd4a15..f6aa4fd 100644
--- a/drivers/power/Kconfig
+++ b/drivers/power/Kconfig
@@ -515,3 +515,4 @@ endif # POWER_SUPPLY
 
 source "drivers/power/reset/Kconfig"
 source "drivers/power/avs/Kconfig"
+source "drivers/power/pwrseq/Kconfig"
diff --git a/drivers/power/Makefile b/drivers/power/Makefile
index e46b75d..4ed2e12 100644
--- a/drivers/power/Makefile
+++ b/drivers/power/Makefile
@@ -74,3 +74,4 @@ obj-$(CONFIG_CHARGER_TPS65217)+= tps65217_charger.o
 obj-$(CONFIG_POWER_RESET)  += reset/
 obj-$(CONFIG_AXP288_FUEL_GAUGE) += axp288_fuel_gauge.o
 obj-$(CONFIG_AXP288_CHARGER)   += axp288_charger.o
+obj-$(CONFIG_POWER_SEQUENCE)   += pwrseq/
diff --git a/drivers/power/pwrseq/Kconfig b/drivers/power/pwrseq/Kconfig
new file mode 100644
index 000..188729e
--- /dev/null
+++ b/drivers/power/pwrseq/Kconfig
@@ -0,0 +1,20 @@
+#
+# 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.
+
+endmenu
diff --git a/drivers/power/pwrseq/Makefile b/drivers/power/pwrseq/Makefile
new file mode 100644
index 000..ad82389
--- /dev/null
+++ b/drivers/power/pwrseq/Makefile
@@ -0,0 +1,2 @@
+obj-$(CONFIG_POWER_SEQUENCE) += core.o
+obj-$(CONFIG_PWRSEQ_GENERIC) += pwrseq_generic.o
diff --git a/drivers/power/pwrseq/core.c b/drivers/power/pwrseq/core.c
new file mode 100644
index 000..60f1e4e
--- /dev/null
+++ b/drivers/power/pwrseq/core.c
@@ -0,0 +1,71 @@
+/*
+ * core.c  power sequence core file
+ *
+ * Copyright (C) 2016 Freescale Semiconductor, Inc.
+ * Author: Peter Chen 
+ *
+ * This program is free software: you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2  of
+ * the License as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see .
+ */
+
+#include 
+
+static DEFINE_MUTEX(pwrseq_list_mutex);
+static LIST_HEAD(pwrseq_list);
+
+int pwrseq_get(struct device_node *np, struct pwrseq *p)
+{
+   if (p && 

[PATCH v3 1/6] binding-doc: power: pwrseq-generic: add binding doc for generic power sequence library

[Peter Chen]

Add binding doc for generic power sequence library.

Signed-off-by: Peter Chen 
Acked-by: Philipp Zabel 
---
 .../bindings/power/pwrseq/pwrseq-generic.txt   | 48 ++
 1 file changed, 48 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/power/pwrseq/pwrseq-generic.txt

diff --git a/Documentation/devicetree/bindings/power/pwrseq/pwrseq-generic.txt 
b/Documentation/devicetree/bindings/power/pwrseq/pwrseq-generic.txt
new file mode 100644
index 000..48bb3e1
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/pwrseq/pwrseq-generic.txt
@@ -0,0 +1,48 @@
+The generic power sequence library
+
+Some hard-wired devices (eg USB/MMC) need to do power sequence before
+the device can be enumerated on the bus, the typical power sequence
+like: enable USB PHY clock, toggle reset pin, etc. But current
+Linux device driver lacks of such code to do it, it may cause some
+hard-wired devices works abnormal or can't be recognized by
+controller at all. The power sequence will be done before this device
+can be found at the bus.
+
+The power sequence properties is under the device node.
+
+Optional properties:
+- clocks: the input clock for device.
+- reset-gpios: Should specify the GPIO for reset.
+- reset-duration-us: the duration in microsecond for assert reset signal.
+
+Below is the example of USB power sequence properties on USB device
+nodes which have two level USB hubs.
+
+ {
+   vbus-supply = <_usb_otg1_vbus>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_usb_otg1_id>;
+   status = "okay";
+
+   #address-cells = <1>;
+   #size-cells = <0>;
+   genesys: hub@1 {
+   compatible = "usb5e3,608";
+   reg = <1>;
+
+   clocks = < IMX6SX_CLK_CKO>;
+   reset-gpios = < 5 GPIO_ACTIVE_LOW>; /* hub reset pin */
+   reset-duration-us = <10>;
+
+   #address-cells = <1>;
+   #size-cells = <0>;
+   asix: ethernet@1 {
+   compatible = "usbb95,1708";
+   reg = <1>;
+
+   clocks = < IMX6SX_CLK_IPG>;
+   reset-gpios = < 6 GPIO_ACTIVE_LOW>; /* 
ethernet_rst */
+   reset-duration-us = <15>;
+   };
+   };
+};
-- 
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

[PATCH v3 6/6] ARM: dts: imx6qdl-udoo.dtsi: fix onboard USB HUB property

[Peter Chen]

The current dts describes USB HUB's property at USB controller's
entry, it is improper. The USB HUB should be the child node
under USB controller, and power sequence properties are under
it.

Signed-off-by: Peter Chen 
---
 arch/arm/boot/dts/imx6qdl-udoo.dtsi | 26 +-
 1 file changed, 13 insertions(+), 13 deletions(-)

diff --git a/arch/arm/boot/dts/imx6qdl-udoo.dtsi 
b/arch/arm/boot/dts/imx6qdl-udoo.dtsi
index 3bee2f9..f29a72c2f 100644
--- a/arch/arm/boot/dts/imx6qdl-udoo.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-udoo.dtsi
@@ -9,6 +9,8 @@
  *
  */
 
+#include 
+
 / {
aliases {
backlight = 
@@ -58,17 +60,6 @@
#address-cells = <1>;
#size-cells = <0>;
 
-   reg_usb_h1_vbus: regulator@0 {
-   compatible = "regulator-fixed";
-   reg = <0>;
-   regulator-name = "usb_h1_vbus";
-   regulator-min-microvolt = <500>;
-   regulator-max-microvolt = <500>;
-   enable-active-high;
-   startup-delay-us = <2>; /* USB2415 requires a POR of 1 
us minimum */
-   gpio = < 12 0>;
-   };
-
reg_panel: regulator@1 {
compatible = "regulator-fixed";
reg = <1>;
@@ -259,9 +250,18 @@
  {
pinctrl-names = "default";
pinctrl-0 = <_usbh>;
-   vbus-supply = <_usb_h1_vbus>;
-   clocks = < IMX6QDL_CLK_CKO>;
status = "okay";
+
+   #address-cells = <1>;
+   #size-cells = <0>;
+   usb2415: hub@1 {
+   compatible = "usb424,2514";
+   reg = <1>;
+
+   clocks = < IMX6QDL_CLK_CKO>;
+   reset-gpios = < 12 GPIO_ACTIVE_LOW>;
+   reset-duration-us = <3000>;
+   };
 };
 
  {
-- 
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

[PATCH v3 5/6] usb: chipidea: let chipidea core device of_node equal's glue layer device of_node

[Peter Chen]

From: Peter Chen 

At device tree, we have no device node for chipidea core,
the glue layer's node is the parent node for host and udc
device. But in related driver, the parent device is chipidea
core. So, in order to let the common driver get parent's node,
we let the core's device node equals glue layer device node.

Signed-off-by: Peter Chen 
Tested-by: Maciej S. Szmigiero 
---
 drivers/usb/chipidea/core.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
index 69426e6..0d05812 100644
--- a/drivers/usb/chipidea/core.c
+++ b/drivers/usb/chipidea/core.c
@@ -914,6 +914,16 @@ static int ci_hdrc_probe(struct platform_device *pdev)
if (!ci)
return -ENOMEM;
 
+   /*
+* At device tree, we have no device node for chipidea core,
+* the glue layer's node is the parent node for host and udc
+* device. But in related driver, the parent device is chipidea
+* core. So, in order to let the common driver get parent's node,
+* we let the core's device node equals glue layer's node.
+*/
+   if (dev->parent && dev->parent->of_node)
+   dev->of_node = dev->parent->of_node;
+
ci->dev = dev;
ci->platdata = dev_get_platdata(dev);
ci->imx28_write_fix = !!(ci->platdata->flags &
-- 
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

[PATCH v3 3/6] binding-doc: usb: usb-device: add optional properties for power sequence

[Peter Chen]

Add optional properties for power sequence.

Signed-off-by: Peter Chen 
---
 Documentation/devicetree/bindings/usb/usb-device.txt | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/usb/usb-device.txt 
b/Documentation/devicetree/bindings/usb/usb-device.txt
index 1c35e7b..3661dd2 100644
--- a/Documentation/devicetree/bindings/usb/usb-device.txt
+++ b/Documentation/devicetree/bindings/usb/usb-device.txt
@@ -13,6 +13,10 @@ Required properties:
 - reg: the port number which this device is connecting to, the range
   is 1-31.
 
+Optional properties:
+power sequence properties, see
+Documentation/devicetree/bindings/power/pwrseq/pwrseq-generic.txt for detail
+
 Example:
 
  {
@@ -21,8 +25,12 @@ Example:
#address-cells = <1>;
#size-cells = <0>;
 
-   hub: genesys@1 {
+   genesys: hub@1 {
compatible = "usb5e3,608";
reg = <1>;
+
+   clocks = < IMX6SX_CLK_CKO>;
+   reset-gpios = < 5 GPIO_ACTIVE_LOW>; /* hub reset pin */
+   reset-duration-us = <10>;
};
 }
-- 
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

[PATCH v2 1/3] doc: usb: usbmisc-imx: add imx7d compatible string

[Li Jun]

Add compatible string for imx7d-usbmisc.

Acked-by: Rob Herring 
Signed-off-by: Li Jun 
---
 Documentation/devicetree/bindings/usb/usbmisc-imx.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/usb/usbmisc-imx.txt 
b/Documentation/devicetree/bindings/usb/usbmisc-imx.txt
index 3539d4e..f1e27fa 100644
--- a/Documentation/devicetree/bindings/usb/usbmisc-imx.txt
+++ b/Documentation/devicetree/bindings/usb/usbmisc-imx.txt
@@ -6,6 +6,7 @@ Required properties:
"fsl,imx6q-usbmisc" for imx6q
"fsl,vf610-usbmisc" for Vybrid vf610
"fsl,imx6sx-usbmisc" for imx6sx
+   "fsl,imx7d-usbmisc" for imx7d
 - reg: Should contain registers location and length
 
 Examples:
-- 
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: pwc over musb: 100% frame drop (lost) on high resolution stream

[Matwey V. Kornilov]

2016-07-20 9:09 GMT+03:00 Matwey V. Kornilov :
> 2016-07-20 0:34 GMT+03:00 Bin Liu :
>> Hi,
>>
>> On Wed, Jul 20, 2016 at 12:25:44AM +0300, Matwey V. Kornilov wrote:
>>> 2016-07-19 23:56 GMT+03:00 Bin Liu :
>>> > Hi,
>>> >
>>> > On Tue, Jul 19, 2016 at 11:21:17PM +0300, mat...@sai.msu.ru wrote:
>>> >> Hello,
>>> >>
>>> >> I have Philips SPC 900 camera (0471:0329) connected to my AM335x based 
>>> >> BeagleBoneBlack SBC.
>>> >> I am sure that both of them are fine and work properly.
>>> >> I am running Linux 4.6.4 (my kernel config is available at 
>>> >> https://clck.ru/A2kQs ) and I've just discovered, that there is an issue 
>>> >> with frame transfer when high resolution formats are used.
>>> >>
>>> >> The issue is the following. I use simple v4l2 example tool (taken from 
>>> >> API docs), which source code is available at http://pastebin.com/grcNXxfe
>>> >>
>>> >> When I use (see line 488) 640x480 frames
>>> >>
>>> >> fmt.fmt.pix.width   = 640;
>>> >> fmt.fmt.pix.height  = 480;
>>> >>
>>> >> then I get "select timeout" and don't get any frames.
>>> >>
>>> >> When I use 320x240 frames
>>> >>
>>> >> fmt.fmt.pix.width   = 320;
>>> >> fmt.fmt.pix.height  = 240;
>>> >>
>>> >> then about 60% frames are missed. An example outpout of ./a.out -f is 
>>> >> available at https://yadi.sk/d/aRka8xWPtSc4y
>>> >> It looks like there are pauses between bulks of frames (frame counter 
>>> >> and timestamp as returned from v4l2 API):
>>> >>
>>> >> 3 3705.142553
>>> >> 8 3705.342533
>>> >> 13 3705.542517
>>> >> 110 3708.776208
>>> >> 115 3708.976190
>>> >> 120 3709.176169
>>> >> 125 3709.376152
>>> >> 130 3709.576144
>>> >> 226 3712.807848
>>> >>
>>> >> When I use tiny 160x120 frames
>>> >>
>>> >> fmt.fmt.pix.width   = 160;
>>> >> fmt.fmt.pix.height  = 120;
>>> >>
>>> >> then more frames are received. See output example at 
>>> >> https://yadi.sk/d/DedBmH6ftSc9t
>>> >> That is why I thought that everything was fine in May when used tiny 
>>> >> xawtv window to check kernel OOPS presence (see 
>>> >> http://www.spinics.net/lists/linux-usb/msg141188.html for reference)
>>> >>
>>> >> Even more. When I introduce USB hub between the host and the webcam, I 
>>> >> can not receive even any 320x240 frames.
>>> >>
>>> >> I've managed to use ftrace to see what is going on when no frames are 
>>> >> received.
>>> >> I've found that pwc_isoc_handler is called frequently as the following:
>>> >>
>>> >>  0)   |  pwc_isoc_handler [pwc]() {
>>> >>  0)   |usb_submit_urb [usbcore]() {
>>> >>  0)   |  usb_submit_urb.part.3 [usbcore]() {
>>> >>  0)   |usb_hcd_submit_urb [usbcore]() {
>>> >>  0)   0.834 us|  usb_get_urb [usbcore]();
>>> >>  0)   |  musb_map_urb_for_dma [musb_hdrc]() {
>>> >>  0)   0.792 us|usb_hcd_map_urb_for_dma [usbcore]();
>>> >>  0)   5.750 us|  }
>>> >>  0)   |  musb_urb_enqueue [musb_hdrc]() {
>>> >>  0)   0.750 us|_raw_spin_lock_irqsave();
>>> >>  0)   |usb_hcd_link_urb_to_ep [usbcore]() {
>>> >>  0)   0.792 us|  _raw_spin_lock();
>>> >>  0)   0.791 us|  _raw_spin_unlock();
>>> >>  0) + 10.500 us   |}
>>> >>  0)   0.791 us|_raw_spin_unlock_irqrestore();
>>> >>  0) + 25.375 us   |  }
>>> >>  0) + 45.208 us   |}
>>> >>  0) + 51.042 us   |  }
>>> >>  0) + 56.084 us   |}
>>> >>  0) + 61.292 us   |  }
>>> >>
>>> >> However, pwc_isoc_handler never calls vb2_buffer_done() that is why I 
>>> >> get "select timeout" in userspace.
>>> >> Unfortunately, my kernel is not compiled with CONFIG_USB_PWC_DEBUG=y but 
>>> >> I can recompile it, if you think that it could provide more information. 
>>> >> I am also ready to perform additional tests (use usbmon maybe?).
>>> >>
>>> >> How could this issue be resolved?
>>> >>
>>> >> Thank you.
>>> >
>>> > Do you have CPPI DMA enabled? If so I think you might hit on a known
>>> > issue in CPPI Isoch transfer, in which the MUSB controller only sends IN
>>> > tokens in every other SOF, so only half of the bus bandwidth is
>>> > utilized, which causes video frame drops in higher resolution.
>>> >
>>>
>>> Yes, I do use DMA:
>>>
>>> CONFIG_USB_TI_CPPI41_DMA=y
>>
>> Okay.
>>
>>>
>>> > To confirm this, use a bus analyzer to capture a bus trace, you would
>>> > see no IN tokens in every other SOF while transfering Isoch packets.
>>> >
>>>
>>> I am sorry, I am new to USB debugging. Do you mean I need to use
>>> usbmon or some external hardware device?
>>
>> I barely use usbmon, and not sure if it gives the information I am
>> looking for. But I meant the external test equipment - USB bus protocol
>> analyzer - a bus packet sniffer.
>>
>
> Now I see. I've googled it, they 

Re: [PATCH 1/1] usb: xhci: Fix panic if disconnect

[Felipe Balbi]

Hi Jim,

Jim Lin  writes:
> After a device is disconnected, xhci_stop_device() will be invoked
> in xhci_bus_suspend().
> Also the "disconnect" IRQ will have ISR to invoke
> xhci_free_virt_device() in this sequence.
> xhci_irq -> xhci_handle_event -> handle_cmd_completion ->
> xhci_handle_cmd_disable_slot -> xhci_free_virt_device
>
> If xhci->devs[slot_id] has been assigned to NULL in
> xhci_free_virt_device(), then virt_dev->eps[i].ring in
> xhci_stop_device() may point to an invlid address to cause kernel
> panic.
>
> virt_dev = xhci->devs[slot_id];
> :
> if (virt_dev->eps[i].ring && virt_dev->eps[i].ring->dequeue)
>
> [] Unable to handle kernel paging request at virtual address 1a68
> [] pgd=ffc00143
> [] [1a68] *pgd=00013c807003, *pud=00013c807003,
> *pmd=00013c808003, *pte=
> [] Internal error: Oops: 9606 [#1] PREEMPT SMP
> [] CPU: 0 PID: 39 Comm: kworker/0:1 Tainted: G U
> [] Workqueue: pm pm_runtime_work
> [] task: ffc0bc0e0bc0 ti: ffc0bc0ec000 task.ti:
> ffc0bc0ec000
> [] PC is at xhci_stop_device.constprop.11+0xb4/0x1a4
>
> This issue is found when running with realtek ethernet device
> (0bda:8153).
>
> Signed-off-by: Jim Lin 

yes, I saw the previous version :-) So, we're pretty close to getting
the merge window opened. This will defer to v4.8-rc1.

Patch looks good, though. :-)

thanks

-- 
balbi


signature.asc
Description: PGP signature

[PATCH v2 2/3] doc: usb: ci-hdrc-usb2: add property over-current-active-high

[Li Jun]

Adding over-current-active-high to indicate the over current flag
is high active as typically we use active low for over current
polarity.

Signed-off-by: Li Jun 
---
 Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt 
b/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt
index 341dc67..0e03344 100644
--- a/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt
+++ b/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt
@@ -81,6 +81,8 @@ i.mx specific properties
 - fsl,usbmisc: phandler of non-core register device, with one
   argument that indicate usb controller index
 - disable-over-current: disable over current detect
+- over-current-active-high: over current signal polarity is high active,
+  typically over current signal polarity is low active.
 - external-vbus-divider: enables off-chip resistor divider for Vbus
 
 Example:
-- 
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 V2] leds: trigger: Introduce an USB port trigger

[Pavel Machek]

On Mon 2016-07-18 08:55:52, Rafał Miłecki wrote:
> On 18 July 2016 at 07:53, Peter Chen  wrote:
> > On Mon, Jul 18, 2016 at 07:57:34AM +0200, Rafał Miłecki wrote:
> >> On 18 July 2016 at 07:40, Peter Chen  wrote:
> >> > On Mon, Jul 18, 2016 at 06:44:49AM +0200, Rafał Miłecki wrote:
> >> >> On 18 July 2016 at 04:31, Peter Chen  wrote:
> >> >> > On Fri, Jul 15, 2016 at 11:10:45PM +0200, Rafał Miłecki wrote:
> >> >> >> +
> >> >> >> +usbport trigger:
> >> >> >> +- usb-ports : List of USB ports that usbport should observed for 
> >> >> >> turning on a
> >> >> >> +   given LED.
> >> >> >> +
> >> >> >
> >> >> > %s/should/should be
> >> >>
> >> >> Thanks.
> >> >>
> >> >>
> >> >> >> diff --git a/drivers/leds/trigger/ledtrig-usbport.c 
> >> >> >> b/drivers/leds/trigger/ledtrig-usbport.c
> >> >> >> new file mode 100644
> >> >> >> index 000..97b064c
> >> >> >> --- /dev/null
> >> >> >> +++ b/drivers/leds/trigger/ledtrig-usbport.c
> >> >> >> @@ -0,0 +1,206 @@
> >> >> >> +/*
> >> >> >> + * USB port LED trigger
> >> >> >> + *
> >> >> >> + * Copyright (C) 2016 Rafał Miłecki 
> >> >> >> + *
> >> >> >> + * This program is free software; you can redistribute it and/or 
> >> >> >> modify
> >> >> >> + * it under the terms of the GNU General Public License as 
> >> >> >> published by
> >> >> >> + * the Free Software Foundation; either version 2 of the License, 
> >> >> >> or (at
> >> >> >> + * your option) any later version.
> >> >> >> + */
> >> >> >
> >
> > In your COPYRIGHT, it says "or any later version". But afaik, It should
> > not be on GPL v3.
> 
> If one picks my code, modifies it, relicenses it using GPL v3, we
> can't include it anymore. It's the same story as with BSD systems and
> their BSD licenses. If one picks e.g. BSD 3-clause licensed code,
> makes it GPL, releases it (e.g. by putting in Linux), BSD can't use it
> anymore.
> 
> Still, this license is GPL v2 compatible and as is it can be included
> in the Linux.

Anything GPLv2 compatible is fair game for the kernel. GPLv2+ is very
common for the kernel.

Best regards,
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V2] leds: trigger: Introduce an USB port trigger

[Rafał Miłecki]

On 20 July 2016 at 03:02, Rob Herring  wrote:
> On Fri, Jul 15, 2016 at 11:10:45PM +0200, Rafał Miłecki wrote:
>> This commit adds a new trigger that can turn on LED when USB device gets
>> connected to the USB port. This can be useful for various home routers
>> that have USB port and a proper LED telling user a device is connected.
>>
>> Right now this trigger is usable with a proper DT only, there isn't a
>> way to specify USB ports from user space. This may change in a future.
>>
>> Signed-off-by: Rafał Miłecki 
>> ---
>> V2: The first version got support for specifying list of USB ports from
>> user space only. There was a (big try &) discussion on adding DT
>> support. It led to a pretty simple solution of comparing of_node of
>> usb_device to of_node specified in usb-ports property.
>> Since it appeared DT support may be simpler and non-DT a bit more
>> complex, this version drops previous support for "ports" and
>> "new_port" and focuses on DT only. The plan is to see if this
>> solution with DT is OK, get it accepted and then work on non-DT.
>>
>> Felipe: if there won't be any objections I'd like to ask for your Ack.
>> ---
>>  Documentation/devicetree/bindings/leds/common.txt |  11 ++
>>  Documentation/leds/ledtrig-usbport.txt|  19 ++
>>  drivers/leds/trigger/Kconfig  |   8 +
>>  drivers/leds/trigger/Makefile |   1 +
>>  drivers/leds/trigger/ledtrig-usbport.c| 206 
>> ++
>>  5 files changed, 245 insertions(+)
>>  create mode 100644 Documentation/leds/ledtrig-usbport.txt
>>  create mode 100644 drivers/leds/trigger/ledtrig-usbport.c
>>
>> diff --git a/Documentation/devicetree/bindings/leds/common.txt 
>> b/Documentation/devicetree/bindings/leds/common.txt
>> index af10678..75536f7 100644
>> --- a/Documentation/devicetree/bindings/leds/common.txt
>> +++ b/Documentation/devicetree/bindings/leds/common.txt
>> @@ -50,6 +50,12 @@ property can be omitted.
>>  For controllers that have no configurable timeout the flash-max-timeout-us
>>  property can be omitted.
>>
>> +Trigger specific properties for child nodes:
>> +
>> +usbport trigger:
>> +- usb-ports : List of USB ports that usbport should observed for turning on 
>> a
>> +   given LED.
>
> I think this should be more generic such that it could work for disk or
> network LEDs too. Perhaps 'led-triggers = '? trigger is a bit of
> a Linux name, but I haven't thought of anything better. Really, I'd
> prefer the link in the other direction (e.g. port node have a 'leds" or
> '*-leds' property), but that's maybe harder to parse.

I was already thinking on this as I plan to add "netdev" trigger at
some point in the future. I'd like to use "net-devices" for it (as a
equivalent or "usb-ports").

However there is a problem with your idea of sharing "led-triggers"
between triggers.. Consider device with generic purpose LED that
should be controllable by a user. I believe we should let user switch
it's state, e.g. with:
echo usbport > trigger
echo netdev > trigger
with a shared property I don't see how we couldn't handle it properly.
I don't think we can use anything like:
led-triggers = <_port1>, <_port1>, <>;
I'd get even more complicated if we ever need cells for any trigger.
AFAIK it's not allowed to mix handles with different cells like:
led-triggers = <_port1>, < 5>, <>;

These problems made me use trigger-specific properies for specifying
LED triggers. Do you have any other idea for sharing a property &
avoiding above problems at the same time?


>> +
>>  Examples:
>>
>>  system-status {
>> @@ -58,6 +64,11 @@ system-status {
>>   ...
>>  };
>>
>> +usb {
>> + label = "USB";
>
> It's not really clear in the example this is an LED node as it is
> incomplete.

What do you mean by incomplete? Should I include e.g. ohci_port1 in
this example?


>> + usb-ports = <_port1>, <_port1>;
>> +};
>> +
>>  camera-flash {
>>   label = "Flash";
>>   led-sources = <0>, <1>;
>> diff --git a/Documentation/leds/ledtrig-usbport.txt 
>> b/Documentation/leds/ledtrig-usbport.txt
>> new file mode 100644
>> index 000..642c4cd
>> --- /dev/null
>> +++ b/Documentation/leds/ledtrig-usbport.txt
>> @@ -0,0 +1,19 @@
>> +USB port LED trigger
>> +
>> +
>> +This LED trigger can be used for signaling user a presence of USB device in 
>> a
>> +given port. It simply turns on LED when device appears and turns it off 
>> when it
>> +disappears.
>> +
>> +It requires specifying a list of USB ports that should be observed. This 
>> can be
>> +done in DT by setting a proper property with list of a phandles. If more 
>> than
>> +one port is specified, LED will be turned on as along as there is at least 
>> one
>> +device connected to any of ports.
>> +
>> +This trigger can be activated from user space on led class devices as shown
>> +below:
>> +
>> +  echo usbport > trigger
>
> Why do I have to do this (by 

Re: [PATCH V2] leds: trigger: Introduce an USB port trigger

[Pavel Machek]

Hi!

> > @@ -0,0 +1,206 @@
> > +/*
> > + * USB port LED trigger
> > + *
> > + * Copyright (C) 2016 Rafał Miłecki 
> > + *
> > + * This program is free software; you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License as published by
> > + * the Free Software Foundation; either version 2 of the License, or (at
> > + * your option) any later version.
> > + */
> 
> GPL v2 only.

No, you are not going to tell people which license they can use for
their kernel code.

GPL v2+ is perfectly fine for the kernel.

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/1] usb: xhci: Fix panic if disconnect

[Jim Lin]

After a device is disconnected, xhci_stop_device() will be invoked
in xhci_bus_suspend().
Also the "disconnect" IRQ will have ISR to invoke
xhci_free_virt_device() in this sequence.
xhci_irq -> xhci_handle_event -> handle_cmd_completion ->
xhci_handle_cmd_disable_slot -> xhci_free_virt_device

If xhci->devs[slot_id] has been assigned to NULL in
xhci_free_virt_device(), then virt_dev->eps[i].ring in
xhci_stop_device() may point to an invlid address to cause kernel
panic.

virt_dev = xhci->devs[slot_id];
:
if (virt_dev->eps[i].ring && virt_dev->eps[i].ring->dequeue)

[] Unable to handle kernel paging request at virtual address 1a68
[] pgd=ffc00143
[] [1a68] *pgd=00013c807003, *pud=00013c807003,
*pmd=00013c808003, *pte=
[] Internal error: Oops: 9606 [#1] PREEMPT SMP
[] CPU: 0 PID: 39 Comm: kworker/0:1 Tainted: G U
[] Workqueue: pm pm_runtime_work
[] task: ffc0bc0e0bc0 ti: ffc0bc0ec000 task.ti:
ffc0bc0ec000
[] PC is at xhci_stop_device.constprop.11+0xb4/0x1a4

This issue is found when running with realtek ethernet device
(0bda:8153).

Signed-off-by: Jim Lin 
---
 drivers/usb/host/xhci-hub.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/usb/host/xhci-hub.c b/drivers/usb/host/xhci-hub.c
index d61fcc4..730b9fd 100644
--- a/drivers/usb/host/xhci-hub.c
+++ b/drivers/usb/host/xhci-hub.c
@@ -386,6 +386,9 @@ static int xhci_stop_device(struct xhci_hcd *xhci, int 
slot_id, int suspend)
 
ret = 0;
virt_dev = xhci->devs[slot_id];
+   if (!virt_dev)
+   return -ENODEV;
+
cmd = xhci_alloc_command(xhci, false, true, GFP_NOIO);
if (!cmd) {
xhci_dbg(xhci, "Couldn't allocate command structure.\n");
-- 
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 net-next v3] cdc_ether: Improve ZTE MF823/831/910 handling

[Oliver Neukum]

On Tue, 2016-07-19 at 16:54 +0200, Kristian Evensen wrote:
> The firmware in several ZTE devices (at least the MF823/831/910
> modems/mifis) use OS fingerprinting to determine which type of device
> to
> export. In addition, these devices export a REST API which can be used
> to
> control the type of device. So far, on Linux, the devices have been
> seen as
> RNDIS or CDC Ether.
> 
> When CDC Ether is used, devices of the same type are, as with RNDIS,
> exported with the same, bogus random MAC address. In addition, the
> devices
> (at least on all firmware revisions I have found) use the bogus MAC
> when
> sending traffic routed from external networks. And as a final feature,
> the
> devices sometimes export the link state incorrectly. There are also
> references online to several other ZTE devices displaying this
> behavior,
> with several different PIDs and MAC addresses.
> 
> This patch tries to improve the handling of ZTE devices by doing the
> following:
> 
> * Create a new driver_info-struct that is used by ZTE devices that do
> not
> have an explicit entry in the product table. This struct is the same
> as the
> default cdc_ether driver info, but a new bind- and an
> rx_fixup-function
> have been added.
> 
> * In the new bind function, we check if we have read a random MAC from
> the
> device. If we have, then we generate a new random MAC address. This
> will
> ensure that all devices get a unique MAC.
> 
> * The rx_fixup-function replaces the destination MAC address in the
> skb
> with that of the device. I have not seen a revision of these devices
> that
> behaves correctly (i.e., sets the right destination MAC), so I chose
> not to
> do any comparison with for example the known, bogus addresses.
> 
> * The MF823/MF832/MF910 sometimes export cdc carrier on twice on
> connect
> (the correct behavior is off then on). Work around this by manually
> setting
> carrier to off if an on-notification is received and the NOCARRIER-bit
> is
> not set.
> 
> This change will affect all devices, but it should take care of
> similar
> mistakes made by other manufacturers. I tried to think of/look/test
> for
> problems/regressions that could be introduced by this behavior, but
> could
> not find any. However, my familiarity with this code path is not that
> great, so there could be something I have overlooked.
> 
> I have tested this patch with multiple revisions of all three devices,
> and
> they behave as expected. In other words, they all got a valid, random
> MAC,
> the correct operational state and I can receive/sent traffic without
> problems. I also tested with some other cdc_ether devices I have and
> did
> not find any problems/regressions caused by the two general changes.
> 
> v2->v3:
> * I had forgot to remove the random MAC generation from
> usbnet_cdc_bind()
> (thanks Olive).
> * Rework logic in the ZTE bind-function a bit.
> 
> v1->v2:
> * Only generate random MAC for ZTE devices (thanks Oliver Neukum).
> * Set random MAC and do RX fixup for all ZTE devices that do not have
> a
> product-entry, as the bogus MAC have been seen on devices with several
> different PIDs/MAC addresses. In other words, it seems to be the
> default
> behavior of ZTE CDC Ether devices (thanks Lars Melin).
> 
> Signed-off-by: Kristian Evensen 
Acked-by: Oliver Neukum 

--
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/1] usb: xhci: Fix panic if disconnect

[Jim Lin]

After a device is disconnected, xhci_stop_device() will be invoked
in xhci_bus_suspend().
Also the "disconnect" IRQ will have ISR to invoke
xhci_free_virt_device() in this sequence.
xhci_irq -> xhci_handle_event -> handle_cmd_completion ->
xhci_handle_cmd_disable_slot -> xhci_free_virt_device

If xhci->devs[slot_id] has been assigned to NULL in
xhci_free_virt_device(), then virt_dev->eps[i].ring in
xhci_stop_device() may point to an invlid address to cause kernel
panic.

virt_dev = xhci->devs[slot_id];
:
if (virt_dev->eps[i].ring && virt_dev->eps[i].ring->dequeue)

[] Unable to handle kernel paging request at virtual address 1a68
[] pgd=ffc00143
[] [1a68] *pgd=00013c807003, *pud=00013c807003,
*pmd=00013c808003, *pte=
[] Internal error: Oops: 9606 [#1] PREEMPT SMP
[] CPU: 0 PID: 39 Comm: kworker/0:1 Tainted: G U
[] Workqueue: pm pm_runtime_work
[] task: ffc0bc0e0bc0 ti: ffc0bc0ec000 task.ti:
ffc0bc0ec000
[] PC is at xhci_stop_device.constprop.11+0xb4/0x1a4

This issue is found when running with realtek ethernet device
(0bda:8153).

Signed-off-by: Jim Lin 
---
 drivers/usb/host/xhci-hub.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/usb/host/xhci-hub.c b/drivers/usb/host/xhci-hub.c
index d61fcc4..730b9fd 100644
--- a/drivers/usb/host/xhci-hub.c
+++ b/drivers/usb/host/xhci-hub.c
@@ -386,6 +386,9 @@ static int xhci_stop_device(struct xhci_hcd *xhci, int 
slot_id, int suspend)
 
ret = 0;
virt_dev = xhci->devs[slot_id];
+   if (!virt_dev)
+   return -ENODEV;
+
cmd = xhci_alloc_command(xhci, false, true, GFP_NOIO);
if (!cmd) {
xhci_dbg(xhci, "Couldn't allocate command structure.\n");
-- 
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: pwc over musb: 100% frame drop (lost) on high resolution stream

[Matwey V. Kornilov]

2016-07-20 0:34 GMT+03:00 Bin Liu :
> Hi,
>
> On Wed, Jul 20, 2016 at 12:25:44AM +0300, Matwey V. Kornilov wrote:
>> 2016-07-19 23:56 GMT+03:00 Bin Liu :
>> > Hi,
>> >
>> > On Tue, Jul 19, 2016 at 11:21:17PM +0300, mat...@sai.msu.ru wrote:
>> >> Hello,
>> >>
>> >> I have Philips SPC 900 camera (0471:0329) connected to my AM335x based 
>> >> BeagleBoneBlack SBC.
>> >> I am sure that both of them are fine and work properly.
>> >> I am running Linux 4.6.4 (my kernel config is available at 
>> >> https://clck.ru/A2kQs ) and I've just discovered, that there is an issue 
>> >> with frame transfer when high resolution formats are used.
>> >>
>> >> The issue is the following. I use simple v4l2 example tool (taken from 
>> >> API docs), which source code is available at http://pastebin.com/grcNXxfe
>> >>
>> >> When I use (see line 488) 640x480 frames
>> >>
>> >> fmt.fmt.pix.width   = 640;
>> >> fmt.fmt.pix.height  = 480;
>> >>
>> >> then I get "select timeout" and don't get any frames.
>> >>
>> >> When I use 320x240 frames
>> >>
>> >> fmt.fmt.pix.width   = 320;
>> >> fmt.fmt.pix.height  = 240;
>> >>
>> >> then about 60% frames are missed. An example outpout of ./a.out -f is 
>> >> available at https://yadi.sk/d/aRka8xWPtSc4y
>> >> It looks like there are pauses between bulks of frames (frame counter and 
>> >> timestamp as returned from v4l2 API):
>> >>
>> >> 3 3705.142553
>> >> 8 3705.342533
>> >> 13 3705.542517
>> >> 110 3708.776208
>> >> 115 3708.976190
>> >> 120 3709.176169
>> >> 125 3709.376152
>> >> 130 3709.576144
>> >> 226 3712.807848
>> >>
>> >> When I use tiny 160x120 frames
>> >>
>> >> fmt.fmt.pix.width   = 160;
>> >> fmt.fmt.pix.height  = 120;
>> >>
>> >> then more frames are received. See output example at 
>> >> https://yadi.sk/d/DedBmH6ftSc9t
>> >> That is why I thought that everything was fine in May when used tiny 
>> >> xawtv window to check kernel OOPS presence (see 
>> >> http://www.spinics.net/lists/linux-usb/msg141188.html for reference)
>> >>
>> >> Even more. When I introduce USB hub between the host and the webcam, I 
>> >> can not receive even any 320x240 frames.
>> >>
>> >> I've managed to use ftrace to see what is going on when no frames are 
>> >> received.
>> >> I've found that pwc_isoc_handler is called frequently as the following:
>> >>
>> >>  0)   |  pwc_isoc_handler [pwc]() {
>> >>  0)   |usb_submit_urb [usbcore]() {
>> >>  0)   |  usb_submit_urb.part.3 [usbcore]() {
>> >>  0)   |usb_hcd_submit_urb [usbcore]() {
>> >>  0)   0.834 us|  usb_get_urb [usbcore]();
>> >>  0)   |  musb_map_urb_for_dma [musb_hdrc]() {
>> >>  0)   0.792 us|usb_hcd_map_urb_for_dma [usbcore]();
>> >>  0)   5.750 us|  }
>> >>  0)   |  musb_urb_enqueue [musb_hdrc]() {
>> >>  0)   0.750 us|_raw_spin_lock_irqsave();
>> >>  0)   |usb_hcd_link_urb_to_ep [usbcore]() {
>> >>  0)   0.792 us|  _raw_spin_lock();
>> >>  0)   0.791 us|  _raw_spin_unlock();
>> >>  0) + 10.500 us   |}
>> >>  0)   0.791 us|_raw_spin_unlock_irqrestore();
>> >>  0) + 25.375 us   |  }
>> >>  0) + 45.208 us   |}
>> >>  0) + 51.042 us   |  }
>> >>  0) + 56.084 us   |}
>> >>  0) + 61.292 us   |  }
>> >>
>> >> However, pwc_isoc_handler never calls vb2_buffer_done() that is why I get 
>> >> "select timeout" in userspace.
>> >> Unfortunately, my kernel is not compiled with CONFIG_USB_PWC_DEBUG=y but 
>> >> I can recompile it, if you think that it could provide more information. 
>> >> I am also ready to perform additional tests (use usbmon maybe?).
>> >>
>> >> How could this issue be resolved?
>> >>
>> >> Thank you.
>> >
>> > Do you have CPPI DMA enabled? If so I think you might hit on a known
>> > issue in CPPI Isoch transfer, in which the MUSB controller only sends IN
>> > tokens in every other SOF, so only half of the bus bandwidth is
>> > utilized, which causes video frame drops in higher resolution.
>> >
>>
>> Yes, I do use DMA:
>>
>> CONFIG_USB_TI_CPPI41_DMA=y
>
> Okay.
>
>>
>> > To confirm this, use a bus analyzer to capture a bus trace, you would
>> > see no IN tokens in every other SOF while transfering Isoch packets.
>> >
>>
>> I am sorry, I am new to USB debugging. Do you mean I need to use
>> usbmon or some external hardware device?
>
> I barely use usbmon, and not sure if it gives the information I am
> looking for. But I meant the external test equipment - USB bus protocol
> analyzer - a bus packet sniffer.
>

Now I see. I've googled it, they start from $1000, I don't know
when/whether/where I can get one to try.
Until that, could I check something else? For instance, disable
CONFIG_USB_TI_CPPI41_DMA.

I've found that after