On Mon, Feb 14, 2011 at 06:41:47PM +0000, Tardy, Pierre wrote: > Philip, > > > And, more important, you will do cond_resched while holding you > > > spinlock, which is *bad*. > > > What if the mmc stack will call you again from another thread? deadlock... > > > Assumptions -- Please Confirm > > ------------------------------------------- > No need to do assumptions, schedule while holding spinlocks is bad, your kernel will oops with something like: > BUG: scheduling while in atomic. I thought the assumptions were made in order to check where the spinlock is _really_ needed. Thinking in that direction is a good aproach IMO. > > >> @@ -1108,7 +1108,7 @@ static void sdhci_set_power(struct sdhci_host *host, unsigned short power) > > >> * can apply clock after applying power > > >> */ > > >> if (host->quirks & SDHCI_QUIRK_DELAY_AFTER_POWER) > > >> - mdelay(10); > > >> + mmc_delay(10); > > > Do you need this quirk in your platform? > > > > No > Then, you dont have any mdelay in your set_ios, and you are trying to optimize something that never happen. There are some more mdelays in error-conditions which could happen occasionally (see sdhci_send_command, spinlocked by sdhci_request for example). Regards, Wolfram -- Pengutronix e.K. | Wolfram Sang | Industrial Linux Solutions | http://www.pengutronix.de/ | -- 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
