linux-amlogic.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: martin.blumenstingl@googlemail.com (Martin Blumenstingl)
To: linus-amlogic@lists.infradead.org
Subject: [RFC v1 5/8] Bluetooth: btrtl: add support for the RTL8723BS and RTL8723DS chips
Date: Sun, 19 Nov 2017 21:38:43 +0100	[thread overview]
Message-ID: <CAFBinCCtHUFMbbSOeKWYSJZKvFbNqhaMOrS-xgzr3E9hbkpnnw@mail.gmail.com> (raw)
In-Reply-To: <109FA59C-9875-4EAA-9DA5-EC811BAA77AE@holtmann.org>

Hi Marcel,

On Sun, Nov 19, 2017 at 9:25 AM, Marcel Holtmann <marcel@holtmann.org> wrote:
> Hi Martin,
>
>> The Realtek RTL8723BS and RTL8723DS chipsets are SDIO wifi chips. They
>> also contain a Bluetooth module which is connected via UART to the host.
>>
>> Realtek's userspace initialization tool (rtk_hciattach) differentiates
>> these two via the HCI version and revision returned by the
>> HCI_OP_READ_LOCAL_VERSION command.
>> Additionally we apply these checks only the for UART devices. Everything
>> else is assumed to be a "RTL8723B" which was originally supported by the
>> driver (communicating via USB).
>>
>> Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
>> ---
>> drivers/bluetooth/btrtl.c | 32 ++++++++++++++++++++++++++++++--
>> 1 file changed, 30 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/bluetooth/btrtl.c b/drivers/bluetooth/btrtl.c
>> index 45b872f5ad22..d896f9421250 100644
>> --- a/drivers/bluetooth/btrtl.c
>> +++ b/drivers/bluetooth/btrtl.c
>> @@ -418,9 +418,33 @@ struct btrtl_device_info *btrtl_initialize(struct hci_dev *hdev)
>>               has_rom_version = false;
>>               break;
>>       case RTL_ROM_LMP_8723B:
>> -             fw_name = "rtl_bt/rtl8723b_fw.bin";
>> -             cfg_name = "rtl_bt/rtl8723b_config.bin";
>> +             /* all variants support reading the ROM version */
>>               has_rom_version = true;
>> +
>> +             /*
>> +              * RTL8723 devices exist in different variants:
>> +              * - RTL8723BS (SDIO chip with UART Bluetooth)
>> +              * - RTL8723DS (SDIO chip with UART Bluetooth)
>> +              * - for backwards-compatibility everything else is assumed to
>> +              *   be an RTL8723B communicating over USB
>> +              *
>> +              * Only UART devices really need the config because that
>> +              * contains the UART speed / flow control settings.
>> +              */
>> +             if (hdev->bus == HCI_UART && resp->hci_ver == 6 &&
>> +                 le16_to_cpu(resp->hci_rev) == 0xb) {
>> +                     fw_name = "rtl_bt/rtl8723bs_fw.bin";
>> +                     cfg_name = "rtl_bt/rtl8723bs_config.bin";
>> +                     cfg_needed = true;
>> +             } else if (hdev->bus == HCI_UART && resp->hci_ver == 8 &&
>> +                        le16_to_cpu(resp->hci_rev) == 0xd) {
>> +                     fw_name = "rtl_bt/rtl8723ds_fw.bin";
>> +                     cfg_name = "rtl_bt/rtl872ds_config.bin";
>> +                     cfg_needed = true;
>> +             } else {
>> +                     fw_name = "rtl_bt/rtl8723b_fw.bin";
>> +                     cfg_name = "rtl_bt/rtl8723b_config.bin";
>> +             }
>
> so the main question is why is this a config file in the first place? So far all other drivers have expressed UART settings via DT (or even via ACPI). If we are just getting the baudrates, then better have this in DT. Since otherwise we end up with board specific filesystems again where different config files need to be installed. That is really not useful in the end.
this is an excellent question (and also the reason why it's an "RFC" patch)!
I'll try to figure out whether:
a) we can skip the config file completely
b) we can generate the config file in-memory
c) we have to stick with this config file

> What is actually in these config files? Can we have some parsing and friendly display tool in bluez.git like we have for other manufactures.
to my knowledge this config file contains:
- the baudrate
- whether flow control is enabled or disabled
- (in some cases) the local-bd-address

do you mean a tool that is similar to bluez.git tools/nokfw.c?


Regards
Martin


[0] https://github.com/NextThingCo/rtl8723ds_bt/blob/f56ef37217665070e574253d23a595ee1ca5ca23/rtk_hciattach/hciattach_rtk.c#L1781

  reply	other threads:[~2017-11-19 20:38 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-17 22:35 [RFC v1 0/8] Realtek Bluetooth serdev support (H5 protocol) Martin Blumenstingl
2017-11-17 22:35 ` [RFC v1 1/8] serdev: implement parity configuration Martin Blumenstingl
2017-11-17 22:35 ` [RFC v1 2/8] Bluetooth: btrtl: add MODULE_FIRMWARE declarations Martin Blumenstingl
2017-11-17 22:35 ` [RFC v1 3/8] Bluetooth: btrtl: split the device initialization into smaller parts Martin Blumenstingl
2017-11-17 22:35 ` [RFC v1 4/8] Bluetooth: btrtl: add support for retrieving the UART settings Martin Blumenstingl
2017-11-17 22:35 ` [RFC v1 5/8] Bluetooth: btrtl: add support for the RTL8723BS and RTL8723DS chips Martin Blumenstingl
2017-11-19  8:25   ` Marcel Holtmann
2017-11-19 20:38     ` Martin Blumenstingl [this message]
2017-11-19 21:17       ` Marcel Holtmann
2017-11-26 22:23         ` Martin Blumenstingl
2017-11-26 22:47           ` Emil Lenngren
2017-11-27 10:00           ` Marcel Holtmann
2017-11-17 22:35 ` [RFC v1 6/8] Bluetooth: hci_h5: add support for Realtek UART Bluetooth modules Martin Blumenstingl
2017-11-19  8:29   ` Marcel Holtmann
2017-11-19 20:28     ` Martin Blumenstingl
2018-03-16 22:22   ` Marcel Holtmann
2018-03-17 22:50     ` Jeremy Cline
2018-03-18 10:46       ` Marcel Holtmann
2018-03-18 22:52       ` Martin Blumenstingl
2017-11-17 22:35 ` [RFC v1 7/8] Bluetooth: hci_serdev: remove the HCI_UART_INIT_PENDING check Martin Blumenstingl
2017-11-19  8:21   ` Marcel Holtmann
2017-11-19 20:24     ` Martin Blumenstingl
2017-11-19 20:43       ` Johan Hedberg
2017-11-17 22:35 ` [RFC v1 8/8] dt-bindings: net: bluetooth: add support for Realtek Bluetooth chips Martin Blumenstingl
2017-11-20 21:09   ` Rob Herring

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=CAFBinCCtHUFMbbSOeKWYSJZKvFbNqhaMOrS-xgzr3E9hbkpnnw@mail.gmail.com \
    --to=martin.blumenstingl@googlemail.com \
    --cc=linus-amlogic@lists.infradead.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).