From: "Christian König" <ckoenig.leichtzumerken@gmail.com>
To: Arunpravin Paneer Selvam <arunpravin.paneerselvam@amd.com>,
amd-gfx@lists.freedesktop.org
Cc: alexander.deucher@amd.com, christian.koenig@amd.com
Subject: Re: [PATCH] drm/amdgpu: Fix the vram base start address
Date: Thu, 2 Nov 2023 16:39:03 +0100 [thread overview]
Message-ID: <de95125a-f413-4765-b131-aeaa1296a1ec@gmail.com> (raw)
In-Reply-To: <838a8374-5499-478e-3439-3000b32bc7e4@amd.com>
Am 01.11.23 um 20:13 schrieb Arunpravin Paneer Selvam:
> Hi Christian,
>
> On 10/30/2023 9:34 PM, Christian König wrote:
>>
>>
>> Am 30.10.23 um 13:22 schrieb Arunpravin Paneer Selvam:
>>> If the size returned by drm buddy allocator is higher than
>>> the required size, we take the higher size to calculate
>>> the buffer start address. This is required if we couldn't
>>> trim the buffer to the requested size. This will fix the
>>> display corruption issue on APU's which has limited VRAM
>>> size.
>>>
>>> gitlab issue link: https://gitlab.freedesktop.org/drm/amd/-/issues/2859
>>> JIRA ticket link: https://ontrack-internal.amd.com/browse/SWDEV-425461
>>>
>>> Fixes: 0a1844bf0b53 ("drm/buddy: Improve contiguous memory allocation")
>>> Signed-off-by: Arunpravin Paneer Selvam
>>> <Arunpravin.PaneerSelvam@amd.com>
>>
>> Acked-by: Christian König <christian.koenig@amd.com>
>>
>> IIRC that hack with the start address is actually not needed any
>> more, but we need to double check this.
> okay, can we just remove this hack and keep the vres->base.start value
> as the start address of the first block from the
> allocated list.
Please double check if we don't have any more cases where we compare the
start address against the visible VRAM limit.
I think we now fixed all those cases and replaced them with calls to
check if all segments are visible, but I'm not 100% sure.
Regards,
Christian.
>
> Thanks,
> Arun
>>
>> Christian.
>>
>>> ---
>>> drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c | 15 +++++++++++++--
>>> 1 file changed, 13 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
>>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
>>> index 18f58efc9dc7..08916538a615 100644
>>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
>>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
>>> @@ -77,7 +77,16 @@ static inline bool
>>> amdgpu_is_vram_mgr_blocks_contiguous(struct list_head *head)
>>> return true;
>>> }
>>> +static inline u64 amdgpu_vram_mgr_blocks_size(struct list_head
>>> *head)
>>> +{
>>> + struct drm_buddy_block *block;
>>> + u64 size = 0;
>>> + list_for_each_entry(block, head, link)
>>> + size += amdgpu_vram_mgr_block_size(block);
>>> +
>>> + return size;
>>> +}
>>> /**
>>> * DOC: mem_info_vram_total
>>> @@ -516,6 +525,8 @@ static int amdgpu_vram_mgr_new(struct
>>> ttm_resource_manager *man,
>>> mutex_unlock(&mgr->lock);
>>> vres->base.start = 0;
>>> + size = max_t(u64, amdgpu_vram_mgr_blocks_size(&vres->blocks),
>>> + vres->base.size);
>>> list_for_each_entry(block, &vres->blocks, link) {
>>> unsigned long start;
>>> @@ -523,8 +534,8 @@ static int amdgpu_vram_mgr_new(struct
>>> ttm_resource_manager *man,
>>> amdgpu_vram_mgr_block_size(block);
>>> start >>= PAGE_SHIFT;
>>> - if (start > PFN_UP(vres->base.size))
>>> - start -= PFN_UP(vres->base.size);
>>> + if (start > PFN_UP(size))
>>> + start -= PFN_UP(size);
>>> else
>>> start = 0;
>>> vres->base.start = max(vres->base.start, start);
>>
>
prev parent reply other threads:[~2023-11-02 15:39 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-30 12:22 [PATCH] drm/amdgpu: Fix the vram base start address Arunpravin Paneer Selvam
2023-10-30 16:04 ` Christian König
2023-11-01 19:13 ` Arunpravin Paneer Selvam
2023-11-02 15:39 ` Christian König [this message]
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=de95125a-f413-4765-b131-aeaa1296a1ec@gmail.com \
--to=ckoenig.leichtzumerken@gmail.com \
--cc=alexander.deucher@amd.com \
--cc=amd-gfx@lists.freedesktop.org \
--cc=arunpravin.paneerselvam@amd.com \
--cc=christian.koenig@amd.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.