From: Mark Rutland <mark.rutland(a)arm.com>
We currently do an ldr from GICC_CTLR to w0, then immediately overwrite
w0 with a mov. Reading the GICC_CTLR has no effect on the state of the
GIC, so there's no reason to do the ldr. It's also inconsistent with the
way we set the GICD_CTLR.
Fix this.
Signed-off-by: Mark Rutland <mark.rutland(a)arm.com>
---
boot.S | 1 -
1 file changed, 1 deletion(-)
diff --git a/boot.S b/boot.S
index a1f25e2..7c28e84 100644
--- a/boot.S
+++ b/boot.S
@@ -49,7 +49,6 @@ _start:
str w0, [x1], #4
2: ldr x1, =GIC_CPU_BASE // GICC_CTLR
- ldr w0, [x1]
mov w0, #3 // EnableGrp0 | EnableGrp1
str w0, [x1]
--
1.7.9.5
On hardware reduced platforms, there is no support for the following:
- PM Event and Control registers
- SCI interrupt (and handler)
- Fixed Events
- General Purpose Events (GPEs)
- Global Lock
- ACPI PM timer
- FACS table (Waking vectors and Global Lock)
but when FACP Hardware Reduced flag is set, ACPI drivers will still access
power management registers directly which will cause oops when system booted.
acpi_gbl_reduced_hardware is a global flag and can be used to prevent
misbehavior on hardware reduced platforms, and this flag is initialized at
the very beginning of the system boot when FADT is parsed, so we can use it
to prevent accessing PM registers.
There are still lots of other places to be fixed, this is the first patch
to fix hte bug we met when --cores=1;
I will finish a patch set and send to upstream if you guys have no
objections. I think we should start a discussion in ACPI mail list for
this bug on hardware reduced platforms now.
Signed-off-by: Hanjun Guo <hanjun.guo(a)linaro.org>
---
drivers/acpi/acpica/hwregs.c | 24 ++++++++++++++++++++++++
1 file changed, 24 insertions(+)
diff --git a/drivers/acpi/acpica/hwregs.c b/drivers/acpi/acpica/hwregs.c
index 8d2e866..4c270c3 100644
--- a/drivers/acpi/acpica/hwregs.c
+++ b/drivers/acpi/acpica/hwregs.c
@@ -265,6 +265,11 @@ acpi_status acpi_hw_clear_acpi_status(void)
ACPI_FUNCTION_TRACE(hw_clear_acpi_status);
+ /* If Hardware Reduced flag is set, there are no GPEs */
+ if (acpi_gbl_reduced_hardware) {
+ return_ACPI_STATUS(AE_NOT_IMPLEMENTED);
+ }
+
ACPI_DEBUG_PRINT((ACPI_DB_IO, "About to write %04X to %8.8X%8.8X\n",
ACPI_BITMASK_ALL_FIXED_STATUS,
ACPI_FORMAT_UINT64(acpi_gbl_xpm1a_status.address)));
@@ -305,6 +310,10 @@ struct acpi_bit_register_info *acpi_hw_get_bit_register_info(u32 register_id)
{
ACPI_FUNCTION_ENTRY();
+ if (acpi_gbl_reduced_hardware) {
+ return (NULL);
+ }
+
if (register_id > ACPI_BITREG_MAX) {
ACPI_ERROR((AE_INFO, "Invalid BitRegister ID: 0x%X",
register_id));
@@ -337,6 +346,11 @@ acpi_status acpi_hw_write_pm1_control(u32 pm1a_control, u32 pm1b_control)
ACPI_FUNCTION_TRACE(hw_write_pm1_control);
+ /* If Hardware Reduced flag is set, there are no PM Control registers */
+ if (acpi_gbl_reduced_hardware) {
+ return_ACPI_STATUS(AE_NOT_IMPLEMENTED);
+ }
+
status =
acpi_hw_write(pm1a_control, &acpi_gbl_FADT.xpm1a_control_block);
if (ACPI_FAILURE(status)) {
@@ -370,6 +384,11 @@ acpi_status acpi_hw_register_read(u32 register_id, u32 *return_value)
ACPI_FUNCTION_TRACE(hw_register_read);
+ /* If Hardware Reduced flag is set, there are no PM Control registers */
+ if (acpi_gbl_reduced_hardware) {
+ return_ACPI_STATUS(AE_NOT_IMPLEMENTED);
+ }
+
switch (register_id) {
case ACPI_REGISTER_PM1_STATUS: /* PM1 A/B: 16-bit access each */
@@ -465,6 +484,11 @@ acpi_status acpi_hw_register_write(u32 register_id, u32 value)
ACPI_FUNCTION_TRACE(hw_register_write);
+ /* If Hardware Reduced flag is set, there are no PM Control registers */
+ if (acpi_gbl_reduced_hardware) {
+ return_ACPI_STATUS(AE_NOT_IMPLEMENTED);
+ }
+
switch (register_id) {
case ACPI_REGISTER_PM1_STATUS: /* PM1 A/B: 16-bit access each */
/*
--
1.7.9.5
Hi,
Update from my side:
- have got invitation letter to US Connect
- run ACPI kernel on RTSMv8 model, environment preparation
- now working on converting PMU driver to ACPI
Tomasz
Values set within all APEI tables have no hardware meaning and
are valid combining with kernel hacks. These changes allow only
to confirm that APEI tables (HEST, ERST, BERT) are supported by
kernel and no issues were observed on arm/arm64 architectures.
Tomasz Nowicki (6):
acpi, apei, ghes: Enable APEI firmware first mode by APEI bit.
acpi, apei, hed: Add Hardware Error Device (HED) to SB bus.
acpi, apei, einj: Fill ACPI tables to enable EINJ driver.
acpi, apei: Fix EINJ and HEST tables.
acpi, apei, bert: Point to the same error block status memory region
as HEST points.
acpi, apei, erst: Point to region where we can pretend registers,
persistent sotrage.
platforms/exynos5250-arndale.acpi/bert.asl | 4 +-
platforms/exynos5250-arndale.acpi/dsdt.asl | 27 +++++
platforms/exynos5250-arndale.acpi/einj.asl | 2 +-
platforms/exynos5250-arndale.acpi/erst.asl | 34 +++----
platforms/exynos5250-arndale.acpi/hest.asl | 148 +---------------------------
platforms/foundation-v8.acpi/bert.asl | 4 +-
platforms/foundation-v8.acpi/dsdt.asl | 27 +++++
platforms/foundation-v8.acpi/einj.asl | 2 +-
platforms/foundation-v8.acpi/erst.asl | 34 +++----
platforms/foundation-v8.acpi/hest.asl | 148 +---------------------------
10 files changed, 98 insertions(+), 332 deletions(-)
--
1.7.9.5
From: Al Stone <ahs3(a)redhat.com>
I should have sent these out for comment much sooner. Once these are
in good shape, the next steps are to send patches for verifying that
the pinconf code is working properly, connecting up the GPIO interrupts
using ACPI, and then conversion of all of the pin controllers for
Arndale (this patch converts one of four).
This patch puts most of the infrastructure in place so that in the
3.11 kernel the Arndale pin controllers can be converted from FDT to
ACPI. The changes in ASL are included in a separate patch. What this
allows is for the pin controllers to be described in either FDT or ACPI
for Arndale and -- in conjunction with the ASL changes -- shows how to
describe a Samsung controller in ACPI.
Changes for v2:
-- Add patch 6 which allows compilation regardless of whether
CONFIG_ACPI is used or not
Al Stone (6):
ACPI: ARM: arndale: remove GPZ GPIO definition from DT so it can be in
ACPI
ACPI: ARM: arndale: whitelist the samsung-pinctrl driver for ACPI
ACPI: make an error message a little clearer
ACPI: improve acpi_extract_package() utility
ACPI: ARM: arndale: enable ACPI in the Samsung pinctrl driver
ACPI: ARM: arndale: add CONFIG_ACPI ifdef's to pinctrl driver
arch/arm/boot/dts/exynos5250-pinctrl.dtsi | 2 +
arch/arm/boot/dts/exynos5250.dtsi | 6 +-
drivers/acpi/acpi_platform.c | 3 +
drivers/acpi/osl.c | 2 +-
drivers/acpi/utils.c | 17 +-
drivers/pinctrl/pinctrl-samsung.c | 517 +++++++++++++++++++++++++++++-
drivers/pinctrl/pinctrl-samsung.h | 3 +
7 files changed, 536 insertions(+), 14 deletions(-)
--
1.8.3.1