usb-related-issues.md

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