similar to: [PATCH AUTOSEL 5.4 143/350] drm/nouveau: Resume hotplug interrupts earlier

huh? Not sure how this got put in the stable queue, but this probably should be dropped. this was prepatory work for some MST functionality that got added recently, not a fix. On Tue, 2019-12-10 at 16:04 -0500, Sasha Levin wrote: > From: Lyude Paul <lyude at redhat.com> > > [ Upstream commit ac0de16a38a9ec7026ca96132e3883c564497068 ] > > Currently, we enable hotplug

Currently, we enable hotplug detection only after we re-enable the display. However, this is too late if we're planning on sending sideband messages during the resume process - which we'll need to do in order to reprobe the topology on resume. So, enable hotplug events before reinitializing the display. Cc: Juston Li <juston.li at intel.com> Cc: Imre Deak <imre.deak at

This fixes some nasty issues I found in nouveau that were being caused looping through connectors using racy legacy methods, along with some caused by making incorrect assumptions about the drm_connector structs in nouveau's connector list. Most of these memory corruption issues could be reproduced by using an MST hub with nouveau. Cc: Karol Herbst <karolherbst at gmail.com> Cc: stable

This fixes some nasty issues I found in nouveau that were being caused looping through connectors using racy legacy methods, along with some caused by making incorrect assumptions about the drm_connector structs in nouveau's connector list. Most of these memory corruption issues could be reproduced by using an MST hub with nouveau. Next version of

When MST and atomic were introduced to nouveau, another structure that could contain a drm_connector embedded within it was introduced; struct nv50_mstc. This meant that we no longer would be able to simply loop through our connector list and assume that nouveau_connector() would return a proper pointer for each connector, since the assertion that all connectors coming from nouveau have a full

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

Turns out this part is my fault for not noticing when reviewing 9a2eba337cace ("drm/nouveau: Fix drm poll_helper handling"). Currently we call drm_kms_helper_poll_enable() from nouveau_display_hpd_work(). This makes basically no sense however, because that means we're calling drm_kms_helper_poll_enable() every time we schedule the hotplug detection work. This is also against the

This is the final portion of the large series for adding MST suspend/resume reprobing that I've been working on for quite a while now. In addition, I: * Refactored and cleaned up any code I ended up digging through in the process of understanding how some parts of these helpers worked. * Added some debugging tools along the way that I ended up needing to figure out some issues in my own

This adds more information to the hotplug uevent and lets user-space know that it's about a particular connector only. Signed-off-by: Simon Ser <contact at emersion.fr> Cc: Ben Skeggs <bskeggs at redhat.com> Cc: Lyude Paul <lyude at redhat.com> Cc: David Airlie <airlied at linux.ie> Cc: Karol Herbst <kherbst at redhat.com> ---

While the way we find the associated connector for an encoder is just fine for legacy modesetting, it's not correct for nv50+ since that uses atomic modesetting. For reference, see the drm_encoder kdocs. Fix this by removing nouveau_encoder_connector_get(), and replacing it with nv04_encoder_get_connector(), nv50_outp_get_old_connector(), and nv50_outp_get_new_connector(). v2: * Don't

Now that DRM can create these debugfs nodes automatically; this isn't needed. Signed-off-by: Lyude Paul <lyude at redhat.com> Cc: Maarten Lankhorst <maarten.lankhorst at linux.intel.com> Cc: Daniel Stone <daniel at fooishbar.org> --- drivers/gpu/drm/i915/i915_debugfs.c | 32 ----------------------------- 1 file changed, 32 deletions(-) diff --git

Signed-off-by: Lyude Paul <lyude at redhat.com> --- drivers/gpu/drm/nouveau/nvkm/engine/disp/outp.c | 8 ++------ 1 file changed, 2 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/disp/outp.c b/drivers/gpu/drm/nouveau/nvkm/engine/disp/outp.c index 6094805fbd63..06b19883a06b 100644 --- a/drivers/gpu/drm/nouveau/nvkm/engine/disp/outp.c +++

On Sun, Feb 11, 2018 at 06:58:11PM +0000, Mike Lothian wrote: > On 11 February 2018 at 09:38, Lukas Wunner <lukas at wunner.de> wrote: > > The patches for radeon and amdgpu are compile-tested only, I only have a > > MacBook Pro with an Nvidia GK107 to test. To test the patches, add an > > "msleep(12*1000);" at the top of the driver's ->runtime_suspend

Noticed that I wasn't paying close enough attention the last time I looked at our audio callbacks, as I completely missed the fact that we were figuring out which audio-enabled connector goes to each encoder by checking it's state, but without grabbing any of the appropriate modesetting locks to do so. That being said however: trying to grab modesetting locks in our audio callbacks would

Now that we're supporting things like Ada and the GSP, there's situations where we really need to actually know the display state that we're starting with when loading the driver in order to prevent breaking GSP expectations. The first step in doing this is making it so that we can read the current state of IORs from nvkm in DRM, so that we can fill in said into into the atomic state.

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

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

It seems that nouveau requires this, so best to do this in the helper. This allows nouveau to use the atomic suspend helper. Cc: nouveau at lists.freedesktop.org Acked-by: Ben Skeggs <bskeggs at redhat.com> #irc Signed-off-by: Maarten Lankhorst <maarten.lankhorst at linux.intel.com> --- drivers/gpu/drm/drm_atomic_helper.c | 51 ++++++++++----

On Tue, Sep 3, 2019 at 4:49 PM Lyude Paul <lyude at redhat.com> wrote: > > Currently, every single piece of code in amdgpu that loops through > connectors does it incorrectly and doesn't use the proper list iteration > helpers, drm_connector_list_iter_begin() and > drm_connector_list_iter_end(). Yeesh. > > So, do that. In fairness, I think the origin of this code