From: Kai Vehmanen <kai.vehmanen@linux.intel.com>
To: Takashi Iwai <tiwai@suse.de>
Cc: alsa-devel@alsa-project.org
Subject: Re: sof/hda rework to share more of patch_hdmi.c logic
Date: Fri, 23 Aug 2019 18:55:05 +0300 (EEST) [thread overview]
Message-ID: <alpine.DEB.2.21.1908231831310.16459@zeliteleevi> (raw)
In-Reply-To: <s5h36hrrk1j.wl-tiwai@suse.de>
Hey,
On Fri, 23 Aug 2019, Takashi Iwai wrote:
> On Fri, 23 Aug 2019, Takashi Iwai wrote:
> > The current patch_hdmi.c implementation is based on the theoretical
> > possibility, and limitation to the reduced PCM streams would work, I
> > suppose.
[...]
> access to the fixed PCM device (e.g. hw:1,1). But, it's hardly
> possible to get more than three audio-monitors active in the real
> scenario, we've almost never seen this necessity.
ack. This does feel very unlikely to be a problem. And one could implement
a wait list -> delay PCM attach if all audio converters are taken when the
new monitor ELD update happens. Upon next disconnect of an already
attached audio enabled monitor, one could check the wait list and hook up
monitors to the freed converters. But yeah, at least on i915 I don't see
the need for this.
This does raise the question whether we should change the behaviour
for the non-DSP HD driver as well...? Tempting, but the risk for breaking
apps may be too high.
> The actual behavior can be found in the description of commit
> a76056f2e57e:
>
> When monitor is connected, find a proper PCM for the monitor.
> When monitor is disconnected, unbind the PCM from the pin.
>
> The binding policy (use Intel platform as example) is:
> 1. Try to use the legacy pin-pcm mapping for the device entry 0
> of the pin.
> 2. If step 1 fails, try to bind pin to the backup PCMs. For example,
> on Intel platform, if DP MST is enabled, 5 PCMs will be created.
> PCM 3, PCM 7, PCM 8 are supposed to be used by device entry 0 of
> pin 5, pin 6 and pin 7. PCM 9 and PCM 10 are the backup PCMs.
> 3. If step 2 fails, try to find any PCM to bind to the pin.
>
> Removing the backup streams means the removal of step 2, but the
> driver will keep working in step 3.
Yes, I didn't have to actually change this code at all. I just limit the
PCM count to number of converters, and the above code works without
modifications (and skips (2)). Only problem left is how to change to
toggle the different rules for calculing pcm count. Unless we change the
behaviour for non-DSP HD driver as well, there needs to be some dynamic
configuration of patch_hdmi. Kconfig/module-param won't do, I assume
distros want to enable both options with same kernel.
Thanks for the quick response!
Br, Kai
next prev parent reply other threads:[~2019-08-23 15:55 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-15 14:28 sof/hda rework to share more of patch_hdmi.c logic Kai Vehmanen
2019-08-15 14:39 ` Takashi Iwai
2019-08-23 14:29 ` Kai Vehmanen
2019-08-23 14:55 ` Takashi Iwai
2019-08-23 15:14 ` Takashi Iwai
2019-08-23 15:55 ` Kai Vehmanen [this message]
2019-08-23 17:18 ` Takashi Iwai
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=alpine.DEB.2.21.1908231831310.16459@zeliteleevi \
--to=kai.vehmanen@linux.intel.com \
--cc=alsa-devel@alsa-project.org \
--cc=tiwai@suse.de \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.