Re: [PATCH v2] drm/xe/ufence: Flush xe ordered_wq in case of ufence timeout

[Matthew Brost <matthew.brost@intel.com>]

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