All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dave Airlie <airlied@gmail.com>
To: Ilija Hadzic <ihadzic@research.bell-labs.com>
Cc: dri-devel@lists.freedesktop.org
Subject: Re: [PATCH 05/19] drm: move dev_mapping to the minor node
Date: Mon, 30 Apr 2012 17:39:27 +0100	[thread overview]
Message-ID: <CAPM=9tyeakH_4ehKQUh7kwzNg5aZ367tf3L+6xqkw+9jpif0HA@mail.gmail.com> (raw)
In-Reply-To: <Pine.GSO.4.62.1204300925490.695@umail>

On Mon, Apr 30, 2012 at 3:48 PM, Ilija Hadzic
<ihadzic@research.bell-labs.com> wrote:
>
>
> On Fri, 20 Apr 2012, Dave Airlie wrote:
>
>> On Thu, Apr 12, 2012 at 7:19 PM, Ilija Hadzic
>> <ihadzic@research.bell-labs.com> wrote:
>>>
>>> Make dev_mapping per-minor instead of per device. This is
>>> a preparatory patch for introducing render nodes. This
>>> will allow per-node instead of per-device mapping range,
>>> once we introduce render nodes.
>>
>>
>> One problem is this introduces a ttm/drm dependency that we don't
>> really have so far.
>>
>
> Sorry for a belated follow-up (I was busy with something else). I understand
> the concern and I think that the patch can be reworked such that it does not
> introduce the dependency. What introduces the dependency is a call to
> drm_unmap_mapping in ttm_bo_unmap_virtual. If the patch is reworked such
> that the minor tracks i_mapping pointer instead of the whole drm_device
> structure, the need for drm_unmap_mapping may be eliminated, which in turn
> will take care of the dependency.
>
> That brings me to a question for you. The patch from which I derived this is
> your patch 7c5cc4f63556e351e9e5980ed22accad410e3fdc (on your original
> render-nodes branch). That's where you introduced drm_unmap_mapping
> function, which calls unmap_mapping_range for every minor known to the
> system.
>
> Why was that necessary at first place ? I mean we don't do the eqivalent of
> that currently when there are multiple physical GPUs in the system, so I
> don't quite get why introduction of multiple minors would require to go
> through the whole list of minors. If that's a "just in case"/"just to be
> safe" kind of thing, then I think we may be able to just call
> drm_unmap_mapping from the driver that needs to call it and only for the
> minor in question.

When we move a buffer from VRAM->RAM we have to invalidate all
userspace mappings for it.

There could be userspace mappings on any of the device nodes, so we
need to get them all.

I think some of this code could be redone, to be less complex, Al Viro
questions why we weren't just setting the
inode mapping ourselves, citing some references in an fs somewhere
(maybe cifs), I haven't had time to follow up and check.

This would also make the case where you have something else create a
device node inside a chroot.

Dave.

  reply	other threads:[~2012-04-30 16:39 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 [this message]
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 ` [RFC v2] Revive the work on render-nodes branch Ville Syrjälä
2012-04-12 19:09   ` 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='CAPM=9tyeakH_4ehKQUh7kwzNg5aZ367tf3L+6xqkw+9jpif0HA@mail.gmail.com' \
    --to=airlied@gmail.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.