On Tue, 6 Jul 2004, Michael Stilmant wrote:
> Hello all,
>
> Bellow the answer directly from genesys.
>
> I'm not an hard core USB device hacker, so can you tell me if this seem
> to be a good reasonable solution, or if this is a 'turn around' patch ?
> I've not tested yet,
>
> Best regards.
Well, this is an interesting result, straight from the horse's mouth as
it were... Let's hope the advice is actually correct!
It's encouraging that we've finally managed to get a response from the
vendor.
> -----Forwarded Message-----
> From: Jason Yu
> To: mstilmant
> Cc: Peter Wei, Aimee Hsu
> Subject: RE: GL811E and Linux
> Date: Tue, 06 Jul 2004 10:42:06 +0800
>
> Dear Sir:
> Please modify some file of linux and recompiler.
> It's relation linux kernel.
I'll skip the 2.4 version and concentrate on 2.6. If that works it can be
back-ported later.
> Linux Kernel 2.6.4
> inlcude/linux/blkdev.h
> change MAX_PHYS_SEGMENTS from 128 to 64
> change MAX_HW_SEGMENTS from 128 to 64
> change MAX_SEGMENT_SIZE from 65526 to 32768
> to solve 811 DMA can't over 64K issues
These changes aren't correct. As Matt Dharm has pointed out, they would
affect all devices in the system, and they are overkill anyway. The
device doesn't care (or even know!) how many scatter-gather segments there
are or how big each segment is. All it cares about is the total amount of
data being transferred, which is limited by max_sectors.
max_sectors is currently set at 128 (which means transferring no more than
64 KB per command). Jason's changes reduce the transfer length to 32 KB
(corresponding to max_sectors = 64), so that's what I'll do in the patch
below. He is probably being far too pessimistic; most likely 64 KB is
okay, and if it isn't then 60 KB almost certainly is. You can try
experimenting with the patch; take the part where I changed max_sectors to
64 and make it 120 instead (or even remove that part of the patch entirely
to leave it at 128).
> drivers/usb/storage/transport.c
> In function "usb_stor_Bulk_transport()"
> Add 100us delay time between scsi command and data stage
> to solve 811 two stages timing issues.
What do you know? A timing problem... And their web site and
documentation claim the chips are 100% standards-compatible.
Okay, the patch below adds this delay. You should try applying this
_without_ using that udelay() patch for usb.c that's been in circulation
for a couple of weeks now.
Good luck!
Alan Stern
===== drivers/usb/storage/scsiglue.c 1.78 vs edited =====
--- 1.78/drivers/usb/storage/scsiglue.c Thu Jun 24 10:09:11 2004
+++ edited/drivers/usb/storage/scsiglue.c Tue Jul 6 14:51:42 2004
@@ -94,15 +94,15 @@
/* Devices using Genesys Logic chips cause a lot of trouble for
* high-speed transfers; they die unpredictably when given more
- * than 64 KB of data at a time. If we detect such a device,
- * reduce the maximum transfer size to 64 KB = 128 sectors. */
+ * than 32 KB of data at a time. If we detect such a device,
+ * reduce the maximum transfer size to 32 KB = 64 sectors. */
#define USB_VENDOR_ID_GENESYS 0x05e3 // Needs a standard location
if (us->pusb_dev->descriptor.idVendor == USB_VENDOR_ID_GENESYS &&
us->pusb_dev->speed == USB_SPEED_HIGH &&
- sdev->request_queue->max_sectors > 128)
- blk_queue_max_sectors(sdev->request_queue, 128);
+ sdev->request_queue->max_sectors > 64)
+ blk_queue_max_sectors(sdev->request_queue, 64);
/* We can't put these settings in slave_alloc() because that gets
* called before the device type is known. Consequently these
===== drivers/usb/storage/transport.c 1.141 vs edited =====
--- 1.141/drivers/usb/storage/transport.c Thu Jun 24 12:44:16 2004
+++ edited/drivers/usb/storage/transport.c Tue Jul 6 14:52:21 2004
@@ -973,6 +973,9 @@
if (result != USB_STOR_XFER_GOOD)
return USB_STOR_TRANSPORT_ERROR;
+ /* Genesys Logic GL811 interfaces require a delay here */
+ udelay(100);
+
/* DATA STAGE */
/* send/receive data payload, if there is any */
if (transfer_length) {
-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
digital self defense, top technical experts, no vendor pitches,
unmatched networking opportunities. Visit www.blackhat.com
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
