Centos-kernel-stream-9/drivers/platform/x86/intel/Kconfig

188 lines
6.8 KiB
Plaintext
Raw Normal View History

# SPDX-License-Identifier: GPL-2.0-only
#
# Intel x86 Platform Specific Drivers
#
menuconfig X86_PLATFORM_DRIVERS_INTEL
bool "Intel x86 Platform Specific Device Drivers"
default y
help
Say Y here to get to see options for device drivers for
various Intel x86 platforms, including vendor-specific
drivers. This option alone does not add any kernel code.
If you say N, all options in this submenu will be skipped
and disabled.
if X86_PLATFORM_DRIVERS_INTEL
source "drivers/platform/x86/intel/atomisp2/Kconfig"
source "drivers/platform/x86/intel/ifs/Kconfig"
source "drivers/platform/x86/intel/int1092/Kconfig"
source "drivers/platform/x86/intel/int33fe/Kconfig"
source "drivers/platform/x86/intel/int3472/Kconfig"
source "drivers/platform/x86/intel/pmc/Kconfig"
source "drivers/platform/x86/intel/pmt/Kconfig"
source "drivers/platform/x86/intel/telemetry/Kconfig"
source "drivers/platform/x86/intel/speed_select_if/Kconfig"
source "drivers/platform/x86/intel/wmi/Kconfig"
source "drivers/platform/x86/intel/uncore-frequency/Kconfig"
config INTEL_HID_EVENT
tristate "Intel HID Event"
depends on ACPI
depends on INPUT
depends on I2C
select INPUT_SPARSEKMAP
help
This driver provides support for the Intel HID Event hotkey interface.
Some laptops require this driver for hotkey support.
To compile this driver as a module, choose M here: the module will
be called intel_hid.
config INTEL_VBTN
tristate "Intel Virtual Button"
depends on ACPI
depends on INPUT
depends on I2C
select INPUT_SPARSEKMAP
help
This driver provides support for the Intel Virtual Button interface.
Some laptops require this driver for power button support.
To compile this driver as a module, choose M here: the module will
be called intel_vbtn.
config INTEL_INT0002_VGPIO
tristate "Intel ACPI INT0002 Virtual GPIO driver"
depends on GPIOLIB && ACPI && PM_SLEEP
select GPIOLIB_IRQCHIP
help
Some peripherals on Bay Trail and Cherry Trail platforms signal a
Power Management Event (PME) to the Power Management Controller (PMC)
to wakeup the system. When this happens software needs to explicitly
clear the PME bus 0 status bit in the GPE0a_STS register to avoid an
IRQ storm on IRQ 9.
This is modelled in ACPI through the INT0002 ACPI device, which is
called a "Virtual GPIO controller" in ACPI because it defines the
event handler to call when the PME triggers through _AEI and _L02
methods as would be done for a real GPIO interrupt in ACPI.
To compile this driver as a module, choose M here: the module will
be called intel_int0002_vgpio.
config INTEL_OAKTRAIL
tristate "Intel Oaktrail Platform Extras"
depends on ACPI
depends on ACPI_VIDEO || ACPI_VIDEO=n
depends on RFKILL && BACKLIGHT_CLASS_DEVICE && ACPI
help
Intel Oaktrail platform need this driver to provide interfaces to
enable/disable the Camera, WiFi, BT etc. devices. If in doubt, say Y
here; it will only load on supported platforms.
platform/x86: Add Intel Software Defined Silicon driver Bugzilla: https://bugzilla.redhat.com/1971952 commit 2546c60004309ede8e2d1d5341e0decd90e057bf Author: David E. Box <david.e.box@linux.intel.com> Date: Fri Feb 11 17:32:50 2022 -0800 platform/x86: Add Intel Software Defined Silicon driver Intel Software Defined Silicon (SDSi) is a post manufacturing mechanism for activating additional silicon features. Features are enabled through a license activation process. The SDSi driver provides a per socket, sysfs attribute interface for applications to perform 3 main provisioning functions: 1. Provision an Authentication Key Certificate (AKC), a key written to internal NVRAM that is used to authenticate a capability specific activation payload. 2. Provision a Capability Activation Payload (CAP), a token authenticated using the AKC and applied to the CPU configuration to activate a new feature. 3. Read the SDSi State Certificate, containing the CPU configuration state. The operations perform function specific mailbox commands that forward the requests to SDSi hardware to perform authentication of the payloads and enable the silicon configuration (to be made available after power cycling). The SDSi device itself is enumerated as an auxiliary device from the intel_vsec driver and as such has a build dependency on CONFIG_INTEL_VSEC. Link: https://github.com/intel/intel-sdsi Signed-off-by: David E. Box <david.e.box@linux.intel.com> Reviewed-by: Mark Gross <markgross@kernel.org> Link: https://lore.kernel.org/r/20220212013252.1293396-2-david.e.box@linux.intel.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: David Arcari <darcari@redhat.com>
2022-04-05 13:39:19 +00:00
config INTEL_SDSI
tristate "Intel On Demand (Software Defined Silicon) Driver"
platform/x86: Add Intel Software Defined Silicon driver Bugzilla: https://bugzilla.redhat.com/1971952 commit 2546c60004309ede8e2d1d5341e0decd90e057bf Author: David E. Box <david.e.box@linux.intel.com> Date: Fri Feb 11 17:32:50 2022 -0800 platform/x86: Add Intel Software Defined Silicon driver Intel Software Defined Silicon (SDSi) is a post manufacturing mechanism for activating additional silicon features. Features are enabled through a license activation process. The SDSi driver provides a per socket, sysfs attribute interface for applications to perform 3 main provisioning functions: 1. Provision an Authentication Key Certificate (AKC), a key written to internal NVRAM that is used to authenticate a capability specific activation payload. 2. Provision a Capability Activation Payload (CAP), a token authenticated using the AKC and applied to the CPU configuration to activate a new feature. 3. Read the SDSi State Certificate, containing the CPU configuration state. The operations perform function specific mailbox commands that forward the requests to SDSi hardware to perform authentication of the payloads and enable the silicon configuration (to be made available after power cycling). The SDSi device itself is enumerated as an auxiliary device from the intel_vsec driver and as such has a build dependency on CONFIG_INTEL_VSEC. Link: https://github.com/intel/intel-sdsi Signed-off-by: David E. Box <david.e.box@linux.intel.com> Reviewed-by: Mark Gross <markgross@kernel.org> Link: https://lore.kernel.org/r/20220212013252.1293396-2-david.e.box@linux.intel.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: David Arcari <darcari@redhat.com>
2022-04-05 13:39:19 +00:00
depends on INTEL_VSEC
depends on X86_64
help
This driver enables access to the Intel On Demand (formerly Software
Defined Silicon) interface used to provision silicon features with an
authentication certificate and capability license.
platform/x86: Add Intel Software Defined Silicon driver Bugzilla: https://bugzilla.redhat.com/1971952 commit 2546c60004309ede8e2d1d5341e0decd90e057bf Author: David E. Box <david.e.box@linux.intel.com> Date: Fri Feb 11 17:32:50 2022 -0800 platform/x86: Add Intel Software Defined Silicon driver Intel Software Defined Silicon (SDSi) is a post manufacturing mechanism for activating additional silicon features. Features are enabled through a license activation process. The SDSi driver provides a per socket, sysfs attribute interface for applications to perform 3 main provisioning functions: 1. Provision an Authentication Key Certificate (AKC), a key written to internal NVRAM that is used to authenticate a capability specific activation payload. 2. Provision a Capability Activation Payload (CAP), a token authenticated using the AKC and applied to the CPU configuration to activate a new feature. 3. Read the SDSi State Certificate, containing the CPU configuration state. The operations perform function specific mailbox commands that forward the requests to SDSi hardware to perform authentication of the payloads and enable the silicon configuration (to be made available after power cycling). The SDSi device itself is enumerated as an auxiliary device from the intel_vsec driver and as such has a build dependency on CONFIG_INTEL_VSEC. Link: https://github.com/intel/intel-sdsi Signed-off-by: David E. Box <david.e.box@linux.intel.com> Reviewed-by: Mark Gross <markgross@kernel.org> Link: https://lore.kernel.org/r/20220212013252.1293396-2-david.e.box@linux.intel.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: David Arcari <darcari@redhat.com>
2022-04-05 13:39:19 +00:00
To compile this driver as a module, choose M here: the module will
be called intel_sdsi.
platform/x86/intel: TPMI domain id and CPU mapping JIRA: https://issues.redhat.com/browse/RHEL-46074 commit 17ca2780458cdb0afc623e3432b1977847da3d15 Author: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Date: Tue May 28 10:34:57 2024 +0300 platform/x86/intel: TPMI domain id and CPU mapping Each TPMI power domain includes a group of CPUs. Several power management settings in this case applicable to a group of CPUs. There can be several power domains in a CPU package. So, provide interfaces for: - Get power domain id for a Linux CPU - Get mask of Linux CPUs in a power domain Hardware Punit uses different CPU numbering, which is not based on APIC (Advanced Programmable Interrupt Controller) CPU numbering. The Linux CPU numbering is based on APIC CPU numbering. Some PM features like Intel Speed Select, the CPU core mask provided by the hardware is based on the Punit CPU numbering. To use the core mask, this mask needs to be converted to a Linux CPUs mask. So, provide interfaces for: - Convert to a Linux CPU number from a Punit CPU number - Convert to a Punit CPU number from a Linux CPU number On each CPU online, MSR 0x54 is used to read the mapping and stores in a per cpu array. Create a hash for faster searching of a Linux CPU number from a Punit CPU number. Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> [tero.kristo: minor updates] Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Tero Kristo <tero.kristo@linux.intel.com> Link: https://lore.kernel.org/r/20240528073457.497816-1-tero.kristo@linux.intel.com Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: David Arcari <darcari@redhat.com>
2024-12-04 14:43:53 +00:00
config INTEL_TPMI_POWER_DOMAINS
tristate
platform/x86/intel: Intel TPMI enumeration driver Bugzilla: https://bugzilla.redhat.com/2177011 commit 47731fd2865fcbcd0b9cdbe90fcd6583c9559631 Author: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Date: Wed Feb 1 17:07:35 2023 -0800 platform/x86/intel: Intel TPMI enumeration driver The TPMI (Topology Aware Register and PM Capsule Interface) provides a flexible, extendable and PCIe enumerable MMIO interface for PM features. For example Intel RAPL (Running Average Power Limit) provides a MMIO interface using TPMI. This has advantage over traditional MSR (Model Specific Register) interface, where a thread needs to be scheduled on the target CPU to read or write. Also the RAPL features vary between CPU models, and hence lot of model specific code. Here TPMI provides an architectural interface by providing hierarchical tables and fields, which will not need any model specific implementation. The TPMI interface uses a PCI VSEC structure to expose the location of MMIO region. This VSEC structure is present in the PCI configuration space of the Intel Out-of-Band (OOB) device, which is handled by the Intel VSEC driver. The Intel VSEC driver parses VSEC structures present in the PCI configuration space of the given device and creates an auxiliary device object for each of them. In particular, it creates an auxiliary device object representing TPMI that can be bound by an auxiliary driver. Introduce a TPMI driver that will bind to the TPMI auxiliary device object created by the Intel VSEC driver. The TPMI specification defines a PFS (PM Feature Structure) table. This table is present in the TPMI MMIO region. The starting address of PFS is derived from the tBIR (Bar Indicator Register) and "Address" field from the VSEC header. Each TPMI PM feature has one entry in the PFS with a unique TPMI ID and its access details. The TPMI driver creates device nodes for the supported PM features. The names of the devices created by the TPMI driver start with the "intel_vsec.tpmi-" prefix which is followed by a specific name of the given PM feature (for example, "intel_vsec.tpmi-rapl.0"). The device nodes are create by using interface "intel_vsec_add_aux()" provided by the Intel VSEC driver. Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Link: https://lore.kernel.org/r/20230202010738.2186174-5-srinivas.pandruvada@linux.intel.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: David Arcari <darcari@redhat.com>
2023-09-05 17:46:41 +00:00
config INTEL_TPMI
tristate "Intel Topology Aware Register and PM Capsule Interface (TPMI)"
depends on INTEL_VSEC
depends on X86_64
platform/x86/intel: TPMI domain id and CPU mapping JIRA: https://issues.redhat.com/browse/RHEL-46074 commit 17ca2780458cdb0afc623e3432b1977847da3d15 Author: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Date: Tue May 28 10:34:57 2024 +0300 platform/x86/intel: TPMI domain id and CPU mapping Each TPMI power domain includes a group of CPUs. Several power management settings in this case applicable to a group of CPUs. There can be several power domains in a CPU package. So, provide interfaces for: - Get power domain id for a Linux CPU - Get mask of Linux CPUs in a power domain Hardware Punit uses different CPU numbering, which is not based on APIC (Advanced Programmable Interrupt Controller) CPU numbering. The Linux CPU numbering is based on APIC CPU numbering. Some PM features like Intel Speed Select, the CPU core mask provided by the hardware is based on the Punit CPU numbering. To use the core mask, this mask needs to be converted to a Linux CPUs mask. So, provide interfaces for: - Convert to a Linux CPU number from a Punit CPU number - Convert to a Punit CPU number from a Linux CPU number On each CPU online, MSR 0x54 is used to read the mapping and stores in a per cpu array. Create a hash for faster searching of a Linux CPU number from a Punit CPU number. Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> [tero.kristo: minor updates] Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Tero Kristo <tero.kristo@linux.intel.com> Link: https://lore.kernel.org/r/20240528073457.497816-1-tero.kristo@linux.intel.com Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: David Arcari <darcari@redhat.com>
2024-12-04 14:43:53 +00:00
select INTEL_TPMI_POWER_DOMAINS
platform/x86/intel: Intel TPMI enumeration driver Bugzilla: https://bugzilla.redhat.com/2177011 commit 47731fd2865fcbcd0b9cdbe90fcd6583c9559631 Author: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Date: Wed Feb 1 17:07:35 2023 -0800 platform/x86/intel: Intel TPMI enumeration driver The TPMI (Topology Aware Register and PM Capsule Interface) provides a flexible, extendable and PCIe enumerable MMIO interface for PM features. For example Intel RAPL (Running Average Power Limit) provides a MMIO interface using TPMI. This has advantage over traditional MSR (Model Specific Register) interface, where a thread needs to be scheduled on the target CPU to read or write. Also the RAPL features vary between CPU models, and hence lot of model specific code. Here TPMI provides an architectural interface by providing hierarchical tables and fields, which will not need any model specific implementation. The TPMI interface uses a PCI VSEC structure to expose the location of MMIO region. This VSEC structure is present in the PCI configuration space of the Intel Out-of-Band (OOB) device, which is handled by the Intel VSEC driver. The Intel VSEC driver parses VSEC structures present in the PCI configuration space of the given device and creates an auxiliary device object for each of them. In particular, it creates an auxiliary device object representing TPMI that can be bound by an auxiliary driver. Introduce a TPMI driver that will bind to the TPMI auxiliary device object created by the Intel VSEC driver. The TPMI specification defines a PFS (PM Feature Structure) table. This table is present in the TPMI MMIO region. The starting address of PFS is derived from the tBIR (Bar Indicator Register) and "Address" field from the VSEC header. Each TPMI PM feature has one entry in the PFS with a unique TPMI ID and its access details. The TPMI driver creates device nodes for the supported PM features. The names of the devices created by the TPMI driver start with the "intel_vsec.tpmi-" prefix which is followed by a specific name of the given PM feature (for example, "intel_vsec.tpmi-rapl.0"). The device nodes are create by using interface "intel_vsec_add_aux()" provided by the Intel VSEC driver. Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Link: https://lore.kernel.org/r/20230202010738.2186174-5-srinivas.pandruvada@linux.intel.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: David Arcari <darcari@redhat.com>
2023-09-05 17:46:41 +00:00
help
The Intel Topology Aware Register and PM Capsule Interface (TPMI),
provides enumerable MMIO interface for power management features.
This driver creates devices, so that other PM feature driver can
be loaded for PM specific feature operation.
To compile this driver as a module, choose M here: the module will
be called intel_vsec_tpmi.
platform/x86/intel: Move intel_pmt from MFD to Auxiliary Bus Bugzilla: https://bugzilla.redhat.com/2058806 commit a3c8f906ed5fc1d4895b5e1a5c6ad6e942d6c0ca Author: David E. Box <david.e.box@linux.intel.com> Date: Tue Dec 7 17:50:12 2021 -0800 platform/x86/intel: Move intel_pmt from MFD to Auxiliary Bus Intel Platform Monitoring Technology (PMT) support is indicated by presence of an Intel defined PCIe Designated Vendor Specific Extended Capabilities (DVSEC) structure with a PMT specific ID. The current MFD implementation creates child devices for each PMT feature, currently telemetry, watcher, and crashlog. However DVSEC structures may also be used by Intel to indicate support for other features. The Out Of Band Management Services Module (OOBMSM) uses DVSEC to enumerate several features, including PMT. In order to support them it is necessary to modify the intel_pmt driver to handle the creation of the child devices more generically. To that end, modify the driver to create child devices for any VSEC/DVSEC features on supported devices (indicated by PCI ID). Additionally, move the implementation from MFD to the Auxiliary bus. VSEC/DVSEC features are really multifunctional PCI devices, not platform devices as MFD was designed for. Auxiliary bus gives more flexibility by allowing the definition of custom structures that can be shared between associated auxiliary devices and the parent device. Also, rename the driver from intel_pmt to intel_vsec to better reflect the purpose. This series also removes the current runtime pm support which was not complete to begin with. None of the current devices require runtime pm. However the support will be replaced when a device is added that requires it. Reviewed-by: Mark Gross <markgross@kernel.org> Acked-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: David E. Box <david.e.box@linux.intel.com> Link: https://lore.kernel.org/r/20211208015015.891275-4-david.e.box@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: David Arcari <darcari@redhat.com>
2022-03-15 15:01:15 +00:00
config INTEL_VSEC
tristate "Intel Vendor Specific Extended Capabilities Driver"
depends on PCI
select AUXILIARY_BUS
help
Adds support for feature drivers exposed using Intel PCIe VSEC and
DVSEC.
To compile this driver as a module, choose M here: the module will
be called intel_vsec.
config INTEL_ISHTP_ECLITE
tristate "Intel ISHTP eclite controller Driver"
depends on INTEL_ISH_HID
depends on ACPI
help
This driver is for accessing the PSE (Programmable Service Engine) -
an Embedded Controller like IP - using ISHTP (Integrated Sensor Hub
Transport Protocol) to get battery, thermal and UCSI (USB Type-C
Connector System Software Interface) related data from the platform.
Users who don't want to use discrete Embedded Controller on Intel's
Elkhartlake platform can leverage this integrated solution of
ECLite which is part of PSE subsystem.
To compile this driver as a module, choose M here: the module
will be called intel_ishtp_eclite.
config INTEL_RST
tristate "Intel Rapid Start Technology Driver"
depends on ACPI
help
This driver provides support for modifying parameters on systems
equipped with Intel's Rapid Start Technology. When put in an ACPI
sleep state, these devices will wake after either a configured
timeout or when the system battery reaches a critical state,
automatically copying memory contents to disk. On resume, the
firmware will copy the memory contents back to RAM and resume the OS
as usual.
config INTEL_SMARTCONNECT
tristate "Intel Smart Connect disabling driver"
depends on ACPI
help
Intel Smart Connect is a technology intended to permit devices to
update state by resuming for a short period of time at regular
intervals. If a user enables this functionality under Windows and
then reboots into Linux, the system may remain configured to resume
on suspend. In the absence of any userspace to support it, the system
will then remain awake until something triggers another suspend.
This driver checks to determine whether the device has Intel Smart
Connect enabled, and if so disables it.
config INTEL_PLR_TPMI
tristate "Intel SoC TPMI Power Limit Reasons driver"
depends on INTEL_TPMI
help
This driver provides the TPMI power limit reasons status information
via debugfs files.
config INTEL_TURBO_MAX_3
bool "Intel Turbo Boost Max Technology 3.0 enumeration driver"
depends on X86_64 && SCHED_MC_PRIO
help
This driver reads maximum performance ratio of each CPU and set up
the scheduler priority metrics. In this way scheduler can prefer
CPU with higher performance to schedule tasks.
This driver is only required when the system is not using Hardware
P-States (HWP). In HWP mode, priority can be read from ACPI tables.
endif # X86_PLATFORM_DRIVERS_INTEL