search for: runtime_status

I can confirm what Peter said, path contains \_SB_.PCI0.RP05 and power_state contains D3hot. Op do 27 okt. 2016 11:06 schreef Peter Wu <peter at lekensteyn.nl>: > On Thu, Oct 27, 2016 at 11:17:48AM +0300, Mika Westerberg wrote: > > On Thu, Oct 27, 2016 at 12:56:41AM +0200, Peter Wu wrote: > > > Hi PCI/ACPI PM experts, > > > > > > Since Linux 4.8, nouveau

On Tue, Aug 28, 2018 at 5:57 PM, Peter Wu <peter at lekensteyn.nl> wrote: > Just to be sure, after "sleep", do both devices report "suspended" in > /sys/bus/pci/devices/0000:00:1c.0/power/runtime_status > /sys/bus/pci/devices/0000:01:00.0/power/runtime_status > > and was this reproduced with a recent mainline kernel with no special > cmdline options? The endlessm kernel on Github seems to have quite some > patches, one of them explicitly disable runtime PM: > https://github.com/e...

...gt; > Minimal test procedure: > > - Note well: Recent Optimus require that a Mini-DP or HDMI cable is > plugged in on boot for the HDA device to be present. > > - Check that HDA, GPU and root port autosuspend when not in use: > cat /sys/bus/pci/devices/0000:01:00.1/power/runtime_status # HDA > cat /sys/bus/pci/devices/0000:01:00.0/power/runtime_status # GPU > cat /sys/bus/pci/devices/0000:00:01.0/power/runtime_status # Root Port > > - Check that all three autoresume when accessing the HDA: > hdajacksensetest -c 1 > > - Unbind the HDA controller: &g...

On Thu, Aug 30, 2018 at 03:41:43PM +0800, Daniel Drake wrote: > On Tue, Aug 28, 2018 at 5:57 PM, Peter Wu <peter at lekensteyn.nl> wrote: > > Just to be sure, after "sleep", do both devices report "suspended" in > > /sys/bus/pci/devices/0000:00:1c.0/power/runtime_status > > /sys/bus/pci/devices/0000:01:00.0/power/runtime_status > > > > and was this reproduced with a recent mainline kernel with no special > > cmdline options? The endlessm kernel on Github seems to have quite some > > patches, one of them explicitly disable runtime PM:...

...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 &&a...

..., 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 && work->func == dev->power.work; } Then adding this to nvkm_i2c_aux_acquire():...

On Fri, Aug 24, 2018 at 11:42 PM, Peter Wu <peter at lekensteyn.nl> wrote: > Are these systems also affected through runtime power management? For > example: > > modprobe nouveau # should enable runtime PM > sleep 6 # wait for runtime suspend to kick in > lspci -s1: # runtime resume by reading PCI config space > > On laptops from

...gt; > Minimal test procedure: > > - Note well: Recent Optimus require that a Mini-DP or HDMI cable is > plugged in on boot for the HDA device to be present. > > - Check that HDA, GPU and root port autosuspend when not in use: > cat /sys/bus/pci/devices/0000:01:00.1/power/runtime_status # HDA > cat /sys/bus/pci/devices/0000:01:00.0/power/runtime_status # GPU > cat /sys/bus/pci/devices/0000:00:01.0/power/runtime_status # Root Port > > - Check that all three autoresume when accessing the HDA: > hdajacksensetest -c 1 > > - Unbind the HDA controller: &g...

...in > > hangs on various laptops > > (https://bugzilla.kernel.org/show_bug.cgi?id=156341). > > This works fine here. I'm facing a different issue. Just to be sure, after "sleep", do both devices report "suspended" in /sys/bus/pci/devices/0000:00:1c.0/power/runtime_status /sys/bus/pci/devices/0000:01:00.0/power/runtime_status and was this reproduced with a recent mainline kernel with no special cmdline options? The endlessm kernel on Github seems to have quite some patches, one of them explicitly disable runtime PM: https://github.com/endlessm/linux/commit/8b128b50...

...; "msleep(12*1000);" at the top of the driver's ->runtime_suspend hook. > > This ensures that the poll worker runs after ->runtime_suspend has begun. > > Wait 12 sec after the GPU has begun runtime suspend, then check > > /sys/bus/pci/devices/0000:01:00.0/power/runtime_status. Without this > > series, the status will be stuck at "suspending" and you'll get hung task > > errors in dmesg after a few minutes. > > I wasn't quite sure where to add that msleep. I've tested the patches > as is on top of agd5f's wip branch withou...

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

...1k/linux/commits/switcheroo_devlink_v2 Minimal test procedure: - Note well: Recent Optimus require that a Mini-DP or HDMI cable is plugged in on boot for the HDA device to be present. - Check that HDA, GPU and root port autosuspend when not in use: cat /sys/bus/pci/devices/0000:01:00.1/power/runtime_status # HDA cat /sys/bus/pci/devices/0000:01:00.0/power/runtime_status # GPU cat /sys/bus/pci/devices/0000:00:01.0/power/runtime_status # Root Port - Check that all three autoresume when accessing the HDA: hdajacksensetest -c 1 - Unbind the HDA controller: echo 0000:01:00.1 > /sys/bus/pci...

...ot being available, a usb device disconnects, a while later Nouveau resumes kernel object trees, Bluetooth reconnects and nouveau suspends again. The commands are: # echo auto > /sys/bus/pci/devices/0000\:00\:1c.4/power/control # grep . /sys/bus/pci/devices/0000:0{0:1c.4,1:00.0}/power/{control,runtime_status} The latter returns auto, suspended, auto, suspended before running powertop, and on, active, auto, suspended after running powertop. -- You are receiving this mail because: You are the assignee for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http...

...diately 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(); > &...

...12*1000);" at the top of the driver's ->runtime_suspend hook. > > > This ensures that the poll worker runs after ->runtime_suspend has begun. > > > Wait 12 sec after the GPU has begun runtime suspend, then check > > > /sys/bus/pci/devices/0000:01:00.0/power/runtime_status. Without this > > > series, the status will be stuck at "suspending" and you'll get hung task > > > errors in dmesg after a few minutes. > > > > I wasn't quite sure where to add that msleep. I've tested the patches > > as is on top of agd5...

On 08.09.2013 23:33, Dave Airlie wrote: >>> Looks like you have Optimus (intel + nvidia), and the backtrace has >>> runtime pm in it, which is something new Dave added for 3.12, adding >>> him in explicitly. The simplest explanation is that disp->init is >>> NULL. And it seems like there are no outputs from the earlier nouveau >>> init prints. I

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

...evice 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 && work->func == dev-&...

...hes, add an > "msleep(12*1000);" at the top of the driver's ->runtime_suspend hook. > This ensures that the poll worker runs after ->runtime_suspend has begun. > Wait 12 sec after the GPU has begun runtime suspend, then check > /sys/bus/pci/devices/0000:01:00.0/power/runtime_status. Without this > series, the status will be stuck at "suspending" and you'll get hung task > errors in dmesg after a few minutes. > > i915, malidp and msm "solved" this issue by not stopping the poll worker > on runtime suspend. But this results in the GPU bo...

...t. To test the patches, add an "msleep(12*1000);" at the top of the driver's ->runtime_suspend hook. This ensures that the poll worker runs after ->runtime_suspend has begun. Wait 12 sec after the GPU has begun runtime suspend, then check /sys/bus/pci/devices/0000:01:00.0/power/runtime_status. Without this series, the status will be stuck at "suspending" and you'll get hung task errors in dmesg after a few minutes. i915, malidp and msm "solved" this issue by not stopping the poll worker on runtime suspend. But this results in the GPU bouncing back and forth be...