aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/devfreq
Commit message (Collapse)AuthorAgeFilesLines
* PM / devfreq: rockchip-dfi: switch to FIELD_PREP_WM16 macroNicolas Frattaroli2025-10-151-23/+22
| | | | | | | | | | | | | | | | | | | | | | | | | 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 <[email protected]> Signed-off-by: Yury Norov (NVIDIA) <[email protected]>
* PM / devfreq: rockchip-dfi: add support for LPDDR5Nicolas Frattaroli2025-09-091-18/+66
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <[email protected]> Reviewed-by: Sascha Hauer <[email protected]> Acked-by: Heiko Stuebner <[email protected]> Signed-off-by: Chanwoo Choi <[email protected]> Link: https://patchwork.kernel.org/project/linux-pm/patch/[email protected]/
* PM / devfreq: rockchip-dfi: double count on RK3588Nicolas Frattaroli2025-09-091-1/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <[email protected]> Signed-off-by: Chanwoo Choi <[email protected]> Link: https://lore.kernel.org/lkml/[email protected]/
* PM / devfreq: mtk-cci: avoid redundant conditionsLiao Yuanhong2025-09-081-1/+1
| | | | | | | | | | | While 'if (i <= 0) ... else if (i > 0) ...' is technically equivalent to 'if (i <= 0) ... else ...', the latter is vastly easier to read because it avoids writing out a condition that is unnecessary. Let's drop such unnecessary conditions. Signed-off-by: Liao Yuanhong <[email protected]> Signed-off-by: Chanwoo Choi <[email protected]> Link: https://patchwork.kernel.org/project/linux-pm/patch/[email protected]/
* PM / devfreq: mtk-cci: Fix potential error pointer dereference in probe()Dan Carpenter2025-09-061-1/+2
| | | | | | | | | | | The drv->sram_reg pointer could be set to ERR_PTR(-EPROBE_DEFER) which would lead to a error pointer dereference. Use IS_ERR_OR_NULL() to check that the pointer is valid. Fixes: e09bd5757b52 ("PM / devfreq: mtk-cci: Handle sram regulator probe deferral") Signed-off-by: Dan Carpenter <[email protected]> Signed-off-by: Chanwoo Choi <[email protected]> Link: https://patchwork.kernel.org/project/linux-pm/patch/[email protected]/
* PM / devfreq: Add HiSilicon uncore frequency scaling driverJie Zhan2025-07-143-0/+670
| | | | | | | | | | | | | | | | | | | | | | Add the HiSilicon uncore frequency scaling driver for Kunpeng SoCs based on the devfreq framework. The uncore domain contains shared computing resources, including system interconnects and L3 cache. The uncore frequency significantly impacts the system-wide performance as well as power consumption. This driver adds support for runtime management of uncore frequency from kernel and userspace. The main function includes setting and getting frequencies, changing frequency scaling policies, and querying the list of CPUs whose performance is significantly related to this uncore frequency domain, etc. The driver communicates with a platform controller through an ACPI PCC mailbox to take the actual actions of frequency scaling. Co-developed-by: Lifeng Zheng <[email protected]> Signed-off-by: Lifeng Zheng <[email protected]> Reviewed-by: Jonathan Cameron <[email protected]> Reviewed-by: Huisong Li <[email protected]> Signed-off-by: Jie Zhan <[email protected]> Signed-off-by: Chanwoo Choi <[email protected]> Link: https://patchwork.kernel.org/project/linux-pm/patch/[email protected]/
* PM / devfreq: Allow devfreq driver to add custom sysfs ABIsJie Zhan2025-07-141-0/+1
| | | | | | | | | | | | Extend the devfreq_dev_profile to allow drivers optionally create device-specific sysfs ABIs together with other common devfreq ABIs under the devfreq device path. Reviewed-by: Jonathan Cameron <[email protected]> Reviewed-by: Huisong Li <[email protected]> Signed-off-by: Jie Zhan <[email protected]> Signed-off-by: Chanwoo Choi <[email protected]> Link: https://patchwork.kernel.org/project/linux-pm/patch/[email protected]/
* PM / devfreq: sun8i-a33-mbus: Simplify by using more devm functionsUwe Kleine-König2025-07-141-29/+9
| | | | | | | | | | | | Use devm allocators for enabling the bus clock and clk_rate_exclusive_get(). This simplifies error handling and the remove callback. Reviewed-by: Chen-Yu Tsai <[email protected]> Signed-off-by: Uwe Kleine-König <[email protected]> Tested-by: Corentin LABBE <[email protected]> Link: https://patchwork.kernel.org/project/linux-pm/patch/[email protected]/ Signed-off-by: Chanwoo Choi <[email protected]>
* PM / devfreq: Fix a index typo in trans_statChanwoo Choi2025-07-141-1/+1
| | | | | | | Fixes: 4920ee6dcfaf ("PM / devfreq: Convert to use sysfs_emit_at() API") Signed-off-by: pls <[email protected]> Link: https://patchwork.kernel.org/project/linux-pm/patch/[email protected]/ Signed-off-by: Chanwoo Choi <[email protected]>
* PM / devfreq: Check governor before using governor->nameLifeng Zheng2025-07-141-7/+3
| | | | | | | | | | | | | Commit 96ffcdf239de ("PM / devfreq: Remove redundant governor_name from struct devfreq") removes governor_name and uses governor->name to replace it. But devfreq->governor may be NULL and directly using devfreq->governor->name may cause null pointer exception. Move the check of governor to before using governor->name. Fixes: 96ffcdf239de ("PM / devfreq: Remove redundant governor_name from struct devfreq") Signed-off-by: Lifeng Zheng <[email protected]> Link: https://lore.kernel.org/lkml/[email protected]/ Signed-off-by: Chanwoo Choi <[email protected]>
* PM / devfreq: Remove redundant devfreq_get_freq_range() calling in ↵Lifeng Zheng2025-07-141-3/+0
| | | | | | | | | | | devfreq_add_device() The calling of devfreq_get_freq_range() in devfreq_add_device() is redundant because min_freq and max_freq are never used. Remove it. Signed-off-by: Lifeng Zheng <[email protected]> Link: https://lore.kernel.org/lkml/[email protected]/ Signed-off-by: Chanwoo Choi <[email protected]>
* PM / devfreq: Limit max_freq with scaling_min_freqLifeng Zheng2025-07-141-5/+2
| | | | | | | | | | | Limit max_freq in devfreq_get_freq_range() with scaling_min_freq to avoid showing an unreachable freq when reading it. Use macro clamp to simplify code. Signed-off-by: Lifeng Zheng <[email protected]> Link: https://lore.kernel.org/lkml/[email protected]/ Signed-off-by: Chanwoo Choi <[email protected]>
* PM / devfreq: governor: Replace sscanf() with kstrtoul() in set_freq_store()Lifeng Zheng2025-07-141-1/+5
| | | | | | | | | Replace sscanf() with kstrtoul() in set_freq_store() and check the result to avoid invalid input. Signed-off-by: Lifeng Zheng <[email protected]> Link: https://lore.kernel.org/lkml/[email protected]/ Signed-off-by: Chanwoo Choi <[email protected]>
* PM / devfreq: rockchip-dfi: Switch to use hrtimer_setup()Nam Cao2025-02-181-2/+1
| | | | | | | | | | | | | | | | 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 <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Acked-by: Chanwoo Choi <[email protected]> Link: https://lore.kernel.org/all/dfb35fb45eacdba7b8767052aa8c29ca157ac1b0.1738746821.git.namcao@linutronix.de
* Merge tag 'devfreq-next-for-6.14' of ↵Rafael J. Wysocki2025-01-132-9/+4
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/chanwoo/linux Merge devfreq updates for 6.14 from Chanwoo Choi: "- Call of_node_put() only once in devfreq_event_get_edev_by_phandle() on devfreq-event.c - Remove unused function parameter of exynos_bus_parse_of() on exynos-bus.c" * tag 'devfreq-next-for-6.14' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/chanwoo/linux: PM / devfreq: exynos: remove unused function parameter PM / devfreq: event: Call of_node_put() only once in devfreq_event_get_edev_by_phandle()
| * PM / devfreq: exynos: remove unused function parameterJeongjun Park2025-01-111-3/+2
| | | | | | | | | | | | | | exynos_bus_parse_of() still declares a parameter struct device_node that is not used yet. This parameter is unnecessary and should be removed. Signed-off-by: Jeongjun Park <[email protected]>
| * PM / devfreq: event: Call of_node_put() only once in ↵Markus Elfring2024-12-081-6/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | devfreq_event_get_edev_by_phandle() An of_node_put(node) call was immediately used after a null pointer check for the local variable “edev” at the end of this function implementation. Thus call such a function only once instead directly before the check. This issue was transformed by using the Coccinelle software. Link: https://lore.kernel.org/lkml/[email protected]/ Signed-off-by: Markus Elfring <[email protected]> Signed-off-by: Chanwoo Choi <[email protected]>
* | Get rid of 'remove_new' relic from platform driver structLinus Torvalds2024-12-015-5/+5
|/ | | | | | | | | | | | | | | | | | | | | | | | | 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 <[email protected]>
* PM / devfreq: imx-bus: Use of_property_present()Rob Herring (Arm)2024-09-041-1/+1
| | | | | | | | | | | | | Use of_property_present() to test for property presence rather than of_get_property(). This is part of a larger effort to remove callers of of_get_property() and similar functions. of_get_property() leaks the DT property data pointer which is a problem for dynamically allocated nodes which may be freed. Link: https://lore.kernel.org/lkml/[email protected]/ Acked-by: Peng Fan <[email protected]> Signed-off-by: Rob Herring (Arm) <[email protected]> Signed-off-by: Chanwoo Choi <[email protected]>
* PM / devfreq: exynos: Use Use devm_clk_get_enabled() helpersAnand Moon2024-09-041-17/+5
| | | | | | | | | | | | | | | | The devm_clk_get_enabled() helpers: - call devm_clk_get() - call clk_prepare_enable() and register what is needed in order to call clk_disable_unprepare() when needed, as a managed resource. This simplifies the code and avoids the calls to clk_disable_unprepare(). While at it, use dev_err_probe consistently, and use its return value to return the error code. Link: https://lore.kernel.org/lkml/[email protected]/ Signed-off-by: Anand Moon <[email protected]> Signed-off-by: Chanwoo Choi <[email protected]>
* PM/devfreq: governor: add missing MODULE_DESCRIPTION() macrosJeff Johnson2024-09-044-0/+4
| | | | | | | | | | | | | | make allmodconfig && make W=1 C=1 reports: WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/devfreq/governor_simpleondemand.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/devfreq/governor_performance.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/devfreq/governor_powersave.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/devfreq/governor_userspace.o Add all missing invocations of the MODULE_DESCRIPTION() macro. Link: https://lore.kernel.org/lkml/[email protected]/ Signed-off-by: Jeff Johnson <[email protected]> Signed-off-by: Chanwoo Choi <[email protected]>
* PM / devfreq: exynos: Use DEFINE_SIMPLE_DEV_PM_OPS for PM functionsAnand Moon2024-05-081-6/+3
| | | | | | | | | | | | This macro has the advantage over SET_SYSTEM_SLEEP_PM_OPS that we don't have to care about when the functions are actually used. Also make use of pm_sleep_ptr() to discard all PM_SLEEP related stuff if CONFIG_PM_SLEEP isn't enabled. Link: https://lore.kernel.org/lkml/[email protected]/ Signed-off-by: Anand Moon <[email protected]> Signed-off-by: Chanwoo Choi <[email protected]>
* PM / devfreq: rk3399_dmc: Convert to platform remove callback returning voidUwe Kleine-König2024-05-081-4/+2
| | | | | | | | | | | | | | | | | | 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 <[email protected]> Signed-off-by: Chanwoo Choi <[email protected]>
* PM / devfreq: sun8i-a33-mbus: Convert to platform remove callback returning voidUwe Kleine-König2024-05-081-4/+2
| | | | | | | | | | | | | | | | | | 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 <[email protected]> Signed-off-by: Chanwoo Choi <[email protected]>
* PM / devfreq: mtk-cci: Convert to platform remove callback returning voidUwe Kleine-König2024-05-081-4/+2
| | | | | | | | | | | | | | | | | | 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 <[email protected]> Signed-off-by: Chanwoo Choi <[email protected]>
* PM / devfreq: exynos-ppmu: Convert to platform remove callback returning voidUwe Kleine-König2024-05-081-4/+2
| | | | | | | | | | | | | | | | | | 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 <[email protected]> Signed-off-by: Chanwoo Choi <[email protected]>
* PM / devfreq: exynos-nocp: Convert to platform remove callback returning voidUwe Kleine-König2024-05-081-4/+2
| | | | | | | | | | | | | | | | | | 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 <[email protected]> Signed-off-by: Chanwoo Choi <[email protected]>
* PM / devfreq: Synchronize devfreq_monitor_[start/stop]Mukesh Ojha2023-12-181-2/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There is a chance if a frequent switch of the governor done in a loop result in timer list corruption where timer cancel being done from two place one from cancel_delayed_work_sync() and followed by expire_timers() can be seen from the traces[1]. while true do echo "simple_ondemand" > /sys/class/devfreq/1d84000.ufshc/governor echo "performance" > /sys/class/devfreq/1d84000.ufshc/governor done It looks to be issue with devfreq driver where device_monitor_[start/stop] need to synchronized so that delayed work should get corrupted while it is either being queued or running or being cancelled. Let's use polling flag and devfreq lock to synchronize the queueing the timer instance twice and work data being corrupted. [1] ... .. <idle>-0 [003] 9436.209662: timer_cancel timer=0xffffff80444f0428 <idle>-0 [003] 9436.209664: timer_expire_entry timer=0xffffff80444f0428 now=0x10022da1c function=__typeid__ZTSFvP10timer_listE_global_addr baseclk=0x10022da1c <idle>-0 [003] 9436.209718: timer_expire_exit timer=0xffffff80444f0428 kworker/u16:6-14217 [003] 9436.209863: timer_start timer=0xffffff80444f0428 function=__typeid__ZTSFvP10timer_listE_global_addr expires=0x10022da2b now=0x10022da1c flags=182452227 vendor.xxxyyy.ha-1593 [004] 9436.209888: timer_cancel timer=0xffffff80444f0428 vendor.xxxyyy.ha-1593 [004] 9436.216390: timer_init timer=0xffffff80444f0428 vendor.xxxyyy.ha-1593 [004] 9436.216392: timer_start timer=0xffffff80444f0428 function=__typeid__ZTSFvP10timer_listE_global_addr expires=0x10022da2c now=0x10022da1d flags=186646532 vendor.xxxyyy.ha-1593 [005] 9436.220992: timer_cancel timer=0xffffff80444f0428 xxxyyyTraceManag-7795 [004] 9436.261641: timer_cancel timer=0xffffff80444f0428 [2] 9436.261653][ C4] Unable to handle kernel paging request at virtual address dead00000000012a [ 9436.261664][ C4] Mem abort info: [ 9436.261666][ C4] ESR = 0x96000044 [ 9436.261669][ C4] EC = 0x25: DABT (current EL), IL = 32 bits [ 9436.261671][ C4] SET = 0, FnV = 0 [ 9436.261673][ C4] EA = 0, S1PTW = 0 [ 9436.261675][ C4] Data abort info: [ 9436.261677][ C4] ISV = 0, ISS = 0x00000044 [ 9436.261680][ C4] CM = 0, WnR = 1 [ 9436.261682][ C4] [dead00000000012a] address between user and kernel address ranges [ 9436.261685][ C4] Internal error: Oops: 96000044 [#1] PREEMPT SMP [ 9436.261701][ C4] Skip md ftrace buffer dump for: 0x3a982d0 ... [ 9436.262138][ C4] CPU: 4 PID: 7795 Comm: TraceManag Tainted: G S W O 5.10.149-android12-9-o-g17f915d29d0c #1 [ 9436.262141][ C4] Hardware name: Qualcomm Technologies, Inc. (DT) [ 9436.262144][ C4] pstate: 22400085 (nzCv daIf +PAN -UAO +TCO BTYPE=--) [ 9436.262161][ C4] pc : expire_timers+0x9c/0x438 [ 9436.262164][ C4] lr : expire_timers+0x2a4/0x438 [ 9436.262168][ C4] sp : ffffffc010023dd0 [ 9436.262171][ C4] x29: ffffffc010023df0 x28: ffffffd0636fdc18 [ 9436.262178][ C4] x27: ffffffd063569dd0 x26: ffffffd063536008 [ 9436.262182][ C4] x25: 0000000000000001 x24: ffffff88f7c69280 [ 9436.262185][ C4] x23: 00000000000000e0 x22: dead000000000122 [ 9436.262188][ C4] x21: 000000010022da29 x20: ffffff8af72b4e80 [ 9436.262191][ C4] x19: ffffffc010023e50 x18: ffffffc010025038 [ 9436.262195][ C4] x17: 0000000000000240 x16: 0000000000000201 [ 9436.262199][ C4] x15: ffffffffffffffff x14: ffffff889f3c3100 [ 9436.262203][ C4] x13: ffffff889f3c3100 x12: 00000000049f56b8 [ 9436.262207][ C4] x11: 00000000049f56b8 x10: 00000000ffffffff [ 9436.262212][ C4] x9 : ffffffc010023e50 x8 : dead000000000122 [ 9436.262216][ C4] x7 : ffffffffffffffff x6 : ffffffc0100239d8 [ 9436.262220][ C4] x5 : 0000000000000000 x4 : 0000000000000101 [ 9436.262223][ C4] x3 : 0000000000000080 x2 : ffffff889edc155c [ 9436.262227][ C4] x1 : ffffff8001005200 x0 : ffffff80444f0428 [ 9436.262232][ C4] Call trace: [ 9436.262236][ C4] expire_timers+0x9c/0x438 [ 9436.262240][ C4] __run_timers+0x1f0/0x330 [ 9436.262245][ C4] run_timer_softirq+0x28/0x58 [ 9436.262255][ C4] efi_header_end+0x168/0x5ec [ 9436.262265][ C4] __irq_exit_rcu+0x108/0x124 [ 9436.262274][ C4] __handle_domain_irq+0x118/0x1e4 [ 9436.262282][ C4] gic_handle_irq.30369+0x6c/0x2bc [ 9436.262286][ C4] el0_irq_naked+0x60/0x6c Link: https://lore.kernel.org/all/[email protected]/ Reported-by: Joyyoung Huang <[email protected]> Acked-by: MyungJoo Ham <[email protected]> Signed-off-by: Mukesh Ojha <[email protected]> Signed-off-by: Chanwoo Choi <[email protected]>
* PM / devfreq: Convert to use sysfs_emit_at() APIChristian Marangi2023-11-131-20/+17
| | | | | | | | | | Follow the advice of the Documentation/filesystems/sysfs.rst and show() should only use sysfs_emit() or sysfs_emit_at() when formatting the value to be returned to user space. Link: https://lore.kernel.org/all/[email protected]/ Signed-off-by: Christian Marangi <[email protected]> Signed-off-by: Chanwoo Choi <[email protected]>
* PM / devfreq: Fix buffer overflow in trans_stat_showChristian Marangi2023-11-131-18/+39
| | | | | | | | | | | | | | | | | | | | | | | Fix buffer overflow in trans_stat_show(). Convert simple snprintf to the more secure scnprintf with size of PAGE_SIZE. Add condition checking if we are exceeding PAGE_SIZE and exit early from loop. Also add at the end a warning that we exceeded PAGE_SIZE and that stats is disabled. Return -EFBIG in the case where we don't have enough space to write the full transition table. Also document in the ABI that this function can return -EFBIG error. Link: https://lore.kernel.org/all/[email protected]/ Cc: [email protected] Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218041 Fixes: e552bbaf5b98 ("PM / devfreq: Add sysfs node for representing frequency transition information.") Signed-off-by: Christian Marangi <[email protected]> Signed-off-by: Chanwoo Choi <[email protected]>
* PM / devfreq: rockchip-dfi: add support for RK3588Sascha Hauer2023-10-191-1/+35
| | | | | | | | | | | | | | 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/[email protected]/ Reviewed-by: Jonathan Cameron <[email protected]> Reviewed-by: Sebastian Reichel <[email protected]> Acked-by: Chanwoo Choi <[email protected]> Acked-by: Heiko Stuebner <[email protected]> Signed-off-by: Sascha Hauer <[email protected]> Signed-off-by: Chanwoo Choi <[email protected]>
* PM / devfreq: rockchip-dfi: account for multiple DDRMON_CTRL registersSascha Hauer2023-10-191-24/+49
| | | | | | | | | | | | | | | | | 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/[email protected]/ Reviewed-by: Jonathan Cameron <[email protected]> Reviewed-by: Sebastian Reichel <[email protected]> Signed-off-by: Sascha Hauer <[email protected]> Signed-off-by: Chanwoo Choi <[email protected]>
* PM / devfreq: rockchip-dfi: make register stride SoC specificSascha Hauer2023-10-191-4/+9
| | | | | | | | | | | | | | | 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/[email protected]/ Reviewed-by: Jonathan Cameron <[email protected]> Reviewed-by: Sebastian Reichel <[email protected]> Signed-off-by: Sascha Hauer <[email protected]> Signed-off-by: Chanwoo Choi <[email protected]>
* PM / devfreq: rockchip-dfi: Add perf supportSascha Hauer2023-10-191-5/+435
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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/[email protected]/ Reviewed-by: Sebastian Reichel <[email protected]> Acked-by: Chanwoo Choi <[email protected]> Acked-by: Heiko Stuebner <[email protected]> Signed-off-by: Sascha Hauer <[email protected]> [cw00.choi: Fix typo from 'write_acccess' to 'write_access'] Signed-off-by: Chanwoo Choi <[email protected]>
* PM / devfreq: rockchip-dfi: give variable a better nameSascha Hauer2023-10-191-7/+12
| | | | | | | | | | | | | 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/[email protected]/ Reviewed-by: Sebastian Reichel <[email protected]> Acked-by: Chanwoo Choi <[email protected]> Signed-off-by: Sascha Hauer <[email protected]> Signed-off-by: Chanwoo Choi <[email protected]>
* PM / devfreq: rockchip-dfi: Prepare for multiple usersSascha Hauer2023-10-191-17/+40
| | | | | | | | | | | | | | | 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/[email protected]/ Reviewed-by: Jonathan Cameron <[email protected]> Reviewed-by: Sebastian Reichel <[email protected]> Acked-by: Chanwoo Choi <[email protected]> Signed-off-by: Sascha Hauer <[email protected]> Signed-off-by: Chanwoo Choi <[email protected]>
* PM / devfreq: rockchip-dfi: Pass private data struct to internal functionsSascha Hauer2023-10-191-9/+6
| | | | | | | | | | | | | The internal functions do not need the struct devfreq_event_dev *, so pass them the struct rockchip_dfi *. This is a preparation for adding perf support later which doesn't have a struct devfreq_event_dev *. Link: https://lore.kernel.org/all/[email protected]/ Reviewed-by: Jonathan Cameron <[email protected]> Reviewed-by: Sebastian Reichel <[email protected]> Acked-by: Chanwoo Choi <[email protected]> Signed-off-by: Sascha Hauer <[email protected]> Signed-off-by: Chanwoo Choi <[email protected]>
* PM / devfreq: rockchip-dfi: Handle LPDDR4XSascha Hauer2023-10-191-0/+1
| | | | | | | | | | | | | In the DFI driver LPDDR4X can be handled in the same way as LPDDR4. Add the missing case. Link: https://lore.kernel.org/all/[email protected]/ Reviewed-by: Jonathan Cameron <[email protected]> Reviewed-by: Sebastian Reichel <[email protected]> Acked-by: Chanwoo Choi <[email protected]> Acked-by: Heiko Stuebner <[email protected]> Signed-off-by: Sascha Hauer <[email protected]> Signed-off-by: Chanwoo Choi <[email protected]>
* PM / devfreq: rockchip-dfi: Handle LPDDR2 correctlySascha Hauer2023-10-191-2/+9
| | | | | | | | | | | | | | According to the downstream driver the DDRMON_CTRL_LPDDR23 bit must be set for both LPDDR2 and LPDDR3. Add the missing LPDDR2 case and while at it turn the if/else if/else into switch/case which makes it easier to read. Link: https://lore.kernel.org/all/[email protected]/ Reviewed-by: Jonathan Cameron <[email protected]> Reviewed-by: Sebastian Reichel <[email protected]> Acked-by: Chanwoo Choi <[email protected]> Signed-off-by: Sascha Hauer <[email protected]> Signed-off-by: Chanwoo Choi <[email protected]>
* PM / devfreq: rockchip-dfi: Add RK3568 supportSascha Hauer2023-10-191-0/+27
| | | | | | | | | | This adds RK3568 support to the DFI driver. Only iniitialization differs from the currently supported RK3399. Link: https://lore.kernel.org/all/[email protected]/ Signed-off-by: Sascha Hauer <[email protected]> Acked-by: Heiko Stuebner <[email protected]> Signed-off-by: Chanwoo Choi <[email protected]>
* PM / devfreq: rockchip-dfi: Clean up DDR type register definesSascha Hauer2023-10-191-12/+21
| | | | | | | | | | | | | | | | | | Use the HIWORD_UPDATE() define known from other rockchip drivers to make the defines look less odd to the readers who've seen other rockchip drivers. The HIWORD registers have their functional bits in the lower 16 bits whereas the upper 16 bits contain a mask. Only the functional bits that have the corresponding mask bit set are modified during a write. Although the register writes look different, the end result should be the same, at least there's no functional change intended with this patch. Link: https://lore.kernel.org/all/[email protected]/ Signed-off-by: Sascha Hauer <[email protected]> Reviewed-by: Sebastian Reichel <[email protected]> Acked-by: Chanwoo Choi <[email protected]> Signed-off-by: Chanwoo Choi <[email protected]>
* PM / devfreq: rk3399_dmc,dfi: generalize DDRTYPE definesSascha Hauer2023-10-192-9/+10
| | | | | | | | | | | | | | | | The DDRTYPE defines are named to be RK3399 specific, but they can be used for other Rockchip SoCs as well, so replace the RK3399_PMUGRF_ prefix with ROCKCHIP_. They are defined in a SoC specific header file, so when generalizing the prefix also move the new defines to a SoC agnostic header file. While at it use GENMASK to define the DDRTYPE bitfield and give it a name including the full register name. Link: https://lore.kernel.org/all/[email protected]/ Reviewed-by: Sebastian Reichel <[email protected]> Acked-by: Chanwoo Choi <[email protected]> Acked-by: Heiko Stuebner <[email protected]> Signed-off-by: Sascha Hauer <[email protected]> Signed-off-by: Chanwoo Choi <[email protected]>
* PM / devfreq: rockchip-dfi: introduce channel maskSascha Hauer2023-10-181-6/+19
| | | | | | | | | | | Different Rockchip SoC variants have a different number of channels. Introduce a channel mask to make the number of channels configurable from SoC initialization code. Link: https://lore.kernel.org/all/[email protected]/ Reviewed-by: Sebastian Reichel <[email protected]> Signed-off-by: Sascha Hauer <[email protected]> Signed-off-by: Chanwoo Choi <[email protected]>
* PM / devfreq: rockchip-dfi: Use free running counterSascha Hauer2023-10-181-22/+30
| | | | | | | | | | | | | | | | | | | | | | | | The DDR_MON counters are free running counters. These are resetted to 0 when starting them over like currently done when reading the current counter values. Resetting the counters becomes a problem with perf support we want to add later, because perf needs counters that are not modified elsewhere. This patch removes resetting the counters and keeps them running instead. That means we no longer use the absolute counter values but instead compare them with the counter values we read last time. Not stopping the counters also has the impact that they are running while we are reading them. We cannot read multiple timers atomically, so the values do not exactly fit together. The effect should be negligible though as the time between two measurements is some orders of magnitude bigger than the time we need to read multiple registers. Link: https://lore.kernel.org/all/[email protected]/ Reviewed-by: Sebastian Reichel <[email protected]> Acked-by: Chanwoo Choi <[email protected]> Signed-off-by: Sascha Hauer <[email protected]> Signed-off-by: Chanwoo Choi <[email protected]>
* PM / devfreq: mediatek: unlock on error in mtk_ccifreq_target()Dan Carpenter2023-10-171-1/+2
| | | | | | | | | | Call mutex_unlock(&drv->reg_lock) before returning the error code. Link: https://lore.kernel.org/all/[email protected]/ Fixes: d2805601988f ("PM / devfreq: mediatek: protect oop in critical session") Signed-off-by: Dan Carpenter <[email protected]> Reviewed-by: AngeloGioacchino Del Regno <[email protected]> Signed-off-by: Chanwoo Choi <[email protected]>
* PM / devfreq: exynos-ppmu: Use device_get_match_data()Rob Herring2023-10-081-10/+3
| | | | | | | | | | Use preferred device_get_match_data() instead of of_match_device() to get the driver match data. With this, adjust the includes to explicitly include the correct headers. Link: https://lore.kernel.org/all/[email protected]/ Signed-off-by: Rob Herring <[email protected]> Signed-off-by: Chanwoo Choi <[email protected]>
* PM / devfreq: rockchip-dfi: dfi store raw values in counter structSascha Hauer2023-10-081-2/+2
| | | | | | | | | | | | When adding perf support to the DFI driver the perf part will need the raw counter values, so move the fixed * 4 factor to rockchip_dfi_get_event(). Link: https://lore.kernel.org/lkml/[email protected]/ Reviewed-by: Jonathan Cameron <[email protected]> Reviewed-by: Sebastian Reichel <[email protected]> Signed-off-by: Sascha Hauer <[email protected]> Signed-off-by: Chanwoo Choi <[email protected]>
* PM / devfreq: rockchip-dfi: Add SoC specific init functionSascha Hauer2023-10-081-15/+33
| | | | | | | | | | Move the RK3399 specifics to a SoC specific init function to make the way free for supporting other SoCs later. Link: https://lore.kernel.org/lkml/[email protected]/ Reviewed-by: Sebastian Reichel <[email protected]> Signed-off-by: Sascha Hauer <[email protected]> Signed-off-by: Chanwoo Choi <[email protected]>
* PM / devfreq: rockchip-dfi: use consistent name for private data structSascha Hauer2023-10-081-36/+36
| | | | | | | | | | | | | The variable name for the private data struct is 'info' in some functions and 'data' in others. Both names do not give a clue what type the variable has, so consistently use 'dfi'. Link: https://lore.kernel.org/lkml/[email protected]/ Reviewed-by: Heiko Stuebner <[email protected]> Reviewed-by: Jonathan Cameron <[email protected]> Reviewed-by: Sebastian Reichel <[email protected]> Signed-off-by: Sascha Hauer <[email protected]> Signed-off-by: Chanwoo Choi <[email protected]>
* PM / devfreq: rockchip-dfi: Embed desc into private data structSascha Hauer2023-10-081-6/+2
| | | | | | | | | | | | No need for an extra allocation, just embed the struct devfreq_event_desc into the private data struct. Link: https://lore.kernel.org/lkml/[email protected]/ Reviewed-by: Heiko Stuebner <[email protected]> Reviewed-by: Jonathan Cameron <[email protected]> Reviewed-by: Sebastian Reichel <[email protected]> Signed-off-by: Sascha Hauer <[email protected]> Signed-off-by: Chanwoo Choi <[email protected]>
generated by cgit (git 2.51.2) at 2025-12-04 07:18:19 +0000