Re: [PATCH v2 0/4] OMAP: DMA: mstandby mode and runtime pm support
Kevin, On Sat, Mar 19, 2011 at 08:46:05AM +0530, G, Manjunath Kondaiah wrote: On Fri, Mar 18, 2011 at 11:27:00AM -0700, Kevin Hilman wrote: G, Manjunath Kondaiah manj...@ti.com writes: On Thu, Mar 17, 2011 at 02:29:18PM -0700, Kevin Hilman wrote: G, Manjunath Kondaiah manj...@ti.com writes: Patch series to support mstandby mode handling and enabling runtime PM support for DMA driver. I still have the same problems as with the previous revision: This is still not runtime-suspending when I use my DMA test in linking mode. If I put a large enough period between transfers, it should autosuspend during transfers. It seems to do auto-suspend and resume once, but then it never suspends again. I tested with my dmatest module[1], and loaded with: # insmod ./dmatest.ko linking=1 forever=1 forever_period=1024 Not only does it not auto-suspend between transfers (which I expected), it also doesn't suspend after removing the module which stops all active channels. Tested again on 2.6.38 with patches pulled from patchworks and for me, the same test case seems to be passing. Here is the log: http://pastebin.com/ccEmTZS5 The above test case is executed on blaze and same result is observed with other OMAP2+ boards also. Can you try again with dmatest loaded without 'debug=1' What's strange is that I noticed it worked with debug=1 also, but didn't with debug disabled. I *think* it's a bug in my test, which I fixed, but can you try the above before pulling a new version of my test? done. without pulling latest dmatest changes, your observation is correct. With latest changes, it is working fine. If you don't see any further issues with this patch series, there are no more changes to this patch series except one warning fix: http://thread.gmane.org/gmane.linux.ports.arm.omap/54753/focus=55097 If it is only warning fix, I can send pull request on top of omap-for-linus branch. -Manjunath -- To unsubscribe from this list: send the line unsubscribe linux-omap 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 0/4] OMAP: DMA: mstandby mode and runtime pm support
G, Manjunath Kondaiah manj...@ti.com writes: [...] If you don't see any further issues with this patch series, there are no more changes to this patch series except one warning fix: http://thread.gmane.org/gmane.linux.ports.arm.omap/54753/focus=55097 OK If it is only warning fix, I can send pull request on top of omap-for-linus branch. Please repost the series one more time for final review. Based on Tony's omap-for-linus branch is fine. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap 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 0/4] OMAP: DMA: mstandby mode and runtime pm support
Kevin Hilman khil...@ti.com writes: G, Manjunath Kondaiah manj...@ti.com writes: [...] If you don't see any further issues with this patch series, there are no more changes to this patch series except one warning fix: http://thread.gmane.org/gmane.linux.ports.arm.omap/54753/focus=55097 OK If it is only warning fix, I can send pull request on top of omap-for-linus branch. Please repost the series one more time for final review. Based on Tony's omap-for-linus branch is fine. Also note that you had the wrong address for the linux-arm-kernel list (now removed). The correct address for that list is linux-arm-ker...@lists.infradead.org Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap 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 0/4] OMAP: DMA: mstandby mode and runtime pm support
G, Manjunath Kondaiah manj...@ti.com writes: On Thu, Mar 17, 2011 at 02:29:18PM -0700, Kevin Hilman wrote: G, Manjunath Kondaiah manj...@ti.com writes: Patch series to support mstandby mode handling and enabling runtime PM support for DMA driver. I still have the same problems as with the previous revision: This is still not runtime-suspending when I use my DMA test in linking mode. If I put a large enough period between transfers, it should autosuspend during transfers. It seems to do auto-suspend and resume once, but then it never suspends again. I tested with my dmatest module[1], and loaded with: # insmod ./dmatest.ko linking=1 forever=1 forever_period=1024 Not only does it not auto-suspend between transfers (which I expected), it also doesn't suspend after removing the module which stops all active channels. Tested again on 2.6.38 with patches pulled from patchworks and for me, the same test case seems to be passing. Here is the log: http://pastebin.com/ccEmTZS5 The above test case is executed on blaze and same result is observed with other OMAP2+ boards also. Can you try again with dmatest loaded without 'debug=1' What's strange is that I noticed it worked with debug=1 also, but didn't with debug disabled. I *think* it's a bug in my test, which I fixed, but can you try the above before pulling a new version of my test? Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap 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 0/4] OMAP: DMA: mstandby mode and runtime pm support
On Fri, Mar 18, 2011 at 11:27:00AM -0700, Kevin Hilman wrote: G, Manjunath Kondaiah manj...@ti.com writes: On Thu, Mar 17, 2011 at 02:29:18PM -0700, Kevin Hilman wrote: G, Manjunath Kondaiah manj...@ti.com writes: Patch series to support mstandby mode handling and enabling runtime PM support for DMA driver. I still have the same problems as with the previous revision: This is still not runtime-suspending when I use my DMA test in linking mode. If I put a large enough period between transfers, it should autosuspend during transfers. It seems to do auto-suspend and resume once, but then it never suspends again. I tested with my dmatest module[1], and loaded with: # insmod ./dmatest.ko linking=1 forever=1 forever_period=1024 Not only does it not auto-suspend between transfers (which I expected), it also doesn't suspend after removing the module which stops all active channels. Tested again on 2.6.38 with patches pulled from patchworks and for me, the same test case seems to be passing. Here is the log: http://pastebin.com/ccEmTZS5 The above test case is executed on blaze and same result is observed with other OMAP2+ boards also. Can you try again with dmatest loaded without 'debug=1' What's strange is that I noticed it worked with debug=1 also, but didn't with debug disabled. I *think* it's a bug in my test, which I fixed, but can you try the above before pulling a new version of my test? done. without pulling latest dmatest changes, your observation is correct. With latest changes, it is working fine. -Manjunath -- To unsubscribe from this list: send the line unsubscribe linux-omap 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 0/4] OMAP: DMA: mstandby mode and runtime pm support
G, Manjunath Kondaiah manj...@ti.com writes: Patch series to support mstandby mode handling and enabling runtime PM support for DMA driver. I still have the same problems as with the previous revision: This is still not runtime-suspending when I use my DMA test in linking mode. If I put a large enough period between transfers, it should autosuspend during transfers. It seems to do auto-suspend and resume once, but then it never suspends again. I tested with my dmatest module[1], and loaded with: # insmod ./dmatest.ko linking=1 forever=1 forever_period=1024 Not only does it not auto-suspend between transfers (which I expected), it also doesn't suspend after removing the module which stops all active channels. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap 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 0/4] OMAP: DMA: mstandby mode and runtime pm support
Hi Kevin, On Fri, Mar 11, 2011 at 07:50:11PM +0530, G, Manjunath Kondaiah wrote: Patch series to support mstandby mode handling and enabling runtime PM support for DMA driver. Changes from v1: - fixed runtime_status issue if channel linking feature is used. - fixed context restore issue during off mode. - removed sysconfig register access during DMA context/restore The review comments and alignment can be found at: http://thread.gmane.org/gmane.linux.ports.arm.omap/53150 Baseline: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git Branch: omap-for-linus commit 94a06b74e724caabcf0464c81527cfbcae0c8aff Merge: 0dde52a 9062511 Author: Tony Lindgren t...@atomide.com Note: For OMAP2420 and OMAP2430, the patch series is tested on top of v2.6.38-rc4 since boot fails with latest mainline for the above OMAP's. Build: - omap1_defconfig - omap2plus_defconfig Boot test: - OMAP1710 H3 - OMAP2420 H4 - OMAP2430 SDP - OMAP3430 Zoom2 - OMAP3630 Zoom3 - OMAP4430 Blaze DMA tests: The following dma test code is used for testing OMAP2+ boards: git://gitorious.org/omap-test/dmatest.git Apart from that, offmode testing is done for OMAP3430-Zoom2 using the procedure: echo 1 /debug/pm_debug/sleep_while_idle echo 1 /debug/pm_debug/enable_off_mode echo 5 /sys/devices/platform/omap/omap_uart.0/sleep_timeout echo 5 /sys/devices/platform/omap/omap_uart.1/sleep_timeout echo 5 /sys/devices/platform/omap/omap_uart.2/sleep_timeout With the above steps, core off mode count gets increasing if the the board is idle for more than 5 seconds. Also, DMA transfers are done with forever option using: insmod ./dmatest.ko linking=1 forever=1 forever_period=1024 debug=1 The /sys/devices/platform/omap/omap_dma_system.0/power/runtime_status was verified and after completion of the tests, runtime_status will be always suspended. (Special thanks to Kevin Hilman for identifying runtime_status count issue with DMA linking option). Ping? Anymore comments on this series? -Manjunath G, Manjunath Kondaiah (4): OMAP2+: PM: omap device: API's for handling mstandby mode OMAP2+: DMA: prevent races while setting M idle mode to nostandby OMAP: PM: DMA: Enable runtime pm OMAP: DMA: Fix: context restore during off mode arch/arm/mach-omap1/dma.c |1 + arch/arm/mach-omap2/dma.c | 16 ++ arch/arm/mach-omap2/omap_hwmod.c | 42 ++ arch/arm/plat-omap/dma.c | 194 + arch/arm/plat-omap/include/plat/dma.h |1 + arch/arm/plat-omap/include/plat/omap_device.h |2 + arch/arm/plat-omap/include/plat/omap_hwmod.h |4 +- arch/arm/plat-omap/omap_device.c | 64 8 files changed, 293 insertions(+), 31 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/4] OMAP: DMA: mstandby mode and runtime pm support
Patch series to support mstandby mode handling and enabling runtime PM support for DMA driver. Changes from v1: - fixed runtime_status issue if channel linking feature is used. - fixed context restore issue during off mode. - removed sysconfig register access during DMA context/restore The review comments and alignment can be found at: http://thread.gmane.org/gmane.linux.ports.arm.omap/53150 Baseline: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git Branch: omap-for-linus commit 94a06b74e724caabcf0464c81527cfbcae0c8aff Merge: 0dde52a 9062511 Author: Tony Lindgren t...@atomide.com Note: For OMAP2420 and OMAP2430, the patch series is tested on top of v2.6.38-rc4 since boot fails with latest mainline for the above OMAP's. Build: - omap1_defconfig - omap2plus_defconfig Boot test: - OMAP1710 H3 - OMAP2420 H4 - OMAP2430 SDP - OMAP3430 Zoom2 - OMAP3630 Zoom3 - OMAP4430 Blaze DMA tests: The following dma test code is used for testing OMAP2+ boards: git://gitorious.org/omap-test/dmatest.git Apart from that, offmode testing is done for OMAP3430-Zoom2 using the procedure: echo 1 /debug/pm_debug/sleep_while_idle echo 1 /debug/pm_debug/enable_off_mode echo 5 /sys/devices/platform/omap/omap_uart.0/sleep_timeout echo 5 /sys/devices/platform/omap/omap_uart.1/sleep_timeout echo 5 /sys/devices/platform/omap/omap_uart.2/sleep_timeout With the above steps, core off mode count gets increasing if the the board is idle for more than 5 seconds. Also, DMA transfers are done with forever option using: insmod ./dmatest.ko linking=1 forever=1 forever_period=1024 debug=1 The /sys/devices/platform/omap/omap_dma_system.0/power/runtime_status was verified and after completion of the tests, runtime_status will be always suspended. (Special thanks to Kevin Hilman for identifying runtime_status count issue with DMA linking option). G, Manjunath Kondaiah (4): OMAP2+: PM: omap device: API's for handling mstandby mode OMAP2+: DMA: prevent races while setting M idle mode to nostandby OMAP: PM: DMA: Enable runtime pm OMAP: DMA: Fix: context restore during off mode arch/arm/mach-omap1/dma.c |1 + arch/arm/mach-omap2/dma.c | 16 ++ arch/arm/mach-omap2/omap_hwmod.c | 42 ++ arch/arm/plat-omap/dma.c | 194 + arch/arm/plat-omap/include/plat/dma.h |1 + arch/arm/plat-omap/include/plat/omap_device.h |2 + arch/arm/plat-omap/include/plat/omap_hwmod.h |4 +- arch/arm/plat-omap/omap_device.c | 64 8 files changed, 293 insertions(+), 31 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
