linux/drivers/devfreq/event, branch v6.17

PM / devfreq: rockchip-dfi: Switch to use hrtimer_setup()

2025-02-18T09:32:34Z

hrtimer_setup() takes the callback function pointer as argument and initializes the timer completely. Replace hrtimer_init() and the open coded initialization of hrtimer::function with the new setup mechanism. Patch was created by using Coccinelle. Signed-off-by: Nam Cao Signed-off-by: Thomas Gleixner Acked-by: Chanwoo Choi Link: https://lore.kernel.org/all/dfb35fb45eacdba7b8767052aa8c29ca157ac1b0.1738746821.git.namcao@linutronix.de

Get rid of 'remove_new' relic from platform driver struct

2024-12-01T23:12:43Z

The continual trickle of small conversion patches is grating on me, and is really not helping. Just get rid of the 'remove_new' member function, which is just an alias for the plain 'remove', and had a comment to that effect: /* * .remove_new() is a relic from a prototype conversion of .remove(). * New drivers are supposed to implement .remove(). Once all drivers are * converted to not use .remove_new any more, it will be dropped. */ This was just a tree-wide 'sed' script that replaced '.remove_new' with '.remove', with some care taken to turn a subsequent tab into two tabs to make things line up. I did do some minimal manual whitespace adjustment for places that used spaces to line things up. Then I just removed the old (sic) .remove_new member function, and this is the end result. No more unnecessary conversion noise. Signed-off-by: Linus Torvalds

PM / devfreq: exynos-ppmu: Convert to platform remove callback returning void

2024-05-08T14:53:08Z

The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by: Uwe Kleine-König Signed-off-by: Chanwoo Choi

PM / devfreq: exynos-nocp: Convert to platform remove callback returning void

2024-05-08T14:53:08Z

PM / devfreq: rockchip-dfi: add support for RK3588

2023-10-19T12:21:16Z

Add support for the RK3588 to the driver. The RK3588 has four DDR channels with a register stride of 0x4000 between the channel registers, also it has a DDRMON_CTRL register per channel. Link: https://lore.kernel.org/all/20231018061714.3553817-20-s.hauer@pengutronix.de/ Reviewed-by: Jonathan Cameron Reviewed-by: Sebastian Reichel Acked-by: Chanwoo Choi Acked-by: Heiko Stuebner Signed-off-by: Sascha Hauer Signed-off-by: Chanwoo Choi

PM / devfreq: rockchip-dfi: account for multiple DDRMON_CTRL registers

2023-10-19T12:17:42Z

The currently supported RK3399 has a set of registers per channel, but it has only a single DDRMON_CTRL register. With upcoming RK3588 this will be different, the RK3588 has a DDRMON_CTRL register per channel. Instead of expecting a single DDRMON_CTRL register, loop over the channels and write the channel specific DDRMON_CTRL register. Break out early out of the loop when there is only a single DDRMON_CTRL register like on the RK3399. Link: https://lore.kernel.org/all/20231018061714.3553817-19-s.hauer@pengutronix.de/ Reviewed-by: Jonathan Cameron Reviewed-by: Sebastian Reichel Signed-off-by: Sascha Hauer Signed-off-by: Chanwoo Choi

PM / devfreq: rockchip-dfi: make register stride SoC specific

2023-10-19T12:17:10Z

The currently supported RK3399 has a stride of 20 between the channel specific registers. Upcoming RK3588 has a different stride, so put the stride into driver data to make it configurable. While at it convert decimal 20 to hex 0x14 for consistency with RK3588 which has a register stride 0x4000 and we want to write that in hex as well. Link: https://lore.kernel.org/all/20231018061714.3553817-18-s.hauer@pengutronix.de/ Reviewed-by: Jonathan Cameron Reviewed-by: Sebastian Reichel Signed-off-by: Sascha Hauer Signed-off-by: Chanwoo Choi

PM / devfreq: rockchip-dfi: Add perf support

2023-10-19T12:13:28Z

The DFI is a unit which is suitable for measuring DDR utilization, but so far it could only be used as an event driver for the DDR frequency scaling driver. This adds perf support to the DFI driver. Usage with the 'perf' tool can look like: perf stat -a -e rockchip_ddr/cycles/,\ rockchip_ddr/read-bytes/,\ rockchip_ddr/write-bytes/,\ rockchip_ddr/bytes/ sleep 1 Performance counter stats for 'system wide': 1582524826 rockchip_ddr/cycles/ 1802.25 MB rockchip_ddr/read-bytes/ 1793.72 MB rockchip_ddr/write-bytes/ 3595.90 MB rockchip_ddr/bytes/ 1.014369709 seconds time elapsed perf support has been tested on a RK3568 and a RK3399, the latter with dual channel DDR. Link: https://lore.kernel.org/all/20231019064819.3496740-1-s.hauer@pengutronix.de/ Reviewed-by: Sebastian Reichel Acked-by: Chanwoo Choi Acked-by: Heiko Stuebner Signed-off-by: Sascha Hauer [cw00.choi: Fix typo from 'write_acccess' to 'write_access'] Signed-off-by: Chanwoo Choi

PM / devfreq: rockchip-dfi: give variable a better name

2023-10-19T11:58:34Z

struct dmc_count_channel::total counts the clock cycles of the DDR controller. Rename it accordingly to give the reader a better idea what this is about. While at it, at some documentation to struct dmc_count_channel. Link: https://lore.kernel.org/all/20231018061714.3553817-16-s.hauer@pengutronix.de/ Reviewed-by: Sebastian Reichel Acked-by: Chanwoo Choi Signed-off-by: Sascha Hauer Signed-off-by: Chanwoo Choi

PM / devfreq: rockchip-dfi: Prepare for multiple users

2023-10-19T11:50:10Z

When adding perf support later the DFI must be enabled when either of devfreq-event or perf is active. Prepare for that by adding a usage counter for the DFI. Also move enabling and disabling of the clock away from the devfreq-event specific functions to which the perf specific part won't have access. Link: https://lore.kernel.org/all/20231018061714.3553817-15-s.hauer@pengutronix.de/ Reviewed-by: Jonathan Cameron Reviewed-by: Sebastian Reichel Acked-by: Chanwoo Choi Signed-off-by: Sascha Hauer Signed-off-by: Chanwoo Choi