All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kai Vehmanen <kai.vehmanen@linux.intel.com>
To: Jaroslav Kysela <perex@perex.cz>
Cc: Takashi Iwai <tiwai@suse.de>,
	Cezary Rojewski <cezary.rojewski@intel.com>,
	Mark Brown <broonie@kernel.org>,
	ALSA development <alsa-devel@alsa-project.org>,
	Kai Vehmanen <kai.vehmanen@linux.intel.com>
Subject: Re: [alsa-devel] UCM extensions
Date: Thu, 7 Nov 2019 13:54:10 +0200 (EET)	[thread overview]
Message-ID: <alpine.DEB.2.21.1911071326410.16459@zeliteleevi> (raw)
In-Reply-To: <c53c36a7-bb55-abca-0e4f-9574d8fe3660@perex.cz>

Hi,

On Thu, 7 Nov 2019, Jaroslav Kysela wrote:

> Dne 07. 11. 19 v 11:18 Cezary Rojewski napsal(a):
> > On 2019-11-05 20:36, Jaroslav Kysela wrote:
> > However, I have some concerns here. First, could you elaborate on "we
> > require for the SOF kernel driver"?
> 
> Please, look here:
> 
> https://github.com/alsa-project/alsa-ucm-conf/commit/a8253465aef2df494ccd5b1103412b0318be582e#diff-a2ba34aee1a55c2fd664d78624477173L37
> 
> The HDA driver sometimes manages different JackControl names depending on the 
> used codec and it would be the real maintenance mess to use the DMI info (long 
> card name) for all possible configurations.
> 
> Also, if you look to the current configs, many duplications can be removed 
> with the If evaluations.

yes, I agree with Jaroslav here. There's definitely the risk of making 
UCM files too complex, but pragmatically, we really need something between 
the current boolean choice between a generic UCM picked by card 
shortname and per-product tailored UCM'es picked up by card longname.

There's some variation in HDA codec controls that is more
convenient to hide in if-else logic in the generic UCM. Same goes 
for addition of controls to the kernel. Without conditional logic, using 
a newer UCM file with an older kernel simply breaks -- even if the change
is incremental only.

There was a discussion in the summer on the list about adding versions in 
kernel and using that to help pick the right UCM profile. This isn't an 
easy path either -- there are many components contributing to the 
overall card interface on kernel side, and you still need to pick (or 
compile at runtime) a single UCM file. It would seem with Jaroslav's 
current proposal, you could cover majority types of minor variations
and thus significantly limit the number of UCM files that need to be 
maintained.

Br, Kai
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel

      reply	other threads:[~2019-11-07 11:55 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-05 19:36 [alsa-devel] UCM extensions Jaroslav Kysela
2019-11-05 19:52 ` Pierre-Louis Bossart
2019-11-05 20:19   ` Jaroslav Kysela
2019-11-05 20:27     ` Pierre-Louis Bossart
2019-11-06 11:50 ` Kai Vehmanen
2019-11-06 13:10   ` Jaroslav Kysela
2019-11-06 13:51     ` Jaska Uimonen
2019-11-06 17:04       ` Jaroslav Kysela
2019-11-07  6:48 ` Takashi Iwai
2019-11-07  8:33   ` Jaroslav Kysela
2019-11-07  9:23     ` Takashi Iwai
2019-11-07 11:08       ` Jaroslav Kysela
2019-11-07 11:16         ` Takashi Iwai
2019-11-07 13:14           ` Jaroslav Kysela
2019-11-07 10:18 ` Cezary Rojewski
2019-11-07 11:01   ` Jaroslav Kysela
2019-11-07 11:54     ` Kai Vehmanen [this message]

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.1911071326410.16459@zeliteleevi \
    --to=kai.vehmanen@linux.intel.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=broonie@kernel.org \
    --cc=cezary.rojewski@intel.com \
    --cc=perex@perex.cz \
    --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.