USB controller driver question

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

 



Hi all,

I am debugging an issue for a USB device (usb wifi dongle from TP-LINK which is using Ralink chipset). I am using it on an embedded board running Linux 2.6.30 on ARM architecture. The board has USB controller from synopsys, and they've provided the driver for the same. The controller has the feature to switch between USB speeds (i.e. 1.0 and 2.0). When I configure the USB controller in USB 1.0 speed, my USB device (i.e. usb wifi dongle) works perfectly fine. But when the USB controller is configured for USB 2.0, the device stops working after some time when doing large data transfer at high speed. Its not crashing the Linux, but the system becomes non-responsive. I could capture the USB packets (using analyzer) between controller and device and found that there was continuous PING - NAK token exchanges were happening. I could re-confirm this scenario by putting some debug prints in controller driver. From this observation, I assumed that it may happen that device is not able to release the buffers and because of that its sending NAK to each incoming PING request. When I reduced the number of PINGs sent out by USB controller driver, the device was working fine. Currently I am skipping every alternate PING token from controller driver.

I want to understand that what should be the ideal frequency to send PING tokens. Should it be very aggressive? I searched through the code of ehci driver in linux kernel, but could not figure out where the exactly PING protocol is implemented in that. Can you please point out the part of source code, so that I can look into it and see how it is implemented ?

Thanks,
Vishal

--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx
Please read the FAQ at http://kernelnewbies.org/FAQ


[Index of Archives]     [Newbies FAQ]     [Linux Kernel Mentors]     [Linux Kernel Development]     [IETF Annouce]     [Git]     [Networking]     [Security]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux SCSI]     [Linux ACPI]
  Powered by Linux