Comment 237 for bug 1283589

(In reply to Ortwin Glück from comment #213)
> (In reply to Lv Zheng from comment #211)
> I tested both kernels and couldn't see any difference. The power plug
> detection always worked. But LID switch didn't.

What do you mean by both?
This - vanilla linux-pm/linux-next + ec-flush{1,2,3,4,5,6}.patch - and which one?

Without timely polling, I think any kernel, even backing to where the Kieran's quirk is first introduced, will still have issues.
Because, Samsung EC will not flag SCI_EVT as long as there is already events queued up.

So IMO, during runtime, we can only allow up to 2 events queued up. While doing testing, frequent actions could cause many events to be queued up, and our EC driver will surely cannot prepare QR_EC from 3rd events because at that time, SCI_EVT surely will not be flagged:
[ +event 1 ] SCI_EVT set
[ +event 2 ]
[ +event 3 ]
                           1st QR_EC
                           can prepare 2nd QR_EC because SCI_EVT=1
                           event returned
[ -event 1 ] SCI_EVT clear
                           2nd QR_EC
                           event returned
                           cannot prepare 3rd QR_EC because SCI_EVT=0
[ -event 2 ] SCI_EVT clear
So IMO, only sending QR_EC timely without checking SCI_EVT or draining events until 0x0 returned can fix this.

Thus I guess the test result depends on how frequently you trigger EC events.

> However, due to another regression I get a dark screen after resume, so I
> shut down cleanly (hacking blindly) and rebooted into the same kernel and
> tested if the events work.

Do you mean currently we are not able to confirm if the patchset can solve old problems because a regression prevents the suspend/resume from working?
I also noticed using linux-3.18-rc1, I could not perform suspend/resume any more. All my local tests are done using patched linux-3.17-rc4.
Maybe other guys here have platforms that are not suffered from this regression.