Hi, On Mon, Jun 24, 2013 at 11:20:32PM +0800, Ming Lei wrote: > On Mon, Jun 24, 2013 at 11:04 PM, Felipe Balbi <balbi@xxxxxx> wrote: > > On Mon, Jun 24, 2013 at 10:56:30PM +0800, Ming Lei wrote: > >> On Mon, Jun 24, 2013 at 10:33 PM, Denis V. Lunev <den@xxxxxxxxxx> wrote: > >> > From: Konstantin Filatov <kfilatov@xxxxxxxxxxxxx> > >> > > >> > This patch shortens TD's packet not only for the last TD in sg list, > >> > but also for the last TD in sg element. > >> > > >> > Signed-off-by: Konstantin Filatov <kfilatov@xxxxxxxxxxxxx> > >> > Signed-off-by: Denis V. Lunev <den@xxxxxxxxxx> > >> > >> Considered that: > >> > >> - the change violates USB spec(1.1/2.0/3.0) > > > > I can't see how this would violate USB spec. USB specifications have no > > knowledge of scatter-gather. > > Per USB spec, short packet can only be the last packet of one transfer. > In our linux USB implementation, we think the sg list passed to URB or one > URB as one single transfer, so the middle short packet will cause the URB > to be understood as two or more transfers by device. no that will not happen. SG is only telling the internal DMA engine where, in memory, the data lies. The actual size is sum(each_sg().length) (as I described, 1044 bytes). which means that, in case of UHCI, DMA will read chunks of 64 bytes out of the areas pointed to by each SG and generate USB packets out of those. You don't send the SG over the USB wire, you use it just to tell the DMA where the data is, right ? That has nothing to do with USB at all. > >> - the problem should be avoided in usbcore since it isn't a uhci > >> specific problem > > > > to this I agree. > > > >> - this patch only hides problem, doesn't help to fix real problem. > > > > what is the problem then ? Are you saying that it's wrong to have an sg > > which is not aligned to wMaxPacketSize somewhere in the middle of an > > sg-table ? How so ? What does that have to do with USB at all ? > > The problem is that short packet can only be the last packet of one > transfer. an what is preventing it from being ? Your SG-table just described 1044 bytes of data scattered in three different locations in main memory, what your DMA HW will do is that it'll read 7x 64 bytes out of the first memory block, then it'll read the remaining 10 bytes and continue to read 54 more bytes out of the second block, and so on. In the end you'll have 16x 64bytes packet with a 20 bytes short in the end. -- balbi
Attachment:
signature.asc
Description: Digital signature
