Le 23/06/2014 19:56, Ilia Mirkin a ?crit : > On Mon, Jun 23, 2014 at 1:46 PM, Martin Peres <martin.peres at free.fr> wrote: >> Le 23/06/2014 18:40, Ilia Mirkin a ?crit : >>> >>> On Mon, Jun 23, 2014 at 12:36 PM, Greg KH <greg at kroah.com> 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.
