Re: Firmware for Bluetooth (and wifi)

On 27.01.2014 10:21, Arend van Spriel wrote:

On 01/27/2014 01:20 AM, Tomasz Figa wrote:

quoted

Hi Chen-Yu, Arend,

On 26.01.2014 22:39, Arend van Spriel wrote:

quoted

On 01/26/2014 05:58 PM, Chen-Yu Tsai wrote:

quoted

Hi,

On Mon, Jan 27, 2014 at 12:34 AM, Hans de Goede [off-list ref]
wrote:

quoted

Hi,

On 01/24/2014 04:38 AM, Chen-Yu Tsai wrote:

<snip>

quoted

quoted

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?

quoted

quoted

quoted

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