Re: FUSB200 xhci issue

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Am 07.09.2013 03:38, schrieb Alan Stern:
On Fri, 6 Sep 2013, Oleksij Rempel wrote:

Am 06.09.2013 23:09, schrieb Alan Stern:
On Fri, 6 Sep 2013, Oleksij Rempel wrote:

Hi Alan,

i need more help.

We have more test results now. Initial patch was probably fixing
fallowing issue - bad performance on EP4/EP3 if Intr transfer is used.
It is reproducible only on EHCI, but not reproducible on xHCI controller.

Is this a high-speed device?

yes

What version of the kernel are you using?

currently it is 3.11.0-rc7-wl-00004-g52e0063, but i can reproduce this
issue with older kernels too.

For example, channel scan function intensively use this endpoints. On
xHCI, channel scan is done in 6 seconds. On EHCI it needs 25s. By
forcing Bulk transfer on host side, it is possible get same performance
on EHCI too. But it isn't working on all controllers because of limited
packed size (64B).

Dumps are attached. One of them may include some other device, but only
ath9k_htc device has EP3 and EP4.

The capture logs show that with EHCI, each endpoint transfers a packet
every 2.5 ms or so, whereas xHCI transfers 2-3 packets per ms.

Is it protocol limitation or HC issue?

It's not a protocol limitation.  If it were, the xHCI communication
would be just as slow as EHCI.

One thing that might help: For each endpoint, keep multiple URBs queued
(try 10) at all times instead of just a single URB.

It's entirely possible that these results are caused by limitations of
your EHCI hardware.  Still, using multiple URBs could yield a
significant improvement.

Same issue on two different intel controllers. I'll try some thing
different for comparison.

Don't try different hardware.  Try submitting multiple URBs.

Suddenly i can't submit multiple urbs, we have lots of read->write operations. I need read result before i can write. Or do you mean some thing different. Beside, all EPs except EP4 are configured for multiple urbs.

Currently i was able to narrow down this problem. Only EP4 OUT is affected, it takes 2.5 msec to get ACK from it. Then i found one interesting register. It switch between packet and stream mode for OUT endpoints. Suddenly it will affect all EP* OUT. Enabling packet mode will solve this problem for EP4, but introduce some other DMA related problem on EP1... :( Do this modes are USB protocol related? I was not able to find some thing to read about it, or may be i just search for wrong words.

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




[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux