Thomas Renninger wrote:
On Wednesday 08 October 2008 12:48:36 Thomas Lindroth wrote:
Alexey Starikovskiy wrote:
Alexey Starikovskiy wrote:
This is AML implementation of EC driver... it relies on certain speed
of AML interpreter to work properly (look for Noop inserted as delay).
It is possible to replace this driver with the native Linux one, which
might be
more robust, but this involves heavy DSDT hacking.
Overall, it is heavily mis-designed BIOS, so don't expect it to be
fixed on Linux side.
Regards,
Alex.
Please check if making Noop a small delay helps
I've tried the patch with an udelay of 100 but it did not make any
difference. I've also tried raising it to 200 but that created an
unbootable system because one of the ACPI init methods failed.
You are right, this is a really broken BIOS.
I find it odd that only I experience this problem. According to one
site this laptop is the 7:th most popular laptop right now so someone
else should have reported something.
T7 is not very popular setting :)
Could you provide a short explanation what should be fixed in which way in the
BIOS tables. Best in a way that I can just forward this.
It's hard in the laptop area to convince fsc to fix it, but I at least like to
try and to tell them.
Hmm, I think the last two mails should already be enough, I think I got it.
As I understand, this is not FSC, but FIC outsource. There is exactly
same thing happening in new FIC laptop.
Is there a general hint I could add into the ACPI Linux guideline, like:
Don't implement EC data/index register reads/writes in AML yourself.
Define a EC variable and e.g. use Store(ECXY, Local0) to read and
Store(Local0, ECXY) to write to specific EC bytes.
Declare EC interface might be a better wording.
Did I get this right?
Yes.
My understanding is that Windows does not support 2 EC devices, so
these people need to implement second in AML.
So, it might be worth noting that Linux can handle any number of EC devices.
Regards,
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
