Hi Arend, Tomasz, On Mon, Jan 27, 2014 at 8:20 AM, Tomasz Figa <tomasz.figa@xxxxxxxxx> 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@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. I will fix this, though the only reason I did this is for the OOB interrupts. >> 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 Yeah I've been following this thread. > 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. Actually since that thread started, I prefer handling the regulators and possibly clocks in the mmc controller, as Olof posted. But that's just my opinion. Cheers, ChenYu -- 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
