On Mon, Nov 30, 2015 at 05:34:45PM +0100, Daniel Vetter wrote:
On Mon, Nov 30, 2015 at 06:09:33PM +0200, Ville Syrjälä wrote:
On Mon, Nov 30, 2015 at 05:24:41PM +0200, Ville Syrjälä wrote:
On Mon, Nov 30, 2015 at 02:37:46PM +0100, Takashi Iwai wrote:
Implement a new i915_audio_component_ops, get_eld(). It's called by the audio driver to fetch the current ELD of the given HDMI/DP port. It returns the size of ELD bytes if it's valid, or zero if the audio is disabled or unplugged, or a negative error code.
Why do we need this? Isn't it something the eld notify hook should pass from i915 to the audio driver?
At least with the locking you have for this, the audio driver can not call this from the eld notify hook since it would deadlock.
Hmm. Actually the locking isn't perhaps quite like that atm. But I guess the mode_config.mutex will make it so.
If we need this we could create a substruct in dev_priv with copies of everything, which would only be protected by av_mutex. That's the usual approach we use when faced with this kind of locking inversion: Copy/update relevant data in the modeset ->enable/disable hooks, then just use these local locks to access those copies. Usually that's enough to untangle things, with no need to resort to workers.
Yeah, IIRC I suggested just that originally.