On Thu, 2008-09-04 at 02:28 +0400, Alexey Starikovskiy wrote:
> Hi Yakui,
>
> Zhao Yakui wrote:
> >> If you _disable_ EC GPE or not enable it in first place, EC(hardware) will be working in
> >> poll mode. So, there is no spare code to clean up, sorry.
> > Not understand what you said.
> It seems to be not my problem...
> > After your three patches hit the upstream kernel, the EC GPE is still
> > enabled when EC timeout happens. In such case when EC is accessed, EC
> > will work in polling mode. At the same time EC GPE interrupt still can
> > be triggered.
> One of my patches adds option to not enable EC GPE (ec_intr=0), so it is
> possible to run EC driver in hardware poll mode, and all the code for such
> operation is needed. I do not know how to say it in simpler terms, sorry.
> If it is still unclear, please consult with Len...
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.
Accorind to ACPI spec 3.0b, the embedded controller must generate SCIs for commands as follows:
• Read Command (3 Bytes)
Byte #1 (Command byte Header) Interrupt on IBF=0
Byte #2 (Address byte to read) No Interrupt
Byte #3 (Data read to host) Interrupt on OBF=1
• Write Command (3 Bytes)
Byte #1 (Command byte Header) Interrupt on IBF=0
Byte #2 (Address byte to write) Interrupt on IBF=0
Byte #3 (Data to read ) Interrupt on IBF=0
• Query Command (2 Bytes)
Byte #1 (Command byte Header) No Interrupt
Byte #2 (Query value to host) Interrupt on OBF=1
• Burst Enable Command (2 Bytes)
Byte #1 (Command byte Header) No Interrupt
Byte #2 (Burst acknowledge byte) Interrupt on OBF=1
• Burst Disable Command (1 Byte)
Byte #1 (Command byte Header) Interrupt on IBF=0
But from the log in comment #46 of bug8459 and comment #26 of bug 11428
we can get the following info:
a. In the course of read command, EC GPE interrupt is triggered only
after read command is issued. Sometimes there is no interrupt after OBF
becomes 1(data ready and Host can read it).
b. In the course of query command, sometimes there is no interrupt
after OBF becomes 1(data ready).
c. In the course of burst disable command, sometimes there is no
interrupt after burst disable command is issued although the IBF is
already zero.(Input buffer is empty)
>From the above log we can know that the EC status is already what OS
expected although there is no interrupt confirmation in some cases. For
example: When issuing read/query command, the OBF already becomes
one(Data ready). When issuing the burst disable command, the IBF already
becomes zero.(EC input buffer is empty). It means that EC still can
work well by polling EC status to check whether it is what OS expected.
And I believe that is valid for all laptops. If the OBF and IBF can't
reflect the EC status correctly, the windows also can't work well.
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.
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.
>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
