* Peter Ujfalusi <peter.ujfalusi@xxxxxx> [150921 02:59]:
> On 09/18/2015 07:29 PM, Tony Lindgren wrote:
> > Commit 68bab8662f49 ("mfd: twl6040: Optional clk32k clock handling")
> > added clock handling for the 32k clock from palmas-clk. However, that
> > patch did not consider a typical situation where twl6040 is built-in,
> > and palmas-clk is a loadable module like we have in omap2plus_defconfig.
> >
> > If palmas-clk is not loaded before twl6040 probes, we will get a
> > "clk32k is not handled" warning during booting. This means that any
> > drivers relying on this clock will mysteriously fail, including
> > omap5-uevm WLAN and audio.
> >
> > Note that for WLAN, we probably should also eventually get
> > the clk32kgaudio for MMC3 directly as that's shared between
> > audio and WLAN SDIO at least for omap5-uevm. It seems the
> > WLAN chip cannot get it as otherwise MMC3 won't get properly
> > probed.
>
> While this is going to 'fix' the WLAN because currently the twl6040 is powered
> on all the time (32k clock is enabled). My plan is to finally implement the
> power state handling for the twl6040, which means that w/o audio activity the
> twl6040 will be turned off. This will imply that any clock which is only used
> by twl6040 will be off as well.
> The proper solution would be to add clock handling to the WLAN driver stack.
Yes the place to request this clock is using pwrseq_simple.c for MMC3.
It seems there are some issues with deferred probe handling there too
though.
Regards,
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
