Re: [PATCH v2 00/10] Exynos IOMMU: proper runtime PM support (use device dependencies)
Hi Marek, Marek Szyprowski wrote: > Hi Tobias > > > On 2016-07-18 18:43, Tobias Jakobi wrote: >> Marek Szyprowski wrote: >>> On 2016-07-18 13:00, Tobias Jakobi wrote: Marek Szyprowski wrote: > On 2016-07-15 15:21, Tobias Jakobi wrote: >> Tobias Jakobi wrote: >>> Hello Marek, >>> >>> I've tested the patchset on 4.7-rc7 and noticed that it breaks >>> reboot on >>> my ODROID-X2. >>> >>> Going to check where exactly things break. >> Sadly it's the last patch where everything comes together: >> "iommu/exynos: Add proper runtime pm support" >> >> I still have to check if forcing runpm status to 'on' makes a >> difference. I suspect that the aggressive clock gating might be the >> reason? > Thanks for testing. I will check this issue. Could you send me your > .config? This is the config I'm currently using: https://github.com/tobiasjakobi/odroid-environment/blob/master/sourcecode/system/vanilla-4.7-debug.conf Do you think checking this with no_console_suspend makes sense? >>> no_console_suspend switch won't provide more information, but I managed >>> to reproduce your issue. I'm really confused how enabling runtime pm can >>> cause problems with usb/smsc95xx ethernet driver (that is the reason for >>> failed reboot). Maybe it is somehow related to the global relations >>> between devices and drivers and the fact that creating the runtime pm >>> links change the order of operations. I will check this again when >>> Rafael send updated patches. Here is the log I got (after waiting some >>> time): >> thanks for looking into this! I'll try to reproduce this on my board. I >> have to admit that I didn't wait too long for the hung task message to >> appear. >> >> I wonder if this has something to do with regulator code cutting some >> supplies too early. Is this on a X2 or a U2/U3? > > I've reproduced it on U3. Here's what I get on my X2. > * Remounting remaining filesystems read-only ... > * Remounting / read only ... > [ 59.695857] EXT4-fs (mmcblk0p2): re-mounted. Opts: (null) > [ ok ] > [ ok ] > [ 59.858672] sd 0:0:0:0: [sda] Synchronizing SCSI cache > [ 66.537116] smsc95xx 1-2.1.1:1.0 eth0: Failed to read reg index > 0x0114: -110 > [ 66.538887] smsc95xx 1-2.1.1:1.0 eth0: Error reading MII_ACCESS > [ 66.544803] smsc95xx 1-2.1.1:1.0 eth0: MII is busy in smsc95xx_mdio_read > [ 66.551487] smsc95xx 1-2.1.1:1.0 eth0: Failed to read MII_BMSR > [ 93.597127] usb 1-2-port2: cannot reset (err = -110) > [ 94.596714] usb 1-2-port2: cannot reset (err = -110) > [ 95.596737] usb 1-2-port2: cannot reset (err = -110) > [ 96.596722] usb 1-2-port2: cannot reset (err = -110) > [ 97.596735] usb 1-2-port2: cannot reset (err = -110) > [ 97.596800] usb 1-2-port2: Cannot enable. Maybe the USB cable is bad? > [ 98.602116] usb 1-2-port2: cannot disable (err = -110) > [ 99.601744] usb 1-2-port2: cannot reset (err = -110) > [ 100.601730] usb 1-2-port2: cannot reset (err = -110) > [ 101.601743] usb 1-2-port2: cannot reset (err = -110) > [ 102.601729] usb 1-2-port2: cannot reset (err = -110) > [ 103.601746] usb 1-2-port2: cannot reset (err = -110) > [ 103.601811] usb 1-2-port2: Cannot enable. Maybe the USB cable is bad? > [ 104.606737] usb 1-2-port2: cannot disable (err = -110) > [ 105.606756] usb 1-2-port2: cannot reset (err = -110) > [ 106.606742] usb 1-2-port2: cannot reset (err = -110) > [ 107.606758] usb 1-2-port2: cannot reset (err = -110) > [ 108.606747] usb 1-2-port2: cannot reset (err = -110) > [ 109.606763] usb 1-2-port2: cannot reset (err = -110) > [ 109.606835] usb 1-2-port2: Cannot enable. Maybe the USB cable is bad? > [ 110.611748] usb 1-2-port2: cannot disable (err = -110) > [ 111.611766] usb 1-2-port2: cannot reset (err = -110) > [ 112.611758] usb 1-2-port2: cannot reset (err = -110) > [ 113.611769] usb 1-2-port2: cannot reset (err = -110) > [ 114.611758] usb 1-2-port2: cannot reset (err = -110) > [ 115.611776] usb 1-2-port2: cannot reset (err = -110) > [ 115.611846] usb 1-2-port2: Cannot enable. Maybe the USB cable is bad? > [ 116.616764] usb 1-2-port2: cannot disable (err = -110) > [ 117.617148] usb 1-2-port2: cannot disable (err = -110) > [ 122.616775] hub 1-2:1.0: hub_ext_port_status failed (err = -110) Output stops there, I don't see any more output with respect to hung tasks (even though hung task detection is on and I've waited for like 10 minutes). Anyway, I looks like that smsc95xx_unbind() is never called, and hence the check_carrier() delayed work queue isn't cancelled. However I'm not convinced that this is the real problem. I have manually triggered the unbind before shutdown, and while the error message from the smsc95xx driver have disappeared, the other messages are still produced. My guess is that we are seeing these messages because reboot is not working, and not the other way round. - Tobias > >> I'm not sure if we >> currently model
Re: [PATCH v2 00/10] Exynos IOMMU: proper runtime PM support (use device dependencies)
Hi Marek, Marek Szyprowski wrote: > Hi Tobias > > > On 2016-07-18 18:43, Tobias Jakobi wrote: >> Marek Szyprowski wrote: >>> On 2016-07-18 13:00, Tobias Jakobi wrote: Marek Szyprowski wrote: > On 2016-07-15 15:21, Tobias Jakobi wrote: >> Tobias Jakobi wrote: >>> Hello Marek, >>> >>> I've tested the patchset on 4.7-rc7 and noticed that it breaks >>> reboot on >>> my ODROID-X2. >>> >>> Going to check where exactly things break. >> Sadly it's the last patch where everything comes together: >> "iommu/exynos: Add proper runtime pm support" >> >> I still have to check if forcing runpm status to 'on' makes a >> difference. I suspect that the aggressive clock gating might be the >> reason? > Thanks for testing. I will check this issue. Could you send me your > .config? This is the config I'm currently using: https://github.com/tobiasjakobi/odroid-environment/blob/master/sourcecode/system/vanilla-4.7-debug.conf Do you think checking this with no_console_suspend makes sense? >>> no_console_suspend switch won't provide more information, but I managed >>> to reproduce your issue. I'm really confused how enabling runtime pm can >>> cause problems with usb/smsc95xx ethernet driver (that is the reason for >>> failed reboot). Maybe it is somehow related to the global relations >>> between devices and drivers and the fact that creating the runtime pm >>> links change the order of operations. I will check this again when >>> Rafael send updated patches. Here is the log I got (after waiting some >>> time): >> thanks for looking into this! I'll try to reproduce this on my board. I >> have to admit that I didn't wait too long for the hung task message to >> appear. >> >> I wonder if this has something to do with regulator code cutting some >> supplies too early. Is this on a X2 or a U2/U3? > > I've reproduced it on U3. Here's what I get on my X2. > * Remounting remaining filesystems read-only ... > * Remounting / read only ... > [ 59.695857] EXT4-fs (mmcblk0p2): re-mounted. Opts: (null) > [ ok ] > [ ok ] > [ 59.858672] sd 0:0:0:0: [sda] Synchronizing SCSI cache > [ 66.537116] smsc95xx 1-2.1.1:1.0 eth0: Failed to read reg index > 0x0114: -110 > [ 66.538887] smsc95xx 1-2.1.1:1.0 eth0: Error reading MII_ACCESS > [ 66.544803] smsc95xx 1-2.1.1:1.0 eth0: MII is busy in smsc95xx_mdio_read > [ 66.551487] smsc95xx 1-2.1.1:1.0 eth0: Failed to read MII_BMSR > [ 93.597127] usb 1-2-port2: cannot reset (err = -110) > [ 94.596714] usb 1-2-port2: cannot reset (err = -110) > [ 95.596737] usb 1-2-port2: cannot reset (err = -110) > [ 96.596722] usb 1-2-port2: cannot reset (err = -110) > [ 97.596735] usb 1-2-port2: cannot reset (err = -110) > [ 97.596800] usb 1-2-port2: Cannot enable. Maybe the USB cable is bad? > [ 98.602116] usb 1-2-port2: cannot disable (err = -110) > [ 99.601744] usb 1-2-port2: cannot reset (err = -110) > [ 100.601730] usb 1-2-port2: cannot reset (err = -110) > [ 101.601743] usb 1-2-port2: cannot reset (err = -110) > [ 102.601729] usb 1-2-port2: cannot reset (err = -110) > [ 103.601746] usb 1-2-port2: cannot reset (err = -110) > [ 103.601811] usb 1-2-port2: Cannot enable. Maybe the USB cable is bad? > [ 104.606737] usb 1-2-port2: cannot disable (err = -110) > [ 105.606756] usb 1-2-port2: cannot reset (err = -110) > [ 106.606742] usb 1-2-port2: cannot reset (err = -110) > [ 107.606758] usb 1-2-port2: cannot reset (err = -110) > [ 108.606747] usb 1-2-port2: cannot reset (err = -110) > [ 109.606763] usb 1-2-port2: cannot reset (err = -110) > [ 109.606835] usb 1-2-port2: Cannot enable. Maybe the USB cable is bad? > [ 110.611748] usb 1-2-port2: cannot disable (err = -110) > [ 111.611766] usb 1-2-port2: cannot reset (err = -110) > [ 112.611758] usb 1-2-port2: cannot reset (err = -110) > [ 113.611769] usb 1-2-port2: cannot reset (err = -110) > [ 114.611758] usb 1-2-port2: cannot reset (err = -110) > [ 115.611776] usb 1-2-port2: cannot reset (err = -110) > [ 115.611846] usb 1-2-port2: Cannot enable. Maybe the USB cable is bad? > [ 116.616764] usb 1-2-port2: cannot disable (err = -110) > [ 117.617148] usb 1-2-port2: cannot disable (err = -110) > [ 122.616775] hub 1-2:1.0: hub_ext_port_status failed (err = -110) Output stops there, I don't see any more output with respect to hung tasks (even though hung task detection is on and I've waited for like 10 minutes). Anyway, I looks like that smsc95xx_unbind() is never called, and hence the check_carrier() delayed work queue isn't cancelled. However I'm not convinced that this is the real problem. I have manually triggered the unbind before shutdown, and while the error message from the smsc95xx driver have disappeared, the other messages are still produced. My guess is that we are seeing these messages because reboot is not working, and not the other way round. - Tobias > >> I'm not sure if we >> currently model
Re: [PATCH v2 00/10] Exynos IOMMU: proper runtime PM support (use device dependencies)
Hi Tobias On 2016-07-18 18:43, Tobias Jakobi wrote: Marek Szyprowski wrote: On 2016-07-18 13:00, Tobias Jakobi wrote: Marek Szyprowski wrote: On 2016-07-15 15:21, Tobias Jakobi wrote: Tobias Jakobi wrote: Hello Marek, I've tested the patchset on 4.7-rc7 and noticed that it breaks reboot on my ODROID-X2. Going to check where exactly things break. Sadly it's the last patch where everything comes together: "iommu/exynos: Add proper runtime pm support" I still have to check if forcing runpm status to 'on' makes a difference. I suspect that the aggressive clock gating might be the reason? Thanks for testing. I will check this issue. Could you send me your .config? This is the config I'm currently using: https://github.com/tobiasjakobi/odroid-environment/blob/master/sourcecode/system/vanilla-4.7-debug.conf Do you think checking this with no_console_suspend makes sense? no_console_suspend switch won't provide more information, but I managed to reproduce your issue. I'm really confused how enabling runtime pm can cause problems with usb/smsc95xx ethernet driver (that is the reason for failed reboot). Maybe it is somehow related to the global relations between devices and drivers and the fact that creating the runtime pm links change the order of operations. I will check this again when Rafael send updated patches. Here is the log I got (after waiting some time): thanks for looking into this! I'll try to reproduce this on my board. I have to admit that I didn't wait too long for the hung task message to appear. I wonder if this has something to do with regulator code cutting some supplies too early. Is this on a X2 or a U2/U3? I've reproduced it on U3. I'm not sure if we currently model the regulator setup correctly here (IIRC then buck8 is supplying the LAN/USB block on U2/U3). IMHO it is not really related to regulator operations, but the sequence of shutting down logical devices in the system. For some reasons when pm links are used, something changes the order of operations in system shutdown procedure, what causes smsc95xx to hang. I have no idea why, but I don't have time to investigate it further. I will wait for the next release of Rafael's pm links patches and then check everything again. Best regards -- Marek Szyprowski, PhD Samsung R Institute Poland
Re: [PATCH v2 00/10] Exynos IOMMU: proper runtime PM support (use device dependencies)
Hi Tobias On 2016-07-18 18:43, Tobias Jakobi wrote: Marek Szyprowski wrote: On 2016-07-18 13:00, Tobias Jakobi wrote: Marek Szyprowski wrote: On 2016-07-15 15:21, Tobias Jakobi wrote: Tobias Jakobi wrote: Hello Marek, I've tested the patchset on 4.7-rc7 and noticed that it breaks reboot on my ODROID-X2. Going to check where exactly things break. Sadly it's the last patch where everything comes together: "iommu/exynos: Add proper runtime pm support" I still have to check if forcing runpm status to 'on' makes a difference. I suspect that the aggressive clock gating might be the reason? Thanks for testing. I will check this issue. Could you send me your .config? This is the config I'm currently using: https://github.com/tobiasjakobi/odroid-environment/blob/master/sourcecode/system/vanilla-4.7-debug.conf Do you think checking this with no_console_suspend makes sense? no_console_suspend switch won't provide more information, but I managed to reproduce your issue. I'm really confused how enabling runtime pm can cause problems with usb/smsc95xx ethernet driver (that is the reason for failed reboot). Maybe it is somehow related to the global relations between devices and drivers and the fact that creating the runtime pm links change the order of operations. I will check this again when Rafael send updated patches. Here is the log I got (after waiting some time): thanks for looking into this! I'll try to reproduce this on my board. I have to admit that I didn't wait too long for the hung task message to appear. I wonder if this has something to do with regulator code cutting some supplies too early. Is this on a X2 or a U2/U3? I've reproduced it on U3. I'm not sure if we currently model the regulator setup correctly here (IIRC then buck8 is supplying the LAN/USB block on U2/U3). IMHO it is not really related to regulator operations, but the sequence of shutting down logical devices in the system. For some reasons when pm links are used, something changes the order of operations in system shutdown procedure, what causes smsc95xx to hang. I have no idea why, but I don't have time to investigate it further. I will wait for the next release of Rafael's pm links patches and then check everything again. Best regards -- Marek Szyprowski, PhD Samsung R Institute Poland
Re: [PATCH v2 00/10] Exynos IOMMU: proper runtime PM support (use device dependencies)
Hey Marek, Marek Szyprowski wrote: > Dear Tobias > > > On 2016-07-18 13:00, Tobias Jakobi wrote: >> Marek Szyprowski wrote: >>> On 2016-07-15 15:21, Tobias Jakobi wrote: Tobias Jakobi wrote: > Hello Marek, > > I've tested the patchset on 4.7-rc7 and noticed that it breaks > reboot on > my ODROID-X2. > > Going to check where exactly things break. Sadly it's the last patch where everything comes together: "iommu/exynos: Add proper runtime pm support" I still have to check if forcing runpm status to 'on' makes a difference. I suspect that the aggressive clock gating might be the reason? >>> Thanks for testing. I will check this issue. Could you send me your >>> .config? >> This is the config I'm currently using: >> https://github.com/tobiasjakobi/odroid-environment/blob/master/sourcecode/system/vanilla-4.7-debug.conf >> >> >> Do you think checking this with no_console_suspend makes sense? > > no_console_suspend switch won't provide more information, but I managed > to reproduce your issue. I'm really confused how enabling runtime pm can > cause problems with usb/smsc95xx ethernet driver (that is the reason for > failed reboot). Maybe it is somehow related to the global relations > between devices and drivers and the fact that creating the runtime pm > links change the order of operations. I will check this again when > Rafael send updated patches. Here is the log I got (after waiting some > time): thanks for looking into this! I'll try to reproduce this on my board. I have to admit that I didn't wait too long for the hung task message to appear. I wonder if this has something to do with regulator code cutting some supplies too early. Is this on a X2 or a U2/U3? I'm not sure if we currently model the regulator setup correctly here (IIRC then buck8 is supplying the LAN/USB block on U2/U3). - Tobias > > # reboot > > Broadcast message from root@target (ttySAC1) (Mon Jul 18 13:33:38 2016): > > The system is going down for reboot NOW! > INIT: Switching to runlevel: 6 > INIT: Sending processes the TERM signal > [info] Using makefile-style concurrent boot in runlevel 6. > [ ok ] Stopping cgroup management proxy daemon: cgproxy[] Stopping > internet superserver: inetd. > [] Stopping cgroup management daemon: cgmanagermax77686-rtc > max77686-rtc: RTC alarm IRQ: 119 > [ ok ] Shutting down ALSA...done. > random: nonblocking pool is initialized > [info] Saving the system clock. > [info] Hardware Clock updated to Mon Jul 18 13:33:40 UTC 2016. > [ ok ] Asking all remaining processes to terminate...done. > [ ok ] All processes ended within 1 seconds...done. > [ ok ] Stopping rpcbind daemon > [ ok ] Deconfiguring network interfaces...done. > [ ok ] Unmounting temporary filesystems...done. > [ ok ] Deactivating swap...done. > EXT4-fs (mmcblk1p2): re-mounted. Opts: (null) > [info] Will now restart. > smsc95xx 1-2:1.0 eth0: Failed to read reg index 0x0114: -110 > smsc95xx 1-2:1.0 eth0: Error reading MII_ACCESS > smsc95xx 1-2:1.0 eth0: MII is busy in smsc95xx_mdio_read > smsc95xx 1-2:1.0 eth0: Failed to read MII_BMSR > INFO: task kworker/0:1:410 blocked for more than 120 seconds. > Not tainted 4.7.0-rc7-debug+ #155 > "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. > kworker/0:1 D c06850a8 0 410 2 0x > Workqueue: events_freezable mmc_rescan > Backtrace: > [] (__schedule) from [] (schedule+0x44/0xb0) > r10: r9:eebe1d88 r8:c0686234 r7: r6:0002 r5:7fff > r4:7fff > [] (schedule) from [] (schedule_timeout+0x154/0x1b0) > [] (schedule_timeout) from [] > (wait_for_common+0xe0/0x174) > r8:c0686234 r7: r6:0002 r5:eebe1d8c r4:7fff > [] (wait_for_common) from [] > (wait_for_completion+0x18/0x1c) > r10:0001 r9: r8: r7:eebe1d88 r6:eebe1d78 r5:ee26 > r4:eebe1de4 > [] (wait_for_completion) from [] > (mmc_wait_for_req+0xc8/0x15c) > [] (mmc_wait_for_req) from [] > (mmc_wait_for_cmd+0x6c/0xa4) > r8:eef73d00 r7:0003 r6:ee26 r5:c0a02448 r4:eebe1de4 r3: > [] (mmc_wait_for_cmd) from [] > (mmc_send_status+0x8c/0xb0) > r7:eebe1eb0 r6:ee26 r5:ee26 r4: > [] (mmc_send_status) from [] (mmc_alive+0x18/0x1c) > r4:ee26 > [] (mmc_alive) from [] > (_mmc_detect_card_removed+0x40/0x90) > [] (_mmc_detect_card_removed) from [] > (mmc_detect+0x2c/0x78) > r5:ee2602bc r4:ee26 > [] (mmc_detect) from [] (mmc_rescan+0x1b0/0x324) > r5:ee2602bc r4:ee260368 > [] (mmc_rescan) from [] (process_one_work+0x194/0x414) > r8:eef73d00 r7:eebe1eb0 r6:eef70280 r5:ee260368 r4:eea24080 r3:c04e94fc > [] (process_one_work) from [] > (worker_thread+0x34/0x4d4) > r10:eef70280 r9:c0a02100 r8:0008 r7:eef70280 r6:eea24098 r5:eef702b4 > r4:eea24080 > [] (worker_thread) from [] (kthread+0xf8/0x11c) > r10: r9: r8: r7:c013aad8 r6:eea24080 r5: > r4:eea29d00 > [] (kthread) from []
Re: [PATCH v2 00/10] Exynos IOMMU: proper runtime PM support (use device dependencies)
Hey Marek, Marek Szyprowski wrote: > Dear Tobias > > > On 2016-07-18 13:00, Tobias Jakobi wrote: >> Marek Szyprowski wrote: >>> On 2016-07-15 15:21, Tobias Jakobi wrote: Tobias Jakobi wrote: > Hello Marek, > > I've tested the patchset on 4.7-rc7 and noticed that it breaks > reboot on > my ODROID-X2. > > Going to check where exactly things break. Sadly it's the last patch where everything comes together: "iommu/exynos: Add proper runtime pm support" I still have to check if forcing runpm status to 'on' makes a difference. I suspect that the aggressive clock gating might be the reason? >>> Thanks for testing. I will check this issue. Could you send me your >>> .config? >> This is the config I'm currently using: >> https://github.com/tobiasjakobi/odroid-environment/blob/master/sourcecode/system/vanilla-4.7-debug.conf >> >> >> Do you think checking this with no_console_suspend makes sense? > > no_console_suspend switch won't provide more information, but I managed > to reproduce your issue. I'm really confused how enabling runtime pm can > cause problems with usb/smsc95xx ethernet driver (that is the reason for > failed reboot). Maybe it is somehow related to the global relations > between devices and drivers and the fact that creating the runtime pm > links change the order of operations. I will check this again when > Rafael send updated patches. Here is the log I got (after waiting some > time): thanks for looking into this! I'll try to reproduce this on my board. I have to admit that I didn't wait too long for the hung task message to appear. I wonder if this has something to do with regulator code cutting some supplies too early. Is this on a X2 or a U2/U3? I'm not sure if we currently model the regulator setup correctly here (IIRC then buck8 is supplying the LAN/USB block on U2/U3). - Tobias > > # reboot > > Broadcast message from root@target (ttySAC1) (Mon Jul 18 13:33:38 2016): > > The system is going down for reboot NOW! > INIT: Switching to runlevel: 6 > INIT: Sending processes the TERM signal > [info] Using makefile-style concurrent boot in runlevel 6. > [ ok ] Stopping cgroup management proxy daemon: cgproxy[] Stopping > internet superserver: inetd. > [] Stopping cgroup management daemon: cgmanagermax77686-rtc > max77686-rtc: RTC alarm IRQ: 119 > [ ok ] Shutting down ALSA...done. > random: nonblocking pool is initialized > [info] Saving the system clock. > [info] Hardware Clock updated to Mon Jul 18 13:33:40 UTC 2016. > [ ok ] Asking all remaining processes to terminate...done. > [ ok ] All processes ended within 1 seconds...done. > [ ok ] Stopping rpcbind daemon > [ ok ] Deconfiguring network interfaces...done. > [ ok ] Unmounting temporary filesystems...done. > [ ok ] Deactivating swap...done. > EXT4-fs (mmcblk1p2): re-mounted. Opts: (null) > [info] Will now restart. > smsc95xx 1-2:1.0 eth0: Failed to read reg index 0x0114: -110 > smsc95xx 1-2:1.0 eth0: Error reading MII_ACCESS > smsc95xx 1-2:1.0 eth0: MII is busy in smsc95xx_mdio_read > smsc95xx 1-2:1.0 eth0: Failed to read MII_BMSR > INFO: task kworker/0:1:410 blocked for more than 120 seconds. > Not tainted 4.7.0-rc7-debug+ #155 > "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. > kworker/0:1 D c06850a8 0 410 2 0x > Workqueue: events_freezable mmc_rescan > Backtrace: > [] (__schedule) from [] (schedule+0x44/0xb0) > r10: r9:eebe1d88 r8:c0686234 r7: r6:0002 r5:7fff > r4:7fff > [] (schedule) from [] (schedule_timeout+0x154/0x1b0) > [] (schedule_timeout) from [] > (wait_for_common+0xe0/0x174) > r8:c0686234 r7: r6:0002 r5:eebe1d8c r4:7fff > [] (wait_for_common) from [] > (wait_for_completion+0x18/0x1c) > r10:0001 r9: r8: r7:eebe1d88 r6:eebe1d78 r5:ee26 > r4:eebe1de4 > [] (wait_for_completion) from [] > (mmc_wait_for_req+0xc8/0x15c) > [] (mmc_wait_for_req) from [] > (mmc_wait_for_cmd+0x6c/0xa4) > r8:eef73d00 r7:0003 r6:ee26 r5:c0a02448 r4:eebe1de4 r3: > [] (mmc_wait_for_cmd) from [] > (mmc_send_status+0x8c/0xb0) > r7:eebe1eb0 r6:ee26 r5:ee26 r4: > [] (mmc_send_status) from [] (mmc_alive+0x18/0x1c) > r4:ee26 > [] (mmc_alive) from [] > (_mmc_detect_card_removed+0x40/0x90) > [] (_mmc_detect_card_removed) from [] > (mmc_detect+0x2c/0x78) > r5:ee2602bc r4:ee26 > [] (mmc_detect) from [] (mmc_rescan+0x1b0/0x324) > r5:ee2602bc r4:ee260368 > [] (mmc_rescan) from [] (process_one_work+0x194/0x414) > r8:eef73d00 r7:eebe1eb0 r6:eef70280 r5:ee260368 r4:eea24080 r3:c04e94fc > [] (process_one_work) from [] > (worker_thread+0x34/0x4d4) > r10:eef70280 r9:c0a02100 r8:0008 r7:eef70280 r6:eea24098 r5:eef702b4 > r4:eea24080 > [] (worker_thread) from [] (kthread+0xf8/0x11c) > r10: r9: r8: r7:c013aad8 r6:eea24080 r5: > r4:eea29d00 > [] (kthread) from []
Re: [PATCH v2 00/10] Exynos IOMMU: proper runtime PM support (use device dependencies)
Dear Tobias
On 2016-07-18 13:00, Tobias Jakobi wrote:
Marek Szyprowski wrote:
On 2016-07-15 15:21, Tobias Jakobi wrote:
Tobias Jakobi wrote:
Hello Marek,
I've tested the patchset on 4.7-rc7 and noticed that it breaks reboot on
my ODROID-X2.
Going to check where exactly things break.
Sadly it's the last patch where everything comes together:
"iommu/exynos: Add proper runtime pm support"
I still have to check if forcing runpm status to 'on' makes a
difference. I suspect that the aggressive clock gating might be the
reason?
Thanks for testing. I will check this issue. Could you send me your
.config?
This is the config I'm currently using:
https://github.com/tobiasjakobi/odroid-environment/blob/master/sourcecode/system/vanilla-4.7-debug.conf
Do you think checking this with no_console_suspend makes sense?
no_console_suspend switch won't provide more information, but I managed
to reproduce your issue. I'm really confused how enabling runtime pm can
cause problems with usb/smsc95xx ethernet driver (that is the reason for
failed reboot). Maybe it is somehow related to the global relations
between devices and drivers and the fact that creating the runtime pm
links change the order of operations. I will check this again when
Rafael send updated patches. Here is the log I got (after waiting some
time):
# reboot
Broadcast message from root@target (ttySAC1) (Mon Jul 18 13:33:38 2016):
The system is going down for reboot NOW!
INIT: Switching to runlevel: 6
INIT: Sending processes the TERM signal
[info] Using makefile-style concurrent boot in runlevel 6.
[ ok ] Stopping cgroup management proxy daemon: cgproxy[] Stopping
internet superserver: inetd.
[] Stopping cgroup management daemon: cgmanagermax77686-rtc
max77686-rtc: RTC alarm IRQ: 119
[ ok ] Shutting down ALSA...done.
random: nonblocking pool is initialized
[info] Saving the system clock.
[info] Hardware Clock updated to Mon Jul 18 13:33:40 UTC 2016.
[ ok ] Asking all remaining processes to terminate...done.
[ ok ] All processes ended within 1 seconds...done.
[ ok ] Stopping rpcbind daemon
[ ok ] Deconfiguring network interfaces...done.
[ ok ] Unmounting temporary filesystems...done.
[ ok ] Deactivating swap...done.
EXT4-fs (mmcblk1p2): re-mounted. Opts: (null)
[info] Will now restart.
smsc95xx 1-2:1.0 eth0: Failed to read reg index 0x0114: -110
smsc95xx 1-2:1.0 eth0: Error reading MII_ACCESS
smsc95xx 1-2:1.0 eth0: MII is busy in smsc95xx_mdio_read
smsc95xx 1-2:1.0 eth0: Failed to read MII_BMSR
INFO: task kworker/0:1:410 blocked for more than 120 seconds.
Not tainted 4.7.0-rc7-debug+ #155
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
kworker/0:1 D c06850a8 0 410 2 0x
Workqueue: events_freezable mmc_rescan
Backtrace:
[] (__schedule) from [] (schedule+0x44/0xb0)
r10: r9:eebe1d88 r8:c0686234 r7: r6:0002 r5:7fff
r4:7fff
[] (schedule) from [] (schedule_timeout+0x154/0x1b0)
[] (schedule_timeout) from []
(wait_for_common+0xe0/0x174)
r8:c0686234 r7: r6:0002 r5:eebe1d8c r4:7fff
[] (wait_for_common) from []
(wait_for_completion+0x18/0x1c)
r10:0001 r9: r8: r7:eebe1d88 r6:eebe1d78 r5:ee26
r4:eebe1de4
[] (wait_for_completion) from []
(mmc_wait_for_req+0xc8/0x15c)
[] (mmc_wait_for_req) from []
(mmc_wait_for_cmd+0x6c/0xa4)
r8:eef73d00 r7:0003 r6:ee26 r5:c0a02448 r4:eebe1de4 r3:
[] (mmc_wait_for_cmd) from []
(mmc_send_status+0x8c/0xb0)
r7:eebe1eb0 r6:ee26 r5:ee26 r4:
[] (mmc_send_status) from [] (mmc_alive+0x18/0x1c)
r4:ee26
[] (mmc_alive) from []
(_mmc_detect_card_removed+0x40/0x90)
[] (_mmc_detect_card_removed) from []
(mmc_detect+0x2c/0x78)
r5:ee2602bc r4:ee26
[] (mmc_detect) from [] (mmc_rescan+0x1b0/0x324)
r5:ee2602bc r4:ee260368
[] (mmc_rescan) from [] (process_one_work+0x194/0x414)
r8:eef73d00 r7:eebe1eb0 r6:eef70280 r5:ee260368 r4:eea24080 r3:c04e94fc
[] (process_one_work) from [] (worker_thread+0x34/0x4d4)
r10:eef70280 r9:c0a02100 r8:0008 r7:eef70280 r6:eea24098 r5:eef702b4
r4:eea24080
[] (worker_thread) from [] (kthread+0xf8/0x11c)
r10: r9: r8: r7:c013aad8 r6:eea24080 r5:
r4:eea29d00
[] (kthread) from [] (ret_from_fork+0x14/0x24)
r7: r6: r5:c0141d20 r4:eea29d00
2 locks held by kworker/0:1/410:
#0: ("events_freezable"){.+.+.+}, at: []
process_one_work+0x128/0x414
#1: ((&(>detect)->work)){+.+.+.}, at: []
process_one_work+0x128/0x414
Best regards
--
Marek Szyprowski, PhD
Samsung R Institute Poland
Re: [PATCH v2 00/10] Exynos IOMMU: proper runtime PM support (use device dependencies)
Dear Tobias
On 2016-07-18 13:00, Tobias Jakobi wrote:
Marek Szyprowski wrote:
On 2016-07-15 15:21, Tobias Jakobi wrote:
Tobias Jakobi wrote:
Hello Marek,
I've tested the patchset on 4.7-rc7 and noticed that it breaks reboot on
my ODROID-X2.
Going to check where exactly things break.
Sadly it's the last patch where everything comes together:
"iommu/exynos: Add proper runtime pm support"
I still have to check if forcing runpm status to 'on' makes a
difference. I suspect that the aggressive clock gating might be the
reason?
Thanks for testing. I will check this issue. Could you send me your
.config?
This is the config I'm currently using:
https://github.com/tobiasjakobi/odroid-environment/blob/master/sourcecode/system/vanilla-4.7-debug.conf
Do you think checking this with no_console_suspend makes sense?
no_console_suspend switch won't provide more information, but I managed
to reproduce your issue. I'm really confused how enabling runtime pm can
cause problems with usb/smsc95xx ethernet driver (that is the reason for
failed reboot). Maybe it is somehow related to the global relations
between devices and drivers and the fact that creating the runtime pm
links change the order of operations. I will check this again when
Rafael send updated patches. Here is the log I got (after waiting some
time):
# reboot
Broadcast message from root@target (ttySAC1) (Mon Jul 18 13:33:38 2016):
The system is going down for reboot NOW!
INIT: Switching to runlevel: 6
INIT: Sending processes the TERM signal
[info] Using makefile-style concurrent boot in runlevel 6.
[ ok ] Stopping cgroup management proxy daemon: cgproxy[] Stopping
internet superserver: inetd.
[] Stopping cgroup management daemon: cgmanagermax77686-rtc
max77686-rtc: RTC alarm IRQ: 119
[ ok ] Shutting down ALSA...done.
random: nonblocking pool is initialized
[info] Saving the system clock.
[info] Hardware Clock updated to Mon Jul 18 13:33:40 UTC 2016.
[ ok ] Asking all remaining processes to terminate...done.
[ ok ] All processes ended within 1 seconds...done.
[ ok ] Stopping rpcbind daemon
[ ok ] Deconfiguring network interfaces...done.
[ ok ] Unmounting temporary filesystems...done.
[ ok ] Deactivating swap...done.
EXT4-fs (mmcblk1p2): re-mounted. Opts: (null)
[info] Will now restart.
smsc95xx 1-2:1.0 eth0: Failed to read reg index 0x0114: -110
smsc95xx 1-2:1.0 eth0: Error reading MII_ACCESS
smsc95xx 1-2:1.0 eth0: MII is busy in smsc95xx_mdio_read
smsc95xx 1-2:1.0 eth0: Failed to read MII_BMSR
INFO: task kworker/0:1:410 blocked for more than 120 seconds.
Not tainted 4.7.0-rc7-debug+ #155
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
kworker/0:1 D c06850a8 0 410 2 0x
Workqueue: events_freezable mmc_rescan
Backtrace:
[] (__schedule) from [] (schedule+0x44/0xb0)
r10: r9:eebe1d88 r8:c0686234 r7: r6:0002 r5:7fff
r4:7fff
[] (schedule) from [] (schedule_timeout+0x154/0x1b0)
[] (schedule_timeout) from []
(wait_for_common+0xe0/0x174)
r8:c0686234 r7: r6:0002 r5:eebe1d8c r4:7fff
[] (wait_for_common) from []
(wait_for_completion+0x18/0x1c)
r10:0001 r9: r8: r7:eebe1d88 r6:eebe1d78 r5:ee26
r4:eebe1de4
[] (wait_for_completion) from []
(mmc_wait_for_req+0xc8/0x15c)
[] (mmc_wait_for_req) from []
(mmc_wait_for_cmd+0x6c/0xa4)
r8:eef73d00 r7:0003 r6:ee26 r5:c0a02448 r4:eebe1de4 r3:
[] (mmc_wait_for_cmd) from []
(mmc_send_status+0x8c/0xb0)
r7:eebe1eb0 r6:ee26 r5:ee26 r4:
[] (mmc_send_status) from [] (mmc_alive+0x18/0x1c)
r4:ee26
[] (mmc_alive) from []
(_mmc_detect_card_removed+0x40/0x90)
[] (_mmc_detect_card_removed) from []
(mmc_detect+0x2c/0x78)
r5:ee2602bc r4:ee26
[] (mmc_detect) from [] (mmc_rescan+0x1b0/0x324)
r5:ee2602bc r4:ee260368
[] (mmc_rescan) from [] (process_one_work+0x194/0x414)
r8:eef73d00 r7:eebe1eb0 r6:eef70280 r5:ee260368 r4:eea24080 r3:c04e94fc
[] (process_one_work) from [] (worker_thread+0x34/0x4d4)
r10:eef70280 r9:c0a02100 r8:0008 r7:eef70280 r6:eea24098 r5:eef702b4
r4:eea24080
[] (worker_thread) from [] (kthread+0xf8/0x11c)
r10: r9: r8: r7:c013aad8 r6:eea24080 r5:
r4:eea29d00
[] (kthread) from [] (ret_from_fork+0x14/0x24)
r7: r6: r5:c0141d20 r4:eea29d00
2 locks held by kworker/0:1/410:
#0: ("events_freezable"){.+.+.+}, at: []
process_one_work+0x128/0x414
#1: ((&(>detect)->work)){+.+.+.}, at: []
process_one_work+0x128/0x414
Best regards
--
Marek Szyprowski, PhD
Samsung R Institute Poland
Re: [PATCH v2 00/10] Exynos IOMMU: proper runtime PM support (use device dependencies)
Hello Marek, Marek Szyprowski wrote: > Hi Tobias, > > > On 2016-07-15 15:21, Tobias Jakobi wrote: >> Tobias Jakobi wrote: >>> Hello Marek, >>> >>> I've tested the patchset on 4.7-rc7 and noticed that it breaks reboot on >>> my ODROID-X2. >>> >>> Going to check where exactly things break. >> Sadly it's the last patch where everything comes together: >> "iommu/exynos: Add proper runtime pm support" >> >> I still have to check if forcing runpm status to 'on' makes a >> difference. I suspect that the aggressive clock gating might be the >> reason? > > Thanks for testing. I will check this issue. Could you send me your > .config? This is the config I'm currently using: https://github.com/tobiasjakobi/odroid-environment/blob/master/sourcecode/system/vanilla-4.7-debug.conf Do you think checking this with no_console_suspend makes sense? - Tobias > > Best regards
Re: [PATCH v2 00/10] Exynos IOMMU: proper runtime PM support (use device dependencies)
Hello Marek, Marek Szyprowski wrote: > Hi Tobias, > > > On 2016-07-15 15:21, Tobias Jakobi wrote: >> Tobias Jakobi wrote: >>> Hello Marek, >>> >>> I've tested the patchset on 4.7-rc7 and noticed that it breaks reboot on >>> my ODROID-X2. >>> >>> Going to check where exactly things break. >> Sadly it's the last patch where everything comes together: >> "iommu/exynos: Add proper runtime pm support" >> >> I still have to check if forcing runpm status to 'on' makes a >> difference. I suspect that the aggressive clock gating might be the >> reason? > > Thanks for testing. I will check this issue. Could you send me your > .config? This is the config I'm currently using: https://github.com/tobiasjakobi/odroid-environment/blob/master/sourcecode/system/vanilla-4.7-debug.conf Do you think checking this with no_console_suspend makes sense? - Tobias > > Best regards
Re: [PATCH v2 00/10] Exynos IOMMU: proper runtime PM support (use device dependencies)
Hi Tobias, On 2016-07-15 15:21, Tobias Jakobi wrote: Tobias Jakobi wrote: Hello Marek, I've tested the patchset on 4.7-rc7 and noticed that it breaks reboot on my ODROID-X2. Going to check where exactly things break. Sadly it's the last patch where everything comes together: "iommu/exynos: Add proper runtime pm support" I still have to check if forcing runpm status to 'on' makes a difference. I suspect that the aggressive clock gating might be the reason? Thanks for testing. I will check this issue. Could you send me your .config? Best regards -- Marek Szyprowski, PhD Samsung R Institute Poland
Re: [PATCH v2 00/10] Exynos IOMMU: proper runtime PM support (use device dependencies)
Hi Tobias, On 2016-07-15 15:21, Tobias Jakobi wrote: Tobias Jakobi wrote: Hello Marek, I've tested the patchset on 4.7-rc7 and noticed that it breaks reboot on my ODROID-X2. Going to check where exactly things break. Sadly it's the last patch where everything comes together: "iommu/exynos: Add proper runtime pm support" I still have to check if forcing runpm status to 'on' makes a difference. I suspect that the aggressive clock gating might be the reason? Thanks for testing. I will check this issue. Could you send me your .config? Best regards -- Marek Szyprowski, PhD Samsung R Institute Poland
Re: [PATCH v2 00/10] Exynos IOMMU: proper runtime PM support (use device dependencies)
Tobias Jakobi wrote: > Hello Marek, > > I've tested the patchset on 4.7-rc7 and noticed that it breaks reboot on > my ODROID-X2. > > Going to check where exactly things break. Sadly it's the last patch where everything comes together: "iommu/exynos: Add proper runtime pm support" I still have to check if forcing runpm status to 'on' makes a difference. I suspect that the aggressive clock gating might be the reason? With best wishes, Tobias > With best wishes, > Tobias > > > Marek Szyprowski wrote: >> Hello, >> >> This patch series finally implements proper runtime PM support in Exynos >> IOMMU driver. This has been achieved by using device links, which lets >> SYSMMU controller's runtime PM to follow master's device runtime PM (the >> device which actually performs DMA transaction). The main idea >> behind this solution is an observation that any DMA activity from master >> device can be done only when master device is active, thus when master >> device is suspended SYSMMU controller device can also be suspended. >> >> This patchset solves the situation that power domains are always enabled, >> because all SYSMMU controllers (which belongs to those domains) are >> permanently active (because existing driver was simplified and kept >> SYSMMU device active all the time after initialization). >> >> Patches 1-5 are resend of the "[RFC][PATCH 0/5] Functional dependencies >> between devices" patchset: >> http://thread.gmane.org/gmane.linux.power-management.general/67424/focus=2126379 >> I've included them here, because it is hard to find them all on mailing >> list archives. >> >> Patches 6-8 are fixes to device dependencies/links code, which were >> required to use this solution for Exynos IOMMU driver. I'm not PM/runtime >> PM code expert, so please double check if my changes are really correct. >> >> This patchset requires my previous changes to Exynos IOMMU driver >> submitted in the "Exynos IOMMU: improve clock management" thread: >> http://www.spinics.net/lists/arm-kernel/msg505695.html >> >> Best regards >> Marek Szyprowski >> Samsung R Institute Poland >> >> >> Changelog: >> v2: >> - replaced PM notifiers with generic device dependencies/links developped >> by Rafael J. Wysocki >> >> v1: http://www.spinics.net/lists/arm-kernel/msg509600.html >> - initial version >> >> >> Patch summary: >> >> Marek Szyprowski (5): >> driver core: Avoid endless recursion if device has more than one link >> driver core: Add support for links to already probed drivers >> PM core: Fix restoring devices with links during system PM transition >> iommu/exynos: Remove excessive, useless debug >> iommu/exynos: Add proper runtime pm support >> >> Rafael J. Wysocki (5): >> driver core: Add a wrapper around __device_release_driver() >> driver core: Functional dependencies tracking support >> PM core: Make async suspend/resume of devices use device links >> PM core: Make runtime PM of devices use device links >> PM core: Optimize the use of device links for runtime PM >> >> drivers/base/base.h | 13 ++ >> drivers/base/core.c | 410 >> +++ >> drivers/base/dd.c| 65 +-- >> drivers/base/power/main.c| 68 ++- >> drivers/base/power/runtime.c | 130 +- >> drivers/iommu/exynos-iommu.c | 221 +++ >> include/linux/device.h | 41 + >> include/linux/pm.h | 1 + >> include/linux/pm_runtime.h | 6 + >> 9 files changed, 809 insertions(+), 146 deletions(-) >> > > -- > To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" > in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html >
Re: [PATCH v2 00/10] Exynos IOMMU: proper runtime PM support (use device dependencies)
Tobias Jakobi wrote: > Hello Marek, > > I've tested the patchset on 4.7-rc7 and noticed that it breaks reboot on > my ODROID-X2. > > Going to check where exactly things break. Sadly it's the last patch where everything comes together: "iommu/exynos: Add proper runtime pm support" I still have to check if forcing runpm status to 'on' makes a difference. I suspect that the aggressive clock gating might be the reason? With best wishes, Tobias > With best wishes, > Tobias > > > Marek Szyprowski wrote: >> Hello, >> >> This patch series finally implements proper runtime PM support in Exynos >> IOMMU driver. This has been achieved by using device links, which lets >> SYSMMU controller's runtime PM to follow master's device runtime PM (the >> device which actually performs DMA transaction). The main idea >> behind this solution is an observation that any DMA activity from master >> device can be done only when master device is active, thus when master >> device is suspended SYSMMU controller device can also be suspended. >> >> This patchset solves the situation that power domains are always enabled, >> because all SYSMMU controllers (which belongs to those domains) are >> permanently active (because existing driver was simplified and kept >> SYSMMU device active all the time after initialization). >> >> Patches 1-5 are resend of the "[RFC][PATCH 0/5] Functional dependencies >> between devices" patchset: >> http://thread.gmane.org/gmane.linux.power-management.general/67424/focus=2126379 >> I've included them here, because it is hard to find them all on mailing >> list archives. >> >> Patches 6-8 are fixes to device dependencies/links code, which were >> required to use this solution for Exynos IOMMU driver. I'm not PM/runtime >> PM code expert, so please double check if my changes are really correct. >> >> This patchset requires my previous changes to Exynos IOMMU driver >> submitted in the "Exynos IOMMU: improve clock management" thread: >> http://www.spinics.net/lists/arm-kernel/msg505695.html >> >> Best regards >> Marek Szyprowski >> Samsung R Institute Poland >> >> >> Changelog: >> v2: >> - replaced PM notifiers with generic device dependencies/links developped >> by Rafael J. Wysocki >> >> v1: http://www.spinics.net/lists/arm-kernel/msg509600.html >> - initial version >> >> >> Patch summary: >> >> Marek Szyprowski (5): >> driver core: Avoid endless recursion if device has more than one link >> driver core: Add support for links to already probed drivers >> PM core: Fix restoring devices with links during system PM transition >> iommu/exynos: Remove excessive, useless debug >> iommu/exynos: Add proper runtime pm support >> >> Rafael J. Wysocki (5): >> driver core: Add a wrapper around __device_release_driver() >> driver core: Functional dependencies tracking support >> PM core: Make async suspend/resume of devices use device links >> PM core: Make runtime PM of devices use device links >> PM core: Optimize the use of device links for runtime PM >> >> drivers/base/base.h | 13 ++ >> drivers/base/core.c | 410 >> +++ >> drivers/base/dd.c| 65 +-- >> drivers/base/power/main.c| 68 ++- >> drivers/base/power/runtime.c | 130 +- >> drivers/iommu/exynos-iommu.c | 221 +++ >> include/linux/device.h | 41 + >> include/linux/pm.h | 1 + >> include/linux/pm_runtime.h | 6 + >> 9 files changed, 809 insertions(+), 146 deletions(-) >> > > -- > To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" > in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html >
Re: [PATCH v2 00/10] Exynos IOMMU: proper runtime PM support (use device dependencies)
Hello Marek, I've tested the patchset on 4.7-rc7 and noticed that it breaks reboot on my ODROID-X2. Going to check where exactly things break. With best wishes, Tobias Marek Szyprowski wrote: > Hello, > > This patch series finally implements proper runtime PM support in Exynos > IOMMU driver. This has been achieved by using device links, which lets > SYSMMU controller's runtime PM to follow master's device runtime PM (the > device which actually performs DMA transaction). The main idea > behind this solution is an observation that any DMA activity from master > device can be done only when master device is active, thus when master > device is suspended SYSMMU controller device can also be suspended. > > This patchset solves the situation that power domains are always enabled, > because all SYSMMU controllers (which belongs to those domains) are > permanently active (because existing driver was simplified and kept > SYSMMU device active all the time after initialization). > > Patches 1-5 are resend of the "[RFC][PATCH 0/5] Functional dependencies > between devices" patchset: > http://thread.gmane.org/gmane.linux.power-management.general/67424/focus=2126379 > I've included them here, because it is hard to find them all on mailing > list archives. > > Patches 6-8 are fixes to device dependencies/links code, which were > required to use this solution for Exynos IOMMU driver. I'm not PM/runtime > PM code expert, so please double check if my changes are really correct. > > This patchset requires my previous changes to Exynos IOMMU driver > submitted in the "Exynos IOMMU: improve clock management" thread: > http://www.spinics.net/lists/arm-kernel/msg505695.html > > Best regards > Marek Szyprowski > Samsung R Institute Poland > > > Changelog: > v2: > - replaced PM notifiers with generic device dependencies/links developped > by Rafael J. Wysocki > > v1: http://www.spinics.net/lists/arm-kernel/msg509600.html > - initial version > > > Patch summary: > > Marek Szyprowski (5): > driver core: Avoid endless recursion if device has more than one link > driver core: Add support for links to already probed drivers > PM core: Fix restoring devices with links during system PM transition > iommu/exynos: Remove excessive, useless debug > iommu/exynos: Add proper runtime pm support > > Rafael J. Wysocki (5): > driver core: Add a wrapper around __device_release_driver() > driver core: Functional dependencies tracking support > PM core: Make async suspend/resume of devices use device links > PM core: Make runtime PM of devices use device links > PM core: Optimize the use of device links for runtime PM > > drivers/base/base.h | 13 ++ > drivers/base/core.c | 410 > +++ > drivers/base/dd.c| 65 +-- > drivers/base/power/main.c| 68 ++- > drivers/base/power/runtime.c | 130 +- > drivers/iommu/exynos-iommu.c | 221 +++ > include/linux/device.h | 41 + > include/linux/pm.h | 1 + > include/linux/pm_runtime.h | 6 + > 9 files changed, 809 insertions(+), 146 deletions(-) >
Re: [PATCH v2 00/10] Exynos IOMMU: proper runtime PM support (use device dependencies)
Hello Marek, I've tested the patchset on 4.7-rc7 and noticed that it breaks reboot on my ODROID-X2. Going to check where exactly things break. With best wishes, Tobias Marek Szyprowski wrote: > Hello, > > This patch series finally implements proper runtime PM support in Exynos > IOMMU driver. This has been achieved by using device links, which lets > SYSMMU controller's runtime PM to follow master's device runtime PM (the > device which actually performs DMA transaction). The main idea > behind this solution is an observation that any DMA activity from master > device can be done only when master device is active, thus when master > device is suspended SYSMMU controller device can also be suspended. > > This patchset solves the situation that power domains are always enabled, > because all SYSMMU controllers (which belongs to those domains) are > permanently active (because existing driver was simplified and kept > SYSMMU device active all the time after initialization). > > Patches 1-5 are resend of the "[RFC][PATCH 0/5] Functional dependencies > between devices" patchset: > http://thread.gmane.org/gmane.linux.power-management.general/67424/focus=2126379 > I've included them here, because it is hard to find them all on mailing > list archives. > > Patches 6-8 are fixes to device dependencies/links code, which were > required to use this solution for Exynos IOMMU driver. I'm not PM/runtime > PM code expert, so please double check if my changes are really correct. > > This patchset requires my previous changes to Exynos IOMMU driver > submitted in the "Exynos IOMMU: improve clock management" thread: > http://www.spinics.net/lists/arm-kernel/msg505695.html > > Best regards > Marek Szyprowski > Samsung R Institute Poland > > > Changelog: > v2: > - replaced PM notifiers with generic device dependencies/links developped > by Rafael J. Wysocki > > v1: http://www.spinics.net/lists/arm-kernel/msg509600.html > - initial version > > > Patch summary: > > Marek Szyprowski (5): > driver core: Avoid endless recursion if device has more than one link > driver core: Add support for links to already probed drivers > PM core: Fix restoring devices with links during system PM transition > iommu/exynos: Remove excessive, useless debug > iommu/exynos: Add proper runtime pm support > > Rafael J. Wysocki (5): > driver core: Add a wrapper around __device_release_driver() > driver core: Functional dependencies tracking support > PM core: Make async suspend/resume of devices use device links > PM core: Make runtime PM of devices use device links > PM core: Optimize the use of device links for runtime PM > > drivers/base/base.h | 13 ++ > drivers/base/core.c | 410 > +++ > drivers/base/dd.c| 65 +-- > drivers/base/power/main.c| 68 ++- > drivers/base/power/runtime.c | 130 +- > drivers/iommu/exynos-iommu.c | 221 +++ > include/linux/device.h | 41 + > include/linux/pm.h | 1 + > include/linux/pm_runtime.h | 6 + > 9 files changed, 809 insertions(+), 146 deletions(-) >
