Pratyush Anand wrote: > On 7/1/2013 4:48 PM, Clemens Ladisch wrote: >>> There is no meaning of submitting an URB for expired time slot. >> >> Of course there is. The HCD cannot exactly know whether the current >> slot will expire before the URB is enqueued, so it is not always >> possible to label the slot as "expired" or not during submission. >> >> The meaning of an isochronous URB submission is "try to transmit this >> data in that frame"; whether the URB actually was transferred will be >> reported to the completion callback. > > Correct, I understand it. Let me explain with an example what I wanted > to convey: > > Lets assume that URB1-8 has been submitted to HCD driver from upper > layer. HCD driver has also further submitted them to the controller > hardware for execution in n to (n+7)th uf respectively. Now URB3 was > not able to be transmitted in time and resulted in missed isoc. This > failure will cause mainly because of two reasons: > 1. SW was slow enough in submission of URB to HW. It actually > submitted when timing was already expired. In this case, it is most > likely that following URBs (4-8) will also result in missed isoc. > So, if we add further URB9 for transmission in (n + 8) uf, most > likely it may also result in missed isoc. But there is _some_ uf that has not yet expired. If the HCD delays enqueuing URBs, it just increases the risk that that uf will expire too. > 2. SW submitted well in time, but HW was slow enough and could not > fetch data in time. In such situation, HW will flush current > descriptor and most likely will be able to transmit next URB > correctly. > > So, What I was proposing, to go for dynamic, something like this... > When an HCD gets an URB request for any isoc pipe, and if there is any > pending missed isoc flag then wait.. do not submit it to controller. > May be just keep them in received list(submitted_list). If during any > of the pending completion callback, SW observes success then submit > all from submitted_list to be scheduled in "very next uf" This is not possible with a very short pipeline where there is no other packet that could complete. And even if it is possible in some cases: why should submitted packets be delayed at all? The UAC driver wants all packets at their correct position in time (or else to be dropped), and the UVC driver does not want delays which could make it lose some data sent by the device. Regards, Clemens -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
