Re: [PATCH libdrm] xf86drm: Parse the separate files to retrieve the vendor/device info

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 08-11-2016 15:00, Emil Velikov wrote:
> On 8 November 2016 at 13:38, Mauro Santos <registo.mailling@xxxxxxxxx> wrote:
>> On 08-11-2016 11:06, Emil Velikov wrote:
>>> On 1 November 2016 at 18:47, Mauro Santos <registo.mailling@xxxxxxxxx> wrote:
>>>> On 01-11-2016 18:13, Emil Velikov wrote:
>>>>> From: Emil Velikov <emil.velikov@xxxxxxxxxxxxx>
>>>>>
>>>>> Parsing config 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>
>>>>> ---
>>>>> Mauro can you apply this against libdrm and rebuild it. You do _not_
>>>>> need to rebuild mesa afterwords.
>>>>>
>>>>> Thanks
>>>>> ---
>>>>>  xf86drm.c | 50 +++++++++++++++++++++++++++++++++++---------------
>>>>>  1 file changed, 35 insertions(+), 15 deletions(-)
>>>>>
>>>>> diff --git a/xf86drm.c b/xf86drm.c
>>>>> index 52add5e..5a5100c 100644
>>>>> --- a/xf86drm.c
>>>>> +++ b/xf86drm.c
>>>>> @@ -2950,25 +2950,45 @@ static int drmParsePciDeviceInfo(const char *d_name,
>>>>>                                   drmPciDeviceInfoPtr device)
>>>>>  {
>>>>>  #ifdef __linux__
>>>>> +#define ARRAY_SIZE(a) (sizeof(a) / sizeof((a)[0]))
>>>>> +    static const char *attrs[] = {
>>>>> +      "revision", /* XXX: make sure it's always first, see note below */
>>>>> +      "vendor",
>>>>> +      "device",
>>>>> +      "subsystem_vendor",
>>>>> +      "subsystem_device",
>>>>> +    };
>>>>>      char path[PATH_MAX + 1];
>>>>> -    unsigned char config[64];
>>>>> -    int fd, ret;
>>>>> +    unsigned int data[ARRAY_SIZE(attrs)];
>>>>> +    FILE *fp;
>>>>> +    int ret;
>>>>>
>>>>> -    snprintf(path, PATH_MAX, "/sys/class/drm/%s/device/config", d_name);
>>>>> -    fd = open(path, O_RDONLY);
>>>>> -    if (fd < 0)
>>>>> -        return -errno;
>>>>> +    for (unsigned i = 0; i < ARRAY_SIZE(attrs); i++) {
>>>>> +        snprintf(path, PATH_MAX, "/sys/class/drm/%s/device/%s",
>>>>> +                 d_name, attrs[i]);
>>>>> +        fp = fopen(path, "r");
>>>>> +        if (!fp) {
>>>>> +            /* Note: First we check the revision, since older kernels
>>>>> +             * may not have it. Default to zero in such cases. */
>>>>> +            if (i == 0) {
>>>>> +                data[i] = 0;
>>>>> +                continue;
>>>>> +            }
>>>>> +            return -errno;
>>>>> +        }
>>>>>
>>>>> -    ret = read(fd, config, sizeof(config));
>>>>> -    close(fd);
>>>>> -    if (ret < 0)
>>>>> -        return -errno;
>>>>> +        ret = fscanf(fp, "%x", &data[i]);
>>>>> +        fclose(fp);
>>>>> +        if (ret != 1)
>>>>> +            return -errno;
>>>>> +
>>>>> +    }
>>>>>
>>>>> -    device->vendor_id = config[0] | (config[1] << 8);
>>>>> -    device->device_id = config[2] | (config[3] << 8);
>>>>> -    device->revision_id = config[8];
>>>>> -    device->subvendor_id = config[44] | (config[45] << 8);
>>>>> -    device->subdevice_id = config[46] | (config[47] << 8);
>>>>> +    device->revision_id = data[0] & 0xff;
>>>>> +    device->vendor_id = data[1] & 0xffff;
>>>>> +    device->device_id = data[2] & 0xffff;
>>>>> +    device->subvendor_id = data[3] & 0xffff;
>>>>> +    device->subdevice_id = data[4] & 0xffff;
>>>>>
>>>>>      return 0;
>>>>>  #else
>>>>>
>>>>
>>>> I have applied this against libdrm 2.4.71 and I don't see any delays
>>>> when starting firefox/chromium/thunderbird/glxgears.
>>>>
>>>> There is also no indication in dmesg that the dGPU is being
>>>> reinitialized when starting the programs where I've detected the problem.
>>>>
>>> Thanks Mauro. Can you give this a try alongside the kernel fix [1] ?
>>> I'd love to get the latter merged soon(ish).
>>> Independent of the kernel side, I might need to go another way for
>>> libdrm/mesa so I'll CC you on future patches.
>>>
>>> Your help is greatly appreciated !
>>>
>>> Thanks
>>> Emil
>>>
>>> [1] http://patchwork.ozlabs.org/patch/689975/
>>>
>>
>> I have applied the patch on top of kernel 4.8.6 and I'm using the libdrm
>> with the patch you sent me previously.
>>
>> With this patch things still seem work fine, I don't see any of the
>> problems I've seen before, but I don't know how to confirm that the
>> value from sysfs is now being used by libdrm instead of defaulting to zero.
>>
> Grr my bad. $libdrm_builddir/tests/drmdevice should do it. You might
> need to explicitly build it (cd tests && make drmdevice)
> 

When running drmdevice as my user it still wakes up the dGPU. The
correct device revisions are being reported by I suppose that is not
being read from sysfs.

sudo dmesg -C && dmesg -w & ./drmdevice

device[0]
	available_nodes 0007
	nodes
		nodes[0] /dev/dri/card1
		nodes[1] /dev/dri/controlD65
		nodes[2] /dev/dri/renderD129
	bustype 0000
	businfo
		pci
			domain	0000
			bus	03
			dev	00
			func	0
	deviceinfo
		pci
			vendor_id	1002
			device_id	6600
			subvendor_id	17aa
			subdevice_id	5049
			revision_id	81

Opening device 0 node /dev/dri/card1
[ 7155.613212] [drm] probing gen 2 caps for device 8086:9d18 = 9724043/e
[ 7155.613218] [drm] enabling PCIE gen 3 link speeds, disable with
radeon.pcie_gen2=0
[ 7157.006460] [drm] PCIE GART of 2048M enabled (table at
0x00000000001D6000).
[ 7157.006603] radeon 0000:03:00.0: WB enabled
[ 7157.006607] radeon 0000:03:00.0: fence driver on ring 0 use gpu addr
0x0000000080000c00 and cpu addr 0xffff88042bb1fc00
[ 7157.006610] radeon 0000:03:00.0: fence driver on ring 1 use gpu addr
0x0000000080000c04 and cpu addr 0xffff88042bb1fc04
[ 7157.006612] radeon 0000:03:00.0: fence driver on ring 2 use gpu addr
0x0000000080000c08 and cpu addr 0xffff88042bb1fc08
[ 7157.006614] radeon 0000:03:00.0: fence driver on ring 3 use gpu addr
0x0000000080000c0c and cpu addr 0xffff88042bb1fc0c
[ 7157.006616] radeon 0000:03:00.0: fence driver on ring 4 use gpu addr
0x0000000080000c10 and cpu addr 0xffff88042bb1fc10
[ 7157.007411] radeon 0000:03:00.0: fence driver on ring 5 use gpu addr
0x0000000000075a18 and cpu addr 0xffffc90002235a18
[ 7157.109456] radeon 0000:03:00.0: failed VCE resume (-110).
[ 7157.340129] [drm] ring test on 0 succeeded in 1 usecs
[ 7157.340136] [drm] ring test on 1 succeeded in 1 usecs
[ 7157.340142] [drm] ring test on 2 succeeded in 1 usecs
[ 7157.340153] [drm] ring test on 3 succeeded in 4 usecs
[ 7157.340163] [drm] ring test on 4 succeeded in 4 usecs
[ 7157.517337] [drm] ring test on 5 succeeded in 2 usecs
[ 7157.517344] [drm] UVD initialized successfully.
[ 7157.517392] [drm] ib test on ring 0 succeeded in 0 usecs
[ 7157.517431] [drm] ib test on ring 1 succeeded in 0 usecs
[ 7157.517474] [drm] ib test on ring 2 succeeded in 0 usecs
[ 7157.517510] [drm] ib test on ring 3 succeeded in 0 usecs
[ 7157.517546] [drm] ib test on ring 4 succeeded in 0 usecs
[ 7158.169561] [drm] ib test on ring 5 succeeded
device[0]
	available_nodes 0007
	nodes
		nodes[0] /dev/dri/card1
		nodes[1] /dev/dri/controlD65
		nodes[2] /dev/dri/renderD129
	bustype 0000
	businfo
		pci
			domain	0000
			bus	03
			dev	00
			func	0
	deviceinfo
		pci
			vendor_id	1002
			device_id	6600
			subvendor_id	17aa
			subdevice_id	5049
			revision_id	81

Opening device 0 node /dev/dri/controlD65
Failed - Permission denied (13)
Opening device 0 node /dev/dri/renderD129
device[0]
	available_nodes 0007
	nodes
		nodes[0] /dev/dri/card1
		nodes[1] /dev/dri/controlD65
		nodes[2] /dev/dri/renderD129
	bustype 0000
	businfo
		pci
			domain	0000
			bus	03
			dev	00
			func	0
	deviceinfo
		pci
			vendor_id	1002
			device_id	6600
			subvendor_id	17aa
			subdevice_id	5049
			revision_id	81

device[1]
	available_nodes 0007
	nodes
		nodes[0] /dev/dri/card0
		nodes[1] /dev/dri/controlD64
		nodes[2] /dev/dri/renderD128
	bustype 0000
	businfo
		pci
			domain	0000
			bus	00
			dev	02
			func	0
	deviceinfo
		pci
			vendor_id	8086
			device_id	1916
			subvendor_id	17aa
			subdevice_id	5049
			revision_id	07

Opening device 1 node /dev/dri/card0
device[1]
	available_nodes 0007
	nodes
		nodes[0] /dev/dri/card0
		nodes[1] /dev/dri/controlD64
		nodes[2] /dev/dri/renderD128
	bustype 0000
	businfo
		pci
			domain	0000
			bus	00
			dev	02
			func	0
	deviceinfo
		pci
			vendor_id	8086
			device_id	1916
			subvendor_id	17aa
			subdevice_id	5049
			revision_id	07

Opening device 1 node /dev/dri/controlD64
Failed - Permission denied (13)
Opening device 1 node /dev/dri/renderD128
device[1]
	available_nodes 0007
	nodes
		nodes[0] /dev/dri/card0
		nodes[1] /dev/dri/controlD64
		nodes[2] /dev/dri/renderD128
	bustype 0000
	businfo
		pci
			domain	0000
			bus	00
			dev	02
			func	0
	deviceinfo
		pci
			vendor_id	8086
			device_id	1916
			subvendor_id	17aa
			subdevice_id	5049
			revision_id	07




>> The values in /sys/class/drm/card{0,1}/device/revision match what is
>> reported by lspci for the iGPU and dGPU.
>> I don't know if it's related but the revision file in
>> /sys/class/pci_bus/0000\:03/device/ does show 0xf1 for both GPUs, which
>> is different from what is shown in /sys/class/drm/card{0,1}/device/revision.
>>
> That's perfect, thanks.
> 
> 0000:03 is (in all likelihood) is the PCI bridge. You can check with
> the device uevent/PCI_SLOT_NAME and cross reference with lspci.
> 

This is right on the money, uevent/PCI_SLOT_NAME does point to the PCI
bridge.

> 
> Emil
> 


-- 
Mauro Santos
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel




[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux