When I do interleaved scan on linux, it's doing LE first, for around
10 seconds, and then Classic scan for another few seconds on kernel
level.
I was playing with Bluetooth on macbook, and noticed that they do both
LE and Classic scan at once. So I tried modifying kernel, I triggered
both LE and classic scan at once by queuing both
HCI_OP_LE_SET_SCAN_ENABLE, and HCI_OP_INQUIRY and it just worked, both
LE and Classic devices were reported.
I tested that with CSR, Broadcom and Atheros chips, and all behaved well.
Is there any reason why we do interleave instead of both scans at once ?
I would be more than happy to modify 'interleaved' behaviour, to do
both LE and classic scan at same time.
Hi Jakub,
> When I do interleaved scan on linux, it's doing LE first, for around
> 10 seconds, and then Classic scan for another few seconds on kernel
> level.
>
> I was playing with Bluetooth on macbook, and noticed that they do both
> LE and Classic scan at once. So I tried modifying kernel, I triggered
> both LE and classic scan at once by queuing both
> HCI_OP_LE_SET_SCAN_ENABLE, and HCI_OP_INQUIRY and it just worked, both
> LE and Classic devices were reported.
>
> I tested that with CSR, Broadcom and Atheros chips, and all behaved well.
>
> Is there any reason why we do interleave instead of both scans at once ?
actually there are chips that do not support BR/EDR inquiry and LE scan at the same time. So for some chips we need this behavior. I think that all chips in platforms running Windows 8 will actually support simultaneous BR/EDR inquiry and LE scan since Microsoft mandated it. However in the embedded SoC world that might not be true actually.
And in the early days of LE, there was almost no chip that was able to handle BR/EDR inquiry and LE scan at the same time. That is why the interleaved behavior exists in the first place.
> I would be more than happy to modify 'interleaved' behaviour, to do
> both LE and classic scan at same time.
Introduce HCI_QUIRK_SIMULTAENOUS_DISCOVERY and allow for well know good behaving controller to set it. That way we can slowly move into that direction and keep interleaved behavior as a fallback.
Regards
Marcel
On Mon, Mar 2, 2015 at 4:25 PM, Marcel Holtmann <[email protected]> wrote=
:
> Hi Jakub,
>
>>>> When I do interleaved scan on linux, it's doing LE first, for around
>>>> 10 seconds, and then Classic scan for another few seconds on kernel
>>>> level.
>>>>
>>>> I was playing with Bluetooth on macbook, and noticed that they do both
>>>> LE and Classic scan at once. So I tried modifying kernel, I triggered
>>>> both LE and classic scan at once by queuing both
>>>> HCI_OP_LE_SET_SCAN_ENABLE, and HCI_OP_INQUIRY and it just worked, both
>>>> LE and Classic devices were reported.
>>>>
>>>> I tested that with CSR, Broadcom and Atheros chips, and all behaved we=
ll.
>>>>
>>>> Is there any reason why we do interleave instead of both scans at once=
?
>>>
>>> actually there are chips that do not support BR/EDR inquiry and LE scan=
at the same time. So for some chips we need this behavior. I think that al=
l chips in platforms running Windows 8 will actually support simultaneous B=
R/EDR inquiry and LE scan since Microsoft mandated it. However in the embed=
ded SoC world that might not be true actually.
>>>
>>> And in the early days of LE, there was almost no chip that was able to =
handle BR/EDR inquiry and LE scan at the same time. That is why the interle=
aved behavior exists in the first place.
>>>
>>>> I would be more than happy to modify 'interleaved' behaviour, to do
>>>> both LE and classic scan at same time.
>>>
>>> Introduce HCI_QUIRK_SIMULTAENOUS_DISCOVERY and allow for well know good=
behaving controller to set it. That way we can slowly move into that direc=
tion and keep interleaved behavior as a fallback.
>>>
>>> Regards
>>>
>>> Marcel
>>>
>>
>> So I send my patches previous week, and I just uploaded new version.
>> The old version was just starting both scans at once. It was working
>> on Atheros, CSR, and Broadcom, but then I find out it doesn't work on
>> Intel controllers.
>
> I know for certain that there are some older Atheros controllers that did=
not support simultaneous service discovery. And I think certain Qualcomm h=
ardware doesn't do either. That might be all fixed now and it might be supp=
orted starting certain controller or firmware version, but that is somethin=
g that should come from the vendor in the end.
>
>> The reason for that was LE scan window equal to LE scan interval. When
>> I doubled Scan Interval, Intel devices started working. Apparently
>> other controllers don't really care.
>
> Can you be more specific which Intel controllers. We have more than one a=
nd also different firmware patches for them. We might need to test this a b=
it more.
>
One was Intel Wilkins Peak 2, I'm not sure about the other, they said
hello in dmesg like this:
[ 1.373161] Bluetooth: hci0: read Intel version: 3707100180012d0d0d
[ 1.373170] Bluetooth: hci0: Intel device is already patched. patch num: 0d
and
[ 9.521272] Bluetooth: hci0: read Intel version: 370710018002030d00
[ 9.554952] Bluetooth: hci0: Intel Bluetooth firmware file:
intel/ibt-hw-37.7.10-fw-1.80.2.3.d.bseq
[ 9.735771] Bluetooth: hci0: Intel Bluetooth firmware patch completed
and activated
However those are built-in into chromebooks, and the patch file in
/lib/firmware/intel/ibt-hw-37.7.10-fw-1.80.2.3.d.bseq have different
size than in i.e. Ubuntu distribution, so there might be somenthing
specially for chromebooks.
>> So now it works on all controllers I have tested with.
>>
>> I have however question about Broadcom:
>> Simultaenous scan work, when there is firmware patch in /lib/firmware
>> (ubuntu have it). If the patch is not present it's not working. Can I
>> somehow make this kind of check in btusb.c to set the quirk ?
>
> You can set this quirk from within hdev->setup(). However this is dangero=
us if it is a maybe thing. In these cases it might be better to keep off. O=
r actually tie it to firmware build numbers that have been tested to work. =
You can get the firmware build numbers from the HCI revision information. T=
hat it works on one Broadcom controllers does not mean it works on all of t=
hem.
>
>> I also have question about scan window and interval: right now I just
>> doubled scan interval. This gives more than 12ms of free time that
>> BR/EDR scan would use to do inquiry. I fund in spec (Version 4.2 [Vol
>> 2, Part E] 6.2 and 6.3) that default Inquiry_Scan_Window is 11.25ms,
>> so this should work good. Do you have any suggestions to tune those
>> parameters in other way ?
>
> Actually inside the kernel we can not just pick new values. They are driv=
en by the Set Scan Parameters management command. So we need to obey to wha=
t userspace gave us.
No, the interval value used during discovery is hard coded here:
http://git.kernel.org/cgit/linux/kernel/git/bluetooth/bluetooth-next.git/tr=
ee/include/net/bluetooth/hci_core.h#n1286
and used here:
http://git.kernel.org/cgit/linux/kernel/git/bluetooth/bluetooth-next.git/tr=
ee/net/bluetooth/mgmt.c#n3862
So it looks like values set by Set Scan Parameters are not used, and
we have to pick new ones. Or is that a bug ?
I will fix the patches that set the quirk for particular controllers.
But patches no 1 and 2 are still good, can you please take a look at
them ?
>
> Regards
>
> Marcel
>
Hi Jakub,
>>> When I do interleaved scan on linux, it's doing LE first, for around
>>> 10 seconds, and then Classic scan for another few seconds on kernel
>>> level.
>>>
>>> I was playing with Bluetooth on macbook, and noticed that they do both
>>> LE and Classic scan at once. So I tried modifying kernel, I triggered
>>> both LE and classic scan at once by queuing both
>>> HCI_OP_LE_SET_SCAN_ENABLE, and HCI_OP_INQUIRY and it just worked, both
>>> LE and Classic devices were reported.
>>>
>>> I tested that with CSR, Broadcom and Atheros chips, and all behaved well.
>>>
>>> Is there any reason why we do interleave instead of both scans at once ?
>>
>> actually there are chips that do not support BR/EDR inquiry and LE scan at the same time. So for some chips we need this behavior. I think that all chips in platforms running Windows 8 will actually support simultaneous BR/EDR inquiry and LE scan since Microsoft mandated it. However in the embedded SoC world that might not be true actually.
>>
>> And in the early days of LE, there was almost no chip that was able to handle BR/EDR inquiry and LE scan at the same time. That is why the interleaved behavior exists in the first place.
>>
>>> I would be more than happy to modify 'interleaved' behaviour, to do
>>> both LE and classic scan at same time.
>>
>> Introduce HCI_QUIRK_SIMULTAENOUS_DISCOVERY and allow for well know good behaving controller to set it. That way we can slowly move into that direction and keep interleaved behavior as a fallback.
>>
>> Regards
>>
>> Marcel
>>
>
> So I send my patches previous week, and I just uploaded new version.
> The old version was just starting both scans at once. It was working
> on Atheros, CSR, and Broadcom, but then I find out it doesn't work on
> Intel controllers.
I know for certain that there are some older Atheros controllers that did not support simultaneous service discovery. And I think certain Qualcomm hardware doesn't do either. That might be all fixed now and it might be supported starting certain controller or firmware version, but that is something that should come from the vendor in the end.
> The reason for that was LE scan window equal to LE scan interval. When
> I doubled Scan Interval, Intel devices started working. Apparently
> other controllers don't really care.
Can you be more specific which Intel controllers. We have more than one and also different firmware patches for them. We might need to test this a bit more.
> So now it works on all controllers I have tested with.
>
> I have however question about Broadcom:
> Simultaenous scan work, when there is firmware patch in /lib/firmware
> (ubuntu have it). If the patch is not present it's not working. Can I
> somehow make this kind of check in btusb.c to set the quirk ?
You can set this quirk from within hdev->setup(). However this is dangerous if it is a maybe thing. In these cases it might be better to keep off. Or actually tie it to firmware build numbers that have been tested to work. You can get the firmware build numbers from the HCI revision information. That it works on one Broadcom controllers does not mean it works on all of them.
> I also have question about scan window and interval: right now I just
> doubled scan interval. This gives more than 12ms of free time that
> BR/EDR scan would use to do inquiry. I fund in spec (Version 4.2 [Vol
> 2, Part E] 6.2 and 6.3) that default Inquiry_Scan_Window is 11.25ms,
> so this should work good. Do you have any suggestions to tune those
> parameters in other way ?
Actually inside the kernel we can not just pick new values. They are driven by the Set Scan Parameters management command. So we need to obey to what userspace gave us.
Regards
Marcel
Hi Marcel,
On Tue, Feb 24, 2015 at 7:18 PM, Marcel Holtmann <[email protected]> wrot=
e:
> Hi Jakub,
>
>> When I do interleaved scan on linux, it's doing LE first, for around
>> 10 seconds, and then Classic scan for another few seconds on kernel
>> level.
>>
>> I was playing with Bluetooth on macbook, and noticed that they do both
>> LE and Classic scan at once. So I tried modifying kernel, I triggered
>> both LE and classic scan at once by queuing both
>> HCI_OP_LE_SET_SCAN_ENABLE, and HCI_OP_INQUIRY and it just worked, both
>> LE and Classic devices were reported.
>>
>> I tested that with CSR, Broadcom and Atheros chips, and all behaved well=
.
>>
>> Is there any reason why we do interleave instead of both scans at once ?
>
> actually there are chips that do not support BR/EDR inquiry and LE scan a=
t the same time. So for some chips we need this behavior. I think that all =
chips in platforms running Windows 8 will actually support simultaneous BR/=
EDR inquiry and LE scan since Microsoft mandated it. However in the embedde=
d SoC world that might not be true actually.
>
> And in the early days of LE, there was almost no chip that was able to ha=
ndle BR/EDR inquiry and LE scan at the same time. That is why the interleav=
ed behavior exists in the first place.
>
>> I would be more than happy to modify 'interleaved' behaviour, to do
>> both LE and classic scan at same time.
>
> Introduce HCI_QUIRK_SIMULTAENOUS_DISCOVERY and allow for well know good b=
ehaving controller to set it. That way we can slowly move into that directi=
on and keep interleaved behavior as a fallback.
>
> Regards
>
> Marcel
>
So I send my patches previous week, and I just uploaded new version.
The old version was just starting both scans at once. It was working
on Atheros, CSR, and Broadcom, but then I find out it doesn't work on
Intel controllers.
The reason for that was LE scan window equal to LE scan interval. When
I doubled Scan Interval, Intel devices started working. Apparently
other controllers don't really care.
So now it works on all controllers I have tested with.
I have however question about Broadcom:
Simultaenous scan work, when there is firmware patch in /lib/firmware
(ubuntu have it). If the patch is not present it's not working. Can I
somehow make this kind of check in btusb.c to set the quirk ?
I also have question about scan window and interval: right now I just
doubled scan interval. This gives more than 12ms of free time that
BR/EDR scan would use to do inquiry. I fund in spec (Version 4.2 [Vol
2, Part E] 6.2 and 6.3) that default Inquiry_Scan_Window is 11.25ms,
so this should work good. Do you have any suggestions to tune those
parameters in other way ?