Re: [PATCH] [musb_hdrc]: fix bug - EOVERFLOW failure when do usb gadget zero test t14

On Mon, Jun 30, 2008 at 8:06 PM, Felipe Balbi <[email protected]> wrote:
> On Mon, Jun 30, 2008 at 08:03:31PM +0800, ext Bryan Wu wrote:
>> On Wed, Jun 25, 2008 at 7:35 PM, Felipe Balbi <[email protected]> wrote:
>> > On Wed, Jun 25, 2008 at 02:33:25PM +0800, ext Bryan Wu wrote:
>> >> >From f77853398c3c5f88ea7833ecb15546bf39023b00 Mon Sep 17 00:00:00 2001
>> >> From: Bryan Wu <[email protected]>
>> >> Date: Wed, 25 Jun 2008 14:29:33 +0800
>> >> Subject: [PATCH] [musb_hdrc]: fix bug - EOVERFLOW failure when do usb
>> >> gadget zero test t14
>> >>
>> >> https://blackfin.uclinux.org/gf/project/uclinux-dist/tracker/?action=TrackerItemEdit&tracker_id=141&tracker_item_id=4141
>> >>
>> >> Sometimes the last IN request will got error response which will
>> >> trigger EOVERFLOW error on USB host side.
>> >> We need to flush fifo after a whole trasfer.
>> >
>> > It looks fine.
>> >
>> > I'll test it a bit more and meld it on the patch going to mailine on
>> > next merge window ;-)
>> >
>>
>> Please hold for a while, our tester reported that the bug still could
>> be found on Blackfin. Even with this patch, the test will fail
>> randomly.
>> For example, run testcase t14 10 times, 1 or 2 tests failed.
>>
>> >From the data captured in Lecory USB analyzer, I think there are some
>> bug in the OTG module:
>> 1. PC Host send SETUP transfer to ep0 to tell gadget that Host will
>> write 151 bytes to gadget (for example)
>> 2. PC host send a series of OUT trasnfers for gadget, so gadget got
>> the 151 bytes from host
>> 3. PC host send IN pakcet for STATUS transfer, but gadget will report
>> a garbage data 1byte or 2bytes instead of ZERO byte.
>>
>> It seems that the bad response is automatically done by hardware. Do
>> you find similar things in Davinci/OMAP platform?
>
> I'm out of analyser here... Will get one still this week, I'll check it.
>
> Basically reproducable with t14 right ?
>

Yes, without the flush operation. It should always fail.
--
root@adam:/home/test# sudo ./src/testusb -D /proc/bus/usb/005/007 -t14
-c 15000 -s 256 -v 1
unknown speed   /proc/bus/usb/005/007
/proc/bus/usb/005/007 test 14 --> 75 (Value too large for defined data type)
--

Apply this patch, run 10 times of this t14, 1 or 2 times will fail.

I have a question about the driver:
When does the driver ask MUSB to send out the last IN packet of the
STATS tranfer?
I think it is automatically controlled by hardware, right? When we
write DATAEND to CSR0,
it waits for host IN token and reply a ZERO length packet to host, right?

Maybe it is a silicon bug.

Thanks a lot
-Bryan
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html