On 2 November 2016 at 11:14, Peter Wu <peter@xxxxxxxxxxxxx> wrote: > On Tue, Nov 01, 2016 at 06:13:34PM +0000, Emil Velikov wrote: >> sysfs file wakes up the device. The latter of which may >> be slow and isn't required to begin with. >> >> Reading through config is/was required since the revision is not >> available by other means, although with a kernel patch in the way we can >> 'cheat' temporarily. >> >> That should be fine, since no open-source project has ever used the >> value. >> >> Cc: Michel Dänzer <michel.daenzer@xxxxxxx> >> Cc: Mauro Santos <registo.mailling@xxxxxxxxx> >> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98502 >> Signed-off-by: Emil Velikov <emil.velikov@xxxxxxxxxxxxx> > > See below for one observation. Other than that, strace confirms that > the new sysfs files are being accessed. > > Reviewed-and-tested-by: Peter Wu <peter@xxxxxxxxxxxxx> > > This was tested with Linux 4.8.4 (unpatched) and libdrm 2.4.71 (+this > patch) with i915 + nouveau. Tested with running glxgears and glxinfo. > Note that glxinfo still accesses 'config' due to libpciaccess. > > + drm_intel_get_aperture_sizes > + drm_intel_probe_agp_aperture_size > + pci_system_init() > + pci_system_linux_sysfs_create > + populate_entries > + pci_device_linux_sysfs_read() <-- offending function > + pci_device_find_by_slot(0, 0, 2, 0) > > That populate_entries function can probably use a fix similar to this > one. > Indeed it would, although we ought to check if that won't cause any (extra) regressions. Skimming through my distro (Arch) the following depend on libpciaccess: intel-gpu-tools libdrm libvirt radeontool spice-vdagent vbetool xorg-server Of which the first two are safe, while the last one isn't + it even exports the revision to DDX via xf86str.h's GDevRec::chipRev Which gives us even more places to check through. Can you lend a hand ? Thanks Emil _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
