search for: hpd_work

If the card doesn't have display hardware, hpd_work and hpd_lock are left uninitialized which causes BUG when attempting to schedule hpd_work on runtime PM resume. Fix it by adding headless flag to DRM and skip any hpd if it's set. Fixes: ae1aadb1eb8d ("nouveau: don't fail driver load if no display hw present.") Link: https://git...

If the card doesn't have display hardware, hpd_work and hpd_lock are left uninitialized which causes BUG when attempting to schedule hpd_work on runtime PM resume. Fix it by adding headless flag to DRM and skip any hpd if it's set. Fixes: ae1aadb1eb8d ("nouveau: don't fail driver load if no display hw present.") Link: https://git...

On 29/5/24 07:52, Vasily Khoruzhick wrote: > If the card doesn't have display hardware, hpd_work and hpd_lock are > left uninitialized which causes BUG when attempting to schedule hpd_work > on runtime PM resume. Hi, Good catch, thank you for looking at this.? A couple of initial comments below: Ben. > > Fix it by adding headless flag to DRM and skip any hpd if it's set. &...

On 6/8/24 00:09, Vasily Khoruzhick wrote: > If the card doesn't have display hardware, hpd_work and hpd_lock are > left uninitialized which causes BUG when attempting to schedule hpd_work > on runtime PM resume. > > Fix it by adding headless flag to DRM and skip any hpd if it's set. > > Fixes: ae1aadb1eb8d ("nouveau: don't fail driver load if no display hw pre...

We need to call drm_helper_hpd_irq_event() on resume to properly detect monitor connection / disconnection on some laptops. For runtime-resume (which gets called on resume from normal suspend too) we must call drm_helper_hpd_irq_event() from a workqueue to avoid a deadlock. Rename acpi_work to hpd_work, and move it out of the #ifdef CONFIG_ACPI blocks to make it suitable for generic work. Signed-off-by: Hans de Goede <hdegoede at redhat.com> --- drivers/gpu/drm/nouveau/nouveau_display.c | 32 +++++++++++++++---------------- drivers/gpu/drm/nouveau/nouveau_drv.h | 2 +- 2 files change...

We need to call drm_helper_hpd_irq_event() on resume to properly detect monitor connection / disconnection on some laptops, use hpd_work for this to avoid deadlocks. Signed-off-by: Hans de Goede <hdegoede at redhat.com> --- drivers/gpu/drm/nouveau/nouveau_drm.c | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c b/drivers/gpu/drm/nouveau/nouveau_drm.c index 31...

[+cc Hans, author of 0b2fe6594fa2 ("drm/nouveau: Queue hpd_work on (runtime) resume")] On Fri, Mar 22, 2019 at 06:30:15AM -0500, Bjorn Helgaas wrote: > On Thu, Mar 21, 2019 at 05:48:19PM -0500, Bjorn Helgaas wrote: > > On Wed, Mar 13, 2019 at 06:25:02PM -0400, Lyude Paul wrote: > > > On Fri, 2019-02-15 at 16:17 -0500, Lyude Paul wrote: &...

Currently, there's nothing in nouveau that actually cancels this work struct. So, cancel it on suspend/unload. Otherwise, if we're unlucky enough hpd_work might try to keep running up until the system is suspended. Signed-off-by: Lyude Paul <lyude at redhat.com> Cc: stable at vger.kernel.org --- drivers/gpu/drm/nouveau/nouveau_display.c | 9 ++++++--- drivers/gpu/drm/nouveau/nouveau_display.h | 2 +- drivers/gpu/drm/nouveau/nouveau_drm.c...

On 11/21/2016 05:50 PM, Hans de Goede wrote: > We need to call drm_helper_hpd_irq_event() on resume to properly detect > monitor connection / disconnection on some laptops, use hpd_work for > this to avoid deadlocks. > Hi, this seems to introduce a hang of nouveau in 4.10-rc if the gpu is runtime resumed while no displays are connected at all. I get a permanent hang - need to power cycle to recover - if i either a) Boot a MacPro test machine which has two discrete cards...

On most systems with ACPI hotplugging support, it seems that we always receive a hotplug event once we re-enable EC interrupts even if the GPU hasn't even been resumed yet. This can cause problems since even though we schedule hpd_work to handle connector reprobing for us, hpd_work synchronizes on pm_runtime_get_sync() to wait until the device is ready to perform reprobing. Since runtime suspend/resume callbacks are disabled before the PM core calls ->suspend(), any calls to pm_runtime_get_sync() during this period will grab a...

On Thu, 2019-04-04 at 09:17 -0500, Bjorn Helgaas wrote: > [+cc Hans, author of 0b2fe6594fa2 ("drm/nouveau: Queue hpd_work on (runtime) > resume")] > > On Fri, Mar 22, 2019 at 06:30:15AM -0500, Bjorn Helgaas wrote: > > On Thu, Mar 21, 2019 at 05:48:19PM -0500, Bjorn Helgaas wrote: > > > On Wed, Mar 13, 2019 at 06:25:02PM -0400, Lyude Paul wrote: > > > > On Fri, 2019-02-15 at 16...

On Mon, Apr 15, 2019 at 02:07:18PM -0400, Lyude Paul wrote: > On Thu, 2019-04-04 at 09:17 -0500, Bjorn Helgaas wrote: > > [+cc Hans, author of 0b2fe6594fa2 ("drm/nouveau: Queue hpd_work on (runtime) > > resume")] > > > > On Fri, Mar 22, 2019 at 06:30:15AM -0500, Bjorn Helgaas wrote: > > > On Thu, Mar 21, 2019 at 05:48:19PM -0500, Bjorn Helgaas wrote: > > > > On Wed, Mar 13, 2019 at 06:25:02PM -0400, Lyude Paul wrote: > > > >...

....c index ec7861457b84..b2a93e3fa67b 100644 --- a/drivers/gpu/drm/nouveau/nouveau_display.c +++ b/drivers/gpu/drm/nouveau/nouveau_display.c @@ -387,6 +387,7 @@ nouveau_display_acpi_ntfy(struct notifier_block *nb, unsigned long val, * connector hotplug on a runtime suspended GPU, * schedule hpd_work to check. */ + NV_DEBUG(drm, "ACPI requested connector probe\n"); schedule_work(&drm->hpd_work); /* acpi-video should not generate keypresses for this */ -- 2.17.1

...y_acpi_ntfy(struct notifier_block *nb, unsigned long val, if (!strcmp(info->device_class, ACPI_VIDEO_CLASS)) { if (info->type == ACPI_VIDEO_NOTIFY_PROBE) { - /* - * This may be the only indication we receive of a - * connector hotplug on a runtime suspended GPU, - * schedule hpd_work to check. - */ - NV_DEBUG(drm, "ACPI requested connector probe\n"); - schedule_work(&drm->hpd_work); + if (READ_ONCE(drm->acpi_hpd_enabled)) { + /* + * This may be the only indication we receive + * of a connector hotplug on a runtime + * suspended GPU, s...

...rm/nouveau/kms/fbcon: Correct pm_runtime calls in nouveau_fbcon_release() drm/nouveau/kms/fbcon: Fix pm_runtime calls in nouveau_fbcon_output_poll_changed() drm/nouveau/kms/fbcon: Use pm_runtime_put_autosuspend() in suspend work drm/nouveau/kms: Use pm_runtime_put_autosuspend() in hpd_work drm/nouveau/kms: Invert conditionals in nouveau_display_acpi_ntfy() drm/nouveau/kms: Fix runtime PM leak in nouveau_display_acpi_ntfy() drm/nouveau/kms: Handle -EINPROGRESS in nouveau_display_acpi_ntfy() drivers/gpu/drm/nouveau/nouveau_connector.c | 5 +- drivers/gpu/drm/nouveau/nouveau_di...

...nt to what I proposed. > > I'm always suspicious of singleton solutions like this (using > schedule_work() in runtime_resume()) because usually they seem to be > solving a generic problem that should happen on many kinds of > hardware. The 0b2fe6594fa2 ("drm/nouveau: Queue hpd_work on (runtime) > resume") commit log says: > > We need to call drm_helper_hpd_irq_event() on resume to properly > detect monitor connection / disconnection on some laptops, use > hpd_work for this to avoid deadlocks. > > The situation of a monitor being connected or...

...or_disable() drm/nouveau/kms/nv50-: Refactor and cleanup DP HPD handling drm/i915/dp: Extract drm_dp_has_mst() drm/nouveau/kms: Use new drm_dp_has_mst() helper for checking MST caps drm/nouveau/kms: Move drm_dp_cec_unset_edid() into nouveau_connector_detect() drm/nouveau/kms: Only use hpd_work for reprobing in HPD paths drm/i915/dp: Extract drm_dp_downstream_read_info() drm/nouveau/kms/nv50-: Use downstream DP clock limits for mode validation drm/i915/dp: Extract drm_dp_has_sink_count() drm/i915/dp: Extract drm_dp_get_sink_count() drm/nouveau/kms/nv50-: Add support for DP_S...

[+cc Rafael] On Wed, Mar 13, 2019 at 06:25:02PM -0400, Lyude Paul wrote: > On Fri, 2019-02-15 at 16:17 -0500, Lyude Paul wrote: > > On Thu, 2019-02-14 at 18:43 -0600, Bjorn Helgaas wrote: > > > On Tue, Feb 12, 2019 at 05:02:30PM -0500, Lyude Paul wrote: > > > > On a very specific subset of ThinkPad P50 SKUs, particularly > > > > ones that come with a

...t; > > > I'm always suspicious of singleton solutions like this (using > > schedule_work() in runtime_resume()) because usually they seem to be > > solving a generic problem that should happen on many kinds of > > hardware. The 0b2fe6594fa2 ("drm/nouveau: Queue hpd_work on (runtime) > > resume") commit log says: > > > > We need to call drm_helper_hpd_irq_event() on resume to properly > > detect monitor connection / disconnection on some laptops, use > > hpd_work for this to avoid deadlocks. > > > > The situati...

...or_disable() drm/nouveau/kms/nv50-: Refactor and cleanup DP HPD handling drm/i915/dp: Extract drm_dp_has_mst() drm/nouveau/kms: Use new drm_dp_has_mst() helper for checking MST caps drm/nouveau/kms: Move drm_dp_cec_unset_edid() into nouveau_connector_detect() drm/nouveau/kms: Only use hpd_work for reprobing in HPD paths drm/i915/dp: Extract drm_dp_downstream_read_info() drm/nouveau/kms/nv50-: Use downstream DP clock limits for mode validation drm/i915/dp: Extract drm_dp_has_sink_count() drm/i915/dp: Extract drm_dp_get_sink_count() drm/nouveau/kms/nv50-: Add support for DP_S...