Alan Stern wrote:
> On Tue, 19 Aug 2008, Marcel Holtmann wrote:
>
> > Our problem is only that we are using a workqueue and can't make any
> > assumption when we get scheduled. This is obviously not
> perfect, but it
> > seems there is nothing much that can be done.
> >
> > I think the specification is simply bad and we have to live with it.
>
> I guess so.
>
> 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.
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.
Dave
*************************************************************************************************************************************************************************************************************************************************
NICE CTI Systems UK Limited ("NICE") is registered in England under company number, 3403044. The registered office of NICE is at Tollbar Way, Hedge End, Southampton, Hampshire SO30 2ZP.
Confidentiality: This communication and any attachments are intended for the above-named persons only and may be confidential and/or legally privileged. Any opinions expressed in this communication are not necessarily those of NICE. If this communication has come to you in error you must take no action based on it, nor must you copy or show it to anyone; please delete/destroy and inform the sender by e-mail immediately.
Monitoring: NICE may monitor incoming and outgoing e-mails.
Viruses: Although we have taken steps toward ensuring that this e-mail and attachments are free from any virus, we advise that in keeping with good computing practice the recipient should ensure they are actually virus free.
****************************************************************************************************************************************************************************************************************************************************
--
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
