|
From: Dmitry T. <dto...@am...> - 2004-11-17 07:58:27
|
On Wednesday 17 November 2004 02:10 am, Li, Shaohua wrote:
> >On Tuesday 16 November 2004 10:37 am, Andi Kleen wrote:
> >> > For detail, please refer to ACPI spec :
> >> > 12 ? ACPI Embedded Controller Interface Specification.
> >>
> >> Ok. But the problem is not the actual write, but the waiting
> >> for the event which takes extremly long on these machines
> >> (it's not a single broken machine, but has been observed
> >> on several VIA based laptops). Would it work to only disable
> >> interrupts during the register write/read, but not during the
> >> polling delay?
> >
> >Actually, the proper solution would be to get rid of polling entirely,
> >like in the patch below. Could anyone with a box with EC verify that
> >it works?
> >
> >Btw, what's up with initializing every variable in ACPI code? It is
> >not free after all...
> >
> I agree the right solution should be to stop polling, but did you look
> at the comments in ec.c (line 361)? It said some systems can't work with
> asynchronous mode.
>
Hmm... Let's see. We can only have 1 reader/writer active at the same time
per EC becuase they are serialized via ec->sem. So the only thing we can
race with is SCI generated by firmware in response to external factors.
So I guess we still need sleep-polling in acpi_ec_query_data, something
like this:
while (unlikely(down_trylock(&ec->sem))) {
/* reader or writer is waiting for completion */
value = acpi_ec_read_status(ec);
if ((value & ACPI_EC_FLAG_OBF) ||
(ec->expect_ibe && !(value & ACPI_EC_FLAG_IBF))) {
ec->expect_ibe = 0;
wake_up(&ec->wait);
}
msleep(1);
}
acpi_hw_low_level_write(8, ACPI_EC_COMMAND_QUERY, &ec->command_addr);
result = acpi_ec_wait_obf(ec);
if (result < 0)
goto end;
.....
Will this work?
--
Dmitry
|