r3128 - branches/src/target/kernel/2.6.23.x/patches

[shoragan at sita.openmoko.org]

Author: shoragan
Date: 2007-10-09 17:22:07 +0200 (Tue, 09 Oct 2007)
New Revision: 3128

Added:
   branches/src/target/kernel/2.6.23.x/patches/s3c2410_udc-2440_dual_packet-workaround.patch
Modified:
   branches/src/target/kernel/2.6.23.x/patches/series
Log:
Follow changes in 2.6.22:
(orig r3117):  laforge | 2007-10-08 15:40:41 +0200

add dual packet workaround to series

(orig r3116):  laforge | 2007-10-08 15:40:11 +0200

add patch from werner to work around s3c2440 dual packet mode usb hangs

Added: branches/src/target/kernel/2.6.23.x/patches/s3c2410_udc-2440_dual_packet-workaround.patch
===================================================================
--- branches/src/target/kernel/2.6.23.x/patches/s3c2410_udc-2440_dual_packet-workaround.patch	2007-10-09 15:17:21 UTC (rev 3127)
+++ branches/src/target/kernel/2.6.23.x/patches/s3c2410_udc-2440_dual_packet-workaround.patch	2007-10-09 15:22:07 UTC (rev 3128)
@@ -0,0 +1,51 @@
+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.
+
+Index: linux-2.6.22.5-moko/drivers/usb/gadget/s3c2410_udc.c
+===================================================================
+--- linux-2.6.22.5-moko.orig/drivers/usb/gadget/s3c2410_udc.c
++++ linux-2.6.22.5-moko/drivers/usb/gadget/s3c2410_udc.c
+@@ -845,6 +845,7 @@
+ 	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 @@
+ 
+ 		if ((ep_csr1 & S3C2410_UDC_OCSR1_PKTRDY) && req) {
+ 			s3c2410_udc_read_fifo(ep,req);
++			if (s3c2410_udc_fifo_count_out())
++				goto handle_ep_again;
+ 		}
+ 	}
+ }

Modified: branches/src/target/kernel/2.6.23.x/patches/series
===================================================================
--- branches/src/target/kernel/2.6.23.x/patches/series	2007-10-09 15:17:21 UTC (rev 3127)
+++ branches/src/target/kernel/2.6.23.x/patches/series	2007-10-09 15:22:07 UTC (rev 3128)
@@ -9,6 +9,7 @@
 g_ether-vendor_product.patch
 s3c2410_serial-nodebug.patch
 #s3c2410_udc_from_upstream.p (merged upstream)
+s3c2410_udc-2440_dual_packet-workaround.patch
 s3c2410_touchscreen.patch
 s3c2410-bbt.patch
 s3c_mci.patch