From: Lv Zheng <zetalog@gmail.com>
To: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>,
Len Brown <len.brown@intel.com>
Cc: Lv Zheng <zetalog@gmail.com>, Lv Zheng <lv.zheng@intel.com>,
linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org
Subject: [RFC PATCH 0/6] ACPICA: 64bit FADT addresses enabling.
Date: Wed, 28 May 2014 01:27:15 +0800 [thread overview]
Message-ID: <cover.1401210684.git.lv.zheng@intel.com> (raw)
In-Reply-To: <38907770.bupFXhytsS@vostro.rjw.lan>
From: Lv Zheng <lv.zheng@intel.com>
This series enable 64-bit addresses on top of linux-pm.git/linux-next.
Commit 0249ed2444d6 (ACPICA: Add option to favor 32-bit FADT addresses.)
breaks resuming from system-suspend on the Intel DP45SG board.
This is because the commit has changed the default behavior of original
Linux. And the root cause is:
1. BIOS may favor the FACS reported via the "FIRMWARE_CTRL" field in the
FADT while the commit doesn't set the firmware waking vector address of
the FACS reported by "FIRMWARE_CTRL", it only sets the firware waking
vector address of the FACS reported by "X_FIRMWARE_CTRL" or
2. BIOS may favor the 64-bit FACS waking vector address when the version of
the FACS is greater than 0 while Linux currently only supports resuming
from the real mode, so the 64-bit firmware waking vector is not tested
and set to 0.
This patchset fixes this issue by excluding the above 2 cases and
re-enables 64-bit FADT addresses again using the following smarter way:
1. Restore old behavior of 32-bit favor for FADT;
2. To exclude cause 1:
Add 64-bit firmware waking vector setting support for selected FACS,
the 64-bit firmware waking vector favor is also controlled by the new
acpi_set_firmware_waking_vector() parameter. OSPM that supports 32-bit
waking environment can set a valid physical address here. For Linux
which only supports real mode waking environment, this should be 0.
3. Fix 32-bit FACS favor by loading both 32-bit and 64-bit FACS, the
selection of FACS is controlled by a new global option -
acpi_gbl_use32_bit_facs_addresses, which is set to TRUE to select the
FACS reported by "FIRMWARE_CTRL" field. Add firmware waking vector
setting support for both 32-bit and 64-bit FACS. This is used to work
around the reported platform where 2 FACS is reported in the FADT;
4. Restore new behavior of 64-bit favor for FADT.
So that it is ensured that the 32-bit firmware waking vector address of the
FACS reported by "FIRMWARE_CTRL" filed is still set after enabling 64-bit
FADT addresses favor.
To enable X_FIRMWARE_CTRL favor and 64-bit firmware waking vector favor,
OSPMs are required to set acpi_gbl_use32_bit_facs_addresses to FALSE and
pass a valid 64-bit firmware waking vector address for
acpi_set_firmware_waking_vector() invocations, thus now the FACS favor and
the 64-bit firmware waking vector support can be completely controlled by
OSPMs and ACPICA does not make any decision silently.
Lv Zheng (6):
ACPICA: Hardware: Reduce divergences for sleep functions.
ACPICA: Hardware: Enable 64-bit firmware waking vector for selected
FACS.
ACPI: sleep: Update acpi_set_firmware_waking_vector() invocations to
favor 32-bit firmware waking vector.
ACPICA: Tables: Enable both 32-bit and 64-bit FACS.
ACPICA: Hardware: Enable firmware waking vector for both 32-bit and
64-bit FACS.
ACPICA: Tables: Enable default 64-bit FADT addresses favor.
arch/ia64/include/asm/acpi.h | 1 +
arch/x86/include/asm/acpi.h | 3 +-
drivers/acpi/acpica/acglobal.h | 2 +
drivers/acpi/acpica/aclocal.h | 1 +
drivers/acpi/acpica/hwxfsleep.c | 83 +++++++++++++++++++++++++--------------
drivers/acpi/acpica/tbfadt.c | 21 ++++++----
drivers/acpi/acpica/tbutils.c | 37 +++++++++++------
drivers/acpi/acpica/tbxfload.c | 3 +-
drivers/acpi/sleep.c | 8 +++-
include/acpi/acpixf.h | 24 ++++++-----
10 files changed, 121 insertions(+), 62 deletions(-)
--
1.7.10
next prev parent reply other threads:[~2014-05-27 17:27 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-12 0:11 [PATCH] ACPICA: Revert "ACPICA: Add option to favor 32-bit FADT addresses." Rafael J. Wysocki
2014-05-12 1:10 ` Zheng, Lv
2014-05-12 8:51 ` Zheng, Lv
2014-05-13 0:09 ` Rafael J. Wysocki
2014-05-13 1:05 ` Zheng, Lv
2014-05-13 1:30 ` Rafael J. Wysocki
2014-05-13 4:54 ` Zheng, Lv
2014-05-13 8:50 ` [PATCH] Tables: Restore old behavor to favor 32-bit FADT addresses Lv Zheng
2014-05-26 13:06 ` Rafael J. Wysocki
2014-05-27 17:27 ` Lv Zheng [this message]
2014-05-27 17:27 ` [RFC PATCH 1/6] ACPICA: Hardware: Reduce divergences for sleep functions Lv Zheng
2014-05-29 10:24 ` Oswald Buddenhagen
2014-05-30 2:15 ` Zheng, Lv
2014-05-27 17:27 ` [RFC PATCH 2/6] ACPICA: Hardware: Enable 64-bit firmware waking vector for selected FACS Lv Zheng
2014-05-27 17:28 ` [RFC PATCH 3/6] ACPI: sleep: Update acpi_set_firmware_waking_vector() invocations to favor 32-bit firmware waking vector Lv Zheng
2014-05-27 17:28 ` [RFC PATCH 4/6] ACPICA: Tables: Enable both 32-bit and 64-bit FACS Lv Zheng
2014-05-27 17:28 ` [RFC PATCH 5/6] ACPICA: Hardware: Enable firmware waking vector for " Lv Zheng
2014-05-27 17:29 ` [RFC PATCH 6/6] ACPICA: Tables: Enable default 64-bit FADT addresses favor Lv Zheng
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=cover.1401210684.git.lv.zheng@intel.com \
--to=zetalog@gmail.com \
--cc=len.brown@intel.com \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lv.zheng@intel.com \
--cc=rafael.j.wysocki@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).