kernel/linux.git/drivers/platform/x86/intel/Makefile, branch v6.19.11

platform/x86/intel: Introduce Intel Elkhart Lake PSE I/O

2025-11-19T13:08:51+00:00

Intel Elkhart Lake Programmable Service Engine (PSE) includes two PCI devices that expose two different capabilities of GPIO and Timed I/O as a single PCI function through shared MMIO with below layout. GPIO: 0x0000 - 0x1000 TIO: 0x1000 - 0x2000 This driver enumerates the PCI parent device and creates auxiliary child devices for these capabilities. The actual functionalities are provided by their respective auxiliary drivers. Signed-off-by: Raag Jadav Acked-by: Ilpo Järvinen Link: https://lore.kernel.org/r/20251112034040.457801-2-raag.jadav@intel.com Signed-off-by: Bartosz Golaszewski

platform/x86: intel: Add 'intel' prefix to the modules automatically

2024-10-31T09:42:24+00:00

Rework Makefile to add 'intel' prefix to the modules automatically. This removes a lot of boilerplate code in it and also makes robust against mistypos in the prefix. Signed-off-by: Andy Shevchenko Link: https://lore.kernel.org/r/20241016105950.785820-2-andriy.shevchenko@linux.intel.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen

platform/x86/intel/tpmi: Add new auxiliary driver for performance limits

2024-05-31T13:32:09+00:00

Add new auxiliary driver that exposes the SoC performance limit reasons via debugfs interface. Reviewed-by: Andy Shevchenko Reviewed-by: Ilpo Järvinen Signed-off-by: Tero Kristo Link: https://lore.kernel.org/r/20240527133400.483634-5-tero.kristo@linux.intel.com Signed-off-by: Ilpo Järvinen

platform/x86/intel: TPMI domain id and CPU mapping

2024-05-31T13:31:23+00:00

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 [tero.kristo: minor updates] Reviewed-by: Andy Shevchenko Reviewed-by: Ilpo Järvinen Signed-off-by: Tero Kristo Link: https://lore.kernel.org/r/20240528073457.497816-1-tero.kristo@linux.intel.com Signed-off-by: Ilpo Järvinen

platform/x86: Add intel_bytcrc_pwrsrc driver

2023-03-16T13:42:30+00:00

Add a new driver for the power-, wake- and reset-source functionality of the Bay Trail (BYT) version of the Crystal Cove PMIC. The main functionality here is detecting which power-sources (USB / DC in / battery) are active. This is normally exposed to userspace as a power_supply class charger device with an online sysfs attribute. But if a charger is online or not is already exposed on BYT-CRC devices through either an ACPI AC power_supply device, or through a native driver for the battery charger chip (e.g. a BQ24292i). So instead of adding duplicate info under the power_supply class this driver exports the info through debugfs and likewise adds debugfs files for the reset- and wake-source info / registers. Despite this driver only exporting debugfs bits it is still useful to have this driver because it clears the wake- and reset-source registers after reading them. Not clearing these can have undesirable side-effects. Specifically if the WAKESRC register contains 0x01 (wake by powerbutton) on reboot then the firmware on some tablets turns the reboot into a poweroff. I guess this may be necessary to make long power-presses turn into a poweroff somehow? Signed-off-by: Hans de Goede Link: https://lore.kernel.org/r/20230303221928.285477-1-hdegoede@redhat.com

platform/x86/intel: Intel TPMI enumeration driver

2023-02-06T12:47:30+00:00

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 Reviewed-by: Pierre-Louis Bossart Acked-by: Rafael J. Wysocki Link: https://lore.kernel.org/r/20230202010738.2186174-5-srinivas.pandruvada@linux.intel.com Reviewed-by: Hans de Goede Signed-off-by: Hans de Goede

platform/x86/intel/ifs: Add stub driver for In-Field Scan

2022-05-12T13:35:29+00:00

Cloud Service Providers that operate fleets of servers have reported [1] occasions where they can detect that a CPU has gone bad due to effects like electromigration, or isolated manufacturing defects. However, that detection method is A/B testing seemingly random application failures looking for a pattern. In-Field Scan (IFS) is a driver for a platform capability to load a crafted 'scan image' to run targeted low level diagnostics outside of the CPU's architectural error detection capabilities. Stub version of driver just does initial part of check for the IFS feature. MSR_IA32_CORE_CAPS must enumerate the presence of the MSR_INTEGRITY_CAPS MSR. [1]: https://www.youtube.com/watch?v=QMF3rqhjYuM Reviewed-by: Dan Williams Signed-off-by: Tony Luck Acked-by: Hans de Goede Reviewed-by: Greg Kroah-Hartman Reviewed-by: Thomas Gleixner Link: https://lore.kernel.org/r/20220506225410.1652287-5-tony.luck@intel.com Signed-off-by: Hans de Goede

platform/x86/intel/uncore-freq: Move to uncore-frequency folder

2022-02-17T12:20:30+00:00

Move the current driver from platform/x86/intel/uncore-frequency.c to platform/x86/intel/uncore-frequency/uncore-frequency.c. No functional changes are expected. Signed-off-by: Srinivas Pandruvada Acked-by: Rafael J. Wysocki Link: https://lore.kernel.org/r/20220204000306.2517447-2-srinivas.pandruvada@linux.intel.com Signed-off-by: Hans de Goede

platform/x86: Add Intel Software Defined Silicon driver

2022-02-14T10:45:20+00:00

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 Reviewed-by: Mark Gross Link: https://lore.kernel.org/r/20220212013252.1293396-2-david.e.box@linux.intel.com Reviewed-by: Hans de Goede Signed-off-by: Hans de Goede

platform/x86: intel_cht_int33fe: Move to intel directory

2022-02-11T09:52:56+00:00

Now that there is only 1 c-file left of the intel_cht_int33fe code, move it to the intel directory instead of it having its own int33fe sub-directory. Note this also renames the module from intel_cht_int33fe_typec to intel_chtwc_int33fe, to better match the names of other PMIC related modules like the intel_chtdc_ti_pwrbtn module. Signed-off-by: Hans de Goede Link: https://lore.kernel.org/r/20220206220220.88491-4-hdegoede@redhat.com