On Mon, Apr 16, 2012 at 1:40 PM, Peter Ujfalusi peter.ujfalusi@ti.com wrote:
On 04/15/2012 10:18 PM, Jarkko Nikula wrote:
On 04/14/2012 06:40 PM, Grazvydas Ignotas wrote:
Hi,
Currently on OMAP the system fails to suspend properly if there are audio streams active (PER and CORE don't enter low power states). I wonder if this is expected to be handled by the driver and can be considered a bug, or is it audio daemon's/system's responsibility to stop all audio streams before kernel to is asked to start suspending?
Did the suspend/resume worked in the past during audio activity?
I don't think so.
I don't know immediately does this require any major changes for McBSP register access that are done in function calls before omap_mcbsp_start (IRCC hwmod might set already ICLK gating for register access) but some code is needed to deal with McBSP register cache restore (due OMAP OFFMODE that might be hit) and most probably for McBSP FIFO draining as well.
What we need to do is to have proper register store/restore for McBSP to support suspend during audio activity. But. Even with that if the McBSP is hitting OFF mode we will loose the McBSP FIFO content (invalidated). This means we are going to have missing samples. Probably the user will not going to notice it, but it is going to happen.
Could we maybe first get it working with RET (I think it's currently default for suspend to RAM), where register contents are not lost AFAIK? What needs to be done there, transmitter stopped and clocks disabled I guess, anything else? I wonder if ongoing DMA needs to be handled somehow too. For our use case FIFO loss, if it happens, shouldn't be a big deal.