On Thu, Nov 19, 2009 at 1:04 PM, Jarkko Nikula <jhnikula@xxxxxxxxx> wrote: > 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. [Anuj] Yes, w/o audio, it goes into suspend neatly. After going through the entire patch series "[PATCHv5 00/20] OMAP ASoC changes in DMA utilization", which I missed earlier, I found that the sysfs entry dma_op_mode can be toggled among element/frame/threshold, by default which is element hence not allowing the mcbsp driver to go into idle state. I changed that at run time and after that I am able to hit the suspend state while playing back audio (at least the log doesn't show that the system is not able to hit suspend). My question is: is sysfs the only way to choose threshold or can it be made as default? I could not see that happening in the code so thinking of the possible reason of choosing not to do so. Because the user who wants to hit suspend will not like to issue driver specific commands. Any specific reason of not doing that by default? > > -- > Jarkko > _______________________________________________ > Alsa-devel mailing list > Alsa-devel@xxxxxxxxxxxxxxxx > http://mailman.alsa-project.org/mailman/listinfo/alsa-devel > -- Best Regards, Anuj Aggarwal _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
