Re: Firmware for Bluetooth (and wifi)

[Arend van Spriel <arend-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>]

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...

Regards,
Arend