From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stefan Herbrechtsmeier Date: Tue, 31 Jul 2012 22:01:51 +0200 Subject: [U-Boot] [PATCH v2 2/5] ehci-hcd: Boost transfer speed In-Reply-To: <635841778.759390.1343522898919.JavaMail.root@advansee.com> References: <635841778.759390.1343522898919.JavaMail.root@advansee.com> Message-ID: <501839AF.60208@herbrechtsmeier.net> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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