Content-Type: multipart/alternative; boundary="Apple-Mail=_9E34E40F-3528-4D44-B9F3-5486B017C972" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: [PATCH v2] Bluetooth: btusb: Add Realtek 8723/8761 support From: Marcel Holtmann In-Reply-To: <54F70642BAB21D4498E1AA3EFE3D519A45FBED07@rsex2.realsil.com.cn> Date: Thu, 3 Jul 2014 20:12:27 +0200 Cc: Larry Finger , Daniel Drake , "Gustavo F. Padovan" , Johan Hedberg , Linux Bluetooth mailing list Message-Id: References: <1404218878-14218-1-git-send-email-drake@endlessm.com> <16AC594D-6B3C-4CB6-B951-0763F3E4E27A@holtmann.org> <53B2D160.4010306@lwfinger.net> <54F70642BAB21D4498E1AA3EFE3D519A45FBED07@rsex2.realsil.com.cn> To: =?utf-8?B?6ZmI6Imz6JCN?= List-ID: --Apple-Mail=_9E34E40F-3528-4D44-B9F3-5486B017C972 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=GB2312 Hi Champion, > 1. RTL vs RTK , it is ok to use "rtl " to comply with wifi drivers lets be consistent and keep using rtl. =20 > 2. firmware table, when module is powered on the default LMP versions = are different. After download firmware ,the LMP version will change to = firmware version. > =20 > module > LMP Subversion > HCI Revision > RTL8723A > 0X1200 > 0X000B > RTL8723B > 0X8723 > 0X000B > RTL8761A > 0X8761 > 0X000A > RTL8821A > 0X8821 > 0X000A > =20 > 8723A/8723B/8821A are combo modules both with wifi and Bluetooth; > 8761A is Bluetooth only chip, but can be used to with wifi 8812/8192, = and will use different bluetooth firmware for each combination. > This can only be distinguished by pids. > I think it is OK to only support 8723A &8723B and leave others for = next time driver update. Can you share the Realtek HCI Vendor Command specification with me = privately. The command above is Bluetooth standard, but we are also = having at least the baud rate change for UART based controllers and the = ROM version command. We most likely also need a vendor command to set = the BD_ADDR in case it is not configured or an OEM wants to change it. I also like to know what is the right procedure for loading the ROM = patches and/or settings. Getting this nicely documented would be of = great benefit. We have the Intel and Broadcom procedures nicely = documented inside the code. =20 > 2. I read the codes in kernel 3.13 , some companies such as Intel = add setup function for their modules in general btusb driver ; while = some provide another driver and set BTUSB_IGNORE in btusb_probe, how can = it work for their private driver only download firmware and do not call = any functions of bluez hci layer ? There are two ways current silicon vendors have done. Either have a = special USB VID/PID or descriptors, attach the firmware loading driver = and load the firmware. The device disconnects from USB and re-connects = with its new identity. And then btusb driver takes over. The second method is doing the setup stage all in the driver. So the = Bluetooth core is actually providing a running transport that is driven = by the transport driver (in this case btusb), but before it takes = control it allows the driver to issue certain HCI commands. This is = mostly used for firmware loading. You can see that for Intel and = Broadcom. If your firmware loading, setup, patching or whatever is done with HCI = commands, you should go the setup callback broke since that way you do = not have to deal with transport details. It will just work. If you speak = a non-HCI protocol, then the method with a separate firmware loading = driver is beneficial. For Realtek it seems the setup stage like what we do with Intel and = Broadcom silicon is exactly what you want. Can you provide a list of USB/PID that match to modules which require = the firmware loading or optionally support the firmware loading. That = would make it easier to populate the matching table. The decision on the = module can be easily done by reading the HCI Local Version Information = first. Regards Marcel --Apple-Mail=_9E34E40F-3528-4D44-B9F3-5486B017C972 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=GB2312
Hi Champion,

1.  RTL vs RTK , it is ok to use "rtl " to comply = with wifi = drivers

lets be = consistent and keep using rtl.
 
2. firmware table, when module = is powered on the default LMP versions are different. After download = firmware ,the LMP version will change to firmware = version.
<image003.jpg> 
module
LMP = Subversion
HCI = Revision
RTL8723A
0X1200
0X000B
RTL8723B
0X8723
0X000B
RTL8761A
0X8761
0X000A
RTL8821A
0X8821
0X000A
 
8723A/8723B/8821A are combo modules both with wifi and = Bluetooth;
8761A is = Bluetooth only chip, but can be used to with wifi 8812/8192, and will = use different bluetooth firmware for each = combination.
This can = only be distinguished by pids.
I think it is OK to only support 8723A = &8723B and leave others for next time driver = update.

Can you = share the Realtek HCI Vendor Command specification with me privately. = The command above is Bluetooth standard, but we are also having at least = the baud rate change for UART based controllers and the ROM version = command. We most likely also need a vendor command to set the BD_ADDR in = case it is not configured or an OEM wants to change it.

I also like to know what is the right = procedure for loading the ROM patches and/or settings. Getting this = nicely documented would be of great benefit. We have the Intel and = Broadcom procedures nicely documented inside the code.
 
2.     I read the codes in kernel = 3.13 , some companies such as Intel add setup function for their modules = in general btusb driver ;  while some provide another driver and = set BTUSB_IGNORE in btusb_probe, how can it work for their private = driver only download firmware and do not call any functions of bluez hci = layer ?

There are = two ways current silicon vendors have done. Either have a special USB = VID/PID or descriptors, attach the firmware loading driver and load the = firmware. The device disconnects from USB and re-connects with its new = identity. And then btusb driver takes over.

The = second method is doing the setup stage all in the driver. So the = Bluetooth core is actually providing a running transport that is driven = by the transport driver (in this case btusb), but before it takes = control it allows the driver to issue certain HCI commands. This is = mostly used for firmware loading. You can see that for Intel and = Broadcom.

If your firmware loading, setup, = patching or whatever is done with HCI commands, you should go the setup = callback broke since that way you do not have to deal with transport = details. It will just work. If you speak a non-HCI protocol, then the = method with a separate firmware loading driver is = beneficial.

For Realtek it seems the setup = stage like what we do with Intel and Broadcom silicon is exactly what = you want.

Can you provide a list of USB/PID = that match to modules which require the firmware loading or optionally = support the firmware loading. That would make it easier to populate the = matching table. The decision on the module can be easily done by reading = the HCI Local Version Information = first.

Regards

Marcel

= --Apple-Mail=_9E34E40F-3528-4D44-B9F3-5486B017C972--