1. 28 2月, 2022 2 次提交
  2. 26 2月, 2022 16 次提交
  3. 25 2月, 2022 2 次提交
    • M
      drm/i915/ttm: fixup the mock_bo · 8fbf2893
      Matthew Auld 提交于
      When running the mock selftests we currently blow up with:
      
      <6> [299.836278] i915: Running i915_gem_huge_page_mock_selftests/igt_mock_memory_region_huge_pages
      <1> [299.836356] BUG: kernel NULL pointer dereference, address: 00000000000000c8
      <1> [299.836361] #PF: supervisor read access in kernel mode
      <1> [299.836364] #PF: error_code(0x0000) - not-present page
      <6> [299.836367] PGD 0 P4D 0
      <4> [299.836369] Oops: 0000 [#1] PREEMPT SMP NOPTI
      <4> [299.836372] CPU: 1 PID: 1429 Comm: i915_selftest Tainted: G     U            5.17.0-rc4-CI-CI_DRM_11227+ #1
      <4> [299.836376] Hardware name: Intel(R) Client Systems NUC11TNHi5/NUC11TNBi5, BIOS TNTGL357.0042.2020.1221.1743 12/21/2020
      <4> [299.836380] RIP: 0010:ttm_resource_init+0x57/0x90 [ttm]
      <4> [299.836392] RSP: 0018:ffffc90001e4f680 EFLAGS: 00010203
      <4> [299.836395] RAX: 0000000000000000 RBX: ffffc90001e4f708 RCX: 0000000000000000
      <4> [299.836398] RDX: ffff888116172528 RSI: ffffc90001e4f6f8 RDI: 0000000000000000
      <4> [299.836401] RBP: ffffc90001e4f6f8 R08: 00000000000001b0 R09: ffff888116172528
      <4> [299.836403] R10: 0000000000000001 R11: 00000000a4cb2e51 R12: ffffc90001e4fa90
      <4> [299.836406] R13: ffff888116172528 R14: ffff888130d7f4b0 R15: ffff888130d7f400
      <4> [299.836409] FS:  00007ff241684500(0000) GS:ffff88849fe80000(0000) knlGS:0000000000000000
      <4> [299.836412] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      <4> [299.836416] CR2: 00000000000000c8 CR3: 0000000107b80001 CR4: 0000000000770ee0
      <4> [299.836418] PKRU: 55555554
      <4> [299.836420] Call Trace:
      <4> [299.836422]  <TASK>
      <4> [299.836423]  i915_ttm_buddy_man_alloc+0x68/0x240 [i915]
      
      ttm_resource_init() now needs to access the bo->bdev, and also wants to
      store the bo reference. Try to keep both working. The mock_bo is a hack
      so we can interface directly with the ttm managers alloc() and free() hooks for
      our mock testing, without invoking other TTM features like eviction,
      moves, etc.
      
      v2: make sure we only touch res->bo if the alloc() returns successfully
      
      Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5123
      Fixes: 0e05fc49 ("drm/ttm: add common accounting to the resource mgr v3")
      Signed-off-by: NMatthew Auld <matthew.auld@intel.com>
      Cc: Christian König <christian.koenig@amd.com>
      Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
      Acked-by: NChristian König <christian.koenig@amd.com>
      Reviewed-by: NThomas Hellström <thomas.hellstrom@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20220221121103.2473831-1-matthew.auld@intel.com
      8fbf2893
    • J
      drm/i915: Check stolen memory size before calling drm_mm_init · b8986c88
      José Roberto de Souza 提交于
      Add check for zero usable stolen memory before calling drm_mm_init
      to support configurations where stolen memory exists but is fully
      reserved.
      
      Also skip memory test in cases that usable stolen is smaller than
      page size(amount mapped and used to test memory).
      
      v2:
      - skiping test if available memory is smaller than page size (Lucas)
      
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
      Cc: Lucas De Marchi <lucas.demarchi@intel.com>
      Signed-off-by: NJosé Roberto de Souza <jose.souza@intel.com>
      Signed-off-by: NSteve Carbonari <steven.carbonari@intel.com>
      Reviewed-by: NLucas De Marchi <lucas.demarchi@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20220223194946.725328-1-jose.souza@intel.com
      b8986c88
  4. 24 2月, 2022 1 次提交
  5. 23 2月, 2022 12 次提交
  6. 22 2月, 2022 5 次提交
    • T
      drm/i915/gt: use get_reset_domain() helper · 64b2a6a0
      Tejas Upadhyay 提交于
      We dont need to implement reset_domain in intel_engine
      _setup(), but can be done as a helper. Implemented as
      engine->reset_domain = get_reset_domain().
      
      Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
      Signed-off-by: NTejas Upadhyay <tejaskumarx.surendrakumar.upadhyay@intel.com>
      Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
      Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20220217123223.748184-1-tejaskumarx.surendrakumar.upadhyay@intel.com
      64b2a6a0
    • A
      drm: implement a method to free unused pages · 95ee2a8b
      Arunpravin 提交于
      On contiguous allocation, we round up the size
      to the *next* power of 2, implement a function
      to free the unused pages after the newly allocate block.
      
      v2(Matthew Auld):
        - replace function name 'drm_buddy_free_unused_pages' with
          drm_buddy_block_trim
        - replace input argument name 'actual_size' with 'new_size'
        - add more validation checks for input arguments
        - add overlaps check to avoid needless searching and splitting
        - merged the below patch to see the feature in action
           - add free unused pages support to i915 driver
        - lock drm_buddy_block_trim() function as it calls mark_free/mark_split
          are all globally visible
      
      v3(Matthew Auld):
        - remove trim method error handling as we address the failure case
          at drm_buddy_block_trim() function
      
      v4:
        - in case of trim, at __alloc_range() split_block failure path
          marks the block as free and removes it from the original list,
          potentially also freeing it, to overcome this problem, we turn
          the drm_buddy_block_trim() input node into a temporary node to
          prevent recursively freeing itself, but still retain the
          un-splitting/freeing of the other nodes(Matthew Auld)
      
        - modify the drm_buddy_block_trim() function return type
      
      v5(Matthew Auld):
        - revert drm_buddy_block_trim() function return type changes in v4
        - modify drm_buddy_block_trim() passing argument n_pages to original_size
          as n_pages has already been rounded up to the next power-of-two and
          passing n_pages results noop
      
      v6:
        - fix warnings reported by kernel test robot <lkp@intel.com>
      
      v7:
        - modify drm_buddy_block_trim() function doc description
        - at drm_buddy_block_trim() handle non-allocated block as
          a serious programmer error
        - fix a typo
      Signed-off-by: NArunpravin <Arunpravin.PaneerSelvam@amd.com>
      Reviewed-by: NMatthew Auld <matthew.auld@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20220221164552.2434-3-Arunpravin.PaneerSelvam@amd.comSigned-off-by: NChristian König <christian.koenig@amd.com>
      95ee2a8b
    • A
      drm: implement top-down allocation method · 476e4063
      Arunpravin 提交于
      Implemented a function which walk through the order list,
      compares the offset and returns the maximum offset block,
      this method is unpredictable in obtaining the high range
      address blocks which depends on allocation and deallocation.
      for instance, if driver requests address at a low specific
      range, allocator traverses from the root block and splits
      the larger blocks until it reaches the specific block and
      in the process of splitting, lower orders in the freelist
      are occupied with low range address blocks and for the
      subsequent TOPDOWN memory request we may return the low
      range blocks.To overcome this issue, we may go with the
      below approach.
      
      The other approach, sorting each order list entries in
      ascending order and compares the last entry of each
      order list in the freelist and return the max block.
      This creates sorting overhead on every drm_buddy_free()
      request and split up of larger blocks for a single page
      request.
      
      v2:
        - Fix alignment issues(Matthew Auld)
        - Remove unnecessary list_empty check(Matthew Auld)
        - merged the below patch to see the feature in action
           - add top-down alloc support to i915 driver
      Signed-off-by: NArunpravin <Arunpravin.PaneerSelvam@amd.com>
      Reviewed-by: NMatthew Auld <matthew.auld@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20220221164552.2434-2-Arunpravin.PaneerSelvam@amd.comSigned-off-by: NChristian König <christian.koenig@amd.com>
      476e4063
    • A
      drm: improve drm_buddy_alloc function · afea229f
      Arunpravin 提交于
      - Make drm_buddy_alloc a single function to handle
        range allocation and non-range allocation demands
      
      - Implemented a new function alloc_range() which allocates
        the requested power-of-two block comply with range limitations
      
      - Moved order computation and memory alignment logic from
        i915 driver to drm buddy
      
      v2:
        merged below changes to keep the build unbroken
         - drm_buddy_alloc_range() becomes obsolete and may be removed
         - enable ttm range allocation (fpfn / lpfn) support in i915 driver
         - apply enhanced drm_buddy_alloc() function to i915 driver
      
      v3(Matthew Auld):
        - Fix alignment issues and remove unnecessary list_empty check
        - add more validation checks for input arguments
        - make alloc_range() block allocations as bottom-up
        - optimize order computation logic
        - replace uint64_t with u64, which is preferred in the kernel
      
      v4(Matthew Auld):
        - keep drm_buddy_alloc_range() function implementation for generic
          actual range allocations
        - keep alloc_range() implementation for end bias allocations
      
      v5(Matthew Auld):
        - modify drm_buddy_alloc() passing argument place->lpfn to lpfn
          as place->lpfn will currently always be zero for i915
      
      v6(Matthew Auld):
        - fixup potential uaf - If we are unlucky and can't allocate
          enough memory when splitting blocks, where we temporarily
          end up with the given block and its buddy on the respective
          free list, then we need to ensure we delete both blocks,
          and no just the buddy, before potentially freeing them
      
        - fix warnings reported by kernel test robot <lkp@intel.com>
      
      v7(Matthew Auld):
        - revert fixup potential uaf
        - keep __alloc_range() add node to the list logic same as
          drm_buddy_alloc_blocks() by having a temporary list variable
        - at drm_buddy_alloc_blocks() keep i915 range_overflows macro
          and add a new check for end variable
      
      v8:
        - fix warnings reported by kernel test robot <lkp@intel.com>
      
      v9(Matthew Auld):
        - remove DRM_BUDDY_RANGE_ALLOCATION flag
        - remove unnecessary function description
      
      v10:
         - keep DRM_BUDDY_RANGE_ALLOCATION flag as removing the flag
           and replacing with (end < size) logic fails amdgpu driver load
      Signed-off-by: NArunpravin <Arunpravin.PaneerSelvam@amd.com>
      Reviewed-by: NMatthew Auld <matthew.auld@intel.com>
      Signed-off-by: NChristian König <christian.koenig@amd.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20220221164552.2434-1-Arunpravin.PaneerSelvam@amd.com
      afea229f
    • I
      drm/i915/adlp: Add TypeC PHY TBT->DP-alt/legacy mode switch workaround · 55223c3b
      Imre Deak 提交于
      Add display workaround # 1309179469 , which fixes a PHY hang when
      switching from TBT mode to DP-alt/legacy mode. The workaround also
      requires an IFWI/PHY firmware change, before that this change has no
      effect (the DKL_PCS_DW5/SOFTRESET flag is always cleared).
      
      HSDES: 18018237866
      HSDES: 16014473319
      Signed-off-by: NImre Deak <imre.deak@intel.com>
      Reviewed-by: NJosé Roberto de Souza <jose.souza@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20220218122611.767974-1-imre.deak@intel.com
      55223c3b
  7. 21 2月, 2022 2 次提交