Comment 231 for bug 1283589
Revision history for this message
|
|
#231 |
© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
0e1f616
(Get the code!)
Hi, Kieran
(In reply to Kieran Clancy from comment #196)
> Note that I also reported this on the mailing lists 4 weeks ago, not sure
> why that was missed.
>
> Lv, I disagree that we need to implement GPE polling in a new kernel thread.
> It was working perfectly without that before the two recent patches. It
> simply needs to be cleared on boot or resume from suspend. After that, the
> interrupts work fine as intended.
Threaded IRQ is very common in Linux, please see kernel/
Software has reasons to do so.
IMO, Windows might already handle EC events in both "polling" and "interrupt" modes, so it doesn't suffer from such firmware variants.
If we switched our driver into this mode, then we needn't do additional "drain" after resuming.
OTOH, ec-flush1.patch ensures that the following commit won't affect Samsung laptops.
"ACPI / EC: Add support to disallow QR_EC to be issued when SCI_EVT isn't set"
https:/
If ec-flush1.patch cannot fix everything, we should check what the following commit brings to us:
"ACPI / EC: Add support to disallow QR_EC to be issued before completing previous QR_EC"
https:/
This commit only ensures there's only one query running. If it must be reverted, then it means Samsung laptops need multiple queries to be issued in an out of control way - which sounds like a "happen to work" environment.
We shouldn't go back to a "happen to work" environment where bugs could be hidden by the hidden logics.