[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