On Fri, 2008-09-05 at 16:58 +0400, Alexey Starikovskiy wrote:
> Zhao Yakui wrote:
> > If the system is already switched to GPE mode, how to continue EC
> > transaction if there is no GPE interrupt confirmation in some EC
> > transaction? For example: on the laptops of bug 11428 & 8459. In fact
> > sometimes there is no EC GPE interrupt confirmation only for the last
> > step of EC transaction(OBF bit already indicates that data is ready but
> > there is no EC interrupt).
> You can't read, do you?
>
> If the interrupt does not arrive for OBF in the middle of transaction,
> transaction will be completed after the GPE_MODE is cleared in acpi_wait()
> in a poll loop below, there is even a comment for that.
Oh, I misunderstand what you have done in the patch.
But from the patch it seems that the definition of acpi_ec_wait in the
attached patch is totally different with that in upstream kernel. Right?
In the attached patch it indicates whether the transaction is finished.
But in the upstream kernel it indicates whether the EC status is already
what OS expected.
If the function definition is totally different, you had better add some
comments. Otherwise it is too difficult to understand.
Maybe your patch is right and can work well on your laptop. But the
basic working flowchart is changed a lot, maybe it had better be tested
on more laptops. At the same time you should add more comments and
descriptions. Otherwise when the regression happens, no one can make any
improvements about the EC driver.
Best regards.
Yakui.
> /* start transaction */
> acpi_ec_write_cmd(ec, command);
> >>>>> /* if we selected poll mode or failed in GPE-mode do a poll loop */
> if (force_poll ||
> !test_bit(EC_FLAGS_GPE_MODE, &ec->flags) ||
> acpi_ec_wait(ec)) {
> delay = jiffies + msecs_to_jiffies(ACPI_EC_DELAY);
> while (time_before(jiffies, delay)) {
> gpe_transaction(ec, acpi_ec_read_status(ec));
> msleep(1);
> if (ec_transaction_done(ec))
> goto end;
> }
> }
>
--
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
