Re: [PATCH 08/18] ASoC: cs35l56: Fix default SDW TX mixer registers

[Pierre-Louis Bossart]

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