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
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
