From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stefan Herbrechtsmeier Date: Fri, 20 Jul 2012 17:15:13 +0200 Subject: [U-Boot] [PATCH v2 2/5] ehci-hcd: Boost transfer speed In-Reply-To: <1346536947.339276.1342796616863.JavaMail.root@advansee.com> References: <1346536947.339276.1342796616863.JavaMail.root@advansee.com> Message-ID: <50097601.5000603@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 Am 20.07.2012 17:03, schrieb Beno?t Th?baudeau: > On Friday 20 July 2012 16:51:33 Stefan Herbrechtsmeier wrote: >> Am 20.07.2012 15:56, schrieb Beno?t Th?baudeau: >>> Dear Marek Vasut, >>> >>> On Friday 20 July 2012 15:44:01 Marek Vasut wrote: >>>>> On Friday 20 July 2012 13:37:37 Stefan Herbrechtsmeier wrote: >>>>>> Am 20.07.2012 13:26, schrieb Beno?t Th?baudeau: >>>>>>> + int xfr_bytes = min(left_length, >>>>>>> + (QT_BUFFER_CNT * 4096 - >>>>>>> + ((uint32_t)buf_ptr & 4095)) & >>>>>>> + ~4095); >>>>>> Why you align the length to 4096? >>>>> It's to guarantee that each transfer length is a multiple of the >>>>> max packet >>>>> length. Otherwise, early short packets are issued, which breaks >>>>> the >>>>> transfer and results in time-out error messages. >>>> Early short packets ? What do you mean? >>> During a USB transfer, all packets must have a length of max packet >>> length for >>> the pipe/endpoint, except the final one that can be a short packet. >>> Without the >>> alignment I make for xfr_bytes, short packets can occur within a >>> transfer, >>> because the hardware starts a new packet for each new queued qTD it >>> handles. >> But if I am right, the max packet length is 512 for bulk and 1024 for >> Interrupt transfer. > There are indeed different max packet lengths for different transfer types, but > it does not matter since the chosen alignment guarantees a multiple of all these > possible max packet lengths. But thereby you limit the transfer to 4 qT buffers for unaligned transfers. Best regards, Stefan