- 04 Sep, 2024 1 commit
-
-
Andres Salomon authored
The Dell BIOS allows you to set custom charging modes, which is useful in particular for extending battery life. This adds support for tweaking those various settings from Linux via sysfs knobs. One might, for example, have their laptop plugged into power at their desk the vast majority of the time and choose fairly aggressive battery-saving settings (eg, only charging once the battery drops below 50% and only charging up to 80%). When leaving for a trip, it would be more useful to instead switch to a standard charging mode (top off at 100%, charge any time power is available). Rebooting into the BIOS to change the charging mode settings is a hassle. For the Custom charging type mode, we reuse the common charge_control_{start,end}_threshold sysfs power_supply entries. The BIOS also has a bunch of other charging modes (with varying levels of usefulness), so this also adds a 'charge_type' sysfs entry that maps the standard values to Dell-specific ones. This work is based on a patch by Perry Yuan <perry_yuan@dell.com> and Limonciello Mario <Mario_Limonciello@Dell.com> submitted back in 2020. Hans de Goede: s/charge_type/charge_types/ since charge_types_show() used the new charge_types power-supply property output format. Signed-off-by:Andres Salomon <dilinger@queued.net> Reviewed-by:
Pali Rohár <pali@kernel.org> Link: https://lore.kernel.org/r/20240820033005.09e03af1@5400Reviewed-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
-
- 26 Aug, 2024 2 commits
-
-
Andy Shevchenko authored
Use modern string_choices API instead of manually determining the output using ternary operator. Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by:
Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Link: https://lore.kernel.org/r/20240821120458.3702655-1-andriy.shevchenko@linux.intel.comReviewed-by:
-
Srinivas Pandruvada authored
The scope of uncore control is per power domain with TPMI. There are two types of processor topologies can be presented by CPUID extended topology leaf irrespective of the hardware architecture: 1. A die is not enumerated in CPUID. In this case there is only one die in a package is visible. In this case there can be multiple power domains in a single die. 2. A power domain in a package is enumerated as a die in CPUID. So there is one power domain per die. To allow die level controls, the current implementation creates a root domain and aggregates all information from power domains in it. This is well suited for configuration 1 above. But for configuration 2 above, the root domain will present the same information as present by power domain. So, no use of aggregating. To check the configuration, call topology_max_dies_per_package(). If it is more than one, avoid creating root domain. Signed-off-by:
Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Reviewed-by:
-
- 24 Aug, 2024 1 commit
-
-
Kuppuswamy Sathyanarayanan authored
In commit # 0a3e4e94 ("platform/x86/intel/ifs: Add SBAF test image loading support"), the documentation for "Structural Based Functional Test at Field (SBAF)" had an incomplete underline. This resulted in the following build warning: Documentation/arch/x86/ifs:2: drivers/platform/x86/intel/ifs/ifs.h:131: WARNING: Title underline too short. Fix it by extending the dotted lines to match the length of the title. Fixes: 0a3e4e94 ("platform/x86/intel/ifs: Add SBAF test image loading support") Reported-by:
Stephen Rothwell <sfr@canb.auug.org.au> Closes: https://lore.kernel.org/lkml/20240820134354.2aec355d@canb.auug.org.au/T/#uSigned-off-by:
Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com> Reviewed-by:
Jithu Joseph <jithu.joseph@intel.com> Link: https://lore.kernel.org/r/20240823184337.2923179-1-sathyanarayanan.kuppuswamy@linux.intel.comSigned-off-by:
-
- 19 Aug, 2024 10 commits
-
-
Matthias Fetzer authored
Fan control on the E531 is done using the ACPI methods FANG and FANW. The correct parameters and register values were found by analyzing EC firmware as well as DSDT. This has been tested on my Thinkpad Edge E531 (6885CTO, BIOS HEET52WW 1.33). Signed-off-by:
Matthias Fetzer <kontakt@matthias-fetzer.de> Reviewed-by:
-
Richard Fitzgerald authored
Change the Kconfig dependency so that it doesn't require both I2C and SPI subsystems to be built. Make a few small changes to the code so that the code for a bus is only called if the bus is being built. When SPI support was added to serial-multi-instantiate it created a dependency that both CONFIG_I2C and CONFIG_SPI must be enabled. Typically they are, but there's no reason why this should be a requirement. A specific kernel build could have only I2C devices or only SPI devices. It should be possible to use serial-multi-instantiate if only I2C or only SPI is enabled. The dependency formula used is: depends on (I2C && !SPI) || (!I2C && SPI) || (I2C && SPI) The advantage of this approach is that if I2C=m or SPI=m then SERIAL_MULTI_INSTANTIATE is limited to n/m. Signed-off-by:
Richard Fitzgerald <rf@opensource.cirrus.com> Link: https://lore.kernel.org/r/20240814132939.308696-1-rf@opensource.cirrus.comReviewed-by:
-
Konrad Dybcio authored
Add basic support for registering the aggregator module on Device Tree- based platforms. These include at least three generations of Qualcomm Snapdragon-based Surface devices: - SC8180X / SQ1 / SQ2: Pro X, - SC8280XP / SQ3: Devkit 2023, Pro 9 - X Elite: Laptop 7 / Pro11 Thankfully, the aggregators on these seem to be configured in an identical way, which allows for using these settings as defaults and no DT properties need to be introduced (until that changes, anyway). Based on the work done by Maximilian Luz, largely rewritten. Signed-off-by:
Konrad Dybcio <quic_kdybcio@quicinc.com> Reviewed-by:
Maximilian Luz <luzmaximilian@gmail.com> Tested-by:
-
Konrad Dybcio authored
Add bindings for the Surface System Aggregator Module (SAM/SSAM), the Microsoft Surface-standard Embedded Controller, used on both x86- and Qualcomm-based devices. It provides a plethora of functions, depending on what's wired up to it. That includes but is not limited to: fan control, keyboard/touchpad support, thermal sensors, power control, special buttons, tablet mode. Signed-off-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20240814-topic-sam-v3-2-a84588aad233@quicinc.comSigned-off-by:
-
Konrad Dybcio authored
There exist some embedded controllers (like Microsoft SAM found on Surface devices or Apple Oscar found on old iPhones) that connect to the host device via serial. Allow that class of devices to exist under serial interface controller nodes. Reviewed-by:
Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by:
-
Armin Wolf authored
The LEGX0820 ACPI device is expected to provide a custom operation region: OperationRegion (XIN1, 0x8F, Zero, 0x04B0) Field (XIN1, AnyAcc, Lock, Preserve) { DMSG, 8, HDAP, 8, Offset (0x03), AFNM, 8, Offset (0x10), P80B, 8, P81B, 8, P82B, 8, P83B, 8, P84B, 8, P85B, 8, P86B, 8, P87B, 8, Offset (0x20), DTTM, 8, TMP1, 8, LTP1, 8, HTP1, 8, TMP2, 8, LTP2, 8, HTP2, 8, Offset (0x3E8), PMSG, 1600 } The PMSG field is used by AML code to log debug messages when DMSG is true. Since those debug messages are already logged using the standard ACPI Debug object, we set DMSG unconditionally to 0x00 and ignore any writes to PMSG. The TMPx, LTPx, HTPx and AFNM fields are used to inform the driver when the temperature/(presumably) trip points/fan mode changes. This only happens when the DTTM flag is set. Unfortunately we have to implement support for this operation region because the AML codes uses code constructs like this one: If (((\_SB.XINI.PLAV != Zero) && (\_SB.XINI.DTTM != Zero))) The PLAV field gets set to 1 when the driver registers its address space handler, so by default XIN1 should not be accessed. However ACPI does not use short-circuit evaluation when evaluating logical conditions. This causes the DTTM field to be accessed even when PLAV is 0, which results in an ACPI error. Since this check happens inside various thermal-related ACPI control methods, various thermal zone become unusable since any attempt to read their temperature results in an ACPI error. Fix this by providing support for this operation region. I suspect that the problem does not happen under Windows (which seemingly does not use short-circuit evaluation either) because the necessary driver comes preinstalled with the machine. Tested-by:Chris <ghostwind@gmail.com> Signed-off-by:
Armin Wolf <W_Armin@gmx.de> Link: https://lore.kernel.org/r/20240813022903.20567-1-W_Armin@gmx.deReviewed-by:
-
Shyam Sundar S K authored
The SMU metrics table has been revised for the 1AH family series. Introduce a new metrics table structure to retrieve comprehensive metrics information from the PMFW. This information will be utilized by the PMF driver to adjust system thermals. Reviewed-by:
Patil Rajesh Reddy <Patil.Reddy@amd.com> Signed-off-by:
Shyam Sundar S K <Shyam-sundar.S-k@amd.com> Link: https://lore.kernel.org/r/20240819063404.378061-2-Shyam-sundar.S-k@amd.comReviewed-by:
-
Shyam Sundar S K authored
The CPU ID macros are needed by the Smart PC builder. Therefore, transfer the CPU ID macros from core.c to the common PMF header file. Reviewed-by:
-
Shyam Sundar S K authored
The APMF function 14 (Notify Smart PC Solution Updates) allows the BIOS (AMD/OEM) to be informed about the outputs of custom Smart PC policies. Enhance the PMF driver to invoke APMF function 14 when these custom policy outputs are triggered. Co-developed-by:
-
Ilpo Järvinen authored
pmc_for_each_mode() takes i (index) variable name as a parameter but the loop index is not used by any of the callers. Make the index variable internal to pmc_for_each_mode(). This also changes the loop logic such that ->lpm_en_modes[] is never read beyond num_lpm_modes. Signed-off-by:
-
- 12 Aug, 2024 21 commits
-
-
Gergo Koteles authored
Since moving ymc_trigger_ec from lenovo-ymc to ideapad-laptop, only the latter uses these definitions and functions. Move them back to source file. Signed-off-by:
Gergo Koteles <soyer@irl.hu> Reviewed-by:
-
Hans de Goede authored
Merge 'platform-drivers-x86-v6.11-3' into review-hans to avoid conflicts when merging further ideapad-laptop patches. platform-drivers-x86 for v6.11-3 Fixes: - ideapad-laptop / lenovo-ymc: Protect VPC calls with a mutex - amd/pmf: Query HPD data also when ALS is disabled The following is an automated shortlog grouped by driver: amd/pmf: - Fix to Update HPD Data When ALS is Disabled ideapad-laptop: - add a mutex to synchronize VPC commands - introduce a generic notification chain - move ymc_trigger_ec from lenovo-ymc
-
Jithu Joseph authored
Add tracing support for the SBAF IFS tests, which may be useful for debugging systems that fail these tests. Log details like test content batch number, SBAF bundle ID, program index and the exact errors or warnings encountered by each HT thread during the test. Reviewed-by:
Ashok Raj <ashok.raj@intel.com> Reviewed-by:
Tony Luck <tony.luck@intel.com> Reviewed-by:
Steven Rostedt (Google) <rostedt@goodmis.org> Signed-off-by:
-
Jithu Joseph authored
In a core, the SBAF test engine is shared between sibling CPUs. An SBAF test image contains multiple bundles. Each bundle is further composed of subunits called programs. When a SBAF test (for a particular core) is triggered by the user, each SBAF bundle from the loaded test image is executed sequentially on all the threads on the core using the stop_core_cpuslocked mechanism. Each bundle execution is initiated by writing to MSR_ACTIVATE_SBAF. SBAF test bundle execution may be aborted when an interrupt occurs or if the CPU does not have enough power budget for the test. In these cases the kernel restarts the test from the aborted bundle. SBAF execution is not retried if the test fails or if the test makes no forward progress after 5 retries. Reviewed-by:
-
Jithu Joseph authored
Structural Based Functional Test at Field (SBAF) is a new type of testing that provides comprehensive core test coverage complementing existing IFS tests like Scan at Field (SAF) or ArrayBist. SBAF device will appear as a new device instance (intel_ifs_2) under /sys/devices/virtual/misc. The user interaction necessary to load the test image and test a particular core is the same as the existing scan test (intel_ifs_0). During the loading stage, the driver will look for a file named ff-mm-ss-<batch02x>.sbft in the /lib/firmware/intel/ifs_2 directory. The hardware interaction needed for loading the image is similar to SAF, with the only difference being the MSR addresses used. Reuse the SAF image loading code, passing the SBAF-specific MSR addresses via struct ifs_test_msrs in the driver device data. Unlike SAF, the SBAF test image chunks are further divided into smaller logical entities called bundles. Since the SBAF test is initiated per bundle, cache the maximum number of bundles in the current image, which is used for iterating through bundles during SBAF test execution. Reviewed-by:
-
Kuppuswamy Sathyanarayanan authored
IFS tests such as Scan at Field (SAF) or Structural Based Functional Test at Field (SBAF), require the user to load a test image. The image loading process is similar across these tests, with the only difference being MSR addresses used. To reuse the code between these tests, remove the hard coding of MSR addresses and allow the driver to pass the MSR addresses per IFS test (via driver device data). Add a new structure named "struct ifs_test_msrs" to specify the test-specific MSR addresses. Each IFS test will provide this structure, enabling them to reuse the common code. This is a preliminary patch in preparation for the addition of SBAF support. Reviewed-by:
-
Srinivas Pandruvada authored
After commit '1630dc62 ("platform/x86: ISST: Add model specific loading for common module")' isst_misc_reg() and isst_misc_unreg() can be simplified. Since these functions are only called during module_init() and module_exit() respectively, there is no contention while calling misc_register()/misc_deregister or isst_if_cpu_info_init()/ isst_if_cpu_info_exit(). Hence remove mutex and reference counting. Signed-off-by:
-
Thomas Zimmermann authored
Replace FB_BLANK_ constants with their counterparts from the backlight subsystem. The values are identical, so there's no change in functionality or semantics. Signed-off-by:
Thomas Zimmermann <tzimmermann@suse.de> Cc: Corentin Chary <corentin.chary@gmail.com> Cc: Hans de Goede <hdegoede@redhat.com> Cc: "Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com> Link: https://lore.kernel.org/r/20240731125220.1147348-11-tzimmermann@suse.deReviewed-by:
-
Thomas Zimmermann authored
Replace FB_BLANK_ constants with their counterparts from the backlight subsystem. The values are identical, so there's no change in functionality or semantics. Signed-off-by:
-
Thomas Zimmermann authored
Replace FB_BLANK_ constants with their counterparts from the backlight subsystem. The values are identical, so there's no change in functionality or semantics. Signed-off-by:
-
Thomas Zimmermann authored
Replace FB_BLANK_ constants with their counterparts from the backlight subsystem. The values are identical, so there's no change in functionality or semantics. Signed-off-by:
Jonathan Woithe <jwoithe@just42.net> Link: https://lore.kernel.org/r/20240731125220.1147348-8-tzimmermann@suse.deReviewed-by:
-
Thomas Zimmermann authored
Replace FB_BLANK_ constants with their counterparts from the backlight subsystem. The values are identical, so there's no change in functionality or semantics. Signed-off-by:
-
Thomas Zimmermann authored
Replace FB_BLANK_ constants with their counterparts from the backlight subsystem. The values are identical, so there's no change in functionality or semantics. Signed-off-by:
-
Thomas Zimmermann authored
Replace FB_BLANK_ constants with their counterparts from the backlight subsystem. The values are identical, so there's no change in functionality or semantics. Signed-off-by:
-
Thomas Zimmermann authored
Replace FB_BLANK_ constants with their counterparts from the backlight subsystem. The values are identical, so there's no change in functionality or semantics. Signed-off-by:
-
Thomas Zimmermann authored
Replace FB_BLANK_ constants with their counterparts from the backlight subsystem. The values are identical, so there's no change in functionality or semantics. Signed-off-by:
-
Thomas Zimmermann authored
Replace FB_BLANK_ constants with their counterparts from the backlight subsystem. The values are identical, so there's no change in functionality or semantics. Signed-off-by:
-
David E. Box authored
PMT providers may require device specific actions before their telemetry may be read. If the read_telem() is assigned, call it instead of memcpy_fromio() and return. Since this needs to be done in multiple locations, add pmt_telem_read_mmio() as a wrapper function to perform this and any other needed checks. Reviewed-by:
Michael J. Ruhl <michael.j.ruhl@intel.com> Signed-off-by:
David E. Box <david.e.box@linux.intel.com> Link: https://lore.kernel.org/r/20240725122346.4063913-4-michael.j.ruhl@intel.comSigned-off-by:
-
David E. Box authored
Some PMT providers require device specific actions before their telemetry can be read. Provide assignable PMT read callbacks to allow providers to perform those actions. Reviewed-by:
-
David E. Box authored
Some drivers outside of PDX86 need access to the vsec header. Move it to include/linux to make it easier to include. Reviewed-by:
-
Kane Chen authored
While debugging runtime s0ix, we do need to check which required IPs are not power gated. This patch adds code to show live substate status vs requirements in sys/kernel/debug/pmc_core/substate_requirements to help runtime s0ix debug. Signed-off-by:
Kane Chen <kane.chen@intel.com> Link: https://lore.kernel.org/r/20240719122807.3853292-1-kane.chen@intel.comReviewed-by:
-
- 08 Aug, 2024 4 commits
-
-
Gergo Koteles authored
Calling VPC commands consists of several VPCW and VPCR ACPI calls. These calls and their results can get mixed up if they are called simultaneously from different threads, like acpi notify handler, sysfs, debugfs, notification chain. The commit e2ffcda1 ("ACPI: OSL: Allow Notify () handlers to run on all CPUs") made the race issues much worse than before it but some races were possible even before that commit. Add a mutex to synchronize VPC commands. Fixes: e2ffcda1 ("ACPI: OSL: Allow Notify () handlers to run on all CPUs") Fixes: e82882cd ("platform/x86: Add driver for Yoga Tablet Mode switch") Signed-off-by:
-
Gergo Koteles authored
Some models need to trigger the EC after each YMC event for the yoga mode control to work properly. EC triggering consist of a VPC call from the lenovo-ymc module. Except for this, all VPC calls are in the ideapad-laptop module. Since ideapad-laptop has a notification chain, a new YMC_EVENT action can be added and triggered from the lenovo-ymc module. Then the ideapad-laptop can trigger the EC. If the triggering is in the ideapad-laptop module, then the ec_trigger module parameter should be there as well. Move the ymc_trigger_ec functionality and the ec_trigger module parameter to the ideapad-laptop module. Signed-off-by:
-
Gergo Koteles authored
There are several cases where a notification chain can simplify Lenovo WMI drivers. Add a generic notification chain into ideapad-laptop. Signed-off-by:
-
Shyam Sundar S K authored
If the Ambient Light Sensor (ALS) is disabled, the current code in the PMF driver does not query for Human Presence Detection (HPD) data in amd_pmf_get_sensor_info(). As a result, stale HPD data is used by PMF-TA to evaluate policy conditions, leading to unexpected behavior in the policy output actions. To resolve this issue, modify the PMF driver to query HPD data independently of ALS. Since user_present is a boolean, modify the current code to return true if the user is present and false if the user is away or if the sensor is not detected, and report this status to the PMF TA firmware accordingly. With this change, amd_pmf_get_sensor_info() now returns void instead of int. Fixes: cedecdba ("platform/x86/amd/pmf: Get ambient light information from AMD SFH driver") Co-developed-by:
-
- 05 Aug, 2024 1 commit
-
-
Arnd Bergmann authored
Linking an object file into multiple modules is not supported and causes a W=1 warning: scripts/Makefile.build:236: drivers/platform/x86/intel/int3472/Makefile: common.o is added to multiple modules: intel_skl_int3472_discrete intel_skl_int3472_tps68470 Split out the common part here into a separate module to make it more reliable. Fixes: a2f9fbc2 ("platform/x86: int3472: Split into 2 drivers") Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Link: https://lore.kernel.org/r/20240529095009.1895618-1-arnd@kernel.orgReviewed-by:
-
