From: Gustavo Sousa <gustavo.sousa@intel.com>
To: Michal Wajdeczko <michal.wajdeczko@intel.com>,
<intel-xe@lists.freedesktop.org>
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
Subject: Re: [PATCH 4/6] drm/xe: Separate early xe_device initialization
Date: Mon, 25 May 2026 16:00:34 -0300 [thread overview]
Message-ID: <87wlwrgvql.fsf@intel.com> (raw)
In-Reply-To: <87bje3ic4o.fsf@intel.com>
Gustavo Sousa <gustavo.sousa@intel.com> writes:
> Michal Wajdeczko <michal.wajdeczko@intel.com> writes:
>
>> We would like to initialize more of the xe_device struct also from
>> the kunit code, as it should be safe to use most of the generic drm
>> or xe components without doing any additional tweaks. Separate early
>> xe initialization code to a new function, so it can be reused.
>>
>> Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
>> ---
>> drivers/gpu/drm/xe/xe_device.c | 39 ++++++++++++++++++++++++----------
>> drivers/gpu/drm/xe/xe_device.h | 1 +
>> 2 files changed, 29 insertions(+), 11 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/xe/xe_device.c b/drivers/gpu/drm/xe/xe_device.c
>> index b498147dcf61..7ba407f73a02 100644
>> --- a/drivers/gpu/drm/xe/xe_device.c
>> +++ b/drivers/gpu/drm/xe/xe_device.c
>> @@ -506,27 +506,45 @@ struct xe_device *xe_device_create(struct pci_dev *pdev)
>> if (IS_ERR(xe))
>> return xe;
>>
>> + err = xe_device_init_early(xe);
>> + if (err)
>> + return ERR_PTR(err);
>> +
>> + return xe;
>> +}
>> +ALLOW_ERROR_INJECTION(xe_device_create, ERRNO); /* See xe_pci_probe() */
>> +
>> +/**
>> + * xe_device_init_early() - Initialize a new &xe_device instance
>> + * @xe: the &xe_device to initialize
>> + *
>> + * Return: 0 on success or a negative error code on failure.
>> + */
>> +int xe_device_init_early(struct xe_device *xe)
>> +{
>> + int err;
>> +
>> err = ttm_device_init(&xe->ttm, &xe_ttm_funcs, xe->drm.dev,
>> xe->drm.anon_inode->i_mapping,
>> xe->drm.vma_offset_manager, 0);
>> - if (WARN_ON(err))
>> - return ERR_PTR(err);
>> + if (err)
>> + return err;
>>
>> xe_bo_dev_init(&xe->bo_device);
>> err = drmm_add_action_or_reset(&xe->drm, xe_device_destroy, NULL);
>
> Curious: are the drmm_* calls going to work fine for the automated
> teardown when they are called from a kunit context?
>
> What about devm_* calls? From a quick look, I know that at least
> xe_bo_pinned_init() will make one of those.
>
>> if (err)
>> - return ERR_PTR(err);
>> + return err;
>>
>> err = xe_shrinker_create(xe);
>> if (err)
>> - return ERR_PTR(err);
>> + return err;
>>
>> xe->atomic_svm_timeslice_ms = 5;
>> xe->min_run_period_lr_ms = 5;
>>
>> err = xe_irq_init(xe);
>> if (err)
>> - return ERR_PTR(err);
>> + return err;
>>
>> xe_validation_device_init(&xe->val);
>>
>> @@ -536,7 +554,7 @@ struct xe_device *xe_device_create(struct pci_dev *pdev)
>>
>> err = xe_pagemap_shrinker_create(xe);
>> if (err)
>> - return ERR_PTR(err);
>> + return err;
>>
>> xa_init_flags(&xe->usm.asid_to_vm, XA_FLAGS_ALLOC);
>>
>> @@ -555,7 +573,7 @@ struct xe_device *xe_device_create(struct pci_dev *pdev)
>>
>> err = xe_bo_pinned_init(xe);
>> if (err)
>> - return ERR_PTR(err);
>> + return err;
>>
>> xe->preempt_fence_wq = alloc_ordered_workqueue("xe-preempt-fence-wq",
>> WQ_MEM_RECLAIM);
>> @@ -569,16 +587,15 @@ struct xe_device *xe_device_create(struct pci_dev *pdev)
>> * drmm_add_action_or_reset register above
>> */
>> drm_err(&xe->drm, "Failed to allocate xe workqueues\n");
>> - return ERR_PTR(-ENOMEM);
>> + return -ENOMEM;
>> }
>>
>> err = drmm_mutex_init(&xe->drm, &xe->pmt.lock);
>> if (err)
>> - return ERR_PTR(err);
>> + return err;
>>
>> - return xe;
>> + return 0;
>> }
>> -ALLOW_ERROR_INJECTION(xe_device_create, ERRNO); /* See xe_pci_probe() */
>
> So, there are things allocated/initialized in xe_device_create() that
> get deallocated/finalized in xe_device_destroy(). With this change, we
> now have things extracted out of xe_device_create() into
> xe_device_init_early(), and it appears that xe_device_destroy() is now
> really the counterpart of the latter than the former.
>
> I think we should just call the function xe_device_init() and then
I guess it could still be called xe_device_init_early() for consistenty
with the naming for the other components of the driver, but I would
still rename xe_device_destroy() to xe_device_fini() to avoid people
mistakenly pairing it with xe_device_create().
Honestly, I think I prefer much more a _init_nohw() suffix than
_init_early(); that way we can pair with _fini_nohw() (as _fini_early()
would be a bit innacurate or ambiguous IMO). But that's a bit
off-topic...
--
Gustavo Sousa
> rename xe_device_destroy() to xe_device_fini().
>
>>
>> static bool xe_driver_flr_disabled(struct xe_device *xe)
>> {
>> diff --git a/drivers/gpu/drm/xe/xe_device.h b/drivers/gpu/drm/xe/xe_device.h
>> index 27cd2329b99f..975768a6a9c8 100644
>> --- a/drivers/gpu/drm/xe/xe_device.h
>> +++ b/drivers/gpu/drm/xe/xe_device.h
>> @@ -44,6 +44,7 @@ static inline struct xe_device *ttm_to_xe_device(struct ttm_device *ttm)
>> }
>>
>> struct xe_device *xe_device_create(struct pci_dev *pdev);
>> +int xe_device_init_early(struct xe_device *xe);
>
> Right now we do not have any external users for this function. We could
> keep it static until we get to use them in kunit.
>
> That said, I think it would also make sense to separate it completely
> from xe_device_create(), i.e., have xe_pci.c call the two functions
> instead of xe_device_init_early() being implicitly called by
> xe_device_create(). I think that would be more alligned with the
> function names.
>
> --
> Gustavo Sousa
>
>> int xe_device_probe_early(struct xe_device *xe);
>> int xe_device_probe(struct xe_device *xe);
>> void xe_device_remove(struct xe_device *xe);
>> --
>> 2.47.1
next prev parent reply other threads:[~2026-05-25 19:00 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-25 16:05 [PATCH 0/6] drm/xe: Misc initialization improvements Michal Wajdeczko
2026-05-25 16:05 ` [PATCH 1/6] drm/xe: Drop unused param from xe_device_create() Michal Wajdeczko
2026-05-25 18:13 ` Raag Jadav
2026-05-25 18:45 ` Gustavo Sousa
2026-05-25 16:05 ` [PATCH 2/6] drm/xe: Move xe->info.force_execlist initialization Michal Wajdeczko
2026-05-25 18:46 ` Gustavo Sousa
2026-05-25 16:05 ` [PATCH 3/6] drm/xe: Move xe->info.devid|revid initialization Michal Wajdeczko
2026-05-25 17:47 ` Gustavo Sousa
2026-05-25 18:25 ` Michal Wajdeczko
2026-05-25 19:12 ` Gustavo Sousa
2026-05-25 19:41 ` [PATCH v2 " Michal Wajdeczko
2026-05-25 20:01 ` Gustavo Sousa
2026-05-25 16:05 ` [PATCH 4/6] drm/xe: Separate early xe_device initialization Michal Wajdeczko
2026-05-25 18:21 ` Gustavo Sousa
2026-05-25 18:57 ` Michal Wajdeczko
2026-05-25 19:05 ` Gustavo Sousa
2026-05-25 19:00 ` Gustavo Sousa [this message]
2026-05-25 19:14 ` Michal Wajdeczko
2026-05-25 18:22 ` Raag Jadav
2026-05-25 16:05 ` [PATCH 5/6] drm/xe/pm: Don't access device in init_early() Michal Wajdeczko
2026-05-25 18:30 ` Raag Jadav
2026-05-25 18:47 ` Gustavo Sousa
2026-05-27 15:46 ` Rodrigo Vivi
2026-05-25 16:05 ` [PATCH 6/6] drm/xe/pm: Do early initialization " Michal Wajdeczko
2026-05-25 18:47 ` Gustavo Sousa
2026-05-25 16:36 ` ✓ CI.KUnit: success for drm/xe: Misc initialization improvements Patchwork
2026-05-25 17:42 ` ✓ Xe.CI.BAT: " Patchwork
2026-05-25 19:48 ` ✓ CI.KUnit: success for drm/xe: Misc initialization improvements (rev2) Patchwork
2026-05-25 20:49 ` ✓ Xe.CI.BAT: " Patchwork
2026-05-26 1:59 ` ✓ Xe.CI.FULL: " 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=87wlwrgvql.fsf@intel.com \
--to=gustavo.sousa@intel.com \
--cc=intel-xe@lists.freedesktop.org \
--cc=michal.wajdeczko@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 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.