linux-fbdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Tomi Valkeinen <tomi.valkeinen@ti.com>
To: Jean-Francois Moine <moinejf@free.fr>
Cc: Mark Brown <broonie@kernel.org>, Jyri Sarha <jsarha@ti.com>,
	peter.ujfalusi@ti.com, liam.r.girdwood@linux.intel.com,
	alsa-devel@alsa-project.org, linux-omap@vger.kernel.org,
	linux-fbdev@vger.kernel.org
Subject: Re: [alsa-devel] [PATCH v7.1 00/19] Rework OMAP4+ HDMI audio support
Date: Thu, 13 Nov 2014 15:44:38 +0000	[thread overview]
Message-ID: <5464D1E6.4050508@ti.com> (raw)
In-Reply-To: <20141113160002.7a1157a5@armhf>

[-- Attachment #1: Type: text/plain, Size: 4763 bytes --]

On 13/11/14 17:00, Jean-Francois Moine wrote:

> When the tda998x is not operational, the CODEC knows it and reports an
> error to the audio subsystem on device open. But, once the tda998x has
> been started, it always stays operational, even without HDMI connection.

What does "started" mean here? tda998x device/driver has been probed?

The reason for the above is probably to handle hotplug? I.e. tda998x
needs to be enabled always to detect HPD?

Usually for OMAP, the HPD detection happens outside the HDMI IP. Thus
the HDMI IP is turned fully off when the video is disabled.

I believe tda998x could be used the same way, if the HPD pin is
connected to a SoC GPIO instead of tda998x.

>>> and I saw only a few dependencies between the 2 subsystems:
>>>
>>> - the CODEC must know the transmitter parameters (DAIs - static -,
>>>   audio constraints - dynamic -),
>>
>> The video mode (i.e. availability of audio) or the EDID (i.e. the
>> supported audio parameters) may change at any time, so I presume in your
>> series the video side will inform the codec of these changes at any point?
> 
> Such changes occur only when the HDMI output device (TV) is replaced by

The user can change the video mode at any time. The audio data packets
are sent in the video blanking intervals, and if those intervals are too
short, the video mode cannot support audio.

If I'm not mistaken, officially only certain video modes defined in the
HDMI spec support audio.

> an other one (manual cable exchange or HDMI switcher). I wonder if
> these changes are correctly treated in the HDMI transmitters, DRM core,
> DRM drivers, X11/wayland...

HPD (which usually equals to cable change, but not always) is handled.

>> a) Always keep the audio device operational, no matter what is the
>> status of the video side. How should this work if the HDMI videomode or
>> the HDMI monitor does not support audio? Is it desirable that the
>> userspace has no idea that the audio is not actually going anywhere?
>>
>> b) Remove the audio device when audio support is not available. This
>> kind of makes sense, as, well, there's no possibility for audio output.
>> But maybe this is not how linux sound devices are supposed to behave?
>>
>> c) Return errors when playback is attempted when audio support is not
>> available. Again, this kind of makes sense, as audio playback is not
>> possible. But maybe this is also not how audio devices generally work.
>>
>> Jyri, were there some other options we discussed?
>>
>> Currently, the OMAP HDMI version does c). It's the easiest solution for us.
> 
> Same for me, but checking the audio capability is done on audio streaming
> start only.

Hmm, I understood you have option a)? You said "I even let audio
streaming start when the HDMI cable is
disconnected".

With "audio support is not available" I mean also the case when the
cable is not connected, as then we don't have EDID information, and thus
we don't have a HDMI monitor with audio support on the other end.

So to clarify, our driver only has "audio support available" if:
- we successfully read EDID
- EDID shows it's a HDMI monitor
- EDID shows it has audio support for the format we support (this we
don't actually do yet)

Otherwise we default to DVI, which means no audio.

If, at any point, the situation changes to "no audio support available",
the audio playback is aborted and starting new audio playback fails.

> AFAIK, the HDMI transmitters don't know if the video or audio is
> displayed/played by the external device(s). Only the user knows.

True.

But the HDMI transmitter can know if the audio absolutely cannot be
played, because there's no cable, or because the monitor says it doesn't
support audio, or because the video mode cannot support audio, or
because the HDMI output stream is disabled.

So the question is, do we want/need to inform the userspace about those
situations? Should a HDMI transmitted always look like it can play
audio, even if it's clear it cannot?

Again, I know very little about audio, but I think it would be nice that
if I open the sound configuration window on my desktop, it'd show me
that the HDMI audio device is disabled (because there's no cable).

But perhaps that's a separate feature. We could have HDMI audio device
always there and functional, but the desktop could get the information
about HDMI cable connection some other way (DRM). And if the cable is
not there, it knows that this particular audio device is also out, and
thus doesn't show it (even if it's functional).

> BTW, you are talking about video modes without audio support. What are
> you thinking about?

This I covered above.

 Tomi



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

  reply	other threads:[~2014-11-13 15:44 UTC|newest]

Thread overview: 52+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-12 14:40 [PATCH v7.1 00/19] Rework OMAP4+ HDMI audio support Jyri Sarha
2014-11-12 14:40 ` [PATCH v7.1 01/19] OMAPDSS: hdmi_wp: Protect reserved bits in hdmi_wp_audio_config_format() Jyri Sarha
2014-11-12 14:40 ` [PATCH v7.1 02/19] OMAPDSS: hdmi5_core: Initialize mandatory sample_order parameter Jyri Sarha
2014-11-12 14:40 ` [PATCH v7.1 03/19] OMAPDSS: hdmi.h: Add HDMI_AUDIO_LAYOUT_6CH enum value Jyri Sarha
2014-11-12 14:40 ` [PATCH v7.1 04/19] OMAPDSS: hdmi: Remove most of OMAP[45]_DSS_HDMI_AUDIO ifdefs Jyri Sarha
2014-11-12 14:40 ` [PATCH v7.1 05/19] OMAPDSS: hdmi4_core: Remove unused hdmi4_audio_get_dma_port() Jyri Sarha
2014-11-12 14:40 ` [PATCH v7.1 06/19] OMAPDSS: hdmi_wp: Add function for getting audio dma address Jyri Sarha
2014-11-12 14:40 ` [PATCH v7.1 07/19] OMAPDSS: hdmi: Make hdmi structure public Jyri Sarha
2014-11-12 14:40 ` [PATCH v7.1 08/19] OMAPDSS: hdmi: Add pdev pointer for audio_pdev in HDMI DRV data Jyri Sarha
2014-11-12 14:41 ` [PATCH v7.1 09/19] ASoC: omap-hdmi-audio: Add platform device for OMAP HDMI audio support Jyri Sarha
2014-11-29 11:32   ` Mark Brown
2014-12-01  7:15     ` Jyri Sarha
2014-12-01 19:21       ` Mark Brown
2014-11-12 14:41 ` [PATCH v7.1 10/19] OMAPDSS: Kconfig: Remove HDMI audio booleans from Kconfig Jyri Sarha
2014-11-12 14:41 ` [PATCH v7.1 11/19] OMAPDSS: hdmi: Make hdmi_mode_has_audio() more user friedly Jyri Sarha
2014-11-14 14:37   ` Vladimir Zapolskiy
2014-11-14 15:05     ` Jyri Sarha
2014-11-17 15:12       ` Vladimir Zapolskiy
2014-11-15 15:52     ` Vladimir Zapolskiy
2014-11-12 14:41 ` [PATCH v7.1 12/19] OMAPDSS: hdmi.h: Add members to hdmi drvdata for audio implementation Jyri Sarha
2014-11-12 14:41 ` [PATCH v7.1 13/19] OMAPDSS: hdmi4: Remove callbacks for the old ASoC DAI driver Jyri Sarha
2014-11-12 14:41 ` [PATCH v7.1 14/19] OMAPDSS: hdmi4: Register ASoC platform device for omap hdmi audio Jyri Sarha
2014-11-12 14:41 ` [PATCH v7.1 15/19] OMAPDSS: hdmi5: Remove callbacks for the old ASoC DAI driver Jyri Sarha
2014-11-12 14:41 ` [PATCH v7.1 16/19] OMAPDSS: hdmi5: Register ASoC platform device for omap hdmi audio Jyri Sarha
2014-11-12 14:41 ` [PATCH v7.1 17/19] ASoC: omap: Remove obsolete HDMI audio code and Kconfig options Jyri Sarha
2014-11-12 14:41 ` [PATCH v7.1 18/19] OMAPDSS: Remove all references to obsolete HDMI audio callbacks Jyri Sarha
2014-11-12 14:41 ` [PATCH v7.1 19/19] OMAPDSS: hdmi5: Change hdmi_wp idlemode to to no_idle for audio playback Jyri Sarha
2014-11-12 22:23 ` [PATCH v7.1 00/19] Rework OMAP4+ HDMI audio support Mark Brown
2014-11-13  8:05   ` Tomi Valkeinen
2014-11-13  9:17     ` [alsa-devel] " Jean-Francois Moine
2014-11-13 10:00       ` Tomi Valkeinen
2014-11-13 14:54         ` Jyri Sarha
2014-11-13 14:57         ` Jean-Francois Moine
2014-11-13 15:44           ` Tomi Valkeinen [this message]
2014-11-14 10:59             ` Jean-Francois Moine
2014-11-20 10:59     ` Tomi Valkeinen
2014-11-21 11:23       ` Mark Brown
2014-11-21 12:10         ` Jyri Sarha
2014-11-21 16:38           ` Mark Brown
2014-11-24  8:48             ` Tomi Valkeinen
2014-11-24 14:55             ` Jyri Sarha
2014-11-21 12:35         ` Jyri Sarha
2014-11-21 16:14           ` Mark Brown
2014-11-24  8:18             ` Tomi Valkeinen
2014-11-24 17:39               ` Mark Brown
2014-11-25  9:26                 ` Tomi Valkeinen
2014-11-25 18:10                   ` Mark Brown
2014-11-26 11:02                     ` Tomi Valkeinen
2014-11-29 11:59 ` Mark Brown
2014-12-01  9:07   ` Tomi Valkeinen
2014-12-01 19:31     ` Mark Brown
2014-12-02  8:52       ` Jyri Sarha

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=5464D1E6.4050508@ti.com \
    --to=tomi.valkeinen@ti.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=broonie@kernel.org \
    --cc=jsarha@ti.com \
    --cc=liam.r.girdwood@linux.intel.com \
    --cc=linux-fbdev@vger.kernel.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=moinejf@free.fr \
    --cc=peter.ujfalusi@ti.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).