Re: [PATCH 2/7] drm/i915: Add get_eld audio component

From: David Henningsson <david.henningsson@canonical.com>
To: "Takashi Iwai" <tiwai@suse.de>,
	"Ville Syrjälä" <ville.syrjala@linux.intel.com>
Cc: Vinod Koul <vinod.koul@intel.com>,
	Daniel Vetter <daniel.vetter@intel.com>,
	intel-gfx@lists.freedesktop.org,
	Mengdong Lin <mengdong.lin@linux.intel.com>,
	alsa-devel@alsa-project.org
Subject: Re: [PATCH 2/7] drm/i915: Add get_eld audio component
Date: Mon, 30 Nov 2015 16:34:22 +0100	[thread overview]
Message-ID: <565C6C7E.4040902@canonical.com> (raw)
In-Reply-To: <s5hlh9fy07e.wl-tiwai@suse.de>

On 2015-11-30 16:29, Takashi Iwai wrote:
> On Mon, 30 Nov 2015 16:24:41 +0100,
> 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?
>
> We need this at least in two situations:
> - when the audio driver is probed
> - when the audio driver is resumed
>
>> 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.
>
> OK, then we may change the eld_notify to pass the values in the
> arguments, and also add the new op with a lock to be called from other
> places from other places.

Maybe we have to make eld_notify not do anything except to call 
schedule_work then? And that work in turn will ask for updated eld from 
the i915 driver, and handle the result.

-- 
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx