Hi Marcel, > -----Original Message----- > From: Marcel Holtmann [mailto:marcel@xxxxxxxxxxxx] > Sent: Thursday, September 01, 2011 5:13 PM > To: Sumangala, Suraj > Cc: Johannes Berg; linville@xxxxxxxxxxxxx; ath6kl-devel; Balasubramanian, > senthilkumar; Mehta, Vipin; Valo, Kalle; linux-wireless@xxxxxxxxxxxxxxx > Subject: RE: [RFC] nl80211: Added NL80211 commands for Bluetooth-WiFi coex > > Hi Suraj, > > > > > > this looks like the total wrong approach to me. This needs to be > > > > > done > > > between mac80211 and Bluetooth subsystems in the kernel directly. > > > Going through userspace for this is a pretty bad idea. > > > > > > > > > Especially if you wanna listen on D-Bus events from bluetoothd > > > > > and then run > > > another process to then execute nl80211 commands looks like total > > > overhead at no gain. Not to talk about potential latency > effects > > > that might be counterproductive. > > > > > > > > > What you really want is a way to mark A2DP channels for > > > > > streaming from > > > userspace as streaming/realtime/priority so the Bluetooth subsystem > > > knows on what to do with it and that way can also tell > > mac80211 > > > correctly about coex settings. > > > > > > > > > We are already settings flushable flags for A2DP streaming > > > > > channels and there > > > is work ongoing for SO_PRIORITY support with L2CAP sockets. > > > > > > > > More than the A2DP connection, it would be more useful to find out > > > > when > > > A2DP start/stop streaming so that we can know when to reallocate > > > resource to Bluetooth. Is it possible to tap this information out of the > Bluetooth core? > > > > Also, can you suggest a way to get A2DP streaming status, inquiry > > > > status, and > > > SCO and ACL role without a hack in the Bluetooth subsystem? > > > > > > the inquiry status is tracked by the Linux kernel since ever. Same > > > goes for ACL and SCO status. The kernel keeps track over almost > > > everything on the HCI level and will do proper cleanup afterwards. Doing this > in userspace will not work out. > > > And it is also racy. > > > > > > Especially in the future bluetoothd will be tracking less and less > > > information. The new management interface will hide almost every > > > single state from bluetoothd where the kernel is doing the job > > > anyway and can do a way better job in the first place. This is also > > > leads to power consumption advantages since bluetoothd does not need > > > to be woken up that often anyway. And in addition the kernel has not deal > with the extra HCI filter handling. > > > > > > The only thing that you mentioned here is A2DP streaming. And by the > > > nature of the A2DP protocol, you do establish a second L2CAP channel > > > that is just used for streaming. That channel is also only present > > > if you are streaming right now. If not streaming is going on, it > > > will be disconnected. So it is pretty easy to have bluetoothd tag > > > such a channel with proper SO_PRIORITY (once we have that code > > > merged upstream) and then the Bluetooth subsystem knows when A2DP > streaming or any high priority/realtime data is transferred over Bluetooth. > > > > Regarding SCO and Inquiry status, do we have an existing API in Bluetooth core > that I can use to get that information? > > there is obviously no exported symbols or anything alike. Since we only export > things that are used by drivers or other subsystem. So you would need to create > such an API. > > However first we need to establish in which direction this should be done > anyway. Should the Bluetooth subsystem notify mac80211 unconditional or > should mac80211 register notifiers of the Bluetooth subsystem. > > We also should not forget direct integration support for changing AFH channel > maps based on the used WiFi channels. > > Regards > > Marcel > If we can provide "hci_dev" as the handle to the Bluetooth core, does it make sense to follow the below steps to send channel classification? 1. Implement an NL80211 command to provide the Bluetooth BDADDR. 2. Send it down to the WiFi driver via a cfg80211 API. 3. Let it call "hci_get_route" to get a hci_hdev handle. 4. Export an API to set channel classification in Bluetooth HCI core. 5. Let the WiFi driver form the channel classification and call the Bluetooth core "write channel classification" API to set the channels. Regards Suraj ��.n��������+%������w��{.n�����{��� �^n�r������&��z�ޗ�zf���h���~����������_��+v���)ߣ�
