Intel-GFX Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Arunpravin <arunpravin.paneerselvam@amd.com>
To: Thomas Zimmermann <tzimmermann@suse.de>,
	dri-devel@lists.freedesktop.org,
	 intel-gfx@lists.freedesktop.org, amd-gfx@lists.freedesktop.org
Cc: alexander.deucher@amd.com, matthew.auld@intel.com,
	christian.koenig@amd.com
Subject: Re: [Intel-gfx] [PATCH v4 2/6] drm: improve drm_buddy_alloc function
Date: Mon, 27 Dec 2021 02:29:42 +0530	[thread overview]
Message-ID: <fb3d8dc7-a0ff-f5ec-2fce-75515843eb92@amd.com> (raw)
In-Reply-To: <d76d347f-7dcb-546a-efc0-a324d773861c@suse.de>

Hi Thomas

On 16/12/21 5:05 pm, Thomas Zimmermann wrote:
> Hi
> 
> Am 01.12.21 um 17:39 schrieb 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
>>
>> Signed-off-by: Arunpravin <Arunpravin.PaneerSelvam@amd.com>

<SNIP>

>> +#define DRM_BUDDY_RANGE_ALLOCATION (1 << 0)
>> +
>>   struct drm_buddy_block {
>>   #define DRM_BUDDY_HEADER_OFFSET GENMASK_ULL(63, 12)
>>   #define DRM_BUDDY_HEADER_STATE  GENMASK_ULL(11, 10)
>> @@ -132,12 +139,11 @@ int drm_buddy_init(struct drm_buddy_mm *mm, u64 size, u64 chunk_size);
>>   
>>   void drm_buddy_fini(struct drm_buddy_mm *mm);
>>   
>> -struct drm_buddy_block *
>> -drm_buddy_alloc(struct drm_buddy_mm *mm, unsigned int order);
> 
> Just a style issue. The structure is called drm_buddy_mm. For 
> consistency, I like to suggest to name all the public interfaces and 
> defines drm_buddy_mm_* instead of just drm_buddy_*.
> 
Thanks for the suggestion, I think renaming drm_buddy_* to
drm_buddy_mm_* creates a long name for the public interfaces, for
instance - drm_buddy_mm_alloc_blocks(),
discussing the style issue internally
@Matthew, @christian - please let me know your opinion

> 
>> -
>> -int drm_buddy_alloc_range(struct drm_buddy_mm *mm,
>> -			  struct list_head *blocks,
>> -			  u64 start, u64 size);
>> +int drm_buddy_alloc(struct drm_buddy_mm *mm,
>> +		    u64 start, u64 end, u64 size,
>> +		    u64 min_page_size,
>> +		    struct list_head *blocks,
>> +		    unsigned long flags);
>>   
>>   void drm_buddy_free(struct drm_buddy_mm *mm, struct drm_buddy_block *block);
> 
> I'd call those *_alloc_blocks() and _free_blocks(). Right now it sounds 
> as if they allocate and free instances of drm_buddy_mm.
can we call those drm_buddy_alloc_blocks() and drm_buddy_free_blocks()
Does this make sense?
> 
> Best regards
> Thomas
>>   
>>
> 

  reply	other threads:[~2021-12-26 20:51 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-01 16:39 [Intel-gfx] [PATCH v4 1/6] drm: move the buddy allocator from i915 into common drm Arunpravin
2021-12-01 16:39 ` [Intel-gfx] [PATCH v4 2/6] drm: improve drm_buddy_alloc function Arunpravin
2021-12-09 15:47   ` Paneer Selvam, Arunpravin
2021-12-13 18:59     ` Matthew Auld
2021-12-15 20:46       ` Arunpravin
2021-12-16 10:55         ` Matthew Auld
2021-12-16 11:35   ` Thomas Zimmermann
2021-12-26 20:59     ` Arunpravin [this message]
2022-01-03  7:41       ` Christian König
2022-01-06 12:01         ` Thomas Zimmermann
2021-12-01 16:39 ` [Intel-gfx] [PATCH v4 3/6] drm: implement top-down allocation method Arunpravin
2021-12-01 16:39 ` [Intel-gfx] [PATCH v4 4/6] drm: implement a method to free unused pages Arunpravin
2021-12-09 15:52   ` Paneer Selvam, Arunpravin
2021-12-13 18:40   ` Matthew Auld
2021-12-15 20:56     ` Arunpravin
2021-12-01 16:39 ` [Intel-gfx] [PATCH v4 5/6] drm/amdgpu: move vram inline functions into a header Arunpravin
2021-12-01 16:39 ` [Intel-gfx] [PATCH v4 6/6] drm/amdgpu: add drm buddy support to amdgpu Arunpravin
2021-12-01 21:50 ` [Intel-gfx] ✗ Fi.CI.BUILD: failure for series starting with [v4,1/6] drm: move the buddy allocator from i915 into common drm Patchwork
2021-12-02  0:56 ` [Intel-gfx] [PATCH v4 1/6] " kernel test robot
2021-12-02  4:49 ` kernel test robot
2021-12-02  8:03 ` Christian König
2021-12-10  3:22 ` [Intel-gfx] ✗ Fi.CI.BUILD: failure for series starting with [v4,1/6] drm: move the buddy allocator from i915 into common drm (rev3) Patchwork

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=fb3d8dc7-a0ff-f5ec-2fce-75515843eb92@amd.com \
    --to=arunpravin.paneerselvam@amd.com \
    --cc=alexander.deucher@amd.com \
    --cc=amd-gfx@lists.freedesktop.org \
    --cc=christian.koenig@amd.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=matthew.auld@intel.com \
    --cc=tzimmermann@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox