[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160610203210.GA2262@nest>
Date: Fri, 10 Jun 2016 23:32:10 +0300
From: Andrey Skvortsov <andrej.skvortzov@...il.com>
To: Lv Zheng <lv.zheng@...el.com>, Bob Moore <robert.moore@...el.com>,
"Rafael J. Wysocki" <rafael.j.wysocki@...el.com>,
linux-acpi@...r.kernel.org, devel@...ica.org,
linux-kernel@...r.kernel.org
Subject: acpi: broken suspend to RAM with v4.7-rc1
Hi,
On my laptop (DELL Vostro 1500) in v4.7-rc1 is broken suspend to RAM.
Laptop doesn't finish suspend to RAM process (disks are off, but WiFi
and Power LEDs are still on). The only way to get it out of this
state, is to turn the power off.
I've bisected the issue to commit 66b1ed5aa8dd25
[ACPICA: ACPI 2.0, Hardware: Add access_width/bit_offset support for acpi_hw_write()].
If I revert this commit in v4.7-rc1 (or v4.7-rc2), suspend to RAM is
working again.
The cause of this problem is that after this commit write to PM1A Control Block
(16-bit register) is done using two 8-bit writes. If I force this write
to be 16-bit, then all is working as before.
To get it working 'access_width' for PM1A Control Block needs to be 2 (16-bit), but it's
1 (8-bit).
The root of the problem seems to be not the commit 66b1ed5aa8dd25 itself, but the ACPI
tables in BIOS where wrong access_width comes from. I fixed problem in FACP table,
put it in initrd to override FACP table from BIOS. This fixed the issue,
suspend to RAM is working now again.
But I'm not sure whether is this proper fix for this problem.
Is there any place in the kernel, where such ACPI quirks are placed?
--
Best regards,
Andrey Skvortsov
Download attachment "signature.asc" of type "application/pgp-signature" (802 bytes)
Powered by blists - more mailing lists