_Actually_ add dri-devel ... On Tue, Jan 21, 2014 at 2:10 PM, Daniel Vetter <daniel@xxxxxxxx> wrote: > On Tue, Jan 21, 2014 at 1:35 PM, Lin, Mengdong <mengdong.lin@xxxxxxxxx> wrote: >> Dear audio and gfx stakeholders, >> >> >> >> We hope to add a new interface between audio and gfx driver, for gfx driver >> to notify audio about HDMI/DP hot-plug and ELD update. >> >> Would you please share some comments on the proposal below? >> >> >> >> Background of this issue: On Intel Haswell/Broadwell platforms, there is a >> HW restriction that after the display HD-Audio controller is in D3, >> >> it cannot be waken up by HDMI/DP hot-plug. Consequently, although the gfx >> driver can still detect the HDMI/DP hot-plug, >> >> audio driver has no idea about this and cannot notify user space whether the >> external HDMI/DP monitor is available for audio playback, >> >> because the audio controller cannot wake up to D0 and receive HW unsolicited >> event about hot-plug from the audio codec. >> >> This limitation will affect user space to decide whether we can output audio >> over HDMI/DP. >> >> >> >> To solve the above limitation, Takashi suggested to add a new communication >> interface between audio and gfx driver: create a common object >> >> containing the ops registered by both graphics and audio drivers, then >> communicate through it, something like vga_switcheroo. >> >> >> >> Is it okay to create this kernel object in i915 driver? >> >> >> >> I915 can export an API like “display_register_audio_client” for audio driver >> to register a client and hot-plug notification ops. >> >> >> >> I915 can also call some API like “display_register_gfx_client” itself and >> register ops for audio driver to query monitor presence and ELD info on a >> specific port. >> >> It would be faster for audio driver than quering ELD by command/response >> over the HD-A bus, thus avoid delay in i915 mode set. >> >> This will also avoid waking up the audio devices unnecessarily if the user >> space does not really want to use HDMI/DP for audio playback. >> >> >> >> Whenever i195 enables/disables audio on a port in modeset, it can call some >> API like “display_set_audio_state()” on this kernel object and trigger >> notifications to the audio driver. >> >> >> >> When the audio driver is probed (in the delayed probe stage), it can request >> i915 API symbol to register the audio client for this communication kernel >> object. >> >> Since the 1st i915 mode set may happen before audio driver registers the >> ops, we’ll let audio driver check ELD once after registering the audio >> client ops. >> >> And for the platforms which uses this communication interface, we can >> disable unsolicited event for HDMI/DP hot-plug in the audio driver. >> >> >> >> We hope to hear your feedback and start to work out more details. > > Yeah, I've discussed this at KS with Takashi and we've agreed that > some common object to facilitate driver interactions. A few things > though: > - This should be common infrastructure useable by all alsa and drm > drivers, not just i915 and snd-hda. Especially on embedded platforms > this issue is fairly rampant ... > - While at it it should also encompass power management handling of > the shared hw imo so that we can get rid of the hsw specific hacks for > the power well code. Or at least we need to rework the power well code > to reuse this new infrastructure, I don't really want to maintain a > few copies of the lazy symbol_get logic this kind of stuff requires. > - I think the biggest problem is figuring out who should register > these device nodes. I think it makes the most sense if we do this in > the gfx driver, but that requires some trickery on the alsa side > (probably with using -EPROBE_DEFER or something like that. > - I agree that passing ELD and all the other information through this > new structure makes lot more sense than the current mess we have with > passing the ELD through some hardware buffer. > - Finally I think we should assign some identifier to this link which > will get exposed both on the drm side and in alsa, so that userspace > can figure out which display connects to which output. With that media > player could do the Right Thing and automatically place the audio > stream on the right pin in alsa. > > Adding dri-devel since that's where we imo need to have this discussion. > > Cheers, Daniel > -- > Daniel Vetter > Software Engineer, Intel Corporation > +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
