1. 30 Aug, 2019 5 commits
  2. 29 Aug, 2019 8 commits
  3. 28 Aug, 2019 8 commits
  4. 27 Aug, 2019 14 commits
  5. 26 Aug, 2019 1 commit
    • Lyude Paul's avatar
      drm/i915: Call dma_set_max_seg_size() in i915_driver_hw_probe() · acd674af
      Lyude Paul authored
      Currently, we don't call dma_set_max_seg_size() for i915 because we
      intentionally do not limit the segment length that the device supports.
      However, this results in a warning being emitted if we try to map
      anything larger than SZ_64K on a kernel with CONFIG_DMA_API_DEBUG_SG
      enabled:
      
      [    7.751926] DMA-API: i915 0000:00:02.0: mapping sg segment longer
      than device claims to support [len=98304] [max=65536]
      [    7.751934] WARNING: CPU: 5 PID: 474 at kernel/dma/debug.c:1220
      debug_dma_map_sg+0x20f/0x340
      
      This was originally brought up on
      https://bugs.freedesktop.org/show_bug.cgi?id=108517 , and the consensus
      there was it wasn't really useful to set a limit (and that dma-debug
      isn't really all that useful for i915 in the first place). Unfortunately
      though, CONFIG_DMA_API_DEBUG_SG is enabled in the debug configs for
      various distro kernels. Since a WARN_ON() will disable automatic problem
      reporting (and cause any CI with said option enabled to start
      complaining), we really should just fix the problem.
      
      Note that as me and Chris Wilson discussed, the other solution for this
      would be to make DMA-API not make such assumptions when a driver hasn't
      explicitly set a maximum segment size. But, taking a look at the commit
      which originally introduced this behavior, commit 78c47830
      ("dma-debug: check scatterlist segments"), there is an explicit mention
      of this assumption and how it applies to devices with no segment size:
      
      	Conversely, devices which are less limited than the rather
      	conservative defaults, or indeed have no limitations at all
      	(e.g. GPUs with their own internal MMU), should be encouraged to
      	set appropriate dma_parms, as they may get more efficient DMA
      	mapping performance out of it.
      
      So unless there's any concerns (I'm open to discussion!), let's just
      follow suite and call dma_set_max_seg_size() with UINT_MAX as our limit
      to silence any warnings.
      
      Changes since v3:
      * Drop patch for enabling CONFIG_DMA_API_DEBUG_SG in CI. It looks like
        just turning it on causes the kernel to spit out bogus WARN_ONs()
        during some igt tests which would otherwise require teaching igt to
        disable the various DMA-API debugging options causing this. This is
        too much work to be worth it, since DMA-API debugging is useless for
        us. So, we'll just settle with this single patch to squelch WARN_ONs()
        during driver load for users that have CONFIG_DMA_API_DEBUG_SG turned
        on for some reason.
      * Move dma_set_max_seg_size() call into i915_driver_hw_probe() - Chris
        Wilson
      Signed-off-by: default avatarLyude Paul <lyude@redhat.com>
      Reviewed-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Cc: <stable@vger.kernel.org> # v4.18+
      Link: https://patchwork.freedesktop.org/patch/msgid/20190823205251.14298-1-lyude@redhat.com
      acd674af
  6. 24 Aug, 2019 2 commits
  7. 23 Aug, 2019 2 commits
    • Chris Wilson's avatar
      drm/i915: Keep drm_i915_file_private around under RCU · 77715906
      Chris Wilson authored
      Ensure that the drm_i915_file_private continues to exist as we attempt
      to remove a request from its list, which may race with the destruction
      of the file.
      
      <6> [38.380714] [IGT] gem_ctx_create: starting subtest basic-files
      <0> [42.201329] BUG: spinlock bad magic on CPU#0, kworker/u16:0/7
      <4> [42.201356] general protection fault: 0000 [#1] PREEMPT SMP PTI
      <4> [42.201371] CPU: 0 PID: 7 Comm: kworker/u16:0 Tainted: G     U            5.3.0-rc5-CI-Patchwork_14169+ #1
      <4> [42.201391] Hardware name: Dell Inc.                 OptiPlex 745                 /0GW726, BIOS 2.3.1  05/21/2007
      <4> [42.201594] Workqueue: i915 retire_work_handler [i915]
      <4> [42.201614] RIP: 0010:spin_dump+0x5a/0x90
      <4> [42.201625] Code: 00 48 8d 88 c0 06 00 00 48 c7 c7 00 71 09 82 e8 35 ef 00 00 48 85 db 44 8b 4d 08 41 b8 ff ff ff ff 48 c7 c1 0b cd 0f 82 74 0e <44> 8b 83 e0 04 00 00 48 8d 8b c0 06 00 00 8b 55 04 48 89 ee 48 c7
      <4> [42.201660] RSP: 0018:ffffc9000004bd80 EFLAGS: 00010202
      <4> [42.201673] RAX: 0000000000000031 RBX: 6b6b6b6b6b6b6b6b RCX: ffffffff820fcd0b
      <4> [42.201688] RDX: 0000000000000000 RSI: ffff88803de266f8 RDI: 00000000ffffffff
      <4> [42.201703] RBP: ffff888038381ff8 R08: 00000000ffffffff R09: 000000006b6b6b6b
      <4> [42.201718] R10: 0000000041cb0b89 R11: 646162206b636f6c R12: ffff88802a618500
      <4> [42.201733] R13: ffff88802b32c288 R14: ffff888038381ff8 R15: ffff88802b32c250
      <4> [42.201748] FS:  0000000000000000(0000) GS:ffff88803de00000(0000) knlGS:0000000000000000
      <4> [42.201765] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      <4> [42.201778] CR2: 00007f2cefc6d180 CR3: 00000000381ee000 CR4: 00000000000006f0
      <4> [42.201793] Call Trace:
      <4> [42.201805]  do_raw_spin_lock+0x66/0xb0
      <4> [42.201898]  i915_request_retire+0x548/0x7c0 [i915]
      <4> [42.201989]  retire_requests+0x4d/0x60 [i915]
      <4> [42.202078]  i915_retire_requests+0x144/0x2e0 [i915]
      <4> [42.202169]  retire_work_handler+0x10/0x40 [i915]
      
      Recently, in commit 44c22f3f ("drm/i915: Serialize insertion into the
      file->mm.request_list"), we fixed a race on insertion. Now, it appears
      we also have a race with destruction!
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Cc: Matthew Auld <matthew.auld@intel.com>
      Reviewed-by: default avatarMatthew Auld <matthew.auld@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20190823181455.31910-1-chris@chris-wilson.co.uk
      77715906
    • Daniele Ceraolo Spurio's avatar
      drm/i915/uc: define GuC and HuC FWs for EHL · 936ad29d
      Daniele Ceraolo Spurio authored
      First uc firmware release for EHL.
      Signed-off-by: default avatarDaniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
      Cc: Matt Roper <matthew.d.roper@intel.com>
      Cc: Anusha Srivatsa <anusha.srivatsa@intel.com>
      Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
      Reviewed-by: default avatarStuart Summers <stuart.summers@intel.com>
      Tested-by: default avatarMatt Roper <matthew.d.roper@intel.com>
      Reviewed-by: default avatarMatt Roper <matthew.d.roper@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20190820012327.36443-1-daniele.ceraolospurio@intel.com
      936ad29d