lkml.org 
[lkml]   [2020]   [Jan]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH 2/2] PM / devfreq: Add devfreq_transitions debugfs file
From
Date
08.01.2020 00:48, Bjorn Andersson пишет:
> On Tue 07 Jan 01:05 PST 2020, Chanwoo Choi wrote:
>
>> Add new devfreq_transitions debugfs file to track the frequency transitions
>> of all devfreq devices for the simple profiling as following:
>> - /sys/kernel/debug/devfreq/devfreq_transitions
>>
>> And the user can decide the storage size (CONFIG_NR_DEVFREQ_TRANSITIONS)
>> in Kconfig in order to save the transition history.
>>
>> [Detailed description of each field of 'devfreq_transitions' debugfs file]
>> - time_ms : Change time of frequency transition. (unit: millisecond)
>> - dev_name : Device name of h/w.
>> - dev : Device name made by devfreq core.
>> - parent_dev : If devfreq device uses the passive governor,
>> show parent devfreq device name.
>> - load_% : If devfreq device uses the simple_ondemand governor,
>> load is used by governor whene deciding the new frequency.
>> (unit: percentage)
>> - old_freq_hz : Frequency before changing. (unit: hz)
>> - new_freq_hz : Frequency after changed. (unit: hz)
>>
>> [For example on Exynos5422-based Odroid-XU3 board]
>> $ cat /sys/kernel/debug/devfreq/devfreq_transitions
>> time_ms dev_name dev parent_dev load_% old_freq_hz new_freq_hz
>> ---------- ------------------------------ ---------- ---------- ---------- ------------ ------------
>> 14600 soc:bus_noc devfreq2 devfreq1 0 100000000 67000000
>> 14600 soc:bus_fsys_apb devfreq3 devfreq1 0 200000000 100000000
>> 14600 soc:bus_fsys devfreq4 devfreq1 0 200000000 100000000
>> 14600 soc:bus_fsys2 devfreq5 devfreq1 0 150000000 75000000
>> 14602 soc:bus_mfc devfreq6 devfreq1 0 222000000 96000000
>> 14602 soc:bus_gen devfreq7 devfreq1 0 267000000 89000000
>> 14602 soc:bus_g2d devfreq9 devfreq1 0 300000000 84000000
>> 14602 soc:bus_g2d_acp devfreq10 devfreq1 0 267000000 67000000
>> 14602 soc:bus_jpeg devfreq11 devfreq1 0 300000000 75000000
>> 14602 soc:bus_jpeg_apb devfreq12 devfreq1 0 167000000 84000000
>> 14603 soc:bus_disp1_fimd devfreq13 devfreq1 0 200000000 120000000
>> 14603 soc:bus_disp1 devfreq14 devfreq1 0 300000000 120000000
>> 14606 soc:bus_gscl_scaler devfreq15 devfreq1 0 300000000 150000000
>> 14606 soc:bus_mscl devfreq16 devfreq1 0 333000000 84000000
>> 14608 soc:bus_wcore devfreq1 9 333000000 84000000
>> 14783 10c20000.memory-controller devfreq0 35 825000000 633000000
>> 15873 soc:bus_wcore devfreq1 41 84000000 400000000
>> 15873 soc:bus_noc devfreq2 devfreq1 0 67000000 100000000
>> [snip]
>>
>
> Wouldn't it make more sense to expose this through the tracing
> framework - like many other subsystems does?

I think devfreq core already has some tracing support and indeed it
should be better to extend it rather than duplicate.

\
 
 \ /
  Last update: 2020-01-08 15:21    [W:0.231 / U:1.480 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site