From: Richard Fitzgerald <rf@opensource.cirrus.com>
To: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>,
<broonie@kernel.org>, <tiwai@suse.com>
Cc: <alsa-devel@alsa-project.org>, <linux-sound@vger.kernel.org>,
<linux-kernel@vger.kernel.org>, <patches@opensource.cirrus.com>
Subject: Re: [PATCH 08/18] ASoC: cs35l56: Fix default SDW TX mixer registers
Date: Tue, 30 Jan 2024 11:04:54 +0000 [thread overview]
Message-ID: <a8432725-6dc6-4765-831f-178dcee8b829@opensource.cirrus.com> (raw)
In-Reply-To: <4f54a12c-c8a3-414c-b4df-3f7b25e6d524@linux.intel.com>
On 29/01/2024 17:15, Pierre-Louis Bossart wrote:
>
>
> On 1/29/24 17:27, Richard Fitzgerald wrote:
>> Patch the SDW TX mixer registers to silicon defaults.
>>
>> CS35L56 is designed for SDCA and a generic SDCA driver would
>> know nothing about these chip-specific registers. So the
>> firmware sets up the SDW TX mixer registers to whatever audio
>> is relevant on a specific system.
>>
>> This means that the driver cannot assume the initial values
>> of these registers. But Linux has ALSA controls to configure
>> routing, so the registers can be patched to silicon default and
>> the ALSA controls used to select what audio to feed back to the
>> host capture path.
>
> humm, which has the precedence then?
> a) the values set by firmware
> b) the default values set by the driver?
>
> Also if the firmware touches those registers shouldn't they be marked as
> 'volatile'?
>
The firmware was designed to work with Windows, so it looks a bit
strange if you are coming at it from ALSA. There's not really any
defined 'precedence'. The firmware will setup the feedback monitor paths
to something that satisfies SDCA and Windows expectations.
We don't care about that in Linux, the firmware on the Intel DSP
probably isn't running the same algorithms for Linux, and we have ALSA
controls to configure those paths. So we patch the mixers back to their
silicon defaults and take over complete control of them.
The firmware only writes them during its power-up sequence so they
will only change when we are rebooting the firmware or coming out of
low-power standby, which is under the control of the driver. When that
happens regmap will re-apply the patch and then sync up the registers
again. The firmware won't touch them after boot, so we can avoid having
to mark them volatile (which would mean implementing our own manual
caching of the settings).
>
>> Backport note:
>> This won't apply to kernels older than v6.6.
>>
>> Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
>> Fixes: e49611252900 ("ASoC: cs35l56: Add driver for Cirrus Logic CS35L56")
>> ---
>> sound/soc/codecs/cs35l56-shared.c | 9 +++++++++
>> 1 file changed, 9 insertions(+)
>>
>> diff --git a/sound/soc/codecs/cs35l56-shared.c b/sound/soc/codecs/cs35l56-shared.c
>> index 35789ffc63af..a812abf90836 100644
>> --- a/sound/soc/codecs/cs35l56-shared.c
>> +++ b/sound/soc/codecs/cs35l56-shared.c
>> @@ -12,6 +12,15 @@
>> #include "cs35l56.h"
>>
>> static const struct reg_sequence cs35l56_patch[] = {
>> + /*
>> + * Firmware can change these to non-defaults to satisfy SDCA.
>> + * Ensure that they are at known defaults.
>> + */
>> + { CS35L56_SWIRE_DP3_CH1_INPUT, 0x00000018 },
>> + { CS35L56_SWIRE_DP3_CH2_INPUT, 0x00000019 },
>> + { CS35L56_SWIRE_DP3_CH3_INPUT, 0x00000029 },
>> + { CS35L56_SWIRE_DP3_CH4_INPUT, 0x00000028 },
>> +
>> /* These are not reset by a soft-reset, so patch to defaults. */
>> { CS35L56_MAIN_RENDER_USER_MUTE, 0x00000000 },
>> { CS35L56_MAIN_RENDER_USER_VOLUME, 0x00000000 },
next prev parent reply other threads:[~2024-01-30 11:05 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-29 16:27 [PATCH 00/18] ALSA: Various fixes for Cirrus Logic CS35L56 support Richard Fitzgerald
2024-01-29 16:27 ` [PATCH 01/18] ASoC: wm_adsp: Fix firmware file search order Richard Fitzgerald
2024-01-29 16:27 ` [PATCH 02/18] ASoC: wm_adsp: Don't overwrite fwf_name with the default Richard Fitzgerald
2024-01-29 16:27 ` [PATCH 03/18] ASoC: cs35l56: cs35l56_component_remove() must clear cs35l56->component Richard Fitzgerald
2024-01-29 16:27 ` [PATCH 04/18] ASoC: cs35l56: cs35l56_component_remove() must clean up wm_adsp Richard Fitzgerald
2024-01-29 16:27 ` [PATCH 05/18] ASoC: cs35l56: Don't add the same register patch multiple times Richard Fitzgerald
2024-01-29 16:27 ` [PATCH 06/18] ASoC: cs35l56: Remove buggy checks from cs35l56_is_fw_reload_needed() Richard Fitzgerald
2024-01-29 16:27 ` [PATCH 07/18] ASoC: cs35l56: Fix to ensure ASP1 registers match cache Richard Fitzgerald
2024-01-29 16:27 ` [PATCH 08/18] ASoC: cs35l56: Fix default SDW TX mixer registers Richard Fitzgerald
2024-01-29 17:15 ` Pierre-Louis Bossart
2024-01-30 11:04 ` Richard Fitzgerald [this message]
2024-01-30 11:12 ` Pierre-Louis Bossart
2024-01-29 16:27 ` [PATCH 09/18] ALSA: hda: cs35l56: Initialize all ASP1 registers Richard Fitzgerald
2024-01-29 16:27 ` [PATCH 10/18] ASoC: cs35l56: Fix for initializing ASP1 mixer registers Richard Fitzgerald
2024-01-29 16:27 ` [PATCH 11/18] ASoC: cs35l56: Fix misuse of wm_adsp 'part' string for silicon revision Richard Fitzgerald
2024-01-29 16:27 ` [PATCH 12/18] ASoC: cs35l56: Firmware file must match the version of preloaded firmware Richard Fitzgerald
2024-01-29 16:27 ` [PATCH 13/18] ASoC: cs35l56: Load tunings for the correct speaker models Richard Fitzgerald
2024-01-29 16:27 ` [PATCH 14/18] ASoC: cs35l56: Allow more time for firmware to boot Richard Fitzgerald
2024-01-29 16:27 ` [PATCH 15/18] ALSA: hda: cs35l56: Fix order of searching for firmware files Richard Fitzgerald
2024-01-29 16:27 ` [PATCH 16/18] ALSA: hda: cs35l56: Fix filename string field layout Richard Fitzgerald
2024-01-29 16:27 ` [PATCH 17/18] ALSA: hda: cs35l56: Firmware file must match the version of preloaded firmware Richard Fitzgerald
2024-01-29 16:27 ` [PATCH 18/18] ALSA: hda: cs35l56: Remove unused test stub function Richard Fitzgerald
2024-02-01 12:47 ` [PATCH 00/18] ALSA: Various fixes for Cirrus Logic CS35L56 support Mark Brown
2024-02-01 12:49 ` Takashi Iwai
2024-02-01 18:39 ` 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=a8432725-6dc6-4765-831f-178dcee8b829@opensource.cirrus.com \
--to=rf@opensource.cirrus.com \
--cc=alsa-devel@alsa-project.org \
--cc=broonie@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-sound@vger.kernel.org \
--cc=patches@opensource.cirrus.com \
--cc=pierre-louis.bossart@linux.intel.com \
--cc=tiwai@suse.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.