All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Christian König" <deathsimple@vodafone.de>
To: Jerome Glisse <j.glisse@gmail.com>
Cc: cand@gmx.com, dri-devel@lists.freedesktop.org
Subject: Re: [PATCH] radeon: Make PM info available to all, not just debug users
Date: Mon, 04 Jun 2012 18:18:10 +0200	[thread overview]
Message-ID: <4FCCDFC2.6060602@vodafone.de> (raw)
In-Reply-To: <CAH3drwZ4D43fgoj-wX2b=bezo0XR6suK3Fgrd+LOpcP_tK=coQ@mail.gmail.com>

On 04.06.2012 17:18, Jerome Glisse wrote:
> On Mon, Jun 4, 2012 at 11:02 AM, Martin Peres<martin.peres@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.

  reply	other threads:[~2012-06-04 16:18 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-02 16:08 [PATCH] radeon: Make PM info available to all, not just debug users Lauri Kasanen
2012-06-03 10:54 ` Christian König
2012-06-04  8:44   ` Lauri Kasanen
2012-06-04 11:30     ` Christian König
2012-06-04 12:30       ` Alex Deucher
2012-06-04 12:40       ` Martin Peres
2012-06-04 14:31         ` Jerome Glisse
2012-06-04 15:02           ` Martin Peres
2012-06-04 15:18             ` Jerome Glisse
2012-06-04 16:18               ` Christian König [this message]
2012-06-04 16:29                 ` Lauri Kasanen
2012-06-04 17:05                   ` Jerome Glisse
2012-06-05 10:11                     ` Lauri Kasanen
2012-06-04 17:01               ` Martin Peres
2012-06-04 17:19                 ` Jerome Glisse
2012-06-04 17:54                   ` Martin Peres
2012-06-04 18:18                     ` Jerome Glisse
2012-06-04 18:29                       ` Jerome Glisse
2012-06-04 20:31                         ` Martin Peres
2012-06-04 19:54                       ` Daniel Vetter
2012-06-04 20:34                         ` Martin Peres

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4FCCDFC2.6060602@vodafone.de \
    --to=deathsimple@vodafone.de \
    --cc=cand@gmx.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=j.glisse@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.