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 [RFC v2] Revive the work on render-nodes branch 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 \
/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.