All of lore.kernel.org
 help / color / mirror / Atom feed
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 17:29:40 +0300 (EEST)	[thread overview]
Message-ID: <alpine.DEB.2.21.1908231652000.16459@zeliteleevi> (raw)
In-Reply-To: <s5hr25ma3xs.wl-tiwai@suse.de>

Hi,

On Thu, 15 Aug 2019, Takashi Iwai wrote:
> Kai Vehmanen wrote:
>> into modifying the SOF Intel backend to use 
>> snd-hda-codec-hdmi/patch_hdmi.c for HDMI/DP audio support, i.e. to be able 
>> to share this code between snd-hda-intel and SOF Intel (and not using 
>> hdac-hdmi).
[..]
>> This will change how HDMI is exposed to user-space with SOF Intel 
>> drivers, so we need to be extra careful how this is introduced. But 

> Agreed.  I guess the biggest difference is the handling of the 
> DP-MST.  The legacy HD-audio HDMI driver takes a different approach
> for DP-MST, namely, it chooses dynamically the pin that is connected
> with a monitor.  It's for keeping the compatibility (more or less)
> with old behavior; the program just needs to open the device that
> corresponds to the notification via jack ctl without fiddling with
> other extra routing.

indeed. I've now got to a point where I have the key functionality
in place. And after some reworks, the changes to patch_hdmi.c 
are pretty minimal, which is very nice (I started with a much more 
evasive patch).

But, but. The DP-MST handling is indeed iffy. I tried a few approaches, 
but it is hard to reconcile concept of "backup PCMs" of patch_hdmi.c with 
concepts of ASoC and ALSA topology, where the PCM and DAIs are supposed to 
be defined in the topology file. This gets worse with SOF (and any similar 
usage) which allow you to have arbitrary DSP processing between a PCM and 
the HDMI/DP DAIs. So this seems like a dead-end.

What I ended up doing was to make a new mode to patch_hdmi.c that limits 
PCM count to actual converter count (and this is aligned with topology), 
and still supporting DP-MST by always mapping monitors to a free PCM. I've 
tested some complex DP-MST scenarios and this seems to work pretty well. 
The jack detection will still be able to tell which of the PCMs have a 
monitor detected.

I wonder if this would be an acceptable approach, given 
the reuse benefits we get. Downsides:
- assignment of monitors to PCMs will depend on ELD update ordering
- in SOF we need to align PCM numbering scheme in all topologies 
  we convert over to patch_hdmi.c

I did not yet figure out how to toggle the new DP-MST mode in patch_hdmi.c 
in a nice way, so didn't sent patches to list yet. I'll do that early next 
week. If you want a sneak preview, I uploaded the series at:

https://github.com/thesofproject/linux/pull/1155

Br, Kai

  reply	other threads:[~2019-08-23 14:29 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 [this message]
2019-08-23 14:55     ` Takashi Iwai
2019-08-23 15:14       ` Takashi Iwai
2019-08-23 15:55         ` Kai Vehmanen
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.1908231652000.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.