1. 19 Jul, 2018 8 commits
  2. 18 Jul, 2018 2 commits
  3. 17 Jul, 2018 2 commits
  4. 16 Jul, 2018 6 commits
  5. 14 Jul, 2018 1 commit
  6. 13 Jul, 2018 21 commits
    • Chris Wilson's avatar
      drm/i915/execlists: Drop clear_gtiir() on GPU reset · 60a94324
      Chris Wilson authored
      With the new CSB processing code, we are not vulnerable to delayed
      delivery of a pre-reset interrupt as we use the CSB status pointers in
      the HWSP to decide if we need to parse any CSB events and no longer need
      to wait for the first post-reset interrupt to be assured that the CSB
      mmio registers are valid.
      
      The new icl code to clear registers has a nasty lock inversion:
      [   57.409776] ======================================================
      [   57.409779] WARNING: possible circular locking dependency detected
      [   57.409783] 4.18.0-rc4-CI-CI_DII_1137+ #1 Tainted: G     U  W
      [   57.409785] ------------------------------------------------------
      [   57.409788] swapper/6/0 is trying to acquire lock:
      [   57.409790] 000000004f304ee5 (&engine->timeline.lock/1){-.-.}, at: execlists_submit_request+0x2b/0x1a0 [i915]
      [   57.409841]
                     but task is already holding lock:
      [   57.409844] 00000000aad89594 (&(&rq->lock)->rlock#2){-.-.}, at: notify_ring+0x2b2/0x480 [i915]
      [   57.409869]
                     which lock already depends on the new lock.
      
      [   57.409872]
                     the existing dependency chain (in reverse order) is:
      [   57.409876]
                     -> #2 (&(&rq->lock)->rlock#2){-.-.}:
      [   57.409900]        notify_ring+0x2b2/0x480 [i915]
      [   57.409922]        gen8_cs_irq_handler+0x39/0xa0 [i915]
      [   57.409943]        gen11_irq_handler+0x2f0/0x420 [i915]
      [   57.409949]        __handle_irq_event_percpu+0x42/0x370
      [   57.409952]        handle_irq_event_percpu+0x2b/0x70
      [   57.409956]        handle_irq_event+0x2f/0x50
      [   57.409959]        handle_edge_irq+0xe7/0x190
      [   57.409964]        handle_irq+0x67/0x160
      [   57.409967]        do_IRQ+0x5e/0x120
      [   57.409971]        ret_from_intr+0x0/0x1d
      [   57.409974]        _raw_spin_unlock_irqrestore+0x4e/0x60
      [   57.409979]        tasklet_action_common.isra.5+0x47/0xb0
      [   57.409982]        __do_softirq+0xd9/0x505
      [   57.409985]        irq_exit+0xa9/0xc0
      [   57.409988]        do_IRQ+0x9a/0x120
      [   57.409991]        ret_from_intr+0x0/0x1d
      [   57.409995]        cpuidle_enter_state+0xac/0x360
      [   57.409999]        do_idle+0x1f3/0x250
      [   57.410004]        cpu_startup_entry+0x6a/0x70
      [   57.410010]        start_secondary+0x19d/0x1f0
      [   57.410015]        secondary_startup_64+0xa5/0xb0
      [   57.410018]
                     -> #1 (&(&dev_priv->irq_lock)->rlock){-.-.}:
      [   57.410081]        clear_gtiir+0x30/0x200 [i915]
      [   57.410116]        execlists_reset+0x6e/0x2b0 [i915]
      [   57.410140]        i915_reset_engine+0x111/0x190 [i915]
      [   57.410165]        i915_handle_error+0x11a/0x4a0 [i915]
      [   57.410198]        i915_hangcheck_elapsed+0x378/0x530 [i915]
      [   57.410204]        process_one_work+0x248/0x6c0
      [   57.410207]        worker_thread+0x37/0x380
      [   57.410211]        kthread+0x119/0x130
      [   57.410215]        ret_from_fork+0x3a/0x50
      [   57.410217]
                     -> #0 (&engine->timeline.lock/1){-.-.}:
      [   57.410224]        _raw_spin_lock_irqsave+0x33/0x50
      [   57.410256]        execlists_submit_request+0x2b/0x1a0 [i915]
      [   57.410289]        submit_notify+0x8d/0x124 [i915]
      [   57.410314]        __i915_sw_fence_complete+0x81/0x250 [i915]
      [   57.410339]        dma_i915_sw_fence_wake+0xd/0x20 [i915]
      [   57.410344]        dma_fence_signal_locked+0x79/0x200
      [   57.410368]        notify_ring+0x2ba/0x480 [i915]
      [   57.410392]        gen8_cs_irq_handler+0x39/0xa0 [i915]
      [   57.410416]        gen11_irq_handler+0x2f0/0x420 [i915]
      [   57.410421]        __handle_irq_event_percpu+0x42/0x370
      [   57.410425]        handle_irq_event_percpu+0x2b/0x70
      [   57.410428]        handle_irq_event+0x2f/0x50
      [   57.410432]        handle_edge_irq+0xe7/0x190
      [   57.410436]        handle_irq+0x67/0x160
      [   57.410439]        do_IRQ+0x5e/0x120
      [   57.410445]        ret_from_intr+0x0/0x1d
      [   57.410449]        cpuidle_enter_state+0xac/0x360
      [   57.410453]        do_idle+0x1f3/0x250
      [   57.410456]        cpu_startup_entry+0x6a/0x70
      [   57.410460]        start_secondary+0x19d/0x1f0
      [   57.410464]        secondary_startup_64+0xa5/0xb0
      [   57.410466]
                     other info that might help us debug this:
      
      [   57.410471] Chain exists of:
                       &engine->timeline.lock/1 --> &(&dev_priv->irq_lock)->rlock --> &(&rq->lock)->rlock#2
      
      [   57.410481]  Possible unsafe locking scenario:
      
      [   57.410485]        CPU0                    CPU1
      [   57.410487]        ----                    ----
      [   57.410490]   lock(&(&rq->lock)->rlock#2);
      [   57.410494]                                lock(&(&dev_priv->irq_lock)->rlock);
      [   57.410498]                                lock(&(&rq->lock)->rlock#2);
      [   57.410503]   lock(&engine->timeline.lock/1);
      [   57.410506]
                      *** DEADLOCK ***
      
      [   57.410511] 4 locks held by swapper/6/0:
      [   57.410514]  #0: 0000000074575789 (&(&dev_priv->irq_lock)->rlock){-.-.}, at: gen11_irq_handler+0x8a/0x420 [i915]
      [   57.410542]  #1: 000000009b29b30e (rcu_read_lock){....}, at: notify_ring+0x1a/0x480 [i915]
      [   57.410573]  #2: 00000000aad89594 (&(&rq->lock)->rlock#2){-.-.}, at: notify_ring+0x2b2/0x480 [i915]
      [   57.410601]  #3: 000000009b29b30e (rcu_read_lock){....}, at: submit_notify+0x35/0x124 [i915]
      [   57.410635]
                     stack backtrace:
      [   57.410640] CPU: 6 PID: 0 Comm: swapper/6 Tainted: G     U  W         4.18.0-rc4-CI-CI_DII_1137+ #1
      [   57.410644] Hardware name: Intel Corporation Ice Lake Client Platform/IceLake U DDR4 SODIMM PD RVP, BIOS ICLSFWR1.R00.2222.A01.1805300339 05/30/2018
      [   57.410650] Call Trace:
      [   57.410652]  <IRQ>
      [   57.410657]  dump_stack+0x67/0x9b
      [   57.410662]  print_circular_bug.isra.16+0x1c8/0x2b0
      [   57.410666]  __lock_acquire+0x1897/0x1b50
      [   57.410671]  ? lock_acquire+0xa6/0x210
      [   57.410674]  lock_acquire+0xa6/0x210
      [   57.410706]  ? execlists_submit_request+0x2b/0x1a0 [i915]
      [   57.410711]  _raw_spin_lock_irqsave+0x33/0x50
      [   57.410741]  ? execlists_submit_request+0x2b/0x1a0 [i915]
      [   57.410769]  execlists_submit_request+0x2b/0x1a0 [i915]
      [   57.410774]  ? _raw_spin_unlock_irqrestore+0x39/0x60
      [   57.410804]  submit_notify+0x8d/0x124 [i915]
      [   57.410828]  __i915_sw_fence_complete+0x81/0x250 [i915]
      [   57.410854]  dma_i915_sw_fence_wake+0xd/0x20 [i915]
      [   57.410858]  dma_fence_signal_locked+0x79/0x200
      [   57.410882]  notify_ring+0x2ba/0x480 [i915]
      [   57.410907]  gen8_cs_irq_handler+0x39/0xa0 [i915]
      [   57.410933]  gen11_irq_handler+0x2f0/0x420 [i915]
      [   57.410938]  __handle_irq_event_percpu+0x42/0x370
      [   57.410943]  handle_irq_event_percpu+0x2b/0x70
      [   57.410947]  handle_irq_event+0x2f/0x50
      [   57.410951]  handle_edge_irq+0xe7/0x190
      [   57.410955]  handle_irq+0x67/0x160
      [   57.410958]  do_IRQ+0x5e/0x120
      [   57.410962]  common_interrupt+0xf/0xf
      [   57.410965]  </IRQ>
      [   57.410969] RIP: 0010:cpuidle_enter_state+0xac/0x360
      [   57.410972] Code: 44 00 00 31 ff e8 84 93 91 ff 45 84 f6 74 12 9c 58 f6 c4 02 0f 85 31 02 00 00 31 ff e8 7d 30 98 ff e8 e8 0e 94 ff fb 4c 29 fb <48> ba cf f7 53 e3 a5 9b c4 20 48 89 d8 48 c1 fb 3f 48 f7 ea b8 ff
      [   57.411015] RSP: 0018:ffffc90000133e90 EFLAGS: 00000216 ORIG_RAX: ffffffffffffffdd
      [   57.411023] RAX: ffff8804ae748040 RBX: 000000000002a97d RCX: 0000000000000000
      [   57.411029] RDX: 0000000000000046 RSI: ffffffff82141263 RDI: ffffffff820f05a7
      [   57.411035] RBP: 0000000000000001 R08: 0000000000000001 R09: 0000000000000000
      [   57.411041] R10: 0000000000000000 R11: 0000000000000000 R12: ffffffff8229f078
      [   57.411045] R13: ffff8804ab2adfa8 R14: 0000000000000000 R15: 0000000d5de092e3
      [   57.411052]  do_idle+0x1f3/0x250
      [   57.411055]  cpu_startup_entry+0x6a/0x70
      [   57.411059]  start_secondary+0x19d/0x1f0
      [   57.411064]  secondary_startup_64+0xa5/0xb0
      
      The easiest remedy is to remove the defunct code.
      
      Fixes: ff047a87 ("drm/i915/icl: Correctly clear lost ctx-switch interrupts across reset for Gen11")
      References: fd8526e5 ("drm/i915/execlists: Trust the CSB")
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Cc: Michel Thierry <michel.thierry@intel.com>
      Cc: Oscar Mateo <oscar.mateo@intel.com>
      Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
      Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
      Reviewed-by: default avatarMichel Thierry <michel.thierry@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20180713203529.1973-3-chris@chris-wilson.co.uk
      60a94324
    • Chris Wilson's avatar
      drm/i915: Do not short-circuit tasklets during reset · 9701975e
      Chris Wilson authored
      Inside intel_engine_is_idle(), we flush the tasklet to ensure that is
      being run in a timely fashion (ksoftirqd has taught us to expect the
      worst). However, if we are in the middle of reset, the HW may not yet be
      ready to execute the submission tasklet and so we must respect the
      disable flag.
      
      Fixes: dd0cf235 ("drm/i915: Speed up idle detection by kicking the tasklets")
      Testcase: igt/drv_selftest/live_hangcheck
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
      Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
      Reviewed-by: default avatarMichel Thierry <michel.thierry@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20180713203529.1973-2-chris@chris-wilson.co.uk
      9701975e
    • Chris Wilson's avatar
      drm/i915/selftests: Include the start of each subtest in the GEM trace · 9dd1a981
      Chris Wilson authored
      Knowing the boundary of each subtest can be instrumental in digesting
      the voluminous trace output and finding the critical piece of
      information.
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: default avatarMichel Thierry <michel.thierry@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20180713203529.1973-1-chris@chris-wilson.co.uk
      9dd1a981
    • Chris Wilson's avatar
      drm/i915/guc: Protect against no desc-pool on premature shutdown · 6710fcfc
      Chris Wilson authored
      Hopefully the final hack to get guc fault-injection happy before we can
      clean it up again, starting from a known good baseline...
      
      [  383.017530] BUG: unable to handle kernel NULL pointer dereference at 00000000000000a0
      [  383.017556] Oops: 0000 [#1] PREEMPT SMP PTI
      [  383.017566] CPU: 7 PID: 4725 Comm: drv_module_relo Tainted: G     U            4.18.0-rc4-CI-CI_DRM_4485+ #1
      [  383.017581] Hardware name: Micro-Star International Co., Ltd. MS-7B54/Z370M MORTAR (MS-7B54), BIOS 1.10 12/28/2017
      [  383.017664] RIP: 0010:guc_stage_desc_pool_destroy+0x17/0xe0 [i915]
      [  383.017674] Code: 59 a0 c6 05 02 59 18 00 01 e8 5e 01 c3 e0 eb b1 0f 1f 00 53 48 89 fb 48 81 c7 90 02 00 00 e8 60 64 45 e1 48 8b 83 80 02 00 00 <48> 8b 80 a0 00 00 00 48 8b 90 68 02 00 00 48 83 ea 01 48 81 fa ff
      [  383.017771] RSP: 0018:ffffc900004bbdd0 EFLAGS: 00010282
      [  383.017782] RAX: 0000000000000000 RBX: ffff88012ff41300 RCX: 0000000000000000
      [  383.017794] RDX: 0000000000000000 RSI: ffffc900004bbd80 RDI: 0000000000000000
      [  383.017805] RBP: ffff88012ff40000 R08: 00000000d876ee11 R09: 0000000000000000
      [  383.017817] R10: 0000000000000000 R11: 0000000000000000 R12: ffff88012ff47770
      [  383.017828] R13: ffff88012ff40068 R14: ffff880264392ef8 R15: ffffffffa0639950
      [  383.017840] FS:  00007fb9c18c8980(0000) GS:ffff8802663c0000(0000) knlGS:0000000000000000
      [  383.017853] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [  383.017864] CR2: 00000000000000a0 CR3: 00000001df6cc003 CR4: 00000000003606e0
      [  383.017875] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      [  383.017887] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      [  383.017898] Call Trace:
      [  383.017962]  intel_uc_fini+0x34/0xd0 [i915]
      [  383.018020]  i915_gem_fini+0x5c/0x100 [i915]
      [  383.018093]  i915_driver_unload+0xd2/0x110 [i915]
      [  383.018150]  i915_pci_remove+0x10/0x20 [i915]
      [  383.018165]  pci_device_remove+0x36/0xb0
      [  383.018179]  device_release_driver_internal+0x185/0x250
      [  383.018193]  driver_detach+0x35/0x70
      [  383.018205]  bus_remove_driver+0x53/0xd0
      [  383.018217]  pci_unregister_driver+0x25/0xa0
      [  383.018232]  __se_sys_delete_module+0x162/0x210
      [  383.018245]  ? do_syscall_64+0xd/0x190
      [  383.018257]  do_syscall_64+0x55/0x190
      [  383.018270]  entry_SYSCALL_64_after_hwframe+0x49/0xbe
      [  383.018282] RIP: 0033:0x7fb9c0f7c1b7
      [  383.018290] Code: 73 01 c3 48 8b 0d d1 8c 2c 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 b8 b0 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d a1 8c 2c 00 f7 d8 64 89 01 48
      [  383.018408] RSP: 002b:00007fffa01c2aa8 EFLAGS: 00000206 ORIG_RAX: 00000000000000b0
      [  383.018425] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fb9c0f7c1b7
      [  383.018440] RDX: 0000000000000000 RSI: 0000000000000800 RDI: 0000560b96856d48
      [  383.018454] RBP: 0000560b96856ce0 R08: 0000560b96856d4c R09: 00007fffa01c2ae8
      [  383.018468] R10: 00007fffa01c1aa4 R11: 0000000000000206 R12: 0000560b954f7470
      
      Testcase: igt/drv_module_reload/basic-reload-inject
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Cc: Michał Winiarski <michal.winiarski@intel.com>
      Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
      Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
      Reviewed-by: default avatarRodrigo Vivi <rodrigo.vivi@intel.com>
      Reviewed-by: default avatarMichal Wajdeczko <michal.wajdeczko@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20180713172658.14070-1-chris@chris-wilson.co.uk
      6710fcfc
    • Ville Syrjälä's avatar
      drm/i915: Print the long_mask alongside the pin_mask · f88f0478
      Ville Syrjälä authored
      We're printing out which pins got a hotplug, so why not also print
      out which pins detected the long pulse as opposed to a short pulse.
      Signed-off-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20180705164357.28512-9-ville.syrjala@linux.intel.comReviewed-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      f88f0478
    • Ville Syrjälä's avatar
      drm/i915: Pass hpd_pin to long_pulse_detect() · af92058f
      Ville Syrjälä authored
      We're doing a pointless translation from hpd_pin to port simply for
      passing the thing to long_pulse_detect(). Let's pass the hpd_pin
      directly instead.
      
      This removes the assumption that the hpd_pin and port always
      match. The only other place where we make that assumption anymore
      is intel_hpd_pin_default() and that's fine as it's what determines
      the relationship between the two. If we ever get hardware where
      the hpd pins are wired in more interesting ways it should be
      trivial to handle from now on.
      
      This should also fix the IS_CNL_WITH_PORT_F() case as that mapped
      pin E back to port F and passed that to
      spt_port_hotplug2_long_detect() which would always return false
      for port F. Now that we pass in pin E directly it'll actually
      do the right thing.
      
      Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
      Fixes: cf53902f ("drm/i915/cnl: Add HPD support for Port F.")
      Signed-off-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20180705164357.28512-7-ville.syrjala@linux.intel.comReviewed-by: default avatarRodrigo Vivi <rodrigo.vivi@intel.com>
      af92058f
    • Ville Syrjälä's avatar
      drm/i915: s/int i/enum hpd_pin pin/ · e9be2850
      Ville Syrjälä authored
      Use the enum hpd_pin type when talking about HPD pins, and rename the
      variable from a very nondescript 'i' to 'pin', a name we already
      use in other parts of the code.
      Signed-off-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20180705164357.28512-6-ville.syrjala@linux.intel.comReviewed-by: default avatarRodrigo Vivi <rodrigo.vivi@intel.com>
      e9be2850
    • Ville Syrjälä's avatar
      drm/i915: Nuke dev_priv->irq_port[] · b6ca3eee
      Ville Syrjälä authored
      Instead of looping over ports and hpd_pins, let's loop over
      the encoders when doing hotplug processing. And instead of
      depending on dev_priv->irq_port[] to tell us whether the
      encoder has the ->hpd_pulse() hook or not, we can just
      check for that directly. So we can just nuke irq_port[] entirely.
      Signed-off-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20180705164357.28512-5-ville.syrjala@linux.intel.comReviewed-by: default avatarRodrigo Vivi <rodrigo.vivi@intel.com>
      b6ca3eee
    • Ville Syrjälä's avatar
      drm/i915: Rewrite mst suspend/resume in terms of encoders · 1a4313d1
      Ville Syrjälä authored
      Rather than looping over all the ports and picking the encoder based on
      the port, let's just loop over all the encoders instead. Gets rid of
      some irq_port[] usage, which is a bit of an eye sore.
      Signed-off-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20180705164357.28512-4-ville.syrjala@linux.intel.comReviewed-by: default avatarRodrigo Vivi <rodrigo.vivi@intel.com>
      1a4313d1
    • Ville Syrjälä's avatar
    • Ville Syrjälä's avatar
    • Chris Wilson's avatar
      drm/i915/userptr: Enable read-only support on gen8+ · 0b100760
      Chris Wilson authored
      On gen8 and onwards, we can mark GPU accesses through the ppGTT as being
      read-only, that is cause any GPU write onto that page to be discarded
      (not triggering a fault). This is all that we need to finally support
      the read-only flag for userptr!
      
      v2: Check default address space for read only support as a proxy for the
      user context/ppgtt.
      
      Testcase: igt/gem_userptr_blits/readonly*
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Cc: Jon Bloomfield <jon.bloomfield@intel.com>
      Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Reviewed-by: default avatarJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Reviewed-by: default avatarMatthew Auld <matthew.william.auld@gmail.com>
      Reviewed-by: default avatarJon Bloomfield <jon.bloomfield@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20180712191430.9269-1-chris@chris-wilson.co.uk
      0b100760
    • Chris Wilson's avatar
      drm/i915: Reject attempted pwrites into a read-only object · f8c1cce3
      Chris Wilson authored
      If the user created a read-only object, they should not be allowed to
      circumvent the write protection using the pwrite ioctl.
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Cc: Jon Bloomfield <jon.bloomfield@intel.com>
      Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Cc: Matthew Auld <matthew.william.auld@gmail.com>
      Reviewed-by: default avatarJon Bloomfield <jon.bloomfield@intel.com>
      Reviewed-by: default avatarJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Reviewed-by: default avatarMatthew Auld <matthew.william.auld@gmail.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20180712185315.3288-5-chris@chris-wilson.co.uk
      f8c1cce3
    • Chris Wilson's avatar
      drm/i915: Prevent writing into a read-only object via a GGTT mmap · 3e977ac6
      Chris Wilson authored
      If the user has created a read-only object, they should not be allowed
      to circumvent the write protection by using a GGTT mmapping. Deny it.
      
      Also most machines do not support read-only GGTT PTEs, so again we have
      to reject attempted writes. Fortunately, this is known a priori, so we
      can at least reject in the call to create the mmap (with a sanity check
      in the fault handler).
      
      v2: Check the vma->vm_flags during mmap() to allow readonly access.
      v3: Remove VM_MAYWRITE to curtail mprotect()
      
      Testcase: igt/gem_userptr_blits/readonly_mmap*
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Cc: Jon Bloomfield <jon.bloomfield@intel.com>
      Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Cc: Matthew Auld <matthew.william.auld@gmail.com>
      Cc: David Herrmann <dh.herrmann@gmail.com>
      Reviewed-by: Matthew Auld <matthew.william.auld@gmail.com> #v1
      Reviewed-by: default avatarJon Bloomfield <jon.bloomfield@intel.com>
      Reviewed-by: default avatarJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20180712185315.3288-4-chris@chris-wilson.co.uk
      3e977ac6
    • Chris Wilson's avatar
      drm/i915/gtt: Disable read-only support under GVT · c9e66688
      Chris Wilson authored
      GVT is not propagating the PTE bits, and is always setting the
      read-write bit, thus breaking read-only support.
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Cc: Zhenyu Wang <zhenyuw@linux.intel.com>
      Cc: Jon Bloomfield <jon.bloomfield@intel.com>
      Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Cc: Matthew Auld <matthew.william.auld@gmail.com>
      Reviewed-by: default avatarJon Bloomfield <jon.bloomfield@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20180712185315.3288-3-chris@chris-wilson.co.uk
      c9e66688
    • Jon Bloomfield's avatar
      drm/i915/gtt: Read-only pages for insert_entries on bdw+ · 250f8c81
      Jon Bloomfield authored
      Hook up the flags to allow read-only ppGTT mappings for gen8+
      
      v2: Include a selftest to check that writes to a readonly PTE are
      dropped
      v3: Don't duplicate cpu_check() as we can just reuse it, and even worse
      don't wholesale copy the theory-of-operation comment from igt_ctx_exec
      without changing it to explain the intention behind the new test!
      v4: Joonas really likes magic mystery values
      Signed-off-by: default avatarJon Bloomfield <jon.bloomfield@intel.com>
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Cc: Matthew Auld <matthew.william.auld@gmail.com>
      Reviewed-by: default avatarJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Reviewed-by: default avatarMatthew Auld <matthew.william.auld@gmail.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20180712185315.3288-2-chris@chris-wilson.co.uk
      250f8c81
    • Jon Bloomfield's avatar
      drm/i915/gtt: Add read only pages to gen8_pte_encode · 25dda4da
      Jon Bloomfield authored
      We can set a bit inside the ppGTT PTE to indicate a page is read-only;
      writes from the GPU will be discarded. We can use this to protect pages
      and in particular support read-only userptr mappings (necessary for
      importing PROT_READ vma).
      Signed-off-by: default avatarJon Bloomfield <jon.bloomfield@intel.com>
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Cc: Matthew Auld <matthew.william.auld@gmail.com>
      Reviewed-by: default avatarJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Reviewed-by: default avatarMatthew Auld <matthew.william.auld@gmail.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20180712185315.3288-1-chris@chris-wilson.co.uk
      25dda4da
    • Clint Taylor's avatar
      drm/i915/glk: Add Quirk for GLK NUC HDMI port issues. · 90c3e219
      Clint Taylor authored
      On GLK NUC platforms the HDMI retiming buffer needs additional disabled
      time to correctly sync to a faster incoming signal.
      
      When measured on a scope the highspeed lines of the HDMI clock turn off
       for ~400uS during a normal resolution change. The HDMI retimer on the
       GLK NUC appears to require at least a full frame of quiet time before a
      new faster clock can be correctly sync'd. Wait 100ms due to msleep
      inaccuracies while waiting for a completed frame. Add a quirk to the
      driver for GLK boards that use ITE66317 HDMI retimers.
      
      V2: Add more devices to the quirk list
      V3: Delay increased to 100ms, check to confirm crtc type is HDMI.
      V4: crtc type check extended to include _DDI and whitespace fixes
      v5: Fix white spaces, remove the macro for delay. Revert the crtc type
          check introduced in v4.
      
      Cc: Imre Deak <imre.deak@intel.com>
      Cc: <stable@vger.kernel.org> # v4.14+
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105887Signed-off-by: default avatarClint Taylor <clinton.a.taylor@intel.com>
      Tested-by: default avatarDaniel Scheller <d.scheller.oss@gmail.com>
      Signed-off-by: default avatarRadhakrishna Sripada <radhakrishna.sripada@intel.com>
      Signed-off-by: default avatarImre Deak <imre.deak@intel.com>
      Reviewed-by: default avatarImre Deak <imre.deak@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20180710200205.1478-1-radhakrishna.sripada@intel.com
      90c3e219
    • Chris Wilson's avatar
      drm/i915/guc: Protect against NULL client dereference in error path · 55fe0768
      Chris Wilson authored
      After aborting a module load, we may try and disable guc before we have
      finished setting it. Long term plan is to ensure perfect onion unwind,
      but in the short term we want to fix the oops to re-enable
      drv_module_reload.
      
      [  317.401239] BUG: unable to handle kernel NULL pointer dereference at 0000000000000030
      [  317.401279] Oops: 0000 [#1] PREEMPT SMP PTI
      [  317.401294] CPU: 5 PID: 4275 Comm: drv_module_relo Tainted: G     U            4.18.0-rc4-CI-CI_DRM_4476+ #1
      [  317.401317] Hardware name: System manufacturer System Product Name/Z170M-PLUS, BIOS 3610 03/29/2018
      [  317.401440] RIP: 0010:unreserve_doorbell+0x0/0x80 [i915]
      [  317.401454] Code: bb e0 48 8b 35 21 4d 18 00 49 c7 c0 a8 e5 62 a0 b9 cc 00 00 00 48 c7 c2 d8 41 5f a0 48 c7 c7 c9 f6 53 a0 e8 a2 3d c2 e0 0f 0b <0f> b7 47 30 66 3d 00 01 74 20 48 8b 57 18 48 0f a3 82 40 05 00 00
      [  317.401602] RSP: 0018:ffffc900003d3da0 EFLAGS: 00010246
      [  317.401619] RAX: ffffffff8223b300 RBX: 0000000000000000 RCX: 0000000000000000
      [  317.401636] RDX: 0000001fffffffc0 RSI: ffff880219f115f0 RDI: 0000000000000000
      [  317.401654] RBP: ffff880219f11838 R08: 0000000000000000 R09: 0000000000000000
      [  317.401671] R10: 0000000000000000 R11: 0000000000000000 R12: ffff880219f11300
      [  317.401689] R13: ffff880219f17770 R14: ffff88022c1daef8 R15: ffffffffa06ae950
      [  317.401707] FS:  00007febf77a9980(0000) GS:ffff880236d40000(0000) knlGS:0000000000000000
      [  317.401727] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [  317.401743] CR2: 0000000000000030 CR3: 0000000222072003 CR4: 00000000003606e0
      [  317.401761] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      [  317.401779] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      [  317.401796] Call Trace:
      [  317.401894]  guc_client_free+0x9/0x130 [i915]
      [  317.401993]  intel_guc_submission_fini+0x50/0x90 [i915]
      [  317.402092]  intel_uc_fini+0x34/0xd0 [i915]
      [  317.402179]  i915_gem_fini+0x5c/0x100 [i915]
      [  317.402249]  i915_driver_unload+0xd2/0x110 [i915]
      [  317.402321]  i915_pci_remove+0x10/0x20 [i915]
      [  317.402341]  pci_device_remove+0x36/0xb0
      [  317.402357]  device_release_driver_internal+0x185/0x250
      [  317.402374]  driver_detach+0x35/0x70
      [  317.402390]  bus_remove_driver+0x53/0xd0
      [  317.402404]  pci_unregister_driver+0x25/0xa0
      [  317.402423]  __se_sys_delete_module+0x162/0x210
      [  317.402439]  ? do_syscall_64+0xd/0x190
      [  317.402454]  do_syscall_64+0x55/0x190
      [  317.402470]  entry_SYSCALL_64_after_hwframe+0x49/0xbe
      [  317.402485] RIP: 0033:0x7febf6e5d1b7
      [  317.402496] Code: 73 01 c3 48 8b 0d d1 8c 2c 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 b8 b0 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d a1 8c 2c 00 f7 d8 64 89 01 48
      [  317.402646] RSP: 002b:00007fffb5e72798 EFLAGS: 00000206 ORIG_RAX: 00000000000000b0
      [  317.402667] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007febf6e5d1b7
      [  317.402686] RDX: 0000000000000000 RSI: 0000000000000800 RDI: 0000562da1addd98
      [  317.402703] RBP: 0000562da1addd30 R08: 0000562da1addd9c R09: 00007fffb5e727d8
      [  317.402721] R10: 00007fffb5e71794 R11: 0000000000000206 R12: 0000562da0ff6470
      
      Testcase: igt/drv_module_reload/basic-reload-inject
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Cc: Michał Winiarski <michal.winiarski@intel.com>
      Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
      Reviewed-by: default avatarRodrigo Vivi <rodrigo.vivi@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20180712202027.19801-1-chris@chris-wilson.co.uk
      55fe0768
    • Rodrigo Vivi's avatar
      f7cf1a18
    • Rodrigo Vivi's avatar
      drm/i915/psr: Remove few mod parameters option. · 9306b62b
      Rodrigo Vivi authored
      Reduce the module parameter to enable or disable.
      
      The link stand by vs full link off was used only once.
      
      And it was actually masking another bug fixed by commit
      '84bb2916 ("drm/i915/psr: Check for SET_POWER_CAPABLE
      bit at PSR init time.")'
      
      So, let's remove these options for now. End goal is to
      fully remove the mod param, moving it to a debugfs
      interface in upcoming patches.
      
      Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
      Cc: Tarun Vyas <tarun.vyas@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/20180712052715.8177-1-rodrigo.vivi@intel.com
      9306b62b