1. 28 Feb, 2022 3 commits
  2. 25 Feb, 2022 16 commits
  3. 24 Feb, 2022 2 commits
  4. 23 Feb, 2022 9 commits
  5. 22 Feb, 2022 3 commits
    • Arunpravin's avatar
      drm: implement a method to free unused pages · 95ee2a8b
      Arunpravin authored
      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: default avatarArunpravin <Arunpravin.PaneerSelvam@amd.com>
      Reviewed-by: default avatarMatthew Auld <matthew.auld@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20220221164552.2434-3-Arunpravin.PaneerSelvam@amd.comSigned-off-by: default avatarChristian König <christian.koenig@amd.com>
      95ee2a8b
    • Arunpravin's avatar
      drm: implement top-down allocation method · 476e4063
      Arunpravin authored
      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: default avatarArunpravin <Arunpravin.PaneerSelvam@amd.com>
      Reviewed-by: default avatarMatthew Auld <matthew.auld@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20220221164552.2434-2-Arunpravin.PaneerSelvam@amd.comSigned-off-by: default avatarChristian König <christian.koenig@amd.com>
      476e4063
    • Arunpravin's avatar
      drm: improve drm_buddy_alloc function · afea229f
      Arunpravin authored
      - 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: default avatarArunpravin <Arunpravin.PaneerSelvam@amd.com>
      Reviewed-by: default avatarMatthew Auld <matthew.auld@intel.com>
      Signed-off-by: default avatarChristian König <christian.koenig@amd.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20220221164552.2434-1-Arunpravin.PaneerSelvam@amd.com
      afea229f
  6. 21 Feb, 2022 1 commit
    • Ville Syrjälä's avatar
      drm/vc4: Use drm_mode_copy() · d8a8cf82
      Ville Syrjälä authored
      struct drm_display_mode embeds a list head, so overwriting
      the full struct with another one will corrupt the list
      (if the destination mode is on a list). Use drm_mode_copy()
      instead which explicitly preserves the list head of
      the destination mode.
      
      Even if we know the destination mode is not on any list
      using drm_mode_copy() seems decent as it sets a good
      example. Bad examples of not using it might eventually
      get copied into code where preserving the list head
      actually matters.
      
      Obviously one case not covered here is when the mode
      itself is embedded in a larger structure and the whole
      structure is copied. But if we are careful when copying
      into modes embedded in structures I think we can be a
      little more reassured that bogus list heads haven't been
      propagated in.
      
      @is_mode_copy@
      @@
      drm_mode_copy(...)
      {
      ...
      }
      
      @depends on !is_mode_copy@
      struct drm_display_mode *mode;
      expression E, S;
      @@
      (
      - *mode = E
      + drm_mode_copy(mode, &E)
      |
      - memcpy(mode, E, S)
      + drm_mode_copy(mode, E)
      )
      
      @depends on !is_mode_copy@
      struct drm_display_mode mode;
      expression E;
      @@
      (
      - mode = E
      + drm_mode_copy(&mode, &E)
      |
      - memcpy(&mode, E, S)
      + drm_mode_copy(&mode, E)
      )
      
      @@
      struct drm_display_mode *mode;
      @@
      - &*mode
      + mode
      
      Cc: Emma Anholt <emma@anholt.net>
      Cc: Maxime Ripard <mripard@kernel.org>
      Signed-off-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Signed-off-by: default avatarMaxime Ripard <maxime@cerno.tech>
      Link: https://patchwork.freedesktop.org/patch/msgid/20220218100403.7028-18-ville.syrjala@linux.intel.com
      d8a8cf82
  7. 20 Feb, 2022 3 commits
  8. 16 Feb, 2022 3 commits