drm/i915: Document that mmap forwarding is discouraged
Too many new drm driver writers seem to look at i915 for inspiration. But we have two ways to do mmap, so discourage readers from the old, ugly version. In a new driver we'd just expose two mmap offsets per object, one for the gtt map and the other for the cpu map. v2: Make it clear that i915 does cpu mmaps this way for past cluelessness^W^W historical reasons. Asked for by Jani. Cc: "Cheng, Yao" <yao.cheng@intel.com> Cc: David Herrmann <dh.herrmann@gmail.com> Reviewed-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This commit is contained in:
parent
101b376d35
commit
3436738180
|
@ -1466,6 +1466,16 @@ unlock:
|
|||
*
|
||||
* While the mapping holds a reference on the contents of the object, it doesn't
|
||||
* imply a ref on the object itself.
|
||||
*
|
||||
* IMPORTANT:
|
||||
*
|
||||
* DRM driver writers who look a this function as an example for how to do GEM
|
||||
* mmap support, please don't implement mmap support like here. The modern way
|
||||
* to implement DRM mmap support is with an mmap offset ioctl (like
|
||||
* i915_gem_mmap_gtt) and then using the mmap syscall on the DRM fd directly.
|
||||
* That way debug tooling like valgrind will understand what's going on, hiding
|
||||
* the mmap call in a driver private ioctl will break that. The i915 driver only
|
||||
* does cpu mmaps this way because we didn't know better.
|
||||
*/
|
||||
int
|
||||
i915_gem_mmap_ioctl(struct drm_device *dev, void *data,
|
||||
|
|
Loading…
Reference in New Issue