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