From mboxrd@z Thu Jan 1 00:00:00 1970 From: Lauri Kasanen Subject: Re: [PATCH] radeon: Make PM info available to all, not just debug users Date: Mon, 4 Jun 2012 19:29:02 +0300 Message-ID: <20120604192902.149fd73d.cand@gmx.com> 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> <4FCCDFC2.6060602@vodafone.de> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Return-path: Received: from mailout-eu.gmx.com (mailout-eu.gmx.com [213.165.64.42]) by gabe.freedesktop.org (Postfix) with SMTP id B687C9F381 for ; Mon, 4 Jun 2012 09:30:00 -0700 (PDT) In-Reply-To: <4FCCDFC2.6060602@vodafone.de> 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: Christian =?ISO-8859-15?Q?K=F6nig?= Cc: cand@gmx.com, dri-devel@lists.freedesktop.org List-Id: dri-devel@lists.freedesktop.org On Mon, 04 Jun 2012 18:18:10 +0200 Christian K=F6nig wrote: > > 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. Hi As long as the info is made available better than it is currently, I'm all = for it. Though with the direction of ioctl and folks, it is deep outside my experti= se. With a deep solution like that someone who knows the area well would ne= ed to do it. - Lauri