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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Feb 13, 2011, at 2:25 AM, Pierre Tardy wrote:

> On Sun, Feb 13, 2011 at 6:39 AM, Philip Rakity <prakity@xxxxxxxxxxx> wrote:
>> 
>> Pierre,
>> 
>> I am preparing a patch to just diable to interrupt line to the SD controller so global interrupts are not locked out.
> I think I already have seen previous version of that patch earlier. It
> does not sound like a bad idea. However, disabling all interrupt is
> really cheap, and disabling only one is a bit more expensive. AFAIK,
> spin_lock and co are really meant for very short time locks.
> 
>>  This
>> will allow mdelay to work correctly in the routines the set_ios() calls.
> This sounds a little bit worse. mdelay is never good, as this is
> active wait, that is loosing tons of good cpu cycles.

do not need active waiting.  Good point.

> Do we really need those? Can we do the same thing asynchronous?

This might be possible without a restructure to separate out all the sub-calls that are
done in set_ios. Otherwise  we would require a restructure of the code in core/ to not use
set_ios but to call only the function they need via separate call in's.
(for example setting the width or power) and the associated changes in all the drivers in host.

Rather then do mdelay we could use:  (code from core.h)

static inline void mmc_delay(unsigned int ms)
{
	if (ms < 1000 / HZ) {
		cond_resched();
		mdelay(ms);
	} else {
		msleep(ms);
	}
}

Since the whole point of locking out the one interrupt line is to let everything else
work this look attractive.   -- Opintions Please --

> 
>> 
>> The pm_ calls  remove the lock before being called and restore it afterwards.  Is this just to ensure interrupts are globally
>> enabled ?
> At least on my platform, pm_ calls cannot be done in atomic context,
> and sdhci runtime_pm flow will call set_ios() back, so you will
> re-enter the function.

ok

> 
>>  If so, I can simplify my patch deleting the original spin_lock calls that surround the pm_ calls.
> No, you cannot safely remove the spin_lock calls here.

ok

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


[Index of Archives]     [Linux USB Devel]     [Linux Media]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux