The first fix is a hairy one, but I think the locking is fool proof now. It is needed because there is no telling in which order user space starts an audio and video stream playback. If the audio is started first and the video mode is changed when video playback starts the audio setup needs to survive display turning off and back on again. After this patch the audio streams should survive a suspend-resume cycle too. The second one is a trivial work-around to a problem in ALSA constraint resolver code. The two fixes are totally independent and the video and audio side patches applied separately trough their own trees. Jyri Sarha (2): OMAPDSS: hdmi: Reconfigure and restart audio when display is enabled ASoC: omap-hdmi-audio: Set buffer bytes step constraint to 128 drivers/video/fbdev/omap2/dss/hdmi.h | 10 +++- drivers/video/fbdev/omap2/dss/hdmi4.c | 65 ++++++++++++++++++++----- drivers/video/fbdev/omap2/dss/hdmi5.c | 89 +++++++++++++++++++++++++++++------ sound/soc/omap/omap-hdmi-audio.c | 10 +++- 4 files changed, 146 insertions(+), 28 deletions(-) -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
