On 20/03/17 19:22, Adrian Hunter wrote: > On 03/16/2017 12:32 PM, 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. > > I just posted a patch to remove the spin lock from set_ios(). Does that help? Yes it does, thanks! Technically, the only other place this could occur is in sdhci_request_done() because this also calls ->set_clock() with the spinlock held. However, this is only called if SDHCI_QUIRK_CLOCK_BEFORE_RESET is set, which is only currently true for a device in sdhci-pci-core.c and this one just uses the normal sdhci_set_clock() routine. Cheers 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
