ath9k-htc on OHCI -> bogus usb xfer
fixed-term.Oleksij.Rempel
fixed-term.Oleksij.Rempel at de.bosch.com
Wed Jul 6 02:09:12 PDT 2016
On 06.07.2016 10:45, Alexey Brodkin wrote:
> Hi Oleksij,
>
> On Wed, 2016-07-06 at 10:38 +0200, fixed-term.Oleksij.Rempel wrote:
>>
>> On 06.07.2016 10:32, Alexey Brodkin wrote:
>>>
>>> Hi Oleksij,
>>>
>>> On Wed, 2016-07-06 at 10:24 +0200, fixed-term.Oleksij.Rempel wrote:
>>>>
>>>>
>>>> Hm... this Endpoint should be Interrupt, not Bulk. If you search for
>>>> lsusb of this kind of adapter all of them list EP3 and EP4 as Interrupt.
>>>>
>>>> what did went wrong here? Is it not working in USB High Speed mode?
>>> Unfortunately as of now on that board EHCI doesn't work.
>>>
>>> That's not a problem of a particular USB device but something in either
>>> ECHI host controller or its integration. I do hope we will fix it sometime soon
>>> (this is a development board and USB controller is implemented in FPGA so
>>> there's a chance to fix stuff later on).
>>>
>>> So given only OHCI works on the board I went forward and attempted to use it
>>> with Wi-Fi USB dongle.
>>
>> I did some tests for 2 years on OHCI controller on x86. There was no
>> noticable issues. It was even a bit faster then Intels EHCI. I don't
>> think OHCI alone is the source of this problem.
>
> Well I was also surprised how well that dongle works with that board in
> OHCI mode. I saw quite consistent ~4-5 Mbit/second rates when doing Speedtest
> from my smartphone. So IMHO it's completely usable. Especially on that kind of
> HW which has main CPU running at just 100MHz.
>
>> On other side, so far i know, this adapter claims to provide usb full
>> speed support, (Not only high speed) and may use different usb
>> descriptor for this. May be this is the problem.
>
> So is there something we may do with all that?
Sure...
This shows that EP4 is Bluk in full speed mode. And it is defined by a
boot loader of this chip:
grep -R USB_FS_EP4_ATTRIBUTE *
sboot/magpie_1_1/sboot/hif/usb/src/usb_table.c:
m2BYTE(USB_FS_EP4_ATTRIBUTE, USB_FS_EP4_MAX_PACKET_SIZE),
sboot/magpie_1_1/sboot/hif/usb/src/usb_table.h:#define
USB_FS_EP4_ATTRIBUTE bUSB_EP_TYPE_BULK
sboot/magpie_1_1/inc/usb_table.h:#define USB_FS_EP4_ATTRIBUTE
bUSB_EP_TYPE_BULK
target_firmware/magpie_fw_dev/target/inc/k2/usb_table.h:#define
USB_FS_EP4_ATTRIBUTE bUSB_EP_TYPE_BULK
target_firmware/magpie_fw_dev/target/inc/magpie/usb_table.h:#define
USB_FS_EP4_ATTRIBUTE bUSB_EP_TYPE_BULK
So, there are fallowing variants to fix it:
a) patch full speed usb descriptor in firmware and add usb reinit
support to the driver.
b) add support of different EP4 types.
In any case, some one need to implement it... right now i have time only
for mentoring.
It is hard to say, which solution is better. It will affect performance
and stability. We will need lots of testing on different HW variants to
know it.
May be usb maeling list can give some input here?
Currently we have fallowing issues:
- if EP4 and EP3 are Interrupt, it works slower on High Speed controller.
- if EP4 and EP3 are Bulk, the work better on High Speed and brake on
Super Speed controllers. This adapter support my 64B packets and if we
have more, fifo of this adapter will overrun.
- Full Speed is currently unknown field for me, and it looks like it was
never actually working properly.
More information about the linux-snps-arc
mailing list