On Wed, Nov 18, 2009 at 8:28 PM, Aggarwal, Anuj <anuj.aggarwal@xxxxxx>wrote: > > If no API or feature would require active McBSP block before the > > omap_mcbsp_start call, then the clock management could be done inside > > the omap_mcbsp_start/-stop functions. > [Aggarwal, Anuj] I tried doing that but it didn't work because before > _start, we need to call set_hw_params which configures mcbsp, for which > clocks are required. > > > First modification to .../plat-omap/mcbsp.c could be just a patch which keeps the clocks on only when needed. I.e. keep them disabled when returning from request and activate them only when accessing the McBSP registers or when it is running. But that said, I don't know are there some use case or API which requires active clocks after request so that should be checked. > > Also context save/restore operations belongs more to PM callbacks > > of .../plat-omap/mcbsp.c. Or probably that can be done also dynamically > > inside the omap_mcbsp_start/-stop for keeping the whole McBSP shutdown > > whenever it is idle. > [Aggarwal, Anuj] I am sorry I couldn't understand that. Did you mean that > PM hooks can be added in the mcbsp driver which can be registered and > called > As and when required? Any reference driver for this, if my understanding > is correct? > > > Yep, the PM hooks in .../plat-omap/mcbsp.c should take care of saving the McBSP registers before going into suspend or restore them back when resuming. This would be second patch after the clock change patch. The comment about dynamic PM was an idea that if McBSP could be unpowered whenever it's not running and do the resume only when calling omap_mcbsp_start. But that would be some future improvements after basic suspend/resume functionality. > I think it's worth to look McBSP register cache concept [1] from Janusz > > Krzysztofik would it help all of this context save/restore operations. > [Aggarwal, Anuj] I tried these two patches on omap3 evm but they didn't > work for me. The system doesn't go to the suspend state when I do: > echo mem > /sys/power/state > And the culprits were core (think sdma) and per domain. I tried > disabling the mcbsp i/f clock as well but it didn't help. On mcbsp > register dump, I couldn't find the sysconfig register getting > configured. Could that be the root cause? > Does it go into suspend if the audio is not running (i.e. McBSP not requested) or if you don't even compile the McBSP support? I haven't looked are there checks for active clocks in PM core but PM is easier to start with bare minimum and to see that system can do suspend/resume and then add more features one by one. -- Jarkko _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
