summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2025-07-07pwm: twl-led: Drop driver local lockingUwe Kleine-König
The pwm core already serializes .apply(). twl6030's .request() and .free() are also already serialized against .apply() because there is only a single PWM. So the mutex doesn't add any additional protection and can be dropped. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com> Link: https://lore.kernel.org/r/c1c7f646190f7cb2fe43b10959aa8dade80cb79e.1750788649.git.u.kleine-koenig@baylibre.com Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
2025-07-07pwm: sun4i: Drop driver local lockingUwe Kleine-König
The pwm core serializes calls to .apply(), so the driver lock doesn't add any protection and can safely be dropped. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com> Link: https://lore.kernel.org/r/87b71c46b82b787959f0cea314d3010f16a50a29.1750788649.git.u.kleine-koenig@baylibre.com Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
2025-07-07pwm: sti: Drop driver local lockingUwe Kleine-König
The pwm core already serializes calls to .apply(), so the driver local mutex adds no protection and can be dropped. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com> Link: https://lore.kernel.org/r/7ad150e40b45d6cb16fee633dcd6390a49a327a1.1750788649.git.u.kleine-koenig@baylibre.com Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
2025-07-07pwm: microchip-core: Drop driver local lockingUwe Kleine-König
The pwm core already serializes .apply() and .get_state(), so the driver local lock is always free and adds no protection. Drop it. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com> Link: https://lore.kernel.org/r/6d6ef0376ea0058b040eec3b257e324493a083f1.1750788649.git.u.kleine-koenig@baylibre.com Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
2025-07-07pwm: lpc18xx-sct: Drop driver local lockingUwe Kleine-König
Both mutexes are only used in one function each. These functions are only called by the .apply() callback. As the .apply() calls are serialized by the core since commit 1cc2e1faafb3 ("pwm: Add more locking") the mutexes have no effect apart from runtime overhead. Drop them. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com> Reviewed-by: Vladimir Zapolskiy <vz@mleia.com> Link: https://lore.kernel.org/r/4f7a2da37adbfe4743564245119045826d86eca6.1750788649.git.u.kleine-koenig@baylibre.com Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
2025-07-07pwm: fsl-ftm: Drop driver local lockingUwe Kleine-König
The pwm core serializes calls to .apply(), so the driver local lock isn't needed for that. It only has the effect to serialize .apply() with .request() and .free() for a different PWM, and .request() and .free against each other. But given that .request and .free() only do a single regmap operation under the lock and regmap itself serializes register accesses, it might happen without the lock that the calls are interleaved now, but affecting different PWMs, so nothing bad can happen. So the mutex has no effect and can be dropped. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com> Link: https://lore.kernel.org/r/6b72104e5e1823170c7c9664189cc0f2ca5c2347.1750788649.git.u.kleine-koenig@baylibre.com Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
2025-07-07pwm: clps711x: Drop driver local lockingUwe Kleine-König
The pwm core serializes calls to .apply(), so the spinlock adds no additional protection. Disabling the irq is also irrelevant as the driver isn't an atomic one and so the callbacks cannot be called from atomic context. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com> Link: https://lore.kernel.org/r/d4931dc0c0d657d80722cfe7d97cb4fb4ccec90e.1750788649.git.u.kleine-koenig@baylibre.com Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
2025-07-07pwm: atmel: Drop driver local lockingUwe Kleine-König
The two functions making use of the lock are only called transitively from .apply(). Calls to .apply() are already serialized by the pwm core so the lock in the driver has no effect and can safely be dropped. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com> Link: https://lore.kernel.org/r/5ad3417aecd4dc6eca9699e21691e3725ea0bb87.1750788649.git.u.kleine-koenig@baylibre.com Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
2025-07-07pwm: argon-fan-hat: Add Argon40 Fan HAT supportMarek Vasut
Add trivial PWM driver for Argon40 Fan HAT, which is a RaspberryPi blower fan hat which can be controlled over I2C. Model this device as a PWM, so the pwm-fan can be attached to it and handle thermal zones and RPM management in a generic manner. Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org> Link: https://lore.kernel.org/r/20250629220757.936212-3-marek.vasut+renesas@mailbox.org Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
2025-07-07dt-bindings: pwm: argon40,fan-hat: Document Argon40 Fan HATMarek Vasut
Document trivial PWM on Argon40 Fan HAT, which is a RaspberryPi blower fan hat which can be controlled over I2C. Reviewed-by: Rob Herring (Arm) <robh@kernel.org> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org> Link: https://lore.kernel.org/r/20250629220757.936212-2-marek.vasut+renesas@mailbox.org Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
2025-07-07dt-bindings: vendor-prefixes: Document Argon40Marek Vasut
Argon 40 Technologies Limited is a SBC expansion board vendor. Document the prefix. For details see https://argon40.com . Acked-by: Conor Dooley <conor.dooley@microchip.com> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org> Link: https://lore.kernel.org/r/20250629220757.936212-1-marek.vasut+renesas@mailbox.org Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
2025-07-07pwm: pwm-mediatek: Add support for PWM IP V3.0.2 in MT6991/MT8196AngeloGioacchino Del Regno
Add support for the PWM IP version 3.0.2, found in MediaTek's Dimensity 9400 MT6991 and in the MT8196 Chromebook SoC: this needs a new register offset array and also a different offset for the PWM_CK_26M_SEL register. Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20250623120118.109170-4-angelogioacchino.delregno@collabora.com Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
2025-07-07pwm: pwm-mediatek: Pass PWM_CK_26M_SEL from platform dataAngeloGioacchino Del Regno
In preparation for adding support for new SoCs, remove variable has_ck_26m_sel from pwm_mediatek_of_data and replace it with a u16 pwm_ck_26m_sel_reg, meant to hold the register offset for PWM_CK_26M_SEL. Also, since the reg offset is guaranteed to never be zero, the logic to check for "has_ck_26m_sel" is changed to check if the register offset in pwm_ck_26m_sel_reg is more than zero. Analogously, when writing, use the register offset from platform data instead of using the PWM_CK_26M_SEL definition. Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20250623120118.109170-3-angelogioacchino.delregno@collabora.com Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
2025-07-07dt-bindings: pwm: mediatek,mt2712-pwm: Add support for MT6991/MT8196AngeloGioacchino Del Regno
Add compatible strings for the MediaTek Dimensity 9400 MT6991 and for the MT8196 Chromebook SoC, having the same PWM IP v3.0.2. Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20250623120118.109170-2-angelogioacchino.delregno@collabora.com Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
2025-07-07dt-bindings: pwm: convert lpc1850-sct-pwm.txt to yaml formatFrank Li
Convert lpc1850-sct-pwm.txt to yaml format. Additional changes: - add ref pwm.yaml. - add resets property to match existed dts. Reviewed-by: Rob Herring (Arm) <robh@kernel.org> Reviewed-by: Vladimir Zapolskiy <vz@mleia.com> Signed-off-by: Frank Li <Frank.Li@nxp.com> Link: https://lore.kernel.org/r/20250616190435.1998078-1-Frank.Li@nxp.com Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
2025-07-07pwm: rockchip: Round period/duty down on apply, up on getNicolas Frattaroli
With CONFIG_PWM_DEBUG=y, the rockchip PWM driver produces warnings like this: rockchip-pwm fd8b0010.pwm: .apply is supposed to round down duty_cycle (requested: 23529/50000, applied: 23542/50000) This is because the driver chooses ROUND_CLOSEST for purported idempotency reasons. However, it's possible to keep idempotency while always rounding down in .apply(). Do this by making .get_state() always round up, and making .apply() always round down. This is done with u64 maths, and setting both period and duty to U32_MAX (the biggest the hardware can support) if they would exceed their 32 bits confines. Fixes: 12f9ce4a5198 ("pwm: rockchip: Fix period and duty cycle approximation") Fixes: 1ebb74cf3537 ("pwm: rockchip: Add support for hardware readout") Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com> Link: https://lore.kernel.org/r/20250616-rockchip-pwm-rounding-fix-v2-1-a9c65acad7b6@collabora.com Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
2025-07-07pwm: stm32: add support for stm32mp25Fabrice Gasnier
Add support for STM32MP25 SoC. Use newly introduced compatible to handle new features along with registers and bits diversity. The MFD part of the driver fills in ipidr, so it is used to check the hardware configuration register, when available to gather the number of PWM channels and complementary outputs. Signed-off-by: Fabrice Gasnier <fabrice.gasnier@foss.st.com> Link: https://lore.kernel.org/r/20250110091922.980627-5-fabrice.gasnier@foss.st.com Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
2025-07-07dt-bindings: pwm: adi,axi-pwmgen: Update documentation linkDavid Lechner
Change the documentation link to point to the location with the most up-to-date information. Signed-off-by: David Lechner <dlechner@baylibre.com> Link: https://lore.kernel.org/r/20250529-pwm-axi-pwmgen-add-external-clock-v3-1-5d8809a7da91@baylibre.com Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
2025-07-07pwm: sophgo-sg2042: Add support for SG2044Longbin Li
Add PWM controller for SG2044 on base of SG2042. Reviewed-by: Chen Wang <unicorn_wang@outlook.com> Tested-by: Chen Wang <unicorn_wang@outlook.com> Signed-off-by: Longbin Li <looong.bin@gmail.com> Link: https://lore.kernel.org/r/20250528101139.28702-4-looong.bin@gmail.com Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
2025-07-07pwm: sophgo-sg2042: Reorganize the code structureLongbin Li
As the driver logic can be used in both SG2042 and SG2044, it will be better to reorganize the code structure. Reviewed-by: Chen Wang <unicorn_wang@outlook.com> Tested-by: Chen Wang <unicorn_wang@outlook.com> Signed-off-by: Longbin Li <looong.bin@gmail.com> Link: https://lore.kernel.org/r/20250528101139.28702-3-looong.bin@gmail.com Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
2025-07-07dt-bindings: pwm: sophgo: Add pwm controller for SG2044Longbin Li
Add compatible string for PWM controller on SG2044. Tested-by: Chen Wang <unicorn_wang@outlook.com> Reviewed-by: Chen Wang <unicorn_wang@outlook.com> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Acked-by: Rob Herring (Arm) <robh@kernel.org> Signed-off-by: Longbin Li <looong.bin@gmail.com> Link: https://lore.kernel.org/r/20250528101139.28702-2-looong.bin@gmail.com Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
2025-07-07pwm: sifive: Fix rounding and idempotency issues in apply and get_stateNylon Chen
This fix ensures consistent rounding and avoids mismatches between applied and reported PWM values that could trigger false idempotency failures in debug checks This change ensures: - real_period is now calculated using DIV_ROUND_UP_ULL() to avoid underestimation. - duty_cycle is rounded up to match the fractional computation in apply() - apply() truncates the result to compensate for get_state's rounding up logic These fixes resolve issues like: .apply is supposed to round down duty_cycle (requested: 360/504000, applied: 361/504124) .apply is not idempotent (ena=1 pol=0 1739692/4032985) -> (ena=1 pol=0 1739630/4032985) Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202505080303.dBfU5YMS-lkp@intel.com/ Co-developed-by: Zong Li <zong.li@sifive.com> Signed-off-by: Zong Li <zong.li@sifive.com> Signed-off-by: Nylon Chen <nylon.chen@sifive.com> Link: https://lore.kernel.org/r/20250529035341.51736-4-nylon.chen@sifive.com Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
2025-07-07pwm: sifive: Fix PWM algorithm and clarify inverted compare behaviorNylon Chen
The `frac` variable represents the pulse inactive time, and the result of this algorithm is the pulse active time. Therefore, we must reverse the result. Although the SiFive Reference Manual states "pwms >= pwmcmpX -> HIGH", the hardware behavior is inverted due to a fixed XNOR with 0. As a result, the pwmcmp register actually defines the low (inactive) portion of the pulse. The reference is SiFive FU740-C000 Manual[0] Link: https://sifive.cdn.prismic.io/sifive/1a82e600-1f93-4f41-b2d8-86ed8b16acba_fu740-c000-manual-v1p6.pdf [0] Co-developed-by: Zong Li <zong.li@sifive.com> Signed-off-by: Zong Li <zong.li@sifive.com> Co-developed-by: Vincent Chen <vincent.chen@sifive.com> Signed-off-by: Vincent Chen <vincent.chen@sifive.com> Signed-off-by: Nylon Chen <nylon.chen@sifive.com> Link: https://lore.kernel.org/r/20250529035341.51736-3-nylon.chen@sifive.com Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
2025-07-07riscv: dts: sifive: unleashed/unmatched: Remove PWM controlled LED's ↵Nylon Chen
active-low properties This removes the active-low properties of the PWM-controlled LEDs in the HiFive Unmatched device tree. The reference is hifive-unleashed-a00.pdf[0] and hifive-unmatched-schematics-v3.pdf[1]. Link: https://sifive.cdn.prismic.io/sifive/c52a8e32-05ce-4aaf-95c8-7bf8453f8698_hifive-unleashed-a00-schematics-1.pdf [0] Link: https://sifive.cdn.prismic.io/sifive/6a06d6c0-6e66-49b5-8e9e-e68ce76f4192_hifive-unmatched-schematics-v3.pdf [1] Acked-by: Conor Dooley <conor.dooley@microchip.com> Reviewed-by: Conor Dooley <conor.dooley@microchip.com> Signed-off-by: Vincent Chen <vincent.chen@sifive.com> Signed-off-by: Nylon Chen <nylon.chen@sifive.com> Link: https://lore.kernel.org/r/20250529035341.51736-2-nylon.chen@sifive.com Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
2025-07-07pwm: pxa: Allow to enable for SpacemiT K1 SoCGuodong Xu
The SpacemiT K1 SoC uses devices similar to the ones on PXA SoCs. Add ARCH_SPACEMIT as one of the possible architectures this driver can be enabled for. Signed-off-by: Guodong Xu <guodong@riscstar.com> Link: https://lore.kernel.org/r/20250429085048.1310409-6-guodong@riscstar.com [ukleinek: reword commit log] Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
2025-07-07pwm: pxa: Add optional reset controlGuodong Xu
Support optional reset control for the PWM PXA driver. During probe, it acquires the reset controller using devm_reset_control_get_optional_exclusive_deasserted() to get and deassert the reset controller to enable the PWM channel. Signed-off-by: Guodong Xu <guodong@riscstar.com> Link: https://lore.kernel.org/r/20250429085048.1310409-3-guodong@riscstar.com [ukleinek: Fix conflict with commit df08fff8add2 ("pwm: pxa: Improve using dev_err_probe()")] Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
2025-07-07dt-bindings: pwm: marvell,pxa-pwm: Add SpacemiT K1 PWM supportGuodong Xu
The SpacemiT K1 SoC reuses the Marvell PXA910-compatible PWM controller with one notable difference: the addition of a resets property. To make the device tree pass schema validation (make dtbs_check W=3), this patch updates the binding to accept spacemit,k1-pwm as a compatible string, when used in conjunction with the fallback marvell,pxa910-pwm. Support for the optional resets property is also added, as it is required by the K1 integration but was not present in the original Marvell bindings. Since the PWM reset line may be deasserted during the early bootloader stage, making the resets property optional avoids potential double-deassertion, which could otherwise cause flickering on displays that use PWM for backlight control. Additionally, this patch adjusts the required value of the #pwm-cells property for the new compatible string: - For "spacemit,k1-pwm", #pwm-cells must be set to 3. - For existing Marvell compatibles, #pwm-cells remains 1. Background of #pwm-cells change is by an ongoing community discussion about increasing the #pwm-cells value from 1 to 3 for all Marvell PXA PWM devices. These devices are currently the only ones whose bindings do not pass the line index as the first argument. See [1] for further details. [1] https://lore.kernel.org/all/cover.1738842938.git.u.kleine-koenig@baylibre.com/ Reviewed-by: Rob Herring (Arm) <robh@kernel.org> # v2 Signed-off-by: Guodong Xu <guodong@riscstar.com> Link: https://lore.kernel.org/r/20250429085048.1310409-2-guodong@riscstar.com Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
2025-07-07pwm: Add support for pwmchip devices for faster and easier userspace accessUwe Kleine-König
With this change each pwmchip defining the new-style waveform callbacks can be accessed from userspace via a character device. Compared to the sysfs-API this is faster and allows to pass the whole configuration in a single ioctl allowing atomic application and thus reducing glitches. On an STM32MP13 I see: root@DistroKit:~ time pwmtestperf real 0m 1.27s user 0m 0.02s sys 0m 1.21s root@DistroKit:~ rm /dev/pwmchip0 root@DistroKit:~ time pwmtestperf real 0m 3.61s user 0m 0.27s sys 0m 3.26s pwmtestperf does essentially: for i in 0 .. 50000: pwm_set_waveform(duty_length_ns=i, period_length_ns=50000, duty_offset_ns=0) and in the presence of /dev/pwmchip0 is uses the ioctls introduced here, without that device it uses /sys/class/pwm/pwmchip0. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com> Link: https://lore.kernel.org/r/ad4a4e49ae3f8ea81e23cac1ac12b338c3bf5c5b.1746010245.git.u.kleine-koenig@baylibre.com Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
2025-07-07pwm: mediatek: Ensure to disable clocks in error pathUwe Kleine-König
After enabling the clocks each error path must disable the clocks again. One of them failed to do so. Unify the error paths to use goto to make it harder for future changes to add a similar bug. Fixes: 7ca59947b5fc ("pwm: mediatek: Prevent divide-by-zero in pwm_mediatek_config()") Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com> Link: https://lore.kernel.org/r/20250704172728.626815-2-u.kleine-koenig@baylibre.com Cc: stable@vger.kernel.org Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
2025-07-07pwm: Fix invalid state detectionUwe Kleine-König
Commit 9dd42d019e63 ("pwm: Allow pwm state transitions from an invalid state") intended to allow some state transitions that were not allowed before. The idea is sane and back then I also got the code comment right, but the check for enabled is bogus. This resulted in state transitions for enabled states to be allowed to have invalid duty/period settings and thus it can happen that low-level drivers get requests for invalid states🙄. Invert the check to allow state transitions for disabled states only. Fixes: 9dd42d019e63 ("pwm: Allow pwm state transitions from an invalid state") Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com> Link: https://lore.kernel.org/r/20250704172416.626433-2-u.kleine-koenig@baylibre.com Cc: stable@vger.kernel.org Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
2025-06-08Linux 6.16-rc1Linus Torvalds
2025-06-08Merge tag 'turbostat-2025.06.08' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux Pull turbostat updates from Len Brown: - Add initial DMR support, which required smarter RAPL probe - Fix AMD MSR RAPL energy reporting - Add RAPL power limit configuration output - Minor fixes * tag 'turbostat-2025.06.08' of git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux: tools/power turbostat: version 2025.06.08 tools/power turbostat: Add initial support for BartlettLake tools/power turbostat: Add initial support for DMR tools/power turbostat: Dump RAPL sysfs info tools/power turbostat: Avoid probing the same perf counters tools/power turbostat: Allow probing RAPL with platform_features->rapl_msrs cleared tools/power turbostat: Clean up add perf/msr counter logic tools/power turbostat: Introduce add_msr_counter() tools/power turbostat: Remove add_msr_perf_counter_() tools/power turbostat: Remove add_cstate_perf_counter_() tools/power turbostat: Remove add_rapl_perf_counter_() tools/power turbostat: Quit early for unsupported RAPL counters tools/power turbostat: Always check rapl_joules flag tools/power turbostat: Fix AMD package-energy reporting tools/power turbostat: Fix RAPL_GFX_ALL typo tools/power turbostat: Add Android support for MSR device handling tools/power turbostat.8: pm_domain wording fix tools/power turbostat.8: fix typo: idle_pct should be pct_idle
2025-06-08Merge tag 'timers-cleanups-2025-06-08' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull timer cleanup from Thomas Gleixner: "The delayed from_timer() API cleanup: The renaming to the timer_*() namespace was delayed due massive conflicts against Linux-next. Now that everything is upstream finish the conversion" * tag 'timers-cleanups-2025-06-08' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: treewide, timers: Rename from_timer() to timer_container_of()
2025-06-08Merge tag 'x86-urgent-2025-06-08' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull x86 fixes from Thomas Gleixner: "A small set of x86 fixes: - Cure IO bitmap inconsistencies A failed fork cleans up all resources of the newly created thread via exit_thread(). exit_thread() invokes io_bitmap_exit() which does the IO bitmap cleanups, which unfortunately assume that the cleanup is related to the current task, which is obviously bogus. Make it work correctly - A lockdep fix in the resctrl code removed the clearing of the command buffer in two places, which keeps stale error messages around. Bring them back. - Remove unused trace events" * tag 'x86-urgent-2025-06-08' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: fs/resctrl: Restore the rdt_last_cmd_clear() calls after acquiring rdtgroup_mutex x86/iopl: Cure TIF_IO_BITMAP inconsistencies x86/fpu: Remove unused trace events
2025-06-08Merge tag 'timers-urgent-2025-06-08' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull timer fix from Thomas Gleixner: "Add the missing seq_file forward declaration in the timer namespace header" * tag 'timers-urgent-2025-06-08' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: timens: Add struct seq_file forward declaration
2025-06-08tools/power turbostat: version 2025.06.08Len Brown
Add initial DMR support, which required smarter RAPL probe Fix AMD MSR RAPL energy reporting Add RAPL power limit configuration output Minor fixes Signed-off-by: Len Brown <len.brown@intel.com>
2025-06-08tools/power turbostat: Add initial support for BartlettLakeZhang Rui
Add initial support for BartlettLake. Signed-off-by: Zhang Rui <rui.zhang@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2025-06-08tools/power turbostat: Add initial support for DMRZhang Rui
Add initial support for DMR. Signed-off-by: Zhang Rui <rui.zhang@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2025-06-08tools/power turbostat: Dump RAPL sysfs infoZhang Rui
for example: intel-rapl:1: psys 28.0s:100W 976.0us:100W intel-rapl:0: package-0 28.0s:57W,max:15W 2.4ms:57W intel-rapl:0/intel-rapl:0:0: core disabled intel-rapl:0/intel-rapl:0:1: uncore disabled intel-rapl-mmio:0: package-0 28.0s:28W,max:15W 2.4ms:57W [lenb: simplified format] Signed-off-by: Zhang Rui <rui.zhang@intel.com> Signed-off-by: Len Brown <len.brown@intel.com> squish me Signed-off-by: Len Brown <len.brown@intel.com>
2025-06-08tools/power turbostat: Avoid probing the same perf countersZhang Rui
For the RAPL package energy status counter, Intel and AMD share the same perf_subsys and perf_name, but with different MSR addresses. Both rapl_counter_arch_infos[0] and rapl_counter_arch_infos[1] are introduced to describe this counter for different Vendors. As a result, the perf counter is probed twice, and causes a failure in in get_rapl_counters() because expected_read_size and actual_read_size don't match. Fix the problem by skipping the already probed counter. Note, this is not a perfect fix. For example, if different vendors/platforms use the same MSR value for different purpose, the code can be fooled when it probes a rapl_counter_arch_infos[] entry that does not belong to the running Vendor/Platform. In a long run, better to put rapl_counter_arch_infos[] into the platform_features so that this becomes Vendor/Platform specific. Signed-off-by: Zhang Rui <rui.zhang@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2025-06-08tools/power turbostat: Allow probing RAPL with platform_features->rapl_msrs ↵Zhang Rui
cleared platform_features->rapl_msrs describes the RAPL MSRs supported. While RAPL Perf counters can be exposed from different kernel backend drivers, e.g. RAPL MSR I/F driver, or RAPL TPMI I/F driver. Thus, turbostat should first blindly probe all the available RAPL Perf counters, and falls back to the RAPL MSR counters if they are listed in platform_features->rapl_msrs. With this, platforms that don't have RAPL MSRs can clear the platform_features->rapl_msrs bits and use RAPL Perf counters only. Signed-off-by: Zhang Rui <rui.zhang@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2025-06-08tools/power turbostat: Clean up add perf/msr counter logicZhang Rui
Increase the code readability by moving the no_perf/no_msr flag and the cai->perf_name/cai->msr sanity checks into the counter probe functions. No functional change. Signed-off-by: Zhang Rui <rui.zhang@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2025-06-08tools/power turbostat: Introduce add_msr_counter()Zhang Rui
probe_rapl_msr() is reused for probing RAPL MSR counters, cstate MSR counters and MPERF/APERF/SMI MSR counters, thus its name is misleading. Similar to add_perf_counter(), introduce add_msr_counter() to probe a counter via MSR. Introduce wrapper function add_rapl_msr_counter() at the same time to add extra check for Zero return value for specified RAPL counters. No functional change intended. Signed-off-by: Zhang Rui <rui.zhang@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2025-06-08tools/power turbostat: Remove add_msr_perf_counter_()Zhang Rui
As the only caller of add_msr_perf_counter_(), add_msr_perf_counter() just gives extra debug output on top. There is no need to keep both functions. Remove add_msr_perf_counter_() and move all the logic to add_msr_perf_counter(). No functional change. Signed-off-by: Zhang Rui <rui.zhang@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2025-06-08tools/power turbostat: Remove add_cstate_perf_counter_()Zhang Rui
As the only caller of add_cstate_perf_counter_(), add_cstate_perf_counter() just gives extra debug output on top. There is no need to keep both functions. Remove add_cstate_perf_counter_() and move all the logic to add_cstate_perf_counter(). No functional change. Signed-off-by: Zhang Rui <rui.zhang@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2025-06-08tools/power turbostat: Remove add_rapl_perf_counter_()Zhang Rui
As the only caller of add_rapl_perf_counter_(), add_rapl_perf_counter() just gives extra debug output on top. There is no need to keep both functions. Remove add_rapl_perf_counter_() and move all the logic to add_rapl_perf_counter(). No functional change. Signed-off-by: Zhang Rui <rui.zhang@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2025-06-08tools/power turbostat: Quit early for unsupported RAPL countersZhang Rui
Quit early for unsupported RAPL counters. No functional change. Signed-off-by: Zhang Rui <rui.zhang@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2025-06-08tools/power turbostat: Always check rapl_joules flagZhang Rui
rapl_joules bit should always be checked even if platform_features->rapl_msrs is not set or no_msr flag is used. Signed-off-by: Zhang Rui <rui.zhang@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2025-06-08tools/power turbostat: Fix AMD package-energy reportingGautham R. Shenoy
commit 05a2f07db888 ("tools/power turbostat: read RAPL counters via perf") that adds support to read RAPL counters via perf defines the notion of a RAPL domain_id which is set to physical_core_id on platforms which support per_core_rapl counters (Eg: AMD processors Family 17h onwards) and is set to the physical_package_id on all the other platforms. However, the physical_core_id is only unique within a package and on platforms with multiple packages more than one core can have the same physical_core_id and thus the same domain_id. (For eg, the first cores of each package have the physical_core_id = 0). This results in all these cores with the same physical_core_id using the same entry in the rapl_counter_info_perdomain[]. Since rapl_perf_init() skips the perf-initialization for cores whose domain_ids have already been visited, cores that have the same physical_core_id always read the perf file corresponding to the physical_core_id of the first package and thus the package-energy is incorrectly reported to be the same value for different packages. Note: This issue only arises when RAPL counters are read via perf and not when they are read via MSRs since in the latter case the MSRs are read separately on each core. Fix this issue by associating each CPU with rapl_core_id which is unique across all the packages in the system. Fixes: 05a2f07db888 ("tools/power turbostat: read RAPL counters via perf") Signed-off-by: Gautham R. Shenoy <gautham.shenoy@amd.com> Signed-off-by: Len Brown <len.brown@intel.com>
2025-06-08tools/power turbostat: Fix RAPL_GFX_ALL typoKaushlendra Kumar
Fix typo in the currently unused RAPL_GFX_ALL macro definition. Signed-off-by: Kaushlendra Kumar <kaushlendra.kumar@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
generated by cgit (git 2.34.1) at 2025-09-11 14:08:09 +0000