summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)Author
2024-10-28iio: accel: kxcjk-1013: Start using chip_info variables instead of enumAndy Shevchenko
Instead of having a enum and keeping IDs as driver data pointers, just have a chip_info struct per supported device. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://patch.msgid.link/20241024191200.229894-12-andriy.shevchenko@linux.intel.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-10-28iio: accel: kxcjk-1013: Rename kxcjk1013_infoAndy Shevchenko
Rename kxcjk1013_info to kxcjk1013_iio_info in preparatory of further cleaning up changes. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://patch.msgid.link/20241024191200.229894-11-andriy.shevchenko@linux.intel.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-10-28iio: accel: kxcjk-1013: Use local variable for regsAndy Shevchenko
Use local variable for regs in preparatory of further cleaning up changes. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://patch.msgid.link/20241024191200.229894-10-andriy.shevchenko@linux.intel.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-10-28iio: accel: kxcjk-1013: Switch from CONFIG_PM guards to pm_ptr() etcAndy Shevchenko
Letting the compiler remove these functions when the kernel is built without CONFIG_PM support is simpler and less error prone than the use of #ifdef based config guards. Removing instances of this approach from IIO also stops them being copied into new drivers. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://patch.msgid.link/20241024191200.229894-9-andriy.shevchenko@linux.intel.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-10-28iio: accel: kxcjk-1013: Revert "Add support for KX022-1020"Andy Shevchenko
The mentioned change effectively broke the ODR startup timeouts settungs for KX023-1025 case. Let's revert it for now and see how we can handle it with the better approach after switching the driver to use data structure instead of enum. This reverts commit d5cbe1502043124ff8af8136b80f93758c4a61e0. Fixes: d5cbe1502043 ("iio: accel: kxcjk-1013: Add support for KX022-1020") Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://patch.msgid.link/20241024191200.229894-8-andriy.shevchenko@linux.intel.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-10-28iio: accel: kxcjk-1013: Remove redundant I²C IDAndy Shevchenko
The ACPI IDs are defined in the respective ID tables. Puting them to the I²C ID legacy table has no meaning. Remove that ID. Fixes: 3bfa74f86006 ("iio:kxcjk-1013: Add support for SMO8500 device") Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://patch.msgid.link/20241024191200.229894-7-andriy.shevchenko@linux.intel.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-10-28iio: acpi: Add iio_get_acpi_device_name_and_data() helper functionAndy Shevchenko
A few drivers duplicate the code to retrieve ACPI device instance name. Some of them want an associated driver data as well. In order of deduplication introduce the common helper functions. Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://patch.msgid.link/20241024191200.229894-6-andriy.shevchenko@linux.intel.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-10-28iio: acpi: Improve iio_read_acpi_mount_matrix()Andy Shevchenko
By using ACPI_HANDLE() the handler argument can be retrieved directly. Replace ACPI_COMPANION() + dereference with ACPI_HANDLE(). Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://patch.msgid.link/20241024191200.229894-5-andriy.shevchenko@linux.intel.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-10-28iio: imu: inv_mpu6050: Replace strange way of checking type of enumerationAndy Shevchenko
When device is enumerated via ACPI the respective device node is of ACPI device type. Use that to check for ACPI enumeration, rather than calling for full match which is O(n) vs. O(1) for the regular check. Acked-by: Jean-Baptiste Maneyrol <jean-baptiste.maneyrol@tdk.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://patch.msgid.link/20241024191200.229894-4-andriy.shevchenko@linux.intel.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-10-28iio: adc: pac1934: Replace strange way of checking type of enumerationAndy Shevchenko
When device is enumerated via ACPI the respective device node is of ACPI device type. Use that to check for ACPI enumeration, rather than calling for full match which is O(n) vs. O(1) for the regular check. Reviewed-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Marius Cristea <marius.cristea@microchip.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://patch.msgid.link/20241024191200.229894-3-andriy.shevchenko@linux.intel.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-10-28iio: magnetometer: bmc150: Drop dead code from the driverAndy Shevchenko
Since there is no ACPI IDs for this driver to be served for, drop dead ACPI bits from it completely. Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://patch.msgid.link/20241024191200.229894-2-andriy.shevchenko@linux.intel.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-10-28iio: adc: ad7606: add support for AD760{7,8,9} partsAlexandru Ardelean
The AD7607, AD7608 and AD7609 are some older parts of the AD7606 family. They are hardware-only, meaning that they don't have any registers accessible via SPI or Parallel interface. They are more similar to the AD7605-4 part, which is supported by the 'ad7606' driver, and are configurable via GPIOs. Like the AD7605-4 part, all 3 parts have 2 CONVST (Conversion Start) pins (CONVST A and CONVST B). But in practice, these should be tied together to make reading of samples easier via a serial line. The AD7607 has an 14-bit resolution and AD7608 & AD7609 have an 18-bit resolution. The main difference between the AD7608 & AD7609 is that the AD7609 has a larger range (±10V & ±20V) vs the ±5V & ±10V ranges for AD7608. However, unlike AD7605-4 part, these 3 parts have oversampling which is configurable (like for the AD7606 in HW-mode) via GPIOs. Datasheet: https://www.analog.com/media/en/technical-documentation/data-sheets/ad7607.pdf Datasheet: https://www.analog.com/media/en/technical-documentation/data-sheets/ad7608.pdf Datasheet: https://www.analog.com/media/en/technical-documentation/data-sheets/ad7609.pdf Signed-off-by: Alexandru Ardelean <aardelean@baylibre.com> Reviewed-by: David Lechner <dlechner@baylibre.com> Link: https://patch.msgid.link/20241025095939.271811-6-aardelean@baylibre.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-10-28iio: adc: ad7606: rework scale-available to be staticAlexandru Ardelean
The main driver for this change is the AD7607 part, which has a scale of "1.220703" for the ±10V range. The AD7607 has a resolution of 14-bits. So, just adding the scale-available list for that part would require some quirks to handle just that scale value. But to do it more neatly, the best approach is to rework the scale available lists to have the same format as it is returned to userspace. That way, we can also get rid of the allocation for the 'scale_avail_show' array. Signed-off-by: Alexandru Ardelean <aardelean@baylibre.com> Reviewed-by: David Lechner <dlechner@baylibre.com> Link: https://patch.msgid.link/20241025095939.271811-4-aardelean@baylibre.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-10-28iio: adc: ad7606: use realbits for sign-extending in scan_directAlexandru Ardelean
Currently the 'ad7606' driver supports parts with 18 and 16 bits resolutions. But when adding support for AD7607 (which has a 14-bit resolution) we should check for the 'realbits' field, to be able to sign-extend correctly. Signed-off-by: Alexandru Ardelean <aardelean@baylibre.com> Reviewed-by: David Lechner <dlechner@baylibre.com> Link: https://patch.msgid.link/20241025095939.271811-3-aardelean@baylibre.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-10-28iio: adc: ad7606: fix/persist oversampling_ratio settingAlexandru Ardelean
When the mutexes were reworked to guards, the caching of the oversampling_ratio values was removed by accident. The main effect of this change is that, after setting the oversampling_ratio value, reading it back would result in the initial value (of 1). The value would get sent to the device correctly though. Fixes 2956979dbd0d: ("iio: adc: ad7606: switch mutexes to guard") Signed-off-by: Alexandru Ardelean <aardelean@baylibre.com> Reviewed-by: David Lechner <dlechner@baylibre.com> Link: https://patch.msgid.link/20241025095939.271811-2-aardelean@baylibre.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-10-28iio: imu: bmi270: Provide chip info as configuration structureJustin Weiss
Prepare the bmi270 driver to support similar devices like the bmi260. Signed-off-by: Justin Weiss <justin@justinweiss.com> Link: https://patch.msgid.link/20241020220011.212395-3-justin@justinweiss.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-10-28iio: imu: bmi270: Remove unused FREQUENCY / SCALE attributesJustin Weiss
These attributes are not currently wired up, and will always return EINVAL. Fixes: 3ea51548d6b2 ("iio: imu: Add i2c driver for bmi270 imu") Signed-off-by: Justin Weiss <justin@justinweiss.com> Link: https://patch.msgid.link/20241020220011.212395-2-justin@justinweiss.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-10-28iio: adc: Remove "default n" entriesAndy Shevchenko
Linus already once did that for PDx86, don't repeat our mistakes. TL;DR: 'n' *is* the default 'default'. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://patch.msgid.link/20241022143600.3314241-1-andriy.shevchenko@linux.intel.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-10-28iio: light: Remove "default n" entriesAndy Shevchenko
Linus already once did that for PDx86, don't repeat our mistakes. TL;DR: 'n' *is* the default 'default'. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://patch.msgid.link/20241022143605.3314275-1-andriy.shevchenko@linux.intel.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-10-28iio: accel: replace s64 __aligned(8) with aligned_s64Jonathan Cameron
e4ca0e59c394 ("types: Complement the aligned types with signed 64-bit one") introduced aligned_s64. Use it for all IIO accelerometer drivers. Reviewed-by: Nuno Sa <nuno.sa@analog.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Matti Vaittinen <mazziesaccount@gmail.com> Link: https://patch.msgid.link/20241020180720.496327-1-jic23@kernel.org Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-10-28iio: light: opt3001: add support for TI's opt3002 light sensorEmil Gedenryd
TI's opt3002 light sensor shares most properties with the opt3001 model, with the exception of supporting a wider spectrum range. Add support for TI's opt3002 by extending the TI opt3001 driver. Datasheet: https://www.ti.com/product/OPT3002 Signed-off-by: Emil Gedenryd <emil.gedenryd@axis.com> Link: https://patch.msgid.link/20241003-add_opt3002-v4-2-c550dc4591b4@axis.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-10-28drivers: iio: adc: add support for ad777x familyRamona Alexandra Nechita
Add support for AD7770, AD7771, AD7779 ADCs. The device is capable of sending out data both on DOUT lines interface,as on the SDO line. The driver currently implements only the SDO data streaming mode. SPI communication is used alternatively for accessing registers and streaming data. Register accesses are protected by crc8. Signed-off-by: Ramona Alexandra Nechita <ramona.nechita@analog.com> Link: https://patch.msgid.link/20241014143204.30195-4-ramona.nechita@analog.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-10-28drm/i915/xe2lpd: Update C20 algorithm to include tx_miscGustavo Sousa
There has been an update to the BSpec in which we need to set tx_misc=0x5 field for C20 TX Context programming for HDMI TMDS for Xe2_LPD and newer. That field is mapped to the bits 7:0 of SRAM_GENERIC_<A/B>_TX_CNTX_CFG_1, which in turn translates to tx[1] of our state struct. Update the algorithm to reflect this change. v2: - Fix Bspec reference (Sai Teja) - Use struct intel_display instead of drm_i915_private. (Jani) - Use the correct bit width for C20_PHY_TX_MISC_MASK. (Jani) Bspec: 74491 Cc: Dnyaneshwar Bhadane <dnyaneshwar.bhadane@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Sai Teja Pottumuttu <sai.teja.pottumuttu@intel.com> #v1 Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241023153352.144146-3-gustavo.sousa@intel.com
2024-10-28drm/i915/cx0: Pass crtc_state to intel_c20_compute_hdmi_tmds_pll()Gustavo Sousa
The variable crtc_state already contains everything that intel_c20_compute_hdmi_tmds_pll() needs. Simplify the function's signature by passing that struct instead of separate variables. Suggested-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241023153352.144146-2-gustavo.sousa@intel.com
2024-10-28cpufreq/amd-pstate: Align offline flow of shared memory and MSR based systemsDhananjay Ugwekar
Set min_perf to lowest_perf for shared memory systems, similar to the MSR based systems. Signed-off-by: Dhananjay Ugwekar <Dhananjay.Ugwekar@amd.com> Reviewed-by: Mario Limonciello <mario.limonciello@amd.com> Reviewed-by: Gautham R. Shenoy <gautham.shenoy@amd.com> Link: https://lore.kernel.org/r/20241023102108.5980-5-Dhananjay.Ugwekar@amd.com Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
2024-10-28cpufreq/amd-pstate: Call cppc_set_epp_perf in the reenable functionDhananjay Ugwekar
The EPP value being set in perf_ctrls.energy_perf is not being propagated to the shared memory, fix that. Signed-off-by: Dhananjay Ugwekar <Dhananjay.Ugwekar@amd.com> Reviewed-by: Mario Limonciello <mario.limonciello@amd.com> Reviewed-by: Perry Yuan <perry.yuan@amd.com> Reviewed-by: Gautham R. Shenoy <gautham.shenoy@amd.com> Link: https://lore.kernel.org/r/20241023102108.5980-4-Dhananjay.Ugwekar@amd.com Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
2024-10-28cpufreq/amd-pstate: Do not attempt to clear MSR_AMD_CPPC_ENABLEDhananjay Ugwekar
MSR_AMD_CPPC_ENABLE is a write once register, i.e. attempting to clear it is futile, it will not take effect. Hence, return if disable (0) argument is passed to the msr_cppc_enable() Signed-off-by: Dhananjay Ugwekar <Dhananjay.Ugwekar@amd.com> Reviewed-by: Mario Limonciello <mario.limonciello@amd.com> Reviewed-by: Gautham R. Shenoy <gautham.shenoy@amd.com> Link: https://lore.kernel.org/r/20241023102108.5980-3-Dhananjay.Ugwekar@amd.com Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
2024-10-28cpufreq/amd-pstate: Rename functions that enable CPPCDhananjay Ugwekar
Explicitly rename functions that enable CPPC as *_cppc_*. Signed-off-by: Dhananjay Ugwekar <Dhananjay.Ugwekar@amd.com> Reviewed-by: Mario Limonciello <mario.limonciello@amd.com> Reviewed-by: Perry Yuan <perry.yuan@amd.com> Link: https://lore.kernel.org/r/20241023102108.5980-2-Dhananjay.Ugwekar@amd.com Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
2024-10-28cpufreq/amd-pstate-ut: Add fix for min freq unit testMario Limonciello
commit 642aff3964b0f ("cpufreq/amd-pstate: Set the initial min_freq to lowest_nonlinear_freq") changed the initial minimum frequency to lowest nonlinear frequency, but the unit tests weren't updated and now fail. Update them to match this same change. Fixes: 642aff3964b0f ("cpufreq/amd-pstate: Set the initial min_freq to lowest_nonlinear_freq") Link: https://lore.kernel.org/r/20241017173439.4924-1-mario.limonciello@amd.com Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
2024-10-28amd-pstate: Switch to amd-pstate by default on some Server platformsSwapnil Sapkal
Currently the default cpufreq driver for all the AMD EPYC servers is acpi-cpufreq. Going forward, switch to amd-pstate as the default driver on the AMD EPYC server platforms with CPU family 0x1A or higher. The default mode will be active mode. Testing shows that amd-pstate with active mode and performance governor provides comparable or better performance per-watt against acpi-cpufreq + performance governor. Likewise, amd-pstate with active mode and powersave governor with the energy_performance_preference=power (EPP=255) provides comparable or better performance per-watt against acpi-cpufreq + schedutil governor for a wide range of workloads. Users can still revert to using acpi-cpufreq driver on these platforms with the "amd_pstate=disable" kernel commandline parameter. Signed-off-by: Swapnil Sapkal <swapnil.sapkal@amd.com> Signed-off-by: Gautham R. Shenoy <gautham.shenoy@amd.com> Reviewed-by: Mario Limonciello <mario.limonciello@amd.com> Link: https://lore.kernel.org/r/20241021101836.9047-3-gautham.shenoy@amd.com Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
2024-10-28amd-pstate: Set min_perf to nominal_perf for active mode performance govGautham R. Shenoy
The amd-pstate driver sets CPPC_REQ.min_perf to CPPC_REQ.max_perf when in active mode with performance governor. Typically CPPC_REQ.max_perf is set to CPPC.highest_perf. This causes frequency throttling on power-limited platforms which causes performance regressions on certain classes of workloads. Hence, set the CPPC_REQ.min_perf to the CPPC.nominal_perf or CPPC_REQ.max_perf, whichever is lower of the two. Fixes: ffa5096a7c33 ("cpufreq: amd-pstate: implement Pstate EPP support for the AMD processors") Signed-off-by: Gautham R. Shenoy <gautham.shenoy@amd.com> Reviewed-by: Mario Limonciello <mario.limonciello@amd.com> Link: https://lore.kernel.org/r/20241021101836.9047-2-gautham.shenoy@amd.com Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
2024-10-28cpufreq/amd-pstate: Remove the redundant amd_pstate_set_driver() callDhananjay Ugwekar
amd_pstate_set_driver() is called twice, once in amd_pstate_init() and once as part of amd_pstate_register_driver(). Move around code and eliminate the redundancy. Signed-off-by: Dhananjay Ugwekar <Dhananjay.Ugwekar@amd.com> Reviewed-by: Mario Limonciello <mario.limonciello@amd.com> Link: https://lore.kernel.org/r/20241017100528.300143-5-Dhananjay.Ugwekar@amd.com Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
2024-10-28cpufreq/amd-pstate: Remove the switch case in amd_pstate_init()Dhananjay Ugwekar
Replace the switch case with a more readable if condition. Signed-off-by: Dhananjay Ugwekar <Dhananjay.Ugwekar@amd.com> Reviewed-by: Mario Limonciello <mario.limonciello@amd.com> Link: https://lore.kernel.org/r/20241017100528.300143-4-Dhananjay.Ugwekar@amd.com Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
2024-10-28cpufreq/amd-pstate: Call amd_pstate_set_driver() in amd_pstate_register_driver()Dhananjay Ugwekar
Replace a similar chunk of code in amd_pstate_register_driver() with amd_pstate_set_driver() call. Signed-off-by: Dhananjay Ugwekar <Dhananjay.Ugwekar@amd.com> Reviewed-by: Mario Limonciello <mario.limonciello@amd.com> Link: https://lore.kernel.org/r/20241017100528.300143-3-Dhananjay.Ugwekar@amd.com Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
2024-10-28cpufreq/amd-pstate: Call amd_pstate_register() in amd_pstate_init()Dhananjay Ugwekar
Replace a similar chunk of code in amd_pstate_init() with amd_pstate_register() call. Suggested-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Dhananjay Ugwekar <Dhananjay.Ugwekar@amd.com> Reviewed-by: Mario Limonciello <mario.limonciello@amd.com> Link: https://lore.kernel.org/r/20241017100528.300143-2-Dhananjay.Ugwekar@amd.com Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
2024-10-28cpufreq/amd-pstate: Set the initial min_freq to lowest_nonlinear_freqDhananjay Ugwekar
According to the AMD architectural programmer's manual volume 2 [1], in section "17.6.4.1 CPPC_CAPABILITY_1" lowest_nonlinear_perf is described as "Reports the most energy efficient performance level (in terms of performance per watt). Above this threshold, lower performance levels generally result in increased energy efficiency. Reducing performance below this threshold does not result in total energy savings for a given computation, although it reduces instantaneous power consumption". So lowest_nonlinear_perf is the most power efficient performance level, and going below that would lead to a worse performance/watt. Also, setting the minimum frequency to lowest_nonlinear_freq (instead of lowest_freq) allows the CPU to idle at a higher frequency which leads to more time being spent in a deeper idle state (as trivial idle tasks are completed sooner). This has shown a power benefit in some systems, in other systems, power consumption has increased but so has the throughput/watt. Modify the initial policy_data->min set by cpufreq-core to lowest_nonlinear_freq, in the ->verify() callback. Also set the cpudata->req[0] to FREQ_QOS_MIN_DEFAULT_VALUE (i.e. 0), so that it also gets overriden by the check in verify function. Link: https://www.amd.com/content/dam/amd/en/documents/processor-tech-docs/programmer-references/24593.pdf [1] Signed-off-by: Dhananjay Ugwekar <Dhananjay.Ugwekar@amd.com> Reviewed-by: Mario Limonciello <mario.limonciello@amd.com> Link: https://lore.kernel.org/r/20241017053927.25285-3-Dhananjay.Ugwekar@amd.com Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
2024-10-28cpufreq/amd-pstate: Remove the redundant verify() functionDhananjay Ugwekar
Merge the two verify() callback functions and rename the cpufreq_policy_data argument for better readability. Signed-off-by: Dhananjay Ugwekar <Dhananjay.Ugwekar@amd.com> Reviewed-by: Mario Limonciello <mario.limonciello@amd.com> Reviewed-by: Gautham R. Shenoy <gautham.shenoy@amd.com> Link: https://lore.kernel.org/r/20241017053927.25285-2-Dhananjay.Ugwekar@amd.com Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
2024-10-28cpufreq/amd-pstate: Drop needless EPP initializationMario Limonciello
The EPP value doesn't need to be cached to the CPPC request in amd_pstate_epp_update_limit() because it's passed as an argument at the end to amd_pstate_set_epp() and stored at that time. Reviewed-by: Gautham R. Shenoy <gautham.shenoy@amd.com> Reviewed-by: Perry Yuan <perry.yuan@amd.com> Tested-by: Dhananjay Ugwekar <dhananjay.ugwekar@amd.com> Link: https://lore.kernel.org/r/20241012174519.897-4-mario.limonciello@amd.com Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
2024-10-28cpufreq/amd-pstate: Use amd_pstate_update_min_max_limit() for EPP limitsMario Limonciello
When the EPP updates are set the maximum capable frequency for the CPU is used to set the upper limit instead of that of the policy. Adjust amd_pstate_epp_update_limit() to reuse policy calculation code from amd_pstate_update_min_max_limit(). Reviewed-by: Gautham R. Shenoy <gautham.shenoy@amd.com> Reviewed-by: Perry Yuan <perry.yuan@amd.com> Tested-by: Dhananjay Ugwekar <dhananjay.ugwekar@amd.com> Link: https://lore.kernel.org/r/20241012174519.897-3-mario.limonciello@amd.com Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
2024-10-28cpufreq/amd-pstate: Don't update CPPC request in amd_pstate_cpu_boost_update()Mario Limonciello
When boost is changed the CPPC value is changed in amd_pstate_cpu_boost_update() but then changed again when refresh_frequency_limits() and all it's callbacks occur. The first is a pointless write, so instead just update the limits for the policy and let the policy refresh anchor everything properly. Fixes: c8c68c38b56f ("cpufreq: amd-pstate: initialize core precision boost state") Reviewed-by: Gautham R. Shenoy <gautham.shenoy@amd.com> Reviewed-by: Perry Yuan <perry.yuan@amd.com> Tested-by: Dhananjay Ugwekar <dhananjay.ugwekar@amd.com> Link: https://lore.kernel.org/r/20241012174519.897-2-mario.limonciello@amd.com Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
2024-10-28cpufreq/amd-pstate: Fix non kerneldoc commentMario Limonciello
The comment for amd_cppc_supported() isn't meant to be kernel doc. Fixes: cb817ec6673b7 ("cpufreq: amd-pstate: show CPPC debug message if CPPC is not supported") Link: https://lore.kernel.org/r/20240905162351.1345560-1-superm1@kernel.org Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
2024-10-28cpufreq/amd-pstate: Rename MSR and shared memory specific functionsDhananjay Ugwekar
Existing function names "cppc_*" and "pstate_*" for shared memory and MSR based systems are not intuitive enough, replace them with "shmem_*" and "msr_*" respectively. Signed-off-by: Dhananjay Ugwekar <Dhananjay.Ugwekar@amd.com> Reviewed-by: Mario Limonciello <mario.limonciello@amd.com> Link: https://lore.kernel.org/r/20240917091434.10685-1-Dhananjay.Ugwekar@amd.com Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
2024-10-28RDMA/bnxt_re: Fix access flags for MR and QP modifyHongguang Gao
Access flag definition in MR and QP is different in FW. Currently both reg/bind MR and modify/query QP uses the same flags. Add a different function to map the QP access flags for newer adapters. Signed-off-by: Kalesh AP <kalesh-anakkur.purayil@broadcom.com> Signed-off-by: Hongguang Gao <hongguang.gao@broadcom.com> Reviewed-by: Damodharam Ammepalli <damodharam.ammepalli@broadcom.com> Signed-off-by: Selvin Xavier <selvin.xavier@broadcom.com> Link: https://patch.msgid.link/1729065346-1364-6-git-send-email-selvin.xavier@broadcom.com Signed-off-by: Leon Romanovsky <leon@kernel.org>
2024-10-28RDMA/bnxt_re: Add support for modify_device hookKalesh AP
Adds support for modify_device in the driver for node desc changes. Signed-off-by: Kalesh AP <kalesh-anakkur.purayil@broadcom.com> Signed-off-by: Selvin Xavier <selvin.xavier@broadcom.com> Link: https://patch.msgid.link/1729065346-1364-5-git-send-email-selvin.xavier@broadcom.com Signed-off-by: Leon Romanovsky <leon@kernel.org>
2024-10-28RDMA/bnxt_re: Add support for CQ rx coalescingChandramohan Akula
RoCE message rate performance is heavily degraded without the use of cq coalescing. With proper coalescing, message rates get better. Furthermore, coalescing significantly reduces contention on the PCIe Root Complex/Memory subsystems. Add the changes to configure CQ rx colascing parameters based on adapter revision when CQ is created. Signed-off-by: Chandramohan Akula <chandramohan.akula@broadcom.com> Signed-off-by: Kalesh AP <kalesh-anakkur.purayil@broadcom.com> Signed-off-by: Selvin Xavier <selvin.xavier@broadcom.com> Link: https://patch.msgid.link/1729065346-1364-4-git-send-email-selvin.xavier@broadcom.com Signed-off-by: Leon Romanovsky <leon@kernel.org>
2024-10-28RDMA/bnxt_re: Add support for optimized modify QPKalesh AP
Modify QP improvements are for state transitions from INIT -> RTR and RTR -> RTS. In order to support the Modify QP Optimization feature, the driver is expected to check for the feature support in the CMDQ_QUERY_FUNC and register its support for this feature with the FW in CMDQ_INITIALIZE_FIRMWARE. Additionally, the driver is required to specify the new fields and attribute masks for the transitions as follows: 1. INIT -> RTR: - New fields: srq_used, type. - enable srq_used when RC QP is configured to use SRQ. - set the type based on the QP type. - Mandatory masks: - RC: CMDQ_MODIFY_QP_MODIFY_MASK_ACCESS, CMDQ_MODIFY_QP_MODIFY_MASK_PKEY - UD QP and QP1: CMDQ_MODIFY_QP_MODIFY_MASK_PKEY, CMDQ_MODIFY_QP_MODIFY_MASK_QKEY 2. RTR -> RTS: - New fields: type - set the type based on the QP type. - Mandatory masks: - RC: CMDQ_MODIFY_QP_MODIFY_MASK_ACCESS - UD QP and QP1: CMDQ_MODIFY_QP_MODIFY_MASK_QKEY Reviewed-by: Saravanan Vajravel <saravanan.vajravel@broadcom.com> Reviewed-by: Tushar Rane <tushar.rane@broadcom.com> Signed-off-by: Kalesh AP <kalesh-anakkur.purayil@broadcom.com> Signed-off-by: Selvin Xavier <selvin.xavier@broadcom.com> Link: https://patch.msgid.link/1729065346-1364-2-git-send-email-selvin.xavier@broadcom.com Signed-off-by: Leon Romanovsky <leon@kernel.org>
2024-10-28drm/sched: Mark scheduler work queues with WQ_MEM_RECLAIMMatthew Brost
drm_gpu_scheduler.submit_wq is used to submit jobs, jobs are in the path of dma-fences, and dma-fences are in the path of reclaim. Mark scheduler work queue with WQ_MEM_RECLAIM to ensure forward progress during reclaim; without WQ_MEM_RECLAIM, work queues cannot make forward progress during reclaim. v2: - Fixes tags (Philipp) - Reword commit message (Philipp) Cc: Luben Tuikov <ltuikov89@gmail.com> Cc: Danilo Krummrich <dakr@kernel.org> Cc: Philipp Stanner <pstanner@redhat.com> Cc: stable@vger.kernel.org Fixes: 34f50cc6441b ("drm/sched: Use drm sched lockdep map for submit_wq") Fixes: a6149f039369 ("drm/sched: Convert drm scheduler to use a work queue rather than kthread") Signed-off-by: Matthew Brost <matthew.brost@intel.com> Acked-by: Nirmoy Das <nirmoy.das@intel.com> Reviewed-by: Philipp Stanner <pstanner@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241023235917.1836428-1-matthew.brost@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2024-10-28perf/marvell: Marvell PEM performance monitor supportGowthami Thiagarajan
PCI Express Interface PMU includes various performance counters to monitor the data that is transmitted over the PCIe link. The counters track various inbound and outbound transactions which includes separate counters for posted/non-posted/completion TLPs. Also, inbound and outbound memory read requests along with their latencies can also be monitored. Address Translation Services(ATS)events such as ATS Translation, ATS Page Request, ATS Invalidation along with their corresponding latencies are also supported. The performance counters are 64 bits wide. For instance, perf stat -e ib_tlp_pr <workload> tracks the inbound posted TLPs for the workload. Co-developed-by: Linu Cherian <lcherian@marvell.com> Signed-off-by: Linu Cherian <lcherian@marvell.com> Signed-off-by: Gowthami Thiagarajan <gthiagarajan@marvell.com> Link: https://lore.kernel.org/r/20241028055309.17893-1-gthiagarajan@marvell.com Signed-off-by: Will Deacon <will@kernel.org>
2024-10-28clk: tegra: use clamp() in tegra_bpmp_clk_determine_rate()Li Zetao
When it needs to get a value within a certain interval, using clamp() makes the code easier to understand than min(max()). Signed-off-by: Li Zetao <lizetao1@huawei.com> Link: https://lore.kernel.org/r/20240830012344.603704-1-lizetao1@huawei.com Acked-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2024-10-28perf/arm_pmuv3: Add PMUv3.9 per counter EL0 access controlRob Herring (Arm)
Armv8.9/9.4 PMUv3.9 adds per counter EL0 access controls. Per counter access is enabled with the UEN bit in PMUSERENR_EL1 register. Individual counters are enabled/disabled in the PMUACR_EL1 register. When UEN is set, the CR/ER bits control EL0 write access and must be set to disable write access. With the access controls, the clearing of unused counters can be skipped. KVM also configures PMUSERENR_EL1 in order to trap to EL2. UEN does not need to be set for it since only PMUv3.5 is exposed to guests. Signed-off-by: Rob Herring (Arm) <robh@kernel.org> Link: https://lore.kernel.org/r/20241002184326.1105499-1-robh@kernel.org Signed-off-by: Will Deacon <will@kernel.org>