[PATCH v3] PCI: create revision file in sysfs

[Lukas Wunner]

On Wed, Nov 16, 2016 at 02:58:11PM -0600, Bjorn Helgaas wrote:
> On Mon, Nov 14, 2016 at 07:40:03PM +0100, Daniel Vetter wrote:
> > On Fri, Nov 11, 2016 at 02:37:23PM +0000, Emil Velikov wrote:
> > > From: Emil Velikov <emil.velikov at collabora.com>
> > > 
> > > Currently the revision isn't available via sysfs/libudev thus if one
> > > wants to know the value they need to read through the config file.
> > > 
> > > This in itself wakes/powers up the device, causing unwanted delay
> > > since it can be quite costly.
> > > 
> > > There are at least two userspace components which could make use the new
> > > file libpciaccess and libdrm. The former [used in various places] wakes
> > > up _every_ PCI device, which can be observed via glxinfo [when using
> > > Mesa 10.0+ drivers]. While the latter [in association with Mesa 13.0]
> > > can lead to 2-3 second delays while starting firefox, thunderbird or
> > > chromium.
> > > 
> > > Expose the revision as a separate file, just like we do for the device,
> > > vendor, their subsystem version and class.
> > > 
> > > Cc: Bjorn Helgaas <bhelgaas at google.com>
> > > Cc: linux-pci at vger.kernel.org
> > > Cc: Greg KH <gregkh at linuxfoundation.org>
> > > Link: https://bugs.freedesktop.org/show_bug.cgi?id=98502
> > > Tested-by: Mauro Santos <registo.mailling at gmail.com>
> > > Reviewed-by: Alex Deucher <alexander.deucher at amd.com>
> > > Signed-off-by: Emil Velikov <emil.velikov at collabora.com>
> > 
> > Given that waking a gpu can take somewhere between ages and forever, and
> > that we read the pci revisions everytime we launch a new gl app I think
> > this is the correct approach. Of course we could just patch libdrm and
> > everyone to not look at the pci revision, but that just leads to every
> > pci-based driver having a driver-private ioctl/getparam thing to expose
> > it. Which also doesn't make much sense.
> 
> This re-asserts what has already been said, but doesn't address any of
> my questions in the v2 discussion, so I'm still looking to continue
> that thread.
> 
> I am curious about this long wakeup issue, though.  Are we talking
> about a D3cold -> D0 transition?

Yes, this is about a D3cold -> D0 transition, the bugzilla entry
Emil linked talks about a dual GPU notebook.

E.g. the Nvidia Kepler GPU in my MacBook Pro has 5 different power
rails which must be brought up in a specific sequence (3.3V, 1.8V, 5V
for the GPU, 1.35V for the video RAM and 1.05V for PCIe), something
on the order of half a second to one second is reasonable for that.

And the DRM driver needs a lot of time as well, half a second in
the case of nouveau:

[ 1500.780052] nouveau 0000:01:00.0: DRM: resuming kernel object tree...
[ 1501.176616] nouveau 0000:01:00.0: DRM: resuming client object trees...
[ 1501.176672] nouveau 0000:01:00.0: DRM: resuming display...
[ 1501.298985] nouveau 0000:01:00.0: DRM: resuming console...

There are no special PCIe things happening here. And since Sinan asked,
these discrete GPUs usually aren't located behind a bridge, just a
regular root port.

Thanks,

Lukas