[PATCH v3] PCI: create revision file in sysfs

[Alex Deucher]

On Fri, Nov 18, 2016 at 4:48 AM, Daniel Vetter <daniel at ffwll.ch> wrote:
> On Fri, Nov 18, 2016 at 10:42:07AM +0100, Daniel Vetter wrote:
>> On Thu, Nov 17, 2016 at 08:40:10PM -0600, Bjorn Helgaas wrote:
>> > On Fri, Nov 18, 2016 at 10:42:20AM +0900, Michel Dänzer wrote:
>> > > On 18/11/16 08:48 AM, Bjorn Helgaas wrote:
>> > > >
>> > > > Popping the stack all the way back to Emil's Nov 8 message:
>> > > >
>> > > >   When using the Mesa drivers alongside firefox [1] (since Mesa 13.0),
>> > > >   glxinfo (Mesa 10.0) and others, all the GPUs* will be awaken,
>> > > >   causing unwanted delays and increased power usage.
>> > > >
>> > > >   [1] https://bugs.freedesktop.org/show_bug.cgi?id=98502
>> > > >
>> > > > The bug is about a delay in starting firefox, thunderbird, or
>> > > > chromium.  I assume the browser starts on the current, powered-up,
>> > > > GPU.  I don't understand why we care about the revision of other,
>> > > > powered-off, GPUs.
>> > >
>> > > We don't. The problem is that the current libdrm API unconditionally
>> > > provides the revision. The plan is to address this in two ways:
>> > >
>> > > * Add new libdrm API which allows the caller to say "I don't need the
>> > > revision", and make Mesa use that. Users having those changes will not
>> > > run into the problem even on older kernels.
>> > >
>> > > * Add the separate revision file in sysfs and make libdrm use that for
>> > > its current API. This means that even callers of the current libdrm API
>> > > will not run into the problem with newer kernels.
>> >
>> > Why do we care about *anything* for the other, powered-off, GPUs?
>> > Even users of the new libdrm API who say "I don't need the revision"
>> > are still getting the vendor/device/etc for those other GPUs.
>>
>> egl device enumeration, and for that you need to know what gpus you have
>> and load their drivers. Afaik. Yes by default they'll all select the
>> online gpu, but they can opt for the faster/other one on multi-gpu
>> machines.
>
> Now the only reason we can avoid parsing the revision flag is that most
> drivers don't care, and the one that does (i915) is generally the one
> that's on and only needs it after driver init. But fundamentally we can't
> avoid the enumeration, and imo it's better to cache this in the kernel
> than implement some userspace thingy (require udev or whatever).
>

We need the revision id as well.

Alex

> I guess in the end I don't really get why caching the revision in the
> kernel is a problem ...
> -Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
> _______________________________________________
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel