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

[Christian König]

On 04.06.2012 17:18, Jerome Glisse wrote:
> On Mon, Jun 4, 2012 at 11:02 AM, Martin Peres<martin.peres at free.fr>  wrote:
>> Le 04/06/2012 16:31, Jerome Glisse a écrit :
>>
>>> 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
>> Any particular idea of what may change?
>>
>> The proposed interface would work even on entirely dynamic
>> reclocking (per-domain frequency scaling) as opposed to
>> perflvl-based reclocking. It is unlikely to happen though.
>>
>> A more realistic possibility could be that engines would be reclocked
>> independently according to their internal load.
>> If that was to happen, then the already-existing API could be used as
>> a master control and engines could specify the performance level policy
>> they want (follow master, always min, always max, conservative, dynamic).
>>
>> I'm pretty sure voltage domains will soon appear but I don't see what could
>> possibly be changed that wouldn't be covered by what I proposed.
>>
>> As for the reason we would like to use IOCTLs instead of sysfs, I really
>> don't understand what is the rationale. I personally want to empower the
>> users to let them decide what is best for them. Sysfs is way easier to
>> work with!
>>
>> Although my idea may be sketchy, I am dead-serious about coming up with
>> a good API.
>>
>> Martin
> My experience is that things that are true today for GPU, are not
> tomorrow. Yes there will still be clock/voltage, but there could be
> new complete different things, like shutting down block.
>
> I am not even mentioning things like complex value range dependency
> btw things (for instance if a domain as clock/voltage in certain range
> than some other domain can only have clock in a restricted range
> value).
>
> While i agree that sysfs looks easy for user to play with, i believe
> that gui is what you really after and afaik closed source driver all
> expose a gui for their power management. Using ioctl allow better
> overall control, like atomic setting of several domain ...

Yeah, I think Jerome is right here.

The internals like different voltage areas, dependencies of clocks, 
possible powered down chip areas, etc are very complex and actually 
completely unteresting to the end user. Also the general direction of 
AMD hardware is going to a complete self containing system, e.g. the 
chip is handling mostly everything on its own.

I agree that this is better done in a hardware dependent ioctl and then 
abstracted in userspace instead of pushing the whole abstraction into 
the kernel.

Regards,
Christian.