Re: [PATCH 01/13] dt-bindings: net: bluetooth: add support for Realtek Bluetooth chips

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

On 04-06-18 21:11, Marcel Holtmann wrote:

<snip>

Hmm that is actually no entirely true, for broadcom the
bluetooth patchram file depends on the clockcrystal freq
used on the board, so there are 2 versions of it for a
single chip, 1 for each of the 2 different freqs used.
are you using .hex or .hcd files for Broadcom? The .hex files are pure patchram, while the .hcd can actually contain extra HCI commands. I remember that some .hcd files contain also HCI commands to do extra settings. Maybe we need a tool that shows the details of these files. We have this for nokfw and rtlfw now.

I'm using hcd files for broadcom.

so I added tools/bcmfw to analyze HCD files. We might also need a compare HCD files option. However you might be able to compare the HCD files that you think are different for some of your hardware.

The problem is that I don't think I can get the exact same
version / build of the patchram in 26MHz and 37.4 Mhz versions
and comparing different versions is not really going to be useful.

All I really know here is that I can usually take any 37.4MHz build,
as indicated by the build string in the hcd file, e.g. :

BCM43438A1 37.4MHz Raspberry Pi 3-0043O

And use that on a board where the wifi nvram file says the
crystal is 37.4MHz and things will work fine. Where as any
hcd with 26Mhz in the buildstring will not work.

My work on the brcm bluetooth code has left me to believe
that the ACPI HID is (supposed to be) unique per board.

I'm thinking of adding a postfix string as driver_data
in the acpi_match_id table for ACPI HIDs which I can test
and then make the bcm-bt code first try e.g. firmware_request
BCM4356A2-26M.hcd before calling BCM4356A2.hcd .

I could instead simply postfix the ACPI HID (as I plan to
do for the realtek btconfig) but as said in all my testing
simply using the latest build, with the right crystal
freq seems to work best. So I would prefer to go with
e.g. BCM4356A2-26M.hcd rather then BCM4356A2-BCM2E74.hcd
this way we will only need 2 hcd files (26M and 37.4M) per
chipset rather a whole lot of them.

Marcel, what do you think of this, would you accept a (to-be-written)
patchset adding -26M / -37.4M postfixes as described above?

This is all aimed at getting the hcd files into linux-firmware,
where less files definitely would be more. Note I'm only talking
about serdev attached bcm-bt devices here. For usb we can keep
using the existing scheme or come up with a new scheme.

Regards,

Hans


--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux