1. 28 Aug, 2012 1 commit
  2. 17 Aug, 2012 1 commit
  3. 13 Aug, 2012 5 commits
  4. 02 Aug, 2012 1 commit
  5. 25 Jul, 2012 9 commits
  6. 24 Jul, 2012 1 commit
    • Ilija Hadzic's avatar
      drm: track dev_mapping in more robust and flexible way · 949c4a34
      Ilija Hadzic authored
      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: default avatarIlija Hadzic <ihadzic@research.bell-labs.com>
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      949c4a34
  7. 19 Jul, 2012 2 commits
  8. 27 Jun, 2012 1 commit
  9. 26 Jun, 2012 1 commit
    • Ben Skeggs's avatar
      drm/nouveau/fbcon: using nv_two_heads is not a good idea · 9bd0c15f
      Ben Skeggs authored
      
      
      nv_two_heads() was never meant to be used outside of pre-nv50 code.  The
      code checks for >= NV_10 for 2 CRTCs, then downgrades a few specific
      chipsets to 1 CRTC based on (pci_device & 0x0ff0).
      
      The breakage example seen is on GTX 560Ti, with a pciid of 0x1200, which
      gets detected as an NV20 (0x020x) with 1 CRTC by nv_two_heads(), causing
      memory corruption because there's actually 2 CRTCs..
      
      This switches fbcon to use the CRTC count directly from the mode_config
      structure, which will also fix the same issue on Kepler boards which have
      4 CRTCs.
      Signed-off-by: default avatarBen Skeggs <bskeggs@redhat.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      9bd0c15f
  10. 31 May, 2012 2 commits
  11. 24 May, 2012 16 commits