On Fri, Oct 25, 2024 at 06:06:47PM +0200, Nirmoy Das wrote:

On 10/24/2024 7:22 PM, Matthew Brost wrote:

On Thu, Oct 24, 2024 at 10:14:21AM -0700, John Harrison wrote:

On 10/24/2024 08:18, Nirmoy Das wrote:

Flush xe ordered_wq in case of ufence timeout which is observed on LNL and that points to the recent scheduling issue with E-cores.

This is similar to the recent fix: commit e51527233804 ("drm/xe/guc/ct: Flush g2h worker in case of g2h response timeout") and should be removed once there is E core scheduling fix.

v2: Add platform check(Himal) s/__flush_workqueue/flush_workqueue(Jani)

Cc: Badal Nilawar [1]badal.nilawar@intel.com Cc: Jani Nikula [2]jani.nikula@intel.com Cc: Matthew Auld [3]matthew.auld@intel.com Cc: John Harrison [4]John.C.Harrison@Intel.com Cc: Himal Prasad Ghimiray [5]himal.prasad.ghimiray@intel.com Cc: Lucas De Marchi [6]lucas.demarchi@intel.com Cc: [7]stable@vger.kernel.org # v6.11+ Link: [8]https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/2754 Suggested-by: Matthew Brost [9]matthew.brost@intel.com Signed-off-by: Nirmoy Das [10]nirmoy.das@intel.com Reviewed-by: Matthew Brost [11]matthew.brost@intel.com

---

drivers/gpu/drm/xe/xe_wait_user_fence.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+)

diff --git a/drivers/gpu/drm/xe/xe_wait_user_fence.c b/drivers/gpu/drm/xe/xe_wai t_user_fence.c index f5deb81eba01..78a0ad3c78fe 100644 --- a/drivers/gpu/drm/xe/xe_wait_user_fence.c +++ b/drivers/gpu/drm/xe/xe_wait_user_fence.c @@ -13,6 +13,7 @@ #include "xe_device.h" #include "xe_gt.h" #include "xe_macros.h" +#include "compat-i915-headers/i915_drv.h" #include "xe_exec_queue.h" static int do_compare(u64 addr, u64 value, u64 mask, u16 op) @@ -155,6 +156,19 @@ int xe_wait_user_fence_ioctl(struct drm_device *dev, void * data, } if (!timeout) {

•                   if (IS_LUNARLAKE(xe)) {
  

•                           /*
  

•                            * This is analogous to e51527233804 ("drm/xe/gu
  

c/ct: Flush g2h

•                            * worker in case of g2h response timeout")
  

•                            *
  

•                            * TODO: Drop this change once workqueue schedul
  

ing delay issue is

•                            * fixed on LNL Hybrid CPU.
  

•                            */
  

•                           flush_workqueue(xe->ordered_wq);
  
  

If we are having multiple instances of this workaround, can we wrap them up in as 'LNL_FLUSH_WORKQUEUE(q)' or some such? Put the IS_LNL check inside the macro and make it pretty obvious exactly where all the instances are by having a single macro name to search for.

+1, I think Lucas is suggesting something similar to this on the chat to make sure we don't lose track of removing these W/A when this gets fixed.

Matt

Sounds good. I will add LNL_FLUSH_WORKQUEUE() and use that for all the places we need this WA.

You will need 2 macros...

- LNL_FLUSH_WORKQUEUE() which accepts xe_device, workqueue_struct - LNL_FLUSH_WORK() which accepts xe_device, work_struct

Matt

Regards,

Nirmoy

John.

•                           err = do_compare(addr, args->value, args->mask,
  

args->op);

•                           if (err <= 0)
  

•                                   break;
  

•                   }
                    err = -ETIME;
                    break;
            }
  
  

References

1. mailto:badal.nilawar@intel.com
2. mailto:jani.nikula@intel.com
3. mailto:matthew.auld@intel.com
4. mailto:John.C.Harrison@Intel.com
5. mailto:himal.prasad.ghimiray@intel.com
6. mailto:lucas.demarchi@intel.com
7. mailto:stable@vger.kernel.org
8. https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/2754
9. mailto:matthew.brost@intel.com
10. mailto:nirmoy.das@intel.com
11. mailto:matthew.brost@intel.com