On 11/5/19 2:19 PM, Jaroslav Kysela wrote:
Dne 05. 11. 19 v 20:52 Pierre-Louis Bossart napsal(a):
On 11/5/19 1:36 PM, Jaroslav Kysela wrote:
Hi all,
I make some internal ucm code cleanups in alsa-lib and added three major extensions to allow more complex configurations which we require for the SOF kernel driver.
Great, thanks for working on this!
The first thing is the added substitution for the value strings:
https://github.com/alsa-project/alsa-lib/commit/f1e637b285e8e04e6761248a070f...
The second thing is the If block:
https://github.com/alsa-project/alsa-lib/commit/985715ce8148dc7ef62c8e3d8ce5...
is it possible for the Condition to check if the card contains the SOF prefix?
For Baytrail/Cherrytrail support, we have a ton of existing UCM files, and the only thing needed is e.g.
- to change from hw:bytcrrt5640 to hw:sofbytcrt5640
It is easy with the proposed substitution, just use hw:${CardId} here. It can for any values (like PCM device names etc.).
thanks for confirming, I thought it'd be fine indeed.
- make the controls for the legacy driver conditional
SectionVerb { EnableSequence [
if (card name does not contain SOF) <platforms/bytcr/PlatformEnableSeq.conf> endif <codecs/rt5640/EnableSeq.conf> ]
The If blocks cannot be used in sequences, but you can do basically this with the proposed If extension:
SectionVerb { If.1 { Condition { Type StringEqual String1 "${CardName}" String2 "bytcrt5640" } True { EnableSequence [ <platforms/bytcr/PlatformEnableSeq.conf> <codecs/rt5640/EnableSeq.conf> ] } False { EnableSequence [ <codecs/rt5640/EnableSeq.conf> ] } } }
The condition with "Type StringEqual" is not implemented yet, but it's easy to add new conditions to my proposed code. If you see something else to be compared, just let me know to add those conditions in the first phase.
ok, that's great.
Maybe StringContains would help, so that we can use String2 "sof" in most cases.
Most of the information that matters for those UCM files is the type of peripherals and the matching mixer configuration for the codec driver, and we should reuse this information between legacy and SOF.
Yes, I see the demand to make the description more universal and easy to read.
Note that cdev is already initialized from the ValueDefaults {} section PlaybackCTL/CaptureCTL values even in the old code, so the most of cdev declarations are not necessary in the current UCM configs too. When the use-case configuration is tied to the one card, I added the code to use it implicitly, so cdev can be really omitted. With the proposed code, the PlaybackCTL/CaptureCTL are always available for the one card configs:
https://github.com/alsa-project/alsa-lib/commit/c099329ce6ffdb26fc7a4a6ffb6f...
Yes, that's a good change, it'll make it easier to manage configurations.
-Pierre