* [PATCH v3 01/29] cpu: Support querying the address width
2020-03-30 23:12 [PATCH v3 00/29] dm: Add programmatic generation of ACPI tables (part A) Simon Glass
@ 2020-03-30 23:12 ` Simon Glass
2020-03-30 23:12 ` [PATCH v3 02/29] spi: Add SPI mode enums Simon Glass
` (35 subsequent siblings)
36 siblings, 0 replies; 86+ messages in thread
From: Simon Glass @ 2020-03-30 23:12 UTC (permalink / raw)
To: u-boot
Different CPUs may support different address widths, meaning the amount of
memory they can address. Add a property for this to the cpu_info struct.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
---
Changes in v3: None
Changes in v2: None
drivers/cpu/cpu_sandbox.c | 1 +
include/cpu.h | 2 ++
test/dm/cpu.c | 1 +
3 files changed, 4 insertions(+)
diff --git a/drivers/cpu/cpu_sandbox.c b/drivers/cpu/cpu_sandbox.c
index ff87e8adca3..05b384f6a45 100644
--- a/drivers/cpu/cpu_sandbox.c
+++ b/drivers/cpu/cpu_sandbox.c
@@ -19,6 +19,7 @@ int cpu_sandbox_get_info(struct udevice *dev, struct cpu_info *info)
{
info->cpu_freq = 42 * 42 * 42 * 42 * 42;
info->features = 0x42424242;
+ info->address_width = IS_ENABLED(CONFIG_PHYS_64BIT) ? 64 : 32;
return 0;
}
diff --git a/include/cpu.h b/include/cpu.h
index 28dd48feb8f..6b1b6b37b3b 100644
--- a/include/cpu.h
+++ b/include/cpu.h
@@ -44,10 +44,12 @@ enum {
*
* @cpu_freq: Current CPU frequency in Hz
* @features: Flags for supported CPU features
+ * @address_width: Width of the CPU address space in bits (e.g. 32)
*/
struct cpu_info {
ulong cpu_freq;
ulong features;
+ uint address_width;
};
struct cpu_ops {
diff --git a/test/dm/cpu.c b/test/dm/cpu.c
index f5f1caef716..e6dc576ea3c 100644
--- a/test/dm/cpu.c
+++ b/test/dm/cpu.c
@@ -33,6 +33,7 @@ static int dm_test_cpu(struct unit_test_state *uts)
ut_assertok(cpu_get_info(dev, &info));
ut_asserteq(info.cpu_freq, 42 * 42 * 42 * 42 * 42);
ut_asserteq(info.features, 0x42424242);
+ ut_asserteq(info.address_width, 32);
ut_asserteq(cpu_get_count(dev), 42);
--
2.26.0.rc2.310.g2932bb562d-goog
^ permalink raw reply related [flat|nested] 86+ messages in thread* [PATCH v3 02/29] spi: Add SPI mode enums
2020-03-30 23:12 [PATCH v3 00/29] dm: Add programmatic generation of ACPI tables (part A) Simon Glass
2020-03-30 23:12 ` [PATCH v3 01/29] cpu: Support querying the address width Simon Glass
@ 2020-03-30 23:12 ` Simon Glass
2020-03-30 23:12 ` [PATCH v3 03/29] tpm: cr50: Release locality on exit Simon Glass
` (34 subsequent siblings)
36 siblings, 0 replies; 86+ messages in thread
From: Simon Glass @ 2020-03-30 23:12 UTC (permalink / raw)
To: u-boot
With ACPI we need to describe the settings of the SPI bus. Add enums to
handle this.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Wolfgang Wallner <wolfgang.wallner@br-automation.com>
---
Changes in v3: None
Changes in v2:
- Add trailing commas to enum
- Don't bracket the definitions with DM_SPI
include/spi.h | 33 +++++++++++++++++++++++++++++++++
1 file changed, 33 insertions(+)
diff --git a/include/spi.h b/include/spi.h
index 852f570eaa8..2b4929fc79d 100644
--- a/include/spi.h
+++ b/include/spi.h
@@ -66,6 +66,39 @@ struct dm_spi_slave_platdata {
#endif /* CONFIG_DM_SPI */
+/**
+ * enum spi_clock_phase - indicates the clock phase to use for SPI (CPHA)
+ *
+ * @SPI_CLOCK_PHASE_FIRST: Data sampled on the first phase
+ * @SPI_CLOCK_PHASE_SECOND: Data sampled on the second phase
+ */
+enum spi_clock_phase {
+ SPI_CLOCK_PHASE_FIRST,
+ SPI_CLOCK_PHASE_SECOND,
+};
+
+/**
+ * enum spi_wire_mode - indicates the number of wires used for SPI
+ *
+ * @SPI_4_WIRE_MODE: Normal bidirectional mode with MOSI and MISO
+ * @SPI_3_WIRE_MODE: Unidirectional version with a single data line SISO
+ */
+enum spi_wire_mode {
+ SPI_4_WIRE_MODE,
+ SPI_3_WIRE_MODE,
+};
+
+/**
+ * enum spi_polarity - indicates the polarity of the SPI bus (CPOL)
+ *
+ * @SPI_POLARITY_LOW: Clock is low in idle state
+ * @SPI_POLARITY_HIGH: Clock is high in idle state
+ */
+enum spi_polarity {
+ SPI_POLARITY_LOW,
+ SPI_POLARITY_HIGH,
+};
+
/**
* struct spi_slave - Representation of a SPI slave
*
--
2.26.0.rc2.310.g2932bb562d-goog
^ permalink raw reply related [flat|nested] 86+ messages in thread* [PATCH v3 03/29] tpm: cr50: Release locality on exit
2020-03-30 23:12 [PATCH v3 00/29] dm: Add programmatic generation of ACPI tables (part A) Simon Glass
2020-03-30 23:12 ` [PATCH v3 01/29] cpu: Support querying the address width Simon Glass
2020-03-30 23:12 ` [PATCH v3 02/29] spi: Add SPI mode enums Simon Glass
@ 2020-03-30 23:12 ` Simon Glass
2020-03-30 23:12 ` [PATCH v3 04/29] tpm: cr50: Add a comment for cr50_priv Simon Glass
` (33 subsequent siblings)
36 siblings, 0 replies; 86+ messages in thread
From: Simon Glass @ 2020-03-30 23:12 UTC (permalink / raw)
To: u-boot
At present the cr50 driver claims the locality and does not release it for
Linux. This causes problems. Fix this by tracking what is claimed, and
adding a 'remove' method.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
---
Changes in v3: None
Changes in v2: None
drivers/tpm/cr50_i2c.c | 13 +++++++++++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/tpm/cr50_i2c.c b/drivers/tpm/cr50_i2c.c
index b904a7d426e..b30f55b40d3 100644
--- a/drivers/tpm/cr50_i2c.c
+++ b/drivers/tpm/cr50_i2c.c
@@ -206,7 +206,7 @@ static int release_locality(struct udevice *dev, int force)
cr50_i2c_write(dev, addr, &buf, 1);
}
- priv->locality = 0;
+ priv->locality = -1;
return 0;
}
@@ -499,6 +499,7 @@ static int process_reset(struct udevice *dev)
static int claim_locality(struct udevice *dev, int loc)
{
const u8 mask = TPM_ACCESS_VALID | TPM_ACCESS_ACTIVE_LOCALITY;
+ struct cr50_priv *priv = dev_get_priv(dev);
u8 access;
int ret;
@@ -525,6 +526,7 @@ static int claim_locality(struct udevice *dev, int loc)
return -EPERM;
}
log_info("Claimed locality %d\n", loc);
+ priv->locality = loc;
return 0;
}
@@ -559,7 +561,11 @@ static int cr50_i2c_open(struct udevice *dev)
static int cr50_i2c_cleanup(struct udevice *dev)
{
- release_locality(dev, 1);
+ struct cr50_priv *priv = dev_get_priv(dev);
+
+ printf("%s: cleanup %d\n", __func__, priv->locality);
+ if (priv->locality != -1)
+ release_locality(dev, 1);
return 0;
}
@@ -631,6 +637,7 @@ static int cr50_i2c_probe(struct udevice *dev)
return log_msg_ret("vendor-id", -EXDEV);
}
priv->vendor = vendor;
+ priv->locality = -1;
return 0;
}
@@ -655,5 +662,7 @@ U_BOOT_DRIVER(cr50_i2c) = {
.ops = &cr50_i2c_ops,
.ofdata_to_platdata = cr50_i2c_ofdata_to_platdata,
.probe = cr50_i2c_probe,
+ .remove = cr50_i2c_cleanup,
.priv_auto_alloc_size = sizeof(struct cr50_priv),
+ .flags = DM_FLAG_OS_PREPARE,
};
--
2.26.0.rc2.310.g2932bb562d-goog
^ permalink raw reply related [flat|nested] 86+ messages in thread* [PATCH v3 04/29] tpm: cr50: Add a comment for cr50_priv
2020-03-30 23:12 [PATCH v3 00/29] dm: Add programmatic generation of ACPI tables (part A) Simon Glass
` (2 preceding siblings ...)
2020-03-30 23:12 ` [PATCH v3 03/29] tpm: cr50: Release locality on exit Simon Glass
@ 2020-03-30 23:12 ` Simon Glass
2020-03-30 23:12 ` [PATCH v3 05/29] tpm: cr50: Use the correct GPIO binding Simon Glass
` (32 subsequent siblings)
36 siblings, 0 replies; 86+ messages in thread
From: Simon Glass @ 2020-03-30 23:12 UTC (permalink / raw)
To: u-boot
Add a comment for the private structure
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
---
Changes in v3: None
Changes in v2:
- Drop the other comment change since it is already applied
drivers/tpm/cr50_i2c.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/drivers/tpm/cr50_i2c.c b/drivers/tpm/cr50_i2c.c
index b30f55b40d3..c1d2d2fa381 100644
--- a/drivers/tpm/cr50_i2c.c
+++ b/drivers/tpm/cr50_i2c.c
@@ -34,6 +34,15 @@ enum {
CR50_MAX_BUF_SIZE = 63,
};
+/**
+ * struct cr50_priv - Private driver data
+ *
+ * @ready_gpio: GPIO to use to check if the TPM is ready
+ * @irq: IRQ to use check if the TPM is ready (has priority over @ready_gpio)
+ * @locality: Currenttly claimed locality (-1 if none)
+ * @vendor: vendor: Vendor ID for TPM
+ * @use_irq: true to use @irq, false to use @ready if available
+ */
struct cr50_priv {
struct gpio_desc ready_gpio;
struct irq irq;
--
2.26.0.rc2.310.g2932bb562d-goog
^ permalink raw reply related [flat|nested] 86+ messages in thread* [PATCH v3 05/29] tpm: cr50: Use the correct GPIO binding
2020-03-30 23:12 [PATCH v3 00/29] dm: Add programmatic generation of ACPI tables (part A) Simon Glass
` (3 preceding siblings ...)
2020-03-30 23:12 ` [PATCH v3 04/29] tpm: cr50: Add a comment for cr50_priv Simon Glass
@ 2020-03-30 23:12 ` Simon Glass
2020-03-30 23:12 ` [PATCH v3 06/29] tpm: Don't cleanup unless an error happens Simon Glass
` (31 subsequent siblings)
36 siblings, 0 replies; 86+ messages in thread
From: Simon Glass @ 2020-03-30 23:12 UTC (permalink / raw)
To: u-boot
This device should use ready-gpios rather than ready-gpio. Fix it.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
---
Changes in v3: None
Changes in v2: None
arch/x86/dts/chromebook_coral.dts | 2 +-
doc/device-tree-bindings/gpio/intel,apl-gpio.txt | 2 +-
.../interrupt-controller/intel,acpi-gpe.txt | 2 +-
drivers/tpm/cr50_i2c.c | 2 +-
4 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/x86/dts/chromebook_coral.dts b/arch/x86/dts/chromebook_coral.dts
index af52e11c89a..d48ef3573ec 100644
--- a/arch/x86/dts/chromebook_coral.dts
+++ b/arch/x86/dts/chromebook_coral.dts
@@ -292,7 +292,7 @@
reg = <0x50>;
compatible = "google,cr50";
u-boot,i2c-offset-len = <0>;
- ready-gpio = <&gpio_n 28 GPIO_ACTIVE_LOW>;
+ ready-gpios = <&gpio_n 28 GPIO_ACTIVE_LOW>;
interrupts-extended = <&acpi_gpe 0x3c 0>;
};
};
diff --git a/doc/device-tree-bindings/gpio/intel,apl-gpio.txt b/doc/device-tree-bindings/gpio/intel,apl-gpio.txt
index cf0659b70ec..8422ff63abd 100644
--- a/doc/device-tree-bindings/gpio/intel,apl-gpio.txt
+++ b/doc/device-tree-bindings/gpio/intel,apl-gpio.txt
@@ -47,7 +47,7 @@ Example:
reg = <0x50>;
compatible = "google,cr50";
u-boot,i2c-offset-len = <0>;
- ready-gpio = <&gpio_n GPIO_28 GPIO_ACTIVE_LOW>;
+ ready-gpios = <&gpio_n GPIO_28 GPIO_ACTIVE_LOW>;
};
};
diff --git a/doc/device-tree-bindings/interrupt-controller/intel,acpi-gpe.txt b/doc/device-tree-bindings/interrupt-controller/intel,acpi-gpe.txt
index d9252bf29f7..2fe02d8a227 100644
--- a/doc/device-tree-bindings/interrupt-controller/intel,acpi-gpe.txt
+++ b/doc/device-tree-bindings/interrupt-controller/intel,acpi-gpe.txt
@@ -25,6 +25,6 @@ Example:
tpm at 50 {
reg = <0x50>;
compatible = "google,cr50";
- ready-gpio = <&gpio_n 0x1c GPIO_ACTIVE_LOW>;
+ ready-gpios = <&gpio_n 0x1c GPIO_ACTIVE_LOW>;
interrupts-extended = <&acpi_gpe 0x3c 0>;
};
diff --git a/drivers/tpm/cr50_i2c.c b/drivers/tpm/cr50_i2c.c
index c1d2d2fa381..b67051af26a 100644
--- a/drivers/tpm/cr50_i2c.c
+++ b/drivers/tpm/cr50_i2c.c
@@ -607,7 +607,7 @@ static int cr50_i2c_ofdata_to_platdata(struct udevice *dev)
priv->irq = irq;
priv->use_irq = true;
} else {
- ret = gpio_request_by_name(dev, "ready-gpio", 0,
+ ret = gpio_request_by_name(dev, "ready-gpios", 0,
&priv->ready_gpio, GPIOD_IS_IN);
if (ret) {
log_warning("Cr50 does not have an ready GPIO/interrupt (err=%d)\n",
--
2.26.0.rc2.310.g2932bb562d-goog
^ permalink raw reply related [flat|nested] 86+ messages in thread* [PATCH v3 06/29] tpm: Don't cleanup unless an error happens
2020-03-30 23:12 [PATCH v3 00/29] dm: Add programmatic generation of ACPI tables (part A) Simon Glass
` (4 preceding siblings ...)
2020-03-30 23:12 ` [PATCH v3 05/29] tpm: cr50: Use the correct GPIO binding Simon Glass
@ 2020-03-30 23:12 ` Simon Glass
2020-03-30 23:12 ` [PATCH v3 07/29] dm: pci: Allow disabling auto-config for a device Simon Glass
` (30 subsequent siblings)
36 siblings, 0 replies; 86+ messages in thread
From: Simon Glass @ 2020-03-30 23:12 UTC (permalink / raw)
To: u-boot
At present the cleanup() method is called on every transfer. It should
only be called on failing transfers. Fix this and tidy up the error
handling a little.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
---
Changes in v3: None
Changes in v2: None
drivers/tpm/tpm-uclass.c | 13 ++++++++++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/drivers/tpm/tpm-uclass.c b/drivers/tpm/tpm-uclass.c
index 1b11c93194d..71d58070062 100644
--- a/drivers/tpm/tpm-uclass.c
+++ b/drivers/tpm/tpm-uclass.c
@@ -72,7 +72,7 @@ int tpm_xfer(struct udevice *dev, const uint8_t *sendbuf, size_t send_size,
struct tpm_ops *ops = tpm_get_ops(dev);
ulong start, stop;
uint count, ordinal;
- int ret, ret2;
+ int ret, ret2 = 0;
if (ops->xfer)
return ops->xfer(dev, sendbuf, send_size, recvbuf, recv_size);
@@ -120,9 +120,16 @@ int tpm_xfer(struct udevice *dev, const uint8_t *sendbuf, size_t send_size,
}
} while (ret);
- ret2 = ops->cleanup ? ops->cleanup(dev) : 0;
+ if (ret) {
+ if (ops->cleanup) {
+ ret2 = ops->cleanup(dev);
+ if (ret2)
+ return log_msg_ret("cleanup", ret2);
+ }
+ return log_msg_ret("xfer", ret);
+ }
- return ret2 ? ret2 : ret;
+ return 0;
}
UCLASS_DRIVER(tpm) = {
--
2.26.0.rc2.310.g2932bb562d-goog
^ permalink raw reply related [flat|nested] 86+ messages in thread* [PATCH v3 07/29] dm: pci: Allow disabling auto-config for a device
2020-03-30 23:12 [PATCH v3 00/29] dm: Add programmatic generation of ACPI tables (part A) Simon Glass
` (5 preceding siblings ...)
2020-03-30 23:12 ` [PATCH v3 06/29] tpm: Don't cleanup unless an error happens Simon Glass
@ 2020-03-30 23:12 ` Simon Glass
2020-03-30 23:12 ` [PATCH v3 08/29] x86: Correct wording of coreboot source code Simon Glass
` (29 subsequent siblings)
36 siblings, 0 replies; 86+ messages in thread
From: Simon Glass @ 2020-03-30 23:12 UTC (permalink / raw)
To: u-boot
Add a means to avoid configuring a device when needed. Add an explanation
of why this is useful to the binding file.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
---
Changes in v3:
- Drop acpi,name in example
Changes in v2: None
doc/device-tree-bindings/pci/x86-pci.txt | 23 +++++++++++++++++++++++
drivers/pci/pci-uclass.c | 2 ++
2 files changed, 25 insertions(+)
diff --git a/doc/device-tree-bindings/pci/x86-pci.txt b/doc/device-tree-bindings/pci/x86-pci.txt
index 3aa5bd9a46c..95e370b3e72 100644
--- a/doc/device-tree-bindings/pci/x86-pci.txt
+++ b/doc/device-tree-bindings/pci/x86-pci.txt
@@ -10,6 +10,17 @@ Optional properties:
configuration in TPL/SPL to reduce code size and boot time, since these
phases only know about a small subset of PCI devices.
+For PCI devices the following optional property is available:
+
+- pci,no-autoconfig : Don't automatically configure this PCI device at all.
+ This is used when the device is statically configured and must maintain
+ this same config throughout the boot process. An example is a serial
+ UART being used to debug PCI configuration, since reconfiguring it stops
+ the UART from working until the driver is re-probed, and this can cause
+ output to be lost. This should not generally be used in production code,
+ although it is often harmless.
+
+
Example:
pci {
@@ -21,4 +32,16 @@ pci {
0x42000000 0x0 0xb0000000 0xb0000000 0 0x10000000
0x01000000 0x0 0x1000 0x1000 0 0xefff>;
u-boot,skip-auto-config-until-reloc;
+
+
+ serial: serial at 18,2 {
+ reg = <0x0200c210 0 0 0 0>;
+ u-boot,dm-pre-reloc;
+ compatible = "intel,apl-ns16550";
+ early-regs = <0xde000000 0x20>;
+ reg-shift = <2>;
+ clock-frequency = <1843200>;
+ current-speed = <115200>;
+ pci,no-autoconfig;
+ };
};
diff --git a/drivers/pci/pci-uclass.c b/drivers/pci/pci-uclass.c
index e2882e3b634..ceb64517047 100644
--- a/drivers/pci/pci-uclass.c
+++ b/drivers/pci/pci-uclass.c
@@ -536,6 +536,8 @@ int pci_auto_config_devices(struct udevice *bus)
int ret;
debug("%s: device %s\n", __func__, dev->name);
+ if (dev_read_bool(dev, "pci,no-autoconfig"))
+ continue;
ret = dm_pciauto_config_device(dev);
if (ret < 0)
return ret;
--
2.26.0.rc2.310.g2932bb562d-goog
^ permalink raw reply related [flat|nested] 86+ messages in thread* [PATCH v3 08/29] x86: Correct wording of coreboot source code
2020-03-30 23:12 [PATCH v3 00/29] dm: Add programmatic generation of ACPI tables (part A) Simon Glass
` (6 preceding siblings ...)
2020-03-30 23:12 ` [PATCH v3 07/29] dm: pci: Allow disabling auto-config for a device Simon Glass
@ 2020-03-30 23:12 ` Simon Glass
2020-03-30 23:12 ` [PATCH v3 09/29] x86: apl: Move p2sb ofdata reading to the correct method Simon Glass
` (28 subsequent siblings)
36 siblings, 0 replies; 86+ messages in thread
From: Simon Glass @ 2020-03-30 23:12 UTC (permalink / raw)
To: u-boot
Some files are taken or modified from coreboot, but the files are
no-longer part of the coreboot project. Fix the wording in a few places.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Wolfgang Wallner <wolfgang.wallner@br-automation.com>
---
Changes in v3: None
Changes in v2: None
arch/x86/cpu/coreboot/timestamp.c | 4 ++--
arch/x86/include/asm/arch-coreboot/timestamp.h | 4 ++--
arch/x86/include/asm/intel_pinctrl_defs.h | 2 --
3 files changed, 4 insertions(+), 6 deletions(-)
diff --git a/arch/x86/cpu/coreboot/timestamp.c b/arch/x86/cpu/coreboot/timestamp.c
index e698200d704..e8ccaf22129 100644
--- a/arch/x86/cpu/coreboot/timestamp.c
+++ b/arch/x86/cpu/coreboot/timestamp.c
@@ -1,8 +1,8 @@
// SPDX-License-Identifier: GPL-2.0+
/*
- * This file is part of the coreboot project.
- *
* Copyright (C) 2011 The ChromiumOS Authors. All rights reserved.
+ *
+ * Modified from the coreboot version
*/
#include <common.h>
diff --git a/arch/x86/include/asm/arch-coreboot/timestamp.h b/arch/x86/include/asm/arch-coreboot/timestamp.h
index 9320afba561..85d42c02c46 100644
--- a/arch/x86/include/asm/arch-coreboot/timestamp.h
+++ b/arch/x86/include/asm/arch-coreboot/timestamp.h
@@ -1,8 +1,8 @@
/* SPDX-License-Identifier: GPL-2.0 */
/*
- * This file is part of the coreboot project.
- *
* Copyright (C) 2011 The ChromiumOS Authors. All rights reserved.
+ *
+ * Taken from the coreboot version
*/
#ifndef __COREBOOT_TIMESTAMP_H__
diff --git a/arch/x86/include/asm/intel_pinctrl_defs.h b/arch/x86/include/asm/intel_pinctrl_defs.h
index 6da06bb52b4..1ea141f082f 100644
--- a/arch/x86/include/asm/intel_pinctrl_defs.h
+++ b/arch/x86/include/asm/intel_pinctrl_defs.h
@@ -1,7 +1,5 @@
/* SPDX-License-Identifier: GPL-2.0 */
/*
- * This file is part of the coreboot project.
- *
* Copyright (C) 2015-2016 Intel Corp.
* Copyright 2019 Google LLC
*
--
2.26.0.rc2.310.g2932bb562d-goog
^ permalink raw reply related [flat|nested] 86+ messages in thread* [PATCH v3 09/29] x86: apl: Move p2sb ofdata reading to the correct method
2020-03-30 23:12 [PATCH v3 00/29] dm: Add programmatic generation of ACPI tables (part A) Simon Glass
` (7 preceding siblings ...)
2020-03-30 23:12 ` [PATCH v3 08/29] x86: Correct wording of coreboot source code Simon Glass
@ 2020-03-30 23:12 ` Simon Glass
2020-03-30 23:12 ` [PATCH v3 10/29] pci: Adjust dm_pci_read_bar32() to return errors correctly Simon Glass
` (27 subsequent siblings)
36 siblings, 0 replies; 86+ messages in thread
From: Simon Glass @ 2020-03-30 23:12 UTC (permalink / raw)
To: u-boot
With P2SB the initial BAR (base-address register) is set up by TPL and
this is used unchanged right through U-Boot.
At present the reading of this address is split between the ofdata() and
probe() methods. There are a few problems that are unique to the p2sb.
One is that its children need to call pcr_read32(), etc. which needs to
have the p2sb address correct. Also some of its children are pinctrl
devices and pinctrl is used when any device is probed. So p2sb really
needs to get its base address set up in ofdata_to_platdata(), before it is
probed.
Another point is that reading the p2sb BAR will not work if the p2sb is
hidden. The FSP-S seems to hide it, presumably to avoid confusing PCI
enumeration.
Reading ofdata in ofdata_to_platdata() is the correct place anyway, so
this is easy to fix.
Move the code into one place and use the early-regs property in all cases
for simplicity and to avoid needing to probe any PCI devices just to read
the BAR.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Wolfgang Wallner <wolfgang.wallner@br-automation.com>
Tested-by: Wolfgang Wallner <wolfgang.wallner@br-automation.com>
---
Changes in v3:
- Fix indenting error mentioned by Andy Shevchenko
Changes in v2: None
arch/x86/cpu/intel_common/p2sb.c | 33 +++++++++++---------------------
1 file changed, 11 insertions(+), 22 deletions(-)
diff --git a/arch/x86/cpu/intel_common/p2sb.c b/arch/x86/cpu/intel_common/p2sb.c
index d5b4846e0a2..6f3c4416186 100644
--- a/arch/x86/cpu/intel_common/p2sb.c
+++ b/arch/x86/cpu/intel_common/p2sb.c
@@ -92,46 +92,35 @@ int p2sb_ofdata_to_platdata(struct udevice *dev)
#if !CONFIG_IS_ENABLED(OF_PLATDATA)
int ret;
+ u32 base[2];
+ ret = dev_read_u32_array(dev, "early-regs", base, ARRAY_SIZE(base));
+ if (ret)
+ return log_msg_ret("Missing/short early-regs", ret);
+ plat->mmio_base = base[0];
+ /* TPL sets up the initial BAR */
if (spl_phase() == PHASE_TPL) {
- u32 base[2];
-
- /* TPL sets up the initial BAR */
- ret = dev_read_u32_array(dev, "early-regs", base,
- ARRAY_SIZE(base));
- if (ret)
- return log_msg_ret("Missing/short early-regs", ret);
- plat->mmio_base = base[0];
plat->bdf = pci_get_devfn(dev);
if (plat->bdf < 0)
return log_msg_ret("Cannot get p2sb PCI address",
plat->bdf);
}
+ upriv->mmio_base = plat->mmio_base;
#else
plat->mmio_base = plat->dtplat.early_regs[0];
plat->bdf = pci_ofplat_get_devfn(plat->dtplat.reg[0]);
-#endif
upriv->mmio_base = plat->mmio_base;
- debug("p2sb: mmio_base=%x\n", (uint)plat->mmio_base);
+#endif
return 0;
}
static int p2sb_probe(struct udevice *dev)
{
- if (spl_phase() == PHASE_TPL) {
+ if (spl_phase() == PHASE_TPL)
return p2sb_early_init(dev);
- } else {
- struct p2sb_platdata *plat = dev_get_platdata(dev);
-
- plat->mmio_base = dev_read_addr_pci(dev);
- /* Don't set BDF since it should not be used */
- if (!plat->mmio_base || plat->mmio_base == FDT_ADDR_T_NONE)
- return -EINVAL;
-
- if (spl_phase() == PHASE_SPL)
- return p2sb_spl_init(dev);
- }
+ else if (spl_phase() == PHASE_SPL)
+ return p2sb_spl_init(dev);
return 0;
}
--
2.26.0.rc2.310.g2932bb562d-goog
^ permalink raw reply related [flat|nested] 86+ messages in thread* [PATCH v3 10/29] pci: Adjust dm_pci_read_bar32() to return errors correctly
2020-03-30 23:12 [PATCH v3 00/29] dm: Add programmatic generation of ACPI tables (part A) Simon Glass
` (8 preceding siblings ...)
2020-03-30 23:12 ` [PATCH v3 09/29] x86: apl: Move p2sb ofdata reading to the correct method Simon Glass
@ 2020-03-30 23:12 ` Simon Glass
2020-04-03 11:22 ` Andy Shevchenko
2020-03-30 23:12 ` [PATCH v3 11/29] x86: apl: Add Global NVS table header Simon Glass
` (26 subsequent siblings)
36 siblings, 1 reply; 86+ messages in thread
From: Simon Glass @ 2020-03-30 23:12 UTC (permalink / raw)
To: u-boot
At present if reading a BAR returns 0xffffffff (e.g. the device is not
present) then the value is masked and a different value is returned.
This makes it harder to detect the problem when debugging.
Update the function to avoid masking in this case.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Wolfgang Wallner <wolfgang.wallner@br-automation.com>
---
Changes in v3: None
Changes in v2: None
drivers/pci/pci-uclass.c | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/pci/pci-uclass.c b/drivers/pci/pci-uclass.c
index ceb64517047..d2e10d6868a 100644
--- a/drivers/pci/pci-uclass.c
+++ b/drivers/pci/pci-uclass.c
@@ -1213,7 +1213,14 @@ u32 dm_pci_read_bar32(const struct udevice *dev, int barnum)
bar = PCI_BASE_ADDRESS_0 + barnum * 4;
dm_pci_read_config32(dev, bar, &addr);
- if (addr & PCI_BASE_ADDRESS_SPACE_IO)
+
+ /*
+ * If we get an invalid address, return this so that comparisons with
+ * FDT_ADDR_T_NONE work correctly
+ */
+ if (addr == 0xffffffff)
+ return addr;
+ else if (addr & PCI_BASE_ADDRESS_SPACE_IO)
return addr & PCI_BASE_ADDRESS_IO_MASK;
else
return addr & PCI_BASE_ADDRESS_MEM_MASK;
--
2.26.0.rc2.310.g2932bb562d-goog
^ permalink raw reply related [flat|nested] 86+ messages in thread* [PATCH v3 10/29] pci: Adjust dm_pci_read_bar32() to return errors correctly
2020-03-30 23:12 ` [PATCH v3 10/29] pci: Adjust dm_pci_read_bar32() to return errors correctly Simon Glass
@ 2020-04-03 11:22 ` Andy Shevchenko
2020-04-08 2:57 ` Simon Glass
0 siblings, 1 reply; 86+ messages in thread
From: Andy Shevchenko @ 2020-04-03 11:22 UTC (permalink / raw)
To: u-boot
On Mon, Mar 30, 2020 at 05:12:46PM -0600, Simon Glass wrote:
> At present if reading a BAR returns 0xffffffff (e.g. the device is not
> present) then the value is masked and a different value is returned.
> This makes it harder to detect the problem when debugging.
The above ('the device is not present') is actually not correct.
BAR is not mandatory register and detection is described in PCI spec.
To get device presence one may have check Vendor ID / Device ID pair rather
then BAR.
> Update the function to avoid masking in this case.
>
> Signed-off-by: Simon Glass <sjg@chromium.org>
> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
> Reviewed-by: Wolfgang Wallner <wolfgang.wallner@br-automation.com>
> ---
>
> Changes in v3: None
> Changes in v2: None
>
> drivers/pci/pci-uclass.c | 9 ++++++++-
> 1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/pci/pci-uclass.c b/drivers/pci/pci-uclass.c
> index ceb64517047..d2e10d6868a 100644
> --- a/drivers/pci/pci-uclass.c
> +++ b/drivers/pci/pci-uclass.c
> @@ -1213,7 +1213,14 @@ u32 dm_pci_read_bar32(const struct udevice *dev, int barnum)
>
> bar = PCI_BASE_ADDRESS_0 + barnum * 4;
> dm_pci_read_config32(dev, bar, &addr);
> - if (addr & PCI_BASE_ADDRESS_SPACE_IO)
> +
> + /*
> + * If we get an invalid address, return this so that comparisons with
> + * FDT_ADDR_T_NONE work correctly
> + */
> + if (addr == 0xffffffff)
> + return addr;
> + else if (addr & PCI_BASE_ADDRESS_SPACE_IO)
> return addr & PCI_BASE_ADDRESS_IO_MASK;
> else
> return addr & PCI_BASE_ADDRESS_MEM_MASK;
> --
> 2.26.0.rc2.310.g2932bb562d-goog
>
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply [flat|nested] 86+ messages in thread* [PATCH v3 10/29] pci: Adjust dm_pci_read_bar32() to return errors correctly
2020-04-03 11:22 ` Andy Shevchenko
@ 2020-04-08 2:57 ` Simon Glass
2020-04-08 16:58 ` Andy Shevchenko
0 siblings, 1 reply; 86+ messages in thread
From: Simon Glass @ 2020-04-08 2:57 UTC (permalink / raw)
To: u-boot
Hi Andy,
On Fri, 3 Apr 2020 at 05:22, Andy Shevchenko
<andriy.shevchenko@linux.intel.com> wrote:
>
> On Mon, Mar 30, 2020 at 05:12:46PM -0600, Simon Glass wrote:
> > At present if reading a BAR returns 0xffffffff (e.g. the device is not
> > present) then the value is masked and a different value is returned.
> > This makes it harder to detect the problem when debugging.
>
> The above ('the device is not present') is actually not correct.
> BAR is not mandatory register and detection is described in PCI spec.
What change are you suggesting here? I suggest 'not present' as an
example of why this might happen.
>
> To get device presence one may have check Vendor ID / Device ID pair rather
> then BAR.
>
> > Update the function to avoid masking in this case.
> >
> > Signed-off-by: Simon Glass <sjg@chromium.org>
> > Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
> > Reviewed-by: Wolfgang Wallner <wolfgang.wallner@br-automation.com>
> > ---
> >
> > Changes in v3: None
> > Changes in v2: None
> >
> > drivers/pci/pci-uclass.c | 9 ++++++++-
> > 1 file changed, 8 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/pci/pci-uclass.c b/drivers/pci/pci-uclass.c
> > index ceb64517047..d2e10d6868a 100644
> > --- a/drivers/pci/pci-uclass.c
> > +++ b/drivers/pci/pci-uclass.c
> > @@ -1213,7 +1213,14 @@ u32 dm_pci_read_bar32(const struct udevice *dev, int barnum)
> >
> > bar = PCI_BASE_ADDRESS_0 + barnum * 4;
> > dm_pci_read_config32(dev, bar, &addr);
> > - if (addr & PCI_BASE_ADDRESS_SPACE_IO)
> > +
> > + /*
> > + * If we get an invalid address, return this so that comparisons with
> > + * FDT_ADDR_T_NONE work correctly
> > + */
> > + if (addr == 0xffffffff)
> > + return addr;
> > + else if (addr & PCI_BASE_ADDRESS_SPACE_IO)
> > return addr & PCI_BASE_ADDRESS_IO_MASK;
> > else
> > return addr & PCI_BASE_ADDRESS_MEM_MASK;
> > --
> > 2.26.0.rc2.310.g2932bb562d-goog
> >
>
> --
> With Best Regards,
> Andy Shevchenko
>
>
Regards,
Simon
^ permalink raw reply [flat|nested] 86+ messages in thread* [PATCH v3 10/29] pci: Adjust dm_pci_read_bar32() to return errors correctly
2020-04-08 2:57 ` Simon Glass
@ 2020-04-08 16:58 ` Andy Shevchenko
2020-04-08 22:15 ` Simon Glass
0 siblings, 1 reply; 86+ messages in thread
From: Andy Shevchenko @ 2020-04-08 16:58 UTC (permalink / raw)
To: u-boot
On Tue, Apr 07, 2020 at 08:57:20PM -0600, Simon Glass wrote:
> Hi Andy,
>
> On Fri, 3 Apr 2020 at 05:22, Andy Shevchenko
> <andriy.shevchenko@linux.intel.com> wrote:
> >
> > On Mon, Mar 30, 2020 at 05:12:46PM -0600, Simon Glass wrote:
> > > At present if reading a BAR returns 0xffffffff (e.g. the device is not
> > > present) then the value is masked and a different value is returned.
> > > This makes it harder to detect the problem when debugging.
> >
> > The above ('the device is not present') is actually not correct.
> > BAR is not mandatory register and detection is described in PCI spec.
>
> What change are you suggesting here? I suggest 'not present' as an
> example of why this might happen.
I suggest to follow PCI spec.
Thus, the code below is fragile and working by luck.
> > To get device presence one may have check Vendor ID / Device ID pair rather
> > then BAR.
> >
> > > Update the function to avoid masking in this case.
> > >
> > > Signed-off-by: Simon Glass <sjg@chromium.org>
> > > Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
> > > Reviewed-by: Wolfgang Wallner <wolfgang.wallner@br-automation.com>
> > > ---
> > >
> > > Changes in v3: None
> > > Changes in v2: None
> > >
> > > drivers/pci/pci-uclass.c | 9 ++++++++-
> > > 1 file changed, 8 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/pci/pci-uclass.c b/drivers/pci/pci-uclass.c
> > > index ceb64517047..d2e10d6868a 100644
> > > --- a/drivers/pci/pci-uclass.c
> > > +++ b/drivers/pci/pci-uclass.c
> > > @@ -1213,7 +1213,14 @@ u32 dm_pci_read_bar32(const struct udevice *dev, int barnum)
> > >
> > > bar = PCI_BASE_ADDRESS_0 + barnum * 4;
> > > dm_pci_read_config32(dev, bar, &addr);
> > > - if (addr & PCI_BASE_ADDRESS_SPACE_IO)
> > > +
> > > + /*
> > > + * If we get an invalid address, return this so that comparisons with
> > > + * FDT_ADDR_T_NONE work correctly
> > > + */
> > > + if (addr == 0xffffffff)
> > > + return addr;
> > > + else if (addr & PCI_BASE_ADDRESS_SPACE_IO)
> > > return addr & PCI_BASE_ADDRESS_IO_MASK;
> > > else
> > > return addr & PCI_BASE_ADDRESS_MEM_MASK;
> > > --
> > > 2.26.0.rc2.310.g2932bb562d-goog
> > >
> >
> > --
> > With Best Regards,
> > Andy Shevchenko
> >
> >
>
> Regards,
> Simon
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply [flat|nested] 86+ messages in thread* [PATCH v3 10/29] pci: Adjust dm_pci_read_bar32() to return errors correctly
2020-04-08 16:58 ` Andy Shevchenko
@ 2020-04-08 22:15 ` Simon Glass
0 siblings, 0 replies; 86+ messages in thread
From: Simon Glass @ 2020-04-08 22:15 UTC (permalink / raw)
To: u-boot
HI Andy,
On Wed, 8 Apr 2020 at 10:58, Andy Shevchenko
<andriy.shevchenko@linux.intel.com> wrote:
>
> On Tue, Apr 07, 2020 at 08:57:20PM -0600, Simon Glass wrote:
> > Hi Andy,
> >
> > On Fri, 3 Apr 2020 at 05:22, Andy Shevchenko
> > <andriy.shevchenko@linux.intel.com> wrote:
> > >
> > > On Mon, Mar 30, 2020 at 05:12:46PM -0600, Simon Glass wrote:
> > > > At present if reading a BAR returns 0xffffffff (e.g. the device is not
> > > > present) then the value is masked and a different value is returned.
> > > > This makes it harder to detect the problem when debugging.
> > >
> > > The above ('the device is not present') is actually not correct.
> > > BAR is not mandatory register and detection is described in PCI spec.
> >
> > What change are you suggesting here? I suggest 'not present' as an
> > example of why this might happen.
>
> I suggest to follow PCI spec.
> Thus, the code below is fragile and working by luck.
I don't know what you are suggesting. This allows an error to be
reported in the common case and helps people discover mistakes in the
driver flow. What is your suggestion?
Rgards,
SImon
>
> > > To get device presence one may have check Vendor ID / Device ID pair rather
> > > then BAR.
> > >
> > > > Update the function to avoid masking in this case.
> > > >
> > > > Signed-off-by: Simon Glass <sjg@chromium.org>
> > > > Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
> > > > Reviewed-by: Wolfgang Wallner <wolfgang.wallner@br-automation.com>
> > > > ---
> > > >
> > > > Changes in v3: None
> > > > Changes in v2: None
> > > >
> > > > drivers/pci/pci-uclass.c | 9 ++++++++-
> > > > 1 file changed, 8 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/drivers/pci/pci-uclass.c b/drivers/pci/pci-uclass.c
> > > > index ceb64517047..d2e10d6868a 100644
> > > > --- a/drivers/pci/pci-uclass.c
> > > > +++ b/drivers/pci/pci-uclass.c
> > > > @@ -1213,7 +1213,14 @@ u32 dm_pci_read_bar32(const struct udevice *dev, int barnum)
> > > >
> > > > bar = PCI_BASE_ADDRESS_0 + barnum * 4;
> > > > dm_pci_read_config32(dev, bar, &addr);
> > > > - if (addr & PCI_BASE_ADDRESS_SPACE_IO)
> > > > +
> > > > + /*
> > > > + * If we get an invalid address, return this so that comparisons with
> > > > + * FDT_ADDR_T_NONE work correctly
> > > > + */
> > > > + if (addr == 0xffffffff)
> > > > + return addr;
> > > > + else if (addr & PCI_BASE_ADDRESS_SPACE_IO)
> > > > return addr & PCI_BASE_ADDRESS_IO_MASK;
> > > > else
> > > > return addr & PCI_BASE_ADDRESS_MEM_MASK;
> > > > --
> > > > 2.26.0.rc2.310.g2932bb562d-goog
> > > >
> > >
> > > --
> > > With Best Regards,
> > > Andy Shevchenko
> > >
> > >
> >
> > Regards,
> > Simon
>
> --
> With Best Regards,
> Andy Shevchenko
>
>
^ permalink raw reply [flat|nested] 86+ messages in thread
* [PATCH v3 11/29] x86: apl: Add Global NVS table header
2020-03-30 23:12 [PATCH v3 00/29] dm: Add programmatic generation of ACPI tables (part A) Simon Glass
` (9 preceding siblings ...)
2020-03-30 23:12 ` [PATCH v3 10/29] pci: Adjust dm_pci_read_bar32() to return errors correctly Simon Glass
@ 2020-03-30 23:12 ` Simon Glass
2020-03-30 23:12 ` [PATCH v3 12/29] dm: core: Add basic ACPI support Simon Glass
` (25 subsequent siblings)
36 siblings, 0 replies; 86+ messages in thread
From: Simon Glass @ 2020-03-30 23:12 UTC (permalink / raw)
To: u-boot
Add the C version of this header. It includes a few Chrome OS bits which
are disabled for a normal build.
Signed-off-by: Simon Glass <sjg@chromium.org>
---
Changes in v3:
- Fix stray #endif
Changes in v2:
- Drop the Chrome OS pieces
- Rename the 'coreboot' console to 'U-Boot'
.../include/asm/arch-apollolake/global_nvs.h | 36 +++++++++++++++++++
1 file changed, 36 insertions(+)
create mode 100644 arch/x86/include/asm/arch-apollolake/global_nvs.h
diff --git a/arch/x86/include/asm/arch-apollolake/global_nvs.h b/arch/x86/include/asm/arch-apollolake/global_nvs.h
new file mode 100644
index 00000000000..5bde837a755
--- /dev/null
+++ b/arch/x86/include/asm/arch-apollolake/global_nvs.h
@@ -0,0 +1,36 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Copyright (C) 2015-2017 Intel Corp.
+ * (Written by Lance Zhao <lijian.zhao@intel.com> for Intel Corp.)
+ * Copyright Google LLC 2019
+ *
+ * Modified from coreboot apollolake/include/soc/nvs.h
+ */
+
+#ifndef _GLOBAL_NVS_H_
+#define _GLOBAL_NVS_H_
+
+struct __packed acpi_global_nvs {
+ /* Miscellaneous */
+ u8 pcnt; /* 0x00 - Processor Count */
+ u8 ppcm; /* 0x01 - Max PPC State */
+ u8 lids; /* 0x02 - LID State */
+ u8 pwrs; /* 0x03 - AC Power State */
+ u8 dpte; /* 0x04 - Enable DPTF */
+ u32 cbmc; /* 0x05 - 0x08 - U-Boot Console */
+ u64 pm1i; /* 0x09 - 0x10 - System Wake Source - PM1 Index */
+ u64 gpei; /* 0x11 - 0x18 - GPE Wake Source */
+ u64 nhla; /* 0x19 - 0x20 - NHLT Address */
+ u32 nhll; /* 0x21 - 0x24 - NHLT Length */
+ u32 prt0; /* 0x25 - 0x28 - PERST_0 Address */
+ u8 scdp; /* 0x29 - SD_CD GPIO portid */
+ u8 scdo; /* 0x2A - GPIO pad offset relative to the community */
+ u8 uior; /* 0x2B - UART debug controller init on S3 resume */
+ u8 ecps; /* 0x2C - SGX Enabled status */
+ u64 emna; /* 0x2D - 0x34 EPC base address */
+ u64 elng; /* 0x35 - 0x3C EPC Length */
+ u8 unused[195];
+ u8 unused2[0xf00];
+};
+
+#endif /* _GLOBAL_NVS_H_ */
--
2.26.0.rc2.310.g2932bb562d-goog
^ permalink raw reply related [flat|nested] 86+ messages in thread* [PATCH v3 12/29] dm: core: Add basic ACPI support
2020-03-30 23:12 [PATCH v3 00/29] dm: Add programmatic generation of ACPI tables (part A) Simon Glass
` (10 preceding siblings ...)
2020-03-30 23:12 ` [PATCH v3 11/29] x86: apl: Add Global NVS table header Simon Glass
@ 2020-03-30 23:12 ` Simon Glass
2020-04-03 11:35 ` Andy Shevchenko
2020-03-30 23:12 ` [PATCH v3 13/29] dts: Add a binding for hid-over-i2c Simon Glass
` (24 subsequent siblings)
36 siblings, 1 reply; 86+ messages in thread
From: Simon Glass @ 2020-03-30 23:12 UTC (permalink / raw)
To: u-boot
ACPI (Advanced Configuration and Power Interface) is a standard for
specifying information about a platform. It is a little like device
tree but the bindings are part of the specification and it supports an
interpreted bytecode language.
Driver model does not use ACPI for U-Boot's configuration, but it is
convenient to have it support generation of ACPI tables for passing to
Linux, etc.
As a starting point, add an optional set of ACPI operations to each
device. Initially only a single operation is available, to obtain the
ACPI name for the device. More operations are added later.
Enable ACPI for sandbox to ensure build coverage and so that we can add
tests.
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Signed-off-by: Simon Glass <sjg@chromium.org>
---
Changes in v3:
- Compute ACPI_NAME_MAX from ACPI_NAME_LEN
- Drop 'Intel' from 'Intel ACPI'
- Rename acpi_return_name() to acpi_copy_name()
- Reword commit message to drop the bit about ACPI being complicated
- Use strncpy() instead of strcpy() in acpi_copy_name()
Changes in v2:
- Move LOGC_ACPI definition to this patch
drivers/core/Kconfig | 9 ++++++
drivers/core/Makefile | 1 +
drivers/core/acpi.c | 33 +++++++++++++++++++
include/dm/acpi.h | 73 +++++++++++++++++++++++++++++++++++++++++++
include/dm/device.h | 5 +++
include/log.h | 2 ++
6 files changed, 123 insertions(+)
create mode 100644 drivers/core/acpi.c
create mode 100644 include/dm/acpi.h
diff --git a/drivers/core/Kconfig b/drivers/core/Kconfig
index 3b95b5387b9..a3b03993423 100644
--- a/drivers/core/Kconfig
+++ b/drivers/core/Kconfig
@@ -261,4 +261,13 @@ config DM_DEV_READ_INLINE
bool
default y if !OF_LIVE
+config ACPIGEN
+ bool "Support ACPI table generation in driver model"
+ default y if SANDBOX || GENERATE_ACPI_TABLE
+ help
+ This option enables generation of ACPI tables using driver-model
+ devices. It adds a new operation struct to each driver, to support
+ things like generating device-specific tables and returning the ACPI
+ name of a device.
+
endmenu
diff --git a/drivers/core/Makefile b/drivers/core/Makefile
index bce7467da1d..c707026a3a0 100644
--- a/drivers/core/Makefile
+++ b/drivers/core/Makefile
@@ -3,6 +3,7 @@
# Copyright (c) 2013 Google, Inc
obj-y += device.o fdtaddr.o lists.o root.o uclass.o util.o
+obj-$(CONFIG_$(SPL_TPL_)ACPIGEN) += acpi.o
obj-$(CONFIG_DEVRES) += devres.o
obj-$(CONFIG_$(SPL_)DM_DEVICE_REMOVE) += device-remove.o
obj-$(CONFIG_$(SPL_)SIMPLE_BUS) += simple-bus.o
diff --git a/drivers/core/acpi.c b/drivers/core/acpi.c
new file mode 100644
index 00000000000..0e64c21bf5b
--- /dev/null
+++ b/drivers/core/acpi.c
@@ -0,0 +1,33 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Core driver model support for ACPI table generation
+ *
+ * Copyright 2019 Google LLC
+ * Written by Simon Glass <sjg@chromium.org>
+ */
+
+#define LOG_CATEOGRY LOGC_ACPI
+
+#include <common.h>
+#include <dm.h>
+#include <dm/acpi.h>
+#include <dm/root.h>
+
+int acpi_copy_name(char *out_name, const char *name)
+{
+ strncpy(out_name, name, ACPI_NAME_MAX);
+ out_name[ACPI_NAME_LEN] = '\0';
+
+ return 0;
+}
+
+int acpi_get_name(const struct udevice *dev, char *out_name)
+{
+ struct acpi_ops *aops;
+
+ aops = device_get_acpi_ops(dev);
+ if (aops && aops->get_name)
+ return aops->get_name(dev, out_name);
+
+ return -ENOSYS;
+}
diff --git a/include/dm/acpi.h b/include/dm/acpi.h
new file mode 100644
index 00000000000..c13d0c8448a
--- /dev/null
+++ b/include/dm/acpi.h
@@ -0,0 +1,73 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Core ACPI (Advanced Configuration and Power Interface) support
+ *
+ * Copyright 2019 Google LLC
+ * Written by Simon Glass <sjg@chromium.org>
+ */
+
+#ifndef __DM_ACPI_H__
+#define __DM_ACPI_H__
+
+/* Allow operations to be optional for ACPI */
+#if CONFIG_IS_ENABLED(ACPIGEN)
+#define acpi_ops_ptr(_ptr) .acpi_ops = _ptr,
+#else
+#define acpi_ops_ptr(_ptr)
+#endif
+
+/* Length of an ACPI name string, excluding nul terminator */
+#define ACPI_NAME_LEN 4
+
+/* Length of an ACPI name string including nul terminator */
+#define ACPI_NAME_MAX (ACPI_NAME_LEN + 1)
+
+/**
+ * struct acpi_ops - ACPI operations supported by driver model
+ */
+struct acpi_ops {
+ /**
+ * get_name() - Obtain the ACPI name of a device
+ *
+ * @dev: Device to check
+ * @out_name: Place to put the name, must hold at least ACPI_NAME_MAX
+ * bytes
+ * @return 0 if OK, -ENOENT if no name is available, other -ve value on
+ * other error
+ */
+ int (*get_name)(const struct udevice *dev, char *out_name);
+};
+
+#define device_get_acpi_ops(dev) ((dev)->driver->acpi_ops)
+
+/**
+ * acpi_get_name() - Obtain the ACPI name of a device
+ *
+ * @dev: Device to check
+ * @out_name: Place to put the name, must hold at least ACPI_NAME_MAX
+ * bytes
+ * @return 0 if OK, -ENOENT if no name is available, other -ve value on
+ * other error
+ */
+int acpi_get_name(const struct udevice *dev, char *out_name);
+
+/**
+ * acpi_copy_name() - Copy an ACPI name to an output buffer
+ *
+ * This convenience function can be used to return a literal string as a name
+ * in functions that implement the get_name() method.
+ *
+ * For example:
+ *
+ * static int mydev_get_name(const struct udevice *dev, char *out_name)
+ * {
+ * return acpi_copy_name(out_name, "WIBB");
+ * }
+ *
+ * @out_name: Place to put the name
+ * @name: Name to copy
+ * @return 0 (always)
+ */
+int acpi_copy_name(char *out_name, const char *name);
+
+#endif
diff --git a/include/dm/device.h b/include/dm/device.h
index a56164b19bb..35e19d87005 100644
--- a/include/dm/device.h
+++ b/include/dm/device.h
@@ -245,6 +245,8 @@ struct udevice_id {
* pointers defined by the driver, to implement driver functions required by
* the uclass.
* @flags: driver flags - see DM_FLAGS_...
+ * @acpi_ops: Advanced Configuration and Power Interface (ACPI) operations,
+ * allowing the device to add things to the ACPI tables passed to Linux
*/
struct driver {
char *name;
@@ -264,6 +266,9 @@ struct driver {
int per_child_platdata_auto_alloc_size;
const void *ops; /* driver-specific operations */
uint32_t flags;
+#if CONFIG_IS_ENABLED(ACPIGEN)
+ struct acpi_ops *acpi_ops;
+#endif
};
/* Declare a new U-Boot driver */
diff --git a/include/log.h b/include/log.h
index 62fb8afbd0e..fbcbd42fb4b 100644
--- a/include/log.h
+++ b/include/log.h
@@ -51,6 +51,8 @@ enum log_category_t {
LOGC_SANDBOX, /* Related to the sandbox board */
LOGC_BLOBLIST, /* Bloblist */
LOGC_DEVRES, /* Device resources (devres_... functions) */
+ /* Advanced Configuration and Power Interface (ACPI) */
+ LOGC_ACPI,
LOGC_COUNT, /* Number of log categories */
LOGC_END, /* Sentinel value for a list of log categories */
--
2.26.0.rc2.310.g2932bb562d-goog
^ permalink raw reply related [flat|nested] 86+ messages in thread* [PATCH v3 12/29] dm: core: Add basic ACPI support
2020-03-30 23:12 ` [PATCH v3 12/29] dm: core: Add basic ACPI support Simon Glass
@ 2020-04-03 11:35 ` Andy Shevchenko
2020-04-08 2:57 ` Simon Glass
0 siblings, 1 reply; 86+ messages in thread
From: Andy Shevchenko @ 2020-04-03 11:35 UTC (permalink / raw)
To: u-boot
On Mon, Mar 30, 2020 at 05:12:48PM -0600, Simon Glass wrote:
> ACPI (Advanced Configuration and Power Interface) is a standard for
> specifying information about a platform. It is a little like device
> tree but the bindings are part of the specification and it supports an
> interpreted bytecode language.
>
> Driver model does not use ACPI for U-Boot's configuration, but it is
> convenient to have it support generation of ACPI tables for passing to
> Linux, etc.
>
> As a starting point, add an optional set of ACPI operations to each
> device. Initially only a single operation is available, to obtain the
> ACPI name for the device. More operations are added later.
>
> Enable ACPI for sandbox to ensure build coverage and so that we can add
> tests.
...
> +int acpi_copy_name(char *out_name, const char *name)
> +{
> + strncpy(out_name, name, ACPI_NAME_MAX);
memcpy()?
> + out_name[ACPI_NAME_LEN] = '\0';
I dunno if compiler is clever enough to catch this and avoid any warnings.
Also it seems above should also have _LEN, and not _MAX.
> + return 0;
> +}
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply [flat|nested] 86+ messages in thread* [PATCH v3 12/29] dm: core: Add basic ACPI support
2020-04-03 11:35 ` Andy Shevchenko
@ 2020-04-08 2:57 ` Simon Glass
2020-04-08 17:01 ` Andy Shevchenko
0 siblings, 1 reply; 86+ messages in thread
From: Simon Glass @ 2020-04-08 2:57 UTC (permalink / raw)
To: u-boot
Hi Andy,
On Fri, 3 Apr 2020 at 05:35, Andy Shevchenko
<andriy.shevchenko@linux.intel.com> wrote:
>
> On Mon, Mar 30, 2020 at 05:12:48PM -0600, Simon Glass wrote:
> > ACPI (Advanced Configuration and Power Interface) is a standard for
> > specifying information about a platform. It is a little like device
> > tree but the bindings are part of the specification and it supports an
> > interpreted bytecode language.
> >
> > Driver model does not use ACPI for U-Boot's configuration, but it is
> > convenient to have it support generation of ACPI tables for passing to
> > Linux, etc.
> >
> > As a starting point, add an optional set of ACPI operations to each
> > device. Initially only a single operation is available, to obtain the
> > ACPI name for the device. More operations are added later.
> >
> > Enable ACPI for sandbox to ensure build coverage and so that we can add
> > tests.
>
>
> ...
>
> > +int acpi_copy_name(char *out_name, const char *name)
> > +{
>
> > + strncpy(out_name, name, ACPI_NAME_MAX);
>
> memcpy()?
strcpy() seems better since it doesn't rely on the correct string in name.
> > + out_name[ACPI_NAME_LEN] = '\0';
>
> I dunno if compiler is clever enough to catch this and avoid any warnings.
I don't see any warnings.
> Also it seems above should also have _LEN, and not _MAX.
Do you mean for the strncpy()? I could do that but I still want to set
the terminator to nul so that the string is definitely terminated.
Regards,
Simon
^ permalink raw reply [flat|nested] 86+ messages in thread* [PATCH v3 12/29] dm: core: Add basic ACPI support
2020-04-08 2:57 ` Simon Glass
@ 2020-04-08 17:01 ` Andy Shevchenko
2020-04-08 22:15 ` Simon Glass
0 siblings, 1 reply; 86+ messages in thread
From: Andy Shevchenko @ 2020-04-08 17:01 UTC (permalink / raw)
To: u-boot
On Tue, Apr 07, 2020 at 08:57:24PM -0600, Simon Glass wrote:
> On Fri, 3 Apr 2020 at 05:35, Andy Shevchenko
> <andriy.shevchenko@linux.intel.com> wrote:
> > On Mon, Mar 30, 2020 at 05:12:48PM -0600, Simon Glass wrote:
...
> > > + strncpy(out_name, name, ACPI_NAME_MAX);
> >
> > memcpy()?
>
> strcpy() seems better since it doesn't rely on the correct string in name.
Definitely not. It has no boundary checks.
> > > + out_name[ACPI_NAME_LEN] = '\0';
> >
> > I dunno if compiler is clever enough to catch this and avoid any warnings.
>
> I don't see any warnings.
strncpy() fine then.
> > Also it seems above should also have _LEN, and not _MAX.
>
> Do you mean for the strncpy()? I could do that but I still want to set
> the terminator to nul so that the string is definitely terminated.
Terminator can be not present.
I should be
strncpy(out_name, name, ACPI_NAME_LEN);
out_name[ACPI_NAME_LEN] = '\0';
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply [flat|nested] 86+ messages in thread* [PATCH v3 12/29] dm: core: Add basic ACPI support
2020-04-08 17:01 ` Andy Shevchenko
@ 2020-04-08 22:15 ` Simon Glass
0 siblings, 0 replies; 86+ messages in thread
From: Simon Glass @ 2020-04-08 22:15 UTC (permalink / raw)
To: u-boot
Hi Andy,
On Wed, 8 Apr 2020 at 11:02, Andy Shevchenko
<andriy.shevchenko@linux.intel.com> wrote:
>
> On Tue, Apr 07, 2020 at 08:57:24PM -0600, Simon Glass wrote:
> > On Fri, 3 Apr 2020 at 05:35, Andy Shevchenko
> > <andriy.shevchenko@linux.intel.com> wrote:
> > > On Mon, Mar 30, 2020 at 05:12:48PM -0600, Simon Glass wrote:
>
> ...
>
> > > > + strncpy(out_name, name, ACPI_NAME_MAX);
> > >
> > > memcpy()?
> >
> > strcpy() seems better since it doesn't rely on the correct string in name.
>
> Definitely not. It has no boundary checks.
>
> > > > + out_name[ACPI_NAME_LEN] = '\0';
> > >
> > > I dunno if compiler is clever enough to catch this and avoid any warnings.
> >
> > I don't see any warnings.
>
> strncpy() fine then.
>
> > > Also it seems above should also have _LEN, and not _MAX.
> >
> > Do you mean for the strncpy()? I could do that but I still want to set
> > the terminator to nul so that the string is definitely terminated.
>
> Terminator can be not present.
> I should be
>
> strncpy(out_name, name, ACPI_NAME_LEN);
> out_name[ACPI_NAME_LEN] = '\0';
Why? The code I have seems to work just fine?
Regards,
Simon
^ permalink raw reply [flat|nested] 86+ messages in thread
* [PATCH v3 13/29] dts: Add a binding for hid-over-i2c
2020-03-30 23:12 [PATCH v3 00/29] dm: Add programmatic generation of ACPI tables (part A) Simon Glass
` (11 preceding siblings ...)
2020-03-30 23:12 ` [PATCH v3 12/29] dm: core: Add basic ACPI support Simon Glass
@ 2020-03-30 23:12 ` Simon Glass
2020-03-30 23:12 ` [PATCH v3 14/29] acpi: Add a binding for ACPI settings in the device tree Simon Glass
` (23 subsequent siblings)
36 siblings, 0 replies; 86+ messages in thread
From: Simon Glass @ 2020-03-30 23:12 UTC (permalink / raw)
To: u-boot
Add this binding from Linux v5.4.
Signed-off-by: Simon Glass <sjg@chromium.org>
---
Changes in v3:
- Split out hid-over-i2c into its own patch
Changes in v2: None
.../input/hid-over-i2c.txt | 44 +++++++++++++++++++
1 file changed, 44 insertions(+)
create mode 100644 doc/device-tree-bindings/input/hid-over-i2c.txt
diff --git a/doc/device-tree-bindings/input/hid-over-i2c.txt b/doc/device-tree-bindings/input/hid-over-i2c.txt
new file mode 100644
index 00000000000..c76bafaf98d
--- /dev/null
+++ b/doc/device-tree-bindings/input/hid-over-i2c.txt
@@ -0,0 +1,44 @@
+* HID over I2C Device-Tree bindings
+
+HID over I2C provides support for various Human Interface Devices over the
+I2C bus. These devices can be for example touchpads, keyboards, touch screens
+or sensors.
+
+The specification has been written by Microsoft and is currently available here:
+http://msdn.microsoft.com/en-us/library/windows/hardware/hh852380.aspx
+
+If this binding is used, the kernel module i2c-hid will handle the communication
+with the device and the generic hid core layer will handle the protocol.
+
+Required properties:
+- compatible: must be "hid-over-i2c"
+- reg: i2c slave address
+- hid-descr-addr: HID descriptor address
+- interrupts: interrupt line
+
+Additional optional properties:
+
+Some devices may support additional optional properties to help with, e.g.,
+power sequencing. The following properties can be supported by one or more
+device-specific compatible properties, which should be used in addition to the
+"hid-over-i2c" string.
+
+- compatible:
+ * "wacom,w9013" (Wacom W9013 digitizer). Supports:
+ - vdd-supply (3.3V)
+ - vddl-supply (1.8V)
+ - post-power-on-delay-ms
+
+- vdd-supply: phandle of the regulator that provides the supply voltage.
+- post-power-on-delay-ms: time required by the device after enabling its regulators
+ or powering it on, before it is ready for communication.
+
+Example:
+
+ i2c-hid-dev at 2c {
+ compatible = "hid-over-i2c";
+ reg = <0x2c>;
+ hid-descr-addr = <0x0020>;
+ interrupt-parent = <&gpx3>;
+ interrupts = <3 2>;
+ };
--
2.26.0.rc2.310.g2932bb562d-goog
^ permalink raw reply related [flat|nested] 86+ messages in thread* [PATCH v3 14/29] acpi: Add a binding for ACPI settings in the device tree
2020-03-30 23:12 [PATCH v3 00/29] dm: Add programmatic generation of ACPI tables (part A) Simon Glass
` (12 preceding siblings ...)
2020-03-30 23:12 ` [PATCH v3 13/29] dts: Add a binding for hid-over-i2c Simon Glass
@ 2020-03-30 23:12 ` Simon Glass
2020-04-03 12:42 ` Andy Shevchenko
2020-03-30 23:12 ` [PATCH v3 15/29] acpi: Add a simple sandbox test Simon Glass
` (22 subsequent siblings)
36 siblings, 1 reply; 86+ messages in thread
From: Simon Glass @ 2020-03-30 23:12 UTC (permalink / raw)
To: u-boot
Devices need to report various identifiers in the ACPI tables. Rather than
hard-coding these in drivers it is typically better to put them in the
device tree.
Add a binding file to describe this.
Signed-off-by: Simon Glass <sjg@chromium.org>
---
Changes in v3:
- Add a pointer to information about acpi,compatible
- Change the example to ELAN
- Correct description of acpi,probed
- Drop hid-descr-addr
- Drop mention of PRIC
- Just add the device.txt binding file in this patch
- Rename acpi,desc to acpi,ddn
Changes in v2:
- Add the hid-over-i2c binding document
- Fix definition of HID
- Infer hid-over-i2c CID value
doc/device-tree-bindings/device.txt | 37 +++++++++++++++++++++++++++++
1 file changed, 37 insertions(+)
create mode 100644 doc/device-tree-bindings/device.txt
diff --git a/doc/device-tree-bindings/device.txt b/doc/device-tree-bindings/device.txt
new file mode 100644
index 00000000000..06c2b84b6d5
--- /dev/null
+++ b/doc/device-tree-bindings/device.txt
@@ -0,0 +1,37 @@
+Devices
+=======
+
+Device bindings are described by their own individual binding files.
+
+U-Boot provides for some optional properties which are documented here. See
+also hid-over-i2c.txt which describes HID devices. See also
+Documentation/firmware-guide/acpi/enumeration.rst in the Linux kernel for
+the acpi,compatible property.
+
+ - acpi,has-power-resource : (boolean) true if this device has a power resource.
+ This causes an ACPI PowerResource to be written containing the properties
+ provided by this binding, to describe how to handle powering the device up
+ and down using GPIOs
+ - acpi,compatible : compatible string to report
+ - acpi,ddn : Contains the string to use as the _DDN (DOS (Disk Operating
+ System) Device Name)
+ - acpi,hid : Contains the string to use as the HID (Hardware ID)
+ identifier _HID
+ - acpi,probed : Tells U-Boot to add 'linux,probed' to the ACPI tables so that
+ Linux will only load the driver if the device can be detected (e.g. on I2C
+ bus)
+ - acpi,uid : _UID value for device
+
+
+Example
+-------
+
+elan_touchscreen: elan-touchscreen at 10 {
+ compatible = "i2c-chip";
+ reg = <0x10>;
+ acpi,hid = "ELAN0001";
+ acpi,ddn = "ELAN Touchscreen";
+ interrupts-extended = <&acpi_gpe GPIO_21_IRQ
+ IRQ_TYPE_EDGE_FALLING>;
+ acpi,probed;
+};
--
2.26.0.rc2.310.g2932bb562d-goog
^ permalink raw reply related [flat|nested] 86+ messages in thread* [PATCH v3 14/29] acpi: Add a binding for ACPI settings in the device tree
2020-03-30 23:12 ` [PATCH v3 14/29] acpi: Add a binding for ACPI settings in the device tree Simon Glass
@ 2020-04-03 12:42 ` Andy Shevchenko
0 siblings, 0 replies; 86+ messages in thread
From: Andy Shevchenko @ 2020-04-03 12:42 UTC (permalink / raw)
To: u-boot
On Mon, Mar 30, 2020 at 05:12:50PM -0600, Simon Glass wrote:
> Devices need to report various identifiers in the ACPI tables. Rather than
> hard-coding these in drivers it is typically better to put them in the
> device tree.
>
> Add a binding file to describe this.
> +elan_touchscreen: elan-touchscreen at 10 {
> + compatible = "i2c-chip";
> + reg = <0x10>;
> + acpi,hid = "ELAN0001";
> + acpi,ddn = "ELAN Touchscreen";
> + interrupts-extended = <&acpi_gpe GPIO_21_IRQ
> + IRQ_TYPE_EDGE_FALLING>;
Can we have this on one line?
> + acpi,probed;
> +};
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply [flat|nested] 86+ messages in thread
* [PATCH v3 15/29] acpi: Add a simple sandbox test
2020-03-30 23:12 [PATCH v3 00/29] dm: Add programmatic generation of ACPI tables (part A) Simon Glass
` (13 preceding siblings ...)
2020-03-30 23:12 ` [PATCH v3 14/29] acpi: Add a binding for ACPI settings in the device tree Simon Glass
@ 2020-03-30 23:12 ` Simon Glass
2020-04-03 12:51 ` Andy Shevchenko
2020-03-30 23:12 ` [PATCH v3 16/29] x86: Move acpi_s3.h to include/acpi/ Simon Glass
` (21 subsequent siblings)
36 siblings, 1 reply; 86+ messages in thread
From: Simon Glass @ 2020-03-30 23:12 UTC (permalink / raw)
To: u-boot
Add a sandbox test for the basic ACPI functionality we have so far.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Wolfgang Wallner <wolfgang.wallner@br-automation.com>
---
Changes in v3: None
Changes in v2:
- Add in the acpi_table.h header file to this patch
arch/sandbox/dts/test.dts | 4 ++
arch/sandbox/include/asm/acpi_table.h | 9 +++++
include/dm/uclass-id.h | 1 +
test/dm/Makefile | 1 +
test/dm/acpi.c | 55 +++++++++++++++++++++++++++
5 files changed, 70 insertions(+)
create mode 100644 arch/sandbox/include/asm/acpi_table.h
create mode 100644 test/dm/acpi.c
diff --git a/arch/sandbox/dts/test.dts b/arch/sandbox/dts/test.dts
index 4a277934a71..5fa951ad4b6 100644
--- a/arch/sandbox/dts/test.dts
+++ b/arch/sandbox/dts/test.dts
@@ -206,6 +206,10 @@
compatible = "denx,u-boot-devres-test";
};
+ acpi-test {
+ compatible = "denx,u-boot-acpi-test";
+ };
+
clocks {
clk_fixed: clk-fixed {
compatible = "fixed-clock";
diff --git a/arch/sandbox/include/asm/acpi_table.h b/arch/sandbox/include/asm/acpi_table.h
new file mode 100644
index 00000000000..921c7f4201d
--- /dev/null
+++ b/arch/sandbox/include/asm/acpi_table.h
@@ -0,0 +1,9 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Copyright 2019 Google LLC
+ */
+
+#ifndef __ASM_ACPI_TABLE_H__
+#define __ASM_ACPI_TABLE_H__
+
+#endif /* __ASM_ACPI_TABLE_H__ */
diff --git a/include/dm/uclass-id.h b/include/dm/uclass-id.h
index 598f65ea7a3..37ada51f9f7 100644
--- a/include/dm/uclass-id.h
+++ b/include/dm/uclass-id.h
@@ -20,6 +20,7 @@ enum uclass_id {
UCLASS_TEST_PROBE,
UCLASS_TEST_DUMMY,
UCLASS_TEST_DEVRES,
+ UCLASS_TEST_ACPI,
UCLASS_SPI_EMUL, /* sandbox SPI device emulator */
UCLASS_I2C_EMUL, /* sandbox I2C device emulator */
UCLASS_I2C_EMUL_PARENT, /* parent for I2C device emulators */
diff --git a/test/dm/Makefile b/test/dm/Makefile
index dd1ceff86c0..3daf8a544ea 100644
--- a/test/dm/Makefile
+++ b/test/dm/Makefile
@@ -13,6 +13,7 @@ obj-$(CONFIG_UT_DM) += test-uclass.o
# subsystem you must add sandbox tests here.
obj-$(CONFIG_UT_DM) += core.o
ifneq ($(CONFIG_SANDBOX),)
+obj-$(CONFIG_ACPIGEN) += acpi.o
obj-$(CONFIG_SOUND) += audio.o
obj-$(CONFIG_BLK) += blk.o
obj-$(CONFIG_BOARD) += board.o
diff --git a/test/dm/acpi.c b/test/dm/acpi.c
new file mode 100644
index 00000000000..429993b9cc0
--- /dev/null
+++ b/test/dm/acpi.c
@@ -0,0 +1,55 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Tests for ACPI table generation
+ *
+ * Copyright 2019 Google LLC
+ * Written by Simon Glass <sjg@chromium.org>
+ */
+
+#include <common.h>
+#include <dm.h>
+#include <dm/acpi.h>
+#include <dm/test.h>
+#include <test/ut.h>
+
+#define ACPI_TEST_DEV_NAME "ABCD"
+
+static int testacpi_get_name(const struct udevice *dev, char *out_name)
+{
+ return acpi_copy_name(out_name, ACPI_TEST_DEV_NAME);
+}
+
+struct acpi_ops testacpi_ops = {
+ .get_name = testacpi_get_name,
+};
+
+static const struct udevice_id testacpi_ids[] = {
+ { .compatible = "denx,u-boot-acpi-test" },
+ { }
+};
+
+U_BOOT_DRIVER(testacpi_drv) = {
+ .name = "testacpi_drv",
+ .of_match = testacpi_ids,
+ .id = UCLASS_TEST_ACPI,
+ acpi_ops_ptr(&testacpi_ops)
+};
+
+UCLASS_DRIVER(testacpi) = {
+ .name = "testacpi",
+ .id = UCLASS_TEST_ACPI,
+};
+
+/* Test ACPI get_name() */
+static int dm_test_acpi_get_name(struct unit_test_state *uts)
+{
+ char name[ACPI_NAME_MAX];
+ struct udevice *dev;
+
+ ut_assertok(uclass_first_device_err(UCLASS_TEST_ACPI, &dev));
+ ut_assertok(acpi_get_name(dev, name));
+ ut_asserteq_str(ACPI_TEST_DEV_NAME, name);
+
+ return 0;
+}
+DM_TEST(dm_test_acpi_get_name, DM_TESTF_SCAN_PDATA | DM_TESTF_SCAN_FDT);
--
2.26.0.rc2.310.g2932bb562d-goog
^ permalink raw reply related [flat|nested] 86+ messages in thread* [PATCH v3 15/29] acpi: Add a simple sandbox test
2020-03-30 23:12 ` [PATCH v3 15/29] acpi: Add a simple sandbox test Simon Glass
@ 2020-04-03 12:51 ` Andy Shevchenko
2020-04-08 2:57 ` Simon Glass
0 siblings, 1 reply; 86+ messages in thread
From: Andy Shevchenko @ 2020-04-03 12:51 UTC (permalink / raw)
To: u-boot
On Mon, Mar 30, 2020 at 05:12:51PM -0600, Simon Glass wrote:
> Add a sandbox test for the basic ACPI functionality we have so far.
> +U_BOOT_DRIVER(testacpi_drv) = {
> + .name = "testacpi_drv",
> + .of_match = testacpi_ids,
> + .id = UCLASS_TEST_ACPI,
> + acpi_ops_ptr(&testacpi_ops)
I have noticed that this is not obvious why no comma here.
Perhaps, since apci_ops_ptr is a macro, you should upper case it.
> +};
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply [flat|nested] 86+ messages in thread* [PATCH v3 15/29] acpi: Add a simple sandbox test
2020-04-03 12:51 ` Andy Shevchenko
@ 2020-04-08 2:57 ` Simon Glass
2020-04-08 16:57 ` Andy Shevchenko
0 siblings, 1 reply; 86+ messages in thread
From: Simon Glass @ 2020-04-08 2:57 UTC (permalink / raw)
To: u-boot
Hi Andy,
On Fri, 3 Apr 2020 at 06:51, Andy Shevchenko
<andriy.shevchenko@linux.intel.com> wrote:
>
> On Mon, Mar 30, 2020 at 05:12:51PM -0600, Simon Glass wrote:
> > Add a sandbox test for the basic ACPI functionality we have so far.
>
> > +U_BOOT_DRIVER(testacpi_drv) = {
> > + .name = "testacpi_drv",
> > + .of_match = testacpi_ids,
> > + .id = UCLASS_TEST_ACPI,
>
> > + acpi_ops_ptr(&testacpi_ops)
>
> I have noticed that this is not obvious why no comma here.
> Perhaps, since apci_ops_ptr is a macro, you should upper case it.
This is a bit like of_match_ptr() which is a macro used by Linux.
Putting them in upper case makes them very hard to read. Admittedly
the lack of a comma is odd though. It is because the field doesn't
exist until ACPI is enabled (which it is not in SPL, for example).
Regards,
Simon
^ permalink raw reply [flat|nested] 86+ messages in thread* [PATCH v3 15/29] acpi: Add a simple sandbox test
2020-04-08 2:57 ` Simon Glass
@ 2020-04-08 16:57 ` Andy Shevchenko
0 siblings, 0 replies; 86+ messages in thread
From: Andy Shevchenko @ 2020-04-08 16:57 UTC (permalink / raw)
To: u-boot
On Tue, Apr 07, 2020 at 08:57:19PM -0600, Simon Glass wrote:
> Hi Andy,
>
> On Fri, 3 Apr 2020 at 06:51, Andy Shevchenko
> <andriy.shevchenko@linux.intel.com> wrote:
> >
> > On Mon, Mar 30, 2020 at 05:12:51PM -0600, Simon Glass wrote:
> > > Add a sandbox test for the basic ACPI functionality we have so far.
> >
> > > +U_BOOT_DRIVER(testacpi_drv) = {
> > > + .name = "testacpi_drv",
> > > + .of_match = testacpi_ids,
> > > + .id = UCLASS_TEST_ACPI,
> >
> > > + acpi_ops_ptr(&testacpi_ops)
> >
> > I have noticed that this is not obvious why no comma here.
> > Perhaps, since apci_ops_ptr is a macro, you should upper case it.
>
> This is a bit like of_match_ptr() which is a macro used by Linux.
For ACPI there is capitalized, but...
> Putting them in upper case makes them very hard to read. Admittedly
> the lack of a comma is odd though. It is because the field doesn't
> exist until ACPI is enabled (which it is not in SPL, for example).
...and this puts them to different categories, like PM ops in Linux kernel,
where they are also capitalized, exactly to be used in struct definitions.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply [flat|nested] 86+ messages in thread
* [PATCH v3 16/29] x86: Move acpi_s3.h to include/acpi/
2020-03-30 23:12 [PATCH v3 00/29] dm: Add programmatic generation of ACPI tables (part A) Simon Glass
` (14 preceding siblings ...)
2020-03-30 23:12 ` [PATCH v3 15/29] acpi: Add a simple sandbox test Simon Glass
@ 2020-03-30 23:12 ` Simon Glass
2020-04-03 12:53 ` Andy Shevchenko
2020-03-30 23:12 ` [PATCH v3 17/29] x86: Move acpi_table header to main include/ directory Simon Glass
` (20 subsequent siblings)
36 siblings, 1 reply; 86+ messages in thread
From: Simon Glass @ 2020-03-30 23:12 UTC (permalink / raw)
To: u-boot
This header relates to ACPI and we are about to add some more ACPI
headers. Move this one into a new directory so they are together.
Signed-off-by: Simon Glass <sjg@chromium.org>
---
Changes in v3:
- Add new patch to move acpi_s3.h to include/acpi/
Changes in v2: None
arch/x86/cpu/apollolake/cpu_spl.c | 2 +-
arch/x86/cpu/apollolake/fsp_s.c | 2 +-
arch/x86/cpu/apollolake/pmc.c | 2 +-
arch/x86/cpu/baytrail/acpi.c | 4 ++--
arch/x86/cpu/cpu.c | 2 +-
arch/x86/cpu/wakeup.S | 2 +-
arch/x86/lib/acpi_s3.c | 2 +-
arch/x86/lib/coreboot_table.c | 2 +-
arch/x86/lib/fsp/fsp_common.c | 2 +-
arch/x86/lib/fsp1/fsp_common.c | 2 +-
arch/x86/lib/fsp2/fsp_dram.c | 2 +-
drivers/pci/pci_rom.c | 4 +---
drivers/power/acpi_pmc/acpi-pmc-uclass.c | 2 +-
drivers/sysreset/sysreset_x86.c | 2 +-
include/{ => acpi}/acpi_s3.h | 0
15 files changed, 15 insertions(+), 17 deletions(-)
rename include/{ => acpi}/acpi_s3.h (100%)
diff --git a/arch/x86/cpu/apollolake/cpu_spl.c b/arch/x86/cpu/apollolake/cpu_spl.c
index 8a39c3128e0..e2509e391fa 100644
--- a/arch/x86/cpu/apollolake/cpu_spl.c
+++ b/arch/x86/cpu/apollolake/cpu_spl.c
@@ -6,13 +6,13 @@
*/
#include <common.h>
-#include <acpi_s3.h>
#include <dm.h>
#include <ec_commands.h>
#include <log.h>
#include <spi_flash.h>
#include <spl.h>
#include <syscon.h>
+#include <acpi/acpi_s3.h>
#include <asm/cpu.h>
#include <asm/cpu_common.h>
#include <asm/cpu_x86.h>
diff --git a/arch/x86/cpu/apollolake/fsp_s.c b/arch/x86/cpu/apollolake/fsp_s.c
index 1f22c1ea3c6..17cf1682ad0 100644
--- a/arch/x86/cpu/apollolake/fsp_s.c
+++ b/arch/x86/cpu/apollolake/fsp_s.c
@@ -5,11 +5,11 @@
*/
#include <common.h>
-#include <acpi_s3.h>
#include <binman.h>
#include <dm.h>
#include <irq.h>
#include <malloc.h>
+#include <acpi/acpi_s3.h>
#include <asm/intel_pinctrl.h>
#include <asm/io.h>
#include <asm/intel_regs.h>
diff --git a/arch/x86/cpu/apollolake/pmc.c b/arch/x86/cpu/apollolake/pmc.c
index aec0c8394c2..4ea7c7447bc 100644
--- a/arch/x86/cpu/apollolake/pmc.c
+++ b/arch/x86/cpu/apollolake/pmc.c
@@ -9,10 +9,10 @@
#define LOG_CATEGORY UCLASS_ACPI_PMC
#include <common.h>
-#include <acpi_s3.h>
#include <dt-structs.h>
#include <dm.h>
#include <spl.h>
+#include <acpi/acpi_s3.h>
#include <asm/io.h>
#include <asm/pci.h>
#include <power/acpi_pmc.h>
diff --git a/arch/x86/cpu/baytrail/acpi.c b/arch/x86/cpu/baytrail/acpi.c
index f44228e6939..3c27391873c 100644
--- a/arch/x86/cpu/baytrail/acpi.c
+++ b/arch/x86/cpu/baytrail/acpi.c
@@ -4,15 +4,15 @@
*/
#include <common.h>
-#include <acpi_s3.h>
#include <cpu.h>
#include <dm.h>
-#include <dm/uclass-internal.h>
+#include <acpi/acpi_s3.h>
#include <asm/acpi_table.h>
#include <asm/io.h>
#include <asm/tables.h>
#include <asm/arch/global_nvs.h>
#include <asm/arch/iomap.h>
+#include <dm/uclass-internal.h>
void acpi_create_fadt(struct acpi_fadt *fadt, struct acpi_facs *facs,
void *dsdt)
diff --git a/arch/x86/cpu/cpu.c b/arch/x86/cpu/cpu.c
index dae06949cc6..246ee50948c 100644
--- a/arch/x86/cpu/cpu.c
+++ b/arch/x86/cpu/cpu.c
@@ -19,7 +19,6 @@
*/
#include <common.h>
-#include <acpi_s3.h>
#include <command.h>
#include <cpu_func.h>
#include <dm.h>
@@ -27,6 +26,7 @@
#include <init.h>
#include <malloc.h>
#include <syscon.h>
+#include <acpi/acpi_s3.h>
#include <asm/acpi.h>
#include <asm/acpi_table.h>
#include <asm/control_regs.h>
diff --git a/arch/x86/cpu/wakeup.S b/arch/x86/cpu/wakeup.S
index 244ca1276af..093bf3bcc5c 100644
--- a/arch/x86/cpu/wakeup.S
+++ b/arch/x86/cpu/wakeup.S
@@ -5,7 +5,7 @@
* From coreboot src/arch/x86/wakeup.S
*/
-#include <acpi_s3.h>
+#include <acpi/acpi_s3.h>
#include <asm/processor.h>
#include <asm/processor-flags.h>
diff --git a/arch/x86/lib/acpi_s3.c b/arch/x86/lib/acpi_s3.c
index 197636c4b50..c3759ec8492 100644
--- a/arch/x86/lib/acpi_s3.c
+++ b/arch/x86/lib/acpi_s3.c
@@ -4,7 +4,7 @@
*/
#include <common.h>
-#include <acpi_s3.h>
+#include <acpi/acpi_s3.h>
#include <asm/acpi.h>
#include <asm/acpi_table.h>
#include <asm/post.h>
diff --git a/arch/x86/lib/coreboot_table.c b/arch/x86/lib/coreboot_table.c
index 2943e11d2a4..c996fc588df 100644
--- a/arch/x86/lib/coreboot_table.c
+++ b/arch/x86/lib/coreboot_table.c
@@ -4,9 +4,9 @@
*/
#include <common.h>
-#include <acpi_s3.h>
#include <malloc.h>
#include <vbe.h>
+#include <acpi/acpi_s3.h>
#include <asm/coreboot_tables.h>
#include <asm/e820.h>
diff --git a/arch/x86/lib/fsp/fsp_common.c b/arch/x86/lib/fsp/fsp_common.c
index 5eff0f99aad..267527eb344 100644
--- a/arch/x86/lib/fsp/fsp_common.c
+++ b/arch/x86/lib/fsp/fsp_common.c
@@ -4,11 +4,11 @@
*/
#include <common.h>
-#include <acpi_s3.h>
#include <cpu_func.h>
#include <dm.h>
#include <errno.h>
#include <rtc.h>
+#include <acpi/acpi_s3.h>
#include <asm/cmos_layout.h>
#include <asm/early_cmos.h>
#include <asm/io.h>
diff --git a/arch/x86/lib/fsp1/fsp_common.c b/arch/x86/lib/fsp1/fsp_common.c
index aee2a05044f..0a726807c2b 100644
--- a/arch/x86/lib/fsp1/fsp_common.c
+++ b/arch/x86/lib/fsp1/fsp_common.c
@@ -4,11 +4,11 @@
*/
#include <common.h>
-#include <acpi_s3.h>
#include <dm.h>
#include <errno.h>
#include <malloc.h>
#include <rtc.h>
+#include <acpi/acpi_s3.h>
#include <asm/cmos_layout.h>
#include <asm/early_cmos.h>
#include <asm/io.h>
diff --git a/arch/x86/lib/fsp2/fsp_dram.c b/arch/x86/lib/fsp2/fsp_dram.c
index 90a238a2245..c8f2c09b6a7 100644
--- a/arch/x86/lib/fsp2/fsp_dram.c
+++ b/arch/x86/lib/fsp2/fsp_dram.c
@@ -5,9 +5,9 @@
*/
#include <common.h>
-#include <acpi_s3.h>
#include <handoff.h>
#include <spl.h>
+#include <acpi/acpi_s3.h>
#include <asm/arch/cpu.h>
#include <asm/fsp/fsp_support.h>
#include <asm/fsp2/fsp_api.h>
diff --git a/drivers/pci/pci_rom.c b/drivers/pci/pci_rom.c
index 90f224b0452..6b17f18bc07 100644
--- a/drivers/pci/pci_rom.c
+++ b/drivers/pci/pci_rom.c
@@ -33,12 +33,10 @@
#include <vbe.h>
#include <video.h>
#include <video_fb.h>
+#include <acpi/acpi_s3.h>
#include <linux/screen_info.h>
-#ifdef CONFIG_X86
-#include <acpi_s3.h>
DECLARE_GLOBAL_DATA_PTR;
-#endif
__weak bool board_should_run_oprom(struct udevice *dev)
{
diff --git a/drivers/power/acpi_pmc/acpi-pmc-uclass.c b/drivers/power/acpi_pmc/acpi-pmc-uclass.c
index d43de87126c..1c79f835c66 100644
--- a/drivers/power/acpi_pmc/acpi-pmc-uclass.c
+++ b/drivers/power/acpi_pmc/acpi-pmc-uclass.c
@@ -6,9 +6,9 @@
#define LOG_CATEGORY UCLASS_ACPI_PMC
#include <common.h>
-#include <acpi_s3.h>
#include <dm.h>
#include <log.h>
+#include <acpi/acpi_s3.h>
#ifdef CONFIG_X86
#include <asm/intel_pinctrl.h>
#endif
diff --git a/drivers/sysreset/sysreset_x86.c b/drivers/sysreset/sysreset_x86.c
index 8e2d1eaa7a1..bc911435602 100644
--- a/drivers/sysreset/sysreset_x86.c
+++ b/drivers/sysreset/sysreset_x86.c
@@ -6,11 +6,11 @@
*/
#include <common.h>
-#include <acpi_s3.h>
#include <dm.h>
#include <efi_loader.h>
#include <pch.h>
#include <sysreset.h>
+#include <acpi/acpi_s3.h>
#include <asm/io.h>
#include <asm/processor.h>
diff --git a/include/acpi_s3.h b/include/acpi/acpi_s3.h
similarity index 100%
rename from include/acpi_s3.h
rename to include/acpi/acpi_s3.h
--
2.26.0.rc2.310.g2932bb562d-goog
^ permalink raw reply related [flat|nested] 86+ messages in thread* [PATCH v3 16/29] x86: Move acpi_s3.h to include/acpi/
2020-03-30 23:12 ` [PATCH v3 16/29] x86: Move acpi_s3.h to include/acpi/ Simon Glass
@ 2020-04-03 12:53 ` Andy Shevchenko
2020-04-08 2:57 ` Simon Glass
0 siblings, 1 reply; 86+ messages in thread
From: Andy Shevchenko @ 2020-04-03 12:53 UTC (permalink / raw)
To: u-boot
On Mon, Mar 30, 2020 at 05:12:52PM -0600, Simon Glass wrote:
> This header relates to ACPI and we are about to add some more ACPI
> headers. Move this one into a new directory so they are together.
>
FWIW,
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
One nit below.
> Signed-off-by: Simon Glass <sjg@chromium.org>
> ---
>
> Changes in v3:
> - Add new patch to move acpi_s3.h to include/acpi/
>
> Changes in v2: None
>
> arch/x86/cpu/apollolake/cpu_spl.c | 2 +-
> arch/x86/cpu/apollolake/fsp_s.c | 2 +-
> arch/x86/cpu/apollolake/pmc.c | 2 +-
> arch/x86/cpu/baytrail/acpi.c | 4 ++--
> arch/x86/cpu/cpu.c | 2 +-
> arch/x86/cpu/wakeup.S | 2 +-
> arch/x86/lib/acpi_s3.c | 2 +-
> arch/x86/lib/coreboot_table.c | 2 +-
> arch/x86/lib/fsp/fsp_common.c | 2 +-
> arch/x86/lib/fsp1/fsp_common.c | 2 +-
> arch/x86/lib/fsp2/fsp_dram.c | 2 +-
> drivers/pci/pci_rom.c | 4 +---
> drivers/power/acpi_pmc/acpi-pmc-uclass.c | 2 +-
> drivers/sysreset/sysreset_x86.c | 2 +-
> include/{ => acpi}/acpi_s3.h | 0
> 15 files changed, 15 insertions(+), 17 deletions(-)
> rename include/{ => acpi}/acpi_s3.h (100%)
>
> diff --git a/arch/x86/cpu/apollolake/cpu_spl.c b/arch/x86/cpu/apollolake/cpu_spl.c
> index 8a39c3128e0..e2509e391fa 100644
> --- a/arch/x86/cpu/apollolake/cpu_spl.c
> +++ b/arch/x86/cpu/apollolake/cpu_spl.c
> @@ -6,13 +6,13 @@
> */
>
> #include <common.h>
> -#include <acpi_s3.h>
> #include <dm.h>
> #include <ec_commands.h>
> #include <log.h>
> #include <spi_flash.h>
> #include <spl.h>
> #include <syscon.h>
> +#include <acpi/acpi_s3.h>
> #include <asm/cpu.h>
> #include <asm/cpu_common.h>
> #include <asm/cpu_x86.h>
> diff --git a/arch/x86/cpu/apollolake/fsp_s.c b/arch/x86/cpu/apollolake/fsp_s.c
> index 1f22c1ea3c6..17cf1682ad0 100644
> --- a/arch/x86/cpu/apollolake/fsp_s.c
> +++ b/arch/x86/cpu/apollolake/fsp_s.c
> @@ -5,11 +5,11 @@
> */
>
> #include <common.h>
> -#include <acpi_s3.h>
> #include <binman.h>
> #include <dm.h>
> #include <irq.h>
> #include <malloc.h>
> +#include <acpi/acpi_s3.h>
> #include <asm/intel_pinctrl.h>
> #include <asm/io.h>
> #include <asm/intel_regs.h>
> diff --git a/arch/x86/cpu/apollolake/pmc.c b/arch/x86/cpu/apollolake/pmc.c
> index aec0c8394c2..4ea7c7447bc 100644
> --- a/arch/x86/cpu/apollolake/pmc.c
> +++ b/arch/x86/cpu/apollolake/pmc.c
> @@ -9,10 +9,10 @@
> #define LOG_CATEGORY UCLASS_ACPI_PMC
>
> #include <common.h>
> -#include <acpi_s3.h>
> #include <dt-structs.h>
> #include <dm.h>
> #include <spl.h>
> +#include <acpi/acpi_s3.h>
> #include <asm/io.h>
> #include <asm/pci.h>
> #include <power/acpi_pmc.h>
> diff --git a/arch/x86/cpu/baytrail/acpi.c b/arch/x86/cpu/baytrail/acpi.c
> index f44228e6939..3c27391873c 100644
> --- a/arch/x86/cpu/baytrail/acpi.c
> +++ b/arch/x86/cpu/baytrail/acpi.c
> @@ -4,15 +4,15 @@
> */
>
> #include <common.h>
> -#include <acpi_s3.h>
> #include <cpu.h>
> #include <dm.h>
> -#include <dm/uclass-internal.h>
> +#include <acpi/acpi_s3.h>
> #include <asm/acpi_table.h>
> #include <asm/io.h>
> #include <asm/tables.h>
> #include <asm/arch/global_nvs.h>
> #include <asm/arch/iomap.h>
> +#include <dm/uclass-internal.h>
>
> void acpi_create_fadt(struct acpi_fadt *fadt, struct acpi_facs *facs,
> void *dsdt)
> diff --git a/arch/x86/cpu/cpu.c b/arch/x86/cpu/cpu.c
> index dae06949cc6..246ee50948c 100644
> --- a/arch/x86/cpu/cpu.c
> +++ b/arch/x86/cpu/cpu.c
> @@ -19,7 +19,6 @@
> */
>
> #include <common.h>
> -#include <acpi_s3.h>
> #include <command.h>
> #include <cpu_func.h>
> #include <dm.h>
> @@ -27,6 +26,7 @@
> #include <init.h>
> #include <malloc.h>
> #include <syscon.h>
> +#include <acpi/acpi_s3.h>
> #include <asm/acpi.h>
> #include <asm/acpi_table.h>
> #include <asm/control_regs.h>
> diff --git a/arch/x86/cpu/wakeup.S b/arch/x86/cpu/wakeup.S
> index 244ca1276af..093bf3bcc5c 100644
> --- a/arch/x86/cpu/wakeup.S
> +++ b/arch/x86/cpu/wakeup.S
> @@ -5,7 +5,7 @@
> * From coreboot src/arch/x86/wakeup.S
> */
>
> -#include <acpi_s3.h>
> +#include <acpi/acpi_s3.h>
> #include <asm/processor.h>
> #include <asm/processor-flags.h>
>
> diff --git a/arch/x86/lib/acpi_s3.c b/arch/x86/lib/acpi_s3.c
> index 197636c4b50..c3759ec8492 100644
> --- a/arch/x86/lib/acpi_s3.c
> +++ b/arch/x86/lib/acpi_s3.c
> @@ -4,7 +4,7 @@
> */
>
> #include <common.h>
> -#include <acpi_s3.h>
> +#include <acpi/acpi_s3.h>
> #include <asm/acpi.h>
> #include <asm/acpi_table.h>
> #include <asm/post.h>
> diff --git a/arch/x86/lib/coreboot_table.c b/arch/x86/lib/coreboot_table.c
> index 2943e11d2a4..c996fc588df 100644
> --- a/arch/x86/lib/coreboot_table.c
> +++ b/arch/x86/lib/coreboot_table.c
> @@ -4,9 +4,9 @@
> */
>
> #include <common.h>
> -#include <acpi_s3.h>
> #include <malloc.h>
> #include <vbe.h>
> +#include <acpi/acpi_s3.h>
> #include <asm/coreboot_tables.h>
> #include <asm/e820.h>
>
> diff --git a/arch/x86/lib/fsp/fsp_common.c b/arch/x86/lib/fsp/fsp_common.c
> index 5eff0f99aad..267527eb344 100644
> --- a/arch/x86/lib/fsp/fsp_common.c
> +++ b/arch/x86/lib/fsp/fsp_common.c
> @@ -4,11 +4,11 @@
> */
>
> #include <common.h>
> -#include <acpi_s3.h>
> #include <cpu_func.h>
> #include <dm.h>
> #include <errno.h>
> #include <rtc.h>
> +#include <acpi/acpi_s3.h>
> #include <asm/cmos_layout.h>
> #include <asm/early_cmos.h>
> #include <asm/io.h>
> diff --git a/arch/x86/lib/fsp1/fsp_common.c b/arch/x86/lib/fsp1/fsp_common.c
> index aee2a05044f..0a726807c2b 100644
> --- a/arch/x86/lib/fsp1/fsp_common.c
> +++ b/arch/x86/lib/fsp1/fsp_common.c
> @@ -4,11 +4,11 @@
> */
>
> #include <common.h>
> -#include <acpi_s3.h>
> #include <dm.h>
> #include <errno.h>
> #include <malloc.h>
> #include <rtc.h>
> +#include <acpi/acpi_s3.h>
> #include <asm/cmos_layout.h>
> #include <asm/early_cmos.h>
> #include <asm/io.h>
> diff --git a/arch/x86/lib/fsp2/fsp_dram.c b/arch/x86/lib/fsp2/fsp_dram.c
> index 90a238a2245..c8f2c09b6a7 100644
> --- a/arch/x86/lib/fsp2/fsp_dram.c
> +++ b/arch/x86/lib/fsp2/fsp_dram.c
> @@ -5,9 +5,9 @@
> */
>
> #include <common.h>
> -#include <acpi_s3.h>
> #include <handoff.h>
> #include <spl.h>
> +#include <acpi/acpi_s3.h>
> #include <asm/arch/cpu.h>
> #include <asm/fsp/fsp_support.h>
> #include <asm/fsp2/fsp_api.h>
> diff --git a/drivers/pci/pci_rom.c b/drivers/pci/pci_rom.c
> index 90f224b0452..6b17f18bc07 100644
> --- a/drivers/pci/pci_rom.c
> +++ b/drivers/pci/pci_rom.c
> @@ -33,12 +33,10 @@
> #include <vbe.h>
> #include <video.h>
> #include <video_fb.h>
> +#include <acpi/acpi_s3.h>
> #include <linux/screen_info.h>
>
> -#ifdef CONFIG_X86
There is nothing in commit message about this change. Is it safe? Don't you get
new compiler warnings (like defined-but-not-used)?
> -#include <acpi_s3.h>
> DECLARE_GLOBAL_DATA_PTR;
> -#endif
>
> __weak bool board_should_run_oprom(struct udevice *dev)
> {
> diff --git a/drivers/power/acpi_pmc/acpi-pmc-uclass.c b/drivers/power/acpi_pmc/acpi-pmc-uclass.c
> index d43de87126c..1c79f835c66 100644
> --- a/drivers/power/acpi_pmc/acpi-pmc-uclass.c
> +++ b/drivers/power/acpi_pmc/acpi-pmc-uclass.c
> @@ -6,9 +6,9 @@
> #define LOG_CATEGORY UCLASS_ACPI_PMC
>
> #include <common.h>
> -#include <acpi_s3.h>
> #include <dm.h>
> #include <log.h>
> +#include <acpi/acpi_s3.h>
> #ifdef CONFIG_X86
> #include <asm/intel_pinctrl.h>
> #endif
> diff --git a/drivers/sysreset/sysreset_x86.c b/drivers/sysreset/sysreset_x86.c
> index 8e2d1eaa7a1..bc911435602 100644
> --- a/drivers/sysreset/sysreset_x86.c
> +++ b/drivers/sysreset/sysreset_x86.c
> @@ -6,11 +6,11 @@
> */
>
> #include <common.h>
> -#include <acpi_s3.h>
> #include <dm.h>
> #include <efi_loader.h>
> #include <pch.h>
> #include <sysreset.h>
> +#include <acpi/acpi_s3.h>
> #include <asm/io.h>
> #include <asm/processor.h>
>
> diff --git a/include/acpi_s3.h b/include/acpi/acpi_s3.h
> similarity index 100%
> rename from include/acpi_s3.h
> rename to include/acpi/acpi_s3.h
> --
> 2.26.0.rc2.310.g2932bb562d-goog
>
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply [flat|nested] 86+ messages in thread* [PATCH v3 16/29] x86: Move acpi_s3.h to include/acpi/
2020-04-03 12:53 ` Andy Shevchenko
@ 2020-04-08 2:57 ` Simon Glass
2020-04-08 17:03 ` Andy Shevchenko
0 siblings, 1 reply; 86+ messages in thread
From: Simon Glass @ 2020-04-08 2:57 UTC (permalink / raw)
To: u-boot
Hi Andy,
On Fri, 3 Apr 2020 at 06:53, Andy Shevchenko
<andriy.shevchenko@linux.intel.com> wrote:
>
> On Mon, Mar 30, 2020 at 05:12:52PM -0600, Simon Glass wrote:
> > This header relates to ACPI and we are about to add some more ACPI
> > headers. Move this one into a new directory so they are together.
> >
>
> FWIW,
> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
>
> One nit below.
>
> > Signed-off-by: Simon Glass <sjg@chromium.org>
> > ---
> >
> > Changes in v3:
> > - Add new patch to move acpi_s3.h to include/acpi/
> >
> > Changes in v2: None
> >
> > arch/x86/cpu/apollolake/cpu_spl.c | 2 +-
> > arch/x86/cpu/apollolake/fsp_s.c | 2 +-
> > arch/x86/cpu/apollolake/pmc.c | 2 +-
> > arch/x86/cpu/baytrail/acpi.c | 4 ++--
> > arch/x86/cpu/cpu.c | 2 +-
> > arch/x86/cpu/wakeup.S | 2 +-
> > arch/x86/lib/acpi_s3.c | 2 +-
> > arch/x86/lib/coreboot_table.c | 2 +-
> > arch/x86/lib/fsp/fsp_common.c | 2 +-
> > arch/x86/lib/fsp1/fsp_common.c | 2 +-
> > arch/x86/lib/fsp2/fsp_dram.c | 2 +-
> > drivers/pci/pci_rom.c | 4 +---
> > drivers/power/acpi_pmc/acpi-pmc-uclass.c | 2 +-
> > drivers/sysreset/sysreset_x86.c | 2 +-
> > include/{ => acpi}/acpi_s3.h | 0
> > 15 files changed, 15 insertions(+), 17 deletions(-)
> > rename include/{ => acpi}/acpi_s3.h (100%)
> >
> > diff --git a/arch/x86/cpu/apollolake/cpu_spl.c b/arch/x86/cpu/apollolake/cpu_spl.c
> > index 8a39c3128e0..e2509e391fa 100644
> > --- a/arch/x86/cpu/apollolake/cpu_spl.c
> > +++ b/arch/x86/cpu/apollolake/cpu_spl.c
> > @@ -6,13 +6,13 @@
> > */
> >
> > #include <common.h>
> > -#include <acpi_s3.h>
> > #include <dm.h>
> > #include <ec_commands.h>
> > #include <log.h>
> > #include <spi_flash.h>
> > #include <spl.h>
> > #include <syscon.h>
> > +#include <acpi/acpi_s3.h>
> > #include <asm/cpu.h>
> > #include <asm/cpu_common.h>
> > #include <asm/cpu_x86.h>
> > diff --git a/arch/x86/cpu/apollolake/fsp_s.c b/arch/x86/cpu/apollolake/fsp_s.c
> > index 1f22c1ea3c6..17cf1682ad0 100644
> > --- a/arch/x86/cpu/apollolake/fsp_s.c
> > +++ b/arch/x86/cpu/apollolake/fsp_s.c
> > @@ -5,11 +5,11 @@
> > */
> >
> > #include <common.h>
> > -#include <acpi_s3.h>
> > #include <binman.h>
> > #include <dm.h>
> > #include <irq.h>
> > #include <malloc.h>
> > +#include <acpi/acpi_s3.h>
> > #include <asm/intel_pinctrl.h>
> > #include <asm/io.h>
> > #include <asm/intel_regs.h>
> > diff --git a/arch/x86/cpu/apollolake/pmc.c b/arch/x86/cpu/apollolake/pmc.c
> > index aec0c8394c2..4ea7c7447bc 100644
> > --- a/arch/x86/cpu/apollolake/pmc.c
> > +++ b/arch/x86/cpu/apollolake/pmc.c
> > @@ -9,10 +9,10 @@
> > #define LOG_CATEGORY UCLASS_ACPI_PMC
> >
> > #include <common.h>
> > -#include <acpi_s3.h>
> > #include <dt-structs.h>
> > #include <dm.h>
> > #include <spl.h>
> > +#include <acpi/acpi_s3.h>
> > #include <asm/io.h>
> > #include <asm/pci.h>
> > #include <power/acpi_pmc.h>
> > diff --git a/arch/x86/cpu/baytrail/acpi.c b/arch/x86/cpu/baytrail/acpi.c
> > index f44228e6939..3c27391873c 100644
> > --- a/arch/x86/cpu/baytrail/acpi.c
> > +++ b/arch/x86/cpu/baytrail/acpi.c
> > @@ -4,15 +4,15 @@
> > */
> >
> > #include <common.h>
> > -#include <acpi_s3.h>
> > #include <cpu.h>
> > #include <dm.h>
> > -#include <dm/uclass-internal.h>
> > +#include <acpi/acpi_s3.h>
> > #include <asm/acpi_table.h>
> > #include <asm/io.h>
> > #include <asm/tables.h>
> > #include <asm/arch/global_nvs.h>
> > #include <asm/arch/iomap.h>
> > +#include <dm/uclass-internal.h>
> >
> > void acpi_create_fadt(struct acpi_fadt *fadt, struct acpi_facs *facs,
> > void *dsdt)
> > diff --git a/arch/x86/cpu/cpu.c b/arch/x86/cpu/cpu.c
> > index dae06949cc6..246ee50948c 100644
> > --- a/arch/x86/cpu/cpu.c
> > +++ b/arch/x86/cpu/cpu.c
> > @@ -19,7 +19,6 @@
> > */
> >
> > #include <common.h>
> > -#include <acpi_s3.h>
> > #include <command.h>
> > #include <cpu_func.h>
> > #include <dm.h>
> > @@ -27,6 +26,7 @@
> > #include <init.h>
> > #include <malloc.h>
> > #include <syscon.h>
> > +#include <acpi/acpi_s3.h>
> > #include <asm/acpi.h>
> > #include <asm/acpi_table.h>
> > #include <asm/control_regs.h>
> > diff --git a/arch/x86/cpu/wakeup.S b/arch/x86/cpu/wakeup.S
> > index 244ca1276af..093bf3bcc5c 100644
> > --- a/arch/x86/cpu/wakeup.S
> > +++ b/arch/x86/cpu/wakeup.S
> > @@ -5,7 +5,7 @@
> > * From coreboot src/arch/x86/wakeup.S
> > */
> >
> > -#include <acpi_s3.h>
> > +#include <acpi/acpi_s3.h>
> > #include <asm/processor.h>
> > #include <asm/processor-flags.h>
> >
> > diff --git a/arch/x86/lib/acpi_s3.c b/arch/x86/lib/acpi_s3.c
> > index 197636c4b50..c3759ec8492 100644
> > --- a/arch/x86/lib/acpi_s3.c
> > +++ b/arch/x86/lib/acpi_s3.c
> > @@ -4,7 +4,7 @@
> > */
> >
> > #include <common.h>
> > -#include <acpi_s3.h>
> > +#include <acpi/acpi_s3.h>
> > #include <asm/acpi.h>
> > #include <asm/acpi_table.h>
> > #include <asm/post.h>
> > diff --git a/arch/x86/lib/coreboot_table.c b/arch/x86/lib/coreboot_table.c
> > index 2943e11d2a4..c996fc588df 100644
> > --- a/arch/x86/lib/coreboot_table.c
> > +++ b/arch/x86/lib/coreboot_table.c
> > @@ -4,9 +4,9 @@
> > */
> >
> > #include <common.h>
> > -#include <acpi_s3.h>
> > #include <malloc.h>
> > #include <vbe.h>
> > +#include <acpi/acpi_s3.h>
> > #include <asm/coreboot_tables.h>
> > #include <asm/e820.h>
> >
> > diff --git a/arch/x86/lib/fsp/fsp_common.c b/arch/x86/lib/fsp/fsp_common.c
> > index 5eff0f99aad..267527eb344 100644
> > --- a/arch/x86/lib/fsp/fsp_common.c
> > +++ b/arch/x86/lib/fsp/fsp_common.c
> > @@ -4,11 +4,11 @@
> > */
> >
> > #include <common.h>
> > -#include <acpi_s3.h>
> > #include <cpu_func.h>
> > #include <dm.h>
> > #include <errno.h>
> > #include <rtc.h>
> > +#include <acpi/acpi_s3.h>
> > #include <asm/cmos_layout.h>
> > #include <asm/early_cmos.h>
> > #include <asm/io.h>
> > diff --git a/arch/x86/lib/fsp1/fsp_common.c b/arch/x86/lib/fsp1/fsp_common.c
> > index aee2a05044f..0a726807c2b 100644
> > --- a/arch/x86/lib/fsp1/fsp_common.c
> > +++ b/arch/x86/lib/fsp1/fsp_common.c
> > @@ -4,11 +4,11 @@
> > */
> >
> > #include <common.h>
> > -#include <acpi_s3.h>
> > #include <dm.h>
> > #include <errno.h>
> > #include <malloc.h>
> > #include <rtc.h>
> > +#include <acpi/acpi_s3.h>
> > #include <asm/cmos_layout.h>
> > #include <asm/early_cmos.h>
> > #include <asm/io.h>
> > diff --git a/arch/x86/lib/fsp2/fsp_dram.c b/arch/x86/lib/fsp2/fsp_dram.c
> > index 90a238a2245..c8f2c09b6a7 100644
> > --- a/arch/x86/lib/fsp2/fsp_dram.c
> > +++ b/arch/x86/lib/fsp2/fsp_dram.c
> > @@ -5,9 +5,9 @@
> > */
> >
> > #include <common.h>
> > -#include <acpi_s3.h>
> > #include <handoff.h>
> > #include <spl.h>
> > +#include <acpi/acpi_s3.h>
> > #include <asm/arch/cpu.h>
> > #include <asm/fsp/fsp_support.h>
> > #include <asm/fsp2/fsp_api.h>
> > diff --git a/drivers/pci/pci_rom.c b/drivers/pci/pci_rom.c
> > index 90f224b0452..6b17f18bc07 100644
> > --- a/drivers/pci/pci_rom.c
> > +++ b/drivers/pci/pci_rom.c
> > @@ -33,12 +33,10 @@
> > #include <vbe.h>
> > #include <video.h>
> > #include <video_fb.h>
> > +#include <acpi/acpi_s3.h>
> > #include <linux/screen_info.h>
> >
>
> > -#ifdef CONFIG_X86
>
> There is nothing in commit message about this change. Is it safe? Don't you get
> new compiler warnings (like defined-but-not-used)?
Not that I can see. Since it isn't specific to x86 anymore it seems
like a good idea to remove this #ifdef
Regards,
Simon
^ permalink raw reply [flat|nested] 86+ messages in thread* [PATCH v3 16/29] x86: Move acpi_s3.h to include/acpi/
2020-04-08 2:57 ` Simon Glass
@ 2020-04-08 17:03 ` Andy Shevchenko
0 siblings, 0 replies; 86+ messages in thread
From: Andy Shevchenko @ 2020-04-08 17:03 UTC (permalink / raw)
To: u-boot
On Tue, Apr 07, 2020 at 08:57:25PM -0600, Simon Glass wrote:
> On Fri, 3 Apr 2020 at 06:53, Andy Shevchenko
> <andriy.shevchenko@linux.intel.com> wrote:
> > On Mon, Mar 30, 2020 at 05:12:52PM -0600, Simon Glass wrote:
> > > This header relates to ACPI and we are about to add some more ACPI
> > > headers. Move this one into a new directory so they are together.
> > >
> >
> > FWIW,
> > Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> >
> > One nit below.
> > > -#ifdef CONFIG_X86
> >
> > There is nothing in commit message about this change. Is it safe? Don't you get
> > new compiler warnings (like defined-but-not-used)?
>
> Not that I can see. Since it isn't specific to x86 anymore it seems
> like a good idea to remove this #ifdef
Please mention in commit message.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply [flat|nested] 86+ messages in thread
* [PATCH v3 17/29] x86: Move acpi_table header to main include/ directory
2020-03-30 23:12 [PATCH v3 00/29] dm: Add programmatic generation of ACPI tables (part A) Simon Glass
` (15 preceding siblings ...)
2020-03-30 23:12 ` [PATCH v3 16/29] x86: Move acpi_s3.h to include/acpi/ Simon Glass
@ 2020-03-30 23:12 ` Simon Glass
2020-04-03 12:58 ` Andy Shevchenko
2020-03-30 23:12 ` [PATCH v3 18/29] acpi: Add an __ACPI__ preprocessor symbol Simon Glass
` (19 subsequent siblings)
36 siblings, 1 reply; 86+ messages in thread
From: Simon Glass @ 2020-03-30 23:12 UTC (permalink / raw)
To: u-boot
This file is potentially useful to other architectures saddled with ACPI
so move most of its contents to a common location.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Wolfgang Wallner <wolfgang.wallner@br-automation.com>
---
Changes in v3:
- Add forward declarations for the functions
- Move acpi_table.h to include/acpi
- Update commit message to say that we move most of its contents
Changes in v2: None
arch/x86/cpu/baytrail/acpi.c | 2 +-
arch/x86/cpu/cpu.c | 2 +-
arch/x86/cpu/quark/acpi.c | 2 +-
arch/x86/cpu/tangier/acpi.c | 4 +-
arch/x86/include/asm/acpi_table.h | 381 +----------------------------
arch/x86/lib/acpi.c | 2 +-
arch/x86/lib/acpi_s3.c | 2 +-
arch/x86/lib/acpi_table.c | 2 +-
arch/x86/lib/tables.c | 2 +-
arch/x86/lib/zimage.c | 2 +-
include/acpi/acpi_table.h | 394 ++++++++++++++++++++++++++++++
lib/efi_loader/efi_acpi.c | 2 +-
12 files changed, 412 insertions(+), 385 deletions(-)
create mode 100644 include/acpi/acpi_table.h
diff --git a/arch/x86/cpu/baytrail/acpi.c b/arch/x86/cpu/baytrail/acpi.c
index 3c27391873c..57723109796 100644
--- a/arch/x86/cpu/baytrail/acpi.c
+++ b/arch/x86/cpu/baytrail/acpi.c
@@ -7,7 +7,7 @@
#include <cpu.h>
#include <dm.h>
#include <acpi/acpi_s3.h>
-#include <asm/acpi_table.h>
+#include <acpi/acpi_table.h>
#include <asm/io.h>
#include <asm/tables.h>
#include <asm/arch/global_nvs.h>
diff --git a/arch/x86/cpu/cpu.c b/arch/x86/cpu/cpu.c
index 246ee50948c..cec04b481b9 100644
--- a/arch/x86/cpu/cpu.c
+++ b/arch/x86/cpu/cpu.c
@@ -27,8 +27,8 @@
#include <malloc.h>
#include <syscon.h>
#include <acpi/acpi_s3.h>
+#include <acpi/acpi_table.h>
#include <asm/acpi.h>
-#include <asm/acpi_table.h>
#include <asm/control_regs.h>
#include <asm/coreboot_tables.h>
#include <asm/cpu.h>
diff --git a/arch/x86/cpu/quark/acpi.c b/arch/x86/cpu/quark/acpi.c
index 7b6fc2f4a53..26cda3b3376 100644
--- a/arch/x86/cpu/quark/acpi.c
+++ b/arch/x86/cpu/quark/acpi.c
@@ -4,7 +4,7 @@
*/
#include <common.h>
-#include <asm/acpi_table.h>
+#include <acpi/acpi_table.h>
#include <asm/tables.h>
#include <asm/arch/global_nvs.h>
#include <asm/arch/iomap.h>
diff --git a/arch/x86/cpu/tangier/acpi.c b/arch/x86/cpu/tangier/acpi.c
index 8b128138b0d..4ec8fdd6f89 100644
--- a/arch/x86/cpu/tangier/acpi.c
+++ b/arch/x86/cpu/tangier/acpi.c
@@ -8,13 +8,13 @@
#include <common.h>
#include <cpu.h>
#include <dm.h>
-#include <dm/uclass-internal.h>
-#include <asm/acpi_table.h>
+#include <acpi/acpi_table.h>
#include <asm/ioapic.h>
#include <asm/mpspec.h>
#include <asm/tables.h>
#include <asm/arch/global_nvs.h>
#include <asm/arch/iomap.h>
+#include <dm/uclass-internal.h>
void acpi_create_fadt(struct acpi_fadt *fadt, struct acpi_facs *facs,
void *dsdt)
diff --git a/arch/x86/include/asm/acpi_table.h b/arch/x86/include/asm/acpi_table.h
index 7588913f937..928475cef4e 100644
--- a/arch/x86/include/asm/acpi_table.h
+++ b/arch/x86/include/asm/acpi_table.h
@@ -9,381 +9,14 @@
#ifndef __ASM_ACPI_TABLE_H__
#define __ASM_ACPI_TABLE_H__
-#define RSDP_SIG "RSD PTR " /* RSDP pointer signature */
-#define OEM_ID "U-BOOT" /* U-Boot */
-#define OEM_TABLE_ID "U-BOOTBL" /* U-Boot Table */
-#define ASLC_ID "INTL" /* Intel ASL Compiler */
-
-#define ACPI_RSDP_REV_ACPI_1_0 0
-#define ACPI_RSDP_REV_ACPI_2_0 2
-
-/*
- * RSDP (Root System Description Pointer)
- * Note: ACPI 1.0 didn't have length, xsdt_address, and ext_checksum
- */
-struct acpi_rsdp {
- char signature[8]; /* RSDP signature */
- u8 checksum; /* Checksum of the first 20 bytes */
- char oem_id[6]; /* OEM ID */
- u8 revision; /* 0 for ACPI 1.0, others 2 */
- u32 rsdt_address; /* Physical address of RSDT (32 bits) */
- u32 length; /* Total RSDP length (incl. extended part) */
- u64 xsdt_address; /* Physical address of XSDT (64 bits) */
- u8 ext_checksum; /* Checksum of the whole table */
- u8 reserved[3];
-};
-
-/* Generic ACPI header, provided by (almost) all tables */
-struct __packed acpi_table_header {
- char signature[4]; /* ACPI signature (4 ASCII characters) */
- u32 length; /* Table length in bytes (incl. header) */
- u8 revision; /* Table version (not ACPI version!) */
- volatile u8 checksum; /* To make sum of entire table == 0 */
- char oem_id[6]; /* OEM identification */
- char oem_table_id[8]; /* OEM table identification */
- u32 oem_revision; /* OEM revision number */
- char aslc_id[4]; /* ASL compiler vendor ID */
- u32 aslc_revision; /* ASL compiler revision number */
-};
-
-/* A maximum number of 32 ACPI tables ought to be enough for now */
-#define MAX_ACPI_TABLES 32
-
-/* RSDT (Root System Description Table) */
-struct acpi_rsdt {
- struct acpi_table_header header;
- u32 entry[MAX_ACPI_TABLES];
-};
-
-/* XSDT (Extended System Description Table) */
-struct acpi_xsdt {
- struct acpi_table_header header;
- u64 entry[MAX_ACPI_TABLES];
-};
-
-/* FADT Preferred Power Management Profile */
-enum acpi_pm_profile {
- ACPI_PM_UNSPECIFIED = 0,
- ACPI_PM_DESKTOP,
- ACPI_PM_MOBILE,
- ACPI_PM_WORKSTATION,
- ACPI_PM_ENTERPRISE_SERVER,
- ACPI_PM_SOHO_SERVER,
- ACPI_PM_APPLIANCE_PC,
- ACPI_PM_PERFORMANCE_SERVER,
- ACPI_PM_TABLET
-};
-
-/* FADT flags for p_lvl2_lat and p_lvl3_lat */
-#define ACPI_FADT_C2_NOT_SUPPORTED 101
-#define ACPI_FADT_C3_NOT_SUPPORTED 1001
-
-/* FADT Boot Architecture Flags */
-#define ACPI_FADT_LEGACY_FREE 0x00
-#define ACPI_FADT_LEGACY_DEVICES (1 << 0)
-#define ACPI_FADT_8042 (1 << 1)
-#define ACPI_FADT_VGA_NOT_PRESENT (1 << 2)
-#define ACPI_FADT_MSI_NOT_SUPPORTED (1 << 3)
-#define ACPI_FADT_NO_PCIE_ASPM_CONTROL (1 << 4)
-
-/* FADT Feature Flags */
-#define ACPI_FADT_WBINVD (1 << 0)
-#define ACPI_FADT_WBINVD_FLUSH (1 << 1)
-#define ACPI_FADT_C1_SUPPORTED (1 << 2)
-#define ACPI_FADT_C2_MP_SUPPORTED (1 << 3)
-#define ACPI_FADT_POWER_BUTTON (1 << 4)
-#define ACPI_FADT_SLEEP_BUTTON (1 << 5)
-#define ACPI_FADT_FIXED_RTC (1 << 6)
-#define ACPI_FADT_S4_RTC_WAKE (1 << 7)
-#define ACPI_FADT_32BIT_TIMER (1 << 8)
-#define ACPI_FADT_DOCKING_SUPPORTED (1 << 9)
-#define ACPI_FADT_RESET_REGISTER (1 << 10)
-#define ACPI_FADT_SEALED_CASE (1 << 11)
-#define ACPI_FADT_HEADLESS (1 << 12)
-#define ACPI_FADT_SLEEP_TYPE (1 << 13)
-#define ACPI_FADT_PCI_EXPRESS_WAKE (1 << 14)
-#define ACPI_FADT_PLATFORM_CLOCK (1 << 15)
-#define ACPI_FADT_S4_RTC_VALID (1 << 16)
-#define ACPI_FADT_REMOTE_POWER_ON (1 << 17)
-#define ACPI_FADT_APIC_CLUSTER (1 << 18)
-#define ACPI_FADT_APIC_PHYSICAL (1 << 19)
-#define ACPI_FADT_HW_REDUCED_ACPI (1 << 20)
-#define ACPI_FADT_LOW_PWR_IDLE_S0 (1 << 21)
-
-enum acpi_address_space_type {
- ACPI_ADDRESS_SPACE_MEMORY = 0, /* System memory */
- ACPI_ADDRESS_SPACE_IO, /* System I/O */
- ACPI_ADDRESS_SPACE_PCI, /* PCI config space */
- ACPI_ADDRESS_SPACE_EC, /* Embedded controller */
- ACPI_ADDRESS_SPACE_SMBUS, /* SMBus */
- ACPI_ADDRESS_SPACE_PCC = 0x0a, /* Platform Comm. Channel */
- ACPI_ADDRESS_SPACE_FIXED = 0x7f /* Functional fixed hardware */
-};
-
-enum acpi_address_space_size {
- ACPI_ACCESS_SIZE_UNDEFINED = 0,
- ACPI_ACCESS_SIZE_BYTE_ACCESS,
- ACPI_ACCESS_SIZE_WORD_ACCESS,
- ACPI_ACCESS_SIZE_DWORD_ACCESS,
- ACPI_ACCESS_SIZE_QWORD_ACCESS
-};
-
-struct acpi_gen_regaddr {
- u8 space_id; /* Address space ID */
- u8 bit_width; /* Register size in bits */
- u8 bit_offset; /* Register bit offset */
- u8 access_size; /* Access size */
- u32 addrl; /* Register address, low 32 bits */
- u32 addrh; /* Register address, high 32 bits */
-};
-
-/* FADT (Fixed ACPI Description Table) */
-struct __packed acpi_fadt {
- struct acpi_table_header header;
- u32 firmware_ctrl;
- u32 dsdt;
- u8 res1;
- u8 preferred_pm_profile;
- u16 sci_int;
- u32 smi_cmd;
- u8 acpi_enable;
- u8 acpi_disable;
- u8 s4bios_req;
- u8 pstate_cnt;
- u32 pm1a_evt_blk;
- u32 pm1b_evt_blk;
- u32 pm1a_cnt_blk;
- u32 pm1b_cnt_blk;
- u32 pm2_cnt_blk;
- u32 pm_tmr_blk;
- u32 gpe0_blk;
- u32 gpe1_blk;
- u8 pm1_evt_len;
- u8 pm1_cnt_len;
- u8 pm2_cnt_len;
- u8 pm_tmr_len;
- u8 gpe0_blk_len;
- u8 gpe1_blk_len;
- u8 gpe1_base;
- u8 cst_cnt;
- u16 p_lvl2_lat;
- u16 p_lvl3_lat;
- u16 flush_size;
- u16 flush_stride;
- u8 duty_offset;
- u8 duty_width;
- u8 day_alrm;
- u8 mon_alrm;
- u8 century;
- u16 iapc_boot_arch;
- u8 res2;
- u32 flags;
- struct acpi_gen_regaddr reset_reg;
- u8 reset_value;
- u16 arm_boot_arch;
- u8 minor_revision;
- u32 x_firmware_ctl_l;
- u32 x_firmware_ctl_h;
- u32 x_dsdt_l;
- u32 x_dsdt_h;
- struct acpi_gen_regaddr x_pm1a_evt_blk;
- struct acpi_gen_regaddr x_pm1b_evt_blk;
- struct acpi_gen_regaddr x_pm1a_cnt_blk;
- struct acpi_gen_regaddr x_pm1b_cnt_blk;
- struct acpi_gen_regaddr x_pm2_cnt_blk;
- struct acpi_gen_regaddr x_pm_tmr_blk;
- struct acpi_gen_regaddr x_gpe0_blk;
- struct acpi_gen_regaddr x_gpe1_blk;
-};
-
-/* FACS flags */
-#define ACPI_FACS_S4BIOS_F (1 << 0)
-#define ACPI_FACS_64BIT_WAKE_F (1 << 1)
-
-/* FACS (Firmware ACPI Control Structure) */
-struct acpi_facs {
- char signature[4]; /* "FACS" */
- u32 length; /* Length in bytes (>= 64) */
- u32 hardware_signature; /* Hardware signature */
- u32 firmware_waking_vector; /* Firmware waking vector */
- u32 global_lock; /* Global lock */
- u32 flags; /* FACS flags */
- u32 x_firmware_waking_vector_l; /* X FW waking vector, low */
- u32 x_firmware_waking_vector_h; /* X FW waking vector, high */
- u8 version; /* Version 2 */
- u8 res1[3];
- u32 ospm_flags; /* OSPM enabled flags */
- u8 res2[24];
-};
-
-/* MADT flags */
-#define ACPI_MADT_PCAT_COMPAT (1 << 0)
-
-/* MADT (Multiple APIC Description Table) */
-struct acpi_madt {
- struct acpi_table_header header;
- u32 lapic_addr; /* Local APIC address */
- u32 flags; /* Multiple APIC flags */
-};
-
-/* MADT: APIC Structure Type*/
-enum acpi_apic_types {
- ACPI_APIC_LAPIC = 0, /* Processor local APIC */
- ACPI_APIC_IOAPIC, /* I/O APIC */
- ACPI_APIC_IRQ_SRC_OVERRIDE, /* Interrupt source override */
- ACPI_APIC_NMI_SRC, /* NMI source */
- ACPI_APIC_LAPIC_NMI, /* Local APIC NMI */
- ACPI_APIC_LAPIC_ADDR_OVERRIDE, /* Local APIC address override */
- ACPI_APIC_IOSAPIC, /* I/O SAPIC */
- ACPI_APIC_LSAPIC, /* Local SAPIC */
- ACPI_APIC_PLATFORM_IRQ_SRC, /* Platform interrupt sources */
- ACPI_APIC_LX2APIC, /* Processor local x2APIC */
- ACPI_APIC_LX2APIC_NMI, /* Local x2APIC NMI */
-};
-
-/* MADT: Processor Local APIC Structure */
-
-#define LOCAL_APIC_FLAG_ENABLED (1 << 0)
-
-struct acpi_madt_lapic {
- u8 type; /* Type (0) */
- u8 length; /* Length in bytes (8) */
- u8 processor_id; /* ACPI processor ID */
- u8 apic_id; /* Local APIC ID */
- u32 flags; /* Local APIC flags */
-};
-
-/* MADT: I/O APIC Structure */
-struct acpi_madt_ioapic {
- u8 type; /* Type (1) */
- u8 length; /* Length in bytes (12) */
- u8 ioapic_id; /* I/O APIC ID */
- u8 reserved;
- u32 ioapic_addr; /* I/O APIC address */
- u32 gsi_base; /* Global system interrupt base */
-};
-
-/* MADT: Interrupt Source Override Structure */
-struct __packed acpi_madt_irqoverride {
- u8 type; /* Type (2) */
- u8 length; /* Length in bytes (10) */
- u8 bus; /* ISA (0) */
- u8 source; /* Bus-relative int. source (IRQ) */
- u32 gsirq; /* Global system interrupt */
- u16 flags; /* MPS INTI flags */
-};
-
-/* MADT: Local APIC NMI Structure */
-struct __packed acpi_madt_lapic_nmi {
- u8 type; /* Type (4) */
- u8 length; /* Length in bytes (6) */
- u8 processor_id; /* ACPI processor ID */
- u16 flags; /* MPS INTI flags */
- u8 lint; /* Local APIC LINT# */
-};
-
-/* MCFG (PCI Express MMIO config space BAR description table) */
-struct acpi_mcfg {
- struct acpi_table_header header;
- u8 reserved[8];
-};
-
-struct acpi_mcfg_mmconfig {
- u32 base_address_l;
- u32 base_address_h;
- u16 pci_segment_group_number;
- u8 start_bus_number;
- u8 end_bus_number;
- u8 reserved[4];
-};
-
-/* PM1_CNT bit defines */
-#define PM1_CNT_SCI_EN (1 << 0)
-
-/* ACPI global NVS structure */
+struct acpi_facs;
+struct acpi_fadt;
struct acpi_global_nvs;
-
-/* CSRT (Core System Resource Table) */
-struct acpi_csrt {
- struct acpi_table_header header;
-};
-
-struct acpi_csrt_group {
- u32 length;
- u32 vendor_id;
- u32 subvendor_id;
- u16 device_id;
- u16 subdevice_id;
- u16 revision;
- u16 reserved;
- u32 shared_info_length;
-};
-
-struct acpi_csrt_shared_info {
- u16 major_version;
- u16 minor_version;
- u32 mmio_base_low;
- u32 mmio_base_high;
- u32 gsi_interrupt;
- u8 interrupt_polarity;
- u8 interrupt_mode;
- u8 num_channels;
- u8 dma_address_width;
- u16 base_request_line;
- u16 num_handshake_signals;
- u32 max_block_size;
-};
-
-/* DBG2 definitions are partially used for SPCR interface_type */
-
-/* Types for port_type field */
-
-#define ACPI_DBG2_SERIAL_PORT 0x8000
-#define ACPI_DBG2_1394_PORT 0x8001
-#define ACPI_DBG2_USB_PORT 0x8002
-#define ACPI_DBG2_NET_PORT 0x8003
-
-/* Subtypes for port_subtype field */
-
-#define ACPI_DBG2_16550_COMPATIBLE 0x0000
-#define ACPI_DBG2_16550_SUBSET 0x0001
-#define ACPI_DBG2_ARM_PL011 0x0003
-#define ACPI_DBG2_ARM_SBSA_32BIT 0x000D
-#define ACPI_DBG2_ARM_SBSA_GENERIC 0x000E
-#define ACPI_DBG2_ARM_DCC 0x000F
-#define ACPI_DBG2_BCM2835 0x0010
-
-#define ACPI_DBG2_1394_STANDARD 0x0000
-
-#define ACPI_DBG2_USB_XHCI 0x0000
-#define ACPI_DBG2_USB_EHCI 0x0001
-
-#define ACPI_DBG2_UNKNOWN 0x00FF
-
-/* SPCR (Serial Port Console Redirection table) */
-struct __packed acpi_spcr {
- struct acpi_table_header header;
- u8 interface_type;
- u8 reserved[3];
- struct acpi_gen_regaddr serial_port;
- u8 interrupt_type;
- u8 pc_interrupt;
- u32 interrupt; /* Global system interrupt */
- u8 baud_rate;
- u8 parity;
- u8 stop_bits;
- u8 flow_control;
- u8 terminal_type;
- u8 reserved1;
- u16 pci_device_id; /* Must be 0xffff if not PCI device */
- u16 pci_vendor_id; /* Must be 0xffff if not PCI device */
- u8 pci_bus;
- u8 pci_device;
- u8 pci_function;
- u32 pci_flags;
- u8 pci_segment;
- u32 reserved2;
-};
+struct acpi_madt_ioapic;
+struct acpi_madt_irqoverride;
+struct acpi_madt_lapic_nmi;
+struct acpi_mcfg_mmconfig;
+struct acpi_table_header;
/* These can be used by the target port */
diff --git a/arch/x86/lib/acpi.c b/arch/x86/lib/acpi.c
index cba9c24dd45..7431458dcf2 100644
--- a/arch/x86/lib/acpi.c
+++ b/arch/x86/lib/acpi.c
@@ -4,7 +4,7 @@
*/
#include <common.h>
-#include <asm/acpi_table.h>
+#include <acpi/acpi_table.h>
#include <asm/io.h>
#include <asm/tables.h>
diff --git a/arch/x86/lib/acpi_s3.c b/arch/x86/lib/acpi_s3.c
index c3759ec8492..52410a515df 100644
--- a/arch/x86/lib/acpi_s3.c
+++ b/arch/x86/lib/acpi_s3.c
@@ -5,8 +5,8 @@
#include <common.h>
#include <acpi/acpi_s3.h>
+#include <acpi/acpi_table.h>
#include <asm/acpi.h>
-#include <asm/acpi_table.h>
#include <asm/post.h>
#include <linux/linkage.h>
diff --git a/arch/x86/lib/acpi_table.c b/arch/x86/lib/acpi_table.c
index 0d69cf271f4..a00663d4d17 100644
--- a/arch/x86/lib/acpi_table.c
+++ b/arch/x86/lib/acpi_table.c
@@ -12,8 +12,8 @@
#include <dm/uclass-internal.h>
#include <serial.h>
#include <version.h>
+#include <acpi/acpi_table.h>
#include <asm/acpi/global_nvs.h>
-#include <asm/acpi_table.h>
#include <asm/ioapic.h>
#include <asm/lapic.h>
#include <asm/mpspec.h>
diff --git a/arch/x86/lib/tables.c b/arch/x86/lib/tables.c
index 7aea722d0b8..574d331d76f 100644
--- a/arch/x86/lib/tables.c
+++ b/arch/x86/lib/tables.c
@@ -6,10 +6,10 @@
#include <common.h>
#include <malloc.h>
#include <smbios.h>
+#include <acpi/acpi_table.h>
#include <asm/sfi.h>
#include <asm/mpspec.h>
#include <asm/tables.h>
-#include <asm/acpi_table.h>
#include <asm/coreboot_tables.h>
/**
diff --git a/arch/x86/lib/zimage.c b/arch/x86/lib/zimage.c
index 9b5e767ccc2..ffc09630b7d 100644
--- a/arch/x86/lib/zimage.c
+++ b/arch/x86/lib/zimage.c
@@ -16,7 +16,7 @@
#include <env.h>
#include <irq_func.h>
#include <malloc.h>
-#include <asm/acpi_table.h>
+#include <acpi/acpi_table.h>
#include <asm/io.h>
#include <asm/ptrace.h>
#include <asm/zimage.h>
diff --git a/include/acpi/acpi_table.h b/include/acpi/acpi_table.h
new file mode 100644
index 00000000000..b4404a632c0
--- /dev/null
+++ b/include/acpi/acpi_table.h
@@ -0,0 +1,394 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Helpers for ACPI table generation
+ *
+ * Based on acpi.c from coreboot
+ *
+ * Copyright 2019 Google LLC
+ *
+ * Copyright (C) 2015, Saket Sinha <saket.sinha89@gmail.com>
+ * Copyright (C) 2016, Bin Meng <bmeng.cn@gmail.com>
+ */
+
+#ifndef __ACPI_TABLE_H__
+#define __ACPI_TABLE_H__
+
+#define RSDP_SIG "RSD PTR " /* RSDP pointer signature */
+#define OEM_ID "U-BOOT" /* U-Boot */
+#define OEM_TABLE_ID "U-BOOTBL" /* U-Boot Table */
+#define ASLC_ID "INTL" /* Intel ASL Compiler */
+
+#define ACPI_RSDP_REV_ACPI_1_0 0
+#define ACPI_RSDP_REV_ACPI_2_0 2
+
+/*
+ * RSDP (Root System Description Pointer)
+ * Note: ACPI 1.0 didn't have length, xsdt_address, and ext_checksum
+ */
+struct acpi_rsdp {
+ char signature[8]; /* RSDP signature */
+ u8 checksum; /* Checksum of the first 20 bytes */
+ char oem_id[6]; /* OEM ID */
+ u8 revision; /* 0 for ACPI 1.0, others 2 */
+ u32 rsdt_address; /* Physical address of RSDT (32 bits) */
+ u32 length; /* Total RSDP length (incl. extended part) */
+ u64 xsdt_address; /* Physical address of XSDT (64 bits) */
+ u8 ext_checksum; /* Checksum of the whole table */
+ u8 reserved[3];
+};
+
+/* Generic ACPI header, provided by (almost) all tables */
+struct __packed acpi_table_header {
+ char signature[4]; /* ACPI signature (4 ASCII characters) */
+ u32 length; /* Table length in bytes (incl. header) */
+ u8 revision; /* Table version (not ACPI version!) */
+ volatile u8 checksum; /* To make sum of entire table == 0 */
+ char oem_id[6]; /* OEM identification */
+ char oem_table_id[8]; /* OEM table identification */
+ u32 oem_revision; /* OEM revision number */
+ char aslc_id[4]; /* ASL compiler vendor ID */
+ u32 aslc_revision; /* ASL compiler revision number */
+};
+
+/* A maximum number of 32 ACPI tables ought to be enough for now */
+#define MAX_ACPI_TABLES 32
+
+/* RSDT (Root System Description Table) */
+struct acpi_rsdt {
+ struct acpi_table_header header;
+ u32 entry[MAX_ACPI_TABLES];
+};
+
+/* XSDT (Extended System Description Table) */
+struct acpi_xsdt {
+ struct acpi_table_header header;
+ u64 entry[MAX_ACPI_TABLES];
+};
+
+/* FADT Preferred Power Management Profile */
+enum acpi_pm_profile {
+ ACPI_PM_UNSPECIFIED = 0,
+ ACPI_PM_DESKTOP,
+ ACPI_PM_MOBILE,
+ ACPI_PM_WORKSTATION,
+ ACPI_PM_ENTERPRISE_SERVER,
+ ACPI_PM_SOHO_SERVER,
+ ACPI_PM_APPLIANCE_PC,
+ ACPI_PM_PERFORMANCE_SERVER,
+ ACPI_PM_TABLET
+};
+
+/* FADT flags for p_lvl2_lat and p_lvl3_lat */
+#define ACPI_FADT_C2_NOT_SUPPORTED 101
+#define ACPI_FADT_C3_NOT_SUPPORTED 1001
+
+/* FADT Boot Architecture Flags */
+#define ACPI_FADT_LEGACY_FREE 0x00
+#define ACPI_FADT_LEGACY_DEVICES BIT(0)
+#define ACPI_FADT_8042 BIT(1)
+#define ACPI_FADT_VGA_NOT_PRESENT BIT(2)
+#define ACPI_FADT_MSI_NOT_SUPPORTED BIT(3)
+#define ACPI_FADT_NO_PCIE_ASPM_CONTROL BIT(4)
+
+/* FADT Feature Flags */
+#define ACPI_FADT_WBINVD BIT(0)
+#define ACPI_FADT_WBINVD_FLUSH BIT(1)
+#define ACPI_FADT_C1_SUPPORTED BIT(2)
+#define ACPI_FADT_C2_MP_SUPPORTED BIT(3)
+#define ACPI_FADT_POWER_BUTTON BIT(4)
+#define ACPI_FADT_SLEEP_BUTTON BIT(5)
+#define ACPI_FADT_FIXED_RTC BIT(6)
+#define ACPI_FADT_S4_RTC_WAKE BIT(7)
+#define ACPI_FADT_32BIT_TIMER BIT(8)
+#define ACPI_FADT_DOCKING_SUPPORTED BIT(9)
+#define ACPI_FADT_RESET_REGISTER BIT(10)
+#define ACPI_FADT_SEALED_CASE BIT(11)
+#define ACPI_FADT_HEADLESS BIT(12)
+#define ACPI_FADT_SLEEP_TYPE BIT(13)
+#define ACPI_FADT_PCI_EXPRESS_WAKE BIT(14)
+#define ACPI_FADT_PLATFORM_CLOCK BIT(15)
+#define ACPI_FADT_S4_RTC_VALID BIT(16)
+#define ACPI_FADT_REMOTE_POWER_ON BIT(17)
+#define ACPI_FADT_APIC_CLUSTER BIT(18)
+#define ACPI_FADT_APIC_PHYSICAL BIT(19)
+#define ACPI_FADT_HW_REDUCED_ACPI BIT(20)
+#define ACPI_FADT_LOW_PWR_IDLE_S0 BIT(21)
+
+enum acpi_address_space_type {
+ ACPI_ADDRESS_SPACE_MEMORY = 0, /* System memory */
+ ACPI_ADDRESS_SPACE_IO, /* System I/O */
+ ACPI_ADDRESS_SPACE_PCI, /* PCI config space */
+ ACPI_ADDRESS_SPACE_EC, /* Embedded controller */
+ ACPI_ADDRESS_SPACE_SMBUS, /* SMBus */
+ ACPI_ADDRESS_SPACE_PCC = 0x0a, /* Platform Comm. Channel */
+ ACPI_ADDRESS_SPACE_FIXED = 0x7f /* Functional fixed hardware */
+};
+
+enum acpi_address_space_size {
+ ACPI_ACCESS_SIZE_UNDEFINED = 0,
+ ACPI_ACCESS_SIZE_BYTE_ACCESS,
+ ACPI_ACCESS_SIZE_WORD_ACCESS,
+ ACPI_ACCESS_SIZE_DWORD_ACCESS,
+ ACPI_ACCESS_SIZE_QWORD_ACCESS
+};
+
+struct acpi_gen_regaddr {
+ u8 space_id; /* Address space ID */
+ u8 bit_width; /* Register size in bits */
+ u8 bit_offset; /* Register bit offset */
+ u8 access_size; /* Access size */
+ u32 addrl; /* Register address, low 32 bits */
+ u32 addrh; /* Register address, high 32 bits */
+};
+
+/* FADT (Fixed ACPI Description Table) */
+struct __packed acpi_fadt {
+ struct acpi_table_header header;
+ u32 firmware_ctrl;
+ u32 dsdt;
+ u8 res1;
+ u8 preferred_pm_profile;
+ u16 sci_int;
+ u32 smi_cmd;
+ u8 acpi_enable;
+ u8 acpi_disable;
+ u8 s4bios_req;
+ u8 pstate_cnt;
+ u32 pm1a_evt_blk;
+ u32 pm1b_evt_blk;
+ u32 pm1a_cnt_blk;
+ u32 pm1b_cnt_blk;
+ u32 pm2_cnt_blk;
+ u32 pm_tmr_blk;
+ u32 gpe0_blk;
+ u32 gpe1_blk;
+ u8 pm1_evt_len;
+ u8 pm1_cnt_len;
+ u8 pm2_cnt_len;
+ u8 pm_tmr_len;
+ u8 gpe0_blk_len;
+ u8 gpe1_blk_len;
+ u8 gpe1_base;
+ u8 cst_cnt;
+ u16 p_lvl2_lat;
+ u16 p_lvl3_lat;
+ u16 flush_size;
+ u16 flush_stride;
+ u8 duty_offset;
+ u8 duty_width;
+ u8 day_alrm;
+ u8 mon_alrm;
+ u8 century;
+ u16 iapc_boot_arch;
+ u8 res2;
+ u32 flags;
+ struct acpi_gen_regaddr reset_reg;
+ u8 reset_value;
+ u16 arm_boot_arch;
+ u8 minor_revision;
+ u32 x_firmware_ctl_l;
+ u32 x_firmware_ctl_h;
+ u32 x_dsdt_l;
+ u32 x_dsdt_h;
+ struct acpi_gen_regaddr x_pm1a_evt_blk;
+ struct acpi_gen_regaddr x_pm1b_evt_blk;
+ struct acpi_gen_regaddr x_pm1a_cnt_blk;
+ struct acpi_gen_regaddr x_pm1b_cnt_blk;
+ struct acpi_gen_regaddr x_pm2_cnt_blk;
+ struct acpi_gen_regaddr x_pm_tmr_blk;
+ struct acpi_gen_regaddr x_gpe0_blk;
+ struct acpi_gen_regaddr x_gpe1_blk;
+};
+
+/* FACS flags */
+#define ACPI_FACS_S4BIOS_F BIT(0)
+#define ACPI_FACS_64BIT_WAKE_F BIT(1)
+
+/* FACS (Firmware ACPI Control Structure) */
+struct acpi_facs {
+ char signature[4]; /* "FACS" */
+ u32 length; /* Length in bytes (>= 64) */
+ u32 hardware_signature; /* Hardware signature */
+ u32 firmware_waking_vector; /* Firmware waking vector */
+ u32 global_lock; /* Global lock */
+ u32 flags; /* FACS flags */
+ u32 x_firmware_waking_vector_l; /* X FW waking vector, low */
+ u32 x_firmware_waking_vector_h; /* X FW waking vector, high */
+ u8 version; /* Version 2 */
+ u8 res1[3];
+ u32 ospm_flags; /* OSPM enabled flags */
+ u8 res2[24];
+};
+
+/* MADT flags */
+#define ACPI_MADT_PCAT_COMPAT BIT(0)
+
+/* MADT (Multiple APIC Description Table) */
+struct acpi_madt {
+ struct acpi_table_header header;
+ u32 lapic_addr; /* Local APIC address */
+ u32 flags; /* Multiple APIC flags */
+};
+
+/* MADT: APIC Structure Type*/
+enum acpi_apic_types {
+ ACPI_APIC_LAPIC = 0, /* Processor local APIC */
+ ACPI_APIC_IOAPIC, /* I/O APIC */
+ ACPI_APIC_IRQ_SRC_OVERRIDE, /* Interrupt source override */
+ ACPI_APIC_NMI_SRC, /* NMI source */
+ ACPI_APIC_LAPIC_NMI, /* Local APIC NMI */
+ ACPI_APIC_LAPIC_ADDR_OVERRIDE, /* Local APIC address override */
+ ACPI_APIC_IOSAPIC, /* I/O SAPIC */
+ ACPI_APIC_LSAPIC, /* Local SAPIC */
+ ACPI_APIC_PLATFORM_IRQ_SRC, /* Platform interrupt sources */
+ ACPI_APIC_LX2APIC, /* Processor local x2APIC */
+ ACPI_APIC_LX2APIC_NMI, /* Local x2APIC NMI */
+};
+
+/* MADT: Processor Local APIC Structure */
+
+#define LOCAL_APIC_FLAG_ENABLED BIT(0)
+
+struct acpi_madt_lapic {
+ u8 type; /* Type (0) */
+ u8 length; /* Length in bytes (8) */
+ u8 processor_id; /* ACPI processor ID */
+ u8 apic_id; /* Local APIC ID */
+ u32 flags; /* Local APIC flags */
+};
+
+/* MADT: I/O APIC Structure */
+struct acpi_madt_ioapic {
+ u8 type; /* Type (1) */
+ u8 length; /* Length in bytes (12) */
+ u8 ioapic_id; /* I/O APIC ID */
+ u8 reserved;
+ u32 ioapic_addr; /* I/O APIC address */
+ u32 gsi_base; /* Global system interrupt base */
+};
+
+/* MADT: Interrupt Source Override Structure */
+struct __packed acpi_madt_irqoverride {
+ u8 type; /* Type (2) */
+ u8 length; /* Length in bytes (10) */
+ u8 bus; /* ISA (0) */
+ u8 source; /* Bus-relative int. source (IRQ) */
+ u32 gsirq; /* Global system interrupt */
+ u16 flags; /* MPS INTI flags */
+};
+
+/* MADT: Local APIC NMI Structure */
+struct __packed acpi_madt_lapic_nmi {
+ u8 type; /* Type (4) */
+ u8 length; /* Length in bytes (6) */
+ u8 processor_id; /* ACPI processor ID */
+ u16 flags; /* MPS INTI flags */
+ u8 lint; /* Local APIC LINT# */
+};
+
+/* MCFG (PCI Express MMIO config space BAR description table) */
+struct acpi_mcfg {
+ struct acpi_table_header header;
+ u8 reserved[8];
+};
+
+struct acpi_mcfg_mmconfig {
+ u32 base_address_l;
+ u32 base_address_h;
+ u16 pci_segment_group_number;
+ u8 start_bus_number;
+ u8 end_bus_number;
+ u8 reserved[4];
+};
+
+/* PM1_CNT bit defines */
+#define PM1_CNT_SCI_EN BIT(0)
+
+/* ACPI global NVS structure */
+struct acpi_global_nvs;
+
+/* CSRT (Core System Resource Table) */
+struct acpi_csrt {
+ struct acpi_table_header header;
+};
+
+struct acpi_csrt_group {
+ u32 length;
+ u32 vendor_id;
+ u32 subvendor_id;
+ u16 device_id;
+ u16 subdevice_id;
+ u16 revision;
+ u16 reserved;
+ u32 shared_info_length;
+};
+
+struct acpi_csrt_shared_info {
+ u16 major_version;
+ u16 minor_version;
+ u32 mmio_base_low;
+ u32 mmio_base_high;
+ u32 gsi_interrupt;
+ u8 interrupt_polarity;
+ u8 interrupt_mode;
+ u8 num_channels;
+ u8 dma_address_width;
+ u16 base_request_line;
+ u16 num_handshake_signals;
+ u32 max_block_size;
+};
+
+/* DBG2 definitions are partially used for SPCR interface_type */
+
+/* Types for port_type field */
+
+#define ACPI_DBG2_SERIAL_PORT 0x8000
+#define ACPI_DBG2_1394_PORT 0x8001
+#define ACPI_DBG2_USB_PORT 0x8002
+#define ACPI_DBG2_NET_PORT 0x8003
+
+/* Subtypes for port_subtype field */
+
+#define ACPI_DBG2_16550_COMPATIBLE 0x0000
+#define ACPI_DBG2_16550_SUBSET 0x0001
+#define ACPI_DBG2_ARM_PL011 0x0003
+#define ACPI_DBG2_ARM_SBSA_32BIT 0x000D
+#define ACPI_DBG2_ARM_SBSA_GENERIC 0x000E
+#define ACPI_DBG2_ARM_DCC 0x000F
+#define ACPI_DBG2_BCM2835 0x0010
+
+#define ACPI_DBG2_1394_STANDARD 0x0000
+
+#define ACPI_DBG2_USB_XHCI 0x0000
+#define ACPI_DBG2_USB_EHCI 0x0001
+
+#define ACPI_DBG2_UNKNOWN 0x00FF
+
+/* SPCR (Serial Port Console Redirection table) */
+struct __packed acpi_spcr {
+ struct acpi_table_header header;
+ u8 interface_type;
+ u8 reserved[3];
+ struct acpi_gen_regaddr serial_port;
+ u8 interrupt_type;
+ u8 pc_interrupt;
+ u32 interrupt; /* Global system interrupt */
+ u8 baud_rate;
+ u8 parity;
+ u8 stop_bits;
+ u8 flow_control;
+ u8 terminal_type;
+ u8 reserved1;
+ u16 pci_device_id; /* Must be 0xffff if not PCI device */
+ u16 pci_vendor_id; /* Must be 0xffff if not PCI device */
+ u8 pci_bus;
+ u8 pci_device;
+ u8 pci_function;
+ u32 pci_flags;
+ u8 pci_segment;
+ u32 reserved2;
+};
+
+#include <asm/acpi_table.h>
+
+#endif /* __ACPI_TABLE_H__ */
diff --git a/lib/efi_loader/efi_acpi.c b/lib/efi_loader/efi_acpi.c
index a4e5e53d15e..9ae9c25c51e 100644
--- a/lib/efi_loader/efi_acpi.c
+++ b/lib/efi_loader/efi_acpi.c
@@ -7,7 +7,7 @@
#include <common.h>
#include <efi_loader.h>
-#include <asm/acpi_table.h>
+#include <acpi/acpi_table.h>
static const efi_guid_t acpi_guid = EFI_ACPI_TABLE_GUID;
--
2.26.0.rc2.310.g2932bb562d-goog
^ permalink raw reply related [flat|nested] 86+ messages in thread* [PATCH v3 17/29] x86: Move acpi_table header to main include/ directory
2020-03-30 23:12 ` [PATCH v3 17/29] x86: Move acpi_table header to main include/ directory Simon Glass
@ 2020-04-03 12:58 ` Andy Shevchenko
2020-04-08 2:57 ` Simon Glass
0 siblings, 1 reply; 86+ messages in thread
From: Andy Shevchenko @ 2020-04-03 12:58 UTC (permalink / raw)
To: u-boot
On Mon, Mar 30, 2020 at 05:12:53PM -0600, Simon Glass wrote:
> This file is potentially useful to other architectures saddled with ACPI
> so move most of its contents to a common location.
It's not just potentially, it's definitely useful.
But this makes me think, why we don't incorporate ACPICA headers as is?
>
> Signed-off-by: Simon Glass <sjg@chromium.org>
> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
> Reviewed-by: Wolfgang Wallner <wolfgang.wallner@br-automation.com>
> ---
>
> Changes in v3:
> - Add forward declarations for the functions
> - Move acpi_table.h to include/acpi
> - Update commit message to say that we move most of its contents
>
> Changes in v2: None
>
> arch/x86/cpu/baytrail/acpi.c | 2 +-
> arch/x86/cpu/cpu.c | 2 +-
> arch/x86/cpu/quark/acpi.c | 2 +-
> arch/x86/cpu/tangier/acpi.c | 4 +-
> arch/x86/include/asm/acpi_table.h | 381 +----------------------------
> arch/x86/lib/acpi.c | 2 +-
> arch/x86/lib/acpi_s3.c | 2 +-
> arch/x86/lib/acpi_table.c | 2 +-
> arch/x86/lib/tables.c | 2 +-
> arch/x86/lib/zimage.c | 2 +-
> include/acpi/acpi_table.h | 394 ++++++++++++++++++++++++++++++
> lib/efi_loader/efi_acpi.c | 2 +-
> 12 files changed, 412 insertions(+), 385 deletions(-)
> create mode 100644 include/acpi/acpi_table.h
>
> diff --git a/arch/x86/cpu/baytrail/acpi.c b/arch/x86/cpu/baytrail/acpi.c
> index 3c27391873c..57723109796 100644
> --- a/arch/x86/cpu/baytrail/acpi.c
> +++ b/arch/x86/cpu/baytrail/acpi.c
> @@ -7,7 +7,7 @@
> #include <cpu.h>
> #include <dm.h>
> #include <acpi/acpi_s3.h>
> -#include <asm/acpi_table.h>
> +#include <acpi/acpi_table.h>
> #include <asm/io.h>
> #include <asm/tables.h>
> #include <asm/arch/global_nvs.h>
> diff --git a/arch/x86/cpu/cpu.c b/arch/x86/cpu/cpu.c
> index 246ee50948c..cec04b481b9 100644
> --- a/arch/x86/cpu/cpu.c
> +++ b/arch/x86/cpu/cpu.c
> @@ -27,8 +27,8 @@
> #include <malloc.h>
> #include <syscon.h>
> #include <acpi/acpi_s3.h>
> +#include <acpi/acpi_table.h>
> #include <asm/acpi.h>
> -#include <asm/acpi_table.h>
> #include <asm/control_regs.h>
> #include <asm/coreboot_tables.h>
> #include <asm/cpu.h>
> diff --git a/arch/x86/cpu/quark/acpi.c b/arch/x86/cpu/quark/acpi.c
> index 7b6fc2f4a53..26cda3b3376 100644
> --- a/arch/x86/cpu/quark/acpi.c
> +++ b/arch/x86/cpu/quark/acpi.c
> @@ -4,7 +4,7 @@
> */
>
> #include <common.h>
> -#include <asm/acpi_table.h>
> +#include <acpi/acpi_table.h>
> #include <asm/tables.h>
> #include <asm/arch/global_nvs.h>
> #include <asm/arch/iomap.h>
> diff --git a/arch/x86/cpu/tangier/acpi.c b/arch/x86/cpu/tangier/acpi.c
> index 8b128138b0d..4ec8fdd6f89 100644
> --- a/arch/x86/cpu/tangier/acpi.c
> +++ b/arch/x86/cpu/tangier/acpi.c
> @@ -8,13 +8,13 @@
> #include <common.h>
> #include <cpu.h>
> #include <dm.h>
> -#include <dm/uclass-internal.h>
> -#include <asm/acpi_table.h>
> +#include <acpi/acpi_table.h>
> #include <asm/ioapic.h>
> #include <asm/mpspec.h>
> #include <asm/tables.h>
> #include <asm/arch/global_nvs.h>
> #include <asm/arch/iomap.h>
> +#include <dm/uclass-internal.h>
>
> void acpi_create_fadt(struct acpi_fadt *fadt, struct acpi_facs *facs,
> void *dsdt)
> diff --git a/arch/x86/include/asm/acpi_table.h b/arch/x86/include/asm/acpi_table.h
> index 7588913f937..928475cef4e 100644
> --- a/arch/x86/include/asm/acpi_table.h
> +++ b/arch/x86/include/asm/acpi_table.h
> @@ -9,381 +9,14 @@
> #ifndef __ASM_ACPI_TABLE_H__
> #define __ASM_ACPI_TABLE_H__
>
> -#define RSDP_SIG "RSD PTR " /* RSDP pointer signature */
> -#define OEM_ID "U-BOOT" /* U-Boot */
> -#define OEM_TABLE_ID "U-BOOTBL" /* U-Boot Table */
> -#define ASLC_ID "INTL" /* Intel ASL Compiler */
> -
> -#define ACPI_RSDP_REV_ACPI_1_0 0
> -#define ACPI_RSDP_REV_ACPI_2_0 2
> -
> -/*
> - * RSDP (Root System Description Pointer)
> - * Note: ACPI 1.0 didn't have length, xsdt_address, and ext_checksum
> - */
> -struct acpi_rsdp {
> - char signature[8]; /* RSDP signature */
> - u8 checksum; /* Checksum of the first 20 bytes */
> - char oem_id[6]; /* OEM ID */
> - u8 revision; /* 0 for ACPI 1.0, others 2 */
> - u32 rsdt_address; /* Physical address of RSDT (32 bits) */
> - u32 length; /* Total RSDP length (incl. extended part) */
> - u64 xsdt_address; /* Physical address of XSDT (64 bits) */
> - u8 ext_checksum; /* Checksum of the whole table */
> - u8 reserved[3];
> -};
> -
> -/* Generic ACPI header, provided by (almost) all tables */
> -struct __packed acpi_table_header {
> - char signature[4]; /* ACPI signature (4 ASCII characters) */
> - u32 length; /* Table length in bytes (incl. header) */
> - u8 revision; /* Table version (not ACPI version!) */
> - volatile u8 checksum; /* To make sum of entire table == 0 */
> - char oem_id[6]; /* OEM identification */
> - char oem_table_id[8]; /* OEM table identification */
> - u32 oem_revision; /* OEM revision number */
> - char aslc_id[4]; /* ASL compiler vendor ID */
> - u32 aslc_revision; /* ASL compiler revision number */
> -};
> -
> -/* A maximum number of 32 ACPI tables ought to be enough for now */
> -#define MAX_ACPI_TABLES 32
> -
> -/* RSDT (Root System Description Table) */
> -struct acpi_rsdt {
> - struct acpi_table_header header;
> - u32 entry[MAX_ACPI_TABLES];
> -};
> -
> -/* XSDT (Extended System Description Table) */
> -struct acpi_xsdt {
> - struct acpi_table_header header;
> - u64 entry[MAX_ACPI_TABLES];
> -};
> -
> -/* FADT Preferred Power Management Profile */
> -enum acpi_pm_profile {
> - ACPI_PM_UNSPECIFIED = 0,
> - ACPI_PM_DESKTOP,
> - ACPI_PM_MOBILE,
> - ACPI_PM_WORKSTATION,
> - ACPI_PM_ENTERPRISE_SERVER,
> - ACPI_PM_SOHO_SERVER,
> - ACPI_PM_APPLIANCE_PC,
> - ACPI_PM_PERFORMANCE_SERVER,
> - ACPI_PM_TABLET
> -};
> -
> -/* FADT flags for p_lvl2_lat and p_lvl3_lat */
> -#define ACPI_FADT_C2_NOT_SUPPORTED 101
> -#define ACPI_FADT_C3_NOT_SUPPORTED 1001
> -
> -/* FADT Boot Architecture Flags */
> -#define ACPI_FADT_LEGACY_FREE 0x00
> -#define ACPI_FADT_LEGACY_DEVICES (1 << 0)
> -#define ACPI_FADT_8042 (1 << 1)
> -#define ACPI_FADT_VGA_NOT_PRESENT (1 << 2)
> -#define ACPI_FADT_MSI_NOT_SUPPORTED (1 << 3)
> -#define ACPI_FADT_NO_PCIE_ASPM_CONTROL (1 << 4)
> -
> -/* FADT Feature Flags */
> -#define ACPI_FADT_WBINVD (1 << 0)
> -#define ACPI_FADT_WBINVD_FLUSH (1 << 1)
> -#define ACPI_FADT_C1_SUPPORTED (1 << 2)
> -#define ACPI_FADT_C2_MP_SUPPORTED (1 << 3)
> -#define ACPI_FADT_POWER_BUTTON (1 << 4)
> -#define ACPI_FADT_SLEEP_BUTTON (1 << 5)
> -#define ACPI_FADT_FIXED_RTC (1 << 6)
> -#define ACPI_FADT_S4_RTC_WAKE (1 << 7)
> -#define ACPI_FADT_32BIT_TIMER (1 << 8)
> -#define ACPI_FADT_DOCKING_SUPPORTED (1 << 9)
> -#define ACPI_FADT_RESET_REGISTER (1 << 10)
> -#define ACPI_FADT_SEALED_CASE (1 << 11)
> -#define ACPI_FADT_HEADLESS (1 << 12)
> -#define ACPI_FADT_SLEEP_TYPE (1 << 13)
> -#define ACPI_FADT_PCI_EXPRESS_WAKE (1 << 14)
> -#define ACPI_FADT_PLATFORM_CLOCK (1 << 15)
> -#define ACPI_FADT_S4_RTC_VALID (1 << 16)
> -#define ACPI_FADT_REMOTE_POWER_ON (1 << 17)
> -#define ACPI_FADT_APIC_CLUSTER (1 << 18)
> -#define ACPI_FADT_APIC_PHYSICAL (1 << 19)
> -#define ACPI_FADT_HW_REDUCED_ACPI (1 << 20)
> -#define ACPI_FADT_LOW_PWR_IDLE_S0 (1 << 21)
> -
> -enum acpi_address_space_type {
> - ACPI_ADDRESS_SPACE_MEMORY = 0, /* System memory */
> - ACPI_ADDRESS_SPACE_IO, /* System I/O */
> - ACPI_ADDRESS_SPACE_PCI, /* PCI config space */
> - ACPI_ADDRESS_SPACE_EC, /* Embedded controller */
> - ACPI_ADDRESS_SPACE_SMBUS, /* SMBus */
> - ACPI_ADDRESS_SPACE_PCC = 0x0a, /* Platform Comm. Channel */
> - ACPI_ADDRESS_SPACE_FIXED = 0x7f /* Functional fixed hardware */
> -};
> -
> -enum acpi_address_space_size {
> - ACPI_ACCESS_SIZE_UNDEFINED = 0,
> - ACPI_ACCESS_SIZE_BYTE_ACCESS,
> - ACPI_ACCESS_SIZE_WORD_ACCESS,
> - ACPI_ACCESS_SIZE_DWORD_ACCESS,
> - ACPI_ACCESS_SIZE_QWORD_ACCESS
> -};
> -
> -struct acpi_gen_regaddr {
> - u8 space_id; /* Address space ID */
> - u8 bit_width; /* Register size in bits */
> - u8 bit_offset; /* Register bit offset */
> - u8 access_size; /* Access size */
> - u32 addrl; /* Register address, low 32 bits */
> - u32 addrh; /* Register address, high 32 bits */
> -};
> -
> -/* FADT (Fixed ACPI Description Table) */
> -struct __packed acpi_fadt {
> - struct acpi_table_header header;
> - u32 firmware_ctrl;
> - u32 dsdt;
> - u8 res1;
> - u8 preferred_pm_profile;
> - u16 sci_int;
> - u32 smi_cmd;
> - u8 acpi_enable;
> - u8 acpi_disable;
> - u8 s4bios_req;
> - u8 pstate_cnt;
> - u32 pm1a_evt_blk;
> - u32 pm1b_evt_blk;
> - u32 pm1a_cnt_blk;
> - u32 pm1b_cnt_blk;
> - u32 pm2_cnt_blk;
> - u32 pm_tmr_blk;
> - u32 gpe0_blk;
> - u32 gpe1_blk;
> - u8 pm1_evt_len;
> - u8 pm1_cnt_len;
> - u8 pm2_cnt_len;
> - u8 pm_tmr_len;
> - u8 gpe0_blk_len;
> - u8 gpe1_blk_len;
> - u8 gpe1_base;
> - u8 cst_cnt;
> - u16 p_lvl2_lat;
> - u16 p_lvl3_lat;
> - u16 flush_size;
> - u16 flush_stride;
> - u8 duty_offset;
> - u8 duty_width;
> - u8 day_alrm;
> - u8 mon_alrm;
> - u8 century;
> - u16 iapc_boot_arch;
> - u8 res2;
> - u32 flags;
> - struct acpi_gen_regaddr reset_reg;
> - u8 reset_value;
> - u16 arm_boot_arch;
> - u8 minor_revision;
> - u32 x_firmware_ctl_l;
> - u32 x_firmware_ctl_h;
> - u32 x_dsdt_l;
> - u32 x_dsdt_h;
> - struct acpi_gen_regaddr x_pm1a_evt_blk;
> - struct acpi_gen_regaddr x_pm1b_evt_blk;
> - struct acpi_gen_regaddr x_pm1a_cnt_blk;
> - struct acpi_gen_regaddr x_pm1b_cnt_blk;
> - struct acpi_gen_regaddr x_pm2_cnt_blk;
> - struct acpi_gen_regaddr x_pm_tmr_blk;
> - struct acpi_gen_regaddr x_gpe0_blk;
> - struct acpi_gen_regaddr x_gpe1_blk;
> -};
> -
> -/* FACS flags */
> -#define ACPI_FACS_S4BIOS_F (1 << 0)
> -#define ACPI_FACS_64BIT_WAKE_F (1 << 1)
> -
> -/* FACS (Firmware ACPI Control Structure) */
> -struct acpi_facs {
> - char signature[4]; /* "FACS" */
> - u32 length; /* Length in bytes (>= 64) */
> - u32 hardware_signature; /* Hardware signature */
> - u32 firmware_waking_vector; /* Firmware waking vector */
> - u32 global_lock; /* Global lock */
> - u32 flags; /* FACS flags */
> - u32 x_firmware_waking_vector_l; /* X FW waking vector, low */
> - u32 x_firmware_waking_vector_h; /* X FW waking vector, high */
> - u8 version; /* Version 2 */
> - u8 res1[3];
> - u32 ospm_flags; /* OSPM enabled flags */
> - u8 res2[24];
> -};
> -
> -/* MADT flags */
> -#define ACPI_MADT_PCAT_COMPAT (1 << 0)
> -
> -/* MADT (Multiple APIC Description Table) */
> -struct acpi_madt {
> - struct acpi_table_header header;
> - u32 lapic_addr; /* Local APIC address */
> - u32 flags; /* Multiple APIC flags */
> -};
> -
> -/* MADT: APIC Structure Type*/
> -enum acpi_apic_types {
> - ACPI_APIC_LAPIC = 0, /* Processor local APIC */
> - ACPI_APIC_IOAPIC, /* I/O APIC */
> - ACPI_APIC_IRQ_SRC_OVERRIDE, /* Interrupt source override */
> - ACPI_APIC_NMI_SRC, /* NMI source */
> - ACPI_APIC_LAPIC_NMI, /* Local APIC NMI */
> - ACPI_APIC_LAPIC_ADDR_OVERRIDE, /* Local APIC address override */
> - ACPI_APIC_IOSAPIC, /* I/O SAPIC */
> - ACPI_APIC_LSAPIC, /* Local SAPIC */
> - ACPI_APIC_PLATFORM_IRQ_SRC, /* Platform interrupt sources */
> - ACPI_APIC_LX2APIC, /* Processor local x2APIC */
> - ACPI_APIC_LX2APIC_NMI, /* Local x2APIC NMI */
> -};
> -
> -/* MADT: Processor Local APIC Structure */
> -
> -#define LOCAL_APIC_FLAG_ENABLED (1 << 0)
> -
> -struct acpi_madt_lapic {
> - u8 type; /* Type (0) */
> - u8 length; /* Length in bytes (8) */
> - u8 processor_id; /* ACPI processor ID */
> - u8 apic_id; /* Local APIC ID */
> - u32 flags; /* Local APIC flags */
> -};
> -
> -/* MADT: I/O APIC Structure */
> -struct acpi_madt_ioapic {
> - u8 type; /* Type (1) */
> - u8 length; /* Length in bytes (12) */
> - u8 ioapic_id; /* I/O APIC ID */
> - u8 reserved;
> - u32 ioapic_addr; /* I/O APIC address */
> - u32 gsi_base; /* Global system interrupt base */
> -};
> -
> -/* MADT: Interrupt Source Override Structure */
> -struct __packed acpi_madt_irqoverride {
> - u8 type; /* Type (2) */
> - u8 length; /* Length in bytes (10) */
> - u8 bus; /* ISA (0) */
> - u8 source; /* Bus-relative int. source (IRQ) */
> - u32 gsirq; /* Global system interrupt */
> - u16 flags; /* MPS INTI flags */
> -};
> -
> -/* MADT: Local APIC NMI Structure */
> -struct __packed acpi_madt_lapic_nmi {
> - u8 type; /* Type (4) */
> - u8 length; /* Length in bytes (6) */
> - u8 processor_id; /* ACPI processor ID */
> - u16 flags; /* MPS INTI flags */
> - u8 lint; /* Local APIC LINT# */
> -};
> -
> -/* MCFG (PCI Express MMIO config space BAR description table) */
> -struct acpi_mcfg {
> - struct acpi_table_header header;
> - u8 reserved[8];
> -};
> -
> -struct acpi_mcfg_mmconfig {
> - u32 base_address_l;
> - u32 base_address_h;
> - u16 pci_segment_group_number;
> - u8 start_bus_number;
> - u8 end_bus_number;
> - u8 reserved[4];
> -};
> -
> -/* PM1_CNT bit defines */
> -#define PM1_CNT_SCI_EN (1 << 0)
> -
> -/* ACPI global NVS structure */
> +struct acpi_facs;
> +struct acpi_fadt;
> struct acpi_global_nvs;
> -
> -/* CSRT (Core System Resource Table) */
> -struct acpi_csrt {
> - struct acpi_table_header header;
> -};
> -
> -struct acpi_csrt_group {
> - u32 length;
> - u32 vendor_id;
> - u32 subvendor_id;
> - u16 device_id;
> - u16 subdevice_id;
> - u16 revision;
> - u16 reserved;
> - u32 shared_info_length;
> -};
> -
> -struct acpi_csrt_shared_info {
> - u16 major_version;
> - u16 minor_version;
> - u32 mmio_base_low;
> - u32 mmio_base_high;
> - u32 gsi_interrupt;
> - u8 interrupt_polarity;
> - u8 interrupt_mode;
> - u8 num_channels;
> - u8 dma_address_width;
> - u16 base_request_line;
> - u16 num_handshake_signals;
> - u32 max_block_size;
> -};
> -
> -/* DBG2 definitions are partially used for SPCR interface_type */
> -
> -/* Types for port_type field */
> -
> -#define ACPI_DBG2_SERIAL_PORT 0x8000
> -#define ACPI_DBG2_1394_PORT 0x8001
> -#define ACPI_DBG2_USB_PORT 0x8002
> -#define ACPI_DBG2_NET_PORT 0x8003
> -
> -/* Subtypes for port_subtype field */
> -
> -#define ACPI_DBG2_16550_COMPATIBLE 0x0000
> -#define ACPI_DBG2_16550_SUBSET 0x0001
> -#define ACPI_DBG2_ARM_PL011 0x0003
> -#define ACPI_DBG2_ARM_SBSA_32BIT 0x000D
> -#define ACPI_DBG2_ARM_SBSA_GENERIC 0x000E
> -#define ACPI_DBG2_ARM_DCC 0x000F
> -#define ACPI_DBG2_BCM2835 0x0010
> -
> -#define ACPI_DBG2_1394_STANDARD 0x0000
> -
> -#define ACPI_DBG2_USB_XHCI 0x0000
> -#define ACPI_DBG2_USB_EHCI 0x0001
> -
> -#define ACPI_DBG2_UNKNOWN 0x00FF
> -
> -/* SPCR (Serial Port Console Redirection table) */
> -struct __packed acpi_spcr {
> - struct acpi_table_header header;
> - u8 interface_type;
> - u8 reserved[3];
> - struct acpi_gen_regaddr serial_port;
> - u8 interrupt_type;
> - u8 pc_interrupt;
> - u32 interrupt; /* Global system interrupt */
> - u8 baud_rate;
> - u8 parity;
> - u8 stop_bits;
> - u8 flow_control;
> - u8 terminal_type;
> - u8 reserved1;
> - u16 pci_device_id; /* Must be 0xffff if not PCI device */
> - u16 pci_vendor_id; /* Must be 0xffff if not PCI device */
> - u8 pci_bus;
> - u8 pci_device;
> - u8 pci_function;
> - u32 pci_flags;
> - u8 pci_segment;
> - u32 reserved2;
> -};
> +struct acpi_madt_ioapic;
> +struct acpi_madt_irqoverride;
> +struct acpi_madt_lapic_nmi;
> +struct acpi_mcfg_mmconfig;
> +struct acpi_table_header;
>
> /* These can be used by the target port */
>
> diff --git a/arch/x86/lib/acpi.c b/arch/x86/lib/acpi.c
> index cba9c24dd45..7431458dcf2 100644
> --- a/arch/x86/lib/acpi.c
> +++ b/arch/x86/lib/acpi.c
> @@ -4,7 +4,7 @@
> */
>
> #include <common.h>
> -#include <asm/acpi_table.h>
> +#include <acpi/acpi_table.h>
> #include <asm/io.h>
> #include <asm/tables.h>
>
> diff --git a/arch/x86/lib/acpi_s3.c b/arch/x86/lib/acpi_s3.c
> index c3759ec8492..52410a515df 100644
> --- a/arch/x86/lib/acpi_s3.c
> +++ b/arch/x86/lib/acpi_s3.c
> @@ -5,8 +5,8 @@
>
> #include <common.h>
> #include <acpi/acpi_s3.h>
> +#include <acpi/acpi_table.h>
> #include <asm/acpi.h>
> -#include <asm/acpi_table.h>
> #include <asm/post.h>
> #include <linux/linkage.h>
>
> diff --git a/arch/x86/lib/acpi_table.c b/arch/x86/lib/acpi_table.c
> index 0d69cf271f4..a00663d4d17 100644
> --- a/arch/x86/lib/acpi_table.c
> +++ b/arch/x86/lib/acpi_table.c
> @@ -12,8 +12,8 @@
> #include <dm/uclass-internal.h>
> #include <serial.h>
> #include <version.h>
> +#include <acpi/acpi_table.h>
> #include <asm/acpi/global_nvs.h>
> -#include <asm/acpi_table.h>
> #include <asm/ioapic.h>
> #include <asm/lapic.h>
> #include <asm/mpspec.h>
> diff --git a/arch/x86/lib/tables.c b/arch/x86/lib/tables.c
> index 7aea722d0b8..574d331d76f 100644
> --- a/arch/x86/lib/tables.c
> +++ b/arch/x86/lib/tables.c
> @@ -6,10 +6,10 @@
> #include <common.h>
> #include <malloc.h>
> #include <smbios.h>
> +#include <acpi/acpi_table.h>
> #include <asm/sfi.h>
> #include <asm/mpspec.h>
> #include <asm/tables.h>
> -#include <asm/acpi_table.h>
> #include <asm/coreboot_tables.h>
>
> /**
> diff --git a/arch/x86/lib/zimage.c b/arch/x86/lib/zimage.c
> index 9b5e767ccc2..ffc09630b7d 100644
> --- a/arch/x86/lib/zimage.c
> +++ b/arch/x86/lib/zimage.c
> @@ -16,7 +16,7 @@
> #include <env.h>
> #include <irq_func.h>
> #include <malloc.h>
> -#include <asm/acpi_table.h>
> +#include <acpi/acpi_table.h>
> #include <asm/io.h>
> #include <asm/ptrace.h>
> #include <asm/zimage.h>
> diff --git a/include/acpi/acpi_table.h b/include/acpi/acpi_table.h
> new file mode 100644
> index 00000000000..b4404a632c0
> --- /dev/null
> +++ b/include/acpi/acpi_table.h
> @@ -0,0 +1,394 @@
> +/* SPDX-License-Identifier: GPL-2.0+ */
> +/*
> + * Helpers for ACPI table generation
> + *
> + * Based on acpi.c from coreboot
> + *
> + * Copyright 2019 Google LLC
> + *
> + * Copyright (C) 2015, Saket Sinha <saket.sinha89@gmail.com>
> + * Copyright (C) 2016, Bin Meng <bmeng.cn@gmail.com>
> + */
> +
> +#ifndef __ACPI_TABLE_H__
> +#define __ACPI_TABLE_H__
> +
> +#define RSDP_SIG "RSD PTR " /* RSDP pointer signature */
> +#define OEM_ID "U-BOOT" /* U-Boot */
> +#define OEM_TABLE_ID "U-BOOTBL" /* U-Boot Table */
> +#define ASLC_ID "INTL" /* Intel ASL Compiler */
> +
> +#define ACPI_RSDP_REV_ACPI_1_0 0
> +#define ACPI_RSDP_REV_ACPI_2_0 2
> +
> +/*
> + * RSDP (Root System Description Pointer)
> + * Note: ACPI 1.0 didn't have length, xsdt_address, and ext_checksum
> + */
> +struct acpi_rsdp {
> + char signature[8]; /* RSDP signature */
> + u8 checksum; /* Checksum of the first 20 bytes */
> + char oem_id[6]; /* OEM ID */
> + u8 revision; /* 0 for ACPI 1.0, others 2 */
> + u32 rsdt_address; /* Physical address of RSDT (32 bits) */
> + u32 length; /* Total RSDP length (incl. extended part) */
> + u64 xsdt_address; /* Physical address of XSDT (64 bits) */
> + u8 ext_checksum; /* Checksum of the whole table */
> + u8 reserved[3];
> +};
> +
> +/* Generic ACPI header, provided by (almost) all tables */
> +struct __packed acpi_table_header {
> + char signature[4]; /* ACPI signature (4 ASCII characters) */
> + u32 length; /* Table length in bytes (incl. header) */
> + u8 revision; /* Table version (not ACPI version!) */
> + volatile u8 checksum; /* To make sum of entire table == 0 */
> + char oem_id[6]; /* OEM identification */
> + char oem_table_id[8]; /* OEM table identification */
> + u32 oem_revision; /* OEM revision number */
> + char aslc_id[4]; /* ASL compiler vendor ID */
> + u32 aslc_revision; /* ASL compiler revision number */
> +};
> +
> +/* A maximum number of 32 ACPI tables ought to be enough for now */
> +#define MAX_ACPI_TABLES 32
> +
> +/* RSDT (Root System Description Table) */
> +struct acpi_rsdt {
> + struct acpi_table_header header;
> + u32 entry[MAX_ACPI_TABLES];
> +};
> +
> +/* XSDT (Extended System Description Table) */
> +struct acpi_xsdt {
> + struct acpi_table_header header;
> + u64 entry[MAX_ACPI_TABLES];
> +};
> +
> +/* FADT Preferred Power Management Profile */
> +enum acpi_pm_profile {
> + ACPI_PM_UNSPECIFIED = 0,
> + ACPI_PM_DESKTOP,
> + ACPI_PM_MOBILE,
> + ACPI_PM_WORKSTATION,
> + ACPI_PM_ENTERPRISE_SERVER,
> + ACPI_PM_SOHO_SERVER,
> + ACPI_PM_APPLIANCE_PC,
> + ACPI_PM_PERFORMANCE_SERVER,
> + ACPI_PM_TABLET
> +};
> +
> +/* FADT flags for p_lvl2_lat and p_lvl3_lat */
> +#define ACPI_FADT_C2_NOT_SUPPORTED 101
> +#define ACPI_FADT_C3_NOT_SUPPORTED 1001
> +
> +/* FADT Boot Architecture Flags */
> +#define ACPI_FADT_LEGACY_FREE 0x00
> +#define ACPI_FADT_LEGACY_DEVICES BIT(0)
> +#define ACPI_FADT_8042 BIT(1)
> +#define ACPI_FADT_VGA_NOT_PRESENT BIT(2)
> +#define ACPI_FADT_MSI_NOT_SUPPORTED BIT(3)
> +#define ACPI_FADT_NO_PCIE_ASPM_CONTROL BIT(4)
> +
> +/* FADT Feature Flags */
> +#define ACPI_FADT_WBINVD BIT(0)
> +#define ACPI_FADT_WBINVD_FLUSH BIT(1)
> +#define ACPI_FADT_C1_SUPPORTED BIT(2)
> +#define ACPI_FADT_C2_MP_SUPPORTED BIT(3)
> +#define ACPI_FADT_POWER_BUTTON BIT(4)
> +#define ACPI_FADT_SLEEP_BUTTON BIT(5)
> +#define ACPI_FADT_FIXED_RTC BIT(6)
> +#define ACPI_FADT_S4_RTC_WAKE BIT(7)
> +#define ACPI_FADT_32BIT_TIMER BIT(8)
> +#define ACPI_FADT_DOCKING_SUPPORTED BIT(9)
> +#define ACPI_FADT_RESET_REGISTER BIT(10)
> +#define ACPI_FADT_SEALED_CASE BIT(11)
> +#define ACPI_FADT_HEADLESS BIT(12)
> +#define ACPI_FADT_SLEEP_TYPE BIT(13)
> +#define ACPI_FADT_PCI_EXPRESS_WAKE BIT(14)
> +#define ACPI_FADT_PLATFORM_CLOCK BIT(15)
> +#define ACPI_FADT_S4_RTC_VALID BIT(16)
> +#define ACPI_FADT_REMOTE_POWER_ON BIT(17)
> +#define ACPI_FADT_APIC_CLUSTER BIT(18)
> +#define ACPI_FADT_APIC_PHYSICAL BIT(19)
> +#define ACPI_FADT_HW_REDUCED_ACPI BIT(20)
> +#define ACPI_FADT_LOW_PWR_IDLE_S0 BIT(21)
> +
> +enum acpi_address_space_type {
> + ACPI_ADDRESS_SPACE_MEMORY = 0, /* System memory */
> + ACPI_ADDRESS_SPACE_IO, /* System I/O */
> + ACPI_ADDRESS_SPACE_PCI, /* PCI config space */
> + ACPI_ADDRESS_SPACE_EC, /* Embedded controller */
> + ACPI_ADDRESS_SPACE_SMBUS, /* SMBus */
> + ACPI_ADDRESS_SPACE_PCC = 0x0a, /* Platform Comm. Channel */
> + ACPI_ADDRESS_SPACE_FIXED = 0x7f /* Functional fixed hardware */
> +};
> +
> +enum acpi_address_space_size {
> + ACPI_ACCESS_SIZE_UNDEFINED = 0,
> + ACPI_ACCESS_SIZE_BYTE_ACCESS,
> + ACPI_ACCESS_SIZE_WORD_ACCESS,
> + ACPI_ACCESS_SIZE_DWORD_ACCESS,
> + ACPI_ACCESS_SIZE_QWORD_ACCESS
> +};
> +
> +struct acpi_gen_regaddr {
> + u8 space_id; /* Address space ID */
> + u8 bit_width; /* Register size in bits */
> + u8 bit_offset; /* Register bit offset */
> + u8 access_size; /* Access size */
> + u32 addrl; /* Register address, low 32 bits */
> + u32 addrh; /* Register address, high 32 bits */
> +};
> +
> +/* FADT (Fixed ACPI Description Table) */
> +struct __packed acpi_fadt {
> + struct acpi_table_header header;
> + u32 firmware_ctrl;
> + u32 dsdt;
> + u8 res1;
> + u8 preferred_pm_profile;
> + u16 sci_int;
> + u32 smi_cmd;
> + u8 acpi_enable;
> + u8 acpi_disable;
> + u8 s4bios_req;
> + u8 pstate_cnt;
> + u32 pm1a_evt_blk;
> + u32 pm1b_evt_blk;
> + u32 pm1a_cnt_blk;
> + u32 pm1b_cnt_blk;
> + u32 pm2_cnt_blk;
> + u32 pm_tmr_blk;
> + u32 gpe0_blk;
> + u32 gpe1_blk;
> + u8 pm1_evt_len;
> + u8 pm1_cnt_len;
> + u8 pm2_cnt_len;
> + u8 pm_tmr_len;
> + u8 gpe0_blk_len;
> + u8 gpe1_blk_len;
> + u8 gpe1_base;
> + u8 cst_cnt;
> + u16 p_lvl2_lat;
> + u16 p_lvl3_lat;
> + u16 flush_size;
> + u16 flush_stride;
> + u8 duty_offset;
> + u8 duty_width;
> + u8 day_alrm;
> + u8 mon_alrm;
> + u8 century;
> + u16 iapc_boot_arch;
> + u8 res2;
> + u32 flags;
> + struct acpi_gen_regaddr reset_reg;
> + u8 reset_value;
> + u16 arm_boot_arch;
> + u8 minor_revision;
> + u32 x_firmware_ctl_l;
> + u32 x_firmware_ctl_h;
> + u32 x_dsdt_l;
> + u32 x_dsdt_h;
> + struct acpi_gen_regaddr x_pm1a_evt_blk;
> + struct acpi_gen_regaddr x_pm1b_evt_blk;
> + struct acpi_gen_regaddr x_pm1a_cnt_blk;
> + struct acpi_gen_regaddr x_pm1b_cnt_blk;
> + struct acpi_gen_regaddr x_pm2_cnt_blk;
> + struct acpi_gen_regaddr x_pm_tmr_blk;
> + struct acpi_gen_regaddr x_gpe0_blk;
> + struct acpi_gen_regaddr x_gpe1_blk;
> +};
> +
> +/* FACS flags */
> +#define ACPI_FACS_S4BIOS_F BIT(0)
> +#define ACPI_FACS_64BIT_WAKE_F BIT(1)
> +
> +/* FACS (Firmware ACPI Control Structure) */
> +struct acpi_facs {
> + char signature[4]; /* "FACS" */
> + u32 length; /* Length in bytes (>= 64) */
> + u32 hardware_signature; /* Hardware signature */
> + u32 firmware_waking_vector; /* Firmware waking vector */
> + u32 global_lock; /* Global lock */
> + u32 flags; /* FACS flags */
> + u32 x_firmware_waking_vector_l; /* X FW waking vector, low */
> + u32 x_firmware_waking_vector_h; /* X FW waking vector, high */
> + u8 version; /* Version 2 */
> + u8 res1[3];
> + u32 ospm_flags; /* OSPM enabled flags */
> + u8 res2[24];
> +};
> +
> +/* MADT flags */
> +#define ACPI_MADT_PCAT_COMPAT BIT(0)
> +
> +/* MADT (Multiple APIC Description Table) */
> +struct acpi_madt {
> + struct acpi_table_header header;
> + u32 lapic_addr; /* Local APIC address */
> + u32 flags; /* Multiple APIC flags */
> +};
> +
> +/* MADT: APIC Structure Type*/
> +enum acpi_apic_types {
> + ACPI_APIC_LAPIC = 0, /* Processor local APIC */
> + ACPI_APIC_IOAPIC, /* I/O APIC */
> + ACPI_APIC_IRQ_SRC_OVERRIDE, /* Interrupt source override */
> + ACPI_APIC_NMI_SRC, /* NMI source */
> + ACPI_APIC_LAPIC_NMI, /* Local APIC NMI */
> + ACPI_APIC_LAPIC_ADDR_OVERRIDE, /* Local APIC address override */
> + ACPI_APIC_IOSAPIC, /* I/O SAPIC */
> + ACPI_APIC_LSAPIC, /* Local SAPIC */
> + ACPI_APIC_PLATFORM_IRQ_SRC, /* Platform interrupt sources */
> + ACPI_APIC_LX2APIC, /* Processor local x2APIC */
> + ACPI_APIC_LX2APIC_NMI, /* Local x2APIC NMI */
> +};
> +
> +/* MADT: Processor Local APIC Structure */
> +
> +#define LOCAL_APIC_FLAG_ENABLED BIT(0)
> +
> +struct acpi_madt_lapic {
> + u8 type; /* Type (0) */
> + u8 length; /* Length in bytes (8) */
> + u8 processor_id; /* ACPI processor ID */
> + u8 apic_id; /* Local APIC ID */
> + u32 flags; /* Local APIC flags */
> +};
> +
> +/* MADT: I/O APIC Structure */
> +struct acpi_madt_ioapic {
> + u8 type; /* Type (1) */
> + u8 length; /* Length in bytes (12) */
> + u8 ioapic_id; /* I/O APIC ID */
> + u8 reserved;
> + u32 ioapic_addr; /* I/O APIC address */
> + u32 gsi_base; /* Global system interrupt base */
> +};
> +
> +/* MADT: Interrupt Source Override Structure */
> +struct __packed acpi_madt_irqoverride {
> + u8 type; /* Type (2) */
> + u8 length; /* Length in bytes (10) */
> + u8 bus; /* ISA (0) */
> + u8 source; /* Bus-relative int. source (IRQ) */
> + u32 gsirq; /* Global system interrupt */
> + u16 flags; /* MPS INTI flags */
> +};
> +
> +/* MADT: Local APIC NMI Structure */
> +struct __packed acpi_madt_lapic_nmi {
> + u8 type; /* Type (4) */
> + u8 length; /* Length in bytes (6) */
> + u8 processor_id; /* ACPI processor ID */
> + u16 flags; /* MPS INTI flags */
> + u8 lint; /* Local APIC LINT# */
> +};
> +
> +/* MCFG (PCI Express MMIO config space BAR description table) */
> +struct acpi_mcfg {
> + struct acpi_table_header header;
> + u8 reserved[8];
> +};
> +
> +struct acpi_mcfg_mmconfig {
> + u32 base_address_l;
> + u32 base_address_h;
> + u16 pci_segment_group_number;
> + u8 start_bus_number;
> + u8 end_bus_number;
> + u8 reserved[4];
> +};
> +
> +/* PM1_CNT bit defines */
> +#define PM1_CNT_SCI_EN BIT(0)
> +
> +/* ACPI global NVS structure */
> +struct acpi_global_nvs;
> +
> +/* CSRT (Core System Resource Table) */
> +struct acpi_csrt {
> + struct acpi_table_header header;
> +};
> +
> +struct acpi_csrt_group {
> + u32 length;
> + u32 vendor_id;
> + u32 subvendor_id;
> + u16 device_id;
> + u16 subdevice_id;
> + u16 revision;
> + u16 reserved;
> + u32 shared_info_length;
> +};
> +
> +struct acpi_csrt_shared_info {
> + u16 major_version;
> + u16 minor_version;
> + u32 mmio_base_low;
> + u32 mmio_base_high;
> + u32 gsi_interrupt;
> + u8 interrupt_polarity;
> + u8 interrupt_mode;
> + u8 num_channels;
> + u8 dma_address_width;
> + u16 base_request_line;
> + u16 num_handshake_signals;
> + u32 max_block_size;
> +};
> +
> +/* DBG2 definitions are partially used for SPCR interface_type */
> +
> +/* Types for port_type field */
> +
> +#define ACPI_DBG2_SERIAL_PORT 0x8000
> +#define ACPI_DBG2_1394_PORT 0x8001
> +#define ACPI_DBG2_USB_PORT 0x8002
> +#define ACPI_DBG2_NET_PORT 0x8003
> +
> +/* Subtypes for port_subtype field */
> +
> +#define ACPI_DBG2_16550_COMPATIBLE 0x0000
> +#define ACPI_DBG2_16550_SUBSET 0x0001
> +#define ACPI_DBG2_ARM_PL011 0x0003
> +#define ACPI_DBG2_ARM_SBSA_32BIT 0x000D
> +#define ACPI_DBG2_ARM_SBSA_GENERIC 0x000E
> +#define ACPI_DBG2_ARM_DCC 0x000F
> +#define ACPI_DBG2_BCM2835 0x0010
> +
> +#define ACPI_DBG2_1394_STANDARD 0x0000
> +
> +#define ACPI_DBG2_USB_XHCI 0x0000
> +#define ACPI_DBG2_USB_EHCI 0x0001
> +
> +#define ACPI_DBG2_UNKNOWN 0x00FF
> +
> +/* SPCR (Serial Port Console Redirection table) */
> +struct __packed acpi_spcr {
> + struct acpi_table_header header;
> + u8 interface_type;
> + u8 reserved[3];
> + struct acpi_gen_regaddr serial_port;
> + u8 interrupt_type;
> + u8 pc_interrupt;
> + u32 interrupt; /* Global system interrupt */
> + u8 baud_rate;
> + u8 parity;
> + u8 stop_bits;
> + u8 flow_control;
> + u8 terminal_type;
> + u8 reserved1;
> + u16 pci_device_id; /* Must be 0xffff if not PCI device */
> + u16 pci_vendor_id; /* Must be 0xffff if not PCI device */
> + u8 pci_bus;
> + u8 pci_device;
> + u8 pci_function;
> + u32 pci_flags;
> + u8 pci_segment;
> + u32 reserved2;
> +};
> +
> +#include <asm/acpi_table.h>
> +
> +#endif /* __ACPI_TABLE_H__ */
> diff --git a/lib/efi_loader/efi_acpi.c b/lib/efi_loader/efi_acpi.c
> index a4e5e53d15e..9ae9c25c51e 100644
> --- a/lib/efi_loader/efi_acpi.c
> +++ b/lib/efi_loader/efi_acpi.c
> @@ -7,7 +7,7 @@
>
> #include <common.h>
> #include <efi_loader.h>
> -#include <asm/acpi_table.h>
> +#include <acpi/acpi_table.h>
>
> static const efi_guid_t acpi_guid = EFI_ACPI_TABLE_GUID;
>
> --
> 2.26.0.rc2.310.g2932bb562d-goog
>
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply [flat|nested] 86+ messages in thread* [PATCH v3 17/29] x86: Move acpi_table header to main include/ directory
2020-04-03 12:58 ` Andy Shevchenko
@ 2020-04-08 2:57 ` Simon Glass
2020-04-08 17:04 ` Andy Shevchenko
0 siblings, 1 reply; 86+ messages in thread
From: Simon Glass @ 2020-04-08 2:57 UTC (permalink / raw)
To: u-boot
Hi Andy,
On Fri, 3 Apr 2020 at 06:58, Andy Shevchenko
<andriy.shevchenko@linux.intel.com> wrote:
>
> On Mon, Mar 30, 2020 at 05:12:53PM -0600, Simon Glass wrote:
> > This file is potentially useful to other architectures saddled with ACPI
> > so move most of its contents to a common location.
>
> It's not just potentially, it's definitely useful.
> But this makes me think, why we don't incorporate ACPICA headers as is?
Due to code style and the vast amount of unused code.
>
> >
> > Signed-off-by: Simon Glass <sjg@chromium.org>
> > Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
> > Reviewed-by: Wolfgang Wallner <wolfgang.wallner@br-automation.com>
> > ---
> >
> > Changes in v3:
> > - Add forward declarations for the functions
> > - Move acpi_table.h to include/acpi
> > - Update commit message to say that we move most of its contents
> >
> > Changes in v2: None
> >
> > arch/x86/cpu/baytrail/acpi.c | 2 +-
> > arch/x86/cpu/cpu.c | 2 +-
> > arch/x86/cpu/quark/acpi.c | 2 +-
> > arch/x86/cpu/tangier/acpi.c | 4 +-
> > arch/x86/include/asm/acpi_table.h | 381 +----------------------------
> > arch/x86/lib/acpi.c | 2 +-
> > arch/x86/lib/acpi_s3.c | 2 +-
> > arch/x86/lib/acpi_table.c | 2 +-
> > arch/x86/lib/tables.c | 2 +-
> > arch/x86/lib/zimage.c | 2 +-
> > include/acpi/acpi_table.h | 394 ++++++++++++++++++++++++++++++
> > lib/efi_loader/efi_acpi.c | 2 +-
> > 12 files changed, 412 insertions(+), 385 deletions(-)
> > create mode 100644 include/acpi/acpi_table.h
> >
Regards,
Simon
^ permalink raw reply [flat|nested] 86+ messages in thread
* [PATCH v3 17/29] x86: Move acpi_table header to main include/ directory
2020-04-08 2:57 ` Simon Glass
@ 2020-04-08 17:04 ` Andy Shevchenko
2020-04-08 22:15 ` Simon Glass
0 siblings, 1 reply; 86+ messages in thread
From: Andy Shevchenko @ 2020-04-08 17:04 UTC (permalink / raw)
To: u-boot
On Tue, Apr 07, 2020 at 08:57:27PM -0600, Simon Glass wrote:
> On Fri, 3 Apr 2020 at 06:58, Andy Shevchenko
> <andriy.shevchenko@linux.intel.com> wrote:
> >
> > On Mon, Mar 30, 2020 at 05:12:53PM -0600, Simon Glass wrote:
> > > This file is potentially useful to other architectures saddled with ACPI
> > > so move most of its contents to a common location.
> >
> > It's not just potentially, it's definitely useful.
> > But this makes me think, why we don't incorporate ACPICA headers as is?
>
> Due to code style and the vast amount of unused code.
So, it will be interesting journey over the same problems then.
But it's your problem to maintain this :-)
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply [flat|nested] 86+ messages in thread
* [PATCH v3 17/29] x86: Move acpi_table header to main include/ directory
2020-04-08 17:04 ` Andy Shevchenko
@ 2020-04-08 22:15 ` Simon Glass
0 siblings, 0 replies; 86+ messages in thread
From: Simon Glass @ 2020-04-08 22:15 UTC (permalink / raw)
To: u-boot
Hi Andy,
On Wed, 8 Apr 2020 at 11:05, Andy Shevchenko
<andriy.shevchenko@linux.intel.com> wrote:
>
> On Tue, Apr 07, 2020 at 08:57:27PM -0600, Simon Glass wrote:
> > On Fri, 3 Apr 2020 at 06:58, Andy Shevchenko
> > <andriy.shevchenko@linux.intel.com> wrote:
> > >
> > > On Mon, Mar 30, 2020 at 05:12:53PM -0600, Simon Glass wrote:
> > > > This file is potentially useful to other architectures saddled with ACPI
> > > > so move most of its contents to a common location.
> > >
> > > It's not just potentially, it's definitely useful.
> > > But this makes me think, why we don't incorporate ACPICA headers as is?
> >
> > Due to code style and the vast amount of unused code.
>
> So, it will be interesting journey over the same problems then.
> But it's your problem to maintain this :-)
If Intel is interested in maintaining this in U-Boot let us know. So
long as the code style is right as we don't add dead code it should be
fine.
Regards,
Simon
^ permalink raw reply [flat|nested] 86+ messages in thread
* [PATCH v3 18/29] acpi: Add an __ACPI__ preprocessor symbol
2020-03-30 23:12 [PATCH v3 00/29] dm: Add programmatic generation of ACPI tables (part A) Simon Glass
` (16 preceding siblings ...)
2020-03-30 23:12 ` [PATCH v3 17/29] x86: Move acpi_table header to main include/ directory Simon Glass
@ 2020-03-30 23:12 ` Simon Glass
2020-03-30 23:12 ` [PATCH v3 19/29] acpi: Add a central location for table version numbers Simon Glass
` (18 subsequent siblings)
36 siblings, 0 replies; 86+ messages in thread
From: Simon Glass @ 2020-03-30 23:12 UTC (permalink / raw)
To: u-boot
The ASL compiler cannot handle C structures and the like so needs some
sort of header guard around these.
We already have an __ASSEMBLY__ #define but it seems best to create a new
one for ACPI since the rules may be different.
Add the check to a few files that ACPI always includes.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Wolfgang Wallner <wolfgang.wallner@br-automation.com>
---
Changes in v3: None
Changes in v2: None
include/acpi/acpi_table.h | 4 ++++
include/dm/acpi.h | 4 ++++
scripts/Makefile.lib | 4 ++--
3 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/include/acpi/acpi_table.h b/include/acpi/acpi_table.h
index b4404a632c0..dd748958136 100644
--- a/include/acpi/acpi_table.h
+++ b/include/acpi/acpi_table.h
@@ -21,6 +21,8 @@
#define ACPI_RSDP_REV_ACPI_1_0 0
#define ACPI_RSDP_REV_ACPI_2_0 2
+#if !defined(__ACPI__)
+
/*
* RSDP (Root System Description Pointer)
* Note: ACPI 1.0 didn't have length, xsdt_address, and ext_checksum
@@ -389,6 +391,8 @@ struct __packed acpi_spcr {
u32 reserved2;
};
+#endif /* !__ACPI__*/
+
#include <asm/acpi_table.h>
#endif /* __ACPI_TABLE_H__ */
diff --git a/include/dm/acpi.h b/include/dm/acpi.h
index c13d0c8448a..ee218b44e85 100644
--- a/include/dm/acpi.h
+++ b/include/dm/acpi.h
@@ -22,6 +22,8 @@
/* Length of an ACPI name string including nul terminator */
#define ACPI_NAME_MAX (ACPI_NAME_LEN + 1)
+#if !defined(__ACPI__)
+
/**
* struct acpi_ops - ACPI operations supported by driver model
*/
@@ -70,4 +72,6 @@ int acpi_get_name(const struct udevice *dev, char *out_name);
*/
int acpi_copy_name(char *out_name, const char *name);
+#endif /* __ACPI__ */
+
#endif
diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
index 30f392fdfb0..aebdb38d0d2 100644
--- a/scripts/Makefile.lib
+++ b/scripts/Makefile.lib
@@ -413,8 +413,8 @@ ASL_TMP = $(patsubst %.c,%.asl.tmp,$@)
quiet_cmd_acpi_c_asl= ASL $<
cmd_acpi_c_asl= \
- $(CPP) -x assembler-with-cpp -D__ASSEMBLY__ -P $(UBOOTINCLUDE) \
- -o $(ASL_TMP) $< && \
+ $(CPP) -x assembler-with-cpp -D__ASSEMBLY__ -D__ACPI__ \
+ -P $(UBOOTINCLUDE) -o $(ASL_TMP) $< && \
iasl -p $@ -tc $(ASL_TMP) $(if $(KBUILD_VERBOSE:1=), >/dev/null) && \
mv $(patsubst %.c,%.hex,$@) $@
--
2.26.0.rc2.310.g2932bb562d-goog
^ permalink raw reply related [flat|nested] 86+ messages in thread* [PATCH v3 19/29] acpi: Add a central location for table version numbers
2020-03-30 23:12 [PATCH v3 00/29] dm: Add programmatic generation of ACPI tables (part A) Simon Glass
` (17 preceding siblings ...)
2020-03-30 23:12 ` [PATCH v3 18/29] acpi: Add an __ACPI__ preprocessor symbol Simon Glass
@ 2020-03-30 23:12 ` Simon Glass
2020-04-03 13:04 ` Andy Shevchenko
2020-03-30 23:12 ` [PATCH v3 20/29] acpi: Add support for DMAR Simon Glass
` (17 subsequent siblings)
36 siblings, 1 reply; 86+ messages in thread
From: Simon Glass @ 2020-03-30 23:12 UTC (permalink / raw)
To: u-boot
Each ACPI table has its own version number. Add the version numbers in a
single function so we can keep them consistent and easily see what
versions are supported.
Start a new acpi_table file in a generic directory to house this function.
We can move things over to this file from x86 as needed.
Signed-off-by: Simon Glass <sjg@chromium.org>
---
Changes in v3:
- Fix a few typos
- Fix file comment for acpi_table.c
Changes in v2:
- Move the sandbox acpi_table.h header file to an earlier patch
- Use #defines for MADT and MCFG version numbers
include/acpi/acpi_table.h | 61 +++++++++++++++++++++++++++++++++++++++
lib/Makefile | 1 +
lib/acpi/Makefile | 4 +++
lib/acpi/acpi_table.c | 60 ++++++++++++++++++++++++++++++++++++++
test/dm/acpi.c | 14 +++++++++
5 files changed, 140 insertions(+)
create mode 100644 lib/acpi/Makefile
create mode 100644 lib/acpi/acpi_table.c
diff --git a/include/acpi/acpi_table.h b/include/acpi/acpi_table.h
index dd748958136..ccf6fa04dbe 100644
--- a/include/acpi/acpi_table.h
+++ b/include/acpi/acpi_table.h
@@ -202,6 +202,26 @@ struct __packed acpi_fadt {
struct acpi_gen_regaddr x_gpe1_blk;
};
+/* FADT TABLE Revision values */
+#define ACPI_FADT_REV_ACPI_1_0 1
+#define ACPI_FADT_REV_ACPI_2_0 3
+#define ACPI_FADT_REV_ACPI_3_0 4
+#define ACPI_FADT_REV_ACPI_4_0 4
+#define ACPI_FADT_REV_ACPI_5_0 5
+#define ACPI_FADT_REV_ACPI_6_0 6
+
+/* MADT TABLE Revision values */
+#define ACPI_MADT_REV_ACPI_3_0 2
+#define ACPI_MADT_REV_ACPI_4_0 3
+#define ACPI_MADT_REV_ACPI_5_0 3
+#define ACPI_MADT_REV_ACPI_6_0 5
+
+#define ACPI_MCFG_REV_ACPI_3_0 1
+
+/* IVRS Revision Field */
+#define IVRS_FORMAT_FIXED 0x01 /* Type 10h & 11h only */
+#define IVRS_FORMAT_MIXED 0x02 /* Type 10h, 11h, & 40h */
+
/* FACS flags */
#define ACPI_FACS_S4BIOS_F BIT(0)
#define ACPI_FACS_64BIT_WAKE_F BIT(1)
@@ -391,6 +411,47 @@ struct __packed acpi_spcr {
u32 reserved2;
};
+/* Tables defined by ACPI and generated by U-Boot */
+enum acpi_tables {
+ ACPITAB_BERT,
+ ACPITAB_DBG2,
+ ACPITAB_DMAR,
+ ACPITAB_DSDT,
+ ACPITAB_FACS,
+ ACPITAB_FADT,
+ ACPITAB_HEST,
+ ACPITAB_HPET,
+ ACPITAB_IVRS,
+ ACPITAB_MADT,
+ ACPITAB_MCFG,
+ ACPITAB_RSDP,
+ ACPITAB_RSDT,
+ ACPITAB_SLIT,
+ ACPITAB_SRAT,
+ ACPITAB_SSDT,
+ ACPITAB_TCPA,
+ ACPITAB_TPM2,
+ ACPITAB_XSDT,
+ ACPITAB_ECDT,
+
+ /* Additional proprietary tables */
+ ACPITAB_VFCT,
+ ACPITAB_NHLT,
+ ACPITAB_SPMI,
+
+ ACPITAB_COUNT,
+};
+
+/**
+ * acpi_get_table_revision() - Get the revision number generated for a table
+ *
+ * This keeps the version-number information in one place
+ *
+ * @table: ACPI table to check
+ * @return version number that U-Boot generates
+ */
+int acpi_get_table_revision(enum acpi_tables table);
+
#endif /* !__ACPI__*/
#include <asm/acpi_table.h>
diff --git a/lib/Makefile b/lib/Makefile
index 15259d0473c..f737eb559fc 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -5,6 +5,7 @@
ifndef CONFIG_SPL_BUILD
+obj-$(CONFIG_$(SPL_)ACPIGEN) += acpi/
obj-$(CONFIG_EFI) += efi/
obj-$(CONFIG_EFI_LOADER) += efi_driver/
obj-$(CONFIG_EFI_LOADER) += efi_loader/
diff --git a/lib/acpi/Makefile b/lib/acpi/Makefile
new file mode 100644
index 00000000000..660491ef711
--- /dev/null
+++ b/lib/acpi/Makefile
@@ -0,0 +1,4 @@
+# SPDX-License-Identifier: GPL-2.0+
+#
+
+obj-y += acpi_table.o
diff --git a/lib/acpi/acpi_table.c b/lib/acpi/acpi_table.c
new file mode 100644
index 00000000000..30639e4dfbd
--- /dev/null
+++ b/lib/acpi/acpi_table.c
@@ -0,0 +1,60 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Generic code used to generate ACPI tables
+ *
+ * Copyright 2019 Google LLC
+ */
+
+#include <common.h>
+#include <acpi/acpi_table.h>
+
+int acpi_get_table_revision(enum acpi_tables table)
+{
+ switch (table) {
+ case ACPITAB_FADT:
+ return ACPI_FADT_REV_ACPI_3_0;
+ case ACPITAB_MADT:
+ return ACPI_MADT_REV_ACPI_3_0;
+ case ACPITAB_MCFG:
+ return ACPI_MCFG_REV_ACPI_3_0;
+ case ACPITAB_TCPA:
+ /* This version and the rest are open-coded */
+ return 2;
+ case ACPITAB_TPM2:
+ return 4;
+ case ACPITAB_SSDT: /* ACPI 3.0 upto 6.3: 2 */
+ return 2;
+ case ACPITAB_SRAT: /* ACPI 2.0: 1, ACPI 3.0: 2, ACPI 4.0 to 6.3: 3 */
+ return 1; /* TODO Should probably be upgraded to 2 */
+ case ACPITAB_DMAR:
+ return 1;
+ case ACPITAB_SLIT: /* ACPI 2.0 upto 6.3: 1 */
+ return 1;
+ case ACPITAB_SPMI: /* IMPI 2.0 */
+ return 5;
+ case ACPITAB_HPET: /* Currently 1. Table added in ACPI 2.0 */
+ return 1;
+ case ACPITAB_VFCT: /* ACPI 2.0/3.0/4.0: 1 */
+ return 1;
+ case ACPITAB_IVRS:
+ return IVRS_FORMAT_FIXED;
+ case ACPITAB_DBG2:
+ return 0;
+ case ACPITAB_FACS: /* ACPI 2.0/3.0: 1, ACPI 4.0 to 6.3: 2 */
+ return 1;
+ case ACPITAB_RSDT: /* ACPI 1.0 upto 6.3: 1 */
+ return 1;
+ case ACPITAB_XSDT: /* ACPI 2.0 upto 6.3: 1 */
+ return 1;
+ case ACPITAB_RSDP: /* ACPI 2.0 upto 6.3: 2 */
+ return 2;
+ case ACPITAB_HEST:
+ return 1;
+ case ACPITAB_NHLT:
+ return 5;
+ case ACPITAB_BERT:
+ return 1;
+ default:
+ return -EINVAL;
+ }
+}
diff --git a/test/dm/acpi.c b/test/dm/acpi.c
index 429993b9cc0..e5510e4323b 100644
--- a/test/dm/acpi.c
+++ b/test/dm/acpi.c
@@ -8,6 +8,7 @@
#include <common.h>
#include <dm.h>
+#include <acpi/acpi_table.h>
#include <dm/acpi.h>
#include <dm/test.h>
#include <test/ut.h>
@@ -53,3 +54,16 @@ static int dm_test_acpi_get_name(struct unit_test_state *uts)
return 0;
}
DM_TEST(dm_test_acpi_get_name, DM_TESTF_SCAN_PDATA | DM_TESTF_SCAN_FDT);
+
+/* Test acpi_get_table_revision() */
+static int dm_test_acpi_get_table_revision(struct unit_test_state *uts)
+{
+ ut_asserteq(1, acpi_get_table_revision(ACPITAB_MCFG));
+ ut_asserteq(2, acpi_get_table_revision(ACPITAB_RSDP));
+ ut_asserteq(4, acpi_get_table_revision(ACPITAB_TPM2));
+ ut_asserteq(-EINVAL, acpi_get_table_revision(ACPITAB_COUNT));
+
+ return 0;
+}
+DM_TEST(dm_test_acpi_get_table_revision,
+ DM_TESTF_SCAN_PDATA | DM_TESTF_SCAN_FDT);
--
2.26.0.rc2.310.g2932bb562d-goog
^ permalink raw reply related [flat|nested] 86+ messages in thread* [PATCH v3 19/29] acpi: Add a central location for table version numbers
2020-03-30 23:12 ` [PATCH v3 19/29] acpi: Add a central location for table version numbers Simon Glass
@ 2020-04-03 13:04 ` Andy Shevchenko
2020-04-08 2:57 ` Simon Glass
0 siblings, 1 reply; 86+ messages in thread
From: Andy Shevchenko @ 2020-04-03 13:04 UTC (permalink / raw)
To: u-boot
On Mon, Mar 30, 2020 at 05:12:55PM -0600, Simon Glass wrote:
> Each ACPI table has its own version number. Add the version numbers in a
> single function so we can keep them consistent and easily see what
> versions are supported.
>
> Start a new acpi_table file in a generic directory to house this function.
> We can move things over to this file from x86 as needed.
...
> +/* FADT TABLE Revision values */
> +#define ACPI_FADT_REV_ACPI_1_0 1
> +#define ACPI_FADT_REV_ACPI_2_0 3
> +#define ACPI_FADT_REV_ACPI_3_0 4
> +#define ACPI_FADT_REV_ACPI_4_0 4
> +#define ACPI_FADT_REV_ACPI_5_0 5
> +#define ACPI_FADT_REV_ACPI_6_0 6
> +
> +/* MADT TABLE Revision values */
> +#define ACPI_MADT_REV_ACPI_3_0 2
> +#define ACPI_MADT_REV_ACPI_4_0 3
> +#define ACPI_MADT_REV_ACPI_5_0 3
> +#define ACPI_MADT_REV_ACPI_6_0 5
Is it for real this fancy numbering? I don't remember spec by heart, perhaps
this needs to be elaborated in the comment.
...
> +/* Tables defined by ACPI and generated by U-Boot */
> +enum acpi_tables {
> + ACPITAB_BERT,
> + ACPITAB_DBG2,
> + ACPITAB_DMAR,
> + ACPITAB_DSDT,
> + ACPITAB_FACS,
> + ACPITAB_FADT,
> + ACPITAB_HEST,
> + ACPITAB_HPET,
> + ACPITAB_IVRS,
> + ACPITAB_MADT,
> + ACPITAB_MCFG,
> + ACPITAB_RSDP,
> + ACPITAB_RSDT,
> + ACPITAB_SLIT,
> + ACPITAB_SRAT,
> + ACPITAB_SSDT,
> + ACPITAB_TCPA,
> + ACPITAB_TPM2,
> + ACPITAB_XSDT,
> + ACPITAB_ECDT,
This should be cleaned according to uefi.org, i.e. not all above tables are
from ACPI spec. And thus, should be rather in the below section.
> +
> + /* Additional proprietary tables */
> + ACPITAB_VFCT,
> + ACPITAB_NHLT,
> + ACPITAB_SPMI,
Where is SPCR?
> +
> + ACPITAB_COUNT,
> +};
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply [flat|nested] 86+ messages in thread* [PATCH v3 19/29] acpi: Add a central location for table version numbers
2020-04-03 13:04 ` Andy Shevchenko
@ 2020-04-08 2:57 ` Simon Glass
0 siblings, 0 replies; 86+ messages in thread
From: Simon Glass @ 2020-04-08 2:57 UTC (permalink / raw)
To: u-boot
Hi Andy,
On Fri, 3 Apr 2020 at 07:04, Andy Shevchenko
<andriy.shevchenko@linux.intel.com> wrote:
>
> On Mon, Mar 30, 2020 at 05:12:55PM -0600, Simon Glass wrote:
> > Each ACPI table has its own version number. Add the version numbers in a
> > single function so we can keep them consistent and easily see what
> > versions are supported.
> >
> > Start a new acpi_table file in a generic directory to house this function.
> > We can move things over to this file from x86 as needed.
>
> ...
>
> > +/* FADT TABLE Revision values */
> > +#define ACPI_FADT_REV_ACPI_1_0 1
> > +#define ACPI_FADT_REV_ACPI_2_0 3
> > +#define ACPI_FADT_REV_ACPI_3_0 4
> > +#define ACPI_FADT_REV_ACPI_4_0 4
> > +#define ACPI_FADT_REV_ACPI_5_0 5
> > +#define ACPI_FADT_REV_ACPI_6_0 6
> > +
> > +/* MADT TABLE Revision values */
> > +#define ACPI_MADT_REV_ACPI_3_0 2
> > +#define ACPI_MADT_REV_ACPI_4_0 3
> > +#define ACPI_MADT_REV_ACPI_5_0 3
> > +#define ACPI_MADT_REV_ACPI_6_0 5
>
> Is it for real this fancy numbering? I don't remember spec by heart, perhaps
> this needs to be elaborated in the comment.
Will add
>
> ...
>
> > +/* Tables defined by ACPI and generated by U-Boot */
> > +enum acpi_tables {
>
> > + ACPITAB_BERT,
> > + ACPITAB_DBG2,
> > + ACPITAB_DMAR,
> > + ACPITAB_DSDT,
> > + ACPITAB_FACS,
> > + ACPITAB_FADT,
> > + ACPITAB_HEST,
> > + ACPITAB_HPET,
> > + ACPITAB_IVRS,
> > + ACPITAB_MADT,
> > + ACPITAB_MCFG,
> > + ACPITAB_RSDP,
> > + ACPITAB_RSDT,
> > + ACPITAB_SLIT,
> > + ACPITAB_SRAT,
> > + ACPITAB_SSDT,
> > + ACPITAB_TCPA,
> > + ACPITAB_TPM2,
> > + ACPITAB_XSDT,
> > + ACPITAB_ECDT,
>
> This should be cleaned according to uefi.org, i.e. not all above tables are
> from ACPI spec. And thus, should be rather in the below section.
I mean things defined or reserved by the spec, so will update the comment.
>
> > +
> > + /* Additional proprietary tables */
> > + ACPITAB_VFCT,
> > + ACPITAB_NHLT,
> > + ACPITAB_SPMI,
>
> Where is SPCR?
>
Will add.
> > +
> > + ACPITAB_COUNT,
> > +};
>
> --
> With Best Regards,
> Andy Shevchenko
>
>
^ permalink raw reply [flat|nested] 86+ messages in thread
* [PATCH v3 20/29] acpi: Add support for DMAR
2020-03-30 23:12 [PATCH v3 00/29] dm: Add programmatic generation of ACPI tables (part A) Simon Glass
` (18 preceding siblings ...)
2020-03-30 23:12 ` [PATCH v3 19/29] acpi: Add a central location for table version numbers Simon Glass
@ 2020-03-30 23:12 ` Simon Glass
2020-04-03 13:15 ` Andy Shevchenko
2020-03-30 23:12 ` [PATCH v3 21/29] test: Add hexdump.h to the unit test header Simon Glass
` (16 subsequent siblings)
36 siblings, 1 reply; 86+ messages in thread
From: Simon Glass @ 2020-03-30 23:12 UTC (permalink / raw)
To: u-boot
The DMA Remapping Reporting (DMAR) table contains information about DMA
remapping.
Add a version simple version of this table with only the minimum fields
filled out. i.e. no entries.
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Signed-off-by: Simon Glass <sjg@chromium.org>
---
Changes in v3:
- Add missing error check in acpi_create_dmar()
- Drop duplicate assert
- Fix DMA_ typo
- Make use of BIT()
Changes in v2:
- Drop two unnecessary __packed
- Move __packed to after struct
include/acpi/acpi_table.h | 57 +++++++++++++++++++++++++++++++++++++++
lib/acpi/acpi_table.c | 28 +++++++++++++++++++
test/dm/acpi.c | 13 +++++++++
3 files changed, 98 insertions(+)
diff --git a/include/acpi/acpi_table.h b/include/acpi/acpi_table.h
index ccf6fa04dbe..10d6ccdf090 100644
--- a/include/acpi/acpi_table.h
+++ b/include/acpi/acpi_table.h
@@ -21,6 +21,9 @@
#define ACPI_RSDP_REV_ACPI_1_0 0
#define ACPI_RSDP_REV_ACPI_2_0 2
+/* TODO(sjg at chromium.org): Figure out how to get compiler revision */
+#define ASL_REVISION 0
+
#if !defined(__ACPI__)
/*
@@ -360,6 +363,51 @@ struct acpi_csrt_shared_info {
u32 max_block_size;
};
+enum dmar_type {
+ DMAR_DRHD = 0,
+ DMAR_RMRR = 1,
+ DMAR_ATSR = 2,
+ DMAR_RHSA = 3,
+ DMAR_ANDD = 4
+};
+
+enum {
+ DRHD_INCLUDE_PCI_ALL = BIT(0)
+};
+
+enum dmar_flags {
+ DMAR_INTR_REMAP = BIT(0),
+ DMAR_X2APIC_OPT_OUT = BIT(1),
+ DMAR_CTRL_PLATFORM_OPT_IN_FLAG = BIT(2),
+};
+
+struct dmar_entry {
+ u16 type;
+ u16 length;
+ u8 flags;
+ u8 reserved;
+ u16 segment;
+ u64 bar;
+};
+
+struct dmar_rmrr_entry {
+ u16 type;
+ u16 length;
+ u16 reserved;
+ u16 segment;
+ u64 bar;
+ u64 limit;
+};
+
+/* DMAR (DMA Remapping Reporting Structure) */
+struct __packed acpi_dmar {
+ struct acpi_table_header header;
+ u8 host_address_width;
+ u8 flags;
+ u8 reserved[10];
+ struct dmar_entry structure[0];
+};
+
/* DBG2 definitions are partially used for SPCR interface_type */
/* Types for port_type field */
@@ -452,6 +500,15 @@ enum acpi_tables {
*/
int acpi_get_table_revision(enum acpi_tables table);
+/**
+ * acpi_create_dmar() - Create a DMA Remapping Reporting (DMAR) table
+ *
+ * @dmar: Place to put the table
+ * @flags: DMAR flags to use
+ * @return 0 if OK, -ve on error
+ */
+int acpi_create_dmar(struct acpi_dmar *dmar, enum dmar_flags flags);
+
#endif /* !__ACPI__*/
#include <asm/acpi_table.h>
diff --git a/lib/acpi/acpi_table.c b/lib/acpi/acpi_table.c
index 30639e4dfbd..3156fb93503 100644
--- a/lib/acpi/acpi_table.c
+++ b/lib/acpi/acpi_table.c
@@ -7,6 +7,34 @@
#include <common.h>
#include <acpi/acpi_table.h>
+#include <dm.h>
+#include <cpu.h>
+
+int acpi_create_dmar(struct acpi_dmar *dmar, enum dmar_flags flags)
+{
+ struct acpi_table_header *header = &dmar->header;
+ struct cpu_info info;
+ struct udevice *cpu;
+ int ret;
+
+ ret = uclass_first_device(UCLASS_CPU, &cpu);
+ if (ret)
+ return log_msg_ret("cpu", ret);
+ ret = cpu_get_info(cpu, &info);
+ if (ret)
+ return log_msg_ret("info", ret);
+ memset((void *)dmar, 0, sizeof(struct acpi_dmar));
+
+ /* Fill out header fields. */
+ acpi_fill_header(&dmar->header, "DMAR");
+ header->length = sizeof(struct acpi_dmar);
+ header->revision = acpi_get_table_revision(ACPITAB_DMAR);
+
+ dmar->host_address_width = info.address_width - 1;
+ dmar->flags = flags;
+
+ return 0;
+}
int acpi_get_table_revision(enum acpi_tables table)
{
diff --git a/test/dm/acpi.c b/test/dm/acpi.c
index e5510e4323b..21ed7c74409 100644
--- a/test/dm/acpi.c
+++ b/test/dm/acpi.c
@@ -67,3 +67,16 @@ static int dm_test_acpi_get_table_revision(struct unit_test_state *uts)
}
DM_TEST(dm_test_acpi_get_table_revision,
DM_TESTF_SCAN_PDATA | DM_TESTF_SCAN_FDT);
+
+/* Test acpi_create_dmar() */
+static int dm_test_acpi_create_dmar(struct unit_test_state *uts)
+{
+ struct acpi_dmar dmar;
+
+ ut_assertok(acpi_create_dmar(&dmar, DMAR_INTR_REMAP));
+ ut_asserteq(DMAR_INTR_REMAP, dmar.flags);
+ ut_asserteq(32 - 1, dmar.host_address_width);
+
+ return 0;
+}
+DM_TEST(dm_test_acpi_create_dmar, DM_TESTF_SCAN_PDATA | DM_TESTF_SCAN_FDT);
--
2.26.0.rc2.310.g2932bb562d-goog
^ permalink raw reply related [flat|nested] 86+ messages in thread* [PATCH v3 20/29] acpi: Add support for DMAR
2020-03-30 23:12 ` [PATCH v3 20/29] acpi: Add support for DMAR Simon Glass
@ 2020-04-03 13:15 ` Andy Shevchenko
0 siblings, 0 replies; 86+ messages in thread
From: Andy Shevchenko @ 2020-04-03 13:15 UTC (permalink / raw)
To: u-boot
On Mon, Mar 30, 2020 at 05:12:56PM -0600, Simon Glass wrote:
> The DMA Remapping Reporting (DMAR) table contains information about DMA
> remapping.
>
> Add a version simple version of this table with only the minimum fields
> filled out. i.e. no entries.
> +/* TODO(sjg at chromium.org): Figure out how to get compiler revision */
> +#define ASL_REVISION 0
Why do you need this?
I don't see any users here either.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply [flat|nested] 86+ messages in thread
* [PATCH v3 21/29] test: Add hexdump.h to the unit test header
2020-03-30 23:12 [PATCH v3 00/29] dm: Add programmatic generation of ACPI tables (part A) Simon Glass
` (19 preceding siblings ...)
2020-03-30 23:12 ` [PATCH v3 20/29] acpi: Add support for DMAR Simon Glass
@ 2020-03-30 23:12 ` Simon Glass
2020-03-30 23:12 ` [PATCH v3 22/29] acpi: Add a method to write tables for a device Simon Glass
` (15 subsequent siblings)
36 siblings, 0 replies; 86+ messages in thread
From: Simon Glass @ 2020-03-30 23:12 UTC (permalink / raw)
To: u-boot
Since ut_asserteq_mem() uses bin2hex() we should include this header in
ut.h to avoid errors. Add it.
Signed-off-by: Simon Glass <sjg@chromium.org>
---
Changes in v3:
- Add new patch to add hexdump.h to the unit test header
Changes in v2: None
include/test/ut.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/test/ut.h b/include/test/ut.h
index 04df8ba3af3..39d15953ed3 100644
--- a/include/test/ut.h
+++ b/include/test/ut.h
@@ -8,6 +8,7 @@
#ifndef __TEST_UT_H
#define __TEST_UT_H
+#include <hexdump.h>
#include <linux/err.h>
struct unit_test_state;
--
2.26.0.rc2.310.g2932bb562d-goog
^ permalink raw reply related [flat|nested] 86+ messages in thread* [PATCH v3 22/29] acpi: Add a method to write tables for a device
2020-03-30 23:12 [PATCH v3 00/29] dm: Add programmatic generation of ACPI tables (part A) Simon Glass
` (20 preceding siblings ...)
2020-03-30 23:12 ` [PATCH v3 21/29] test: Add hexdump.h to the unit test header Simon Glass
@ 2020-03-30 23:12 ` Simon Glass
2020-04-03 13:20 ` Andy Shevchenko
2020-03-30 23:12 ` [PATCH v3 23/29] acpi: Convert part of acpi_table to use acpi_ctx Simon Glass
` (14 subsequent siblings)
36 siblings, 1 reply; 86+ messages in thread
From: Simon Glass @ 2020-03-30 23:12 UTC (permalink / raw)
To: u-boot
A device may want to write out ACPI tables to describe itself to Linux.
Add a method to permit this.
Reviewed-by: Wolfgang Wallner <wolfgang.wallner@br-automation.com>
Signed-off-by: Simon Glass <sjg@chromium.org>
---
Changes in v3: None
Changes in v2:
- Drop definition of ACPI_TABLE_CREATOR
- Generalise the ACPI function recursion with acpi_recurse_method()
- Make _acpi_write_dev_tables() static and switch argument order
arch/sandbox/dts/test.dts | 4 +++
arch/x86/lib/acpi_table.c | 9 -----
drivers/core/acpi.c | 61 +++++++++++++++++++++++++++++++++
include/acpi/acpi_table.h | 10 ++++++
include/dm/acpi.h | 30 +++++++++++++++++
lib/acpi/acpi_table.c | 10 ++++++
test/dm/acpi.c | 71 +++++++++++++++++++++++++++++++++++++++
7 files changed, 186 insertions(+), 9 deletions(-)
diff --git a/arch/sandbox/dts/test.dts b/arch/sandbox/dts/test.dts
index 5fa951ad4b6..1204c14b079 100644
--- a/arch/sandbox/dts/test.dts
+++ b/arch/sandbox/dts/test.dts
@@ -210,6 +210,10 @@
compatible = "denx,u-boot-acpi-test";
};
+ acpi-test2 {
+ compatible = "denx,u-boot-acpi-test";
+ };
+
clocks {
clk_fixed: clk-fixed {
compatible = "fixed-clock";
diff --git a/arch/x86/lib/acpi_table.c b/arch/x86/lib/acpi_table.c
index a00663d4d17..f98d6d17b3e 100644
--- a/arch/x86/lib/acpi_table.c
+++ b/arch/x86/lib/acpi_table.c
@@ -60,15 +60,6 @@ static void acpi_write_rsdp(struct acpi_rsdp *rsdp, struct acpi_rsdt *rsdt,
sizeof(struct acpi_rsdp));
}
-void acpi_fill_header(struct acpi_table_header *header, char *signature)
-{
- memcpy(header->signature, signature, 4);
- memcpy(header->oem_id, OEM_ID, 6);
- memcpy(header->oem_table_id, OEM_TABLE_ID, 8);
- header->oem_revision = U_BOOT_BUILD_DATE;
- memcpy(header->aslc_id, ASLC_ID, 4);
-}
-
static void acpi_write_rsdt(struct acpi_rsdt *rsdt)
{
struct acpi_table_header *header = &(rsdt->header);
diff --git a/drivers/core/acpi.c b/drivers/core/acpi.c
index 0e64c21bf5b..3059634f1f8 100644
--- a/drivers/core/acpi.c
+++ b/drivers/core/acpi.c
@@ -11,8 +11,17 @@
#include <common.h>
#include <dm.h>
#include <dm/acpi.h>
+#include <dm/device-internal.h>
#include <dm/root.h>
+/* Type of method to call */
+enum method_t {
+ METHOD_WRITE_TABLES,
+};
+
+/* Prototype for all methods */
+typedef int (*acpi_method)(const struct udevice *dev, struct acpi_ctx *ctx);
+
int acpi_copy_name(char *out_name, const char *name)
{
strncpy(out_name, name, ACPI_NAME_MAX);
@@ -31,3 +40,55 @@ int acpi_get_name(const struct udevice *dev, char *out_name)
return -ENOSYS;
}
+
+acpi_method acpi_get_method(struct udevice *dev, enum method_t method)
+{
+ struct acpi_ops *aops;
+
+ aops = device_get_acpi_ops(dev);
+ if (aops) {
+ switch (method) {
+ case METHOD_WRITE_TABLES:
+ return aops->write_tables;
+ }
+ }
+
+ return NULL;
+}
+
+int acpi_recurse_method(struct acpi_ctx *ctx, struct udevice *parent,
+ enum method_t method)
+{
+ struct udevice *dev;
+ acpi_method func;
+ int ret;
+
+ func = acpi_get_method(parent, method);
+ if (func) {
+ log_debug("\n- %s %p\n", parent->name, func);
+ ret = device_ofdata_to_platdata(parent);
+ if (ret)
+ return log_msg_ret("ofdata", ret);
+ ret = func(parent, ctx);
+ if (ret)
+ return log_msg_ret("func", ret);
+ }
+ device_foreach_child(dev, parent) {
+ ret = acpi_recurse_method(ctx, dev, method);
+ if (ret)
+ return log_msg_ret("recurse", ret);
+ }
+
+ return 0;
+}
+
+int acpi_write_dev_tables(struct acpi_ctx *ctx)
+{
+ int ret;
+
+ log_debug("Writing device tables\n");
+ ret = acpi_recurse_method(ctx, dm_root(), METHOD_WRITE_TABLES);
+ log_debug("Writing finished, err=%d\n", ret);
+
+ return ret;
+}
diff --git a/include/acpi/acpi_table.h b/include/acpi/acpi_table.h
index 10d6ccdf090..268e36b67e1 100644
--- a/include/acpi/acpi_table.h
+++ b/include/acpi/acpi_table.h
@@ -509,6 +509,16 @@ int acpi_get_table_revision(enum acpi_tables table);
*/
int acpi_create_dmar(struct acpi_dmar *dmar, enum dmar_flags flags);
+/**
+ * acpi_fill_header() - Set up a new table header
+ *
+ * This sets all fields except length, revision, checksum and aslc_revision
+ *
+ * @header: ACPI header to update
+ * @signature: Table signature to use (4 characters)
+ */
+void acpi_fill_header(struct acpi_table_header *header, char *signature);
+
#endif /* !__ACPI__*/
#include <asm/acpi_table.h>
diff --git a/include/dm/acpi.h b/include/dm/acpi.h
index ee218b44e85..9a0a437dd03 100644
--- a/include/dm/acpi.h
+++ b/include/dm/acpi.h
@@ -24,6 +24,17 @@
#if !defined(__ACPI__)
+/**
+ * struct acpi_ctx - Context used for writing ACPI tables
+ *
+ * This contains a few useful pieces of information used when writing
+ *
+ * @current: Current address for writing
+ */
+struct acpi_ctx {
+ void *current;
+};
+
/**
* struct acpi_ops - ACPI operations supported by driver model
*/
@@ -38,6 +49,15 @@ struct acpi_ops {
* other error
*/
int (*get_name)(const struct udevice *dev, char *out_name);
+
+ /**
+ * write_tables() - Write out any tables required by this device
+ *
+ * @dev: Device to write
+ * @ctx: ACPI context to use
+ * @return 0 if OK, -ve on error
+ */
+ int (*write_tables)(const struct udevice *dev, struct acpi_ctx *ctx);
};
#define device_get_acpi_ops(dev) ((dev)->driver->acpi_ops)
@@ -72,6 +92,16 @@ int acpi_get_name(const struct udevice *dev, char *out_name);
*/
int acpi_copy_name(char *out_name, const char *name);
+/**
+ * acpi_write_dev_tables() - Write ACPI tables required by devices
+ *
+ * This scans through all devices and tells them to write any tables they want
+ * to write.
+ *
+ * @return 0 if OK, -ve if any device returned an error
+ */
+int acpi_write_dev_tables(struct acpi_ctx *ctx);
+
#endif /* __ACPI__ */
#endif
diff --git a/lib/acpi/acpi_table.c b/lib/acpi/acpi_table.c
index 3156fb93503..1710cde2c40 100644
--- a/lib/acpi/acpi_table.c
+++ b/lib/acpi/acpi_table.c
@@ -9,6 +9,7 @@
#include <acpi/acpi_table.h>
#include <dm.h>
#include <cpu.h>
+#include <version.h>
int acpi_create_dmar(struct acpi_dmar *dmar, enum dmar_flags flags)
{
@@ -86,3 +87,12 @@ int acpi_get_table_revision(enum acpi_tables table)
return -EINVAL;
}
}
+
+void acpi_fill_header(struct acpi_table_header *header, char *signature)
+{
+ memcpy(header->signature, signature, 4);
+ memcpy(header->oem_id, OEM_ID, 6);
+ memcpy(header->oem_table_id, OEM_TABLE_ID, 8);
+ header->oem_revision = U_BOOT_BUILD_DATE;
+ memcpy(header->aslc_id, ASLC_ID, 4);
+}
diff --git a/test/dm/acpi.c b/test/dm/acpi.c
index 21ed7c74409..5743530a3a5 100644
--- a/test/dm/acpi.c
+++ b/test/dm/acpi.c
@@ -8,12 +8,26 @@
#include <common.h>
#include <dm.h>
+#include <version.h>
#include <acpi/acpi_table.h>
#include <dm/acpi.h>
#include <dm/test.h>
#include <test/ut.h>
#define ACPI_TEST_DEV_NAME "ABCD"
+#define BUF_SIZE 4096
+
+static int testacpi_write_tables(const struct udevice *dev,
+ struct acpi_ctx *ctx)
+{
+ struct acpi_dmar *dmar;
+
+ dmar = (struct acpi_dmar *)ctx->current;
+ acpi_create_dmar(dmar, DMAR_INTR_REMAP);
+ ctx->current += sizeof(struct acpi_dmar);
+
+ return 0;
+}
static int testacpi_get_name(const struct udevice *dev, char *out_name)
{
@@ -22,6 +36,7 @@ static int testacpi_get_name(const struct udevice *dev, char *out_name)
struct acpi_ops testacpi_ops = {
.get_name = testacpi_get_name,
+ .write_tables = testacpi_write_tables,
};
static const struct udevice_id testacpi_ids[] = {
@@ -80,3 +95,59 @@ static int dm_test_acpi_create_dmar(struct unit_test_state *uts)
return 0;
}
DM_TEST(dm_test_acpi_create_dmar, DM_TESTF_SCAN_PDATA | DM_TESTF_SCAN_FDT);
+
+/* Test acpi_fill_header() */
+static int dm_test_acpi_fill_header(struct unit_test_state *uts)
+{
+ struct acpi_table_header hdr;
+
+ /* Make sure these 5 fields are not changed */
+ hdr.length = 0x11;
+ hdr.revision = 0x22;
+ hdr.checksum = 0x33;
+ hdr.aslc_revision = 0x44;
+ acpi_fill_header(&hdr, "ABCD");
+
+ ut_asserteq_mem("ABCD", hdr.signature, sizeof(hdr.signature));
+ ut_asserteq(0x11, hdr.length);
+ ut_asserteq(0x22, hdr.revision);
+ ut_asserteq(0x33, hdr.checksum);
+ ut_asserteq_mem(OEM_ID, hdr.oem_id, sizeof(hdr.oem_id));
+ ut_asserteq_mem(OEM_TABLE_ID, hdr.oem_table_id,
+ sizeof(hdr.oem_table_id));
+ ut_asserteq(U_BOOT_BUILD_DATE, hdr.oem_revision);
+ ut_asserteq_mem(ASLC_ID, hdr.aslc_id, sizeof(hdr.aslc_id));
+ ut_asserteq(0x44, hdr.aslc_revision);
+
+ return 0;
+}
+DM_TEST(dm_test_acpi_fill_header, DM_TESTF_SCAN_PDATA | DM_TESTF_SCAN_FDT);
+
+/* Test ACPI write_tables() */
+static int dm_test_acpi_write_tables(struct unit_test_state *uts)
+{
+ struct acpi_dmar *dmar;
+ struct acpi_ctx ctx;
+ void *buf;
+
+ buf = malloc(BUF_SIZE);
+ ut_assertnonnull(buf);
+
+ ctx.current = buf;
+ ut_assertok(acpi_write_dev_tables(&ctx));
+ dmar = buf;
+
+ /*
+ * We should have two dmar tables, one for each "denx,u-boot-acpi-test"
+ * device
+ */
+ ut_asserteq_ptr(dmar + 2, ctx.current);
+ ut_asserteq(DMAR_INTR_REMAP, dmar->flags);
+ ut_asserteq(32 - 1, dmar->host_address_width);
+
+ ut_asserteq(DMAR_INTR_REMAP, dmar[1].flags);
+ ut_asserteq(32 - 1, dmar[1].host_address_width);
+
+ return 0;
+}
+DM_TEST(dm_test_acpi_write_tables, DM_TESTF_SCAN_PDATA | DM_TESTF_SCAN_FDT);
--
2.26.0.rc2.310.g2932bb562d-goog
^ permalink raw reply related [flat|nested] 86+ messages in thread* [PATCH v3 22/29] acpi: Add a method to write tables for a device
2020-03-30 23:12 ` [PATCH v3 22/29] acpi: Add a method to write tables for a device Simon Glass
@ 2020-04-03 13:20 ` Andy Shevchenko
2020-04-08 2:57 ` Simon Glass
0 siblings, 1 reply; 86+ messages in thread
From: Andy Shevchenko @ 2020-04-03 13:20 UTC (permalink / raw)
To: u-boot
On Mon, Mar 30, 2020 at 05:12:58PM -0600, Simon Glass wrote:
> A device may want to write out ACPI tables to describe itself to Linux.
> Add a method to permit this.
> +acpi_method acpi_get_method(struct udevice *dev, enum method_t method)
> +{
> + struct acpi_ops *aops;
> +
> + aops = device_get_acpi_ops(dev);
> + if (aops) {
> + switch (method) {
> + case METHOD_WRITE_TABLES:
> + return aops->write_tables;
> + }
Where is default?
> + }
> +
> + return NULL;
Perhaps,
if (!aops)
return NULL;
switch (method) {
...
default:
return NULL;
}
> +}
...
> + log_debug("\n- %s %p\n", parent->name, func);
Leading '\n' in the messages is not good idea.
It might work nicely in U-Boot, but in general better to avoid.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply [flat|nested] 86+ messages in thread* [PATCH v3 22/29] acpi: Add a method to write tables for a device
2020-04-03 13:20 ` Andy Shevchenko
@ 2020-04-08 2:57 ` Simon Glass
0 siblings, 0 replies; 86+ messages in thread
From: Simon Glass @ 2020-04-08 2:57 UTC (permalink / raw)
To: u-boot
Hi Andy,
On Fri, 3 Apr 2020 at 07:20, Andy Shevchenko
<andriy.shevchenko@linux.intel.com> wrote:
>
> On Mon, Mar 30, 2020 at 05:12:58PM -0600, Simon Glass wrote:
> > A device may want to write out ACPI tables to describe itself to Linux.
> > Add a method to permit this.
>
> > +acpi_method acpi_get_method(struct udevice *dev, enum method_t method)
> > +{
> > + struct acpi_ops *aops;
> > +
> > + aops = device_get_acpi_ops(dev);
> > + if (aops) {
> > + switch (method) {
> > + case METHOD_WRITE_TABLES:
> > + return aops->write_tables;
> > + }
>
> Where is default?
There isn't one...that would be an error. We want to get a compiler
warning if we leave something out.
>
> > + }
> > +
> > + return NULL;
>
> Perhaps,
>
> if (!aops)
> return NULL;
>
> switch (method) {
> ...
> default:
> return NULL;
> }
>
> > +}
>
> ...
>
> > + log_debug("\n- %s %p\n", parent->name, func);
>
> Leading '\n' in the messages is not good idea.
> It might work nicely in U-Boot, but in general better to avoid.
OK will separate it out.
Regards,
Simon
^ permalink raw reply [flat|nested] 86+ messages in thread
* [PATCH v3 23/29] acpi: Convert part of acpi_table to use acpi_ctx
2020-03-30 23:12 [PATCH v3 00/29] dm: Add programmatic generation of ACPI tables (part A) Simon Glass
` (21 preceding siblings ...)
2020-03-30 23:12 ` [PATCH v3 22/29] acpi: Add a method to write tables for a device Simon Glass
@ 2020-03-30 23:12 ` Simon Glass
2020-04-03 13:24 ` Andy Shevchenko
2020-03-30 23:13 ` [PATCH v3 24/29] x86: Allow devices to write ACPI tables Simon Glass
` (13 subsequent siblings)
36 siblings, 1 reply; 86+ messages in thread
From: Simon Glass @ 2020-03-30 23:12 UTC (permalink / raw)
To: u-boot
The current code uses an address but a pointer would result in fewer
casts. Also it repeats the alignment code in a lot of places so this would
be better done in a helper function.
Update write_acpi_tables() to make use of the new acpi_ctx structure,
adding a few helpers to clean things up.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Wolfgang Wallner <wolfgang.wallner@br-automation.com>
---
Changes in v3:
- Rename acpi_align_large() to acpi_align64()
Changes in v2: None
arch/x86/lib/acpi_table.c | 88 +++++++++++++++++++--------------------
include/acpi/acpi_table.h | 36 ++++++++++++++++
lib/acpi/acpi_table.c | 24 ++++++++++-
test/dm/acpi.c | 28 +++++++++++++
4 files changed, 130 insertions(+), 46 deletions(-)
diff --git a/arch/x86/lib/acpi_table.c b/arch/x86/lib/acpi_table.c
index f98d6d17b3e..afa00bc2f80 100644
--- a/arch/x86/lib/acpi_table.c
+++ b/arch/x86/lib/acpi_table.c
@@ -10,6 +10,7 @@
#include <cpu.h>
#include <dm.h>
#include <dm/uclass-internal.h>
+#include <mapmem.h>
#include <serial.h>
#include <version.h>
#include <acpi/acpi_table.h>
@@ -19,6 +20,7 @@
#include <asm/mpspec.h>
#include <asm/tables.h>
#include <asm/arch/global_nvs.h>
+#include <dm/acpi.h>
/*
* IASL compiles the dsdt entries and writes the hex values
@@ -468,9 +470,9 @@ static void acpi_create_spcr(struct acpi_spcr *spcr)
/*
* QEMU's version of write_acpi_tables is defined in drivers/misc/qfw.c
*/
-ulong write_acpi_tables(ulong start)
+ulong write_acpi_tables(ulong start_addr)
{
- u32 current;
+ struct acpi_ctx sctx, *ctx = &sctx;
struct acpi_rsdp *rsdp;
struct acpi_rsdt *rsdt;
struct acpi_xsdt *xsdt;
@@ -481,60 +483,61 @@ ulong write_acpi_tables(ulong start)
struct acpi_madt *madt;
struct acpi_csrt *csrt;
struct acpi_spcr *spcr;
+ void *start;
+ ulong addr;
int i;
- current = start;
+ start = map_sysmem(start_addr, 0);
+ ctx->current = start;
/* Align ACPI tables to 16 byte */
- current = ALIGN(current, 16);
+ acpi_align(ctx);
- debug("ACPI: Writing ACPI tables at %lx\n", start);
+ debug("ACPI: Writing ACPI tables at %lx\n", start_addr);
/* We need at least an RSDP and an RSDT Table */
- rsdp = (struct acpi_rsdp *)current;
- current += sizeof(struct acpi_rsdp);
- current = ALIGN(current, 16);
- rsdt = (struct acpi_rsdt *)current;
- current += sizeof(struct acpi_rsdt);
- current = ALIGN(current, 16);
- xsdt = (struct acpi_xsdt *)current;
- current += sizeof(struct acpi_xsdt);
+ rsdp = ctx->current;
+ acpi_inc_align(ctx, sizeof(struct acpi_rsdp));
+ rsdt = ctx->current;
+ acpi_inc_align(ctx, sizeof(struct acpi_rsdt));
+ xsdt = ctx->current;
+ acpi_inc_align(ctx, sizeof(struct acpi_xsdt));
/*
* Per ACPI spec, the FACS table address must be aligned to a 64 byte
* boundary (Windows checks this, but Linux does not).
*/
- current = ALIGN(current, 64);
+ acpi_align64(ctx);
/* clear all table memory */
- memset((void *)start, 0, current - start);
+ memset((void *)start, 0, ctx->current - start);
acpi_write_rsdp(rsdp, rsdt, xsdt);
acpi_write_rsdt(rsdt);
acpi_write_xsdt(xsdt);
debug("ACPI: * FACS\n");
- facs = (struct acpi_facs *)current;
- current += sizeof(struct acpi_facs);
- current = ALIGN(current, 16);
+ facs = ctx->current;
+ acpi_inc_align(ctx, sizeof(struct acpi_facs));
acpi_create_facs(facs);
debug("ACPI: * DSDT\n");
- dsdt = (struct acpi_table_header *)current;
+ dsdt = ctx->current;
memcpy(dsdt, &AmlCode, sizeof(struct acpi_table_header));
- current += sizeof(struct acpi_table_header);
- memcpy((char *)current,
+ acpi_inc(ctx, sizeof(struct acpi_table_header));
+ memcpy(ctx->current,
(char *)&AmlCode + sizeof(struct acpi_table_header),
dsdt->length - sizeof(struct acpi_table_header));
- current += dsdt->length - sizeof(struct acpi_table_header);
- current = ALIGN(current, 16);
+ acpi_inc_align(ctx, dsdt->length - sizeof(struct acpi_table_header));
/* Pack GNVS into the ACPI table area */
for (i = 0; i < dsdt->length; i++) {
u32 *gnvs = (u32 *)((u32)dsdt + i);
if (*gnvs == ACPI_GNVS_ADDR) {
- debug("Fix up global NVS in DSDT to 0x%08x\n", current);
- *gnvs = current;
+ ulong addr = (ulong)map_to_sysmem(ctx->current);
+
+ debug("Fix up global NVS in DSDT to %#08lx\n", addr);
+ *gnvs = addr;
break;
}
}
@@ -544,51 +547,46 @@ ulong write_acpi_tables(ulong start)
dsdt->checksum = table_compute_checksum((void *)dsdt, dsdt->length);
/* Fill in platform-specific global NVS variables */
- acpi_create_gnvs((struct acpi_global_nvs *)current);
- current += sizeof(struct acpi_global_nvs);
- current = ALIGN(current, 16);
+ acpi_create_gnvs(ctx->current);
+ acpi_inc_align(ctx, sizeof(struct acpi_global_nvs));
debug("ACPI: * FADT\n");
- fadt = (struct acpi_fadt *)current;
- current += sizeof(struct acpi_fadt);
- current = ALIGN(current, 16);
+ fadt = ctx->current;
+ acpi_inc_align(ctx, sizeof(struct acpi_fadt));
acpi_create_fadt(fadt, facs, dsdt);
acpi_add_table(rsdp, fadt);
debug("ACPI: * MADT\n");
- madt = (struct acpi_madt *)current;
+ madt = ctx->current;
acpi_create_madt(madt);
- current += madt->header.length;
+ acpi_inc_align(ctx, madt->header.length);
acpi_add_table(rsdp, madt);
- current = ALIGN(current, 16);
debug("ACPI: * MCFG\n");
- mcfg = (struct acpi_mcfg *)current;
+ mcfg = ctx->current;
acpi_create_mcfg(mcfg);
- current += mcfg->header.length;
+ acpi_inc_align(ctx, mcfg->header.length);
acpi_add_table(rsdp, mcfg);
- current = ALIGN(current, 16);
debug("ACPI: * CSRT\n");
- csrt = (struct acpi_csrt *)current;
+ csrt = ctx->current;
acpi_create_csrt(csrt);
- current += csrt->header.length;
+ acpi_inc_align(ctx, csrt->header.length);
acpi_add_table(rsdp, csrt);
- current = ALIGN(current, 16);
debug("ACPI: * SPCR\n");
- spcr = (struct acpi_spcr *)current;
+ spcr = ctx->current;
acpi_create_spcr(spcr);
- current += spcr->header.length;
+ acpi_inc_align(ctx, spcr->header.length);
acpi_add_table(rsdp, spcr);
- current = ALIGN(current, 16);
- debug("current = %x\n", current);
+ addr = map_to_sysmem(ctx->current);
+ debug("current = %lx\n", addr);
acpi_rsdp_addr = (unsigned long)rsdp;
debug("ACPI: done\n");
- return current;
+ return addr;
}
ulong acpi_get_rsdp_addr(void)
diff --git a/include/acpi/acpi_table.h b/include/acpi/acpi_table.h
index 268e36b67e1..0710324e698 100644
--- a/include/acpi/acpi_table.h
+++ b/include/acpi/acpi_table.h
@@ -26,6 +26,8 @@
#if !defined(__ACPI__)
+struct acpi_ctx;
+
/*
* RSDP (Root System Description Pointer)
* Note: ACPI 1.0 didn't have length, xsdt_address, and ext_checksum
@@ -519,6 +521,40 @@ int acpi_create_dmar(struct acpi_dmar *dmar, enum dmar_flags flags);
*/
void acpi_fill_header(struct acpi_table_header *header, char *signature);
+/**
+ * acpi_align() - Align the ACPI output pointer to a 16-byte boundary
+ *
+ * @ctx: ACPI context
+ */
+void acpi_align(struct acpi_ctx *ctx);
+
+/**
+ * acpi_align64() - Align the ACPI output pointer to a 64-byte boundary
+ *
+ * @ctx: ACPI context
+ */
+void acpi_align64(struct acpi_ctx *ctx);
+
+/**
+ * acpi_inc() - Increment the ACPI output pointer by a bit
+ *
+ * The pointer is NOT aligned afterwards.
+ *
+ * @ctx: ACPI context
+ * @amount: Amount to increment by
+ */
+void acpi_inc(struct acpi_ctx *ctx, uint amount);
+
+/**
+ * acpi_inc_align() - Increment the ACPI output pointer by a bit and align
+ *
+ * The pointer is aligned afterwards.
+ *
+ * @ctx: ACPI context
+ * @amount: Amount to increment by
+ */
+void acpi_inc_align(struct acpi_ctx *ctx, uint amount);
+
#endif /* !__ACPI__*/
#include <asm/acpi_table.h>
diff --git a/lib/acpi/acpi_table.c b/lib/acpi/acpi_table.c
index 1710cde2c40..35075a608f7 100644
--- a/lib/acpi/acpi_table.c
+++ b/lib/acpi/acpi_table.c
@@ -6,10 +6,11 @@
*/
#include <common.h>
-#include <acpi/acpi_table.h>
#include <dm.h>
#include <cpu.h>
#include <version.h>
+#include <acpi/acpi_table.h>
+#include <dm/acpi.h>
int acpi_create_dmar(struct acpi_dmar *dmar, enum dmar_flags flags)
{
@@ -96,3 +97,24 @@ void acpi_fill_header(struct acpi_table_header *header, char *signature)
header->oem_revision = U_BOOT_BUILD_DATE;
memcpy(header->aslc_id, ASLC_ID, 4);
}
+
+void acpi_align(struct acpi_ctx *ctx)
+{
+ ctx->current = (void *)ALIGN((ulong)ctx->current, 16);
+}
+
+void acpi_align64(struct acpi_ctx *ctx)
+{
+ ctx->current = (void *)ALIGN((ulong)ctx->current, 64);
+}
+
+void acpi_inc(struct acpi_ctx *ctx, uint amount)
+{
+ ctx->current += amount;
+}
+
+void acpi_inc_align(struct acpi_ctx *ctx, uint amount)
+{
+ ctx->current += amount;
+ acpi_align(ctx);
+}
diff --git a/test/dm/acpi.c b/test/dm/acpi.c
index 5743530a3a5..17e208ee80e 100644
--- a/test/dm/acpi.c
+++ b/test/dm/acpi.c
@@ -151,3 +151,31 @@ static int dm_test_acpi_write_tables(struct unit_test_state *uts)
return 0;
}
DM_TEST(dm_test_acpi_write_tables, DM_TESTF_SCAN_PDATA | DM_TESTF_SCAN_FDT);
+
+/* Test basic ACPI functions */
+static int dm_test_acpi_basic(struct unit_test_state *uts)
+{
+ struct acpi_ctx ctx;
+
+ /* Check align works */
+ ctx.current = (void *)5;
+ acpi_align(&ctx);
+ ut_asserteq_ptr((void *)16, ctx.current);
+
+ /* Check that align does nothing if already aligned */
+ acpi_align(&ctx);
+ ut_asserteq_ptr((void *)16, ctx.current);
+ acpi_align64(&ctx);
+ ut_asserteq_ptr((void *)64, ctx.current);
+ acpi_align64(&ctx);
+ ut_asserteq_ptr((void *)64, ctx.current);
+
+ /* Check incrementing */
+ acpi_inc(&ctx, 3);
+ ut_asserteq_ptr((void *)67, ctx.current);
+ acpi_inc_align(&ctx, 3);
+ ut_asserteq_ptr((void *)80, ctx.current);
+
+ return 0;
+}
+DM_TEST(dm_test_acpi_basic, DM_TESTF_SCAN_PDATA | DM_TESTF_SCAN_FDT);
--
2.26.0.rc2.310.g2932bb562d-goog
^ permalink raw reply related [flat|nested] 86+ messages in thread* [PATCH v3 23/29] acpi: Convert part of acpi_table to use acpi_ctx
2020-03-30 23:12 ` [PATCH v3 23/29] acpi: Convert part of acpi_table to use acpi_ctx Simon Glass
@ 2020-04-03 13:24 ` Andy Shevchenko
2020-04-03 13:25 ` Andy Shevchenko
2020-04-08 2:57 ` Simon Glass
0 siblings, 2 replies; 86+ messages in thread
From: Andy Shevchenko @ 2020-04-03 13:24 UTC (permalink / raw)
To: u-boot
On Mon, Mar 30, 2020 at 05:12:59PM -0600, Simon Glass wrote:
> The current code uses an address but a pointer would result in fewer
> casts. Also it repeats the alignment code in a lot of places so this would
> be better done in a helper function.
>
> Update write_acpi_tables() to make use of the new acpi_ctx structure,
> adding a few helpers to clean things up.
...
> +void acpi_align(struct acpi_ctx *ctx);
> +void acpi_align64(struct acpi_ctx *ctx);
In the code, it will be not understandable the difference.
align without number would be good if the function only single one.
So, align16() much better.
> +void acpi_inc(struct acpi_ctx *ctx, uint amount);
inc with amount is not inc, it's rather add.
> + * acpi_inc_align() - Increment the ACPI output pointer by a bit and align
Align how?
> +void acpi_inc_align(struct acpi_ctx *ctx, uint amount);
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply [flat|nested] 86+ messages in thread
* [PATCH v3 23/29] acpi: Convert part of acpi_table to use acpi_ctx
2020-04-03 13:24 ` Andy Shevchenko
@ 2020-04-03 13:25 ` Andy Shevchenko
2020-04-08 2:57 ` Simon Glass
1 sibling, 0 replies; 86+ messages in thread
From: Andy Shevchenko @ 2020-04-03 13:25 UTC (permalink / raw)
To: u-boot
On Fri, Apr 03, 2020 at 04:24:06PM +0300, Andy Shevchenko wrote:
> On Mon, Mar 30, 2020 at 05:12:59PM -0600, Simon Glass wrote:
> > The current code uses an address but a pointer would result in fewer
> > casts. Also it repeats the alignment code in a lot of places so this would
> > be better done in a helper function.
> >
> > Update write_acpi_tables() to make use of the new acpi_ctx structure,
> > adding a few helpers to clean things up.
...
> > +void acpi_inc(struct acpi_ctx *ctx, uint amount);
>
> inc with amount is not inc, it's rather add.
...or pad if you wish.
>
> > + * acpi_inc_align() - Increment the ACPI output pointer by a bit and align
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply [flat|nested] 86+ messages in thread
* [PATCH v3 23/29] acpi: Convert part of acpi_table to use acpi_ctx
2020-04-03 13:24 ` Andy Shevchenko
2020-04-03 13:25 ` Andy Shevchenko
@ 2020-04-08 2:57 ` Simon Glass
1 sibling, 0 replies; 86+ messages in thread
From: Simon Glass @ 2020-04-08 2:57 UTC (permalink / raw)
To: u-boot
Hi Andy,
On Fri, 3 Apr 2020 at 07:24, Andy Shevchenko
<andriy.shevchenko@linux.intel.com> wrote:
>
> On Mon, Mar 30, 2020 at 05:12:59PM -0600, Simon Glass wrote:
> > The current code uses an address but a pointer would result in fewer
> > casts. Also it repeats the alignment code in a lot of places so this would
> > be better done in a helper function.
> >
> > Update write_acpi_tables() to make use of the new acpi_ctx structure,
> > adding a few helpers to clean things up.
>
> ...
>
> > +void acpi_align(struct acpi_ctx *ctx);
>
> > +void acpi_align64(struct acpi_ctx *ctx);
>
> In the code, it will be not understandable the difference.
> align without number would be good if the function only single one.
>
> So, align16() much better.
We had this discussion previously and changed it to what we have now
in v3. I feel it is a matter of preference.
>
> > +void acpi_inc(struct acpi_ctx *ctx, uint amount);
>
> inc with amount is not inc, it's rather add.
Increment by one, or increment by an amount. The word 'add' would be
very confusing here, since we are not adding anything to the ACPI
table.
>
> > + * acpi_inc_align() - Increment the ACPI output pointer by a bit and align
>
> Align how?
Will update the comment
>
REgardsm
Simon
^ permalink raw reply [flat|nested] 86+ messages in thread
* [PATCH v3 24/29] x86: Allow devices to write ACPI tables
2020-03-30 23:12 [PATCH v3 00/29] dm: Add programmatic generation of ACPI tables (part A) Simon Glass
` (22 preceding siblings ...)
2020-03-30 23:12 ` [PATCH v3 23/29] acpi: Convert part of acpi_table to use acpi_ctx Simon Glass
@ 2020-03-30 23:13 ` Simon Glass
2020-03-30 23:13 ` [PATCH v3 25/29] acpi: Drop code for missing XSDT from acpi_write_rsdp() Simon Glass
` (12 subsequent siblings)
36 siblings, 0 replies; 86+ messages in thread
From: Simon Glass @ 2020-03-30 23:13 UTC (permalink / raw)
To: u-boot
Call the new core function to permit devices to write their own ACPI
tables. These tables will appear after all other tables.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Wolfgang Wallner <wolfgang.wallner@br-automation.com>
---
Changes in v3: None
Changes in v2: None
arch/x86/lib/acpi_table.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/x86/lib/acpi_table.c b/arch/x86/lib/acpi_table.c
index afa00bc2f80..e5247c64049 100644
--- a/arch/x86/lib/acpi_table.c
+++ b/arch/x86/lib/acpi_table.c
@@ -580,6 +580,8 @@ ulong write_acpi_tables(ulong start_addr)
acpi_inc_align(ctx, spcr->header.length);
acpi_add_table(rsdp, spcr);
+ acpi_write_dev_tables(ctx);
+
addr = map_to_sysmem(ctx->current);
debug("current = %lx\n", addr);
--
2.26.0.rc2.310.g2932bb562d-goog
^ permalink raw reply related [flat|nested] 86+ messages in thread* [PATCH v3 25/29] acpi: Drop code for missing XSDT from acpi_write_rsdp()
2020-03-30 23:12 [PATCH v3 00/29] dm: Add programmatic generation of ACPI tables (part A) Simon Glass
` (23 preceding siblings ...)
2020-03-30 23:13 ` [PATCH v3 24/29] x86: Allow devices to write ACPI tables Simon Glass
@ 2020-03-30 23:13 ` Simon Glass
2020-03-30 23:13 ` [PATCH v3 26/29] acpi: Move acpi_add_table() to generic code Simon Glass
` (11 subsequent siblings)
36 siblings, 0 replies; 86+ messages in thread
From: Simon Glass @ 2020-03-30 23:13 UTC (permalink / raw)
To: u-boot
We don't actually support tables without an XSDT so we can drop this dead
code.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Wolfgang Wallner <wolfgang.wallner@br-automation.com>
---
Changes in v3: None
Changes in v2: None
arch/x86/lib/acpi_table.c | 15 ++-------------
1 file changed, 2 insertions(+), 13 deletions(-)
diff --git a/arch/x86/lib/acpi_table.c b/arch/x86/lib/acpi_table.c
index e5247c64049..8c169f44938 100644
--- a/arch/x86/lib/acpi_table.c
+++ b/arch/x86/lib/acpi_table.c
@@ -42,19 +42,8 @@ static void acpi_write_rsdp(struct acpi_rsdp *rsdp, struct acpi_rsdt *rsdt,
rsdp->length = sizeof(struct acpi_rsdp);
rsdp->rsdt_address = (u32)rsdt;
- /*
- * Revision: ACPI 1.0: 0, ACPI 2.0/3.0/4.0: 2
- *
- * Some OSes expect an XSDT to be present for RSD PTR revisions >= 2.
- * If we don't have an ACPI XSDT, force ACPI 1.0 (and thus RSD PTR
- * revision 0)
- */
- if (xsdt == NULL) {
- rsdp->revision = ACPI_RSDP_REV_ACPI_1_0;
- } else {
- rsdp->xsdt_address = (u64)(u32)xsdt;
- rsdp->revision = ACPI_RSDP_REV_ACPI_2_0;
- }
+ rsdp->xsdt_address = (u64)(u32)xsdt;
+ rsdp->revision = ACPI_RSDP_REV_ACPI_2_0;
/* Calculate checksums */
rsdp->checksum = table_compute_checksum((void *)rsdp, 20);
--
2.26.0.rc2.310.g2932bb562d-goog
^ permalink raw reply related [flat|nested] 86+ messages in thread* [PATCH v3 26/29] acpi: Move acpi_add_table() to generic code
2020-03-30 23:12 [PATCH v3 00/29] dm: Add programmatic generation of ACPI tables (part A) Simon Glass
` (24 preceding siblings ...)
2020-03-30 23:13 ` [PATCH v3 25/29] acpi: Drop code for missing XSDT from acpi_write_rsdp() Simon Glass
@ 2020-03-30 23:13 ` Simon Glass
2020-03-30 23:13 ` [PATCH v3 27/29] acpi: Put table-setup code in its own function Simon Glass
` (10 subsequent siblings)
36 siblings, 0 replies; 86+ messages in thread
From: Simon Glass @ 2020-03-30 23:13 UTC (permalink / raw)
To: u-boot
Move this code to a generic location so that we can test it with sandbox.
This requires adding a few new fields to acpi_ctx, so drop the local
variables used in the original code.
Also use mapmem to avoid pointer-to-address casts which don't work on
sandbox.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Wolfgang Wallner <wolfgang.wallner@br-automation.com>
---
Changes in v3:
- Fix 'RSDP' typo
Changes in v2: None
arch/x86/lib/acpi_table.c | 82 +++++----------------------------------
include/acpi/acpi_table.h | 9 +++++
include/dm/acpi.h | 5 +++
lib/acpi/acpi_table.c | 61 +++++++++++++++++++++++++++++
test/dm/acpi.c | 4 ++
5 files changed, 89 insertions(+), 72 deletions(-)
diff --git a/arch/x86/lib/acpi_table.c b/arch/x86/lib/acpi_table.c
index 8c169f44938..d4af56eabf4 100644
--- a/arch/x86/lib/acpi_table.c
+++ b/arch/x86/lib/acpi_table.c
@@ -83,66 +83,6 @@ static void acpi_write_xsdt(struct acpi_xsdt *xsdt)
sizeof(struct acpi_xsdt));
}
-/**
- * Add an ACPI table to the RSDT (and XSDT) structure, recalculate length
- * and checksum.
- */
-static void acpi_add_table(struct acpi_rsdp *rsdp, void *table)
-{
- int i, entries_num;
- struct acpi_rsdt *rsdt;
- struct acpi_xsdt *xsdt = NULL;
-
- /* The RSDT is mandatory while the XSDT is not */
- rsdt = (struct acpi_rsdt *)rsdp->rsdt_address;
-
- if (rsdp->xsdt_address)
- xsdt = (struct acpi_xsdt *)((u32)rsdp->xsdt_address);
-
- /* This should always be MAX_ACPI_TABLES */
- entries_num = ARRAY_SIZE(rsdt->entry);
-
- for (i = 0; i < entries_num; i++) {
- if (rsdt->entry[i] == 0)
- break;
- }
-
- if (i >= entries_num) {
- debug("ACPI: Error: too many tables\n");
- return;
- }
-
- /* Add table to the RSDT */
- rsdt->entry[i] = (u32)table;
-
- /* Fix RSDT length or the kernel will assume invalid entries */
- rsdt->header.length = sizeof(struct acpi_table_header) +
- (sizeof(u32) * (i + 1));
-
- /* Re-calculate checksum */
- rsdt->header.checksum = 0;
- rsdt->header.checksum = table_compute_checksum((u8 *)rsdt,
- rsdt->header.length);
-
- /*
- * And now the same thing for the XSDT. We use the same index as for
- * now we want the XSDT and RSDT to always be in sync in U-Boot
- */
- if (xsdt) {
- /* Add table to the XSDT */
- xsdt->entry[i] = (u64)(u32)table;
-
- /* Fix XSDT length */
- xsdt->header.length = sizeof(struct acpi_table_header) +
- (sizeof(u64) * (i + 1));
-
- /* Re-calculate checksum */
- xsdt->header.checksum = 0;
- xsdt->header.checksum = table_compute_checksum((u8 *)xsdt,
- xsdt->header.length);
- }
-}
-
static void acpi_create_facs(struct acpi_facs *facs)
{
memset((void *)facs, 0, sizeof(struct acpi_facs));
@@ -462,8 +402,6 @@ static void acpi_create_spcr(struct acpi_spcr *spcr)
ulong write_acpi_tables(ulong start_addr)
{
struct acpi_ctx sctx, *ctx = &sctx;
- struct acpi_rsdp *rsdp;
- struct acpi_rsdt *rsdt;
struct acpi_xsdt *xsdt;
struct acpi_facs *facs;
struct acpi_table_header *dsdt;
@@ -485,9 +423,9 @@ ulong write_acpi_tables(ulong start_addr)
debug("ACPI: Writing ACPI tables at %lx\n", start_addr);
/* We need at least an RSDP and an RSDT Table */
- rsdp = ctx->current;
+ ctx->rsdp = ctx->current;
acpi_inc_align(ctx, sizeof(struct acpi_rsdp));
- rsdt = ctx->current;
+ ctx->rsdt = ctx->current;
acpi_inc_align(ctx, sizeof(struct acpi_rsdt));
xsdt = ctx->current;
acpi_inc_align(ctx, sizeof(struct acpi_xsdt));
@@ -500,8 +438,8 @@ ulong write_acpi_tables(ulong start_addr)
/* clear all table memory */
memset((void *)start, 0, ctx->current - start);
- acpi_write_rsdp(rsdp, rsdt, xsdt);
- acpi_write_rsdt(rsdt);
+ acpi_write_rsdp(ctx->rsdp, ctx->rsdt, xsdt);
+ acpi_write_rsdt(ctx->rsdt);
acpi_write_xsdt(xsdt);
debug("ACPI: * FACS\n");
@@ -543,38 +481,38 @@ ulong write_acpi_tables(ulong start_addr)
fadt = ctx->current;
acpi_inc_align(ctx, sizeof(struct acpi_fadt));
acpi_create_fadt(fadt, facs, dsdt);
- acpi_add_table(rsdp, fadt);
+ acpi_add_table(ctx, fadt);
debug("ACPI: * MADT\n");
madt = ctx->current;
acpi_create_madt(madt);
acpi_inc_align(ctx, madt->header.length);
- acpi_add_table(rsdp, madt);
+ acpi_add_table(ctx, madt);
debug("ACPI: * MCFG\n");
mcfg = ctx->current;
acpi_create_mcfg(mcfg);
acpi_inc_align(ctx, mcfg->header.length);
- acpi_add_table(rsdp, mcfg);
+ acpi_add_table(ctx, mcfg);
debug("ACPI: * CSRT\n");
csrt = ctx->current;
acpi_create_csrt(csrt);
acpi_inc_align(ctx, csrt->header.length);
- acpi_add_table(rsdp, csrt);
+ acpi_add_table(ctx, csrt);
debug("ACPI: * SPCR\n");
spcr = ctx->current;
acpi_create_spcr(spcr);
acpi_inc_align(ctx, spcr->header.length);
- acpi_add_table(rsdp, spcr);
+ acpi_add_table(ctx, spcr);
acpi_write_dev_tables(ctx);
addr = map_to_sysmem(ctx->current);
debug("current = %lx\n", addr);
- acpi_rsdp_addr = (unsigned long)rsdp;
+ acpi_rsdp_addr = (unsigned long)ctx->rsdp;
debug("ACPI: done\n");
return addr;
diff --git a/include/acpi/acpi_table.h b/include/acpi/acpi_table.h
index 0710324e698..b86800fdfa4 100644
--- a/include/acpi/acpi_table.h
+++ b/include/acpi/acpi_table.h
@@ -555,6 +555,15 @@ void acpi_inc(struct acpi_ctx *ctx, uint amount);
*/
void acpi_inc_align(struct acpi_ctx *ctx, uint amount);
+/**
+ * acpi_add_table() - Add a new table to the RSDP and XSDT
+ *
+ * @ctx: ACPI context
+ * @table: Table to add
+ * @return 0 if OK, -E2BIG if too many tables
+ */
+int acpi_add_table(struct acpi_ctx *ctx, void *table);
+
#endif /* !__ACPI__*/
#include <asm/acpi_table.h>
diff --git a/include/dm/acpi.h b/include/dm/acpi.h
index 9a0a437dd03..ee6f7a63e79 100644
--- a/include/dm/acpi.h
+++ b/include/dm/acpi.h
@@ -30,9 +30,14 @@
* This contains a few useful pieces of information used when writing
*
* @current: Current address for writing
+ * @rsdp: Pointer to the Root System Description Pointer, typically used when
+ * adding a new table. The RSDP holds pointers to the RSDT and XSDT.
+ * @rsdt: Pointer to the Root System Description Table
*/
struct acpi_ctx {
void *current;
+ struct acpi_rsdp *rsdp;
+ struct acpi_rsdt *rsdt;
};
/**
diff --git a/lib/acpi/acpi_table.c b/lib/acpi/acpi_table.c
index 35075a608f7..b2086cbbf7a 100644
--- a/lib/acpi/acpi_table.c
+++ b/lib/acpi/acpi_table.c
@@ -8,6 +8,8 @@
#include <common.h>
#include <dm.h>
#include <cpu.h>
+#include <mapmem.h>
+#include <tables_csum.h>
#include <version.h>
#include <acpi/acpi_table.h>
#include <dm/acpi.h>
@@ -118,3 +120,62 @@ void acpi_inc_align(struct acpi_ctx *ctx, uint amount)
ctx->current += amount;
acpi_align(ctx);
}
+
+/**
+ * Add an ACPI table to the RSDT (and XSDT) structure, recalculate length
+ * and checksum.
+ */
+int acpi_add_table(struct acpi_ctx *ctx, void *table)
+{
+ int i, entries_num;
+ struct acpi_rsdt *rsdt;
+ struct acpi_xsdt *xsdt;
+
+ /* The RSDT is mandatory while the XSDT is not */
+ rsdt = ctx->rsdt;
+
+ /* This should always be MAX_ACPI_TABLES */
+ entries_num = ARRAY_SIZE(rsdt->entry);
+
+ for (i = 0; i < entries_num; i++) {
+ if (rsdt->entry[i] == 0)
+ break;
+ }
+
+ if (i >= entries_num) {
+ debug("ACPI: Error: too many tables\n");
+ return -E2BIG;
+ }
+
+ /* Add table to the RSDT */
+ rsdt->entry[i] = map_to_sysmem(table);
+
+ /* Fix RSDT length or the kernel will assume invalid entries */
+ rsdt->header.length = sizeof(struct acpi_table_header) +
+ (sizeof(u32) * (i + 1));
+
+ /* Re-calculate checksum */
+ rsdt->header.checksum = 0;
+ rsdt->header.checksum = table_compute_checksum((u8 *)rsdt,
+ rsdt->header.length);
+
+ /*
+ * And now the same thing for the XSDT. We use the same index as for
+ * now we want the XSDT and RSDT to always be in sync in U-Boot
+ */
+ xsdt = (struct acpi_xsdt *)((u32)rsdp->xsdt_address);
+
+ /* Add table to the XSDT */
+ xsdt->entry[i] = map_to_sysmem(table);
+
+ /* Fix XSDT length */
+ xsdt->header.length = sizeof(struct acpi_table_header) +
+ (sizeof(u64) * (i + 1));
+
+ /* Re-calculate checksum */
+ xsdt->header.checksum = 0;
+ xsdt->header.checksum = table_compute_checksum((u8 *)xsdt,
+ xsdt->header.length);
+
+ return 0;
+}
diff --git a/test/dm/acpi.c b/test/dm/acpi.c
index 17e208ee80e..4dd4a540967 100644
--- a/test/dm/acpi.c
+++ b/test/dm/acpi.c
@@ -21,10 +21,14 @@ static int testacpi_write_tables(const struct udevice *dev,
struct acpi_ctx *ctx)
{
struct acpi_dmar *dmar;
+ int ret;
dmar = (struct acpi_dmar *)ctx->current;
acpi_create_dmar(dmar, DMAR_INTR_REMAP);
ctx->current += sizeof(struct acpi_dmar);
+ ret = acpi_add_table(ctx, dmar);
+ if (ret)
+ return log_msg_ret("add", ret);
return 0;
}
--
2.26.0.rc2.310.g2932bb562d-goog
^ permalink raw reply related [flat|nested] 86+ messages in thread* [PATCH v3 27/29] acpi: Put table-setup code in its own function
2020-03-30 23:12 [PATCH v3 00/29] dm: Add programmatic generation of ACPI tables (part A) Simon Glass
` (25 preceding siblings ...)
2020-03-30 23:13 ` [PATCH v3 26/29] acpi: Move acpi_add_table() to generic code Simon Glass
@ 2020-03-30 23:13 ` Simon Glass
2020-04-03 13:32 ` Andy Shevchenko
2020-03-30 23:13 ` [PATCH v3 28/29] acpi: Move the xsdt pointer to acpi_ctx Simon Glass
` (9 subsequent siblings)
36 siblings, 1 reply; 86+ messages in thread
From: Simon Glass @ 2020-03-30 23:13 UTC (permalink / raw)
To: u-boot
We always write three basic tables to ACPI at the start. Move this into
its own function, along with acpi_fill_header(), so we can write a test
for this code.
Signed-off-by: Simon Glass <sjg@chromium.org>
---
Changes in v3:
- Beef up the comment explaining how the unaligned address is used
- Fix 'XDST' typo
- Move acpi_align_large() out of dm_test_acpi_setup_base_tables()
Changes in v2: None
arch/x86/lib/acpi_table.c | 72 +----------------------------------
include/acpi/acpi_table.h | 10 +++++
lib/acpi/acpi_table.c | 79 ++++++++++++++++++++++++++++++++++++++-
test/dm/acpi.c | 58 +++++++++++++++++++++++++++-
4 files changed, 145 insertions(+), 74 deletions(-)
diff --git a/arch/x86/lib/acpi_table.c b/arch/x86/lib/acpi_table.c
index d4af56eabf4..4a7b0739394 100644
--- a/arch/x86/lib/acpi_table.c
+++ b/arch/x86/lib/acpi_table.c
@@ -31,58 +31,6 @@ extern const unsigned char AmlCode[];
/* ACPI RSDP address to be used in boot parameters */
static ulong acpi_rsdp_addr;
-static void acpi_write_rsdp(struct acpi_rsdp *rsdp, struct acpi_rsdt *rsdt,
- struct acpi_xsdt *xsdt)
-{
- memset(rsdp, 0, sizeof(struct acpi_rsdp));
-
- memcpy(rsdp->signature, RSDP_SIG, 8);
- memcpy(rsdp->oem_id, OEM_ID, 6);
-
- rsdp->length = sizeof(struct acpi_rsdp);
- rsdp->rsdt_address = (u32)rsdt;
-
- rsdp->xsdt_address = (u64)(u32)xsdt;
- rsdp->revision = ACPI_RSDP_REV_ACPI_2_0;
-
- /* Calculate checksums */
- rsdp->checksum = table_compute_checksum((void *)rsdp, 20);
- rsdp->ext_checksum = table_compute_checksum((void *)rsdp,
- sizeof(struct acpi_rsdp));
-}
-
-static void acpi_write_rsdt(struct acpi_rsdt *rsdt)
-{
- struct acpi_table_header *header = &(rsdt->header);
-
- /* Fill out header fields */
- acpi_fill_header(header, "RSDT");
- header->length = sizeof(struct acpi_rsdt);
- header->revision = 1;
-
- /* Entries are filled in later, we come with an empty set */
-
- /* Fix checksum */
- header->checksum = table_compute_checksum((void *)rsdt,
- sizeof(struct acpi_rsdt));
-}
-
-static void acpi_write_xsdt(struct acpi_xsdt *xsdt)
-{
- struct acpi_table_header *header = &(xsdt->header);
-
- /* Fill out header fields */
- acpi_fill_header(header, "XSDT");
- header->length = sizeof(struct acpi_xsdt);
- header->revision = 1;
-
- /* Entries are filled in later, we come with an empty set */
-
- /* Fix checksum */
- header->checksum = table_compute_checksum((void *)xsdt,
- sizeof(struct acpi_xsdt));
-}
-
static void acpi_create_facs(struct acpi_facs *facs)
{
memset((void *)facs, 0, sizeof(struct acpi_facs));
@@ -402,7 +350,6 @@ static void acpi_create_spcr(struct acpi_spcr *spcr)
ulong write_acpi_tables(ulong start_addr)
{
struct acpi_ctx sctx, *ctx = &sctx;
- struct acpi_xsdt *xsdt;
struct acpi_facs *facs;
struct acpi_table_header *dsdt;
struct acpi_fadt *fadt;
@@ -415,33 +362,16 @@ ulong write_acpi_tables(ulong start_addr)
int i;
start = map_sysmem(start_addr, 0);
- ctx->current = start;
-
- /* Align ACPI tables to 16 byte */
- acpi_align(ctx);
debug("ACPI: Writing ACPI tables at %lx\n", start_addr);
- /* We need at least an RSDP and an RSDT Table */
- ctx->rsdp = ctx->current;
- acpi_inc_align(ctx, sizeof(struct acpi_rsdp));
- ctx->rsdt = ctx->current;
- acpi_inc_align(ctx, sizeof(struct acpi_rsdt));
- xsdt = ctx->current;
- acpi_inc_align(ctx, sizeof(struct acpi_xsdt));
+ acpi_setup_base_tables(ctx, start);
/*
* Per ACPI spec, the FACS table address must be aligned to a 64 byte
* boundary (Windows checks this, but Linux does not).
*/
acpi_align64(ctx);
- /* clear all table memory */
- memset((void *)start, 0, ctx->current - start);
-
- acpi_write_rsdp(ctx->rsdp, ctx->rsdt, xsdt);
- acpi_write_rsdt(ctx->rsdt);
- acpi_write_xsdt(xsdt);
-
debug("ACPI: * FACS\n");
facs = ctx->current;
acpi_inc_align(ctx, sizeof(struct acpi_facs));
diff --git a/include/acpi/acpi_table.h b/include/acpi/acpi_table.h
index b86800fdfa4..05b0948b6f6 100644
--- a/include/acpi/acpi_table.h
+++ b/include/acpi/acpi_table.h
@@ -564,6 +564,16 @@ void acpi_inc_align(struct acpi_ctx *ctx, uint amount);
*/
int acpi_add_table(struct acpi_ctx *ctx, void *table);
+/**
+ * acpi_setup_base_tables() - Set up context along with RSDP, RSDT and XSDT
+ *
+ * Set up the context with the given start position. Some basic tables are
+ * always needed, so set them up as well.
+ *
+ * @ctx: Context to set up
+ */
+void acpi_setup_base_tables(struct acpi_ctx *ctx, void *start);
+
#endif /* !__ACPI__*/
#include <asm/acpi_table.h>
diff --git a/lib/acpi/acpi_table.c b/lib/acpi/acpi_table.c
index b2086cbbf7a..70d29c53881 100644
--- a/lib/acpi/acpi_table.c
+++ b/lib/acpi/acpi_table.c
@@ -156,7 +156,7 @@ int acpi_add_table(struct acpi_ctx *ctx, void *table)
/* Re-calculate checksum */
rsdt->header.checksum = 0;
- rsdt->header.checksum = table_compute_checksum((u8 *)rsdt,
+ rsdt->header.checksum = table_compute_checksum(rsdt,
rsdt->header.length);
/*
@@ -179,3 +179,80 @@ int acpi_add_table(struct acpi_ctx *ctx, void *table)
return 0;
}
+
+static void acpi_write_rsdp(struct acpi_rsdp *rsdp, struct acpi_rsdt *rsdt,
+ struct acpi_xsdt *xsdt)
+{
+ memset(rsdp, 0, sizeof(struct acpi_rsdp));
+
+ memcpy(rsdp->signature, RSDP_SIG, 8);
+ memcpy(rsdp->oem_id, OEM_ID, 6);
+
+ rsdp->length = sizeof(struct acpi_rsdp);
+ rsdp->rsdt_address = map_to_sysmem(rsdt);
+
+ rsdp->xsdt_address = map_to_sysmem(xsdt);
+ rsdp->revision = ACPI_RSDP_REV_ACPI_2_0;
+
+ /* Calculate checksums */
+ rsdp->checksum = table_compute_checksum(rsdp, 20);
+ rsdp->ext_checksum = table_compute_checksum(rsdp,
+ sizeof(struct acpi_rsdp));
+}
+
+static void acpi_write_rsdt(struct acpi_rsdt *rsdt)
+{
+ struct acpi_table_header *header = &rsdt->header;
+
+ /* Fill out header fields */
+ acpi_fill_header(header, "RSDT");
+ header->length = sizeof(struct acpi_rsdt);
+ header->revision = 1;
+
+ /* Entries are filled in later, we come with an empty set */
+
+ /* Fix checksum */
+ header->checksum = table_compute_checksum(rsdt,
+ sizeof(struct acpi_rsdt));
+}
+
+static void acpi_write_xsdt(struct acpi_xsdt *xsdt)
+{
+ struct acpi_table_header *header = &xsdt->header;
+
+ /* Fill out header fields */
+ acpi_fill_header(header, "XSDT");
+ header->length = sizeof(struct acpi_xsdt);
+ header->revision = 1;
+
+ /* Entries are filled in later, we come with an empty set */
+
+ /* Fix checksum */
+ header->checksum = table_compute_checksum(xsdt,
+ sizeof(struct acpi_xsdt));
+}
+
+void acpi_setup_base_tables(struct acpi_ctx *ctx, void *start)
+{
+ struct acpi_xsdt *xsdt;
+
+ ctx->current = start;
+
+ /* Align ACPI tables to 16 byte */
+ acpi_align(ctx);
+
+ /* We need at least an RSDP and an RSDT Table */
+ ctx->rsdp = ctx->current;
+ acpi_inc_align(ctx, sizeof(struct acpi_rsdp));
+ ctx->rsdt = ctx->current;
+ acpi_inc_align(ctx, sizeof(struct acpi_rsdt));
+ xsdt = ctx->current;
+ acpi_inc_align(ctx, sizeof(struct acpi_xsdt));
+
+ /* clear all table memory */
+ memset((void *)start, '\0', ctx->current - start);
+
+ acpi_write_rsdp(ctx->rsdp, ctx->rsdt, xsdt);
+ acpi_write_rsdt(ctx->rsdt);
+ acpi_write_xsdt(xsdt);
+}
diff --git a/test/dm/acpi.c b/test/dm/acpi.c
index 4dd4a540967..5d5e46e2944 100644
--- a/test/dm/acpi.c
+++ b/test/dm/acpi.c
@@ -8,6 +8,9 @@
#include <common.h>
#include <dm.h>
+#include <malloc.h>
+#include <mapmem.h>
+#include <tables_csum.h>
#include <version.h>
#include <acpi/acpi_table.h>
#include <dm/acpi.h>
@@ -137,9 +140,9 @@ static int dm_test_acpi_write_tables(struct unit_test_state *uts)
buf = malloc(BUF_SIZE);
ut_assertnonnull(buf);
- ctx.current = buf;
+ acpi_setup_base_tables(&ctx, buf);
+ dmar = ctx.current;
ut_assertok(acpi_write_dev_tables(&ctx));
- dmar = buf;
/*
* We should have two dmar tables, one for each "denx,u-boot-acpi-test"
@@ -152,6 +155,11 @@ static int dm_test_acpi_write_tables(struct unit_test_state *uts)
ut_asserteq(DMAR_INTR_REMAP, dmar[1].flags);
ut_asserteq(32 - 1, dmar[1].host_address_width);
+ /* Check that the pointers were added correctly */
+ ut_asserteq(map_to_sysmem(dmar), ctx.rsdt->entry[0]);
+ ut_asserteq(map_to_sysmem(dmar + 1), ctx.rsdt->entry[1]);
+ ut_asserteq(0, ctx.rsdt->entry[2]);
+
return 0;
}
DM_TEST(dm_test_acpi_write_tables, DM_TESTF_SCAN_PDATA | DM_TESTF_SCAN_FDT);
@@ -183,3 +191,49 @@ static int dm_test_acpi_basic(struct unit_test_state *uts)
return 0;
}
DM_TEST(dm_test_acpi_basic, DM_TESTF_SCAN_PDATA | DM_TESTF_SCAN_FDT);
+
+/* Test acpi_setup_base_tables */
+static int dm_test_acpi_setup_base_tables(struct unit_test_state *uts)
+{
+ struct acpi_rsdp *rsdp;
+ struct acpi_rsdt *rsdt;
+ struct acpi_xsdt *xsdt;
+ struct acpi_ctx ctx;
+ void *buf, *end;
+
+ /*
+ * Use an unaligned address deliberately, by allocating an aligned
+ * address and then adding 4 to it
+ */
+ buf = memalign(64, BUF_SIZE);
+ ut_assertnonnull(buf);
+ acpi_setup_base_tables(&ctx, buf + 4);
+
+ rsdp = buf + 16;
+ ut_asserteq_ptr(rsdp, ctx.rsdp);
+ ut_assertok(memcmp(RSDP_SIG, rsdp->signature, sizeof(rsdp->signature)));
+ ut_asserteq(sizeof(*rsdp), rsdp->length);
+ ut_assertok(table_compute_checksum(rsdp, 20));
+ ut_assertok(table_compute_checksum(rsdp, sizeof(*rsdp)));
+
+ rsdt = PTR_ALIGN((void *)rsdp + sizeof(*rsdp), 16);
+ ut_asserteq_ptr(rsdt, ctx.rsdt);
+ ut_assertok(memcmp("RSDT", rsdt->header.signature, ACPI_NAME_LEN));
+ ut_asserteq(sizeof(*rsdt), rsdt->header.length);
+ ut_assertok(table_compute_checksum(rsdt, sizeof(*rsdt)));
+
+ xsdt = PTR_ALIGN((void *)rsdt + sizeof(*rsdt), 16);
+ ut_assertok(memcmp("XSDT", xsdt->header.signature, ACPI_NAME_LEN));
+ ut_asserteq(sizeof(*xsdt), xsdt->header.length);
+ ut_assertok(table_compute_checksum(xsdt, sizeof(*xsdt)));
+
+ end = PTR_ALIGN((void *)xsdt + sizeof(*xsdt), 64);
+ ut_asserteq_ptr(end, ctx.current);
+
+ ut_asserteq(map_to_sysmem(rsdt), rsdp->rsdt_address);
+ ut_asserteq(map_to_sysmem(xsdt), rsdp->xsdt_address);
+
+ return 0;
+}
+DM_TEST(dm_test_acpi_setup_base_tables,
+ DM_TESTF_SCAN_PDATA | DM_TESTF_SCAN_FDT);
--
2.26.0.rc2.310.g2932bb562d-goog
^ permalink raw reply related [flat|nested] 86+ messages in thread* [PATCH v3 27/29] acpi: Put table-setup code in its own function
2020-03-30 23:13 ` [PATCH v3 27/29] acpi: Put table-setup code in its own function Simon Glass
@ 2020-04-03 13:32 ` Andy Shevchenko
2020-04-08 2:57 ` Simon Glass
0 siblings, 1 reply; 86+ messages in thread
From: Andy Shevchenko @ 2020-04-03 13:32 UTC (permalink / raw)
To: u-boot
On Mon, Mar 30, 2020 at 05:13:03PM -0600, Simon Glass wrote:
> We always write three basic tables to ACPI at the start. Move this into
> its own function, along with acpi_fill_header(), so we can write a test
> for this code.
...
> /* Re-calculate checksum */
> rsdt->header.checksum = 0;
> - rsdt->header.checksum = table_compute_checksum((u8 *)rsdt,
> + rsdt->header.checksum = table_compute_checksum(rsdt,
> rsdt->header.length);
Why suddenly casting is not needed in this patch?
Same question to the rest.
(If it's a valid change, it should be in a separate patch)
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply [flat|nested] 86+ messages in thread
* [PATCH v3 27/29] acpi: Put table-setup code in its own function
2020-04-03 13:32 ` Andy Shevchenko
@ 2020-04-08 2:57 ` Simon Glass
2020-04-08 17:11 ` Andy Shevchenko
0 siblings, 1 reply; 86+ messages in thread
From: Simon Glass @ 2020-04-08 2:57 UTC (permalink / raw)
To: u-boot
Hi Andy,
On Fri, 3 Apr 2020 at 07:32, Andy Shevchenko
<andriy.shevchenko@linux.intel.com> wrote:
>
> On Mon, Mar 30, 2020 at 05:13:03PM -0600, Simon Glass wrote:
> > We always write three basic tables to ACPI at the start. Move this into
> > its own function, along with acpi_fill_header(), so we can write a test
> > for this code.
>
> ...
>
> > /* Re-calculate checksum */
> > rsdt->header.checksum = 0;
> > - rsdt->header.checksum = table_compute_checksum((u8 *)rsdt,
> > + rsdt->header.checksum = table_compute_checksum(rsdt,
> > rsdt->header.length);
Please can you keep the filenames / functions in your response?
Fragments make it harder to find the code.
>
> Why suddenly casting is not needed in this patch?
> Same question to the rest.
>
> (If it's a valid change, it should be in a separate patch)
It was never needed. See the prototype for table_compute_checksum().
But I can put it back in.
Regards,
Simon
^ permalink raw reply [flat|nested] 86+ messages in thread
* [PATCH v3 27/29] acpi: Put table-setup code in its own function
2020-04-08 2:57 ` Simon Glass
@ 2020-04-08 17:11 ` Andy Shevchenko
2020-04-08 19:35 ` Simon Glass
0 siblings, 1 reply; 86+ messages in thread
From: Andy Shevchenko @ 2020-04-08 17:11 UTC (permalink / raw)
To: u-boot
On Tue, Apr 07, 2020 at 08:57:52PM -0600, Simon Glass wrote:
> On Fri, 3 Apr 2020 at 07:32, Andy Shevchenko
> <andriy.shevchenko@linux.intel.com> wrote:
> >
> > On Mon, Mar 30, 2020 at 05:13:03PM -0600, Simon Glass wrote:
> > > We always write three basic tables to ACPI at the start. Move this into
> > > its own function, along with acpi_fill_header(), so we can write a test
> > > for this code.
> >
> > ...
> >
> > > /* Re-calculate checksum */
> > > rsdt->header.checksum = 0;
> > > - rsdt->header.checksum = table_compute_checksum((u8 *)rsdt,
> > > + rsdt->header.checksum = table_compute_checksum(rsdt,
> > > rsdt->header.length);
>
> Please can you keep the filenames / functions in your response?
> Fragments make it harder to find the code.
I thought, obviously mistakenly, that git users know about git grep ...
> > Why suddenly casting is not needed in this patch?
> > Same question to the rest.
> >
> > (If it's a valid change, it should be in a separate patch)
>
> It was never needed. See the prototype for table_compute_checksum().
>
> But I can put it back in.
Depends on your preferences, but it's definitely not a material for this
change. Separate one?
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply [flat|nested] 86+ messages in thread
* [PATCH v3 27/29] acpi: Put table-setup code in its own function
2020-04-08 17:11 ` Andy Shevchenko
@ 2020-04-08 19:35 ` Simon Glass
0 siblings, 0 replies; 86+ messages in thread
From: Simon Glass @ 2020-04-08 19:35 UTC (permalink / raw)
To: u-boot
Hi Andy,
On Wed, 8 Apr 2020 at 11:11, Andy Shevchenko
<andriy.shevchenko@linux.intel.com> wrote:
>
> On Tue, Apr 07, 2020 at 08:57:52PM -0600, Simon Glass wrote:
> > On Fri, 3 Apr 2020 at 07:32, Andy Shevchenko
> > <andriy.shevchenko@linux.intel.com> wrote:
> > >
> > > On Mon, Mar 30, 2020 at 05:13:03PM -0600, Simon Glass wrote:
> > > > We always write three basic tables to ACPI at the start. Move this into
> > > > its own function, along with acpi_fill_header(), so we can write a test
> > > > for this code.
> > >
> > > ...
> > >
> > > > /* Re-calculate checksum */
> > > > rsdt->header.checksum = 0;
> > > > - rsdt->header.checksum = table_compute_checksum((u8 *)rsdt,
> > > > + rsdt->header.checksum = table_compute_checksum(rsdt,
> > > > rsdt->header.length);
> >
> > Please can you keep the filenames / functions in your response?
> > Fragments make it harder to find the code.
>
> I thought, obviously mistakenly, that git users know about git grep ...
Well I'd appreciate it if you could keep them in. It is customary, and
it avoids grepping as you say.
>
> > > Why suddenly casting is not needed in this patch?
> > > Same question to the rest.
> > >
> > > (If it's a valid change, it should be in a separate patch)
> >
> > It was never needed. See the prototype for table_compute_checksum().
> >
> > But I can put it back in.
>
> Depends on your preferences, but it's definitely not a material for this
> change. Separate one?
It isn't worth worrying about as a later commit drops it. Let's just
leave it as you had it, with the cast.
Regards,
Simon
^ permalink raw reply [flat|nested] 86+ messages in thread
* [PATCH v3 28/29] acpi: Move the xsdt pointer to acpi_ctx
2020-03-30 23:12 [PATCH v3 00/29] dm: Add programmatic generation of ACPI tables (part A) Simon Glass
` (26 preceding siblings ...)
2020-03-30 23:13 ` [PATCH v3 27/29] acpi: Put table-setup code in its own function Simon Glass
@ 2020-03-30 23:13 ` Simon Glass
2020-03-30 23:13 ` [PATCH v3 29/29] acpi: Add an acpi command Simon Glass
` (8 subsequent siblings)
36 siblings, 0 replies; 86+ messages in thread
From: Simon Glass @ 2020-03-30 23:13 UTC (permalink / raw)
To: u-boot
Put this in the context along with the other important pointers.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Wolfgang Wallner <wolfgang.wallner@br-automation.com>
---
Changes in v3: None
Changes in v2: None
include/dm/acpi.h | 2 ++
lib/acpi/acpi_table.c | 10 ++++------
test/dm/acpi.c | 5 +++++
3 files changed, 11 insertions(+), 6 deletions(-)
diff --git a/include/dm/acpi.h b/include/dm/acpi.h
index ee6f7a63e79..288310b5128 100644
--- a/include/dm/acpi.h
+++ b/include/dm/acpi.h
@@ -33,11 +33,13 @@
* @rsdp: Pointer to the Root System Description Pointer, typically used when
* adding a new table. The RSDP holds pointers to the RSDT and XSDT.
* @rsdt: Pointer to the Root System Description Table
+ * @xsdt: Pointer to the Extended System Description Table
*/
struct acpi_ctx {
void *current;
struct acpi_rsdp *rsdp;
struct acpi_rsdt *rsdt;
+ struct acpi_xsdt *xsdt;
};
/**
diff --git a/lib/acpi/acpi_table.c b/lib/acpi/acpi_table.c
index 70d29c53881..28003dc8f46 100644
--- a/lib/acpi/acpi_table.c
+++ b/lib/acpi/acpi_table.c
@@ -163,7 +163,7 @@ int acpi_add_table(struct acpi_ctx *ctx, void *table)
* And now the same thing for the XSDT. We use the same index as for
* now we want the XSDT and RSDT to always be in sync in U-Boot
*/
- xsdt = (struct acpi_xsdt *)((u32)rsdp->xsdt_address);
+ xsdt = ctx->xsdt;
/* Add table to the XSDT */
xsdt->entry[i] = map_to_sysmem(table);
@@ -234,8 +234,6 @@ static void acpi_write_xsdt(struct acpi_xsdt *xsdt)
void acpi_setup_base_tables(struct acpi_ctx *ctx, void *start)
{
- struct acpi_xsdt *xsdt;
-
ctx->current = start;
/* Align ACPI tables to 16 byte */
@@ -246,13 +244,13 @@ void acpi_setup_base_tables(struct acpi_ctx *ctx, void *start)
acpi_inc_align(ctx, sizeof(struct acpi_rsdp));
ctx->rsdt = ctx->current;
acpi_inc_align(ctx, sizeof(struct acpi_rsdt));
- xsdt = ctx->current;
+ ctx->xsdt = ctx->current;
acpi_inc_align(ctx, sizeof(struct acpi_xsdt));
/* clear all table memory */
memset((void *)start, '\0', ctx->current - start);
- acpi_write_rsdp(ctx->rsdp, ctx->rsdt, xsdt);
+ acpi_write_rsdp(ctx->rsdp, ctx->rsdt, ctx->xsdt);
acpi_write_rsdt(ctx->rsdt);
- acpi_write_xsdt(xsdt);
+ acpi_write_xsdt(ctx->xsdt);
}
diff --git a/test/dm/acpi.c b/test/dm/acpi.c
index 5d5e46e2944..8e160d2cf4e 100644
--- a/test/dm/acpi.c
+++ b/test/dm/acpi.c
@@ -160,6 +160,10 @@ static int dm_test_acpi_write_tables(struct unit_test_state *uts)
ut_asserteq(map_to_sysmem(dmar + 1), ctx.rsdt->entry[1]);
ut_asserteq(0, ctx.rsdt->entry[2]);
+ ut_asserteq(map_to_sysmem(dmar), ctx.xsdt->entry[0]);
+ ut_asserteq(map_to_sysmem(dmar + 1), ctx.xsdt->entry[1]);
+ ut_asserteq(0, ctx.xsdt->entry[2]);
+
return 0;
}
DM_TEST(dm_test_acpi_write_tables, DM_TESTF_SCAN_PDATA | DM_TESTF_SCAN_FDT);
@@ -223,6 +227,7 @@ static int dm_test_acpi_setup_base_tables(struct unit_test_state *uts)
ut_assertok(table_compute_checksum(rsdt, sizeof(*rsdt)));
xsdt = PTR_ALIGN((void *)rsdt + sizeof(*rsdt), 16);
+ ut_asserteq_ptr(xsdt, ctx.xsdt);
ut_assertok(memcmp("XSDT", xsdt->header.signature, ACPI_NAME_LEN));
ut_asserteq(sizeof(*xsdt), xsdt->header.length);
ut_assertok(table_compute_checksum(xsdt, sizeof(*xsdt)));
--
2.26.0.rc2.310.g2932bb562d-goog
^ permalink raw reply related [flat|nested] 86+ messages in thread* [PATCH v3 29/29] acpi: Add an acpi command
2020-03-30 23:12 [PATCH v3 00/29] dm: Add programmatic generation of ACPI tables (part A) Simon Glass
` (27 preceding siblings ...)
2020-03-30 23:13 ` [PATCH v3 28/29] acpi: Move the xsdt pointer to acpi_ctx Simon Glass
@ 2020-03-30 23:13 ` Simon Glass
2020-03-31 18:14 ` Leif Lindholm
2020-04-03 13:39 ` Andy Shevchenko
2020-03-31 6:31 ` [PATCH v3 00/29] dm: Add programmatic generation of ACPI tables (part A) Heinrich Schuchardt
` (7 subsequent siblings)
36 siblings, 2 replies; 86+ messages in thread
From: Simon Glass @ 2020-03-30 23:13 UTC (permalink / raw)
To: u-boot
It is useful to dump ACPI tables in U-Boot to see what has been generated.
Add a command to handle this.
To allow the command to find the tables, add a position into the global
data.
Support subcommands to list and dump the tables.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Wolfgang Wallner <wolfgang.wallner@br-automation.com>
---
Changes in v3: None
Changes in v2: None
arch/sandbox/include/asm/global_data.h | 1 +
arch/x86/include/asm/global_data.h | 1 +
cmd/Kconfig | 14 ++
cmd/Makefile | 1 +
cmd/acpi.c | 179 +++++++++++++++++++++++++
lib/acpi/acpi_table.c | 1 +
test/dm/acpi.c | 73 ++++++++++
7 files changed, 270 insertions(+)
create mode 100644 cmd/acpi.c
diff --git a/arch/sandbox/include/asm/global_data.h b/arch/sandbox/include/asm/global_data.h
index f4ce72d5660..f95ddb058a2 100644
--- a/arch/sandbox/include/asm/global_data.h
+++ b/arch/sandbox/include/asm/global_data.h
@@ -13,6 +13,7 @@
struct arch_global_data {
uint8_t *ram_buf; /* emulated RAM buffer */
void *text_base; /* pointer to base of text region */
+ ulong acpi_start; /* Start address of ACPI tables */
};
#include <asm-generic/global_data.h>
diff --git a/arch/x86/include/asm/global_data.h b/arch/x86/include/asm/global_data.h
index f4c1839104e..4aee2f3e8c4 100644
--- a/arch/x86/include/asm/global_data.h
+++ b/arch/x86/include/asm/global_data.h
@@ -123,6 +123,7 @@ struct arch_global_data {
#ifdef CONFIG_FSP_VERSION2
struct fsp_header *fsp_s_hdr; /* Pointer to FSP-S header */
#endif
+ ulong acpi_start; /* Start address of ACPI tables */
};
#endif
diff --git a/cmd/Kconfig b/cmd/Kconfig
index 6403bc45a5e..2d3bfe0ab91 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -190,6 +190,20 @@ comment "Commands"
menu "Info commands"
+config CMD_ACPI
+ bool "acpi"
+ default y if ACPIGEN
+ help
+ List and dump ACPI tables. ACPI (Advanced Configuration and Power
+ Interface) is used mostly on x86 for providing information to the
+ Operating System about devices in the system. The tables are set up
+ by the firmware, typically U-Boot but possibly an earlier firmware
+ module, if U-Boot is chain-loaded from something else. ACPI tables
+ can also include code, to perform hardware-specific tasks required
+ by the Operating Systems. This allows some amount of separation
+ between the firmware and OS, and is particularly useful when you
+ want to make hardware changes without the OS needing to be adjusted.
+
config CMD_BDI
bool "bdinfo"
default y
diff --git a/cmd/Makefile b/cmd/Makefile
index f1dd513a4b4..15a9693ed0e 100644
--- a/cmd/Makefile
+++ b/cmd/Makefile
@@ -11,6 +11,7 @@ obj-y += help.o
obj-y += version.o
# command
+obj-$(CONFIG_CMD_ACPI) += acpi.o
obj-$(CONFIG_CMD_AES) += aes.o
obj-$(CONFIG_CMD_AB_SELECT) += ab_select.o
obj-$(CONFIG_CMD_ADC) += adc.o
diff --git a/cmd/acpi.c b/cmd/acpi.c
new file mode 100644
index 00000000000..8a320435736
--- /dev/null
+++ b/cmd/acpi.c
@@ -0,0 +1,179 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright 2019 Google LLC
+ * Written by Simon Glass <sjg@chromium.org>
+ */
+#include <common.h>
+#include <command.h>
+#include <mapmem.h>
+#include <acpi/acpi_table.h>
+#include <asm/acpi_table.h>
+#include <dm/acpi.h>
+
+DECLARE_GLOBAL_DATA_PTR;
+
+static void dump_hdr(struct acpi_table_header *hdr)
+{
+ bool has_hdr = memcmp(hdr->signature, "FACS", ACPI_NAME_LEN);
+
+ printf("%.*s %08lx %06x", ACPI_NAME_LEN, hdr->signature,
+ (ulong)map_to_sysmem(hdr), hdr->length);
+ if (has_hdr) {
+ printf(" (v%02d %.6s %.8s %u %.4s %d)\n", hdr->revision,
+ hdr->oem_id, hdr->oem_table_id, hdr->oem_revision,
+ hdr->aslc_id, hdr->aslc_revision);
+ } else {
+ printf("\n");
+ }
+}
+
+/**
+ * find_table() - Look up an ACPI table
+ *
+ * @sig: Signature of table (4 characters, upper case)
+ * @return pointer to table header, or NULL if not found
+ */
+struct acpi_table_header *find_table(const char *sig)
+{
+ struct acpi_rsdp *rsdp;
+ struct acpi_rsdt *rsdt;
+ int len, i, count;
+
+ rsdp = map_sysmem(gd->arch.acpi_start, 0);
+ if (!rsdp)
+ return NULL;
+ rsdt = map_sysmem(rsdp->rsdt_address, 0);
+ len = rsdt->header.length - sizeof(rsdt->header);
+ count = len / sizeof(u32);
+ for (i = 0; i < count; i++) {
+ struct acpi_table_header *hdr;
+
+ hdr = map_sysmem(rsdt->entry[i], 0);
+ if (!memcmp(hdr->signature, sig, ACPI_NAME_LEN))
+ return hdr;
+ if (!memcmp(hdr->signature, "FACP", ACPI_NAME_LEN)) {
+ struct acpi_fadt *fadt = (struct acpi_fadt *)hdr;
+
+ if (!memcmp(sig, "DSDT", ACPI_NAME_LEN) && fadt->dsdt)
+ return map_sysmem(fadt->dsdt, 0);
+ if (!memcmp(sig, "FACS", ACPI_NAME_LEN) &&
+ fadt->firmware_ctrl)
+ return map_sysmem(fadt->firmware_ctrl, 0);
+ }
+ }
+
+ return NULL;
+}
+
+static int dump_table_name(const char *sig)
+{
+ struct acpi_table_header *hdr;
+
+ hdr = find_table(sig);
+ if (!hdr)
+ return -ENOENT;
+ printf("%.*s @ %08lx\n", ACPI_NAME_LEN, hdr->signature,
+ (ulong)map_to_sysmem(hdr));
+ print_buffer(0, hdr, 1, hdr->length, 0);
+
+ return 0;
+}
+
+static void list_fact(struct acpi_fadt *fadt)
+{
+ if (fadt->dsdt)
+ dump_hdr(map_sysmem(fadt->dsdt, 0));
+ if (fadt->firmware_ctrl)
+ dump_hdr(map_sysmem(fadt->firmware_ctrl, 0));
+}
+
+static int list_rsdt(struct acpi_rsdt *rsdt, struct acpi_xsdt *xsdt)
+{
+ int len, i, count;
+
+ dump_hdr(&rsdt->header);
+ if (xsdt)
+ dump_hdr(&xsdt->header);
+ len = rsdt->header.length - sizeof(rsdt->header);
+ count = len / sizeof(u32);
+ for (i = 0; i < count; i++) {
+ struct acpi_table_header *hdr;
+
+ if (!rsdt->entry[i])
+ break;
+ hdr = map_sysmem(rsdt->entry[i], 0);
+ dump_hdr(hdr);
+ if (!memcmp(hdr->signature, "FACP", ACPI_NAME_LEN))
+ list_fact((struct acpi_fadt *)hdr);
+ if (xsdt) {
+ if (xsdt->entry[i] != rsdt->entry[i]) {
+ printf(" (xsdt mismatch %llx)\n",
+ xsdt->entry[i]);
+ }
+ }
+ }
+
+ return 0;
+}
+
+static int list_rsdp(struct acpi_rsdp *rsdp)
+{
+ struct acpi_rsdt *rsdt;
+ struct acpi_xsdt *xsdt;
+
+ printf("RSDP %08lx %06x (v%02d %.6s)\n", (ulong)map_to_sysmem(rsdp),
+ rsdp->length, rsdp->revision, rsdp->oem_id);
+ rsdt = map_sysmem(rsdp->rsdt_address, 0);
+ xsdt = map_sysmem(rsdp->xsdt_address, 0);
+ list_rsdt(rsdt, xsdt);
+
+ return 0;
+}
+
+static int do_acpi_list(cmd_tbl_t *cmdtp, int flag, int argc,
+ char *const argv[])
+{
+ struct acpi_rsdp *rsdp;
+
+ rsdp = map_sysmem(gd->arch.acpi_start, 0);
+ if (!rsdp) {
+ printf("No ACPI tables present\n");
+ return 0;
+ }
+ printf("ACPI tables start at %lx\n", gd->arch.acpi_start);
+ list_rsdp(rsdp);
+
+ return 0;
+}
+
+static int do_acpi_dump(cmd_tbl_t *cmdtp, int flag, int argc,
+ char *const argv[])
+{
+ const char *name;
+ char sig[ACPI_NAME_LEN];
+ int ret;
+
+ if (argc < 2)
+ return CMD_RET_USAGE;
+ name = argv[1];
+ if (strlen(name) != ACPI_NAME_LEN) {
+ printf("Table name '%s' must be four characters\n", name);
+ return CMD_RET_FAILURE;
+ }
+ str_to_upper(name, sig, -1);
+ ret = dump_table_name(sig);
+ if (ret) {
+ printf("Table '%.*s' not found\n", ACPI_NAME_LEN, sig);
+ return CMD_RET_FAILURE;
+ }
+
+ return 0;
+}
+
+static char acpi_help_text[] =
+ "list - list ACPI tables\n"
+ "acpi dump <name> - Dump ACPI table";
+
+U_BOOT_CMD_WITH_SUBCMDS(acpi, "ACPI tables", acpi_help_text,
+ U_BOOT_SUBCMD_MKENT(list, 1, 1, do_acpi_list),
+ U_BOOT_SUBCMD_MKENT(dump, 2, 1, do_acpi_dump));
diff --git a/lib/acpi/acpi_table.c b/lib/acpi/acpi_table.c
index 28003dc8f46..3b5479eb85b 100644
--- a/lib/acpi/acpi_table.c
+++ b/lib/acpi/acpi_table.c
@@ -238,6 +238,7 @@ void acpi_setup_base_tables(struct acpi_ctx *ctx, void *start)
/* Align ACPI tables to 16 byte */
acpi_align(ctx);
+ gd->arch.acpi_start = map_to_sysmem(ctx->current);
/* We need at least an RSDP and an RSDT Table */
ctx->rsdp = ctx->current;
diff --git a/test/dm/acpi.c b/test/dm/acpi.c
index 8e160d2cf4e..4eabf53128a 100644
--- a/test/dm/acpi.c
+++ b/test/dm/acpi.c
@@ -7,9 +7,11 @@
*/
#include <common.h>
+#include <console.h>
#include <dm.h>
#include <malloc.h>
#include <mapmem.h>
+#include <version.h>
#include <tables_csum.h>
#include <version.h>
#include <acpi/acpi_table.h>
@@ -212,6 +214,7 @@ static int dm_test_acpi_setup_base_tables(struct unit_test_state *uts)
buf = memalign(64, BUF_SIZE);
ut_assertnonnull(buf);
acpi_setup_base_tables(&ctx, buf + 4);
+ ut_asserteq(map_to_sysmem(PTR_ALIGN(buf + 4, 16)), gd->arch.acpi_start);
rsdp = buf + 16;
ut_asserteq_ptr(rsdp, ctx.rsdp);
@@ -242,3 +245,73 @@ static int dm_test_acpi_setup_base_tables(struct unit_test_state *uts)
}
DM_TEST(dm_test_acpi_setup_base_tables,
DM_TESTF_SCAN_PDATA | DM_TESTF_SCAN_FDT);
+
+/* Test 'acpi list' command */
+static int dm_test_acpi_cmd_list(struct unit_test_state *uts)
+{
+ struct acpi_ctx ctx;
+ ulong addr;
+ void *buf;
+
+ buf = memalign(16, BUF_SIZE);
+ ut_assertnonnull(buf);
+ acpi_setup_base_tables(&ctx, buf);
+
+ ut_assertok(acpi_write_dev_tables(&ctx));
+
+ console_record_reset();
+ run_command("acpi list", 0);
+ addr = (ulong)map_to_sysmem(buf);
+ ut_assert_nextline("ACPI tables start at %lx", addr);
+ ut_assert_nextline("RSDP %08lx %06lx (v02 U-BOOT)", addr,
+ sizeof(struct acpi_rsdp));
+ addr = ALIGN(addr + sizeof(struct acpi_rsdp), 16);
+ ut_assert_nextline("RSDT %08lx %06lx (v01 U-BOOT U-BOOTBL %u INTL 0)",
+ addr, sizeof(struct acpi_table_header) +
+ 2 * sizeof(u32), U_BOOT_BUILD_DATE);
+ addr = ALIGN(addr + sizeof(struct acpi_rsdt), 16);
+ ut_assert_nextline("XSDT %08lx %06lx (v01 U-BOOT U-BOOTBL %u INTL 0)",
+ addr, sizeof(struct acpi_table_header) +
+ 2 * sizeof(u64), U_BOOT_BUILD_DATE);
+ addr = ALIGN(addr + sizeof(struct acpi_xsdt), 64);
+ ut_assert_nextline("DMAR %08lx %06lx (v01 U-BOOT U-BOOTBL %u INTL 0)",
+ addr, sizeof(struct acpi_dmar), U_BOOT_BUILD_DATE);
+ addr = ALIGN(addr + sizeof(struct acpi_dmar), 16);
+ ut_assert_nextline("DMAR %08lx %06lx (v01 U-BOOT U-BOOTBL %u INTL 0)",
+ addr, sizeof(struct acpi_dmar), U_BOOT_BUILD_DATE);
+ ut_assert_console_end();
+
+ return 0;
+}
+DM_TEST(dm_test_acpi_cmd_list, DM_TESTF_SCAN_PDATA | DM_TESTF_SCAN_FDT);
+
+/* Test 'acpi dump' command */
+static int dm_test_acpi_cmd_dump(struct unit_test_state *uts)
+{
+ struct acpi_ctx ctx;
+ ulong addr;
+ void *buf;
+
+ buf = memalign(16, BUF_SIZE);
+ ut_assertnonnull(buf);
+ acpi_setup_base_tables(&ctx, buf);
+
+ ut_assertok(acpi_write_dev_tables(&ctx));
+
+ /* First search for a non-existent table */
+ console_record_reset();
+ run_command("acpi dump rdst", 0);
+ ut_assert_nextline("Table 'RDST' not found");
+ ut_assert_console_end();
+
+ /* Now a real table */
+ console_record_reset();
+ run_command("acpi dump dmar", 0);
+ addr = ALIGN(map_to_sysmem(ctx.xsdt) + sizeof(struct acpi_xsdt), 64);
+ ut_assert_nextline("DMAR @ %08lx", addr);
+ ut_assert_nextlines_are_dump(0x30);
+ ut_assert_console_end();
+
+ return 0;
+}
+DM_TEST(dm_test_acpi_cmd_dump, DM_TESTF_SCAN_PDATA | DM_TESTF_SCAN_FDT);
--
2.26.0.rc2.310.g2932bb562d-goog
^ permalink raw reply related [flat|nested] 86+ messages in thread* [PATCH v3 29/29] acpi: Add an acpi command
2020-03-30 23:13 ` [PATCH v3 29/29] acpi: Add an acpi command Simon Glass
@ 2020-03-31 18:14 ` Leif Lindholm
2020-04-03 13:41 ` Andy Shevchenko
2020-04-03 13:39 ` Andy Shevchenko
1 sibling, 1 reply; 86+ messages in thread
From: Leif Lindholm @ 2020-03-31 18:14 UTC (permalink / raw)
To: u-boot
On Mon, Mar 30, 2020 at 17:13:05 -0600, Simon Glass wrote:
> It is useful to dump ACPI tables in U-Boot to see what has been generated.
> Add a command to handle this.
>
> To allow the command to find the tables, add a position into the global
> data.
>
> Support subcommands to list and dump the tables.
>
> Signed-off-by: Simon Glass <sjg@chromium.org>
> Reviewed-by: Wolfgang Wallner <wolfgang.wallner@br-automation.com>
> ---
>
> Changes in v3: None
> Changes in v2: None
>
> arch/sandbox/include/asm/global_data.h | 1 +
> arch/x86/include/asm/global_data.h | 1 +
> cmd/Kconfig | 14 ++
> cmd/Makefile | 1 +
> cmd/acpi.c | 179 +++++++++++++++++++++++++
> lib/acpi/acpi_table.c | 1 +
> test/dm/acpi.c | 73 ++++++++++
> 7 files changed, 270 insertions(+)
> create mode 100644 cmd/acpi.c
>
> diff --git a/arch/sandbox/include/asm/global_data.h b/arch/sandbox/include/asm/global_data.h
> index f4ce72d5660..f95ddb058a2 100644
> --- a/arch/sandbox/include/asm/global_data.h
> +++ b/arch/sandbox/include/asm/global_data.h
> @@ -13,6 +13,7 @@
> struct arch_global_data {
> uint8_t *ram_buf; /* emulated RAM buffer */
> void *text_base; /* pointer to base of text region */
> + ulong acpi_start; /* Start address of ACPI tables */
> };
>
> #include <asm-generic/global_data.h>
> diff --git a/arch/x86/include/asm/global_data.h b/arch/x86/include/asm/global_data.h
> index f4c1839104e..4aee2f3e8c4 100644
> --- a/arch/x86/include/asm/global_data.h
> +++ b/arch/x86/include/asm/global_data.h
> @@ -123,6 +123,7 @@ struct arch_global_data {
> #ifdef CONFIG_FSP_VERSION2
> struct fsp_header *fsp_s_hdr; /* Pointer to FSP-S header */
> #endif
> + ulong acpi_start; /* Start address of ACPI tables */
> };
>
> #endif
> diff --git a/cmd/Kconfig b/cmd/Kconfig
> index 6403bc45a5e..2d3bfe0ab91 100644
> --- a/cmd/Kconfig
> +++ b/cmd/Kconfig
> @@ -190,6 +190,20 @@ comment "Commands"
>
> menu "Info commands"
>
> +config CMD_ACPI
> + bool "acpi"
> + default y if ACPIGEN
> + help
> + List and dump ACPI tables. ACPI (Advanced Configuration and Power
> + Interface) is used mostly on x86 for providing information to the
> + Operating System about devices in the system. The tables are set up
> + by the firmware, typically U-Boot but possibly an earlier firmware
> + module, if U-Boot is chain-loaded from something else. ACPI tables
> + can also include code, to perform hardware-specific tasks required
> + by the Operating Systems. This allows some amount of separation
> + between the firmware and OS, and is particularly useful when you
> + want to make hardware changes without the OS needing to be adjusted.
> +
> config CMD_BDI
> bool "bdinfo"
> default y
> diff --git a/cmd/Makefile b/cmd/Makefile
> index f1dd513a4b4..15a9693ed0e 100644
> --- a/cmd/Makefile
> +++ b/cmd/Makefile
> @@ -11,6 +11,7 @@ obj-y += help.o
> obj-y += version.o
>
> # command
> +obj-$(CONFIG_CMD_ACPI) += acpi.o
> obj-$(CONFIG_CMD_AES) += aes.o
> obj-$(CONFIG_CMD_AB_SELECT) += ab_select.o
> obj-$(CONFIG_CMD_ADC) += adc.o
> diff --git a/cmd/acpi.c b/cmd/acpi.c
> new file mode 100644
> index 00000000000..8a320435736
> --- /dev/null
> +++ b/cmd/acpi.c
> @@ -0,0 +1,179 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright 2019 Google LLC
> + * Written by Simon Glass <sjg@chromium.org>
> + */
> +#include <common.h>
> +#include <command.h>
> +#include <mapmem.h>
> +#include <acpi/acpi_table.h>
> +#include <asm/acpi_table.h>
> +#include <dm/acpi.h>
> +
> +DECLARE_GLOBAL_DATA_PTR;
> +
> +static void dump_hdr(struct acpi_table_header *hdr)
> +{
> + bool has_hdr = memcmp(hdr->signature, "FACS", ACPI_NAME_LEN);
> +
> + printf("%.*s %08lx %06x", ACPI_NAME_LEN, hdr->signature,
> + (ulong)map_to_sysmem(hdr), hdr->length);
> + if (has_hdr) {
> + printf(" (v%02d %.6s %.8s %u %.4s %d)\n", hdr->revision,
> + hdr->oem_id, hdr->oem_table_id, hdr->oem_revision,
> + hdr->aslc_id, hdr->aslc_revision);
> + } else {
> + printf("\n");
> + }
> +}
> +
> +/**
> + * find_table() - Look up an ACPI table
> + *
> + * @sig: Signature of table (4 characters, upper case)
> + * @return pointer to table header, or NULL if not found
> + */
> +struct acpi_table_header *find_table(const char *sig)
> +{
> + struct acpi_rsdp *rsdp;
> + struct acpi_rsdt *rsdt;
> + int len, i, count;
> +
> + rsdp = map_sysmem(gd->arch.acpi_start, 0);
> + if (!rsdp)
> + return NULL;
> + rsdt = map_sysmem(rsdp->rsdt_address, 0);
> + len = rsdt->header.length - sizeof(rsdt->header);
> + count = len / sizeof(u32);
> + for (i = 0; i < count; i++) {
> + struct acpi_table_header *hdr;
> +
> + hdr = map_sysmem(rsdt->entry[i], 0);
> + if (!memcmp(hdr->signature, sig, ACPI_NAME_LEN))
> + return hdr;
> + if (!memcmp(hdr->signature, "FACP", ACPI_NAME_LEN)) {
> + struct acpi_fadt *fadt = (struct acpi_fadt *)hdr;
> +
> + if (!memcmp(sig, "DSDT", ACPI_NAME_LEN) && fadt->dsdt)
> + return map_sysmem(fadt->dsdt, 0);
> + if (!memcmp(sig, "FACS", ACPI_NAME_LEN) &&
> + fadt->firmware_ctrl)
> + return map_sysmem(fadt->firmware_ctrl, 0);
> + }
> + }
> +
> + return NULL;
> +}
> +
> +static int dump_table_name(const char *sig)
> +{
> + struct acpi_table_header *hdr;
> +
> + hdr = find_table(sig);
> + if (!hdr)
> + return -ENOENT;
> + printf("%.*s @ %08lx\n", ACPI_NAME_LEN, hdr->signature,
> + (ulong)map_to_sysmem(hdr));
> + print_buffer(0, hdr, 1, hdr->length, 0);
> +
> + return 0;
> +}
> +
> +static void list_fact(struct acpi_fadt *fadt)
Hmm, should this function be called list_facp or list_fadt?
(The wonder that is the table called FADT with the marker FACP.)
/
Leif
> +{
> + if (fadt->dsdt)
> + dump_hdr(map_sysmem(fadt->dsdt, 0));
> + if (fadt->firmware_ctrl)
> + dump_hdr(map_sysmem(fadt->firmware_ctrl, 0));
> +}
> +
> +static int list_rsdt(struct acpi_rsdt *rsdt, struct acpi_xsdt *xsdt)
> +{
> + int len, i, count;
> +
> + dump_hdr(&rsdt->header);
> + if (xsdt)
> + dump_hdr(&xsdt->header);
> + len = rsdt->header.length - sizeof(rsdt->header);
> + count = len / sizeof(u32);
> + for (i = 0; i < count; i++) {
> + struct acpi_table_header *hdr;
> +
> + if (!rsdt->entry[i])
> + break;
> + hdr = map_sysmem(rsdt->entry[i], 0);
> + dump_hdr(hdr);
> + if (!memcmp(hdr->signature, "FACP", ACPI_NAME_LEN))
> + list_fact((struct acpi_fadt *)hdr);
> + if (xsdt) {
> + if (xsdt->entry[i] != rsdt->entry[i]) {
> + printf(" (xsdt mismatch %llx)\n",
> + xsdt->entry[i]);
> + }
> + }
> + }
> +
> + return 0;
> +}
> +
> +static int list_rsdp(struct acpi_rsdp *rsdp)
> +{
> + struct acpi_rsdt *rsdt;
> + struct acpi_xsdt *xsdt;
> +
> + printf("RSDP %08lx %06x (v%02d %.6s)\n", (ulong)map_to_sysmem(rsdp),
> + rsdp->length, rsdp->revision, rsdp->oem_id);
> + rsdt = map_sysmem(rsdp->rsdt_address, 0);
> + xsdt = map_sysmem(rsdp->xsdt_address, 0);
> + list_rsdt(rsdt, xsdt);
> +
> + return 0;
> +}
> +
> +static int do_acpi_list(cmd_tbl_t *cmdtp, int flag, int argc,
> + char *const argv[])
> +{
> + struct acpi_rsdp *rsdp;
> +
> + rsdp = map_sysmem(gd->arch.acpi_start, 0);
> + if (!rsdp) {
> + printf("No ACPI tables present\n");
> + return 0;
> + }
> + printf("ACPI tables start at %lx\n", gd->arch.acpi_start);
> + list_rsdp(rsdp);
> +
> + return 0;
> +}
> +
> +static int do_acpi_dump(cmd_tbl_t *cmdtp, int flag, int argc,
> + char *const argv[])
> +{
> + const char *name;
> + char sig[ACPI_NAME_LEN];
> + int ret;
> +
> + if (argc < 2)
> + return CMD_RET_USAGE;
> + name = argv[1];
> + if (strlen(name) != ACPI_NAME_LEN) {
> + printf("Table name '%s' must be four characters\n", name);
> + return CMD_RET_FAILURE;
> + }
> + str_to_upper(name, sig, -1);
> + ret = dump_table_name(sig);
> + if (ret) {
> + printf("Table '%.*s' not found\n", ACPI_NAME_LEN, sig);
> + return CMD_RET_FAILURE;
> + }
> +
> + return 0;
> +}
> +
> +static char acpi_help_text[] =
> + "list - list ACPI tables\n"
> + "acpi dump <name> - Dump ACPI table";
> +
> +U_BOOT_CMD_WITH_SUBCMDS(acpi, "ACPI tables", acpi_help_text,
> + U_BOOT_SUBCMD_MKENT(list, 1, 1, do_acpi_list),
> + U_BOOT_SUBCMD_MKENT(dump, 2, 1, do_acpi_dump));
> diff --git a/lib/acpi/acpi_table.c b/lib/acpi/acpi_table.c
> index 28003dc8f46..3b5479eb85b 100644
> --- a/lib/acpi/acpi_table.c
> +++ b/lib/acpi/acpi_table.c
> @@ -238,6 +238,7 @@ void acpi_setup_base_tables(struct acpi_ctx *ctx, void *start)
>
> /* Align ACPI tables to 16 byte */
> acpi_align(ctx);
> + gd->arch.acpi_start = map_to_sysmem(ctx->current);
>
> /* We need at least an RSDP and an RSDT Table */
> ctx->rsdp = ctx->current;
> diff --git a/test/dm/acpi.c b/test/dm/acpi.c
> index 8e160d2cf4e..4eabf53128a 100644
> --- a/test/dm/acpi.c
> +++ b/test/dm/acpi.c
> @@ -7,9 +7,11 @@
> */
>
> #include <common.h>
> +#include <console.h>
> #include <dm.h>
> #include <malloc.h>
> #include <mapmem.h>
> +#include <version.h>
> #include <tables_csum.h>
> #include <version.h>
> #include <acpi/acpi_table.h>
> @@ -212,6 +214,7 @@ static int dm_test_acpi_setup_base_tables(struct unit_test_state *uts)
> buf = memalign(64, BUF_SIZE);
> ut_assertnonnull(buf);
> acpi_setup_base_tables(&ctx, buf + 4);
> + ut_asserteq(map_to_sysmem(PTR_ALIGN(buf + 4, 16)), gd->arch.acpi_start);
>
> rsdp = buf + 16;
> ut_asserteq_ptr(rsdp, ctx.rsdp);
> @@ -242,3 +245,73 @@ static int dm_test_acpi_setup_base_tables(struct unit_test_state *uts)
> }
> DM_TEST(dm_test_acpi_setup_base_tables,
> DM_TESTF_SCAN_PDATA | DM_TESTF_SCAN_FDT);
> +
> +/* Test 'acpi list' command */
> +static int dm_test_acpi_cmd_list(struct unit_test_state *uts)
> +{
> + struct acpi_ctx ctx;
> + ulong addr;
> + void *buf;
> +
> + buf = memalign(16, BUF_SIZE);
> + ut_assertnonnull(buf);
> + acpi_setup_base_tables(&ctx, buf);
> +
> + ut_assertok(acpi_write_dev_tables(&ctx));
> +
> + console_record_reset();
> + run_command("acpi list", 0);
> + addr = (ulong)map_to_sysmem(buf);
> + ut_assert_nextline("ACPI tables start at %lx", addr);
> + ut_assert_nextline("RSDP %08lx %06lx (v02 U-BOOT)", addr,
> + sizeof(struct acpi_rsdp));
> + addr = ALIGN(addr + sizeof(struct acpi_rsdp), 16);
> + ut_assert_nextline("RSDT %08lx %06lx (v01 U-BOOT U-BOOTBL %u INTL 0)",
> + addr, sizeof(struct acpi_table_header) +
> + 2 * sizeof(u32), U_BOOT_BUILD_DATE);
> + addr = ALIGN(addr + sizeof(struct acpi_rsdt), 16);
> + ut_assert_nextline("XSDT %08lx %06lx (v01 U-BOOT U-BOOTBL %u INTL 0)",
> + addr, sizeof(struct acpi_table_header) +
> + 2 * sizeof(u64), U_BOOT_BUILD_DATE);
> + addr = ALIGN(addr + sizeof(struct acpi_xsdt), 64);
> + ut_assert_nextline("DMAR %08lx %06lx (v01 U-BOOT U-BOOTBL %u INTL 0)",
> + addr, sizeof(struct acpi_dmar), U_BOOT_BUILD_DATE);
> + addr = ALIGN(addr + sizeof(struct acpi_dmar), 16);
> + ut_assert_nextline("DMAR %08lx %06lx (v01 U-BOOT U-BOOTBL %u INTL 0)",
> + addr, sizeof(struct acpi_dmar), U_BOOT_BUILD_DATE);
> + ut_assert_console_end();
> +
> + return 0;
> +}
> +DM_TEST(dm_test_acpi_cmd_list, DM_TESTF_SCAN_PDATA | DM_TESTF_SCAN_FDT);
> +
> +/* Test 'acpi dump' command */
> +static int dm_test_acpi_cmd_dump(struct unit_test_state *uts)
> +{
> + struct acpi_ctx ctx;
> + ulong addr;
> + void *buf;
> +
> + buf = memalign(16, BUF_SIZE);
> + ut_assertnonnull(buf);
> + acpi_setup_base_tables(&ctx, buf);
> +
> + ut_assertok(acpi_write_dev_tables(&ctx));
> +
> + /* First search for a non-existent table */
> + console_record_reset();
> + run_command("acpi dump rdst", 0);
> + ut_assert_nextline("Table 'RDST' not found");
> + ut_assert_console_end();
> +
> + /* Now a real table */
> + console_record_reset();
> + run_command("acpi dump dmar", 0);
> + addr = ALIGN(map_to_sysmem(ctx.xsdt) + sizeof(struct acpi_xsdt), 64);
> + ut_assert_nextline("DMAR @ %08lx", addr);
> + ut_assert_nextlines_are_dump(0x30);
> + ut_assert_console_end();
> +
> + return 0;
> +}
> +DM_TEST(dm_test_acpi_cmd_dump, DM_TESTF_SCAN_PDATA | DM_TESTF_SCAN_FDT);
> --
> 2.26.0.rc2.310.g2932bb562d-goog
>
^ permalink raw reply [flat|nested] 86+ messages in thread* [PATCH v3 29/29] acpi: Add an acpi command
2020-03-31 18:14 ` Leif Lindholm
@ 2020-04-03 13:41 ` Andy Shevchenko
0 siblings, 0 replies; 86+ messages in thread
From: Andy Shevchenko @ 2020-04-03 13:41 UTC (permalink / raw)
To: u-boot
On Tue, Mar 31, 2020 at 07:14:18PM +0100, Leif Lindholm wrote:
> On Mon, Mar 30, 2020 at 17:13:05 -0600, Simon Glass wrote:
> > +static void list_fact(struct acpi_fadt *fadt)
>
> Hmm, should this function be called list_facp or list_fadt?
> (The wonder that is the table called FADT with the marker FACP.)
Spec refers to some historical reasons.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply [flat|nested] 86+ messages in thread
* [PATCH v3 29/29] acpi: Add an acpi command
2020-03-30 23:13 ` [PATCH v3 29/29] acpi: Add an acpi command Simon Glass
2020-03-31 18:14 ` Leif Lindholm
@ 2020-04-03 13:39 ` Andy Shevchenko
1 sibling, 0 replies; 86+ messages in thread
From: Andy Shevchenko @ 2020-04-03 13:39 UTC (permalink / raw)
To: u-boot
On Mon, Mar 30, 2020 at 05:13:05PM -0600, Simon Glass wrote:
> It is useful to dump ACPI tables in U-Boot to see what has been generated.
> Add a command to handle this.
>
> To allow the command to find the tables, add a position into the global
> data.
>
> Support subcommands to list and dump the tables.
...
> +static void dump_hdr(struct acpi_table_header *hdr)
> +{
> + bool has_hdr = memcmp(hdr->signature, "FACS", ACPI_NAME_LEN);
I believe more than one table has the same header structure. Either this
function is incorrectly called (should be dump_facs_hdr() or alike), or
you need to make it better, i.e. generic.
> + printf("%.*s %08lx %06x", ACPI_NAME_LEN, hdr->signature,
> + (ulong)map_to_sysmem(hdr), hdr->length);
> + if (has_hdr) {
> + printf(" (v%02d %.6s %.8s %u %.4s %d)\n", hdr->revision,
> + hdr->oem_id, hdr->oem_table_id, hdr->oem_revision,
> + hdr->aslc_id, hdr->aslc_revision);
> + } else {
> + printf("\n");
> + }
> +}
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply [flat|nested] 86+ messages in thread
* [PATCH v3 00/29] dm: Add programmatic generation of ACPI tables (part A)
2020-03-30 23:12 [PATCH v3 00/29] dm: Add programmatic generation of ACPI tables (part A) Simon Glass
` (28 preceding siblings ...)
2020-03-30 23:13 ` [PATCH v3 29/29] acpi: Add an acpi command Simon Glass
@ 2020-03-31 6:31 ` Heinrich Schuchardt
2020-04-02 2:34 ` Simon Glass
2020-03-31 8:07 ` Antwort: [PATCH v3 11/29] x86: apl: Add Global NVS table header Wolfgang Wallner
` (6 subsequent siblings)
36 siblings, 1 reply; 86+ messages in thread
From: Heinrich Schuchardt @ 2020-03-31 6:31 UTC (permalink / raw)
To: u-boot
On 3/31/20 1:12 AM, Simon Glass wrote:
> This is split from the original series in an attempt to get things applied
> in chunks.
>
> This section includes patches up to and including the 'acpi' command.
>
> Changes in v3:
> - Add a pointer to information about acpi,compatible
> - Add forward declarations for the functions
> - Add missing error check in acpi_create_dmar()
> - Add new patch to add hexdump.h to the unit test header
> - Add new patch to move acpi_s3.h to include/acpi/
> - Beef up the comment explaining how the unaligned address is used
> - Change the example to ELAN
> - Compute ACPI_NAME_MAX from ACPI_NAME_LEN
> - Correct description of acpi,probed
> - Drop 'Intel' from 'Intel ACPI'
Hello Simon,
not only x86 but also ARM can use ACPI tables for booting. Below I see
all those files under arch/x86/lib/.
I think we should separate the x86 specific stuff from the general ACPI
coding.
This is not meant to stop this series but can be done afterwards.
Best regards
Heinrich
> - Drop acpi,name in example
> - Drop duplicate assert
> - Drop hid-descr-addr
> - Drop mention of PRIC
> - Fix 'RSDP' typo
> - Fix 'XDST' typo
> - Fix DMA_ typo
> - Fix a few typos
> - Fix file comment for acpi_table.c
> - Fix indenting error mentioned by Andy Shevchenko
> - Fix stray #endif
> - Just add the device.txt binding file in this patch
> - Make use of BIT()
> - Move acpi_align_large() out of dm_test_acpi_setup_base_tables()
> - Move acpi_table.h to include/acpi
> - Rename acpi,desc to acpi,ddn
> - Rename acpi_align_large() to acpi_align64()
> - Rename acpi_return_name() to acpi_copy_name()
> - Reword commit message to drop the bit about ACPI being complicated
> - Split out hid-over-i2c into its own patch
> - Update commit message to say that we move most of its contents
> - Use strncpy() instead of strcpy() in acpi_copy_name()
>
> Changes in v2:
> - Add in the acpi_table.h header file to this patch
> - Add the hid-over-i2c binding document
> - Add trailing commas to enum
> - Don't bracket the definitions with DM_SPI
> - Drop definition of ACPI_TABLE_CREATOR
> - Drop the Chrome OS pieces
> - Drop the other comment change since it is already applied
> - Drop two unnecessary __packed
> - Fix definition of HID
> - Generalise the ACPI function recursion with acpi_recurse_method()
> - Infer hid-over-i2c CID value
> - Make _acpi_write_dev_tables() static and switch argument order
> - Move LOGC_ACPI definition to this patch
> - Move __packed to after struct
> - Move the sandbox acpi_table.h header file to an earlier patch
> - Rename the 'coreboot' console to 'U-Boot'
> - Use #defines for MADT and MCFG version numbers
>
> Simon Glass (29):
> cpu: Support querying the address width
> spi: Add SPI mode enums
> tpm: cr50: Release locality on exit
> tpm: cr50: Add a comment for cr50_priv
> tpm: cr50: Use the correct GPIO binding
> tpm: Don't cleanup unless an error happens
> dm: pci: Allow disabling auto-config for a device
> x86: Correct wording of coreboot source code
> x86: apl: Move p2sb ofdata reading to the correct method
> pci: Adjust dm_pci_read_bar32() to return errors correctly
> x86: apl: Add Global NVS table header
> dm: core: Add basic ACPI support
> dts: Add a binding for hid-over-i2c
> acpi: Add a binding for ACPI settings in the device tree
> acpi: Add a simple sandbox test
> x86: Move acpi_s3.h to include/acpi/
> x86: Move acpi_table header to main include/ directory
> acpi: Add an __ACPI__ preprocessor symbol
> acpi: Add a central location for table version numbers
> acpi: Add support for DMAR
> test: Add hexdump.h to the unit test header
> acpi: Add a method to write tables for a device
> acpi: Convert part of acpi_table to use acpi_ctx
> x86: Allow devices to write ACPI tables
> acpi: Drop code for missing XSDT from acpi_write_rsdp()
> acpi: Move acpi_add_table() to generic code
> acpi: Put table-setup code in its own function
> acpi: Move the xsdt pointer to acpi_ctx
> acpi: Add an acpi command
>
> arch/sandbox/dts/test.dts | 8 +
> arch/sandbox/include/asm/acpi_table.h | 9 +
> arch/sandbox/include/asm/global_data.h | 1 +
> arch/x86/cpu/apollolake/cpu_spl.c | 2 +-
> arch/x86/cpu/apollolake/fsp_s.c | 2 +-
> arch/x86/cpu/apollolake/pmc.c | 2 +-
> arch/x86/cpu/baytrail/acpi.c | 6 +-
> arch/x86/cpu/coreboot/timestamp.c | 4 +-
> arch/x86/cpu/cpu.c | 4 +-
> arch/x86/cpu/intel_common/p2sb.c | 33 +-
> arch/x86/cpu/quark/acpi.c | 2 +-
> arch/x86/cpu/tangier/acpi.c | 4 +-
> arch/x86/cpu/wakeup.S | 2 +-
> arch/x86/dts/chromebook_coral.dts | 2 +-
> arch/x86/include/asm/acpi_table.h | 381 +-----------
> .../include/asm/arch-apollolake/global_nvs.h | 36 ++
> .../x86/include/asm/arch-coreboot/timestamp.h | 4 +-
> arch/x86/include/asm/global_data.h | 1 +
> arch/x86/include/asm/intel_pinctrl_defs.h | 2 -
> arch/x86/lib/acpi.c | 2 +-
> arch/x86/lib/acpi_s3.c | 4 +-
> arch/x86/lib/acpi_table.c | 240 ++------
> arch/x86/lib/coreboot_table.c | 2 +-
> arch/x86/lib/fsp/fsp_common.c | 2 +-
> arch/x86/lib/fsp1/fsp_common.c | 2 +-
> arch/x86/lib/fsp2/fsp_dram.c | 2 +-
> arch/x86/lib/tables.c | 2 +-
> arch/x86/lib/zimage.c | 2 +-
> cmd/Kconfig | 14 +
> cmd/Makefile | 1 +
> cmd/acpi.c | 179 ++++++
> doc/device-tree-bindings/device.txt | 37 ++
> .../gpio/intel,apl-gpio.txt | 2 +-
> .../input/hid-over-i2c.txt | 44 ++
> .../interrupt-controller/intel,acpi-gpe.txt | 2 +-
> doc/device-tree-bindings/pci/x86-pci.txt | 23 +
> drivers/core/Kconfig | 9 +
> drivers/core/Makefile | 1 +
> drivers/core/acpi.c | 94 +++
> drivers/cpu/cpu_sandbox.c | 1 +
> drivers/pci/pci-uclass.c | 11 +-
> drivers/pci/pci_rom.c | 4 +-
> drivers/power/acpi_pmc/acpi-pmc-uclass.c | 2 +-
> drivers/sysreset/sysreset_x86.c | 2 +-
> drivers/tpm/cr50_i2c.c | 24 +-
> drivers/tpm/tpm-uclass.c | 13 +-
> include/{ => acpi}/acpi_s3.h | 0
> include/acpi/acpi_table.h | 581 ++++++++++++++++++
> include/cpu.h | 2 +
> include/dm/acpi.h | 114 ++++
> include/dm/device.h | 5 +
> include/dm/uclass-id.h | 1 +
> include/log.h | 2 +
> include/spi.h | 33 +
> include/test/ut.h | 1 +
> lib/Makefile | 1 +
> lib/acpi/Makefile | 4 +
> lib/acpi/acpi_table.c | 257 ++++++++
> lib/efi_loader/efi_acpi.c | 2 +-
> scripts/Makefile.lib | 4 +-
> test/dm/Makefile | 1 +
> test/dm/acpi.c | 317 ++++++++++
> test/dm/cpu.c | 1 +
> 63 files changed, 1915 insertions(+), 637 deletions(-)
> create mode 100644 arch/sandbox/include/asm/acpi_table.h
> create mode 100644 arch/x86/include/asm/arch-apollolake/global_nvs.h
> create mode 100644 cmd/acpi.c
> create mode 100644 doc/device-tree-bindings/device.txt
> create mode 100644 doc/device-tree-bindings/input/hid-over-i2c.txt
> create mode 100644 drivers/core/acpi.c
> rename include/{ => acpi}/acpi_s3.h (100%)
> create mode 100644 include/acpi/acpi_table.h
> create mode 100644 include/dm/acpi.h
> create mode 100644 lib/acpi/Makefile
> create mode 100644 lib/acpi/acpi_table.c
> create mode 100644 test/dm/acpi.c
>
^ permalink raw reply [flat|nested] 86+ messages in thread* [PATCH v3 00/29] dm: Add programmatic generation of ACPI tables (part A)
2020-03-31 6:31 ` [PATCH v3 00/29] dm: Add programmatic generation of ACPI tables (part A) Heinrich Schuchardt
@ 2020-04-02 2:34 ` Simon Glass
0 siblings, 0 replies; 86+ messages in thread
From: Simon Glass @ 2020-04-02 2:34 UTC (permalink / raw)
To: u-boot
Hi Heinrich,
On Tue, 31 Mar 2020 at 00:37, Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:
>
> On 3/31/20 1:12 AM, Simon Glass wrote:
> > This is split from the original series in an attempt to get things applied
> > in chunks.
> >
> > This section includes patches up to and including the 'acpi' command.
> >
> > Changes in v3:
> > - Add a pointer to information about acpi,compatible
> > - Add forward declarations for the functions
> > - Add missing error check in acpi_create_dmar()
> > - Add new patch to add hexdump.h to the unit test header
> > - Add new patch to move acpi_s3.h to include/acpi/
> > - Beef up the comment explaining how the unaligned address is used
> > - Change the example to ELAN
> > - Compute ACPI_NAME_MAX from ACPI_NAME_LEN
> > - Correct description of acpi,probed
> > - Drop 'Intel' from 'Intel ACPI'
>
>
> Hello Simon,
>
> not only x86 but also ARM can use ACPI tables for booting. Below I see
> all those files under arch/x86/lib/.
Not all. Actually quite a few are in drivers/core and lib/acpi.
>
> I think we should separate the x86 specific stuff from the general ACPI
> coding.
>
> This is not meant to stop this series but can be done afterwards.
Yes we can easily move things when needed and I've already moved
things based on feedback from ARM. I really don't want the location of
code to hold up progress.
Regards,
Simon
>
> Best regards
>
> Heinrich
>
> > - Drop acpi,name in example
> > - Drop duplicate assert
> > - Drop hid-descr-addr
> > - Drop mention of PRIC
> > - Fix 'RSDP' typo
> > - Fix 'XDST' typo
> > - Fix DMA_ typo
> > - Fix a few typos
> > - Fix file comment for acpi_table.c
> > - Fix indenting error mentioned by Andy Shevchenko
> > - Fix stray #endif
> > - Just add the device.txt binding file in this patch
> > - Make use of BIT()
> > - Move acpi_align_large() out of dm_test_acpi_setup_base_tables()
> > - Move acpi_table.h to include/acpi
> > - Rename acpi,desc to acpi,ddn
> > - Rename acpi_align_large() to acpi_align64()
> > - Rename acpi_return_name() to acpi_copy_name()
> > - Reword commit message to drop the bit about ACPI being complicated
> > - Split out hid-over-i2c into its own patch
> > - Update commit message to say that we move most of its contents
> > - Use strncpy() instead of strcpy() in acpi_copy_name()
> >
> > Changes in v2:
> > - Add in the acpi_table.h header file to this patch
> > - Add the hid-over-i2c binding document
> > - Add trailing commas to enum
> > - Don't bracket the definitions with DM_SPI
> > - Drop definition of ACPI_TABLE_CREATOR
> > - Drop the Chrome OS pieces
> > - Drop the other comment change since it is already applied
> > - Drop two unnecessary __packed
> > - Fix definition of HID
> > - Generalise the ACPI function recursion with acpi_recurse_method()
> > - Infer hid-over-i2c CID value
> > - Make _acpi_write_dev_tables() static and switch argument order
> > - Move LOGC_ACPI definition to this patch
> > - Move __packed to after struct
> > - Move the sandbox acpi_table.h header file to an earlier patch
> > - Rename the 'coreboot' console to 'U-Boot'
> > - Use #defines for MADT and MCFG version numbers
> >
> > Simon Glass (29):
> > cpu: Support querying the address width
> > spi: Add SPI mode enums
> > tpm: cr50: Release locality on exit
> > tpm: cr50: Add a comment for cr50_priv
> > tpm: cr50: Use the correct GPIO binding
> > tpm: Don't cleanup unless an error happens
> > dm: pci: Allow disabling auto-config for a device
> > x86: Correct wording of coreboot source code
> > x86: apl: Move p2sb ofdata reading to the correct method
> > pci: Adjust dm_pci_read_bar32() to return errors correctly
> > x86: apl: Add Global NVS table header
> > dm: core: Add basic ACPI support
> > dts: Add a binding for hid-over-i2c
> > acpi: Add a binding for ACPI settings in the device tree
> > acpi: Add a simple sandbox test
> > x86: Move acpi_s3.h to include/acpi/
> > x86: Move acpi_table header to main include/ directory
> > acpi: Add an __ACPI__ preprocessor symbol
> > acpi: Add a central location for table version numbers
> > acpi: Add support for DMAR
> > test: Add hexdump.h to the unit test header
> > acpi: Add a method to write tables for a device
> > acpi: Convert part of acpi_table to use acpi_ctx
> > x86: Allow devices to write ACPI tables
> > acpi: Drop code for missing XSDT from acpi_write_rsdp()
> > acpi: Move acpi_add_table() to generic code
> > acpi: Put table-setup code in its own function
> > acpi: Move the xsdt pointer to acpi_ctx
> > acpi: Add an acpi command
> >
> > arch/sandbox/dts/test.dts | 8 +
> > arch/sandbox/include/asm/acpi_table.h | 9 +
> > arch/sandbox/include/asm/global_data.h | 1 +
> > arch/x86/cpu/apollolake/cpu_spl.c | 2 +-
> > arch/x86/cpu/apollolake/fsp_s.c | 2 +-
> > arch/x86/cpu/apollolake/pmc.c | 2 +-
> > arch/x86/cpu/baytrail/acpi.c | 6 +-
> > arch/x86/cpu/coreboot/timestamp.c | 4 +-
> > arch/x86/cpu/cpu.c | 4 +-
> > arch/x86/cpu/intel_common/p2sb.c | 33 +-
> > arch/x86/cpu/quark/acpi.c | 2 +-
> > arch/x86/cpu/tangier/acpi.c | 4 +-
> > arch/x86/cpu/wakeup.S | 2 +-
> > arch/x86/dts/chromebook_coral.dts | 2 +-
> > arch/x86/include/asm/acpi_table.h | 381 +-----------
> > .../include/asm/arch-apollolake/global_nvs.h | 36 ++
> > .../x86/include/asm/arch-coreboot/timestamp.h | 4 +-
> > arch/x86/include/asm/global_data.h | 1 +
> > arch/x86/include/asm/intel_pinctrl_defs.h | 2 -
> > arch/x86/lib/acpi.c | 2 +-
> > arch/x86/lib/acpi_s3.c | 4 +-
> > arch/x86/lib/acpi_table.c | 240 ++------
> > arch/x86/lib/coreboot_table.c | 2 +-
> > arch/x86/lib/fsp/fsp_common.c | 2 +-
> > arch/x86/lib/fsp1/fsp_common.c | 2 +-
> > arch/x86/lib/fsp2/fsp_dram.c | 2 +-
> > arch/x86/lib/tables.c | 2 +-
> > arch/x86/lib/zimage.c | 2 +-
> > cmd/Kconfig | 14 +
> > cmd/Makefile | 1 +
> > cmd/acpi.c | 179 ++++++
> > doc/device-tree-bindings/device.txt | 37 ++
> > .../gpio/intel,apl-gpio.txt | 2 +-
> > .../input/hid-over-i2c.txt | 44 ++
> > .../interrupt-controller/intel,acpi-gpe.txt | 2 +-
> > doc/device-tree-bindings/pci/x86-pci.txt | 23 +
> > drivers/core/Kconfig | 9 +
> > drivers/core/Makefile | 1 +
> > drivers/core/acpi.c | 94 +++
> > drivers/cpu/cpu_sandbox.c | 1 +
> > drivers/pci/pci-uclass.c | 11 +-
> > drivers/pci/pci_rom.c | 4 +-
> > drivers/power/acpi_pmc/acpi-pmc-uclass.c | 2 +-
> > drivers/sysreset/sysreset_x86.c | 2 +-
> > drivers/tpm/cr50_i2c.c | 24 +-
> > drivers/tpm/tpm-uclass.c | 13 +-
> > include/{ => acpi}/acpi_s3.h | 0
> > include/acpi/acpi_table.h | 581 ++++++++++++++++++
> > include/cpu.h | 2 +
> > include/dm/acpi.h | 114 ++++
> > include/dm/device.h | 5 +
> > include/dm/uclass-id.h | 1 +
> > include/log.h | 2 +
> > include/spi.h | 33 +
> > include/test/ut.h | 1 +
> > lib/Makefile | 1 +
> > lib/acpi/Makefile | 4 +
> > lib/acpi/acpi_table.c | 257 ++++++++
> > lib/efi_loader/efi_acpi.c | 2 +-
> > scripts/Makefile.lib | 4 +-
> > test/dm/Makefile | 1 +
> > test/dm/acpi.c | 317 ++++++++++
> > test/dm/cpu.c | 1 +
> > 63 files changed, 1915 insertions(+), 637 deletions(-)
> > create mode 100644 arch/sandbox/include/asm/acpi_table.h
> > create mode 100644 arch/x86/include/asm/arch-apollolake/global_nvs.h
> > create mode 100644 cmd/acpi.c
> > create mode 100644 doc/device-tree-bindings/device.txt
> > create mode 100644 doc/device-tree-bindings/input/hid-over-i2c.txt
> > create mode 100644 drivers/core/acpi.c
> > rename include/{ => acpi}/acpi_s3.h (100%)
> > create mode 100644 include/acpi/acpi_table.h
> > create mode 100644 include/dm/acpi.h
> > create mode 100644 lib/acpi/Makefile
> > create mode 100644 lib/acpi/acpi_table.c
> > create mode 100644 test/dm/acpi.c
> >
>
^ permalink raw reply [flat|nested] 86+ messages in thread
* Antwort: [PATCH v3 11/29] x86: apl: Add Global NVS table header
2020-03-30 23:12 [PATCH v3 00/29] dm: Add programmatic generation of ACPI tables (part A) Simon Glass
` (29 preceding siblings ...)
2020-03-31 6:31 ` [PATCH v3 00/29] dm: Add programmatic generation of ACPI tables (part A) Heinrich Schuchardt
@ 2020-03-31 8:07 ` Wolfgang Wallner
2020-04-03 11:25 ` Andy Shevchenko
2020-03-31 8:16 ` Antwort: [PATCH v3 12/29] dm: core: Add basic ACPI support Wolfgang Wallner
` (5 subsequent siblings)
36 siblings, 1 reply; 86+ messages in thread
From: Wolfgang Wallner @ 2020-03-31 8:07 UTC (permalink / raw)
To: u-boot
Hi Simon,
-----"Simon Glass" <sjg@chromium.org> schrieb: -----
>An: u-boot at lists.denx.de
>Von: "Simon Glass" <sjg@chromium.org>
>Datum: 31.03.2020 01:14
>Kopie: "Andy Shevchenko" <andriy.shevchenko@linux.intel.com>,
>"Wolfgang Wallner" <wolfgang.wallner@br-automation.com>, "Leif
>Lindholm" <leif@nuviainc.com>, "Simon Glass" <sjg@chromium.org>, "Bin
>Meng" <bmeng.cn@gmail.com>
>Betreff: [PATCH v3 11/29] x86: apl: Add Global NVS table header
>
>Add the C version of this header. It includes a few Chrome OS bits
>which
>are disabled for a normal build.
>
>Signed-off-by: Simon Glass <sjg@chromium.org>
>---
>
>Changes in v3:
>- Fix stray #endif
>
>Changes in v2:
>- Drop the Chrome OS pieces
>- Rename the 'coreboot' console to 'U-Boot'
>
> .../include/asm/arch-apollolake/global_nvs.h | 36
>+++++++++++++++++++
> 1 file changed, 36 insertions(+)
> create mode 100644 arch/x86/include/asm/arch-apollolake/global_nvs.h
>
>diff --git a/arch/x86/include/asm/arch-apollolake/global_nvs.h
>b/arch/x86/include/asm/arch-apollolake/global_nvs.h
>new file mode 100644
>index 00000000000..5bde837a755
>--- /dev/null
>+++ b/arch/x86/include/asm/arch-apollolake/global_nvs.h
>@@ -0,0 +1,36 @@
>+/* SPDX-License-Identifier: GPL-2.0+ */
>+/*
>+ * Copyright (C) 2015-2017 Intel Corp.
>+ * (Written by Lance Zhao <lijian.zhao@intel.com> for Intel Corp.)
>+ * Copyright Google LLC 2019
>+ *
>+ * Modified from coreboot apollolake/include/soc/nvs.h
>+ */
>+
>+#ifndef _GLOBAL_NVS_H_
>+#define _GLOBAL_NVS_H_
>+
>+struct __packed acpi_global_nvs {
>+ /* Miscellaneous */
>+ u8 pcnt; /* 0x00 - Processor Count */
>+ u8 ppcm; /* 0x01 - Max PPC State */
>+ u8 lids; /* 0x02 - LID State */
>+ u8 pwrs; /* 0x03 - AC Power State */
>+ u8 dpte; /* 0x04 - Enable DPTF */
>+ u32 cbmc; /* 0x05 - 0x08 - U-Boot Console */
>+ u64 pm1i; /* 0x09 - 0x10 - System Wake Source - PM1 Index */
>+ u64 gpei; /* 0x11 - 0x18 - GPE Wake Source */
>+ u64 nhla; /* 0x19 - 0x20 - NHLT Address */
>+ u32 nhll; /* 0x21 - 0x24 - NHLT Length */
>+ u32 prt0; /* 0x25 - 0x28 - PERST_0 Address */
>+ u8 scdp; /* 0x29 - SD_CD GPIO portid */
>+ u8 scdo; /* 0x2A - GPIO pad offset relative to the community */
>+ u8 uior; /* 0x2B - UART debug controller init on S3 resume */
>+ u8 ecps; /* 0x2C - SGX Enabled status */
>+ u64 emna; /* 0x2D - 0x34 EPC base address */
>+ u64 elng; /* 0x35 - 0x3C EPC Length */
>+ u8 unused[195];
>+ u8 unused2[0xf00];
Nit 1: Something is still wrong with the indentation of unused2.
Nit 2: Could you please add comments on why the values 195 and 0xf00 were
chosen? I would assume 195 was selected so that unused2 starts on
a 256-byte boundary? But that is only a guess.
>+};
>+
>+#endif /* _GLOBAL_NVS_H_ */
>--
>2.26.0.rc2.310.g2932bb562d-goog
>
Reviewed-by: Wolfgang Wallner <wolgang.wallner@br-automation.com>
^ permalink raw reply [flat|nested] 86+ messages in thread* Antwort: [PATCH v3 11/29] x86: apl: Add Global NVS table header
2020-03-31 8:07 ` Antwort: [PATCH v3 11/29] x86: apl: Add Global NVS table header Wolfgang Wallner
@ 2020-04-03 11:25 ` Andy Shevchenko
0 siblings, 0 replies; 86+ messages in thread
From: Andy Shevchenko @ 2020-04-03 11:25 UTC (permalink / raw)
To: u-boot
On Tue, Mar 31, 2020 at 10:07:37AM +0200, Wolfgang Wallner wrote:
> >+struct __packed acpi_global_nvs {
> >+ /* Miscellaneous */
> >+ u8 pcnt; /* 0x00 - Processor Count */
> >+ u8 ppcm; /* 0x01 - Max PPC State */
> >+ u8 lids; /* 0x02 - LID State */
> >+ u8 pwrs; /* 0x03 - AC Power State */
> >+ u8 dpte; /* 0x04 - Enable DPTF */
> >+ u32 cbmc; /* 0x05 - 0x08 - U-Boot Console */
> >+ u64 pm1i; /* 0x09 - 0x10 - System Wake Source - PM1 Index */
> >+ u64 gpei; /* 0x11 - 0x18 - GPE Wake Source */
> >+ u64 nhla; /* 0x19 - 0x20 - NHLT Address */
> >+ u32 nhll; /* 0x21 - 0x24 - NHLT Length */
> >+ u32 prt0; /* 0x25 - 0x28 - PERST_0 Address */
> >+ u8 scdp; /* 0x29 - SD_CD GPIO portid */
> >+ u8 scdo; /* 0x2A - GPIO pad offset relative to the community */
> >+ u8 uior; /* 0x2B - UART debug controller init on S3 resume */
> >+ u8 ecps; /* 0x2C - SGX Enabled status */
> >+ u64 emna; /* 0x2D - 0x34 EPC base address */
> >+ u64 elng; /* 0x35 - 0x3C EPC Length */
> >+ u8 unused[195];
> >+ u8 unused2[0xf00];
>
> Nit 1: Something is still wrong with the indentation of unused2.
>
> Nit 2: Could you please add comments on why the values 195 and 0xf00 were
> chosen? I would assume 195 was selected so that unused2 starts on
> a 256-byte boundary? But that is only a guess.
Better to calculate them (I mean 195). In Linux kernel, for instance, a trick
is being used for that.
The rest is not simply boundary but rather 256 vs 4096 size of NVS. The
previous (small one) is what being used by U-Boot. I don't remember what ACPI
spec dictates about this (i.o.w. if it depends to the ACPI version in use).
> >+};
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply [flat|nested] 86+ messages in thread
* Antwort: [PATCH v3 12/29] dm: core: Add basic ACPI support
2020-03-30 23:12 [PATCH v3 00/29] dm: Add programmatic generation of ACPI tables (part A) Simon Glass
` (30 preceding siblings ...)
2020-03-31 8:07 ` Antwort: [PATCH v3 11/29] x86: apl: Add Global NVS table header Wolfgang Wallner
@ 2020-03-31 8:16 ` Wolfgang Wallner
2020-03-31 19:25 ` Antwort: [PATCH v3 13/29] dts: Add a binding for hid-over-i2c Wolfgang Wallner
` (4 subsequent siblings)
36 siblings, 0 replies; 86+ messages in thread
From: Wolfgang Wallner @ 2020-03-31 8:16 UTC (permalink / raw)
To: u-boot
Hi Simon,
-----"Simon Glass" <sjg@chromium.org> schrieb: -----
>Betreff: [PATCH v3 12/29] dm: core: Add basic ACPI support
>
>ACPI (Advanced Configuration and Power Interface) is a standard for
>specifying information about a platform. It is a little like device
>tree but the bindings are part of the specification and it supports
>an
>interpreted bytecode language.
>
>Driver model does not use ACPI for U-Boot's configuration, but it is
>convenient to have it support generation of ACPI tables for passing
>to
>Linux, etc.
>
>As a starting point, add an optional set of ACPI operations to each
>device. Initially only a single operation is available, to obtain the
>ACPI name for the device. More operations are added later.
>
>Enable ACPI for sandbox to ensure build coverage and so that we can
>add
>tests.
>
>Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
>Signed-off-by: Simon Glass <sjg@chromium.org>
>---
>
>Changes in v3:
>- Compute ACPI_NAME_MAX from ACPI_NAME_LEN
>- Drop 'Intel' from 'Intel ACPI'
>- Rename acpi_return_name() to acpi_copy_name()
>- Reword commit message to drop the bit about ACPI being complicated
>- Use strncpy() instead of strcpy() in acpi_copy_name()
>
>Changes in v2:
>- Move LOGC_ACPI definition to this patch
>
> drivers/core/Kconfig | 9 ++++++
> drivers/core/Makefile | 1 +
> drivers/core/acpi.c | 33 +++++++++++++++++++
> include/dm/acpi.h | 73
>+++++++++++++++++++++++++++++++++++++++++++
> include/dm/device.h | 5 +++
> include/log.h | 2 ++
> 6 files changed, 123 insertions(+)
> create mode 100644 drivers/core/acpi.c
> create mode 100644 include/dm/acpi.h
>
Reviewed-by: Wolfgang Wallner <wolfgang.wallner@br-automation.com>
^ permalink raw reply [flat|nested] 86+ messages in thread* Antwort: [PATCH v3 13/29] dts: Add a binding for hid-over-i2c
2020-03-30 23:12 [PATCH v3 00/29] dm: Add programmatic generation of ACPI tables (part A) Simon Glass
` (31 preceding siblings ...)
2020-03-31 8:16 ` Antwort: [PATCH v3 12/29] dm: core: Add basic ACPI support Wolfgang Wallner
@ 2020-03-31 19:25 ` Wolfgang Wallner
2020-04-08 2:58 ` Simon Glass
2020-03-31 19:30 ` Antwort: [PATCH v3 19/29] acpi: Add a central location for table version numbers Wolfgang Wallner
` (3 subsequent siblings)
36 siblings, 1 reply; 86+ messages in thread
From: Wolfgang Wallner @ 2020-03-31 19:25 UTC (permalink / raw)
To: u-boot
Hi Simon,
-----"Simon Glass" <sjg@chromium.org> schrieb: -----
>An: u-boot at lists.denx.de
>Von: "Simon Glass" <sjg@chromium.org>
>Datum: 31.03.2020 01:14
>Kopie: "Andy Shevchenko" <andriy.shevchenko@linux.intel.com>,
>"Wolfgang Wallner" <wolfgang.wallner@br-automation.com>, "Leif
>Lindholm" <leif@nuviainc.com>, "Simon Glass" <sjg@chromium.org>
>Betreff: [PATCH v3 14/29] acpi: Add a binding for ACPI settings in
>the device tree
>
> Devices need to report various identifiers in the ACPI tables. Rather than
> hard-coding these in drivers it is typically better to put them in the
> device tree.
>
> Add a binding file to describe this.
>
> Signed-off-by: Simon Glass <sjg@chromium.org>
> ---
>
> Changes in v3:
> - Add a pointer to information about acpi,compatible
> - Change the example to ELAN
> - Correct description of acpi,probed
> - Drop hid-descr-addr
> - Drop mention of PRIC
I understand now where the term "PRIC" came from.
The property "acpi,has-power-resource" triggers the function
acpi_device_add_power_res(), which writes a PowerResource ('PowerResource'
as specified in section 7.2 of ACPI 6.3). This function comes from Coreboot,
and that implementation uses "PRIC" as the hardcoded device name. That's it,
it is an arbitrary chosen device name (probably meaning "power IC" ... ?).
Anyway, dropping the term "PRIC" makes the description easier to understand.
The important information is that "acpi,has-power-resource" leads to the
addition of a PowerResource entry.
> - Just add the device.txt binding file in this patch
> - Rename acpi,desc to acpi,ddn
>
> Changes in v2:
> - Add the hid-over-i2c binding document
> - Fix definition of HID
> - Infer hid-over-i2c CID value
>
> doc/device-tree-bindings/device.txt | 37 +++++++++++++++++++++++++++++
> 1 file changed, 37 insertions(+)
> create mode 100644 doc/device-tree-bindings/device.txt
>
> diff --git a/doc/device-tree-bindings/device.txt b/doc/device-tree-bindings/device.txt
> new file mode 100644
> index 00000000000..06c2b84b6d5
> --- /dev/null
> +++ b/doc/device-tree-bindings/device.txt
> @@ -0,0 +1,37 @@
> +Devices
> +=======
> +
> +Device bindings are described by their own individual binding files.
> +
> +U-Boot provides for some optional properties which are documented here. See
> +also hid-over-i2c.txt which describes HID devices. See also
> +Documentation/firmware-guide/acpi/enumeration.rst in the Linux kernel for
> +the acpi,compatible property.
> +
> + - acpi,has-power-resource : (boolean) true if this device has a power resource.
> + This causes an ACPI PowerResource to be written containing the properties
> + provided by this binding, to describe how to handle powering the device up
> + and down using GPIOs
> + - acpi,compatible : compatible string to report
I still don't see a use case for a new "acpi,compatible" property.
I will take a step back, and explain my understanding of the involved pieces
and why I think adding "acpi,compatible" is of no benefit.
Summary:
As far as I understand the proposed "acpi, compatible" property, the following
would happen:
We have "acpi,compatible" in Devicetree, which results in a "compatible"-entry
in ACPI's _DSD method, which is then again interpreted as the
"compatible"-property of Devicetree. IMHO it would be strange for "compatible"
and "acpi,compatible" to be different, so we could drop "acpi,compatible" and
use the existing "compatible" instead.
The _DSD-method for "PRP0001"-devices in ACPI allows to use Devicetree
properties inside ACPI, especially it allows to re-use Devicetree's
"compatible"-property. But this is for a different use case (using Devicetree
properties inside ACPI, not add ACPI properties in Devicetree).
Detailed explanation:
1) ACPI Constraint: Devices need to have either _HID or _ADR
ACPI puts constraints on what properties a device ("device" here means a
"Device()" entry in ASL code (DSDT or SSDT)) has to have. It has to have
either an _HID or an _ADR property depending on whether it is on an
enumerable bus:
* if it is on an enumerable bus, it has to have an _ADR (address)
property (e.g. a PCI device on a PCI bus)
* if it is not on an enumerable bus, it has to have a _HID (hardware ID)
property (e.g. the GPIO controllers on the Apollo Lake SoC). The legal
values for _HID are specified and allow the type of the device to be
identified (a similar concept as the "compatible" property in devicetree)
These contraints are specified in section 6.1 of ACPI 6.3 [1].
2) ACPI's _DSD Method
The Device Specific Data (_DSD) method provides a way to provide additional
device properties to device drivers. It returns a package of "Device Data
Descriptors", each consisting of a UUID and a package in a format defined
by the provided UUID.
The details are specified in section 6.2.5 of ACPI 6.3 [1].
3) Special UUID value for _DSD: daffd814-...
The document "Device Properties UUID For _DSD" [2] specifies a special UUID
value: daffd814-6eba-4d8c-8a91-bc9bbf4aa301
When this UUID is used in the package returned by in a _DSD method,
it means the format of the package after the UUID consits of packages
each of size 2.
The first entry in these packages always has to be a string, the second
entry can be an integer, a string, a reference or again a package. The
value of the string defines the type and allowed values of the second entry.
The typical use case for this UUID is to return some kind of
key/value-pairs.
The specification in [2] does not specify which strings are legal as
key names. This depends on the _HID of the device that implements the
_DSD method.
4) Special _HID value: PRP0001
When the _HID property has the value "PRP0001", the _DSD method is expected
to provide data with the "daffd814"-UUID which contains a "compatible"
property.
This interpreted similar to the "compatible" property known from Devicetree.
5) Linux device-property API
Linux provides a "device-property" API (define in include/linux/property.h)
which can be used instead of a Devicetree specific API.
E.g. using device_property_read_u32() instead of of_property_read_u32().
Putting these pieces together:
Suppose the following use case:
There is an existing driver for Devicetree, but it should be used under
x86, where devices are usually described via ACPI.
To avoid having to register a new _HID that would have the exact same
meaning in ACPI as an already existing Devicetree "compatible" string, the
possibilities desbribed by 2-4) allow to solve this use case while
respecting the contraints described in 1).
Additionally, using the API described in 5) allows to add other Devicetree
properties (not only the "compatible" property) to the ACPI description of
the device. This allows to have a single device driver that can get its
device description from either Devicetree or ACPI, and the description is
basically the same in both worlds. This is described e.g. in the
presentation in [4].
[1] https://uefi.org/sites/default/files/resources/ACPI_6_3_final_Jan30.pdf
[2] http://www.uefi.org/sites/default/files/resources/_DSD-device-properties-UUID.pdf
[3] Documentation/firmware-guide/acpi/enumeration.rst in the Linux kernel
[4] https://elinux.org/images/2/2d/Device_tree_acpi_compatibility-david_woodhouse-kernel_recipes_2015.pdf
> + - acpi,ddn : Contains the string to use as the _DDN (DOS (Disk Operating
> + System) Device Name)
> + - acpi,hid : Contains the string to use as the HID (Hardware ID)
> + identifier _HID
> + - acpi,probed : Tells U-Boot to add 'linux,probed' to the ACPI tables so that
> + Linux will only load the driver if the device can be detected (e.g. on I2C
> + bus)
Will support for 'linux,probed' be mainlined? Otherwise the description
should IMHO mention that it is an out-of-tree feature.
> + - acpi,uid : _UID value for device
> +
> +
> +Example
> +-------
> +
> +elan_touchscreen: elan-touchscreen at 10 {
> + compatible = "i2c-chip";
Why would you use a generic compatible string in this case?
According to drivers/input/touchscreen/elants_i2c.c in the Linux kernel
the ACPI _HID "ELAN0001" refers to the same device as the Devicetree
compatible string "elan,ekth3500".
Again, because of the direct relationship between "compatible" string and
_HID I think we could move that knowledge into a (stub-) driver for
"elan,ekth3500" and then we could avoid the need for "acpi,hid" here.
> + reg = <0x10>;
> + acpi,hid = "ELAN0001";
> + acpi,ddn = "ELAN Touchscreen";
> + interrupts-extended = <&acpi_gpe GPIO_21_IRQ
> + IRQ_TYPE_EDGE_FALLING>;
> + acpi,probed;
> +};
> --
> 2.26.0.rc2.310.g2932bb562d-goog
regards, Wolfgang
^ permalink raw reply [flat|nested] 86+ messages in thread* [PATCH v3 13/29] dts: Add a binding for hid-over-i2c
2020-03-31 19:25 ` Antwort: [PATCH v3 13/29] dts: Add a binding for hid-over-i2c Wolfgang Wallner
@ 2020-04-08 2:58 ` Simon Glass
2020-04-08 17:08 ` Andy Shevchenko
2020-04-08 19:39 ` Antwort: " Wolfgang Wallner
0 siblings, 2 replies; 86+ messages in thread
From: Simon Glass @ 2020-04-08 2:58 UTC (permalink / raw)
To: u-boot
Hi Wolfgang,
On Tue, 31 Mar 2020 at 13:25, Wolfgang Wallner
<wolfgang.wallner@br-automation.com> wrote:
>
> Hi Simon,
>
> -----"Simon Glass" <sjg@chromium.org> schrieb: -----
>
> >An: u-boot at lists.denx.de
> >Von: "Simon Glass" <sjg@chromium.org>
> >Datum: 31.03.2020 01:14
> >Kopie: "Andy Shevchenko" <andriy.shevchenko@linux.intel.com>,
> >"Wolfgang Wallner" <wolfgang.wallner@br-automation.com>, "Leif
> >Lindholm" <leif@nuviainc.com>, "Simon Glass" <sjg@chromium.org>
> >Betreff: [PATCH v3 14/29] acpi: Add a binding for ACPI settings in
> >the device tree
> >
> > Devices need to report various identifiers in the ACPI tables. Rather than
> > hard-coding these in drivers it is typically better to put them in the
> > device tree.
> >
> > Add a binding file to describe this.
> >
> > Signed-off-by: Simon Glass <sjg@chromium.org>
> > ---
> >
> > Changes in v3:
> > - Add a pointer to information about acpi,compatible
> > - Change the example to ELAN
> > - Correct description of acpi,probed
> > - Drop hid-descr-addr
> > - Drop mention of PRIC
>
> I understand now where the term "PRIC" came from.
> The property "acpi,has-power-resource" triggers the function
> acpi_device_add_power_res(), which writes a PowerResource ('PowerResource'
> as specified in section 7.2 of ACPI 6.3). This function comes from Coreboot,
> and that implementation uses "PRIC" as the hardcoded device name. That's it,
> it is an arbitrary chosen device name (probably meaning "power IC" ... ?).
>
> Anyway, dropping the term "PRIC" makes the description easier to understand.
> The important information is that "acpi,has-power-resource" leads to the
> addition of a PowerResource entry.
>
> > - Just add the device.txt binding file in this patch
> > - Rename acpi,desc to acpi,ddn
> >
> > Changes in v2:
> > - Add the hid-over-i2c binding document
> > - Fix definition of HID
> > - Infer hid-over-i2c CID value
> >
> > doc/device-tree-bindings/device.txt | 37 +++++++++++++++++++++++++++++
> > 1 file changed, 37 insertions(+)
> > create mode 100644 doc/device-tree-bindings/device.txt
> >
> > diff --git a/doc/device-tree-bindings/device.txt b/doc/device-tree-bindings/device.txt
> > new file mode 100644
> > index 00000000000..06c2b84b6d5
> > --- /dev/null
> > +++ b/doc/device-tree-bindings/device.txt
> > @@ -0,0 +1,37 @@
> > +Devices
> > +=======
> > +
> > +Device bindings are described by their own individual binding files.
> > +
> > +U-Boot provides for some optional properties which are documented here. See
> > +also hid-over-i2c.txt which describes HID devices. See also
> > +Documentation/firmware-guide/acpi/enumeration.rst in the Linux kernel for
> > +the acpi,compatible property.
> > +
> > + - acpi,has-power-resource : (boolean) true if this device has a power resource.
> > + This causes an ACPI PowerResource to be written containing the properties
> > + provided by this binding, to describe how to handle powering the device up
> > + and down using GPIOs
> > + - acpi,compatible : compatible string to report
>
> I still don't see a use case for a new "acpi,compatible" property.
> I will take a step back, and explain my understanding of the involved pieces
> and why I think adding "acpi,compatible" is of no benefit.
>
> Summary:
> As far as I understand the proposed "acpi, compatible" property, the following
> would happen:
> We have "acpi,compatible" in Devicetree, which results in a "compatible"-entry
> in ACPI's _DSD method, which is then again interpreted as the
> "compatible"-property of Devicetree. IMHO it would be strange for "compatible"
> and "acpi,compatible" to be different, so we could drop "acpi,compatible" and
> use the existing "compatible" instead.
But the compatible string is "hid-over-i2c". We don't want to have
lots of different compatible strings here, different drivers which do
the same thing. If we end up wanting a touchscreen drivers in U-Boot
that might change, but for now I think a generic driver is easier.
>
> The _DSD-method for "PRP0001"-devices in ACPI allows to use Devicetree
> properties inside ACPI, especially it allows to re-use Devicetree's
> "compatible"-property. But this is for a different use case (using Devicetree
> properties inside ACPI, not add ACPI properties in Devicetree).
>
> Detailed explanation:
>
> 1) ACPI Constraint: Devices need to have either _HID or _ADR
>
> ACPI puts constraints on what properties a device ("device" here means a
> "Device()" entry in ASL code (DSDT or SSDT)) has to have. It has to have
> either an _HID or an _ADR property depending on whether it is on an
> enumerable bus:
>
> * if it is on an enumerable bus, it has to have an _ADR (address)
> property (e.g. a PCI device on a PCI bus)
> * if it is not on an enumerable bus, it has to have a _HID (hardware ID)
> property (e.g. the GPIO controllers on the Apollo Lake SoC). The legal
> values for _HID are specified and allow the type of the device to be
> identified (a similar concept as the "compatible" property in devicetree)
>
> These contraints are specified in section 6.1 of ACPI 6.3 [1].
>
> 2) ACPI's _DSD Method
>
> The Device Specific Data (_DSD) method provides a way to provide additional
> device properties to device drivers. It returns a package of "Device Data
> Descriptors", each consisting of a UUID and a package in a format defined
> by the provided UUID.
>
> The details are specified in section 6.2.5 of ACPI 6.3 [1].
>
> 3) Special UUID value for _DSD: daffd814-...
>
> The document "Device Properties UUID For _DSD" [2] specifies a special UUID
> value: daffd814-6eba-4d8c-8a91-bc9bbf4aa301
>
> When this UUID is used in the package returned by in a _DSD method,
> it means the format of the package after the UUID consits of packages
> each of size 2.
> The first entry in these packages always has to be a string, the second
> entry can be an integer, a string, a reference or again a package. The
> value of the string defines the type and allowed values of the second entry.
>
> The typical use case for this UUID is to return some kind of
> key/value-pairs.
>
> The specification in [2] does not specify which strings are legal as
> key names. This depends on the _HID of the device that implements the
> _DSD method.
>
> 4) Special _HID value: PRP0001
>
> When the _HID property has the value "PRP0001", the _DSD method is expected
> to provide data with the "daffd814"-UUID which contains a "compatible"
> property.
>
> This interpreted similar to the "compatible" property known from Devicetree.
>
> 5) Linux device-property API
>
> Linux provides a "device-property" API (define in include/linux/property.h)
> which can be used instead of a Devicetree specific API.
> E.g. using device_property_read_u32() instead of of_property_read_u32().
>
Thank you very much for digging into this. I read the ACPI spec years
ago but clearly need to read it again.
> Putting these pieces together:
>
> Suppose the following use case:
> There is an existing driver for Devicetree, but it should be used under
> x86, where devices are usually described via ACPI.
>
> To avoid having to register a new _HID that would have the exact same
> meaning in ACPI as an already existing Devicetree "compatible" string, the
> possibilities desbribed by 2-4) allow to solve this use case while
> respecting the contraints described in 1).
>
> Additionally, using the API described in 5) allows to add other Devicetree
> properties (not only the "compatible" property) to the ACPI description of
> the device. This allows to have a single device driver that can get its
> device description from either Devicetree or ACPI, and the description is
> basically the same in both worlds. This is described e.g. in the
> presentation in [4].
>
> [1] https://uefi.org/sites/default/files/resources/ACPI_6_3_final_Jan30.pdf
> [2] http://www.uefi.org/sites/default/files/resources/_DSD-device-properties-UUID.pdf
> [3] Documentation/firmware-guide/acpi/enumeration.rst in the Linux kernel
> [4] https://elinux.org/images/2/2d/Device_tree_acpi_compatibility-david_woodhouse-kernel_recipes_2015.pdf
>
> > + - acpi,ddn : Contains the string to use as the _DDN (DOS (Disk Operating
> > + System) Device Name)
> > + - acpi,hid : Contains the string to use as the HID (Hardware ID)
> > + identifier _HID
> > + - acpi,probed : Tells U-Boot to add 'linux,probed' to the ACPI tables so that
> > + Linux will only load the driver if the device can be detected (e.g. on I2C
> > + bus)
>
> Will support for 'linux,probed' be mainlined? Otherwise the description
> should IMHO mention that it is an out-of-tree feature.
OK
>
> > + - acpi,uid : _UID value for device
> > +
> > +
> > +Example
> > +-------
> > +
> > +elan_touchscreen: elan-touchscreen at 10 {
> > + compatible = "i2c-chip";
>
> Why would you use a generic compatible string in this case?
> According to drivers/input/touchscreen/elants_i2c.c in the Linux kernel
> the ACPI _HID "ELAN0001" refers to the same device as the Devicetree
> compatible string "elan,ekth3500".
>
> Again, because of the direct relationship between "compatible" string and
> _HID I think we could move that knowledge into a (stub-) driver for
> "elan,ekth3500" and then we could avoid the need for "acpi,hid" here.
But then we need a driver for the ELAN touchscreen. My goal here is to
have all of these devices serviced by a single driver, using suitable
properties in the DT.
>
> > + reg = <0x10>;
> > + acpi,hid = "ELAN0001";
> > + acpi,ddn = "ELAN Touchscreen";
> > + interrupts-extended = <&acpi_gpe GPIO_21_IRQ
> > + IRQ_TYPE_EDGE_FALLING>;
> > + acpi,probed;
> > +};
> > --
> > 2.26.0.rc2.310.g2932bb562d-goog
>
Regards,
SImon
^ permalink raw reply [flat|nested] 86+ messages in thread* [PATCH v3 13/29] dts: Add a binding for hid-over-i2c
2020-04-08 2:58 ` Simon Glass
@ 2020-04-08 17:08 ` Andy Shevchenko
2020-04-08 19:39 ` Antwort: " Wolfgang Wallner
1 sibling, 0 replies; 86+ messages in thread
From: Andy Shevchenko @ 2020-04-08 17:08 UTC (permalink / raw)
To: u-boot
On Tue, Apr 07, 2020 at 08:58:13PM -0600, Simon Glass wrote:
> On Tue, 31 Mar 2020 at 13:25, Wolfgang Wallner
> <wolfgang.wallner@br-automation.com> wrote:
> > >An: u-boot at lists.denx.de
> > >Von: "Simon Glass" <sjg@chromium.org>
> > >Datum: 31.03.2020 01:14
> > >Kopie: "Andy Shevchenko" <andriy.shevchenko@linux.intel.com>,
> > >"Wolfgang Wallner" <wolfgang.wallner@br-automation.com>, "Leif
> > >Lindholm" <leif@nuviainc.com>, "Simon Glass" <sjg@chromium.org>
> > >Betreff: [PATCH v3 14/29] acpi: Add a binding for ACPI settings in
> > >the device tree
> > The _DSD-method for "PRP0001"-devices in ACPI allows to use Devicetree
> > properties inside ACPI, especially it allows to re-use Devicetree's
> > "compatible"-property. But this is for a different use case (using Devicetree
> > properties inside ACPI, not add ACPI properties in Devicetree).
Before we are going further with this here is a BIG CAVEAT.
PRP0001 MUST NOT be used in production devices.
This has been derived solely for debugging / pre-production testing / etc
purposes. The real devices must have an official ACPI _HID.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply [flat|nested] 86+ messages in thread
* Antwort: Re: [PATCH v3 13/29] dts: Add a binding for hid-over-i2c
2020-04-08 2:58 ` Simon Glass
2020-04-08 17:08 ` Andy Shevchenko
@ 2020-04-08 19:39 ` Wolfgang Wallner
2020-04-08 20:40 ` Andy Shevchenko
1 sibling, 1 reply; 86+ messages in thread
From: Wolfgang Wallner @ 2020-04-08 19:39 UTC (permalink / raw)
To: u-boot
Hi Andy,
-----"Andy Shevchenko" <andriy.shevchenko@linux.intel.com> schrieb: -----
>
> Betreff: Re: [PATCH v3 13/29] dts: Add a binding for hid-over-i2c
>
> On Tue, Apr 07, 2020 at 08:58:13PM -0600, Simon Glass wrote:
> > On Tue, 31 Mar 2020 at 13:25, Wolfgang Wallner
> > <wolfgang.wallner@br-automation.com> wrote:
> > > >An: u-boot at lists.denx.de
> > > >Von: "Simon Glass" <sjg@chromium.org>
> > > >Datum: 31.03.2020 01:14
> > > >Kopie: "Andy Shevchenko" <andriy.shevchenko@linux.intel.com>,
> > > >"Wolfgang Wallner" <wolfgang.wallner@br-automation.com>, "Leif
> > > >Lindholm" <leif@nuviainc.com>, "Simon Glass" <sjg@chromium.org>
> > > >Betreff: [PATCH v3 14/29] acpi: Add a binding for ACPI settings in
> > > >the device tree
>
> > > The _DSD-method for "PRP0001"-devices in ACPI allows to use Devicetree
> > > properties inside ACPI, especially it allows to re-use Devicetree's
> > > "compatible"-property. But this is for a different use case (using Devicetree
> > > properties inside ACPI, not add ACPI properties in Devicetree).
>
> Before we are going further with this here is a BIG CAVEAT.
>
> PRP0001 MUST NOT be used in production devices.
>
> This has been derived solely for debugging / pre-production testing / etc
> purposes. The real devices must have an official ACPI _HID.
Thanks for pointing this out! I was not aware of this.
I have tried to understand how the PRP0001 is meant to be used, but could not
find sufficient documentation. The best document I could find is
Documentation/firmware-guide/acpi/enumeration.rst in the Linux kernel, and
as far as I can tell the constraint that you mention is also not described
there.
Do you know any other resources regarding PRP0001, e.g. some kind of
speficiation?
If PRP0001 is only for debugging, then I must also have misunderstood the
Linux "device-property" API (define in include/linux/property.h).
There are some presentations available on the internet, e.g. [1], that I
understand like PRP0001 + "device-property" API provide a way do access data
from either Devicetree or ACPI, depending on what kind of platform you are on.
regards, Wolfgang
[1] https://elinux.org/images/2/2d/Device_tree_acpi_compatibility-david_woodhouse-kernel_recipes_2015.pdf
^ permalink raw reply [flat|nested] 86+ messages in thread
* [PATCH v3 13/29] dts: Add a binding for hid-over-i2c
2020-04-08 19:39 ` Antwort: " Wolfgang Wallner
@ 2020-04-08 20:40 ` Andy Shevchenko
2020-04-08 20:49 ` Andy Shevchenko
2020-04-15 14:00 ` Antwort: Re: " Wolfgang Wallner
0 siblings, 2 replies; 86+ messages in thread
From: Andy Shevchenko @ 2020-04-08 20:40 UTC (permalink / raw)
To: u-boot
On Wed, Apr 8, 2020 at 10:39 PM Wolfgang Wallner
<wolfgang.wallner@br-automation.com> wrote:
> > On Tue, Apr 07, 2020 at 08:58:13PM -0600, Simon Glass wrote:
> > > On Tue, 31 Mar 2020 at 13:25, Wolfgang Wallner
> > > <wolfgang.wallner@br-automation.com> wrote:
> > > > >An: u-boot at lists.denx.de
> > > > >Von: "Simon Glass" <sjg@chromium.org>
> > > > >Datum: 31.03.2020 01:14
> > > > >Kopie: "Andy Shevchenko" <andriy.shevchenko@linux.intel.com>,
> > > > >"Wolfgang Wallner" <wolfgang.wallner@br-automation.com>, "Leif
> > > > >Lindholm" <leif@nuviainc.com>, "Simon Glass" <sjg@chromium.org>
> > > > >Betreff: [PATCH v3 14/29] acpi: Add a binding for ACPI settings in
> > > > >the device tree
> >
> > > > The _DSD-method for "PRP0001"-devices in ACPI allows to use Devicetree
> > > > properties inside ACPI, especially it allows to re-use Devicetree's
> > > > "compatible"-property. But this is for a different use case (using Devicetree
> > > > properties inside ACPI, not add ACPI properties in Devicetree).
> >
> > Before we are going further with this here is a BIG CAVEAT.
> >
> > PRP0001 MUST NOT be used in production devices.
> >
> > This has been derived solely for debugging / pre-production testing / etc
> > purposes. The real devices must have an official ACPI _HID.
>
> Thanks for pointing this out! I was not aware of this.
> I have tried to understand how the PRP0001 is meant to be used, but could not
> find sufficient documentation. The best document I could find is
> Documentation/firmware-guide/acpi/enumeration.rst in the Linux kernel, and
> as far as I can tell the constraint that you mention is also not described
> there.
>
> Do you know any other resources regarding PRP0001, e.g. some kind of
> speficiation?
I guess the best one is to ask somebody from UEFI Forum / ASWG. PRP is
a PNP ID for UEFI Forum.
> If PRP0001 is only for debugging, then I must also have misunderstood the
> Linux "device-property" API (define in include/linux/property.h).
Not exactly.
> There are some presentations available on the internet, e.g. [1], that I
> understand like PRP0001 + "device-property" API provide a way do access data
> from either Devicetree or ACPI, depending on what kind of platform you are on.
No, these are not hard linked to each other (the relation is that
PRP0001 is a way to enumerate devices, which don't have dedicated ACPI
_HID, by using compatible property [1]). The _DSD per se (i.o.w.
device properties implementation in ACPI) is a different story [2].
And I put [3] here, interesting to read. However, at that time I was
quite far from this topic.
[1]: https://www.kernel.org/doc/html/latest/firmware-guide/acpi/enumeration.html#device-tree-namespace-link-device-id
[2]: https://uefi.org/sites/default/files/resources/_DSD-implementation-guide-toplevel-1_2-3.htm.
[3]: https://patchwork.kernel.org/patch/7004241/
> [1] https://elinux.org/images/2/2d/Device_tree_acpi_compatibility-david_woodhouse-kernel_recipes_2015.pdf
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply [flat|nested] 86+ messages in thread
* [PATCH v3 13/29] dts: Add a binding for hid-over-i2c
2020-04-08 20:40 ` Andy Shevchenko
@ 2020-04-08 20:49 ` Andy Shevchenko
2020-04-15 14:00 ` Antwort: Re: " Wolfgang Wallner
1 sibling, 0 replies; 86+ messages in thread
From: Andy Shevchenko @ 2020-04-08 20:49 UTC (permalink / raw)
To: u-boot
On Wed, Apr 8, 2020 at 11:40 PM Andy Shevchenko
<andy.shevchenko@gmail.com> wrote:
> On Wed, Apr 8, 2020 at 10:39 PM Wolfgang Wallner
> <wolfgang.wallner@br-automation.com> wrote:
> > > On Tue, Apr 07, 2020 at 08:58:13PM -0600, Simon Glass wrote:
> > > > On Tue, 31 Mar 2020 at 13:25, Wolfgang Wallner
> > > > <wolfgang.wallner@br-automation.com> wrote:
> > > > > >An: u-boot at lists.denx.de
> > > > > >Von: "Simon Glass" <sjg@chromium.org>
> > > > > >Datum: 31.03.2020 01:14
> > > > > >Kopie: "Andy Shevchenko" <andriy.shevchenko@linux.intel.com>,
> > > > > >"Wolfgang Wallner" <wolfgang.wallner@br-automation.com>, "Leif
> > > > > >Lindholm" <leif@nuviainc.com>, "Simon Glass" <sjg@chromium.org>
> > > > > >Betreff: [PATCH v3 14/29] acpi: Add a binding for ACPI settings in
> > > > > >the device tree
> > >
> > > > > The _DSD-method for "PRP0001"-devices in ACPI allows to use Devicetree
> > > > > properties inside ACPI, especially it allows to re-use Devicetree's
> > > > > "compatible"-property. But this is for a different use case (using Devicetree
> > > > > properties inside ACPI, not add ACPI properties in Devicetree).
> > >
> > > Before we are going further with this here is a BIG CAVEAT.
> > >
> > > PRP0001 MUST NOT be used in production devices.
> > >
> > > This has been derived solely for debugging / pre-production testing / etc
> > > purposes. The real devices must have an official ACPI _HID.
> >
> > Thanks for pointing this out! I was not aware of this.
> > I have tried to understand how the PRP0001 is meant to be used, but could not
> > find sufficient documentation. The best document I could find is
> > Documentation/firmware-guide/acpi/enumeration.rst in the Linux kernel, and
> > as far as I can tell the constraint that you mention is also not described
> > there.
> >
> > Do you know any other resources regarding PRP0001, e.g. some kind of
> > speficiation?
>
> I guess the best one is to ask somebody from UEFI Forum / ASWG. PRP is
> a PNP ID for UEFI Forum.
Basically last message in [3] from Rafael mentions his view on
PRP0001. I guess there is still no document, although as I noticed the
PRP prefix become official in a mean time.
> > If PRP0001 is only for debugging, then I must also have misunderstood the
> > Linux "device-property" API (define in include/linux/property.h).
>
> Not exactly.
>
> > There are some presentations available on the internet, e.g. [1], that I
> > understand like PRP0001 + "device-property" API provide a way do access data
> > from either Devicetree or ACPI, depending on what kind of platform you are on.
>
> No, these are not hard linked to each other (the relation is that
> PRP0001 is a way to enumerate devices, which don't have dedicated ACPI
> _HID, by using compatible property [1]). The _DSD per se (i.o.w.
> device properties implementation in ACPI) is a different story [2].
>
> And I put [3] here, interesting to read. However, at that time I was
> quite far from this topic.
>
> [1]: https://www.kernel.org/doc/html/latest/firmware-guide/acpi/enumeration.html#device-tree-namespace-link-device-id
> [2]: https://uefi.org/sites/default/files/resources/_DSD-implementation-guide-toplevel-1_2-3.htm.
> [3]: https://patchwork.kernel.org/patch/7004241/
>
> > [1] https://elinux.org/images/2/2d/Device_tree_acpi_compatibility-david_woodhouse-kernel_recipes_2015.pdf
>
> --
> With Best Regards,
> Andy Shevchenko
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply [flat|nested] 86+ messages in thread
* Antwort: Re: Re: [PATCH v3 13/29] dts: Add a binding for hid-over-i2c
2020-04-08 20:40 ` Andy Shevchenko
2020-04-08 20:49 ` Andy Shevchenko
@ 2020-04-15 14:00 ` Wolfgang Wallner
2020-04-15 14:25 ` Andy Shevchenko
2020-04-15 14:57 ` Antwort: Re: Re: " Wolfgang Wallner
1 sibling, 2 replies; 86+ messages in thread
From: Wolfgang Wallner @ 2020-04-15 14:00 UTC (permalink / raw)
To: u-boot
Hi Andy,
-----"Andy Shevchenko" <andy.shevchenko@gmail.com> schrieb: -----
> Betreff: Re: Re: [PATCH v3 13/29] dts: Add a binding for hid-over-i2c
>
> On Wed, Apr 8, 2020 at 11:40 PM Andy Shevchenko
> <andy.shevchenko@gmail.com> wrote:
> > On Wed, Apr 8, 2020 at 10:39 PM Wolfgang Wallner
> > <wolfgang.wallner@br-automation.com> wrote:
> > > > On Tue, Apr 07, 2020 at 08:58:13PM -0600, Simon Glass wrote:
> > > > > On Tue, 31 Mar 2020 at 13:25, Wolfgang Wallner
> > > > > <wolfgang.wallner@br-automation.com> wrote:
> > > > > > >An: u-boot at lists.denx.de
> > > > > > >Von: "Simon Glass" <sjg@chromium.org>
> > > > > > >Datum: 31.03.2020 01:14
> > > > > > >Kopie: "Andy Shevchenko" <andriy.shevchenko@linux.intel.com>,
> > > > > > >"Wolfgang Wallner" <wolfgang.wallner@br-automation.com>, "Leif
> > > > > > >Lindholm" <leif@nuviainc.com>, "Simon Glass" <sjg@chromium.org>
> > > > > > >Betreff: [PATCH v3 14/29] acpi: Add a binding for ACPI settings in
> > > > > > >the device tree
> > > >
> > > > > > The _DSD-method for "PRP0001"-devices in ACPI allows to use Devicetree
> > > > > > properties inside ACPI, especially it allows to re-use Devicetree's
> > > > > > "compatible"-property. But this is for a different use case (using Devicetree
> > > > > > properties inside ACPI, not add ACPI properties in Devicetree).
> > > >
> > > > Before we are going further with this here is a BIG CAVEAT.
> > > >
> > > > PRP0001 MUST NOT be used in production devices.
> > > >
> > > > This has been derived solely for debugging / pre-production testing / etc
> > > > purposes. The real devices must have an official ACPI _HID.
> > >
> > > Thanks for pointing this out! I was not aware of this.
> > > I have tried to understand how the PRP0001 is meant to be used, but could not
> > > find sufficient documentation. The best document I could find is
> > > Documentation/firmware-guide/acpi/enumeration.rst in the Linux kernel, and
> > > as far as I can tell the constraint that you mention is also not described
> > > there.
> > >
> > > Do you know any other resources regarding PRP0001, e.g. some kind of
> > > speficiation?
> >
> > I guess the best one is to ask somebody from UEFI Forum / ASWG. PRP is
> > a PNP ID for UEFI Forum.
>
> Basically last message in [3] from Rafael mentions his view on
> PRP0001. I guess there is still no document, although as I noticed the
> PRP prefix become official in a mean time.
Thanks for the references. I have read them carefully, especially the thread
in [3].
My understanding up to now was based on presentations by David Woodhouse,
so it matches with his viewpoint in the thread at [3]. And as far as I can
tell Rafael Wysocki agrees with him in this thread.
What I could not find in either of the references is that PRP0001 is only
for debugging, I only know about this constraint from your mail. Could you
point me to any source for this?
> > > If PRP0001 is only for debugging, then I must also have misunderstood the
> > > Linux "device-property" API (define in include/linux/property.h).
> >
> > Not exactly.
> >
> > > There are some presentations available on the internet, e.g. [1], that I
> > > understand like PRP0001 + "device-property" API provide a way do access data
> > > from either Devicetree or ACPI, depending on what kind of platform you are on.
> >
> > No, these are not hard linked to each other (the relation is that
> > PRP0001 is a way to enumerate devices, which don't have dedicated ACPI
> > _HID, by using compatible property [1]). The _DSD per se (i.o.w.
> > device properties implementation in ACPI) is a different story [2].
> >
> > And I put [3] here, interesting to read. However, at that time I was
> > quite far from this topic.
> >
> > [1]: https://www.kernel.org/doc/html/latest/firmware-guide/acpi/enumeration.html#device-tree-namespace-link-device-id
> > [2]: https://uefi.org/sites/default/files/resources/_DSD-implementation-guide-toplevel-1_2-3.htm.
> > [3]: https://patchwork.kernel.org/patch/7004241/
> >
> > > [1] https://elinux.org/images/2/2d/Device_tree_acpi_compatibility-david_woodhouse-kernel_recipes_2015.pdf
> >
> > --
> > With Best Regards,
> > Andy Shevchenko
regards, Wolfgang
PS: I only realized now that I had mixed up the email-subject in my first
reply and now the complete thread is under the wrong topic. Sorry for that.
^ permalink raw reply [flat|nested] 86+ messages in thread
* [PATCH v3 13/29] dts: Add a binding for hid-over-i2c
2020-04-15 14:00 ` Antwort: Re: " Wolfgang Wallner
@ 2020-04-15 14:25 ` Andy Shevchenko
2020-04-15 14:57 ` Antwort: Re: Re: " Wolfgang Wallner
1 sibling, 0 replies; 86+ messages in thread
From: Andy Shevchenko @ 2020-04-15 14:25 UTC (permalink / raw)
To: u-boot
On Wed, Apr 15, 2020 at 5:00 PM Wolfgang Wallner
<wolfgang.wallner@br-automation.com> wrote:
> -----"Andy Shevchenko" <andy.shevchenko@gmail.com> schrieb: -----
> > Betreff: Re: Re: [PATCH v3 13/29] dts: Add a binding for hid-over-i2c
> >
> > On Wed, Apr 8, 2020 at 11:40 PM Andy Shevchenko
> > <andy.shevchenko@gmail.com> wrote:
> > > On Wed, Apr 8, 2020 at 10:39 PM Wolfgang Wallner
> > > <wolfgang.wallner@br-automation.com> wrote:
> > > > > On Tue, Apr 07, 2020 at 08:58:13PM -0600, Simon Glass wrote:
> > > > > > On Tue, 31 Mar 2020 at 13:25, Wolfgang Wallner
> > > > > > <wolfgang.wallner@br-automation.com> wrote:
> > > > > > > >An: u-boot at lists.denx.de
> > > > > > > >Von: "Simon Glass" <sjg@chromium.org>
> > > > > > > >Datum: 31.03.2020 01:14
> > > > > > > >Kopie: "Andy Shevchenko" <andriy.shevchenko@linux.intel.com>,
> > > > > > > >"Wolfgang Wallner" <wolfgang.wallner@br-automation.com>, "Leif
> > > > > > > >Lindholm" <leif@nuviainc.com>, "Simon Glass" <sjg@chromium.org>
> > > > > > > >Betreff: [PATCH v3 14/29] acpi: Add a binding for ACPI settings in
> > > > > > > >the device tree
> > > > >
> > > > > > > The _DSD-method for "PRP0001"-devices in ACPI allows to use Devicetree
> > > > > > > properties inside ACPI, especially it allows to re-use Devicetree's
> > > > > > > "compatible"-property. But this is for a different use case (using Devicetree
> > > > > > > properties inside ACPI, not add ACPI properties in Devicetree).
> > > > >
> > > > > Before we are going further with this here is a BIG CAVEAT.
> > > > >
> > > > > PRP0001 MUST NOT be used in production devices.
> > > > >
> > > > > This has been derived solely for debugging / pre-production testing / etc
> > > > > purposes. The real devices must have an official ACPI _HID.
> > > >
> > > > Thanks for pointing this out! I was not aware of this.
> > > > I have tried to understand how the PRP0001 is meant to be used, but could not
> > > > find sufficient documentation. The best document I could find is
> > > > Documentation/firmware-guide/acpi/enumeration.rst in the Linux kernel, and
> > > > as far as I can tell the constraint that you mention is also not described
> > > > there.
> > > >
> > > > Do you know any other resources regarding PRP0001, e.g. some kind of
> > > > speficiation?
> > >
> > > I guess the best one is to ask somebody from UEFI Forum / ASWG. PRP is
> > > a PNP ID for UEFI Forum.
> >
> > Basically last message in [3] from Rafael mentions his view on
> > PRP0001. I guess there is still no document, although as I noticed the
> > PRP prefix become official in a mean time.
>
> Thanks for the references. I have read them carefully, especially the thread
> in [3].
>
> My understanding up to now was based on presentations by David Woodhouse,
> so it matches with his viewpoint in the thread at [3]. And as far as I can
> tell Rafael Wysocki agrees with him in this thread.
>
> What I could not find in either of the references is that PRP0001 is only
> for debugging, I only know about this constraint from your mail. Could you
> point me to any source for this?
From [3], Rafael said:
"Let alone the fact that PRP0001 is actually quite useful at the
prototyping stage when it is premature to allocate a new device ID just
yet. Taking that to the extreme, if someone whittles a board in his or
her garage and wants to use it to drive their homemade grass watering
system, having to invent a new device ID and put it into the existing
driver that otherwise doesn't require any modifications is ... you know
what I mean."
It implies that the process should have included the allocation of an
official ACPI ID.
You always can ask ASWG for the clarification. Maybe I learn something
new about PRP0001 :-)
> > > > If PRP0001 is only for debugging, then I must also have misunderstood the
> > > > Linux "device-property" API (define in include/linux/property.h).
> > >
> > > Not exactly.
> > >
> > > > There are some presentations available on the internet, e.g. [1], that I
> > > > understand like PRP0001 + "device-property" API provide a way do access data
> > > > from either Devicetree or ACPI, depending on what kind of platform you are on.
> > >
> > > No, these are not hard linked to each other (the relation is that
> > > PRP0001 is a way to enumerate devices, which don't have dedicated ACPI
> > > _HID, by using compatible property [1]). The _DSD per se (i.o.w.
> > > device properties implementation in ACPI) is a different story [2].
> > >
> > > And I put [3] here, interesting to read. However, at that time I was
> > > quite far from this topic.
> > >
> > > [1]: https://www.kernel.org/doc/html/latest/firmware-guide/acpi/enumeration.html#device-tree-namespace-link-device-id
> > > [2]: https://uefi.org/sites/default/files/resources/_DSD-implementation-guide-toplevel-1_2-3.htm.
> > > [3]: https://patchwork.kernel.org/patch/7004241/
> > >
> > > > [1] https://elinux.org/images/2/2d/Device_tree_acpi_compatibility-david_woodhouse-kernel_recipes_2015.pdf
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply [flat|nested] 86+ messages in thread
* Antwort: Re: Re: Re: [PATCH v3 13/29] dts: Add a binding for hid-over-i2c
2020-04-15 14:00 ` Antwort: Re: " Wolfgang Wallner
2020-04-15 14:25 ` Andy Shevchenko
@ 2020-04-15 14:57 ` Wolfgang Wallner
2020-04-15 15:15 ` Andy Shevchenko
1 sibling, 1 reply; 86+ messages in thread
From: Wolfgang Wallner @ 2020-04-15 14:57 UTC (permalink / raw)
To: u-boot
Hi Andy,
-----"Andy Shevchenko" <andy.shevchenko@gmail.com> schrieb: -----
> On Wed, Apr 15, 2020 at 5:00 PM Wolfgang Wallner
> <wolfgang.wallner@br-automation.com> wrote:
> > -----"Andy Shevchenko" <andy.shevchenko@gmail.com> schrieb: -----
> > > Betreff: Re: Re: [PATCH v3 13/29] dts: Add a binding for hid-over-i2c
> > >
> > > On Wed, Apr 8, 2020 at 11:40 PM Andy Shevchenko
> > > <andy.shevchenko@gmail.com> wrote:
> > > > On Wed, Apr 8, 2020 at 10:39 PM Wolfgang Wallner
> > > > <wolfgang.wallner@br-automation.com> wrote:
> > > > > > On Tue, Apr 07, 2020 at 08:58:13PM -0600, Simon Glass wrote:
> > > > > > > On Tue, 31 Mar 2020 at 13:25, Wolfgang Wallner
> > > > > > > <wolfgang.wallner@br-automation.com> wrote:
> > > > > > > > >An: u-boot at lists.denx.de
> > > > > > > > >Von: "Simon Glass" <sjg@chromium.org>
> > > > > > > > >Datum: 31.03.2020 01:14
> > > > > > > > >Kopie: "Andy Shevchenko" <andriy.shevchenko@linux.intel.com>,
> > > > > > > > >"Wolfgang Wallner" <wolfgang.wallner@br-automation.com>, "Leif
> > > > > > > > >Lindholm" <leif@nuviainc.com>, "Simon Glass" <sjg@chromium.org>
> > > > > > > > >Betreff: [PATCH v3 14/29] acpi: Add a binding for ACPI settings in
> > > > > > > > >the device tree
> > > > > >
> > > > > > > > The _DSD-method for "PRP0001"-devices in ACPI allows to use Devicetree
> > > > > > > > properties inside ACPI, especially it allows to re-use Devicetree's
> > > > > > > > "compatible"-property. But this is for a different use case (using Devicetree
> > > > > > > > properties inside ACPI, not add ACPI properties in Devicetree).
> > > > > >
> > > > > > Before we are going further with this here is a BIG CAVEAT.
> > > > > >
> > > > > > PRP0001 MUST NOT be used in production devices.
> > > > > >
> > > > > > This has been derived solely for debugging / pre-production testing / etc
> > > > > > purposes. The real devices must have an official ACPI _HID.
> > > > >
> > > > > Thanks for pointing this out! I was not aware of this.
> > > > > I have tried to understand how the PRP0001 is meant to be used, but could not
> > > > > find sufficient documentation. The best document I could find is
> > > > > Documentation/firmware-guide/acpi/enumeration.rst in the Linux kernel, and
> > > > > as far as I can tell the constraint that you mention is also not described
> > > > > there.
> > > > >
> > > > > Do you know any other resources regarding PRP0001, e.g. some kind of
> > > > > speficiation?
> > > >
> > > > I guess the best one is to ask somebody from UEFI Forum / ASWG. PRP is
> > > > a PNP ID for UEFI Forum.
> > >
> > > Basically last message in [3] from Rafael mentions his view on
> > > PRP0001. I guess there is still no document, although as I noticed the
> > > PRP prefix become official in a mean time.
> >
> > Thanks for the references. I have read them carefully, especially the thread
> > in [3].
> >
> > My understanding up to now was based on presentations by David Woodhouse,
> > so it matches with his viewpoint in the thread at [3]. And as far as I can
> > tell Rafael Wysocki agrees with him in this thread.
> >
> > What I could not find in either of the references is that PRP0001 is only
> > for debugging, I only know about this constraint from your mail. Could you
> > point me to any source for this?
>
> From [3], Rafael said:
> "Let alone the fact that PRP0001 is actually quite useful at the
> prototyping stage when it is premature to allocate a new device ID just
> yet. Taking that to the extreme, if someone whittles a board in his or
> her garage and wants to use it to drive their homemade grass watering
> system, having to invent a new device ID and put it into the existing
> driver that otherwise doesn't require any modifications is ... you know
> what I mean."
>
> It implies that the process should have included the allocation of an
> official ACPI ID.
I understand the quoted paragraph differently. In the paragraphs above Rafael
argues that PRP0001 is useful, as with PRP0001 we can avoid registering
redundant ACPI IDs. In the quoted paragraph he then gives another example
where PRP0001 is also useful: for debugging.
But I don't understand it in a way that PRP0001 would be limited to only
debugging.
A few posts before in [4] he explains in more detail, and I think it matches
my understanding of the last post, especially the following sentence:
"It would be a failure if people had to write separate drivers for
ACPI-based and DT-based platforms to handle the same hardware, at least
at the leaf driver level."
[4] https://patchwork.kernel.org/comment/15339311/
> You always can ask ASWG for the clarification. Maybe I learn something
> new about PRP0001 :-)
I had no interaction with ASWG before so I'm not sure what the process is,
but I will look it up.
> > > > > If PRP0001 is only for debugging, then I must also have misunderstood the
> > > > > Linux "device-property" API (define in include/linux/property.h).
> > > >
> > > > Not exactly.
> > > >
> > > > > There are some presentations available on the internet, e.g. [1], that I
> > > > > understand like PRP0001 + "device-property" API provide a way do access data
> > > > > from either Devicetree or ACPI, depending on what kind of platform you are on.
> > > >
> > > > No, these are not hard linked to each other (the relation is that
> > > > PRP0001 is a way to enumerate devices, which don't have dedicated ACPI
> > > > _HID, by using compatible property [1]). The _DSD per se (i.o.w.
> > > > device properties implementation in ACPI) is a different story [2].
> > > >
> > > > And I put [3] here, interesting to read. However, at that time I was
> > > > quite far from this topic.
> > > >
> > > > [1]: https://www.kernel.org/doc/html/latest/firmware-guide/acpi/enumeration.html#device-tree-namespace-link-device-id
> > > > [2]: https://uefi.org/sites/default/files/resources/_DSD-implementation-guide-toplevel-1_2-3.htm.
> > > > [3]: https://patchwork.kernel.org/patch/7004241/
> > > >
> > > > > [1] https://elinux.org/images/2/2d/Device_tree_acpi_compatibility-david_woodhouse-kernel_recipes_2015.pdf
regards, Wolfgang
^ permalink raw reply [flat|nested] 86+ messages in thread
* Antwort: Re: Re: Re: [PATCH v3 13/29] dts: Add a binding for hid-over-i2c
2020-04-15 14:57 ` Antwort: Re: Re: " Wolfgang Wallner
@ 2020-04-15 15:15 ` Andy Shevchenko
2020-04-15 15:17 ` Andy Shevchenko
0 siblings, 1 reply; 86+ messages in thread
From: Andy Shevchenko @ 2020-04-15 15:15 UTC (permalink / raw)
To: u-boot
On Wed, Apr 15, 2020 at 04:57:33PM +0200, Wolfgang Wallner wrote:
> > On Wed, Apr 15, 2020 at 5:00 PM Wolfgang Wallner
> > <wolfgang.wallner@br-automation.com> wrote:
> > > -----"Andy Shevchenko" <andy.shevchenko@gmail.com> schrieb: -----
> > > > Betreff: Re: Re: [PATCH v3 13/29] dts: Add a binding for hid-over-i2c
> > > >
> > > > On Wed, Apr 8, 2020 at 11:40 PM Andy Shevchenko
> > > > <andy.shevchenko@gmail.com> wrote:
> > > > > On Wed, Apr 8, 2020 at 10:39 PM Wolfgang Wallner
> > > > > <wolfgang.wallner@br-automation.com> wrote:
> > > > > > > On Tue, Apr 07, 2020 at 08:58:13PM -0600, Simon Glass wrote:
> > > > > > > > On Tue, 31 Mar 2020 at 13:25, Wolfgang Wallner
> > > > > > > > <wolfgang.wallner@br-automation.com> wrote:
> > > > > > > > > >An: u-boot at lists.denx.de
> > > > > > > > > >Von: "Simon Glass" <sjg@chromium.org>
> > > > > > > > > >Datum: 31.03.2020 01:14
> > > > > > > > > >Kopie: "Andy Shevchenko" <andriy.shevchenko@linux.intel.com>,
> > > > > > > > > >"Wolfgang Wallner" <wolfgang.wallner@br-automation.com>, "Leif
> > > > > > > > > >Lindholm" <leif@nuviainc.com>, "Simon Glass" <sjg@chromium.org>
> > > > > > > > > >Betreff: [PATCH v3 14/29] acpi: Add a binding for ACPI settings in
> > > > > > > > > >the device tree
> > > > > > >
> > > > > > > > > The _DSD-method for "PRP0001"-devices in ACPI allows to use Devicetree
> > > > > > > > > properties inside ACPI, especially it allows to re-use Devicetree's
> > > > > > > > > "compatible"-property. But this is for a different use case (using Devicetree
> > > > > > > > > properties inside ACPI, not add ACPI properties in Devicetree).
> > > > > > >
> > > > > > > Before we are going further with this here is a BIG CAVEAT.
> > > > > > >
> > > > > > > PRP0001 MUST NOT be used in production devices.
> > > > > > >
> > > > > > > This has been derived solely for debugging / pre-production testing / etc
> > > > > > > purposes. The real devices must have an official ACPI _HID.
> > > > > >
> > > > > > Thanks for pointing this out! I was not aware of this.
> > > > > > I have tried to understand how the PRP0001 is meant to be used, but could not
> > > > > > find sufficient documentation. The best document I could find is
> > > > > > Documentation/firmware-guide/acpi/enumeration.rst in the Linux kernel, and
> > > > > > as far as I can tell the constraint that you mention is also not described
> > > > > > there.
> > > > > >
> > > > > > Do you know any other resources regarding PRP0001, e.g. some kind of
> > > > > > speficiation?
> > > > >
> > > > > I guess the best one is to ask somebody from UEFI Forum / ASWG. PRP is
> > > > > a PNP ID for UEFI Forum.
> > > >
> > > > Basically last message in [3] from Rafael mentions his view on
> > > > PRP0001. I guess there is still no document, although as I noticed the
> > > > PRP prefix become official in a mean time.
> > >
> > > Thanks for the references. I have read them carefully, especially the thread
> > > in [3].
> > >
> > > My understanding up to now was based on presentations by David Woodhouse,
> > > so it matches with his viewpoint in the thread at [3]. And as far as I can
> > > tell Rafael Wysocki agrees with him in this thread.
> > >
> > > What I could not find in either of the references is that PRP0001 is only
> > > for debugging, I only know about this constraint from your mail. Could you
> > > point me to any source for this?
> >
> > From [3], Rafael said:
> > "Let alone the fact that PRP0001 is actually quite useful at the
> > prototyping stage when it is premature to allocate a new device ID just
> > yet. Taking that to the extreme, if someone whittles a board in his or
> > her garage and wants to use it to drive their homemade grass watering
> > system, having to invent a new device ID and put it into the existing
> > driver that otherwise doesn't require any modifications is ... you know
> > what I mean."
> >
> > It implies that the process should have included the allocation of an
> > official ACPI ID.
>
> I understand the quoted paragraph differently. In the paragraphs above Rafael
> argues that PRP0001 is useful, as with PRP0001 we can avoid registering
> redundant ACPI IDs. In the quoted paragraph he then gives another example
> where PRP0001 is also useful: for debugging.
> But I don't understand it in a way that PRP0001 would be limited to only
> debugging.
>
> A few posts before in [4] he explains in more detail, and I think it matches
> my understanding of the last post, especially the following sentence:
>
> "It would be a failure if people had to write separate drivers for
> ACPI-based and DT-based platforms to handle the same hardware, at least
> at the leaf driver level."
>
Maybe better to ask him directly?
> [4] https://patchwork.kernel.org/comment/15339311/
>
> > You always can ask ASWG for the clarification. Maybe I learn something
> > new about PRP0001 :-)
>
> I had no interaction with ASWG before so I'm not sure what the process is,
> but I will look it up.
>
> > > > > > If PRP0001 is only for debugging, then I must also have misunderstood the
> > > > > > Linux "device-property" API (define in include/linux/property.h).
> > > > >
> > > > > Not exactly.
> > > > >
> > > > > > There are some presentations available on the internet, e.g. [1], that I
> > > > > > understand like PRP0001 + "device-property" API provide a way do access data
> > > > > > from either Devicetree or ACPI, depending on what kind of platform you are on.
> > > > >
> > > > > No, these are not hard linked to each other (the relation is that
> > > > > PRP0001 is a way to enumerate devices, which don't have dedicated ACPI
> > > > > _HID, by using compatible property [1]). The _DSD per se (i.o.w.
> > > > > device properties implementation in ACPI) is a different story [2].
> > > > >
> > > > > And I put [3] here, interesting to read. However, at that time I was
> > > > > quite far from this topic.
> > > > >
> > > > > [1]: https://www.kernel.org/doc/html/latest/firmware-guide/acpi/enumeration.html#device-tree-namespace-link-device-id
> > > > > [2]: https://uefi.org/sites/default/files/resources/_DSD-implementation-guide-toplevel-1_2-3.htm.
> > > > > [3]: https://patchwork.kernel.org/patch/7004241/
> > > > >
> > > > > > [1] https://elinux.org/images/2/2d/Device_tree_acpi_compatibility-david_woodhouse-kernel_recipes_2015.pdf
>
> regards, Wolfgang
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply [flat|nested] 86+ messages in thread
* Antwort: Re: Re: Re: [PATCH v3 13/29] dts: Add a binding for hid-over-i2c
2020-04-15 15:15 ` Andy Shevchenko
@ 2020-04-15 15:17 ` Andy Shevchenko
0 siblings, 0 replies; 86+ messages in thread
From: Andy Shevchenko @ 2020-04-15 15:17 UTC (permalink / raw)
To: u-boot
On Wed, Apr 15, 2020 at 06:15:39PM +0300, Andy Shevchenko wrote:
> On Wed, Apr 15, 2020 at 04:57:33PM +0200, Wolfgang Wallner wrote:
> > > On Wed, Apr 15, 2020 at 5:00 PM Wolfgang Wallner
> > > <wolfgang.wallner@br-automation.com> wrote:
> > > > -----"Andy Shevchenko" <andy.shevchenko@gmail.com> schrieb: -----
> > > > > Betreff: Re: Re: [PATCH v3 13/29] dts: Add a binding for hid-over-i2c
> > > > >
> > > > > On Wed, Apr 8, 2020 at 11:40 PM Andy Shevchenko
> > > > > <andy.shevchenko@gmail.com> wrote:
> > > > > > On Wed, Apr 8, 2020 at 10:39 PM Wolfgang Wallner
> > > > > > <wolfgang.wallner@br-automation.com> wrote:
> > > > > > > > On Tue, Apr 07, 2020 at 08:58:13PM -0600, Simon Glass wrote:
> > > > > > > > > On Tue, 31 Mar 2020 at 13:25, Wolfgang Wallner
> > > > > > > > > <wolfgang.wallner@br-automation.com> wrote:
> > > > > > > > > > >An: u-boot at lists.denx.de
> > > > > > > > > > >Von: "Simon Glass" <sjg@chromium.org>
> > > > > > > > > > >Datum: 31.03.2020 01:14
> > > > > > > > > > >Kopie: "Andy Shevchenko" <andriy.shevchenko@linux.intel.com>,
> > > > > > > > > > >"Wolfgang Wallner" <wolfgang.wallner@br-automation.com>, "Leif
> > > > > > > > > > >Lindholm" <leif@nuviainc.com>, "Simon Glass" <sjg@chromium.org>
> > > > > > > > > > >Betreff: [PATCH v3 14/29] acpi: Add a binding for ACPI settings in
> > > > > > > > > > >the device tree
> > > > > > > >
> > > > > > > > > > The _DSD-method for "PRP0001"-devices in ACPI allows to use Devicetree
> > > > > > > > > > properties inside ACPI, especially it allows to re-use Devicetree's
> > > > > > > > > > "compatible"-property. But this is for a different use case (using Devicetree
> > > > > > > > > > properties inside ACPI, not add ACPI properties in Devicetree).
> > > > > > > >
> > > > > > > > Before we are going further with this here is a BIG CAVEAT.
> > > > > > > >
> > > > > > > > PRP0001 MUST NOT be used in production devices.
> > > > > > > >
> > > > > > > > This has been derived solely for debugging / pre-production testing / etc
> > > > > > > > purposes. The real devices must have an official ACPI _HID.
> > > > > > >
> > > > > > > Thanks for pointing this out! I was not aware of this.
> > > > > > > I have tried to understand how the PRP0001 is meant to be used, but could not
> > > > > > > find sufficient documentation. The best document I could find is
> > > > > > > Documentation/firmware-guide/acpi/enumeration.rst in the Linux kernel, and
> > > > > > > as far as I can tell the constraint that you mention is also not described
> > > > > > > there.
> > > > > > >
> > > > > > > Do you know any other resources regarding PRP0001, e.g. some kind of
> > > > > > > speficiation?
> > > > > >
> > > > > > I guess the best one is to ask somebody from UEFI Forum / ASWG. PRP is
> > > > > > a PNP ID for UEFI Forum.
> > > > >
> > > > > Basically last message in [3] from Rafael mentions his view on
> > > > > PRP0001. I guess there is still no document, although as I noticed the
> > > > > PRP prefix become official in a mean time.
> > > >
> > > > Thanks for the references. I have read them carefully, especially the thread
> > > > in [3].
> > > >
> > > > My understanding up to now was based on presentations by David Woodhouse,
> > > > so it matches with his viewpoint in the thread at [3]. And as far as I can
> > > > tell Rafael Wysocki agrees with him in this thread.
> > > >
> > > > What I could not find in either of the references is that PRP0001 is only
> > > > for debugging, I only know about this constraint from your mail. Could you
> > > > point me to any source for this?
> > >
> > > From [3], Rafael said:
> > > "Let alone the fact that PRP0001 is actually quite useful at the
> > > prototyping stage when it is premature to allocate a new device ID just
> > > yet. Taking that to the extreme, if someone whittles a board in his or
> > > her garage and wants to use it to drive their homemade grass watering
> > > system, having to invent a new device ID and put it into the existing
> > > driver that otherwise doesn't require any modifications is ... you know
> > > what I mean."
> > >
> > > It implies that the process should have included the allocation of an
> > > official ACPI ID.
> >
> > I understand the quoted paragraph differently. In the paragraphs above Rafael
> > argues that PRP0001 is useful, as with PRP0001 we can avoid registering
> > redundant ACPI IDs. In the quoted paragraph he then gives another example
> > where PRP0001 is also useful: for debugging.
> > But I don't understand it in a way that PRP0001 would be limited to only
> > debugging.
> >
> > A few posts before in [4] he explains in more detail, and I think it matches
> > my understanding of the last post, especially the following sentence:
> >
> > "It would be a failure if people had to write separate drivers for
> > ACPI-based and DT-based platforms to handle the same hardware, at least
> > at the leaf driver level."
> >
>
> Maybe better to ask him directly?
I guess here is a root of misunderstanding, i.e. PRP0001 as _HID() vs. Device
Properties as _DSD() method.
I think you quoted the thoughts WRT latter, and not related to the _HID() part!
> > [4] https://patchwork.kernel.org/comment/15339311/
> >
> > > You always can ask ASWG for the clarification. Maybe I learn something
> > > new about PRP0001 :-)
> >
> > I had no interaction with ASWG before so I'm not sure what the process is,
> > but I will look it up.
> >
> > > > > > > If PRP0001 is only for debugging, then I must also have misunderstood the
> > > > > > > Linux "device-property" API (define in include/linux/property.h).
> > > > > >
> > > > > > Not exactly.
> > > > > >
> > > > > > > There are some presentations available on the internet, e.g. [1], that I
> > > > > > > understand like PRP0001 + "device-property" API provide a way do access data
> > > > > > > from either Devicetree or ACPI, depending on what kind of platform you are on.
> > > > > >
> > > > > > No, these are not hard linked to each other (the relation is that
> > > > > > PRP0001 is a way to enumerate devices, which don't have dedicated ACPI
> > > > > > _HID, by using compatible property [1]). The _DSD per se (i.o.w.
> > > > > > device properties implementation in ACPI) is a different story [2].
> > > > > >
> > > > > > And I put [3] here, interesting to read. However, at that time I was
> > > > > > quite far from this topic.
> > > > > >
> > > > > > [1]: https://www.kernel.org/doc/html/latest/firmware-guide/acpi/enumeration.html#device-tree-namespace-link-device-id
> > > > > > [2]: https://uefi.org/sites/default/files/resources/_DSD-implementation-guide-toplevel-1_2-3.htm.
> > > > > > [3]: https://patchwork.kernel.org/patch/7004241/
> > > > > >
> > > > > > > [1] https://elinux.org/images/2/2d/Device_tree_acpi_compatibility-david_woodhouse-kernel_recipes_2015.pdf
> >
> > regards, Wolfgang
>
> --
> With Best Regards,
> Andy Shevchenko
>
>
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply [flat|nested] 86+ messages in thread
* Antwort: [PATCH v3 19/29] acpi: Add a central location for table version numbers
2020-03-30 23:12 [PATCH v3 00/29] dm: Add programmatic generation of ACPI tables (part A) Simon Glass
` (32 preceding siblings ...)
2020-03-31 19:25 ` Antwort: [PATCH v3 13/29] dts: Add a binding for hid-over-i2c Wolfgang Wallner
@ 2020-03-31 19:30 ` Wolfgang Wallner
2020-04-08 2:58 ` Simon Glass
2020-03-31 19:34 ` Antwort: [PATCH v3 20/29] acpi: Add support for DMAR Wolfgang Wallner
` (2 subsequent siblings)
36 siblings, 1 reply; 86+ messages in thread
From: Wolfgang Wallner @ 2020-03-31 19:30 UTC (permalink / raw)
To: u-boot
Hi Simon,
-----"Simon Glass" <sjg@chromium.org> schrieb: -----
>Betreff: [PATCH v3 19/29] acpi: Add a central location for table
>version numbers
>
>Each ACPI table has its own version number. Add the version numbers
>in a
>single function so we can keep them consistent and easily see what
>versions are supported.
>
>Start a new acpi_table file in a generic directory to house this
>function.
>We can move things over to this file from x86 as needed.
>
>Signed-off-by: Simon Glass <sjg@chromium.org>
>---
>
>Changes in v3:
>- Fix a few typos
>- Fix file comment for acpi_table.c
>
>Changes in v2:
>- Move the sandbox acpi_table.h header file to an earlier patch
>- Use #defines for MADT and MCFG version numbers
>
> include/acpi/acpi_table.h | 61
>+++++++++++++++++++++++++++++++++++++++
> lib/Makefile | 1 +
> lib/acpi/Makefile | 4 +++
> lib/acpi/acpi_table.c | 60
>++++++++++++++++++++++++++++++++++++++
> test/dm/acpi.c | 14 +++++++++
> 5 files changed, 140 insertions(+)
> create mode 100644 lib/acpi/Makefile
> create mode 100644 lib/acpi/acpi_table.c
>
>diff --git a/include/acpi/acpi_table.h b/include/acpi/acpi_table.h
>index dd748958136..ccf6fa04dbe 100644
>--- a/include/acpi/acpi_table.h
>+++ b/include/acpi/acpi_table.h
>@@ -202,6 +202,26 @@ struct __packed acpi_fadt {
> struct acpi_gen_regaddr x_gpe1_blk;
> };
>
[snip]
> #include <asm/acpi_table.h>
>diff --git a/lib/Makefile b/lib/Makefile
>index 15259d0473c..f737eb559fc 100644
>--- a/lib/Makefile
>+++ b/lib/Makefile
>@@ -5,6 +5,7 @@
>
> ifndef CONFIG_SPL_BUILD
>
>+obj-$(CONFIG_$(SPL_)ACPIGEN) += acpi/
Could you please help me understand why $(SPL_) is used here?
You have mentioned in your answer of the v2 patch explicitly that you should
use $SPL_ here and have changed the patch accordingly in v3, so I trust that
it makes sense. But I fail to understand how this works. The newly added line
is within "ifndef CONFIG_SPL_BUILD", in which case $SPL_ should alwys be empty
anyway. At least that is how I understood the assigment to SPL_ in Makefile.spl.
> obj-$(CONFIG_EFI) += efi/
> obj-$(CONFIG_EFI_LOADER) += efi_driver/
> obj-$(CONFIG_EFI_LOADER) += efi_loader/
[snip]
Reviewed-by: Wolfgang Wallner <wolfgang.wallner@br-automation.com>
^ permalink raw reply [flat|nested] 86+ messages in thread* [PATCH v3 19/29] acpi: Add a central location for table version numbers
2020-03-31 19:30 ` Antwort: [PATCH v3 19/29] acpi: Add a central location for table version numbers Wolfgang Wallner
@ 2020-04-08 2:58 ` Simon Glass
0 siblings, 0 replies; 86+ messages in thread
From: Simon Glass @ 2020-04-08 2:58 UTC (permalink / raw)
To: u-boot
Hi Wolfgang,
On Tue, 31 Mar 2020 at 13:30, Wolfgang Wallner
<wolfgang.wallner@br-automation.com> wrote:
>
>
> Hi Simon,
>
> -----"Simon Glass" <sjg@chromium.org> schrieb: -----
>
> >Betreff: [PATCH v3 19/29] acpi: Add a central location for table
> >version numbers
> >
> >Each ACPI table has its own version number. Add the version numbers
> >in a
> >single function so we can keep them consistent and easily see what
> >versions are supported.
> >
> >Start a new acpi_table file in a generic directory to house this
> >function.
> >We can move things over to this file from x86 as needed.
> >
> >Signed-off-by: Simon Glass <sjg@chromium.org>
> >---
> >
> >Changes in v3:
> >- Fix a few typos
> >- Fix file comment for acpi_table.c
> >
> >Changes in v2:
> >- Move the sandbox acpi_table.h header file to an earlier patch
> >- Use #defines for MADT and MCFG version numbers
> >
> > include/acpi/acpi_table.h | 61
> >+++++++++++++++++++++++++++++++++++++++
> > lib/Makefile | 1 +
> > lib/acpi/Makefile | 4 +++
> > lib/acpi/acpi_table.c | 60
> >++++++++++++++++++++++++++++++++++++++
> > test/dm/acpi.c | 14 +++++++++
> > 5 files changed, 140 insertions(+)
> > create mode 100644 lib/acpi/Makefile
> > create mode 100644 lib/acpi/acpi_table.c
> >
> >diff --git a/include/acpi/acpi_table.h b/include/acpi/acpi_table.h
> >index dd748958136..ccf6fa04dbe 100644
> >--- a/include/acpi/acpi_table.h
> >+++ b/include/acpi/acpi_table.h
> >@@ -202,6 +202,26 @@ struct __packed acpi_fadt {
> > struct acpi_gen_regaddr x_gpe1_blk;
> > };
> >
>
> [snip]
>
> > #include <asm/acpi_table.h>
> >diff --git a/lib/Makefile b/lib/Makefile
> >index 15259d0473c..f737eb559fc 100644
> >--- a/lib/Makefile
> >+++ b/lib/Makefile
> >@@ -5,6 +5,7 @@
> >
> > ifndef CONFIG_SPL_BUILD
> >
> >+obj-$(CONFIG_$(SPL_)ACPIGEN) += acpi/
>
> Could you please help me understand why $(SPL_) is used here?
> You have mentioned in your answer of the v2 patch explicitly that you should
> use $SPL_ here and have changed the patch accordingly in v3, so I trust that
> it makes sense. But I fail to understand how this works. The newly added line
> is within "ifndef CONFIG_SPL_BUILD", in which case $SPL_ should alwys be empty
> anyway. At least that is how I understood the assigment to SPL_ in Makefile.spl.
Yes you are right. It is unnecessary. I'll move it down further.
>
> > obj-$(CONFIG_EFI) += efi/
> > obj-$(CONFIG_EFI_LOADER) += efi_driver/
> > obj-$(CONFIG_EFI_LOADER) += efi_loader/
>
> [snip]
>
> Reviewed-by: Wolfgang Wallner <wolfgang.wallner@br-automation.com>
^ permalink raw reply [flat|nested] 86+ messages in thread
* Antwort: [PATCH v3 20/29] acpi: Add support for DMAR
2020-03-30 23:12 [PATCH v3 00/29] dm: Add programmatic generation of ACPI tables (part A) Simon Glass
` (33 preceding siblings ...)
2020-03-31 19:30 ` Antwort: [PATCH v3 19/29] acpi: Add a central location for table version numbers Wolfgang Wallner
@ 2020-03-31 19:34 ` Wolfgang Wallner
2020-04-01 7:39 ` Antwort: [PATCH v3 13/29] dts: Add a binding for hid-over-i2c Wolfgang Wallner
2020-04-06 11:53 ` Antwort: [PATCH v3 21/29] test: Add hexdump.h to the unit test header Wolfgang Wallner
36 siblings, 0 replies; 86+ messages in thread
From: Wolfgang Wallner @ 2020-03-31 19:34 UTC (permalink / raw)
To: u-boot
Hi Simon,
-----"Simon Glass" <sjg@chromium.org> schrieb: -----
>Betreff: [PATCH v3 20/29] acpi: Add support for DMAR
>
>The DMA Remapping Reporting (DMAR) table contains information about
>DMA
>remapping.
>
>Add a version simple version of this table with only the minimum
>fields
>filled out. i.e. no entries.
>
>Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
>Signed-off-by: Simon Glass <sjg@chromium.org>
>---
>
>Changes in v3:
>- Add missing error check in acpi_create_dmar()
>- Drop duplicate assert
>- Fix DMA_ typo
>- Make use of BIT()
>
>Changes in v2:
>- Drop two unnecessary __packed
>- Move __packed to after struct
>
> include/acpi/acpi_table.h | 57
>+++++++++++++++++++++++++++++++++++++++
> lib/acpi/acpi_table.c | 28 +++++++++++++++++++
> test/dm/acpi.c | 13 +++++++++
> 3 files changed, 98 insertions(+)
Reviewed-by: Wolfgang Wallner <wolfgang.wallner@br-automation.com>
^ permalink raw reply [flat|nested] 86+ messages in thread* Antwort: [PATCH v3 13/29] dts: Add a binding for hid-over-i2c
2020-03-30 23:12 [PATCH v3 00/29] dm: Add programmatic generation of ACPI tables (part A) Simon Glass
` (34 preceding siblings ...)
2020-03-31 19:34 ` Antwort: [PATCH v3 20/29] acpi: Add support for DMAR Wolfgang Wallner
@ 2020-04-01 7:39 ` Wolfgang Wallner
2020-04-08 2:57 ` Simon Glass
2020-04-06 11:53 ` Antwort: [PATCH v3 21/29] test: Add hexdump.h to the unit test header Wolfgang Wallner
36 siblings, 1 reply; 86+ messages in thread
From: Wolfgang Wallner @ 2020-04-01 7:39 UTC (permalink / raw)
To: u-boot
Hi Simon,
-----"U-Boot" <u-boot-bounces@lists.denx.de> schrieb: -----
[snip]
>> + - acpi,ddn : Contains the string to use as the _DDN (DOS (Disk
>Operating
>> + System) Device Name)
>> + - acpi,hid : Contains the string to use as the HID (Hardware ID)
>> + identifier _HID
>> + - acpi,probed : Tells U-Boot to add 'linux,probed' to the ACPI
>tables so that
>> + Linux will only load the driver if the device can be detected
>(e.g. on I2C
>> + bus)
>
>Will support for 'linux,probed' be mainlined? Otherwise the
>description
>should IMHO mention that it is an out-of-tree feature.
I have thought some more about this property.
The Chromium discussions [1] mention that "linux,probed" is intended to be
a property in both Devicetree and ACPI, so a Linux kernel could handle the
device in the expected way whether it boots on a Devicetree platform or an
ACPI platform. The proposed "acpi,probed" property would only solve one such
use case (ACPI-based platforms): U-Boot boots, reads "acpi,probed" from
Devicetree, adds "linux,probed" to the ACPI description and hands that to the
Linux kernel.
Why would we not keep the name "linux,probed" for this property? U-Boot could
still do the same Devicetree -> ACPI translation, but the same property could
then also be useful for Devicetree-based platforms.
[snip]
regards, Wolfgang
[1] https://groups.google.com/a/chromium.org/forum/#!msg/chromium-os-reviews/4HTHl78IGHw/oz82uImnBgAJ
^ permalink raw reply [flat|nested] 86+ messages in thread* [PATCH v3 13/29] dts: Add a binding for hid-over-i2c
2020-04-01 7:39 ` Antwort: [PATCH v3 13/29] dts: Add a binding for hid-over-i2c Wolfgang Wallner
@ 2020-04-08 2:57 ` Simon Glass
0 siblings, 0 replies; 86+ messages in thread
From: Simon Glass @ 2020-04-08 2:57 UTC (permalink / raw)
To: u-boot
Hi Wolfgang,
On Wed, 1 Apr 2020 at 01:39, Wolfgang Wallner
<wolfgang.wallner@br-automation.com> wrote:
>
> Hi Simon,
>
> -----"U-Boot" <u-boot-bounces@lists.denx.de> schrieb: -----
>
> [snip]
>
> >> + - acpi,ddn : Contains the string to use as the _DDN (DOS (Disk
> >Operating
> >> + System) Device Name)
> >> + - acpi,hid : Contains the string to use as the HID (Hardware ID)
> >> + identifier _HID
> >> + - acpi,probed : Tells U-Boot to add 'linux,probed' to the ACPI
> >tables so that
> >> + Linux will only load the driver if the device can be detected
> >(e.g. on I2C
> >> + bus)
> >
> >Will support for 'linux,probed' be mainlined? Otherwise the
> >description
> >should IMHO mention that it is an out-of-tree feature.
>
> I have thought some more about this property.
> The Chromium discussions [1] mention that "linux,probed" is intended to be
> a property in both Devicetree and ACPI, so a Linux kernel could handle the
> device in the expected way whether it boots on a Devicetree platform or an
> ACPI platform. The proposed "acpi,probed" property would only solve one such
> use case (ACPI-based platforms): U-Boot boots, reads "acpi,probed" from
> Devicetree, adds "linux,probed" to the ACPI description and hands that to the
> Linux kernel.
>
> Why would we not keep the name "linux,probed" for this property? U-Boot could
> still do the same Devicetree -> ACPI translation, but the same property could
> then also be useful for Devicetree-based platforms.
OK...oh dear. I will change it back to linux,probed
Regards,
Simon
^ permalink raw reply [flat|nested] 86+ messages in thread
* Antwort: [PATCH v3 21/29] test: Add hexdump.h to the unit test header
2020-03-30 23:12 [PATCH v3 00/29] dm: Add programmatic generation of ACPI tables (part A) Simon Glass
` (35 preceding siblings ...)
2020-04-01 7:39 ` Antwort: [PATCH v3 13/29] dts: Add a binding for hid-over-i2c Wolfgang Wallner
@ 2020-04-06 11:53 ` Wolfgang Wallner
36 siblings, 0 replies; 86+ messages in thread
From: Wolfgang Wallner @ 2020-04-06 11:53 UTC (permalink / raw)
To: u-boot
Hi Simon,
-----"Simon Glass" <sjg@chromium.org> schrieb: -----
>
>Since ut_asserteq_mem() uses bin2hex() we should include this header
>in
>ut.h to avoid errors. Add it.
>
>Signed-off-by: Simon Glass <sjg@chromium.org>
>---
>
>Changes in v3:
>- Add new patch to add hexdump.h to the unit test header
>
>Changes in v2: None
>
> include/test/ut.h | 1 +
> 1 file changed, 1 insertion(+)
>
Reviewed-by: Wolfgang Wallner <wolfgang.wallner@br-automation.com>
^ permalink raw reply [flat|nested] 86+ messages in thread