From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from s3.sipsolutions.net ([2a01:4f8:190:3424::2] helo=sipsolutions.net) by bombadil.infradead.org with esmtps (Exim 4.87 #1 (Red Hat Linux)) id 1cyYJQ-000062-0q for ath10k@lists.infradead.org; Thu, 13 Apr 2017 06:33:02 +0000 Message-ID: <1492065153.28255.1.camel@sipsolutions.net> Subject: Re: [PATCHv4 0/2] cfg80211: mac80211: BTCOEX feature support From: Johannes Berg Date: Thu, 13 Apr 2017 08:32:33 +0200 In-Reply-To: References: <1491905730-16392-1-git-send-email-c_traja@qti.qualcomm.com> <50d867d1-740c-85b9-2bab-6ef49c4d87c1@broadcom.com> Mime-Version: 1.0 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "ath10k" Errors-To: ath10k-bounces+kvalo=adurom.com@lists.infradead.org To: Tamizh Chelvam Raja , Arend Van Spriel , "linux-wireless@vger.kernel.org" Cc: "linux-bluetooth@vger.kernel.org" , Marcel Holtmann , "tamizhchelvam@codeaurora.org" , "ath10k@lists.infradead.org" On Wed, 2017-04-12 at 07:08 +0000, Tamizh Chelvam Raja wrote: > > > > So you make a distinction between WMM ACs, but what about the > > different > > types/profiles of BT traffic? > > > > [Tamizh] There will be BT high and BT low traffic. It will be decided > by BT module. Firmware internally checks BT low traffic with wlan > traffic. If we enable some of wlan frames as high priority, those > frames will have more priority than BT low traffic. That ("firmware internally..." etc.) really sounds more like an argument *not* to apply this patch ... Everyone has their favourite BT coex control. We could possibly implement this in our driver, but I'm not sure we'd *want* to, since it's so far from what we actually do today. Do we really need more than toggling it on/off? Actually, I probably should've asked this much earlier - but what use cases do you see for this? What can a user, or userspace application like NM, really try to set here? It seems the use cases for this would be rather constrained? johannes _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Message-ID: <1492065153.28255.1.camel@sipsolutions.net> Subject: Re: [PATCHv4 0/2] cfg80211: mac80211: BTCOEX feature support From: Johannes Berg To: Tamizh Chelvam Raja , Arend Van Spriel , "linux-wireless@vger.kernel.org" Cc: "ath10k@lists.infradead.org" , "tamizhchelvam@codeaurora.org" , "linux-bluetooth@vger.kernel.org" , Marcel Holtmann Date: Thu, 13 Apr 2017 08:32:33 +0200 In-Reply-To: References: <1491905730-16392-1-git-send-email-c_traja@qti.qualcomm.com> <50d867d1-740c-85b9-2bab-6ef49c4d87c1@broadcom.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 List-ID: On Wed, 2017-04-12 at 07:08 +0000, Tamizh Chelvam Raja wrote: > > > > So you make a distinction between WMM ACs, but what about the > > different > > types/profiles of BT traffic? > > > > [Tamizh] There will be BT high and BT low traffic. It will be decided > by BT module. Firmware internally checks BT low traffic with wlan > traffic. If we enable some of wlan frames as high priority, those > frames will have more priority than BT low traffic. That ("firmware internally..." etc.) really sounds more like an argument *not* to apply this patch ... Everyone has their favourite BT coex control. We could possibly implement this in our driver, but I'm not sure we'd *want* to, since it's so far from what we actually do today. Do we really need more than toggling it on/off? Actually, I probably should've asked this much earlier - but what use cases do you see for this? What can a user, or userspace application like NM, really try to set here? It seems the use cases for this would be rather constrained? johannes