Pierre, The spin_lock may not be needed if the same thread cannot be re-entered. That was the reason for the assumptions. Sorry about not being clear. Philip On Feb 14, 2011, at 10:41 AM, 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. > > >>>> @@ -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. > > Pierre > > --------------------------------------------------------------------- > Intel Corporation SAS (French simplified joint stock company) > Registered headquarters: "Les Montalets"- 2, rue de Paris, > 92196 Meudon Cedex, France > Registration Number: 302 456 199 R.C.S. NANTERRE > Capital: 4,572,000 Euros > > This e-mail and any attachments may contain confidential material for > the sole use of the intended recipient(s). Any review or distribution > by others is strictly prohibited. If you are not the intended > recipient, please contact the sender and delete all copies. > -- 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
