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>
Add a new file to handle generating ACPI code programatically. This is
used when information must be dynamically added to the tables, e.g. the
SSDT.
Initial support is just for writing simple values. Also add a 'base' value
so that the table can be freed. This likely doesn't happen in normal code,
but is nice to do in tests.
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>
Add a function to build up the ACPI path for a device and another for its
scope.
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>
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>
Reviewed-by: Wolfgang Wallner <wolfgang.wallner@br-automation.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
