[PATCH 8/8] drm/xe: Split init of xe_gt_init_hwconfig to xe_gt_init and *_early

[Lucas De Marchi]

On Thu, Mar 13, 2025 at 08:23:18PM +0100, Maarten Lankhorst wrote:
>Hey,
>
>On 2025-03-13 15:28, Lucas De Marchi wrote:
>> On Thu, Mar 13, 2025 at 10:19:58AM +0100, Maarten Lankhorst wrote:
>>> Hey,
>>>
>>> On 2025-03-11 21:55, Lucas De Marchi wrote:
>>>> On Mon, Mar 10, 2025 at 09:06:53PM +0100, Maarten Lankhorst wrote:
>>>>> static void xe_gt_fini(void *arg)
>>>>> @@ -471,6 +451,18 @@ int xe_gt_init(struct xe_gt *gt)
>>>>>     if (!fw_ref)
>>>>>         return -ETIMEDOUT;
>>>>>
>>>>> +    err = xe_uc_init(&gt->uc);
>>>>> +    if (err)
>>>>> +        goto err_force_wake;
>>>>> +
>>>>> +    err = xe_uc_init_hwconfig(&gt->uc);
>>>>> +    if (err)
>>>>> +        goto err_force_wake;
>>>>
>>>> humn... why are these 2 variants not merged together then?
>>>>
>>>> at the end of this series I don't know what to expect. Is everything
>>>> here sufficient or is this part of what we need?
>>> That's a good question, makes sense to merge those 2 calls.
>>>
>>> I haven't done it yet was because I was trying to solve the issue of flickering. If it turns things
>>> break, then  I want to ensure that we could undo the patches.
>>
>> and does this series alone, without additional patches, fixes it?
>> Correct. With this series the flickering is gone. Display is able to be the first to allocate memory and GGTT space, so it can safely recover the initial BIOS fb.
>
>For paranoia, we probably should move the xe_ttm_sys_mgr_init() a bit lower just before xe_vram_probe().
>Maybe I should rename xe_tile_init_noalloc to xe_tile_probe_vram() as well to make things more clear.

I've tested this series on RPL on top of current drm-xe-next and
apparently it worked well, without any flickering.

Lucas De Marchi