On Fri, 2023-09-01 at 17:04 +0300, Imre Deak wrote:
On some i915 platforms at least the HPD poll work involves I2C bit-banging using udelay()s to probe for monitor EDIDs. This in turn may trigger the
workqueue: output_poll_execute [drm_kms_helper] hogged CPU for
10000us 4 times, consider switching to WQ_UNBOUND
warning. Fix this by scheduling drm_mode_config::output_poll_work on a WQ_UNBOUND workqueue.
Cc: Tejun Heo tj@kernel.org Cc: Heiner Kallweit hkallweit1@gmail.com CC: stable@vger.kernel.org # 6.5 Cc: dri-devel@lists.freedesktop.org Suggested-by: Tejun Heo tj@kernel.org Suggested-by: Heiner Kallweit hkallweit1@gmail.com Reported-by: Heiner Kallweit hkallweit1@gmail.com Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/9245 Link: https://lore.kernel.org/all/f7e21caa-e98d-e5b5-932a-fe12d27fde9b@gmail.com Signed-off-by: Imre Deak imre.deak@intel.com
drivers/gpu/drm/drm_probe_helper.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_probe_helper.c b/drivers/gpu/drm/drm_probe_helper.c index 3f479483d7d80..72eac0cd25e74 100644 --- a/drivers/gpu/drm/drm_probe_helper.c +++ b/drivers/gpu/drm/drm_probe_helper.c @@ -279,7 +279,8 @@ static void reschedule_output_poll_work(struct drm_device *dev) */ delay = HZ;
- schedule_delayed_work(&dev->mode_config.output_poll_work,
delay);
- queue_delayed_work(system_unbound_wq,
&dev->mode_config.output_poll_work,
delay); } /** @@ -614,7 +615,7 @@ int drm_helper_probe_single_connector_modes(struct drm_connector *connector, */ dev->mode_config.delayed_event = true; if (dev->mode_config.poll_enabled)
mod_delayed_work(system_wq,
mod_delayed_work(system_unbound_wq,
&dev-
mode_config.output_poll_work,
0); } @@ -838,7 +839,8 @@ static void output_poll_execute(struct work_struct *work) drm_kms_helper_hotplug_event(dev); if (repoll)
schedule_delayed_work(delayed_work,
DRM_OUTPUT_POLL_PERIOD);
queue_delayed_work(system_unbound_wq,
delayed_work,
DRM_OUTPUT_POLL_PERIOD); } /**
Hello all,
why was this patch never included? Especially this 2/2 seems to solve a latency issue we are observing: the work can last milliseconds and run on isolated cores, affecting latency requirements in some real time scenarios (e.g. oslat).
Thanks, Gabriele