Remove flush_scheduled_work() use from i915

Tetsuo Handa writes in https://lore.kernel.org/r/e170edc2-e5b9-4c8b-4ed3-7e2d7a2850dc@I-love.SAKURA.ne.jp

Like commit c4f135d643823a86 ("workqueue: Wrap flush_workqueue() using a macro") says, flush_scheduled_work() is dangerous and will be forbidden. We are on the way for removing all flush_scheduled_work() callers from the kernel, and there are only 4 callers remaining as of linux-20221104.

drivers/gpu/drm/i915/display/intel_display.c:8997: flush_scheduled_work();

drivers/gpu/drm/i915/gt/selftest_execlists.c:88: flush_scheduled_work();

drivers/md/dm.c:234: flush_scheduled_work();

drivers/message/fusion/mptscsih.c:1234: flush_scheduled_work();

I'm planning to start emitting runtime messages in linux-next.git tree.

The usage in gt/selftest_execlists.c has already been removed in commit 7d33fd02dd94 ("drm/i915/selftests: Remove flush_scheduled_work() from live_execlists"), but display/intel_display.c is still remaining.

Things to figure out:

• Can we get by with just removing the call? Probably not. We schedule so much work on the system workqueue, even figuring this out is hard.
• Can we flush_work() all the work we've scheduled instead? The task would be to figure out everything we schedule, and flush them in the right places. It's ugly to flush everything in place of the flush_scheduled_work() call.
• Or should we create a new local workqueue (or several) for display and queue all of our work there? Or reuse existing i915 local workqueues better? Or a mix of them? We could then flush_workqueue() each of the workqueues, just like we do for flip and modeset workqueues already.

Bottom line, we can't keep using flush_scheduled_work(). It flushes everything on the system workqueue, and it could deadlock.