On Thu, Jul 14, 2016 at 11:34:05AM +0200, Mark Kettenis wrote: > > Date: Thu, 14 Jul 2016 17:53:22 +1000 > > From: Jonathan Gray <[email protected]> > > > > 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.
I'd look at the no-1-8v property to start with (ommmc should be looking at ti,dual-volt before using 3.0v as well). Documented as: - no-1-8-v: when present, denotes that 1.8v card voltage is not supported on this system, even if the controller claims it is.
