All of lore.kernel.org
 help / color / mirror / Atom feed
From: Martin Peres <martin.peres@free.fr>
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 17:02:04 +0200	[thread overview]
Message-ID: <4FCCCDEC.8010400@free.fr> (raw)
In-Reply-To: <CAH3drwaz9h8K5tayncj_a6b0i_SzeCMKG5UPQo6o9LCLgBqqHg@mail.gmail.com>

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

  reply	other threads:[~2012-06-04 15:02 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 [this message]
2012-06-04 15:18             ` Jerome Glisse
2012-06-04 16:18               ` Christian König
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=4FCCCDEC.8010400@free.fr \
    --to=martin.peres@free.fr \
    --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.