Return-Path: Subject: RE: [PATCH] Bluetooth: Support SCO over HCI for Atheros AR300x Bluetooth device From: Marcel Holtmann To: "Sumangala, Suraj" Cc: "Gustavo F. Padovan" , "linux-bluetooth@vger.kernel.org" , "Somi Ramasamy Mothilal, JothiKumar" Date: Mon, 30 May 2011 22:16:32 -0700 In-Reply-To: <480687D4EEFE7447A2E09AADFF66736204992145@nasanexd02c.na.qualcomm.com> References: <1305878771-26464-1-git-send-email-suraj@atheros.com> ,<20110530190213.GC2556@joana> <480687D4EEFE7447A2E09AADFF66736204992145@nasanexd02c.na.qualcomm.com> Content-Type: text/plain; charset="UTF-8" Message-ID: <1306818995.2060.8.camel@aeonflux> Mime-Version: 1.0 Sender: linux-bluetooth-owner@vger.kernel.org List-ID: Hi Suraj, > * Suraj Sumangala [2011-05-20 13:36:11 +0530]: > > > This patch adds SCO over HCI support to Atheros AR300x HCI transport > > driver. > > > > Signed-off-by: Suraj Sumangala > > --- > > drivers/bluetooth/hci_ath.c | 14 +++++++------- > > 1 files changed, 7 insertions(+), 7 deletions(-) > > > > diff --git a/drivers/bluetooth/hci_ath.c b/drivers/bluetooth/hci_ath.c > > index 4093935..8e15c31 100644 > > --- a/drivers/bluetooth/hci_ath.c > > +++ b/drivers/bluetooth/hci_ath.c > > @@ -162,11 +162,6 @@ static int ath_enqueue(struct hci_uart *hu, struct sk_buff *skb) > > { > > struct ath_struct *ath = hu->priv; > > > > - if (bt_cb(skb)->pkt_type == HCI_SCODATA_PKT) { > > - kfree_skb(skb); > > - return 0; > > - } > > - > > /* > > * Update power management enable flag with parameters of > > * HCI sleep enable vendor specific HCI command. > > @@ -184,9 +179,14 @@ static int ath_enqueue(struct hci_uart *hu, struct sk_buff *skb) > > memcpy(skb_push(skb, 1), &bt_cb(skb)->pkt_type, 1); > > > > skb_queue_tail(&ath->txq, skb); > > - set_bit(HCI_UART_SENDING, &hu->tx_state); > > > > - schedule_work(&ath->ctxtsw); > > + if (bt_cb(skb)->pkt_type == HCI_SCODATA_PKT) { > > + clear_bit(HCI_UART_SENDING, &hu->tx_state); > > + hci_uart_tx_wakeup(hu); > > We can't do that, prioritize SCO over HCI Events. This can lead to weird sync > problems, so please remove this and send me a new patch. > > The reason why I went with this approach was > 1. In the schedule_work path, we were doing some power management logic which was relevent only for ACL packets. > 2. Without this somehow the SCO audio quality was bad and the controller team mention that they were not getting SCO packets in this rate. you might actually have to re-design your driver then. Since essentially you need to ensure that events like HCI_Conn_Complete arrive in the proper order to make sure that ACL and SCO handles are properly available before ACL or SCO packets are send. This has been always the problem. Especially with USB endpoints where SCO packets and ACL packets are on different endpoints. Getting the order right is pretty tricky. In addition you have the completed packet events that need to be handled properly. Otherwise you might screw up the flow control. Regards Marcel