Hi Marcel,
         Attached file includes vendor commands of realtek Bluetooth modules in initialize procedure.
And btusb is example of add rtl setup callbacks (not finished)



Champion
Ext:6325

发件人: Marcel Holtmann [mailto:marcel@holtmann.org]
发送时间: 2014年7月4日 2:12
收件人: 陈艳萍
抄送: Larry Finger; Daniel Drake; Gustavo F. Padovan; Johan Hedberg; Linux Bluetooth mailing list
主题: Re: [PATCH v2] Bluetooth: btusb: Add Realtek 8723/8761 support

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