Re: [PATCH RFC v4 3/8] ASoC: hdmi-codec: Add hdmi-codec for external HDMI-encoders

From: Daniel Vetter <daniel@ffwll.ch>
To: Russell King - ARM Linux <linux@arm.linux.org.uk>
Cc: devicetree@vger.kernel.org, alsa-devel@alsa-project.org,
	peter.ujfalusi@ti.com, tony@atomide.com, broonie@kernel.org,
	Arnaud Pouliquen <arnaud.pouliquen@st.com>,
	dri-devel@lists.freedesktop.org, liam.r.girdwood@linux.intel.com,
	tomi.valkeinen@ti.com, Jyri Sarha <jsarha@ti.com>,
	bcousson@baylibre.com, linux-omap@vger.kernel.org
Subject: Re: [PATCH RFC v4 3/8] ASoC: hdmi-codec: Add hdmi-codec for external HDMI-encoders
Date: Mon, 28 Sep 2015 14:21:41 +0200	[thread overview]
Message-ID: <20150928122141.GC3383@phenom.ffwll.local> (raw)
In-Reply-To: <20150928112628.GC21626@n2100.arm.linux.org.uk>

On Mon, Sep 28, 2015 at 12:26:28PM +0100, Russell King - ARM Linux wrote:
> On Mon, Sep 28, 2015 at 11:01:34AM +0200, Arnaud Pouliquen wrote:
> > few questions/remarks
> > BR,
> > Arnaud
> > 
> > >+static void hdmi_codec_abort(struct device *dev)
> > >+{
> > >+    struct hdmi_codec_priv *hcp = dev_get_drvdata(dev);
> > >+
> > >+    dev_dbg(dev, "%s()\n", __func__);
> > >+
> > >+    mutex_lock(&hcp->current_stream_lock);
> > >+    if (hcp->current_stream && hcp->current_stream->runtime &&
> > >+        snd_pcm_running(hcp->current_stream)) {
> > >+        dev_info(dev, "HDMI audio playback aborted\n");
> > >+        snd_pcm_stream_lock_irq(hcp->current_stream);
> > >+        snd_pcm_stop(hcp->current_stream, SNDRV_PCM_STATE_DISCONNECTED);
> > >+        snd_pcm_stream_unlock_irq(hcp->current_stream);
> > >+    }
> > >+    mutex_unlock(&hcp->current_stream_lock);
> > >+}
> > Does driver should stop the stream in case of unplug?
> > This could generate unexpected behavior at application level.
> > Perhaps should be better if this part is managed in DRM driver. if HDMI
> > master, I2S bus should be maintained ON to consume the audio stream until
> > application action.
> 
> If it does, that's really horrid.

Atm the rule for display outputs is that nothing gets yanked until
userspace approves, since otherwise compositors get stuck (or fall over
with an unexpected -EINVAL from the kernel). The exception is DP MST
because the current implementation is a complete hack for DP MST sink
lifetimes and that's why we need to synchronously nuke them (which means
shutting down everything). I'm surprised not a hole lot more people
complain about this ...
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel