Re: [rfc]btusb with SCO support

[Oliver Neukum <oliver@neukum.org>]

Am Montag 18 August 2008 15:38:19 schrieben Sie:
> Hi Oliver,
> 
> > > > > > here's my current version of btusb with SCO support. This is preliminary.
> > > > > > I am still looking at a way to delay using the higher altsettings until SCO
> > > > > > is actually used, but the timeouts seem to be too long to do the obvious.
> > > > > 
> > > > > the module parameter and blacklist/quirks stuff has been merged upstream
> > > > > with Linus now. Feel free to update your SCO support patch and then lets
> > > > > get this merged.
> > > > 
> > > > Still testing. I am new to bluetooth so getting a sound testing environment
> > > > up takes a bit of time. I am getting iso urbs to complete now.
> > > 
> > > I hacked up a version that does work fine for me and has been tested on
> > > my Quad G5. The attached applies on top of 2.6.27-rc3.
> > > 
> > > The alternate settings are still fixed to selecting #2, however the
> > > change to always select the appropriate one would be simple. We only
> > > need to calculate the right value. The killing and re-submitting URB
> > > code is already present.
> > 
> > This approach has a principal race condition. You have no idea when
> > the work queue will be run. Thus you can lose the first SCO packages.
> 
> I am open for suggestions, but I don't see any other way to get support
> for this. We can't keep the isoc URBs running all the time, because that
> consumes power.

How much? Or rather why not change the altsetting to the maximum
on open and defer submitting the URBs to notify() ?

> 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.

> > 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?

	Regards
		Oliver