Re: unparseable, undocumented /sys/class/drm/.../pstate

[Martin Peres <martin.peres@free.fr>]

Le 23/06/2014 19:56, Ilia Mirkin a écrit :
> On Mon, Jun 23, 2014 at 1:46 PM, Martin Peres <martin.peres@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@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.