lkml.org 
[lkml]   [2008]   [Mar]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: Bugs in MMC [was: [Bug 10030] Suspend doesn't work when SD card is inserted]
Date

> > > > Card insert/remove events can be system wake events though. Which
> > > > makes that restriction impractical.
> >
> > This part seems to be ignored by your comment ... wake events.
>
> How so? How is a wake caused by the MMC controller different
> than any other source?

They aren't. Which is part of why the way MMC currently assumes that
insert/remove events don't work is a problem.


> > That is, the MMC core doesn't understand wakeup events.
> >
> > Or, as pointed out elsewhere, well-behaved MMC hosts ... which don't
> > need either such reprobing or the associated remove-on-suspend.
>
> You need well behaved _systems_, not just hosts to achieve that
> guarantee.

Sure, but a host can't be well behaved all by itself!

And in any case, I had already made clear I was talking
about _systems_ that behave properly.


> SDHCI controllers have the ability to wake up the
> system on card removal, but there is zero guarantee that the
> platform actually wired the controller up in a way that actually
> allows it to do this. Throw suspend to disk, where the system might
> completely lose power, into the mix and you're completely screwed.

I'm talking about generic MMC/SD controllers of the type
that have been around for years ... on systems which won't
use hibernation ("suspend to disk"), but do use real system
sleep states where card detection (by IRQs) works.


> So for the default behaviour to change, we need one of two things:
>
> - Certainty that removals cannot go unnoticed. (even then, you
> also need wakeup latency guarantees)
> - Ability to detect a removal after the fact.
>
> For the general case, the first one is impossible given todays
> hardware.

Odd that it's very possible on the systems I mentioned.


> The second might be solvable, but noone has done the work.

I don't know what you mean by "detect a removal after
the fact", or why it'd be needed if you detected it
in the first place.


> (If your complete system can satisfy the first option, feel
> free to add the "unsafe" option to you defconfig, but that is
> hardly adequate reason to have it on by default.)

Thing is, I had also pointed out that it wasn't "unsafe"
in the least on many systems.

I'll refresh the patch which improves that mechanism and
updates its description.

- Dave


\
 
 \ /
  Last update: 2008-03-06 22:27    [W:2.063 / U:0.520 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site