From: Russell King - ARM Linux <linux@arm.linux.org.uk>
To: Arnaud Pouliquen <arnaud.pouliquen@st.com>
Cc: devicetree@vger.kernel.org, alsa-devel@alsa-project.org,
liam.r.girdwood@linux.intel.com, tomi.valkeinen@ti.com,
dri-devel@lists.freedesktop.org, peter.ujfalusi@ti.com,
tony@atomide.com, broonie@kernel.org, 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 12:26:28 +0100 [thread overview]
Message-ID: <20150928112628.GC21626@n2100.arm.linux.org.uk> (raw)
In-Reply-To: <560901EE.60407@st.com>
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.
Firstly, do you expect your video playback to stop just because you've
unplugged the TV? Maybe you've got a dumb HDMI switch, and you've
switched from one input to another to momentarily check something on
another input - should the video playback suddenly end up with its
audio path being dumped on the floor because of that?
Also, as I've said before, there's hardware out there where the SPDIF
audio output is routed to more than just the HDMI interface, and the
capabilities of HDMI really don't apply in that situation - you may
have an AV receiver connected to the SPDIF output which is able to
accept much more than the basic audio that most TVs accept. Having
stuff restricted to the union of the abilities is far too restrictive.
Stopping the audio output because the TV went away in this case is also
plain idiotic.
SPDIF is something that can be routed to multiple devices simultaneously,
and there's no capability or connection reporting involved in it.
Imposing the status of one "SPDIF listener" on the entire audio system is
unreasonable.
> >+
> >+static int hdmi_codec_hw_params(struct snd_pcm_substream *substream,
> >+ struct snd_pcm_hw_params *params,
> >+ struct snd_soc_dai *dai)
> >+{
> >+ struct hdmi_codec_priv *hcp = snd_soc_dai_get_drvdata(dai);
> >+ struct hdmi_codec_params hp = {
> >+ .iec = {
> >+ .status = { 0 },
> >+ .subcode = { 0 },
> >+ .pad = 0,
> >+ .dig_subframe = { 0 },
> >+ }
> >+ };
> >+ int ret;
> >+
> >+ dev_dbg(dai->dev, "%s() width %d rate %d channels %d\n", __func__,
> >+ params_width(params), params_rate(params),
> >+ params_channels(params));
> >+
> >+ ret = snd_pcm_create_iec958_consumer_hw_params(params, hp.iec.status,
> >+ sizeof(hp.iec.status));
> Tell me if i am wrong, but in case of SPDIF format, IEC status is managed by
> cpu_dai not by the codec.
Correct. I2S needs the IEC958 status programmed into the HDMI interface
though, because HDMI is basically SPDIF.
--
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2015-09-28 11:26 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <mailman.310.1442574427.844.alsa-devel@alsa-project.org>
[not found] ` <56057A9E.9080602@st.com>
2015-09-28 9:01 ` [PATCH RFC v4 3/8] ASoC: hdmi-codec: Add hdmi-codec for external HDMI-encoders Arnaud Pouliquen
2015-09-28 11:26 ` Russell King - ARM Linux [this message]
2015-09-28 12:21 ` Daniel Vetter
2015-09-28 12:26 ` Jyri Sarha
2015-09-18 11:06 [PATCH RFC v4 0/8] Implement generic ASoC HDMI codec and use it in tda998x Jyri Sarha
2015-09-18 11:06 ` [PATCH RFC v4 3/8] ASoC: hdmi-codec: Add hdmi-codec for external HDMI-encoders Jyri Sarha
[not found] ` <6fe9ab5dff972e6f228259d6818f3f481a11577d.1442572860.git.jsarha-l0cyMroinI0@public.gmane.org>
2015-09-19 17:54 ` Mark Brown
2015-09-21 9:31 ` Russell King - ARM Linux
2015-09-21 13:41 ` Jyri Sarha
2015-09-21 17:18 ` Mark Brown
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150928112628.GC21626@n2100.arm.linux.org.uk \
--to=linux@arm.linux.org.uk \
--cc=alsa-devel@alsa-project.org \
--cc=arnaud.pouliquen@st.com \
--cc=bcousson@baylibre.com \
--cc=broonie@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=jsarha@ti.com \
--cc=liam.r.girdwood@linux.intel.com \
--cc=linux-omap@vger.kernel.org \
--cc=peter.ujfalusi@ti.com \
--cc=tomi.valkeinen@ti.com \
--cc=tony@atomide.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).