• I
    drm: track dev_mapping in more robust and flexible way · 949c4a34
    Ilija Hadzic 提交于
    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.htmlSigned-off-by: NIlija Hadzic <ihadzic@research.bell-labs.com>
    Signed-off-by: NDave Airlie <airlied@redhat.com>
    949c4a34
radeon_object.c 16.4 KB