Re: Problem with naming of broadcom bt patchram firmware files

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

 



Hi Hans,

> I've been working recently on adding support for serialport /
> serdev attached brcm bt devices on more (x86) boards.
> 
> This is going well in general, but I just noticed a problem
> with this.
> 
> Currently on for example both the Raspberry Pi 3 and the
> Chuwi Vi8 Plus, we will load brcm/BCM43430A1.hcd as patchram
> file. Ideally this file will be in linux-firmware (*) so things
> will just work.
> 
> But it turns out there are 2 different builds of the firmware,
> one for boards which use a 26MHz crystal and one for boards which
> use a 37.4Mhz crystal and guess what the RPi 3 uses 37.4Mhz
> and the Chuwi Vi8 Plus 26Mhz.
> 
> So this causes 2 problems:
> 
> 1) We need a -xxmhz postfix to the firmware name I believe,
> but this will break existing setups, so I guess we first
> try to load with the postfix, and then fallback to the old
> name?
> 
> 2) A bigger problem is how to figure out which frequency we
> need. The wifi driver knows this as there is an xtalfreq=26000
> or xtalfreq=37400 in the nvram file it loads. We could come
> up with a mechanism to use this, but this will not be pretty and
> it assumes that the uart attached bcm bt is always combined
> with a wifi part which uses nvram from /lib/firmware.
> 
> Looking at all the devices I'm aware of atm there is no
> real heuristic for this, but if we only look at x86 we can
> get away with a per chip default, which we set in the
> bcm_uart_subver_table.
> 
> So the direction I'm thinking in atm is:
> 
> 1) Let hci_bcm.c tell btbcm.c which frequency to use, with an
> option for it to pass "don't know use default"
> 
> 2) For ARM allow setting the frequency through a devicetree property
> which gets set on the serdev device-node (the node with the
> "brcm,bcm43438-bt" compatible), with a fallback to the default
> if not set.
> 
> 3) On x86 rely on the defaults and if ever necessary use DMI
> quirks to override
> 
> Note for this to work, the default for the BCM43430A1.hcd needs
> to be 26 MHz and the RPi needs to have an updated devicetree
> setting the freq to 37.4.
> 
> So what are your thoughts on this?

we need to move towards a modalias:firmware file name mapping table so that you can also just put all the firmware files you find in the Windows driver into lib/firmware and stop worrying about it. That is what Windows actually does, the PnP ID maps to the firmware file. They do that even for USB. Some time ago, I have written code for that and seems like I need to dust this off since now it is needed.

Here is what I had for /lib/firmware/brcm/bcmbtfw.map table that I used for testing.

usb:v0930p0223*         BCM20702A1_001.002.014.1483.1674.hex
usb:v0A5Cp21E8*         BCM20702A1_001.002.014.1443.1459.hex
usb:v0A5Cp21EC*         BCM20702A1_001.002.014.1443.1460.hex
usb:v0B05p17CB*         BCM20702A1_001.002.014.1443.1467.hex
usb:v19FFp0239*         BCM20702B0_002.001.014.0527.0557.hex

And we can stick ACPI and DT modalias entries in there as well.

In addition, I am really thinking we should let hci_bcm.c be what it is and move towards the btuart.c serdev only driver that I posted a few days ago. That way we 
can try to keep this clean and don’t have to deal with TTY line discipline legacy.

Do you have a good reference for the Broadcom Windows driver that includes UART based devices. And I wonder if the Apple UART devices use ROM patching or if they are RAM based like their USB counterparts.

Regards

Marcel

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



[Index of Archives]     [Linux IBM ACPI]     [Linux Power Management]     [Linux Kernel]     [Linux Laptop]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]     [Linux Resources]

  Powered by Linux