From: "Thomas Hellström" <thomas.hellstrom@linux.intel.com>
To: "Christian König" <ckoenig.leichtzumerken@gmail.com>,
"Oak Zeng" <oak.zeng@intel.com>,
dri-devel@lists.freedesktop.org, intel-xe@lists.freedesktop.org
Cc: Amaranath.Somalapuram@amd.com, lucas.demarchi@intel.com
Subject: Re: [PATCH] drm/xe: Fix a build error
Date: Tue, 30 Jan 2024 15:42:08 +0100 [thread overview]
Message-ID: <69d83bad-0e63-4d9f-9638-578f99e1fa7f@linux.intel.com> (raw)
In-Reply-To: <26bde5f6-62a5-494c-b59f-b330eb85f4bb@gmail.com>
On 1/30/24 15:31, Christian König wrote:
> Am 29.01.24 um 21:25 schrieb Thomas Hellström:
>> Hi,
>>
>> On 1/29/24 17:48, Christian König wrote:
>>> Am 27.01.24 um 16:53 schrieb Oak Zeng:
>>>> This fixes a build failure on drm-tip. This issue was introduced
>>>> during
>>>> merge of "drm/ttm: replace busy placement with flags v6". For some
>>>> reason, the xe_bo.c part of above change is not merged. Manually merge
>>>> the missing part to drm_tip
>>>
>>> Mhm, I provided this as manual fixup for drm-tip in this rerere commit:
>>>
>>> commit afc5797e8c03bed3ec47a34f2bc3cf03fce24411
>>> Author: Christian König <christian.koenig@amd.com>
>>> Date: Thu Jan 25 10:44:54 2024 +0100
>>>
>>> 2024y-01m-25d-09h-44m-07s UTC: drm-tip rerere cache update
>>>
>>> git version 2.34.1
>>>
>>>
>>> And for me compiling xe in drm-tip worked fine after that. No idea
>>> why that didn't work for you.
>>>
>>> Anyway feel free to add my rb to this patch here if it helps in any
>>> way.
>>>
>>> Regards,
>>> Christian.
>>
>> I reverted that rerere cache update and added another one, so now it
>> works. Not sure exactly what the difference was, but the resulting
>> patch was for the drm-misc-next merge in my case, and It was for
>> drm-xe-something in your case.
>
> Yeah, I've noticed that this was applied to the drm-xe-something
> branch as well. That's why I reverted and re-applied the patch but dim
> still ended up applying it to drm-xe-something instead of
> drm-misc-next so I thought that this was intentional.
>
> It would be rather nice if somebody can tell me what the heck went
> wrong here so that I don't repeat this mistake.
TBH I'm not completely sure. Sometimes those fixups are not recognized
and applied, which seems to be have been the case here.
But it appears to be important to break the interactive rebuild-tip just
after the merge that brings in the silent conflict. In this case it was
drm-misc-next. Sometimes it might also help to hold off commiting until
drm-misc-next backmerges the recent release series and thus contain all
code that the commit touches.
/Thomas
>
> Thanks,
> Christian.
>
>>
>> /Thomas
>>
>>
>>>
>>>>
>>>> Signed-off-by: Oak Zeng <oak.zeng@intel.com>
>>>> ---
>>>> drivers/gpu/drm/xe/xe_bo.c | 33 +++++++++++++++------------------
>>>> 1 file changed, 15 insertions(+), 18 deletions(-)
>>>>
>>>> diff --git a/drivers/gpu/drm/xe/xe_bo.c b/drivers/gpu/drm/xe/xe_bo.c
>>>> index 686d716c5581..d6a193060cc0 100644
>>>> --- a/drivers/gpu/drm/xe/xe_bo.c
>>>> +++ b/drivers/gpu/drm/xe/xe_bo.c
>>>> @@ -38,22 +38,26 @@ static const struct ttm_place
>>>> sys_placement_flags = {
>>>> static struct ttm_placement sys_placement = {
>>>> .num_placement = 1,
>>>> .placement = &sys_placement_flags,
>>>> - .num_busy_placement = 1,
>>>> - .busy_placement = &sys_placement_flags,
>>>> };
>>>> -static const struct ttm_place tt_placement_flags = {
>>>> - .fpfn = 0,
>>>> - .lpfn = 0,
>>>> - .mem_type = XE_PL_TT,
>>>> - .flags = 0,
>>>> +static const struct ttm_place tt_placement_flags[] = {
>>>> + {
>>>> + .fpfn = 0,
>>>> + .lpfn = 0,
>>>> + .mem_type = XE_PL_TT,
>>>> + .flags = TTM_PL_FLAG_DESIRED,
>>>> + },
>>>> + {
>>>> + .fpfn = 0,
>>>> + .lpfn = 0,
>>>> + .mem_type = XE_PL_SYSTEM,
>>>> + .flags = TTM_PL_FLAG_FALLBACK,
>>>> + }
>>>> };
>>>> static struct ttm_placement tt_placement = {
>>>> - .num_placement = 1,
>>>> - .placement = &tt_placement_flags,
>>>> - .num_busy_placement = 1,
>>>> - .busy_placement = &sys_placement_flags,
>>>> + .num_placement = 2,
>>>> + .placement = tt_placement_flags,
>>>> };
>>>> bool mem_type_is_vram(u32 mem_type)
>>>> @@ -230,8 +234,6 @@ static int __xe_bo_placement_for_flags(struct
>>>> xe_device *xe, struct xe_bo *bo,
>>>> bo->placement = (struct ttm_placement) {
>>>> .num_placement = c,
>>>> .placement = bo->placements,
>>>> - .num_busy_placement = c,
>>>> - .busy_placement = bo->placements,
>>>> };
>>>> return 0;
>>>> @@ -251,7 +253,6 @@ static void xe_evict_flags(struct
>>>> ttm_buffer_object *tbo,
>>>> /* Don't handle scatter gather BOs */
>>>> if (tbo->type == ttm_bo_type_sg) {
>>>> placement->num_placement = 0;
>>>> - placement->num_busy_placement = 0;
>>>> return;
>>>> }
>>>> @@ -1391,8 +1392,6 @@ static int __xe_bo_fixed_placement(struct
>>>> xe_device *xe,
>>>> bo->placement = (struct ttm_placement) {
>>>> .num_placement = 1,
>>>> .placement = place,
>>>> - .num_busy_placement = 1,
>>>> - .busy_placement = place,
>>>> };
>>>> return 0;
>>>> @@ -2150,9 +2149,7 @@ int xe_bo_migrate(struct xe_bo *bo, u32
>>>> mem_type)
>>>> xe_place_from_ttm_type(mem_type, &requested);
>>>> placement.num_placement = 1;
>>>> - placement.num_busy_placement = 1;
>>>> placement.placement = &requested;
>>>> - placement.busy_placement = &requested;
>>>> /*
>>>> * Stolen needs to be handled like below VRAM handling if we
>>>> ever need
>>>
>
prev parent reply other threads:[~2024-01-30 14:42 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-27 15:53 [PATCH] drm/xe: Fix a build error Oak Zeng
2024-01-27 15:46 ` ✓ CI.Patch_applied: success for " Patchwork
2024-01-27 15:46 ` ✓ CI.checkpatch: " Patchwork
2024-01-27 15:47 ` ✓ CI.KUnit: " Patchwork
2024-01-27 15:54 ` ✓ CI.Build: " Patchwork
2024-01-27 15:54 ` ✓ CI.Hooks: " Patchwork
2024-01-27 15:56 ` ✓ CI.checksparse: " Patchwork
2024-01-27 16:23 ` ✗ CI.BAT: failure " Patchwork
2024-01-29 16:48 ` [PATCH] " Christian König
2024-01-29 20:25 ` Thomas Hellström
2024-01-29 20:29 ` Zeng, Oak
2024-01-30 8:15 ` Thomas Hellström
2024-01-30 14:31 ` Christian König
2024-01-30 14:42 ` Thomas Hellström [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=69d83bad-0e63-4d9f-9638-578f99e1fa7f@linux.intel.com \
--to=thomas.hellstrom@linux.intel.com \
--cc=Amaranath.Somalapuram@amd.com \
--cc=ckoenig.leichtzumerken@gmail.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-xe@lists.freedesktop.org \
--cc=lucas.demarchi@intel.com \
--cc=oak.zeng@intel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox