From: Richard Fitzgerald <rf@opensource.cirrus.com>
To: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>,
<broonie@kernel.org>, <peter.ujfalusi@linux.intel.com>,
<yung-chuan.liao@linux.intel.com>
Cc: <kai.vehmanen@linux.intel.com>, <cezary.rojewski@intel.com>,
<ranjani.sridharan@linux.intel.com>,
<alsa-devel@alsa-project.org>, <linux-sound@vger.kernel.org>,
<linux-kernel@vger.kernel.org>, <patches@opensource.cirrus.com>
Subject: Re: [PATCH v3] ASoC: Intel: soc-acpi-intel-tgl-match: add cs42l43 and cs35l56 support
Date: Mon, 4 Dec 2023 15:54:35 +0000 [thread overview]
Message-ID: <f2dec209-6bc7-49ab-9dff-57a2ca4efb03@opensource.cirrus.com> (raw)
In-Reply-To: <8510b464-9352-480d-88cf-857597e16cbc@linux.intel.com>
On 04/12/2023 14:55, Pierre-Louis Bossart wrote:
>
>
> On 12/4/23 07:56, Richard Fitzgerald wrote:
>> From: Bard Liao <yung-chuan.liao@linux.intel.com>
>>
>> This is a test configuration for UpExtreme with Cirrus Logic
>> CS35L56-EIGHT-C board.
>>
>> The codec layout is configured as:
>> - Link3: CS42L43 Jack
>> - Link0: 2x CS35L56 Speaker (amps 1 and 2)
>> - Link1: 2x CS35L56 Speaker (amps 7 and 8)
>>
>> Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com>
>> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
>> Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
>> Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
>> ---
>> Changes since V1:
>> - Changed ALSA prefixes for CS35L56 to 'AMPn'
>> - Renumbered the CS35L56 prefixes to match the numbering of the
>> OUTn speaker sockets on the EIGHT-C board
>> ---
>> .../intel/common/soc-acpi-intel-tgl-match.c | 78 +++++++++++++++++++
>> 1 file changed, 78 insertions(+)
>>
>> diff --git a/sound/soc/intel/common/soc-acpi-intel-tgl-match.c b/sound/soc/intel/common/soc-acpi-intel-tgl-match.c
>> index 5804926c8b56..e5f721ba5ed4 100644
>> --- a/sound/soc/intel/common/soc-acpi-intel-tgl-match.c
>> +++ b/sound/soc/intel/common/soc-acpi-intel-tgl-match.c
>
>> +static const struct snd_soc_acpi_adr_device cs35l56_0_adr[] = {
>> + {
>> + .adr = 0x00003301FA355601ull,
>> + .num_endpoints = 1,
>> + .endpoints = &spk_r_endpoint,
>> + .name_prefix = "AMP1"
>> + },
>> + {
>> + .adr = 0x00003201FA355601ull,
>> + .num_endpoints = 1,
>> + .endpoints = &spk_3_endpoint,
>> + .name_prefix = "AMP2"
>> + }
>> +};
>> +
>> +static const struct snd_soc_acpi_adr_device cs35l56_1_adr[] = {
>> + {
>> + .adr = 0x00013701FA355601ull,
>> + .num_endpoints = 1,
>> + .endpoints = &spk_l_endpoint,
>> + .name_prefix = "AMP8"
>> + },
>> + {
>> + .adr = 0x00013601FA355601ull,
>> + .num_endpoints = 1,
>> + .endpoints = &spk_2_endpoint,
>> + .name_prefix = "AMP7"
>> + }
>> +};
>
> Don't we need the same change of name_prefix for
> soc-acpi-intel-mtl-match.c? I see this in the existing code:
>
The chain that Peter sent only has CS35L56 added to tgl-match.
I've checked the history of mtl-match and the patch that added CS35L56
there was not cc'd to any cirrus.com email address so we didn't notice
it. Otherwise we would have picked this up earlier. alsa-devel is noisy.
I haven't got a MTL platform to test on but I can send a separate patch
to change mtl-match if you are happy with this prefix change.
FWIW I was going to switch to using "cs35l56-n" prefix but while editing
all our unit test cases to the new prefix I realized that's a problem if
we make similar devices with the same controls. We often make a family
of devices that have the same (or very similar) software interface - for
example CS35L41/L51 and the CS47L15/35/85/90/92/93/48L92 family. If we
use the chip ID as the prefix it would create a bogus change in the ALSA
control names even though they are the same controls. OTOH if we used
"cs35l56-n" for all cs35l56-like devices (to avoid the name change) it's
strange that there's a control named for a chip you don't have...
If it quacks like a duck it would be nice if it looks like a duck :)
next prev parent reply other threads:[~2023-12-04 15:55 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-04 13:56 [PATCH v3] ASoC: Intel: soc-acpi-intel-tgl-match: add cs42l43 and cs35l56 support Richard Fitzgerald
2023-12-04 14:55 ` Pierre-Louis Bossart
2023-12-04 15:54 ` Richard Fitzgerald [this message]
2023-12-04 16:44 ` Pierre-Louis Bossart
2023-12-05 13:11 ` Mark Brown
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=f2dec209-6bc7-49ab-9dff-57a2ca4efb03@opensource.cirrus.com \
--to=rf@opensource.cirrus.com \
--cc=alsa-devel@alsa-project.org \
--cc=broonie@kernel.org \
--cc=cezary.rojewski@intel.com \
--cc=kai.vehmanen@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-sound@vger.kernel.org \
--cc=patches@opensource.cirrus.com \
--cc=peter.ujfalusi@linux.intel.com \
--cc=pierre-louis.bossart@linux.intel.com \
--cc=ranjani.sridharan@linux.intel.com \
--cc=yung-chuan.liao@linux.intel.com \
/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.