summaryrefslogtreecommitdiff
path: root/lib/acpi
AgeCommit message (Collapse)AuthorFilesLines
2022-02-09acpi: Move MCFG implementation to common libMoritz Fischer2-0/+65
MCFG tables are used on multiple arches. Move to common ACPI lib. Cc: Simon Glass <sjg@chromium.org> Signed-off-by: Moritz Fischer <moritzf@google.com> Reviewed-by: Simon Glass <sjg@chromium.org> Use sizeof(*mcfg) instead of sizeof(*header) Signed-off-by: Simon Glass <sjg@chromium.org>
2022-01-25acpi: Collect tables in the acpi_item listSimon Glass1-0/+5
At present this list is used to collect items within the DSDT and SSDT tables. It is useful for it to collect the whole tables as well, so there is a list of what was created and which write created each one. Refactor the code accordingly. Signed-off-by: Simon Glass <sjg@chromium.org>
2022-01-25x86: Move acpi_get_rsdp_addr() ACPI tables to the writerSimon Glass1-0/+8
Move this over to use a writer file, moving the code from the x86 implementation. There is no need to store a separate variable since we can simply access the ACPI context. With this, the original monolithic x86 function for writing ACPI tables is gone. Note that QEMU has its own implementation. Signed-off-by: Simon Glass <sjg@chromium.org>
2022-01-25x86: Move device-specific ACPI tables to a writer functionSimon Glass1-0/+12
Move this over to use a writer function, moving the code from the x86 implementation. Signed-off-by: Simon Glass <sjg@chromium.org>
2022-01-25x86: acpi: Update acpi_fill_csrt() to use acpi_ctxSimon Glass1-7/+6
Update this function to the newer style, so we can avoid passing and returning an address through this function. Also move this function out of the x86 code so it can be used by other archs. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2022-01-25x86: Move CSRT table to a writer functionSimon Glass2-0/+51
Move this table over to use a writer function, moving the code from the x86 implementation. Signed-off-by: Simon Glass <sjg@chromium.org>
2022-01-25x86: Move SSDT table to a writer functionSimon Glass2-0/+50
Move this table over to use a writer function, moving the code from the x86 implementation. Signed-off-by: Simon Glass <sjg@chromium.org>
2022-01-25x86: Move DSDT table to a writer functionSimon Glass4-0/+65
Move this table over to use a writer function, moving the code from the x86 implementation. Add a pointer to the DSDT in struct acpi_ctx so we can reference it later. Disable this table for sandbox since we don't actually compile real ASL code. Signed-off-by: Simon Glass <sjg@chromium.org>
2022-01-25x86: Move FACS table to a writer functionSimon Glass2-0/+34
Move this table over to use a writer function, moving the code from the x86 implementation. Add a pointer to the DSDT in struct acpi_ctx so we can reference it later. Signed-off-by: Simon Glass <sjg@chromium.org>
2022-01-25x86: Move base tables to a writer functionSimon Glass4-76/+101
Use the new ACPI writer to write the base tables at the start of the area, moving this code from the x86 implementation. Signed-off-by: Simon Glass <sjg@chromium.org>
2022-01-25x86: Use the ACPI table writerSimon Glass1-1/+3
Use the new ACPI writer to write the ACPI tables. At present this is all done in one monolithic function. Future work will split this out. Unfortunately the QFW write_acpi_tables() function conflicts with the 'writer' version, so disable that for sandbox. Signed-off-by: Simon Glass <sjg@chromium.org>
2022-01-25x86: acpi: Split out context creation from base tablesSimon Glass3-15/+19
At present acpi_setup_base_tables() both sets up the ACPI context and writes out the base tables. We want to use an ACPI writer to write the base tables, so split this function into two, with acpi_setup_ctx() doing the context set, and acpi_setup_base_tables() just doing the base tables. Disable the writer's write_acpi_tables() function for now, to avoid build errors. It is enabled in a following patch. Signed-off-by: Simon Glass <sjg@chromium.org>
2022-01-25acpi: Add a linker list for ACPI tablesSimon Glass1-0/+91
At present we call lots of functions to generate the required ACPI tables. It would be better to standardise these functions and allow them to be automatically collected and used when needed. Add a linker list to handle this. Signed-off-by: Simon Glass <sjg@chromium.org>
2022-01-25acpi: Use finer-grained control of ACPI-table generationSimon Glass1-4/+4
Rather than keying everything off ACPIGEN, use the main GENERATE_ACPI_TABLE option to determine whether the core ACPI code is included. Make sure these option are not enabled in SPL/TPL since we never generate tables there. Signed-off-by: Simon Glass <sjg@chromium.org>
2022-01-25x86: Move the acpi table to generic global_dataSimon Glass1-1/+1
Allow this to be used on any arch. Also convert to using macros so that we can check the CONFIG option in C code. Signed-off-by: Simon Glass <sjg@chromium.org>
2022-01-19doc: replace @return by Return:Heinrich Schuchardt1-4/+4
Sphinx expects Return: and not @return to indicate a return value. find . -name '*.c' -exec \ sed -i 's/^\(\s\)\*\(\s*\)@return\(\s\)/\1*\2Return:\3/' {} \; find . -name '*.h' -exec \ sed -i 's/^\(\s\)\*\(\s*\)@return\(\s\)/\1*\2Return:\3/' {} \; Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
2021-10-06acpi: Use U-Boot version for OEM_REVISIONPali Rohár1-1/+17
OEM_REVISION is 32-bit unsigned number. It should be increased only when changing software version. Therefore it should not depend on build time. Change calculation to use U-Boot version numbers and set this revision to date number. Prior this change OEM_REVISION was calculated from build date and stored in the same format. After this change macro U_BOOT_BUILD_DATE is not used in other files so remove it from global autogenerated files and also from Makefile. Signed-off-by: Pali Rohár <pali@kernel.org> Reviewed-by: Simon Glass <sjg@chromium.org>
2021-09-17Remove including timestamp.h in version.hPali Rohár1-0/+1
Header file version.h does not use anything from timestamp.h. Including of timestamp.h has side effect which cause recompiling object file at every make run because timestamp.h changes at every run. So remove timestamp.h from version.h and include timestamp.h in files which needs it. This change reduce recompilation time of final U-Boot binary when U-Boot source files were not changed as less source files needs to be recompiled. Signed-off-by: Pali Rohár <pali@kernel.org> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com> [trini: Add in lib/acpi/acpi_table.c and test/dm/acpi.c, rework a few others] Signed-off-by: Tom Rini <trini@konsulko.com>
2021-02-02common: Drop asm/global_data.h from common headerSimon Glass1-0/+1
Move this out of the common header and include it only where needed. In a number of cases this requires adding "struct udevice;" to avoid adding another large header or in other cases replacing / adding missing header files that had been pulled in, very indirectly. Finally, we have a few cases where we did not need to include <asm/global_data.h> at all, so remove that include. Signed-off-by: Simon Glass <sjg@chromium.org> Signed-off-by: Tom Rini <trini@konsulko.com>
2020-12-18x86: Simplify acpi_device_infer_name()Simon Glass1-24/+3
There is no-longer any need to check if sequence numbers are valid, since this is ensured by driver model. Drop the unwanted logic. Signed-off-by: Simon Glass <sjg@chromium.org>
2020-12-13dm: treewide: Rename ..._platdata variables to just ..._platSimon Glass1-1/+1
Try to maintain some consistency between these variables by using _plat as a suffix for them. Signed-off-by: Simon Glass <sjg@chromium.org>
2020-12-13dm: treewide: Rename 'platdata' variables to just 'plat'Simon Glass1-2/+2
We use 'priv' for private data but often use 'platdata' for platform data. We can't really use 'pdata' since that is ambiguous (it could mean private or platform data). Rename some of the latter variables to end with 'plat' for consistency. Signed-off-by: Simon Glass <sjg@chromium.org>
2020-11-06acpi: Correct reset handling in acpi_device_add_power_res()Simon Glass1-1/+1
If there is no reset line, this still emits ACPI code for the reset GPIO. Fix it by updating the check. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2020-11-06x86: Allow putting some tables in the bloblistSimon Glass1-2/+2
At present all tables are placed starting at address f0000 in memory, and can be up to 64KB in size. If the tables are very large, this may not provide enough space. Also if the tables point to other tables (such as console log or a ramoops area) then we must allocate other memory anyway. The bloblist is a nice place to put these tables since it is contiguous, which makes it easy to reserve this memory for linux using the 820 tables. Add an option to put some of the tables in the bloblist. For SMBIOS and ACPI, create suitable pointers from the f0000 region to the new location of the tables. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> [bmeng: squashed in http://patchwork.ozlabs.org/project/uboot/patch/ 20201105062407.1.I8091ad931cbbb5e3b6f6ababdf3f8d5db0d17bb9@changeid/] Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
2020-09-25acpi: Use I2cSerialBusV2() instead of I2cSerialBus()Simon Glass1-1/+1
Use the correct name of the ACPI structure being created. Signed-off-by: Simon Glass <sjg@chromium.org>
2020-09-25acpi: Add more support for generating processor tablesSimon Glass1-0/+167
This adds tables relating to P-States and C-States. Signed-off-by: Simon Glass <sjg@chromium.org>
2020-09-25acpi: Add support for generating processor tablesSimon Glass1-0/+55
ACPI has a number of CPU-related tables. Add utility functions to write out the basic packages. Signed-off-by: Simon Glass <sjg@chromium.org>
2020-09-25x86: acpi: Support generation of the DBG2 tableSimon Glass1-0/+64
Add an implementation of the DBG2 (Debug Port Table 2) ACPI table. Adjust one of the header includes to be in the correct order, before adding more. Note that the DBG2 table is generic but the PCI UART is x86-specific at present since it assumes an ns16550 UART. It can be generalised later if necessary. Signed-off-by: Simon Glass <sjg@chromium.org>
2020-09-25dm: acpi: Use correct GPIO polarity type in acpi_dp_add_gpio()Simon Glass1-2/+2
This function currently accepts the IRQ-polarity type. Fix it to use the GPIO type instead. Signed-off-by: Simon Glass <sjg@chromium.org>
2020-09-25acpi: Support generating a multi-function _DSM for devicesSimon Glass2-0/+97
Add a function to generate ACPI code for a _DSM method for a device. This includes functions for starting and ending each part of the _DSM. Signed-off-by: Simon Glass <sjg@chromium.org> [bmeng: fix the "new blank line at EOF" git warning] Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
2020-09-25acpi: Add support for conditions and return valuesSimon Glass1-0/+68
Add functions to support generating ACPI code for condition checks and return values. Signed-off-by: Simon Glass <sjg@chromium.org>
2020-09-25acpi: Add support for writing a _PRWSimon Glass1-0/+10
A 'Power Resource for Wake' list the resources a device depends on for wake. Add a function to generate this. Signed-off-by: Simon Glass <sjg@chromium.org>
2020-07-17acpi: Support writing named valuesSimon Glass1-0/+49
Allow writing named integers and strings to the generated ACPI 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> [bmeng: Fix the "new blank line at EOF" warning] Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
2020-07-17acpi: Support generation of a deviceSimon Glass1-0/+7
Allow writing an ACPI device to the generated ACPI 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> [bmeng: Fix build failures on Sandbox] Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
2020-07-17acpi: Support generation of a generic registerSimon Glass1-0/+71
Allow writing out a generic register. 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> [bmeng: Fix build failures on Sandbox] Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
2020-07-17acpi: Support generation of a scopeSimon Glass1-0/+7
Add a function to write a scope to the generated ACPI code. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Wolfgang Wallner <wolfgang.wallner@br-automation.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> [bmeng: Fix build failures on Sandbox] Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
2020-07-17dm: acpi: Enhance acpi_get_name()Simon Glass1-0/+106
For many device types it is possible to figure out the name just by looking at its uclass or parent. Add a function to handle this, since it allows us to cover the vast majority of cases automatically. However it is sometimes impossible to figure out an ACPI name for a device just by looking at its uclass. For example a touch device may have a vendor-specific name. Add a new "acpi,name" property to allow a custom name to be created. With this new feature we can drop the get_name() methods in the sandbox I2C and SPI drivers. They were only added for testing purposes. Update the tests to use the new values. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Wolfgang Wallner <wolfgang.wallner@br-automation.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2020-07-17acpi: Add support for a generic power sequenceSimon Glass1-0/+99
Add a way for devices to enable and disable themselves using ACPI code that updates GPIOs. This takes several timing parameters and supports enable, reset and stop. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Wolfgang Wallner <wolfgang.wallner@br-automation.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2020-07-17acpi: Add support for writing a GPIO power sequenceSimon Glass1-0/+85
Power to some devices is controlled by GPIOs. Add a way to generate ACPI code to enable and disable a GPIO so that this can be handled within an ACPI method. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Wolfgang Wallner <wolfgang.wallner@br-automation.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2020-07-17acpi: Add support for writing a Power ResourceSimon Glass1-0/+22
These are used in ACPI to disable power to various pats of the system when in sleep. Add a way to create a power resource, with the caller finishing off the details. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Wolfgang Wallner <wolfgang.wallner@br-automation.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2020-07-17acpi: Add support for various misc ACPI opcodesSimon Glass1-0/+86
Add more functions to handle some miscellaneous ACPI opcodes. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Wolfgang Wallner <wolfgang.wallner@br-automation.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2020-07-17acpi: Support copying properties from device tree to ACPISimon Glass1-0/+56
Some drivers in Linux support both device tree and ACPI. U-Boot itself uses Linux device-tree bindings for its own configuration but does not use ACPI. It is convenient to copy these values over to the ACPI DP table for passing to linux. Add some convenience functions to help with this. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Wolfgang Wallner <wolfgang.wallner@br-automation.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2020-07-17acpi: Support writing a GPIOSimon Glass1-0/+23
Allowing writing out a reference to a GPIO within the ACPI output. This can be used by ACPI code to access a GPIO at runtime. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Wolfgang Wallner <wolfgang.wallner@br-automation.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2020-07-17acpi: Support writing Device Properties objects via _DSDSimon Glass2-0/+324
More complex device properties can be provided to drivers via a device-specific data (_DSD) object. To create this we need to build it up in a separate data structure and then generate the ACPI code, due to its recursive nature. Add an implementation of this. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Wolfgang Wallner <wolfgang.wallner@br-automation.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2020-07-17acpi: Support writing a UUIDSimon Glass1-0/+38
ACPI supports writing a UUID in a special format. Add a function to handle this. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Wolfgang Wallner <wolfgang.wallner@br-automation.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2020-07-17acpi: Support writing a nameSimon Glass1-0/+96
ACPI supports storing names which are made up of multiple path components. Several special cases are supported. Add a function to emit a name. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Wolfgang Wallner <wolfgang.wallner@br-automation.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2020-07-17acpi: Support writing a stringSimon Glass1-0/+6
ACPI supports storing a simple null-terminated string. Add support for this. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Wolfgang Wallner <wolfgang.wallner@br-automation.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2020-07-17acpi: Support writing an integerSimon Glass1-0/+51
ACPI supports storing integers in various ways. Add a function to handle this. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Wolfgang Wallner <wolfgang.wallner@br-automation.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2020-07-17acpigen: Support writing a packageSimon Glass1-0/+12
A package collects together several elements. Add an easy way of writing a package header and updating its length later. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Wolfgang Wallner <wolfgang.wallner@br-automation.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2020-07-17acpigen: Support writing a lengthSimon Glass1-0/+33
It is convenient to write a length value for preceding a block of data. Of course the length is not known or is hard to calculate a priori. So add a way to mark the start on a stack, so the length can be updated when known. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Wolfgang Wallner <wolfgang.wallner@br-automation.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>