usb_storage: USB storage transfer size increase for xHCI
PATCH 1/1 usb_storage: USB storage transfer size increase for xHCI
Increase xHCI transfer size for USB storage devices. This helps to achieve 10-20x speedup for large transfers
---
common/usb_storage.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
common/usb_storage.c +3 -1
@@ -97,13 +97,15 @@ struct us_data {trans_cmnd transport;/* transport routine */ }; -#ifdef CONFIG_USB_EHCI +#if defined(CONFIG_USB_EHCI )/* * The U-Boot EHCI driver can handle any transfer length as long as there is * enough free heap space left, but the SCSI READ(10) and WRITE(10) commands are * limited to 65535 blocks. */ #define USB_MAX_XFER_BLK 65535 +#elif defined(CONFIG_USB_XHCI ) +#define USB_MAX_XFER_BLK 4096#else #define USB_MAX_XFER_BLK 20#endif
Signature · 1 line
2.2.0
PATCH 1/1 usb_storage: USB storage transfer size increase for xHCI
Quoted 5 lines · Sergey Temerkhanov
Increase xHCI transfer size for USB storage devices. This helps to achieve 10-20x speedup for large transfers
Signed-off-by Sergey Temerkhanov <[email protected]>Signed-off-by Radha Mohan Chintakuntla <[email protected]>
Hi!
Quoted 18 lines
---
common/usb_storage.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)common/usb_storage.c +1
-1@@ -97,13 +97,15 @@ struct us_data {trans_cmnd transport;/* transport routine */ }; -#ifdef CONFIG_USB_EHCI +#if defined(CONFIG_USB_EHCI )/* * The U-Boot EHCI driver can handle any transfer length as long as there is * enough free heap space left, but the SCSI READ(10) and WRITE(10)
Quoted 4 lines
commands are * limited to 65535 blocks.
*/
#defineUSB_MAX_XFER_BLK65535
+#elifdefined(CONFIG_USB_XHCI)
Why don't you keep the XHCI consistent with EHCI, ie 64k transfers as well ?
Quoted 4 lines
+#define
USB_MAX_XFER_BLK4096
#else
#defineUSB_MAX_XFER_BLK20
#endif
Best regards,
Marek Vasut
PATCH 1/1 usb_storage: USB storage transfer size increase for xHCI
Tried different values but transfer sizes larger than ~8k blocks never complete on some controllers causing timeouts and crashes. So, 4k blocks is a safe enough xfer size
Regards,
Sergey
Quoted 44 lines · Marek Vasut
Quoted 5 lines · Sergey Temerkhanov
Increase xHCI transfer size for USB storage devices. This helps to achieve 10-20x speedup for large transfers
Signed-off-by Sergey Temerkhanov <[email protected]>Signed-off-by Radha Mohan Chintakuntla <[email protected]>Hi!
Quoted 10 lines
---
common/usb_storage.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)common/usb_storage.c +0
-0common/usb_storage.c struct us_data { · line 102
Quoted 7 lines
common/usb_storage.c +1
-1@@ -97,13 +97,15 @@ struct us_data {trans_cmnd transport;/* transport routine */ }; -#ifdef CONFIG_USB_EHCI +#if defined(CONFIG_USB_EHCI )/* * The U-Boot EHCI driver can handle any transfer length as long as there
Quoted 5 lines
common/usb_storage.c +0
-0is * enough free heap space left, but the SCSI READ(10) and WRITE(10)commands are * limited to 65535 blocks.
*/
#defineUSB_MAX_XFER_BLK65535
+#elifdefined(CONFIG_USB_XHCI)Why don't you keep the XHCI consistent with EHCI, ie 64k transfers as well ?
Quoted 4 lines
+#define
USB_MAX_XFER_BLK4096
#else
#defineUSB_MAX_XFER_BLK20
#endifBest regards,
Marek Vasut
PATCH 1/1 usb_storage: USB storage transfer size increase for xHCI
Quoted 3 lines · Sergei Temerkhanov
Tried different values but transfer sizes larger than ~8k blocks never complete on some controllers causing timeouts and crashes. So, 4k blocks is a safe enough xfer size
Would you please elaborate on this ?
Best regards,
Marek Vasut
A message that is not in the archive (sent off-list or not yet received): CAPEA6dY71DZhHb61c_+RfdvsM0PvzXRxY1nSw9zFPaqvTYzUgQ@mail.gmail.com
PATCH 1/1 usb_storage: USB storage transfer size increase for xHCI
On Thursday, August 13, 2015 at 10:56:27 PM, Sergei Temerkhanov wrote:
Hi!
(please stop top-posting ; please keep the list in the loop)
Quoted 5 lines
Well, when I was working on this, setting large transfer sizes resulted in, AFAIR,
xhci_wait_for_event()timeout and changingXHCI_TIMEOUTdoesn't help. This function returns NULL which is being dereferenced somewhere else (I don't remember where exactly), there are several places in the generic xhci support code where this is possible.
I suspect we might need a quirk for the XHCI instead them (quirk that the controller gets stuck when you try to queue arbitrary number of descriptors). But I wonder, don't you have some cache problems instead ? Try disabling dcache (CONFIG_SYS_DCACHE_OFF) on your machine and see if that fixes the problem .
Best regards,
Marek Vasut
PATCH 1/1 usb_storage: USB storage transfer size increase for xHCI
OK, I'll try to find some time for this. I remember trying it with DCACHE disabled but for no luck
Regards,
Sergey
Quoted 24 lines · Marek Vasut
On Thursday, August 13, 2015 at 10:56:27 PM, Sergei Temerkhanov wrote:
Hi!
(please stop top-posting ; please keep the list in the loop)
Quoted 1 line
Well, when I was working on this, setting large transfer sizes resulted
in,
Quoted 2 lines
AFAIR,
xhci_wait_for_event()timeout and changingXHCI_TIMEOUTdoesn't help. This function returns NULL which is being dereferenced somewhereelse
Quoted 2 lines
(I don't remember where exactly), there are several places in the generic xhci support code where this is possible.
I suspect we might need a quirk for the XHCI instead them (quirk that the controller gets stuck when you try to queue arbitrary number of descriptors).
But I wonder, don't you have some cache problems instead ? Try disabling dcache (CONFIG_SYS_DCACHE_OFF) on your machine and see if that fixes the problem .Best regards,
Marek Vasut
PATCH 1/1 usb_storage: USB storage transfer size increase for xHCI
Quoted 2 lines · Sergei Temerkhanov
OK, I'll try to find some time for this. I remember trying it with DCACHE disabled but for no luck
Cool, thanks. Btw please stop top-posting ;)
Quoted 31 lines
Regards,
SergeyQuoted 27 lines · Marek Vasut
On Thursday, August 13, 2015 at 10:56:27 PM, Sergei Temerkhanov wrote:
Hi!
(please stop top-posting ; please keep the list in the loop)
Quoted 1 line
Well, when I was working on this, setting large transfer sizes resulted
in,
Quoted 2 lines
AFAIR,
xhci_wait_for_event()timeout and changingXHCI_TIMEOUTdoesn't help. This function returns NULL which is being dereferenced somewhereelse
Quoted 2 lines
(I don't remember where exactly), there are several places in the generic xhci support code where this is possible.
I suspect we might need a quirk for the XHCI instead them (quirk that the controller gets stuck when you try to queue arbitrary number of descriptors).
But I wonder, don't you have some cache problems instead ? Try disabling dcache (CONFIG_SYS_DCACHE_OFF) on your machine and see if that fixes the problem .Best regards,
Marek Vasut
Best regards,
Marek Vasut
PATCH 1/1 usb_storage: USB storage transfer size increase for xHCI
In reply to Marek VasutWell, when I was working on this, setting large transfer sizes resulted in, AFAIR, xhci_wait_for_event() timeout and changing XHCI_TIMEOUT doesn't help. This function returns NULL which is being dereferenced somewhere else (I don't remember where exactly), there are several places in the generic xhci support code where this is possible - I think it was abort_td().
Regards,
Sergey
Quoted 11 lines · Marek Vasut
Quoted 2 lines · Sergei Temerkhanov
Tried different values but transfer sizes larger than ~8k blocks never complete on some controllers causing timeouts and crashes. So, 4k blocks
is
Quoted 1 line
a safe enough xfer size
Would you please elaborate on this ?
Best regards,
Marek Vasut
PATCH 1/1 usb_storage: USB storage transfer size increase for xHCI
On Friday, August 14, 2015 at 12:48:57 AM, Sergei Temerkhanov wrote:
Hi,
please stop top-posting :(
Quoted 5 lines
Well, when I was working on this, setting large transfer sizes resulted in, AFAIR,
xhci_wait_for_event()timeout and changingXHCI_TIMEOUTdoesn't help. This function returns NULL which is being dereferenced somewhere else (I don't remember where exactly), there are several places in the generic xhci support code where this is possible - I think it wasabort_td().
Can you please send fixes for those null-pointer dereferences you're triggering? Also, I suspect that if your controller cannot support arbitrary lenght of the descriptors, it might be a controller bug and a quirk should be introduced. Does the controller work in Linux ?
Quoted 17 lines
Regards,
SergeyQuoted 13 lines · Marek Vasut
Quoted 3 lines · Sergei Temerkhanov
Tried different values but transfer sizes larger than ~8k blocks never complete on some controllers causing timeouts and crashes. So, 4k blocks
is
Quoted 1 line
a safe enough xfer size
Would you please elaborate on this ?
Best regards,
Marek Vasut
Best regards,
Marek Vasut