Le 04/06/2012 13:30, Christian König a écrit :
On 04.06.2012 10:44, Lauri Kasanen wrote:
So the issue is the location of the info, not the format. I'd be more
than happy to split it into six files (default_core_clock,
current_core_clock...) that each offer just a kHz number, just like
the cpufreq scaling_cur_freq do. Would that be preferable?
Yeah, that sounds like a start, and also only register those files if
the clock in question is really available, e. g. integrated chipsets
doesn't have a memory clock for example.
But I have my doubts that it would be accepted easily, cause for
debugfs we can pretty much pump every information in there we want,
while sysfs files must maintain a more or less stable API for setting
system parameters, see Documentation/sysfs-rules.txt.
Christian.
Hey everyone,
Now that we talk about this, I think we need a common way to expose
clocks and performance levels across drm drivers. At the moment,
Nouveau's sysfs interface for PM is all but great. I'm sure we can all
agree on a common interface.
NVIDIA PM is performance-level based (up to 4 + possible overclocking).
IIRC, AMD uses perflvls too (3, low, middle and high). No idea about
Intel but I'm curious about their boost feature.
I also don't know how many reclockable domains you have, but so far, we
reclock 9 domains.
What we could want to expose:
- 1) Several performance profiles (boot, 0, 1 ,2 ,3 , dynamic, custom)
- 2) Selectable performance profile for battery/sector (arguable)
- 3) Clocks for each performance profile
- 4) Voltage for the performance profile (there may be voltage domains too)
- 5) The custom performance profile should allow the user to set clocks
and voltage
= Performance profile representation =
I think that exposing one sysfs per clock per perflvl is insane, at
least on Nouveau (that would result in 63 files). At the moment, we
expose some clocks of a perflvl in one readable single line (c: core
405MHz shader 810MHz memory 405MHz voltage 900mV)
However, this is kind of against the sysfs rule that sysfs is not a
human interface. We didn't pay attention to it but we'll have to do it soon.
IMO, we should use one sysfs file per performance profile and then
display clocks as a csv. Each column meaning a different domain. If a
domain is not available on a given card, then the advertised clock
should be 0. That should allow us to add new domains when needed.
The custom performance level could be constructed in the same way.
However, I'm not sure about what should be done for voltage. At the
moment, we have only one adjustable voltage domain. It may however
change in the future. The solution may be to have 2 sysfs files per
performance profile, one exposing clocks and one exposing voltages.
= Setting clocks =
The user can only select between a few performance profiles:
- the boot clocks
- the performance levels as found in the vbios
- the dynamic profile that switches between the vbios perflvls according
to the load
- the custom profile, for tweakers
Currently, we allow the user to set 2 performances profiles, one will be
used when on battery and one is used when on sector. If the user sets
only one performance profile, then it is used in both cases.
Example: Both values are specified in one write:
echo 0,2 > /sys/class/drm/card0/device/performance_level
= Reading clocks =
I see 3 important informations we need to export:
- The current performance profile
- The current clocks & voltages
- The settings actually set by the user (battery/sector perflvl)
= Anything else ? =
What do you think? Did I forgot anything? How would this idea map to
your hardware/drivers?
Martin
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
