At Thu, 23 Jan 2014 06:35:12 +0000, Lin, Mengdong wrote: > > > -----Original Message----- > > From: Takashi Iwai [mailto:tiwai@xxxxxxx] > > Sent: Thursday, January 23, 2014 1:19 AM > > To: Daniel Vetter > > Cc: Lin, Mengdong; Barnes, Jesse; Zanoni, Paulo R; > > alsa-devel@xxxxxxxxxxxxxxxx; intel-gfx@xxxxxxxxxxxxxxxxxxxxx; dri-devel > > Subject: Re: Need your advice: Add a new communication inteface > > between HD-Audio and Gfx drivers for hotplug notification/ELD update > > > > 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 for clarification! > Maybe we can add output info (eg. display port number) to the eld entries under /proc/asound/cardx. Is it okay? It's possible, but the proc file is just a help. It can't be the API. For accessing the information, we'll need some new API, or let inform via sysfs of the new device. > And I have a question: how to assure the audio/gfx client find its right peer? > On a x86 platform, there can be an integrated GPU and an discrete GPU. So there can be two audio controllers and two GPUs. > We need to assure audio controller find the proper GPU, and vice versa. Maybe we need the peer audio/gfx to register with a same identifier (something like vendor ID) for peering. Yes, it's an open issue. So far, the binding with vga_switcheroo is done by a rough guess with PCI ID. Takashi _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
