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

[Felipe Balbi]

From f77853398c3c5f88ea7833ecb15546bf39023b00 Mon Sep 17 00:00:00 2001

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 ;-)

[Bryan Wu]

Post by Felipe Balbi

From f77853398c3c5f88ea7833ecb15546bf39023b00 Mon Sep 17 00:00:00 2001

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.

Post by Felipe Balbi
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?

Thanks
-Bryan
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-***@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Felipe Balbi]

Post by Bryan Wu

Post by Felipe Balbi

From f77853398c3c5f88ea7833ecb15546bf39023b00 Mon Sep 17 00:00:00 2001

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.

Post by Felipe Balbi
From the data captured in Lecory USB analyzer, I think there are some

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 ?

this anyways, sounds quite weird.

[Bryan Wu]

Post by Felipe Balbi

Post by Bryan Wu

Post by Felipe Balbi

From f77853398c3c5f88ea7833ecb15546bf39023b00 Mon Sep 17 00:00:00 2001

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.

Post by Felipe Balbi
From the data captured in Lecory USB analyzer, I think there are some

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.
--
***@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 majordomo-***@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Felipe Balbi]

Post by Bryan Wu
Yes, without the flush operation. It should always fail.
--
-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)
--

Cool, as soon as I get a analyzer, i'll also look at it.

Post by Bryan Wu
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?

As soon as I remember, yeah. Done by hw.

There was a known issue when the CSR was 0x77ff (if I'm not wrong, will
look my mails and search for the right flakey csr), but we tested on
omap3 and it didn't seem to be affected.

Maybe blackfin is affected?

Post by Bryan Wu
Maybe it is a silicon bug.

Might be, there are so many of them :-p

[Bryan Wu]

Post by Felipe Balbi

Post by Bryan Wu
Yes, without the flush operation. It should always fail.
--
-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)
--

Cool, as soon as I get a analyzer, i'll also look at it.

Post by Bryan Wu
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?

As soon as I remember, yeah. Done by hw.
There was a known issue when the CSR was 0x77ff (if I'm not wrong, will
look my mails and search for the right flakey csr), but we tested on
omap3 and it didn't seem to be affected.

Oh, is there any URL for this known issue?
So happy to know we are in the same MAD USB (musb), -:))))

-Bryan
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-***@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Felipe Balbi]

Post by Bryan Wu
Oh, is there any URL for this known issue?
So happy to know we are in the same MAD USB (musb), -:))))

Unfortunately no, we found out during internal developement of usb
(Nokia).

I'll try to find the exact file that was the easiest way to reproduce
the problem, but that's tomorrow's task :-p
--
Best Regards,

Felipe Balbi
me-uiRdBs8odbtmTBlB0Cgj/***@public.gmane.org
http://blog.felipebalbi.com
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-***@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[David Brownell]

Post by Bryan Wu
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?

When I did the DaVinci work (creating the 2.6 version of this
driver, matching then-current kernel interfaces and fixing a
lot of the bugs in Mentor's code), there were plenty of odd
behaviors and gremlins ... but I don't recall any with quite
that symptom.

- Dave

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