From: Martin Peres <martin.peres@linux.intel.com>
To: intel-gfx@lists.freedesktop.org
Subject: Re: i915 render node discovery buggy?
Date: Tue, 27 Oct 2015 13:28:11 +0200 [thread overview]
Message-ID: <562F5FCB.30200@linux.intel.com> (raw)
In-Reply-To: <20151027102436.GH8644@n2100.arm.linux.org.uk>
On 27/10/15 12:24, Russell King - ARM Linux wrote:
> In passing, while reading the Intel DDX driver code, I've noticed
> that the Intel driver contains code which assumes that the master and
> render devices are related by minor device number, eg:
>
> /* Are we a render-node ourselves? */
> if (is_render_node(fd, &master))
> return NULL;
>
> sprintf(buf, "/dev/dri/renderD%d", (int)((master.st_rdev | 0x80) & 0xbf));
> if (stat(buf, &render) == 0 &&
> master.st_mode == render.st_mode &&
> render.st_rdev == ((master.st_rdev | 0x80) & 0xbf))
> return strdup(buf);
>
> There's also code doing the reverse as well.
>
> From my observations, the assumption that this code is built upon is
> false. I have an ARM platform here (non-Intel graphics) which shows
> the problem - we have a KMS-only DRM driver (card0) and a GPU-only
> DRM driver (card1). This populates the /dev/dri subdirectory as
> follows:
>
> crw-rw----+ 1 root video 226, 0 Oct 27 04:59 card0
> crw-rw----+ 1 root video 226, 1 Oct 26 20:40 card1
> crw-rw---- 1 root video 226, 64 Oct 26 20:40 controlD64
> crw-rw---- 1 root video 226, 128 Oct 26 20:40 renderD128
>
> and if I look at /sys/class/drm, you can then see who owns which devices:
>
> lrwxrwxrwx 1 root root 0 Oct 26 20:40 card0 -> ../../devices/platform/armada-drm/drm/card0
> lrwxrwxrwx 1 root root 0 Oct 26 20:40 card0-HDMI-A-1 -> ../../devices/platform/armada-drm/drm/card0/card0-HDMI-A-1
> lrwxrwxrwx 1 root root 0 Oct 26 20:40 card1 -> ../../devices/platform/etnaviv/drm/card1
> lrwxrwxrwx 1 root root 0 Oct 26 20:40 controlD64 -> ../../devices/platform/armada-drm/drm/controlD64
> lrwxrwxrwx 1 root root 0 Oct 26 20:40 renderD128 -> ../../devices/platform/etnaviv/drm/renderD128
>
> So, renderD128 is card1's render node, which does not conform to the
> assumption which the Intel DDX driver makes - (1 | 0x80) & 0xbf is
> not 128. The same thing can happen if there's ever a case on Intel
> hardware where a KMS DRM driver registers prior to the i915 driver.
>
> I think the only way to properly determine which render nodes
> correspond with which master node is to actually open the device and
> check the device names, or parse sysfs - maybe reading the links of
> /sys/class/drm, and checking which link dirname corresponds with the
> master node.
>
> Any comments?
libdrm already has the right function for that:|char
*drmGetRenderDeviceNameFromFd(int fd);
|
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
prev parent reply other threads:[~2015-10-27 11:28 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-27 10:24 i915 render node discovery buggy? Russell King - ARM Linux
2015-10-27 11:28 ` Martin Peres [this message]
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=562F5FCB.30200@linux.intel.com \
--to=martin.peres@linux.intel.com \
--cc=intel-gfx@lists.freedesktop.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.