- 06 Feb, 2023 7 commits
-
-
Srinivas Pandruvada authored
Add entry for TPMI (Topology Aware Register and PM Capsule Interface) driver. Signed-off-by:
Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Link: https://lore.kernel.org/r/20230202010738.2186174-8-srinivas.pandruvada@linux.intel.comReviewed-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
-
Srinivas Pandruvada authored
Add interface to get resources and platform data. This will avoid code duplication. These interfaces includes: - Get resource count - Get resource at an index Signed-off-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-7-srinivas.pandruvada@linux.intel.comReviewed-by:
-
Srinivas Pandruvada authored
There is one Intel Out-of-Band (OOB) PCI device per CPU package. Since TPMI feature is exposed via OOB PCI device, there will be multiple TPMI device instances on a multi CPU package system. There are several PM features, which needs to associate APIC based CPU package ID information to a TPMI instance. For example if Intel Speed Select feature requires control of a CPU package, it needs to identify right TPMI device instance. There is one special TPMI ID (ID = 0x81) in the PFS. The MMIO region of this TPMI ID points to a mapping table: - PCI Bus ID - PCI Device ID - APIC based Package ID This mapping information can be used by any PM feature driver which requires mapping from a CPU package to a TPMI device instance. Unlike other TPMI features, device node is not created for this feature ID (0x81). Instead store the mapping information as platform data, which is part of the per PCI device TPMI instance (struct intel_tpmi_info). Later the TPMI feature drivers can get the mapping information using an interface "tpmi_get_platform_data()" Signed-off-by:
-
Srinivas Pandruvada authored
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 authored
Add fields to struct intel_vsec_device, so that core module (which creates aux bus devices) can pass private data to the client drivers. For example there is one vsec device instance per CPU package. On a multi package system, this private data can be used to pass the package ID. This package id can be used by client drivers to change power settings for a specific CPU package by targeting MMIO space of the correct PCI device. Signed-off-by:
David E. Box <david.e.box@linux.intel.com> Link: https://lore.kernel.org/r/20230202010738.2186174-4-srinivas.pandruvada@linux.intel.comReviewed-by:
-
Srinivas Pandruvada authored
Remove static for intel_vsec_add_aux() and export this interface so that it can be used by other vsec related modules. This driver creates aux devices by parsing PCI-VSEC, which allows individual drivers to load on those devices. Those driver may further create more devices on aux bus by parsing the PCI MMIO region. For example, TPMI (Topology Aware Register and PM Capsule Interface) creates device nodes for power management features by parsing MMIO region. When TPMI driver creates devices, it can reuse existing function intel_vsec_add_aux() to create aux devices with TPMI device as the parent. Signed-off-by:
-
Srinivas Pandruvada authored
Add TPMI (Topology Aware Register and PM Capsule Interface) VSEC ID to create an aux device. This will allow TPMI driver to enumerate on this aux device. Signed-off-by:
-
- 03 Feb, 2023 23 commits
-
-
Hans de Goede authored
According to: https://github.com/intel/ipu6-drivers/blob/master/patch/int3472-support-independent-clock-and-LED-gpios-5.17%2B.patch Bits 31-24 of the _DSM pin entry integer value codes the active-value, that is the actual physical signal (0 or 1) which needs to be output on the pin to turn the sensor chip on (to make it active). So if bits 31-24 are 0 for a reset pin, then the actual value of the reset pin needs to be 0 to take the chip out of reset. IOW in this case the reset signal is active-high rather then the default active-low. And if bits 31-24 are 0 for a clk-en pin then the actual value of the clk pin needs to be 0 to enable the clk. So in this case the clk-en signal is active-low rather then the default active-high. IOW if bits 31-24 are 0 for a pin, then the default polarity of the pin is inverted. Add a check for this and also propagate this new polarity to the clock registration. Signed-off-by:
Sakari Ailus <sakari.ailus@linux.intel.com> Link: https://lore.kernel.org/r/20230127203729.10205-6-hdegoede@redhat.com
-
Hans de Goede authored
Move the requesting of the clk-enable GPIO to skl_int3472_register_clock() (and move the gpiod_put to unregister). This mirrors the GPIO handling in skl_int3472_register_regulator() and allows removing skl_int3472_map_gpio_to_clk() from discrete.c. Signed-off-by:
-
Hans de Goede authored
On some systems, e.g. the Lenovo ThinkPad X1 Yoga gen 7 and the ThinkPad X1 Nano gen 2 there is no clock-enable pin, triggering the: "No clk GPIO. The privacy LED won't work" warning and causing the privacy LED to not work. Fix this by modeling the privacy LED as a LED class device rather then integrating it with the registered clock. Note this relies on media subsys changes to actually turn the LED on/off when the sensor's v4l2_subdev's s_stream() operand gets called. Signed-off-by:
-
Hans de Goede authored
Add a helper function to map the type returned by the _DSM method to a function name + the default polarity for that function. And fold the INT3472_GPIO_TYPE_RESET and INT3472_GPIO_TYPE_POWERDOWN cases into a single generic case. This is a preparation patch for further GPIO mapping changes. Signed-off-by:
-
Hans de Goede authored
Make v4l2_async_register_subdev_sensor() try to get a privacy LED associated with the sensor and extend the call_s_stream() wrapper to enable/disable the privacy LED if found. This makes the core handle privacy LED control, rather then having to duplicate this code in all the sensor drivers. Suggested-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
Hans de Goede authored
Immutable branch from LEDs due for the v6.3 merge window
-
Deepak R Varma authored
Simplify code by using min_t helper macro for logical evaluation and value assignment. Use the _t variant of min macro since the variable types are not same. This issue is identified by coccicheck using the minmax.cocci file. Signed-off-by:
Deepak R Varma <drv@mailo.com> Link: https://lore.kernel.org/r/Y9QupEMPFoZpWIiM@ubun2204.myguest.virtualbox.orgReviewed-by:
-
Deepak R Varma authored
Simplify code by using min_t helper macro for logical evaluation and value assignment. Use the _t variant of min macro since the variable types are not same. This issue is identified by coccicheck using the minmax.cocci file. Signed-off-by:
Pali Rohár <pali@kernel.org> Link: https://lore.kernel.org/r/Y9P8debIztOZXazW@ubun2204.myguest.virtualbox.orgReviewed-by:
-
Armin Wolf authored
Until now, the dell-wmi-ddv driver needs to be manually patched and compiled to test compatibility with unknown DDV WMI interface versions. Add a module param to allow users to force loading even when a unknown interface version was detected. Since this might cause various unwanted side effects, the module param is marked as unsafe. Signed-off-by:
Armin Wolf <W_Armin@gmx.de> Link: https://lore.kernel.org/r/20230126194021.381092-5-W_Armin@gmx.deReviewed-by:
-
Armin Wolf authored
When the ACPI WMI interface returns a valid ACPI object which has the wrong type, then ENOMSG instead of EIO should be returned, since the WMI method was still successfully evaluated. Signed-off-by:
-
Armin Wolf authored
In several cases, the DDV WMI interface can return buffers with a length of zero. Return -ENODATA in such a case for proper error handling. Also replace some -EIO errors with more specialized ones. Signed-off-by:
-
Armin Wolf authored
While trying to solve a bugreport on bugzilla, i learned that some devices (for example the Dell XPS 17 9710) provide a more recent DDV WMI interface (version 3). Since the new interface version just adds an additional method, no code changes are necessary apart from whitelisting the version. Signed-off-by:
-
Srinivas Pandruvada authored
This release adds following change: - Minor fixes for coverity static analysis - Don't read cpufreq on offline CPUs - SST turbo-freq enable on auto mode when user disables SMT from kernel command line - Fix uncore frequency display - Set uncore frequency max/min limits on perf level change Signed-off-by:
-
Srinivas Pandruvada authored
When perf level is changed, uncore limits can change. Set the uncore limits via Linux uncore sysfs, when user changes perf level with -o option. Signed-off-by:
-
Zhang Rui authored
Need memory frequency quirk as Sapphire Rapids in Emerald Rapids. So add Emerald Rapids CPU model check in is_spr_platform(). Signed-off-by:
Zhang Rui <rui.zhang@intel.com> [srinivas.pandruvada@linux.intel.com: Subject, changelog and code edits] Signed-off-by:
-
Srinivas Pandruvada authored
Uncore P1 is not uncore minmum frequency. This is uncore base frequency. Correct display from uncore-frequency-min(MHz) to uncore-frequency-base(Mhz). To get uncore min frequency use mailbox command CONFIG_TDP_GET_RATIO_INFO. Use this mailbox to get uncore frequency limits when present. Signed-off-by:
-
Srinivas Pandruvada authored
When SMT is disabled from kernel command line, sibling CPUs still appears in the sysfs as offline CPUs. This is a problem when turbo-freq is enabled in auto mode. They are still assigned to CLOS value of 3 as they are still in the present CPU list. But they are not in the sibling list of a CPU. When the CPU is a high priority CPU, because of sibling it will be still set to CLOS to 3 as CLOS is assigned at core level not at CPU level. So, avoid setting CLOS 3 to offline CPU. Signed-off-by:
-
Srinivas Pandruvada authored
Due to some recent kernel changes, reading cpufreq attributes like scaling_max_freq on offline CPUs returns error. So avoid reading cpufreq attributes on offline CPUs. Signed-off-by:
-
Zhang Rui authored
strlen() and strtok() takes null-termimated strings as input. Make sure these strings are null-terminated before using them. Signed-off-by:
-
Zhang Rui authored
Remove the duplicate dup() invocation. Signed-off-by:
-
Zhang Rui authored
Add handling for open() failure case to make sure a valid file descriptor is passed to dup(). Signed-off-by:
-
Zhang Rui authored
variable 'non_block' is always 0, thus remove the variable and the handling for "non_block != 0" case. Signed-off-by:
-
Zhang Rui authored
struct isst_id *id is a pointer, comparing it with less than zero is wrong. The check is there to make sure the id->pkg and id->die is set to -1, when it is illegal or unavailable. Here comparing with MAX_PACKAGE_COUNT and MAX_DIE_PER_PACKAGE is sufficient. Hence remove the wrong check. Signed-off-by:
-
- 02 Feb, 2023 10 commits
-
-
Rishit Bansal authored
Follow up from https://lore.kernel.org/all/20230120221214.24426-1-rishitbansal0@gmail.com/ There is a "Win-Lock" key on HP Omen Laptops which supports enabling and disabling the Windows key, which trigger commands 0x21a4 and 0x121a4 respectively. Currently the hp-wmi driver throws warnings for this event. These can be ignored using KE_IGNORE as the functionality is handled by the keyboard firmware itself. Signed-off-by:
Rishit Bansal <rishitbansal0@gmail.com> Link: https://lore.kernel.org/r/20230123214150.62597-1-rishitbansal0@gmail.comReviewed-by:
-
Hans de Goede authored
The apple_gmux code no longer uses any symbols from the ACPI_VIDEO code, so that dependency can be dropped. Signed-off-by:
-
Andy Shevchenko authored
The acpi_evaluate_dsm_typed() provides a way to check the type of the object evaluated by _DSM call. Use it instead of open coded variant. Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20230119180904.78446-1-andriy.shevchenko@linux.intel.comReviewed-by:
-
Andy Shevchenko authored
The acpi_evaluate_dsm_typed() provides a way to check the type of the object evaluated by _DSM call. Use it instead of open coded variant. Signed-off-by:
Rajneesh Bhardwaj <irenic.rajneesh@gmail.com> Link: https://lore.kernel.org/r/20230118095440.41634-1-andriy.shevchenko@linux.intel.comReviewed-by:
-
Andy Shevchenko authored
The acpi_evaluate_dsm_typed() provides a way to check the type of the object evaluated by _DSM call. Use it instead of open coded variant. Signed-off-by:
Maximilian Luz <luzmaximilian@gmail.com> Link: https://lore.kernel.org/r/20230118093823.39679-1-andriy.shevchenko@linux.intel.comReviewed-by:
-
Maximilian Luz authored
We currently have a struct ssam_request_sync and a function ssam_request_sync(). While this is valid C, there are some downsides to it. One of these is that current Sphinx versions (>= 3.0) cannot disambiguate between the two (see disucssion and pull request linked below). It instead emits a "WARNING: Duplicate C declaration" and links for the struct and function in the resulting documentation link to the same entry (i.e. both to either function or struct documentation) instead of their respective own entries. While we could just ignore that and wait for a fix, there's also a point to be made that the current naming can be somewhat confusing when searching (e.g. via grep) or trying to understand the levels of abstraction at play: We currently have struct ssam_request_sync and associated functions ssam_request_sync_[alloc|free|init|wait|...]() operating on this struct. However, function ssam_request_sync() is one abstraction level above this. Similarly, ssam_request_sync_with_buffer() is not a function operating on struct ssam_request_sync, but rather a sibling to ssam_request_sync(), both using the struct under the hood. Therefore, rename the top level request functions: ssam_request_sync() -> ssam_request_do_sync() ssam_request_sync_with_buffer() -> ssam_request_do_sync_with_buffer() ssam_request_sync_onstack() -> ssam_request_do_sync_onstack() Link: https://lore.kernel.org/all/085e0ada65c11da9303d07e70c510dc45f21315b.1656756450.git.mchehab@kernel.org/ Link: https://github.com/sphinx-doc/sphinx/pull/8313Signed-off-by:
-
Maximilian Luz authored
The target ID of the base hub is currently set to KIP (keyboard/ peripherals). However, even though it manages such devices with the KIP target ID, the base hub itself is actually accessed via the SAM target ID. So set it accordingly. Note that the target ID of the hub can be chosen arbitrarily and does not directly correspond to any physical or virtual component of the EC. This change is only a code improvement intended for consistency and clarity, it does not fix an actual bug. Signed-off-by:
-
Maximilian Luz authored
Similar to the target category (TC), the target ID (TID) can be one value out of a small number of choices, given in enum ssam_ssh_tid. In the device ID macros, SSAM_SDEV() and SSAM_VDEV() we already use text expansion to, both, remove some textual clutter for the target category values and enforce that the value belongs to the known set. Now that we know the names for the target IDs, use the same trick for them as well. Also rename the SSAM_ANY_x macros to SSAM_SSH_x_ANY to better fit in. Signed-off-by:
Sebastian Reichel <sebastian.reichel@collabora.com> Link: https://lore.kernel.org/r/20221202223327.690880-9-luzmaximilian@gmail.comReviewed-by:
-
Maximilian Luz authored
Instead of hard-coding the target ID, use the respective enum ssam_ssh_tid value. Signed-off-by:
-
Maximilian Luz authored
Instead of hard-coding the target ID, use the respective enum ssam_ssh_tid value. Signed-off-by:
-
