1. 04 Feb, 2014 2 commits
  2. 30 Jan, 2014 1 commit
    • Imre Deak's avatar
      drm/i915: vlv: fix DP PHY lockup due to invalid PP sequencer setup · 2cac613b
      Imre Deak authored
      Atm we setup the HW panel power sequencer logic both for eDP and DP
      ports. On eDP we then go on and start the power on sequence and commence
      with link training when it's ready. On DP we don't do the power on
      sequencing but do the link training immediately. At this point the DP
      PHY block gets stuck, since - supposedly - it is waiting for the power
      on sequence to finish. The actual register write that seems to hold off
      the PHY is PIPEX_PP_ON_DELAYS[Panel Control Port Select]. Writing here
      a non-0 value eventually sets PIPEX_PP_STATUS[Require Asset Status] to
      1 and blocks the PHY until the panel power on is ready.
      
      Fix this by not doing any PP sequencing setup for DP ports.
      
      Thanks to Ville Syrjälä, Jesse Barnes and Todd Previte for the help in
      tracking this down.
      
      Note that on older gmch platforms (where we have lvds instead of edp)
      we've hacked around this by writing the magic ABCD unlock key to PP
      registers, which disables the hw sanity checks.
      
      For edp all platforms thus far had the pch split, with the edp port in
      the north display complex and the PP registers on the pch the hw
      sanity checks (expressed through the "Require Asset Status" bit) was
      never functional, hence never a real issue.
      
      This regression has been introduce in
      
      commit bf13e81b
      Author: Jani Nikula <jani.nikula@intel.com>
      Date:   Fri Sep 6 07:40:05 2013 +0300
      
          drm/i915: add support for per-pipe power sequencing on vlv
      Signed-off-by: default avatarImre Deak <imre.deak@intel.com>
      [danvet: Add note about the bigger story here.]
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      2cac613b
  3. 28 Jan, 2014 1 commit
  4. 27 Jan, 2014 1 commit
    • Chris Wilson's avatar
      drm/i915: Decouple GPU error reporting from ring initialisation · 372fbb8e
      Chris Wilson authored
      Currently we report through our error state only the rings that have
      been initialised (as detected by ring->obj). This check is done after
      the GPU reset and ring re-initialisation, which means that the software
      state may not be the same as when we captured the hardware error and we
      may not print out any of the vital information for debugging the hang.
      
      This (and the implied object leak) is a regression from
      
      commit 3d57e5bd
      Author: Ben Widawsky <ben@bwidawsk.net>
      Date:   Mon Oct 14 10:01:36 2013 -0700
      
          drm/i915: Do a fuller init after reset
      
      Note that we are already starting to get bug reports with incomplete
      error states from 3.13, which also hampers debugging userspace driver
      issues.
      
      v2: Prevent a NULL dereference on 830gm/845g after a GPU reset where
          the scratch obj may be NULL.
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Cc: Ben Widawsky <ben@bwidawsk.net>
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      References: https://bugs.freedesktop.org/show_bug.cgi?id=74094
      Cc: stable@vger.kernel.org # please don't delay since it's a
      vital support/debug feature for the intel gfx stack in general
      Reviewed-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      [danvet: Add a bit of fluff to make it clear we need this expedited in
      stable.]
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      372fbb8e
  5. 25 Jan, 2014 1 commit
    • Stanislaw Gruszka's avatar
      i915: remove pm_qos request on error · 22accca0
      Stanislaw Gruszka authored
      Not removing pm qos request and free memory for it can cause crash,
      when some other driver use pm qos. For example, this oops:
      
      BUG: unable to handle kernel paging request at fffffffffffffff8
      IP: [<ffffffff81307a6b>] plist_add+0x5b/0xd0
      Call Trace:
       [<ffffffff810acf25>] pm_qos_update_target+0x125/0x1e0
       [<ffffffff810ad071>] pm_qos_add_request+0x91/0x100
       [<ffffffffa053ec14>] e1000_open+0xe4/0x5b0 [e1000e]
      
      was caused by earlier i915 probe failure:
      
      [drm:i915_report_and_clear_eir] *ERROR* EIR stuck: 0x00000010, masking
      [drm:init_ring_common] *ERROR* render ring initialization failed ctl 0001f001 head 00003004 tail 00000000 start 00003000
      [drm:i915_driver_load] *ERROR* failed to init modeset
      i915: probe of 0000:00:02.0 failed with error -5
      
      Bug report:
      http://bugzilla.redhat.com/show_bug.cgi?id=1057533Reported-by: default avatarGiandomenico De Tullio <ghisha@gmail.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarStanislaw Gruszka <sgruszka@redhat.com>
      [danvet: Drop unnecessary code movement.]
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      22accca0
  6. 24 Jan, 2014 1 commit
    • Daniel Vetter's avatar
      Revert "drm/i915: Mask reserved bits in display/sprite address registers" · 85ba7b7d
      Daniel Vetter authored
      This reverts commit 446f2545.
      
      I've left the masking in the pageflip code since that seems to be some
      useful piece of preemptive robustness.
      
      Iirc I've merged this patch under the assumption that the BIOS leaves
      some random gunk in the lower bits and gets unhappy if we trample on
      them. We have quite a few case like this, so this made sense.
      
      Now I've just learned that there's actual hardware features bits in
      the low 12 bits, and the kernel needs to preserve them to allow a
      userspace blob to do its job. Given Dave Airlie's clear stance on
      userspace blob drivers I've quickly chatted with him and he doesn't
      seem too happy. So let's revert this.
      
      If there are indeed bits that we must preserve in this range then we
      can ressurrect this patch, but with proper documentation for those
      bits supplied. And we probably also need to think a bit about
      interactions with our driver.
      
      Cc: Armin Reese <armin.c.reese@intel.com>
      Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
      Cc: Dave Airlie <airlied@linux.ie>
      Reviewed-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      85ba7b7d
  7. 23 Jan, 2014 1 commit
  8. 22 Jan, 2014 15 commits
  9. 21 Jan, 2014 6 commits
    • Dave Airlie's avatar
      Merge branch 'drm-vbl-timestamp' of git://gitorious.org/vsyrjala/linux into drm-next · f5395ba3
      Dave Airlie authored
      Here's the vblank timestamp pull request you wanted.
      
      I addressed the few bugs that Mario pointed out and added
      the r-bs.
      
      As it has been a while since I made the changes, I gave it a
      quick spin on a few different i915 machines. Fortunately
      everything still seems to be fine.
      
      * 'drm-vbl-timestamp' of git://gitorious.org/vsyrjala/linux:
        drm/i915: Add a kludge for DSL incrementing too late and ISR not working
        drm/radeon: Move the early vblank IRQ fixup to radeon_get_crtc_scanoutpos()
        drm: Pass 'flags' from the caller to .get_scanout_position()
        drm: Fix vblank timestamping constants for interlaced modes
        drm/i915: Fix scanoutpos calculations for interlaced modes
        drm: Change {pixel,line,frame}dur_ns from s64 to int
        drm: Use crtc_clock in drm_calc_timestamping_constants()
        drm/radeon: Populate crtc_clock in radeon_atom_get_tv_timings()
        drm: Simplify the math in drm_calc_timestamping_constants()
        drm: Improve drm_calc_timestamping_constants() documentation
        drm/i915: Call drm_calc_timestamping_constants() earlier
        drm/i915: Kill hwmode save/restore
        drm: Pass the display mode to drm_calc_vbltimestamp_from_scanoutpos()
        drm: Pass the display mode to drm_calc_timestamping_constants()
      f5395ba3
    • Dave Airlie's avatar
      Merge branch 'topic/core-stuff' of git://people.freedesktop.org/~danvet/drm-intel into drm-next · 2b76a676
      Dave Airlie authored
      Some straggling drm core patches
      
      * 'topic/core-stuff' of git://people.freedesktop.org/~danvet/drm-intel:
        drm/gem: Always initialize the gem object in object_init
        drm/edid: Populate picture aspect ratio for CEA modes
        drm/edid: parse the list of additional 3D modes
        drm/edid: split VIC display mode lookup into a separate function
        drm: Make the connector mode_valid() vfunc return a drm_mode_status enum
      2b76a676
    • Dave Airlie's avatar
      Merge branch 'vmwgfx-next' of git://people.freedesktop.org/~thomash/linux into drm-next · aec476a6
      Dave Airlie authored
      Just a single fix for sparse/smatch warnings introduced by the previous
      vmwgfx-next pull.
      
      * 'vmwgfx-next' of git://people.freedesktop.org/~thomash/linux:
        drm/vmwgfx: Fix recently introduced sparse / smatch warnings and errors
      aec476a6
    • Thomas Hellstrom's avatar
    • Daniel Vetter's avatar
      drm/gem: Always initialize the gem object in object_init · 6ab11a26
      Daniel Vetter authored
      At least drm/i915 expects that the obj->dev pointer is set even in
      failure paths. Specifically when the shmem initialization fails we
      call i915_gem_object_free which needs to deref obj->base.dev to get at
      the slab pointer in the device private structure. And the shmem
      allocation can easily fail when userspace is hitting open file limits.
      
      Doing the structure init even when the shmem file allocation fails
      prevents this Oops.
      
      This is a regression from
      
      commit 89c8233f
      Author: David Herrmann <dh.herrmann@gmail.com>
      Date:   Thu Jul 11 11:56:32 2013 +0200
      
          drm/gem: simplify object initialization
      
      v2: Add regression note which Chris supplied.
      
      Testcase: igt/gem_fd_exhaustion
      Reported-and-Suggested-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      References: http://lists.freedesktop.org/archives/intel-gfx/2014-January/038433.html
      Cc: stable@vger.kernel.org
      Reviewed-by: default avatarDavid Herrmann <dh.herrmann@gmail.com>
      Cc: David Herrmann <dh.herrmann@gmail.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      6ab11a26
    • Dave Airlie's avatar
      Merge branch 'drm-next-3.14' of git://people.freedesktop.org/~agd5f/linux into drm-next · 8c9b2e32
      Dave Airlie authored
      New tree with the INFO ioctl merge fixed up.  This also adds a couple
      of additional minor fixes.
      
      A few more changes for 3.14, mostly just bug fixes.  Note that:
      drm/radeon: add query to fetch the max engine clock.
      will conflict with 3.13 final, but the fix is pretty obvious.
      
      * 'drm-next-3.14' of git://people.freedesktop.org/~agd5f/linux: (22 commits)
        drm/radeon: add UVD support for OLAND
        drm/radeon: fix minor typos in si_dpm.c
        drm/radeon: set the full cache bit for fences on r7xx+
        drm/radeon: fix surface sync in fence on cayman (v2)
        drm/radeon/dpm: disable mclk switching on desktop RV770
        drm/radeon: fix endian handling in radeon_atom_init_mc_reg_table
        drm/radeon: write gfx pg bases even when gfx pg is disabled
        drm/radeon: bail early from enable ss in certain cases
        drm/radeon: handle ss percentage divider properly
        drm/radeon: add query to fetch the max engine clock (v2)
        drm/radeon/dp: sleep after powering up the display
        drm/radeon/dp: use usleep_range rather than udelay
        drm/radeon/dp: bump i2c-over-aux retries to 7
        drm/radeon: disable ss on DP for DCE3.x
        drm/radeon/cik: use hw defaults for TC_CFG registers
        drm/radeon: disable dpm on BTC
        drm/radeon/cik: use WAIT_REG_MEM special op for CP HDP flush
        drm/radeon/cik: use POLL_REG_MEM special op for sDMA HDP flush
        drm/radeon: consolidate sdma hdp flushing code for CIK
        drm/radeon: consolidate cp hdp flushing code for CIK
        ...
      8c9b2e32
  10. 20 Jan, 2014 11 commits