[PATCH] radeon: Make PM info available to all, not just debug users

[Martin Peres]

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