From aaf47f5e848026377c1473813abf436c0b8edf42 Mon Sep 17 00:00:00 2001 From: Oleksij Rempel Date: Tue, 15 Oct 2013 09:39:12 -0700 Subject: [PATCH] Created usb related issues (markdown) --- usb-related-issues.md | 128 ++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 128 insertions(+) create mode 100644 usb-related-issues.md diff --git a/usb-related-issues.md b/usb-related-issues.md new file mode 100644 index 0000000..3fcc818 --- /dev/null +++ b/usb-related-issues.md @@ -0,0 +1,128 @@ +# EP4 problem + +## Description of problem (copy of mail from ath9k-devel list) +> It looks like Atheros AR9271, AR7010 (ath9k_htc) and AR9170 (carl9170) +> have the same usb controller - FUSB200. They share same design and same +> problem. They have 3 OUT and 1 IN Bulk EPs for network traffic. 1 OUT +> and 1 IN Interrupt EP for WMI commands. +> +> Here is the layout: +> https://github.com/qca/open-ath9k-htc-firmware/wiki/usb-regs +> EP 1 OUT; Bulk; = LP (Low priority downstream); RX0; +> EP 2 IN; Bulk; = US (upstream) +> EP 3 IN; Interrupt; +> EP 4 OUT; Interrupt; +> EP 5 OUT; Bulk; = HP (High priority downstream); RX1; +> EP 6 OUT; Bulk; = MP (Medium priority downstream); RX2; +> +> the layout with FIFOs see in attachment. +> +> EPs 5 and 6 are not used by driver. They seems to be supported by +> hardware, but not handled by firmware. So, not important for now. +> +> EPs 1, 2, 5, 6 are handled by DMA with some previous buffering. +> +> === And here is the problem === +> +> EPs 3, 4 accessed directly. For some reasons, response time on this EPs +> on USB 2.0 is 2-4 ms. Same hardware on USB 3.0 has less delay - 0.2 ms. +> +> === Test 1. Using Bulk instead of Int === +> +> Previously ath9k_htc driver had workaround, by forcing Bulk traffic on +> EP3 and 4. (Actually, only EP4 is interesting for this issue) But it is +> not working with all hardware correctly. For example, on USB 3.0, the +> changes well be applied only after device reset. Before device reset, +> even if ath9k_htc driver was sending Bulk, usb driver converted it back +> to Interrupt. After reset, usb driver started sending bulk and was not +> able to work with too small FIFO size on FUSB200. EP4 is mapped to +> 64byte FIFO, but we need 512 byte for bulk transfer. +> +> According to product brief, FUSB200 can be flexible reconfigurable. +> Theoretically we should be able to map EP4 to 512 byte FIFO. I tried it, +> but no interrupt was generated. (some thing is wrong, i do not know +> what) According to product brief, if FUSB200 connected with DMA module, +> the FIFOs will be handled by DMA. It looks like FIFOs 0-13 can't be +> accessed same way like we do it with FIFO14 and 15 (EP3 and EP4). So it +> looks like we can't fix it correctly - by remaping interrupt EPs to +> bigger FIFOs and define it as Bulk. If there are some DMA mask +> registers, please tell me. +> +> === Test 2. Using other EPs (5, 6 or 1) === +> +> The DMA engine, which is connected with this EPs, has build in priority +> system. For example EP1 will need more packets or time until DMA will be +> triggered. EPs 5 and 6 need less time to react. Maybe we can use this +> EPs as better workaround. But right now, i do not know how to enable DMA +> at the beginning. After firmware upload, only EP3 and EP4 are working. +> Which use no DMA. I was not able to find on which stage and how DMA was +> enabled. +> I also have doubt. DMA buffer will probably add too big delay. +> Espesially on reg read. So, maybe this option wan't work too. +> +> === Other workarounds === +> +> Since we can't fix or untill we will be able to fix usb issue, we need +> to optimise IO operations. Small packets will waste usb bandwidth. For +> example, typical write or read IO is 8byte. We need at least 64 bytes to +> normally utilise USB bus. +> +> Here are changes which will increase performance: +> 1. do buffered write. - this is was already done before me. +> 2. TODO: read arrays. - currently driver will do one read per time. +> 3. TODO: optimised and buffered RMW operations. +> +> ath9k use intensively RMW, so it good field for optimisation. RMW is +> needed to change some bit of register. So we do read + chage + write. +> By mowing this command to Firmware, we will be able to do buffered RMW +> and dramatically reduce usb bus traffic. +> +> Here are links to my kernel and firmware branches with described +> optimisation: +> https://github.com/olerem/open-ath9k-htc-firmware/commits/speed +> https://github.com/olerem/linux-2.6/commits/wifi-perf2 +> +> With this patches i reduced scan time on ar9271 from 25 to ~15 seconds! + + +## Feedback from Faraday devs +> However it looks to me that it's almost identical to the one +> integrated in FOTG210 (OTG), which +> has been released to U-Boot open source, and the Linux driver is also +> available at my github: +> +> [FOTG210 driver for U-boot](http://git.denx.de/?p=u-boot.git;a=blob_plain;f=drivers/usb/gadget/fotg210.c;hb=99b4eaa68e0e2fdd9b0d0b1d40809d7e8f92044f) +> +> [FOTG210 driver for Linux](https://github.com/dantesu1218/linux-kernel/blob/linux-3.2.21/drivers/usb/gadget/fotg210_udc.c) +> +> Please check its fifo configuration routines, it looks to me that +> you're encounter issues caused by bad fifo configuration. +> +> Note: +> +> 1. FOTG210_UDC V.S. FUSB200: +> +> FOTG210 has only 4 fifos, each of it supports upto 512 bytes. +> FUSB200 has 16 fifos, 0~ 13 support up-to 512 bytes; 14,15 support +> only up-to 64 bytes. +> +> 2. Faraday USB device controller general design issues: +> +> 1) DO NOT use ISOC!!! It's buggy, you won't want to mess with it. +> 2) DO NOT use shared fifo unless you're 100% for sure that there +> is 1 and only 1 data transfer +> at a time. (i.e. Mass storage). +> In other words, the shared fifo is known to be malfunctioned with RNDIS. + +and + +>> Is it possible that some FIFOs hard-wired to dma? I can read and write +>> FIFOs 14 and 15 directly without dma, by reading or writing some +>> register. And i also get interrupt if there is some data. But if i map +>> EP4 to FIFO13 instead of FIFO15, then i get no interrupt (I assume +>> FIFO13 and FIFO15 belong to same interrupt group). USB dump shows that +>> data on EP4 was accepted. +>> +> +> Since FIFO14 & FIFO15 supports only upto 64bytes, while others FIFO0 ~ FIFO13 +> support 512 bytes. So yes, it's possible that FIFO14 & FIFO15 are dedicated for interrupt EPs. \ No newline at end of file -- 2.25.1