search for: nouveau_display_fini

.../drivers/gpu/drm/nouveau/nouveau_display.c b/drivers/gpu/drm/nouveau/nouveau_display.c index ec7861457b84..1ba3f152cfcb 100644 --- a/drivers/gpu/drm/nouveau/nouveau_display.c +++ b/drivers/gpu/drm/nouveau/nouveau_display.c @@ -425,7 +425,7 @@ nouveau_display_init(struct drm_device *dev) } void -nouveau_display_fini(struct drm_device *dev, bool suspend) +nouveau_display_fini(struct drm_device *dev, bool suspend, bool runtime) { struct nouveau_display *disp = nouveau_display(dev); struct nouveau_drm *drm = nouveau_drm(dev); @@ -450,6 +450,9 @@ nouveau_display_fini(struct drm_device *dev, bool suspend) }...

...PI hotplug handling to prevent duplicate connector + * probes + * FIXME: make sure that WRITE_ONCE() implies a store barrier + * beforehand + */ + WRITE_ONCE(drm->acpi_hpd_enabled, false); + /* enable flip completion events */ nvif_notify_get(&drm->flip); return ret; } void -nouveau_display_fini(struct drm_device *dev, bool suspend) +nouveau_display_fini(struct drm_device *dev, bool suspend, bool runtime) { struct nouveau_display *disp = nouveau_display(dev); struct nouveau_drm *drm = nouveau_drm(dev); @@ -443,6 +453,10 @@ nouveau_display_fini(struct drm_device *dev, bool suspend) /...

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

Mh ok, paper over in nouveau_display_fini until Ben comes up with a better idea then?! Greetings, Tobias On 7/20/17 10:13 AM, Daniel Vetter wrote: > On Wed, Jul 19, 2017 at 04:10:50PM -0400, Ilia Mirkin wrote: >> I believe the solution is to not call drm_crtc_vblank_off for atomic >> modesetting in nouveau_display_fini....

I believe the solution is to not call drm_crtc_vblank_off for atomic modesetting in nouveau_display_fini. I think Ben's working on it. On Wed, Jul 19, 2017 at 1:25 PM, Tobias Klausmann <tobias.johannes.klausmann at mni.thm.de> wrote: > mimic the behavior of vblank_disable_fn(), another caller of > drm_vblank_disable_and_save(). > > This avoids oopsing, while trying to disable vb...

On Thu, Jul 20, 2017 at 11:58 PM, Tobias Klausmann <tobias.johannes.klausmann at mni.thm.de> wrote: > Mh ok, > > paper over in nouveau_display_fini until Ben comes up with a better idea > then?! No paper needed, just don't call drm_vblank_off for the atomic case. Not sure why that patch isn't landed yet, it should be simple. -Daniel > > Greetings, > > Tobias > > > On 7/20/17 10:13 AM, Daniel Vetter wrote: >...

..._mst_topology.c I notice that drm_dp_mst_link_probe_work() is the ->work element in drm_dp_mst_topology_mgr() and is queued on HPD. I further notice that the work item is flushed on ->runtime_suspend: nouveau_pmops_runtime_suspend() nouveau_do_suspend() nouveau_display_suspend() nouveau_display_fini() disp->fini() == nv50_display_fini() nv50_mstm_fini() drm_dp_mst_topology_mgr_suspend() flush_work(&mgr->work); And before the work item is flushed, the HPD source is quiesced. So it looks like drm_dp_mst_link_probe_work() can only ever run while the GPU is runti...

On Wed, Jul 19, 2017 at 04:10:50PM -0400, Ilia Mirkin wrote: > I believe the solution is to not call drm_crtc_vblank_off for atomic > modesetting in nouveau_display_fini. I think Ben's working on it. Yes, the goal of vblank_on/off was very much to not paper over driver bugs with clever tricks like these. If the driver cant keep track of its vblank, something has gone wrong, and the core should _not_ fix it up. Otherwise we're back to the old style vblank h...

On Sat, 2017-07-15 at 14:52 -0400, Ilia Mirkin wrote: > > OK, so this issue appears to be that we're calling > drm_crtc_vblank_off() on a crtc for which vblank is already disabled. > My guess is that this happens because the crtc is disabled. > > Not sure what the proper check is to see if vblanks are already disabled... Seems so, the below shut up suspend for both 8600 GT

...nsertions(+) > > diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c b/drivers/gpu/drm/nouveau/nouveau_display.c > index d8c92521226d..05c3688ccb76 100644 > --- a/drivers/gpu/drm/nouveau/nouveau_display.c > +++ b/drivers/gpu/drm/nouveau/nouveau_display.c > @@ -642,6 +642,15 @@ nouveau_display_fini(struct drm_device *dev, bool suspend, bool runtime) > disp->fini(dev, runtime, suspend); > } > > +void > +nouveau_display_shutdown(struct drm_device *dev) > +{ > + if (drm_drv_uses_atomic_modeset(dev)) > + drm_atomic_helper_shutdown(dev); > + else > + drm_hel...

Next version of https://patchwork.freedesktop.org/series/46815/ Same as previous version, but some small changes made to commit messages and acks/rbs have been added Lyude Paul (5): drm/nouveau: Fix bogus drm_kms_helper_poll_enable() placement drm/nouveau: Remove duplicate poll_enable() in pmops_runtime_suspend() drm/nouveau: Fix deadlock with fb_helper with async RPM requests

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

Latest version of https://patchwork.freedesktop.org/series/46815/ with some significant improvements: - I finally figured out a clean way to do this entirely with runtime PM helpers, no avoiding grabbing refs required! - Since this new method removes the need for a lot of the other changes I made (although we probably still want those changes, but not for fixing these deadlocks)

...mpletion+0x104/0x190 > [ 861.506845] wait_for_completion+0x12c/0x190 > [ 861.507555] ? wake_up_q+0x80/0x80 > [ 861.508268] flush_work+0x1c9/0x280 > [ 861.508990] ? flush_workqueue_prep_pwqs+0x1b0/0x1b0 > [ 861.509735] nvif_notify_put+0xb1/0xc0 [nouveau] > [ 861.510482] nouveau_display_fini+0xbd/0x170 [nouveau] > [ 861.511241] nouveau_display_suspend+0x67/0x120 [nouveau] > [ 861.511969] nouveau_do_suspend+0x5e/0x2d0 [nouveau] > [ 861.512715] nouveau_pmops_runtime_suspend+0x47/0xb0 [nouveau] > [ 861.513435] pci_pm_runtime_suspend+0x6b/0x180 > [ 861.514165] ? pc...

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

...time_get_noresume() and mark the device as > busy once we're finished. Patch looks fine in principle, but doesn't seem to be sufficient to fix the following race: 1. runtime_suspend commences 2. user plugs in a display before the runtime_suspend worker disables hotplug interrupts in nouveau_display_fini() 3. hotplug is handled, display is lit up 4. runtime_suspend worker waits for hotplug handler to finish 5. GPU is runtime suspended and the newly plugged in display goes black The call to pm_runtime_mark_last_busy() has no effect in this situation because rpm_suspend() doesn't look at the las...

This is the latest version of https://patchwork.freedesktop.org/series/46815/ I moved everything out of fb_helper and back into nouveau, because it seems that other drivers actually do have this handled already as far as I can tell. Lyude Paul (13): drm/nouveau: Fix bogus drm_kms_helper_poll_enable() placement drm/nouveau: Remove duplicate poll_enable() in pmops_runtime_suspend()

...[ 861.506136] ? wait_for_completion+0x104/0x190 [ 861.506845] wait_for_completion+0x12c/0x190 [ 861.507555] ? wake_up_q+0x80/0x80 [ 861.508268] flush_work+0x1c9/0x280 [ 861.508990] ? flush_workqueue_prep_pwqs+0x1b0/0x1b0 [ 861.509735] nvif_notify_put+0xb1/0xc0 [nouveau] [ 861.510482] nouveau_display_fini+0xbd/0x170 [nouveau] [ 861.511241] nouveau_display_suspend+0x67/0x120 [nouveau] [ 861.511969] nouveau_do_suspend+0x5e/0x2d0 [nouveau] [ 861.512715] nouveau_pmops_runtime_suspend+0x47/0xb0 [nouveau] [ 861.513435] pci_pm_runtime_suspend+0x6b/0x180 [ 861.514165] ? pci_has_legacy_pm_support+0...

...7b88] drm_get_last_vbltimestamp at ffffffffa020ad91 [drm] #14 [ffffc900039f7ba8] drm_update_vblank_count at ffffffffa020b3e1 [drm] #15 [ffffc900039f7c10] drm_vblank_disable_and_save at ffffffffa020bbe9 [drm] #16 [ffffc900039f7c40] drm_crtc_vblank_off at ffffffffa020c3c0 [drm] #17 [ffffc900039f7cb0] nouveau_display_fini at ffffffffa048a4d6 [nouveau] #18 [ffffc900039f7ce0] nouveau_display_suspend at ffffffffa048ac4f [nouveau] #19 [ffffc900039f7d00] nouveau_do_suspend at ffffffffa047e5ec [nouveau] #20 [ffffc900039f7d38] nouveau_pmops_suspend at ffffffffa047e77d [nouveau] #21 [ffffc900039f7d50] pci_pm_suspend at ffff...

This is the latest version of https://patchwork.freedesktop.org/series/46815/ With a bunch of fixes to the new fb_helper to prevent it from breaking module loading/unloading with nouveau. Also; lots of documentation fixes and one fix in response to a kbuild bot. Lyude Paul (8): drm/nouveau: Fix bogus drm_kms_helper_poll_enable() placement drm/nouveau: Enable polling even if we have runtime