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

[Jerome Glisse]

On Mon, Jun 4, 2012 at 8:40 AM, Martin Peres <martin.peres at free.fr> wrote:
> 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
>

I don't think sysfs is the way to go, i am pretty sure that power
management will change drasticly again in the future especialy btw
discret and integrated GPU. I would rather have hardware specific
ioctl.

Cheers,
Jerome