Re: [rfc]btusb with SCO support

Oliver Neukum
2008-08-18T14:27:25Z

Am Montag 18 August 2008 16:10:20 schrieb Marcel Holtmann:

> run powertop and you will see why we can't do that. Also there is no max
> altsetting. It doesn't work like this. You have to pick the right one.
>
> The Bluetooth USB spec. is messed up when it comes to SCO.

Very well, it can't be helped then.

> > > On the other hand, this is audio and I don't really care if we loose a
> > > packet or not.
> >
> > It isn't limited to sound. The URBs for acl reception can also be delayed
> > arbitrarily long.
>
> We can move that into the notify() callback, but the killing the URBs
> becomes a problem.

/**
* usb_unlink_anchored_urbs - asynchronously cancel transfer requests en masse
* @anchor: anchor the requests are bound to
*
* this allows all outstanding URBs to be unlinked starting
* from the back of the queue. This function is asynchronous.
* The unlinking is just tiggered. It may happen after this
* function has returned.
*/
void usb_unlink_anchored_urbs(struct usb_anchor *anchor)

> On the other hand, ACL shouldn't be any problem since there is a HCI
> connection setup in between and the ACL part of Bluetooth is reliable
> and we have flow control on it.
>
> Also these are bulk URBs. I am under the assumption that the Bluetooth
> controller will queue packets up until we submit the first URB.
>
> > > > Secondly, what happens when this next event comes so quickly that
> > > > the work is still scheduled or running? it seems to me that the work handler
> > > > can read stale conn_hash values.
> > >
> > > I don't see that happening since Bluetooth connection setup is
> > > serialized and we only have to make sure that bulk and isoc URBs are
> > > running when the connection is up.
> >
> > CPU A CPU B
> > HCI_NOTIFY_CONN_ADD
> > schedule_work(&data->work);
> > hdev->conn_hash.acl_num > 0
> > HCI_NOTIFY_CONN_DEL
> > schedule_work(&data->work);
> >
> > will the work handler run again?
>
> As I said, the ACL and SCO connection setup is serialized. While in
> theory this can happen, I don't see it in practice.
>
> What would be your proposal to handle this in a cleaner way?

Difficult. I was hoping to avoid scheduling work. I have to rethink.

Regards
Oliver