1. 06 Jan, 2010 7 commits
    • Chris Wilson's avatar
      drm/i915: Permit pinning whilst the device is 'suspended' · e3d8affb
      Chris Wilson authored
      As pinning (allocating and binding GTT memory) does not actually invoke
      GPU commands, it is safe, and indeed is attempted, during resumption
      from suspension:
      
        [drm:intel_init_clock_gating] *ERROR* failed to pin power context: -16
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Reported-by: default avatarHugh Dickins <hugh.dickins@tiscali.co.uk>
      Cc: stable@kernel.org
      Signed-off-by: default avatarEric Anholt <eric@anholt.net>
      e3d8affb
    • Chris Wilson's avatar
      drm/i915: Hold struct mutex whilst pinning power context bo. · 9ea8d059
      Chris Wilson authored
      Hugh found an error path where we were attempting to unref a bo without
      holding the struct mutex:
      
        [drm:intel_init_clock_gating] *ERROR* failed to pin power context: -16
        ------------[ cut here ]------------
        WARNING: at drivers/gpu/drm/drm_gem.c:438 drm_gem_object_free+0x20/0x5e()
        Hardware name: ESPRIMO Mobile V5505
        Modules linked in: snd_pcm_oss snd_mixer_oss snd_seq snd_seq_device
        Pid: 3793, comm: s2ram Not tainted 2.6.33-rc2 #4
        Call Trace:
         [<7815298e>] warn_slowpath_common+0x59/0x6b
         [<781529b3>] warn_slowpath_null+0x13/0x18
         [<78317c1a>] ? drm_gem_object_free+0x20/0x5e
         [<78317c1a>] drm_gem_object_free+0x20/0x5e
         [<78317bfa>] ? drm_gem_object_free+0x0/0x5e
         [<7829df11>] kref_put+0x38/0x45
         [<7833a5f0>] intel_init_clock_gating+0x232/0x271
         [<78317bfa>] ? drm_gem_object_free+0x0/0x5e
         [<7832c307>] i915_restore_state+0x21a/0x2b3
         [<7832379d>] i915_resume+0x3c/0xbb
         [<78174fe5>] ? trace_hardirqs_on_caller+0xfc/0x123
         [<7831c756>] ? drm_class_resume+0x0/0x3e
         [<7831c78d>] drm_class_resume+0x37/0x3e
         [<78351e0a>] legacy_resume+0x1e/0x51
         [<78351ece>] device_resume+0x91/0xab
         [<7831c756>] ? drm_class_resume+0x0/0x3e
         [<78352226>] dpm_resume+0x58/0x10f
         [<783522fb>] dpm_resume_end+0x1e/0x2c
         [<78180f80>] suspend_devices_and_enter+0x61/0x84
         [<78180ff8>] enter_state+0x55/0x83
         [<7818091c>] state_store+0x94/0xaa
         [<7829d09e>] kobj_attr_store+0x1e/0x23
         [<782098e0>] sysfs_write_file+0x66/0x99
         [<781cd2f0>] vfs_write+0x8a/0x108
         [<781cd408>] sys_write+0x3c/0x63
         [<78125c10>] sysenter_do_call+0x12/0x36
        ---[ end trace a343537f29950fda ]---
      
      It is in fact slightly more insiduous that first appears since we are
      attempting to not just free the object without the lock, but are trying
      to do the whole bo manipulation without holding the lock.
      Reported-by: default avatarHugh Dickins <hugh.dickins@tiscali.co.uk>
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Cc: stable@kernel.org
      Signed-off-by: default avatarEric Anholt <eric@anholt.net>
      9ea8d059
    • Andrew Morton's avatar
      drm/i915: fix unused var · 29bd0ae2
      Andrew Morton authored
      drivers/gpu/drm/i915/i915_dma.c: In function 'i915_driver_load':
      drivers/gpu/drm/i915/i915_dma.c:1114: warning: 'll_base' may be used uninitialized in this function
      
      Partly this is because gcc isn't smart enough.  But `ll_base' does get used
      uninitialised in the DRM_DEBUG() call.
      
      Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
      Cc: Eric Anholt <eric@anholt.net>
      Cc: Dave Airlie <airlied@linux.ie>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarEric Anholt <eric@anholt.net>
      29bd0ae2
    • Tobias Klauser's avatar
      drm/i915: Storage class should be before const qualifier · 69e302a9
      Tobias Klauser authored
      The C99 specification states in section 6.11.5:
      
      The placement of a storage-class specifier other than at the beginning
      of the declaration specifiers in a declaration is an obsolescent
      feature.
      Signed-off-by: default avatarTobias Klauser <tklauser@distanz.ch>
      Signed-off-by: default avatarEric Anholt <eric@anholt.net>
      69e302a9
    • Jesse Barnes's avatar
      drm/i915: remove render reclock support · cda9d05c
      Jesse Barnes authored
      This code generally fails to adjust the render clock, and when it does,
      it conflicts with some other register settings and can cause problems.
      
      So remove this code altogether.  I'm reworking it now to do the right
      thing, but the only bit it will share is the VBT check for whether
      reclocking is supported, so I'm leaving that bit.
      
      Reverts most of 652c393a ("add dynamic
      clock frequency control"), though for many the regressions showed up
      in the later 181a5336 ("Fix render
      reclock availability detection").
      Signed-off-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      Signed-off-by: default avatarEric Anholt <eric@anholt.net>
      cda9d05c
    • Andrew Lutomirski's avatar
      drm/i915: Fix RC6 suspend/resume · 1d3c36ad
      Andrew Lutomirski authored
      We restored RC6 twice on resume, even with modesetting off.  Instead,
      only restore it once and skip RC6 initialization entirely in non-KMS mode.
      Signed-off-by: default avatarAndy Lutomirski <luto@mit.edu>
      Tested-by: default avatarJeff Chua <jeff.chua.linux@gmail.com>
      Signed-off-by: default avatarEric Anholt <eric@anholt.net>
      1d3c36ad
    • Jesse Barnes's avatar
      drm/i915: execbuf2 support · 76446cac
      Jesse Barnes authored
      This patch adds a new execbuf ioctl, execbuf2, for use by clients that
      want to control fence register allocation more finely.  The buffer
      passed in to the new ioctl includes a new relocation type to indicate
      whether a given object needs a fence register assigned for the command
      buffer in question.
      
      Compatibility with the existing execbuf ioctl is implemented in terms
      of the new code, preserving the assumption that fence registers are
      required for pre-965 rendering commands.
      Signed-off-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      [ickle: Remove pre-emptive clear_fence_reg()]
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: default avatarKristian Høgsberg <krh@bitplanet.net>
      [anholt: Removed dmesg spam]
      Signed-off-by: default avatarEric Anholt <eric@anholt.net>
      76446cac
  2. 17 Dec, 2009 1 commit
  3. 16 Dec, 2009 9 commits
  4. 15 Dec, 2009 23 commits