similar to: [PATCH 0/5] drm/nouveau: Fix a lot of nasty RPM bugs and deadlocks

This is a trimmed down version of https://patchwork.freedesktop.org/series/46637/ with all of the review comments addressed. The last version of this series had fixes for the i2c and DP aux busses to ensure that the GPU would be turned on whenever anything tried to access the i2c/aux busses. Unfortunately: one of the fixes apparently contained some very incorrect usage of Linux's runtime PM

Latest version of https://patchwork.freedesktop.org/series/46815/ , with one small change re: ilia 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 drm/nouveau: Use pm_runtime_get_noresume() in connector_detect()

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

On Wed, Jul 18, 2018 at 04:56:39PM -0400, Lyude Paul wrote: > When DP MST hubs get confused, they can occasionally stop responding for > a good bit of time up until the point where the DRM driver manages to > do the right DPCD accesses to get it to start responding again. In a > worst case scenario however, this process can take upwards of 10+ > seconds. > > Currently we use

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)

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

It's dead code, the core handles all this directly now. This also allows us to unexport drm_atomic_helper_connector_set_property. The only special case is nouveau which used one function for both pre-nv50 legacy modeset code and post-nv50 atomic world instead of 2 vtables. But amounts to exactly the same. What is rather strange here is how few drivers set this up, I suspect the earlier patch

This is the next version of https://patchwork.freedesktop.org/series/46815/ With a lot more thought put into it so as to avoid the potential deadlock scenarios I missed. This also required fixing some bogus DRM helper usage. Try and deadlock me now, nouveau. I dare you!!! Lyude Paul (8): drm/nouveau: Fix bogus drm_kms_helper_poll_enable() placement drm/nouveau: Enable polling even if we

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

While the GPU is guaranteed to be on when a hotplug has been received, the same assertion does not hold true if a connector probe has been started by userspace without having had received a sysfs event. So ensure that any connector probing keeps the GPU alive for the duration of the probe. Signed-off-by: Lyude Paul <lyude at redhat.com> Cc: Karol Herbst <karolherbst at gmail.com> Cc:

On Mon, Aug 13, 2018 at 03:16:43PM -0400, Lyude Paul wrote: > I'm sure I don't need to tell you that fb_helper's locking is a mess. Uh, loaded statement :-) Especially since we've just reworked all the fbdev locking to untangle it from drm_modeset locking. What's still a mess about it? It's documented, and very clearly wrapped around all the drm_modeset locks. If

It's dead code, the core handles all this directly now. The only special case is nouveau and tda988x which used one function for both legacy modeset code and -nv50 atomic world instead of 2 vtables. But amounts to exactly the same. v2: Rebase over the panel/brideg refactorings in stm/ltdc. Signed-off-by: Daniel Vetter <daniel.vetter at intel.com> Cc: Archit Taneja <architt at

It's dead code, the core handles all this directly now. The only special case is nouveau and tda988x which used one function for both legacy modeset code and -nv50 atomic world instead of 2 vtables. But amounts to exactly the same. v2: Rebase over the panel/brideg refactorings in stm/ltdc. Signed-off-by: Daniel Vetter <daniel.vetter at intel.com> Cc: Archit Taneja <architt at

It's dead code, the core handles all this directly now. The only special case is nouveau and tda988x which used one function for both legacy modeset code and -nv50 atomic world instead of 2 vtables. But amounts to exactly the same. v2: Rebase over the panel/brideg refactorings in stm/ltdc. Signed-off-by: Daniel Vetter <daniel.vetter at intel.com> Cc: Archit Taneja <architt at

Place the declaration of struct nouveau_conn_atom above that of struct nouveau_connector. This commit makes no changes to the moved block what so ever, it just moves it up a bit. This is a preparation patch to fix some issues with connector handling on pre nv50 displays (which do not use atomic modesetting). Signed-off-by: Hans de Goede <hdegoede at redhat.com> ---

Place the declaration of struct nouveau_conn_atom above that of struct nouveau_connector. This commit makes no changes to the moved block what so ever, it just moves it up a bit. This is a preparation patch to fix some issues with connector handling on pre nv50 displays (which do not use atomic modesetting). Signed-off-by: Hans de Goede <hdegoede at redhat.com> ---

On Mon, Jul 16, 2018 at 07:59:26PM -0400, Lyude Paul wrote: > --- a/drivers/gpu/drm/nouveau/dispnv50/disp.c > +++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c > @@ -2012,10 +2012,18 @@ nv50_disp_atomic_state_alloc(struct drm_device *dev) > return &atom->state; > } > > +static void > +nouveau_output_poll_changed(struct drm_device *dev) > +{ > +

On Mon, Jul 30, 2018 at 08:39:48PM -0400, Lyude Paul wrote: > I'm sure I don't need to tell you that fb_helper's locking is a mess. > That being said; fb_helper's locking mess can seriously complicate the > runtime suspend/resume operations of drivers because it can invoke > atomic commits and connector probing from anywhere that calls >

Hello everyone, This set will switch the users of pm_runtime_put_autosuspend() to __pm_runtime_put_autosuspend() while the former will soon be re-purposed to include a call to pm_runtime_mark_last_busy(). The two are almost always used together, apart from bugs which are likely common. Going forward, most new users should be using pm_runtime_put_autosuspend(). Once this conversion is done and

For nouveau, while the GPU is guaranteed to be on when a hotplug has been received, the same assertion does not hold true if a connector probe has been started by userspace without having had received a sysfs event. So ensure that any connector probing keeps the GPU alive for the duration of the probe by introducing drm_helper_probe_single_connector_modes_with_rpm(). It's the same as