On Mon, 2012-08-20 at 20:47 -0500, Ricardo Neri wrote: > Hello! > > I have been working on prototypes for the ASoC OMAP HDMI audio driver to > propagate events from the HDMI output (e.g., display getting > enabled/disabled/suspended). This for the users of the driver to react > to such events. For instance, if the display is disabled or disconected, > audio could be stopped, rerouted or whatever other decision the user > makes. This is needed because, if, for instance, the HDMI IP goes off, > audio will stall and the audio users will only see a "playback write > error (DMA or IRQ trouble?)" > > In my prototypes I have used snd_soc_jack for this purpose and I have > some questions: > > *I see snd_soc_jack is used mostly for headsets and microphones with > actual external mechanical connections. Strictly, in my case I propagate > events originated by the OMAP display driver (changes in the power > state), and not from external events. Some of these events are generated > from an actual HDMI cable connection/disconnection, though. > > *Maybe the event should be propagated by omapdss/omapdrm/drm and the > entity in charge of the audio policy should listen those events instead. > > *I do see SND_JACK_VIDEOOUT and SND_JACK_AVOUT types so maybe it is > feasible for an audio driver to report events from an AV output. > > I was wondering about how much sense does it make to you guys use a > snd_soc_jack in this case? How does DRM handle audio? I made a quick grep, but I see the drm drivers only enabling the audio in the HW, nothing else. If there's a common generic way to handle this, we should obviously use that. But if we need to choose between doing something custom or doing it in omapdrm driver, I think we should go for drm the only solution and forget about audio with omapfb. Tomi
Attachment:
signature.asc
Description: This is a digitally signed message part
