change prefix for kernelpatchbase 2.6.26

git-svn-id: svn://svn.openwrt.org/openwrt/trunk@13619 3c298f89-4303-0410-b956-a3cf2f4a3e73

1 files changed, 61 insertions, 0 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
new file mode 100755
index 0000000000..2ed8283e8c
--- /dev/null
+++ b/target/linux/s3c24xx/patches-2.6.26/1022-s3c2410_udc-2440_dual_packet-workaround.patch.patch
@@ -0,0 +1,61 @@
+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
+