From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?ISO-8859-1?Q?Christian_K=F6nig?= Subject: Re: [PATCH] radeon: Make PM info available to all, not just debug users Date: Mon, 04 Jun 2012 18:18:10 +0200 Message-ID: <4FCCDFC2.6060602@vodafone.de> References: <20120602190858.335065e1.cand@gmx.com> <4FCB4266.80907@vodafone.de> <20120604114431.aeeda075.cand@gmx.com> <4FCC9C56.2000505@vodafone.de> <4FCCACBD.4030401@free.fr> <4FCCCDEC.8010400@free.fr> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" Content-Transfer-Encoding: quoted-printable Return-path: Received: from outgoing.email.vodafone.de (outgoing.email.vodafone.de [139.7.28.128]) by gabe.freedesktop.org (Postfix) with ESMTP id 9E13A9F36D for ; Mon, 4 Jun 2012 09:18:14 -0700 (PDT) In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org Errors-To: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org To: Jerome Glisse Cc: cand@gmx.com, dri-devel@lists.freedesktop.org List-Id: dri-devel@lists.freedesktop.org On 04.06.2012 17:18, Jerome Glisse wrote: > On Mon, Jun 4, 2012 at 11:02 AM, Martin Peres wrot= e: >> Le 04/06/2012 16:31, Jerome Glisse a =E9crit : >> >>> 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 co= uld >> 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.