On Tue, 1 Jun 2010 12:20:12 +1000
Neil Brown <[email protected]> wrote:
> On Tue, 1 Jun 2010 03:49:37 +0200 (CEST)
> Thomas Gleixner <[email protected]> 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
> > > 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,
True, because device wakeups are enabled
by device.driver.suspend() methods, which are
invoked towards the end of the activities
triggered by writing /sys/power/state.
Now, there can be platforms (mostly embedded)
where the drivers adopt a policy that not only
do they keep their devices in as low a power
state as practical at all times, but they also
keep the hardware wakeup mechanisms enabled (they
may be needed to kick the hardware out of those
low power states) ... That is, suspend() might be
superfluous (a NOP) in those platforms' drivers.
Such platforms might also be (non-ACPI) ones
where idle C-states and S3/STR have the same
power consumption ... but that would be a
platform-specific issue, not a generic thing
which all Linux implementations could rely on.
- Dave