Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Florian Mickler]

On Tue, 1 Jun 2010 12:20:12 +1000
Neil Brown <neilb@xxxxxxx> wrote:

> On Tue, 1 Jun 2010 03:49:37 +0200 (CEST)
> Thomas Gleixner <tglx@xxxxxxxxxxxxx> wrote:

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

Can you explain the difference between the /sys/power/state thing? Is
it the reprogramming of wake-sources as mentioned by Raffael?

In an idle based suspend I assume there would be no new wake-sources
on suspending.

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

Well as far as I get it, the workaround is to not suspend in sitations
where a race is likely to occur. (I.e. block suspend)

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

cheers,
Flo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/