Intel-XE Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: "Thomas Hellström" <thomas.hellstrom@linux.intel.com>
To: "Zeng, Oak" <oak.zeng@intel.com>,
	"Christian König" <ckoenig.leichtzumerken@gmail.com>,
	"dri-devel@lists.freedesktop.org"
	<dri-devel@lists.freedesktop.org>,
	"intel-xe@lists.freedesktop.org" <intel-xe@lists.freedesktop.org>
Cc: "Amaranath.Somalapuram@amd.com" <Amaranath.Somalapuram@amd.com>,
	"De Marchi, Lucas" <lucas.demarchi@intel.com>
Subject: Re: [PATCH] drm/xe: Fix a build error
Date: Tue, 30 Jan 2024 09:15:45 +0100	[thread overview]
Message-ID: <f1ad0bcb-c7e0-4c56-9982-38362bb70d56@linux.intel.com> (raw)
In-Reply-To: <SA1PR11MB6991072A876ED10A0CEE193F927E2@SA1PR11MB6991.namprd11.prod.outlook.com>

Hi, Oak

On 1/29/24 21:29, Zeng, Oak wrote:
> Hi Thomas,
>
> My patch was based on drm-tip.... because I found drm-tip is broken....

Yes, but drm-tip is rebuilt and force-pushed every time any of the 
merged branches adds a new commit, so any commit needs to land in any of 
the included branches, and when that is not possible because of 
interdependencies, it needs to land in a merge commit, or a separate 
"fixup" to a merge.

All described here:

https://drm.pages.freedesktop.org/maintainer-tools/drm-tip.html#

What was happening in this case was that the "fixup" Christian had added 
somehow didn't work, so I removed it and added a new one. We never apply 
patches directly on drm-tip.

/Thomas


>
> As long as drm-tip can build, I am all good.
>
> Thanks,
> Oak
>
>> -----Original Message-----
>> From: Thomas Hellström <thomas.hellstrom@linux.intel.com>
>> Sent: Monday, January 29, 2024 3:26 PM
>> To: Christian König <ckoenig.leichtzumerken@gmail.com>; Zeng, Oak
>> <oak.zeng@intel.com>; dri-devel@lists.freedesktop.org; intel-
>> xe@lists.freedesktop.org
>> Cc: Amaranath.Somalapuram@amd.com; De Marchi, Lucas
>> <lucas.demarchi@intel.com>
>> Subject: Re: [PATCH] drm/xe: Fix a build error
>>
>> 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.
>>
>> /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

  reply	other threads:[~2024-01-30  8:15 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 [this message]
2024-01-30 14:31     ` Christian König
2024-01-30 14:42       ` Thomas Hellström

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=f1ad0bcb-c7e0-4c56-9982-38362bb70d56@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