1. 17 Nov, 2009 1 commit
  2. 15 Jul, 2009 1 commit
  3. 18 Jun, 2009 1 commit
  4. 15 Jun, 2009 1 commit
    • GeunSik Lim's avatar
      debugfs: Fix terminology inconsistency of dir name to mount debugfs filesystem. · 156f5a78
      GeunSik Lim authored
      Many developers use "/debug/" or "/debugfs/" or "/sys/kernel/debug/"
      directory name to mount debugfs filesystem for ftrace according to
      ./Documentation/tracers/ftrace.txt file.
      And, three directory names(ex:/debug/, /debugfs/, /sys/kernel/debug/) is
      existed in kernel source like ftrace, DRM, Wireless, Documentation,
      Network[sky2]files to mount debugfs filesystem.
      debugfs means debug filesystem for debugging easy to use by greg kroah
      hartman. "/sys/kernel/debug/" name is suitable as directory name
      of debugfs filesystem.
      - debugfs related reference: http://lwn.net/Articles/334546/
      Fix inconsistency of directory name to mount debugfs filesystem.
      * From Steven Rostedt
        - find_debugfs() and tracing_files() in this patch.
      Signed-off-by: default avatarGeunSik Lim <geunsik.lim@samsung.com>
      Acked-by     : Inaky Perez-Gonzalez <inaky@linux.intel.com>
      Reviewed-by  : Steven Rostedt <rostedt@goodmis.org>
      Reviewed-by  : James Smart <james.smart@emulex.com>
      CC: Jiri Kosina <trivial@kernel.org>
      CC: David Airlie <airlied@linux.ie>
      CC: Peter Osterlund <petero2@telia.com>
      CC: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
      CC: Anil S Keshavamurthy <anil.s.keshavamurthy@intel.com>
      CC: Masami Hiramatsu <mhiramat@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
  5. 11 Jun, 2009 1 commit
    • yakui_zhao's avatar
      drm: add separate drm debugging levels · 4fefcb27
      yakui_zhao authored
      Now all the DRM debug info will be reported if the boot option of
      "drm.debug=1" is added. Sometimes it is inconvenient to get the debug
      info in KMS mode. We will get too much unrelated info.
      This will separate several DRM debug levels and the debug level can be used
      to print the different debug info. And the debug level is controlled by the
      module parameter of drm.debug
      In this patch it is divided into four debug levels;
             	drm_core, drm_driver, drm_kms, drm_mode.
      At the same time we can get the different debug info by changing the debug
      level. This can be done by adding the module parameter. Of course it can
      be changed through the /sys/module/drm/parameters/debug after the system is
      Four debug macro definitions are provided.
      	DRM_DEBUG(fmt, args...)
      	DRM_DEBUG_DRIVER(prefix, fmt, args...)
      	DRM_DEBUG_KMS(prefix, fmt, args...)
      	DRM_DEBUG_MODE(prefix, fmt, args...)
      When the boot option of "drm.debug=4" is added, it will print the debug info
      using DRM_DEBUG_KMS macro definition.
      When the boot option of "drm.debug=6" is added, it will print the debug info
      Sometimes we expect to print the value of an array.
      For example: SDVO command,
      In such case the following four DRM debug macro definitions are added:
      	DRM_LOG(fmt, args...)
      	DRM_LOG_DRIVER(fmt, args...)
      	DRM_LOG_KMS(fmt, args...)
      	DRM_LOG_MODE(fmt, args...)
      Signed-off-by: default avatarZhao Yakui <yakui.zhao@intel.com>
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
  6. 23 Apr, 2009 2 commits
  7. 19 Apr, 2009 2 commits
  8. 27 Mar, 2009 1 commit
  9. 12 Mar, 2009 3 commits
  10. 04 Mar, 2009 1 commit
  11. 02 Mar, 2009 2 commits
  12. 19 Jan, 2009 1 commit
  13. 29 Dec, 2008 5 commits
    • 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
        - 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>
    • 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>
    • 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
      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>
    • 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>
    • 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>
  14. 11 Nov, 2008 1 commit
  15. 17 Oct, 2008 2 commits
    • Jesse Barnes's avatar
      drm: kill drm_device->irq · 9bfbd5cb
      Jesse Barnes authored
      Like the last patch but adds a macro to get at the irq value instead of
      dereferencing pdev directly.  Should  make things easier for the BSD guys and
      if we ever support non-PCI devices.
      Signed-off-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
    • Eric Anholt's avatar
      drm: Add GEM ("graphics execution manager") to i915 driver. · 673a394b
      Eric Anholt authored
      GEM allows the creation of persistent buffer objects accessible by the
      graphics device through new ioctls for managing execution of commands on the
      device.  The userland API is almost entirely driver-specific to ensure that
      any driver building on this model can easily map the interface to individual
      driver requirements.
      GEM is used by the 2d driver for managing its internal state allocations and
      will be used for pixmap storage to reduce memory consumption and enable
      zero-copy GLX_EXT_texture_from_pixmap, and in the 3d driver is used to enable
      GL_EXT_framebuffer_object and GL_ARB_pixel_buffer_object.
      Signed-off-by: default avatarEric Anholt <eric@anholt.net>
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
  16. 13 Jul, 2008 1 commit
    • Dave Airlie's avatar
      drm: reorganise drm tree to be more future proof. · c0e09200
      Dave Airlie authored
      With the coming of kernel based modesetting and the memory manager stuff,
      the everything in one directory approach was getting very ugly and
      starting to be unmanageable.
      This restructures the drm along the lines of other kernel components.
      It creates a drivers/gpu/drm directory and moves the hw drivers into
      subdirectores. It moves the includes into an include/drm, and
      sets up the unifdef for the userspace headers we should be exporting.
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
  17. 26 Apr, 2008 1 commit
  18. 06 Feb, 2008 4 commits
  19. 16 Jul, 2007 1 commit
  20. 10 Jul, 2007 3 commits
  21. 22 Mar, 2007 1 commit
    • Thomas Hellstrom's avatar
      drm: fix driver deadlock with AIGLX and reclaim_buffers_locked · 040ac320
      Thomas Hellstrom authored
      Bugzilla Bug #9457
      Add refcounting of user waiters to the DRM hardware lock, so that we can use
      DRM_LOCK_CONT flag more conservatively.
      Also add a kernel waiter refcount that if nonzero transfers the lock for the
      kernel context when it is released. This is useful when waiting for idle and can be used for very simple fence object driver implementations for the new memory manager
      Signed-off-by: default avatarDave Airlie <airlied@linux.ie>
  22. 11 Dec, 2006 1 commit
  23. 06 Dec, 2006 2 commits
  24. 21 Sep, 2006 1 commit