On Wed, Nov 08, 2017 at 10:43:05PM +1100, Simon Shields wrote: > Hi Arend, > > On Wed, Nov 08, 2017 at 11:38:11AM +0100, Arend van Spriel wrote: > > + Stefan > > > > On 11/7/2017 2:31 PM, Simon Shields wrote: > > > Hi Arend, > > > > > > On Tue, Nov 07, 2017 at 12:09:23PM +0100, Arend van Spriel wrote: > > > > On 11/6/2017 12:27 PM, Simon Shields wrote: > > > > > On Mon, Nov 06, 2017 at 11:59:37AM +0100, Arend van Spriel wrote: > > > > > > On 11/4/2017 2:24 PM, Simon Shields wrote: > > > > > > > Some boards use an external 32khz clock for low-power > > > > > > > mode timing. Make sure the clock is powered on while the chipset > > > > > > > is active. > > > > > > > > > > > > Do you have such a board? With the little documentation I can get my hands > > > > > > on here I wonder whether the clock needs to be enabled before the device is > > > > > > powered. If you have the hardware I would like to check some registers in > > > > > > the device. > > > > > > > > > > > > > > > > Yes. Trats2 (exynos4412-based) has such a setup. The BCM4334 works fine > > > > > with this patch and one more that enables the WL_REG_EN pin when > > > > > brcmfmac is probed. > > > > > > > > Ok. So this is exactly the thing I was wondering about. So it makes me > > > > curious how the WL_REG_EN patch looks like. Can you provide that? > > > > > > > > > > Here[0] is a link to the patch in its current state. Obviously, it's not > > > ready at all for mainlining :-) > > > > > > [0]: https://github.com/fourkbomb/linux/commit/436e59e58b44d856c186fc4767560cecbcbc0c59.patch > > > > Thanks. Indeed doing it in module_init of brcmfmac is not going to fly. > > Actually the MMC stack has a mechanism to power the SDIO device. This can be > > configured through the device tree [1]. I just checked and it actually > > includes specifying the external clock as well. > > > > It looks like mmc-pwrseq-simple would handle the clock case, but it > doesn't handle the regulator properly: it sets the GPIO to high before > powering on, then lowers it immediately after powering it on. > > I guess a simpler approach here would be to extend pwrseq-simple to behave > as we need it to. I missed something really obvious... All that's needed is to invert the GPIO, like this[0]. Thanks for the pointer :) Cheers, Simon [0]: https://patchwork.kernel.org/patch/10048501/
