kernel/drivers/devfreq/event/rockchip-dfi.c, branch linux-rolling-stable

PM / devfreq: rockchip-dfi: switch to FIELD_PREP_WM16 macro

2025-10-15T14:39:54Z

The era of hand-rolled HIWORD_UPDATE macros is over, at least for those drivers that use constant masks. Like many other Rockchip drivers, rockchip-dfi brings with it its own HIWORD_UPDATE macro. This variant doesn't shift the value (and like the others, doesn't do any checking). Remove it, and replace instances of it with hw_bitfield.h's FIELD_PREP_WM16. Since FIELD_PREP_WM16 requires contiguous masks and shifts the value for us, some reshuffling of definitions needs to happen. This gives us better compile-time error checking, and in my opinion, nicer code. Tested on an RK3568 ODROID-M1 board (LPDDR4X at 1560 MHz, an RK3588 Radxa ROCK 5B board (LPDDR4X at 2112 MHz) and an RK3588 Radxa ROCK 5T board (LPDDR5 at 2400 MHz). perf measurements were consistent with the measurements of stress-ng --stream in all cases. Signed-off-by: Nicolas Frattaroli Signed-off-by: Yury Norov (NVIDIA)

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

2025-09-09T14:37:39Z

The Rockchip RK3588 SoC can also support LPDDR5 memory. This type of memory needs some special case handling in the rockchip-dfi driver. Add support for it in rockchip-dfi, as well as the needed GRF register definitions. This has been tested as returning both the right cycle count and bandwidth on a LPDDR5 board where the CKR bit is 1. I couldn't test whether the values are correct on a system where CKR is 0, as I'm not savvy enough with the Rockchip tooling to know whether this can be set in the DDR init blob. Downstream has some special case handling for a hardware version where not just the control bits differ, but also the register. Since I don't know whether that hardware version is in any production silicon, it's left unimplemented for now, with an error message urging users to report if they have such a system. There is a slight change of behaviour for non-LPDDR5 systems: instead of writing 0 as the control flags to the control register and pretending everything is alright if the memory type is unknown, we now explicitly return an error. Signed-off-by: Nicolas Frattaroli Reviewed-by: Sascha Hauer Acked-by: Heiko Stuebner Signed-off-by: Chanwoo Choi Link: https://patchwork.kernel.org/project/linux-pm/patch/20250530-rk3588-dfi-improvements-v1-2-6e077c243a95@collabora.com/

PM / devfreq: rockchip-dfi: double count on RK3588

2025-09-09T14:37:39Z

On RK3588 with LPDDR4X memory, the cycle count as returned by perf stat -a -e rockchip_ddr/cycles/ sleep 1 consistently reads half as much as what the actual DDR frequency is at. For a LPDDR4X module running at 2112MHz, I get more like 1056059916 cycles per second, which is almost bang-on half what it should be. No, I'm not mixing up megatransfers and megahertz. Consulting the downstream driver, this appears to be because the RK3588 hardware specifically (and RK3528 as well, for future reference) needs a multiplier of 2 to get to the correct frequency with everything but LPDDR5. The RK3588's actual memory bandwidth measurements in MB/s are correct however, as confirmed with stress-ng --stream. This makes me think the access counters are not affected in the same way. This tracks with the vendor kernel not multiplying the access counts either. Solve this by adding a new member to the dfi struct, which each SoC can set to whatever they want, but defaults to 1 if left unset by the SoC init functions. The event_get_count op can then use this multiplier if the cycle count is requested. The cycle multiplier is not used in rockchip_dfi_get_event because the vendor driver doesn't use it there either, and we don't do other actual bandwidth unit conversion stuff in there anyway. Fixes: 481d97ba61e1 ("PM / devfreq: rockchip-dfi: add support for RK3588") Signed-off-by: Nicolas Frattaroli Signed-off-by: Chanwoo Choi Link: https://lore.kernel.org/lkml/20250530-rk3588-dfi-improvements-v1-1-6e077c243a95@collabora.com/

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

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