From: Emil Velikov <emil.l.velikov@gmail.com>
To: Mauro Santos <registo.mailling@gmail.com>
Cc: "Michel Dänzer" <michel.daenzer@amd.com>,
"ML dri-devel" <dri-devel@lists.freedesktop.org>
Subject: Re: [PATCH libdrm] xf86drm: Parse the separate files to retrieve the vendor/device info
Date: Tue, 8 Nov 2016 11:06:29 +0000 [thread overview]
Message-ID: <CACvgo531RLdtVy_tXYKNa27DLiQBKBMcPA7kC_COqnpXBSvB4A@mail.gmail.com> (raw)
In-Reply-To: <2cdd903e-2af6-fcdf-9987-de1db667906c@gmail.com>
On 1 November 2016 at 18:47, Mauro Santos <registo.mailling@gmail.com> wrote:
> On 01-11-2016 18:13, Emil Velikov wrote:
>> From: Emil Velikov <emil.velikov@collabora.com>
>>
>> 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@amd.com>
>> Cc: Mauro Santos <registo.mailling@gmail.com>
>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98502
>> Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
>> ---
>> 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/
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2016-11-08 11:06 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-01 18:13 [PATCH libdrm] xf86drm: Parse the separate files to retrieve the vendor/device info Emil Velikov
2016-11-01 18:47 ` Mauro Santos
2016-11-08 11:06 ` Emil Velikov [this message]
2016-11-08 13:38 ` Mauro Santos
2016-11-08 15:00 ` Emil Velikov
2016-11-08 15:27 ` Mauro Santos
2016-11-08 15:57 ` Emil Velikov
2016-11-08 16:57 ` Mauro Santos
2016-11-08 17:13 ` Emil Velikov
2016-11-08 18:08 ` Mauro Santos
2016-11-08 18:36 ` Mauro Santos
2016-11-08 18:47 ` Emil Velikov
2016-11-02 11:14 ` Peter Wu
2016-11-02 11:47 ` Emil Velikov
2016-11-02 12:32 ` Peter Wu
2016-11-09 18:08 ` [PATCH libdrm v2] xf86drm: Parse the separate files to retrieve the vendor, ... info Emil Velikov
2016-11-10 8:00 ` Michel Dänzer
2016-11-10 12:40 ` Nicolai Hähnle
2016-11-10 13:38 ` Emil Velikov
2016-11-14 9:56 ` Michel Dänzer
2016-11-14 10:46 ` Emil Velikov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CACvgo531RLdtVy_tXYKNa27DLiQBKBMcPA7kC_COqnpXBSvB4A@mail.gmail.com \
--to=emil.l.velikov@gmail.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=michel.daenzer@amd.com \
--cc=registo.mailling@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).