From mboxrd@z Thu Jan 1 00:00:00 1970 From: Martin Peres Subject: Re: unparseable, undocumented /sys/class/drm/.../pstate Date: Mon, 23 Jun 2014 19:46:03 +0200 Message-ID: <53A867DB.90604@free.fr> References: <20140621180201.GA4621@amd.pavel.ucw.cz> <20140621194538.GA4903@kroah.com> <20140623160727.GA19557@kroah.com> <20140623163600.GB20939@kroah.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" Content-Transfer-Encoding: quoted-printable Return-path: Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) by gabe.freedesktop.org (Postfix) with ESMTP id AB5406E3BC for ; Mon, 23 Jun 2014 10:48:05 -0700 (PDT) In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Ilia Mirkin , Greg KH Cc: Pavel Machek , kernel list , "dri-devel@lists.freedesktop.org" , Ben Skeggs List-Id: dri-devel@lists.freedesktop.org Le 23/06/2014 18:40, Ilia Mirkin a =E9crit : > On Mon, Jun 23, 2014 at 12:36 PM, Greg KH wrote: >> On Mon, Jun 23, 2014 at 12:18:51PM -0400, Ilia Mirkin wrote: >> A list of valid "values" that a file can be in is fine if you just then >> write one value back to that file. That's the one exception, but a >> minor one given the huge number of sysfs files. Other than that, if you > > Which is pretty much what the pstate file is. Would it make things > better if we removed the descriptive info while leaving the pstate > file in place? This means we should also create a new sysfs file per performance level = too, right? Is there another way for a driver to expose a list in sysfs? Since NVIDIA gives different names to performance levels depending on = the card family, we may need to abstract the name away in order to = provide some consistency and make listing performance levels easier from = a program (may it use readdir() or stat()). Moving the file to debugfs would "fix" the one-value-per-file rule but = it would also require users to mount debugfs at boot time in order to = write the default configuration they want for PM instead of just = changing /etc/sysctl.d/nouveau.conf... On the other hand, I'm not sure = we can commit on having a stable ABI on the way we display clocks = (unless people take them as a single value and do not try to parse them) = as new hardware will alter the semantics of each clock domain, if not = drop/split some of them! Whatever we do, it doesn't look like we can find a nice solution that = fits every use cases unless we write a userspace program to access this = data, but this seems highly overkill...