Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752437AbaFWSCS (ORCPT ); Mon, 23 Jun 2014 14:02:18 -0400 Received: from smtp3-g21.free.fr ([212.27.42.3]:17928 "EHLO smtp3-g21.free.fr" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751100AbaFWSCR (ORCPT ); Mon, 23 Jun 2014 14:02:17 -0400 Message-ID: <53A86B31.8090307@free.fr> Date: Mon, 23 Jun 2014 20:00:17 +0200 From: Martin Peres User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Ilia Mirkin CC: Greg KH , kernel list , "dri-devel@lists.freedesktop.org" , Ben Skeggs , Pavel Machek Subject: Re: unparseable, undocumented /sys/class/drm/.../pstate References: <20140621180201.GA4621@amd.pavel.ucw.cz> <20140621194538.GA4903@kroah.com> <20140623160727.GA19557@kroah.com> <20140623163600.GB20939@kroah.com> <53A867DB.90604@free.fr> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Le 23/06/2014 19:56, Ilia Mirkin a écrit : > On Mon, Jun 23, 2014 at 1:46 PM, Martin Peres wrote: >> Le 23/06/2014 18:40, Ilia Mirkin a écrit : >>> >>> 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... > > I was thinking just having the list of level ids in the pstate file, > and then stick the current file into debugfs. That way people retain > the ability to see things, as well as use pstate directly for a > configured system. In this case, would we still use the * to indicate the current perflvl? Also, are we supposed to output the current perflvl or the current configuration in use? Right now, we configure it to either auto (WIP), perflvl X at all time or perflvl X when on battery and Y when on sector. However, when we read pstate, we only get the current perflvl if my memory serves me right. Maybe we should create a r-o file that outputs the current perflvl and keep pstate for storing the configuration. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/