Re: Firmware for Bluetooth (and wifi)

[Tomasz Figa <tomasz.figa-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>]

On 27.01.2014 10:21, Arend van Spriel wrote:
> On 01/27/2014 01:20 AM, Tomasz Figa wrote:
>> Hi Chen-Yu, Arend,
>>
>> On 26.01.2014 22:39, Arend van Spriel wrote:
>>> On 01/26/2014 05:58 PM, Chen-Yu Tsai wrote:
>>>> Hi,
>>>>
>>>> On Mon, Jan 27, 2014 at 12:34 AM, Hans de Goede <hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
>>>> wrote:
>>>>> Hi,
>>>>>
>>>>> On 01/24/2014 04:38 AM, Chen-Yu Tsai wrote:
>>>>>
>>>>> <snip>
>>>>>
>>>>>
>>>>>>> Quick update, I've just tested:
>>>>>>> https://github.com/wens/linux/commits/wip/sunxi-next-wifi
>>>>>>
>>>>>>
>>>>>> About this, I would like to move WiFi power control to a regulator,
>>>>>> and controlled by sunxi-mci via vmmc-supply (not supported ATM)
>>>>>
>>>>>
>>>>> Actually the sunxi-mci.c driver already has support for an optional
>>>>> regulator called vmmc.
>>>>>
>>>>> I like this idea, I've done a version of the dt patch using a regulator
>>>>> instead of rfkill here:
>>>>> https://github.com/jwrdegoede/linux-sunxi/commit/8d200113b573549cdcdc1b2d5a5a1cad15cfbe07
>>>>>
>>>>>
>>>>> This works as advertised and IMHO is the better solution.
>>>>
>>>> I have a version in another branch I haven't pushed. I had it using an
>>>> always-on regulator. I can adjust it to use vmmc.
>>>>
>>>> BTW, I'd like to do a patch for sunxi-mci to use the DT parsing code
>>>> in mmc core.
>>>> We should re-use code if possible, wouldn't you agree?
>>>>
>>>>>>> About the oob interrupt stuff not working, AFAIK you should set a
>>>>>>> pinctrl
>>>>>>> function (not input, but a function like mmc is a function) on the
>>>>>>> pin in
>>>>>>> question
>>>>>>> for it to work as external interrupt, I believe you're not doing
>>>>>>> so in
>>>>>>> your
>>>>>>> dts.
>>>>>>
>>>>>>
>>>>>> The pinctrl driver seems to set the function when the interrupt is
>>>>>> enabled.
>>>>>> Unfortunately we don't have any documentation/examples on how to
>>>>>> use them.
>>>>>> I will look into that later.
>>>>>
>>>>>
>>>>> Hmm, but you also have a pinctrl entry in the dts setting it up as
>>>>> gpio-input,
>>>>> maybe that conflicts ?
>>>>
>>>> I made a version with pinctrl entry setup as "irq", got an interrupt,
>>>> but then the whole thing hung. Looks like pinctrl irqchip was not
>>>> properly handling chained interrupts. I have done a simple fix, and I
>>>> hope to test it tomorrow. Then I'll do some more testing with different
>>>> configurations and hopefully write some documents.
>>>
>>> Hi Chen-Yu,
>>>
>>> I had a look at github tree from Hans with your DT support patch for
>>> brcmfmac. I applied it to my 3.14 tree and modified it a little. I guess
>>> the bindings are still experimental, but I would prefer you to use brcm
>>> instead of broadcom in the 'compatible' entry as found in
>>> Documentation/devicetree/bindings/vendor-prefixes.txt. There is an
>>> exception to this rule in the bindings (in net/broadcom-bcm87xx.txt),
>>> but I guess that train has left and it is tricky to change it now.
>>> In the brcmfmac patch you also use multiple of_device ids. Could we make
>>> it more generic, ie. compatible = "brcm,brcmfmac" or "brcm,wifi-fullmac"
>>> or whatever...
>>
>> brcmfmac and wifi-fullmac strings sound to generic for me. What happens
>> if an incompatible brcmfmac chip shows up? I'd rather use something like
>> "bcm43xx" to cover existing chip family, if all the bcm43xx chips are
>> compatible, or something more specific otherwise.
>
> The brcmfmac driver that consumes these DT nodes will have a closer look
> at the device obtaining the chipid during the probe and determine if it
> can support it. So the compatible string indicates that the device needs
> a so-called fullmac wireless driver opposed to a mac80211 aka. softmac
> wireless driver.

The compatible string should guarantee that the chip ID register holds a 
valid value, so just "wifi-fullmac" or "brcmfmac" sounds too generic to 
me. The string must specify the family of chips with this chip ID scheme 
in a reasonably precise way. "brcm,bcm43xx-fmac" maybe? I still see a 
risk of, say, BCM43999 showing up, which would be a completely different 
chip. while having the model matching the pattern.

However this is something for you Broadcom guys to know better, so feel 
free to suggest anything better.

Best regards,
Tomasz