Abstracting buffer sharing mechanism from the drm drivers

[Aaron Plattner]

At the suggestion of a few drm developers, I'm looking at abstracting the buffer
sharing mechanism away from the individual drm drivers and treating it as a
low-level interface that kernel subsystems use to communicate, rather than as
something drivers should be accessing directly.  This would also mean that they
wouldn't have to each implement their own set of dma_buf_ops, and the logic for
things like detecting that you're importing your own dma_buf would be written
once, in drm_prime.c and not in every driver's gem_prime_import function.

Of course, it's slightly difficult because each driver's implementation seems to
be subtly different.

 * i915 uses its own special locking function, i915_mutex_lock_interruptible.

 * nouveau and radeon pin the pages when the dma_buf is created, while i915 pins
   them at map time.

 * the vmap functions are different between i915 and radeon/nouveau, but it
   looks like all they use the dma_buf object for is to find the GEM object.

Does it make sense to try to abstract the dma_buf parts of this?  For
example, a hypothetical new drm_gem_map_dma_buf would call a hook that lets i915
do its i915_gem_wait_for_error thing, takes the lock, calls a new gem_get_pages
driver hook, does the dma_map_sg call, and handles the unlocking?  I'll come up
with a more detailed proposal or patches if this sounds like a good idea.

--
Aaron