Skip to contentSkip to conversation

What's the purpose of the new btusb driver ?

DISCUSSION Max Krasnyansky 3 participants 9 messages Oct 23, 2007 – Nov 11, 2007 Bluetooth drivers

lore
Share & tools
lore
#0 lore raw

Marcel,

I was going through latest 2.6 updates and noticed
"Generic Bluetooth USB driver"
Why do we need it ?

The driver code looks awfully similar to my very first implementation of the hci_usb. ie No URB queuing, etc.
I think the only thing that is wrong with hci_usb is the custom urb queuing code (ie _urb stuff). That code was temporary at the time I put it in (year ago now). Greg and I were discussing merging it into USB core. I think we should just do that instead.
If you think URB queuing is no longer needed (I doubt it) then maybe we can just rip that part out.

Comments ?

Max

maintainer
#1 lore raw

Hi Max,

Quoted 4 lines

I was going through latest 2.6 updates and noticed
"Generic Bluetooth USB driver"
Why do we need it ?

Quoted 8 lines

The driver code looks awfully similar to my very first implementation of the hci_usb. ie No URB queuing, etc.
I think the only thing that is wrong with hci_usb is the custom urb queuing code (ie _urb stuff). That code was temporary at the time I put it in (year ago now). Greg and I were discussing merging it into USB core. I think we should just do that instead.
If you think URB queuing is no longer needed (I doubt it) then maybe we can just rip that part out.

the USB subsystem changed a lot in the last two years and everything goes into the direction of one-shot URBs or is using USB anchors to track them. The btusb driver is a full re-write from scratch to make use of it. The driver is still marked as experimental and you can't select it if you enable hci_usb. I pushed it into the mainline kernel since we are currently trying to make it work with autosuspend and also with USB remote wakeup. Both are tricky parts and will need a lot of quirks. In the long run this driver should also do the correct alternate switching in case of SCO connections. So it is meant as a full replacement, but we are not there yet. The hci_usb driver works and I didn't wanna touch it unless we have a full replacement.

My latest tests with the bpa10x and bfusb drivers showed that the URB queuing code is not really needed. The USB core does this already for us and in case of control, interrupt and bulk URBs we can fire at will. The USB core will handle it. The re-submitting can be easily handled and we can attach an anchor to a number of URBs to later on kill them all at once. Latest edition was a flag to let the USB core free the buffer by itself so that the driver doesn't have to care about it anymore. All URBs now have a reference count and so the users are known.

I still have some minor troubles with the isochronous URBs for SCO support and this one-shot model, but that should be fixed soon.

Regards

Marcel

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

#2 lore raw
Quoted 36 lines · Marcel Holtmann

Hi Max,

Quoted 4 lines

I was going through latest 2.6 updates and noticed
"Generic Bluetooth USB driver"
Why do we need it ?

Quoted 8 lines

The driver code looks awfully similar to my very first implementation of the hci_usb. ie No URB queuing, etc.
I think the only thing that is wrong with hci_usb is the custom urb queuing code (ie _urb stuff). That code was temporary at the time I put it in (year ago now). Greg and I were discussing merging it into USB core. I think we should just do that instead.
If you think URB queuing is no longer needed (I doubt it) then maybe we can just rip that part out.

the USB subsystem changed a lot in the last two years and everything goes into the direction of one-shot URBs or is using USB anchors to track them. The btusb driver is a full re-write from scratch to make use of it. The driver is still marked as experimental and you can't select it if you enable hci_usb. I pushed it into the mainline kernel since we are currently trying to make it work with autosuspend and also with USB remote wakeup. Both are tricky parts and will need a lot of quirks. In the long run this driver should also do the correct alternate switching in case of SCO connections. So it is meant as a full replacement, but we are not there yet. The hci_usb driver works and I didn't wanna touch it unless we have a full replacement.

My latest tests with the bpa10x and bfusb drivers showed that the URB queuing code is not really needed. The USB core does this already for us and in case of control, interrupt and bulk URBs we can fire at will. The USB core will handle it. The re-submitting can be easily handled and we can attach an anchor to a number of URBs to later on kill them all at once. Latest edition was a flag to let the USB core free the buffer by itself so that the driver doesn't have to care about it anymore. All URBs now have a reference count and so the users are known.

Quoted 2 lines

I still have some minor troubles with the isochronous URBs for SCO support and this one-shot model, but that should be fixed soon.

Sounds good. Thanks for the explanation.

Max

maintainer
#3 lore raw

Hi Max,

Quoted 1 line

Sounds good. Thanks for the explanation.

any time :)

I heard rumors that Qualcomm is working on a BlueZ based project. Any chance you are coming back to help me out with the kernel stuff. All this new Alternate MAC/PHY stuff is a lot of work.

Regards

Marcel

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

#4 lore raw
Quoted 7 lines · Marcel Holtmann

Hi Max,

Quoted 1 line

Sounds good. Thanks for the explanation.

any time :)

I heard rumors that Qualcomm is working on a BlueZ based project.

Hmm. Heard from whom ?

Quoted 2 lines

Any chance you are coming back to help me out with the kernel stuff. All this new Alternate MAC/PHY stuff is a lot of work.

It is ? I haven't been following BT spec development. I get these emails from SIG (I'm still subscribed to their mailing list). But they are being redirected to /dev/null because of lack of time.
Can you give me some pointers to that MAC/PHY stuff you're talking about ? Is it in the latest spec ?

Max

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

#5 lore raw
Quoted 2 lines · Max

Can you give me some pointers to that MAC/PHY stuff you're talking about ? Is it in the latest spec ?

Nothing is cast in concrete at this time. The various components are still in the feature definition stage and nothing is ready for prototyping.

--- tom
tom allebrandi
[email protected]

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

maintainer
#6 lore raw
In reply to Max Krasnyansky

Hi Max,

Quoted 3 lines
Quoted 1 line

I heard rumors that Qualcomm is working on a BlueZ based project.

Hmm. Heard from whom ?

we had one guy from Qualcomm attending the BlueZ developer meeting a few month ago. So it seems there some efforts.

Quoted 8 lines
Quoted 2 lines

Any chance you are coming back to help me out with the kernel stuff. All this new Alternate MAC/PHY stuff is a lot of work.

It is ? I haven't been following BT spec development. I get these emails from SIG (I'm still subscribed to their mailing list). But they are being redirected to /dev/null because of lack of time.
Can you give me some pointers to that MAC/PHY stuff you're talking about ? Is it in the latest spec ?

Nothing is set in stone here, but for the Seattle release of the specification next year it seems that Alternate MAC/PHY additions are coming. Which means using Ultra-Wideband and/or IEEE 802.11 as alternate radio technologies for high speed links.

Also the L2CAP retransmission and flow control will be started to be used by profile specification. This means we need an implementation for that at some point. I started working on it, but always get distracted by user space stuff.

Regards

Marcel

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

#7 lore raw
Quoted 7 lines · Marcel Holtmann

Hi Max,

Quoted 2 lines
Quoted 1 line

I heard rumors that Qualcomm is working on a BlueZ based project.

Hmm. Heard from whom ?

we had one guy from Qualcomm attending the BlueZ developer meeting a few month ago. So it seems there some efforts.

Do you remember his name ?

Quoted 13 lines
Quoted 7 lines
Quoted 2 lines

Any chance you are coming back to help me out with the kernel stuff. All this new Alternate MAC/PHY stuff is a lot of work.

It is ? I haven't been following BT spec development. I get these emails from SIG (I'm still subscribed to their mailing list). But they are being redirected to /dev/null because of lack of time.
Can you give me some pointers to that MAC/PHY stuff you're talking about ? Is it in the latest spec ?

Nothing is set in stone here, but for the Seattle release of the specification next year it seems that Alternate MAC/PHY additions are coming. Which means using Ultra-Wideband and/or IEEE 802.11 as alternate radio technologies for high speed links.

Quoted 4 lines

Also the L2CAP retransmission and flow control will be started to be used by profile specification. This means we need an implementation for that at some point. I started working on it, but always get distracted by user space stuff.

Sounds interesting.

Max

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

maintainer
#8 lore raw

Hi Max,

Quoted 6 lines
Quoted 5 lines
Quoted 2 lines
Quoted 1 line

I heard rumors that Qualcomm is working on a BlueZ based project.

Hmm. Heard from whom ?

we had one guy from Qualcomm attending the BlueZ developer meeting a few month ago. So it seems there some efforts.

Do you remember his name ?

his name is Steve Ross and since the Google announcement of the Android mobile platform, I am pretty sure that it goes into that direction.

Quoted 13 lines
Quoted 12 lines
Quoted 7 lines
Quoted 2 lines

Any chance you are coming back to help me out with the kernel stuff. All this new Alternate MAC/PHY stuff is a lot of work.

It is ? I haven't been following BT spec development. I get these emails from SIG (I'm still subscribed to their mailing list). But they are being redirected to /dev/null because of lack of time.
Can you give me some pointers to that MAC/PHY stuff you're talking about ? Is it in the latest spec ?

Nothing is set in stone here, but for the Seattle release of the specification next year it seems that Alternate MAC/PHY additions are coming. Which means using Ultra-Wideband and/or IEEE 802.11 as alternate radio technologies for high speed links.

Quoted 5 lines
Quoted 4 lines

Also the L2CAP retransmission and flow control will be started to be used by profile specification. This means we need an implementation for that at some point. I started working on it, but always get distracted by user space stuff.

Sounds interesting.

Cool. Ping me when you are back in. The user space portion is covered pretty well, but the kernel area lacks some developers.

Regards

Marcel

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel