search for: rpm_suspending

...39;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 && work->func == dev->power.work; > > } > > > > Then adding this to nvkm_i2c_aux_a...

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

After resuming more than once on battery these HP Ivybridge laptops, the XHCI devices stop working. Have anyone seen this before? I wanted to check before diving in deeper. Let me know if you have any ideas. Thanks! Facts - Xen 4.0.3, Linux 3.2.7 PVOPs - Happens on HP Ivybridge. Doesn''t happen on very similar HP Sandybridge Clash system. - Happens on battery, but not on AC. -

...mediately 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 && work->func == dev->power.work; } Then adding this to nvkm_i2c_aux_acquire(): struct device *dev = pad->i2c->subdev.device->dev; if (!(is_pm_work(dev) &amp...

On Wed, Aug 01, 2018 at 05:14:58PM -0400, Lyude Paul wrote: > We can't and don't need to try resuming the device from our hotplug > handlers, but hotplug events are generally something we'd like to keep > the device awake for whenever possible. So, grab a PM ref safely in our > hotplug handlers using pm_runtime_get_noresume() and mark the device as > busy once we're

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

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

When I attach an external monitor to my new Dell Precision I always get this and the monitor refuses to recognize video input. If I persist it reaches a point where the machine will boot but won't bring up a login prompt. I have to ssh to get in. And worst of all, it persisted after I remove the external monitor and am forced to re-install CentOS (7.6.1810). Aug 02 14:19:42

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 think Ben's working on it. > Yes, the goal of

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.

...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 && work->func == dev->power.work; > > } > > > > Then adding this to nvk...

https://bugs.freedesktop.org/show_bug.cgi?id=102192 Bug ID: 102192 Summary: Dell XPS 15 9560: PU: 1 PID: 58 at drivers/gpu/drm/nouveau/nvkm/subdev/mmu/gf100.c:190 gf100_vm_flush+0x1b3/0x1c0 [nouveau] Product: xorg Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All)

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

https://bugs.freedesktop.org/show_bug.cgi?id=111940 Bug ID: 111940 Summary: frequent timeout warnings during normal operation Product: xorg Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: not set Component: Driver/nouveau

On Thu, Jul 19, 2018 at 08:08:15PM -0400, Lyude Paul wrote: > On Thu, 2018-07-19 at 09:49 +0200, Lukas Wunner wrote: > > 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

https://bugs.freedesktop.org/show_bug.cgi?id=99900 --- Comment #14 from Viktor Kuzmin <kvaster at gmail.com> --- This porblem is not related only to NVC0. This bugs is the same (I think): https://bugs.freedesktop.org/show_bug.cgi?id=98690 MacBook Pro 11.3 (GK107, GeForce GT 750M), Gentoo Linux, kernel 4.10.8. [ 49.196313] Workqueue: pm pm_runtime_work [ 49.196314] Call Trace: [

Hi fellas, I come to you to clarify/corroborate one suspicion of mine, involving nouveau. Few days since, my laptop started to create lots of kerneloops and the traceback always involves nouveau. I didn't intend to create a bug report without confirming that whether or not it really is a nouveau problem. Here is the backtrace in all its glory, attached. Kernel - 3.14.6-200.fc20.x86_64 Three

...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 && work->func == dev->power.work; > > > } > > >...

nouveau's ->runtime_suspend hook calls drm_kms_helper_poll_disable(), which waits for the output poll worker to finish if it's running. The output poll worker meanwhile calls pm_runtime_get_sync() in nouveau_connector_detect() which waits for the ongoing suspend to finish, causing a deadlock. Fix by not acquiring a runtime PM ref if nouveau_connector_detect() is called in the output

On Thu, 2018-07-19 at 09:49 +0200, Lukas Wunner wrote: > 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,