kernel/linux.git/drivers/gpu/drm/i915/display/intel_hotplug.c, branch linux-6.9.y

drm/i915: Disable hotplug detection works during driver init/shutdown

2024-01-08T16:56:45+00:00

As described in the previous patch, an unexpected connector detection/modeset started from the intel_hotplug::hotplug_work can happen during the driver init/shutdown sequence. Prevent these by disabling the queuing of and flushing all the intel_hotplug work that can start them at the beginning of the init/shutdown sequence and allow the queuing only while the display is in the initialized state. Other work items - like the intel_connector::modeset_retry_work or the MST probe works - are still enabled and can start a detection/modeset, but after the previous patch these will be rejected. Disabling these works as well is for a follow-up patchset. Link: https://patchwork.freedesktop.org/patch/msgid/20240104083008.2715733-9-imre.deak@intel.com Reviewed-by: Jouni Högander Signed-off-by: Imre Deak

drm/i915: Keep the connector polled state disabled after storm

2024-01-08T16:51:31+00:00

If an HPD IRQ storm is detected on a connector during driver loading or system suspend/resume - disabling the IRQ and switching to polling - the polling may get disabled too early - before the intended 2 minute HPD_STORM_REENABLE_DELAY - with the HPD IRQ staying disabled for this duration. One such sequence is: Thread#1 Thread#2 intel_display_driver_probe()-> intel_hpd_init()-> (HPD IRQ gets enabled) . intel_hpd_irq_handler()-> . intel_hpd_irq_storm_detect() . intel_hpd_irq_setup()-> . (HPD IRQ gets disabled) . queue_delayed_work(hotplug.hotplug_work) . ... . i915_hotplug_work_func()-> . intel_hpd_irq_storm_switch_to_polling()-> . (polling enabled) . intel_hpd_poll_disable()-> queue_work(hotplug.poll_init_work) ... i915_hpd_poll_init_work()-> (polling gets disabled, HPD IRQ is still disabled) ... (Connector is neither polled or detected via HPD IRQs for 2 minutes) intel_hpd_irq_storm_reenable_work()-> (HPD IRQ gets enabled) To avoid the above 2 minute state without either polling or enabled HPD IRQ, leave the connector's polling mode unchanged in i915_hpd_poll_init_work() if its HPD IRQ got disabled after an IRQ storm indicated by the connector's HPD_DISABLED pin state. Link: https://patchwork.freedesktop.org/patch/msgid/20240104083008.2715733-3-imre.deak@intel.com Reviewed-by: Jouni Högander Signed-off-by: Imre Deak

drm/i915: convert INTEL_DISPLAY_ENABLED() into a function

2023-10-04T09:40:39+00:00

There's no need for this to be a macro. Add some documentation too. Signed-off-by: Jani Nikula Reviewed-by: Ville Syrjälä Link: https://patchwork.freedesktop.org/patch/msgid/480b9b697b2ffa0c8677115bd443ba633801c6c1.1696336887.git.jani.nikula@intel.com

drm/i915: Fix HPD polling, reenabling the output poll work as needed

2023-08-23T19:25:09+00:00

After the commit in the Fixes: line below, HPD polling stopped working on i915, since after that change calling drm_kms_helper_poll_enable() doesn't restart drm_mode_config::output_poll_work if the work was stopped (no connectors needing polling) and enabling polling for a connector (during runtime suspend or detecting an HPD IRQ storm). After the above change calling drm_kms_helper_poll_enable() is a nop after it's been called already and polling for some connectors was disabled/re-enabled. Fix this by calling drm_kms_helper_poll_reschedule() added in the previous patch instead, which reschedules the work whenever expected. Fixes: d33a54e3991d ("drm/probe_helper: sort out poll_running vs poll_enabled") CC: stable@vger.kernel.org # 6.4+ Cc: Dmitry Baryshkov Cc: dri-devel@lists.freedesktop.org Reviewed-by: Jouni Högander Signed-off-by: Imre Deak Link: https://patchwork.freedesktop.org/patch/msgid/20230822113015.41224-2-imre.deak@intel.com

drm/i915: Don't change the status of forced connectors during HPD poll detect

2023-08-11T13:08:53+00:00

As described in the previous patch a connector shouldn't change its status while it's forced to a connected/disconnected state. This can still happen while running the connector detect function to account for lost HPD events in a low-power state. Fix this by reusing the connector detect function which handles a hotplug event and prevents updating the status for forced connectors as expected. Testcase: igt@kms_force_connector_basic@force-connector-state Signed-off-by: Imre Deak Reviewed-by: Jouni Högander Link: https://patchwork.freedesktop.org/patch/msgid/20230809104307.1218058-3-imre.deak@intel.com

drm/i915: Don't change the status of forced connectors during hotplug detect

2023-08-11T13:08:53+00:00

DRM display connectors forced to a connected/disconnected state via the drm_connector::force member shouldn't change their status. Atm, this can still happen in the connector's detect function when called to handle a hotplug event. This in turn may lead to the GETCONNECTOR ioctl to report the incorrect state if it's called to return the connector properties without doing an actual detection (by calling the ioctl with a non-zero drm_mode_get_connector::count_modes). Fix the above by updating the connector state during hotplug detect only if the connector state is not forced. Testcase: igt@kms_force_connector_basic@force-connector-state Signed-off-by: Imre Deak Reviewed-by: Jouni Högander Link: https://patchwork.freedesktop.org/patch/msgid/20230809104307.1218058-2-imre.deak@intel.com

drm/i915: Avoid endless HPD poll detect loop via runtime suspend/resume

2023-08-11T13:08:52+00:00

The issue fixed in commit a8ddac7c9f06 ("drm/i915: Avoid HPD poll detect triggering a new detect cycle") on VLV, CHV is still present on platforms where the display hotplug detection functionality is available whenever the device is in D0 state (hence these platforms switch to HPD polling only when the device is runtime suspended). The above commit avoids an endless i915_hpd_poll_init_work() -> connector detect loop by making sure that by the end of i915_hpd_poll_init_work() all display power references acquired by the connector detect functions which can trigger a new cycle (display core power domain) are dropped. However on platforms where HPD polling is enabled/disabled only from the runtime suspend/resume handlers, this is not ensured: for instance eDP VDD, TypeC port PHYs and the runtime autosuspend delay may still keep the device runtime resumed (via a power reference acquired during connector detection and hence result in an endless loop like the above). Solve the problem described in the above commit on all platforms, by making sure that a i915_hpd_poll_init_work() -> connector detect sequence can't take any power reference in the first place which would trigger a new cycle, instead of relying on these power references to be dropped by the end of the sequence. With the default runtime autosuspend delay (10 sec) this issue didn't happen in practice, since the device remained runtime resumed for the whole duration of the above sequence. CI/IGT tests however set the autosuspend delay to 0, which makes the problem visible, see References: below. Tested on GLK, CHV. v2: Don't warn about a requeued work, to account for disabling polling directly during driver loading, reset and system resume. References: https://gitlab.freedesktop.org/drm/intel/-/issues/7940#note_1997403 Signed-off-by: Imre Deak Reviewed-by: Jouni Högander Link: https://patchwork.freedesktop.org/patch/msgid/20230809104307.1218058-1-imre.deak@intel.com

i915/display/hotplug: use drm_kms_helper_connector_hotplug_event()

2023-07-11T09:48:40+00:00

This adds more information to the hotplug uevent and lets user-space know that it's about a particular connector only. v2: don't rely on the changed HPD pin bitmask to count changed connectors (Jani) Signed-off-by: Simon Ser Cc: Jani Nikula Cc: Ville Syrjälä Cc: Rodrigo Vivi Cc: Gustavo Sousa Cc: Imre Deak Cc: Lucas De Marchi Reviewed-by: Jani Nikula Signed-off-by: Jani Nikula Link: https://patchwork.freedesktop.org/patch/msgid/20230623094229.120264-1-contact@emersion.fr

drm/i915: add a dedicated workqueue inside drm_i915_private

2023-06-10T03:33:11+00:00

In order to avoid flush_scheduled_work() usage, add a dedicated workqueue in the drm_i915_private structure. In this way, we don't need to use the system queue anymore. This change is mostly mechanical and based on Tetsuo's original patch[1]. v6 by Jani: - Also create unordered_wq for mock device Link: https://patchwork.freedesktop.org/series/114608/ [1] Cc: Tetsuo Handa Cc: Tvrtko Ursulin Cc: Jani Nikula Cc: Ville Syrjälä Reviewed-by: Jani Nikula Reviewed-by: Tvrtko Ursulin Signed-off-by: Luca Coelho Signed-off-by: Jani Nikula Link: https://patchwork.freedesktop.org/patch/msgid/c816ebe17ef08d363981942a096a586a7658a65e.1686231190.git.jani.nikula@intel.com

drm/i915/irq: split out hotplug irq handling

2023-05-16T07:31:22+00:00

Split hotplug irq handling out of i915_irq.[ch] into display/intel_hotplug_irq.[ch]. The line between the new intel_hotplug_irq.[ch] and the existing intel_hotplug.[ch] needs further clarification, but the first step is to move the stuff out of i915_irq.[ch]. Reviewed-by: Rodrigo Vivi Reviewed-by: Gustavo Sousa Signed-off-by: Jani Nikula Link: https://patchwork.freedesktop.org/patch/msgid/20230515101738.2399816-2-jani.nikula@intel.com