Skip to content
  1. Dec 29, 2008
    • Jesse Barnes's avatar
      DRM: i915: add mode setting support · 79e53945
      Jesse Barnes authored
      
      
      This commit adds i915 driver support for the DRM mode setting APIs.
      Currently, VGA, LVDS, SDVO DVI & VGA, TV and DVO LVDS outputs are
      supported.  HDMI, DisplayPort and additional SDVO output support will
      follow.
      
      Support for the mode setting code is controlled by the new 'modeset'
      module option.  A new config option, CONFIG_DRM_I915_KMS controls the
      default behavior, and whether a PCI ID list is built into the module for
      use by user level module utilities.
      
      Note that if mode setting is enabled, user level drivers that access
      display registers directly or that don't use the kernel graphics memory
      manager will likely corrupt kernel graphics memory, disrupt output
      configuration (possibly leading to hangs and/or blank displays), and
      prevent panic/oops messages from appearing.  So use caution when
      enabling this code; be sure your user level code supports the new
      interfaces.
      
      A new SysRq key, 'g', provides emergency support for switching back to
      the kernel's framebuffer console; which is useful for testing.
      
      Co-authors: Dave Airlie <airlied@linux.ie>, Hong Liu <hong.liu@intel.com>
      
      Signed-off-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      Signed-off-by: default avatarEric Anholt <eric@anholt.net>
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      79e53945
    • Dave Airlie's avatar
      DRM: add mode setting support · f453ba04
      Dave Airlie authored
      
      
      Add mode setting support to the DRM layer.
      
      This is a fairly big chunk of work that allows DRM drivers to provide
      full output control and configuration capabilities to userspace.  It was
      motivated by several factors:
        - the fb layer's APIs aren't suited for anything but simple
          configurations
        - coordination between the fb layer, DRM layer, and various userspace
          drivers is poor to non-existent (radeonfb excepted)
        - user level mode setting drivers makes displaying panic & oops
          messages more difficult
        - suspend/resume of graphics state is possible in many more
          configurations with kernel level support
      
      This commit just adds the core DRM part of the mode setting APIs.
      Driver specific commits using these new structure and APIs will follow.
      
      Co-authors: Jesse Barnes <jbarnes@virtuousgeek.org>, Jakob Bornecrantz <jakob@tungstengraphics.com>
      Contributors: Alan Hourihane <alanh@tungstengraphics.com>, Maarten Maathuis <madman2003@gmail.com>
      
      Signed-off-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      Signed-off-by: default avatarEric Anholt <eric@anholt.net>
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      f453ba04
    • Jesse Barnes's avatar
      drm/i915: add GEM GTT mapping support · de151cf6
      Jesse Barnes authored
      
      
      Use the new core GEM object mapping code to allow GTT mapping of GEM
      objects on i915.  The fault handler will make sure a fence register is
      allocated too, if the object in question is tiled.
      
      Signed-off-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      Signed-off-by: default avatarEric Anholt <eric@anholt.net>
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      de151cf6
    • Jesse Barnes's avatar
      drm: GEM mmap support · a2c0a97b
      Jesse Barnes authored
      
      
      Add core support for mapping of GEM objects.  Drivers should provide a
      vm_operations_struct if they want to support page faulting of objects.
      The code for handling GEM object offsets was taken from TTM, which was
      written by Thomas Hellström.
      
      Signed-off-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      Signed-off-by: default avatarEric Anholt <eric@anholt.net>
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      a2c0a97b
    • Eric Anholt's avatar
    • Dave Airlie's avatar
      drm: reorganise start and load. · a9d51a5a
      Dave Airlie authored
      
      
      Make sure we have the primary node so the device can add maps.
      
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      a9d51a5a
    • Vegard Nossum's avatar
      drm: fix leak of uninitialized data to userspace · 1147c9cd
      Vegard Nossum authored
      
      
      ...so drm_getunique() is trying to copy some uninitialized data to
      userspace. The ECX register contains the number of words that are
      left to copy -- so there are 5 * 4 = 20 bytes left. The offset of the
      first uninitialized byte (counting from the start of the string) is
      also 20 (i.e. 0xf65d2294&((1 << 5)-1) == 20). So somebody tried to
      copy 40 bytes when the string was only 19 long.
      
      In drm_set_busid() we have this code:
      
              dev->unique_len = 40;
              dev->unique = drm_alloc(dev->unique_len + 1, DRM_MEM_DRIVER);
            ...
              len = snprintf(dev->unique, dev->unique_len, pci:%04x:%02x:%02x.%d",
      
      ...so it seems that dev->unique is never updated to reflect the
      actual length of the string. The remaining bytes (20 in this case)
      are random uninitialized bytes that are copied into userspace.
      
      This patch fixes the problem by setting dev->unique_len after the
      snprintf().
      
      airlied- I've had to fix this up to store the alloced size so
      we have it for drm_free later.
      
      Reported-by: default avatarSitsofe Wheeler <sitsofe@yahoo.com>
      Signed-off-by: default avatarVegard Nossum <vegardno@thuin.ifi.uio.no>
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      1147c9cd
    • Dave Airlie's avatar
      drm: move to kref per-master structures. · 7c1c2871
      Dave Airlie authored
      
      
      This is step one towards having multiple masters sharing a drm
      device in order to get fast-user-switching to work.
      
      It splits out the information associated with the drm master
      into a separate kref counted structure, and allocates this when
      a master opens the device node. It also allows the current master
      to abdicate (say while VT switched), and a new master to take over
      the hardware.
      
      It moves the Intel and radeon drivers to using the sarea from
      within the new master structures.
      
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      7c1c2871
    • Dave Airlie's avatar
      drm: cleanup exit path for module unload · e7f7ab45
      Dave Airlie authored
      
      
      The current sub-module unload exit path is a mess, it tries
      to abuse the idr. Just keep a list of devices per driver struct
      and free them in-order on rmmod.
      
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      e7f7ab45
  2. Dec 25, 2008
  3. Dec 24, 2008
  4. Dec 23, 2008
  5. Dec 22, 2008
  6. Dec 21, 2008
  7. Dec 20, 2008