Hi Champion,
I have a card here which has RTL8723BE wifi and bluetooth combined. 2 antennas.
In linux-next (Linux 4.2) the bluetooth and wifi work fine separately,
but when using them together, I can sometimes see a problem. This is
using the btusb driver based on your code (now included in Linux 4.2),
and the RTL8723B rtlwifi driver, all using the latest firmware in the
linux-firmware git repo.
To reproduce:
- Boot with no wifi connection active
- "hcitool scan" and verify that my laptop and phone can be seen
- Connect to wifi
- Run "hcitool scan" again a few times a minute, within 2-5 minutes
normally my phone and laptop can no longer be seen
- Disconnect from wifi and immediately run "hcitool scan" again, my
phone and laptop can be seen
3 interesting observations when the scan results are coming back empty:
1. I can still get the names of the remote devices by running
"hcitool name <addr>"
2. I can still query the remote devices by running "hcitool info
<addr>". After this, the scan suddenly starts working again!
3. Even though both of my local bluetooth devices no longer appear in
scan results, I can sometimes see my neighbour's phone coming up as a
scan result at this time.
Anyway, disabling btcoexist avoids the issue, so I dug through that
code, and found the exact line of code that seems to (sometimes) make
us enter this strange mode.
Call chain inside drivers/net/wireless/rtlwifi/btcoexist/halbtc8723b2ant.c:
ex_btc8723b2ant_bt_info_notify (called when starting and finishing a BT scan)
btc8723b2ant_run_coexist_mechanism
btc8723b2ant_action_bt_inquiry
As wifi is connected, we now call:
btc8723b2ant_ps_tdma(btcoexist, NORMAL_EXEC, true, 3);
This is the function call that sometimes puts us into the mode where
there are no scan results. Inside this function, if I comment out
these lines in the turn_on section, the bug is avoided:
case 3:
//btc8723b2ant_set_fw_ps_tdma(btcoexist, 0xe3, 0x1c,
// 0x3, 0xf1, 0x90);
break;
Any idea what is happening here? Can you help me find a better fix?
Thanks
Daniel
RGVhciBhbGwsCgpBcyBNYXJjZWwgc2FpZCwgc29tZSBSZWFsdGVrIFdpRmkgKyBCVCBzb2x1dGlv
biBhcmUgdHdvIGNoaXBzIHNvbHV0aW9uLgotIDEgY2hpcCBzb2x1dGlvbjogODcyM0JFLCA4ODIx
QUUKLSAyIGNoaXBzIHNvbHV0aW9uOiA4ODEyQUUgKyA4NzYxQVUsIDgxOTJFRSArIDg3NjFBVQoK
RXZlbiBpbiAyIGNoaXBzIHNvbHV0aW9uLCB0aGVyZSBhcmUgc29tZSBkaWZmZXJlbmNlOgotIEhh
cmR3YXJlIGNvbm5lY3RlZCBpbiBtb2R1bGU6IDgxOTJFRSArIDg3NjFBVQotIEluZGVwZW5kZW50
LCBuZWVkIFNXIGludm9sdmVkLCBldmVuIGluIHRoZSBzYW1lIG1vZHVsZTogODgxMkFFICsgODc2
MUFVCgpJbiAxIGNoaXAgb3IgaGFyZHdhcmUgY29ubmVjdGVkIHNvbHV0aW9uLCBib3RoIGRyaXZl
ciBkb24ndCBuZWVkIGNvbW11bmljYXRlLApCVGNvZXggZHJpdmVyIGtub3dzIGV2ZXJ5dGhpbmcg
dmlhIEhXIGV2ZW50LCBhbmQgY29udHJvbCBldmVyeXRoaW5nIGl0IHdhbnRzLgoKSW4gMiBjaGlw
cyBhbmQgaW5kZXBlbmRlbnQgc29sdXRpb24sIHllcywgaXRzIG91ciBwcm9ibGVtLiBJbiB0aGlz
IGNhc2UsIHdlIG5lZWQgCnNvbWUgY29tbXVuaWNhdGlvbiBtZWNoYW5pc20gYmV0d2VlbiBkcml2
ZXJzLiBUaGUgcmZyZXMgc3Vic3lzdGVtIHNlZW1zIApnb29kLCBidXQgaXQgdGFrZXMgdGltZS4g
SWYgb3RoZXIgc2ltcGxlIG1ldGhvZHMgY2FuIGRvLCBwbGVhc2UgdGVsbCB1cy4KClRoYW5rcywK
U2hhb2Z1CgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCrFxOiBMYXJy
eSBGaW5nZXIgW2xhcnJ5LmZpbmdlckBnbWFpbC5jb21dIKVOqu0gTGFycnkgRmluZ2VyIFtMYXJy
eS5GaW5nZXJAbHdmaW5nZXIubmV0XQqxSKXzpOm0wTogMjAxNaZ+NaTrMjik6SCkVaTIIDExOjU4
CqbcOiBNYXJjZWwgSG9sdG1hbm47IERhbmllbCBEcmFrZQqwxqW7OiBDaGFtcGlvbl9jaGVuOyBD
YXJsbyBDYWlvbmU7IExpbnV4IEJsdWV0b290aCBtYWlsaW5nIGxpc3Q7IFNoYW9mdTsgYXNraWpl
cnJ5X3poYW5nOyBhbGV4X2x1OyBDaGloLUhzaWFuZyBXYW5nOyBqYXNvbl9tYW87IFBrc2hpaDsg
U2hhb2Z1CqVEpq46IFJlOiBSZWFsdGVrIFVTQiBibHVldG9vdGg6IG5vIHNjYW4gcmVzdWx0cyB3
aGVuIHdpZmkgaXMgY29ubmVjdGVkCgpPbiAwNS8yOC8yMDE1IDEwOjEzIEFNLCBNYXJjZWwgSG9s
dG1hbm4gd3JvdGU6Cj4gSGkgRGFuaWVsLAo+Cj4+Pj4gICAgICAgV2Ugd2FudCB0byBzaGFyZSBz
b21lIGluZm9ybWF0aW9uIGJldHdlZW4gd2lmaSBkcml2ZXIgYW5kIGJ0IGRyaXZlciwgd2hhdCBy
dWxlcyBkbyB5b3UgcmVjb21tZW5kIGZvciB0aGUgZm9sbG93aW5nIHNpdHVhdGlvbiA/Cj4+Pj4g
MS4gYXQgc3lzdGVtIHN0YXJ0dXAsIGJsdWV0b290aCBkcml2ZXIgd2FudCB0byByZWFkIHNvbWUg
aW5mb3JtYXRpb24gKGVnIGFudGVubmEgc2V0dGluZ3MpIHRoYXQgZ2VuZXJhdGVkIGJ5IHdpZmkg
LCBzaGFsbCB3ZSB1c2UgZmlsZXMgb3IgL3Byb2MvIGluZm9ybWF0aW9uPwo+Pj4+IDIuIHdoZW4g
dXNlciBpcyB1c2luZyBCbHVldG9vdGgsIGJ0IGRyaXZlciBtYXkgbm90aWZ5IHdpZmkgZHJpdmVy
IHRvIHBlcmZvcm0gYmV0dGVyLCBzaGFsbCB3ZSB1c2Ugc29ja2V0IHRvIGNvbW11bmljYXRpb24/
Cj4+Pgo+Pj4gdGhpcyBpcyB0aGUgQmx1ZXRvb3RoIHN1YnN5c3RlbSBjb21tdW5pY2F0aW5nIHdp
dGggdGhlIFdpRmkgc3Vic3lzdGVtIChjZmc4MDIxMSkgYW5kIHZpY2UgdmVyc2EsIHRoZW4gdGhp
cyBpcyBoYXBwZW5pbmcgaW5zaWRlIHRoZSBrZXJuZWwuIEkgZG8gbm90IHNlZSBhbnkgbmVlZCB0
byBldmVuIHRyeSB0byBnbyB2aWEgdXNlcnNwYWNlIGF0IGFsbC4gU28gbmVpdGhlciAvcHJvYyBh
bmQgbm8gc29ja2V0cyBmb3IgdGhpcy4KPj4KPj4gSSBhZ3JlZS4gQnV0IGNhbiB3ZSBnaXZlIG1v
cmUgc3BlY2lmaWMgYWR2aWNlIG9uIGhvdyB0byBkbyB0aGlzIGluc2lkZQo+PiB0aGUga2VybmVs
Pwo+PiBpLmUuIHNob3VsZCB0aGV5IGNyZWF0ZSBhIG5ldyBkcml2ZXIgdW5kZXIgZHJpdmVycy9t
aXNjIHdoaWNoIGV4cG9zZXMKPj4gYSBzaGFyZWQgQVBJIHZpYSBFWFBPUlRfU1lNQk9MPwo+Cj4g
SSB3YXMgYWN0dWFsbHkgdGhpbmtpbmcgYWJvdXQgY3JlYXRpbmcgYSByZnJlcyBzdWJzeXN0ZW0g
d2hlcmUgZWFjaCByYWRpbyBzdWJzeXN0ZW0gY2FuIHJlZ2lzdGVyIHRoZWlyIGFudGVubmEgYW5k
IGNoYW5uZWwgaW5mb3JtYXRpb24uIFRoYXQgd2h5IFdpRmkgZG9lcyBub3QgZGVwZW5kIG9uIEJs
dWV0b290aCBvciB0aGF0IEJsdWV0b290aCBkZXBlbmQgb24gV2lGaS4gVGhpcyBjcm9zcyBkZXBl
bmRlbmN5IGlzIHNvbWV0aGluZyBJIGxpa2UgdG8gYXZvaWQuCj4KPiBBbmQgd2l0aCByZnJlcyBz
dWJzeXN0ZW0gaW4gcGxhY2UsIGVhY2ggc3Vic3lzdGVtIGNvdWxkIGFsc28gcmVnaXN0ZXIgZm9y
IG5vdGlmaWNhdGlvbiBhbmQgYWRhcHQgaXRzIHJhZGlvIHVzYWdlIGlmIHBvc3NpYmxlLiBLZWVw
IGluIG1pbmQgdGhhdCB3ZSBzdXBwb3J0IG11bHRpcGxlIEJsdWV0b290aCBhbmQgV2lGaSBjYXJk
cyBpbiB0aGUgc3lzdGVtLiBTbyB0aGlzIGFsbCBuZWVkcyB0byBiZSBmdWxseSBnZW5lcmljLgo+
Cj4+IFRoZSBvdGhlciBvcHRpb24gZm9yIFJlYWx0ZWsgdG8gY29uc2lkZXIgaXMgdG8gZG8gdGhp
cyBpbgo+PiBoYXJkd2FyZS9maXJtd2FyZS4gSSBhbHJlYWR5IHNhdyB0aGF0IHRoZSBidGNvZXhp
c3QgZHJpdmVyIGtub3dzCj4+IGV4YWN0bHkgd2hlbiB0aGUgd2lmaSBhbmQgQlQgc3RhcnQgYW5k
IGZpbmlzaCBzY2FubmluZywgc28gdGhlcmUgaXMKPj4gY2xlYXJseSBhbHJlYWR5IGFuIGluZm9y
bWF0aW9uLXBhc3NpbmcgbWVjaGFuaXNtIGJldHdlZW4gdGhlIHR3bwo+PiBpbnRlcmZhY2VzLiBJ
IHdvbmRlciBpZiBhbiB1cGRhdGVkIGZpcm13YXJlIGNvdWxkIGV4dGVuZCB0aGF0IHRvCj4+IGlu
Y2x1ZGUgdGhlIG5ldyBpbmZvcm1hdGlvbiB0aGF0IHlvdSB3aXNoIHRvIGFkZGl0aW9uYWxseSB0
cmFuc2Zlci4KPgo+IFRoYXQgaXMgYW5vdGhlciBvcHRpb24gYW5kIGEgbG90IG9mIGNvbXBhbmll
cyBoYXZlIGNob3NlbiB0byBkbyB0aGlzLiBJZiB0aGlzIGlzIGEgY2FyZCB0aGF0IGhhcyBXaUZp
IGFuZCBCbHVldG9vdGggb24gdGhlIHNhbWUgaGFyZHdhcmUsIHRoZW4gbm9ybWFsbHkgYW4gaW50
ZXJuYWwgYnVzIGV4aXN0cyBmb3IgY29tbXVuaWNhdGluZyBjb2V4aXN0ZW5jZSBpbmZvcm1hdGlv
biBvdXQtb2YtYmFuZC4gVGhhdCBpcyB3aGF0IHdlIGFyZSBleHBlY3RpbmcgaW4gYSBsb3Qgb2Yg
Y2FzZXMgdG8gaGFwcGVuIHdoZW4gbG9va2luZyBhdCBwbGF0Zm9ybXMuCj4KPiBPZiBjb3Vyc2Ug
cmZyZXMgd2lsbCBiZSBoYXJkbHkgZG8gYSBiZXR0ZXIgam9iIHRoZW4gdGhlIGludGVybmFsIGNv
bW11bmljYXRpb24gYmV0d2VlbiB0aGUgV2lGaSBhbmQgQmx1ZXRvb3RoIHBhcnRzIG9uIHRoZSBz
YW1lIGNoaXAuIEl0IGNhbiBvbmx5IGhlbHAgd2hlbiB0aGUgdHdvIHBpZWNlcyBhcmUgaW5kZXBl
bmRlbnQgb3Igd2hlbiB5b3UgaGF2ZSBtb3JlIHRoYW4gb25lIG9mIGVhY2ggaW5zdGFsbGVkLgoK
SSBkbyBub3Qga25vdyBtdWNoIGFib3V0IHRoZSBpbnRlcm5hbCBzdHJ1Y3R1cmUgb2YgdGhlIFJl
YWx0ZWsgZGV2aWNlcywgYW5kIEkKaGF2ZSBubyBpZGVhIGlmIHRoZSB0d28gcGFydHMgY2FuIGNv
bW11bmljYXRlIG92ZXIgYW4gaW50ZXJuYWwgYnVzLiBGb3IgdGhhdApyZWFzb24sIEkgaGF2ZSBh
ZGRlZCBTaGFvZnUsIHRoZSBsZWFkIGVuZ2luZWVyIG9uIHRoZSBQQ0llIHdpZmkgZHJpdmVyLgoK
SXMgdGhlcmUgYSB0aW1lIGZyYW1lIGZvciByZnJlcz8gQWx0aG91Z2ggaXQgbWlnaHQgbm90IGRv
IGEgYmV0dGVyIGpvYiBpbiBhbGwKY2FzZXMsIGl0cyBnZW5lcmFsaXR5IHdpbGwgYmUgdXNlZnVs
LgoKTGFycnkKCgoKLS0tLS0tUGxlYXNlIGNvbnNpZGVyIHRoZSBlbnZpcm9ubWVudCBiZWZvcmUg
cHJpbnRpbmcgdGhpcyBlLW1haWwuCg==
On 05/28/2015 10:13 AM, Marcel Holtmann wrote:
> Hi Daniel,
>
>>>> We want to share some information between wifi driver and bt driver, what rules do you recommend for the following situation ?
>>>> 1. at system startup, bluetooth driver want to read some information (eg antenna settings) that generated by wifi , shall we use files or /proc/ information?
>>>> 2. when user is using Bluetooth, bt driver may notify wifi driver to perform better, shall we use socket to communication?
>>>
>>> this is the Bluetooth subsystem communicating with the WiFi subsystem (cfg80211) and vice versa, then this is happening inside the kernel. I do not see any need to even try to go via userspace at all. So neither /proc and no sockets for this.
>>
>> I agree. But can we give more specific advice on how to do this inside
>> the kernel?
>> i.e. should they create a new driver under drivers/misc which exposes
>> a shared API via EXPORT_SYMBOL?
>
> I was actually thinking about creating a rfres subsystem where each radio subsystem can register their antenna and channel information. That why WiFi does not depend on Bluetooth or that Bluetooth depend on WiFi. This cross dependency is something I like to avoid.
>
> And with rfres subsystem in place, each subsystem could also register for notification and adapt its radio usage if possible. Keep in mind that we support multiple Bluetooth and WiFi cards in the system. So this all needs to be fully generic.
>
>> The other option for Realtek to consider is to do this in
>> hardware/firmware. I already saw that the btcoexist driver knows
>> exactly when the wifi and BT start and finish scanning, so there is
>> clearly already an information-passing mechanism between the two
>> interfaces. I wonder if an updated firmware could extend that to
>> include the new information that you wish to additionally transfer.
>
> That is another option and a lot of companies have chosen to do this. If this is a card that has WiFi and Bluetooth on the same hardware, then normally an internal bus exists for communicating coexistence information out-of-band. That is what we are expecting in a lot of cases to happen when looking at platforms.
>
> Of course rfres will be hardly do a better job then the internal communication between the WiFi and Bluetooth parts on the same chip. It can only help when the two pieces are independent or when you have more than one of each installed.
I do not know much about the internal structure of the Realtek devices, and I
have no idea if the two parts can communicate over an internal bus. For that
reason, I have added Shaofu, the lead engineer on the PCIe wifi driver.
Is there a time frame for rfres? Although it might not do a better job in all
cases, its generality will be useful.
Larry
Hi Daniel,
>>> We want to share some information between wifi driver and bt driver, what rules do you recommend for the following situation ?
>>> 1. at system startup, bluetooth driver want to read some information (eg antenna settings) that generated by wifi , shall we use files or /proc/ information?
>>> 2. when user is using Bluetooth, bt driver may notify wifi driver to perform better, shall we use socket to communication?
>>
>> this is the Bluetooth subsystem communicating with the WiFi subsystem (cfg80211) and vice versa, then this is happening inside the kernel. I do not see any need to even try to go via userspace at all. So neither /proc and no sockets for this.
>
> I agree. But can we give more specific advice on how to do this inside
> the kernel?
> i.e. should they create a new driver under drivers/misc which exposes
> a shared API via EXPORT_SYMBOL?
I was actually thinking about creating a rfres subsystem where each radio subsystem can register their antenna and channel information. That why WiFi does not depend on Bluetooth or that Bluetooth depend on WiFi. This cross dependency is something I like to avoid.
And with rfres subsystem in place, each subsystem could also register for notification and adapt its radio usage if possible. Keep in mind that we support multiple Bluetooth and WiFi cards in the system. So this all needs to be fully generic.
> The other option for Realtek to consider is to do this in
> hardware/firmware. I already saw that the btcoexist driver knows
> exactly when the wifi and BT start and finish scanning, so there is
> clearly already an information-passing mechanism between the two
> interfaces. I wonder if an updated firmware could extend that to
> include the new information that you wish to additionally transfer.
That is another option and a lot of companies have chosen to do this. If this is a card that has WiFi and Bluetooth on the same hardware, then normally an internal bus exists for communicating coexistence information out-of-band. That is what we are expecting in a lot of cases to happen when looking at platforms.
Of course rfres will be hardly do a better job then the internal communication between the WiFi and Bluetooth parts on the same chip. It can only help when the two pieces are independent or when you have more than one of each installed.
Regards
Marcel
On Thu, May 28, 2015 at 8:23 AM, Marcel Holtmann <[email protected]> wrote:
> Hi Champion,
>
>> We want to share some information between wifi driver and bt driver, what rules do you recommend for the following situation ?
>> 1. at system startup, bluetooth driver want to read some information (eg antenna settings) that generated by wifi , shall we use files or /proc/ information?
>> 2. when user is using Bluetooth, bt driver may notify wifi driver to perform better, shall we use socket to communication?
>
> this is the Bluetooth subsystem communicating with the WiFi subsystem (cfg80211) and vice versa, then this is happening inside the kernel. I do not see any need to even try to go via userspace at all. So neither /proc and no sockets for this.
I agree. But can we give more specific advice on how to do this inside
the kernel?
i.e. should they create a new driver under drivers/misc which exposes
a shared API via EXPORT_SYMBOL?
The other option for Realtek to consider is to do this in
hardware/firmware. I already saw that the btcoexist driver knows
exactly when the wifi and BT start and finish scanning, so there is
clearly already an information-passing mechanism between the two
interfaces. I wonder if an updated firmware could extend that to
include the new information that you wish to additionally transfer.
Daniel
Hi Champion,
> We want to share some information between wifi driver and bt driver, what rules do you recommend for the following situation ?
> 1. at system startup, bluetooth driver want to read some information (eg antenna settings) that generated by wifi , shall we use files or /proc/ information?
> 2. when user is using Bluetooth, bt driver may notify wifi driver to perform better, shall we use socket to communication?
this is the Bluetooth subsystem communicating with the WiFi subsystem (cfg80211) and vice versa, then this is happening inside the kernel. I do not see any need to even try to go via userspace at all. So neither /proc and no sockets for this.
Regards
Marcel
RGVhciBEYW5pZWwsDQoJV2Ugd2FudCB0byBzaGFyZSBzb21lIGluZm9ybWF0aW9uIGJldHdlZW4g
d2lmaSBkcml2ZXIgYW5kIGJ0IGRyaXZlciwgd2hhdCBydWxlcyBkbyB5b3UgcmVjb21tZW5kIGZv
ciB0aGUgZm9sbG93aW5nIHNpdHVhdGlvbiA/DQoxLiBhdCBzeXN0ZW0gc3RhcnR1cCwgYmx1ZXRv
b3RoIGRyaXZlciB3YW50IHRvIHJlYWQgc29tZSBpbmZvcm1hdGlvbiAoZWcgYW50ZW5uYSBzZXR0
aW5ncykgdGhhdCBnZW5lcmF0ZWQgYnkgd2lmaSAsIHNoYWxsIHdlIHVzZSBmaWxlcyBvciAvcHJv
Yy8gaW5mb3JtYXRpb24/IA0KMi4gd2hlbiB1c2VyIGlzIHVzaW5nIEJsdWV0b290aCwgYnQgZHJp
dmVyIG1heSBub3RpZnkgd2lmaSBkcml2ZXIgdG8gcGVyZm9ybSBiZXR0ZXIsIHNoYWxsIHdlIHVz
ZSBzb2NrZXQgdG8gY29tbXVuaWNhdGlvbj8NCg0KQ2hhbXBpb24NCkV4dDojNjMyNQ0KDQotLS0t
LemCruS7tuWOn+S7ti0tLS0tDQrlj5Hku7bkuro6IERhbmllbCBEcmFrZSBbbWFpbHRvOmRyYWtl
QGVuZGxlc3NtLmNvbV0gDQrlj5HpgIHml7bpl7Q6IDIwMTXlubQ15pyIMjHml6UgMjE6MzANCuaU
tuS7tuS6ujog6ZmI6Imz6JCNDQrmioTpgIE6IExhcnJ5IEZpbmdlcjsgQ2FybG8gQ2Fpb25lOyBM
aW51eCBCbHVldG9vdGggbWFpbGluZyBsaXN0OyBzaGFvZnVAcmVhbHRlay5jb20gPiBzaGFvZnU7
IOW8oOW/l+elpTsg6ZmG5pyx5LyfOyBDaGloLUhzaWFuZyBXYW5nOyDmr5vkuLrplIs7IHBrc2hp
aEByZWFsdGVrLmNvbQ0K5Li76aKYOiBSZTog562U5aSNOiDnrZTlpI06IFJlYWx0ZWsgVVNCIGJs
dWV0b290aDogbm8gc2NhbiByZXN1bHRzIHdoZW4gd2lmaSBpcyBjb25uZWN0ZWQNCg0KSGksDQoN
Ck9uIFR1ZSwgTWF5IDEyLCAyMDE1IGF0IDg6MzYgUE0sIOmZiOiJs+iQjSA8Y2hhbXBpb25fY2hl
bkByZWFsc2lsLmNvbS5jbj4gd3JvdGU6DQo+IERlYXIgRGFuaWVsLA0KPiAgICAgICAgIEZvciAg
ODcyM0JVLCAgICAgICBhbHdheXMgdXNlIENPTkZJR19TMF9BTlRURU5B77ybDQo+ICAgICAgICAg
Rm9yICA4NzIzQkUg77yMIDEgYW50ZW5uYSBDT05GSUdfUzFfQU5UVEVOQTsgMiBhbnRlbm5hcyAN
Cj4gQ09ORklHX1MwX0FOVFRFTkENCg0KDQpJIHRlc3RlZCB3aXRoIENPTkZJR19TMF9BTlRFTk5B
IGFzIEkgYW0gdXNpbmcgYSA4NzIzQkUgd2l0aCAyIGFudGVubmFzLg0KDQpJIGJlbGlldmUgdGhp
cyBjb25maWd1cmF0aW9uIGlzIGhhdmluZyBubyBlZmZlY3QuIEkgdGVzdGVkIGFzIGZvbGxvd3M6
DQoNCkJ1aWx0IGtlcm5lbCB3aXRob3V0IHJ0bHdpZmkgc3VwcG9ydC4NCkJvb3RlZC4NCkRpc2Nv
bm5lY3RlZCBib3RoIGFudGVubmFzLg0KTW92ZWQgcmVtb3RlIGJsdWV0b290aCBkZXZpY2UgMiBt
ZXRyZXMgYXdheS4NClJhbiAiaGNpdG9vbCBzY2FuIiAtLT4gbm8gcmVzdWx0cy4gR29vZC4NCkNv
bm5lY3RlZCBhbnRlbm5hIDEuIFNjYW4gLS0+IHJlbW90ZSBkZXZpY2UgY2FuIGJlIHNlZW4gRGlz
Y29ubmVjdGVkIGFudGVubmEgMSwgY29ubmVjdGVkIGFudGVubmEgMi4gU2NhbiAtLT4gcmVtb3Rl
IGRldmljZSBjYW4gYmUgc2Vlbg0KDQpJIHRoZW4gdHJpZWQgd2l0aCBDT05GSUdfUzFfQU5URU5O
QSBhbmQgdGhlbiBhZ2FpbiB3aXRob3V0IGRvaW5nIHRoZQ0KUzAvUzEgYW50ZW5uYSBjb25maWcg
YXQgYWxsLiBUaGUgcmVzdWx0cyBhcmUgYWx3YXlzIHRoZSBzYW1lLiBJdCBzZWVtcyBsaWtlIHRo
ZSBibHVldG9vdGggaW50ZXJmYWNlIGlzIGFsd2F5cyB1c2luZyBib3RoIGFudGVubmFzIChoZW5j
ZSBpdCBjYW4gd29yayBldmVuIGlmIG9uZSBvZiB0aGVtIGlzIGRpc2Nvbm5lY3RlZCkuDQoNCkFs
c28sIGV2ZW4gd2l0aCB0aGlzIGFudGVubmEgY29uZmlnIGluIHBsYWNlLCB0aGVyZSBpcyBubyBh
ZmZlY3Qgb24gdGhlIG9yaWdpbmFsIGlzc3VlOiBjb25uZWN0aW5nIHRvIHdpZmkgc3RpbGwgYnJl
YWtzIHRoZSBibHVldG9vdGggc2NhbiBhZnRlciBhIHNob3J0IHdoaWxlLg0KDQpPbiBXZWQsIE1h
eSAxMywgMjAxNSBhdCAxOjUxIEFNLCDpmYjoibPokI0gPGNoYW1waW9uX2NoZW5AcmVhbHNpbC5j
b20uY24+IHdyb3RlOg0KPiBEZWFyIERhbmllbCwNCj4gUGxlYXNlIHRyeSB0byBjb21tZW50IHRo
ZSBmb2xsb3dpbmcgY29kZSBpbiB3aWZpIGRyaXZlciANCj4gaGFsYnRjODcyM2IyYW50X2FjdGlv
bl9idF9pbnF1aXJ5KCkNCj4gLyoNCj4gICAgICAgICAgICAgICAgIGNvZXhfZG0tPm5lZWRfcmVj
b3ZlcjB4OTQ4ID0gdHJ1ZTsNCj4gICAgICAgICAgICAgICAgIGNvZXhfZG0tPmJhY2t1cDB4OTQ4
ID0gDQo+IGJ0Y29leGlzdC0+YnRjX3JlYWRfNGJ5dGUoYnRjb2V4aXN0LCAweDk0OCk7DQo+DQo+
ICAgICAgICAgICAgICAgICBoYWxidGM4NzIzYjJhbnRfc2V0X2FudF9wYXRoKGJ0Y29leGlzdCwg
QlRDX0FOVF9XSUZJX0FUX0FVWCwgZmFsc2UsIGZhbHNlKTsNCj4gICAgICAgICAqLw0KDQpUaGlz
IGFsc28gbWFrZXMgbm8gZGlmZmVyZW5jZSwgdGhlIGlzc3VlIGlzIHN0aWxsIHRoZXJlLg0KDQpU
aGFua3MNCkRhbmllbA0K
Hi,
On Tue, May 12, 2015 at 8:36 PM, 陈艳萍 <[email protected]> wrote:
> Dear Daniel,
> For 8723BU, always use CONFIG_S0_ANTTENA；
> For 8723BE ， 1 antenna CONFIG_S1_ANTTENA; 2 antennas CONFIG_S0_ANTTENA
I tested with CONFIG_S0_ANTENNA as I am using a 8723BE with 2 antennas.
I believe this configuration is having no effect. I tested as follows:
Built kernel without rtlwifi support.
Booted.
Disconnected both antennas.
Moved remote bluetooth device 2 metres away.
Ran "hcitool scan" --> no results. Good.
Connected antenna 1. Scan --> remote device can be seen
Disconnected antenna 1, connected antenna 2. Scan --> remote device can be seen
I then tried with CONFIG_S1_ANTENNA and then again without doing the
S0/S1 antenna config at all. The results are always the same. It seems
like the bluetooth interface is always using both antennas (hence it
can work even if one of them is disconnected).
Also, even with this antenna config in place, there is no affect on
the original issue: connecting to wifi still breaks the bluetooth scan
after a short while.
On Wed, May 13, 2015 at 1:51 AM, 陈艳萍 <[email protected]> wrote:
> Dear Daniel,
> Please try to comment the following code in wifi driver halbtc8723b2ant_action_bt_inquiry()
> /*
> coex_dm->need_recover0x948 = true;
> coex_dm->backup0x948 = btcoexist->btc_read_4byte(btcoexist, 0x948);
>
> halbtc8723b2ant_set_ant_path(btcoexist, BTC_ANT_WIFI_AT_AUX, false, false);
> */
This also makes no difference, the issue is still there.
Thanks
Daniel
RGVhciBEYW5pZWwsDQoJRm9yICA4NzIzQlUsCSAgIGFsd2F5cyB1c2UgQ09ORklHX1MwX0FOVFRF
TkHvvJsNCglGb3IgIDg3MjNCRSDvvIwgMSBhbnRlbm5hIENPTkZJR19TMV9BTlRURU5BOyAyIGFu
dGVubmFzIENPTkZJR19TMF9BTlRURU5BDQoNCkRlYXIgIHNoYW9mdSwNCglXb3VsZCB5b3UgcGxl
YXNlIGhlbHAgdG8gY2hlY2sgd2l0aCBoYWxidGM4NzIzYjJhbnQuYyBidGNvZXhpc3QgZHJpdmVy
Pw0KDQotLS0tLemCruS7tuWOn+S7ti0tLS0tDQrlj5Hku7bkuro6IERhbmllbCBEcmFrZSBbbWFp
bHRvOmRyYWtlQGVuZGxlc3NtLmNvbV0gDQrlj5HpgIHml7bpl7Q6IDIwMTXlubQ15pyIMTLml6Ug
MjA6NTMNCuaUtuS7tuS6ujog6ZmI6Imz6JCNDQrmioTpgIE6IExhcnJ5IEZpbmdlcjsgQ2FybG8g
Q2Fpb25lOyBMaW51eCBCbHVldG9vdGggbWFpbGluZyBsaXN0OyBzaGFvZnVAcmVhbHRlay5jb20g
PiBzaGFvZnU7IOW8oOW/l+elpTsg6ZmG5pyx5LyfOyBDaGloLUhzaWFuZyBXYW5nOyDmr5vkuLrp
lIsNCuS4u+mimDogUmU6IOetlOWkjTogUmVhbHRlayBVU0IgYmx1ZXRvb3RoOiBubyBzY2FuIHJl
c3VsdHMgd2hlbiB3aWZpIGlzIGNvbm5lY3RlZA0KDQpIaSBDaGFtcGlvbiwNCg0KVGhhbmtzIGZv
ciB0aGUgc3VnZ2VzdGlvbi4NCg0KT24gTW9uLCBNYXkgMTEsIDIwMTUgYXQgODo1NCBQTSwg6ZmI
6Imz6JCNIDxjaGFtcGlvbl9jaGVuQHJlYWxzaWwuY29tLmNuPiB3cm90ZToNCj4gRGVhciBEYW5p
ZWwsDQo+ICAgICAgICAgRm9yIHNvbWUgcmVhc29uLCA4NzIzQiBjaGlwIHdpdGggc2luZ2xlIGFu
dGVubmEgYW5kIDIgYW50ZW5uYXMgaGF2ZSBkaWZmZXJlbnQgc2V0dGluZ3MgYW5kIHRoaXMgY2Fu
IG9ubHkgYmUgbW9kaWZpZWQgbWFudWFsbHkuDQo+IEJUIGRyaXZlciB3aWxsIHNldCBjb250cm9s
bGVyIHRvIHVzZSBTMCB3aGVuIHVzZSAyIGFudGVubmFzLg0KPiAgICAgICAgIEluIG15IHN1Ym1p
dHRlZCBkcml2ZXIgLCB0aGVyZSBhcmUgZm9sbG93aW5nIGNvZGVzIHRvIGFkZCB0aGUgY29uZmln
IHNldHRpbmdzIGF0IHRoZSBlbmQgb2YgZmlybXdhcmUgdG8gYmUgZG93bmxvYWRlZC4NCj4gV291
bGQgeW91IHBsZWFzZSB0cnkgdG8gYWRkIHRoZXNlIGNvZGVzIGFuZCB0ZXN0IGFnYWluPw0KPg0K
PiAvKmZvciA4NzIzQix1c2UgUzAgQW50dGVuYSBmb3IgYmx1ZXRvb3RoKi8NCj4gICAgICAgICBp
ZihsbXBfdmVyc2lvbj09Uk9NX0xNUF84NzIzQikNCj4gICAgICAgICB7DQo+ICAgICAgICAgICAg
ICAgICBtZW1jcHkoKmJ1ZitwYXRjaF9lbnRyeS0+cGF0Y2hfbGVuZ3RoLFJUS19DT05GSUdfU0lH
TkFUVVJFLDYpOw0KPiAgICAgICAgICAgICAgICAgaWYgKFVTRV9TMF9BTlRURU5BKQ0KPiAgICAg
ICAgICAgICAgICAgICAgICAgICBtZW1jcHkoKmJ1ZitwYXRjaF9lbnRyeS0+cGF0Y2hfbGVuZ3Ro
KzYsQ09ORklHX1MwX0FOVFRFTkEsNCk7DQo+ICAgICAgICAgICAgICAgICBlbHNlDQo+ICAgICAg
ICAgICAgICAgICAgICAgICAgIG1lbWNweSgqYnVmK3BhdGNoX2VudHJ5LT5wYXRjaF9sZW5ndGgr
NixDT05GSUdfUzFfQU5UVEVOQSw0KTsNCj4gICAgICAgICAgICAgICAgICpidWZfbGVuICs9IDEw
Ow0KPiAgICAgICAgICAgICAgICAgQlRfREJHKCJVU0VfUzBfQU5UVEVOQSIpOw0KPiAgICAgICAg
IH0NCg0KWWVzLCBJIHNhdyB0aGlzIGNvZGUgYWxyZWFkeSBhbmQgZXhwZXJpbWVudGVkIHdpdGgg
aXQuIEl0IGRpZG4ndCBzZWVtIHRvIG1ha2UgYW55IGRpZmZlcmVuY2UuIEknbGwgdHJ5IGFnYWlu
IHRob3VnaCwgd2hpY2ggY29uZmlndXJhdGlvbiBzaG91bGQgSSB1c2UsIENPTkZJR19TMF9BTlRU
RU5BIG9yIENPTkZJR19TMV9BTlRURU5BPw0KDQpCeSBvbmx5IGNvbm5lY3Rpbmcgb25lIGFudGVu
bmEgYXQgYSB0aW1lLCBJIHdhcyBhYmxlIHRvIHNlZSB0aGF0IGJsdWV0b290aCBoYXBwaWx5IHVz
ZXMgZWl0aGVyIG9uZS4gSSBoYXZlIGEgZmVlbGluZyB0aGF0IHRoZSBwcmVmZXJlbmNlIHlvdSB3
cml0ZSBhYm92ZSBpcyBvdmVycmlkZGVuIGJ5IGNvZGUgaW4gdGhlIGhhbGJ0Yzg3MjNiMmFudC5j
IGJ0Y29leGlzdCBkcml2ZXIuDQoNCkRhbmllbA0K
Hi Champion,
Thanks for the suggestion.
On Mon, May 11, 2015 at 8:54 PM, 陈艳萍 <[email protected]> wrote:
> Dear Daniel,
> For some reason, 8723B chip with single antenna and 2 antennas have different settings and this can only be modified manually.
> BT driver will set controller to use S0 when use 2 antennas.
> In my submitted driver , there are following codes to add the config settings at the end of firmware to be downloaded.
> Would you please try to add these codes and test again?
>
> /*for 8723B,use S0 Anttena for bluetooth*/
> if(lmp_version==ROM_LMP_8723B)
> {
> memcpy(*buf+patch_entry->patch_length,RTK_CONFIG_SIGNATURE,6);
> if (USE_S0_ANTTENA)
> memcpy(*buf+patch_entry->patch_length+6,CONFIG_S0_ANTTENA,4);
> else
> memcpy(*buf+patch_entry->patch_length+6,CONFIG_S1_ANTTENA,4);
> *buf_len += 10;
> BT_DBG("USE_S0_ANTTENA");
> }
Yes, I saw this code already and experimented with it. It didn't seem
to make any difference. I'll try again though, which configuration
should I use, CONFIG_S0_ANTTENA or CONFIG_S1_ANTTENA?
By only connecting one antenna at a time, I was able to see that
bluetooth happily uses either one. I have a feeling that the
preference you write above is overridden by code in the
halbtc8723b2ant.c btcoexist driver.
Daniel
Dear Daniel,
For some reason, 8723B chip with single antenna and 2 antennas have different settings and this can only be modified manually.
BT driver will set controller to use S0 when use 2 antennas.
In my submitted driver , there are following codes to add the config settings at the end of firmware to be downloaded.
Would you please try to add these codes and test again?
/*for 8723B,use S0 Anttena for bluetooth*/
if(lmp_version==ROM_LMP_8723B)
{
memcpy(*buf+patch_entry->patch_length,RTK_CONFIG_SIGNATURE,6);
if (USE_S0_ANTTENA)
memcpy(*buf+patch_entry->patch_length+6,CONFIG_S0_ANTTENA,4);
else
memcpy(*buf+patch_entry->patch_length+6,CONFIG_S1_ANTTENA,4);
*buf_len += 10;
BT_DBG("USE_S0_ANTTENA");
}
-----邮件原件-----
发件人: Larry Finger [mailto:[email protected]] 代表 Larry Finger
发送时间: 2015年5月10日 5:47
收件人: Daniel Drake; 陈艳萍
抄送: Carlo Caione; Linux Bluetooth mailing list; [email protected] > shaofu
主题: Re: Realtek USB bluetooth: no scan results when wifi is connected
On 05/09/2015 03:32 PM, Daniel Drake wrote:
> Hi Champion,
>
> I have a card here which has RTL8723BE wifi and bluetooth combined. 2 antennas.
>
> In linux-next (Linux 4.2) the bluetooth and wifi work fine separately,
> but when using them together, I can sometimes see a problem. This is
> using the btusb driver based on your code (now included in Linux 4.2),
> and the RTL8723B rtlwifi driver, all using the latest firmware in the
> linux-firmware git repo.
>
> To reproduce:
> - Boot with no wifi connection active
> - "hcitool scan" and verify that my laptop and phone can be seen
> - Connect to wifi
> - Run "hcitool scan" again a few times a minute, within 2-5 minutes
> normally my phone and laptop can no longer be seen
> - Disconnect from wifi and immediately run "hcitool scan" again, my
> phone and laptop can be seen
>
> 3 interesting observations when the scan results are coming back empty:
> 1. I can still get the names of the remote devices by running
> "hcitool name <addr>"
> 2. I can still query the remote devices by running "hcitool info
> <addr>". After this, the scan suddenly starts working again!
> 3. Even though both of my local bluetooth devices no longer appear
> in scan results, I can sometimes see my neighbour's phone coming up as
> a scan result at this time.
>
> Anyway, disabling btcoexist avoids the issue, so I dug through that
> code, and found the exact line of code that seems to (sometimes) make
> us enter this strange mode.
>
> Call chain inside drivers/net/wireless/rtlwifi/btcoexist/halbtc8723b2ant.c:
> ex_btc8723b2ant_bt_info_notify (called when starting and finishing a
> BT scan) btc8723b2ant_run_coexist_mechanism
> btc8723b2ant_action_bt_inquiry
>
> As wifi is connected, we now call:
> btc8723b2ant_ps_tdma(btcoexist, NORMAL_EXEC, true, 3);
>
> This is the function call that sometimes puts us into the mode where
> there are no scan results. Inside this function, if I comment out
> these lines in the turn_on section, the bug is avoided:
>
> case 3:
> //btc8723b2ant_set_fw_ps_tdma(btcoexist, 0xe3, 0x1c,
> // 0x3, 0xf1, 0x90);
> break;
>
> Any idea what is happening here? Can you help me find a better fix?
Daniel,
Do you see any adverse side effects when you comment out the "case 3" code?
As there has not been a lot of testing of wifi and BT with Realtek devices in the field, I expect to see a number of bugs like this.
I added Shao Fu (aka Rock) to the Cc list. He is the Realtek engineer responsible for the wifi driver.
Larry
On 05/11/2015 08:36 AM, Daniel Drake wrote:
> Hi Larry,
>
> On Sat, May 9, 2015 at 3:46 PM, Larry Finger <[email protected]> wrote:
>> Do you see any adverse side effects when you comment out the "case 3" code?
>
> No, it fixes the scan results issue and I also tested a simultaneous
> download over wifi while sending a file over bluetooth. Seems to be
> working fine.
OK. As I know you are busy, I will submit the patch to
[email protected] for you.
Larry
Hi Larry,
On Sat, May 9, 2015 at 3:46 PM, Larry Finger <[email protected]> wrote:
> Do you see any adverse side effects when you comment out the "case 3" code?
No, it fixes the scan results issue and I also tested a simultaneous
download over wifi while sending a file over bluetooth. Seems to be
working fine.
Daniel
On 05/09/2015 03:32 PM, Daniel Drake wrote:
> Hi Champion,
>
> I have a card here which has RTL8723BE wifi and bluetooth combined. 2 antennas.
>
> In linux-next (Linux 4.2) the bluetooth and wifi work fine separately,
> but when using them together, I can sometimes see a problem. This is
> using the btusb driver based on your code (now included in Linux 4.2),
> and the RTL8723B rtlwifi driver, all using the latest firmware in the
> linux-firmware git repo.
>
> To reproduce:
> - Boot with no wifi connection active
> - "hcitool scan" and verify that my laptop and phone can be seen
> - Connect to wifi
> - Run "hcitool scan" again a few times a minute, within 2-5 minutes
> normally my phone and laptop can no longer be seen
> - Disconnect from wifi and immediately run "hcitool scan" again, my
> phone and laptop can be seen
>
> 3 interesting observations when the scan results are coming back empty:
> 1. I can still get the names of the remote devices by running
> "hcitool name <addr>"
> 2. I can still query the remote devices by running "hcitool info
> <addr>". After this, the scan suddenly starts working again!
> 3. Even though both of my local bluetooth devices no longer appear in
> scan results, I can sometimes see my neighbour's phone coming up as a
> scan result at this time.
>
> Anyway, disabling btcoexist avoids the issue, so I dug through that
> code, and found the exact line of code that seems to (sometimes) make
> us enter this strange mode.
>
> Call chain inside drivers/net/wireless/rtlwifi/btcoexist/halbtc8723b2ant.c:
> ex_btc8723b2ant_bt_info_notify (called when starting and finishing a BT scan)
> btc8723b2ant_run_coexist_mechanism
> btc8723b2ant_action_bt_inquiry
>
> As wifi is connected, we now call:
> btc8723b2ant_ps_tdma(btcoexist, NORMAL_EXEC, true, 3);
>
> This is the function call that sometimes puts us into the mode where
> there are no scan results. Inside this function, if I comment out
> these lines in the turn_on section, the bug is avoided:
>
> case 3:
> //btc8723b2ant_set_fw_ps_tdma(btcoexist, 0xe3, 0x1c,
> // 0x3, 0xf1, 0x90);
> break;
>
> Any idea what is happening here? Can you help me find a better fix?
Daniel,
Do you see any adverse side effects when you comment out the "case 3" code?
As there has not been a lot of testing of wifi and BT with Realtek devices in
the field, I expect to see a number of bugs like this.
I added Shao Fu (aka Rock) to the Cc list. He is the Realtek engineer
responsible for the wifi driver.
Larry
Hi Larry,
>>>>> We want to share some information between wifi driver and bt driver, what rules do you recommend for the following situation ?
>>>>> 1. at system startup, bluetooth driver want to read some information (eg antenna settings) that generated by wifi , shall we use files or /proc/ information?
>>>>> 2. when user is using Bluetooth, bt driver may notify wifi driver to perform better, shall we use socket to communication?
>>>>
>>>> this is the Bluetooth subsystem communicating with the WiFi subsystem (cfg80211) and vice versa, then this is happening inside the kernel. I do not see any need to even try to go via userspace at all. So neither /proc and no sockets for this.
>>>
>>> I agree. But can we give more specific advice on how to do this inside
>>> the kernel?
>>> i.e. should they create a new driver under drivers/misc which exposes
>>> a shared API via EXPORT_SYMBOL?
>>
>> I was actually thinking about creating a rfres subsystem where each radio subsystem can register their antenna and channel information. That why WiFi does not depend on Bluetooth or that Bluetooth depend on WiFi. This cross dependency is something I like to avoid.
>>
>> And with rfres subsystem in place, each subsystem could also register for notification and adapt its radio usage if possible. Keep in mind that we support multiple Bluetooth and WiFi cards in the system. So this all needs to be fully generic.
>>
>>> The other option for Realtek to consider is to do this in
>>> hardware/firmware. I already saw that the btcoexist driver knows
>>> exactly when the wifi and BT start and finish scanning, so there is
>>> clearly already an information-passing mechanism between the two
>>> interfaces. I wonder if an updated firmware could extend that to
>>> include the new information that you wish to additionally transfer.
>>
>> That is another option and a lot of companies have chosen to do this. If this is a card that has WiFi and Bluetooth on the same hardware, then normally an internal bus exists for communicating coexistence information out-of-band. That is what we are expecting in a lot of cases to happen when looking at platforms.
>>
>> Of course rfres will be hardly do a better job then the internal communication between the WiFi and Bluetooth parts on the same chip. It can only help when the two pieces are independent or when you have more than one of each installed.
>
> I do not know much about the internal structure of the Realtek devices, and I have no idea if the two parts can communicate over an internal bus. For that reason, I have added Shaofu, the lead engineer on the PCIe wifi driver.
>
> Is there a time frame for rfres? Although it might not do a better job in all cases, its generality will be useful.
there is no timeframe on rfres. It is something we clearly want, but I have not yet started working on it.
Regards
Marcel
Hi Shaofu,
please do not top-post on this mailing list.
> As Marcel said, some Realtek WiFi + BT solution are two chips solution.
> - 1 chip solution: 8723BE, 8821AE
> - 2 chips solution: 8812AE + 8761AU, 8192EE + 8761AU
>
> Even in 2 chips solution, there are some difference:
> - Hardware connected in module: 8192EE + 8761AU
> - Independent, need SW involved, even in the same module: 8812AE + 8761AU
>
> In 1 chip or hardware connected solution, both driver don't need communicate,
> BTcoex driver knows everything via HW event, and control everything it wants.
>
> In 2 chips and independent solution, yes, its our problem. In this case, we need
> some communication mechanism between drivers. The rfres subsystem seems
> good, but it takes time. If other simple methods can do, please tell us.
there is no simple method. You need to retrieve the current WiFi channels in use from the WiFi subsystem and handle the update of the AFH channel based on that.
Regards
Marcel