All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrey Skvortsov <andrej.skvortzov@gmail.com>
To: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Cc: Lv Zheng <lv.zheng@intel.com>, Bob Moore <robert.moore@intel.com>,
	"Rafael J. Wysocki" <rafael.j.wysocki@intel.com>,
	linux-acpi@vger.kernel.org, devel@acpica.org,
	linux-kernel@vger.kernel.org
Subject: Re: acpi: broken suspend to RAM with v4.7-rc1
Date: Sat, 11 Jun 2016 13:49:22 +0300	[thread overview]
Message-ID: <20160611104922.GA2368@nest> (raw)
In-Reply-To: <3027571.8eTQaleASL@vostro.rjw.lan>

[-- Attachment #1: Type: text/plain, Size: 2398 bytes --]

On 10 Jun, Rafael J. Wysocki wrote:
> On Friday, June 10, 2016 11:32:10 PM Andrey Skvortsov wrote:
> > 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_h=
> > w_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 B=
> > lock
> > (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-b=
> > it), but it's=20
> > 1 (8-bit).
> > 
> > The root of the problem seems to be not the commit 66b1ed5aa8dd25 itself, b=
> > ut 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?
> 
> Well, if the commit in question caused a problem to happen for you, it also
> might cause similar problems to happen elsewhere.
> 
> It looks like we'll need to revert that commit.
Hi,

or maybe to reset access_width AnyAcc from FACP table only for PM1A control
register or even for all registers? This will fix the issue too.

diff --git a/drivers/acpi/acpica/tbfadt.c b/drivers/acpi/acpica/tbfadt.c
index 6208069..a476e94 100644
--- a/drivers/acpi/acpica/tbfadt.c
+++ b/drivers/acpi/acpica/tbfadt.c
@@ -714,7 +714,14 @@ static void acpi_tb_setup_fadt_registers(void)
                        }
                }
        }

+       /*
+        * Reset access_width in the GAS for PM1A control register to
+        * undefined value. Because in some cases this field contains
+        * wrong value.
+        */
+       acpi_gbl_FADT.xpm1a_control_block.access_width = 0;


-- 
Best regards,
Andrey Skvortsov



[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

  reply	other threads:[~2016-06-11 10:49 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-10 20:32 acpi: broken suspend to RAM with v4.7-rc1 Andrey Skvortsov
2016-06-10 21:24 ` Rafael J. Wysocki
2016-06-11 10:49   ` Andrey Skvortsov [this message]
2016-06-11 11:56     ` Rafael J. Wysocki
2016-06-11 11:56       ` Rafael J. Wysocki
     [not found]       ` <744357E9AAD1214791ACBA4B0B9092633AA54819@SHSMSX101.ccr.corp.intel.com>
2016-06-13  8:50         ` [Devel] " Zheng, Lv
2016-06-13  8:50           ` Zheng, Lv
2016-06-13 10:07           ` Andrey Skvortsov
2016-06-15  0:24             ` Rafael J. Wysocki
2016-06-15  6:05               ` [Devel] " Zheng, Lv
2016-06-15  6:05                 ` Zheng, Lv
2016-06-15 20:02                 ` Andrey Skvortsov
2016-06-24  1:02             ` [Devel] " Zheng, Lv
2016-06-24  1:02               ` Zheng, Lv
2016-06-24 21:32               ` Andrey Skvortsov
2016-06-27  1:17                 ` [Devel] " Zheng, Lv
2016-06-27  1:17                   ` Zheng, Lv
2016-06-27  8:49                   ` Andrey Skvortsov
2016-08-05  1:06                 ` [Devel] " Zheng, Lv
2016-08-05  1:06                   ` Zheng, Lv
2016-08-10 17:51                   ` Andrey Skvortsov
  -- strict thread matches above, loose matches on Subject: below --
2016-06-28  5:10 [Devel] " Zheng, Lv
2016-06-28  5:10 ` Zheng, Lv

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160611104922.GA2368@nest \
    --to=andrej.skvortzov@gmail.com \
    --cc=devel@acpica.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lv.zheng@intel.com \
    --cc=rafael.j.wysocki@intel.com \
    --cc=rjw@rjwysocki.net \
    --cc=robert.moore@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.