949c4a34af
Setting dev_mapping (pointer to the address_space structure used for memory mappings) to the address_space of the first opener's inode and then failing if other openers come in through a different inode has a few restrictions that are eliminated by this patch. If we already have valid dev_mapping and we spot an opener with different i_node, we force its i_mapping pointer to the already established address_space structure (first opener's inode). This will make all mappings from drm device hang off the same address_space object. Some benefits (things that now work and didn't work before) of this patch are: * user space can mknod and use any number of device nodes and they will all work fine as long as the major device number is that of the drm module. * user space can even remove the first opener's device nodes and mknod the new one and the applications and windowing system will still work. * GPU drivers can safely assume that dev->dev_mapping is correct address_space and just blindly copy it into their (private) bdev.dev_mapping For reference, some discussion that lead to this patch can be found here: http://lists.freedesktop.org/archives/dri-devel/2012-April/022283.html Signed-off-by: Ilija Hadzic <ihadzic@research.bell-labs.com> Signed-off-by: Dave Airlie <airlied@redhat.com> |
||
|---|---|---|
| .. | ||
| Kconfig | ||
| Makefile | ||
| svga3d_reg.h | ||
| svga_escape.h | ||
| svga_overlay.h | ||
| svga_reg.h | ||
| svga_types.h | ||
| vmwgfx_buffer.c | ||
| vmwgfx_dmabuf.c | ||
| vmwgfx_drv.c | ||
| vmwgfx_drv.h | ||
| vmwgfx_execbuf.c | ||
| vmwgfx_fb.c | ||
| vmwgfx_fence.c | ||
| vmwgfx_fence.h | ||
| vmwgfx_fifo.c | ||
| vmwgfx_gmr.c | ||
| vmwgfx_gmrid_manager.c | ||
| vmwgfx_ioctl.c | ||
| vmwgfx_irq.c | ||
| vmwgfx_kms.c | ||
| vmwgfx_kms.h | ||
| vmwgfx_ldu.c | ||
| vmwgfx_marker.c | ||
| vmwgfx_overlay.c | ||
| vmwgfx_reg.h | ||
| vmwgfx_resource.c | ||
| vmwgfx_scrn.c | ||
| vmwgfx_ttm_glue.c | ||