1. 27 Mar, 2015 1 commit
  2. 26 Mar, 2015 20 commits
  3. 25 Mar, 2015 3 commits
  4. 24 Mar, 2015 3 commits
  5. 23 Mar, 2015 8 commits
  6. 20 Mar, 2015 5 commits
    • Michel Thierry's avatar
      drm/i915: Do not leak objects after capturing error state · 0b37a9a9
      Michel Thierry authored
      While running kmemleak chasing a different memleak, I saw that the
      capture_error_state function was leaking some objects, for example:
      
      unreferenced object 0xffff8800a9b72148 (size 8192):
        comm "kworker/u16:0", pid 1499, jiffies 4295201243 (age 990.096s)
        hex dump (first 32 bytes):
          00 00 04 00 00 00 00 00 5d f4 ff ff 00 00 00 00  ........].......
          00 30 b0 01 00 00 00 00 37 00 00 00 00 00 00 00  .0......7.......
        backtrace:
          [<ffffffff811e5ae4>] create_object+0x104/0x2c0
          [<ffffffff8178f50a>] kmemleak_alloc+0x7a/0xc0
          [<ffffffff811cde4b>] __kmalloc+0xeb/0x220
          [<ffffffffa038f1d9>] kcalloc.constprop.12+0x2d/0x2f [i915]
          [<ffffffffa0316064>] i915_capture_error_state+0x3f4/0x1660 [i915]
          [<ffffffffa03207df>] i915_handle_error+0x7f/0x660 [i915]
          [<ffffffffa03210f7>] i915_hangcheck_elapsed+0x2e7/0x470 [i915]
          [<ffffffff8108d574>] process_one_work+0x144/0x490
          [<ffffffff8108dfbd>] worker_thread+0x11d/0x530
          [<ffffffff81094079>] kthread+0xc9/0xe0
          [<ffffffff817a2398>] ret_from_fork+0x58/0x90
          [<ffffffffffffffff>] 0xffffffffffffffff
      
      The following objects are allocated in i915_gem_capture_buffers, but not
      released in i915_error_state_free:
        - error->active_bo_count
        - error->pinned_bo
        - error->pinned_bo_count
        - error->active_bo[vm_count] (allocated in i915_gem_capture_vm).
      
      The leaks were introduced by
      commit 95f5301d
      Author: Ben Widawsky <ben@bwidawsk.net>
      Date:   Wed Jul 31 17:00:15 2013 -0700
      
          drm/i915: Update error capture for VMs
      
      v2: Reuse iterator and add culprit commit details (Chris)
      
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: default avatarMichel Thierry <michel.thierry@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      0b37a9a9
    • Ville Syrjälä's avatar
      drm/i915: Fix SKL sprite disable double buffer register update · 2ddc1dad
      Ville Syrjälä authored
      Write the PLANE_SURF register instead of PLANE_CTL to arm the double
      buffer regisrter update.
      Signed-off-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      2ddc1dad
    • Ville Syrjälä's avatar
      drm/i915: Eliminate plane control register RMW from sprite code · 48fe4691
      Ville Syrjälä authored
      Replace the RMW access with explicit initialization of the entire plane
      control register, as was done for primary planes in:
      
       commit f45651ba
       Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
       Date:   Fri Aug 8 21:51:10 2014 +0300
      
          drm/i915: Eliminate rmw from .update_primary_plane()
      
      The automagic primary plane disable is still doing RMWs, but that will
      require more work to untangle, so leave it alone for now.
      Signed-off-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      48fe4691
    • Ville Syrjälä's avatar
      drm/i915: Eliminate the RMW sprite colorkey management · 47ecbb20
      Ville Syrjälä authored
      Store the colorkey in intel_plane and kill off all the RMW stuff
      handling it.
      
      This is just an intermediate step and eventually the colorkey needs to
      be converted into some properties.
      
      v2: Actually update the hardware state in the set_colorkey ioctl (Daniel)
      Signed-off-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      47ecbb20
    • Matt Roper's avatar
      drm/i915: Move vblank wait determination to 'check' phase · 08fd59fc
      Matt Roper authored
      Determining whether we'll need to wait for vblanks is something we
      should determine during the atomic 'check' phase, not the 'commit'
      phase.  Note that we only set these bits in the branch of 'check' where
      intel_crtc->active is true so that we don't try to wait on a disabled
      CRTC.
      
      The whole 'wait for vblank after update' flag should go away in the
      future, once we start handling watermarks in a proper atomic manner.
      
      This regression has been introduced in
      
      commit 2fdd7def16dd7580f297827930126c16b152ec11
      Author: Matt Roper <matthew.d.roper@intel.com>
      Date:   Wed Mar 4 10:49:04 2015 -0800
          drm/i915: Don't clobber plane state on internal disables
      
      Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
      Root-cause-analysis-by: default avatarPaulo Zanoni <paulo.r.zanoni@intel.com>
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89550
      Testcase: igt/pm_rpm/legacy-planes
      Testcase: igt/pm_rpm/legacy-planes-dpms
      Testcase: igt/pm_rpm/universal-planes
      Testcase: igt/pm_rpm/universal-planes-dpms
      Signed-off-by: default avatarMatt Roper <matthew.d.roper@intel.com>
      Tested-by: default avatarPaulo Zanoni <paulo.r.zanoni@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      08fd59fc