Skip to content
  1. Mar 19, 2018
    • Dhinakaran Pandiyan's avatar
      drm/i915/dp: Write to SET_POWER dpcd to enable MST hub. · ad260ab3
      Dhinakaran Pandiyan authored
      
      
      If bios sets up an MST output and hardware state readout code sees this is
      an SST configuration, when disabling the encoder we end up calling
      ->post_disable_dp() hook instead of the MST version. Consequently, we write
      to the DP_SET_POWER dpcd to set it D3 state. Further along when we try
      enable the encoder in MST mode, POWER_UP_PHY transaction fails to power up
      the MST hub. This results in continuous link training failures which keep
      the system busy delaying boot. We could identify bios MST boot discrepancy
      and handle it accordingly but a simple way to solve this is to write to the
      DP_SET_POWER dpcd for MST too.
      
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105470
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Cc: Jani Nikula <jani.nikula@intel.com>
      Reviewed-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Reported-by: default avatarLaura Abbott <labbott@redhat.com>
      Cc: stable@vger.kernel.org
      Fixes: 5ea2355a
      
       ("drm/i915/mst: Use MST sideband message transactions for dpms control")
      Tested-by: default avatarLaura Abbott <labbott@redhat.com>
      Signed-off-by: default avatarDhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
      Signed-off-by: default avatarJani Nikula <jani.nikula@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20180314054825.1718-1-dhinakaran.pandiyan@intel.com
      ad260ab3
  2. Mar 17, 2018
    • Ville Syrjälä's avatar
      drm/i915: Kill the remaining CHV HBR2 leftovers · 3b358cda
      Ville Syrjälä authored
      
      
      AFAIK CHV was supposed to have HBR2 originally, but in the end the feature
      was dropped. We still have some code leftovers from those early days.
      Eliminate them.
      
      The extra bit for the training pattern seems to be dead in the hardware.
      I can set it (in fact I can set almost any reserved bit in the
      registers) but it doesn't seem to interfere with the operation of the
      hardware. Either that or I'm very lucky that my displays complete link
      training with the incorrect pattern being sent out.
      
      Signed-off-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20180302095656.19662-1-ville.syrjala@linux.intel.com
      Reviewed-by: default avatarDhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
      3b358cda
  3. Mar 16, 2018
  4. Mar 15, 2018
  5. Mar 14, 2018
    • Chris Wilson's avatar
      drm/i915: Check rq->timeline before deference · ab268151
      Chris Wilson authored
      
      
      Not only is the context suspect to disappearing, but so is it's
      timeline. Under a lockless inspection of the requests for
      debugging from intel_engine_dump(), the context may already have been
      freed and we have to check before chasing the dangling pointer.
      
      [28033.681755] Modules linked in: vgem snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic x86_pkg_temp_thermal intel_powerclamp coretemp snd_hda_intel crct10dif_pclmul crc32_pclmul snd_hda_codec snd_hwdep snd_hda_core ghash_clmulni_intel snd_pcm mei_me mei i915 r8169 mii prime_numbers i2c_hid
      [28033.681796] CPU: 3 PID: 3058 Comm: gem_exec_schedu Tainted: G     U           4.16.0-rc5+ #9
      [28033.681804] Hardware name: Acer Aspire E5-575G/Ironman_SK  , BIOS V1.12 08/02/2016
      [28033.681834] RIP: 0010:print_request+0x2b/0xb0 [i915]
      [28033.681840] RSP: 0018:ffffc90004afbc18 EFLAGS: 00010202
      [28033.681847] RAX: 6b6b6b6b6b6b6b6b RBX: ffff8801921b5a40 RCX: 0000000000000006
      [28033.681854] RDX: ffffc90004afbc60 RSI: ffff8801921b5a40 RDI: 0000000000000004
      [28033.681861] RBP: ffffc90004afbd80 R08: 0000000000000000 R09: 0000000000000001
      [28033.681868] R10: ffffc90004afbbd0 R11: ffffc90004afbc73 R12: ffffc90004afbc60
      [28033.681875] R13: ffffc90004afbd80 R14: ffff8801d40ec670 R15: ffff8801921b5a40
      [28033.681883] FS:  00007fbba5f6c8c0(0000) GS:ffff8801e8400000(0000) knlGS:0000000000000000
      [28033.681891] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [28033.681897] CR2: 00007fbba5f8f000 CR3: 00000001b2efa002 CR4: 00000000003606e0
      [28033.681904] Call Trace:
      [28033.681932]  intel_engine_print_registers+0x6a7/0x930 [i915]
      [28033.681962]  intel_engine_dump+0x30d/0x740 [i915]
      [28033.681971]  ? seq_printf+0x3a/0x50
      [28033.681995]  i915_engine_info+0xb8/0xe0 [i915]
      [28033.682003]  ? drm_get_color_range_name+0x20/0x20
      [28033.682010]  seq_read+0xe1/0x440
      [28033.682018]  full_proxy_read+0x51/0x80
      [28033.682025]  __vfs_read+0x21/0x130
      [28033.682031]  ? do_sys_open+0x134/0x220
      [28033.682037]  ? kmem_cache_free+0x177/0x2b0
      [28033.682043]  vfs_read+0xa1/0x150
      [28033.682049]  SyS_read+0x40/0xa0
      [28033.682055]  do_syscall_64+0x6b/0x1b0
      [28033.682063]  entry_SYSCALL_64_after_hwframe+0x42/0xb7
      [28033.682069] RIP: 0033:0x7fbba4655d11
      [28033.682074] RSP: 002b:00007ffd8c49da58 EFLAGS: 00000246 ORIG_RAX: 0000000000000000
      [28033.682082] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fbba4655d11
      [28033.682089] RDX: 000000000000003f RSI: 00005647bfbfc260 RDI: 0000000000000006
      [28033.682096] RBP: 000000000000003f R08: 00000000ffffffff R09: 0000000000000000
      [28033.682104] R10: 0000000000000000 R11: 0000000000000246 R12: 00005647bfbfc260
      [28033.682111] R13: 0000000000000006 R14: 0000000000000000 R15: 00005647bfbfc260
      [28033.682119] Code: 41 55 41 54 49 89 d4 55 53 48 89 fd 48 8b 86 c8 00 00 00 48 8b 3d d6 1e 14 e2 48 89 f3 48 2b be a8 02 00 00 48 8b 80 b0 00 00 00 <4c> 8b 68 18 e8 bc 80 02 e1 8b 8b 70 02 00 00 8b b3 28 02 00 00
      [28033.682206] RIP: print_request+0x2b/0xb0 [i915] RSP: ffffc90004afbc18
      
      Reported-by: default avatarMika Kuoppala <mika.kuoppala@linux.intel.com>
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
      Reviewed-by: default avatarMika Kuoppala <mika.kuoppala@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20180314101630.8933-1-chris@chris-wilson.co.uk
      ab268151
    • Jackie Li's avatar
      drm/i915/guc: Check the locking status of GuC WOPCM registers · f08e2035
      Jackie Li authored
      
      
      GuC WOPCM registers are write-once registers. Current driver code accesses
      these registers without checking the accessibility to these registers which
      will lead to unpredictable driver behaviors if these registers were touch
      by other components (such as faulty BIOS code).
      
      This patch moves the GuC WOPCM registers updating code into intel_wopcm.c
      and adds check before and after the update to GuC WOPCM registers so that
      we can make sure the driver is in a known state after writing to these
      write-once registers.
      
      v6:
       - Made sure module reloading won't bug the kernel while doing
         locking status checking
      
      v7:
       - Fixed patch format issues
      
      v8:
       - Fixed coding style issue on register lock bit macro definition (Sagar)
      
      v9:
       - Avoided to use redundant !! to cast uint to bool (Chris)
       - Return error code instead of GEM_BUG_ON for locked with invalid register
         values case (Sagar)
       - Updated guc_wopcm_hw_init to use guc_wopcm as first parameter (Michal)
       - Added code to set and validate the HuC_LOADING_AGENT_GUC bit in GuC
         WOPCM offset register based on the presence of HuC firmware (Michal)
       - Use bit fields instead of macros for GuC WOPCM flags (Michal)
      
      v10:
       - Refined variable names, removed redundant comments (Joonas)
       - Introduced lockable_reg to handle the write once register write and
         propagate the write error to caller (Joonas)
       - Used lockable_reg abstraction to avoid locking bit check on generic
         i915_reg_t (Michal)
       - Added log message for error paths (Michal)
       - Removed hw_updated flag and only relies on real hardware status
      
      v11:
       - Replaced lockable_reg with simplified function (Michal)
       - Used new macros for locking bits of WOPCM size/offset registers instead
         of using BIT(0) directly (Michal)
       - use intel_wopcm_init_hw() called from intel_gem_init_hw() to do GuC
         WOPCM register setup instead of calling from intel_uc_init_hw() (Michal)
      
      v12:
       - Updated function kernel-doc to align with code changes (Michal)
       - Updated code to use wopcm pointer directly (Michal)
      
      v13:
       - Updated the ordering of s-o-b/cc/r-b tags (Sagar)
      
      BSpec: 10875, 10833
      
      Signed-off-by: default avatarJackie Li <yaodong.li@intel.com>
      Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> (v11)
      Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> (v12)
      Reviewed-by: default avatarJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Signed-off-by: default avatarJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/1520987574-19351-5-git-send-email-yaodong.li@intel.com
      f08e2035
    • Jackie Li's avatar
      drm/i915: Add HuC firmware size related restriction for Gen9 and CNL A0 · 96c83d35
      Jackie Li authored
      
      
      On CNL A0 and Gen9, there's a hardware restriction that requires the
      available GuC WOPCM size to be larger than or equal to HuC firmware size.
      
      This patch adds new verification code to ensure the available GuC WOPCM
      size to be larger than or equal to HuC firmware size on both Gen9 and CNL
      A0.
      
      v6:
       - Extended HuC FW size check against GuC WOPCM size to all
         Gen9 and CNL A0 platforms
      
      v7:
       - Fixed patch format issues
      
      v8:
       - Renamed variables and functions to avoid ambiguity (Joonas)
       - Updated commit message and comments to be more comprehensive (Sagar)
      
      v9:
       - Moved code that is not related to restriction check into a separate
         patch and updated the commit message accordingly (Sagar/Michal)
       - Avoided to call uc_get_fw_size for better layer isolation (Michal)
      
      v10:
       - Shorten function names and reorganized size_check code to have clear
         isolation (Joonas)
       - Removed unnecessary comments (Joonas)
      
      v11:
       - Fixed logic error in size check (Michal)
      
      v12:
       - Add space between "HuC FW" and "(%uKiB)" in error message (Michal)
      
      v13:
       - Updated the ordering of s-o-b/cc/r-b tags (Sagar)
      
      BSpec: 10875
      
      Signed-off-by: default avatarJackie Li <yaodong.li@intel.com>
      Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
      Cc: Sagar Arun Kamble <sagar.a.kamble@intel.com>
      Cc: John Spotswood <john.a.spotswood@intel.com>
      Cc: Jeff McGee <jeff.mcgee@intel.com>
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Reviewed-by: Sagar Arun Kamble <sagar.a.kamble@intel.com> (v8)
      Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> (v11)
      Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> (v12)
      Reviewed-by: default avatarJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Signed-off-by: default avatarJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/1520987574-19351-4-git-send-email-yaodong.li@intel.com
      96c83d35
    • Jackie Li's avatar
      drm/i915: Add support to return CNL specific reserved WOPCM size · 5cbc1e2f
      Jackie Li authored
      
      
      CNL has its specific reserved GuC WOPCM size for RC6 and other hardware
      contexts.
      
      This patch updates the code to return CNL specific reserved GuC WOPCM size
      for RC6 and other hardware contexts so that the GuC WOPCM size can be
      calculated correctly for CNL.
      
      v9:
       - Created a new patch for these changes originally made in v8 4/6 patch of
         this series (Sagar/Michal)
      
      v10:
       - Used if-else ladder to the returning of context sizes (Joonas)
      
      v11:
       - Removed GUC_ prefix from context size macro (Michal)
      
      v13:
        - Updated the ordering of s-o-b/cc/r-b tags (Sagar)
      
      Bspec: 12690
      
      Signed-off-by: default avatarJackie Li <yaodong.li@intel.com>
      Cc: Sagar Arun Kamble <sagar.a.kamble@intel.com>
      Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> (v9)
      Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> (v11)
      Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> (v12)
      Reviewed-by: default avatarJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Signed-off-by: default avatarJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/1520987574-19351-3-git-send-email-yaodong.li@intel.com
      5cbc1e2f
    • Jackie Li's avatar
      drm/i915: Implement dynamic GuC WOPCM offset and size calculation · 6b0478fb
      Jackie Li authored
      
      
      Hardware may have specific restrictions on GuC WOPCM offset and size. On
      Gen9, the value of the GuC WOPCM size register needs to be larger than the
      value of GuC WOPCM offset register + a Gen9 specific offset (144KB) for
      reserved GuC WOPCM. Fail to enforce such a restriction on GuC WOPCM size
      will lead to GuC firmware execution failures. On the other hand, with
      current static GuC WOPCM offset and size values (512KB for both offset and
      size), the GuC WOPCM size verification will fail on Gen9 even if it can be
      fixed by lowering the GuC WOPCM offset by calculating its value based on
      HuC firmware size (which is likely less than 200KB on Gen9), so that we can
      have a GuC WOPCM size value which is large enough to pass the GuC WOPCM
      size check.
      
      This patch updates the reserved GuC WOPCM size for RC6 context on Gen9 to
      24KB to strictly align with the Gen9 GuC WOPCM layout. It also adds support
      to verify the GuC WOPCM size aganist the Gen9 hardware restrictions. To
      meet all above requirements, let's provide dynamic partitioning of the
      WOPCM that will be based on platform specific HuC/GuC firmware sizes.
      
      v2:
       - Removed intel_wopcm_init (Ville/Sagar/Joonas)
       - Renamed and Moved the intel_wopcm_partition into intel_guc (Sagar)
       - Removed unnecessary function calls (Joonas)
       - Init GuC WOPCM partition as soon as firmware fetching is completed
      
      v3:
       - Fixed indentation issues (Chris)
       - Removed layering violation code (Chris/Michal)
       - Created separat files for GuC wopcm code  (Michal)
       - Used inline function to avoid code duplication (Michal)
      
      v4:
       - Preset the GuC WOPCM top during early GuC init (Chris)
       - Fail intel_uc_init_hw() as soon as GuC WOPCM partitioning failed
      
      v5:
       - Moved GuC DMA WOPCM register updating code into intel_wopcm.c
       - Took care of the locking status before writing to GuC DMA
         Write-Once registers. (Joonas)
      
      v6:
       - Made sure the GuC WOPCM size to be multiple of 4K (4K aligned)
      
      v8:
       - Updated comments and fixed naming issues (Sagar/Joonas)
       - Updated commit message to include more description about the hardware
         restriction on GuC WOPCM size (Sagar)
      
      v9:
       - Minor changes variable names and code comments (Sagar)
       - Added detailed GuC WOPCM layout drawing (Sagar/Michal)
       - Refined macro definitions to be reader friendly (Michal)
       - Removed redundent check to valid flag (Michal)
       - Unified first parameter for exported GuC WOPCM functions (Michal)
       - Refined the name and parameter list of hardware restriction checking
         functions (Michal)
      
      v10:
       - Used shorter function name for internal functions (Joonas)
       - Moved init-ealry function into c file (Joonas)
       - Consolidated and removed redundant size checks (Joonas/Michal)
       - Removed unnecessary unlikely() from code which is only called once
         during boot (Joonas)
       - More fixes to kernel-doc format and content (Michal)
       - Avoided the use of PAGE_MASK for 4K pages (Michal)
       - Added error log messages to error paths (Michal)
      
      v11:
       - Replaced intel_guc_wopcm with more generic intel_wopcm and attached
         intel_wopcm to drm_i915_private instead intel_guc (Michal)
       - dynamic calculation of GuC non-wopcm memory start (a.k.a WOPCM Top
         offset from GuC WOPCM base) (Michal)
       - Moved WOPCM marco definitions into .c source file (Michal)
       - Exported WOPCM layout diagram as kernel-doc (Michal)
      
      v12:
       - Updated naming, function kernel-doc to align with new changes (Michal)
      
      v13:
       - Updated the ordering of s-o-b/cc/r-b tags (Sagar)
       - Corrected one tense error in comment (Sagar)
       - Corrected typos and removed spurious comments (Joonas)
      
      Bspec: 12690
      
      Signed-off-by: default avatarJackie Li <yaodong.li@intel.com>
      Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
      Cc: Sagar Arun Kamble <sagar.a.kamble@intel.com>
      Cc: Sujaritha Sundaresan <sujaritha.sundaresan@intel.com>
      Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
      Cc: John Spotswood <john.a.spotswood@intel.com>
      Cc: Oscar Mateo <oscar.mateo@intel.com>
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Reviewed-by: Sagar Arun Kamble <sagar.a.kamble@intel.com> (v8)
      Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> (v9)
      Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> (v11)
      Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> (v12)
      Reviewed-by: default avatarJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Signed-off-by: default avatarJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/1520987574-19351-2-git-send-email-yaodong.li@intel.com
      6b0478fb
    • Jackie Li's avatar
      drm/i915/guc: Rename guc_ggtt_offset to intel_guc_ggtt_offset · 3c009e3c
      Jackie Li authored
      
      
      GuC related exported functions should start with "intel_guc_" prefix and
      pass intel_guc as the first parameter since its GuC related. Current
      guc_ggtt_offset() failed to follow this code convention and this is a
      problem for future patches that needs to access intel_guc data to verify
      the GGTT offset against the GuC WOPCM top.
      
      This patch renames the guc_ggtt_offset to intel_guc_ggtt_offset and updates
      the related code to pass intel_guc pointer to this function call, so that
      we can have a unified coding style for GuC code and also enable the future
      patches to get GuC related data from intel_guc to do the offset
      verification. Meanwhile, this patch also moves the GUC_GGTT_TOP from
      intel_guc_regs.h to intel_guc.h since it is not GuC register related
      definition.
      
      v8:
       - Fixed coding style issues and moved GUC_GGTT_TOP to intel_guc.h (Sagar)
       - Updated commit message to explain to reason and motivation to add
         intel_guc as the first parameter of intel_guc_ggtt_offset (Chris)
      
      v9:
       - Fixed code alignment issue due to line break (Chris)
      
      v10:
       - Removed unnecessary comments, redundant code and avoided reuse variable
         to avoid potential issues (Joonas)
      
      v13:
       - Updated the ordering of s-o-b/cc/r-b tags (Sagar)
      
      Signed-off-by: default avatarJackie Li <yaodong.li@intel.com>
      Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
      Cc: Sagar Arun Kamble <sagar.a.kamble@intel.com>
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Reviewed-by: Sagar Arun Kamble <sagar.a.kamble@intel.com> (v8)
      Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> (v9)
      Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> (v11)
      Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> (v12)
      Reviewed-by: default avatarJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Signed-off-by: default avatarJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/1520987574-19351-1-git-send-email-yaodong.li@intel.com
      3c009e3c
    • Dhinakaran Pandiyan's avatar
      drm/i915/psr: Comment to clarify SRD_DEBUG is called PSR_MASK SKL+ · 62801bf6
      Dhinakaran Pandiyan authored
      
      
      What was called SRD_DEBUG(0x6F860) on HSW and BDW was renamed to PSR_MASK
      SKL onwards, add a note next to the macro definition.
      There is also a different PSR_DEBUG on SKL+ to add to the confusion.
      
      Signed-off-by: default avatarDhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
      Acked-by: default avatarRodrigo Vivi <rodrigo.vivi@intel.com>
      Signed-off-by: default avatarRodrigo Vivi <rodrigo.vivi@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20180313040954.6289-1-dhinakaran.pandiyan@intel.com
      62801bf6
    • Chris Wilson's avatar
      drm/i915: Show GEM_TRACE when detecting a failed GPU idle · 629820fc
      Chris Wilson authored
      If we timeout waiting for the GPU to idle, something went seriously
      wrong. We currently dump the engine state, but we can also dump the
      ftrace buffer showing our last operations (when available).
      
      In passing, note that since commit 559e040f
      
       ("drm/i915: Show the GPU
      state when declaring wedged", we now show the engine state twice, once
      in detecting the failed idle and then again on declaring wedged.
      
      v2: ftrace_dump() takes a parameter specifying whether to dump all cpu
      buffers or the local cpu's.
      
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
      Reviewed-by: default avatarJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20180309101114.1138-1-chris@chris-wilson.co.uk
      629820fc
    • Rodrigo Vivi's avatar
      drm/i915: Move CUR SURFLIVE definition to a better place. · a8ada068
      Rodrigo Vivi authored
      
      
      No functional change. But let's keep definitions clean
      and cursor related register definitions together.
      
      v2: Fix caps x no caps on same reg. Change name to match
          original reg name. (by Ville).
          Also fix name on code s/surlive/surflive and on subject
          s/cur_surlife/cur surflive/.
      
      Suggested-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Signed-off-by: default avatarRodrigo Vivi <rodrigo.vivi@intel.com>
      Reviewed-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20180312210528.7905-1-rodrigo.vivi@intel.com
      a8ada068
    • Dhinakaran Pandiyan's avatar
      drm/i915/psr: Remove PSR active flag from debugfs · be74229b
      Dhinakaran Pandiyan authored
      
      
      The flag becomes misleading with flips and cursor moves not modifying it's
      state as HW takes care of exiting PSR (when HW tracking is enabled)
      
      Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
      Signed-off-by: default avatarDhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
      Acked-by: default avatarRodrigo Vivi <rodrigo.vivi@intel.com>
      Signed-off-by: default avatarRodrigo Vivi <rodrigo.vivi@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20180313044211.27105-1-dhinakaran.pandiyan@intel.com
      be74229b
    • Rodrigo Vivi's avatar
      drm/i915/psr: Use more PSR HW tracking. · 5baf63cc
      Rodrigo Vivi authored
      
      
      So far we are using frontbuffer tracking for everything
      and ignoring that PSR has a HW capable HW tracking for many
      modern usages of GPU on Core platforms and newer Atom ones.
      
      One reason for that is that we were trying to keep same
      infrastructure in place for VLV/CHV than the rest of platforms.
      But also because when this infrastructure was created
      the front-buffer-tracking origin wasn't that good and stable
      how it is today after Paulo reworked it to attend FBC cases.
      
      However this PSR implementation without HW tracking died
      on gen8LP. And newer platforms are starting to demand more HW
      tracking specially with PSR2 cases in mind.
      
      By disabling and re-enabling PSR totally every time we believe
      someone is going to change the front buffer content we don't
      allow PSR HW tracking to do this job and specially compromising
      the whole idea of PSR2 case where the HW tracking detect only
      the damaged area and do a partial screen update.
      
      So, from now on, on the platforms that has hw_tracking let's
      rely more on HW tracking.
      
      This also is the case in used by other drivers and more validated
      by SV teams. So I hope that this will lead us to less misterious
      bugs.
      
      v2: Only do this for platform that actually has hw tracking.
      
      v3 from DK
      Do this only for flips, small gradual changes are better.
      
      Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
      Cc: Jim Bride <jim.bride@linux.intel.com>
      Cc: Vathsala Nagaraju <vathsala.nagaraju@intel.com>
      Signed-off-by: default avatarRodrigo Vivi <rodrigo.vivi@intel.com>
      Signed-off-by: default avatarDhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
      Reviewed-by: default avatarJose Roberto de Souza <jose.souza@intel.com>
      Signed-off-by: default avatarRodrigo Vivi <rodrigo.vivi@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20180307033420.3086-3-dhinakaran.pandiyan@intel.com
      5baf63cc
    • Dhinakaran Pandiyan's avatar
      drm/i915/frontbuffer: HW tracking for cursor moves to fix PSR lags. · a694e226
      Dhinakaran Pandiyan authored
      
      
      DRM_IOCTL_MODE_CURSOR results in frontbuffer flush before the cursor
      plane MMIOs are written to. But this flush should not be necessary for
      PSR as hardware tracking triggers PSR exit when MMIOs are written. As
      for FBC, the spec says "Flips or changes to plane size and panning" cause
      FBC to be nuked. Use origin == ORIGIN_FLIP so that features can ignore
      cursor updates in their frontbuffer_flush implementations.
      
       /sys/kernel/debug/dri/0/i915_fbc_status shows
      "Compressing: yes" when I move the cursor around.
      
      v3: Use ORIGIN_FLIP now that pin_to_display does not flush frontbuffer.
      v2: Update comment in i915_gem_object_pin_to_display_plane. (Chris)
      
      Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
      Signed-off-by: default avatarDhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
      Reviewed-by: default avatarRodrigo Vivi <rodrigo.vivi@intel.com>
      Signed-off-by: default avatarRodrigo Vivi <rodrigo.vivi@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20180307033420.3086-2-dhinakaran.pandiyan@intel.com
      a694e226
    • Dhinakaran Pandiyan's avatar
      drm/i915/frontbuffer: Pull frontbuffer_flush out of gem_obj_pin_to_display · 07bcd99b
      Dhinakaran Pandiyan authored
      
      
      i915_gem_obj_pin_to_display() calls frontbuffer_flush with origin set to
      DIRTYFB. The callers however are at a vantage point to decide if hardware
      frontbuffer tracking can do the flush for us. For example, legacy cursor
      updates, like flips, write to MMIO registers, which then triggers PSR flush
      by the hardware. Moving frontbuffer_flush out will enable us to skip a
      software initiated flush by setting origin to FLIP. Thanks to Chris for the
      idea.
      
      v2:
      Rebased due to Ville adding intel_plane_pin_fb().
      Minor code reordering as fb_obj_flush doesn't need struct_mutex (Chris)
      
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
      Signed-off-by: default avatarDhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
      Reviewed-by: default avatarRodrigo Vivi <rodrigo.vivi@intel.com>
      Signed-off-by: default avatarRodrigo Vivi <rodrigo.vivi@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20180307033420.3086-1-dhinakaran.pandiyan@intel.com
      07bcd99b
  6. Mar 13, 2018
    • Chris Wilson's avatar
      drm/i915: Use sseu size for determining eu_regs[] · c7fb3c6c
      Chris Wilson authored
      eu_regs[] is written 2*max_slices times (like s_reg[]) but oddly read
      2*max_slices + max_subslices/2 times. Allocate the array large enough
      for the writes to avoid overwriting our stack and worry about the logic
      later.
      
      Fixes: 7aa0b14e
      
       ("drm/i915: Remove variable length arrays from sseu debugfs printers")
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105479
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
      Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
      Cc: Matthew Auld <matthew.auld@intel.com>
      Reviewed-by: default avatarLionel Landwerlin <lionel.g.landwerlin@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20180313113149.1094-1-chris@chris-wilson.co.uk
      c7fb3c6c
    • Chris Wilson's avatar
      drm/i915: Warn against variable length arrays · c5c2b118
      Chris Wilson authored
      
      
      VLA are strongly discouraged in the kernel due to ambiguity they impose
      on the limited stack space and security concerns over manipulating the
      stack frame. Add -Wvla to our compiler flags so that CI rejects them.
      
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Cc: Jani Nikula <jani.nikula@intel.com>
      Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Acked-by: default avatarJani Nikula <jani.nikula@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20180313004055.25411-2-chris@chris-wilson.co.uk
      c5c2b118
    • Chris Wilson's avatar
      drm/i915: Remove variable length arrays from sseu debugfs printers · 7aa0b14e
      Chris Wilson authored
      
      
      In order to enable -Wvla to prevent new variable length arrays being
      used in i915.ko, we first must remove the existing VLA. Inside
      i915_print_sseu_info(), VLA are used as the actual size of the sseu
      depends on platform. Replace the VLA with the maximum required.
      
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
      Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
      Cc: Matthew Auld <matthew.auld@intel.com>
      Reviewed-by: default avatarTvrtko Ursulin <tvrtko.ursulin@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20180313004055.25411-1-chris@chris-wilson.co.uk
      7aa0b14e
    • Michal Wajdeczko's avatar
      drm/i915/uc: Sanitize uC together with GEM · c37d5728
      Michal Wajdeczko authored
      
      
      Instead of dancing around uC on reset/suspend/resume scenarios,
      explicitly sanitize uC when we sanitize GEM to force uC reload
      and start from known beginning.
      
      v2: don't forget about reset path (Daniele)
          sanitize uc before gem initiated full reset (Daniele)
      v3: drop redundant disable_communication in init_hw (Daniele)
      
      Signed-off-by: default avatarMichal Wajdeczko <michal.wajdeczko@intel.com>
      Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
      Cc: Sagar Arun Kamble <sagar.a.kamble@intel.com>
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Cc: Michel Thierry <michel.thierry@intel.com>
      Reviewed-by: default avatarDaniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Link: https://patchwork.freedesktop.org/patch/msgid/20180312130308.22952-3-michal.wajdeczko@intel.com
      c37d5728
    • Michal Wajdeczko's avatar
      drm/i915/uc: Sanitize uC options early · 3c33fc7c
      Michal Wajdeczko authored
      
      
      We are sanitizing uC related modparams together with other driver
      modparams in intel_sanitize_options called from i915_driver_init_hw,
      but this is too late for us as we will want to use USES_GUC/USES_HUC
      macros at earlier stage. Since our sanitizing does not require any
      MMIO access, we can do it in intel_uc_init_early right after we resolve
      firmware names.
      
      Signed-off-by: default avatarMichal Wajdeczko <michal.wajdeczko@intel.com>
      Cc: Sagar Arun Kamble <sagar.a.kamble@intel.com>
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Link: https://patchwork.freedesktop.org/patch/msgid/20180312130308.22952-2-michal.wajdeczko@intel.com
      3c33fc7c
    • Chris Wilson's avatar
      drm/i915: Remove the impedance mismatch around intel_engine_enable_signaling · 6f9ec414
      Chris Wilson authored
      
      
      There is some redundancy between dma_fence->ops->enable_signaling (via
      i915_fence_enable_signaling) and our backend,
      intel_engine_enable_signaling() in that both levels recheck the fence
      status multiple times. If we convert intel_engine_enable_signaling() to
      return the information desired by dma_fence->ops->enable_signaling, we
      can reduce i915_fence_enable_signaling to a simple stub and avoid
      trying to reinterpret the same information.
      
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
      Cc: Mika Kuoppala <mika.kuoppala@intel.com>
      Cc: Michal Winiarski <michal.winiarski@intel.com>
      Reviewed-by: default avatarTvrtko Ursulin <tvrtko.ursulin@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20180308140732.25090-1-chris@chris-wilson.co.uk
      6f9ec414
    • Rodrigo Vivi's avatar
      drm/i915/psr: Display WA 0884 applied broadly for more HW tracking. · caa1fd66
      Rodrigo Vivi authored
      
      
      WA 0884:bxt:all,cnl:*:A - "When FBC is enabled with eDP PSR,
      the CPU host modify writes may not get updated on the Display
      as expected.
      WA: Write 0x00000000 to CUR_SURFLIVE_A with every CPU
      host modify write to trigger PSR exit."
      
      We can also find on spec other cases where they describe
      bogus writes to cursor registers to force PSR exit with
      HW tracking. And it was confirmed by HW engineers that
      this Wa can be safely applied for any frontbuffer activity.
      
      So let's use this more and more here instead of forcibly
      disable and re-enable PSR everytime that we have a simple
      reliable flush case.
      
      Other commits improve the fbcon/fbdev use a lot, but this
      approach is the only when where we can get a fully reliable
      console with no slowness or missed frames and PSR still
      enabled and active.
      
      v2: - Rebase on drm-tip
          - (DK) Add a comment to explain that WA
          tells about writing 0 to CUR_SURFLIVE_A but we write to
          CUR_SURFLIVE(pipe).
      v3: Wa doesn't work on PSR2.
      
      Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
      Signed-off-by: default avatarRodrigo Vivi <rodrigo.vivi@intel.com>
      Reviewed-by: default avatarDhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20180309005218.26772-1-rodrigo.vivi@intel.com
      caa1fd66
  7. Mar 10, 2018