All of lore.kernel.org
 help / color / mirror / Atom feed
From: Balakrishna Godavarthi <bgodavar@codeaurora.org>
To: Matthias Kaehlcke <mka@chromium.org>
Cc: marcel@holtmann.org, johan.hedberg@gmail.com,
	linux-kernel@vger.kernel.org, linux-bluetooth@vger.kernel.org,
	hemantg@codeaurora.org, linux-arm-msm@vger.kernel.org
Subject: Re: [PATCH v2 3/3] Bluetooth: hci_qca: Fix frame reassembly errors for wcn3990
Date: Tue, 27 Nov 2018 12:31:05 +0530	[thread overview]
Message-ID: <7453751357b0708af05c1ff3de8f1a2d@codeaurora.org> (raw)
In-Reply-To: <20181127002744.GZ22824@google.com>

Hi Matthias,

On 2018-11-27 05:57, Matthias Kaehlcke wrote:
> On Mon, Nov 26, 2018 at 04:09:50PM -0800, Matthias Kaehlcke wrote:
>> On Thu, Nov 22, 2018 at 05:45:12PM +0530, Balakrishna Godavarthi 
>> wrote:
>> > During initalization of wcn3990, we observed UART is reading some
>> > stray bytes on the Rx line. This is logging Frame reassembly errors
>> > on the serial console. This could be because of tristate of Tx line
>> > of wcn3990 during boot up.
>> >
>> > [  176.929612] Bluetooth: hci_qca.c:qca_recv() hci0: Frame reassembly failed (-84)
>> > [  176.945734] Bluetooth: hci_qca.c:qca_recv() hci0: Frame reassembly failed (-84)
>> > [  176.953298] Bluetooth: hci_qca.c:qca_recv() hci0: Frame reassembly failed (-84)
>> > [  177.010660] Bluetooth: hci_qca.c:qca_recv() hci0: Frame reassembly failed (-84)
>> > [  177.067633] Bluetooth: hci_qca.c:qca_recv() hci0: Frame reassembly failed (-84)
>> >
>> > Now we enable a flag during bootup to stop executing proto receive
>> > function and clear it back once the initialization is done.
>> >
>> > Signed-off-by: Balakrishna Godavarthi <bgodavar@codeaurora.org>
>> > Tested-by: Matthias Kaehlcke <mka@chromium.org>
>> > ---
>> > v2:
>> >  * Updated commit text & comments.
>> > v1:
>> >  * initial patch
>> > ---
>> >  drivers/bluetooth/hci_qca.c | 18 ++++++++++++++++++
>> >  1 file changed, 18 insertions(+)
>> >
>> > diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c
>> > index ed905ea1c58a..2f3d9e16ba5a 100644
>> > --- a/drivers/bluetooth/hci_qca.c
>> > +++ b/drivers/bluetooth/hci_qca.c
>> > @@ -56,6 +56,7 @@
>> >
>> >  /* Controller states */
>> >  #define STATE_IN_BAND_SLEEP_ENABLED	1
>> > +#define STATE_DISCARD_RX		2
>> >
>> >  #define IBS_WAKE_RETRANS_TIMEOUT_MS	100
>> >  #define IBS_TX_IDLE_TIMEOUT_MS		2000
>> > @@ -511,6 +512,7 @@ static int qca_open(struct hci_uart *hu)
>> >  		} else {
>> >  			hu->init_speed = qcadev->init_speed;
>> >  			hu->oper_speed = qcadev->oper_speed;
>> > +			set_bit(STATE_DISCARD_RX, &qca->flags);
>> >  			ret = qca_power_setup(hu, true);
>> >  			if (ret) {
>> >  				destroy_workqueue(qca->workqueue);
>> > @@ -903,6 +905,13 @@ static int qca_recv(struct hci_uart *hu, const void *data, int count)
>> >  	if (!test_bit(HCI_UART_REGISTERED, &hu->flags))
>> >  		return -EUNATCH;
>> >
>> > +	/* We discard Rx data received while device is in booting
>> > +	 * stage, This is because of BT chip Tx line is in tristate.
>> > +	 * Due to this we read some garbage data on UART Rx.
>> > +	 */
>> > +	if (test_bit(STATE_DISCARD_RX, &qca->flags))
>> > +		return 0;
>> > +
>> >  	qca->rx_skb = h4_recv_buf(hu->hdev, qca->rx_skb, data, count,
>> >  				  qca_recv_pkts, ARRAY_SIZE(qca_recv_pkts));
>> >  	if (IS_ERR(qca->rx_skb)) {
>> > @@ -1193,6 +1202,7 @@ static int qca_setup(struct hci_uart *hu)
>> >  		if (ret)
>> >  			return ret;
>> >
>> > +		clear_bit(STATE_DISCARD_RX, &qca->flags);
>> >  		ret = qca_read_soc_version(hdev, &soc_ver);
>> >  		if (ret)
>> >  			return ret;
>> > @@ -1269,6 +1279,14 @@ static const struct qca_vreg_data qca_soc_data = {
>> >
>> >  static void qca_power_shutdown(struct hci_uart *hu)
>> >  {
>> > +	struct qca_data *qca = hu->priv;
>> > +
>> > +	/* From this point we go into power off state,
>> > +	 * disable IBS and discard all the queued data.
>> > +	 */
>> > +	clear_bit(STATE_IN_BAND_SLEEP_ENABLED, &qca->flags);
>> 
>> Is IBS actually related to the frame reassembly errors or is this
>> addressing a different issue? In 100 iteratios of 'hciconfig up/down'
>> without clearing the flag I didn't observe any frame reassembly
>> errors.
> 
> Looks like this addresses the "Bluetooth: Received HCI_IBS_SLEEP_IND
> in rx state 0" messages that are seen when the interface is brought up
> on a system with firmware binaries (with IBS support?). Please spin
> this out into a separate patch.
> 

[Bala]: "Bluetooth: Received HCI_IBS_SLEEP_IND in rx state 0 is an 
different issue.
          i suspect that is due to mismatch of ibs timers over flow value 
between wcn3990 & HOST.
          clearing ibs is required, to stop ibs state machine while we do 
hci close
          this is intern help in resolving the frame reassembly errors 
during close (in rare case observed)
          anyways will send this a separate patch.

> Thanks
> 
> Matthias


-- 
Regards
Balakrishna.

      reply	other threads:[~2018-11-27  7:01 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-22 12:15 [PATCH v2 0/3] Bug fixes for Qualcomm BT chip wcn3990 Balakrishna Godavarthi
2018-11-22 12:15 ` [PATCH v2 1/3] Bluetooth: hci_qca: use wait_until_sent() for power pulses Balakrishna Godavarthi
2018-11-26 19:05   ` Matthias Kaehlcke
2018-11-22 12:15 ` [PATCH v2 2/3] Bluetooth: hci_qca: Deassert RTS while baudrate change command Balakrishna Godavarthi
2018-11-26 19:42   ` Matthias Kaehlcke
2018-11-27  6:41     ` Balakrishna Godavarthi
2018-11-22 12:15 ` [PATCH v2 3/3] Bluetooth: hci_qca: Fix frame reassembly errors for wcn3990 Balakrishna Godavarthi
2018-11-27  0:09   ` Matthias Kaehlcke
2018-11-27  0:27     ` Matthias Kaehlcke
2018-11-27  7:01       ` Balakrishna Godavarthi [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7453751357b0708af05c1ff3de8f1a2d@codeaurora.org \
    --to=bgodavar@codeaurora.org \
    --cc=hemantg@codeaurora.org \
    --cc=johan.hedberg@gmail.com \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-bluetooth@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marcel@holtmann.org \
    --cc=mka@chromium.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.