At Wed, 22 Jan 2014 15:18:21 +0100, Daniel Vetter wrote: > > On Wed, Jan 22, 2014 at 12:48:04PM +0000, Lin, Mengdong wrote: > > > -----Original Message----- > > > From: daniel.vetter@xxxxxxxx [mailto:daniel.vetter@xxxxxxxx] On Behalf Of > > > Daniel Vetter > > > Sent: Tuesday, January 21, 2014 9:11 PM > > > To: Lin, Mengdong > > > Cc: Takashi Iwai (tiwai@xxxxxxx); Barnes, Jesse; Zanoni, Paulo R; > > > alsa-devel@xxxxxxxxxxxxxxxx; intel-gfx@xxxxxxxxxxxxxxxxxxxxx > > > Subject: Re: Need your advice: Add a new communication inteface > > > between HD-Audio and Gfx drivers for hotplug notification/ELD update > > > > > > 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. > > > > Thanks for your advice, Daniel! > > > > > 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 ... > > > > Agree. Where to put this common object? > > Is it okay to put it under /driver/gpu/drm, similar to vga_switchroo? > > Shall we divide clients into audio and gfx categories, and define > > different ops for them? Since different info/request flow in different > > direction between audio and gfx. > > I guess we could place them into drivers/gpu, yeah. For a name I'd suggest > avsink or something like that, to make it clear that it's the combination > of audio+video. For the actual interfaces I guess we just need one object > in the device model, but the interface should be split into things called > from the audio side only, functions for the video driver side only and > stuff which can be called from both sides. This matters mostly just so we > don't end up with deadlocks since we need a lock to protect the avsink > state itself (e.g. the EDL or the audio_output_connected state). > > > > - 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. > > > > Sounds good. > > > > > - 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. > > > > Can the new infrastructure allow audio driver to query whether gfx driver is ready? > > Maybe audio can wait until gfx is ready. For HD-Audio driver, the most > > time consuming part is delayed after the probe stage, and actually we > > can wait in the delayed phase. > > Tbh I haven't really thought about this really. EPROBE_DEFER looks like > the technique used by embedded platforms, but there's also the new > aggregate device driver infrastructure that Russell King is working on for > the imx driver. Or maybe we need to hand-roll our own notification scheme. > > On a hunch it's probably best if the gfx side registers this device (since > it also owns the output state in general) and that the audio side waits > until the gfx side has registered everything if it's not there yet. I also > haven't though about how the audio side could probe for the right avsink > node really ... Yes, I think doing it first in the gfx side makes sense, too. > > > - 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. > > > > Is there something that blocks media player from doing the right thing now? > > For HD-Audio, the eld entries under /proc/asound/cardx expose the ELD > > info and can help user space to check if a monitor is usable on a pin. > > Current limitation is these eld entries cannot update if the audio > > controller is in D3, so we need the new infrastructure to notify audio > > driver to update them. But I'm not sure about embedded audio, maybe > > Takashi would like to share more info. > > ELD doesn't contain the serial number from the EDID, so if you have two > monitors of the same model userspace can't figure out which audio output > is connected to which screen. Right. And, comparing two different data just for knowing whether A and B are relevant is merely a pain. thanks, Takashi _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
