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

[Martin Peres]

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?

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/