similar to: [PATCH] drm/nouveau: don't attempt to schedule hpd_work on headless cards

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

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.

Most of the reason I'm asking for an RFC here is because this code pulls a lot of code out of i915 and into shared DP helpers. Anyway-nouveau's HPD related code has been collecting dust for a while. Other then the occasional runtime PM related and MST related fixes, we're missing a lot of nice things that have been added to DRM since this was originally written. Additionally, the code

To start off: this patch series is less work to review then it looks - most (but not all) of the nouveau related work has already been reviewed elsewhere. Most of the reason I'm asking for an RFC here is because this code pulls a lot of code out of i915 and into shared DP helpers. Anyway-nouveau's HPD related code has been collecting dust for a while. Other then the occasional runtime PM

Most of the reason I'm asking for an RFC here is because this code pulls a lot of code out of i915 and into shared DP helpers. Anyway-nouveau's HPD related code has been collecting dust for a while. Other then the occasional runtime PM related and MST related fixes, we're missing a lot of nice things that have been added to DRM since this was originally written. Additionally, the code

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

To start off: this patch series is less work to review then it looks - most (but not all) of the nouveau related work has already been reviewed elsewhere. Most of the reason I'm asking for an RFC here is because this code pulls a lot of code out of i915 and into shared DP helpers. Anyway-nouveau's HPD related code has been collecting dust for a while. Other then the occasional runtime PM

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

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 ++++++---

[+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: > > > > On Thu,

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:

Signed-off-by: Lyude Paul <lyude at redhat.com> --- drivers/gpu/drm/nouveau/nouveau_display.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c b/drivers/gpu/drm/nouveau/nouveau_display.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 @@

On 2018-08-17 10:11 AM, Hans Verkuil wrote: > From: Hans Verkuil <hans.verkuil at cisco.com> > > Add DisplayPort CEC-Tunneling-over-AUX support to amdgpu. > > Signed-off-by: Hans Verkuil <hans.verkuil at cisco.com> > Acked-by: Alex Deucher <alexander.deucher at amd.com> > --- > drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 13 +++++++++++-- >

While working on refactoring how we handle connector hotplugging/probing + a bunch of misc DP stuff, I found a bunch of runtime_pm errors that were mostly introduced by me at one point. Oops. A lot of these aren't triggered consistently on a lot of systems, so it's not terribly surprising these got swept under the rug. Lyude Paul (9): drm/nouveau/kms: Handle -EINPROGRESS in

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

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 the Lenovo P50 I've been working on, ACPI notifications for hotplugs always seem happen even while the GPU has it's hotplugs enabled. This means that we're uselessly scheduling two connector probes every time we get a hotplug. Since we can't unregister the acpi handler without causing userspace to start getting mysterious keypresses from the ACPI_VIDEO_REPROBE events that are

On Wed, Apr 24, 2019 at 03:16:37PM -0400, Lyude Paul wrote: > On Wed, 2019-04-24 at 13:59 -0500, Bjorn Helgaas wrote: > > Not being a scheduled work expert, I was unsure if this experiment was > > equivalent to what I proposed. > > > > I'm always suspicious of singleton solutions like this (using > > schedule_work() in runtime_resume()) because usually they

On Wed, 2019-04-24 at 13:59 -0500, Bjorn Helgaas wrote: > Not being a scheduled work expert, I was unsure if this experiment was > equivalent 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.

why the nouveau_is_rpm_worker stuff? On Sat, Nov 17, 2018 at 2:50 AM Lyude Paul <lyude at redhat.com> wrote: > > Now that we have ->pre_transfer() and ->post_transfer() for DP AUX > channel devices, we can implement these hooks in order to ensure that > the GPU is actually woken up before AUX transactions happen. This fixes > /dev/drm_dp_aux* not working while the GPU is