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

_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Reply via email to