From: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
To: Charles Keepax <ckeepax@opensource.cirrus.com>
Cc: perex@perex.cz, bard.liao@intel.com, mengdong.lin@intel.com,
patches@opensource.cirrus.com, alsa-devel@alsa-project.org
Subject: Re: [PATCH alsa-ucm-conf 2/2] sof-soundwire: Add basic support for a 4x cs35l56 configuration
Date: Wed, 6 Dec 2023 09:39:06 -0600 [thread overview]
Message-ID: <8f9f67b1-a58f-4163-beda-46ae259fa16f@linux.intel.com> (raw)
In-Reply-To: <20231206094701.GI14858@ediswmail.ad.cirrus.com>
>>>>> + EnableSequence [
>>>>> + cset "name='AMP1 Speaker Switch' 1"
>>>>> + cset "name='AMP2 Speaker Switch' 1"
>>>>> + cset "name='AMP3 Speaker Switch' 1"
>>>>> + cset "name='AMP4 Speaker Switch' 1"
>>>>> + ]
>>>>
>>>> If we only need an on/off switch, I wonder if this can be made
>>>> conditional, i.e. enable/disable a control if it exists. That would
>>>> scale to various numbers of amplifiers without a need to add a 2-amp, 6
>>>> or 8-amp configuration.
>>>
>>> I think that is possible, would you lean towards modifying
>>> HiFi.conf to only include a single file for cs35l56, or would you
>>> lean more towards having each cs35l56-x.conf file include a
>>> single base file?
>>
>> I wasn't referring to partitioning of files, rather the conditional UCM
>> syntax,
>>
>> Condition {
>> Type ControlExists
>> Control "name='AMP4 Speaker Switch'"
>> }
>>
>
> I get that, but once you have added those you still have the
> issue HiFi.conf will load the speaker use-case as follows:
>
> False.Include.spkdev.File "/sof-soundwire/${var:SpeakerCodec1}-${var:SpeakerAmps1}.conf"
>
> Meaning the number of amps will be part of the file name
> requested. So my question was how you wanted to deal with that?
> Personally I would lean towards just having all the
> cs35l56-8.conf, cs35l56-6.conf etc. include a cs35l56-base.conf.
> Its slightly more files, but feels a bit less crufty than having
> a special case for cs35l56 to not include the number of amps in
> the filename.
Ah yes, I forgot that part...
I must admit I don't recall either what we were trying to achieve in UCM
with the number of amplifiers and speakers both added to the components
string: "cfg-spk:%d cfg-amp:%d"
Probably best to go with your solution and see what can be optimized
later...
prev parent reply other threads:[~2023-12-06 15:40 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-05 14:24 [PATCH alsa-ucm-conf 1/2] sof-soundwire: Add basic support for cs42l43 Charles Keepax
2023-12-05 14:24 ` [PATCH alsa-ucm-conf 2/2] sof-soundwire: Add basic support for a 4x cs35l56 configuration Charles Keepax
2023-12-05 15:25 ` Pierre-Louis Bossart
2023-12-05 16:28 ` Charles Keepax
2023-12-05 17:11 ` Pierre-Louis Bossart
2023-12-06 9:47 ` Charles Keepax
2023-12-06 10:09 ` Jaroslav Kysela
2023-12-06 10:31 ` Charles Keepax
2023-12-06 15:39 ` Pierre-Louis Bossart [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=8f9f67b1-a58f-4163-beda-46ae259fa16f@linux.intel.com \
--to=pierre-louis.bossart@linux.intel.com \
--cc=alsa-devel@alsa-project.org \
--cc=bard.liao@intel.com \
--cc=ckeepax@opensource.cirrus.com \
--cc=mengdong.lin@intel.com \
--cc=patches@opensource.cirrus.com \
--cc=perex@perex.cz \
/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