Re: [RFC} sdhci.c set_ios -- disable global interrupts and Question on Power Management

From: Wolfram Sang <w.sang@pengutronix.de>
To: "Tardy, Pierre" <pierre.tardy@intel.com>
Cc: Philip Rakity <prakity@marvell.com>,
	Pierre Tardy <tardyp@gmail.com>,
	"linux-mmc@vger.kernel.org" <linux-mmc@vger.kernel.org>
Subject: Re: [RFC} sdhci.c set_ios -- disable global interrupts and Question on Power Management
Date: Tue, 15 Feb 2011 09:39:17 +0100	[thread overview]
Message-ID: <20110215083917.GB3517@pengutronix.de> (raw)
In-Reply-To: <8250E4885F9967469CAC3FB5CBA2CE69935205E445@irsmsx501.ger.corp.intel.com>

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/  |