1. 02 4月, 2014 17 次提交
    • B
      drm/i915: Add register whitelists for mesa · 5947de9b
      Brad Volkin 提交于
      These registers are currently used by mesa for blitting,
      transform feedback extensions, and performance monitoring
      extensions.
      
      v2: REG64 macro
      Signed-off-by: NBrad Volkin <bradley.d.volkin@intel.com>
      Reviewed-by: NJani Nikula <jani.nikula@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      5947de9b
    • B
      drm/i915: Allow some privileged commands from master · 17c1eb15
      Brad Volkin 提交于
      The Intel DDX uses these to implement scanline waits in the X server.
      Signed-off-by: NBrad Volkin <bradley.d.volkin@intel.com>
      Reviewed-by: NJani Nikula <jani.nikula@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      17c1eb15
    • B
      drm/i915: Reject privileged commands · 9c640d1d
      Brad Volkin 提交于
      The spec defines most of these commands as privileged. A few others,
      like the semaphore mbox command and some display commands, are also
      reserved for the driver's use. Subsequent patches relax some of
      these restrictions.
      
      v2: Rebased
      Signed-off-by: NBrad Volkin <bradley.d.volkin@intel.com>
      Reviewed-by: NJani Nikula <jani.nikula@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      9c640d1d
    • B
      drm/i915: Initial command parser table definitions · 3a6fa984
      Brad Volkin 提交于
      Add command tables defining irregular length commands for each ring.
      This requires a few new command opcode definitions.
      
      v2: Whitespace adjustment in command definitions, sparse fix for !F
      
      OTC-Tracker: AXIA-4631
      Change-Id: I064bceb457e15f46928058352afe76d918c58ef5
      Signed-off-by: NBrad Volkin <bradley.d.volkin@intel.com>
      Reviewed-by: NJani Nikula <jani.nikula@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      3a6fa984
    • B
      drm/i915: Allow full PPGTT with param override · 8d214b7d
      Ben Widawsky 提交于
      When PPGTT was disabled by default, the patch also prevented the user
      from overriding this behavior via module parameter. Being able to test
      this on arbitrary kernels is extremely beneficial to track down the
      remaining bugs. The patch that prevented this was:
      
      commit 93a25a9e
      Author: Daniel Vetter <daniel.vetter@ffwll.ch>
      Date:   Thu Mar 6 09:40:43 2014 +0100
      
          drm/i915: Disable full ppgtt by default
      
      By default PPGTT is set to -1. 0 means off, 1 means aliasing only, 2
      means full, all other values are reserved.
      Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      8d214b7d
    • B
      drm/i915: Split out GTT specific header file · 0260c420
      Ben Widawsky 提交于
      This file contains all necessary defines, prototypes and typesdefs for
      manipulating GEN graphics address translation (this does not include the
      legacy AGP driver)
      
      Reiterating the comment in the header,
      "Please try to maintain the following order within this file unless it
      makes sense to do otherwise. From top to bottom:
      1. typedefs
      2. #defines, and macros
      3. structure definitions
      4. function prototypes
      
      Within each section, please try to order by generation in ascending
      order, from top to bottom (ie. GEN6 on the top, GEN8 on the bottom)."
      
      I've made some minor cleanups, and fixed a couple of typos while here -
      but there should be no functional changes.
      
      The purpose of the patch is to reduce clutter in our main header file,
      making room for new growth, and make documentation of our interfaces
      easier by splitting things out.
      
      With a little more work, like making i915_gtt a pointer, we could
      potentially completely isolate this header from i915_drv.h. At the
      moment however, I don't think it's worth the effort.
      
      Personally, I would have liked to put the PTE encoding functions in this
      file too, but I didn't want to rock the boat too much.
      
      A similar patch has been in use on my machine for some time. This exact
      patch though has only been compile tested.
      Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      0260c420
    • D
      drm/i915: make semaphore signaller detection more robust · 921d42ea
      Daniel Vetter 提交于
      Extract all this logic into a new helper function
      semaphore_wait_to_signaller_ring because:
      
      - The current code has way too much magic.
      
      - The current code doesn't look at bi16, which encodes VECS signallers
        on HSW. Those are just added after the fact, so can't be encoded in
        a neat formula.
      
      - The current logic can't blow up since it limits its value range
        sufficiently, but that's a bit too tricky to rely on in my opinion.
        Especially when we start to add bdw support.
      
      - I'm not a big fan of the explicit ring->semaphore_register list, but
        I think it's more robust to use the same mapping both when
        constructing the semaphore commands and when decoding them.
      
      - Finally add a FIXME comment about lack of broadwell support here,
        like in the earlier ipehr semaphore cmd detection function.
      
      Cc: Mika Kuoppala <mika.kuoppala@intel.com>
      Cc: Ben Widawsky <ben@bwidawsk.net>
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: NMika Kuoppala <mika.kuoppala@intel.com>
      [danvet: Actually drop the untrue claim in the commit message Chris
      pointed out.]
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      921d42ea
    • D
      drm/i915: Add FIXME for bdw semaphore detection in hancheck · a028c4b0
      Daniel Vetter 提交于
      Currently not an issue since we don't emit sempahores, but better
      not forget about those.
      
      As a little prep work extract the ipehr decoding for cleaner control
      flow. And apply a bit of polish.
      
      Cc: Ben Widawsky <ben@bwidawsk.net>
      Reviewed-by: NMika Kuoppala <mika.kuoppala@intel.com>
      Reviewed-by: NBen Widawsky <ben@bwidawsk.net>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      a028c4b0
    • C
      drm/i915: Rename GFX_TLB_INVALIDATE_ALWAYS · aa83e30d
      Chris Wilson 提交于
      The documentation calls this GFX_MODE bit "Flush TLB invalidate Mode".
      However, that is not a good name for an enable bit as it doesn't make it
      clear what is enabled. An even worse name is GFX_TLB_INVALIDATE_ALWAYS
      as enabling that bit actually prevents the TLB from being invalidated at
      every flush. This leads to great confusion when reading code and
      proposed patches. To get around this try to bake in what is enabled by
      setting the bit and call it GFX_TLB_INVALIDATE_EXPLICIT.
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Cc: "Gupta, Sourab" <sourab.gupta@intel.com>
      Acked-by: N"Gupta, Sourab" <sourab.gupta@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      aa83e30d
    • P
      drm/i915: don't get/put runtime PM at the debugfs forcewake file · c8431fda
      Paulo Zanoni 提交于
      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: NPaulo Zanoni <paulo.r.zanoni@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      c8431fda
    • P
      drm/i915: fix WARNs when reading DDI state while suspended · 882244a3
      Paulo Zanoni 提交于
      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: NPaulo Zanoni <paulo.r.zanoni@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      882244a3
    • P
      drm/i915: don't read cursor registers on powered down pipes · a23dc658
      Paulo Zanoni 提交于
      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: NPaulo Zanoni <paulo.r.zanoni@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      a23dc658
    • P
      drm/i915: get runtime PM at i915_display_info · b0e5ddf3
      Paulo Zanoni 提交于
      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: NPaulo Zanoni <paulo.r.zanoni@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      b0e5ddf3
    • P
      drm/i915: don't read pp_ctrl_reg if we're suspended · efbc20ab
      Paulo Zanoni 提交于
      ... 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: NPaulo Zanoni <paulo.r.zanoni@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      efbc20ab
    • P
      drm/i915: get runtime PM at i915_reg_read_ioctl · cf67c70f
      Paulo Zanoni 提交于
      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: NPaulo Zanoni <paulo.r.zanoni@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      cf67c70f
    • P
      drm/i915: don't schedule force_wake_timer at gen6_read · aa0b3b5b
      Paulo Zanoni 提交于
      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: NPaulo Zanoni <paulo.r.zanoni@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      aa0b3b5b
    • I
      drm/i915: vlv: reserve the GT power context only once during driver init · ae48434c
      Imre Deak 提交于
      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: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Signed-off-by: NImre Deak <imre.deak@intel.com>
      Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      ae48434c
  2. 31 3月, 2014 23 次提交