On Tue, Aug 21, 2012 at 1:01 AM, Tomi Valkeinen <tomi.valkeinen@xxxxxx> wrote: > 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. I confess to not knowing too much about audio/alsa, but what does audio driver need from hdmi? Just hotplug events? >From a quick look, it seems most of what the existing drm drivers are doing is detecting if the display supports audio, and then turning on/off the hw.. (and some infoframe stuff in some cases). Does ASoC support 'hotplug' of audio devices? If so, maybe it makes some sense to have some support in drm core. At least all the edid parsing stuff to determine if the display supports audio should be generic and not driver specific. BR, -R > 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 > _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
