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... Regards, Arend -- 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
