Shaohua,
There is cond_resched() before the exit from deferred execution routine,
specifically to let notify thread a chance to execute.
Thus by the time deferred execution is exited, notify should be already
done,
and we could safely enable _Lxx again.
Do you think it is not sufficient?
Regards,
Alex.
Li, Shaohua wrote:
Bob & Ming,
I'm working on adding wakeup GPE support at system runtime, this
capability can help us
Identify which device invokes a wakeup event at runtime, this is
required for runtime device
Power management.
Below is the ASL code. For example, _L0c, USB3 will send a wakeup GPE
and invoke
a notify. In the notify handler, OS will clear USB3's PCI PME status to
avoid wakeup
event flood. But in current code, acpi_ev_asynch_execute_gpe_method will
start an asynchronous
execution of notify and return soon. Just before the return,
acpi_ev_asynch_execute_gpe_method
will reenable GPE 0C. That means GPE is enabled before OS execute
notification handler and USB3's
PCI PME status is cleared, and cause GPE flood. Ideally, I think we
should delay GPE enable
of _L0c till notification handler is finished or simply the method _L0c
is really finished.
What do you think?
Thanks,
Shaohua
Method (_L0C, 0, NotSerialized)
{
Notify (\_SB.PCI0.USB3, 0x02)
}
Method (_L0D, 0, NotSerialized)
{
Notify (\_SB.PCI0.USB7, 0x02)
}
Method (_L0E, 0, NotSerialized)
{
Notify (\_SB.PCI0.USB4, 0x02)
}
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
