Opened 4 years ago

Closed 4 years ago

#12596 closed defect (fixed)

XO-4 sound streams hang over suspend/resume

Reported by: tomyin Owned by: dsd
Priority: low Milestone: 13.2.0
Component: kernel Version: not specified
Keywords: Cc:
Blocked By: Blocking:
Deployments affected: Action Needed: add to build
Verified: no

Description

OS: 31034o4
OFW: Q7B22
EC: 0.4.02
Procedure:

  1. Play buck.ogv by Movie Player in GNOME mode.
  2. Press power button let machine enter suspend.
  3. Wake up machine by press power button then close Movie Player.

Attachments (2)

0001-snd-debug.patch (5.7 KB) - added by dsd 4 years ago.
tdma-sr.patch (6.3 KB) - added by dsd 4 years ago.

Download all attachments as: .zip

Change History (9)

comment:1 Changed 4 years ago by dsd

  • Milestone changed from Not Triaged to 13.1.0
  • Owner set to dsd

comment:2 Changed 4 years ago by tomyin

Jukebox can’t be closed.

  1. Play buck.ogv by Jukebox in Sugar mode.
  2. Press power button let machine enter suspend.
  3. Wake up machine by press power button then close Jukebox.

comment:3 Changed 4 years ago by dsd

  • Summary changed from [CL4] Movie Player can’t be closed. to XO-4 sound streams hang over suspend/resume

I can't quite figure this one out.

Firstly, the mmp-pcm offers flag SNDRV_PCM_INFO_RESUME which suggests that it has complete suspend/resume handling. It doesn't - the suspend/resume code is commented out.

Trying to enable the suspend/resume code: doesn't work. I suspect it is let down by the lack of suspend/resume routines in tdma. Attached as snd-debug.patch here.

By dropping SNDRV_PCM_INFO_RESUME the stream will simply be fully stopped and restarted during suspend and resume, should be foolproof, and thats what we do on XO-1.75. However that doesn't work either. No tdma interrupts arrive when the stream is restarted during resume. I went to some extra steps to make sure that the right info is reprogrammed during resume, and I checked TDMA register dumps from just before enabling the DMA channel, no difference between the failing and working case. Attached as tdma-sr.patch here.

Next step would be to check the ICU registers, make sure the interrupt is really unmasked, and look for other reasons why DMA interrupts would not be happening.

Changed 4 years ago by dsd

Changed 4 years ago by dsd

comment:4 Changed 4 years ago by dsd

Another approach would be to copy over the sledgehammer power management from the XO-1.75 kernel.

comment:5 Changed 4 years ago by dsd

The current soc-dmaengine code is not really cut out for the sledgehammer approach of tearing down the DMA stream over suspend/resume so that it gets fully recreated from scratch.

For example, we call dmaengine_slave_config() from mmp_pcm_hw_params(), an important part of setting up the stream. However hw_params is not called again in the resume path when the stream is being restarted.

Looks like full state save/restore might be a more workable approach.

comment:6 Changed 4 years ago by dsd

  • Action Needed changed from never set to add to build
  • Component changed from not assigned to kernel
  • Milestone changed from 13.1.0 to 13.2.0

Fixed in arm-3.5 7fa49a9a and aeff3e257a, we now implement a full suspend/resume of the audio stream.

The tdma difficulty encountered earlier is likely due to the close tie between tdma and audio. Through a simple experiment I determined that TDMA will not roll if the SSPA is not set up. I also found that the SSPA must be set up first.

The previously-disabled suspend/resume code didn't work either. I imagine it was just incomplete. I examined carefully the call sequence for when an audio stream is opened and made sure that the same sequence executes in resume. Now things are working.

comment:7 Changed 4 years ago by dsd

  • Resolution set to fixed
  • Status changed from new to closed

Tested 13.2.0 build 8 on XO-4, the sound stream is fine after closing and opening the lid while TamTamMini is playing a drum loop.

Note: See TracTickets for help on using tickets.