2015-06-18 13:06:16 +03:00
|
|
|
/*
|
|
|
|
* Copyright © 2015 Intel Corporation
|
|
|
|
*
|
|
|
|
* Permission is hereby granted, free of charge, to any person obtaining a
|
|
|
|
* copy of this software and associated documentation files (the "Software"),
|
|
|
|
* to deal in the Software without restriction, including without limitation
|
|
|
|
* the rights to use, copy, modify, merge, publish, distribute, sublicense,
|
|
|
|
* and/or sell copies of the Software, and to permit persons to whom the
|
|
|
|
* Software is furnished to do so, subject to the following conditions:
|
|
|
|
*
|
|
|
|
* The above copyright notice and this permission notice (including the next
|
|
|
|
* paragraph) shall be included in all copies or substantial portions of the
|
|
|
|
* Software.
|
|
|
|
*
|
|
|
|
* THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
|
|
|
|
* IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
|
|
|
|
* FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
|
|
|
|
* THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
|
|
|
|
* LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
|
|
|
|
* FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
|
|
|
|
* IN THE SOFTWARE.
|
|
|
|
*/
|
|
|
|
|
2024-08-27 13:45:21 +03:00
|
|
|
#include <linux/debugfs.h>
|
2015-06-18 13:06:16 +03:00
|
|
|
#include <linux/kernel.h>
|
|
|
|
|
2024-08-26 19:31:16 +03:00
|
|
|
#include <drm/drm_probe_helper.h>
|
|
|
|
|
2015-06-18 13:06:16 +03:00
|
|
|
#include "i915_drv.h"
|
2022-02-03 16:02:29 +02:00
|
|
|
#include "i915_irq.h"
|
2025-02-13 17:02:13 +02:00
|
|
|
#include "intel_connector.h"
|
drm/i915: Avoid endless HPD poll detect loop via runtime suspend/resume
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 <imre.deak@intel.com>
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230809104307.1218058-1-imre.deak@intel.com
2023-08-09 13:43:05 +03:00
|
|
|
#include "intel_display_power.h"
|
2025-05-22 12:48:43 +03:00
|
|
|
#include "intel_display_core.h"
|
2025-03-20 17:03:58 +02:00
|
|
|
#include "intel_display_rpm.h"
|
2019-08-06 14:39:33 +03:00
|
|
|
#include "intel_display_types.h"
|
2025-06-09 15:55:56 +03:00
|
|
|
#include "intel_dp.h"
|
2025-02-13 17:02:13 +02:00
|
|
|
#include "intel_hdcp.h"
|
2019-04-29 15:50:11 +03:00
|
|
|
#include "intel_hotplug.h"
|
2023-05-15 13:17:37 +03:00
|
|
|
#include "intel_hotplug_irq.h"
|
2015-06-18 13:06:16 +03:00
|
|
|
|
2015-07-02 16:05:28 +03:00
|
|
|
/**
|
|
|
|
* DOC: Hotplug
|
|
|
|
*
|
|
|
|
* Simply put, hotplug occurs when a display is connected to or disconnected
|
|
|
|
* from the system. However, there may be adapters and docking stations and
|
|
|
|
* Display Port short pulses and MST devices involved, complicating matters.
|
|
|
|
*
|
|
|
|
* Hotplug in i915 is handled in many different levels of abstraction.
|
|
|
|
*
|
|
|
|
* The platform dependent interrupt handling code in i915_irq.c enables,
|
|
|
|
* disables, and does preliminary handling of the interrupts. The interrupt
|
|
|
|
* handlers gather the hotplug detect (HPD) information from relevant registers
|
|
|
|
* into a platform independent mask of hotplug pins that have fired.
|
|
|
|
*
|
|
|
|
* The platform independent interrupt handler intel_hpd_irq_handler() in
|
|
|
|
* intel_hotplug.c does hotplug irq storm detection and mitigation, and passes
|
|
|
|
* further processing to appropriate bottom halves (Display Port specific and
|
|
|
|
* regular hotplug).
|
|
|
|
*
|
|
|
|
* The Display Port work function i915_digport_work_func() calls into
|
|
|
|
* intel_dp_hpd_pulse() via hooks, which handles DP short pulses and DP MST long
|
|
|
|
* pulses, with failures and non-MST long pulses triggering regular hotplug
|
|
|
|
* processing on the connector.
|
|
|
|
*
|
|
|
|
* The regular hotplug work function i915_hotplug_work_func() calls connector
|
|
|
|
* detect hooks, and, if connector status changes, triggers sending of hotplug
|
|
|
|
* uevent to userspace via drm_kms_helper_hotplug_event().
|
|
|
|
*
|
|
|
|
* Finally, the userspace is responsible for triggering a modeset upon receiving
|
|
|
|
* the hotplug uevent, disabling or enabling the crtc as needed.
|
|
|
|
*
|
|
|
|
* The hotplug interrupt storm detection and mitigation code keeps track of the
|
|
|
|
* number of interrupts per hotplug pin per a period of time, and if the number
|
|
|
|
* of interrupts exceeds a certain threshold, the interrupt is disabled for a
|
|
|
|
* while before being re-enabled. The intention is to mitigate issues raising
|
|
|
|
* from broken hardware triggering massive amounts of interrupts and grinding
|
|
|
|
* the system to a halt.
|
2015-07-10 12:30:43 +05:30
|
|
|
*
|
|
|
|
* Current implementation expects that hotplug interrupt storm will not be
|
|
|
|
* seen when display port sink is connected, hence on platforms whose DP
|
|
|
|
* callback is handled by i915_digport_work_func reenabling of hpd is not
|
|
|
|
* performed (it was never expected to be disabled in the first place ;) )
|
|
|
|
* this is specific to DP sinks handled by this routine and any other display
|
|
|
|
* such as HDMI or DVI enabled on the same port will have proper logic since
|
|
|
|
* it will use i915_hotplug_work_func where this logic is handled.
|
2015-07-02 16:05:28 +03:00
|
|
|
*/
|
|
|
|
|
2017-08-11 11:26:50 -07:00
|
|
|
/**
|
2018-01-29 15:22:21 -08:00
|
|
|
* intel_hpd_pin_default - return default pin associated with certain port.
|
2017-08-11 11:26:50 -07:00
|
|
|
* @port: the hpd port to get associated pin
|
|
|
|
*
|
2018-01-29 15:22:21 -08:00
|
|
|
* It is only valid and used by digital port encoder.
|
|
|
|
*
|
2020-07-01 00:55:59 +03:00
|
|
|
* Return pin that is associatade with @port.
|
2017-08-11 11:26:50 -07:00
|
|
|
*/
|
2025-02-12 18:36:35 +02:00
|
|
|
enum hpd_pin intel_hpd_pin_default(enum port port)
|
2017-08-11 11:26:50 -07:00
|
|
|
{
|
2020-07-01 00:55:59 +03:00
|
|
|
return HPD_PORT_A + port - PORT_A;
|
2017-08-11 11:26:50 -07:00
|
|
|
}
|
|
|
|
|
2022-09-16 16:06:34 +03:00
|
|
|
/* Threshold == 5 for long IRQs, 50 for short */
|
|
|
|
#define HPD_STORM_DEFAULT_THRESHOLD 50
|
|
|
|
|
2015-06-18 13:06:16 +03:00
|
|
|
#define HPD_STORM_DETECT_PERIOD 1000
|
|
|
|
#define HPD_STORM_REENABLE_DELAY (2 * 60 * 1000)
|
2019-07-11 17:53:42 -07:00
|
|
|
#define HPD_RETRY_DELAY 1000
|
2015-06-18 13:06:16 +03:00
|
|
|
|
2020-01-21 19:10:51 +02:00
|
|
|
static enum hpd_pin
|
|
|
|
intel_connector_hpd_pin(struct intel_connector *connector)
|
|
|
|
{
|
|
|
|
struct intel_encoder *encoder = intel_attached_encoder(connector);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* MST connectors get their encoder attached dynamically
|
|
|
|
* so need to make sure we have an encoder here. But since
|
|
|
|
* MST encoders have their hpd_pin set to HPD_NONE we don't
|
|
|
|
* have to special case them beyond that.
|
|
|
|
*/
|
|
|
|
return encoder ? encoder->hpd_pin : HPD_NONE;
|
|
|
|
}
|
|
|
|
|
2015-06-18 13:06:16 +03:00
|
|
|
/**
|
drm/i915: Add short HPD IRQ storm detection for non-MST systems
Unfortunately, it seems that the HPD IRQ storm problem from the early
days of Intel GPUs was never entirely solved, only mostly. Within the
last couple of days, I got a bug report from one of our customers who
had been having issues with their machine suddenly booting up very
slowly after having updated. The amount of time it took to boot went
from around 30 seconds, to over 6 minutes consistently.
After some investigation, I discovered that i915 was reporting massive
amounts of short HPD IRQ spam on this system from the DisplayPort port,
despite there not being anything actually connected. The symptoms would
start with one "long" HPD IRQ being detected at boot:
[ 1.891398] [drm:intel_get_hpd_pins [i915]] hotplug event received, stat 0x00440000, dig 0x00440000, pins 0x000000a0
[ 1.891436] [drm:intel_hpd_irq_handler [i915]] digital hpd port B - long
[ 1.891472] [drm:intel_hpd_irq_handler [i915]] Received HPD interrupt on PIN 5 - cnt: 0
[ 1.891508] [drm:intel_hpd_irq_handler [i915]] digital hpd port D - long
[ 1.891544] [drm:intel_hpd_irq_handler [i915]] Received HPD interrupt on PIN 7 - cnt: 0
[ 1.891592] [drm:intel_dp_hpd_pulse [i915]] got hpd irq on port B - long
[ 1.891628] [drm:intel_dp_hpd_pulse [i915]] got hpd irq on port D - long
…
followed by constant short IRQs afterwards:
[ 1.895091] [drm:intel_encoder_hotplug [i915]] [CONNECTOR:66:DP-1] status updated from unknown to disconnected
[ 1.895129] [drm:i915_hotplug_work_func [i915]] Connector DP-3 (pin 7) received hotplug event.
[ 1.895165] [drm:intel_dp_detect [i915]] [CONNECTOR:72:DP-3]
[ 1.895275] [drm:intel_get_hpd_pins [i915]] hotplug event received, stat 0x00200000, dig 0x00200000, pins 0x00000080
[ 1.895312] [drm:intel_hpd_irq_handler [i915]] digital hpd port D - short
[ 1.895762] [drm:intel_get_hpd_pins [i915]] hotplug event received, stat 0x00200000, dig 0x00200000, pins 0x00000080
[ 1.895799] [drm:intel_hpd_irq_handler [i915]] digital hpd port D - short
[ 1.896239] [drm:intel_dp_aux_xfer [i915]] dp_aux_ch timeout status 0x71450085
[ 1.896293] [drm:intel_get_hpd_pins [i915]] hotplug event received, stat 0x00200000, dig 0x00200000, pins 0x00000080
[ 1.896330] [drm:intel_hpd_irq_handler [i915]] digital hpd port D - short
[ 1.896781] [drm:intel_get_hpd_pins [i915]] hotplug event received, stat 0x00200000, dig 0x00200000, pins 0x00000080
[ 1.896817] [drm:intel_hpd_irq_handler [i915]] digital hpd port D - short
[ 1.897275] [drm:intel_get_hpd_pins [i915]] hotplug event received, stat 0x00200000, dig 0x00200000, pins 0x00000080
The customer's system in question has a GM45 GPU, which is apparently
well known for hotplugging storms.
So, workaround this impressively broken hardware by changing the default
HPD storm threshold from 5 to 50. Then, make long IRQs count for 10, and
short IRQs count for 1. This makes it so that 5 long IRQs will trigger
an HPD storm, and on systems with short HPD storm detection 50 short
IRQs will trigger an HPD storm. 50 short IRQs amounts to 100ms of
constant pulsing, which seems like a good middleground between being too
sensitive and not being sensitive enough (which would cause visible
stutters in userspace every time a storm occurs).
And just to be extra safe: we don't enable this by default on systems
with MST support. There's too high of a chance of MST support triggering
storm detection, and systems that are new enough to support MST are a
lot less likely to have issues with IRQ storms anyway.
As a note: this patch was tested using a ThinkPad T450s and a Chamelium
to simulate the short IRQ storms.
Changes since v1:
- Don't use two separate thresholds, just make long IRQs count for 10
each and short IRQs count for 1. This simplifies the code a bit
- Ville Syrjälä
Changes since v2:
- Document @long_hpd in intel_hpd_irq_storm_detect, no functional
changes
Changes since v4:
- Remove !! in long_hpd assignment - Ville Syrjälä
- queue_hp = true - Ville Syrjälä
Signed-off-by: Lyude Paul <lyude@redhat.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181106213017.14563-6-lyude@redhat.com
2018-11-06 16:30:16 -05:00
|
|
|
* intel_hpd_irq_storm_detect - gather stats and detect HPD IRQ storm on a pin
|
2025-03-20 16:45:59 +02:00
|
|
|
* @display: display device
|
2015-06-18 13:06:16 +03:00
|
|
|
* @pin: the pin to gather stats on
|
drm/i915: Add short HPD IRQ storm detection for non-MST systems
Unfortunately, it seems that the HPD IRQ storm problem from the early
days of Intel GPUs was never entirely solved, only mostly. Within the
last couple of days, I got a bug report from one of our customers who
had been having issues with their machine suddenly booting up very
slowly after having updated. The amount of time it took to boot went
from around 30 seconds, to over 6 minutes consistently.
After some investigation, I discovered that i915 was reporting massive
amounts of short HPD IRQ spam on this system from the DisplayPort port,
despite there not being anything actually connected. The symptoms would
start with one "long" HPD IRQ being detected at boot:
[ 1.891398] [drm:intel_get_hpd_pins [i915]] hotplug event received, stat 0x00440000, dig 0x00440000, pins 0x000000a0
[ 1.891436] [drm:intel_hpd_irq_handler [i915]] digital hpd port B - long
[ 1.891472] [drm:intel_hpd_irq_handler [i915]] Received HPD interrupt on PIN 5 - cnt: 0
[ 1.891508] [drm:intel_hpd_irq_handler [i915]] digital hpd port D - long
[ 1.891544] [drm:intel_hpd_irq_handler [i915]] Received HPD interrupt on PIN 7 - cnt: 0
[ 1.891592] [drm:intel_dp_hpd_pulse [i915]] got hpd irq on port B - long
[ 1.891628] [drm:intel_dp_hpd_pulse [i915]] got hpd irq on port D - long
…
followed by constant short IRQs afterwards:
[ 1.895091] [drm:intel_encoder_hotplug [i915]] [CONNECTOR:66:DP-1] status updated from unknown to disconnected
[ 1.895129] [drm:i915_hotplug_work_func [i915]] Connector DP-3 (pin 7) received hotplug event.
[ 1.895165] [drm:intel_dp_detect [i915]] [CONNECTOR:72:DP-3]
[ 1.895275] [drm:intel_get_hpd_pins [i915]] hotplug event received, stat 0x00200000, dig 0x00200000, pins 0x00000080
[ 1.895312] [drm:intel_hpd_irq_handler [i915]] digital hpd port D - short
[ 1.895762] [drm:intel_get_hpd_pins [i915]] hotplug event received, stat 0x00200000, dig 0x00200000, pins 0x00000080
[ 1.895799] [drm:intel_hpd_irq_handler [i915]] digital hpd port D - short
[ 1.896239] [drm:intel_dp_aux_xfer [i915]] dp_aux_ch timeout status 0x71450085
[ 1.896293] [drm:intel_get_hpd_pins [i915]] hotplug event received, stat 0x00200000, dig 0x00200000, pins 0x00000080
[ 1.896330] [drm:intel_hpd_irq_handler [i915]] digital hpd port D - short
[ 1.896781] [drm:intel_get_hpd_pins [i915]] hotplug event received, stat 0x00200000, dig 0x00200000, pins 0x00000080
[ 1.896817] [drm:intel_hpd_irq_handler [i915]] digital hpd port D - short
[ 1.897275] [drm:intel_get_hpd_pins [i915]] hotplug event received, stat 0x00200000, dig 0x00200000, pins 0x00000080
The customer's system in question has a GM45 GPU, which is apparently
well known for hotplugging storms.
So, workaround this impressively broken hardware by changing the default
HPD storm threshold from 5 to 50. Then, make long IRQs count for 10, and
short IRQs count for 1. This makes it so that 5 long IRQs will trigger
an HPD storm, and on systems with short HPD storm detection 50 short
IRQs will trigger an HPD storm. 50 short IRQs amounts to 100ms of
constant pulsing, which seems like a good middleground between being too
sensitive and not being sensitive enough (which would cause visible
stutters in userspace every time a storm occurs).
And just to be extra safe: we don't enable this by default on systems
with MST support. There's too high of a chance of MST support triggering
storm detection, and systems that are new enough to support MST are a
lot less likely to have issues with IRQ storms anyway.
As a note: this patch was tested using a ThinkPad T450s and a Chamelium
to simulate the short IRQ storms.
Changes since v1:
- Don't use two separate thresholds, just make long IRQs count for 10
each and short IRQs count for 1. This simplifies the code a bit
- Ville Syrjälä
Changes since v2:
- Document @long_hpd in intel_hpd_irq_storm_detect, no functional
changes
Changes since v4:
- Remove !! in long_hpd assignment - Ville Syrjälä
- queue_hp = true - Ville Syrjälä
Signed-off-by: Lyude Paul <lyude@redhat.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181106213017.14563-6-lyude@redhat.com
2018-11-06 16:30:16 -05:00
|
|
|
* @long_hpd: whether the HPD IRQ was long or short
|
2015-06-18 13:06:16 +03:00
|
|
|
*
|
drm/i915: Add short HPD IRQ storm detection for non-MST systems
Unfortunately, it seems that the HPD IRQ storm problem from the early
days of Intel GPUs was never entirely solved, only mostly. Within the
last couple of days, I got a bug report from one of our customers who
had been having issues with their machine suddenly booting up very
slowly after having updated. The amount of time it took to boot went
from around 30 seconds, to over 6 minutes consistently.
After some investigation, I discovered that i915 was reporting massive
amounts of short HPD IRQ spam on this system from the DisplayPort port,
despite there not being anything actually connected. The symptoms would
start with one "long" HPD IRQ being detected at boot:
[ 1.891398] [drm:intel_get_hpd_pins [i915]] hotplug event received, stat 0x00440000, dig 0x00440000, pins 0x000000a0
[ 1.891436] [drm:intel_hpd_irq_handler [i915]] digital hpd port B - long
[ 1.891472] [drm:intel_hpd_irq_handler [i915]] Received HPD interrupt on PIN 5 - cnt: 0
[ 1.891508] [drm:intel_hpd_irq_handler [i915]] digital hpd port D - long
[ 1.891544] [drm:intel_hpd_irq_handler [i915]] Received HPD interrupt on PIN 7 - cnt: 0
[ 1.891592] [drm:intel_dp_hpd_pulse [i915]] got hpd irq on port B - long
[ 1.891628] [drm:intel_dp_hpd_pulse [i915]] got hpd irq on port D - long
…
followed by constant short IRQs afterwards:
[ 1.895091] [drm:intel_encoder_hotplug [i915]] [CONNECTOR:66:DP-1] status updated from unknown to disconnected
[ 1.895129] [drm:i915_hotplug_work_func [i915]] Connector DP-3 (pin 7) received hotplug event.
[ 1.895165] [drm:intel_dp_detect [i915]] [CONNECTOR:72:DP-3]
[ 1.895275] [drm:intel_get_hpd_pins [i915]] hotplug event received, stat 0x00200000, dig 0x00200000, pins 0x00000080
[ 1.895312] [drm:intel_hpd_irq_handler [i915]] digital hpd port D - short
[ 1.895762] [drm:intel_get_hpd_pins [i915]] hotplug event received, stat 0x00200000, dig 0x00200000, pins 0x00000080
[ 1.895799] [drm:intel_hpd_irq_handler [i915]] digital hpd port D - short
[ 1.896239] [drm:intel_dp_aux_xfer [i915]] dp_aux_ch timeout status 0x71450085
[ 1.896293] [drm:intel_get_hpd_pins [i915]] hotplug event received, stat 0x00200000, dig 0x00200000, pins 0x00000080
[ 1.896330] [drm:intel_hpd_irq_handler [i915]] digital hpd port D - short
[ 1.896781] [drm:intel_get_hpd_pins [i915]] hotplug event received, stat 0x00200000, dig 0x00200000, pins 0x00000080
[ 1.896817] [drm:intel_hpd_irq_handler [i915]] digital hpd port D - short
[ 1.897275] [drm:intel_get_hpd_pins [i915]] hotplug event received, stat 0x00200000, dig 0x00200000, pins 0x00000080
The customer's system in question has a GM45 GPU, which is apparently
well known for hotplugging storms.
So, workaround this impressively broken hardware by changing the default
HPD storm threshold from 5 to 50. Then, make long IRQs count for 10, and
short IRQs count for 1. This makes it so that 5 long IRQs will trigger
an HPD storm, and on systems with short HPD storm detection 50 short
IRQs will trigger an HPD storm. 50 short IRQs amounts to 100ms of
constant pulsing, which seems like a good middleground between being too
sensitive and not being sensitive enough (which would cause visible
stutters in userspace every time a storm occurs).
And just to be extra safe: we don't enable this by default on systems
with MST support. There's too high of a chance of MST support triggering
storm detection, and systems that are new enough to support MST are a
lot less likely to have issues with IRQ storms anyway.
As a note: this patch was tested using a ThinkPad T450s and a Chamelium
to simulate the short IRQ storms.
Changes since v1:
- Don't use two separate thresholds, just make long IRQs count for 10
each and short IRQs count for 1. This simplifies the code a bit
- Ville Syrjälä
Changes since v2:
- Document @long_hpd in intel_hpd_irq_storm_detect, no functional
changes
Changes since v4:
- Remove !! in long_hpd assignment - Ville Syrjälä
- queue_hp = true - Ville Syrjälä
Signed-off-by: Lyude Paul <lyude@redhat.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181106213017.14563-6-lyude@redhat.com
2018-11-06 16:30:16 -05:00
|
|
|
* Gather stats about HPD IRQs from the specified @pin, and detect IRQ
|
2015-06-18 13:06:16 +03:00
|
|
|
* storms. Only the pin specific stats and state are changed, the caller is
|
|
|
|
* responsible for further action.
|
|
|
|
*
|
drm/i915: Add short HPD IRQ storm detection for non-MST systems
Unfortunately, it seems that the HPD IRQ storm problem from the early
days of Intel GPUs was never entirely solved, only mostly. Within the
last couple of days, I got a bug report from one of our customers who
had been having issues with their machine suddenly booting up very
slowly after having updated. The amount of time it took to boot went
from around 30 seconds, to over 6 minutes consistently.
After some investigation, I discovered that i915 was reporting massive
amounts of short HPD IRQ spam on this system from the DisplayPort port,
despite there not being anything actually connected. The symptoms would
start with one "long" HPD IRQ being detected at boot:
[ 1.891398] [drm:intel_get_hpd_pins [i915]] hotplug event received, stat 0x00440000, dig 0x00440000, pins 0x000000a0
[ 1.891436] [drm:intel_hpd_irq_handler [i915]] digital hpd port B - long
[ 1.891472] [drm:intel_hpd_irq_handler [i915]] Received HPD interrupt on PIN 5 - cnt: 0
[ 1.891508] [drm:intel_hpd_irq_handler [i915]] digital hpd port D - long
[ 1.891544] [drm:intel_hpd_irq_handler [i915]] Received HPD interrupt on PIN 7 - cnt: 0
[ 1.891592] [drm:intel_dp_hpd_pulse [i915]] got hpd irq on port B - long
[ 1.891628] [drm:intel_dp_hpd_pulse [i915]] got hpd irq on port D - long
…
followed by constant short IRQs afterwards:
[ 1.895091] [drm:intel_encoder_hotplug [i915]] [CONNECTOR:66:DP-1] status updated from unknown to disconnected
[ 1.895129] [drm:i915_hotplug_work_func [i915]] Connector DP-3 (pin 7) received hotplug event.
[ 1.895165] [drm:intel_dp_detect [i915]] [CONNECTOR:72:DP-3]
[ 1.895275] [drm:intel_get_hpd_pins [i915]] hotplug event received, stat 0x00200000, dig 0x00200000, pins 0x00000080
[ 1.895312] [drm:intel_hpd_irq_handler [i915]] digital hpd port D - short
[ 1.895762] [drm:intel_get_hpd_pins [i915]] hotplug event received, stat 0x00200000, dig 0x00200000, pins 0x00000080
[ 1.895799] [drm:intel_hpd_irq_handler [i915]] digital hpd port D - short
[ 1.896239] [drm:intel_dp_aux_xfer [i915]] dp_aux_ch timeout status 0x71450085
[ 1.896293] [drm:intel_get_hpd_pins [i915]] hotplug event received, stat 0x00200000, dig 0x00200000, pins 0x00000080
[ 1.896330] [drm:intel_hpd_irq_handler [i915]] digital hpd port D - short
[ 1.896781] [drm:intel_get_hpd_pins [i915]] hotplug event received, stat 0x00200000, dig 0x00200000, pins 0x00000080
[ 1.896817] [drm:intel_hpd_irq_handler [i915]] digital hpd port D - short
[ 1.897275] [drm:intel_get_hpd_pins [i915]] hotplug event received, stat 0x00200000, dig 0x00200000, pins 0x00000080
The customer's system in question has a GM45 GPU, which is apparently
well known for hotplugging storms.
So, workaround this impressively broken hardware by changing the default
HPD storm threshold from 5 to 50. Then, make long IRQs count for 10, and
short IRQs count for 1. This makes it so that 5 long IRQs will trigger
an HPD storm, and on systems with short HPD storm detection 50 short
IRQs will trigger an HPD storm. 50 short IRQs amounts to 100ms of
constant pulsing, which seems like a good middleground between being too
sensitive and not being sensitive enough (which would cause visible
stutters in userspace every time a storm occurs).
And just to be extra safe: we don't enable this by default on systems
with MST support. There's too high of a chance of MST support triggering
storm detection, and systems that are new enough to support MST are a
lot less likely to have issues with IRQ storms anyway.
As a note: this patch was tested using a ThinkPad T450s and a Chamelium
to simulate the short IRQ storms.
Changes since v1:
- Don't use two separate thresholds, just make long IRQs count for 10
each and short IRQs count for 1. This simplifies the code a bit
- Ville Syrjälä
Changes since v2:
- Document @long_hpd in intel_hpd_irq_storm_detect, no functional
changes
Changes since v4:
- Remove !! in long_hpd assignment - Ville Syrjälä
- queue_hp = true - Ville Syrjälä
Signed-off-by: Lyude Paul <lyude@redhat.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181106213017.14563-6-lyude@redhat.com
2018-11-06 16:30:16 -05:00
|
|
|
* The number of IRQs that are allowed within @HPD_STORM_DETECT_PERIOD is
|
2025-03-20 16:45:59 +02:00
|
|
|
* stored in @display->hotplug.hpd_storm_threshold which defaults to
|
drm/i915: Add short HPD IRQ storm detection for non-MST systems
Unfortunately, it seems that the HPD IRQ storm problem from the early
days of Intel GPUs was never entirely solved, only mostly. Within the
last couple of days, I got a bug report from one of our customers who
had been having issues with their machine suddenly booting up very
slowly after having updated. The amount of time it took to boot went
from around 30 seconds, to over 6 minutes consistently.
After some investigation, I discovered that i915 was reporting massive
amounts of short HPD IRQ spam on this system from the DisplayPort port,
despite there not being anything actually connected. The symptoms would
start with one "long" HPD IRQ being detected at boot:
[ 1.891398] [drm:intel_get_hpd_pins [i915]] hotplug event received, stat 0x00440000, dig 0x00440000, pins 0x000000a0
[ 1.891436] [drm:intel_hpd_irq_handler [i915]] digital hpd port B - long
[ 1.891472] [drm:intel_hpd_irq_handler [i915]] Received HPD interrupt on PIN 5 - cnt: 0
[ 1.891508] [drm:intel_hpd_irq_handler [i915]] digital hpd port D - long
[ 1.891544] [drm:intel_hpd_irq_handler [i915]] Received HPD interrupt on PIN 7 - cnt: 0
[ 1.891592] [drm:intel_dp_hpd_pulse [i915]] got hpd irq on port B - long
[ 1.891628] [drm:intel_dp_hpd_pulse [i915]] got hpd irq on port D - long
…
followed by constant short IRQs afterwards:
[ 1.895091] [drm:intel_encoder_hotplug [i915]] [CONNECTOR:66:DP-1] status updated from unknown to disconnected
[ 1.895129] [drm:i915_hotplug_work_func [i915]] Connector DP-3 (pin 7) received hotplug event.
[ 1.895165] [drm:intel_dp_detect [i915]] [CONNECTOR:72:DP-3]
[ 1.895275] [drm:intel_get_hpd_pins [i915]] hotplug event received, stat 0x00200000, dig 0x00200000, pins 0x00000080
[ 1.895312] [drm:intel_hpd_irq_handler [i915]] digital hpd port D - short
[ 1.895762] [drm:intel_get_hpd_pins [i915]] hotplug event received, stat 0x00200000, dig 0x00200000, pins 0x00000080
[ 1.895799] [drm:intel_hpd_irq_handler [i915]] digital hpd port D - short
[ 1.896239] [drm:intel_dp_aux_xfer [i915]] dp_aux_ch timeout status 0x71450085
[ 1.896293] [drm:intel_get_hpd_pins [i915]] hotplug event received, stat 0x00200000, dig 0x00200000, pins 0x00000080
[ 1.896330] [drm:intel_hpd_irq_handler [i915]] digital hpd port D - short
[ 1.896781] [drm:intel_get_hpd_pins [i915]] hotplug event received, stat 0x00200000, dig 0x00200000, pins 0x00000080
[ 1.896817] [drm:intel_hpd_irq_handler [i915]] digital hpd port D - short
[ 1.897275] [drm:intel_get_hpd_pins [i915]] hotplug event received, stat 0x00200000, dig 0x00200000, pins 0x00000080
The customer's system in question has a GM45 GPU, which is apparently
well known for hotplugging storms.
So, workaround this impressively broken hardware by changing the default
HPD storm threshold from 5 to 50. Then, make long IRQs count for 10, and
short IRQs count for 1. This makes it so that 5 long IRQs will trigger
an HPD storm, and on systems with short HPD storm detection 50 short
IRQs will trigger an HPD storm. 50 short IRQs amounts to 100ms of
constant pulsing, which seems like a good middleground between being too
sensitive and not being sensitive enough (which would cause visible
stutters in userspace every time a storm occurs).
And just to be extra safe: we don't enable this by default on systems
with MST support. There's too high of a chance of MST support triggering
storm detection, and systems that are new enough to support MST are a
lot less likely to have issues with IRQ storms anyway.
As a note: this patch was tested using a ThinkPad T450s and a Chamelium
to simulate the short IRQ storms.
Changes since v1:
- Don't use two separate thresholds, just make long IRQs count for 10
each and short IRQs count for 1. This simplifies the code a bit
- Ville Syrjälä
Changes since v2:
- Document @long_hpd in intel_hpd_irq_storm_detect, no functional
changes
Changes since v4:
- Remove !! in long_hpd assignment - Ville Syrjälä
- queue_hp = true - Ville Syrjälä
Signed-off-by: Lyude Paul <lyude@redhat.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181106213017.14563-6-lyude@redhat.com
2018-11-06 16:30:16 -05:00
|
|
|
* @HPD_STORM_DEFAULT_THRESHOLD. Long IRQs count as +10 to this threshold, and
|
|
|
|
* short IRQs count as +1. If this threshold is exceeded, it's considered an
|
|
|
|
* IRQ storm and the IRQ state is set to @HPD_MARK_DISABLED.
|
|
|
|
*
|
|
|
|
* By default, most systems will only count long IRQs towards
|
2025-03-20 16:45:59 +02:00
|
|
|
* &display->hotplug.hpd_storm_threshold. However, some older systems also
|
drm/i915: Add short HPD IRQ storm detection for non-MST systems
Unfortunately, it seems that the HPD IRQ storm problem from the early
days of Intel GPUs was never entirely solved, only mostly. Within the
last couple of days, I got a bug report from one of our customers who
had been having issues with their machine suddenly booting up very
slowly after having updated. The amount of time it took to boot went
from around 30 seconds, to over 6 minutes consistently.
After some investigation, I discovered that i915 was reporting massive
amounts of short HPD IRQ spam on this system from the DisplayPort port,
despite there not being anything actually connected. The symptoms would
start with one "long" HPD IRQ being detected at boot:
[ 1.891398] [drm:intel_get_hpd_pins [i915]] hotplug event received, stat 0x00440000, dig 0x00440000, pins 0x000000a0
[ 1.891436] [drm:intel_hpd_irq_handler [i915]] digital hpd port B - long
[ 1.891472] [drm:intel_hpd_irq_handler [i915]] Received HPD interrupt on PIN 5 - cnt: 0
[ 1.891508] [drm:intel_hpd_irq_handler [i915]] digital hpd port D - long
[ 1.891544] [drm:intel_hpd_irq_handler [i915]] Received HPD interrupt on PIN 7 - cnt: 0
[ 1.891592] [drm:intel_dp_hpd_pulse [i915]] got hpd irq on port B - long
[ 1.891628] [drm:intel_dp_hpd_pulse [i915]] got hpd irq on port D - long
…
followed by constant short IRQs afterwards:
[ 1.895091] [drm:intel_encoder_hotplug [i915]] [CONNECTOR:66:DP-1] status updated from unknown to disconnected
[ 1.895129] [drm:i915_hotplug_work_func [i915]] Connector DP-3 (pin 7) received hotplug event.
[ 1.895165] [drm:intel_dp_detect [i915]] [CONNECTOR:72:DP-3]
[ 1.895275] [drm:intel_get_hpd_pins [i915]] hotplug event received, stat 0x00200000, dig 0x00200000, pins 0x00000080
[ 1.895312] [drm:intel_hpd_irq_handler [i915]] digital hpd port D - short
[ 1.895762] [drm:intel_get_hpd_pins [i915]] hotplug event received, stat 0x00200000, dig 0x00200000, pins 0x00000080
[ 1.895799] [drm:intel_hpd_irq_handler [i915]] digital hpd port D - short
[ 1.896239] [drm:intel_dp_aux_xfer [i915]] dp_aux_ch timeout status 0x71450085
[ 1.896293] [drm:intel_get_hpd_pins [i915]] hotplug event received, stat 0x00200000, dig 0x00200000, pins 0x00000080
[ 1.896330] [drm:intel_hpd_irq_handler [i915]] digital hpd port D - short
[ 1.896781] [drm:intel_get_hpd_pins [i915]] hotplug event received, stat 0x00200000, dig 0x00200000, pins 0x00000080
[ 1.896817] [drm:intel_hpd_irq_handler [i915]] digital hpd port D - short
[ 1.897275] [drm:intel_get_hpd_pins [i915]] hotplug event received, stat 0x00200000, dig 0x00200000, pins 0x00000080
The customer's system in question has a GM45 GPU, which is apparently
well known for hotplugging storms.
So, workaround this impressively broken hardware by changing the default
HPD storm threshold from 5 to 50. Then, make long IRQs count for 10, and
short IRQs count for 1. This makes it so that 5 long IRQs will trigger
an HPD storm, and on systems with short HPD storm detection 50 short
IRQs will trigger an HPD storm. 50 short IRQs amounts to 100ms of
constant pulsing, which seems like a good middleground between being too
sensitive and not being sensitive enough (which would cause visible
stutters in userspace every time a storm occurs).
And just to be extra safe: we don't enable this by default on systems
with MST support. There's too high of a chance of MST support triggering
storm detection, and systems that are new enough to support MST are a
lot less likely to have issues with IRQ storms anyway.
As a note: this patch was tested using a ThinkPad T450s and a Chamelium
to simulate the short IRQ storms.
Changes since v1:
- Don't use two separate thresholds, just make long IRQs count for 10
each and short IRQs count for 1. This simplifies the code a bit
- Ville Syrjälä
Changes since v2:
- Document @long_hpd in intel_hpd_irq_storm_detect, no functional
changes
Changes since v4:
- Remove !! in long_hpd assignment - Ville Syrjälä
- queue_hp = true - Ville Syrjälä
Signed-off-by: Lyude Paul <lyude@redhat.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181106213017.14563-6-lyude@redhat.com
2018-11-06 16:30:16 -05:00
|
|
|
* suffer from short IRQ storms and must also track these. Because short IRQ
|
|
|
|
* storms are naturally caused by sideband interactions with DP MST devices,
|
|
|
|
* short IRQ detection is only enabled for systems without DP MST support.
|
|
|
|
* Systems which are new enough to support DP MST are far less likely to
|
|
|
|
* suffer from IRQ storms at all, so this is fine.
|
2017-02-03 21:18:25 -05:00
|
|
|
*
|
|
|
|
* The HPD threshold can be controlled through i915_hpd_storm_ctl in debugfs,
|
|
|
|
* and should only be adjusted for automated hotplug testing.
|
2015-06-18 13:06:16 +03:00
|
|
|
*
|
drm/i915: Add short HPD IRQ storm detection for non-MST systems
Unfortunately, it seems that the HPD IRQ storm problem from the early
days of Intel GPUs was never entirely solved, only mostly. Within the
last couple of days, I got a bug report from one of our customers who
had been having issues with their machine suddenly booting up very
slowly after having updated. The amount of time it took to boot went
from around 30 seconds, to over 6 minutes consistently.
After some investigation, I discovered that i915 was reporting massive
amounts of short HPD IRQ spam on this system from the DisplayPort port,
despite there not being anything actually connected. The symptoms would
start with one "long" HPD IRQ being detected at boot:
[ 1.891398] [drm:intel_get_hpd_pins [i915]] hotplug event received, stat 0x00440000, dig 0x00440000, pins 0x000000a0
[ 1.891436] [drm:intel_hpd_irq_handler [i915]] digital hpd port B - long
[ 1.891472] [drm:intel_hpd_irq_handler [i915]] Received HPD interrupt on PIN 5 - cnt: 0
[ 1.891508] [drm:intel_hpd_irq_handler [i915]] digital hpd port D - long
[ 1.891544] [drm:intel_hpd_irq_handler [i915]] Received HPD interrupt on PIN 7 - cnt: 0
[ 1.891592] [drm:intel_dp_hpd_pulse [i915]] got hpd irq on port B - long
[ 1.891628] [drm:intel_dp_hpd_pulse [i915]] got hpd irq on port D - long
…
followed by constant short IRQs afterwards:
[ 1.895091] [drm:intel_encoder_hotplug [i915]] [CONNECTOR:66:DP-1] status updated from unknown to disconnected
[ 1.895129] [drm:i915_hotplug_work_func [i915]] Connector DP-3 (pin 7) received hotplug event.
[ 1.895165] [drm:intel_dp_detect [i915]] [CONNECTOR:72:DP-3]
[ 1.895275] [drm:intel_get_hpd_pins [i915]] hotplug event received, stat 0x00200000, dig 0x00200000, pins 0x00000080
[ 1.895312] [drm:intel_hpd_irq_handler [i915]] digital hpd port D - short
[ 1.895762] [drm:intel_get_hpd_pins [i915]] hotplug event received, stat 0x00200000, dig 0x00200000, pins 0x00000080
[ 1.895799] [drm:intel_hpd_irq_handler [i915]] digital hpd port D - short
[ 1.896239] [drm:intel_dp_aux_xfer [i915]] dp_aux_ch timeout status 0x71450085
[ 1.896293] [drm:intel_get_hpd_pins [i915]] hotplug event received, stat 0x00200000, dig 0x00200000, pins 0x00000080
[ 1.896330] [drm:intel_hpd_irq_handler [i915]] digital hpd port D - short
[ 1.896781] [drm:intel_get_hpd_pins [i915]] hotplug event received, stat 0x00200000, dig 0x00200000, pins 0x00000080
[ 1.896817] [drm:intel_hpd_irq_handler [i915]] digital hpd port D - short
[ 1.897275] [drm:intel_get_hpd_pins [i915]] hotplug event received, stat 0x00200000, dig 0x00200000, pins 0x00000080
The customer's system in question has a GM45 GPU, which is apparently
well known for hotplugging storms.
So, workaround this impressively broken hardware by changing the default
HPD storm threshold from 5 to 50. Then, make long IRQs count for 10, and
short IRQs count for 1. This makes it so that 5 long IRQs will trigger
an HPD storm, and on systems with short HPD storm detection 50 short
IRQs will trigger an HPD storm. 50 short IRQs amounts to 100ms of
constant pulsing, which seems like a good middleground between being too
sensitive and not being sensitive enough (which would cause visible
stutters in userspace every time a storm occurs).
And just to be extra safe: we don't enable this by default on systems
with MST support. There's too high of a chance of MST support triggering
storm detection, and systems that are new enough to support MST are a
lot less likely to have issues with IRQ storms anyway.
As a note: this patch was tested using a ThinkPad T450s and a Chamelium
to simulate the short IRQ storms.
Changes since v1:
- Don't use two separate thresholds, just make long IRQs count for 10
each and short IRQs count for 1. This simplifies the code a bit
- Ville Syrjälä
Changes since v2:
- Document @long_hpd in intel_hpd_irq_storm_detect, no functional
changes
Changes since v4:
- Remove !! in long_hpd assignment - Ville Syrjälä
- queue_hp = true - Ville Syrjälä
Signed-off-by: Lyude Paul <lyude@redhat.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181106213017.14563-6-lyude@redhat.com
2018-11-06 16:30:16 -05:00
|
|
|
* Return true if an IRQ storm was detected on @pin.
|
2015-06-18 13:06:16 +03:00
|
|
|
*/
|
2025-03-20 16:45:59 +02:00
|
|
|
static bool intel_hpd_irq_storm_detect(struct intel_display *display,
|
drm/i915: Add short HPD IRQ storm detection for non-MST systems
Unfortunately, it seems that the HPD IRQ storm problem from the early
days of Intel GPUs was never entirely solved, only mostly. Within the
last couple of days, I got a bug report from one of our customers who
had been having issues with their machine suddenly booting up very
slowly after having updated. The amount of time it took to boot went
from around 30 seconds, to over 6 minutes consistently.
After some investigation, I discovered that i915 was reporting massive
amounts of short HPD IRQ spam on this system from the DisplayPort port,
despite there not being anything actually connected. The symptoms would
start with one "long" HPD IRQ being detected at boot:
[ 1.891398] [drm:intel_get_hpd_pins [i915]] hotplug event received, stat 0x00440000, dig 0x00440000, pins 0x000000a0
[ 1.891436] [drm:intel_hpd_irq_handler [i915]] digital hpd port B - long
[ 1.891472] [drm:intel_hpd_irq_handler [i915]] Received HPD interrupt on PIN 5 - cnt: 0
[ 1.891508] [drm:intel_hpd_irq_handler [i915]] digital hpd port D - long
[ 1.891544] [drm:intel_hpd_irq_handler [i915]] Received HPD interrupt on PIN 7 - cnt: 0
[ 1.891592] [drm:intel_dp_hpd_pulse [i915]] got hpd irq on port B - long
[ 1.891628] [drm:intel_dp_hpd_pulse [i915]] got hpd irq on port D - long
…
followed by constant short IRQs afterwards:
[ 1.895091] [drm:intel_encoder_hotplug [i915]] [CONNECTOR:66:DP-1] status updated from unknown to disconnected
[ 1.895129] [drm:i915_hotplug_work_func [i915]] Connector DP-3 (pin 7) received hotplug event.
[ 1.895165] [drm:intel_dp_detect [i915]] [CONNECTOR:72:DP-3]
[ 1.895275] [drm:intel_get_hpd_pins [i915]] hotplug event received, stat 0x00200000, dig 0x00200000, pins 0x00000080
[ 1.895312] [drm:intel_hpd_irq_handler [i915]] digital hpd port D - short
[ 1.895762] [drm:intel_get_hpd_pins [i915]] hotplug event received, stat 0x00200000, dig 0x00200000, pins 0x00000080
[ 1.895799] [drm:intel_hpd_irq_handler [i915]] digital hpd port D - short
[ 1.896239] [drm:intel_dp_aux_xfer [i915]] dp_aux_ch timeout status 0x71450085
[ 1.896293] [drm:intel_get_hpd_pins [i915]] hotplug event received, stat 0x00200000, dig 0x00200000, pins 0x00000080
[ 1.896330] [drm:intel_hpd_irq_handler [i915]] digital hpd port D - short
[ 1.896781] [drm:intel_get_hpd_pins [i915]] hotplug event received, stat 0x00200000, dig 0x00200000, pins 0x00000080
[ 1.896817] [drm:intel_hpd_irq_handler [i915]] digital hpd port D - short
[ 1.897275] [drm:intel_get_hpd_pins [i915]] hotplug event received, stat 0x00200000, dig 0x00200000, pins 0x00000080
The customer's system in question has a GM45 GPU, which is apparently
well known for hotplugging storms.
So, workaround this impressively broken hardware by changing the default
HPD storm threshold from 5 to 50. Then, make long IRQs count for 10, and
short IRQs count for 1. This makes it so that 5 long IRQs will trigger
an HPD storm, and on systems with short HPD storm detection 50 short
IRQs will trigger an HPD storm. 50 short IRQs amounts to 100ms of
constant pulsing, which seems like a good middleground between being too
sensitive and not being sensitive enough (which would cause visible
stutters in userspace every time a storm occurs).
And just to be extra safe: we don't enable this by default on systems
with MST support. There's too high of a chance of MST support triggering
storm detection, and systems that are new enough to support MST are a
lot less likely to have issues with IRQ storms anyway.
As a note: this patch was tested using a ThinkPad T450s and a Chamelium
to simulate the short IRQ storms.
Changes since v1:
- Don't use two separate thresholds, just make long IRQs count for 10
each and short IRQs count for 1. This simplifies the code a bit
- Ville Syrjälä
Changes since v2:
- Document @long_hpd in intel_hpd_irq_storm_detect, no functional
changes
Changes since v4:
- Remove !! in long_hpd assignment - Ville Syrjälä
- queue_hp = true - Ville Syrjälä
Signed-off-by: Lyude Paul <lyude@redhat.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181106213017.14563-6-lyude@redhat.com
2018-11-06 16:30:16 -05:00
|
|
|
enum hpd_pin pin, bool long_hpd)
|
2015-06-18 13:06:16 +03:00
|
|
|
{
|
2025-03-20 16:45:59 +02:00
|
|
|
struct intel_hotplug *hpd = &display->hotplug;
|
2018-11-06 16:30:14 -05:00
|
|
|
unsigned long start = hpd->stats[pin].last_jiffies;
|
2015-06-18 13:06:16 +03:00
|
|
|
unsigned long end = start + msecs_to_jiffies(HPD_STORM_DETECT_PERIOD);
|
drm/i915: Add short HPD IRQ storm detection for non-MST systems
Unfortunately, it seems that the HPD IRQ storm problem from the early
days of Intel GPUs was never entirely solved, only mostly. Within the
last couple of days, I got a bug report from one of our customers who
had been having issues with their machine suddenly booting up very
slowly after having updated. The amount of time it took to boot went
from around 30 seconds, to over 6 minutes consistently.
After some investigation, I discovered that i915 was reporting massive
amounts of short HPD IRQ spam on this system from the DisplayPort port,
despite there not being anything actually connected. The symptoms would
start with one "long" HPD IRQ being detected at boot:
[ 1.891398] [drm:intel_get_hpd_pins [i915]] hotplug event received, stat 0x00440000, dig 0x00440000, pins 0x000000a0
[ 1.891436] [drm:intel_hpd_irq_handler [i915]] digital hpd port B - long
[ 1.891472] [drm:intel_hpd_irq_handler [i915]] Received HPD interrupt on PIN 5 - cnt: 0
[ 1.891508] [drm:intel_hpd_irq_handler [i915]] digital hpd port D - long
[ 1.891544] [drm:intel_hpd_irq_handler [i915]] Received HPD interrupt on PIN 7 - cnt: 0
[ 1.891592] [drm:intel_dp_hpd_pulse [i915]] got hpd irq on port B - long
[ 1.891628] [drm:intel_dp_hpd_pulse [i915]] got hpd irq on port D - long
…
followed by constant short IRQs afterwards:
[ 1.895091] [drm:intel_encoder_hotplug [i915]] [CONNECTOR:66:DP-1] status updated from unknown to disconnected
[ 1.895129] [drm:i915_hotplug_work_func [i915]] Connector DP-3 (pin 7) received hotplug event.
[ 1.895165] [drm:intel_dp_detect [i915]] [CONNECTOR:72:DP-3]
[ 1.895275] [drm:intel_get_hpd_pins [i915]] hotplug event received, stat 0x00200000, dig 0x00200000, pins 0x00000080
[ 1.895312] [drm:intel_hpd_irq_handler [i915]] digital hpd port D - short
[ 1.895762] [drm:intel_get_hpd_pins [i915]] hotplug event received, stat 0x00200000, dig 0x00200000, pins 0x00000080
[ 1.895799] [drm:intel_hpd_irq_handler [i915]] digital hpd port D - short
[ 1.896239] [drm:intel_dp_aux_xfer [i915]] dp_aux_ch timeout status 0x71450085
[ 1.896293] [drm:intel_get_hpd_pins [i915]] hotplug event received, stat 0x00200000, dig 0x00200000, pins 0x00000080
[ 1.896330] [drm:intel_hpd_irq_handler [i915]] digital hpd port D - short
[ 1.896781] [drm:intel_get_hpd_pins [i915]] hotplug event received, stat 0x00200000, dig 0x00200000, pins 0x00000080
[ 1.896817] [drm:intel_hpd_irq_handler [i915]] digital hpd port D - short
[ 1.897275] [drm:intel_get_hpd_pins [i915]] hotplug event received, stat 0x00200000, dig 0x00200000, pins 0x00000080
The customer's system in question has a GM45 GPU, which is apparently
well known for hotplugging storms.
So, workaround this impressively broken hardware by changing the default
HPD storm threshold from 5 to 50. Then, make long IRQs count for 10, and
short IRQs count for 1. This makes it so that 5 long IRQs will trigger
an HPD storm, and on systems with short HPD storm detection 50 short
IRQs will trigger an HPD storm. 50 short IRQs amounts to 100ms of
constant pulsing, which seems like a good middleground between being too
sensitive and not being sensitive enough (which would cause visible
stutters in userspace every time a storm occurs).
And just to be extra safe: we don't enable this by default on systems
with MST support. There's too high of a chance of MST support triggering
storm detection, and systems that are new enough to support MST are a
lot less likely to have issues with IRQ storms anyway.
As a note: this patch was tested using a ThinkPad T450s and a Chamelium
to simulate the short IRQ storms.
Changes since v1:
- Don't use two separate thresholds, just make long IRQs count for 10
each and short IRQs count for 1. This simplifies the code a bit
- Ville Syrjälä
Changes since v2:
- Document @long_hpd in intel_hpd_irq_storm_detect, no functional
changes
Changes since v4:
- Remove !! in long_hpd assignment - Ville Syrjälä
- queue_hp = true - Ville Syrjälä
Signed-off-by: Lyude Paul <lyude@redhat.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181106213017.14563-6-lyude@redhat.com
2018-11-06 16:30:16 -05:00
|
|
|
const int increment = long_hpd ? 10 : 1;
|
2018-11-06 16:30:14 -05:00
|
|
|
const int threshold = hpd->hpd_storm_threshold;
|
2015-06-18 13:06:16 +03:00
|
|
|
bool storm = false;
|
|
|
|
|
drm/i915: Add short HPD IRQ storm detection for non-MST systems
Unfortunately, it seems that the HPD IRQ storm problem from the early
days of Intel GPUs was never entirely solved, only mostly. Within the
last couple of days, I got a bug report from one of our customers who
had been having issues with their machine suddenly booting up very
slowly after having updated. The amount of time it took to boot went
from around 30 seconds, to over 6 minutes consistently.
After some investigation, I discovered that i915 was reporting massive
amounts of short HPD IRQ spam on this system from the DisplayPort port,
despite there not being anything actually connected. The symptoms would
start with one "long" HPD IRQ being detected at boot:
[ 1.891398] [drm:intel_get_hpd_pins [i915]] hotplug event received, stat 0x00440000, dig 0x00440000, pins 0x000000a0
[ 1.891436] [drm:intel_hpd_irq_handler [i915]] digital hpd port B - long
[ 1.891472] [drm:intel_hpd_irq_handler [i915]] Received HPD interrupt on PIN 5 - cnt: 0
[ 1.891508] [drm:intel_hpd_irq_handler [i915]] digital hpd port D - long
[ 1.891544] [drm:intel_hpd_irq_handler [i915]] Received HPD interrupt on PIN 7 - cnt: 0
[ 1.891592] [drm:intel_dp_hpd_pulse [i915]] got hpd irq on port B - long
[ 1.891628] [drm:intel_dp_hpd_pulse [i915]] got hpd irq on port D - long
…
followed by constant short IRQs afterwards:
[ 1.895091] [drm:intel_encoder_hotplug [i915]] [CONNECTOR:66:DP-1] status updated from unknown to disconnected
[ 1.895129] [drm:i915_hotplug_work_func [i915]] Connector DP-3 (pin 7) received hotplug event.
[ 1.895165] [drm:intel_dp_detect [i915]] [CONNECTOR:72:DP-3]
[ 1.895275] [drm:intel_get_hpd_pins [i915]] hotplug event received, stat 0x00200000, dig 0x00200000, pins 0x00000080
[ 1.895312] [drm:intel_hpd_irq_handler [i915]] digital hpd port D - short
[ 1.895762] [drm:intel_get_hpd_pins [i915]] hotplug event received, stat 0x00200000, dig 0x00200000, pins 0x00000080
[ 1.895799] [drm:intel_hpd_irq_handler [i915]] digital hpd port D - short
[ 1.896239] [drm:intel_dp_aux_xfer [i915]] dp_aux_ch timeout status 0x71450085
[ 1.896293] [drm:intel_get_hpd_pins [i915]] hotplug event received, stat 0x00200000, dig 0x00200000, pins 0x00000080
[ 1.896330] [drm:intel_hpd_irq_handler [i915]] digital hpd port D - short
[ 1.896781] [drm:intel_get_hpd_pins [i915]] hotplug event received, stat 0x00200000, dig 0x00200000, pins 0x00000080
[ 1.896817] [drm:intel_hpd_irq_handler [i915]] digital hpd port D - short
[ 1.897275] [drm:intel_get_hpd_pins [i915]] hotplug event received, stat 0x00200000, dig 0x00200000, pins 0x00000080
The customer's system in question has a GM45 GPU, which is apparently
well known for hotplugging storms.
So, workaround this impressively broken hardware by changing the default
HPD storm threshold from 5 to 50. Then, make long IRQs count for 10, and
short IRQs count for 1. This makes it so that 5 long IRQs will trigger
an HPD storm, and on systems with short HPD storm detection 50 short
IRQs will trigger an HPD storm. 50 short IRQs amounts to 100ms of
constant pulsing, which seems like a good middleground between being too
sensitive and not being sensitive enough (which would cause visible
stutters in userspace every time a storm occurs).
And just to be extra safe: we don't enable this by default on systems
with MST support. There's too high of a chance of MST support triggering
storm detection, and systems that are new enough to support MST are a
lot less likely to have issues with IRQ storms anyway.
As a note: this patch was tested using a ThinkPad T450s and a Chamelium
to simulate the short IRQ storms.
Changes since v1:
- Don't use two separate thresholds, just make long IRQs count for 10
each and short IRQs count for 1. This simplifies the code a bit
- Ville Syrjälä
Changes since v2:
- Document @long_hpd in intel_hpd_irq_storm_detect, no functional
changes
Changes since v4:
- Remove !! in long_hpd assignment - Ville Syrjälä
- queue_hp = true - Ville Syrjälä
Signed-off-by: Lyude Paul <lyude@redhat.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181106213017.14563-6-lyude@redhat.com
2018-11-06 16:30:16 -05:00
|
|
|
if (!threshold ||
|
2025-03-20 16:45:59 +02:00
|
|
|
(!long_hpd && !display->hotplug.hpd_short_storm_enabled))
|
2018-11-06 16:30:14 -05:00
|
|
|
return false;
|
|
|
|
|
2015-06-18 13:06:16 +03:00
|
|
|
if (!time_in_range(jiffies, start, end)) {
|
2018-11-06 16:30:14 -05:00
|
|
|
hpd->stats[pin].last_jiffies = jiffies;
|
|
|
|
hpd->stats[pin].count = 0;
|
|
|
|
}
|
|
|
|
|
drm/i915: Add short HPD IRQ storm detection for non-MST systems
Unfortunately, it seems that the HPD IRQ storm problem from the early
days of Intel GPUs was never entirely solved, only mostly. Within the
last couple of days, I got a bug report from one of our customers who
had been having issues with their machine suddenly booting up very
slowly after having updated. The amount of time it took to boot went
from around 30 seconds, to over 6 minutes consistently.
After some investigation, I discovered that i915 was reporting massive
amounts of short HPD IRQ spam on this system from the DisplayPort port,
despite there not being anything actually connected. The symptoms would
start with one "long" HPD IRQ being detected at boot:
[ 1.891398] [drm:intel_get_hpd_pins [i915]] hotplug event received, stat 0x00440000, dig 0x00440000, pins 0x000000a0
[ 1.891436] [drm:intel_hpd_irq_handler [i915]] digital hpd port B - long
[ 1.891472] [drm:intel_hpd_irq_handler [i915]] Received HPD interrupt on PIN 5 - cnt: 0
[ 1.891508] [drm:intel_hpd_irq_handler [i915]] digital hpd port D - long
[ 1.891544] [drm:intel_hpd_irq_handler [i915]] Received HPD interrupt on PIN 7 - cnt: 0
[ 1.891592] [drm:intel_dp_hpd_pulse [i915]] got hpd irq on port B - long
[ 1.891628] [drm:intel_dp_hpd_pulse [i915]] got hpd irq on port D - long
…
followed by constant short IRQs afterwards:
[ 1.895091] [drm:intel_encoder_hotplug [i915]] [CONNECTOR:66:DP-1] status updated from unknown to disconnected
[ 1.895129] [drm:i915_hotplug_work_func [i915]] Connector DP-3 (pin 7) received hotplug event.
[ 1.895165] [drm:intel_dp_detect [i915]] [CONNECTOR:72:DP-3]
[ 1.895275] [drm:intel_get_hpd_pins [i915]] hotplug event received, stat 0x00200000, dig 0x00200000, pins 0x00000080
[ 1.895312] [drm:intel_hpd_irq_handler [i915]] digital hpd port D - short
[ 1.895762] [drm:intel_get_hpd_pins [i915]] hotplug event received, stat 0x00200000, dig 0x00200000, pins 0x00000080
[ 1.895799] [drm:intel_hpd_irq_handler [i915]] digital hpd port D - short
[ 1.896239] [drm:intel_dp_aux_xfer [i915]] dp_aux_ch timeout status 0x71450085
[ 1.896293] [drm:intel_get_hpd_pins [i915]] hotplug event received, stat 0x00200000, dig 0x00200000, pins 0x00000080
[ 1.896330] [drm:intel_hpd_irq_handler [i915]] digital hpd port D - short
[ 1.896781] [drm:intel_get_hpd_pins [i915]] hotplug event received, stat 0x00200000, dig 0x00200000, pins 0x00000080
[ 1.896817] [drm:intel_hpd_irq_handler [i915]] digital hpd port D - short
[ 1.897275] [drm:intel_get_hpd_pins [i915]] hotplug event received, stat 0x00200000, dig 0x00200000, pins 0x00000080
The customer's system in question has a GM45 GPU, which is apparently
well known for hotplugging storms.
So, workaround this impressively broken hardware by changing the default
HPD storm threshold from 5 to 50. Then, make long IRQs count for 10, and
short IRQs count for 1. This makes it so that 5 long IRQs will trigger
an HPD storm, and on systems with short HPD storm detection 50 short
IRQs will trigger an HPD storm. 50 short IRQs amounts to 100ms of
constant pulsing, which seems like a good middleground between being too
sensitive and not being sensitive enough (which would cause visible
stutters in userspace every time a storm occurs).
And just to be extra safe: we don't enable this by default on systems
with MST support. There's too high of a chance of MST support triggering
storm detection, and systems that are new enough to support MST are a
lot less likely to have issues with IRQ storms anyway.
As a note: this patch was tested using a ThinkPad T450s and a Chamelium
to simulate the short IRQ storms.
Changes since v1:
- Don't use two separate thresholds, just make long IRQs count for 10
each and short IRQs count for 1. This simplifies the code a bit
- Ville Syrjälä
Changes since v2:
- Document @long_hpd in intel_hpd_irq_storm_detect, no functional
changes
Changes since v4:
- Remove !! in long_hpd assignment - Ville Syrjälä
- queue_hp = true - Ville Syrjälä
Signed-off-by: Lyude Paul <lyude@redhat.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181106213017.14563-6-lyude@redhat.com
2018-11-06 16:30:16 -05:00
|
|
|
hpd->stats[pin].count += increment;
|
|
|
|
if (hpd->stats[pin].count > threshold) {
|
2018-11-06 16:30:14 -05:00
|
|
|
hpd->stats[pin].state = HPD_MARK_DISABLED;
|
2025-03-20 16:45:59 +02:00
|
|
|
drm_dbg_kms(display->drm,
|
2020-03-10 10:52:46 +02:00
|
|
|
"HPD interrupt storm detected on PIN %d\n", pin);
|
2015-06-18 13:06:16 +03:00
|
|
|
storm = true;
|
|
|
|
} else {
|
2025-03-20 16:45:59 +02:00
|
|
|
drm_dbg_kms(display->drm,
|
2020-03-10 10:52:46 +02:00
|
|
|
"Received HPD interrupt on PIN %d - cnt: %d\n",
|
|
|
|
pin,
|
2018-11-06 16:30:14 -05:00
|
|
|
hpd->stats[pin].count);
|
2015-06-18 13:06:16 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
return storm;
|
|
|
|
}
|
|
|
|
|
2025-03-20 16:45:59 +02:00
|
|
|
static bool detection_work_enabled(struct intel_display *display)
|
2024-01-04 10:30:04 +02:00
|
|
|
{
|
2025-05-06 16:06:50 +03:00
|
|
|
lockdep_assert_held(&display->irq.lock);
|
2024-01-04 10:30:04 +02:00
|
|
|
|
2025-03-20 16:45:59 +02:00
|
|
|
return display->hotplug.detection_work_enabled;
|
2024-01-04 10:30:04 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
static bool
|
2025-03-20 16:45:59 +02:00
|
|
|
mod_delayed_detection_work(struct intel_display *display, struct delayed_work *work, int delay)
|
2024-01-04 10:30:04 +02:00
|
|
|
{
|
2025-05-06 16:06:50 +03:00
|
|
|
lockdep_assert_held(&display->irq.lock);
|
2024-01-04 10:30:04 +02:00
|
|
|
|
2025-03-20 16:45:59 +02:00
|
|
|
if (!detection_work_enabled(display))
|
2024-01-04 10:30:04 +02:00
|
|
|
return false;
|
|
|
|
|
2025-06-20 12:15:30 +03:00
|
|
|
return mod_delayed_work(display->wq.unordered, work, delay);
|
2024-01-04 10:30:04 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
static bool
|
2025-03-20 16:45:59 +02:00
|
|
|
queue_delayed_detection_work(struct intel_display *display, struct delayed_work *work, int delay)
|
2024-01-04 10:30:04 +02:00
|
|
|
{
|
2025-05-06 16:06:50 +03:00
|
|
|
lockdep_assert_held(&display->irq.lock);
|
2024-01-04 10:30:04 +02:00
|
|
|
|
2025-03-20 16:45:59 +02:00
|
|
|
if (!detection_work_enabled(display))
|
2024-01-04 10:30:04 +02:00
|
|
|
return false;
|
|
|
|
|
2025-06-20 12:15:30 +03:00
|
|
|
return queue_delayed_work(display->wq.unordered, work, delay);
|
2024-01-04 10:30:04 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
static bool
|
2025-03-20 16:45:59 +02:00
|
|
|
queue_detection_work(struct intel_display *display, struct work_struct *work)
|
2024-01-04 10:30:04 +02:00
|
|
|
{
|
2025-05-06 16:06:50 +03:00
|
|
|
lockdep_assert_held(&display->irq.lock);
|
2024-01-04 10:30:04 +02:00
|
|
|
|
2025-03-20 16:45:59 +02:00
|
|
|
if (!detection_work_enabled(display))
|
2024-01-04 10:30:04 +02:00
|
|
|
return false;
|
|
|
|
|
2025-06-20 12:15:30 +03:00
|
|
|
return queue_work(display->wq.unordered, work);
|
2024-01-04 10:30:04 +02:00
|
|
|
}
|
|
|
|
|
2018-11-06 16:30:15 -05:00
|
|
|
static void
|
2025-03-20 16:45:59 +02:00
|
|
|
intel_hpd_irq_storm_switch_to_polling(struct intel_display *display)
|
2015-06-18 13:06:16 +03:00
|
|
|
{
|
2017-03-01 10:52:22 +01:00
|
|
|
struct drm_connector_list_iter conn_iter;
|
2020-01-21 19:10:50 +02:00
|
|
|
struct intel_connector *connector;
|
2015-06-18 13:06:16 +03:00
|
|
|
bool hpd_disabled = false;
|
|
|
|
|
2025-05-06 16:06:50 +03:00
|
|
|
lockdep_assert_held(&display->irq.lock);
|
2015-06-18 13:06:16 +03:00
|
|
|
|
2025-03-20 16:45:59 +02:00
|
|
|
drm_connector_list_iter_begin(display->drm, &conn_iter);
|
2020-01-21 19:10:50 +02:00
|
|
|
for_each_intel_connector_iter(connector, &conn_iter) {
|
|
|
|
enum hpd_pin pin;
|
|
|
|
|
|
|
|
if (connector->base.polled != DRM_CONNECTOR_POLL_HPD)
|
2015-06-18 13:06:16 +03:00
|
|
|
continue;
|
|
|
|
|
2020-01-21 19:10:51 +02:00
|
|
|
pin = intel_connector_hpd_pin(connector);
|
2015-06-18 13:06:16 +03:00
|
|
|
if (pin == HPD_NONE ||
|
2025-03-20 16:45:59 +02:00
|
|
|
display->hotplug.stats[pin].state != HPD_MARK_DISABLED)
|
2015-06-18 13:06:16 +03:00
|
|
|
continue;
|
|
|
|
|
2025-03-20 16:45:59 +02:00
|
|
|
drm_info(display->drm,
|
2020-03-10 10:52:46 +02:00
|
|
|
"HPD interrupt storm detected on connector %s: "
|
2015-06-18 13:06:16 +03:00
|
|
|
"switching from hotplug detection to polling\n",
|
2020-01-21 19:10:50 +02:00
|
|
|
connector->base.name);
|
2015-06-18 13:06:16 +03:00
|
|
|
|
2025-03-20 16:45:59 +02:00
|
|
|
display->hotplug.stats[pin].state = HPD_DISABLED;
|
2020-01-21 19:10:50 +02:00
|
|
|
connector->base.polled = DRM_CONNECTOR_POLL_CONNECT |
|
|
|
|
DRM_CONNECTOR_POLL_DISCONNECT;
|
2015-06-18 13:06:16 +03:00
|
|
|
hpd_disabled = true;
|
|
|
|
}
|
2017-03-01 10:52:22 +01:00
|
|
|
drm_connector_list_iter_end(&conn_iter);
|
2015-06-18 13:06:16 +03:00
|
|
|
|
|
|
|
/* Enable polling and queue hotplug re-enabling. */
|
|
|
|
if (hpd_disabled) {
|
2025-03-20 16:45:59 +02:00
|
|
|
drm_kms_helper_poll_reschedule(display->drm);
|
|
|
|
mod_delayed_detection_work(display,
|
|
|
|
&display->hotplug.reenable_work,
|
2024-01-04 10:30:04 +02:00
|
|
|
msecs_to_jiffies(HPD_STORM_REENABLE_DELAY));
|
2015-06-18 13:06:16 +03:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static void intel_hpd_irq_storm_reenable_work(struct work_struct *work)
|
|
|
|
{
|
2025-03-20 16:45:59 +02:00
|
|
|
struct intel_display *display =
|
|
|
|
container_of(work, typeof(*display), hotplug.reenable_work.work);
|
2020-02-05 20:35:42 +02:00
|
|
|
struct drm_connector_list_iter conn_iter;
|
|
|
|
struct intel_connector *connector;
|
2025-03-20 17:03:58 +02:00
|
|
|
struct ref_tracker *wakeref;
|
2018-07-05 19:43:54 +03:00
|
|
|
enum hpd_pin pin;
|
2015-06-18 13:06:16 +03:00
|
|
|
|
2025-03-20 17:03:58 +02:00
|
|
|
wakeref = intel_display_rpm_get(display);
|
2015-06-18 13:06:16 +03:00
|
|
|
|
2025-05-06 16:06:50 +03:00
|
|
|
spin_lock_irq(&display->irq.lock);
|
2015-06-18 13:06:16 +03:00
|
|
|
|
2025-03-20 16:45:59 +02:00
|
|
|
drm_connector_list_iter_begin(display->drm, &conn_iter);
|
2020-02-05 20:35:42 +02:00
|
|
|
for_each_intel_connector_iter(connector, &conn_iter) {
|
|
|
|
pin = intel_connector_hpd_pin(connector);
|
|
|
|
if (pin == HPD_NONE ||
|
2025-03-20 16:45:59 +02:00
|
|
|
display->hotplug.stats[pin].state != HPD_DISABLED)
|
2015-06-18 13:06:16 +03:00
|
|
|
continue;
|
|
|
|
|
2020-02-05 20:35:42 +02:00
|
|
|
if (connector->base.polled != connector->polled)
|
2025-03-20 16:45:59 +02:00
|
|
|
drm_dbg(display->drm,
|
2020-03-10 10:52:46 +02:00
|
|
|
"Reenabling HPD on connector %s\n",
|
|
|
|
connector->base.name);
|
2020-02-05 20:35:42 +02:00
|
|
|
connector->base.polled = connector->polled;
|
2015-06-18 13:06:16 +03:00
|
|
|
}
|
2020-02-05 20:35:42 +02:00
|
|
|
drm_connector_list_iter_end(&conn_iter);
|
|
|
|
|
|
|
|
for_each_hpd_pin(pin) {
|
2025-03-20 16:45:59 +02:00
|
|
|
if (display->hotplug.stats[pin].state == HPD_DISABLED)
|
|
|
|
display->hotplug.stats[pin].state = HPD_ENABLED;
|
2020-02-05 20:35:42 +02:00
|
|
|
}
|
|
|
|
|
2025-03-20 16:46:02 +02:00
|
|
|
intel_hpd_irq_setup(display);
|
2020-02-05 20:35:42 +02:00
|
|
|
|
2025-05-06 16:06:50 +03:00
|
|
|
spin_unlock_irq(&display->irq.lock);
|
2015-06-18 13:06:16 +03:00
|
|
|
|
2025-03-20 17:03:58 +02:00
|
|
|
intel_display_rpm_put(display, wakeref);
|
2015-06-18 13:06:16 +03:00
|
|
|
}
|
|
|
|
|
2023-08-09 13:43:07 +03:00
|
|
|
static enum intel_hotplug_state
|
|
|
|
intel_hotplug_detect_connector(struct intel_connector *connector)
|
2015-06-18 13:06:16 +03:00
|
|
|
{
|
2018-01-17 21:21:46 +02:00
|
|
|
struct drm_device *dev = connector->base.dev;
|
2015-06-18 13:06:16 +03:00
|
|
|
enum drm_connector_status old_status;
|
2020-06-30 05:57:00 +05:30
|
|
|
u64 old_epoch_counter;
|
2023-08-09 13:43:06 +03:00
|
|
|
int status;
|
2020-06-30 05:57:00 +05:30
|
|
|
bool ret = false;
|
2015-06-18 13:06:16 +03:00
|
|
|
|
drm/i915/display: Make WARN* drm specific where drm_device ptr is available
drm specific WARN* calls include device information in the
backtrace, so we know what device the warnings originate from.
Covert all the calls of WARN* with device specific drm_WARN*
variants in functions where drm_device or drm_i915_private struct
pointer is readily available.
The conversion was done automatically with below coccinelle semantic
patch. checkpatch errors/warnings are fixed manually.
@rule1@
identifier func, T;
@@
func(...) {
...
struct drm_device *T = ...;
<...
(
-WARN(
+drm_WARN(T,
...)
|
-WARN_ON(
+drm_WARN_ON(T,
...)
|
-WARN_ONCE(
+drm_WARN_ONCE(T,
...)
|
-WARN_ON_ONCE(
+drm_WARN_ON_ONCE(T,
...)
)
...>
}
@rule2@
identifier func, T;
@@
func(struct drm_device *T,...) {
<...
(
-WARN(
+drm_WARN(T,
...)
|
-WARN_ON(
+drm_WARN_ON(T,
...)
|
-WARN_ONCE(
+drm_WARN_ONCE(T,
...)
|
-WARN_ON_ONCE(
+drm_WARN_ON_ONCE(T,
...)
)
...>
}
@rule3@
identifier func, T;
@@
func(...) {
...
struct drm_i915_private *T = ...;
<+...
(
-WARN(
+drm_WARN(&T->drm,
...)
|
-WARN_ON(
+drm_WARN_ON(&T->drm,
...)
|
-WARN_ONCE(
+drm_WARN_ONCE(&T->drm,
...)
|
-WARN_ON_ONCE(
+drm_WARN_ON_ONCE(&T->drm,
...)
)
...+>
}
@rule4@
identifier func, T;
@@
func(struct drm_i915_private *T,...) {
<+...
(
-WARN(
+drm_WARN(&T->drm,
...)
|
-WARN_ON(
+drm_WARN_ON(&T->drm,
...)
|
-WARN_ONCE(
+drm_WARN_ONCE(&T->drm,
...)
|
-WARN_ON_ONCE(
+drm_WARN_ON_ONCE(&T->drm,
...)
)
...+>
}
Signed-off-by: Pankaj Bharadiya <pankaj.laxminarayan.bharadiya@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200128181603.27767-20-pankaj.laxminarayan.bharadiya@intel.com
2020-01-28 23:46:01 +05:30
|
|
|
drm_WARN_ON(dev, !mutex_is_locked(&dev->mode_config.mutex));
|
2018-01-17 21:21:46 +02:00
|
|
|
old_status = connector->base.status;
|
2020-07-01 21:00:01 +03:00
|
|
|
old_epoch_counter = connector->base.epoch_counter;
|
2015-06-18 13:06:16 +03:00
|
|
|
|
2023-08-09 13:43:06 +03:00
|
|
|
status = drm_helper_probe_detect(&connector->base, NULL, false);
|
|
|
|
if (!connector->base.force)
|
|
|
|
connector->base.status = status;
|
2017-04-06 20:55:20 +02:00
|
|
|
|
2020-06-30 05:57:00 +05:30
|
|
|
if (old_epoch_counter != connector->base.epoch_counter)
|
|
|
|
ret = true;
|
|
|
|
|
|
|
|
if (ret) {
|
2022-01-21 15:00:32 +02:00
|
|
|
drm_dbg_kms(dev, "[CONNECTOR:%d:%s] status updated from %s to %s (epoch counter %llu->%llu)\n",
|
|
|
|
connector->base.base.id,
|
|
|
|
connector->base.name,
|
|
|
|
drm_get_connector_status_name(old_status),
|
|
|
|
drm_get_connector_status_name(connector->base.status),
|
|
|
|
old_epoch_counter,
|
|
|
|
connector->base.epoch_counter);
|
2020-06-30 05:57:00 +05:30
|
|
|
return INTEL_HOTPLUG_CHANGED;
|
|
|
|
}
|
|
|
|
return INTEL_HOTPLUG_UNCHANGED;
|
2015-06-18 13:06:16 +03:00
|
|
|
}
|
|
|
|
|
2023-08-09 13:43:07 +03:00
|
|
|
enum intel_hotplug_state
|
|
|
|
intel_encoder_hotplug(struct intel_encoder *encoder,
|
|
|
|
struct intel_connector *connector)
|
|
|
|
{
|
|
|
|
return intel_hotplug_detect_connector(connector);
|
|
|
|
}
|
|
|
|
|
2018-07-05 19:43:53 +03:00
|
|
|
static bool intel_encoder_has_hpd_pulse(struct intel_encoder *encoder)
|
|
|
|
{
|
|
|
|
return intel_encoder_is_dig_port(encoder) &&
|
2019-12-04 20:05:43 +02:00
|
|
|
enc_to_dig_port(encoder)->hpd_pulse != NULL;
|
2018-07-05 19:43:53 +03:00
|
|
|
}
|
|
|
|
|
2025-03-05 13:48:19 +02:00
|
|
|
static bool hpd_pin_has_pulse(struct intel_display *display, enum hpd_pin pin)
|
|
|
|
{
|
|
|
|
struct intel_encoder *encoder;
|
|
|
|
|
|
|
|
for_each_intel_encoder(display->drm, encoder) {
|
|
|
|
if (encoder->hpd_pin != pin)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
if (intel_encoder_has_hpd_pulse(encoder))
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
static bool hpd_pin_is_blocked(struct intel_display *display, enum hpd_pin pin)
|
|
|
|
{
|
2025-05-06 16:06:50 +03:00
|
|
|
lockdep_assert_held(&display->irq.lock);
|
2025-03-05 13:48:19 +02:00
|
|
|
|
|
|
|
return display->hotplug.stats[pin].blocked_count;
|
|
|
|
}
|
|
|
|
|
|
|
|
static u32 get_blocked_hpd_pin_mask(struct intel_display *display)
|
|
|
|
{
|
|
|
|
enum hpd_pin pin;
|
|
|
|
u32 hpd_pin_mask = 0;
|
|
|
|
|
|
|
|
for_each_hpd_pin(pin) {
|
|
|
|
if (hpd_pin_is_blocked(display, pin))
|
|
|
|
hpd_pin_mask |= BIT(pin);
|
|
|
|
}
|
|
|
|
|
|
|
|
return hpd_pin_mask;
|
|
|
|
}
|
|
|
|
|
2015-06-18 13:06:16 +03:00
|
|
|
static void i915_digport_work_func(struct work_struct *work)
|
|
|
|
{
|
2025-03-05 13:48:19 +02:00
|
|
|
struct intel_display *display =
|
|
|
|
container_of(work, struct intel_display, hotplug.dig_port_work);
|
|
|
|
struct intel_hotplug *hotplug = &display->hotplug;
|
2025-03-04 17:29:12 +02:00
|
|
|
u32 long_hpd_pin_mask, short_hpd_pin_mask;
|
2018-07-05 19:43:53 +03:00
|
|
|
struct intel_encoder *encoder;
|
2025-03-05 13:48:19 +02:00
|
|
|
u32 blocked_hpd_pin_mask;
|
2015-06-18 13:06:16 +03:00
|
|
|
u32 old_bits = 0;
|
|
|
|
|
2025-05-06 16:06:50 +03:00
|
|
|
spin_lock_irq(&display->irq.lock);
|
2025-03-05 13:48:19 +02:00
|
|
|
|
|
|
|
blocked_hpd_pin_mask = get_blocked_hpd_pin_mask(display);
|
|
|
|
long_hpd_pin_mask = hotplug->long_hpd_pin_mask & ~blocked_hpd_pin_mask;
|
|
|
|
hotplug->long_hpd_pin_mask &= ~long_hpd_pin_mask;
|
|
|
|
short_hpd_pin_mask = hotplug->short_hpd_pin_mask & ~blocked_hpd_pin_mask;
|
|
|
|
hotplug->short_hpd_pin_mask &= ~short_hpd_pin_mask;
|
|
|
|
|
2025-05-06 16:06:50 +03:00
|
|
|
spin_unlock_irq(&display->irq.lock);
|
2015-06-18 13:06:16 +03:00
|
|
|
|
2025-03-20 16:45:59 +02:00
|
|
|
for_each_intel_encoder(display->drm, encoder) {
|
2018-07-05 19:43:53 +03:00
|
|
|
struct intel_digital_port *dig_port;
|
2025-03-04 17:29:12 +02:00
|
|
|
enum hpd_pin pin = encoder->hpd_pin;
|
2018-07-05 19:43:53 +03:00
|
|
|
bool long_hpd, short_hpd;
|
|
|
|
enum irqreturn ret;
|
|
|
|
|
|
|
|
if (!intel_encoder_has_hpd_pulse(encoder))
|
2015-06-18 13:06:16 +03:00
|
|
|
continue;
|
|
|
|
|
2025-03-04 17:29:12 +02:00
|
|
|
long_hpd = long_hpd_pin_mask & BIT(pin);
|
|
|
|
short_hpd = short_hpd_pin_mask & BIT(pin);
|
2018-07-05 19:43:53 +03:00
|
|
|
|
|
|
|
if (!long_hpd && !short_hpd)
|
|
|
|
continue;
|
2015-06-18 13:06:16 +03:00
|
|
|
|
2019-12-04 20:05:43 +02:00
|
|
|
dig_port = enc_to_dig_port(encoder);
|
2015-06-18 13:06:16 +03:00
|
|
|
|
2018-07-05 19:43:53 +03:00
|
|
|
ret = dig_port->hpd_pulse(dig_port, long_hpd);
|
|
|
|
if (ret == IRQ_NONE) {
|
|
|
|
/* fall back to old school hpd */
|
2025-03-04 17:29:12 +02:00
|
|
|
old_bits |= BIT(pin);
|
2015-06-18 13:06:16 +03:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (old_bits) {
|
2025-05-06 16:06:50 +03:00
|
|
|
spin_lock_irq(&display->irq.lock);
|
2025-03-20 16:45:59 +02:00
|
|
|
display->hotplug.event_bits |= old_bits;
|
|
|
|
queue_delayed_detection_work(display,
|
|
|
|
&display->hotplug.hotplug_work, 0);
|
2025-05-06 16:06:50 +03:00
|
|
|
spin_unlock_irq(&display->irq.lock);
|
2015-06-18 13:06:16 +03:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2020-06-04 21:45:00 +03:00
|
|
|
/**
|
|
|
|
* intel_hpd_trigger_irq - trigger an hpd irq event for a port
|
|
|
|
* @dig_port: digital port
|
|
|
|
*
|
|
|
|
* Trigger an HPD interrupt event for the given port, emulating a short pulse
|
|
|
|
* generated by the sink, and schedule the dig port work to handle it.
|
|
|
|
*/
|
|
|
|
void intel_hpd_trigger_irq(struct intel_digital_port *dig_port)
|
|
|
|
{
|
2025-03-05 13:48:19 +02:00
|
|
|
struct intel_display *display = to_intel_display(dig_port);
|
|
|
|
struct intel_hotplug *hotplug = &display->hotplug;
|
2025-03-04 17:29:12 +02:00
|
|
|
struct intel_encoder *encoder = &dig_port->base;
|
2020-06-04 21:45:00 +03:00
|
|
|
|
2025-05-06 16:06:50 +03:00
|
|
|
spin_lock_irq(&display->irq.lock);
|
2020-06-04 21:45:00 +03:00
|
|
|
|
2025-03-05 13:48:19 +02:00
|
|
|
hotplug->short_hpd_pin_mask |= BIT(encoder->hpd_pin);
|
|
|
|
if (!hpd_pin_is_blocked(display, encoder->hpd_pin))
|
|
|
|
queue_work(hotplug->dp_wq, &hotplug->dig_port_work);
|
|
|
|
|
2025-05-06 16:06:50 +03:00
|
|
|
spin_unlock_irq(&display->irq.lock);
|
2020-06-04 21:45:00 +03:00
|
|
|
}
|
|
|
|
|
2015-06-18 13:06:16 +03:00
|
|
|
/*
|
|
|
|
* Handle hotplug events outside the interrupt handler proper.
|
|
|
|
*/
|
|
|
|
static void i915_hotplug_work_func(struct work_struct *work)
|
|
|
|
{
|
2025-03-05 13:48:19 +02:00
|
|
|
struct intel_display *display =
|
|
|
|
container_of(work, struct intel_display, hotplug.hotplug_work.work);
|
|
|
|
struct intel_hotplug *hotplug = &display->hotplug;
|
2017-03-01 10:52:22 +01:00
|
|
|
struct drm_connector_list_iter conn_iter;
|
2020-01-21 19:10:50 +02:00
|
|
|
struct intel_connector *connector;
|
2019-07-11 17:53:42 -07:00
|
|
|
u32 changed = 0, retry = 0;
|
2015-06-18 13:06:16 +03:00
|
|
|
u32 hpd_event_bits;
|
2019-07-11 17:53:42 -07:00
|
|
|
u32 hpd_retry_bits;
|
2023-06-23 09:42:35 +00:00
|
|
|
struct drm_connector *first_changed_connector = NULL;
|
|
|
|
int changed_connectors = 0;
|
2025-03-05 13:48:19 +02:00
|
|
|
u32 blocked_hpd_pin_mask;
|
2015-06-18 13:06:16 +03:00
|
|
|
|
2025-03-20 16:45:59 +02:00
|
|
|
mutex_lock(&display->drm->mode_config.mutex);
|
|
|
|
drm_dbg_kms(display->drm, "running encoder hotplug functions\n");
|
2015-06-18 13:06:16 +03:00
|
|
|
|
2025-05-06 16:06:50 +03:00
|
|
|
spin_lock_irq(&display->irq.lock);
|
2015-06-18 13:06:16 +03:00
|
|
|
|
2025-03-05 13:48:19 +02:00
|
|
|
blocked_hpd_pin_mask = get_blocked_hpd_pin_mask(display);
|
|
|
|
hpd_event_bits = hotplug->event_bits & ~blocked_hpd_pin_mask;
|
|
|
|
hotplug->event_bits &= ~hpd_event_bits;
|
|
|
|
hpd_retry_bits = hotplug->retry_bits & ~blocked_hpd_pin_mask;
|
|
|
|
hotplug->retry_bits &= ~hpd_retry_bits;
|
2015-06-18 13:06:16 +03:00
|
|
|
|
2018-11-06 16:30:15 -05:00
|
|
|
/* Enable polling for connectors which had HPD IRQ storms */
|
2025-03-20 16:45:59 +02:00
|
|
|
intel_hpd_irq_storm_switch_to_polling(display);
|
2015-06-18 13:06:16 +03:00
|
|
|
|
2025-05-06 16:06:50 +03:00
|
|
|
spin_unlock_irq(&display->irq.lock);
|
2015-06-18 13:06:16 +03:00
|
|
|
|
2023-02-15 10:38:31 +02:00
|
|
|
/* Skip calling encode hotplug handlers if ignore long HPD set*/
|
2025-03-20 16:45:59 +02:00
|
|
|
if (display->hotplug.ignore_long_hpd) {
|
|
|
|
drm_dbg_kms(display->drm, "Ignore HPD flag on - skip encoder hotplug handlers\n");
|
|
|
|
mutex_unlock(&display->drm->mode_config.mutex);
|
2023-02-15 10:38:31 +02:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2025-03-20 16:45:59 +02:00
|
|
|
drm_connector_list_iter_begin(display->drm, &conn_iter);
|
2020-01-21 19:10:50 +02:00
|
|
|
for_each_intel_connector_iter(connector, &conn_iter) {
|
2020-01-21 19:10:51 +02:00
|
|
|
enum hpd_pin pin;
|
2019-07-11 17:53:42 -07:00
|
|
|
u32 hpd_bit;
|
|
|
|
|
2020-01-21 19:10:51 +02:00
|
|
|
pin = intel_connector_hpd_pin(connector);
|
|
|
|
if (pin == HPD_NONE)
|
2015-06-18 13:06:16 +03:00
|
|
|
continue;
|
2020-01-21 19:10:50 +02:00
|
|
|
|
2020-01-21 19:10:51 +02:00
|
|
|
hpd_bit = BIT(pin);
|
2019-07-11 17:53:42 -07:00
|
|
|
if ((hpd_event_bits | hpd_retry_bits) & hpd_bit) {
|
2020-01-21 19:10:51 +02:00
|
|
|
struct intel_encoder *encoder =
|
|
|
|
intel_attached_encoder(connector);
|
|
|
|
|
2020-03-30 12:54:24 +03:00
|
|
|
if (hpd_event_bits & hpd_bit)
|
|
|
|
connector->hotplug_retries = 0;
|
|
|
|
else
|
|
|
|
connector->hotplug_retries++;
|
|
|
|
|
2025-03-20 16:45:59 +02:00
|
|
|
drm_dbg_kms(display->drm,
|
2020-03-30 12:54:24 +03:00
|
|
|
"Connector %s (pin %i) received hotplug event. (retry %d)\n",
|
|
|
|
connector->base.name, pin,
|
|
|
|
connector->hotplug_retries);
|
2018-01-17 21:21:46 +02:00
|
|
|
|
2020-03-30 12:54:24 +03:00
|
|
|
switch (encoder->hotplug(encoder, connector)) {
|
2019-07-11 17:53:42 -07:00
|
|
|
case INTEL_HOTPLUG_UNCHANGED:
|
|
|
|
break;
|
|
|
|
case INTEL_HOTPLUG_CHANGED:
|
|
|
|
changed |= hpd_bit;
|
2023-06-23 09:42:35 +00:00
|
|
|
changed_connectors++;
|
|
|
|
if (!first_changed_connector) {
|
|
|
|
drm_connector_get(&connector->base);
|
|
|
|
first_changed_connector = &connector->base;
|
|
|
|
}
|
2019-07-11 17:53:42 -07:00
|
|
|
break;
|
|
|
|
case INTEL_HOTPLUG_RETRY:
|
|
|
|
retry |= hpd_bit;
|
|
|
|
break;
|
|
|
|
}
|
2015-06-18 13:06:16 +03:00
|
|
|
}
|
|
|
|
}
|
2017-03-01 10:52:22 +01:00
|
|
|
drm_connector_list_iter_end(&conn_iter);
|
2025-03-20 16:45:59 +02:00
|
|
|
mutex_unlock(&display->drm->mode_config.mutex);
|
2015-06-18 13:06:16 +03:00
|
|
|
|
2023-06-23 09:42:35 +00:00
|
|
|
if (changed_connectors == 1)
|
|
|
|
drm_kms_helper_connector_hotplug_event(first_changed_connector);
|
|
|
|
else if (changed_connectors > 0)
|
2025-03-20 16:45:59 +02:00
|
|
|
drm_kms_helper_hotplug_event(display->drm);
|
2019-07-11 17:53:42 -07:00
|
|
|
|
2023-06-23 09:42:35 +00:00
|
|
|
if (first_changed_connector)
|
|
|
|
drm_connector_put(first_changed_connector);
|
|
|
|
|
2019-07-11 17:53:42 -07:00
|
|
|
/* Remove shared HPD pins that have changed */
|
|
|
|
retry &= ~changed;
|
|
|
|
if (retry) {
|
2025-05-06 16:06:50 +03:00
|
|
|
spin_lock_irq(&display->irq.lock);
|
2025-03-20 16:45:59 +02:00
|
|
|
display->hotplug.retry_bits |= retry;
|
2019-07-11 17:53:42 -07:00
|
|
|
|
2025-03-20 16:45:59 +02:00
|
|
|
mod_delayed_detection_work(display,
|
|
|
|
&display->hotplug.hotplug_work,
|
2024-01-04 10:30:04 +02:00
|
|
|
msecs_to_jiffies(HPD_RETRY_DELAY));
|
2025-05-06 16:06:50 +03:00
|
|
|
spin_unlock_irq(&display->irq.lock);
|
2019-07-11 17:53:42 -07:00
|
|
|
}
|
2015-06-18 13:06:16 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
* intel_hpd_irq_handler - main hotplug irq handler
|
2025-03-20 16:45:59 +02:00
|
|
|
* @display: display device
|
2015-06-18 13:06:16 +03:00
|
|
|
* @pin_mask: a mask of hpd pins that have triggered the irq
|
|
|
|
* @long_mask: a mask of hpd pins that may be long hpd pulses
|
|
|
|
*
|
|
|
|
* This is the main hotplug irq handler for all platforms. The platform specific
|
|
|
|
* irq handlers call the platform specific hotplug irq handlers, which read and
|
|
|
|
* decode the appropriate registers into bitmasks about hpd pins that have
|
|
|
|
* triggered (@pin_mask), and which of those pins may be long pulses
|
|
|
|
* (@long_mask). The @long_mask is ignored if the port corresponding to the pin
|
|
|
|
* is not a digital port.
|
|
|
|
*
|
|
|
|
* Here, we do hotplug irq storm detection and mitigation, and pass further
|
|
|
|
* processing to appropriate bottom halves.
|
|
|
|
*/
|
2025-03-20 16:45:59 +02:00
|
|
|
void intel_hpd_irq_handler(struct intel_display *display,
|
2015-06-18 13:06:16 +03:00
|
|
|
u32 pin_mask, u32 long_mask)
|
|
|
|
{
|
2018-07-05 19:43:53 +03:00
|
|
|
struct intel_encoder *encoder;
|
2015-06-18 13:06:16 +03:00
|
|
|
bool storm_detected = false;
|
|
|
|
bool queue_dig = false, queue_hp = false;
|
2018-11-08 22:04:24 +02:00
|
|
|
u32 long_hpd_pulse_mask = 0;
|
|
|
|
u32 short_hpd_pulse_mask = 0;
|
|
|
|
enum hpd_pin pin;
|
2015-06-18 13:06:16 +03:00
|
|
|
|
|
|
|
if (!pin_mask)
|
|
|
|
return;
|
|
|
|
|
2025-05-06 16:06:50 +03:00
|
|
|
spin_lock(&display->irq.lock);
|
2018-11-08 22:04:24 +02:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Determine whether ->hpd_pulse() exists for each pin, and
|
|
|
|
* whether we have a short or a long pulse. This is needed
|
|
|
|
* as each pin may have up to two encoders (HDMI and DP) and
|
|
|
|
* only the one of them (DP) will have ->hpd_pulse().
|
|
|
|
*/
|
2025-03-20 16:45:59 +02:00
|
|
|
for_each_intel_encoder(display->drm, encoder) {
|
2018-11-08 22:04:24 +02:00
|
|
|
bool long_hpd;
|
2018-07-05 19:43:53 +03:00
|
|
|
|
2018-11-08 22:04:24 +02:00
|
|
|
pin = encoder->hpd_pin;
|
2018-07-05 19:43:54 +03:00
|
|
|
if (!(BIT(pin) & pin_mask))
|
2015-06-18 13:06:16 +03:00
|
|
|
continue;
|
|
|
|
|
2020-07-01 00:56:01 +03:00
|
|
|
if (!intel_encoder_has_hpd_pulse(encoder))
|
2018-11-08 22:04:24 +02:00
|
|
|
continue;
|
2015-06-18 13:06:16 +03:00
|
|
|
|
2018-11-08 22:04:24 +02:00
|
|
|
long_hpd = long_mask & BIT(pin);
|
drm/i915: Add short HPD IRQ storm detection for non-MST systems
Unfortunately, it seems that the HPD IRQ storm problem from the early
days of Intel GPUs was never entirely solved, only mostly. Within the
last couple of days, I got a bug report from one of our customers who
had been having issues with their machine suddenly booting up very
slowly after having updated. The amount of time it took to boot went
from around 30 seconds, to over 6 minutes consistently.
After some investigation, I discovered that i915 was reporting massive
amounts of short HPD IRQ spam on this system from the DisplayPort port,
despite there not being anything actually connected. The symptoms would
start with one "long" HPD IRQ being detected at boot:
[ 1.891398] [drm:intel_get_hpd_pins [i915]] hotplug event received, stat 0x00440000, dig 0x00440000, pins 0x000000a0
[ 1.891436] [drm:intel_hpd_irq_handler [i915]] digital hpd port B - long
[ 1.891472] [drm:intel_hpd_irq_handler [i915]] Received HPD interrupt on PIN 5 - cnt: 0
[ 1.891508] [drm:intel_hpd_irq_handler [i915]] digital hpd port D - long
[ 1.891544] [drm:intel_hpd_irq_handler [i915]] Received HPD interrupt on PIN 7 - cnt: 0
[ 1.891592] [drm:intel_dp_hpd_pulse [i915]] got hpd irq on port B - long
[ 1.891628] [drm:intel_dp_hpd_pulse [i915]] got hpd irq on port D - long
…
followed by constant short IRQs afterwards:
[ 1.895091] [drm:intel_encoder_hotplug [i915]] [CONNECTOR:66:DP-1] status updated from unknown to disconnected
[ 1.895129] [drm:i915_hotplug_work_func [i915]] Connector DP-3 (pin 7) received hotplug event.
[ 1.895165] [drm:intel_dp_detect [i915]] [CONNECTOR:72:DP-3]
[ 1.895275] [drm:intel_get_hpd_pins [i915]] hotplug event received, stat 0x00200000, dig 0x00200000, pins 0x00000080
[ 1.895312] [drm:intel_hpd_irq_handler [i915]] digital hpd port D - short
[ 1.895762] [drm:intel_get_hpd_pins [i915]] hotplug event received, stat 0x00200000, dig 0x00200000, pins 0x00000080
[ 1.895799] [drm:intel_hpd_irq_handler [i915]] digital hpd port D - short
[ 1.896239] [drm:intel_dp_aux_xfer [i915]] dp_aux_ch timeout status 0x71450085
[ 1.896293] [drm:intel_get_hpd_pins [i915]] hotplug event received, stat 0x00200000, dig 0x00200000, pins 0x00000080
[ 1.896330] [drm:intel_hpd_irq_handler [i915]] digital hpd port D - short
[ 1.896781] [drm:intel_get_hpd_pins [i915]] hotplug event received, stat 0x00200000, dig 0x00200000, pins 0x00000080
[ 1.896817] [drm:intel_hpd_irq_handler [i915]] digital hpd port D - short
[ 1.897275] [drm:intel_get_hpd_pins [i915]] hotplug event received, stat 0x00200000, dig 0x00200000, pins 0x00000080
The customer's system in question has a GM45 GPU, which is apparently
well known for hotplugging storms.
So, workaround this impressively broken hardware by changing the default
HPD storm threshold from 5 to 50. Then, make long IRQs count for 10, and
short IRQs count for 1. This makes it so that 5 long IRQs will trigger
an HPD storm, and on systems with short HPD storm detection 50 short
IRQs will trigger an HPD storm. 50 short IRQs amounts to 100ms of
constant pulsing, which seems like a good middleground between being too
sensitive and not being sensitive enough (which would cause visible
stutters in userspace every time a storm occurs).
And just to be extra safe: we don't enable this by default on systems
with MST support. There's too high of a chance of MST support triggering
storm detection, and systems that are new enough to support MST are a
lot less likely to have issues with IRQ storms anyway.
As a note: this patch was tested using a ThinkPad T450s and a Chamelium
to simulate the short IRQ storms.
Changes since v1:
- Don't use two separate thresholds, just make long IRQs count for 10
each and short IRQs count for 1. This simplifies the code a bit
- Ville Syrjälä
Changes since v2:
- Document @long_hpd in intel_hpd_irq_storm_detect, no functional
changes
Changes since v4:
- Remove !! in long_hpd assignment - Ville Syrjälä
- queue_hp = true - Ville Syrjälä
Signed-off-by: Lyude Paul <lyude@redhat.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181106213017.14563-6-lyude@redhat.com
2018-11-06 16:30:16 -05:00
|
|
|
|
2025-03-20 16:45:59 +02:00
|
|
|
drm_dbg(display->drm,
|
2020-03-10 10:52:46 +02:00
|
|
|
"digital hpd on [ENCODER:%d:%s] - %s\n",
|
|
|
|
encoder->base.base.id, encoder->base.name,
|
|
|
|
long_hpd ? "long" : "short");
|
2025-03-05 13:48:19 +02:00
|
|
|
|
|
|
|
if (!hpd_pin_is_blocked(display, pin))
|
|
|
|
queue_dig = true;
|
drm/i915: Add short HPD IRQ storm detection for non-MST systems
Unfortunately, it seems that the HPD IRQ storm problem from the early
days of Intel GPUs was never entirely solved, only mostly. Within the
last couple of days, I got a bug report from one of our customers who
had been having issues with their machine suddenly booting up very
slowly after having updated. The amount of time it took to boot went
from around 30 seconds, to over 6 minutes consistently.
After some investigation, I discovered that i915 was reporting massive
amounts of short HPD IRQ spam on this system from the DisplayPort port,
despite there not being anything actually connected. The symptoms would
start with one "long" HPD IRQ being detected at boot:
[ 1.891398] [drm:intel_get_hpd_pins [i915]] hotplug event received, stat 0x00440000, dig 0x00440000, pins 0x000000a0
[ 1.891436] [drm:intel_hpd_irq_handler [i915]] digital hpd port B - long
[ 1.891472] [drm:intel_hpd_irq_handler [i915]] Received HPD interrupt on PIN 5 - cnt: 0
[ 1.891508] [drm:intel_hpd_irq_handler [i915]] digital hpd port D - long
[ 1.891544] [drm:intel_hpd_irq_handler [i915]] Received HPD interrupt on PIN 7 - cnt: 0
[ 1.891592] [drm:intel_dp_hpd_pulse [i915]] got hpd irq on port B - long
[ 1.891628] [drm:intel_dp_hpd_pulse [i915]] got hpd irq on port D - long
…
followed by constant short IRQs afterwards:
[ 1.895091] [drm:intel_encoder_hotplug [i915]] [CONNECTOR:66:DP-1] status updated from unknown to disconnected
[ 1.895129] [drm:i915_hotplug_work_func [i915]] Connector DP-3 (pin 7) received hotplug event.
[ 1.895165] [drm:intel_dp_detect [i915]] [CONNECTOR:72:DP-3]
[ 1.895275] [drm:intel_get_hpd_pins [i915]] hotplug event received, stat 0x00200000, dig 0x00200000, pins 0x00000080
[ 1.895312] [drm:intel_hpd_irq_handler [i915]] digital hpd port D - short
[ 1.895762] [drm:intel_get_hpd_pins [i915]] hotplug event received, stat 0x00200000, dig 0x00200000, pins 0x00000080
[ 1.895799] [drm:intel_hpd_irq_handler [i915]] digital hpd port D - short
[ 1.896239] [drm:intel_dp_aux_xfer [i915]] dp_aux_ch timeout status 0x71450085
[ 1.896293] [drm:intel_get_hpd_pins [i915]] hotplug event received, stat 0x00200000, dig 0x00200000, pins 0x00000080
[ 1.896330] [drm:intel_hpd_irq_handler [i915]] digital hpd port D - short
[ 1.896781] [drm:intel_get_hpd_pins [i915]] hotplug event received, stat 0x00200000, dig 0x00200000, pins 0x00000080
[ 1.896817] [drm:intel_hpd_irq_handler [i915]] digital hpd port D - short
[ 1.897275] [drm:intel_get_hpd_pins [i915]] hotplug event received, stat 0x00200000, dig 0x00200000, pins 0x00000080
The customer's system in question has a GM45 GPU, which is apparently
well known for hotplugging storms.
So, workaround this impressively broken hardware by changing the default
HPD storm threshold from 5 to 50. Then, make long IRQs count for 10, and
short IRQs count for 1. This makes it so that 5 long IRQs will trigger
an HPD storm, and on systems with short HPD storm detection 50 short
IRQs will trigger an HPD storm. 50 short IRQs amounts to 100ms of
constant pulsing, which seems like a good middleground between being too
sensitive and not being sensitive enough (which would cause visible
stutters in userspace every time a storm occurs).
And just to be extra safe: we don't enable this by default on systems
with MST support. There's too high of a chance of MST support triggering
storm detection, and systems that are new enough to support MST are a
lot less likely to have issues with IRQ storms anyway.
As a note: this patch was tested using a ThinkPad T450s and a Chamelium
to simulate the short IRQ storms.
Changes since v1:
- Don't use two separate thresholds, just make long IRQs count for 10
each and short IRQs count for 1. This simplifies the code a bit
- Ville Syrjälä
Changes since v2:
- Document @long_hpd in intel_hpd_irq_storm_detect, no functional
changes
Changes since v4:
- Remove !! in long_hpd assignment - Ville Syrjälä
- queue_hp = true - Ville Syrjälä
Signed-off-by: Lyude Paul <lyude@redhat.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181106213017.14563-6-lyude@redhat.com
2018-11-06 16:30:16 -05:00
|
|
|
|
2018-11-08 22:04:24 +02:00
|
|
|
if (long_hpd) {
|
|
|
|
long_hpd_pulse_mask |= BIT(pin);
|
2025-03-20 16:45:59 +02:00
|
|
|
display->hotplug.long_hpd_pin_mask |= BIT(pin);
|
2018-11-08 22:04:24 +02:00
|
|
|
} else {
|
|
|
|
short_hpd_pulse_mask |= BIT(pin);
|
2025-03-20 16:45:59 +02:00
|
|
|
display->hotplug.short_hpd_pin_mask |= BIT(pin);
|
2015-06-18 13:06:16 +03:00
|
|
|
}
|
2018-11-08 22:04:24 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
/* Now process each pin just once */
|
|
|
|
for_each_hpd_pin(pin) {
|
|
|
|
bool long_hpd;
|
|
|
|
|
|
|
|
if (!(BIT(pin) & pin_mask))
|
|
|
|
continue;
|
2015-06-18 13:06:16 +03:00
|
|
|
|
2025-03-20 16:45:59 +02:00
|
|
|
if (display->hotplug.stats[pin].state == HPD_DISABLED) {
|
2015-06-18 13:06:16 +03:00
|
|
|
/*
|
|
|
|
* On GMCH platforms the interrupt mask bits only
|
|
|
|
* prevent irq generation, not the setting of the
|
|
|
|
* hotplug bits itself. So only WARN about unexpected
|
|
|
|
* interrupts on saner platforms.
|
|
|
|
*/
|
2025-03-20 16:45:59 +02:00
|
|
|
drm_WARN_ONCE(display->drm, !HAS_GMCH(display),
|
drm/i915/display: Make WARN* drm specific where drm_device ptr is available
drm specific WARN* calls include device information in the
backtrace, so we know what device the warnings originate from.
Covert all the calls of WARN* with device specific drm_WARN*
variants in functions where drm_device or drm_i915_private struct
pointer is readily available.
The conversion was done automatically with below coccinelle semantic
patch. checkpatch errors/warnings are fixed manually.
@rule1@
identifier func, T;
@@
func(...) {
...
struct drm_device *T = ...;
<...
(
-WARN(
+drm_WARN(T,
...)
|
-WARN_ON(
+drm_WARN_ON(T,
...)
|
-WARN_ONCE(
+drm_WARN_ONCE(T,
...)
|
-WARN_ON_ONCE(
+drm_WARN_ON_ONCE(T,
...)
)
...>
}
@rule2@
identifier func, T;
@@
func(struct drm_device *T,...) {
<...
(
-WARN(
+drm_WARN(T,
...)
|
-WARN_ON(
+drm_WARN_ON(T,
...)
|
-WARN_ONCE(
+drm_WARN_ONCE(T,
...)
|
-WARN_ON_ONCE(
+drm_WARN_ON_ONCE(T,
...)
)
...>
}
@rule3@
identifier func, T;
@@
func(...) {
...
struct drm_i915_private *T = ...;
<+...
(
-WARN(
+drm_WARN(&T->drm,
...)
|
-WARN_ON(
+drm_WARN_ON(&T->drm,
...)
|
-WARN_ONCE(
+drm_WARN_ONCE(&T->drm,
...)
|
-WARN_ON_ONCE(
+drm_WARN_ON_ONCE(&T->drm,
...)
)
...+>
}
@rule4@
identifier func, T;
@@
func(struct drm_i915_private *T,...) {
<+...
(
-WARN(
+drm_WARN(&T->drm,
...)
|
-WARN_ON(
+drm_WARN_ON(&T->drm,
...)
|
-WARN_ONCE(
+drm_WARN_ONCE(&T->drm,
...)
|
-WARN_ON_ONCE(
+drm_WARN_ON_ONCE(&T->drm,
...)
)
...+>
}
Signed-off-by: Pankaj Bharadiya <pankaj.laxminarayan.bharadiya@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200128181603.27767-20-pankaj.laxminarayan.bharadiya@intel.com
2020-01-28 23:46:01 +05:30
|
|
|
"Received HPD interrupt on pin %d although disabled\n",
|
|
|
|
pin);
|
2015-06-18 13:06:16 +03:00
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
2025-03-20 16:45:59 +02:00
|
|
|
if (display->hotplug.stats[pin].state != HPD_ENABLED)
|
2015-06-18 13:06:16 +03:00
|
|
|
continue;
|
|
|
|
|
2018-11-08 22:04:24 +02:00
|
|
|
/*
|
|
|
|
* Delegate to ->hpd_pulse() if one of the encoders for this
|
|
|
|
* pin has it, otherwise let the hotplug_work deal with this
|
|
|
|
* pin directly.
|
|
|
|
*/
|
|
|
|
if (((short_hpd_pulse_mask | long_hpd_pulse_mask) & BIT(pin))) {
|
|
|
|
long_hpd = long_hpd_pulse_mask & BIT(pin);
|
|
|
|
} else {
|
2025-03-20 16:45:59 +02:00
|
|
|
display->hotplug.event_bits |= BIT(pin);
|
2018-11-08 22:04:24 +02:00
|
|
|
long_hpd = true;
|
2025-03-05 13:48:19 +02:00
|
|
|
|
|
|
|
if (!hpd_pin_is_blocked(display, pin))
|
|
|
|
queue_hp = true;
|
2015-06-18 13:06:16 +03:00
|
|
|
}
|
|
|
|
|
2025-03-20 16:45:59 +02:00
|
|
|
if (intel_hpd_irq_storm_detect(display, pin, long_hpd)) {
|
|
|
|
display->hotplug.event_bits &= ~BIT(pin);
|
2015-06-18 13:06:16 +03:00
|
|
|
storm_detected = true;
|
drm/i915: Add short HPD IRQ storm detection for non-MST systems
Unfortunately, it seems that the HPD IRQ storm problem from the early
days of Intel GPUs was never entirely solved, only mostly. Within the
last couple of days, I got a bug report from one of our customers who
had been having issues with their machine suddenly booting up very
slowly after having updated. The amount of time it took to boot went
from around 30 seconds, to over 6 minutes consistently.
After some investigation, I discovered that i915 was reporting massive
amounts of short HPD IRQ spam on this system from the DisplayPort port,
despite there not being anything actually connected. The symptoms would
start with one "long" HPD IRQ being detected at boot:
[ 1.891398] [drm:intel_get_hpd_pins [i915]] hotplug event received, stat 0x00440000, dig 0x00440000, pins 0x000000a0
[ 1.891436] [drm:intel_hpd_irq_handler [i915]] digital hpd port B - long
[ 1.891472] [drm:intel_hpd_irq_handler [i915]] Received HPD interrupt on PIN 5 - cnt: 0
[ 1.891508] [drm:intel_hpd_irq_handler [i915]] digital hpd port D - long
[ 1.891544] [drm:intel_hpd_irq_handler [i915]] Received HPD interrupt on PIN 7 - cnt: 0
[ 1.891592] [drm:intel_dp_hpd_pulse [i915]] got hpd irq on port B - long
[ 1.891628] [drm:intel_dp_hpd_pulse [i915]] got hpd irq on port D - long
…
followed by constant short IRQs afterwards:
[ 1.895091] [drm:intel_encoder_hotplug [i915]] [CONNECTOR:66:DP-1] status updated from unknown to disconnected
[ 1.895129] [drm:i915_hotplug_work_func [i915]] Connector DP-3 (pin 7) received hotplug event.
[ 1.895165] [drm:intel_dp_detect [i915]] [CONNECTOR:72:DP-3]
[ 1.895275] [drm:intel_get_hpd_pins [i915]] hotplug event received, stat 0x00200000, dig 0x00200000, pins 0x00000080
[ 1.895312] [drm:intel_hpd_irq_handler [i915]] digital hpd port D - short
[ 1.895762] [drm:intel_get_hpd_pins [i915]] hotplug event received, stat 0x00200000, dig 0x00200000, pins 0x00000080
[ 1.895799] [drm:intel_hpd_irq_handler [i915]] digital hpd port D - short
[ 1.896239] [drm:intel_dp_aux_xfer [i915]] dp_aux_ch timeout status 0x71450085
[ 1.896293] [drm:intel_get_hpd_pins [i915]] hotplug event received, stat 0x00200000, dig 0x00200000, pins 0x00000080
[ 1.896330] [drm:intel_hpd_irq_handler [i915]] digital hpd port D - short
[ 1.896781] [drm:intel_get_hpd_pins [i915]] hotplug event received, stat 0x00200000, dig 0x00200000, pins 0x00000080
[ 1.896817] [drm:intel_hpd_irq_handler [i915]] digital hpd port D - short
[ 1.897275] [drm:intel_get_hpd_pins [i915]] hotplug event received, stat 0x00200000, dig 0x00200000, pins 0x00000080
The customer's system in question has a GM45 GPU, which is apparently
well known for hotplugging storms.
So, workaround this impressively broken hardware by changing the default
HPD storm threshold from 5 to 50. Then, make long IRQs count for 10, and
short IRQs count for 1. This makes it so that 5 long IRQs will trigger
an HPD storm, and on systems with short HPD storm detection 50 short
IRQs will trigger an HPD storm. 50 short IRQs amounts to 100ms of
constant pulsing, which seems like a good middleground between being too
sensitive and not being sensitive enough (which would cause visible
stutters in userspace every time a storm occurs).
And just to be extra safe: we don't enable this by default on systems
with MST support. There's too high of a chance of MST support triggering
storm detection, and systems that are new enough to support MST are a
lot less likely to have issues with IRQ storms anyway.
As a note: this patch was tested using a ThinkPad T450s and a Chamelium
to simulate the short IRQ storms.
Changes since v1:
- Don't use two separate thresholds, just make long IRQs count for 10
each and short IRQs count for 1. This simplifies the code a bit
- Ville Syrjälä
Changes since v2:
- Document @long_hpd in intel_hpd_irq_storm_detect, no functional
changes
Changes since v4:
- Remove !! in long_hpd assignment - Ville Syrjälä
- queue_hp = true - Ville Syrjälä
Signed-off-by: Lyude Paul <lyude@redhat.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181106213017.14563-6-lyude@redhat.com
2018-11-06 16:30:16 -05:00
|
|
|
queue_hp = true;
|
2015-06-18 13:06:16 +03:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2018-11-06 16:30:15 -05:00
|
|
|
/*
|
|
|
|
* Disable any IRQs that storms were detected on. Polling enablement
|
|
|
|
* happens later in our hotplug work.
|
|
|
|
*/
|
2020-10-06 21:58:09 +03:00
|
|
|
if (storm_detected)
|
2025-03-20 16:46:02 +02:00
|
|
|
intel_hpd_irq_setup(display);
|
2015-06-18 13:06:16 +03:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Our hotplug handler can grab modeset locks (by calling down into the
|
|
|
|
* fb helpers). Hence it must not be run on our own dev-priv->wq work
|
|
|
|
* queue for otherwise the flush_work in the pageflip code will
|
|
|
|
* deadlock.
|
|
|
|
*/
|
|
|
|
if (queue_dig)
|
2025-03-20 16:45:59 +02:00
|
|
|
queue_work(display->hotplug.dp_wq, &display->hotplug.dig_port_work);
|
2015-06-18 13:06:16 +03:00
|
|
|
if (queue_hp)
|
2025-03-20 16:45:59 +02:00
|
|
|
queue_delayed_detection_work(display,
|
|
|
|
&display->hotplug.hotplug_work, 0);
|
2024-01-04 10:30:04 +02:00
|
|
|
|
2025-05-06 16:06:50 +03:00
|
|
|
spin_unlock(&display->irq.lock);
|
2015-06-18 13:06:16 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* intel_hpd_init - initializes and enables hpd support
|
2025-03-20 16:45:59 +02:00
|
|
|
* @display: display device instance
|
2015-06-18 13:06:16 +03:00
|
|
|
*
|
|
|
|
* This function enables the hotplug support. It requires that interrupts have
|
|
|
|
* already been enabled with intel_irq_init_hw(). From this point on hotplug and
|
|
|
|
* poll request can run concurrently to other code, so locking rules must be
|
|
|
|
* obeyed.
|
|
|
|
*
|
|
|
|
* This is a separate step from interrupt enabling to simplify the locking rules
|
|
|
|
* in the driver load and resume code.
|
2016-06-21 17:03:44 -04:00
|
|
|
*
|
2020-10-13 21:11:37 +03:00
|
|
|
* Also see: intel_hpd_poll_enable() and intel_hpd_poll_disable().
|
2015-06-18 13:06:16 +03:00
|
|
|
*/
|
2025-03-20 16:45:59 +02:00
|
|
|
void intel_hpd_init(struct intel_display *display)
|
2015-06-18 13:06:16 +03:00
|
|
|
{
|
|
|
|
int i;
|
|
|
|
|
2025-03-20 16:45:59 +02:00
|
|
|
if (!HAS_DISPLAY(display))
|
drm/i915: skip display initialization when there is no display
Display features should not be initialized or de-initialized when there
is no display. Skip modeset initialization, output setup, plane, crtc,
encoder, connector registration, display cdclk and rawclk
initialization, display core initialization, etc.
Skip the functionality at as high level as possible, and remove any
redundant checks. If the functionality is conditional to *other* display
checks, do not add more. If the un-initialization has checks for
initialization, do not add more.
We explicitly do not care about any GMCH/VLV/CHV code paths, as they've
always had and will have display.
Reviewed-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210408203150.237947-3-jose.souza@intel.com
2021-04-08 13:31:50 -07:00
|
|
|
return;
|
|
|
|
|
2015-06-18 13:06:16 +03:00
|
|
|
for_each_hpd_pin(i) {
|
2025-03-20 16:45:59 +02:00
|
|
|
display->hotplug.stats[i].count = 0;
|
|
|
|
display->hotplug.stats[i].state = HPD_ENABLED;
|
2015-06-18 13:06:16 +03:00
|
|
|
}
|
2016-06-21 17:03:44 -04:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Interrupt setup is already guaranteed to be single-threaded, this is
|
|
|
|
* just to make the assert_spin_locked checks happy.
|
|
|
|
*/
|
2025-05-06 16:06:50 +03:00
|
|
|
spin_lock_irq(&display->irq.lock);
|
2025-03-20 16:46:02 +02:00
|
|
|
intel_hpd_irq_setup(display);
|
2025-05-06 16:06:50 +03:00
|
|
|
spin_unlock_irq(&display->irq.lock);
|
2016-06-21 17:03:44 -04:00
|
|
|
}
|
|
|
|
|
2025-03-20 16:45:59 +02:00
|
|
|
static void i915_hpd_poll_detect_connectors(struct intel_display *display)
|
2023-08-09 13:43:07 +03:00
|
|
|
{
|
|
|
|
struct drm_connector_list_iter conn_iter;
|
|
|
|
struct intel_connector *connector;
|
|
|
|
struct intel_connector *first_changed_connector = NULL;
|
|
|
|
int changed = 0;
|
|
|
|
|
2025-03-20 16:45:59 +02:00
|
|
|
mutex_lock(&display->drm->mode_config.mutex);
|
2023-08-09 13:43:07 +03:00
|
|
|
|
2025-03-20 16:45:59 +02:00
|
|
|
if (!display->drm->mode_config.poll_enabled)
|
2023-08-09 13:43:07 +03:00
|
|
|
goto out;
|
|
|
|
|
2025-03-20 16:45:59 +02:00
|
|
|
drm_connector_list_iter_begin(display->drm, &conn_iter);
|
2023-08-09 13:43:07 +03:00
|
|
|
for_each_intel_connector_iter(connector, &conn_iter) {
|
|
|
|
if (!(connector->base.polled & DRM_CONNECTOR_POLL_HPD))
|
|
|
|
continue;
|
|
|
|
|
|
|
|
if (intel_hotplug_detect_connector(connector) != INTEL_HOTPLUG_CHANGED)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
changed++;
|
|
|
|
|
|
|
|
if (changed == 1) {
|
|
|
|
drm_connector_get(&connector->base);
|
|
|
|
first_changed_connector = connector;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
drm_connector_list_iter_end(&conn_iter);
|
|
|
|
|
|
|
|
out:
|
2025-03-20 16:45:59 +02:00
|
|
|
mutex_unlock(&display->drm->mode_config.mutex);
|
2023-08-09 13:43:07 +03:00
|
|
|
|
|
|
|
if (!changed)
|
|
|
|
return;
|
|
|
|
|
|
|
|
if (changed == 1)
|
|
|
|
drm_kms_helper_connector_hotplug_event(&first_changed_connector->base);
|
|
|
|
else
|
2025-03-20 16:45:59 +02:00
|
|
|
drm_kms_helper_hotplug_event(display->drm);
|
2023-08-09 13:43:07 +03:00
|
|
|
|
|
|
|
drm_connector_put(&first_changed_connector->base);
|
|
|
|
}
|
|
|
|
|
2016-08-17 12:09:06 +01:00
|
|
|
static void i915_hpd_poll_init_work(struct work_struct *work)
|
|
|
|
{
|
2025-03-20 16:45:59 +02:00
|
|
|
struct intel_display *display =
|
|
|
|
container_of(work, typeof(*display), hotplug.poll_init_work);
|
2017-03-01 10:52:22 +01:00
|
|
|
struct drm_connector_list_iter conn_iter;
|
2020-01-21 19:10:50 +02:00
|
|
|
struct intel_connector *connector;
|
drm/i915: Avoid endless HPD poll detect loop via runtime suspend/resume
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 <imre.deak@intel.com>
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230809104307.1218058-1-imre.deak@intel.com
2023-08-09 13:43:05 +03:00
|
|
|
intel_wakeref_t wakeref;
|
2016-06-21 17:03:44 -04:00
|
|
|
bool enabled;
|
|
|
|
|
2025-03-20 16:45:59 +02:00
|
|
|
mutex_lock(&display->drm->mode_config.mutex);
|
2016-06-21 17:03:44 -04:00
|
|
|
|
2025-03-20 16:45:59 +02:00
|
|
|
enabled = READ_ONCE(display->hotplug.poll_enabled);
|
drm/i915: Avoid endless HPD poll detect loop via runtime suspend/resume
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 <imre.deak@intel.com>
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230809104307.1218058-1-imre.deak@intel.com
2023-08-09 13:43:05 +03:00
|
|
|
/*
|
|
|
|
* Prevent taking a power reference from this sequence of
|
|
|
|
* i915_hpd_poll_init_work() -> drm_helper_hpd_irq_event() ->
|
|
|
|
* connector detect which would requeue i915_hpd_poll_init_work()
|
|
|
|
* and so risk an endless loop of this same sequence.
|
|
|
|
*/
|
|
|
|
if (!enabled) {
|
2025-02-06 20:55:27 +02:00
|
|
|
wakeref = intel_display_power_get(display,
|
drm/i915: Avoid endless HPD poll detect loop via runtime suspend/resume
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 <imre.deak@intel.com>
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230809104307.1218058-1-imre.deak@intel.com
2023-08-09 13:43:05 +03:00
|
|
|
POWER_DOMAIN_DISPLAY_CORE);
|
2025-03-20 16:45:59 +02:00
|
|
|
drm_WARN_ON(display->drm,
|
|
|
|
READ_ONCE(display->hotplug.poll_enabled));
|
|
|
|
cancel_work(&display->hotplug.poll_init_work);
|
drm/i915: Avoid endless HPD poll detect loop via runtime suspend/resume
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 <imre.deak@intel.com>
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230809104307.1218058-1-imre.deak@intel.com
2023-08-09 13:43:05 +03:00
|
|
|
}
|
2016-06-21 17:03:44 -04:00
|
|
|
|
2025-05-06 16:06:50 +03:00
|
|
|
spin_lock_irq(&display->irq.lock);
|
2024-01-04 10:29:58 +02:00
|
|
|
|
2025-03-20 16:45:59 +02:00
|
|
|
drm_connector_list_iter_begin(display->drm, &conn_iter);
|
2020-01-21 19:10:50 +02:00
|
|
|
for_each_intel_connector_iter(connector, &conn_iter) {
|
2020-02-05 20:35:43 +02:00
|
|
|
enum hpd_pin pin;
|
|
|
|
|
|
|
|
pin = intel_connector_hpd_pin(connector);
|
|
|
|
if (pin == HPD_NONE)
|
|
|
|
continue;
|
2016-01-07 10:43:28 -05:00
|
|
|
|
2025-03-20 16:45:59 +02:00
|
|
|
if (display->hotplug.stats[pin].state == HPD_DISABLED)
|
2024-01-04 10:29:58 +02:00
|
|
|
continue;
|
|
|
|
|
2020-01-21 19:10:51 +02:00
|
|
|
connector->base.polled = connector->polled;
|
2016-01-07 10:43:28 -05:00
|
|
|
|
2020-02-05 20:35:43 +02:00
|
|
|
if (enabled && connector->base.polled == DRM_CONNECTOR_POLL_HPD)
|
|
|
|
connector->base.polled = DRM_CONNECTOR_POLL_CONNECT |
|
|
|
|
DRM_CONNECTOR_POLL_DISCONNECT;
|
2015-06-18 13:06:16 +03:00
|
|
|
}
|
2017-03-01 10:52:22 +01:00
|
|
|
drm_connector_list_iter_end(&conn_iter);
|
2015-06-18 13:06:16 +03:00
|
|
|
|
2025-05-06 16:06:50 +03:00
|
|
|
spin_unlock_irq(&display->irq.lock);
|
2024-01-04 10:29:58 +02:00
|
|
|
|
2016-06-21 17:03:44 -04:00
|
|
|
if (enabled)
|
2025-03-20 16:45:59 +02:00
|
|
|
drm_kms_helper_poll_reschedule(display->drm);
|
2016-06-21 17:03:44 -04:00
|
|
|
|
2025-03-20 16:45:59 +02:00
|
|
|
mutex_unlock(&display->drm->mode_config.mutex);
|
2016-06-21 17:03:44 -04:00
|
|
|
|
2015-06-18 13:06:16 +03:00
|
|
|
/*
|
2016-06-21 17:03:44 -04:00
|
|
|
* We might have missed any hotplugs that happened while we were
|
|
|
|
* in the middle of disabling polling
|
2015-06-18 13:06:16 +03:00
|
|
|
*/
|
drm/i915: Avoid endless HPD poll detect loop via runtime suspend/resume
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 <imre.deak@intel.com>
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230809104307.1218058-1-imre.deak@intel.com
2023-08-09 13:43:05 +03:00
|
|
|
if (!enabled) {
|
2025-03-20 16:45:59 +02:00
|
|
|
i915_hpd_poll_detect_connectors(display);
|
drm/i915: Avoid endless HPD poll detect loop via runtime suspend/resume
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 <imre.deak@intel.com>
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230809104307.1218058-1-imre.deak@intel.com
2023-08-09 13:43:05 +03:00
|
|
|
|
2025-02-06 20:55:27 +02:00
|
|
|
intel_display_power_put(display,
|
drm/i915: Avoid endless HPD poll detect loop via runtime suspend/resume
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 <imre.deak@intel.com>
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230809104307.1218058-1-imre.deak@intel.com
2023-08-09 13:43:05 +03:00
|
|
|
POWER_DOMAIN_DISPLAY_CORE,
|
|
|
|
wakeref);
|
|
|
|
}
|
2016-06-21 17:03:44 -04:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
2020-10-13 21:11:37 +03:00
|
|
|
* intel_hpd_poll_enable - enable polling for connectors with hpd
|
2025-03-20 16:45:59 +02:00
|
|
|
* @display: display device instance
|
2016-06-21 17:03:44 -04:00
|
|
|
*
|
2020-10-13 21:11:37 +03:00
|
|
|
* This function enables polling for all connectors which support HPD.
|
|
|
|
* Under certain conditions HPD may not be functional. On most Intel GPUs,
|
|
|
|
* this happens when we enter runtime suspend.
|
2016-06-21 17:03:44 -04:00
|
|
|
* On Valleyview and Cherryview systems, this also happens when we shut off all
|
|
|
|
* of the powerwells.
|
|
|
|
*
|
|
|
|
* Since this function can get called in contexts where we're already holding
|
2025-01-20 13:45:16 +05:30
|
|
|
* dev->mode_config.mutex, we do the actual hotplug enabling in a separate
|
2016-06-21 17:03:44 -04:00
|
|
|
* worker.
|
|
|
|
*
|
2020-10-13 21:11:37 +03:00
|
|
|
* Also see: intel_hpd_init() and intel_hpd_poll_disable().
|
2016-06-21 17:03:44 -04:00
|
|
|
*/
|
2025-03-20 16:45:59 +02:00
|
|
|
void intel_hpd_poll_enable(struct intel_display *display)
|
2016-06-21 17:03:44 -04:00
|
|
|
{
|
2025-03-20 16:45:59 +02:00
|
|
|
if (!HAS_DISPLAY(display) || !intel_display_device_enabled(display))
|
drm/i915: skip display initialization when there is no display
Display features should not be initialized or de-initialized when there
is no display. Skip modeset initialization, output setup, plane, crtc,
encoder, connector registration, display cdclk and rawclk
initialization, display core initialization, etc.
Skip the functionality at as high level as possible, and remove any
redundant checks. If the functionality is conditional to *other* display
checks, do not add more. If the un-initialization has checks for
initialization, do not add more.
We explicitly do not care about any GMCH/VLV/CHV code paths, as they've
always had and will have display.
Reviewed-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210408203150.237947-3-jose.souza@intel.com
2021-04-08 13:31:50 -07:00
|
|
|
return;
|
|
|
|
|
2025-03-20 16:45:59 +02:00
|
|
|
WRITE_ONCE(display->hotplug.poll_enabled, true);
|
2016-06-21 17:03:44 -04:00
|
|
|
|
|
|
|
/*
|
|
|
|
* We might already be holding dev->mode_config.mutex, so do this in a
|
2025-01-20 13:45:16 +05:30
|
|
|
* separate worker
|
2016-06-21 17:03:44 -04:00
|
|
|
* As well, there's no issue if we race here since we always reschedule
|
|
|
|
* this worker anyway
|
|
|
|
*/
|
2025-05-06 16:06:50 +03:00
|
|
|
spin_lock_irq(&display->irq.lock);
|
2025-03-20 16:45:59 +02:00
|
|
|
queue_detection_work(display,
|
|
|
|
&display->hotplug.poll_init_work);
|
2025-05-06 16:06:50 +03:00
|
|
|
spin_unlock_irq(&display->irq.lock);
|
2015-06-18 13:06:16 +03:00
|
|
|
}
|
|
|
|
|
2020-10-13 21:11:37 +03:00
|
|
|
/**
|
|
|
|
* intel_hpd_poll_disable - disable polling for connectors with hpd
|
2025-03-20 16:45:59 +02:00
|
|
|
* @display: display device instance
|
2020-10-13 21:11:37 +03:00
|
|
|
*
|
|
|
|
* This function disables polling for all connectors which support HPD.
|
|
|
|
* Under certain conditions HPD may not be functional. On most Intel GPUs,
|
|
|
|
* this happens when we enter runtime suspend.
|
|
|
|
* On Valleyview and Cherryview systems, this also happens when we shut off all
|
|
|
|
* of the powerwells.
|
|
|
|
*
|
|
|
|
* Since this function can get called in contexts where we're already holding
|
2025-01-20 13:45:16 +05:30
|
|
|
* dev->mode_config.mutex, we do the actual hotplug enabling in a separate
|
2020-10-13 21:11:37 +03:00
|
|
|
* worker.
|
|
|
|
*
|
|
|
|
* Also used during driver init to initialize connector->polled
|
|
|
|
* appropriately for all connectors.
|
|
|
|
*
|
|
|
|
* Also see: intel_hpd_init() and intel_hpd_poll_enable().
|
|
|
|
*/
|
2025-03-20 16:45:59 +02:00
|
|
|
void intel_hpd_poll_disable(struct intel_display *display)
|
2020-10-13 21:11:37 +03:00
|
|
|
{
|
2025-06-09 15:55:56 +03:00
|
|
|
struct intel_encoder *encoder;
|
|
|
|
|
2025-03-20 16:45:59 +02:00
|
|
|
if (!HAS_DISPLAY(display))
|
drm/i915: skip display initialization when there is no display
Display features should not be initialized or de-initialized when there
is no display. Skip modeset initialization, output setup, plane, crtc,
encoder, connector registration, display cdclk and rawclk
initialization, display core initialization, etc.
Skip the functionality at as high level as possible, and remove any
redundant checks. If the functionality is conditional to *other* display
checks, do not add more. If the un-initialization has checks for
initialization, do not add more.
We explicitly do not care about any GMCH/VLV/CHV code paths, as they've
always had and will have display.
Reviewed-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210408203150.237947-3-jose.souza@intel.com
2021-04-08 13:31:50 -07:00
|
|
|
return;
|
|
|
|
|
2025-06-09 15:55:56 +03:00
|
|
|
for_each_intel_dp(display->drm, encoder)
|
|
|
|
intel_dp_dpcd_set_probe(enc_to_intel_dp(encoder), true);
|
|
|
|
|
2025-03-20 16:45:59 +02:00
|
|
|
WRITE_ONCE(display->hotplug.poll_enabled, false);
|
2024-01-04 10:30:04 +02:00
|
|
|
|
2025-05-06 16:06:50 +03:00
|
|
|
spin_lock_irq(&display->irq.lock);
|
2025-03-20 16:45:59 +02:00
|
|
|
queue_detection_work(display,
|
|
|
|
&display->hotplug.poll_init_work);
|
2025-05-06 16:06:50 +03:00
|
|
|
spin_unlock_irq(&display->irq.lock);
|
2020-10-13 21:11:37 +03:00
|
|
|
}
|
|
|
|
|
2025-03-20 16:45:59 +02:00
|
|
|
void intel_hpd_poll_fini(struct intel_display *display)
|
2025-02-13 17:02:13 +02:00
|
|
|
{
|
|
|
|
struct intel_connector *connector;
|
|
|
|
struct drm_connector_list_iter conn_iter;
|
|
|
|
|
|
|
|
/* Kill all the work that may have been queued by hpd. */
|
2025-03-20 16:45:59 +02:00
|
|
|
drm_connector_list_iter_begin(display->drm, &conn_iter);
|
2025-02-13 17:02:13 +02:00
|
|
|
for_each_intel_connector_iter(connector, &conn_iter) {
|
|
|
|
intel_connector_cancel_modeset_retry_work(connector);
|
|
|
|
intel_hdcp_cancel_works(connector);
|
|
|
|
}
|
|
|
|
drm_connector_list_iter_end(&conn_iter);
|
|
|
|
}
|
|
|
|
|
2025-03-20 16:45:59 +02:00
|
|
|
void intel_hpd_init_early(struct intel_display *display)
|
2015-06-18 13:06:16 +03:00
|
|
|
{
|
2025-03-20 16:45:59 +02:00
|
|
|
INIT_DELAYED_WORK(&display->hotplug.hotplug_work,
|
2019-07-11 17:53:42 -07:00
|
|
|
i915_hotplug_work_func);
|
2025-03-20 16:45:59 +02:00
|
|
|
INIT_WORK(&display->hotplug.dig_port_work, i915_digport_work_func);
|
|
|
|
INIT_WORK(&display->hotplug.poll_init_work, i915_hpd_poll_init_work);
|
|
|
|
INIT_DELAYED_WORK(&display->hotplug.reenable_work,
|
2015-06-18 13:06:16 +03:00
|
|
|
intel_hpd_irq_storm_reenable_work);
|
2022-09-16 16:06:34 +03:00
|
|
|
|
2025-03-20 16:45:59 +02:00
|
|
|
display->hotplug.hpd_storm_threshold = HPD_STORM_DEFAULT_THRESHOLD;
|
2022-09-16 16:06:34 +03:00
|
|
|
/* If we have MST support, we want to avoid doing short HPD IRQ storm
|
|
|
|
* detection, as short HPD storms will occur as a natural part of
|
|
|
|
* sideband messaging with MST.
|
|
|
|
* On older platforms however, IRQ storms can occur with both long and
|
|
|
|
* short pulses, as seen on some G4x systems.
|
|
|
|
*/
|
2025-03-20 16:45:59 +02:00
|
|
|
display->hotplug.hpd_short_storm_enabled = !HAS_DP_MST(display);
|
2015-06-18 13:06:16 +03:00
|
|
|
}
|
|
|
|
|
2025-03-20 16:45:59 +02:00
|
|
|
static bool cancel_all_detection_work(struct intel_display *display)
|
2024-01-04 10:30:04 +02:00
|
|
|
{
|
|
|
|
bool was_pending = false;
|
|
|
|
|
2025-03-20 16:45:59 +02:00
|
|
|
if (cancel_delayed_work_sync(&display->hotplug.hotplug_work))
|
2024-01-04 10:30:04 +02:00
|
|
|
was_pending = true;
|
2025-03-20 16:45:59 +02:00
|
|
|
if (cancel_work_sync(&display->hotplug.poll_init_work))
|
2024-01-04 10:30:04 +02:00
|
|
|
was_pending = true;
|
2025-03-20 16:45:59 +02:00
|
|
|
if (cancel_delayed_work_sync(&display->hotplug.reenable_work))
|
2024-01-04 10:30:04 +02:00
|
|
|
was_pending = true;
|
|
|
|
|
|
|
|
return was_pending;
|
|
|
|
}
|
|
|
|
|
2025-03-20 16:45:59 +02:00
|
|
|
void intel_hpd_cancel_work(struct intel_display *display)
|
2015-06-18 13:06:16 +03:00
|
|
|
{
|
2025-03-20 16:45:59 +02:00
|
|
|
if (!HAS_DISPLAY(display))
|
drm/i915: skip display initialization when there is no display
Display features should not be initialized or de-initialized when there
is no display. Skip modeset initialization, output setup, plane, crtc,
encoder, connector registration, display cdclk and rawclk
initialization, display core initialization, etc.
Skip the functionality at as high level as possible, and remove any
redundant checks. If the functionality is conditional to *other* display
checks, do not add more. If the un-initialization has checks for
initialization, do not add more.
We explicitly do not care about any GMCH/VLV/CHV code paths, as they've
always had and will have display.
Reviewed-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210408203150.237947-3-jose.souza@intel.com
2021-04-08 13:31:50 -07:00
|
|
|
return;
|
|
|
|
|
2025-05-06 16:06:50 +03:00
|
|
|
spin_lock_irq(&display->irq.lock);
|
2015-06-18 13:06:16 +03:00
|
|
|
|
2025-03-05 13:48:19 +02:00
|
|
|
drm_WARN_ON(display->drm, get_blocked_hpd_pin_mask(display));
|
|
|
|
|
2025-03-20 16:45:59 +02:00
|
|
|
display->hotplug.long_hpd_pin_mask = 0;
|
|
|
|
display->hotplug.short_hpd_pin_mask = 0;
|
|
|
|
display->hotplug.event_bits = 0;
|
|
|
|
display->hotplug.retry_bits = 0;
|
2015-06-18 13:06:16 +03:00
|
|
|
|
2025-05-06 16:06:50 +03:00
|
|
|
spin_unlock_irq(&display->irq.lock);
|
2015-06-18 13:06:16 +03:00
|
|
|
|
2025-03-20 16:45:59 +02:00
|
|
|
cancel_work_sync(&display->hotplug.dig_port_work);
|
2024-01-04 10:30:04 +02:00
|
|
|
|
|
|
|
/*
|
|
|
|
* All other work triggered by hotplug events should be canceled by
|
|
|
|
* now.
|
|
|
|
*/
|
2025-03-20 16:45:59 +02:00
|
|
|
if (cancel_all_detection_work(display))
|
|
|
|
drm_dbg_kms(display->drm, "Hotplug detection work still active\n");
|
2015-06-18 13:06:16 +03:00
|
|
|
}
|
2016-06-21 17:03:43 -04:00
|
|
|
|
2025-03-20 16:45:59 +02:00
|
|
|
static void queue_work_for_missed_irqs(struct intel_display *display)
|
2024-01-04 10:30:04 +02:00
|
|
|
{
|
2025-03-05 13:48:19 +02:00
|
|
|
struct intel_hotplug *hotplug = &display->hotplug;
|
|
|
|
bool queue_hp_work = false;
|
|
|
|
u32 blocked_hpd_pin_mask;
|
2024-01-04 10:30:04 +02:00
|
|
|
enum hpd_pin pin;
|
|
|
|
|
2025-05-06 16:06:50 +03:00
|
|
|
lockdep_assert_held(&display->irq.lock);
|
2024-01-04 10:30:04 +02:00
|
|
|
|
2025-03-05 13:48:19 +02:00
|
|
|
blocked_hpd_pin_mask = get_blocked_hpd_pin_mask(display);
|
|
|
|
if ((hotplug->event_bits | hotplug->retry_bits) & ~blocked_hpd_pin_mask)
|
|
|
|
queue_hp_work = true;
|
2024-01-04 10:30:04 +02:00
|
|
|
|
|
|
|
for_each_hpd_pin(pin) {
|
2025-03-20 16:45:59 +02:00
|
|
|
switch (display->hotplug.stats[pin].state) {
|
2024-01-04 10:30:04 +02:00
|
|
|
case HPD_MARK_DISABLED:
|
2025-03-05 13:48:19 +02:00
|
|
|
queue_hp_work = true;
|
2024-01-04 10:30:04 +02:00
|
|
|
break;
|
2025-03-04 17:29:13 +02:00
|
|
|
case HPD_DISABLED:
|
2024-01-04 10:30:04 +02:00
|
|
|
case HPD_ENABLED:
|
|
|
|
break;
|
|
|
|
default:
|
2025-03-20 16:45:59 +02:00
|
|
|
MISSING_CASE(display->hotplug.stats[pin].state);
|
2024-01-04 10:30:04 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2025-03-05 13:48:19 +02:00
|
|
|
if ((hotplug->long_hpd_pin_mask | hotplug->short_hpd_pin_mask) & ~blocked_hpd_pin_mask)
|
|
|
|
queue_work(hotplug->dp_wq, &hotplug->dig_port_work);
|
|
|
|
|
|
|
|
if (queue_hp_work)
|
2025-03-20 16:45:59 +02:00
|
|
|
queue_delayed_detection_work(display, &display->hotplug.hotplug_work, 0);
|
2024-01-04 10:30:04 +02:00
|
|
|
}
|
|
|
|
|
2025-03-05 13:48:19 +02:00
|
|
|
static bool block_hpd_pin(struct intel_display *display, enum hpd_pin pin)
|
|
|
|
{
|
|
|
|
struct intel_hotplug *hotplug = &display->hotplug;
|
|
|
|
|
2025-05-06 16:06:50 +03:00
|
|
|
lockdep_assert_held(&display->irq.lock);
|
2025-03-05 13:48:19 +02:00
|
|
|
|
|
|
|
hotplug->stats[pin].blocked_count++;
|
|
|
|
|
|
|
|
return hotplug->stats[pin].blocked_count == 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
static bool unblock_hpd_pin(struct intel_display *display, enum hpd_pin pin)
|
|
|
|
{
|
|
|
|
struct intel_hotplug *hotplug = &display->hotplug;
|
|
|
|
|
2025-05-06 16:06:50 +03:00
|
|
|
lockdep_assert_held(&display->irq.lock);
|
2025-03-05 13:48:19 +02:00
|
|
|
|
|
|
|
if (drm_WARN_ON(display->drm, hotplug->stats[pin].blocked_count == 0))
|
|
|
|
return true;
|
|
|
|
|
|
|
|
hotplug->stats[pin].blocked_count--;
|
|
|
|
|
|
|
|
return hotplug->stats[pin].blocked_count == 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* intel_hpd_block - Block handling of HPD IRQs on an HPD pin
|
|
|
|
* @encoder: Encoder to block the HPD handling for
|
|
|
|
*
|
|
|
|
* Blocks the handling of HPD IRQs on the HPD pin of @encoder.
|
|
|
|
*
|
|
|
|
* On return:
|
2025-03-28 15:32:02 -04:00
|
|
|
*
|
2025-03-05 13:48:19 +02:00
|
|
|
* - It's guaranteed that the blocked encoders' HPD pulse handler
|
|
|
|
* (via intel_digital_port::hpd_pulse()) is not running.
|
|
|
|
* - The hotplug event handling (via intel_encoder::hotplug()) of an
|
|
|
|
* HPD IRQ pending at the time this function is called may be still
|
|
|
|
* running.
|
|
|
|
* - Detection on the encoder's connector (via
|
|
|
|
* drm_connector_helper_funcs::detect_ctx(),
|
|
|
|
* drm_connector_funcs::detect()) remains allowed, for instance as part of
|
|
|
|
* userspace connector probing, or DRM core's connector polling.
|
|
|
|
*
|
2025-03-04 17:29:17 +02:00
|
|
|
* The call must be followed by calling intel_hpd_unblock(), or
|
|
|
|
* intel_hpd_clear_and_unblock().
|
2025-03-05 13:48:19 +02:00
|
|
|
*
|
|
|
|
* Note that the handling of HPD IRQs for another encoder using the same HPD
|
|
|
|
* pin as that of @encoder will be also blocked.
|
|
|
|
*/
|
|
|
|
void intel_hpd_block(struct intel_encoder *encoder)
|
|
|
|
{
|
|
|
|
struct intel_display *display = to_intel_display(encoder);
|
|
|
|
struct intel_hotplug *hotplug = &display->hotplug;
|
|
|
|
bool do_flush = false;
|
|
|
|
|
|
|
|
if (encoder->hpd_pin == HPD_NONE)
|
|
|
|
return;
|
|
|
|
|
2025-05-06 16:06:50 +03:00
|
|
|
spin_lock_irq(&display->irq.lock);
|
2025-03-05 13:48:19 +02:00
|
|
|
|
|
|
|
if (block_hpd_pin(display, encoder->hpd_pin))
|
|
|
|
do_flush = true;
|
|
|
|
|
2025-05-06 16:06:50 +03:00
|
|
|
spin_unlock_irq(&display->irq.lock);
|
2025-03-05 13:48:19 +02:00
|
|
|
|
|
|
|
if (do_flush && hpd_pin_has_pulse(display, encoder->hpd_pin))
|
|
|
|
flush_work(&hotplug->dig_port_work);
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* intel_hpd_unblock - Unblock handling of HPD IRQs on an HPD pin
|
|
|
|
* @encoder: Encoder to unblock the HPD handling for
|
|
|
|
*
|
|
|
|
* Unblock the handling of HPD IRQs on the HPD pin of @encoder, which was
|
|
|
|
* previously blocked by intel_hpd_block(). Any HPD IRQ raised on the
|
|
|
|
* HPD pin while it was blocked will be handled for @encoder and for any
|
|
|
|
* other encoder sharing the same HPD pin.
|
|
|
|
*/
|
|
|
|
void intel_hpd_unblock(struct intel_encoder *encoder)
|
|
|
|
{
|
|
|
|
struct intel_display *display = to_intel_display(encoder);
|
|
|
|
|
|
|
|
if (encoder->hpd_pin == HPD_NONE)
|
|
|
|
return;
|
|
|
|
|
2025-05-06 16:06:50 +03:00
|
|
|
spin_lock_irq(&display->irq.lock);
|
2025-03-05 13:48:19 +02:00
|
|
|
|
|
|
|
if (unblock_hpd_pin(display, encoder->hpd_pin))
|
2025-03-20 16:45:59 +02:00
|
|
|
queue_work_for_missed_irqs(display);
|
2025-03-05 13:48:19 +02:00
|
|
|
|
2025-05-06 16:06:50 +03:00
|
|
|
spin_unlock_irq(&display->irq.lock);
|
2025-03-05 13:48:19 +02:00
|
|
|
}
|
|
|
|
|
2025-03-04 17:29:17 +02:00
|
|
|
/**
|
|
|
|
* intel_hpd_clear_and_unblock - Unblock handling of new HPD IRQs on an HPD pin
|
|
|
|
* @encoder: Encoder to unblock the HPD handling for
|
|
|
|
*
|
|
|
|
* Unblock the handling of HPD IRQs on the HPD pin of @encoder, which was
|
|
|
|
* previously blocked by intel_hpd_block(). Any HPD IRQ raised on the
|
|
|
|
* HPD pin while it was blocked will be cleared, handling only new IRQs.
|
|
|
|
*/
|
|
|
|
void intel_hpd_clear_and_unblock(struct intel_encoder *encoder)
|
|
|
|
{
|
|
|
|
struct intel_display *display = to_intel_display(encoder);
|
|
|
|
struct intel_hotplug *hotplug = &display->hotplug;
|
|
|
|
enum hpd_pin pin = encoder->hpd_pin;
|
|
|
|
|
|
|
|
if (pin == HPD_NONE)
|
|
|
|
return;
|
|
|
|
|
2025-05-06 16:06:50 +03:00
|
|
|
spin_lock_irq(&display->irq.lock);
|
2025-03-04 17:29:17 +02:00
|
|
|
|
|
|
|
if (unblock_hpd_pin(display, pin)) {
|
|
|
|
hotplug->event_bits &= ~BIT(pin);
|
|
|
|
hotplug->retry_bits &= ~BIT(pin);
|
|
|
|
hotplug->short_hpd_pin_mask &= ~BIT(pin);
|
|
|
|
hotplug->long_hpd_pin_mask &= ~BIT(pin);
|
|
|
|
}
|
|
|
|
|
2025-05-06 16:06:50 +03:00
|
|
|
spin_unlock_irq(&display->irq.lock);
|
2025-03-04 17:29:17 +02:00
|
|
|
}
|
|
|
|
|
2025-03-20 16:45:59 +02:00
|
|
|
void intel_hpd_enable_detection_work(struct intel_display *display)
|
2024-01-04 10:30:04 +02:00
|
|
|
{
|
2025-05-06 16:06:50 +03:00
|
|
|
spin_lock_irq(&display->irq.lock);
|
2025-03-20 16:45:59 +02:00
|
|
|
display->hotplug.detection_work_enabled = true;
|
|
|
|
queue_work_for_missed_irqs(display);
|
2025-05-06 16:06:50 +03:00
|
|
|
spin_unlock_irq(&display->irq.lock);
|
2024-01-04 10:30:04 +02:00
|
|
|
}
|
|
|
|
|
2025-03-20 16:45:59 +02:00
|
|
|
void intel_hpd_disable_detection_work(struct intel_display *display)
|
2024-01-04 10:30:04 +02:00
|
|
|
{
|
2025-05-06 16:06:50 +03:00
|
|
|
spin_lock_irq(&display->irq.lock);
|
2025-03-20 16:45:59 +02:00
|
|
|
display->hotplug.detection_work_enabled = false;
|
2025-05-06 16:06:50 +03:00
|
|
|
spin_unlock_irq(&display->irq.lock);
|
2024-01-04 10:30:04 +02:00
|
|
|
|
2025-03-20 16:45:59 +02:00
|
|
|
cancel_all_detection_work(display);
|
2024-01-04 10:30:04 +02:00
|
|
|
}
|
|
|
|
|
2025-03-20 16:45:59 +02:00
|
|
|
bool intel_hpd_schedule_detection(struct intel_display *display)
|
2024-01-04 10:30:04 +02:00
|
|
|
{
|
|
|
|
unsigned long flags;
|
|
|
|
bool ret;
|
|
|
|
|
2025-05-06 16:06:50 +03:00
|
|
|
spin_lock_irqsave(&display->irq.lock, flags);
|
2025-03-20 16:45:59 +02:00
|
|
|
ret = queue_delayed_detection_work(display, &display->hotplug.hotplug_work, 0);
|
2025-05-06 16:06:50 +03:00
|
|
|
spin_unlock_irqrestore(&display->irq.lock, flags);
|
2024-01-04 10:30:04 +02:00
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2022-09-16 16:06:33 +03:00
|
|
|
static int i915_hpd_storm_ctl_show(struct seq_file *m, void *data)
|
|
|
|
{
|
2025-03-20 16:46:00 +02:00
|
|
|
struct intel_display *display = m->private;
|
|
|
|
struct drm_i915_private *dev_priv = to_i915(display->drm);
|
2025-03-20 16:45:59 +02:00
|
|
|
struct intel_hotplug *hotplug = &display->hotplug;
|
2022-09-16 16:06:33 +03:00
|
|
|
|
|
|
|
/* Synchronize with everything first in case there's been an HPD
|
|
|
|
* storm, but we haven't finished handling it in the kernel yet
|
|
|
|
*/
|
|
|
|
intel_synchronize_irq(dev_priv);
|
2025-03-20 16:45:59 +02:00
|
|
|
flush_work(&display->hotplug.dig_port_work);
|
|
|
|
flush_delayed_work(&display->hotplug.hotplug_work);
|
2022-09-16 16:06:33 +03:00
|
|
|
|
|
|
|
seq_printf(m, "Threshold: %d\n", hotplug->hpd_storm_threshold);
|
|
|
|
seq_printf(m, "Detected: %s\n",
|
|
|
|
str_yes_no(delayed_work_pending(&hotplug->reenable_work)));
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static ssize_t i915_hpd_storm_ctl_write(struct file *file,
|
|
|
|
const char __user *ubuf, size_t len,
|
|
|
|
loff_t *offp)
|
|
|
|
{
|
|
|
|
struct seq_file *m = file->private_data;
|
2025-03-20 16:46:00 +02:00
|
|
|
struct intel_display *display = m->private;
|
2025-03-20 16:45:59 +02:00
|
|
|
struct intel_hotplug *hotplug = &display->hotplug;
|
2022-09-16 16:06:33 +03:00
|
|
|
unsigned int new_threshold;
|
|
|
|
int i;
|
|
|
|
char *newline;
|
|
|
|
char tmp[16];
|
|
|
|
|
|
|
|
if (len >= sizeof(tmp))
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
if (copy_from_user(tmp, ubuf, len))
|
|
|
|
return -EFAULT;
|
|
|
|
|
|
|
|
tmp[len] = '\0';
|
|
|
|
|
|
|
|
/* Strip newline, if any */
|
|
|
|
newline = strchr(tmp, '\n');
|
|
|
|
if (newline)
|
|
|
|
*newline = '\0';
|
|
|
|
|
|
|
|
if (strcmp(tmp, "reset") == 0)
|
|
|
|
new_threshold = HPD_STORM_DEFAULT_THRESHOLD;
|
|
|
|
else if (kstrtouint(tmp, 10, &new_threshold) != 0)
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
if (new_threshold > 0)
|
2025-03-20 16:45:59 +02:00
|
|
|
drm_dbg_kms(display->drm,
|
2022-09-16 16:06:33 +03:00
|
|
|
"Setting HPD storm detection threshold to %d\n",
|
|
|
|
new_threshold);
|
|
|
|
else
|
2025-03-20 16:45:59 +02:00
|
|
|
drm_dbg_kms(display->drm, "Disabling HPD storm detection\n");
|
2022-09-16 16:06:33 +03:00
|
|
|
|
2025-05-06 16:06:50 +03:00
|
|
|
spin_lock_irq(&display->irq.lock);
|
2022-09-16 16:06:33 +03:00
|
|
|
hotplug->hpd_storm_threshold = new_threshold;
|
|
|
|
/* Reset the HPD storm stats so we don't accidentally trigger a storm */
|
|
|
|
for_each_hpd_pin(i)
|
|
|
|
hotplug->stats[i].count = 0;
|
2025-05-06 16:06:50 +03:00
|
|
|
spin_unlock_irq(&display->irq.lock);
|
2022-09-16 16:06:33 +03:00
|
|
|
|
|
|
|
/* Re-enable hpd immediately if we were in an irq storm */
|
2025-03-20 16:45:59 +02:00
|
|
|
flush_delayed_work(&display->hotplug.reenable_work);
|
2022-09-16 16:06:33 +03:00
|
|
|
|
|
|
|
return len;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int i915_hpd_storm_ctl_open(struct inode *inode, struct file *file)
|
|
|
|
{
|
|
|
|
return single_open(file, i915_hpd_storm_ctl_show, inode->i_private);
|
|
|
|
}
|
|
|
|
|
|
|
|
static const struct file_operations i915_hpd_storm_ctl_fops = {
|
|
|
|
.owner = THIS_MODULE,
|
|
|
|
.open = i915_hpd_storm_ctl_open,
|
|
|
|
.read = seq_read,
|
|
|
|
.llseek = seq_lseek,
|
|
|
|
.release = single_release,
|
|
|
|
.write = i915_hpd_storm_ctl_write
|
|
|
|
};
|
|
|
|
|
|
|
|
static int i915_hpd_short_storm_ctl_show(struct seq_file *m, void *data)
|
|
|
|
{
|
2025-03-20 16:46:00 +02:00
|
|
|
struct intel_display *display = m->private;
|
2022-09-16 16:06:33 +03:00
|
|
|
|
|
|
|
seq_printf(m, "Enabled: %s\n",
|
2025-03-20 16:45:59 +02:00
|
|
|
str_yes_no(display->hotplug.hpd_short_storm_enabled));
|
2022-09-16 16:06:33 +03:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int
|
|
|
|
i915_hpd_short_storm_ctl_open(struct inode *inode, struct file *file)
|
|
|
|
{
|
|
|
|
return single_open(file, i915_hpd_short_storm_ctl_show,
|
|
|
|
inode->i_private);
|
|
|
|
}
|
|
|
|
|
|
|
|
static ssize_t i915_hpd_short_storm_ctl_write(struct file *file,
|
|
|
|
const char __user *ubuf,
|
|
|
|
size_t len, loff_t *offp)
|
|
|
|
{
|
|
|
|
struct seq_file *m = file->private_data;
|
2025-03-20 16:46:00 +02:00
|
|
|
struct intel_display *display = m->private;
|
2025-03-20 16:45:59 +02:00
|
|
|
struct intel_hotplug *hotplug = &display->hotplug;
|
2022-09-16 16:06:33 +03:00
|
|
|
char *newline;
|
|
|
|
char tmp[16];
|
|
|
|
int i;
|
|
|
|
bool new_state;
|
|
|
|
|
|
|
|
if (len >= sizeof(tmp))
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
if (copy_from_user(tmp, ubuf, len))
|
|
|
|
return -EFAULT;
|
|
|
|
|
|
|
|
tmp[len] = '\0';
|
|
|
|
|
|
|
|
/* Strip newline, if any */
|
|
|
|
newline = strchr(tmp, '\n');
|
|
|
|
if (newline)
|
|
|
|
*newline = '\0';
|
|
|
|
|
|
|
|
/* Reset to the "default" state for this system */
|
|
|
|
if (strcmp(tmp, "reset") == 0)
|
2025-03-20 16:45:59 +02:00
|
|
|
new_state = !HAS_DP_MST(display);
|
2022-09-16 16:06:33 +03:00
|
|
|
else if (kstrtobool(tmp, &new_state) != 0)
|
|
|
|
return -EINVAL;
|
|
|
|
|
2025-03-20 16:45:59 +02:00
|
|
|
drm_dbg_kms(display->drm, "%sabling HPD short storm detection\n",
|
2022-09-16 16:06:33 +03:00
|
|
|
new_state ? "En" : "Dis");
|
|
|
|
|
2025-05-06 16:06:50 +03:00
|
|
|
spin_lock_irq(&display->irq.lock);
|
2022-09-16 16:06:33 +03:00
|
|
|
hotplug->hpd_short_storm_enabled = new_state;
|
|
|
|
/* Reset the HPD storm stats so we don't accidentally trigger a storm */
|
|
|
|
for_each_hpd_pin(i)
|
|
|
|
hotplug->stats[i].count = 0;
|
2025-05-06 16:06:50 +03:00
|
|
|
spin_unlock_irq(&display->irq.lock);
|
2022-09-16 16:06:33 +03:00
|
|
|
|
|
|
|
/* Re-enable hpd immediately if we were in an irq storm */
|
2025-03-20 16:45:59 +02:00
|
|
|
flush_delayed_work(&display->hotplug.reenable_work);
|
2022-09-16 16:06:33 +03:00
|
|
|
|
|
|
|
return len;
|
|
|
|
}
|
|
|
|
|
|
|
|
static const struct file_operations i915_hpd_short_storm_ctl_fops = {
|
|
|
|
.owner = THIS_MODULE,
|
|
|
|
.open = i915_hpd_short_storm_ctl_open,
|
|
|
|
.read = seq_read,
|
|
|
|
.llseek = seq_lseek,
|
|
|
|
.release = single_release,
|
|
|
|
.write = i915_hpd_short_storm_ctl_write,
|
|
|
|
};
|
|
|
|
|
2025-03-20 16:45:59 +02:00
|
|
|
void intel_hpd_debugfs_register(struct intel_display *display)
|
2022-09-16 16:06:33 +03:00
|
|
|
{
|
2025-03-20 16:45:59 +02:00
|
|
|
struct drm_minor *minor = display->drm->primary;
|
2022-09-16 16:06:33 +03:00
|
|
|
|
|
|
|
debugfs_create_file("i915_hpd_storm_ctl", 0644, minor->debugfs_root,
|
2025-03-20 16:46:00 +02:00
|
|
|
display, &i915_hpd_storm_ctl_fops);
|
2022-09-16 16:06:33 +03:00
|
|
|
debugfs_create_file("i915_hpd_short_storm_ctl", 0644, minor->debugfs_root,
|
2025-03-20 16:46:00 +02:00
|
|
|
display, &i915_hpd_short_storm_ctl_fops);
|
2023-02-15 10:38:31 +02:00
|
|
|
debugfs_create_bool("i915_ignore_long_hpd", 0644, minor->debugfs_root,
|
2025-03-20 16:45:59 +02:00
|
|
|
&display->hotplug.ignore_long_hpd);
|
2022-09-16 16:06:33 +03:00
|
|
|
}
|