From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Ilija Hadzic <ihadzic@research.bell-labs.com>
Cc: dri-devel@lists.freedesktop.org
Subject: Re: [RFC v2] Revive the work on render-nodes branch
Date: Thu, 12 Apr 2012 21:55:26 +0300 [thread overview]
Message-ID: <20120412185526.GN4917@intel.com> (raw)
In-Reply-To: <1334254784-3200-1-git-send-email-ihadzic@research.bell-labs.com>
On Thu, Apr 12, 2012 at 02:19:25PM -0400, Ilija Hadzic wrote:
> The following set of patches is the reword of the series
> sent two weeks ago [2] that will revive the drm-render-nodes [1]
> branch. Details of the original series are described in [2].
>
> Patches in this series have been reworked (and a few prep patches
> have been added) to address the comment about the planes support
> (planes can now be included in the resource list for the render
> node).
>
> Consequently, the ioctls have changed to include plane support
> so the libdrm side is also affected (patches for libdrm will be sent
> in the series following this one).
Didn't have time for a detailed look yet, but at least one thing
missing from your patch set is handling of possible_crtcs and
possible_clones for getplane and getencoder ioctls. AFAICT the
bits in those are supposed to tell you the index of the object ID
in the getresources reply. So when queried via a "render node",
some form of remapping must be performed.
Also the name "render node" is still very confusing. How about just
callling it a partition or something. Or maybe someone could suggest
a more self explanatory name for this stuff.
--
Ville Syrjälä
Intel OTC
next prev parent reply other threads:[~2012-04-12 18:55 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-04-12 18:19 Ilija Hadzic
2012-04-12 18:19 ` [PATCH 01/19] drm: simplify dereferencing of node type Ilija Hadzic
2012-04-12 18:19 ` [PATCH 02/19] drm: track planes in drm_mode_group structure Ilija Hadzic
2012-04-12 18:19 ` [PATCH 03/19] drm: use drm_mode_group in drm_mode_getplane_res Ilija Hadzic
2012-04-12 18:19 ` [PATCH 04/19] drm: do not push inode down into drm_open_helper Ilija Hadzic
2012-04-12 18:19 ` [PATCH 05/19] drm: move dev_mapping to the minor node Ilija Hadzic
2012-04-20 10:04 ` Dave Airlie
2012-04-30 14:48 ` Ilija Hadzic
2012-04-30 16:39 ` Dave Airlie
2012-04-30 16:52 ` Ilija Hadzic
2012-04-30 17:53 ` Dave Airlie
2012-04-30 18:04 ` Dave Airlie
2012-05-15 20:48 ` Ilija Hadzic
2012-04-12 18:19 ` [PATCH 06/19] drm: add support for render nodes Ilija Hadzic
2012-04-12 18:19 ` [PATCH 07/19] drm: initial multiple nodes ioctl work Ilija Hadzic
2012-04-20 10:15 ` Dave Airlie
2012-04-12 18:19 ` [PATCH 08/19] drm: separate render node descriptor from minor Ilija Hadzic
2012-04-12 18:19 ` [PATCH 09/19] drm: cleanup render node ioctls Ilija Hadzic
2012-04-12 18:19 ` [PATCH 10/19] drm: only allow render node ioctls through control node Ilija Hadzic
2012-04-12 18:19 ` [PATCH 11/19] drm: do not remove a render node in use Ilija Hadzic
2012-04-12 18:19 ` [PATCH 12/19] drm: allocate correct id_list size for a render node Ilija Hadzic
2012-04-12 18:19 ` [PATCH 13/19] drm: add drm_mode_group_fini function Ilija Hadzic
2012-04-12 18:19 ` [PATCH 14/19] drm: properly free id_list when a render node is removed Ilija Hadzic
2012-04-12 18:19 ` [PATCH 15/19] drm: call drm_mode_group_fini on primary node Ilija Hadzic
2012-04-12 18:19 ` [PATCH 16/19] drm: more elaborate check for resource count Ilija Hadzic
2012-04-12 18:19 ` [PATCH 17/19] drm: validate id list when creating a render node Ilija Hadzic
2012-04-12 18:19 ` [PATCH 18/19] drm: keep track of which node holds which resource Ilija Hadzic
2012-04-12 18:19 ` [PATCH 19/19] drm: hold mutex in critical sections of render-node code Ilija Hadzic
2012-04-12 18:55 ` Ville Syrjälä [this message]
2012-04-12 19:09 ` [RFC v2] Revive the work on render-nodes branch Ilija Hadzic
2012-04-20 10:20 ` Dave Airlie
2012-04-20 13:46 ` Daniel Vetter
2012-04-30 15:16 ` Ilija Hadzic
2012-04-30 19:01 ` Kristian Høgsberg
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=20120412185526.GN4917@intel.com \
--to=ville.syrjala@linux.intel.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=ihadzic@research.bell-labs.com \
--subject='Re: [RFC v2] Revive the work on render-nodes branch' \
/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
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.