On 16/03/17 10:32, Jon Hunter wrote: > It is common for SD/MMC host controllers to set the parent clock that > drives the SD/MMC interface in order to support various operating > speeds. Typically, this is performed by calling common clock framework > APIs such as clk_set_rate(). The problem is that these APIs may sleep > and must not be called from within atomic sections and therefore, these > functions cannot be called within the existing 'set_clock' SDHCI > operator because they are called from within the context of a spinlock. > Add a new 'set_parent_clock' operator for the SDHCI driver that is > called early during the SDHCI 'set_ios' before the spinlock is aquire to > give the platform driver the opportunity to set the parent clock rate. > > Please note that, unfortunately, the Tegra and MSM SDHCI drivers > currently appear to mis-use the 'set_clock' operator by calling > clk_set_rate(). In the case of Tegra, occasionally but not always, > 'scheduling while atomic' errors are reported (so most of the time we > are getting lucky). In the of the MSM SDHCI driver, it is releasing and > re-acquiring the spinlock which is bad. > > Signed-off-by: Jon Hunter <jonathanh@xxxxxxxxxx> > --- > > I have not attempted to fix the MSM driver in this seris, but I am > copying hopefully, the right people to fix it. > > drivers/mmc/host/sdhci.c | 3 +++ > drivers/mmc/host/sdhci.h | 2 ++ > 2 files changed, 5 insertions(+) > > diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c > index 6fdd7a70f229..b7f1521edbec 100644 > --- a/drivers/mmc/host/sdhci.c > +++ b/drivers/mmc/host/sdhci.c > @@ -1579,6 +1579,9 @@ static void sdhci_set_ios(struct mmc_host *mmc, struct mmc_ios *ios) > if (ios->power_mode == MMC_POWER_UNDEFINED) > return; > > + if (host->ops->set_parent_clock) > + host->ops->set_parent_clock(host, ios->power_mode); Ugh ... not sure what happened here but this should be 'ios->clock'! And I did test this! Sorry will resend. Jon -- nvpublic -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
