On Mon, Jun 23, 2014 at 2:00 PM, Martin Peres <martin.peres@xxxxxxx> wrote: > Le 23/06/2014 19:56, Ilia Mirkin a écrit : > >> On Mon, Jun 23, 2014 at 1:46 PM, Martin Peres <martin.peres@xxxxxxx> >> wrote: >>> >>> Le 23/06/2014 18:40, Ilia Mirkin a écrit : >>>> >>>> >>>> On Mon, Jun 23, 2014 at 12:36 PM, Greg KH <greg@xxxxxxxxx> 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? That would only be in debugfs. pstate would just list the available levels and let you set one. (or 'auto', as you point out below) > > 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. Yeah, we could do something like that... ugh, the battery/ac stuff is a complication. Unclear whether that belongs in the kernel in the first place... but I guess other drivers do it? _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
