Date:	Tue, 24 Jun 2014 10:06:06 +1000
From:	Ben Skeggs <skeggsb@...il.com>
To:	Greg KH <greg@...ah.com>
Cc:	Ilia Mirkin <imirkin@...m.mit.edu>,
	kernel list <linux-kernel@...r.kernel.org>,
	"dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>,
	Ben Skeggs <bskeggs@...hat.com>, Pavel Machek <pavel@....cz>
Subject: Re: unparseable, undocumented /sys/class/drm/.../pstate

On Tue, Jun 24, 2014 at 6:26 AM, Greg KH <greg@...ah.com> wrote:
> On Mon, Jun 23, 2014 at 04:18:39PM -0400, Ilia Mirkin wrote:
>> On Mon, Jun 23, 2014 at 4:15 PM, Pavel Machek <pavel@....cz> wrote:
>> > Hi!
>> >
>> >> >> >> > I guess better interface would be something like
>> >> >> >> >
>> >> >> >> > pstate/07/core_clock_min
>> >> >> >> >           core_clock_max
>> >> >> >> >           memory_clock_min
>> >> >> >> >           memory_clock_max
>> >> >> >> >
>> >> >> >> > and then pstate/active containing just the number of active state?
>> >> >
>> >> >> Could we just say that the format of this file is one-per-line of
>> >> >>
>> >> >> level: information-for-the-user
>> >> >
>> >> > But it is not.
>> >>
>> >> But it is...
>> >>
>> >> > Management tools will want to parse it, sooner or
>> >> > later.  What is wrong with solution described above?
>> >>
>> >> It is complex and annoying to the people that will actually use it.
>> >
>> > grep -r . pstate/ is actually not that bad...
>>
>> While that's a clever trick that anyone who's done a bunch of stuff
>> with sysfs knows, I doubt the average linux user could come up with
>> that on their own. I know I didn't.
>
> That's fine, why would an "average" Linux user ever need to poke around
> in sysfs?  Again, please describe what you are wanting to have exported
> to userspace, and what userspace is supposed to do with that
> information, before worrying about the actual sysfs file layout.
Because, at the moment, we can't by default give any kind of automatic
clock management policy due to the fact that in a great number of
cases, we'll likely hang the GPU when changing clock speeds.  The
VBIOS defaults aren't sufficient for more demanding games etc, and
people might want to try/risk selecting the highest level anyway to
see if it'll work for them.  When things actually work, this will all
automagically happen based on load and users should never need to
touch it.

So, we want a file users can write the level identifier into.  Which,
shockingly, is exactly what the file currently does.

I, however, also decided that people might actually want to know what
this "0x0a" they're echoing into the file actually means; So, in the
output (which is a list of valid identifiers), after the identifier
there's a bunch of "<name> <value>" pairs giving an overview of that
this mysterious "0x0a" is.

Sure, we can remove the information and have the informationless list
of identifiers and we'd suddenly be strictly obeying the rules, then
we've also made any potential userspace tool that we're worried about
a lot more useless (what's it going to do, a drop-down list of 0x07,
0x0a, 0x0e, 0x0f?).

Sure, we can split this all up into a directory structure; and make it
a lot more cumbersome for the intended target of the user who just
wants to override an unfortunate but currently necessary default.  I'm
not sure how exactly one-per-line "<id>: <name> <min>-<max> ..." is
hard for userspace to deal with (scanf anyone?), but a directory
structure won't be any easier, the available files will still differ
with each card generation etc and userspace will just have to loop
over a directory list instead of each line of a single file.

But, as I said on IRC yesterday, let's just move this to debugfs to
save this waste of time argument, and move on.

Ben.


>
> greg k-h
> _______________________________________________
> dri-devel mailing list
> dri-devel@...ts.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists