> From: Sebastian Andrzej Siewior [mailto:bigeasy@xxxxxxxxxxxxx] > Sent: Wednesday, October 19, 2011 9:21 AM > > On 09/29/2011 01:02 PM, Felipe Balbi wrote: > > > diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c > > index c9b011a..8270671 100644 > > --- a/drivers/usb/dwc3/gadget.c > > +++ b/drivers/usb/dwc3/gadget.c <snip> > > @@ -633,6 +640,9 @@ static struct dwc3_request *dwc3_prepare_trbs(struct dwc3_ep *dep, > > trb.lst = last_one; > > } > > > > + if (usb_endpoint_xfer_bulk(dep->desc)&& dep->stream_capable) > > + trb.sid_sofn = req->request.stream_id; > > Hmmm. The XferNotReady event tells us which stream we are waiting for. > I think we have to take this into account here. > So if the gadget queues a req for stream 3 and host asks for stream 5 no > transfer is going on because we start a transfer for stream 3 which the > host is not interested in, right?. Even worse, because once stream 5 is > queued by the gadget it sits there and waits until stream 3 is > finished. So everything stalls until the host asks for a packet from > stream 3. > Or am I wrong here? If we start a transfer for stream 3 instead of 5 is > the host informed that he received a data for another stream and takes > it anyway? Hi Sebastian, The device will only start a transfer for a stream that the host has submitted a request for on the command pipe, so presumably the host will not refuse a stream that it has requested. And which stream to transfer will normally be selected by the device, using ERDY(Stream, NumP). So I think this should be OK. I guess only time will tell, though. -- Paul ��.n��������+%������w��{.n�����{���)�� jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
