On 12-06-2025 17:24, Usyskin, Alexander wrote:
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.nila...@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.
Sure I will change the intervals.
Regards,
Badal
- -
Thanks,
Sasha