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

Stefan Herbrechtsmeier
2012-07-31T20:01:51Z

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