1. 04 Apr, 2014 4 commits
  2. 02 Apr, 2014 1 commit
    • Chris Wilson's avatar
      drm/i915: Fix the computation of required fb size for pipe · bc104d1f
      Chris Wilson authored
      The computation of required framebuffer size in
      
      commit d978ef14
      Author: Jesse Barnes <jbarnes@virtuousgeek.org>
      Date:   Fri Mar 7 08:57:51 2014 -0800
      
          drm/i915: Wrap the preallocated BIOS framebuffer and preserve for KMS fbcon v12
      
      is too optimistic, and would rely on the invariant fb being
      reconstructed to exactly fit each pipe (and probably ignore hardware
      limits). Instead, we want to compute the upper bound on what the display
      engine will access and ensure that is within the inherited framebuffer.
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      bc104d1f
  3. 01 Apr, 2014 8 commits
    • Paulo Zanoni's avatar
      drm/i915: don't get/put runtime PM at the debugfs forcewake file · c8431fda
      Paulo Zanoni authored
      Because gen6_gt_force_wake_{get,put} should already be responsible for
      getting/putting runtime PM. If we keep these calls, debugfs will not
      be testing the get/put calls of the forcewake functions.
      Signed-off-by: default avatarPaulo Zanoni <paulo.r.zanoni@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      c8431fda
    • Paulo Zanoni's avatar
      drm/i915: fix WARNs when reading DDI state while suspended · 882244a3
      Paulo Zanoni authored
      If runtime PM is enabled and we unset all modes, we will runtime
      suspend after __intel_set_mode() , then function
      intel_modeset_check_state() will try to read the HW state while it is
      suspended and trigger lots of WARNs because it shouldn't be reading
      registers.
      
      So on this patch we make intel_ddi_connector_get_hw_state() return
      false in case the power domain is disabled, and we also make
      intel_display_power_enabled() return false in case the device is
      suspended. Notice that we can't just use
      intel_display_power_enabled_sw() because while the driver is being
      initialized the power domain refcounts are not reflecting the real
      state of the hardware.
      
      Just for reference, I have previously published an alternate patch for
      this problem, called "drm/i915: get runtime PM at intel_set_mode".
      
      Testcase: igt/pm_pc8
      Signed-off-by: default avatarPaulo Zanoni <paulo.r.zanoni@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      882244a3
    • Paulo Zanoni's avatar
      drm/i915: don't read cursor registers on powered down pipes · a23dc658
      Paulo Zanoni authored
      At i915_display_info, don't call cursor_position() for a disabled
      CRTC, since the CRTC may be on a powered down pipe, and this will
      cause "Unclaimed register before interrupt" error messages.
      
      Testcase: igt/pm_pc8/debugfs-read
      Signed-off-by: default avatarPaulo Zanoni <paulo.r.zanoni@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      a23dc658
    • Paulo Zanoni's avatar
      drm/i915: get runtime PM at i915_display_info · b0e5ddf3
      Paulo Zanoni authored
      Otherwise we may get some WARNs complaining that we're reading a
      register while we're suspended.
      
      Testcase: igt/pm_pc8/debugfs-read
      Signed-off-by: default avatarPaulo Zanoni <paulo.r.zanoni@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      b0e5ddf3
    • Paulo Zanoni's avatar
      drm/i915: don't read pp_ctrl_reg if we're suspended · efbc20ab
      Paulo Zanoni authored
      ... at edp_have_panel_vdd. Just return false, saying we don't have the
      panel VDD since the device is suspended.
      
      We started getting WARNs about this problem since the patch that
      started checking if we're suspended while reading registers.
      
      Example backtrace provided by Paulo:
      
      [   63.572201] [drm:hsw_enable_pc8] Enabling package C8+
      [   63.581831] [drm:i915_runtime_suspend] Device suspended
      [   63.664798] ------------[ cut here ]------------
      [   63.664824] WARNING: CPU: 3 PID: 828 at
      drivers/gpu/drm/i915/intel_uncore.c:47
      assert_device_not_suspended.isra.7+0x32/0x40 [i915]()
      [   63.664826] Device suspended
      [   63.664828] Modules linked in: ccm fuse ip6table_filter ip6_tables
      ebtable_nat ebtables arc4 ath9k_htc ath9k_common ath9k_hw mac80211 ath
      cfg80211 iTCO_wdt iTCO_vendor_support x86_pkg_temp_thermal coretemp
      microcode i2c_i801 e1000e pcspkr serio_raw lpc_ich ptp pps_core mei_me
      mei mfd_core dm_crypt i915 crc32_pclmul crc32c_intel
      ghash_clmulni_intel i2c_algo_bit drm_kms_helper drm video
      [   63.664867] CPU: 3 PID: 828 Comm: kworker/3:3 Not tainted 3.14.0+ #153
      [   63.664869] Hardware name: Intel Corporation Shark Bay Client
      platform/WhiteTip Mountain 1, BIOS HSWLPTU1.86C.0133.R00.1309172123
      09/17/2013
      [   63.664887] Workqueue: events edp_panel_vdd_work [i915]
      [   63.664889]  0000000000000009 ffff88009d745c28 ffffffff8167ec6f
      ffff88009d745c70
      [   63.664895]  ffff88009d745c60 ffffffff8106c8ed ffff880036278000
      00000000000c7204
      [   63.664900]  ffff88014f2d3040 ffff880036278070 0000000000000001
      ffff88009d745cc0
      [   63.664905] Call Trace:
      [   63.664911]  [<ffffffff8167ec6f>] dump_stack+0x4d/0x66
      [   63.664916]  [<ffffffff8106c8ed>] warn_slowpath_common+0x7d/0xa0
      [   63.664920]  [<ffffffff8106c95c>] warn_slowpath_fmt+0x4c/0x50
      [   63.664926]  [<ffffffff810bd6be>] ? mark_held_locks+0xae/0x130
      [   63.664941]  [<ffffffffa00d80d2>]
      assert_device_not_suspended.isra.7+0x32/0x40 [i915]
      [   63.664956]  [<ffffffffa00d99d2>] gen6_read32+0x32/0x120 [i915]
      [   63.664969]  [<ffffffffa00d99a0>] ? gen6_read8+0x120/0x120 [i915]
      [   63.664985]  [<ffffffffa0106f8f>] edp_have_panel_vdd+0x3f/0x50 [i915]
      [   63.665000]  [<ffffffffa01074e8>] edp_panel_vdd_off_sync+0x58/0x1c0 [i915]
      [   63.665004]  [<ffffffff8108a06c>] ? process_one_work+0x18c/0x560
      [   63.665018]  [<ffffffffa0107684>] edp_panel_vdd_work+0x34/0x50 [i915]
      [   63.665022]  [<ffffffff8108a0d7>] process_one_work+0x1f7/0x560
      [   63.665026]  [<ffffffff8108a06c>] ? process_one_work+0x18c/0x560
      [   63.665031]  [<ffffffff8108ae2b>] worker_thread+0x11b/0x3a0
      [   63.665035]  [<ffffffff8108ad10>] ? manage_workers.isra.21+0x2a0/0x2a0
      [   63.665039]  [<ffffffff810916fc>] kthread+0xfc/0x120
      [   63.665043]  [<ffffffff81091600>] ? kthread_create_on_node+0x230/0x230
      [   63.665048]  [<ffffffff8169082c>] ret_from_fork+0x7c/0xb0
      [   63.665052]  [<ffffffff81091600>] ? kthread_create_on_node+0x230/0x230
      [   63.665054] ---[ end trace 1250bcc890af9999 ]---
      [   63.665060] [drm:edp_panel_vdd_off_sync] Turning eDP VDD off
      [   63.665061] ------------[ cut here ]------------
      
      Testcase: igt/pm_pc8
      Signed-off-by: default avatarPaulo Zanoni <paulo.r.zanoni@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      efbc20ab
    • Paulo Zanoni's avatar
      drm/i915: get runtime PM at i915_reg_read_ioctl · cf67c70f
      Paulo Zanoni authored
      To avoid WARNs when we call it.
      
      Testcase: igt/pm_pc8/reg-read-ioctl
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=75693Signed-off-by: default avatarPaulo Zanoni <paulo.r.zanoni@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      cf67c70f
    • Paulo Zanoni's avatar
      drm/i915: don't schedule force_wake_timer at gen6_read · aa0b3b5b
      Paulo Zanoni authored
      So far force_wake_timer was only used by gen6_gt_force_wake_put. Since
      we always had balanced gen6_gt_force_wake_get/put calls, we could
      guarantee balanced calls to intel_runtime_pm_get/put.
      
      Commit 8232644c, "drm/i915: Convert
      the forcewake worker into a timer func" started scheduling the
      force_wake_timer at gen6_read, which resulted in an unbalanced
      runtime_pm refcount.
      
      So this commit just reverts to the old behavior until we can find a
      proper way to used delayed force_wake from the register read/write
      macros without leaving the runtime_pm refcounts unbalanced and without
      runtime suspending the driver while forcewake is active.
      
      Testcase: igt/pm_pc8/rte
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76544Signed-off-by: default avatarPaulo Zanoni <paulo.r.zanoni@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      aa0b3b5b
    • Imre Deak's avatar
      drm/i915: vlv: reserve the GT power context only once during driver init · ae48434c
      Imre Deak authored
      Atm we reserve/allocate and free the power context during GT power
      enable/disable time. There is no need to do this, we can reserve/allocate
      the buffer once during driver loading and free it during driver cleanup.
      The re-reservation can also fail in case the driver previously manages to
      allocate something on the given fixed address.
      
      The buffer isn't exepected to move even if allocated by the BIOS, for
      safety add an assert to check this assumption.
      
      This also fixed a bug for Ville, where re-reserving the context failed
      during a GPU reset (I assume because something else got allocated on its
      fixed address).
      Tested-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Signed-off-by: default avatarImre Deak <imre.deak@intel.com>
      Reviewed-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      ae48434c
  4. 31 Mar, 2014 23 commits
  5. 30 Mar, 2014 4 commits