Re: [PATCH] drm/xe/device: Discard check for lmem_init

["Ville Syrjälä" <ville.syrjala@linux.intel.com>]

On Wed, Dec 17, 2025 at 03:12:29PM -0800, Matt Roper wrote:
> On Wed, Dec 17, 2025 at 06:21:43PM +0530, Balasubramani Vivekanandan wrote:
> > Prior to lmem init check, driver is waiting for the pcode uncore_init
> > status. uncore_init status will be asserted after the complete boot and
> > initialization of the SoC by the pcode. uncore_init confirms that lmem
> > init and mmio unblock has been already completed.
> > It makes no sense to check for lmem init after the pcode uncore_init
> > check. So it can be removed.
> 
> While I think this should be fine on our current platforms, one thing
> that worries me is that we'll bypass xe_pcode_ready() if we ever have a
> device that sets skip_pcode in xe_pci.c.  No such device exists today,
> but if one shows up in the future it may not be obvious when enabling
> the platform that we'd need to add back the GU_CNTL check (or something
> equivalent).
> 
> A couple thoughts:
> 
>  - Maybe we should have an initial patch that drops 'skip_pcode' from
>    xe_device_desc since it's not being used today.  If it becomes
>    necessary in the future, then we can easily re-add it, and the
>    process of doing so may help remind us that we also need to do other
>    checks to make sure the device/lmem is fully initialized and ready to
>    use.
> 
>  - Maybe we should replace wait_for_lmem_ready() with an
>    "assert_lmem_ready()" function that will just do a quick sanity check
>    on debug builds.
> 
>         static void assert_lmem_ready(struct xe_device *xe) {
>                 if (!IS_DGFX(xe) || IS_SRIOV_VF(xe))
>                         return;
> 
>                 xe_assert(xe, xe_mmio_read32(xe_root_tile_mmio(xe), GU_CNTL) & LMEM_INIT);
>         }
> 
>    That eliminates all the looping/polling logic, but still helps make
>    sure we don't miss anything if we ever need to skip the pcode step on
>    a future platform (or if the init flows change and our ordering
>    assumptions are no longer true).  And since it's an xe_assert() it's
>    only active on debug/CI builds and will be compiled out on release
>    builds.

This stuff doesn't look performance critical in any way,
so there is no good reason to compile it out from release
builds.

-- 
Ville Syrjälä
Intel