Re: [PATCH 7/9] xhci: remove XHCI_TRUST_TX_LENGTH quirk and handle it as default

2015-05-29 Thread Rodrigo Severo 
On Fri, May 29, 2015 at 11:01 AM, Mathias Nyman
mathias.ny...@linux.intel.com wrote:
 Now including Renesas uPD720201 we got four xhci vendors that return
 Success instead of short transfer when there are still unstraferred bytes
 left. The driver anyway checks the untransferred bytes and suggest adding
 the quirk if needed, so we can as well make it default behavior and get
 rid of the quirk all together.

 Cc: Rodrigo Severo rodr...@fabricadeideias.com
 Signed-off-by: Mathias Nyman mathias.ny...@linux.intel.com
 ---
  drivers/usb/host/xhci-pci.c  |  3 ---
  drivers/usb/host/xhci-ring.c | 22 ++
  drivers/usb/host/xhci.h  |  2 --
  3 files changed, 10 insertions(+), 17 deletions(-)

 diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
 index 4a4cb1d..3ebf182 100644
 --- a/drivers/usb/host/xhci-pci.c
 +++ b/drivers/usb/host/xhci-pci.c
 @@ -103,7 +103,6 @@ static void xhci_pci_quirks(struct device *dev, struct 
 xhci_hcd *xhci)
 QUIRK: Fresco Logic revision %u 
 has broken MSI implementation,
 pdev-revision);
 -   xhci-quirks |= XHCI_TRUST_TX_LENGTH;
 }

 if (pdev-vendor == PCI_VENDOR_ID_NEC)
 @@ -117,7 +116,6 @@ static void xhci_pci_quirks(struct device *dev, struct 
 xhci_hcd *xhci)
 xhci-quirks |= XHCI_AMD_PLL_FIX;

 if (pdev-vendor == PCI_VENDOR_ID_AMD)
 -   xhci-quirks |= XHCI_TRUST_TX_LENGTH;

You should remove the whole if statement here, not only the
XHCI_TRUST_TX_LENGTH setting.


Rodrigo
--
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: Video transfer hangs with cx231xx deivce on ASM1042A USB 3.0 Host Controller

2015-05-20 Thread Rodrigo Severo 
On Tue, May 5, 2015 at 8:27 AM, Mathias Nyman
mathias.ny...@linux.intel.com wrote:
 On 23.04.2015 17:38, Rodrigo Severo wrote:
 On Mon, Apr 13, 2015 at 10:15 AM, Mathias Nyman
 mathias.ny...@linux.intel.com wrote:
 Hi

 On 08.04.2015 20:45, Rodrigo Severo wrote:

 At that time I even tested enabling XHCI_TRUST_TX_LENGTH quirk for the
 ASM1042A USB 3.0 Host Controller which eliminated the warnings on my
 logs but didn't solve the hang issues.

 Can you add xhci debugging and post the output before the hang.

 Enable xhci debugging with:
 echo -n 'module xhci_hcd =p'  /sys/kernel/debug/dynamic_debug/control

 Im not sure my first message with the log uncompressed. Now I'm
 sending it with the log compressed.

 I hope this is better.

 Hi

 Last patchseries I sent includes fixes for similar issues.

 The ERROR Transfer event TRB DMA ptr not part of current TD where we try to
 find a one old TRB should be fixed by:

 http://marc.info/?l=linux-usbm=143040326306659w=2

 In your example case it was the TRB at 0x..9250  which we start searching for
 from 0x..9260 to, well, the same 0x..9260

I have several servers with 5 cx231xx A/V recording devices working
without problems.

Today I included 2 Renesas USB boards to try 7 cx231xx A/V recording
devices on the same server.

It worked for around 10 min and them I got the following warnings:

May 20 14:57:39 video3-df kernel: [ 1004.311844] xhci_hcd
:04:00.0: WARN Set TR Deq Ptr cmd failed due to incorrect slot or
ep state.
May 20 14:58:27 video3-df kernel: [ 1052.429235] xhci_hcd
:06:00.0: WARN Set TR Deq Ptr cmd failed due to incorrect slot or
ep state.
May 20 14:59:16 video3-df kernel: [ 1101.123178] xhci_hcd
:08:00.0: WARN Set TR Deq Ptr cmd failed due to incorrect slot or
ep state.
May 20 15:00:36 video3-df kernel: [ 1180.558526] xhci_hcd
:02:00.0: WARN Set TR Deq Ptr cmd failed due to incorrect slot or
ep state.

Four minutes later my logs where flooded with the following errors:
May 20 15:04:05 video3-df kernel: [ 1390.185470] xhci_hcd
:02:00.0: ERROR Transfer event TRB DMA ptr not part of current TD
ep_index 8 comp_code 1
May 20 15:04:05 video3-df kernel: [ 1390.185523] xhci_hcd
:02:00.0: Looking for event-dma 039ec060 trb-start
039ec040 trb-end 039ec040 seg-start 039ec000
seg-end 039ecff0

and all recording devices became unstable.

From lspci we can see that the device that started to throw lots of
errors was a Renesas uPD720201:

02:00.0 USB controller: Renesas Technology Corp. uPD720201 USB 3.0
Host Controller (rev 03)
04:00.0 USB controller: ASMedia Technology Inc. ASM1042A USB 3.0 Host Controller
06:00.0 USB controller: ASMedia Technology Inc. ASM1042A USB 3.0 Host Controller
08:00.0 USB controller: Renesas Technology Corp. uPD720202 USB 3.0
Host Controller (rev 02)

Is there any kind of limit on how many xhci hosts I can have in the
same machine?


Regards,

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

XHCI: ASMedia 1042 generating warnings when recording video

2015-05-14 Thread Rodrigo Severo 
Hi,


The xhci driver is generating the following warnings when recording
A/V with a cx231xx USB 2.0 dongle connect to an ASMedia 1042 host:

xhci_hcd :03:00.0: WARN Set TR Deq Ptr cmd failed due to incorrect
slot or ep state.

These warnings occurs sporadically and doesn't seem to affect the
actual A/V recording.

I wonder if it's worth an effort to fix this.

Please take notice that now I'm talking about an ASMedia 1042 host,
not to be confused with a ASMedia 1042A host. Recently a bug that
affected ASMedia 1042A hosts was solved by a patch from Mathias Nyman.
That issue is properly solved AFAICT. This issue affects only 1042
hosts, not 1042A.

If there is any extra info necessary, please let me know.


Regards,

Rodrigo Severo
--
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: Video transfer hangs with cx231xx deivce on ASM1042A USB 3.0 Host Controller

2015-04-23 Thread Rodrigo Severo 
On Mon, Apr 13, 2015 at 10:15 AM, Mathias Nyman
mathias.ny...@linux.intel.com wrote:
 Hi

 On 08.04.2015 20:45, Rodrigo Severo wrote:

 At that time I even tested enabling XHCI_TRUST_TX_LENGTH quirk for the
 ASM1042A USB 3.0 Host Controller which eliminated the warnings on my
 logs but didn't solve the hang issues.

 Can you add xhci debugging and post the output before the hang.

 Enable xhci debugging with:
 echo -n 'module xhci_hcd =p'  /sys/kernel/debug/dynamic_debug/control

Im not sure my first message with the log uncompressed. Now I'm
sending it with the log compressed.

I hope this is better.


Regards,

Rodrigo


xhci-hang.log.gz
Description: GNU Zip compressed data

Re: Video transfer hangs with cx231xx deivce on ASM1042A USB 3.0 Host Controller

2015-04-23 Thread Rodrigo Severo 
On Mon, Apr 13, 2015 at 10:15 AM, Mathias Nyman
mathias.ny...@linux.intel.com wrote:
 Hi

 On 08.04.2015 20:45, Rodrigo Severo wrote:

 When connecting cx231xx video grab devices (which are USB 2.0
 themselves) on ASMedia ASM1042A USB 3.0 Host Controllers the video
 capture process hangs after a few minutes. Besides hanging my log is
 flowed with the following warning:

 Does this only happend with the ASMedia ASM1042A xHCI controller?
 Can you reproduce it with a xHCI controller from another vendor?

I've just tested with another 3.0 xhci host, an PCI-e board Renesas
Technology Corp. uPD720202 USB 3.0 Host Controller, with ID 1912:0015.

When I started capturing video with the video grabber connected to
this xhci host the messages where like the ones I received with the
ASMedia 1042A. Lots of:

xhci_hcd :06:00.0: WARN Successful completion on short TX: needs
XHCI_TRUST_TX_LENGTH quirk?

But when the video grab hanged it presented the message below once:

Apr 23 10:54:31 video-teste kernel: [  158.931156] xhci_hcd
:06:00.0: ERROR Transfer event TRB DMA ptr not part of current TD
ep_index 8 comp_code 1

And them flooded my log with the messages below at a rate of tens per second:

Apr 23 10:54:31 video-teste kernel: [  158.931252] xhci_hcd
:06:00.0: Looking for event-dma b9af9250 trb-start
b9af9260 trb-end b9af9260 seg-start b9af9000
seg-end b9af93f0
Apr 23 10:54:31 video-teste kernel: [  158.936148] xhci_hcd
:06:00.0: ERROR Transfer event TRB DMA ptr not part of current TD
ep_index 8 comp_code 1

Do you need xhci debugging from this board also?


Regards,

Rodrigo Severo
--
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: Video transfer hangs with cx231xx deivce on ASM1042A USB 3.0 Host Controller

2015-04-15 Thread Rodrigo Severo 
On Mon, Apr 13, 2015 at 10:15 AM, Mathias Nyman
mathias.ny...@linux.intel.com wrote:

 Does this only happend with the ASMedia ASM1042A xHCI controller?
 Can you reproduce it with a xHCI controller from another vendor?


I'm not sure. I will try when I came back home next week (travelling).


 Can you add xhci debugging and post the output before the hang.

 Enable xhci debugging with:
 echo -n 'module xhci_hcd =p'  /sys/kernel/debug/dynamic_debug/control

Will do it.


Regards,

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

Video transfer hangs with cx231xx deivce on ASM1042A USB 3.0 Host Controller

2015-04-08 Thread Rodrigo Severo 
Hi,


When connecting cx231xx video grab devices (which are USB 2.0
themselves) on ASMedia ASM1042A USB 3.0 Host Controllers the video
capture process hangs after a few minutes. Besides hanging my log is
flowed with the following warning:

xhci_hcd :05:00.0: WARN Successful completion on short TX: needs
XHCI_TRUST_TX_LENGTH quirk?

I believe it's important to notice that the same capture device on the
same motherboard but on a different USB host (the USB controller:
Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 USB EHCI
Controller) runs smoothly for months (I'm using it to record real time
video continuously).

I tested this several months ago with the same results but didn't have
the time to pursue a final proper fix.

At that time I even tested enabling XHCI_TRUST_TX_LENGTH quirk for the
ASM1042A USB 3.0 Host Controller which eliminated the warnings on my
logs but didn't solve the hang issues.

Now that I have the time I retested with the latest kernel and
unfortunately the problem still exists.

Here is the output of scripts/ver_linux:

If some fields are empty or look unusual you may have an old version.
Compare to the current minimal requirements in Documentation/Changes.

Linux video-teste 4.0.0-04rc7-generic #201504061936 SMP Mon Apr 6
23:37:35 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

Gnu C  scripts/ver_linux:
Gnu make   4.0
scripts/ver_linux: 20: scripts/ver_linux: ld: not found
binutils
util-linux 2.25.1
mount  debug
module-init-tools  18
e2fsprogs  1.42.10
jfsutils   1.1.15
PPP2.4.5
Linux C Library2.19
Dynamic linker (ldd)   2.19
Procps 3.3.9
Net-tools  1.60
Kbd1.15.5
Sh-utils   8.23
wireless-tools 30
Modules Loaded btrfs xor raid6_pq ufs qnx4 hfsplus hfs minix
ntfs msdos jfs xfs libcrc32c cx231xx_alsa cx25840 cx231xx
videobuf_vmalloc tveeprom cx2341x rc_core videobuf_core i2c_mux
v4l2_common videodev media amdkfd amd_iommu_v2 nfsd kvm_amd
auth_rpcgss nfs_acl nfs kvm radeon lockd crct10dif_pclmul crc32_pclmul
ghash_clmulni_intel aesni_intel snd_hda_codec_hdmi snd_hda_intel
snd_hda_controller grace sunrpc snd_hda_codec snd_hwdep snd_pcm
fscache snd_timer snd soundcore aes_x86_64 lrw ttm drm_kms_helper drm
eeepc_wmi asus_wmi gf128mul glue_helper ablk_helper k10temp
sparse_keymap fam15h_power video i2c_algo_bit mxm_wmi edac_core cryptd
nls_iso8859_1 shpchp joydev serio_raw i2c_piix4 edac_mce_amd wmi
tpm_infineon 8250_fintek mac_hid hid_generic usbhid hid psmouse ahci
r8169 libahci mii

I don't have a USB sniffer but I might be able to buy one it's it
proofs necessary.

Please let me know if there is any extra info that might help further
diagnose this issue.


Regards,

Rodrigo Severo

-- 
Rodrigo Severo | DIRETOR DE TECNOLOGIA
Tel. +55 61 3030-1515
Siga a Fábrica no twitter:@empautaclipping

fabricadeideias.com
12 ANOS DE TECNOLOGIA E COMUNICAÇÃO
NUMA COMBINAÇÃO PERFEITA

Bus 007 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Device Descriptor:
  bLength18
  bDescriptorType 1
  bcdUSB   2.00
  bDeviceClass9 Hub
  bDeviceSubClass 0 Unused
  bDeviceProtocol 0 Full speed (or root) hub
  bMaxPacketSize064
  idVendor   0x1d6b Linux Foundation
  idProduct  0x0002 2.0 root hub
  bcdDevice4.00
  iManufacturer   3 Linux 4.0.0-04rc7-generic ehci_hcd
  iProduct2 EHCI Host Controller
  iSerial 1 :00:16.2
  bNumConfigurations  1
  Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength   25
bNumInterfaces  1
bConfigurationValue 1
iConfiguration  0 
bmAttributes 0xe0
  Self Powered
  Remote Wakeup
MaxPower0mA
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber0
  bAlternateSetting   0
  bNumEndpoints   1
  bInterfaceClass 9 Hub
  bInterfaceSubClass  0 Unused
  bInterfaceProtocol  0 Full speed (or root) hub
  iInterface  0 
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81  EP 1 IN
bmAttributes3
  Transfer TypeInterrupt
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0004  1x 4 bytes
bInterval  12
Hub Descriptor:
  bLength   9
  bDescriptorType  41
  nNbrPorts 4
  wHubCharacteristic 0x000a
No power switching (usb 1.0)
Per-port overcurrent protection
  bPwrOn2PwrGood   10 * 2 milli seconds
  bHubContrCurrent  0 milli Ampere
  DeviceRemovable0x00

Re: Video transfer hangs with cx231xx deivce on ASM1042A USB 3.0 Host Controller

2015-04-08 Thread Rodrigo Severo 
On Wed, Apr 8, 2015 at 2:45 PM, Rodrigo Severo
rodr...@fabricadeideias.com wrote:

 Please let me know if there is any extra info that might help further
 diagnose this issue.

Please disregard the lsusb log on my previous email as I just saw that
it lacks lots of info from the cx231xx video grab device. I believe
this is another result of the hanging I'm experiencing.

After disconnecting and reconnecting the video grab device lsusb
provides all expected info.


Regards,

Rodrigo

-- 
Rodrigo Severo | DIRETOR DE TECNOLOGIA
Tel. +55 61 3030-1515
Siga a Fábrica no twitter:@empautaclipping

fabricadeideias.com
12 ANOS DE TECNOLOGIA E COMUNICAÇÃO
NUMA COMBINAÇÃO PERFEITA

Bus 007 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Device Descriptor:
  bLength18
  bDescriptorType 1
  bcdUSB   2.00
  bDeviceClass9 Hub
  bDeviceSubClass 0 Unused
  bDeviceProtocol 0 Full speed (or root) hub
  bMaxPacketSize064
  idVendor   0x1d6b Linux Foundation
  idProduct  0x0002 2.0 root hub
  bcdDevice4.00
  iManufacturer   3 Linux 4.0.0-04rc7-generic ehci_hcd
  iProduct2 EHCI Host Controller
  iSerial 1 :00:16.2
  bNumConfigurations  1
  Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength   25
bNumInterfaces  1
bConfigurationValue 1
iConfiguration  0 
bmAttributes 0xe0
  Self Powered
  Remote Wakeup
MaxPower0mA
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber0
  bAlternateSetting   0
  bNumEndpoints   1
  bInterfaceClass 9 Hub
  bInterfaceSubClass  0 Unused
  bInterfaceProtocol  0 Full speed (or root) hub
  iInterface  0 
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81  EP 1 IN
bmAttributes3
  Transfer TypeInterrupt
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0004  1x 4 bytes
bInterval  12
Hub Descriptor:
  bLength   9
  bDescriptorType  41
  nNbrPorts 4
  wHubCharacteristic 0x000a
No power switching (usb 1.0)
Per-port overcurrent protection
  bPwrOn2PwrGood   10 * 2 milli seconds
  bHubContrCurrent  0 milli Ampere
  DeviceRemovable0x00
  PortPwrCtrlMask0xff
 Hub Port Status:
   Port 1: .0100 power
   Port 2: .0100 power
   Port 3: .0100 power
   Port 4: .0100 power
Device Status: 0x0001
  Self Powered

Bus 011 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Device Descriptor:
  bLength18
  bDescriptorType 1
  bcdUSB   1.10
  bDeviceClass9 Hub
  bDeviceSubClass 0 Unused
  bDeviceProtocol 0 Full speed (or root) hub
  bMaxPacketSize064
  idVendor   0x1d6b Linux Foundation
  idProduct  0x0001 1.1 root hub
  bcdDevice4.00
  iManufacturer   3 Linux 4.0.0-04rc7-generic ohci_hcd
  iProduct2 OHCI PCI host controller
  iSerial 1 :00:16.0
  bNumConfigurations  1
  Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength   25
bNumInterfaces  1
bConfigurationValue 1
iConfiguration  0 
bmAttributes 0xe0
  Self Powered
  Remote Wakeup
MaxPower0mA
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber0
  bAlternateSetting   0
  bNumEndpoints   1
  bInterfaceClass 9 Hub
  bInterfaceSubClass  0 Unused
  bInterfaceProtocol  0 Full speed (or root) hub
  iInterface  0 
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81  EP 1 IN
bmAttributes3
  Transfer TypeInterrupt
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0002  1x 2 bytes
bInterval 255
Hub Descriptor:
  bLength   9
  bDescriptorType  41
  nNbrPorts 4
  wHubCharacteristic 0x0012
No power switching (usb 1.0)
No overcurrent protection
  bPwrOn2PwrGood2 * 2 milli seconds
  bHubContrCurrent  0 milli Ampere
  DeviceRemovable0x00
  PortPwrCtrlMask0xff
 Hub Port Status:
   Port 1: .0100 power
   Port 2: .0100 power
   Port 3: .0100 power
   Port 4: .0100 power
Device Status: 0x0001
  Self Powered

Bus 010 Device 001: ID 1d6b:0001

Fwd: Instability when using USB Video Grabber with several xHCI hubs. There is one eHCI hub where it is stable

2014-08-26 Thread Rodrigo Severo 
Hi,


I have been trying to set several USB Video Grabbers on a few
machines. The Video Grabbers are Oner Touch Video Capture dongles
from Diammond Multimedia, a Connexant device with device ID 1f4d:0102.

On an old machine with Advanced Micro Devices, Inc. [AMD/ATI]
SB7x0/SB8x0/SB9x0 USB EHCI Controller I have three Video Grabbers,
one on each USB hub, working flawlessly.

My problem is that I can't find a new machine where these devices are
also stable. I'm compiling a list of USB hubs where they aren't
stable. In all of them, I get tons of TX lenght quirk messages like
xhci_hcd :01:00.0: WARN Successful completion on short TX: needs
XHCI_TRUST_TX_LENGTH quirk?. Activating the TX quirk workaround for
these SUB hubs prevents the messages from being logged but
unfortunatelly the video grabbers keep being randomly disconnected
when recording.

I have already seem this same behaviour with the following xHCI hubs:

* Renesas uPD720201 - ID 0x1912:0x0014
* Renesas uPD720202 - ID 0x1912:0x0015
* AsMedia ASM1042A - ID 0x1b21:0x1142

Can someone help me further diagnose thi issue? I'm kind of lost right now.


Regards,

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

Fwd: [PATCH] Including XHCI_TRUST_TX_LENGTH for Renesas uPD720202 USB 3.0 chip.

2014-08-25 Thread Rodrigo Severo 
On Mon, Aug 25, 2014 at 3:17 PM, Greg KH gre...@linuxfoundation.org wrote:

 On Fri, Aug 22, 2014 at 12:33:10PM -0300, Rodrigo Severo wrote:
  Renesas uPD720202 USB 3.0 chip needs XHCI_TRUST_TX_LENGTH quirk workaround 
  as per below logs
  produced when using a Diammond video capture dongle:
 
  Aug 21 18:07:33 [kernel] handle_tx_event: 67 callbacks suppressed
  Aug 21 18:07:33 [kernel] xhci_hcd :01:00.0: WARN Successful completion 
  on short TX: needs XHCI_TRUST_TX_LENGTH quirk?
  - Last output repeated 9 times -
 
  While at it I took the opportunity to define Renesas uPD720202 device ID.
 
  Signed-off-by: Rodrigo Severo rodr...@fabricadeideias.com
  ---
   drivers/usb/host/xhci-pci.c | 12 
   1 file changed, 8 insertions(+), 4 deletions(-)
 
  diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
  index 47390e3..52df456 100644
  --- a/drivers/usb/host/xhci-pci.c
  +++ b/drivers/usb/host/xhci-pci.c
  @@ -38,6 +38,8 @@
   #define PCI_DEVICE_ID_INTEL_LYNXPOINT_XHCI   0x8c31
   #define PCI_DEVICE_ID_INTEL_LYNXPOINT_LP_XHCI0x9c31
 
  +#define PCI_DEVICE_ID_RENESAS_UPD720202 0x0015

 Minor nit, can you use a tab to line up the value properly?

Will do. If I just apply a single tab I can't see much aliging
happening. Should I apply more tabs?


 Also, please use scripts/get_maintainer.pl to send the patch to the
 proper person, I don't know if the xhci maintainer saw this patch :(

That would be a nice reason for the long silence. Will do it. I didn't
know about scripts/get_maintainer.pl

Thanks for the heads up.


  +
   static const char hcd_name[] = xhci_hcd;
 
   /* called after powerup, by probe or system-pm wakeup */
  @@ -143,10 +145,12 @@ static void xhci_pci_quirks(struct device *dev, 
  struct xhci_hcd *xhci)
xhci-quirks |= XHCI_TRUST_TX_LENGTH;
}
if (pdev-vendor == PCI_VENDOR_ID_RENESAS 
  - pdev-device == 0x0015 
  - pdev-subsystem_vendor == PCI_VENDOR_ID_SAMSUNG 
  - pdev-subsystem_device == 0xc0cd)
  - xhci-quirks |= XHCI_RESET_ON_RESUME;
  + pdev-device == PCI_DEVICE_ID_RENESAS_UPD720202) {
  + xhci-quirks |= XHCI_TRUST_TX_LENGTH;

 You just added this quirk to devices that previously didn't seem to need
 it, why?

Because I got the WARN Successful completion on short TX: needs
XHCI_TRUST_TX_LENGTH quirk? kernel message when using a Video Grabber
connected to a Renesas USB PCI-e board.

As far as I could understand from my research that's the proper way to
deal with this situation. Or is there a better course of action?


  + if (pdev-subsystem_vendor == PCI_VENDOR_ID_SAMSUNG 
  + pdev-subsystem_device == 0xc0cd)
  + xhci-quirks |= XHCI_RESET_ON_RESUME;

 Can't we just get a table of quirks instead of logic functions to make
 this easier to add new ones?

Such a change might be just out of my reach but I can try to do it if
you could point me to some other code that uses a table as you
suggest.

By the way, which git repository should I use as base for my work? I'm
currently using
https://kernel.googlesource.com/pub/scm/linux/kernel/git/mnyman/xhci/

Is this the right one?


Rodrigo
--
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] Including XHCI_TRUST_TX_LENGTH for Renesas uPD720202 USB 3.0 chip.

2014-08-22 Thread Rodrigo Severo 
Renesas uPD720202 USB 3.0 chip needs XHCI_TRUST_TX_LENGTH quirk workaround as 
per below logs
produced when using a Diammond video capture dongle:

Aug 21 18:07:33 [kernel] handle_tx_event: 67 callbacks suppressed
Aug 21 18:07:33 [kernel] xhci_hcd :01:00.0: WARN Successful completion on 
short TX: needs XHCI_TRUST_TX_LENGTH quirk?
- Last output repeated 9 times -

While at it I took the opportunity to define Renesas uPD720202 device ID.

Signed-off-by: Rodrigo Severo rodr...@fabricadeideias.com
---
 drivers/usb/host/xhci-pci.c | 12 
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
index 47390e3..52df456 100644
--- a/drivers/usb/host/xhci-pci.c
+++ b/drivers/usb/host/xhci-pci.c
@@ -38,6 +38,8 @@
 #define PCI_DEVICE_ID_INTEL_LYNXPOINT_XHCI 0x8c31
 #define PCI_DEVICE_ID_INTEL_LYNXPOINT_LP_XHCI  0x9c31
 
+#define PCI_DEVICE_ID_RENESAS_UPD720202 0x0015
+
 static const char hcd_name[] = xhci_hcd;
 
 /* called after powerup, by probe or system-pm wakeup */
@@ -143,10 +145,12 @@ static void xhci_pci_quirks(struct device *dev, struct 
xhci_hcd *xhci)
xhci-quirks |= XHCI_TRUST_TX_LENGTH;
}
if (pdev-vendor == PCI_VENDOR_ID_RENESAS 
-   pdev-device == 0x0015 
-   pdev-subsystem_vendor == PCI_VENDOR_ID_SAMSUNG 
-   pdev-subsystem_device == 0xc0cd)
-   xhci-quirks |= XHCI_RESET_ON_RESUME;
+   pdev-device == PCI_DEVICE_ID_RENESAS_UPD720202) {
+   xhci-quirks |= XHCI_TRUST_TX_LENGTH;
+   if (pdev-subsystem_vendor == PCI_VENDOR_ID_SAMSUNG 
+   pdev-subsystem_device == 0xc0cd)
+   xhci-quirks |= XHCI_RESET_ON_RESUME;
+   }
if (pdev-vendor == PCI_VENDOR_ID_VIA)
xhci-quirks |= XHCI_RESET_ON_RESUME;
 }
-- 
1.8.5.5

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