linux-bluetooth.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Loic Poulain <loic.poulain@linaro.org>
To: Marcel Holtmann <marcel@holtmann.org>
Cc: "open list:BLUETOOTH DRIVERS" <linux-bluetooth@vger.kernel.org>,
	linux-arm-msm@vger.kernel.org, kkapra@codeaurora.org,
	bgodavar@codeaurora.org
Subject: Re: [PATCH 2/2] Bluetooth: btqca: Add AR3002 rampatch support
Date: Wed, 25 Apr 2018 09:58:47 +0200	[thread overview]
Message-ID: <CAMZdPi8ABhv8EDaE+afFpHexuMKjst5djiMt4HFoGqPNHs+akQ@mail.gmail.com> (raw)
In-Reply-To: <B39D4D6F-96FB-442E-84D8-BEA603E7A053@holtmann.org>

Hi Marcel,

+Balakrishna Godavarthi, I've just seen that his recent patch for
wcn3990 support deals with the same download issue.

On 24 April 2018 at 17:13, Marcel Holtmann <marcel@holtmann.org> wrote:
> Hi Loic,
>
>> This patch adds rampatch download compatibility for ROME >= 3.2.
>> Starting with ROME 3.2, the 'download mode' field of the rampatch
>> header indicates if the controller acknowledges (or not) the received
>> rampatch segments. If not, we need to send all the segments without
>> expecting any event from the controller (except for the last segment).
>> Goal is (I assume) to speed-up rampatch download.
>
> WHYYYYYYYYYY ???
>
> I have done the measurement with the Intel chips and it is insignificant on Linux. The Linux USB subsystem is a lot better than the one from Windows.

To be honest, I have no much information (so maybe Windows
optimization is the point), I mainly extracted info from a Yocto
hciattach patch:
https://github.com/boundarydevices/meta-boundary/blob/krogoth/recipes-connectivity/bluez5/bluez5/0001-hciattach-add-QCA9377-Tuffello-support.patch

My module version use HCI UART as transport layer.


> Is there any chance we can just switch this back on and keep waiting for the event?

I tried to change the fw/rampatch header on  the fly to 'standard
download mode' before starting flashing.
It seems to be supported since pretty all segments are correctly sent
and acked by the vendor event.
However the last segment is nacked:

    Bluetooth: hci0: TLV with error stat 0x0 rtype 0x4 (0x3)

I suppose the rampatch contains a checksum which is verified once
download is complete, hacking the header would cause a corruption of
the rampatch, leading to this NACK.
So in theory, the download behavior seems to depend only on the
rampatch file(header) and is not hard-coded on controller side.

Since rampatchs are not under our control, I think it's good to
support this download mode anyway.

Regards,
Loic

  reply	other threads:[~2018-04-25  7:58 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-23 17:59 [PATCH 1/2] Bluetooth: Add __hci_cmd_sync_noev function Loic Poulain
2018-04-23 17:59 ` [PATCH 2/2] Bluetooth: btqca: Add AR3002 rampatch support Loic Poulain
2018-04-24 15:13   ` Marcel Holtmann
2018-04-25  7:58     ` Loic Poulain [this message]
2018-04-25 12:16       ` bgodavar
2018-04-25 13:37         ` Loic Poulain
2018-04-25 15:19           ` bgodavar
2018-04-26  6:52             ` Loic Poulain
2018-04-24 15:10 ` [PATCH 1/2] Bluetooth: Add __hci_cmd_sync_noev function Marcel Holtmann
2018-04-25 10:00   ` Loic Poulain
2018-04-25 12:10     ` Marcel Holtmann
2018-04-25 13:34       ` Loic Poulain

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=CAMZdPi8ABhv8EDaE+afFpHexuMKjst5djiMt4HFoGqPNHs+akQ@mail.gmail.com \
    --to=loic.poulain@linaro.org \
    --cc=bgodavar@codeaurora.org \
    --cc=kkapra@codeaurora.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-bluetooth@vger.kernel.org \
    --cc=marcel@holtmann.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).