[PATCH 05/19] drm: move dev_mapping to the minor node
Ilija Hadzic
ihadzic at research.bell-labs.com
Mon Apr 30 07:48:38 PDT 2012
On Fri, 20 Apr 2012, Dave Airlie wrote:
> On Thu, Apr 12, 2012 at 7:19 PM, Ilija Hadzic
> <ihadzic at 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.
If we can do that, then the patch will in principle look the same to what
the current code does, except that dev_mapping will be in the minor
structure and there will ne no new dependencies introduced. The patch will
also be simpler that way.
-- Ilija
More information about the dri-devel
mailing list