[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <200803040144.09601.david-b@pacbell.net>
Date: Tue, 4 Mar 2008 01:44:09 -0800
From: David Brownell <david-b@...bell.net>
To: Pierre Ossman <drzeus-mmc@...eus.cx>
Cc: Alan Stern <stern@...land.harvard.edu>,
"Rafael J. Wysocki" <rjw@...k.pl>,
pm list <linux-pm@...ts.linux-foundation.org>,
Zdenek Kabelac <zdenek.kabelac@...il.com>,
Kernel development list <linux-kernel@...r.kernel.org>
Subject: Re: Bugs in MMC [was: [Bug 10030] Suspend doesn't work when SD card is inserted]
On Monday 03 March 2008, Pierre Ossman wrote:
> On Mon, 3 Mar 2008 13:59:37 -0800
> David Brownell <david-b@...bell.net> wrote:
>
> >
> > 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.
> > I think hosts need to be able to call mmc_detect_change() as soon as
> > they see a stable signal. The MMC core can hold off handling that
> > for a while, if it needs to wait until the code walking the device
> > tree gets around to resuming that host. It's a lot more natural to
> > hold off such stuff one time there than in N host drivers; especially
> > since the MMC core already has such hold-off code.
> >
>
> That actually sorts itself out as the MMC core reprobes on wakeup, but
> I see your point. Right now things will work peachy if the controllers
> just make sure to disable their card detection logic before telling the
> core to suspend.
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.
- Dave
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists