[PATCH v2 05/10] drm/xe/xe_late_bind_fw: Load late binding firmware

Usyskin, Alexander alexander.usyskin at intel.com
Thu Jun 12 11:54:38 UTC 2025


> Subject: Re: [PATCH v2 05/10] drm/xe/xe_late_bind_fw: Load late binding
> firmware
> 
> 
> 
> On 6/6/2025 10:57 AM, Badal Nilawar wrote:
> > Load late binding firmware
> >
> > v2:
> >   - s/EAGAIN/EBUSY/
> >   - Flush worker in suspend and driver unload (Daniele)
> >
> > Signed-off-by: Badal Nilawar <badal.nilawar at intel.com>
> > ---
> >   drivers/gpu/drm/xe/xe_late_bind_fw.c       | 121
> ++++++++++++++++++++-
> >   drivers/gpu/drm/xe/xe_late_bind_fw.h       |   1 +
> >   drivers/gpu/drm/xe/xe_late_bind_fw_types.h |   5 +
> >   3 files changed, 126 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/xe/xe_late_bind_fw.c
> b/drivers/gpu/drm/xe/xe_late_bind_fw.c
> > index 0231f3dcfc18..7fe304c54374 100644
> > --- a/drivers/gpu/drm/xe/xe_late_bind_fw.c
> > +++ b/drivers/gpu/drm/xe/xe_late_bind_fw.c
> > @@ -16,6 +16,16 @@
> >   #include "xe_late_bind_fw.h"
> >   #include "xe_pcode.h"
> >   #include "xe_pcode_api.h"
> > +#include "xe_pm.h"
> > +
> > +/*
> > + * The component should load quite quickly in most cases, but it could take
> > + * a bit. Using a very big timeout just to cover the worst case scenario
> > + */
> > +#define LB_INIT_TIMEOUT_MS 20000
> > +
> > +#define LB_FW_LOAD_RETRY_MAXCOUNT 40
> > +#define LB_FW_LOAD_RETRY_PAUSE_MS 50
> 
> Are those retry values spec'd anywhere? For GSC we use those because the
> GSC specs say to retry in 50ms intervals for up to 2 secs to give time
> for the GSC to do proxy handling. Does it make sense to do the same in
> this case, given that there is no proxy involved?
> 
Here 50ms is too small, we are waiting for other OS components to release handle.
We usually have 3 times 2 sec in user-space, but it is too big for kernel,
let's do 200ms step up to 6 sec.

- - 
Thanks,
Sasha


More information about the dri-devel mailing list