+ Marcel
On 3/2/2018 6:14 AM, Kalle Valo wrote:
> Arend van Spriel <[email protected]> writes:
>
>> On 3/1/2018 6:59 PM, Tamizh chelvam wrote:
>>> From: Tamizh chelvam <[email protected]>
>>>
>>> This patch introduces NL80211_CMD_SET_BTCOEX command and
>>> NL80211_ATTR_BTCOEX_OP attribute to enable or disable btcoex.
>>
>> What kind of btcoex are we talking about here? Is it signalling
>> between wlan and bt to get access to the shared RF.
>
> Yes, at least that's how I understand this.
>
>> Why would it require user-space interaction? Are there no options for
>> wlan to detect bt is in use, ie. bt hci is setup, and vice versa. Can
>> it be indicated in platform data or device tree. Trying to understand
>> the use-case here.
>
> One use case is being able to disable btcoex in case of problems or to
> test if it's btcoex related. I think during the last five years the need
> for this interface has come every once in a while.
Well, you would want to disable btcoex *and* bt to verify wlan is
working properly on its own. And similarly disable btcoex *and* wlan to
verify bt works properly.
Now I do recall a thread between you and Marcel. Looked it up and it was
this thread [1], but did not see a follow-up on it. I suspect it
involves more than just an enable/disable state. That may be fine for
devices in which BT and WLAN are integrated and coordination of RF use
is done on the device. The "btcoex subsystem" thread seems to aim for
more like providing the coordination logic so independent BT device and
WLAN device can still use the same RF. So before adopting the api in
nl80211 it would be good to revive that thread.
Regards,
Arend
[1] https://www.spinics.net/lists/linux-wireless/msg133333.html
Arend van Spriel <[email protected]> writes:
> + Marcel
>
> On 3/2/2018 6:14 AM, Kalle Valo wrote:
>> Arend van Spriel <[email protected]> writes:
>>
>>> On 3/1/2018 6:59 PM, Tamizh chelvam wrote:
>>>> From: Tamizh chelvam <[email protected]>
>>>>
>>>> This patch introduces NL80211_CMD_SET_BTCOEX command and
>>>> NL80211_ATTR_BTCOEX_OP attribute to enable or disable btcoex.
>>>
>>> What kind of btcoex are we talking about here? Is it signalling
>>> between wlan and bt to get access to the shared RF.
>>
>> Yes, at least that's how I understand this.
>>
>>> Why would it require user-space interaction? Are there no options for
>>> wlan to detect bt is in use, ie. bt hci is setup, and vice versa. Can
>>> it be indicated in platform data or device tree. Trying to understand
>>> the use-case here.
>>
>> One use case is being able to disable btcoex in case of problems or to
>> test if it's btcoex related. I think during the last five years the need
>> for this interface has come every once in a while.
>
> Well, you would want to disable btcoex *and* bt to verify wlan is
> working properly on its own. And similarly disable btcoex *and* wlan
> to verify bt works properly.
Sure. But my main motiviation with this is to replace the module
parameters we already have:
drivers/net/wireless/ath/ath9k/htc_drv_init.c:module_param_named(btcoex_enable, ath9k_htc_btcoex_enable, int, 0444);
drivers/net/wireless/ath/ath9k/htc_drv_init.c:MODULE_PARM_DESC(btcoex_enable, "Enable wifi-BT coexistence");
drivers/net/wireless/ath/ath9k/init.c:module_param_named(btcoex_enable, ath9k_btcoex_enable, int, 0444);
drivers/net/wireless/ath/ath9k/init.c:MODULE_PARM_DESC(btcoex_enable, "Enable wifi-BT coexistence");
drivers/net/wireless/broadcom/b43/main.c:module_param_named(btcoex, modparam_btcoex, int, 0444);
drivers/net/wireless/broadcom/b43/main.c:MODULE_PARM_DESC(btcoex, "Enable Bluetooth coexistence (default on)");
But looking closely in ath9k cases it doesn't actually sound doable as
IIRC the ath9k module parameters are off by default. In b43 it's enabled
by default, though.
> Now I do recall a thread between you and Marcel. Looked it up and it
> was this thread [1], but did not see a follow-up on it. I suspect it
> involves more than just an enable/disable state. That may be fine for
> devices in which BT and WLAN are integrated and coordination of RF use
> is done on the device. The "btcoex subsystem" thread seems to aim for
> more like providing the coordination logic so independent BT device
> and WLAN device can still use the same RF. So before adopting the api
> in nl80211 it would be good to revive that thread.
I think that "btcoex subsystem" is a holy grail which will be never
implemented :) But who knows, miracles can happen...
--
Kalle Valo
On 3/2/2018 10:59 AM, Marcel Holtmann wrote:
> Hi Arend,
>
>>>>> This patch introduces NL80211_CMD_SET_BTCOEX command and
>>>>> NL80211_ATTR_BTCOEX_OP attribute to enable or disable btcoex.
>>>>
>>>> What kind of btcoex are we talking about here? Is it signalling
>>>> between wlan and bt to get access to the shared RF.
>>>
>>> Yes, at least that's how I understand this.
>>>
>>>> Why would it require user-space interaction? Are there no options for
>>>> wlan to detect bt is in use, ie. bt hci is setup, and vice versa. Can
>>>> it be indicated in platform data or device tree. Trying to understand
>>>> the use-case here.
>>>
>>> One use case is being able to disable btcoex in case of problems or to
>>> test if it's btcoex related. I think during the last five years the need
>>> for this interface has come every once in a while.
>>
>> Well, you would want to disable btcoex *and* bt to verify wlan is working properly on its own. And similarly disable btcoex *and* wlan to verify bt works properly.
>>
>> Now I do recall a thread between you and Marcel. Looked it up and it was this thread [1], but did not see a follow-up on it. I suspect it involves more than just an enable/disable state. That may be fine for devices in which BT and WLAN are integrated and coordination of RF use is done on the device. The "btcoex subsystem" thread seems to aim for more like providing the coordination logic so independent BT device and WLAN device can still use the same RF. So before adopting the api in nl80211 it would be good to revive that thread.
>
> actually we can solve any number of WiFi devices vs any number of Bluetooth devices on the same host. It goes mainly in the direction of WiFi having a notifier about its currently used channels and Bluetooth subsystem can subscribe to these and issue AFH channel map classification updates as needed.
I see. From this I would say the notifier functionality would sit nicely
in cfg80211.
> The other way around for the Bluetooth audio cases and a shared antenna, you need a tighter integration. If the antenna is not shared, then it makes no difference anyway since you are not sharing the transceiver. Normally these are just handled by the firmware internally and right priorities for RF scheduling are done. The Bluetooth controller normally then does a bit too much, but nobody wants to implement that in the host cleanly, and so they all hack it into the controller. I think that Realtek has some older chips where it would be really needed in the host. And Intel controllers can also let the host do it, but by default it is magically done by the controller.
Not entirely sure what you mean by "does a bit too much", but this is
what I considered as being btcoex. Indeed most do the whole coordination
in the device and not on the host. Pretty sure about Broadcom ;-)
Regards,
Arend
Hi Arend,
>>>> This patch introduces NL80211_CMD_SET_BTCOEX command and
>>>> NL80211_ATTR_BTCOEX_OP attribute to enable or disable btcoex.
>>>
>>> What kind of btcoex are we talking about here? Is it signalling
>>> between wlan and bt to get access to the shared RF.
>>
>> Yes, at least that's how I understand this.
>>
>>> Why would it require user-space interaction? Are there no options for
>>> wlan to detect bt is in use, ie. bt hci is setup, and vice versa. Can
>>> it be indicated in platform data or device tree. Trying to understand
>>> the use-case here.
>>
>> One use case is being able to disable btcoex in case of problems or to
>> test if it's btcoex related. I think during the last five years the need
>> for this interface has come every once in a while.
>
> Well, you would want to disable btcoex *and* bt to verify wlan is working properly on its own. And similarly disable btcoex *and* wlan to verify bt works properly.
>
> Now I do recall a thread between you and Marcel. Looked it up and it was this thread [1], but did not see a follow-up on it. I suspect it involves more than just an enable/disable state. That may be fine for devices in which BT and WLAN are integrated and coordination of RF use is done on the device. The "btcoex subsystem" thread seems to aim for more like providing the coordination logic so independent BT device and WLAN device can still use the same RF. So before adopting the api in nl80211 it would be good to revive that thread.
actually we can solve any number of WiFi devices vs any number of Bluetooth devices on the same host. It goes mainly in the direction of WiFi having a notifier about its currently used channels and Bluetooth subsystem can subscribe to these and issue AFH channel map classification updates as needed.
The other way around for the Bluetooth audio cases and a shared antenna, you need a tighter integration. If the antenna is not shared, then it makes no difference anyway since you are not sharing the transceiver. Normally these are just handled by the firmware internally and right priorities for RF scheduling are done. The Bluetooth controller normally then does a bit too much, but nobody wants to implement that in the host cleanly, and so they all hack it into the controller. I think that Realtek has some older chips where it would be really needed in the host. And Intel controllers can also let the host do it, but by default it is magically done by the controller.
Regards
Marcel