Re: [Bluez-devel] BlueZ and the ALSA support

[Marcel Holtmann <marcel@holtmann.org>]

Hi Lars,

> | My problem is that I haven't written all of the hci_usb driver code and
> | some parts are still so messy that I think a complete rewrite is the
> | best that we can do.
> 
> I see, did not know that.

we use our own URB management and this is bad and ugly :(

> | But what I will do is to add a module parameter for
> | choosing the alternate setting that can be changed at runtime. To bring
> | up a device with a new alternate setting you only have to unplug and
> | then plug it in again. This is not the solution we should have, but it
> | will help us with testing the SCO stuff without recompiling the kernel
> | every time.
> 
> Yes, that would be a first step.

Maybe I get this done tomorrow.

> I hope I can have a look at the way how usb_hci works, so that I can
> understand when an asynchronus/delayed change of the endpoint selection
> could happen - or how we could get rid of not-send urbs. *sigh* just
> need more time...
> 
> don't you think it should be possible to
> a) block the submit of new urbs when a change notify has arrived
> b) queue until the queue is empty
> c) change the endpoint setting and release the block
> 
> I don't know to which bad runs or locks this could lead...

To be honest, I don't know. This ISOC stuff is still a mystery to me and
so far I don't know of any Linux driver that is using the ISOC transfers
and have to change the alternate setting at the same time. Selecting it
at probe() time is very easy.

Regards

Marcel




-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel