diff options
author | Thomas Renninger <trenn@suse.de> | 2010-10-21 18:24:57 +0200 |
---|---|---|
committer | Len Brown <len.brown@intel.com> | 2010-10-22 01:21:30 -0400 |
commit | 7a18e96dcbdec3c96876444ae2c7e36ce458e151 (patch) | |
tree | c4a8ed0442eba1035fb7420f8598c955b1735032 /crypto/cast6.c | |
parent | f6f94e2ab1b33f0082ac22d71f66385a60d8157f (diff) | |
download | op-kernel-dev-7a18e96dcbdec3c96876444ae2c7e36ce458e151.zip op-kernel-dev-7a18e96dcbdec3c96876444ae2c7e36ce458e151.tar.gz |
ACPI: Make Embedded Controller command timeout delay configurable
Here and then there show up machines which need higher timeout values.
Finding this on affected machines can be cumbersome, because
ACPI_EC_DELAY is a compile option -> make it configurable via boot param.
This can even be provided writable at runtime via:
/sys/modules/acpi/parameters/ec_delay
Known machines where this helps:
Some HP machines where for whatever reasons specific EC accesses take
very long at resume from S3 (in _WAK function).
The AE_TIME error is passed upwards and the ACPI interpreter will
not execute the rest of the _WAK function which results in not properly
initialized devices/variables with different side-effects.
Afaik, on some MSI machines this helped as well.
If this param is needed there probably are underlying problems like:
- EC firmware bug
- A kernel EC driver bug
- An ACPI interpreter behavior (e.g. timings when specific
EC accesses happen and how) which the EC does not like
- ...
which should get evaluated further, but often are nasty or
impossible to fix from OS side.
Signed-off-by: Thomas Renninger <trenn@suse.de>
Signed-off-by: Len Brown <len.brown@intel.com>
Diffstat (limited to 'crypto/cast6.c')
0 files changed, 0 insertions, 0 deletions