1. 21 Nov, 2018 4 commits
  2. 20 Nov, 2018 1 commit
  3. 19 Nov, 2018 1 commit
    • Ville Syrjälä's avatar
      drm/i915: Disable LP3 watermarks on all SNB machines · 21556350
      Ville Syrjälä authored
      I have a Thinkpad X220 Tablet in my hands that is losing vblank
      interrupts whenever LP3 watermarks are used.
      If I nudge the latency value written to the WM3 register just
      by one in either direction the problem disappears. That to me
      suggests that the punit will not enter the corrsponding
      powersave mode (MPLL shutdown IIRC) unless the latency value
      in the register matches exactly what we read from SSKPD. Ie.
      it's not really a latency value but rather just a cookie
      by which the punit can identify the desired power saving state.
      On HSW/BDW this was changed such that we actually just write
      the WM level number into those bits, which makes much more
      sense given the observed behaviour.
      We could try to handle this by disallowing LP3 watermarks
      only when vblank interrupts are enabled but we'd first have
      to prove that only vblank interrupts are affected, which
      seems unlikely. Also we can't grab the wm mutex from the
      vblank enable/disable hooks because those are called with
      various spinlocks held. Thus we'd have to redesigne the
      watermark locking. So to play it safe and keep the code
      simple we simply disable LP3 watermarks on all SNB machines.
      To do that we simply zero out the latency values for
      watermark level 3, and we adjust the watermark computation
      to check for that. The behaviour now matches that of the
      g4x/vlv/skl wm code in the presence of a zeroed latency
      v2: s/USHRT_MAX/U32_MAX/ for consistency with the types (Chris)
      Cc: stable@vger.kernel.org
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Acked-by: Chris Wilson's avatarChris Wilson <chris@chris-wilson.co.uk>
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101269
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103713Signed-off-by: Ville Syrjälä's avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20181114173440.6730-1-ville.syrjala@linux.intel.com
      (cherry picked from commit 03981c6e)
      Signed-off-by: Joonas Lahtinen's avatarJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
  4. 15 Nov, 2018 3 commits
  5. 14 Nov, 2018 2 commits
  6. 12 Nov, 2018 8 commits
    • Ville Syrjälä's avatar
      drm/i915: Fix hpd handling for pins with two encoders · 44a7276b
      Ville Syrjälä authored
      In my haste to remove irq_port[] I accidentally changed the
      way we deal with hpd pins that are shared by multiple encoders
      (DP and HDMI for pre-DDI platforms). Previously we would only
      handle such pins via ->hpd_pulse(), but now we queue up the
      hotplug work for the HDMI encoder directly. Worse yet, we now
      count each hpd twice and this increment the hpd storm count
      twice as fast. This can lead to spurious storms being detected.
      Go back to the old way of doing things, ie. delegate to
      ->hpd_pulse() for any pin which has an encoder with that hook
      implemented. I don't really like the idea of adding irq_port[]
      back so let's loop through the encoders first to check if we
      have an encoder with ->hpd_pulse() for the pin, and then go
      through all the pins and decided on the correct course of action
      based on the earlier findings.
      I have occasionally toyed with the idea of unifying the pre-DDI
      HDMI and DP encoders into a single encoder as well. Besides the
      hotplug processing it would have the other benefit of preventing
      userspace from trying to enable both encoders at the same time.
      That is simply illegal as they share the same clock/data pins.
      We have some testcases that will attempt that and thus fail on
      many older machines. But for now let's stick to fixing just the
      hotplug code.
      Cc: stable@vger.kernel.org # 4.19+
      Cc: Lyude Paul <lyude@redhat.com>
      Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
      Fixes: b6ca3eee ("drm/i915: Nuke dev_priv->irq_port[]")
      Signed-off-by: Ville Syrjälä's avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20181108200424.28371-1-ville.syrjala@linux.intel.comReviewed-by: Lyude Paul's avatarLyude Paul <lyude@redhat.com>
      (cherry picked from commit 5a3aeca9)
      Signed-off-by: Joonas Lahtinen's avatarJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
    • Chris Wilson's avatar
      drm/i915/execlists: Force write serialisation into context image vs execution · 0a823e8f
      Chris Wilson authored
      Ensure that the writes into the context image are completed prior to the
      register mmio to trigger execution. Although previously we were assured
      by the SDM that all writes are flushed before an uncached memory
      transaction (our mmio write to submit the context to HW for execution),
      we have empirical evidence to believe that this is not actually the
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108656
      References: https://bugs.freedesktop.org/show_bug.cgi?id=108315
      References: https://bugs.freedesktop.org/show_bug.cgi?id=106887Signed-off-by: Chris Wilson's avatarChris Wilson <chris@chris-wilson.co.uk>
      Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
      Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
      Acked-by: default avatarMika Kuoppala <mika.kuoppala@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20181108081740.25615-1-chris@chris-wilson.co.uk
      Cc: stable@vger.kernel.org
      (cherry picked from commit 987abd5c)
      Signed-off-by: Joonas Lahtinen's avatarJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
    • Imre Deak's avatar
      drm/i915/icl: Fix power well 2 wrt. DC-off toggling order · c4f22407
      Imre Deak authored
      To enable DC5/6 power well 2 has to be disabled as for previous
      platforms, so fix things up.
      Bspec: 4234
      Fixes: 67ca07e7 ("drm/i915/icl: Add power well support")
      Cc: Animesh Manna <animesh.manna@intel.com>
      Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Signed-off-by: Imre Deak's avatarImre Deak <imre.deak@intel.com>
      Reviewed-by: Ville Syrjälä's avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20181102182200.17219-1-imre.deak@intel.com
      (cherry picked from commit a33e1ece)
      Signed-off-by: Joonas Lahtinen's avatarJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
    • Lyude Paul's avatar
      drm/i915: Fix NULL deref when re-enabling HPD IRQs on systems with MST · 541ff7e9
      Lyude Paul authored
      Turns out that if you trigger an HPD storm on a system that has an MST
      topology connected to it, you'll end up causing the kernel to eventually
      hit a NULL deref:
      [  332.339041] BUG: unable to handle kernel NULL pointer dereference at 00000000000000ec
      [  332.340906] PGD 0 P4D 0
      [  332.342750] Oops: 0000 [#1] SMP PTI
      [  332.344579] CPU: 2 PID: 25 Comm: kworker/2:0 Kdump: loaded Tainted: G           O      4.18.0-rc3short-hpd-storm+ #2
      [  332.346453] Hardware name: LENOVO 20BWS1KY00/20BWS1KY00, BIOS JBET71WW (1.35 ) 09/14/2018
      [  332.348361] Workqueue: events intel_hpd_irq_storm_reenable_work [i915]
      [  332.350301] RIP: 0010:intel_hpd_irq_storm_reenable_work.cold.3+0x2f/0x86 [i915]
      [  332.352213] Code: 00 00 ba e8 00 00 00 48 c7 c6 c0 aa 5f a0 48 c7 c7 d0 73 62 a0 4c 89 c1 4c 89 04 24 e8 7f f5 af e0 4c 8b 04 24 44 89 f8 29 e8 <41> 39 80 ec 00 00 00 0f 85 43 13 fc ff 41 0f b6 86 b8 04 00 00 41
      [  332.354286] RSP: 0018:ffffc90000147e48 EFLAGS: 00010006
      [  332.356344] RAX: 0000000000000005 RBX: ffff8802c226c9d4 RCX: 0000000000000006
      [  332.358404] RDX: 0000000000000000 RSI: 0000000000000082 RDI: ffff88032dc95570
      [  332.360466] RBP: 0000000000000005 R08: 0000000000000000 R09: ffff88031b3dc840
      [  332.362528] R10: 0000000000000000 R11: 000000031a069602 R12: ffff8802c226ca20
      [  332.364575] R13: ffff8802c2268000 R14: ffff880310661000 R15: 000000000000000a
      [  332.366615] FS:  0000000000000000(0000) GS:ffff88032dc80000(0000) knlGS:0000000000000000
      [  332.368658] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [  332.370690] CR2: 00000000000000ec CR3: 000000000200a003 CR4: 00000000003606e0
      [  332.372724] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      [  332.374773] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      [  332.376798] Call Trace:
      [  332.378809]  process_one_work+0x1a1/0x350
      [  332.380806]  worker_thread+0x30/0x380
      [  332.382777]  ? wq_update_unbound_numa+0x10/0x10
      [  332.384772]  kthread+0x112/0x130
      [  332.386740]  ? kthread_create_worker_on_cpu+0x70/0x70
      [  332.388706]  ret_from_fork+0x35/0x40
      [  332.390651] Modules linked in: i915(O) vfat fat joydev btusb btrtl btbcm btintel bluetooth ecdh_generic iTCO_wdt wmi_bmof i2c_algo_bit drm_kms_helper intel_rapl syscopyarea sysfillrect x86_pkg_temp_thermal sysimgblt coretemp fb_sys_fops crc32_pclmul drm psmouse pcspkr mei_me mei i2c_i801 lpc_ich mfd_core i2c_core tpm_tis tpm_tis_core thinkpad_acpi wmi tpm rfkill video crc32c_intel serio_raw ehci_pci xhci_pci ehci_hcd xhci_hcd [last unloaded: i915]
      [  332.394963] CR2: 00000000000000ec
      This appears to be due to the fact that with an MST topology, not all
      intel_connector structs will have ->encoder set. So, fix this by
      skipping connectors without encoders in
      For those wondering, this bug was found on accident while simulating HPD
      storms using a Chamelium connected to a ThinkPad T450s (Broadwell).
      Changes since v1:
      - Check intel_connector->mst_port instead of intel_connector->encoder
      Signed-off-by: Lyude Paul's avatarLyude Paul <lyude@redhat.com>
      Reviewed-by: Ville Syrjälä's avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Cc: stable@vger.kernel.org
      Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20181106213017.14563-3-lyude@redhat.com
      (cherry picked from commit fee61dee)
      Signed-off-by: Joonas Lahtinen's avatarJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
    • Lyude Paul's avatar
      drm/i915: Fix possible race in intel_dp_add_mst_connector() · 7c451230
      Lyude Paul authored
      This hasn't caused any issues yet that I'm aware of, but as Ville
      Syrjälä pointed out - we need to make sure that
      intel_connector->mst_port is set before initializing MST connectors,
      since in theory we could potentially check intel_connector->mst_port in
      i915_hpd_poll_init_work() after registering the connector but before
      having written it's value.
      Signed-off-by: Lyude Paul's avatarLyude Paul <lyude@redhat.com>
      Reviewed-by: Ville Syrjälä's avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
      Cc: stable@vger.kernel.org
      Link: https://patchwork.freedesktop.org/patch/msgid/20181106213017.14563-2-lyude@redhat.com
      (cherry picked from commit 66a5ab10)
      Signed-off-by: Joonas Lahtinen's avatarJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
    • Chris Wilson's avatar
      drm/i915/ringbuffer: Delay after EMIT_INVALIDATE for gen4/gen5 · fb5bbae9
      Chris Wilson authored
      Exercising the gpu reloc path strenuously revealed an issue where the
      updated relocations (from MI_STORE_DWORD_IMM) were not being observed
      upon execution. After some experiments with adding pipecontrols (a lot
      of pipecontrols (32) as gen4/5 do not have a bit to wait on earlier pipe
      controls or even the current on), it was discovered that we merely
      needed to delay the EMIT_INVALIDATE by several flushes. It is important
      to note that it is the EMIT_INVALIDATE as opposed to the EMIT_FLUSH that
      needs the delay as opposed to what one might first expect -- that the
      delay is required for the TLB invalidation to take effect (one presumes
      to purge any CS buffers) as opposed to a delay after flushing to ensure
      the writes have landed before triggering invalidation.
      Testcase: igt/gem_tiled_fence_blits
      Signed-off-by: Chris Wilson's avatarChris Wilson <chris@chris-wilson.co.uk>
      Cc: stable@vger.kernel.org
      Reviewed-by: Ville Syrjälä's avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20181105094305.5767-1-chris@chris-wilson.co.uk
      (cherry picked from commit 55f99bf2)
      Signed-off-by: Joonas Lahtinen's avatarJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
    • Hang Yuan's avatar
      drm/i915/gvt: ensure gpu is powered before do i915_gem_gtt_insert · f3be657d
      Hang Yuan authored
      i915_gem_gtt_insert may evict some vmas and access HW if ggtt
      vm space is not enough. So add mmio_hw_access_pre before invoke
      i915_gem_gtt_insert to avoid call trace like below in vgpu create/
      destroy test.
      WARNING: CPU: 6 PID: 8720 at drivers/gpu/drm/i915/intel_drv.h:1768
      assert_rpm_wakelock_held.part.2+0x27/0x30 [i915]
      RPM wakelock ref not held during HW access
      Call Trace:
        [<ffffffff99af3b22>] dump_stack+0x19/0x1b
        [<ffffffff9948e338>] __warn+0xd8/0x100
        [<ffffffff9948e3bf>] warn_slowpath_fmt+0x5f/0x80
        [<ffffffffc0d5cc32>] assert_rpm_wakelock_held.part.2+0x27/0x30 [i915]
        [<ffffffffc0c7ffcf>] intel_runtime_pm_get_noresume+0x6f/0x80 [i915]
        [<ffffffffc0ca614d>] i915_gem_request_alloc+0x2dd/0x3c0 [i915]
        [<ffffffffc0c9056e>] i915_gem_switch_to_kernel_context+0xae/0x1d0 [i915]
        [<ffffffffc0c91572>] ggtt_flush+0x12/0x30 [i915]
        [<ffffffffc0c917ef>] i915_gem_evict_something+0x25f/0x470 [i915]
        [<ffffffffc0c9b62c>] i915_gem_gtt_insert+0x15c/0x1c0 [i915]
        [<ffffffffc0d35837>] alloc_gm+0xa7/0x160 [i915]
        [<ffffffffc0d35d8d>] intel_vgpu_alloc_resource+0x1ad/0x410 [i915]
        [<ffffffffc0d4819c>] intel_gvt_create_vgpu+0x16c/0x260 [i915]
        [<ffffffffc055d980>] intel_vgpu_create+0x50/0x140 [kvmgt]
        [<ffffffffc04fc6fa>] mdev_device_create+0x1aa/0x2e0 [mdev]
      v2: use mmio_hw_access_pre/post <Zhenyu>
      Signed-off-by: default avatarHang Yuan <hang.yuan@linux.intel.com>
      Signed-off-by: Zhenyu Wang's avatarZhenyu Wang <zhenyuw@linux.intel.com>
    • Xinyun Liu's avatar
      drm/i915/gvt: not to touch undefined MOCS registers · def40774
      Xinyun Liu authored
      Some engines are not available for all Gens. eg, Gen11 introduced
      VCS3/VCS4/VECS2, and VCS2 is not supported on some Gen9 machines. So need to
      add check before access them.
      Signed-off-by: default avatarXinyun Liu <xinyun.liu@intel.com>
      Signed-off-by: Zhao Yakui's avatarYakui Zhao <Yakui.Zhao@intel.com>
      Signed-off-by: Zhenyu Wang's avatarZhenyu Wang <zhenyuw@linux.intel.com>
  7. 06 Nov, 2018 11 commits
  8. 31 Oct, 2018 3 commits
  9. 24 Oct, 2018 2 commits
  10. 19 Oct, 2018 1 commit
    • Lyude Paul's avatar
      drm/atomic_helper: Stop modesets on unregistered connectors harder · de9f8eea
      Lyude Paul authored
      Unfortunately, it appears our fix in:
      commit b5d29843 ("drm/atomic_helper: Allow DPMS On<->Off changes
      for unregistered connectors")
      Which attempted to work around the problems introduced by:
      commit 4d802739 ("drm/atomic_helper: Disallow new modesets on
      unregistered connectors")
      Is still not the right solution, as modesets can still be triggered
      outside of drm_atomic_set_crtc_for_connector().
      So in order to fix this, while still being careful that we don't break
      modesets that a driver may perform before being registered with
      userspace, we replace connector->registered with a tristate member,
      connector->registration_state. This allows us to keep track of whether
      or not a connector is still initializing and hasn't been exposed to
      userspace, is currently registered and exposed to userspace, or has been
      legitimately removed from the system after having once been present.
      Using this info, we can prevent userspace from performing new modesets
      on unregistered connectors while still allowing the driver to perform
      modesets on unregistered connectors before the driver has finished being
      Changes since v1:
      - Fix WARN_ON() in drm_connector_cleanup() that CI caught with this
        patchset in igt@drv_module_reload@basic-reload-inject and
        igt@drv_module_reload@basic-reload by checking if the connector is
        registered instead of unregistered, as calling drm_connector_cleanup()
        on a connector that hasn't been registered with userspace yet should
        stay valid.
      - Remove unregistered_connector_check(), and just go back to what we
        were doing before in commit 4d802739 ("drm/atomic_helper: Disallow
        new modesets on unregistered connectors") except replacing
        READ_ONCE(connector->registered) with drm_connector_is_unregistered().
        This gets rid of the behavior of allowing DPMS On<->Off, but that should
        be fine as it's more consistent with the UAPI we had before - danvet
      - s/drm_connector_unregistered/drm_connector_is_unregistered/ - danvet
      - Update documentation, fix some typos.
      Fixes: b5d29843 ("drm/atomic_helper: Allow DPMS On<->Off changes for unregistered connectors")
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
      Cc: stable@vger.kernel.org
      Cc: David Airlie <airlied@linux.ie>
      Signed-off-by: Lyude Paul's avatarLyude Paul <lyude@redhat.com>
      Reviewed-by: Daniel Vetter's avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Link: https://patchwork.freedesktop.org/patch/msgid/20181016203946.9601-1-lyude@redhat.com
      (cherry picked from commit 39b50c60)
      Fixes: e9655095 ("drm/atomic_helper: Disallow new modesets on unregistered connectors")
      Fixes: 34ca26a9 ("drm/atomic_helper: Allow DPMS On<->Off changes for unregistered connectors")
      Cc: stable@vger.kernel.org
      Signed-off-by: Joonas Lahtinen's avatarJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
  11. 18 Oct, 2018 4 commits