Received-SPF: pass (google.com: domain of linux-kernel+bounces-44465-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) client-ip=147.75.48.161;
Message-ID: <11280dec-cf3d-1694-d837-2bf263ad148a@linux.intel.com>
Date: Tue, 30 Jan 2024 12:12:36 +0100
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0)
 Gecko/20100101 Thunderbird/102.15.1
Subject: Re: [PATCH 08/18] ASoC: cs35l56: Fix default SDW TX mixer registers
To: Richard Fitzgerald <rf@opensource.cirrus.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
References: <20240129162737.497-1-rf@opensource.cirrus.com>
 <20240129162737.497-9-rf@opensource.cirrus.com>
 <4f54a12c-c8a3-414c-b4df-3f7b25e6d524@linux.intel.com>
 <a8432725-6dc6-4765-831f-178dcee8b829@opensource.cirrus.com>
Content-Language: en-US
From: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
In-Reply-To: <a8432725-6dc6-4765-831f-178dcee8b829@opensource.cirrus.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit


>>> 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).

ok, thanks for the explanations.