On Wed, 20 Aug 2008, Dave Higton wrote: > > Since these are isoc URBs anyway, shouldn't you simply drop them until > > the new altsetting is ready? That's a lot easier than trying to keep > > track of them and deferring them (which doesn't make much sense for > > Isochronous data). > > If they were scheduled before an altsetting change, they must be plain > wrong for the new altsetting - and indeed the new altsetting could be > 0, in which case they wouldn't be sent anyway. So it seems to me that > they should be dropped. That's not a good description of the situation. The URBs were scheduled _after_ an altsetting change was requested but _before_ the change took place. Therefore the URBs are designed for the new altsetting and so are wrong for the altsetting in effect at the time of submission. (Indeed, the old altsetting might be 0, in which case submission would fail anyway.) So they should be dropped. > The only difference it makes, from the POV of the outside world, is an > ever so slight change in the time the stream is switched off. No. Since the submission or transmission of those URBs would have failed anyway (if they were submitted before the altsetting change occurred), they wouldn't get delivered in either case. The length of time the stream is off is the time required to switch altsettings -- and that simply is unavoidable. The other possibility suggested was to delay submitting the URBs until after the new altsetting was in place. That is a bad idea because it means delaying the delivery of isoc data, which makes no sense -- the whole idea of an isochronous stream is that the information should be delivered as quickly as possible and it doesn't much matter if some of it gets lost. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
