1. 18 7月, 2012 3 次提交
  2. 17 7月, 2012 16 次提交
  3. 16 7月, 2012 2 次提交
  4. 14 7月, 2012 1 次提交
    • D
      Merge tag 'drm-intel-next-2012-07-06' of... · 12f0e670
      Dave Airlie 提交于
      Merge tag 'drm-intel-next-2012-07-06' of git://people.freedesktop.org/~danvet/drm-intel into drm-next
      
      Daniel writes:
      New pull for -next. Highlights:
      - rc6/turbo support for hsw (Eugeni)
      - improve corner-case of the reset handling code - gpu reset handling
        should be rock-solid now
      - support for fb offset > 4096 pixels on gen4+ (yeah, you need some fairly
        big screens to hit that)
      - the "Flush Me Harder" patch to fix the gen6+ fallout from disabling the
        flushing_list
      - no more /dev/agpgart on gen6+!
      - HAS_PCH_xxx improvements from Paulo
      - a few minor bits&pieces all over, most of it in thew hsw code
      
      * tag 'drm-intel-next-2012-07-06' of git://people.freedesktop.org/~danvet/drm-intel: (40 commits)
        drm/i915: program FDI_RX TP and FDI delays
        drm/i915: introduce for_each_encoder_on_crtc
        drm/i915: adjust framebuffer base address on gen4+
        drm/i915: introduce crtc->dspaddr_offset
        drm/i915: Reject page flips with changed format/offset/pitch
        drm/i915: Zero initialize mode_cmd
        drm/i915: don't return a spurious -EIO from intel_ring_begin
        drm/i915: properly SIGBUS on I/O errors
        drm/i915: don't hang userspace when the gpu reset is stuck
        drm/i915: non-interruptible sleeps can't handle -EAGAIN
        drm/i915: don't trylock in the gpu reset code
        drm/i915: fix PIPE_DDI_PORT_MASK
        drm/i915: prevent bogus intel_update_fbc notifications
        drm/i915: re-initialize DDI buffer translations after resume
        drm/i915: don't ironlake_init_pch_refclk() on LPT
        drm/i915: get rid of dev_priv->info->has_pch_split
        drm/i915: add PCH_NONE to enum intel_pch
        drm/i915: prefer wide & slow to fast & narrow in DP configs
        drm/i915: fix up ilk rc6 disabling confusion
        drm/i915: move force wake support into intel_pm
        ...
      12f0e670
  5. 05 7月, 2012 18 次提交
    • E
      drm/i915: program FDI_RX TP and FDI delays · 4acf5186
      Eugeni Dodonov 提交于
      This is required for a stable FDI connection.
      
      v2: fix and simplify the FDI_RX_MISC bits as noticed by Paulo Zanoni.
      
      CC: Paulo Zanoni <paulo.r.zanoni@intel.com>
      Signed-off-by: NEugeni Dodonov <eugeni.dodonov@intel.com>
      Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      4acf5186
    • D
      drm/i915: introduce for_each_encoder_on_crtc · 6c2b7c12
      Daniel Vetter 提交于
      We already have this pattern at quite a few places, and moving part of
      the modeset helper stuff into the driver will add more.
      
      v2: Don't clobber the crtc struct name with the macro parameter ...
      
      v3: Convert two more places noticed by Paulo Zanoni.
      Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
      Signed-Off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      6c2b7c12
    • D
      drm/i915: adjust framebuffer base address on gen4+ · c2c75131
      Daniel Vetter 提交于
      The tileoffset register only supports a limited offset in x/y of 4096,
      so for giant screen configuration with a shared fb we wrap around.
      
      Fix this by computing a linear offset in tiles (pages) and only use
      the tileoffset register to offset within the tile.
      Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
      Signed-Off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      c2c75131
    • D
      drm/i915: introduce crtc->dspaddr_offset · e506a0c6
      Daniel Vetter 提交于
      To avoid recomputing the display framebuffer offset on gen2/3
      pageflips. This is also prep work to do similar trickery on gen4+
      
      Also:
      - kill "Start", such upper-case remnants from the ddx must surely die.
      - rename "Offset" to linear_offset, to make it clearer that on gen4+
        this is only used by the hw for linear buffers, for tiled buffers it
        uses the TILEOFF register.
      - call DSAPADDR DSPLINOFF on gen4+ for the same reason (and because
        the documentation really renamed the register).
      Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
      Signed-Off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      e506a0c6
    • V
      drm/i915: Reject page flips with changed format/offset/pitch · e6a595d2
      Ville Syrjälä 提交于
      MI display flips can't handle some changes in the framebuffer
      format or layout. Return an error in such cases.
      Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      e6a595d2
    • V
      drm/i915: Zero initialize mode_cmd · 3a7f2f6a
      Ville Syrjälä 提交于
      Zero initialize the mode_cmd structure when creating the kernel
      framebuffer. Avoids having uninitialized data in offsets[0] for
      instance.
      Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      3a7f2f6a
    • D
      drm/i915: don't return a spurious -EIO from intel_ring_begin · de2b9985
      Daniel Vetter 提交于
      The issue with this check is that it results in userspace receiving an
      -EIO while the gpu reset hasn't completed, resulting in fallback to sw
      rendering or worse.
      
      Now there's also a stern comment in intel_ring_wait_seqno saying that
      intel_ring_begin should not return -EAGAIN, ever, because some callers
      can't handle that. But after an audit of the callsites I don't see any
      issues. I guess the last problematic spot disappeared with the removal
      of the pipelined fencing code.
      
      So do the right thing and call check_wedge, which should properly
      decide whether an -EAGAIN or -EIO is appropriate if wedged is set.
      
      Note that the early check for a wedged gpu before touching the ring is
      rather important (and it took me quite some time of acting like the
      densest doofus to figure that out): If we don't do that and the gpu
      died for good, not having been resurrect by the reset code, userspace
      can merrily fill up the entire ring until it notices that something is
      amiss.
      
      Allowing userspace to emit more render, despite that we know that it
      will fail can't lead to anything good (and by experience can lead to
      all sorts of havoc, including angering the OOM gods and hard-hanging
      the hw for good).
      
      v2: Fix EAGAIN mispell, noticed by Chris Wilson.
      Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
      Tested-by: NChris Wilson <chris@chris-wilson.co.uk>
      Signed-Off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      de2b9985
    • D
      drm/i915: properly SIGBUS on I/O errors · a9340cca
      Daniel Vetter 提交于
      ... instead of looping endless with no hope of ever serving that
      page-fault. We only need to break out of this loop when the gpu died,
      to run the reset work (and hopefully resurrect it).
      
      To clarify questions Chris raised on irc: This is about handling I/O
      errors not from our own code, but e.g. when the disk died when trying
      to swap in a gem bo. So this patch remidies the issue that the current
      handling only handles gpu-death-induced cases of -EIO. Admittedly,
      dying disks are much rarer than hanging gpus ...To clarify questions
      Chris raised on irc: This is about handling I/O errors not from our
      own code, but e.g. when the disk died when trying to swap in a gem bo.
      So this patch remidies the issue that the current handling only
      handles gpu-death-induced cases of -EIO. Admittedly, dying disks are
      much rarer than hanging gpus ...
      
      This seems to have been lost in:
      
      commit d9bc7e9f
      Author: Chris Wilson <chris@chris-wilson.co.uk>
      Date:   Mon Feb 7 13:09:31 2011 +0000
      
          drm/i915: Fix infinite loop regression from 21dd3734Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
      Tested-by: NChris Wilson <chris@chris-wilson.co.uk>
      Signed-Off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      a9340cca
    • D
      drm/i915: don't hang userspace when the gpu reset is stuck · 0a6759c6
      Daniel Vetter 提交于
      With the gpu reset no longer using a trylock we've increased the
      chances of userspace getting stuck quite a bit. To make that
      (hopefully) rare case more paletable time out when waiting for the gpu
      reset code to complete and signal this little issue to the caller by
      returning -EIO.
      
      This should help userspace to somewhat gracefully fall back and
      hopefully allow the user to grab some logs and reboot the machine
      (instead of staring at a frozen X screen in agony).
      
      Suggested by Chris Wilson because I've been stubborn about allowing
      the gpu reset code no to fail, ever (by removing the trylock).
      Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
      Tested-by: NChris Wilson <chris@chris-wilson.co.uk>
      Signed-Off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      0a6759c6
    • D
      drm/i915: non-interruptible sleeps can't handle -EAGAIN · d6b2c790
      Daniel Vetter 提交于
      So don't return -EAGAIN, even in the case of a gpu hang. Remap it to
      -EIO instead. Note that this isn't really an issue with
      interruptability, but more that we have quite a few codepaths (mostly
      around kms stuff) that simply can't handle any errors and hence not
      even -EAGAIN. Instead of adding proper failure paths so that we could
      restart these ioctls we've opted for the cheap way out of sleeping
      non-interruptibly.  Which works everywhere but when the gpu dies,
      which this patch fixes.
      
      So essentially interruptible == false means 'wait for the gpu or die
      trying'.'
      
      This patch is a bit ugly because intel_ring_begin is all non-interruptible
      and hence only returns -EIO. But as the comment in there says,
      auditing all the callsites would be a pain.
      
      To avoid duplicating code, reuse i915_gem_check_wedge in __wait_seqno
      and intel_wait_ring_buffer. Also use the opportunity to clarify the
      different cases in i915_gem_check_wedge a bit with comments.
      
      v2: Don't access dev_priv->mm.interruptible from check_wedge - we
      might not hold dev->struct_mutex, making this racy. Instead pass
      interruptible in as a parameter. I've noticed this because I've hit a
      BUG_ON(!mutex_is_locked) at the top of check_wedge. This has been
      added in
      
      commit b4aca010
      Author: Ben Widawsky <ben@bwidawsk.net>
      Date:   Wed Apr 25 20:50:12 2012 -0700
      
          drm/i915: extract some common olr+wedge code
      
      although that commit is missing any justification for this. I guess
      it's just copy&paste, because the same commit add the same BUG_ON
      check to check_olr, where it indeed makes sense.
      
      But in check_wedge everything we access is protected by other means,
      so this is superflous. And because it now gets in the way (we add a
      new caller in __wait_seqno, which can be called without
      dev->struct_mutext) let's just remove it.
      
      v3: Group all the i915_gem_check_wedge refactoring into this patch, so
      that this patch here is all about not returning -EAGAIN to callsites
      that can't handle syscall restarting.
      
      v4: Add clarification what interuptible == fales means in our code,
      requested by Ben Widawsky.
      
      v5: Fix EAGAIN mispell noticed by Chris Wilson.
      Reviewed-by: NBen Widawsky <ben@bwidawsk.net>
      Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
      Tested-by: NChris Wilson <chris@chris-wilson.co.uk>
      Signed-Off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      d6b2c790
    • D
      drm/i915: don't trylock in the gpu reset code · d54a02c0
      Daniel Vetter 提交于
      Simply failing to reset the gpu because someone else might still hold
      the mutex isn't a great idea - I see reliable silent reset failures.
      And gpu reset simply needs to be reliable and Just Work.
      
      "But ... the deadlocks!"
      
      We already kick all processes waiting for the gpu before launching the
      reset work item. New waiters need to check the wedging state anyway
      and then bail out. If we have places that can deadlock, we simply need
      to fix them.
      
      "But ... testing!"
      
      We have the gpu hangman, and if the current gpu load gem_exec_nop
      isn't good enough to hit a specific case, we can add a new one.
      
      "But ...  don't we return -EAGAIN for non-interruptible calls to
      wait_seqno now?"
      
      Yep, but this problem already exists in the current code. A follow up
      patch will remedy this by returning -EIO for non-interruptible sleeps
      if the gpu died and the low-level wait bails out with -EAGAIN.
      Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
      Tested-by: NChris Wilson <chris@chris-wilson.co.uk>
      Signed-Off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      d54a02c0
    • P
      drm/i915: fix PIPE_DDI_PORT_MASK · 4c3c115a
      Paulo Zanoni 提交于
      Only bits 30:28, bit 31 is PIPE_DDI_FUNC_ENABLE.
      Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      4c3c115a
    • E
      drm/i915: prevent bogus intel_update_fbc notifications · 4c243e25
      Eugeni Dodonov 提交于
      This pollutes dmesg output even if we do not have FBC for the device, so
      move the DRM_DEBUG_KMS statement lower.
      
      v2: just kill the message as suggested by Daniel.
      Signed-off-by: NEugeni Dodonov <eugeni.dodonov@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      4c243e25
    • E
      drm/i915: re-initialize DDI buffer translations after resume · a8f78b58
      Eugeni Dodonov 提交于
      This is necessary for the modesetting to work correctly after a
      suspend-resume cycle. Without this, the pipes and clocks got the correct
      configuration, but the underlying DDI buffers configuration was lost.
      Signed-off-by: NEugeni Dodonov <eugeni.dodonov@intel.com>
      Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      a8f78b58
    • P
      drm/i915: don't ironlake_init_pch_refclk() on LPT · 40579abe
      Paulo Zanoni 提交于
      This function is used to set the PCH_DREF_CONTROL register, which does
      not exist on LPT anymore.
      Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      40579abe
    • P
      drm/i915: get rid of dev_priv->info->has_pch_split · 45e6e3a1
      Paulo Zanoni 提交于
      Previously we had has_pch_split to tell us whether we had a PCH or not
      and we also had dev_priv->pch_type to tell us which kind of PCH it
      was, but it could only be used if we were 100% sure we did have a PCH.
      Now that PCH_NONE was added to dev_priv->pch_type we don't need
      has_pch_split anymore: we can just check for pch_type != PCH_NONE.
      
      The HAS_PCH_{IBX,CPT,LPT} macros use dev_priv->pch_type, so they can
      only be called after intel_detect_pch. The HAS_PCH_SPLIT macro looks
      at dev_priv->info->has_pch_split, which is available earlier.
      
      Since the goal is to implement HAS_PCH_SPLIT using dev_priv->pch_type
      instead of dev_priv->info->has_pch_split, we need to make sure that
      intel_detect_pch is called before any calls to HAS_PCH_SPLIT are made.
      So we moved the intel_detect_pch call to an earlier stage.
      Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      45e6e3a1
    • P
      drm/i915: add PCH_NONE to enum intel_pch · f0350830
      Paulo Zanoni 提交于
      And rely on the fact that it's 0 to assume that machines without a PCH
      will have PCH_NONE as dev_priv->pch_type.
      
      Just today I finally realized that HAS_PCH_IBX is true for machines
      without a PCH. IMHO this is totally counter-intuitive and I don't
      think it's a good idea to assume that we're going to check for
      HAS_PCH_IBX only after we check for HAS_PCH_SPLIT.
      
      I believe that in the future we'll have more PCH types and checks
      like:
      
          if (HAS_PCH_IBX(dev) || HAS_PCH_CPT(dev))
      
      will become more and more common. There's a good chance that we may
      break non-PCH machines by adding these checks in code that runs on all
      machines. I also believe that the HAS_PCH_SPLIT check will become less
      common as we add more and more different PCH types. We'll probably
      start replacing checks like:
      
          if (HAS_PCH_SPLIT(dev))
              foo();
          else
              bar();
      
      with:
      
          if (HAS_PCH_NEW(dev))
              baz();
          else if (HAS_PCH_OLD(dev) || HAS_PCH_IBX(dev))
              foo();
          else
              bar();
      
      and this may break gen 2/3/4.
      
      As far as we have investigated, this patch will affect the behavior of
      intel_hdmi_dpms and intel_dp_link_down on gen 4. In both functions the
      code inside the HAS_PCH_IBX check is for IBX-specific workarounds, so
      we should be safe. If we start bisecting gen 2/3/4 bugs to this commit
      we should consider replacing the HAS_PCH_IBX checks with something
      else.
      
      V2: Improve commit message, list possible side effects and solution.
      Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      f0350830
    • J
      drm/i915: prefer wide & slow to fast & narrow in DP configs · 2514bc51
      Jesse Barnes 提交于
      High frequency link configurations have the potential to cause trouble
      with long and/or cheap cables, so prefer slow and wide configurations
      instead.  This patch has the potential to cause trouble for eDP
      configurations that lie about available lanes, so if we run into that we
      can make it conditional on eDP.
      
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=45801
      Tested-by: peter@colberg.org
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      2514bc51