> Date: Thu, 14 Jul 2016 17:53:22 +1000 > From: Jonathan Gray <j...@jsg.id.au> > > On Thu, Jul 14, 2016 at 03:20:34AM -0400, Ian Sutton wrote: > > I am working on a MD PCI-E driver for the armv7/imx platform. It > > attaches via FDT/simplebus, ascertaining its physical memory addresses > > from the fdt structure originating from the dtb files present on the > > msdos bootloader partition. The dtb files we're using now have the > > cubox's 'pcie' nodes disabled via a "status=disabled" property. The > > following patches fix this in the decompiled dtb outfiles: > > I thought the wlan was attached to pcie but it seems it is > actually an sdio device. > > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/imx6qdl-microsom.dtsi > > /* USDHC1 - Connected to optional BRCM Wifi/BT/FM */ > &usdhc1 { > pinctrl-names = "default"; > pinctrl-0 = <&pinctrl_microsom_brcm_wifi &pinctrl_microsom_usdhc1>; > bus-width = <4>; > mmc-pwrseq = <&usdhc1_pwrseq>; > keep-power-in-suspend; > no-1-8-v; > non-removable; > vmmc-supply = <®_brcm>; > status = "okay"; > };
WiFi over SDIO is quite common for these SoC-type systems. The Bay Trail-based ASUS EeeBook I have has a similar setup. I suppose PCIe sucks quite a bit of power even if you do proper link management. I actually believe that Broadcom's PCIe solutions are essentially SDIO with a PCIe to SDIO bridge on front of them. Time to investigate the sdmmc0: can't enable card message I see on my CuBox-i4Pro once more.
