Hi Marcel, > -----Original Message----- > From: Marcel Holtmann [mailto:marcel@xxxxxxxxxxxx] > Sent: Thursday, September 01, 2011 4:22 AM > 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. > > Regards > > Marcel > Thanks. Regarding SCO and Inquiry status, do we have an existing API in Bluetooth core that I can use to get that information? Regards Suraj ��.n��������+%������w��{.n�����{���zW����ܨ}���Ơz�j:+v�����w����ޙ��&�)ߡ�a����z�ޗ���ݢj��w�f
