1. 07 8月, 2013 5 次提交
    • J
      drm/i915: do not disable backlight on vgaswitcheroo switch off · 3f577573
      Jani Nikula 提交于
      On muxed systems, the other vgaswitcheroo client may depend on i915 to
      handle the backlight. We began switching off the backlight since
      
      commit a261b246
      Author: Daniel Vetter <daniel.vetter@ffwll.ch>
      Date:   Thu Jul 26 19:21:47 2012 +0200
      
          drm/i915: disable all crtcs at suspend time
      
      breaking backlight on discreet graphics in (some) muxed systems.
      
      Keep the backlight on when the state is changed through vgaswitcheroo.
      
      Note: The alternative would be to add a quirk table to achieve the same
      based on system identifiers, but AFAICS it would asymptotically approach
      effectively the same as this patch as more IDs are added, but with the
      maintenance burden of the quirk table.
      
      Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=55311Tested-by: NFede <fedevx@yahoo.com>
      Tested-by: NAximab <laurent.debian@gmail.com>
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=59785Tested-by: Nsfievet <sebastien.fievet@free.fr>
      Signed-off-by: NJani Nikula <jani.nikula@intel.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      3f577573
    • V
      drm/i915: Don't call encoder's get_config unless encoder is active · 3eaba51c
      Ville Syrjälä 提交于
      The SDVO code tries to compare the encoder's and crtc's idea of the
      pixel_multiplier. Normally they have to match, but when transitioning
      to DPMS off, we turn off the pipe before reading out the pipe_config,
      so the pixel_multiplier in the pipe_config will be 0, whereas the
      encoder will still have its pixel_multiplier set to whatever value we
      were using when the display was active. This leads to a warning
      from intel_modeset_check_state().
      
      WARNING: CPU: 1 PID: 2846 at drivers/gpu/drm/i915/intel_sdvo.c:1378 intel_sdvo_get_config+0x158/0x160()
      SDVO pixel multiplier mismatch, port: 0, encoder: 1
      Modules linked in: snd_hda_codec_idt snd_hda_intel snd_hda_codec snd_hwdep
      CPU: 1 PID: 2846 Comm: Xorg Not tainted 3.11.0-rc3-00208-gbe1e8d7-dirty #19
      Hardware name: Apple Computer, Inc. Macmini1,1/Mac-F4208EC8, BIOS  MM11.88Z.0055.B03.0604071521 04/07/06
       00000000 00000000 ef0afa54 c1597bbb c1737ea4 ef0afa84 c10392ca c1737e6c
       ef0afab0 00000b1e c1737ea4 00000562 c12dfbe8 c12dfbe8 ef0afb14 00000000
       f697ec00 ef0afa9c c103936e 00000009 ef0afa94 c1737e6c ef0afab0 ef0afadc
      Call Trace:
       [<c1597bbb>] dump_stack+0x41/0x56
       [<c10392ca>] warn_slowpath_common+0x7a/0xa0
       [<c103936e>] warn_slowpath_fmt+0x2e/0x30
       [<c12dfbe8>] intel_sdvo_get_config+0x158/0x160
       [<c12c3220>] check_crtc_state+0x1e0/0xb10
       [<c12cdc7d>] intel_modeset_check_state+0x29d/0x7c0
       [<c12dfe5c>] intel_sdvo_dpms+0x5c/0xa0
       [<c12985de>] drm_mode_obj_set_property_ioctl+0x40e/0x420
       [<c1298625>] drm_mode_connector_property_set_ioctl+0x35/0x40
       [<c1289294>] drm_ioctl+0x3e4/0x540
       [<c10fc1a2>] do_vfs_ioctl+0x72/0x570
       [<c10fc72f>] SyS_ioctl+0x8f/0xa0
       [<c159b7fa>] sysenter_do_call+0x12/0x22
      ---[ end trace 7ce940aff1366d60 ]---
      
      Fix the problem by skipping the encoder get_config() function for
      inactive encoders.
      Tested-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      3eaba51c
    • A
      drm/i915: avoid brightness overflow when doing scale · 22505b82
      Aaron Lu 提交于
      Some card's max brightness level is pretty large, e.g. on Acer Aspire
      4732Z, the max level is 989910. If user space set a large enough level
      then the current scale done in intel_panel_set_backlight will cause an
      integer overflow and the scaled level will be mistakenly small, leaving
      user with an almost black screen. This patch fixes this problem.
      Signed-off-by: NAaron Lu <aaron.lu@intel.com>
      [danvet: Add a comment to explain what's going on.]
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      22505b82
    • P
      drm/i915: update last_vblank when disabling the power well · 9dbd8feb
      Paulo Zanoni 提交于
      The DRM layer keeps track of our vblanks and it assumes our vblank
      counters only go back to zero when they overflow. The problem is that
      when we disable the power well our counters also go to zero, but it
      doesn't mean they did overflow. So on this patch we grab the lock and
      update last_vblank so the DRM layer won't think our counters
      overflowed.
      
      This patch fixes the following intel-gpu-tools test:
      ./kms_flip --run-subtest blocking-absolute-wf_vblank
      
      Regression introduced by the following commit:
      
      commit bf51d5e2
      Author: Paulo Zanoni <paulo.r.zanoni@intel.com>
      Date:   Wed Jul 3 17:12:13 2013 -0300
          drm/i915: switch disable_power_well default value to 1
      
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=66808Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
      [danvet: Added a comment that this might be better done in
      drm_vblank_post_modeset in general.]
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      9dbd8feb
    • D
      drm/i915: fix gen4 digital port hotplug definitions · 0ce99f74
      Daniel Vetter 提交于
      Apparently Bspec is wrong in this case here even for gm45. Note that
      Bspec is horribly misguided on i965g/gm, so we don't have any other
      data points besides that it seems to make machines work better.
      
      With this changes all the bits in PORT_HOTPLUG_STAT for the digital
      ports are ordered the same way. This seems to agree with what register
      dumps from the hpd storm handling code shows, where the LIVE bit and
      the short/long pulse STATUS bits light up at the same time with this
      enumeration (but no with the one from Bspec).
      
      Also tested on my gm45 which has two DP+ ports, and everything seems
      to still work as expected.
      
      References: http://www.mail-archive.com/intel-gfx@lists.freedesktop.org/msg23054.html
      Cc: Egbert Eich <eich@suse.com>
      Cc: Jan Niggemann <jn@hz6.de>
      Tested-by: NJan Niggemann <jn@hz6.de>
      [danvet: Add a big warning that Bspec seems to be wrong for these
      bits, suggested by Jani.]
      Acked-by: NJani Nikula <jani.nikula@linux.intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      0ce99f74
  2. 31 7月, 2013 1 次提交
  3. 26 7月, 2013 1 次提交
  4. 25 7月, 2013 1 次提交
  5. 23 7月, 2013 1 次提交
    • D
      drm/i915: fix hdmi portclock limits · 7d148ef5
      Daniel Vetter 提交于
      In
      
      commit 325b9d04
      Author: Daniel Vetter <daniel.vetter@ffwll.ch>
      Date:   Fri Apr 19 11:24:33 2013 +0200
      
          drm/i915: fixup 12bpc hdmi dotclock handling
      
      I've errornously claimed that we don't yet support the hdmi 1.4
      dotclocks > 225 MHz on Haswell. But a bug report and a closer look at
      the wrpll table showed that we've supported port clocks up to 300MHz.
      
      With the new code to dynamically compute wrpll limits we should have
      no issues going up to the full 340 MHz range of hdmi 1.4, so let's
      just use that to fix this regression. That'll allow 4k over hdmi for
      free!
      
      v2: Drop the random hunk that somehow slipped in.
      
      v3: Cantiga has the original HDMI dotclock limit of 165MHz. And also
      patch up the mode filtering. To do so extract the dotclock limits into
      a little helper function.
      
      v4: Use 300MHz (from Bspec) instead of 340MHz (upper limit for hdmi
      1.3), apparently hw is not required to be able to drive the highest
      dotclocks. Suggested by Damien.
      
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67048
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67030
      Tested-by: Andreas Reis <andreas.reis@gmail.com> (v2)
      Cc: Damien Lespiau <damien.lespiau@intel.com>
      Reviewed-by: NDamien Lespiau <damien.lespiau@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      7d148ef5
  6. 21 7月, 2013 1 次提交
    • D
      drm/i915: fix up gt init sequence fallout · 181d1b9e
      Daniel Vetter 提交于
      The regression fix for gen6+ rps fallout
      
      commit 7dcd2677
      Author: Konstantin Khlebnikov <khlebnikov@openvz.org>
      Date:   Wed Jul 17 10:22:58 2013 +0400
      
          drm/i915: fix long-standing SNB regression in power consumption after resume
      
      unintentionally also changed the init sequence ordering between
      gt_init and gt_reset - we need to reset BIOS damage like leftover
      forcewake references before we run our own code. Otherwise we can get
      nasty dmesg noise like
      
      [drm:__gen6_gt_force_wake_mt_get] *ERROR* Timed out waiting for forcewake old ack to clear.
      
      again. Since _reset suggests that we first need to have stuff
      initialized (which isn't the case here) call it sanitze instead.
      
      While at it also block out the rps disable introduced by the above
      commit on ilk: We don't have any knowledge of ilk rps being broken in
      similar ways. And the disable functions uses the default hw state
      which is only read out when we're enabling rps. So essentially we've
      been writing random grabage into that register.
      Reported-by: NChris Wilson <chris@chris-wilson.co.uk>
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Cc: Konstantin Khlebnikov <khlebnikov@openvz.org>
      Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
      Cc: stable@vger.kernel.org
      Tested-by: NChris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      181d1b9e
  7. 20 7月, 2013 2 次提交
  8. 19 7月, 2013 1 次提交
    • D
      drm/i915: correctly restore fences with objects attached · 94a335db
      Daniel Vetter 提交于
      To avoid stalls we delay tiling changes and especially hold of
      committing the new fence state for as long as possible.
      Synchronization points are in the execbuf code and in our gtt fault
      handler.
      
      Unfortunately we've missed that tricky detail when adding proper fence
      restore code in
      
      commit 19b2dbde
      Author: Chris Wilson <chris@chris-wilson.co.uk>
      Date:   Wed Jun 12 10:15:12 2013 +0100
      
          drm/i915: Restore fences after resume and GPU resets
      
      The result was that we've restored fences for objects with no tiling,
      since the object<->fence link still existed after resume. Now that
      wouldn't have been too bad since any subsequent access would have
      fixed things up, but if we've changed from tiled to untiled real havoc
      happened:
      
      The tiling stride is stored -1 in the fence register, so a stride of 0
      resulted in all 1s in the top 32bits, and so a completely bogus fence
      spanning everything from the start of the object to the top of the
      GTT. The tell-tale in the register dumps looks like:
      
                       FENCE START 2: 0x0214d001
                       FENCE END 2: 0xfffff3ff
      
      Bit 11 isn't set since the hw doesn't store it, even when writing all
      1s (at least on my snb here).
      
      To prevent such a gaffle in the future add a sanity check for fences
      with an untiled object attached in i915_gem_write_fence.
      
      v2: Fix the WARN, spotted by Chris.
      
      v3: Trying to reuse get_fences looked ugly and obfuscated the code.
      Instead reuse update_fence and to make it really dtrt also move the
      fence dirty state clearing into update_fence.
      
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Cc: Stéphane Marchesin <marcheu@chromium.org>
      Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=60530
      Cc: stable@vger.kernel.org (for 3.10 only)
      Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
      Tested-by: NMatthew Garrett <matthew.garrett@nebula.com>
      Tested-by: NBjörn Bidar <theodorstormgrade@gmail.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      94a335db
  9. 18 7月, 2013 1 次提交
    • R
      ACPI / video / i915: No ACPI backlight if firmware expects Windows 8 · 8c5bd7ad
      Rafael J. Wysocki 提交于
      According to Matthew Garrett, "Windows 8 leaves backlight control up
      to individual graphics drivers rather than making ACPI calls itself.
      There's plenty of evidence to suggest that the Intel driver for
      Windows [8] doesn't use the ACPI interface, including the fact that
      it's broken on a bunch of machines when the OS claims to support
      Windows 8.  The simplest thing to do appears to be to disable the
      ACPI backlight interface on these systems".
      
      There's a problem with that approach, however, because simply
      avoiding to register the ACPI backlight interface if the firmware
      calls _OSI for Windows 8 may not work in the following situations:
       (1) The ACPI backlight interface actually works on the given system
           and the i915 driver is not loaded (e.g. another graphics driver
           is used).
       (2) The ACPI backlight interface doesn't work on the given system,
           but there is a vendor platform driver that will register its
           own, equally broken, backlight interface if not prevented from
           doing so by the ACPI subsystem.
      Therefore we need to allow the ACPI backlight interface to be
      registered until the i915 driver is loaded which then will unregister
      it if the firmware has called _OSI for Windows 8 (or will register
      the ACPI video driver without backlight support if not already
      present).
      
      For this reason, introduce an alternative function for registering
      ACPI video, acpi_video_register_with_quirks(), that will check
      whether or not the ACPI video driver has already been registered
      and whether or not the backlight Windows 8 quirk has to be applied.
      If the quirk has to be applied, it will block the ACPI backlight
      support and either unregister the backlight interface if the ACPI
      video driver has already been registered, or register the ACPI
      video driver without the backlight interface otherwise.  Make
      the i915 driver use acpi_video_register_with_quirks() instead of
      acpi_video_register() in i915_driver_load().
      
      This change is based on earlier patches from Matthew Garrett,
      Chun-Yi Lee and Seth Forshee and includes a fix from Aaron Lu's.
      
      References: https://bugzilla.kernel.org/show_bug.cgi?id=51231Tested-by: NAaron Lu <aaron.lu@intel.com>
      Tested-by: NIgor Gnatenko <i.gnatenko.brain@gmail.com>
      Tested-by: NYves-Alexis Perez <corsac@debian.org>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Reviewed-by: NAaron Lu <aaron.lu@intel.com>
      Acked-by: NMatthew Garrett <matthew.garrett@nebula.com>
      8c5bd7ad
  10. 17 7月, 2013 3 次提交
    • C
      drm/i915: Fix dereferencing invalid connectors in is_crtc_connector_off() · 2e57f47d
      Chris Wilson 提交于
      In commit e3de42b6
      Author: Imre Deak <imre.deak@intel.com>
      Date:   Fri May 3 19:44:07 2013 +0200
      
          drm/i915: force full modeset if the connector is in DPMS OFF mode
      
      a new function was added that walked over the set of connectors to see
      if any of the currently associated CRTC was switched off. This function
      walked an array of connectors, rather than the array of pointers to
      connectors contained in the drm_mode_set - i.e. it was dereferencing far
      past the end of the first connector. This only becomes an issue if we
      attempt to use a clone mode (i.e. more than one connector per CRTC) such
      that set->num_connectors > 1.
      Reported-by: NTimo Aaltonen <tjaalton@ubuntu.com>
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=65927Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Cc: Imre Deak <imre.deak@intel.com>
      Cc: Egbert Eich <eich@suse.de>
      Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Cc: stable@vger.kernel.org
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      2e57f47d
    • D
      drm/i915: Sanitize shared dpll state · 35c95375
      Daniel Vetter 提交于
      There seems to be no limit to the amount of gunk the firmware can
      leave behind. Some platforms leave pch dplls on which are not in
      active use at all. The example in the bug report is a Apple Macbook
      Pro.
      
      Note that this escape scrunity of the hw state checker until we've
      tried to use this enabled, but unused pll since we did only check for
      the inverse case of a in-used, but disabled pll.
      
      v2: Add a WARN in the pll state checker which would have caught this
      case.
      
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=66952Reported-and-tested-by: Nshui yangwei <yangweix.shui@intel.com>
      Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      35c95375
    • K
      drm/i915: fix long-standing SNB regression in power consumption after resume v2 · 7dcd2677
      Konstantin Khlebnikov 提交于
      This patch fixes regression in power consumtion of sandy bridge gpu, which
      exists since v3.6 Sometimes after resuming from s2ram gpu starts thinking that
      it's extremely busy. After that it never reaches rc6 state.
      
      Bug exists since kernel v3.6:
      
      commit b4ae3f22
      Author: Jesse Barnes <jbarnes@virtuousgeek.org>
      Date:   Thu Jun 14 11:04:48 2012 -0700
      
          drm/i915: load boot context at driver init time
      
      For some reason RC6 is already enabled at the beginning of resuming process.
      Following initliaztion breaks some internal state and confuses RPS engine.
      This patch disables RC6 at the beginnig of resume and initialization.
      
      I've rearranged initialization sequence, because intel_disable_gt_powersave()
      needs initialized force_wake_get/put and some locks from the dev_priv.
      
      Note: The culprit in the initialization sequence seems to be the write
      to MBCTL added in the above mentioned commit. The first version of
      this patch just held a forcewake reference across the clock gating
      init functions, which seems to have been enought to gather quite a few
      positive test reports. But since that smelled a bit like ad-hoc
      duct-tape v2 now just disables rps/rc6 across the entire hw setup.
      
      References: https://bugs.freedesktop.org/show_bug.cgi?id=54089
      References: https://bugzilla.kernel.org/show_bug.cgi?id=58971
      References: https://patchwork.kernel.org/patch/2827634/ (patch v1)
      Signed-off-by: NKonstantin Khlebnikov <khlebnikov@openvz.org>
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
      [danvet: Add note about v1 vs. v2 of this patch and use standard
      layout for the commit citation. Also add the tested-bys from v1 and a
      cc: stable.]
      Cc: stable@vger.kernel.org (Note: tiny conflict due to the addition of
      the backlight lock in 3.11)
      Tested-by: Alexander Kaltsas <alexkaltsas@gmail.com> (v1)
      Tested-by: rocko <rockorequin@hotmail.com> (v1)
      Tested-by: JohnMB <johnmbryant@sky.com> (v1)
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      7dcd2677
  11. 13 7月, 2013 2 次提交
  12. 12 7月, 2013 1 次提交
    • D
      drm/i915: fix up readout of the lvds dither bit on gen2/3 · 06922821
      Daniel Vetter 提交于
      It's in the PFIT_CONTROL register, but very much associated with the
      lvds encoder. So move the readout for it (in the case of an otherwise
      disabled pfit) from the pipe to the lvds encoder's get_config
      function.
      
      Otherwise we get a pipe state mismatch if we use pipe B for a non-lvds
      output and we've left the dither bit enabled behind us. This can
      happen if the BIOS has set the bit (some seem to unconditionally do
      that, even in the complete absence of an lvds port), but not enabled
      pipe B at boot-up. Then we won't clear the pfit control register since
      we can only touch that if the pfit is associated with our pipe in the
      crtc configuration - we could trample over the pfit state of the other
      pipe otherwise since it's shared. Once pipe B is enabled we notice
      that the 6to8 dither bit is set and complain about the mismatch.
      
      Note that testing indicates that we don't actually need to set this
      bit when the pfit is disabled, dithering on 18bpp panels seems to work
      regardless. But ripping that code out is not something for a bugfix
      meant for -rc kernels.
      
      v2: While at it clarify the logic in i9xx_get_pfit_config, spurred by
      comments from Chris on irc.
      
      v3: Use Chris suggestion to make the control flow in
      i9xx_get_pfit_config easier to understand.
      
      v4: Kill the extra line, spotted by Chris.
      Reported-by: NKnut Petersen <Knut_Petersen@t-online.de>
      Cc: Knut Petersen <Knut_Petersen@t-online.de>
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      References: http://lists.freedesktop.org/archives/intel-gfx/2013-July/030092.htmlTested-by: NKnut Petersen <Knut_Petersen@t-online.de>
      Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      06922821
  13. 10 7月, 2013 4 次提交
    • C
      Revert "drm/i915: Workaround incoherence between fences and LLC across multiple CPUs" · 46a0b638
      Chris Wilson 提交于
      This reverts commit 25ff1195 and the follow on for Valleyview commit 2dc8aae0.
      
      commit 25ff1195
      Author: Chris Wilson <chris@chris-wilson.co.uk>
      Date:   Thu Apr 4 21:31:03 2013 +0100
      
          drm/i915: Workaround incoherence between fences and LLC across multiple CPUs
      
      commit 2dc8aae0
      Author: Chris Wilson <chris@chris-wilson.co.uk>
      Date:   Wed May 22 17:08:06 2013 +0100
      
          drm/i915: Workaround incoherence with fence updates on Valleyview
      
      Jon Bloomfield came up with a plausible explanation and cheap fix
      (drm/i915: Fix incoherence with fence updates on Sandybridge+) for the
      race condition, so lets run with it.
      
      This is a candidate for stable as the old workaround incurs a
      significant cost (calling wbinvd on all CPUs before performing the
      register write) for some workloads as noted by Carsten Emde.
      
      Link: http://lists.freedesktop.org/archives/intel-gfx/2013-June/028819.html
      References: https://www.osadl.org/?id=1543#c7602
      References: https://bugs.freedesktop.org/show_bug.cgi?id=63825Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Cc: Jon Bloomfield <jon.bloomfield@intel.com>
      Cc: Carsten Emde <C.Emde@osadl.org>
      Cc: stable@vger.kernel.org
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      46a0b638
    • C
      drm/i915: Fix incoherence with fence updates on Sandybridge+ · d18b9619
      Chris Wilson 提交于
      This hopefully fixes the root cause behind the workaround added in
      
      commit 25ff1195
      Author: Chris Wilson <chris@chris-wilson.co.uk>
      Date:   Thu Apr 4 21:31:03 2013 +0100
      
          drm/i915: Workaround incoherence between fences and LLC across multiple CPUs
      
      Thanks to further investigation by Jon Bloomfield, he realised that
      the 64-bit register might be broken up by the hardware into two 32-bit
      writes (a problem we have encountered elsewhere). This non-atomicity
      would then cause an issue where a second thread would see an
      intermediate register state (new high dword, old low dword), and this
      register would randomly be used in preference to its own thread register.
      This would cause the second thread to read from and write into a fairly
      random tiled location.  Breaking the operation into 3 explicit 32-bit
      updates (first disable the fence, poke the upper bits, then poke the lower
      bits and enable) ensures that, given proper serialisation between the
      32-bit register write and the memory transfer, that the fence value is
      always consistent.
      
      Armed with this knowledge, we can explain how the previous workaround
      work. The key to the corruption is that a second thread sees an
      erroneous fence register that conflicts and overrides its own. By
      serialising the fence update across all CPUs, we have a small window
      where no GTT access is occurring and so hide the potential corruption.
      This also leads to the conclusion that the earlier workaround was
      incomplete.
      
      v2: Be overly paranoid about the order in which fence updates become
      visible to the GPU to make really sure that we turn the fence off before
      doing the update, and then only switch the fence on afterwards.
      Signed-off-by: NJon Bloomfield <jon.bloomfield@intel.com>
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Cc: Carsten Emde <C.Emde@osadl.org>
      Cc: stable@vger.kernel.org
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      d18b9619
    • C
      drm/i915: Fix write-read race with multiple rings · 02978ff5
      Chris Wilson 提交于
      Daniel noticed a problem where is we wrote to an object with ring A in
      the middle of a very long running batch, then executed a quick batch on
      ring B before a batch that reads from the same object, its obj->ring would
      now point to ring B, but its last_write_seqno would be still relative to
      ring A. This would allow for the user to read from the object before the
      GPU had completed the write, as set_domain would only check that ring B
      had passed the last_write_seqno.
      
      To fix this simply (and inelegantly), we bump the last_write_seqno when
      switching rings so that the last_write_seqno is always relative to the
      current obj->ring.
      
      This fixes igt/tests/gem_write_read_ring_switch.
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Cc: stable@vger.kernel.org
      [danvet: Add note about the newly created igt which exercises this
      bug.]
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      02978ff5
    • G
      Partially revert "drm/i915: unconditionally use mt forcewake on hsw/ivb" · c11e5f35
      Guenter Roeck 提交于
      This patch partially reverts commit 36ec8f87 for
      IvyBridge CPUs.
      
      The original commit results in repeated 'Timed out waiting for forcewake old
      ack to clear' messages on a Supermicro C7H61 board (BIOS version 2.00 and 2.00b)
      with i7-3770K CPU. It ultimately results in a hangup if the system is highly
      loaded. Reverting the commit for IvyBridge CPUs fixes the issue.
      
      Issue a warning if the CPU is IvyBridge and mt forcewake is disabled, since
      this condition can result in secondary issues.
      
      v2: Only revert patch for Ivybridge CPUs
          Issue info message if mt forcewake is disabled on Ivybridge
      
      Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=60541
      Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Cc: Mika Kuoppala <mika.kuoppala@intel.com>
      Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
      Cc: stable@vger.kernel.org
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=66139Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      c11e5f35
  14. 09 7月, 2013 4 次提交
  15. 04 7月, 2013 3 次提交
  16. 02 7月, 2013 1 次提交
    • D
      drm/i915: Don't try to tear down the stolen drm_mm if it's not there · 446f8d81
      Daniel Vetter 提交于
      Every other place properly checks whether we've managed to set
      up the stolen allocator at boot-up properly, with the exception
      of the cleanup code. Which results in an ugly
      
      *ERROR* Memory manager not clean. Delaying takedown
      
      at module unload time since the drm_mm isn't initialized at all.
      
      v2: While at it check whether the stolen drm_mm is initialized instead
      of the more obscure stolen_base == 0 check.
      
      v3: Fix up the logic. Also we need to keep the stolen_base check in
      i915_gem_object_create_stolen_for_preallocated since that can be
      called before stolen memory is fully set up. Spotted by Chris Wilson.
      
      v4: Readd the conversion in i915_gem_object_create_stolen_for_preallocated,
      the check is for the dev_priv->mm.gtt_space drm_mm, the stolen
      allocatot must already be initialized when calling that function (if
      we indeed have stolen memory).
      
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=65953
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Tested-by: lu hua <huax.lu@intel.com> (v3)
      Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      446f8d81
  17. 01 7月, 2013 8 次提交
新手
引导
客服 返回
顶部