diff options
Diffstat (limited to 'target/linux/s3c24xx/patches-2.6.26/1022-s3c2410_udc-2440_dual_packet-workaround.patch.patch')
| -rwxr-xr-x | target/linux/s3c24xx/patches-2.6.26/1022-s3c2410_udc-2440_dual_packet-workaround.patch.patch | 61 |
1 files changed, 0 insertions, 61 deletions
diff --git a/target/linux/s3c24xx/patches-2.6.26/1022-s3c2410_udc-2440_dual_packet-workaround.patch.patch b/target/linux/s3c24xx/patches-2.6.26/1022-s3c2410_udc-2440_dual_packet-workaround.patch.patch deleted file mode 100755 index 2ed8283e8..000000000 --- a/target/linux/s3c24xx/patches-2.6.26/1022-s3c2410_udc-2440_dual_packet-workaround.patch.patch +++ /dev/null @@ -1,61 +0,0 @@ -From 5207363cc9d50f99a2ad490eff5efa913b1c10ba Mon Sep 17 00:00:00 2001 -From: mokopatches <mokopatches@openmoko.org> -Date: Wed, 16 Jul 2008 14:44:50 +0100 -Subject: [PATCH] s3c2410_udc-2440_dual_packet-workaround.patch - This is a patch that seems to make the USB hangs on the S3C2440 go away. At - least a good amount of ping torture didn't make them come back so far. - -The issue is that, if there are several back-to-back packets, -sometimes no interrupt is generated for one of them. This -seems to be caused by the mysterious dual packet mode, which -the USB hardware enters automatically if the endpoint size is -half that of the FIFO. (On the 2440, this is the normal -situation for bulk data endpoints.) - -There is also a timing factor in this. I think what happens is -that the USB hardware automatically sends an acknowledgement -if there is only one packet in the FIFO (the FIFO has space -for two). If another packet arrives before the host has -retrieved and acknowledged the previous one, no interrupt is -generated for that second one. - -However, there may be an indication. There is one undocumented -bit (none of the 244x manuals document it), OUT_CRS1_REG[1], -that seems to be set suspiciously often when this condition -occurs. There is also CLR_DATA_TOGGLE, OUT_CRS1_REG[7], which -may have a function related to this. (The Samsung manual is -rather terse on that, as usual.) - -This needs to be examined further. For now, the patch seems to do the -trick. - -Note that this is not a clean solution by any means, because we -might potentially get stuck in that interrupt for quite a while. ---- - drivers/usb/gadget/s3c2410_udc.c | 3 +++ - 1 files changed, 3 insertions(+), 0 deletions(-) - -diff --git a/drivers/usb/gadget/s3c2410_udc.c b/drivers/usb/gadget/s3c2410_udc.c -index 6b1ef48..c1a4379 100644 ---- a/drivers/usb/gadget/s3c2410_udc.c -+++ b/drivers/usb/gadget/s3c2410_udc.c -@@ -845,6 +845,7 @@ static void s3c2410_udc_handle_ep(struct s3c2410_ep *ep) - u32 ep_csr1; - u32 idx; - -+handle_ep_again: - if (likely (!list_empty(&ep->queue))) - req = list_entry(ep->queue.next, - struct s3c2410_request, queue); -@@ -884,6 +885,8 @@ static void s3c2410_udc_handle_ep(struct s3c2410_ep *ep) - - if ((ep_csr1 & S3C2410_UDC_OCSR1_PKTRDY) && req) { - s3c2410_udc_read_fifo(ep,req); -+ if (s3c2410_udc_fifo_count_out()) -+ goto handle_ep_again; - } - } - } --- -1.5.6.3 - |