Revision tags: v6.6.25, v6.6.24, v6.6.23, v6.6.16, v6.6.15, v6.6.14, v6.6.13, v6.6.12, v6.6.11, v6.6.10, v6.6.9, v6.6.8, v6.6.7, v6.6.6, v6.6.5, v6.6.4, v6.6.3, v6.6.2, v6.5.11, v6.6.1, v6.5.10, v6.6, v6.5.9, v6.5.8, v6.5.7, v6.5.6, v6.5.5, v6.5.4, v6.5.3, v6.5.2, v6.1.51, v6.5.1, v6.1.50, v6.5, v6.1.49, v6.1.48, v6.1.46, v6.1.45, v6.1.44, v6.1.43, v6.1.42, v6.1.41, v6.1.40, v6.1.39, v6.1.38 |
|
#
5894cf57 |
| 02-Jul-2023 |
Ard Biesheuvel <ardb@kernel.org> |
acpi/prmt: Use EFI runtime sandbox to invoke PRM handlers
Instead of bypassing the kernel's adaptation layer for performing EFI runtime calls, wire up ACPI PRM handling into it. This means these cal
acpi/prmt: Use EFI runtime sandbox to invoke PRM handlers
Instead of bypassing the kernel's adaptation layer for performing EFI runtime calls, wire up ACPI PRM handling into it. This means these calls can no longer occur concurrently with EFI runtime calls, and will be made from the EFI runtime workqueue. It also means any page faults occurring during PRM handling will be identified correctly as originating in firmware code.
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
show more ...
|
Revision tags: v6.1.37 |
|
#
f6f0c9a7 |
| 29-Jun-2023 |
Huacai Chen <chenhuacai@loongson.cn> |
LoongArch: Add SMT (Simultaneous Multi-Threading) support
Loongson-3A6000 has SMT (Simultaneous Multi-Threading) support, each physical core has two logical cores (threads). This patch add SMT probe
LoongArch: Add SMT (Simultaneous Multi-Threading) support
Loongson-3A6000 has SMT (Simultaneous Multi-Threading) support, each physical core has two logical cores (threads). This patch add SMT probe and scheduler support via ACPI PPTT.
If SCHED_SMT enabled, Loongson-3A6000 is treated as 4 cores, 8 threads; If SCHED_SMT disabled, Loongson-3A6000 is treated as 8 cores, 8 threads.
Remove smp_num_siblings to support HMP (Heterogeneous Multi-Processing).
Signed-off-by: Liupu Wang <wangliupu@loongson.cn> Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
show more ...
|
Revision tags: v6.1.36, v6.4, v6.1.35, v6.1.34, v6.1.33, v6.1.32, v6.1.31, v6.1.30, v6.1.29, v6.1.28, v6.1.27, v6.1.26, v6.3, v6.1.25, v6.1.24, v6.1.23, v6.1.22, v6.1.21, v6.1.20, v6.1.19, v6.1.18, v6.1.17, v6.1.16, v6.1.15, v6.1.14, v6.1.13, v6.2, v6.1.12, v6.1.11, v6.1.10, v6.1.9, v6.1.8, v6.1.7, v6.1.6, v6.1.5, v6.0.19, v6.0.18, v6.1.4, v6.1.3, v6.0.17, v6.1.2, v6.0.16, v6.1.1, v6.0.15, v6.0.14, v6.0.13, v6.1, v6.0.12, v6.0.11, v6.0.10, v5.15.80, v6.0.9, v5.15.79, v6.0.8, v5.15.78 |
|
#
e81c782c |
| 10-Nov-2022 |
Sudeep Holla <sudeep.holla@arm.com> |
ACPI: Implement a generic FFH Opregion handler
This registers the FFH OpRegion handler before ACPI tables are loaded. The platform support for the same is checked via Platform-Wide OSPM Capabilities
ACPI: Implement a generic FFH Opregion handler
This registers the FFH OpRegion handler before ACPI tables are loaded. The platform support for the same is checked via Platform-Wide OSPM Capabilities(OSC) before registering the OpRegion handler.
It relies on the special context data passed to offset and the length. However the interpretation of the values is platform/architecture specific. This generic handler just passed all the information to the platform/architecture specific callback. It also implements the default callbacks which return as not supported.
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
show more ...
|
#
c2465f95 |
| 09-Nov-2022 |
Jeremy Linton <jeremy.linton@arm.com> |
ACPI: Enable FPDT on arm64
FPDT provides some boot timing records useful for analyzing parts of the UEFI boot stack. Given the existing code works on arm64, and allows reading the values without uti
ACPI: Enable FPDT on arm64
FPDT provides some boot timing records useful for analyzing parts of the UEFI boot stack. Given the existing code works on arm64, and allows reading the values without utilizing /dev/mem it seems like a good idea to turn it on.
Signed-off-by: Jeremy Linton <jeremy.linton@arm.com> Acked-by: Sudeep Holla <sudeep.holla@arm.com> Link: https://lore.kernel.org/r/20221109174720.203723-1-jeremy.linton@arm.com Signed-off-by: Will Deacon <will@kernel.org>
show more ...
|
Revision tags: v6.0.7, v5.15.77, v5.15.76, v6.0.6, v6.0.5, v5.15.75, v6.0.4, v6.0.3, v6.0.2, v5.15.74, v5.15.73, v6.0.1, v5.15.72, v6.0, v5.15.71 |
|
#
a97edbaa |
| 26-Sep-2022 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI: Kconfig: Drop link to https://01.org/linux-acpi
Because the https://01.org/linux-acpi web site has become permanently inaccessible, drop the remaining link to it from the ACPI Kconfig.
Signed
ACPI: Kconfig: Drop link to https://01.org/linux-acpi
Because the https://01.org/linux-acpi web site has become permanently inaccessible, drop the remaining link to it from the ACPI Kconfig.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
show more ...
|
#
d206cef0 |
| 26-Sep-2022 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI: docs: Drop useless DSDT override documentation
Because https://01.org/linux-acpi web site has become permanently inaccessible, the "Overriding DSDT" document in the kernel tree pointing to it
ACPI: docs: Drop useless DSDT override documentation
Because https://01.org/linux-acpi web site has become permanently inaccessible, the "Overriding DSDT" document in the kernel tree pointing to it as the main source of information is useless (and the config option name mentioned by it is incorrect), so drop it and drop the pointer to it from the ACPI Kconfig.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
show more ...
|
Revision tags: v5.15.70, v5.15.69, v5.15.68, v5.15.67, v5.15.66, v5.15.65, v5.15.64, v5.15.63, v5.15.62, v5.15.61, v5.15.60, v5.15.59, v5.19, v5.15.58, v5.15.57, v5.15.56, v5.15.55, v5.15.54, v5.15.53, v5.15.52, v5.15.51, v5.15.50, v5.15.49, v5.15.48, v5.15.47, v5.15.46, v5.15.45 |
|
#
fe7aebb4 |
| 04-Jun-2022 |
Hans de Goede <hdegoede@redhat.com> |
ACPI: video: Add Nvidia WMI EC brightness control detection (v3)
On some new laptop designs a new Nvidia specific WMI interface is present which gives info about panel brightness control and may all
ACPI: video: Add Nvidia WMI EC brightness control detection (v3)
On some new laptop designs a new Nvidia specific WMI interface is present which gives info about panel brightness control and may allow controlling the brightness through this interface when the embedded controller is used for brightness control.
When this WMI interface is present and indicates that the EC is used, then this interface should be used for brightness control.
Changes in v2: - Use the new shared nvidia-wmi-ec-backlight.h header for the WMI firmware API definitions - ACPI_VIDEO can now be enabled on non X86 too, adjust the Kconfig changes to match this.
Changes in v3: - Use WMI_BRIGHTNESS_GUID define
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Daniel Dadap <ddadap@nvidia.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
show more ...
|
#
e3435fff |
| 28-Jun-2022 |
Sudeep Holla <sudeep.holla@arm.com> |
ACPI: Move PRM config option under the main ACPI config
Currently PRM(Platform Runtime Mechanism) config option is listed along with the main ACPI (Advanced Configuration and Power Interface) option
ACPI: Move PRM config option under the main ACPI config
Currently PRM(Platform Runtime Mechanism) config option is listed along with the main ACPI (Advanced Configuration and Power Interface) option at the same level. On ARM64 platforms unlike x86, ACPI option is listed at the topmost level of configuration menu. It is rather very confusing to see PRM option also listed along with ACPI in the topmost level.
Move the same under ACPI config option. No functional change, just changes the level of visibility of this option under the configuration menu.
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
show more ...
|
#
36d1f098 |
| 28-Jun-2022 |
Sudeep Holla <sudeep.holla@arm.com> |
ACPI: Enable Platform Runtime Mechanism(PRM) support on ARM64
There is interest to make use of PRM(Platform Runtime Mechanism) even on ARM64 ACPI platforms. Allow PRM to be enabled on ARM64 platform
ACPI: Enable Platform Runtime Mechanism(PRM) support on ARM64
There is interest to make use of PRM(Platform Runtime Mechanism) even on ARM64 ACPI platforms. Allow PRM to be enabled on ARM64 platforms. It will be enabled by default as on x86_64.
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
show more ...
|
#
7fdc74da |
| 16-Jun-2022 |
Riwen Lu <luriwen@kylinos.cn> |
ACPI: processor: Split out thermal initialization from ACPI PSS
Commit 239708a3af44 ("ACPI: Split out ACPI PSS from ACPI Processor driver"), moves processor thermal registration to acpi_pss_perf_ini
ACPI: processor: Split out thermal initialization from ACPI PSS
Commit 239708a3af44 ("ACPI: Split out ACPI PSS from ACPI Processor driver"), moves processor thermal registration to acpi_pss_perf_init(), which doesn't get executed if ACPI_CPU_FREQ_PSS is not enabled.
As ARM64 supports P-states using CPPC, it should be possible to also support processor passive cooling even if PSS is not enabled. Split out the processor thermal cooling register from ACPI PSS to support this, and move it into a separate function in processor_thermal.c.
Signed-off-by: Riwen Lu <luriwen@kylinos.cn> Reviewed-by: Punit Agrawal <punit.agrawal@bytedance.com> [ rjw: Subject edits ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
show more ...
|
#
038275d2 |
| 13-Jun-2022 |
Riwen Lu <luriwen@kylinos.cn> |
ACPI: video: Drop X86 dependency from Kconfig
The ACPI video device is also present in ARM64 laptops, so drop the Kconfig dependency on X86 for ACPI_VIDEO.
Signed-off-by: Riwen Lu <luriwen@kylinos.
ACPI: video: Drop X86 dependency from Kconfig
The ACPI video device is also present in ARM64 laptops, so drop the Kconfig dependency on X86 for ACPI_VIDEO.
Signed-off-by: Riwen Lu <luriwen@kylinos.cn> [ rjw: Subject rewrite, changelog edits ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
show more ...
|
Revision tags: v5.15.44, v5.15.43, v5.15.42, v5.18, v5.15.41, v5.15.40, v5.15.39, v5.15.38, v5.15.37, v5.15.36, v5.15.35, v5.15.34, v5.15.33, v5.15.32, v5.15.31, v5.17, v5.15.30, v5.15.29, v5.15.28, v5.15.27, v5.15.26, v5.15.25, v5.15.24, v5.15.23, v5.15.22 |
|
#
a8ab8ef4 |
| 06-Feb-2022 |
Tom Rix <trix@redhat.com> |
ACPI: clean up double words in two comments
Remove the second 'on' and 'those'.
Signed-off-by: Tom Rix <trix@redhat.com> [ rjw: Subject adjustments ] Signed-off-by: Rafael J. Wysocki <rafael.j.wyso
ACPI: clean up double words in two comments
Remove the second 'on' and 'those'.
Signed-off-by: Tom Rix <trix@redhat.com> [ rjw: Subject adjustments ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
show more ...
|
Revision tags: v5.15.21, v5.15.20, v5.15.19 |
|
#
04662bac |
| 30-Jan-2022 |
Randy Dunlap <rdunlap@infradead.org> |
ACPI: require CRC32 to build
ACPI core now requires crc32() but the kernel build can fail when CRC32 is not set/enabled, so select it in the ACPI Kconfig entry.
Fixes this build error:
ia64-linux-
ACPI: require CRC32 to build
ACPI core now requires crc32() but the kernel build can fail when CRC32 is not set/enabled, so select it in the ACPI Kconfig entry.
Fixes this build error:
ia64-linux-ld: drivers/acpi/scan.o: in function `acpi_store_pld_crc': include/acpi/platform/aclinuxex.h:62: undefined reference to `crc32_le'
Fixes: 882c982dada4 ("acpi: Store CRC-32 hash of the _PLD in struct acpi_device") Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Reported-by: Guenter Roeck <linux@roeck-us.net> Reviewed-by: Guenter Roeck <linux@roeck-us.net> Tested-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
show more ...
|
Revision tags: v5.15.18, v5.15.17, v5.4.173, v5.15.16, v5.15.15, v5.16 |
|
#
77e2a047 |
| 04-Jan-2022 |
Sudeep Holla <sudeep.holla@arm.com> |
ACPI: PCC: Implement OperationRegion handler for the PCC Type 3 subtype
PCC OpRegion provides a mechanism to communicate with the platform directly from the AML. PCCT provides the list of PCC channe
ACPI: PCC: Implement OperationRegion handler for the PCC Type 3 subtype
PCC OpRegion provides a mechanism to communicate with the platform directly from the AML. PCCT provides the list of PCC channel available in the platform, a subset or all of them can be used in PCC Opregion.
This patch registers the PCC OpRegion handler before ACPI tables are loaded. This relies on the special context data passed to identify and set up the PCC channel before the OpRegion handler is executed for the first time.
Typical PCC Opregion declaration looks like this:
OperationRegion (PFRM, PCC, 2, 0x74) Field (PFRM, ByteAcc, NoLock, Preserve) { SIGN, 32, FLGS, 32, LEN, 32, CMD, 32, DATA, 800 }
It contains four named double words followed by 100 bytes of buffer names DATA.
ASL can fill out the buffer something like:
/* Create global or local buffer */ Name (BUFF, Buffer (0x0C){}) /* Create double word fields over the buffer */ CreateDWordField (BUFF, 0x0, WD0) CreateDWordField (BUFF, 0x04, WD1) CreateDWordField (BUFF, 0x08, WD2)
/* Fill the named fields */ WD0 = 0x50434300 SIGN = BUFF WD0 = 1 FLGS = BUFF WD0 = 0x10 LEN = BUFF
/* Fill the payload in the DATA buffer */ WD0 = 0 WD1 = 0x08 WD2 = 0 DATA = BUFF
/* Write to CMD field to trigger handler */ WD0 = 0x4404 CMD = BUFF
This buffer is received by acpi_pcc_opregion_space_handler. This handler will fetch the complete buffer via internal_pcc_buffer.
The setup handler will receive the special PCC context data which will contain the PCC channel index which used to set up the channel. The buffer pointer and length is saved in region context which is then used in the handler.
(kernel test robot: Build failure with CONFIG_ACPI_DEBUGGER) Link: https://lore.kernel.org/r/202201041539.feAV0l27-lkp@intel.com Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
show more ...
|
#
b0013e03 |
| 21-Dec-2021 |
Chen Yu <yu.c.chen@intel.com> |
ACPI: Introduce Platform Firmware Runtime Telemetry driver
This driver allows user space to fetch telemetry data from the firmware with the help of the Platform Firmware Runtime Telemetry interface.
ACPI: Introduce Platform Firmware Runtime Telemetry driver
This driver allows user space to fetch telemetry data from the firmware with the help of the Platform Firmware Runtime Telemetry interface.
Both PFRU and PFRT are based on ACPI _DSM interfaces located under special device objects in the ACPI Namespace, but these interfaces are different from each other, so it is better to provide a separate driver from each of them, even though they share some common definitions and naming conventions.
Tested-by: Hongyu Ning <hongyu.ning@intel.com> Signed-off-by: Chen Yu <yu.c.chen@intel.com> [ rjw: Subject and changelog edits ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
show more ...
|
#
0db89fa2 |
| 21-Dec-2021 |
Chen Yu <yu.c.chen@intel.com> |
ACPI: Introduce Platform Firmware Runtime Update device driver
Introduce the pfr_update driver which can be used for Platform Firmware Runtime code injection and driver update [1].
The user is expe
ACPI: Introduce Platform Firmware Runtime Update device driver
Introduce the pfr_update driver which can be used for Platform Firmware Runtime code injection and driver update [1].
The user is expected to provide the EFI capsule, and pass it to the driver by writing the capsule to a device special file. The capsule is transferred by the driver to the platform firmware with the help of an ACPI _DSM method under the special ACPI Platform Firmware Runtime Update device (INTC1080), and the actual firmware update is carried out by the low-level Management Mode code in the platform firmware.
This change allows certain pieces of the platform firmware to be updated on the fly while the system is running (runtime) without the need to restart it, which is key in the cases when the system needs to be available 100% of the time and it cannot afford the downtime related to restarting it, or when the work carried out by the system is particularly important, so it cannot be interrupted, and it is not practical to wait until it is complete.
Link: https://uefi.org/sites/default/files/resources/Intel_MM_OS_Interface_Spec_Rev100.pdf # [1] Tested-by: Hongyu Ning <hongyu.ning@intel.com> Signed-off-by: Chen Yu <yu.c.chen@intel.com> [ rjw: Subject and changelog edits ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
show more ...
|
Revision tags: v5.15.10, v5.15.9, v5.15.8, v5.15.7, v5.15.6, v5.15.5, v5.15.4, v5.15.3, v5.15.2, v5.15.1, v5.15 |
|
#
f64bd790 |
| 29-Oct-2021 |
Dan Williams <dan.j.williams@intel.com> |
ACPI: Keep sub-table parsing infrastructure available for modules
The NFIT driver and now the CXL ACPI driver have both open-coded ACPI table parsing. Before another instance is added arrange for th
ACPI: Keep sub-table parsing infrastructure available for modules
The NFIT driver and now the CXL ACPI driver have both open-coded ACPI table parsing. Before another instance is added arrange for the core ACPI sub-table parsing to be optionally available to drivers via the CONFIG_ACPI_TABLE_LIB symbol. If no drivers select the symbol then the infrastructure reverts back to being tagged __init via the __init_or_acpilib annotation.
For now, only tag the core sub-table routines and data that the CEDT parsing in the cxl_acpi driver would want to reuse, a CEDT parsing helper is added in a later change.
Cc: "Rafael J. Wysocki" <rafael@kernel.org> Cc: Len Brown <lenb@kernel.org> Cc: Alison Schofield <alison.schofield@intel.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Link: https://lore.kernel.org/r/163553709227.2509508.8215196520233473814.stgit@dwillia2-desk3.amr.corp.intel.com Signed-off-by: Dan Williams <dan.j.williams@intel.com>
show more ...
|
Revision tags: v5.14.14, v5.14.13, v5.14.12, v5.14.11, v5.14.10, v5.14.9, v5.14.8, v5.14.7 |
|
#
c117dfff |
| 21-Sep-2021 |
Masanari Iida <standby24x7@gmail.com> |
ACPI: Kconfig: Fix a typo in Kconfig
This patch fixes a spelling typo in acpi/Kconfig
Signed-off-by: Masanari Iida <standby24x7@gmail.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.c
ACPI: Kconfig: Fix a typo in Kconfig
This patch fixes a spelling typo in acpi/Kconfig
Signed-off-by: Masanari Iida <standby24x7@gmail.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
show more ...
|
Revision tags: v5.14.6, v5.10.67, v5.10.66, v5.14.5, v5.14.4, v5.10.65, v5.14.3, v5.10.64, v5.14.2, v5.10.63, v5.14.1, v5.10.62, v5.14, v5.10.61, v5.10.60, v5.10.53, v5.10.52, v5.10.51 |
|
#
d2cbbf1f |
| 15-Jul-2021 |
Robert Richter <rrichter@amd.com> |
ACPI: Kconfig: Fix table override from built-in initrd
During a rework of initramfs code the INITRAMFS_COMPRESSION config option was removed in commit 65e00e04e5ae. A leftover as a dependency broke
ACPI: Kconfig: Fix table override from built-in initrd
During a rework of initramfs code the INITRAMFS_COMPRESSION config option was removed in commit 65e00e04e5ae. A leftover as a dependency broke the config option ACPI_TABLE_OVERRIDE_VIA_ BUILTIN_INITRD that is used to enable the overriding of ACPI tables from built-in initrd. Fixing the dependency.
Fixes: 65e00e04e5ae ("initramfs: refactor the initramfs build rules") Signed-off-by: Robert Richter <rrichter@amd.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
show more ...
|
Revision tags: v5.10.50, v5.10.49 |
|
#
b1121e2a |
| 05-Jul-2021 |
Huacai Chen <chenhuacai@loongson.cn> |
ACPI: Add LoongArch support for ACPI_PROCESSOR/ACPI_NUMA
We are preparing to add new Loongson (based on LoongArch, not MIPS) support. LoongArch use ACPI other than DT as its boot protocol, so add it
ACPI: Add LoongArch support for ACPI_PROCESSOR/ACPI_NUMA
We are preparing to add new Loongson (based on LoongArch, not MIPS) support. LoongArch use ACPI other than DT as its boot protocol, so add its support for ACPI_PROCESSOR/ACPI_NUMA.
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
show more ...
|
#
9b52363b |
| 01-Jul-2021 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI: Kconfig: Provide help text for the ACPI_PRMT option
Add missing help text for CONFIG_ACPI_PRMT.
Fixes: cefc7ca46235 ("ACPI: PRM: implement OperationRegion handler for the PlatformRtMechanism
ACPI: Kconfig: Provide help text for the ACPI_PRMT option
Add missing help text for CONFIG_ACPI_PRMT.
Fixes: cefc7ca46235 ("ACPI: PRM: implement OperationRegion handler for the PlatformRtMechanism subtype") Reported-by: Borislav Petkov <bp@alien8.de> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
show more ...
|
Revision tags: v5.13, v5.10.46 |
|
#
3cf48554 |
| 18-Jun-2021 |
Jean-Philippe Brucker <jean-philippe@linaro.org> |
ACPI: Add driver for the VIOT table
The ACPI Virtual I/O Translation Table describes topology of para-virtual platforms, similarly to vendor tables DMAR, IVRS and IORT. For now it describes the rela
ACPI: Add driver for the VIOT table
The ACPI Virtual I/O Translation Table describes topology of para-virtual platforms, similarly to vendor tables DMAR, IVRS and IORT. For now it describes the relation between virtio-iommu and the endpoints it manages.
Three steps are needed to configure DMA of endpoints:
(1) acpi_viot_init(): parse the VIOT table, find or create the fwnode associated to each vIOMMU device. This needs to happen after acpi_scan_init(), because it relies on the struct device and their fwnode to be available.
(2) When probing the vIOMMU device, the driver registers its IOMMU ops within the IOMMU subsystem. This step doesn't require any intervention from the VIOT driver.
(3) viot_iommu_configure(): before binding the endpoint to a driver, find the associated IOMMU ops. Register them, along with the endpoint ID, into the device's iommu_fwspec.
If step (3) happens before step (2), it is deferred until the IOMMU is initialized, then retried.
Tested-by: Eric Auger <eric.auger@redhat.com> Reviewed-by: Eric Auger <eric.auger@redhat.com> Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org> Acked-by: Rafael J. Wysocki <rafael@kernel.org> Link: https://lore.kernel.org/r/20210618152059.1194210-4-jean-philippe@linaro.org Signed-off-by: Joerg Roedel <jroedel@suse.de>
show more ...
|
Revision tags: v5.10.43 |
|
#
cefc7ca4 |
| 09-Jun-2021 |
Erik Kaneda <erik.kaneda@intel.com> |
ACPI: PRM: implement OperationRegion handler for the PlatformRtMechanism subtype
Platform Runtime Mechanism (PRM) is a firmware interface that exposes a set of binary executables that can either be
ACPI: PRM: implement OperationRegion handler for the PlatformRtMechanism subtype
Platform Runtime Mechanism (PRM) is a firmware interface that exposes a set of binary executables that can either be called from the AML interpreter or device drivers by bypassing the AML interpreter. This change implements the AML interpreter path.
According to the specification [1], PRM services are listed in an ACPI table called the PRMT. This patch parses module and handler information listed in the PRMT and registers the PlatformRtMechanism OpRegion handler before ACPI tables are loaded.
Each service is defined by a 16-byte GUID and called from writing a 26-byte ASL buffer containing the identifier to a FieldUnit object defined inside a PlatformRtMechanism OperationRegion.
OperationRegion (PRMR, PlatformRtMechanism, 0, 26) Field (PRMR, BufferAcc, NoLock, Preserve) { PRMF, 208 // Write to this field to invoke the OperationRegion Handler }
The 26-byte ASL buffer is defined as the following:
Byte Offset Byte Length Description ============================================================= 0 1 PRM OperationRegion handler status 1 8 PRM service status 9 1 PRM command 10 16 PRM handler GUID
The ASL caller fills out a 26-byte buffer containing the PRM command and the PRM handler GUID like so:
/* Local0 is the PRM data buffer */ Local0 = buffer (26){}
/* Create byte fields over the buffer */ CreateByteField (Local0, 0x9, CMD) CreateField (Local0, 0x50, 0x80, GUID)
/* Fill in the command and data fields of the data buffer */ CMD = 0 // run command GUID = ToUUID("xxxx-xx-xxx-xxxx")
/* * Invoke PRM service with an ID that matches GUID and save the * result. */ Local0 = (\_SB.PRMT.PRMF = Local0)
Byte offset 0 - 8 are written by the handler as a status passed back to AML and used by ASL like so:
/* Create byte fields over the buffer */ CreateByteField (Local0, 0x0, PSTA) CreateQWordField (Local0, 0x1, USTA)
In this ASL code, PSTA contains a status from the OperationRegion and USTA contains a status from the PRM service.
The 26-byte buffer is recieved by acpi_platformrt_space_handler. This handler will look at the command value and the handler guid and take the approperiate actions.
Command value Action ===================================================================== 0 Run the PRM service indicated by the PRM handler GUID (bytes 10-26)
1 Prevent PRM runtime updates from happening to the service's parent module
2 Allow PRM updates from happening to the service's parent module
This patch enables command value 0.
Link: https://uefi.org/sites/default/files/resources/Platform%20Runtime%20Mechanism%20-%20with%20legal%20notice.pdf # [1] Signed-off-by: Erik Kaneda <erik.kaneda@intel.com> [ rjw: Subject and changelog edits ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
show more ...
|
Revision tags: v5.10.42, v5.10.41, v5.10.40, v5.10.39, v5.4.119, v5.10.36, v5.10.35, v5.10.34, v5.4.116, v5.10.33, v5.12, v5.10.32, v5.10.31, v5.10.30, v5.10.27, v5.10.26, v5.10.25, v5.10.24, v5.10.23, v5.10.22, v5.10.21, v5.10.20, v5.10.19, v5.4.101, v5.10.18, v5.10.17, v5.11, v5.10.16 |
|
#
21f05a43 |
| 11-Feb-2021 |
Maximilian Luz <luzmaximilian@gmail.com> |
ACPI: platform: Hide ACPI_PLATFORM_PROFILE option
The ACPI_PLATFORM_PROFILE option essentially provides a library and not really an independent module. Thus it seems to be more user-friendly to hide
ACPI: platform: Hide ACPI_PLATFORM_PROFILE option
The ACPI_PLATFORM_PROFILE option essentially provides a library and not really an independent module. Thus it seems to be more user-friendly to hide this option and simply make drivers depending on it select it.
Suggested-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Maximilian Luz <luzmaximilian@gmail.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
show more ...
|
Revision tags: v5.10.15, v5.10.14 |
|
#
d1eb86e5 |
| 29-Jan-2021 |
Zhang Rui <rui.zhang@intel.com> |
ACPI: tables: introduce support for FPDT table
ACPI Firmware Performance Data Table (FPDT) provides information about firmware performance during system boot, S3 suspend and S3 resume.
Have the ker
ACPI: tables: introduce support for FPDT table
ACPI Firmware Performance Data Table (FPDT) provides information about firmware performance during system boot, S3 suspend and S3 resume.
Have the kernel parse the FPDT table, and expose the firmware performance data to userspace as sysfs attributes under /sys/firmware/acpi/fpdt/.
Tested-by: Todd Brandt <todd.e.brandt@linux.intel.com> Signed-off-by: Zhang Rui <rui.zhang@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
show more ...
|