usb-related-issues.md

   1 **Note**: we are working in our free time to fix the bugs and extend this driver. Most changes go to new kernel and firmware versions. Please, be kind and make sure you use latest code before sending us bug reports.
   2
   3 # Unstable USB connection (ath9k_htc: USB layer deinitialized)
   4 For example:
   5
   6 `[ 2081.341801] usb 3-1: USB disconnect, device number 89`
   7
   8 `[ 2083.284344] ath: phy455: Failed to wakeup in 500us`
   9
  10 We get some bug reports about unstable connections and different weird issues. Before reporting a bug, please check:
  11 * is it working with other (shorter?) cable? This HW seems to be picky about cable quality, so check it.
  12 * is it working with powered USB hub? People had issues with some specific usb controllers. Test on other HW if possible, or at least find some cheap powered usb hub.
  13 * is it working with LED disabled? LEDs are triggered from host over USB. Looks like some host controllers don't like it. Use this command:
  14
  15 `sudo bash -c "echo none > /sys/class/leds/ath9k_htc-phy*/trigger"`
  16
  17 # BOGUS urb xfer, pipe 1 != type 3
  18 If you get this error, then you need to update firmware (at least version 1.4) and kernel (at least v3.18). If you still get this issue, ask or check if your kernel really has this patch [ath9k_htc: do not use bulk on EP3 and EP4](https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/net/wireless/ath/ath9k/hif_usb.c?id=2b721118b7821107757eb1d37af4b60e877b27e7).
  19
  20 ... Or, your USB host controller forced this adapter to start in USB 1.1 Full Speed mode. Which is not tested or supported yet.
  21
  22 # USB Suspend (Firmware issue)
  23 Currently usb suspend is not working, instead of suspend firmware will reboot. If we are lucky,
  24 firmware will set device to lo power mode and reboot on resume.
  25
  26 # USB reset (Firmware issue)
  27 Currently usb reset is not correctly working with some usb host controllers.
  28 In some cases it will have absolutely no issue. For example with most xHCI controllers.
  29 On EHCI we can be rebooted:
  30 * Firmware should do some thing if we get reset interrupt. This will solve reset issue for most EHCI controllers
  31 * Some EHCI controllers will send suspend signal after reset (Hardware bug?). In this case we should ignore suspend interrupt or find correct way to respond on reset, if FUSB200 support it.
  32
  33 # EP4 problem
  34
  35 ## Description of problem (copy of mail from ath9k-devel list)
  36 > It looks like Atheros AR9271, AR7010 (ath9k_htc) and AR9170 (carl9170)
  37 > have the same usb controller - FUSB200. They share same design and same
  38 > problem. They have 3 OUT and 1 IN Bulk EPs for network traffic. 1 OUT
  39 > and 1 IN Interrupt EP for WMI commands.
  40 >
  41 > Here is the layout:
  42 > https://github.com/qca/open-ath9k-htc-firmware/wiki/usb-regs
  43 > EP 1 OUT; Bulk; = LP (Low priority downstream); RX0;
  44 > EP 2 IN; Bulk; = US (upstream)
  45 > EP 3 IN; Interrupt;
  46 > EP 4 OUT; Interrupt;
  47 > EP 5 OUT; Bulk; = HP (High priority downstream); RX1;
  48 > EP 6 OUT; Bulk; = MP (Medium priority downstream); RX2;
  49 >
  50 > the layout with FIFOs see in attachment.
  51 >
  52 > EPs 5 and 6 are not used by driver. They seems to be supported by
  53 > hardware, but not handled by firmware. So, not important for now.
  54 >
  55 > EPs 1, 2, 5, 6 are handled by DMA with some previous buffering.
  56 >
  57 > === And here is the problem ===
  58 >
  59 > EPs 3, 4 accessed directly. For some reasons, response time on this EPs
  60 > on USB 2.0 is 2-4 ms. Same hardware on USB 3.0 has less delay - 0.2 ms.
  61 >
  62 > === Test 1. Using Bulk instead of Int ===
  63 >
  64 > Previously ath9k_htc driver had workaround, by forcing Bulk traffic on
  65 > EP3 and 4. (Actually, only EP4 is interesting for this issue) But it is
  66 > not working with all hardware correctly. For example, on USB 3.0, the
  67 > changes well be applied only after device reset. Before device reset,
  68 > even if ath9k_htc driver was sending Bulk, usb driver converted it back
  69 > to Interrupt. After reset, usb driver started sending bulk and was not
  70 > able to work with too small FIFO size on FUSB200. EP4 is mapped to
  71 > 64byte FIFO, but we need 512 byte for bulk transfer.
  72 >
  73 > According to product brief, FUSB200 can be flexible reconfigurable.
  74 > Theoretically we should be able to map EP4 to 512 byte FIFO. I tried it,
  75 > but no interrupt was generated. (some thing is wrong, i do not know
  76 > what) According to product brief, if FUSB200 connected with DMA module,
  77 > the FIFOs will be handled by DMA. It looks like FIFOs 0-13 can't be
  78 > accessed same way like we do it with FIFO14 and 15 (EP3 and EP4). So it
  79 > looks like we can't fix it correctly - by remaping interrupt EPs to
  80 > bigger FIFOs and define it as Bulk. If there are some DMA mask
  81 > registers, please tell me.
  82 >
  83 > === Test 2. Using other EPs (5, 6 or 1) ===
  84 >
  85 > The DMA engine, which is connected with this EPs, has build in priority
  86 > system. For example EP1 will need more packets or time until DMA will be
  87 > triggered. EPs 5 and 6 need less time to react. Maybe we can use this
  88 > EPs as better workaround. But right now, i do not know how to enable DMA
  89 > at the beginning. After firmware upload, only EP3 and EP4 are working.
  90 > Which use no DMA. I was not able to find on which stage and how DMA was
  91 > enabled.
  92 > I also have doubt. DMA buffer will probably add too big delay.
  93 > Espesially on reg read. So, maybe this option wan't work too.
  94 >
  95 > === Other workarounds ===
  96 >
  97 > Since we can't fix or untill we will be able to fix usb issue, we need
  98 > to optimise IO operations. Small packets will waste usb bandwidth. For
  99 > example, typical write or read IO is 8byte. We need at least 64 bytes to
 100 > normally utilise USB bus.
 101 >
 102 > Here are changes which will increase performance:
 103 > 1. do buffered write. - this is was already done before me.
 104 > 2. TODO: read arrays. - currently driver will do one read per time.
 105 > 3. TODO: optimised and buffered RMW operations.
 106 >
 107 > ath9k use intensively RMW, so it good field for optimisation. RMW is
 108 > needed to change some bit of register. So we do read + chage + write.
 109 > By mowing this command to Firmware, we will be able to do buffered RMW
 110 > and dramatically reduce usb bus traffic.
 111 >
 112 > Here are links to my kernel and firmware branches with described
 113 > optimisation:
 114 > https://github.com/olerem/open-ath9k-htc-firmware/commits/speed
 115 > https://github.com/olerem/linux-2.6/commits/wifi-perf2
 116 >
 117 > With this patches i reduced scan time on ar9271 from 25 to ~15 seconds!
 118
 119
 120 ## Feedback from Faraday devs
 121 > However it looks to me that it's almost identical to the one
 122 > integrated in FOTG210 (OTG), which
 123 > has been released to U-Boot open source, and the Linux driver is also
 124 > available at my github:
 125 >
 126 > [FOTG210 driver for U-boot](http://git.denx.de/?p=u-boot.git;a=blob_plain;f=drivers/usb/gadget/fotg210.c;hb=99b4eaa68e0e2fdd9b0d0b1d40809d7e8f92044f)
 127 >
 128 > [FOTG210 driver for Linux](https://github.com/dantesu1218/linux-kernel/blob/linux-3.2.21/drivers/usb/gadget/fotg210_udc.c)
 129 >
 130 > Please check its fifo configuration routines, it looks to me that
 131 > you're encounter issues caused by bad fifo configuration.
 132 >
 133 > Note:
 134 >
 135 > 1. FOTG210_UDC  V.S. FUSB200:
 136 >
 137 >    FOTG210 has only 4 fifos, each of it supports upto 512 bytes.
 138 >    FUSB200 has 16 fifos, 0~ 13 support up-to 512 bytes; 14,15 support
 139 > only up-to 64 bytes.
 140 >
 141 > 2. Faraday USB device controller general design issues:
 142 >
 143 >    1) DO NOT use ISOC!!! It's buggy, you won't want to mess with it.
 144 >    2) DO NOT use shared fifo unless you're 100% for sure that there
 145 > is 1 and only 1 data transfer
 146 >        at a time. (i.e. Mass storage).
 147 >        In other words, the shared fifo is known to be malfunctioned with RNDIS.
 148
 149 and
 150
 151 >> Is it possible that some FIFOs hard-wired to dma? I can read and write
 152 >> FIFOs 14 and 15 directly without dma, by reading or writing some
 153 >> register. And i also get interrupt if there is some data. But if i map
 154 >> EP4 to FIFO13 instead of FIFO15, then i get no interrupt (I assume
 155 >> FIFO13 and FIFO15 belong to same interrupt group). USB dump shows that
 156 >> data on EP4 was accepted.
 157 >>
 158 >
 159 > Since FIFO14 & FIFO15 supports only upto 64bytes, while others FIFO0 ~ FIFO13
 160 > support 512 bytes. So yes, it's possible that FIFO14 & FIFO15 are dedicated for interrupt EPs.