[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20100601122012.1edeaf48@notabene.brown>
Date: Tue, 1 Jun 2010 12:20:12 +1000
From: Neil Brown <neilb@...e.de>
To: Thomas Gleixner <tglx@...utronix.de>
Cc: "Rafael J. Wysocki" <rjw@...k.pl>,
Alan Stern <stern@...land.harvard.edu>,
Felipe Balbi <felipe.balbi@...ia.com>,
Arve Hjønnevåg <arve@...roid.com>,
Peter Zijlstra <peterz@...radead.org>,
"Paul@...p1.linux-foundation.org" <Paul@...p1.linux-foundation.org>,
LKML <linux-kernel@...r.kernel.org>,
Florian Mickler <florian@...kler.org>,
Linux OMAP Mailing List <linux-omap@...r.kernel.org>,
Linux PM <linux-pm@...ts.linux-foundation.org>,
Alan Cox <alan@...rguk.ukuu.org.uk>
Subject: Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
On Tue, 1 Jun 2010 03:49:37 +0200 (CEST)
Thomas Gleixner <tglx@...utronix.de> wrote:
> On Tue, 1 Jun 2010, Neil Brown wrote:
> > And if you are right that the race window cannot be closed, then the whole
> > suspend-blocker infrastructure is pointless as the purpose of it is simply to
> > close that window. If it really does not and cannot work, then it would be
> > best to reject it for that reason rather than for less concrete aesthetic
> > arguments.
> > But presumably it does work in practice on Android hardware so ..... confused.
> >
> > Having just seen the email from Thomas, maybe you mean that it cannot be
> > closed on devices using ACPI, but can on other devices. I can sort-of
> > imagine how that would be the case (I tried reading an ACPI spec once - my
> > hat is of to those of you who understand it).
> > That shouldn't prevent us from closing the race window on "sane" hardware
> > that allows it. This would, I think, be sufficient for Android's needs.
> >
> > I'm hoping we can get agreement on:
> > - there is a race with suspend
>
> That's a matter of how you define "suspend".
I define "suspend" as
echo mem > /sys/power/state
>
> If "suspend" is another deep idle state and the hardware is sane,
> there is no race at all - assumed that the driver/platform developer
> got it right. It's not rocket science to transition from "normal" irq
> delivery to wakeup based delivery raceless (except for PC style x86
> hardware of today)
>
> If "suspend" is the thing we are used to via /sys/power/state then the
> race will persist forever except for the suspend blocker workaround,
> which we can express in QoS terms as well w/o adding another suspend
> related user space API.
I'm not interested in adding another user-space API if it can possibly be
avoided, and I think it can. But that is a later step in the process.
I think you have acknowledged that there is a race with suspend - thanks.
Next step was "can it be closed".
You seem to suggest that it can, but you describe it as a "work around"
rather than a "bug fix"...
Do you agree that the race is a "bug", and therefore it is appropriate to
"fix" it assuming an acceptable fix can be found (which I think it can)?
If you agree that it is appropriate for try to fix this bug, then the next
step would be to get the Android devs to agree that a fix could - in
principle - address the need for which they created suspend-blockers.
Arve: can you confirm that?
Then, with a clear and agreed goal, we can look at possible fixes.
Thanks,
NeilBrown
>
> Thanks,
>
> tglx
--
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