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

["Vivekanandan, Balasubramani" <balasubramani.vivekanandan@intel.com>]

On 18.12.2025 17:57, Ville Syrjälä wrote:
> 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.

In the upcoming platforms, there are changes in the register bits driver
has to check to sync with the fw initialization. For that I had to
modify the lmem init check function and it was getting complex.
That is when I figured out there is no need for this lmem init check
after xe_pcode_ready() and so decided to discard it.
After review, it looks like I have to change it into an assert.

Regards,
Bala

> 
> -- 
> Ville Syrjälä
> Intel