Zhao Yakui wrote:
Hi, Alexey
After investigation I found that the laptop in bug 11428 is the same
as that in bug 8459. Is the EC on such laptop that you mean "optimized"
EC? But in fact the OBF and IBF can reflect the EC status correctly
although sometimes there is no GPE interrupt confirmation.
Why you use "but in fact" here? There is no reason to repeat to me my own
findings as a "new truth"...
At the same time maybe EC will send a notification event requiring OS's
attention. In such case OS can detect whether the notification event is
sent by checking the SCI_EVT bit in the EC GPE interrupt service
routine.(I.E . acpi_ec_gpe_handler). In fact only checking notification
event in ec gpe handler is enough to make EC work.
If so, the EC work flowchart will become very simple. I will try to
write this patch and consult with Len.
You just described software poll mode of EC driver,
"missing confirmations" are the switch from pure interrupt mode to "the
poll for IBF/OBF changes, but expect interrupt for SCI change".
Do you plan to drop pure interrupt mode now?
There is another issue. From the log in comment #26 of bug 11428 I find
that OS still issues the burst disable command although EC already exits
the burst mode. Maybe we should check whether the EC is in burst mode
before issuing EC burst disable command.
Does it hurt?
>ACPI: EC: transaction start
>[ 124.540016] ACPI: EC: <--- command = 0x83
>[ 124.540016] ACPI: EC: ---> status = 0x0a
>[ 124.542009] ACPI: EC: ---> status = 0x08
>[ 124.542009] ACPI: EC: transaction end
Thanks.
Alex.
--
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
