Re: [PATCH v2] usb: host: xhci: Enable XHCI_SPURIOUS_SUCCESS for all controllers with xhci 1.0

2013-07-25 Thread Shuduo Sang 
On Thu, Jul 25, 2013 at 12:30 AM, Sarah Sharp
sarah.a.sh...@linux.intel.com wrote:
 On Mon, Jul 22, 2013 at 03:58:19PM +0800, Shuduo Sang wrote:
 On Mon, Jul 22, 2013 at 3:23 PM, George Cherian george.cher...@ti.com 
 wrote:
 Yes, I run below script to capture picture.

 #!/bin/bash
 # camera_stress.sh
 # Testing the camera by BinLi

 for ((i=0; i10 ; i++))
 do
 fswebcam --no-banner -r 352x288 -d /dev/video0 test_$i.jpg
 done

 It will randomly fail at later loops. The fail rate about 20%~30%. When it 
 fail,
 I can see error messages by dmesg as below:

 [ 68.171039] xhci_hcd :00:14.0: ERROR Transfer event TRB DMA ptr
 not part of current TD
 [ 68.175030] xhci_hcd :00:14.0: ERROR Transfer event TRB DMA ptr
 not part of current TD
 [ 68.179026] xhci_hcd :00:14.0: ERROR Transfer event TRB DMA ptr
 not part of current TD
 [ 68.180082] usb 3-12: USB disconnect, device number 4
 [ 68.450459] usb 3-12: new high-speed USB device number 5 using xhci_hcd
 [ 68.477960] usb 3-12: New USB device found, idVendor=5986, idProduct=0397
 [ 68.477964] usb 3-12: New USB device strings: Mfr=1, Product=2, 
 SerialNumber=0
 [ 68.477966] usb 3-12: Product: Integrated Camera
 [ 68.477968] usb 3-12: Manufacturer: Vimicro corp.
 [ 68.479107] uvcvideo: Found UVC 1.00 device Integrated Camera (5986:0397)
 [ 68.479821] input: Integrated Camera as
 /devices/pci:00/:00:14.0/usb3/3-12/3-12:1.0/input/input15
 [ 321.389721] type=1400 audit(1374214638.182:29): apparmor=DENIED
 operation=capable parent=1 profile=/usr/sbin/cupsd pid=1232
 comm=cupsd pid=1232 comm=cupsd c
 apability=36 capname=block_suspend

 That's a different issue.  The log shows that your USB webcam
 disconnects, and that's why your script fails.  Then the device
 re-connects.


Hmm, I think you are right. I tried my script on another laptop with
Lynx Point host and same webcam, it works very well. Sorry if my
information misled you and George.

 Do other USB devices work after the camera disconnects?  Does the webcam
 itself work (at least for a while) after you stop and restart the
 script?  (Note that after a disconnect, the webcam may be present on
 /dev/video1 instead of /dev/video0, because your script had /dev/video0
 open when the webcam re-connected.)

  Then I manually applied George's patch against 3.10.0 but the issue
  still happen when I use
  camera to capture picture.
 
  Can you explain what is the exact issue you face after applying the patch?
  Are you still getting
 
  ERROR Transfer event TRB DMA ptr not part of current TD

 Yes, after I applied your patch manually, I still getting this error.
 Seems fail rate is same.

 I'm still going to apply George's patch, because it does fix a different
 issue.


Is there any code piece to triage the issue George's patch fix? Then I can
do some verification with George's patch or without.

 I'm not sure if there's anything software can do if the webcam keeps
 disconnecting.  That's usually an electrical issue.  Have you tried a
 different USB cable?  If the webcam is behind a hub, have you tried
 connecting it directly to the computer's roothub?  If it's attached to
 the roothub, have you tried putting it behind an external hub?

 If none of that works, I can look at your logs, and try to figure out if
 there's anything software can do.  Can you recompile your kernel with
 George's patch and CONFIG_USB_DEBUG and CONFIG_USB_XHCI_HCD_DEBUGGING
 turned on?  Please send me the log from just before you start your
 script to when the device disconnects.

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

Re: [PATCH v2] usb: host: xhci: Enable XHCI_SPURIOUS_SUCCESS for all controllers with xhci 1.0

2013-07-24 Thread Sarah Sharp 
On Mon, Jul 22, 2013 at 03:58:19PM +0800, Shuduo Sang wrote:
 On Mon, Jul 22, 2013 at 3:23 PM, George Cherian george.cher...@ti.com wrote:
 Yes, I run below script to capture picture.
 
 #!/bin/bash
 # camera_stress.sh
 # Testing the camera by BinLi
 
 for ((i=0; i10 ; i++))
 do
 fswebcam --no-banner -r 352x288 -d /dev/video0 test_$i.jpg
 done
 
 It will randomly fail at later loops. The fail rate about 20%~30%. When it 
 fail,
 I can see error messages by dmesg as below:
 
 [ 68.171039] xhci_hcd :00:14.0: ERROR Transfer event TRB DMA ptr
 not part of current TD
 [ 68.175030] xhci_hcd :00:14.0: ERROR Transfer event TRB DMA ptr
 not part of current TD
 [ 68.179026] xhci_hcd :00:14.0: ERROR Transfer event TRB DMA ptr
 not part of current TD
 [ 68.180082] usb 3-12: USB disconnect, device number 4
 [ 68.450459] usb 3-12: new high-speed USB device number 5 using xhci_hcd
 [ 68.477960] usb 3-12: New USB device found, idVendor=5986, idProduct=0397
 [ 68.477964] usb 3-12: New USB device strings: Mfr=1, Product=2, 
 SerialNumber=0
 [ 68.477966] usb 3-12: Product: Integrated Camera
 [ 68.477968] usb 3-12: Manufacturer: Vimicro corp.
 [ 68.479107] uvcvideo: Found UVC 1.00 device Integrated Camera (5986:0397)
 [ 68.479821] input: Integrated Camera as
 /devices/pci:00/:00:14.0/usb3/3-12/3-12:1.0/input/input15
 [ 321.389721] type=1400 audit(1374214638.182:29): apparmor=DENIED
 operation=capable parent=1 profile=/usr/sbin/cupsd pid=1232
 comm=cupsd pid=1232 comm=cupsd c
 apability=36 capname=block_suspend

That's a different issue.  The log shows that your USB webcam
disconnects, and that's why your script fails.  Then the device
re-connects.

Do other USB devices work after the camera disconnects?  Does the webcam
itself work (at least for a while) after you stop and restart the
script?  (Note that after a disconnect, the webcam may be present on
/dev/video1 instead of /dev/video0, because your script had /dev/video0
open when the webcam re-connected.)

  Then I manually applied George's patch against 3.10.0 but the issue
  still happen when I use
  camera to capture picture.
 
  Can you explain what is the exact issue you face after applying the patch?
  Are you still getting
 
  ERROR Transfer event TRB DMA ptr not part of current TD
 
 Yes, after I applied your patch manually, I still getting this error.
 Seems fail rate is same.

I'm still going to apply George's patch, because it does fix a different
issue.

I'm not sure if there's anything software can do if the webcam keeps
disconnecting.  That's usually an electrical issue.  Have you tried a
different USB cable?  If the webcam is behind a hub, have you tried
connecting it directly to the computer's roothub?  If it's attached to
the roothub, have you tried putting it behind an external hub?

If none of that works, I can look at your logs, and try to figure out if
there's anything software can do.  Can you recompile your kernel with
George's patch and CONFIG_USB_DEBUG and CONFIG_USB_XHCI_HCD_DEBUGGING
turned on?  Please send me the log from just before you start your
script to when the device disconnects.

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

Re: [PATCH v2] usb: host: xhci: Enable XHCI_SPURIOUS_SUCCESS for all controllers with xhci 1.0

2013-07-22 Thread Shuduo Sang 
Hi Sarah and George,

I met this issue at my side too. Per lspci output and HCIVERSION, I
see the host is Lynx
Point xhci 1.0 host.

I notice George's patch has not been merged in kernel 3.11-rc1.
Then I manually applied George's patch against 3.10.0 but the issue
still happen when I use
camera to capture picture. So I doubt some corner test has not been
covered by patch.
Pls let me know what I can do if you need more information.

Thanks,
Shuduo

On Tue, Jul 2, 2013 at 11:27 AM, Sarah Sharp
sarah.a.sh...@linux.intel.com wrote:
 Thanks George, this looks fine.  I will munge the description a bit when
 I commit it, and mark it for stable as well.

 Unfortunately, due to the timing of the merge window, this patch will
 have to wait for 2-3 weeks until 3.11-rc1 is out.

 Sarah Sharp

 On Mon, Jul 01, 2013 at 10:59:12AM +0530, George Cherian wrote:
 Xhci controllers with hci_version  0.96 gives spurious success
 events on short packet completion. During webcam capture the
 ERROR Transfer event TRB DMA ptr not part of current TD was observed.
 The same application works fine with synopsis controllers hci_version 0.96.
 The same Issue is seen with Intel Pantherpoint xhci controller. So enabling
 this quirk in xhci_gen_setup if controller verion is greater than 0.96.
 For xhci-pci move the quirk to much generic place xhci_gen_setup.

 Signed-off-by: George Cherian george.cher...@ti.com
 ---
  drivers/usb/host/xhci-pci.c | 1 -
  drivers/usb/host/xhci.c | 7 +++
  2 files changed, 7 insertions(+), 1 deletion(-)

 diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
 index cc24e39..f00cb20 100644
 --- a/drivers/usb/host/xhci-pci.c
 +++ b/drivers/usb/host/xhci-pci.c
 @@ -93,7 +93,6 @@ static void xhci_pci_quirks(struct device *dev, struct 
 xhci_hcd *xhci)
   }
   if (pdev-vendor == PCI_VENDOR_ID_INTEL 
   pdev-device == PCI_DEVICE_ID_INTEL_PANTHERPOINT_XHCI) 
 {
 - xhci-quirks |= XHCI_SPURIOUS_SUCCESS;
   xhci-quirks |= XHCI_EP_LIMIT_QUIRK;
   xhci-limit_active_eps = 64;
   xhci-quirks |= XHCI_SW_BW_CHECKING;
 diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
 index d8f640b..0f7be59 100644
 --- a/drivers/usb/host/xhci.c
 +++ b/drivers/usb/host/xhci.c
 @@ -4697,6 +4697,13 @@ int xhci_gen_setup(struct usb_hcd *hcd, 
 xhci_get_quirks_t get_quirks)

   get_quirks(dev, xhci);

 + /* In xhci controllers which follow xhci 1.0 spec gives a spurious
 +  * success event after a short transfer. This quirk will ignore such
 +  * spurious event.
 +  */
 + if (xhci-hci_version  0x96)
 + xhci-quirks |= XHCI_SPURIOUS_SUCCESS;
 +
   /* Make sure the HC is halted. */
   retval = xhci_halt(xhci);
   if (retval)
 --
 1.8.1.4

 --
 To unsubscribe from this list: send the line unsubscribe linux-kernel in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 Please read the FAQ at  http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] usb: host: xhci: Enable XHCI_SPURIOUS_SUCCESS for all controllers with xhci 1.0

2013-07-22 Thread George Cherian 


Hi Shuduo,

On 7/22/2013 12:35 PM, Shuduo Sang wrote:

Hi Sarah and George,

I met this issue at my side too. Per lspci output and HCIVERSION, I
see the host is Lynx
Point xhci 1.0 host.

I notice George's patch has not been merged in kernel 3.11-rc1.


Just to make sure, without the patch are you getting the following error.

ERROR Transfer event TRB DMA ptr not part of current TD



Then I manually applied George's patch against 3.10.0 but the issue
still happen when I use
camera to capture picture.


Can you explain what is the exact issue you face after applying the patch?
Are you still getting

ERROR Transfer event TRB DMA ptr not part of current TD


So I doubt some corner test has not been
covered by patch.
Pls let me know what I can do if you need more information.

Thanks,
Shuduo

On Tue, Jul 2, 2013 at 11:27 AM, Sarah Sharp
sarah.a.sh...@linux.intel.com wrote:

Thanks George, this looks fine.  I will munge the description a bit when
I commit it, and mark it for stable as well.

Unfortunately, due to the timing of the merge window, this patch will
have to wait for 2-3 weeks until 3.11-rc1 is out.

Sarah Sharp

On Mon, Jul 01, 2013 at 10:59:12AM +0530, George Cherian wrote:

Xhci controllers with hci_version  0.96 gives spurious success
events on short packet completion. During webcam capture the
ERROR Transfer event TRB DMA ptr not part of current TD was observed.
The same application works fine with synopsis controllers hci_version 0.96.
The same Issue is seen with Intel Pantherpoint xhci controller. So enabling
this quirk in xhci_gen_setup if controller verion is greater than 0.96.
For xhci-pci move the quirk to much generic place xhci_gen_setup.

Signed-off-by: George Cherian george.cher...@ti.com
---
  drivers/usb/host/xhci-pci.c | 1 -
  drivers/usb/host/xhci.c | 7 +++
  2 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
index cc24e39..f00cb20 100644
--- a/drivers/usb/host/xhci-pci.c
+++ b/drivers/usb/host/xhci-pci.c
@@ -93,7 +93,6 @@ static void xhci_pci_quirks(struct device *dev, struct 
xhci_hcd *xhci)
   }
   if (pdev-vendor == PCI_VENDOR_ID_INTEL 
   pdev-device == PCI_DEVICE_ID_INTEL_PANTHERPOINT_XHCI) {
- xhci-quirks |= XHCI_SPURIOUS_SUCCESS;
   xhci-quirks |= XHCI_EP_LIMIT_QUIRK;
   xhci-limit_active_eps = 64;
   xhci-quirks |= XHCI_SW_BW_CHECKING;
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index d8f640b..0f7be59 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -4697,6 +4697,13 @@ int xhci_gen_setup(struct usb_hcd *hcd, 
xhci_get_quirks_t get_quirks)

   get_quirks(dev, xhci);

+ /* In xhci controllers which follow xhci 1.0 spec gives a spurious
+  * success event after a short transfer. This quirk will ignore such
+  * spurious event.
+  */
+ if (xhci-hci_version  0x96)
+ xhci-quirks |= XHCI_SPURIOUS_SUCCESS;
+
   /* Make sure the HC is halted. */
   retval = xhci_halt(xhci);
   if (retval)
--
1.8.1.4


--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


--
-George

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

Re: [PATCH v2] usb: host: xhci: Enable XHCI_SPURIOUS_SUCCESS for all controllers with xhci 1.0

2013-07-22 Thread Shuduo Sang 
On Mon, Jul 22, 2013 at 3:23 PM, George Cherian george.cher...@ti.com wrote:

 Hi Shuduo,


 On 7/22/2013 12:35 PM, Shuduo Sang wrote:

 Hi Sarah and George,

 I met this issue at my side too. Per lspci output and HCIVERSION, I
 see the host is Lynx
 Point xhci 1.0 host.

 I notice George's patch has not been merged in kernel 3.11-rc1.


 Just to make sure, without the patch are you getting the following error.


 ERROR Transfer event TRB DMA ptr not part of current TD


Yes, I run below script to capture picture.

#!/bin/bash
# camera_stress.sh
# Testing the camera by BinLi

for ((i=0; i10 ; i++))
do
fswebcam --no-banner -r 352x288 -d /dev/video0 test_$i.jpg
done

It will randomly fail at later loops. The fail rate about 20%~30%. When it fail,
I can see error messages by dmesg as below:

[ 68.171039] xhci_hcd :00:14.0: ERROR Transfer event TRB DMA ptr
not part of current TD
[ 68.175030] xhci_hcd :00:14.0: ERROR Transfer event TRB DMA ptr
not part of current TD
[ 68.179026] xhci_hcd :00:14.0: ERROR Transfer event TRB DMA ptr
not part of current TD
[ 68.180082] usb 3-12: USB disconnect, device number 4
[ 68.450459] usb 3-12: new high-speed USB device number 5 using xhci_hcd
[ 68.477960] usb 3-12: New USB device found, idVendor=5986, idProduct=0397
[ 68.477964] usb 3-12: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 68.477966] usb 3-12: Product: Integrated Camera
[ 68.477968] usb 3-12: Manufacturer: Vimicro corp.
[ 68.479107] uvcvideo: Found UVC 1.00 device Integrated Camera (5986:0397)
[ 68.479821] input: Integrated Camera as
/devices/pci:00/:00:14.0/usb3/3-12/3-12:1.0/input/input15
[ 321.389721] type=1400 audit(1374214638.182:29): apparmor=DENIED
operation=capable parent=1 profile=/usr/sbin/cupsd pid=1232
comm=cupsd pid=1232 comm=cupsd c
apability=36 capname=block_suspend




 Then I manually applied George's patch against 3.10.0 but the issue
 still happen when I use
 camera to capture picture.


 Can you explain what is the exact issue you face after applying the patch?
 Are you still getting


 ERROR Transfer event TRB DMA ptr not part of current TD


Yes, after I applied your patch manually, I still getting this error.
Seems fail rate is same.

 So I doubt some corner test has not been
 covered by patch.
 Pls let me know what I can do if you need more information.

 Thanks,
 Shuduo

 On Tue, Jul 2, 2013 at 11:27 AM, Sarah Sharp
 sarah.a.sh...@linux.intel.com wrote:

 Thanks George, this looks fine.  I will munge the description a bit when
 I commit it, and mark it for stable as well.

 Unfortunately, due to the timing of the merge window, this patch will
 have to wait for 2-3 weeks until 3.11-rc1 is out.

 Sarah Sharp

 On Mon, Jul 01, 2013 at 10:59:12AM +0530, George Cherian wrote:

 Xhci controllers with hci_version  0.96 gives spurious success
 events on short packet completion. During webcam capture the
 ERROR Transfer event TRB DMA ptr not part of current TD was observed.
 The same application works fine with synopsis controllers hci_version
 0.96.
 The same Issue is seen with Intel Pantherpoint xhci controller. So
 enabling
 this quirk in xhci_gen_setup if controller verion is greater than 0.96.
 For xhci-pci move the quirk to much generic place xhci_gen_setup.

 Signed-off-by: George Cherian george.cher...@ti.com
 ---
   drivers/usb/host/xhci-pci.c | 1 -
   drivers/usb/host/xhci.c | 7 +++
   2 files changed, 7 insertions(+), 1 deletion(-)

 diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
 index cc24e39..f00cb20 100644
 --- a/drivers/usb/host/xhci-pci.c
 +++ b/drivers/usb/host/xhci-pci.c
 @@ -93,7 +93,6 @@ static void xhci_pci_quirks(struct device *dev, struct
 xhci_hcd *xhci)
}
if (pdev-vendor == PCI_VENDOR_ID_INTEL 
pdev-device ==
 PCI_DEVICE_ID_INTEL_PANTHERPOINT_XHCI) {
 - xhci-quirks |= XHCI_SPURIOUS_SUCCESS;
xhci-quirks |= XHCI_EP_LIMIT_QUIRK;
xhci-limit_active_eps = 64;
xhci-quirks |= XHCI_SW_BW_CHECKING;
 diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
 index d8f640b..0f7be59 100644
 --- a/drivers/usb/host/xhci.c
 +++ b/drivers/usb/host/xhci.c
 @@ -4697,6 +4697,13 @@ int xhci_gen_setup(struct usb_hcd *hcd,
 xhci_get_quirks_t get_quirks)

get_quirks(dev, xhci);

 + /* In xhci controllers which follow xhci 1.0 spec gives a spurious
 +  * success event after a short transfer. This quirk will ignore
 such
 +  * spurious event.
 +  */
 + if (xhci-hci_version  0x96)
 + xhci-quirks |= XHCI_SPURIOUS_SUCCESS;
 +
/* Make sure the HC is halted. */
retval = xhci_halt(xhci);
if (retval)
 --
 1.8.1.4

 --
 To unsubscribe from this list: send the line unsubscribe linux-kernel
 in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 Please read the FAQ at  http://www.tux.org/lkml/


 --

Re: [PATCH v2] usb: host: xhci: Enable XHCI_SPURIOUS_SUCCESS for all controllers with xhci 1.0

2013-07-01 Thread Sarah Sharp 
Thanks George, this looks fine.  I will munge the description a bit when
I commit it, and mark it for stable as well.

Unfortunately, due to the timing of the merge window, this patch will
have to wait for 2-3 weeks until 3.11-rc1 is out.

Sarah Sharp

On Mon, Jul 01, 2013 at 10:59:12AM +0530, George Cherian wrote:
 Xhci controllers with hci_version  0.96 gives spurious success
 events on short packet completion. During webcam capture the
 ERROR Transfer event TRB DMA ptr not part of current TD was observed.
 The same application works fine with synopsis controllers hci_version 0.96.
 The same Issue is seen with Intel Pantherpoint xhci controller. So enabling
 this quirk in xhci_gen_setup if controller verion is greater than 0.96.
 For xhci-pci move the quirk to much generic place xhci_gen_setup.
 
 Signed-off-by: George Cherian george.cher...@ti.com
 ---
  drivers/usb/host/xhci-pci.c | 1 -
  drivers/usb/host/xhci.c | 7 +++
  2 files changed, 7 insertions(+), 1 deletion(-)
 
 diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
 index cc24e39..f00cb20 100644
 --- a/drivers/usb/host/xhci-pci.c
 +++ b/drivers/usb/host/xhci-pci.c
 @@ -93,7 +93,6 @@ static void xhci_pci_quirks(struct device *dev, struct 
 xhci_hcd *xhci)
   }
   if (pdev-vendor == PCI_VENDOR_ID_INTEL 
   pdev-device == PCI_DEVICE_ID_INTEL_PANTHERPOINT_XHCI) {
 - xhci-quirks |= XHCI_SPURIOUS_SUCCESS;
   xhci-quirks |= XHCI_EP_LIMIT_QUIRK;
   xhci-limit_active_eps = 64;
   xhci-quirks |= XHCI_SW_BW_CHECKING;
 diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
 index d8f640b..0f7be59 100644
 --- a/drivers/usb/host/xhci.c
 +++ b/drivers/usb/host/xhci.c
 @@ -4697,6 +4697,13 @@ int xhci_gen_setup(struct usb_hcd *hcd, 
 xhci_get_quirks_t get_quirks)
  
   get_quirks(dev, xhci);
  
 + /* In xhci controllers which follow xhci 1.0 spec gives a spurious
 +  * success event after a short transfer. This quirk will ignore such
 +  * spurious event.
 +  */
 + if (xhci-hci_version  0x96)
 + xhci-quirks |= XHCI_SPURIOUS_SUCCESS;
 +
   /* Make sure the HC is halted. */
   retval = xhci_halt(xhci);
   if (retval)
 -- 
 1.8.1.4
 
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2] usb: host: xhci: Enable XHCI_SPURIOUS_SUCCESS for all controllers with xhci 1.0

2013-06-30 Thread George Cherian 
Xhci controllers with hci_version  0.96 gives spurious success
events on short packet completion. During webcam capture the
ERROR Transfer event TRB DMA ptr not part of current TD was observed.
The same application works fine with synopsis controllers hci_version 0.96.
The same Issue is seen with Intel Pantherpoint xhci controller. So enabling
this quirk in xhci_gen_setup if controller verion is greater than 0.96.
For xhci-pci move the quirk to much generic place xhci_gen_setup.

Signed-off-by: George Cherian george.cher...@ti.com
---
 drivers/usb/host/xhci-pci.c | 1 -
 drivers/usb/host/xhci.c | 7 +++
 2 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
index cc24e39..f00cb20 100644
--- a/drivers/usb/host/xhci-pci.c
+++ b/drivers/usb/host/xhci-pci.c
@@ -93,7 +93,6 @@ static void xhci_pci_quirks(struct device *dev, struct 
xhci_hcd *xhci)
}
if (pdev-vendor == PCI_VENDOR_ID_INTEL 
pdev-device == PCI_DEVICE_ID_INTEL_PANTHERPOINT_XHCI) {
-   xhci-quirks |= XHCI_SPURIOUS_SUCCESS;
xhci-quirks |= XHCI_EP_LIMIT_QUIRK;
xhci-limit_active_eps = 64;
xhci-quirks |= XHCI_SW_BW_CHECKING;
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index d8f640b..0f7be59 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -4697,6 +4697,13 @@ int xhci_gen_setup(struct usb_hcd *hcd, 
xhci_get_quirks_t get_quirks)
 
get_quirks(dev, xhci);
 
+   /* In xhci controllers which follow xhci 1.0 spec gives a spurious
+* success event after a short transfer. This quirk will ignore such
+* spurious event.
+*/
+   if (xhci-hci_version  0x96)
+   xhci-quirks |= XHCI_SPURIOUS_SUCCESS;
+
/* Make sure the HC is halted. */
retval = xhci_halt(xhci);
if (retval)
-- 
1.8.1.4

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