Hi Marek, Here's a patch.
-Jim On Mon, Jul 30, 2012 at 7:41 PM, Marek Vasut <marek.va...@gmail.com> wrote: > Dear Jim Shimer, > > > Marek, > > > > I don't have a USB 1.x device to do that regression. Taking the call to > > usb_test_unit_ready out of the block reads/writes and leaving it only in > > get info really speed up ext2load. With the recent cache changes on top > of > > this and the 5ms delay, we're getting fairly close to the Linux USB > > transfer times and are happy with the results. Can you look into > > integrating this? > > Can you send a patch that'll yank it out? I should be able to test it in a > bit. > > > -Jim > > > > On Mon, Jul 30, 2012 at 6:54 PM, Marek Vasut <ma...@denx.de> wrote: > > > Dear Jim Shimer, > > > > > > > While tuning ext2load, we found that usb_test_unit_ready was being > > > > called every block read. We compared the usb block storage to the > > > > scsi block storage cmd_scsi.c, and found that the scsi device was > only > > > > calling its scsi_setup_test_unit_ready() during scsi_can. It appears > > > > that usb_test_unit_ready() really only needs to be called once during > > > > usb_stor_scan(), via usb_stor_get_info(). Is there a particular > > > > reason usb_test_unit_ready is called for every block read, or do you > > > > think its > > > > > > ok > > > > > > > to only call during usb_stor_scan()? We're finding this speeds up > > > > > > ext2load > > > > > > > quite a bit. > > > > > > Could it be because the USB is actually quite slower than SCSI and the > > > device > > > might get congested? It seems the code was there ever since (I can't > seem > > > to > > > find the origin of it) and we might actually want to try if this > doesn't > > > break > > > some usb 1.x things. > > > > > > > Regards, > > > > Jim > > > > > > Best regards, > > > Marek Vasut > > Best regards, > Marek Vasut > -- *James H Shimer* Motorola Mobility T3-12-HH72 900 Chelmsford Street Lowell MA 08151 978-614-3550
0001-Optimize-USB-load-ext2load-by-removing-uneeded-test-.patch
Description: Binary data
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
