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@xxxxxxxxxx> 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.
By the way, you might find this thread interesting:
http://thread.gmane.org/gmane.linux.kernel.mmc/24728/focus=24783
In addition to the general idea of handling power control, I have also
posted a link to my patch adding DT support to brcmfmac driver.
Best regards,
Tomasz
--
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
