[U-Boot] [PATCH v2 2/5] ehci-hcd: Boost transfer speed

[Stefan Herbrechtsmeier <stefan@herbrechtsmeier.net>]

Dear Beno?t

Am 29.07.2012 02:48, schrieb Beno?t Th?baudeau:
> Sorry for the delay. I'm very busy, and there is much to tell on this topic.
No problem. Hopefully I don't make you to much extra trouble.

>>> BTW, the 15x speed gain that I gave in my patch description was
>>> compared to an
>>> older version of the original code that used 20 blocks per transfer
>>> in
>>> usb_storage.c. This is now 40 blocks per transfer with a
>>> page-aligned buffer, so
>>> the speed gain compared to the current code should be rather about
>>> 7x. I should
>>> update that.
>> I'm sure that there is a significant speed gain but you shouldn't
>> miss
>> the heap usage as the main CONFIG_SYS_MALLOC_LEN is 128kB.
> I have checked all the config files. Among those using EHCI, most have a heap
> size >= 1 MiB. The only exceptions are:
>
> ---------------------------------------------
> | Heap Size |      Board       |  RAM Size  |
> |-------------------------------------------|
> |   512 kiB | MERGERBOX        |   > 10 MiB |
> |           | MPC8315ERDB      |    128 MiB |
> |           | MVBLM7           |    512 MiB |
> |-------------------------------------------|
> |   256 kiB | MPC8349ITX       |    256 MiB |
> |           | omap4_panda      |      1 GiB |
> |-------------------------------------------|
> |   128 kiB | adp-ag102        |    256 MiB |
> |           | at91sam9m10g45ek |    128 MiB |
> |           | edminiv2         |     64 MiB |
> |           | M52277EVB        |     64 MiB |
> |           | omap3_beagle     | >= 128 MiB |
> ---------------------------------------------
>
> As you can see, these small heap sizes are not linked to any hardware
> constraint, but only to the lack of need to have larger heaps, so they could be
> easily enlarged if needed. But even 128 kiB should be enough for common usage.
You are right.
>
>> Maybe you should also add a worst case heap usage and I'm not sure,
>> if
>> your calculation are right, as the size of struct qTD is allays 32B
>> and
>> thereby I get 50kB or 64kB.
> >From ehci.h:
> struct qTD {
> 	/* this part defined by EHCI spec */
> 	uint32_t qt_next;		/* see EHCI 3.5.1 */
> #define	QT_NEXT_TERMINATE	1
> 	uint32_t qt_altnext;		/* see EHCI 3.5.2 */
> 	uint32_t qt_token;		/* see EHCI 3.5.3 */
> 	uint32_t qt_buffer[5];		/* see EHCI 3.5.4 */
> 	uint32_t qt_buffer_hi[5];	/* Appendix B */
> 	/* pad struct for 32 byte alignment */
> 	uint32_t unused[3];
> };
>
> So sizeof(struct qTD) is 16 * 32 bits = 64 bytes. For the worst alignment case,
> the number of qTDs to allocate for 65535 blocks of 512 bytes (worst MSC case
> with 512-byte sectors) is DIV_ROUND_UP(65535 * 512, 4 * 4096) = 2048 qTDs, i.e.
> 128 kiB. For the same transfer size with the best alignment case, it is
> DIV_ROUND_UP(65535 * 512, 5 * 4096) = 1639 qTDs, i.e. 104896 B.
Sorry, you are right. I had missed the arrays.

Regards,
     Stefan