Hi, On Thu, May 22, 2014 at 5:49 PM, Hans de Goede <hdegoede@xxxxxxxxxx> wrote: > Hi All, > > Arend asked me to test these 2 patches for adding devicetree support to brcmfmac sdio devices: > "dt: bindings: add bindings for Broadcom bcm43xx sdio devices" > "brcmfmac: add device tree support for SDIO devices" > https://groups.google.com/forum/#!msg/linux-sunxi/Zph6zDTnAcw/_-wOO-gnIuQJ > > Getting this to do anything at all meant also adding this patch: > > "mmc: Add SDIO function devicetree subnode parsing" > https://lkml.org/lkml/2014/4/3/522 > > So that the card / sdio-func devices would actually get their of_node > pointer set to the child node under the mmc controller describing > the sdio wifi module. > > But that does not solve the entire problem. Listing the oob-interrupt info > in the child node works fine. But listing the brcm,wlan-supply gpio does > not. Since these sdio wifi modules are typically soldered onto the > board, there mmc controller device tree node has non-removable; set, > so the mmc subsystem will try to initialize the sdio device as soon > as the mmc driver loads, and if that fails will never look at it again. > > So we need to have the brcm,wlan-supply gpio driven high *before* the mmc > host driver initializes. In case of the brcm,wlan-supply property, this > is actually a problem which we've already solved in a number of dts files > for allwinner boards, simply create a fixed-regulator with an enable/disable > gpio, and set that as vmmc-supply for the mmc-host for the sdio wifi. > > However the "brcmfmac: add device tree support for SDIO devices" patch > also adds support for 2 devicetree controlled clocks. Assuming these need > to be ungated before the sdio module will respond to mmc commands, we have > the same problem. Olof posted an RFC series on this very matter: http://www.spinics.net/lists/linux-mmc/msg24411.html There was a lengthy discussion, however I don't think the matter was settled. CC-ed everyone from that discussion. > I've been thinking a bit about this, and it is a non trivial problem since > sdio devices are normally instantiated when probed, unlike ie spi devices > which are instantiated from devicetree. > > Adding device tree instantiation of sdio devices seems like a bad idea, as > then we get 2 vastly different device instantiation paths. Still we need some > way to get power and clks setup before the mmc host initializes. > > Therefor I would like to suggest to add a number of standard properties to > mmc-bus child nodes. Making the dts for an mmc host with an sdio device which > needs clks setup before it will work look like this: > > mmc3: mmc@01c12000 { > #address-cells = <1>; > #size-cells = <0>; > pinctrl-names = "default"; > pinctrl-0 = <&mmc3_pins_a>; > vmmc-supply = <®_vmmc3>; > bus-width = <4>; > non-removable; > status = "okay"; > > brcmf: bcrmf@0 { > reg = <0>; > compatible = "brcm,bcm43xx-fmac"; > clocks = <&clk_out_a>, <&clk_out_b>; > clock-frequency = <32768>, <26000000>; > interrupt-parent = <&pio>; > interrupts = <10 4>; /* PH10 / EINT10 */ > interrupt-names = "host-wake"; > status = "okay"; > }; > }; > > Where the "clocks" and "clock-frequency" attributes would be something > which we standardize in Documentation/devicetree/bindings/mmc/mmc-bus.txt > > These standard properties would *not* be used by the driver for the > childnode device, so as to avoid the chicken and egg problem of that driver > needing to enable clks, and it only getting bound to the device after > the device has been discovered which requires those clocks. > > Instead these properties would be parsed by mmc_of_parse, and we will > get enabled automatically by mmc_add_host before doing any probing. > > If the optional clock-frequency property is also set, then mmc_add_host > will not only enable the clks but also set them to the specified > frequency. > > Note I've no boards which actually need the clocks, all 3 boards with > sdio wifi which I've use a 26MHz crystal directly attached to the module, > so once I get the oob interrupt working (this needs some work on > the allwinner side) we can merge Arend's patches with the clock bits > dropped for now. > > Still I want to get a discussion going on this, so that when the time > comes that we do need it we know how to deal with this, or ideally > already have code in place to deal with it. 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
