1. 17 Dec, 2018 2 commits
  2. 13 Dec, 2018 8 commits
    • Chris Wilson's avatar
      drm/i915: Fix Cherryview oops on boot · a4893349
      Chris Wilson authored
      Do not dereference the LUT blob before checking whether that blob
      exists. Or else,
      
      <1>[   13.978684] BUG: unable to handle kernel NULL pointer dereference at 0000000000000048
      <6>[   13.978718] PGD 0 P4D 0
      <4>[   13.978733] Oops: 0000 [#1] PREEMPT SMP PTI
      <4>[   13.978750] CPU: 0 PID: 282 Comm: modprobe Not tainted 4.20.0-rc5-CI-CI_DRM_5294+ #1
      <4>[   13.978773] Hardware name:  /NUC5CPYB, BIOS PYBSWCEL.86A.0058.2016.1102.1842 11/02/2016
      <4>[   13.978932] RIP: 0010:cherryview_load_csc_matrix+0x1e6/0x210 [i915]
      <4>[   13.978953] Code: 41 5c 41 5d e9 7b 83 aa e1 41 c1 e4 0d 48 83 bd 00 02 00 00 00 48 8b 85 10 02 00 00 45 89 e5 74 09 ba 01 00 00 00 31 c9 eb 9d <48> 8b 50 48 48 c1 ea 03 81 fa 00 01 00 00 75 07 31 d2 48 85 c0 75
      <4>[   13.979001] RSP: 0018:ffffc9000026f840 EFLAGS: 00010246
      <4>[   13.979018] RAX: 0000000000000000 RBX: ffff888165500000 RCX: 7885fe6200000000
      <4>[   13.979039] RDX: 0000000000000020 RSI: ffff88816553a008 RDI: ffff888165464a88
      <4>[   13.979060] RBP: ffff888165464a88 R08: 000000000ed0e429 R09: 0000000000000001
      <4>[   13.979080] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000004000
      <4>[   13.979101] R13: 0000000000004000 R14: ffff888165500000 R15: ffff888165464a88
      <4>[   13.979122] FS:  00007fb69c4f3540(0000) GS:ffff88817ba00000(0000) knlGS:0000000000000000
      <4>[   13.979146] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      <4>[   13.979163] CR2: 0000000000000048 CR3: 000000016d7fa000 CR4: 00000000001006f0
      <4>[   13.979184] Call Trace:
      <4>[   13.979302]  intel_update_crtc+0x18f/0x2b0 [i915]
      <4>[   13.979421]  intel_update_crtcs+0x49/0x60 [i915]
      <4>[   13.979538]  intel_atomic_commit_tail+0x1ea/0xd70 [i915]
      <4>[   13.979657]  ? intel_atomic_commit_ready+0x3f/0x50 [i915]
      <4>[   13.979762]  ? __i915_sw_fence_complete+0x1a0/0x250 [i915]
      <4>[   13.979884]  intel_atomic_commit+0x244/0x330 [i915]
      <4>[   13.980002]  intel_initial_commit+0xb6/0x140 [i915]
      <4>[   13.980127]  intel_modeset_init+0x7a1/0x1880 [i915]
      <4>[   13.980235]  i915_driver_load+0xcbb/0x15c0 [i915]
      <4>[   13.980257]  ? __pm_runtime_resume+0x4f/0x80
      <4>[   13.980277]  ? _raw_spin_unlock_irqrestore+0x4c/0x60
      <4>[   13.980296]  ? lockdep_hardirqs_on+0xe0/0x1b0
      <4>[   13.980401]  i915_pci_probe+0x29/0xa0 [i915]
      <4>[   13.980421]  pci_device_probe+0xa1/0x130
      <4>[   13.980440]  really_probe+0xf3/0x3e0
      <4>[   13.980456]  driver_probe_device+0x10a/0x120
      <4>[   13.980474]  __driver_attach+0xdb/0x100
      <4>[   13.980489]  ? driver_probe_device+0x120/0x120
      <4>[   13.980505]  ? driver_probe_device+0x120/0x120
      <4>[   13.980522]  bus_for_each_dev+0x74/0xc0
      <4>[   13.980539]  bus_add_driver+0x15f/0x250
      <4>[   13.980554]  ? 0xffffffffa0348000
      <4>[   13.980568]  driver_register+0x56/0xe0
      <4>[   13.980583]  ? 0xffffffffa0348000
      <4>[   13.980597]  do_one_initcall+0x58/0x2e0
      <4>[   13.980615]  ? do_init_module+0x1d/0x1ea
      <4>[   13.980631]  ? rcu_read_lock_sched_held+0x6f/0x80
      <4>[   13.980649]  ? kmem_cache_alloc_trace+0x264/0x290
      <4>[   13.980668]  do_init_module+0x56/0x1ea
      <4>[   13.980685]  load_module+0x227a/0x29c0
      <4>[   13.980715]  ? __se_sys_finit_module+0xd3/0xf0
      <4>[   13.980731]  __se_sys_finit_module+0xd3/0xf0
      <4>[   13.980756]  do_syscall_64+0x55/0x190
      <4>[   13.980772]  entry_SYSCALL_64_after_hwframe+0x49/0xbe
      <4>[   13.980789] RIP: 0033:0x7fb69c019839
      <4>[   13.980804] Code: 00 f3 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 1f f6 2c 00 f7 d8 64 89 01 48
      <4>[   13.980851] RSP: 002b:00007ffdc112e3a8 EFLAGS: 00000246 ORIG_RAX: 0000000000000139
      <4>[   13.980875] RAX: ffffffffffffffda RBX: 000055c689fe0b30 RCX: 00007fb69c019839
      <4>[   13.980895] RDX: 0000000000000000 RSI: 000055c689a05d2e RDI: 0000000000000000
      <4>[   13.980916] RBP: 000055c689a05d2e R08: 0000000000000000 R09: 0000000000000000
      <4>[   13.980936] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
      <4>[   13.980957] R13: 000055c689fe0c60 R14: 0000000000040000 R15: 000055c689fe0b30
      <4>[   13.980986] Modules linked in: i915(+) snd_hda_intel snd_hda_codec snd_hwdep snd_hda_core snd_pcm pinctrl_cherryview prime_numbers
      <4>[   13.981027] CR2: 0000000000000048
      
      Fixes: 302da0cd ("drm/i915: Use intel_ types more consistently for color management code (v2)")
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109054Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Cc: Matt Roper <matthew.d.roper@intel.com>
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Reviewed-by: default avatarMatt Roper <matthew.d.roper@intel.com>
      Signed-off-by: default avatarMatt Roper <matthew.d.roper@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20181213161241.3461-1-chris@chris-wilson.co.uk
      a4893349
    • Oscar Mateo's avatar
      drm/i915/icl: Mind the SFC units when resetting VD or VEBox engines · f513ac76
      Oscar Mateo authored
      SFC (Scaler & Format Converter) units are shared between VD and VEBoxes.
      They also happen to have separate reset bits. So, whenever we want to reset
      one or more of the media engines, we have to make sure the SFCs do not
      change owner in the process and, if this owner happens to be one of the
      engines being reset, we need to reset the SFC as well.
      
      This happens in 4 steps:
      
      1) Tell the engine that a software reset is going to happen. The engine
      will then try to force lock the SFC (if currently locked, it will
      remain so; if currently unlocked, it will ignore this and all new lock
      requests).
      
      2) Poll the ack bit to make sure the hardware has received the forced
      lock from the driver. Once this bit is set, it indicates SFC status
      (lock or unlock) will not change anymore (until we tell the engine it
      is safe to unlock again).
      
      3) Check the usage bit to see if the SFC has ended up being locked to
      the engine we want to reset. If this is the case, we have to reset
      the SFC as well.
      
      4) Unlock all the SFCs once the reset sequence is completed.
      
      Obviously, if we are resetting the whole GPU, we don't have to worry
      about all of this.
      
      BSpec: 10989
      BSpec: 10990
      BSpec: 10954
      BSpec: 10955
      BSpec: 10956
      BSpec: 19212
      Signed-off-by: default avatarTomasz Lis <tomasz.lis@intel.com>
      Signed-off-by: default avatarOscar Mateo <oscar.mateo@intel.com>
      Signed-off-by: default avatarMichel Thierry <michel.thierry@intel.com>
      Cc: Michel Thierry <michel.thierry@intel.com>
      Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: default avatarTvrtko Ursulin <tvrtko.ursulin@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20181213091522.2926-4-chris@chris-wilson.co.uk
      f513ac76
    • Oscar Mateo's avatar
      drm/i915/icl: Record the valid VDBoxes with SFC capability · 57b19d55
      Oscar Mateo authored
      In Gen11, only even numbered "logical" VDBoxes are hooked up to an SFC
      (Scaler & Format Converter) unit. We will use this information to decide
      when the SFC units need to be reset.
      
      BSpec: 20189
      Signed-off-by: default avatarTomasz Lis <tomasz.lis@intel.com>
      Signed-off-by: default avatarOscar Mateo <oscar.mateo@intel.com>
      Signed-off-by: default avatarMichel Thierry <michel.thierry@intel.com>
      Signed-off-by: default avatarDaniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
      Cc: Michel Thierry <michel.thierry@intel.com>
      Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
      Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: default avatarTvrtko Ursulin <tvrtko.ursulin@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20181213091522.2926-3-chris@chris-wilson.co.uk
      57b19d55
    • Chris Wilson's avatar
      drm/i915/selftests: Verify we can perform resets from atomic context · 921f3a60
      Chris Wilson authored
      We currently require that our per-engine reset can be called from any
      context, even hardirq, and in the future wish to perform the device
      reset without holding struct_mutex (which requires some lockless
      shenanigans that demand the lowlevel intel_reset_gpu() be able to be
      used in atomic context). Test that we meet the current requirements by
      calling i915_reset_engine() from under various atomic contexts.
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
      Reviewed-by: default avatarTvrtko Ursulin <tvrtko.ursulin@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20181213091522.2926-2-chris@chris-wilson.co.uk
      921f3a60
    • Chris Wilson's avatar
      drm/i915/selftests: Check we can recover a wedged device · 5edd56d3
      Chris Wilson authored
      After declaring a terminally wedged device, we allow ourselves to
      recover on the next GPU reset (manually triggered), or resume. Check
      that resetting a wedged device does work.
      
      v2: Add rpm (taken explicitly in the subtest in case we remove the outer
      wakeref) and early warning to i915_reset() for missed wakerefs
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
      Reviewed-by: default avatarTvrtko Ursulin <tvrtko.ursulin@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20181213091522.2926-1-chris@chris-wilson.co.uk
      5edd56d3
    • Lucas De Marchi's avatar
      drm/i915: merge gen checks to use range · f3ce44a0
      Lucas De Marchi authored
      Instead of using IS_GEN() for consecutive gen checks, let's pass the
      range to IS_GEN_RANGE(). By code inspection these were the ranges deemed
      necessary for spatch:
      
      @@
      expression e;
      @@
      (
      - IS_GEN(e, 3) || IS_GEN(e, 2)
      + IS_GEN_RANGE(e, 2, 3)
      |
      - IS_GEN(e, 3) || IS_GEN(e, 4)
      + IS_GEN_RANGE(e, 3, 4)
      |
      - IS_GEN(e, 5) || IS_GEN(e, 6)
      + IS_GEN_RANGE(e, 5, 6)
      |
      - IS_GEN(e, 6) || IS_GEN(e, 7)
      + IS_GEN_RANGE(e, 6, 7)
      |
      - IS_GEN(e, 7) || IS_GEN(e, 8)
      + IS_GEN_RANGE(e, 7, 8)
      |
      - IS_GEN(e, 8) || IS_GEN(e, 9)
      + IS_GEN_RANGE(e, 8, 9)
      |
      - IS_GEN(e, 10) || IS_GEN(e, 9)
      + IS_GEN_RANGE(e, 9, 10)
      |
      - IS_GEN(e, 9) || IS_GEN(e, 10)
      + IS_GEN_RANGE(e, 9, 10)
      )
      
      After conversion, checking we don't have any missing IS_GEN_RANGE() ||
      IS_GEN() was also done.
      Signed-off-by: default avatarLucas De Marchi <lucas.demarchi@intel.com>
      Reviewed-by: default avatarJani Nikula <jani.nikula@intel.com>
      Signed-off-by: default avatarRodrigo Vivi <rodrigo.vivi@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20181212181044.15886-3-lucas.demarchi@intel.com
      f3ce44a0
    • Lucas De Marchi's avatar
      drm/i915: replace IS_GEN<N> with IS_GEN(..., N) · cf819eff
      Lucas De Marchi authored
      Define IS_GEN() similarly to our IS_GEN_RANGE(). but use gen instead of
      gen_mask to do the comparison. Now callers can pass then gen as a parameter,
      so we don't require one macro for each gen.
      
      The following spatch was used to convert the users of these macros:
      
      @@
      expression e;
      @@
      (
      - IS_GEN2(e)
      + IS_GEN(e, 2)
      |
      - IS_GEN3(e)
      + IS_GEN(e, 3)
      |
      - IS_GEN4(e)
      + IS_GEN(e, 4)
      |
      - IS_GEN5(e)
      + IS_GEN(e, 5)
      |
      - IS_GEN6(e)
      + IS_GEN(e, 6)
      |
      - IS_GEN7(e)
      + IS_GEN(e, 7)
      |
      - IS_GEN8(e)
      + IS_GEN(e, 8)
      |
      - IS_GEN9(e)
      + IS_GEN(e, 9)
      |
      - IS_GEN10(e)
      + IS_GEN(e, 10)
      |
      - IS_GEN11(e)
      + IS_GEN(e, 11)
      )
      
      v2: use IS_GEN rather than GT_GEN and compare to info.gen rather than
          using the bitmask
      Signed-off-by: default avatarLucas De Marchi <lucas.demarchi@intel.com>
      Reviewed-by: default avatarJani Nikula <jani.nikula@intel.com>
      Signed-off-by: default avatarRodrigo Vivi <rodrigo.vivi@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20181212181044.15886-2-lucas.demarchi@intel.com
      cf819eff
    • Lucas De Marchi's avatar
      drm/i915: Rename IS_GEN to IS_GEN_RANGE · 00690008
      Lucas De Marchi authored
      RANGE makes it longer, but clearer. We are also going to add a macro to
      check an individual gen, so add the _RANGE prefix here.
      
      Diff generated with:
      
      sed 's/IS_GEN(/IS_GEN_RANGE(/g' drivers/gpu/drm/i915/{*/,}*.{c,h} -i
      
      v2: use IS_GEN rather than GT_GEN
      Signed-off-by: default avatarLucas De Marchi <lucas.demarchi@intel.com>
      Reviewed-by: default avatarTvrtko Ursulin <tvrtko.ursulin@intel.com>
      Reviewed-by: default avatarJani Nikula <jani.nikula@intel.com>
      Signed-off-by: default avatarRodrigo Vivi <rodrigo.vivi@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20181212181044.15886-1-lucas.demarchi@intel.com
      00690008
  3. 12 Dec, 2018 2 commits
  4. 11 Dec, 2018 3 commits
    • Matt Roper's avatar
      drm/i915: Switch to level-based DDB allocation algorithm (v5) · d8e87498
      Matt Roper authored
      The DDB allocation algorithm currently used by the driver grants each
      plane a very small minimum allocation of DDB blocks and then divies up
      all of the remaining blocks based on the percentage of the total data
      rate that the plane makes up.  It turns out that this proportional
      allocation approach is overly-generous with the larger planes and can
      leave very small planes wthout a big enough allocation to even hit their
      level 0 watermark requirements (especially on APL, which has a smaller
      DDB in general than other gen9 platforms).  Or there can be situations
      where the smallest planes hit a lower watermark level than they should
      have been able to hit with a more equitable division of DDB blocks, thus
      limiting the overall system sleep state that can be achieved.
      
      The bspec now describes an alternate algorithm that can be used to
      overcome these types of issues.  With the new algorithm, we calculate
      all plane watermark values for all wm levels first, then go back and
      partition a pipe's DDB space second.  The DDB allocation will calculate
      what the highest watermark level that can be achieved on *all* active
      planes, and then grant the blocks necessary to hit that level to each
      plane.  Any remaining blocks are then divided up proportionally
      according to data rate, similar to the old algorithm.
      
      There was a previous attempt to implement this algorithm a couple years
      ago in bb9d85f6 ("drm/i915/skl: New ddb allocation algorithm"), but
      some regressions were reported, the patch was reverted, and nobody
      ever got around to figuring out exactly where the bug was in that
      version.  Our watermark code has evolved significantly in the meantime,
      but we're still getting bug reports caused by the unfair proportional
      algorithm, so let's give this another shot.
      
      v2:
       - Make sure cursor allocation stays constant and fixed at the end of
         the pipe allocation.
       - Fix some watermark level iterators that weren't handling the max
         level.
      
      v3:
       - Ensure we don't leave any DDB blocks unused by using DIV_ROUND_UP+min
         to calculate the extra blocks for each plane.  (Ville)
       - Replace a while() loop with a for() loop to be more consistent with
         surrounding code.  (Ville)
       - Clean unattainable watermark levels with memset rather than directly
         clearing the member fields.  Also do the same for the transition
         watermark values if they can't be achieved.  (Ville)
       - Drop min_disp_buf_needed calculations in skl_compute_plane_wm() since
         the results are no longer needed or used.  (Ville)
       - Drop skl_latency[0] != 0 sanity check; both watermark methods already
         account for an invalid 0 latency by returning FP_16_16_MAX.  (Ville)
      
      v4:
       - Break DDB allocation loop when total_data_rate=0 rather than
         alloc_size=0.  If total_data_rate has dropped to 0, all remaining
         planes are disabled, which isn't true for alloc_size (we might just
         have not had any remaining blocks to hand out).  Plus
         total_data_rate=0 is the case we need to avoid to a prevent a
         div-by-0.  (Ville)
       - s/DIV_ROUND_UP/DIV64_U64_ROUND_UP/ to prevent 32-bit breakage (Ville)
      
      v5:
       - Don't forget to move 'start' pointer forward for UV surface when
         setting plane DDB boundaries.  (Ville)
      
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105458Signed-off-by: default avatarMatt Roper <matthew.d.roper@intel.com>
      Reviewed-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20181211173107.11068-2-matthew.d.roper@intel.com
      d8e87498
    • Matt Roper's avatar
      drm/i915: Don't use DDB allocation when choosing gen9 watermark method · 9343bb24
      Matt Roper authored
      The bspec gives an if/else chain for choosing whether to use "method 1"
      or "method 2" for calculating the watermark "Selected Result Blocks"
      value for a plane.  One of the branches of the if chain is:
      
              "Else If ('plane buffer allocation' is known and (plane buffer
              allocation / plane blocks per line) >=1)"
      
      Since our driver currently calculates DDB allocations first and the
      actual watermark values second, the plane buffer allocation is known at
      this point in our code and we include this test in our driver's logic.
      However we plan to soon move to a "watermarks first, ddb allocation
      second" sequence where we won't know the DDB allocation at this point.
      Let's drop this arm of the if/else statement (effectively considering
      the DDB allocation unknown) as an independent patch so that any
      regressions can be more accurately bisected to either the different
      watermark value (in this patch) or the new DDB allocation (in the next
      patch).
      Signed-off-by: default avatarMatt Roper <matthew.d.roper@intel.com>
      Reviewed-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20181211173107.11068-1-matthew.d.roper@intel.com
      9343bb24
    • Clint Taylor's avatar
      drm/i915/hdmi: SCDC Scrambling enable without CTS mode · ab2cb2cb
      Clint Taylor authored
      Setting the SCDC scrambling CTS mode causes HDMI Link Layer protocol tests
      HF1-12 and HF1-13 to fail.
      
      V2: Removed "Source Shall" entries to a new patch
      V3: Rebase to drm-tip
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107895
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107896Signed-off-by: default avatarClint Taylor <clinton.a.taylor@intel.com>
      Signed-off-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/1544482374-26507-1-git-send-email-clinton.a.taylor@intel.com
      ab2cb2cb
  5. 10 Dec, 2018 2 commits
  6. 07 Dec, 2018 9 commits
  7. 06 Dec, 2018 9 commits
  8. 05 Dec, 2018 2 commits
  9. 04 Dec, 2018 3 commits