> > What's the purpose of the card-counting loop in
> > host/omap.c:mmc_omap_switch_handler()? It looks like dead code.
> >
>
> I'm not too familiar with that driver, but they've been playing around
> with multiplexing several cards into one controller. Might be bits and
> pieces of that.
>
On Mon, 25 Feb 2008, Pierre Ossman wrote:
> > What do you think of the patch attached to comment #40 in the Bugzilla
> > entry?
> >
>
> Looks ok. As long as those two synchronization points are guaranteed,
> then I'm happy.
Maybe a better approach would be to leave the workqueue unfreezable,
On Mon, 25 Feb 2008 12:58:30 -0500 (EST)
Alan Stern <[EMAIL PROTECTED]> wrote:
> Thanks for the explanations.
>
> On Mon, 25 Feb 2008, Pierre Ossman wrote:
>
> > Trying to keep up with the PM changes is a full time job. For now I've
> > mostly ignored it as I don't even have time for the other
Thanks for the explanations.
On Mon, 25 Feb 2008, Pierre Ossman wrote:
> Trying to keep up with the PM changes is a full time job. For now I've
> mostly ignored it as I don't even have time for the other stuff.
> Patches welcome.
What do you think of the patch attached to comment #40 in the
On Sun, 24 Feb 2008 10:33:34 -0500 (EST)
Alan Stern <[EMAIL PROTECTED]> wrote:
>
> Well, the patch itself isn't really adequate; it was just a first pass
> intended to illustrate the nature of the problem.
>
> The problems in the MMC subsystem go deeper.
>
> The first is the way it uses
On Sun, 24 Feb 2008 10:33:34 -0500 (EST)
Alan Stern [EMAIL PROTECTED] wrote:
Well, the patch itself isn't really adequate; it was just a first pass
intended to illustrate the nature of the problem.
The problems in the MMC subsystem go deeper.
The first is the way it uses
Thanks for the explanations.
On Mon, 25 Feb 2008, Pierre Ossman wrote:
Trying to keep up with the PM changes is a full time job. For now I've
mostly ignored it as I don't even have time for the other stuff.
Patches welcome.
What do you think of the patch attached to comment #40 in the
On Mon, 25 Feb 2008 12:58:30 -0500 (EST)
Alan Stern [EMAIL PROTECTED] wrote:
Thanks for the explanations.
On Mon, 25 Feb 2008, Pierre Ossman wrote:
Trying to keep up with the PM changes is a full time job. For now I've
mostly ignored it as I don't even have time for the other stuff.
On Mon, 25 Feb 2008, Pierre Ossman wrote:
What do you think of the patch attached to comment #40 in the Bugzilla
entry?
Looks ok. As long as those two synchronization points are guaranteed,
then I'm happy.
Maybe a better approach would be to leave the workqueue unfreezable,
and keep
snip
What's the purpose of the card-counting loop in
host/omap.c:mmc_omap_switch_handler()? It looks like dead code.
I'm not too familiar with that driver, but they've been playing around
with multiplexing several cards into one controller. Might be bits and
pieces of that.
AFAIK,
On Sun, 24 Feb 2008, Rafael J. Wysocki wrote:
> > In fact this turns out to be exactly the problem with the MMC
> > subsystem. It uses a dedicated workqueue (kmmcd) to handle state
> > changes, and mmc_suspend_host() does a flush_workqueue(). If the
> > workqueue contains an entry to register
On Sun, 24 Feb 2008, Rafael J. Wysocki wrote:
In fact this turns out to be exactly the problem with the MMC
subsystem. It uses a dedicated workqueue (kmmcd) to handle state
changes, and mmc_suspend_host() does a flush_workqueue(). If the
workqueue contains an entry to register or
12 matches
Mail list logo
