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
Hi Max,
> > 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.
> > 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
Max said:
> 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
Marcel Holtmann wrote:
> Hi Max,
>
>> Sounds good. Thanks for the explanation.
>
> any time :)
>
> I heard rumors that Qualcomm is working on a BlueZ based project.
Hmm. Heard from whom ?
> 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
Hi Max,
> 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
Marcel Holtmann wrote:
> Hi Max,
>
>> 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.
>
> 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.
Sounds good. Thanks for the explanation.
Max
Hi Max,
> 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.
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
Hi Max,
> >>> 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.
> >>> 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.
> 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
Marcel Holtmann wrote:
> Hi Max,
>
>>> 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 ?
>>> 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.
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