OMAP: DMA: mstandby mode and runtime pm support
Get series with b4
b4 am [email protected]Versions newest first
- v1 Latest0 of 3 patches 0 repliesNew
Patches in v1 No applies recorded yet
None of the 3 patches the cover letter announces are in this archive.
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.
Cover letter [PATCH 0/3] OMAP: DMA: mstandby mode and runtime pm support
Quoted 22 lines · Manjunath Kondaiah
Quoted 21 lines · Manjunath Kondaiah
Quoted 19 lines · Kevin Hilman
Quoted 2 lines · Manjunath Kondaiah
This patch series is remaining part of dma hwmod to support pm runtime and for handling mstandby mode for all applicable DMA mstandby mode errata.
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=1024Not 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.
Quoted 7 lines
Quoted 2 lines
The normal chaining test cases are executed and which used to show the proper status. Let me reproduce this issue with your test procedure.
ok. I am able to reproduce this issue and fixed
_get_syncusage inomap_start_dmaif channel linking is used. Earlier it was handled for the cases with chaining API's. If linking is done without chaining API's, it will result in_get_syncand_putmismatch.
Great, glad you found it.
My DMA test module predates the existence of a chaining API, so I guess that's part of the problem. Glad it helped though.
Quoted 2 lines
Thanks for the test case and I will be re posting the patches with the above fix.
Thanks,
Kevin