Need your advice: Add a new communication inteface between HD-Audio and Gfx drivers for hotplug notification/ELD update

[Daniel Vetter]

_Actually_ add dri-devel ...

On Tue, Jan 21, 2014 at 2:10 PM, Daniel Vetter <daniel at ffwll.ch> wrote:
> On Tue, Jan 21, 2014 at 1:35 PM, Lin, Mengdong <mengdong.lin at intel.com> 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