[alsa-devel] [PATCH 1/2] OMAP3: MCBSP: Suspend/resume failure fix

[Jarkko Nikula]

On Wed, Nov 18, 2009 at 8:28 PM, Aggarwal, Anuj <anuj.aggarwal at ti.com>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