search for: d61a5c106351

...c_aux_acquire() > > wants it in resumed state, so is waiting forever for the device to > > runtime suspend in order to resume it again immediately afterwards. > > > > The deadlock in the stack trace you've posted could be resolved using > > the technique I used in d61a5c106351 by adding the following to > > include/linux/pm_runtime.h: > > > > static inline bool pm_runtime_status_suspending(struct device *dev) > > { > > return dev->power.runtime_status == RPM_SUSPENDING; > > } > > > > static inline bool is_pm_work(stru...

...Okay, the PCI device is suspending and the nvkm_i2c_aux_acquire() wants it in resumed state, so is waiting forever for the device to runtime suspend in order to resume it again immediately afterwards. The deadlock in the stack trace you've posted could be resolved using the technique I used in d61a5c106351 by adding the following to include/linux/pm_runtime.h: static inline bool pm_runtime_status_suspending(struct device *dev) { return dev->power.runtime_status == RPM_SUSPENDING; } static inline bool is_pm_work(struct device *dev) { struct work_struct *work = current_work(); return work &amp...

...> wants it in resumed state, so is waiting forever for the device to > > > runtime suspend in order to resume it again immediately afterwards. > > > > > > The deadlock in the stack trace you've posted could be resolved using > > > the technique I used in d61a5c106351 by adding the following to > > > include/linux/pm_runtime.h: > > > > > > static inline bool pm_runtime_status_suspending(struct device *dev) > > > { > > > return dev->power.runtime_status == RPM_SUSPENDING; > > > } > > > > >...

...2c_aux_acquire() > > wants it in resumed state, so is waiting forever for the device to > > runtime suspend in order to resume it again immediately afterwards. > > > > The deadlock in the stack trace you've posted could be resolved using > > the technique I used in d61a5c106351 by adding the following to > > include/linux/pm_runtime.h: > > > > static inline bool pm_runtime_status_suspending(struct device *dev) > > { > > return dev->power.runtime_status == RPM_SUSPENDING; > > } > > > > static inline bool is_pm_work...

...; to finish the autosuspend request while the pm core waits for the > > > output poll thread to finish > > > > The correct fix is to call pm_runtime_get_sync() *conditionally* in > > the atomic commit which enables the display, using the same conditional > > as d61a5c106351, i.e. if (!drm_kms_helper_is_poll_worker()). First of all, I was mistaken when I wrote above that a check for !drm_kms_helper_is_poll_worker() would solve the problem. Sorry! It doesn't because the call to pm_runtime_get_sync() is not happening in output_poll_execute() but in drm_dp_mst_link_...

Having runtime PM makes no difference on whether or not we want polling, and it's now safe to just enable polling unconditionally in drm_load() thanks to d61a5c106351 ("drm/nouveau: Fix deadlock on runtime suspend") Signed-off-by: Lyude Paul <lyude at redhat.com> Cc: Lukas Wunner <lukas at wunner.de> Cc: Peter Ujfalusi <peter.ujfalusi at ti.com> Cc: stable at vger.kernel.org --- drivers/gpu/drm/nouveau/nouveau_drm.c | 7 ++++--- 1 f...

...ug event anyway, since drm_helper_hpd_irq_event() wouldn't bother trying to probe connectors so long as polling is disabled. So; simply move this back into nouveau_display_init() again. The race condition that both of these patches attempted to work around has already been fixed properly in d61a5c106351 ("drm/nouveau: Fix deadlock on runtime suspend") Fixes: 9a2eba337cace ("drm/nouveau: Fix drm poll_helper handling") Signed-off-by: Lyude Paul <lyude at redhat.com> Cc: Lukas Wunner <lukas at wunner.de> Cc: Peter Ujfalusi <peter.ujfalusi at ti.com> Cc: stable a...

...uspending and the nvkm_i2c_aux_acquire() > wants it in resumed state, so is waiting forever for the device to > runtime suspend in order to resume it again immediately afterwards. > > The deadlock in the stack trace you've posted could be resolved using > the technique I used in d61a5c106351 by adding the following to > include/linux/pm_runtime.h: > > static inline bool pm_runtime_status_suspending(struct device *dev) > { > return dev->power.runtime_status == RPM_SUSPENDING; > } > > static inline bool is_pm_work(struct device *dev) > { > struct work...

...suspending and the nvkm_i2c_aux_acquire() > wants it in resumed state, so is waiting forever for the device to > runtime suspend in order to resume it again immediately afterwards. > > The deadlock in the stack trace you've posted could be resolved using > the technique I used in d61a5c106351 by adding the following to > include/linux/pm_runtime.h: > > static inline bool pm_runtime_status_suspending(struct device *dev) > { > return dev->power.runtime_status == RPM_SUSPENDING; > } > > static inline bool is_pm_work(struct device *dev) > { >...

...deadlock if ->runtime_suspend commences before the hotplug event and the hotplug event occurs before polling has been disabled by ->runtime_suspend. The correct fix is to call pm_runtime_get_sync() *conditionally* in the atomic commit which enables the display, using the same conditional as d61a5c106351, i.e. if (!drm_kms_helper_is_poll_worker()). Now I realize I sent you down the wrong path when I suggested to introduce a DRM helper here. My apologies, I didn't fully appreciate what is going awry here! Anything that happens in nouveau's poll worker never needs to acquire a runtime PM r...

...end commences before the > hotplug event and the hotplug event occurs before polling has been > disabled by ->runtime_suspend. > > The correct fix is to call pm_runtime_get_sync() *conditionally* in > the atomic commit which enables the display, using the same conditional > as d61a5c106351, i.e. if (!drm_kms_helper_is_poll_worker()). > > Now I realize I sent you down the wrong path when I suggested to > introduce a DRM helper here. My apologies, I didn't fully appreciate > what is going awry here! > > Anything that happens in nouveau's poll worker never n...

[cc += linux-pm] Hi Lyude, First of all, thanks a lot for looking into this. On Mon, Jul 16, 2018 at 07:59:25PM -0400, Lyude Paul wrote: > In order to fix all of the spots that need to have runtime PM get/puts() > added, we need to ensure that it's possible for us to call > pm_runtime_get/put() in any context, regardless of how deep, since > almost all of the spots that are

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

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

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

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

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

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

https://bugs.freedesktop.org/show_bug.cgi?id=70388 Priority: medium Bug ID: 70388 Assignee: nouveau at lists.freedesktop.org Summary: [NV34] failed to idle channel 0xcccc0000 Severity: critical Classification: Unclassified OS: Linux (All) Reporter: rosti.bsd at gmail.com Hardware: x86 (IA32)